Update: Nov 21, 2006

New version 0.5 of the IP spoofer tester. Now supports all versions of Windows using raw ethernet. See the changelog for details.

Added Slashdot Response web page. On May 2, 2006 the Spoofer Project was posted to Slashdot. Thousands of Slashdot users downloaded and the IP source spoofing client thereby contributing to our aggregate Spoofing Summary. Thanks! We sincerely appreciate the interest and feedback. We've created a Slashdot Response web page that addresses the most common questions and comments posted by Slashdot readers.

Every hour, we generate a summary report on the current state of Internet IP address spoofing. Thus far, we've collected data from approximately 8000 clients, 2000 networks and 1100 ASes. Detailed results from our research were presented at: USENIX SRUTI 2005 and NANOG 34.

With sufficient network coverage, we can better understand the current state of filtering in the Internet. The following spoofer tester client packages are available:

Build	MD5	Description
spoofer-win32-setup-0.5.exe	e11cd2bb4c101e8cae7f6f77ad301424	Windows Binary
spoofer-linux-0.5.tar.gz	9a4bfeeb0c0e3ee92d21f16519cf3972	Linux Binary
spoofer-freebsd-0.5.tar.gz	4214c07149375e65a3d468cff78b9345	FreeBSD (5.x) Binary
spoofer-osx-0.5.tar.gz	72c07ae122dceb413b7274948edcc0e2	Mac OSX Binary
spoofer-solaris-0.5.tar.gz	2abcb9d450db917d459e3d0ce2dceab0	Solaris (Sparc) Binary
spoofer-0.5.tar.gz	97c16a4189deb2a76af2949e5fadda31	Source Code
changelog		ChangeLog

Download one of the packaged binaries above (preferred method) or build from the source code.

• Windows: simply download and run the installer
• *nix: Uncompress and untar with
     $ gzip -dc spoofer-xxx-0.5.tar.gz | tar -xvf -
  You must run the spoofer as root (in order to create the raw socket) with no arguments, e.g.
     # ./spoofer

The classic design tenets of Internet architecture produced a network capable of remarkable scalability while relegating security to the end hosts. As a result, the public Internet includes no explicit notion of authenticity and will forward packets with forged headers. Malicious users capitalize on the ability to ``spoof'' source IP addresses for anonymity, indirection, targeted attacks and security circumvention. Compromised hosts on networks that permit IP spoofing enable a wide variety of attacks. Despite being first exploited over two-decades ago, IP spoofing is a persistent problem and a continued threat. In addition to mounting spoofed-source bandwidth-based denial-of-service (DoS) attacks, new exploits utilizing IP spoofing surface regularly.

The anonymity afforded by spoofing greatly complicates the job of network operators defending their networks. Ingress address filtering [RFC2827] or unicast reverse path forwarding (uRPF) checks [RFC3704] can prevent spoofing when practical. In production networks however, these filtering techniques are limited by multi-homing, route asymmetry, filter list maintenance and router design. As a result, our initial study demonstrates that a considerable portion of the Internet is vulnerable to IP spoofing while analysis of backscatter shows spoofing remains widespread.

Previous research investigates various means of tracing or mitigating spoofing. Jin et. al give a scheme to block spoofed packets based on hop count, while Duan et. al detail a filtering mechanism based on feasible path construction. Packet marking and traceback mechanisms provide a means to trace spoofed packets to their origin, removing the advantage of anonymity. Despite these research efforts, finding and preventing sources of spoofed traffic remains an operationally difficult problem for network operators. This project seeks to determine the extent to which spoofing is currently possible and a relevant issue on the Internet.

Our methodology is simple. We make software to test spoofing publicly available and ask the community to run it from as many sites as possible. The spoofer program attempts to send a series of spoofed UDP packets to a server on our campus. These packets are designed to test:

• Different classes of spoofed traffic including bogons, RFC1918 and valid sources
• Ability to spoof neighboring, adjacent addresses
• Where along the path filtering is employed
• Presence of a NAT device along the path

Not all spoofed traffic may reach the server if a filter or other policy blocks or rewrites the packets. After sending the spoofed UDP packets, the program establishes a TCP connection with the server informing it of the spoofed packets it tried to send. Based on this transaction, the server records the success or failure of the machine's ability to send spoofed packets in a database.

This research conducted by MIT ANA. Feedback, comments and bugfixes welcome. Contact Rob Beverly for more information. In addition, we welcome feedback and discussion on the Spoofer Mailing List

Thanks to (alphabetically): Mike Afergan, John Curran, Simson Garfinkel, Aaron Hughes, Ken Shores, Nick Weaver and John Wroclawski for constructive discussions and feedback. Thanks also to the U Oregon routeviews crew for their BGP data and Marco d'Itri for the Zebra dump parser.