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.
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
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.)
web page was also developed for the spoof-tester.
Also see ICSA's netlitmus anti-spoofing test tool or
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 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
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
- 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
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.)
- 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)
- idle scan stealth
RFC 2267 ingress filters
- Cisco's unicast reverse path forwarding
- egress filters
denial of service
smurf advisory and
- distributed denial of service
tfn tribe flood network
or tfn2k or
- CERT's distributed
denial of service tools
denial of service workshop pdf
- Cisco info on
distributed denial of service attacks
- U of W ddos
- hackernews article on denial of service attacks
- SANS recommendations
and tips for testing your
- ICSA's DDOS guide
ISP's join to fight DoS
itrace backtracking ICMP pkt proposal
ICMP traceback messages
- MCI's dostracker
backtracking DoS (denial of service)
ISP spoof testing service
tracking packet floods using cisco routers
- Robert Stone's (UUNET) centertrack
- U of W
Practical Network Support for IP Traceback
- NCSU's Wu's shang project
- 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
Towards Tracing Hidden Attackers on Untrusted IP Networks 2001
Last Modified Tuesday, 01-Jun-2004 12:25:15 EDT email@example.com
(touches: 289590 )
back to Tom Dunigan's page
or the ORNL home page