Eliminating IP Spoofing
When IP routers forward packets, they inspect their destination address to determine the outgoing interface or the next step router towards the packet’s destination. Given this, a simple router does not need to look at the source address of the packets. The source address is mainly used by the destination to send the return packets or by intermediate routers to generate ICMP messages when problems are detected. This assumption was true in the the early days of the Internet and most routers only looked at destination addresses.
However, authorising routers to ignore the source address of the packets that they forward opens a huge security hole. Consider the simple network shown in the ASCII Figure below. Assume that there are three subnets:
H1--+ | +--R8---R8--- H3 | | H2
R8 advertises the
2001:db8:1/64 prefix on the subnet that includes host
H1 and it auto-configures its address as
2001:db8:1::1/64. Similarly, host address
2001:db8:2::2 is configured on
H3 runs an important service, such as a web server or a DNS server. Denial of service (DoS) attacks are an important risk for a public service. If
H1 is malicious, it could send packets to
H3 faster than
H3’s ability to process them. This would make
H3 unusable. The administrators of
H3 could detect the source of these attacks by observing the packets that they receive. However, the malicious host could hide its attack by sending packets with a different source address than its allocated one. For example, assume that
H1 sends packets towards
H3 with the
2001:db8:2::2 source address. This behaviour is called IP Spoofing because
H1 spoofs the address allocated to
R9 will forward these packets based on their destination address. They will eventually reach
H3 that will reply towards
H2. In addition to overloading ` H3
the attack launched by H1
will now also overload H2
. In some cases, H2` is the real target of the attack and the attacker exploits the amplification capabilities of some services. For example, a short DNS request sent to a DNS server will usually result in a longer reply that includes some DNS resource records.
Fortunately, there are techniques and network operators can and should deploy to prevent those IP spoofing attacks. The easiest approach is to filter packets based on their source address as closely as possible to the sources. BCP38, also known as RFC2827, requires the deployment of this filtering on all networks connected to the Internet.
Unfortunately, even if BCP38 was published in 2000, it is still not universally deployed,, neither in IPv4 nor in IPv6 networks. CAIDA, as part of their ongoing effort to measure the Internet, have deployed a measurement tool that can be used to check whether a given network can be used to send spoofed packets. You a encouraged to install this tool and use it regularly. If you spot a network that still forwards spoofed packets, do not hesitate to contact the network administrators to ask them to fix the problem.
CAIDA also publishes a summary report that lists the vulnerable networks. If you administer a network, check from time to time that you do not appear in this ‘most wanted’ list of vulnerable networks…