Spoofer Project: FAQ

What:
1. What is IP spoofing?
  IP spoofing is the practise of forging various portions of the Internet Protocol (IP) header. Because a vast majority of Internet traffic, applications, and servers use IP, IP spoofing has important security implications. Additional details are available in this article.
2. What is this project??
  The Spoofer Project seeks to understand the Internet's vulnerability to different types of spoofed-source IP address attacks.
3. Can you explain email spoofing?
  No, sorry, this project is concerned only with IP source address spoofing. This Wikipedia article explains the difference.
Participation:
1. What can I expect when I run the tester?
  Glad you asked, screenshots are available with example runs.
2. Why would I want to participate in this study?
  Participation is completely voluntary. That said, the more reports we receive, the better our network coverage is and hence the more accurate our understanding of the extent to which spoofing is possible. In addition, networks may install or removing anti-spoofing mechanisms over time, an effect we monitor as well.
3. How does my participation help solve the spoofing problem?
  The data we collect only measures the extent of the problem. We are using this data to inform our research. We are working on a distributed anti-spoofing mechanism prototype; stay tuned.
4. Download and run a privileged binary? You're going to compromise ("root") my system!
  Actually, our spoofer client doesn't alter files on your system, install backdoors or abuse its privilege. But don't take our word for it: we provide complete, open source code for examination. If you're not comfortable running one of our pre-compiled binaries, you're welcome to build your own. We also provide MD5 checksums on the web site as an additional measure of authenticity.
5. Does your program do something more sinister, such as collecting sensitive internal network information and sent it back to scammers?
  No, the spoofer client program does nothing more than send various sequences of spoofed-source IP packets and confers with our server to determine which packets were received or lost. We don't collect any additional information or do anything beyond what's advertised.
6. Won't this attract the attention of my ISP and raise security alarms?
  It's unlikely. Intrusion detection systems are bombarded with suspicious events continually. The small number of spoofed packets our client sends is unlikely to attract any attention. We have yet to hear of any reports that our spoofer raised a security alarm. That being said, always follow the rules and laws governing your network and do not run our tester if its use is in question.
7. I'm behind a NAT, will I be able to spoof?
  No, but the client tester will detect this. This data is important to us so we can estimate the prevalence of NAT preventing spoofing.
8. I know my network prevents spoofing, should I run the spoofer anyway?
  Yes, please. We also maintain a count of netblocks believed to prevent spoofing. Running the spoofer, even when the spoof is blocked, gives us valuable data.
Relevance:
1. What's the point (1)? Spoofing is no longer an attack vector with the rise of zombies and bot farms.
  Untrue. As we predicted in our USENIX SRUTI paper, bots such as stacheldraht v4 test the ability of their zombies to spoof and exploit that ability. Recent attacks against the DNS infrastructure have been especially acute, accounting for more than 40Gbps of traffic on some provider networks.
2. What's the point (2)? No attacks use spoofing any longer.
  Untrue. In the past few months, a spoofing-based DNS DDoS attack has become very popular and a large problem for providers and victims. In addition, spoofing is being used by spammers to evade outbound TCP port 25 SMTP filtering and for in-window TCP reset attacks. Spoofing has been exploited for malicious purposes for more than 20 years. We cannot anticipate the next spoofing-based attack. This motivates our architectural research and response.
3. Spoofing isn't a problem! Every self-respecting ISP uses filters or uRPF. Gone are the days of spoofing.
  Actually, our measurements clearly show that spoofing is still prevalent among approximately 25% of the autonomous systems and netblocks we survey. More importantly, a single entry point for spoofed traffic provides attackers a means to send spoofed traffic to the entire Internet. ISPs can employ filtering [RFC2827] to ensure their outbound traffic is not spoofed. But there is currently no way to ensure that inbound traffic is legitimate as long as there exist entry points for spoofed traffic. uRPF [RFC3704] does not work, and is not used, in the core of the network where routing asymmetry renders it useless.
4. Spoofing isn't bad! viz. NAT gateways, reverse traceroute, etc.
  This is a great question, and one that is good for debate. Certainly spoofing is used for bad purposes. In reality, there are very few instances of legitimate source spoofing. Even when spoofing is intended for a legitimate purpose, it is almost certainly the wrong architectural response. Clearly there is a tradeoff between the current state of affairs where the semantics of source IP addresses are overloaded, e.g. for authentication, and security. Our stance is that benefit of enforcing packets sent to have the same source address as the sender far outweigh any downside.
5. Does this effort help scammers find an ISP that allows spoofing?
  No. We keep data on individual networks private and only publish aggregate statistics. Any scammer that is sophisticated enough to employ spoofing in the first place will be able to test spoofing on her network without the assistance of our tester.
6. It's obvious that spoofing is on the decline due to home users using NAT.
  Yes, however this is indicative of a secondary phenomenon and not the network's response to, or ability to defend, spoofed packets. A malicious party attached to a network that permits spoofing clearly will not use a NAT or otherwise impede her ability to send spoofed packets.
Client:
1. Does the spoofer client run on Windows?
  Yes! Versions ≥ 0.5 use raw ethernet to spoof when raw sockets fail due to Microsoft mechanisms to prevent spoofing.
2. Why do I have to run the spoofer as root?
  Programs that create raw sockets must run as root. If you are concerned about the security of our binaries, we welcome you to examine the provided source code and build your own.
3. The spoofer doesn't seem to work on Windows 9x
  It appears that the setsockopt(IP_HDRINCL) option is not supported. Please try the spoofer on Windows 2000 or XP.
4. My Linux box is unable to send spoofed packets even though I'm root, what's going on?
  Check to see whether /proc/sys/net/ipv4/conf/*/rp_filter is set to 1 (true). If so, the machine is performing RFC1812 reverse path source validation and will not send spoofed packets. RP checking is off by default, but some Linux distributions enable it.
5. What's the difference between versions?
  See the CHANGES file in the source distribution.
6. How do I test IPv6 spoofing?
  Recent versions of the tester detect IPv6 capable clients and attempt to spoof IPv6 source addresses. If you're having trouble testing IPv6 spoofing, check that 2001:470:1f06:ee0::2 is reachable from your location (thanks to Hurricane Electric for their IPv6 tunnel broker service!). Contact us with problems as IPv6 testing is a work-in-progress.
Statistics:
1. The numbers in the summary report don't add up!
  This is due to the server receiving multiple spoofer reports from the same client (IP address) but with different operating systems. For instance multiple machines running different OSes sitting behind a NAT.
2. How long have you been collecting data?
  The first public announcement was sent to the NANOG mailing list on February 24th, 2005.
3. In your summary results, are you reporting on unique IPs?
  Yes, we report each IP only once.
4. Can you provide addresses of spoofable netblocks/ASes?
  No. To respect the privacy and security of the participants and networks involved in the study, we don't make this data publicly available.
Defense:
1. I'm a service provider. How can I prevent my network from being used for spoofing-based attacks?
  First, read up on different types of Ingress Filtering. Read and understand BCP 38. Use our tool to verify that your network employs the correct source address filtering.
2. I'm a service provider. How can I protect my network from spoofing-based attacks?
  Good question. Unfortunately, filtering techniques only ensure that ISPs are "good Internet citizens," but don't prevent the reception of spoofed IP traffic. The vast majority of defenses involve finding traffic signatures to block or blackhole (for instance, if a particular customer is being DDoS'd). NANOG is a good starting point for understanding how such defense is coordinated among providers, in particular, see Christ Morrow's 2004 presentation.
3. Is there current work on IP spoofing defense?
  Yes. A good starting point is the Source Address Validation (SAVI) IETF working group. Various researchers, including us, are actively working on other defenses.
Misc:
1. Can you please explain "tracefilter" and how you're using it?
  Sure, see our paper on tracefilter here.
2. You're not doing IP spoofing! IP spoofing involves predicting TCP sequence numbers. Get your terminology right!
  We are testing the ability of clients around the Internet to send UDP packets with spoofed source IP addresses. TCP sequence number prediction attempts to exploit the ability to spoof by faking a TCP connection. We call the former "IP spoofing" and the latter "TCP sequence prediction using IP spoofing." Please use whatever terminology you're most comfortable with.
3. You still didn't answer my question!
  Did you read our publications? Still have a question? Please let us know!

$Id: faq.php 824 2013-05-15 20:54:21Z rbeverly $