Backtracking Spoofed Packets

.... under construction ....

This survey and backtracking analysis at Oak Ridge National Laboratory is sponsored by the Office of Counter Intelligence of the US Departmant of Energy.

Introduction

Each internet packet on the Internet carries a destination address and a return address. The destination address is used by the network routers in delivering the packets to its destination. The source address (or the return address) is only needed by the final destination enable to reply. Like US postal return addresses, the source address is ignored and can be forged or spoofed. Normal network applications provide legitimate source addresses, but a hacker can persuade an operating system (you need "root" on a UNIX system) to use spoofed addresses for the source address.

Spoofed addresses can be used to hide one's network identity or to direct return packets to another host/target. Spoofed addresses can also be used to masquerade as another host that is possibly trusted by the target host. Spoofed addresses have been used in the following Internet attacks:

• DoS --smurf attacks (ICMP broadcast)
• DoS --fraggle attacks (e.g., UDP broacast to port 7)
• DoS --teardrop attack (IP fragmentation bugs)
• DoS --land attack (IP source = destination address)
• DoS --SYN flooding
• distributed denial of service attacks
• providing bogus packet flows to hide real attack source
• masquerading (TCP sequence number guessing)
• stealth/idle scanning

Denial of Service Attacks

Denial of service attacks prevent the targeted site from providing network services by either flooding the site with packets (smurf or fraggle attacks), consuming finite network resources (SYN flooding), or causing the site to crash (teardrop or land attacks). None of these attacks require that the source address of the attack packet be valid. By design, the attack flow often looks like legitimate traffic, so it is very difficult to filter out the attacking flow at the targeted site. Since the source addresses are spoofed, it is impossible to know what the real source of the packets is without backtracking an active flow.

In February of 2000, more sophisticated distributed denial of service attacks were launched against major Internet sites. Tools for mounting distributed denial of service attacks began appearing in the fall of 1999, and CERT and others were aware of attack preparations. (See links below.) The attackers broke into a number of Internet computers (usually attached to high speed nets) and installed attack agents. The attackers used these distributed agents to mount simultaneous denial of service attacks against a targeted site.

Dropping spoofed packets

In an ideal world, each router would be configured with ingress filters that would drop packets arriving from "internal" networks whose source address was not a member of the set of network addresses that this router serves. The majority of routers could be so configured. Backbone routers and edge routers for complex topologies probably could not be configured with such filters. These ingress filters should be required as part of a "good neighbor policy." Ingress filters would not totally eliminate denial of service attacks but could greatly reduce such attacks. An attacker could still spoof an address within a local subnet, but that would permit backtracking the packets to the source subnet. Cisco's unicast reverse path forwarding also can be used to block spoofed packets at edge routers.

At ORNL we have developed a prototype program that an end-user can run to verify that his ISP has proper ingress filters enabled. The user can download this spoof-tester (versions would be needed for each OS). The spoof-tester contacts a server (with TCP) and obtains a spoofed address for testing. The spoof-tester then transmits a series of spoofed packets (TCP, UDP, ICMP) from the users machine to the server, some with the Record-Route option. The server then notifies the spoof-tester if the spoofed packets are detected. (The actual IP address of the user's machine is embedded in the spoofed packets.) If the spoofed packets are detected, the user or testing service could then notify the ISP. (The spoofed packets transport checksums are wrong so there are no packets reflected to the spoofed address.) A prototype web page was also developed for the spoof-tester. Also see ICSA's netlitmus anti-spoofing test tool or here.

Most routers are (should be) configured with egress filters that prevent spoofed internal addresses from being passed from an external interface. These egress filters reduce the risk of internal hosts using an IP address as the basis of trust decisions. SANS has some hints for testing your router configuration.

Back tracking

Back tracking spoofed packets is easy in principle. Assuming the attack is ongoing, one determines which router at the target site the attack flow is coming from, call it router Z. One logs into router Z, and determines from which interface/router the attack is coming from, call it router W. Then one logs into router W, and so forth. In practice, backtracking is complicated by the following:

• it is a slow manual process
• the flow must stay active during the traceback, much like tracing a phone call
• the flow may come from multiple sources and have varying signatures
• one or more routers along the path may not have the facility for identifying the upstream source
• one may need physical access to some routers to enable backtracking
• router personnel may be unavailable to assist
• eventually, one starts to cross into other administrative domains or countries and encounter legal/political obstacles

With Cisco routers one can use the "log-input" feature of an access control list. In 1996, MCI published a set of Perl scripts for Cisco routers that would login, set up an ACL in debug mode, determine the next-hop router, and login to the next-hop router and repeat the process. Robert Stone at UUNET reroutes the attack flow in his CenterTrack design to tunnel the traffic to instrumented routers. NCSU's Wu is working on "Deciduous: Intrusion Source Tracing". There have also been several backtracking papers (master's thesis) on using active networks to backtrack and block spoofed attack flows. (See the URL's below.)

Action items

• educate router keepers about ingress/egress filters
• get router manufacturers to provide a backtracking mechanism
• establish cooperative agreements among router keepers to aid in backtracking
• have a "first alert" at major router hubs
• provide a "spoof-tester program" that would allow a user to verify if his ISP was using ingress filters
• look at liability issues for ISP's that were the source of spoofed attacks

Our preliminary tech report (PS, 120K)

More information

idle scan stealth

RFC 2267 ingress filters

Cisco's unicast reverse path forwarding

egress filters

denial of service

smurf attacks and land attack and teardrop

CERT's smurf advisory and teardrop/land advisory

distributed denial of service stacheldraht or trinoo or tfn tribe flood network or tfn2k or

CERT's distributed denial of service tools and denial of service workshop pdf

Cisco info on distributed denial of service attacks

U of W ddos links

hackernews article on denial of service attacks

SANS recommendations and tips for testing your routers

ICSA's DDOS guide

ISP's join to fight DoS

back tracking

Bellovin's itrace backtracking ICMP pkt proposal and IETF's ICMP traceback messages

MCI's dostracker backtracking DoS (denial of service) or dostrack

ORNL's prototype ISP spoof testing service

Cisco's tracking packet floods using cisco routers

Robert Stone's (UUNET) centertrack or pdf

U of W Practical Network Support for IP Traceback

NCSU's Wu's shang project and Deciduous

Van's thesis A Defense Against Address Spoofing Using Active Networks

Halbig's thesis An Active Network Approach to defending and tracking denial-of-service attacks

Towards Tracing Hidden Attackers on Untrusted IP Networks 2001