1.0 IP Address Spoofing
In order to send and receive data across the Internet, a universally agreed upon set of protocols is required to govern these activities. Although there are a number of communication protocols supported by the Internet, the principle method of communication is the TCP/IP protocol suite [1, 2]. The TCP/IP protocol suite is used to specify how data is transmitted across packet switched networks over the Internet.
The TCP/IP protocol suite uses numeric identifiers called IP addresses to uniquely identify computers on a network. Typical network communications such as email, file transfers, or web page requests all require the use of valid source and destination IP addresses. The source IP address identifies the data sender and the destination IP address identifies the data receiver. The basic unit of data transfer in a packet switched network is called an IP packet. Packets are composed of two basic components: a header portion that contains the necessary information to route the packet and a payload portion that contains the data [3]. Two 32-bit fields in the packet header contain the source and destination IP addresses.
The TCP/IP protocol suite has proven to be an effective communication method, but it does contain inherent security flaws. Steven Bellovin’s paper entitled, Security Problems in the TCP/IP Protocol Suite, describes some of these flaws in detail [4]. A number of these flaws exist because some systems rely on source IP addresses as a means of authentication. Access to a system or services provided by a system is decided based on the claimed source IP address contained in the packet. This means of authentication has proven to be unreliable. There have been many documented cases of intruders spoofing source IP addresses to gain unauthorized access to systems and services. IP address spoofing can be defined as the intentional misrepresentation of the source IP address in an IP packet in order to conceal the identity of the sender or to impersonate another computing system. The US Department of Energy Computer Incident Advisory Capability (CIAC) [5] and CERT/CC [6] have both released advisories that define IP address spoofing in the context of gaining root or privileged access to a system by an intruder impersonating a local system’s IP address. These advisories explain how systems that rely on session based IP address authentication are susceptible to IP address spoofing which, if successful, can allow an intruder to gain unauthorized access to a system or services.
In addition to using spoofed IP addresses as a means to gain unauthorized access to a system, it can also be used to conceal the identity of the packet sender. CERT/CC has issued advisories about the use of spoofed IP addresses as a method to conceal an attacker’s identity during flooding attacks [7] and to purposely cause systems to crash [8], both resulting in successful DoS attacks.
IP address spoofing is possible because the network devices that provide connectivity between individual networks, called routers, only require inspection of the destination IP address in the packet to make routing decisions. The source IP address is not required by routers and an invalid source IP address will not affect the delivery of packets. Spoofed IP addresses are an effective way to conceal an attacker’s identity during a DoS attack. When a DoS attack is launched against a system, the attacker is not interested in retrieving any information from the intended victim and thus the return or source IP address can be spoofed. In a DoS attack, the overall goal is to deny the use of services the system provides to authorized users without being discovered. One class of DoS attacks includes sending large volumes of network traffic to a system until it becomes overwhelmed and cannot respond to new requests for service. This type of DoS attacks is successful because computational resources are finite and every honored spurious request means one less legitimate request that can be serviced. Typically, the packets that comprise the flooding attack contain spoofed packets so that determining the source of the attack will be more difficult.
Figure 1: Valid source IP address, illustrates a typical interaction between a workstation with a valid source IP address requesting web pages and the web server executing the requests. When the workstation requests a page from the web server the request contains both the workstation’s IP address (i.e. source IP address 192.168.0.5) and the address of the web server executing the request (i.e. destination IP address 10.0.0.23). The web server returns the web page using the source IP address specified in the request as the destination IP address, 192.168.0.5 and its own IP address as the source IP address, 10.0.0.23.
Figure 1: Valid source IP address
Figure 2: Spoofed source IP address, illustrates the interaction between a workstation requesting web pages using a spoofed source IP address and the web server executing the requests. If a spoofed source IP address (i.e. 172.16.0.6) is used by the workstation, the web server executing the web page request will attempt to execute the request by sending information to the IP address of what it believes to be the originating system (i.e. the workstation at 172.16.0.6). The system at the spoofed IP address will receive unsolicited connection attempts from the web server that it will simply discard.
Figure 2: Spoofed source IP address
Basic networking concepts are discussed in the following section in order to provide the necessary context to discuss the technical aspects of IP address spoofing. Locating the origin of DoS attacks is very complex when IP address spoofing is used.
The Open Systems Interconnection Reference Model (OSI model) groups network protocols, communications, and applications into seven distinct layers [9]. It is a model that is used to understand how protocols or applications can work to interconnect networks. The model represents all the specifications, functions, and activities that need to occur for successful networking. Each layer in the model represents a group of related functions, specifications, and activities. TCP/IP is not a single protocol but rather a suite of protocols. It is comprised of the Internet Protocol (IP), Transmission Control Protocol (TCP), User Packet Protocol (UDP), and the Internet Message Control Protocol (ICMP). Using a suite of protocols rather than a single protocol simplifies the design and implementation of the hardware and software that allow computing platforms to be connected together. For a detailed explanation of the exact format and description of the TCP/IP protocol suite please refer to RFC 791 [2] and RFC 793 [1].
The TCP/IP protocol suite governs how data is transported across networks from host to host, but does not specify how data is transmitted across different physical media. Layer 2 of the OSI model governs how the raw signals on a physical line are interpreted and converted into bits and then organized in frames for transport. To transmit these frames over physical media most networks use Ethernet. Ethernet is an IEEE 802.3 series standard that specifies how two or more systems sharing a common cabling system can interact [10]. Ethernet uses its own addressing scheme that consists of a unique 48-bit number. This address is known as the Media Access Controller (MAC) address and is assigned to network interface cards (NIC) by the manufacturer. Each manufacturer is assigned a block of these addresses by the IEEE Registration Authority [11]. MAC addresses encapsulate packets transmitted over networks that use Ethernet.
IP is a network layer protocol that is used to deliver packets across connected networks to their intended destination. IP operates at layer 3 of the OSI model, the network layer. IP is connectionless. It does not generate or maintain state information about the packets during delivery. The implication of connectionless delivery is that delivery of packets is unreliable and only transported on a best-effort basis. Packets may arrive out of sequence, be delayed, duplicated, or not arrive at all [2]. Additionally, since each packet is delivered independently of the others, they may not travel along the same route to their intended destination. This best-effort delivery scheme allows IP to have the necessary level of abstraction to deliver packets over the heterogeneous environments they may encounter on the way to their destination.
Although IP provides the necessary functionality to transmit packets over heterogeneous computing platforms and environments, it does not provide the necessary services for reliable packet delivery. This best-effort delivery scheme utilized by IP presents a problem for applications that rely on the integrity of the data they transmit or receive.
TCP operates at layer 4 of the OSI model, the transport layer. TCP provides the necessary functionality to guarantee reliable packet delivery. In contrast to IP, TCP provides reliable connection-based data stream delivery that ensures error-free, sequential, and non-duplicated packet delivery. This is achieved by the use of a number of techniques such as: flow control mechanisms, sequence numbers, required acknowledgements, and adaptive retransmission techniques [12]. TCP requires that the data sender and receiver establish a connection before the data can be sent and received.
UDP like TCP operates at layer 4 of the OSI model. UDP provides the necessary functionality to establish packet delivery between two computing systems. However, like IP, UDP packets may arrive out of sequence, be delayed, duplicated, or not arrive at all [3]. UDP depends upon the IP protocol to move the packets that it produces. UDP is typically used for applications where speed of data transmission is a priority and integrity is not critical for proper functioning. An example of some of the uses of UDP is streaming audio or video.
ICMP is used to send messages
between computing systems for diagnostic or management purposes [2]. Most ICMP is used internally by IP
applications, but there are some applications that use its functionality. A popular example of this is ping.
Figure 3 : IP packet structure, illustrates the anatomy of a typical IP packet that traverses over Ethernet. Like the layers of an onion, a packet’s fields can be stripped away until just the data portion remains. Network applications generate packets by encapsulating data with protocol information. The protocol information appended to the data field is called the packet header. The data portion is first encapsulated by the desired transport protocol, then the IP protocol, and finally by the MAC address.
Figure 3 : IP packet structure over Ethernet
To understand how to trace spoofed packets to their origin it is necessary to understand how they travel through networks from source to destination. Network A and B, as shown in Figure 4: Simplified network schematic, connect to the same Internet backbone. Their network boundaries can be defined as the interface on their routers that receive and transmit information from their respective networks to the Internet Service Provider’s (ISP) backbone.
Figure 4: Simplified network schematic
An ISP backbone is a high-speed data transmission line that connects networks to the Internet. When systems in Network A communicate with systems in Network B their packets pass through four routers. Routers 1 and 4 are the edge routers of the respective networks and routers 2 and 3 are the two ISP backbone routers. When a system on Network A transmits a packet, it encapsulates it with the MAC address of the NIC installed on the system. When the packet reaches the edge router of Network A (i.e. Router – 1), the router inspects the packet and replaces the current MAC address with its own MAC address (i.e. 0050DAC6C95F). Then Router – 1 and forwards the packet to Router – 2 (see Figure 5: Packets routed by network A's edge router).
Figure 5: Packets routed by network A's edge router
Further inspection of the colored packet reveals that the destination IP address of 24.12.36.5 is a valid IP address within Network B. The source IP address of 121.34.5.171 is not part of the valid IP address range of Network A. Valid source IP addresses for Network A fall within the range of 216.34.12.0 to 216.34.12.255 inclusively. Therefore, this packet is spoofed. The backbone ISP router (i.e. Router - 2 in Figure 6: Packets routed by the ISP's backbone router), receives the packet from Network A’s router, checks the destination IP address, replaces the MAC address with its own MAC address (i.e. 0232FE07A123), and then forwards the packet to Router - 3.
Figure 6: Packets routed by the ISP's backbone router
Router – 3 repeats this process and forwards the packet to the edge router of Network – B, Router – 4 (see Figure 7: Packets routed by the ISP's 2nd backbone router). Router – 4 then forwards the packet to Network B’s firewall that inspects the packet and sends it to the system with the IP address of 24.12.36.5.
Figure 7: Packets routed by the ISP's 2nd backbone router
Even though the packet contained an invalid source IP address, it was still able to arrive at the intended destination. Routers only need to inspect the destination IP address to determine the best path for efficient delivery. The source IP address does not have to be examined. The previous example made use of a simplified network architecture to illustrate how packets are moved between networks. In practice, tracing the path of spoofed IP packets can be a difficult endeavor.
Tracing spoofed IP packets back to the true source presents a number of challenges that are both technical and non-technical in nature. Currently, the best method to determine the true source of a spoofed packet is to manually trace the path of the packet from router to router until you reach the network of origin.
As stated in a Cisco technical notes document,
“The only reliable way to identify the source of an attack is to trace it back hop-by-hop through the network. This process involves reconfiguring routers and examining log information, and therefore requires cooperation by all network operators along the path from the attacker to the victim [13].”
This is not a trivial undertaking as packets typically pass through several routers before they reach their destination. Even packets sent from the same source and going to the same destination do not have to follow the same path; they may pass through different routers. By inspecting the MAC address of the incoming packets, you can determine the location of the fowarding router or last hop. This assumes that the router is logging and recording the MAC address of the incoming packets. As shown in the previous section, regardless of the source IP address in the packet being spoofed, the MAC address of the packet source has to be correct. If you were able to retrieve the MAC address from every single hop between the source and destination systems, you could trace the packet’s network of origin.
Following the path of an packet through a network using only MAC addresses supplied by router logs presents some interesting difficulties as discussed in [14, 15]:
· It is a slow and manual process: Responding to a computer incident in a timely fashion is critical to limiting damage to systems. Harvesting logs from each router along the transmission path and examining specific packets takes time. Network personnel for each router have to be contacted and be willing to send the relevant log information. The time required to trace the spoofed packets will be significant. The logs of several routers may have to be examined and the results of the search verified through correlation.
· Reliance on upstream router personnel: A successful investigation to determine the source of spoofed packets will depend on the co-operation of every ISP or administrator in the path between the sender and receiver. Failure to provide all of the necessary information will make tracing the origin of the spoofed packet impossible. Even if all router administrators are willing to cooperate, they may not have the technical skill or time required to assist in the investigation. Interpreting router logs and enabling logging on router interfaces requires some measure of technical skill.
· The system sending the spoofed packets may be compromised: If you are able to trace the packets back to an actual system, it may itself be the victim of an attack. However, the owner of the system may be unaware that they have been successfully compromised and that their system is being used to send spoofed packets as part of a denial of service attack. You may succeed in stopping the flow of spoofed packets from this source but you would not have discovered the identity of the attacker.
· Multiple sources of spoofed packets: Tracing the path of spoofed packets is a labor intensive undertaking. There may be multiple sources of incoming spoofed packets. Each source of spoofed packets will mean a separate investigation as the packets may take different routes to the system.
· Routers may not be logging: Not all organizations will have logging enabled on their routers. An organization could be using older routers that do not support the logging required or there could be significant performance issues when logging is enabled. It is not uncommon for packets to travel through nine or more intermediate hops until they reach their destination. Failure of just one router to log will make tracing the spoofed packets impossible.
· Network traffic bursts or variances: If the incoming flow of spoofed packets is stopped periodically or is sent from different systems at different times, tracing them to the source will be problematic. If the source of the packets currently being traced stops sending spoofed packets, then determining the last hop point may not be possible. Without the flow of spoofed packets to guide the way, the MAC addresses will have to be retrieved exclusively from the logs of all routers between the source and destination. If the appropriate logging was not enabled on even a single router, the investigation time devoted to that flow will have been wasted.
· Crossing jurisdictions/national boundaries: Tracing spoofed packets relies on being able to communicate and gain cooperation from network administrators responsible for the routers between you and the source of spoofed packets. The Internet knows no geographical boundaries and packets may traverse a number of network boundaries in different countries on the way to their destination. Assistance from network administrators will typically be on a voluntary basis. In those cases where law enforcement becomes involved, warrants may be issued to compel ISPs to reveal their log files for the purpose of tracing network attacks. These writs may prove ineffective in getting information from countries that do not recognize their authority.
· Language barriers: Tracing spoofed packets relies on being able to communicate and gain cooperation from network administrators responsible for the routers between you and the source of spoofed packets. If you cannot communicate with the network administrators, it will be hard to let them know what information required.
· Network failure: A successful DoS attack causes the target system or the network infrastructure the system relies on to become overwhelmed and fail. If the router has failed as a result of the DoS attack, harvesting its logs may be problematic.
The router that connects a network to another network is known as a border router. One way to mitigate the threat of IP spoofing is by inspecting packets when they the leave and enter a network looking for invalid source IP addresses. If this type of filtering were performed on all border routers, IP address spoofing would be greatly reduced.
Egress filtering checks the source IP address of packets to ensure they come from a valid IP address range within the internal network [16]. When the router receives a packet that contains an invalid source address, the packet is simply discarded and does not leave the network boundary. This type of filtering may not prevent a system from participating in a DoS attack as the spoofed IP address used could fall within the valid internal address range. It will simplify the process of tracing the packets, since the systems will have to use a source IP address within the valid IP range of the network.
Ingress filtering checks the source IP address of packets that enter the network to ensure they do not come from sources that are not permitted to access the network [17]. At a minimum, all private, reserved, and internal IP addresses should be discarded by the router and not allowed to enter the network.
5.0 References
[1] (September, 1981). RFC: 793. Transmission Control Protocol Darpa Internet Program Protocol Specification.
ftp://ftp.isi.edu/in-notes/rfc793.txt
[2] (September, 1981). RFC: 791. Internet Protocol Darpa
Internet Program Protocol Specification.
ftp://ftp.isi.edu/in-notes/rfc791.txt
[3] Stevens, R. (October 1999). TCP/IP Illustrated, Volume 1 The Protocols. Addison-Wesley Professional Computing Series.
[4] Bellovin, S. (April 1989). Security problems in the TCP/IP Protocol Suite, Computer Communications Review, Vol. 19, No. 2, pp. 32-48.
[5] (
[6] (
[7] (
http://www.cert.org/advisories/CA-1996-21.html
[8] (
[9] (June, 1996). ISO/OSI Network Model.
http://www.uwsg.indiana.edu/usail/network/nfs/network_layers.html
[10] Part 3: Carrier sense multiple access with collision
detection (CSMA/CD) access method and physical layer specifications. (ISO/IEC
8802-3: 2000 (E)). IEEE Standard for Information technology--Telecommunications
and information exchange between systems--Local and metropolitan area
networks--Specific requirements.
http://standards.ieee.org/getieee802/802.3.html
[11] IEEE Registration Authority Overview. IEEE.org.
http://standards.ieee.org/regauth/index.html
[12] Schuba, C. et al. (1997). Analysis of a Denial of Service Attack on TCP.
[13] Characterizing and Tracing Packet Floods Using Cisco
Routers. Cisco Systems, Inc. Retrieved
[14] Dunigan, T. (
[15] Burch, H., Cheswick, B. (December 2000). Tracing Anonymous Packets to Their Approximate Source.
[16] Flanagan, H. (
[17] (January 1998). RFC: 2267. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. ftp://ftp.isi.edu/in-notes/rfc2267.txt