4.5. What Is IP Spoofing?


One tactic used in malicious attacks, particularly in DDoS, is IP spoofing. In normal IP communications, the header field contains the source IP address and the destination address as set by the default network socket operations. IP spoofing occurs when a malicious program creates its own packets and does not set the true source IP address in the packet's header. It is easy to craft individual packets with full control over the IP header and send them out over the network if one has sufficient privileges within the operating system. This is referred to as raw socket access.

A natural question to ask is why does this capability exist in the TCP/IP stack? There are perfectly legitimate reasons to craft packets by hand and transmit them on the network, rather than only use functions provided by a given TCP/IP stack's API; for example, in mobile IP environments, where a roaming host must use a "home" IP address in a foreign network [Per02], virtual private networks that set the host IP to an address local to the organization's network, etc. Regardless of the advisability of allowing use of raw sockets in the TCP/IP API, current operating systems lacking mandatory access control [Bell] and other advanced security features will have ways of getting around such limitations. Removal of raw sockets from the Windows API was proposed in 2001, and researchers showed many examples of programmers getting around the lack of raw sockets in earlier versions of Windows (e.g., the l0pht implemented a workaround for a lack of raw sockets in Windows 9x in l0phtcrack 3; PCAUSA provides a raw sockets implementation for Windows 9x see http://www.pcausa.com/; WinPcap implements a means of sending raw packets see http://netgroup-serv.polito.it/winpcap/). With the release of Windows XP Service Pack 2 in August 2004, Microsoft removed the raw sockets API, which broke applications like the public domain nmap port scanner. In just a few days, a workaround was produced restoring the ability of nmap to craft custom packets. See http://seclists.org/lists/nmap-hackers/2004/Jul-Sep/0003.html. We must also live with the fact that even if the ability to spoof addresses did not exist in the first place, DDoS would still not only be possible, but be just as damaging. There are simply too many ways to perform viable denial of service attacks.

There are several levels of spoofing.

  • Fully random IP addresses. The host generates IP addresses that are taken at random from the entire IPv4 space, 0.0.0.0 255.255.255.255. This strategy will sometimes generate invalid IPv4 addresses, such as addresses from 192.168.0.0 range, that are reserved for private networks, and may also generate nonroutable IP addresses, multicast addresses, broadcast addresses, and invalid addresses (e.g.,0.2.45.6). Some of these exotic addresses cause significant problems in their own right for routing hardware, which must process spoofed packets, and in some cases they crash or lock up the router. However, most randomly generated addresses will be valid and routable. If the attacker cares little about whether a particular packet is delivered, she can send large numbers of randomly spoofed packets and expect that most of them will be delivered.

A frequently proposed defense against random spoofing is to use a form of ingress and egress filtering [FS00]. (See Sidebar "Ingress/Egress Filtering" for a complete description of these sometime confusing terms and how they apply to the problem of IP spoofing.) This technique compares the packet's source address with the range of IP addresses assigned to its source or destination network, depending on the location of the filtering router, and drops nonmatching ones that appear to be randomly spoofed.

While ingress/egress filtering has the potential to greatly limit the ability of attackers to generate spoofed packets, it has to be widely deployed to really impact the DDoS threat. An edge network performing ingress/egress filtering is mostly scrutinizing its own traffic to protect others, but itself gains little benefit. This may be the reason why this type of filtering is still not widely deployed.

  • Subnet spoofing. If a host resides in, say, the 192.168.1.0/24 network, then it is relatively easy to spoof a neighbor from the same network. For example, 192.168.1.2 can easily spoof 192.168.1.45 or any other address in 192.168.1.0/24 range unless the network administrators have put in protective measures that prevent an assigned Ethernet hardware address (MAC address) being associated with any but the administratively assigned IP address. This is an expensive fix from an administration point of view.

If the host is part of a larger network (for example, a /16 network that contains 65,536 addresses), then it could spoof addresses from the larger domain, assuming the protective measures outlined in the previous point have not been implemented.

Packets spoofed at the subnet level can be filtered by ingress/egress filtering only at the subnet level, since their source address is, by definition, from an assigned address range for a given network. Even with such filtering at the subnet level, spoofing can still make it difficult to identify the flooding host.

Ingress/Egress Filtering

The terms ingress and egress mean, respectively, the acts of entering and exiting. In an interconnected network of networks, such as the Internet, what leaves (egresses) one network will enter (ingress) another. It is extremely important to clearly define the location where the filtering is done with respect to the network whose traffic is being filtered, to avoid confusion.

If there was one "Big I" Internet, and we all connected our hosts directly to "The Internet," life would be simple and we could just say "ingress means entering the Internet" and "egress means leaving the Internet," and everything would be clear. There would be only one perspective. But there is no "Internet" to which we all connect, and to make matters worse there are tier 1 and tier 2 network providers, as well as leaf networks (e.g., university and enterprise networks).

To see how a confusion can occur, take the example given in RFC 2827 [FS00]. It discusses ingress filtering in terms of an attacker's packets coming in to an edge router of ISP D. This is illustrated by the following figure.

Ingress/egress filtering example from RFC 2827

The authors of the RFC describe an attacker residing within the 204.69.207. 0/24 address space, which is provided Internet connectivity by ISP D. (This is shown in the above figure.) They describe an input traffic filter being applied on the ingress (input) link of Router 2, which provides connectivity to the attacker's network. This restricts traffic to allow only packets originating from source addresses within the 204.69.207.0/24 prefix, prohibiting the attacker from spoofing addresses of any other network besides 204.69.207.0/24.

The authors of this RFC only discuss ISP D doing filtering of traffic coming in to their edge router from their customer, shown in the figure on page 94 as Router 2. So in their example, ISP D does ingress filtering to avoid an attacker using "invalid" source addresses that appear to come from networks other than the customer's address range.

This RFC does not consider this same filtering also being done by the customer through the router the customer owns, Router 1. (This customer is known as an edge network, an end customer of a network service provider, or simply a leaf network.) If outbound packets are filtered on Router 1 to prevent source addresses from networks other than 204.69.207.0/24 leaving this leaf network, the customer would be doing egress filtering.

It would be very confusing to always say "ingress means packets going to the ISP" and explain that customer 204.69.207.0/24 does ingress filtering to block packets leaving its network, especially if the description is taken across more than one network (e.g., moving to the left in the figure on page 94.)

Another possible source of confusion in the use of these terms is that the filtering to be performed could be on any criteria, not just on source addresses. While discussion of these terms often focuses on the issue of mitigating IP spoofing, the filtering could be on protocol type, port number, or any other criteria of importance.

Within the context of handling IP spoofing, there are two important reasons for making the ingress/egress distinction, and they have to do with filtering being done for the same reason at two locations (perhaps simultaneously), the customer network's egress router and the ingress router of an ISP that connects to the customer's network.

  1. It can be argued that egress filtering of traffic leaving a leaf network is less expensive, CPU-wise, than the equivalent ingress filtering for that same traffic coming into a tier 2 network provider (and it is even worse if you go up one level to tier 1, or backbone providers, which is not the place to do ingress filtering to stop spoofed packets coming in from their peers.) [*] Given this argument, egress filtering on leaf networks to stop attackers from spoofing off-network hosts is more desirable.

  2. Spoofing can happen in either direction. Attackers outside your network can send packets inbound to your network pretending to be hosts on your network, and attackers inside your network can send packets outbound from your network pretending to be from hosts outside your network. This means that leaf networks should do both ingress and egress filtering to protect their network as well as other networks. Even if your ISP says it will filter packets coming into your network to prevent spoofing, you may want to do redundant filtering of those same packets to make sure that spoofing cannot take place. After all, don't things fail sometimes?

In this book, we will be careful to use ingress filtering to mean filtering the traffic coming into your network and egress filtering to mean filtering the traffic leaving your network. We will be explicit when talking about filtering being done by an ISP or tier 1 provider versus filtering being done by a leaf network. Where the filters are applied and why really does matter.


[*] see http://www.netsys.com/firewalls/firewalls-2001-06/msg00385.html

  • Spoofing the victim's addresses. This is the reflection attack scenario. The host forges the source address in service request packets (for example, a SYN packet for a TCP connection) to invoke a flood of service replies to be sent to the victim. If there is no filtering of packets as they leave the source network or at the entry point to the upstream ISP's router, these forged packets allow a reflection DoS attack.

4.5.1. Why Is IP Spoofing Defense Challenging?

There is nothing to prevent someone from spoofing IP addresses, since all that is required is privileged access to the network socket. One must put up filters and restrictions at the edge of every network to allow only packets with source addresses from that network to leave. For example, a network 192.168.1.0/24 (a /24 network containing 254 host addresses) should allow only address packets carrying a source from the range 192.168.1.1 192.168.1.254 to leave the network. Note the clear omission of the broadcast addresses 192.168.1.0 and 192.168.1.255 which are used in conjunction with spoofing in a Smurf attack. If any network does not put this form of filtering in place on its router, machines in that network can spoof any IP address.

There are sometimes good reasons not to turn this form of filtering on in your network. It requires a little extra network administration, and may temporarily shut off your Internet access if you make configuration mistakes. If you do turn anti-spoofing egress filtering on, it may break mobile IP support. It may be worth considering for other security implications, but you must realize that you are contributing to other networks' security, not your own. You would need expensive solutions to prevent spoofed traffic from reaching you. Some ideas are discussed in Chapter 7.

There are research results suggesting that it may be possible to detect many spoofed packets in the core of the Internet [PL01, LMW+01, FS00]. However, these approaches are immature, they require deployment in core Internet routers, and there is no reason to believe any of them will be adopted in the foreseeable future.

4.5.2. Why DDoS Attacks Use IP Spoofing

IP spoofing is not necessary for a successful DDoS attack, since the attacker can exhaust the victim's resources with a sufficiently large packet flood, regardless of the validity of source addresses. However, some DDoS attacks do use IP spoofing for several reasons.

  • Hiding the location of agent machines. In single-point DoS attacks, spoofing was used to hide the location of the attacking host. In such attacks, network operators find it hard to block the source of the attack and/or remove the offending host from the network, or even clean it. In DDoS attacks, the agents are the path to the handler, which provides an additional layer of indirection to the attacker. Hiding agents means hiding a quick path to the attacker.

  • Reflector attacks. Reflector attacks require spoofing to be accomplished. The agents must be able to spoof the victim's addresses in service requests directed at legitimate servers, to invoke replies that flood the victim.

  • Bypassing DDoS defenses. Some DDoS defenses build a list of legitimate clients that are accessing the network. During the attack, these clients are given preferential treatment. Other defenses attempt to share resources fairly among all current clients, each source IP address being assigned its fair share. In both of these scenarios, IP spoofing defeats the separation of clients based on their IP addresses, and enables the attack packets to assume the IP addresses of legitimate clients. Of course this only applies to UDP-based attacks, as one cannot typically spoof source addresses on TCP connection based services in order to bypass DDoS mitigation defenses.

4.5.3. Spoofing Is Irrelevant at 10,000+ Hosts

Looking at the history of DDoS attacks, one quickly realizes that given the sheer number of agents in a DDoS network, spoofing is not really necessary in a flooding attack, as described in Section 4.3.6. Agent networks of 10,000 hosts or more are not uncommon and are easily traded on IRC networks, where some malicious attackers use them as "currency." As shown in Section 2.5.2, botnets of 400,000 hosts are not impossible to obtain. At this size, preventing all spoofing could somewhat help certain DDoS defense approaches deal with certain forms of DDoS attacks. This alone would not eliminate the problem of DDoS.



Internet Denial of Service. Attack and Defense Mechanisms
Internet Denial of Service: Attack and Defense Mechanisms
ISBN: 0131475738
EAN: 2147483647
Year: 2003
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net