Why spoofing is the number one security problem on the Internet, and how
we should fight it
This article explains the widely underestimated security
impact of the current lack of anti-spoofing measures on the Internet.
The Internet Protocol (IP) basically works with small portions of data
called datagrams that contain a small header that is used for address
information. This header contains two addresses:
The first address determines where the datagram should go. The second
address tells the destination where the datagram originated. In the
handling of this second address there lies a problem.
- The destination address.
- The source address.
Part of the merits of the IP protocol come from the fact that it is
connection less, and that routers make routing actions based on
destination address without any influence by the source address. This
works fine on the parts of the Internet that
are designed for redundancy, where filtering would in many cases
be impossible, but unfortunately this way of working is
deadly when used outside of the major backbone
Network administrators have the choice to do source based IP filtering
on their routers with so called anti-spoofing filters. Unfortunately much
of the network administrators do not. Further, network hardware and OS
manufacturers have the choice to make 'anti-spoofing' the default
operation for their products, unfortunately non of them seem to take their
responsibility on that either. It is this
combination of reluctance and ignorance that is the
indirect course of the fast majority of security problems on the
This article I tries to explain the full extend of the
spoofing problems on Internet security, and the methods that should be
taken by responsible administrators and manufacturers.
(NOTE: In this article the full technical details are kept to a
minimum, and do not describe combinations with other techniques that are
sometimes needed for successful spoofing. This is done in order
not to make this document into a hackers guideline
to spoofing. This however also means that the summary of spoofing dangers
described here is not fully complete, and for example some of the
techniques that are described as being only possible on shared sniffable
segments for a part are also possible outside of such a context))
Spoofing combined with Sniffing
One of the best known dangers of spoofing is the use of spoofing in
combination with sniffing in order to perform an attack where the sniffed
data is used to craft a response that has one of the following
Spoof address translation in order for the machine of the spoofer
to make the target believe that it is the party that is is trying to contact,
examples of this form of spoofing are:
- DNS spoofing: This spoofing method will convince the target machine
that the machine that it wants to contact (for example
www.somecompany.com) is the machine of the attacker, or in an other
implementation that the name of the attacker machine is a name with
elevated access rights. If for example the machine 'operator.domain.com'
is allowed administrator rights on a database, this spoofing method could
convince the database that the attacking machine has this name.
- ARP spoofing: This spoofing method is simular to the DNS spoofing, but
only one layer lower in the TCP/IP stack, and further it will also work on
switched networks. With this method the attacker could convince any host or
router that it is the host or router on the local network that it should
forward its IP datagrams to. This method is now commonly used for sniffing
TCP takeover: This method of spoofing will wait for the authentication
phase of a TCP session to complete, and will after this insert data into
the existing TCP stream.
Spoofing without sniffing
Although the spoofing techniques that are possible when combined with
sniffing as described above are the best known, they are not the only
dangers, in fact their impact on the overall Internet security is the
low when compared with techniques that do not require sniffing.
Spoofing for untraceable DoS
DoS attacks that rely on malformed packets of connection less protocols can
use IP spoofing in order to masquerade the true origin of the packets,
this means that even if you are able to detect the attack, you will not be
able to trace or stop it as the attacker does not need any response from
the target. Blocking the IP of the attacker will not work as the attacker has
the full Internet address range of IP addresses to choose from, and will
only result in a DoS of the service you are trying to protect.
Spoofing as DoS weapon
The spoofing of IP can itself be used as a DoS weapon. A host that server
state-full protocols will in a network without spoofing possibilities be
able to set a limit the amount of state objects it maintains for a single
IP address. If however the attacker is able to spoof a large amount of IP
addresses, than this attacker can have the host create a large amount of
state objects in order to DoS this system.
Spoofing as stealth scan method
Before an attacker will attack a specific server he will in most cases want
to scan the system in order to find out as much as possible about the
system. In many cases this scan could alert fire-walls, IDS systems and
their administrators of a forthcoming attack, and could point the
administrator to the originator of a following (basic) DDOS attack.
By hiding the actual scan in a large amount of spoofed scanning datagrams
from a wide range of IP addresses, the attacker will be able to hide the
real scan from the administrators.
Spoofing as IDS DoS
In order to detect and stop hack attacks many companies now implement so
called Intrusion Detection Systems. These systems when combined with
fire-walls that support them will in the ideal case stop a hack that is in
progress ones specific or generic hacking fingerprints are detected.
A problem however with IDS systems is that they have to do a wide range of
CPU intensive and state-full protocol analysis. Datagrams can be
crafted to use a
maximum amount of IDS resources (state objects and cpu) per byte of
datagram. By using again a large amount of spoofed IP addresses,
and by again using this to create as
much as possible state objects on the IDS system, combined with large
strains on the IDS to do the full set of protocol analysis it will in many
cases be possible to heighten the latency of the IDS detection to
such an extend that the full attack can be implemented before the IDS has
been able to detect it.
Spoofing and DoS of fire-walls
In many cases IDS and firewall systems will be able to early detect
attacks. A firewall might take action on this by blocking the specific
suspect IP address for a period of time. However the problem of spoofing
will make this solution one that not many administrators will choose to
implement. This point is the point that makes me conclude that spoofing is
'the' number one problem in Internet security.
implement strict fire-walling, than spoofing possibilities will make these
strict rules become DoS vulnerabilities themselves.
firewall would block any IP that initiates an attack, an attacker that would
spoof a large range of IP addresses will be able to let the firewall become
a DoS tool.
In fact this means in the current 'highly spoofable' Internet you have a
difficult choice between two possibilities:
Taking this into account, and taking into account that most ISP's and
manufacturers don't take anti-spoofing measures so serious as to warrant
them to implement them, the only thing to conclude is that there
is a large underestimation of the spoofing problem both with system
administrators and with router and OS manufacturers.
- Being potentially penetratable
- Being highly DoS-able
Anti spoofing measures
Spoofing is nothing new, spoofing measures are also nothing new, however
the major growth of the Internet has resulted in a large amount of
office network administrators, that never had to worry
about spoofing moving to a internetwork administration.
This combined with the fact that many of the anti-spoofing rules that could
be implemented implicitly by routers and hosts are not accounts for the
fact that an extreme large portion of the Internet is at this moment
a possible source of spoofed datagrams.
When looking at the security implementations the available
simple anti-spoofing measures could have if implemented globally, it is
essential that the responsible people are educated about their
responsibility and possibilities.
Border router filter rules
Much of the anti-spoofing rules could reside on the border routers of
ISP's. The principle is simple, the ISP knows its own networks, in general
all the ISP has to do on the border routers is put in the following rules:
The first one is basically the most important, it is also described in
rfc2827 as 'the' way to
fight DoS attacks, but as this article shows its implementation has a much
wider impact. RFC3013
describes these measures also in a
somewhat broader perspective, unfortunately not many ISP's seem to be
aware of these RFC's.
- Don't let anything out with a source IP address not belonging to the ISP
- Don't let anything in with a source IP address belonging to the ISP
Access router filter rules
Next to the border routers the access routers could also be used in order
to prevent IP spoofing at its most common source, these filters however
can be sometimes tricky when combined with some dynamic IP and
'multi-POP' static IP routing. If implemented well however these filters
can completely prevent IP spoofing that originates from an access network.
Tools for auditing router spoofing filters
In order to test and educate I have created a simple set of perl scripts
that can test the anti-spoofing filters between two test points.
Anti spoofing for shared-segments
Next to cross-network spoofing, any network that uses shared-segment
technologies is vulnerable to L2 spoofing specific to these types of
Static ARP tables
The ARP protocol is a protocol that is used on shared segments in order to
'map' IP addresses to MAC addresses. This protocol is particular vulnerable
due to the fact that it makes use of broadcasts, and has not a single
form of authentication in the protocol.
Basically when a system needs to send a IP datagram, it will look to see if
the IP address is in its current ARP table. If it is not it will broadcast
an ARP request on the shared segment, and will bind the IP address to the
MAC address mentioned in the ARP response it receives on this.
The use of spoofed ARP responses makes it possible for an attacker to
disrupt the network, but more than that makes it possible for the attacker
to implement a simple man-in-the middle attack, or in its simplest form to
sniff a switched network that would otherwise be non-sniffable.
If hosts and routers implement Static ARP tables this problem can
ARP table based MAC/IP filtering
The use of static ARP tables takes away much of the impact of the
shared-segment spoofing, but one important point still remains.
Most operating systems do not (at least not by default) check if
a received IP datagram originated from a MAC address that makes any
The use of the (static) ARP table in combination with the
routing table could prevent most of the shared-segment spoofing
possibilities. For this the following rules should be followed:
The use of these filters is unfortunately not possible in the majority of
operating systems, it is however crucial to the security of insecure
shared-segment networks that this solution is implemented.
- Local IP datagram IP source addresses should match the MAC addresses in
the static ARP table.
- Non-local IP datagrams should match the MAC address of one of the
'known routers' that has a valid route entry in the routing table.
Next to the spoofing of ARP in order to remap an IP to an existing MAC
address end the spoofing of only the IP address, it is also possible for
an attacker to spoof both the IP and the MAC address.
shared-segment switches fortunately have a security feature called 'MAC
locking'. This feature makes it possible to lock a MAC address to a
specific physical port of the switch. This combined with static ARP and
MAC/IP filters could totally eradicate the spoofing possibilities on a
Implicit anti-spoofing rules
One of the major reasons why most of the above anti-spoofing measures
are not taken on a large portion of the Internet is the fact that the
OSses that implement them all require 'explicit' configuration of the
filters. It is however very good possible to implement a large portion of
the anti-spoofing filters to be implemented implicitly by the operating
system as a result of other configuration actions.
This will not completely close all the spoofing gaps, it will however
close the most influential part of them, without any security competence
required from the end users.
Implicit ingress/egress router filters
For a router the most simple rule for anti-spoofing would be:
If there is no route in one direction, assume there is no route in the other direction.
Although this rule will not always be completely trough, the number of
components where it is not true is much and much smaller than the number
of routing components where this is a valid assumption.
If router manufacturers would implement this rule as default it would
prevent most of the spoofing on the Internet.
Implicit partial static ARP tables
Although full static ARP tables may not be possible as implicit
configuration, a partial implementation will also improve the security of
shared-segment networks. based on the assumption that:
Routers are rather statical components in a network infrastructure
It will be valid for any host to assume the MAC address of the system
configured as router will remain valid for a very large period of time,
in particular on networks that only have one or two 'default gateways' and no
further routers. Taking this into account it should be considered valid
if the operating system would store the ARP table entries of the IP
addresses that have routing table entries, and implicitly bind the
system configuration of routing table entries to the maintenance of a
partial static ARP table.
Implicit MAC/IP filtering
The implementation of the partial static ARP tables can be combined with
the assumption from the Implicit ingress/egress router filters that:
If there is no route in one direction, assume there is no route in the other direction.
This would mean that any external IP should originate from one of the
MAC addresses that belongs to an entry in the routing table that has got
a matching route to the originating IP address.
Further when combined with the (dynamic or static) ARP table, any 'local'
IP address that does have an entry in the ARP table should not be accepted
from any other MAC address.
Rob J Meijer 07/2001