On May 2, 2006 our Spoofer Project was posted to Slashdot. Thousands of Slashdot users downloaded and ran our IP source spoofing client thereby contributing to our aggregate Spoofing Summary. Thanks! We sincerely appreciate the interest and feedback. This web page addresses the most common questions and comments posted by Slashdot readers. We always welcome any and all feedback.

1. What's the point (1)? Spoofing is no longer an attack vector with the rise of zombies and bot farms.
   • Ans: 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.
   
   
2. What's the point (2)? No attacks use spoofing any longer.
   • Ans: 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. Why would I want to participate in this study?
   • Ans: 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 wish to monitor as well.
   
   
4. How does my participation help solve the spoofing problem?
   • Ans: The data we collect only measures the extent of the problem. We are using this data to inform our research. We have created a non-distributed anti-spoofing mechanism prototype, the details of which will be published soon.
   
   
5. Spoofing isn't a problem! Every self-respecting ISP uses filters or uRPF. Gone are the days of spoofing.
   • Ans: 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.
   
   
6. Spoofing isn't bad! viz. NAT gateways, P2P applications, etc.
   • Ans: 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.
   
   
7. Measurements are questionable since they only measure the ability of users to send spoofed packets to a single destination (namely the monitor/server on our campus network).
   • Ans: Yes, however part of our research and measurements involve testing where filtering is employed. Best common practices and reality show that filtering and source address verification is performed at the edge of the network, typically one or two hops from any sender. Once a spoofed packet makes it to the core of the network, it almost certainly traverses unimpeded to any destination on the Internet. Thus, distributed tests around the Internet to our single destination on our campus network is, in fact, a very representative study.
   
   
8. Download and run a privileged binary? You're going to compromise ("root") my system!
   • Ans: 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.
   
   
9. Does your program do something more sinister, such as collecting sensitive internal network information and sent it back to scammers?
   • Ans: 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. Again, please feel free to examine the source code as in the previous answer.
   
   
10. Does this effort help scammers find an ISP that allows spoofing?
    • Ans: 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.
    
    
11. Why does the Windows version insist on spawning Internet Explorer to display the results?
    • Ans: Because we were lazy. The next version of the spoofer client will correct this aesthetic shortcoming.
    
    
12. Windows version is useless.
    • Ans: Clients running Windows XP with service pack 2 will not be able to source spoofed packets due to recent restrictions Microsoft imposes on raw sockets. Two answers to this statement. The first is that we are currently coding a work around based on nmap's raw ethernet approach. Second, our server detects a client that is blocked by operating system restrictions - providing us with additional data on the operating system response to preventing spoofing.
    
    
13. It's obvious that spoofing is on the decline due to home users using NAT.
    • Ans: 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.
    
    
14. Won't this attract the attention of my ISP and raise security alarms?
    • Ans: 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.
    
    
15. You're not doing IP spoofing! IP spoofing involves predicting TCP sequence numbers. Get your terminology right!
    • Ans: 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.
    
    
16. In your summary results, are you reporting on unique IPs?
    • Ans: Yes, we report each IP only once.
    
    
17. You don't even know how to untar! tar -xzvf will untar a compressed archived! Duh!
    • Ans: Yes, gzip support is built into gnu's tar, but cannot be assumed and hence using a combination of tar and gzip is more portable. However, we strongly subscribe to the UNIX philosophy of combining multiple small programs using pipes and redirection rather than overloading functionality. You're welcome to untar as you're most comfortable.
    
    
18. You still didn't answer my question!
    • Ans: Did you read our FAQ? Did you read our USENIX SRUTI paper? Still have a question? Please let us know!
    
    

---

$Id: slashdot.php 493 2009-03-06 18:29:44Z rbeverly $