fuzzerfuzzingnetworkingtransport
How do I go about executing a fuzzing strategy to stress a network stack, specifically at the third and fourth layers (network and transport)? I've looked at frameworks to generate fuzzers, like SPIKE, but it seems to me that they are mostly focused on the application layer and above? Is there any well known techniques out there to fuzz well-known protocols in these layers, say, TCP?
Thanks.
Transport is the act of moving data between two end points (think the "TCP" in TCP/IP). The application layer is the application that makes use of that transport (think HTTP or FTP, for example).
See http://en.wikipedia.org/wiki/OSI_model for more info.
Use a simple Faraday cage to block or limit the external RF signal level.
You can make your own with aluminum foil. The openings should be smaller than the wavelength of your data service if that's what you want to block.
This works better with an actual device than with the simulator since the Mac is hard to work on when inside the Faraday cage ;-)
Best Answer
Look at Scapy. It allows you to fuzz at the network and transport layers. The
fuzzfunction will fuzz anything you didn't explicitly specify in the IP or TCP layers (you can apply it separately to each). This gives you a range of abilities from just randomly generating ip addresses and port pairs to making and sending nonsense packets.You may also want to look at Fragroute. This will twist TCP/IP into using all sorts of evasions techniques, but could potentially unveil otherwise hidden bugs/vulnerabilities in your network stack.
Furthermore, if your organization doesn't object, you could set up a Tor exit node and capture traffic from it. I've found it useful for testing correct TCP connection state tracking. Though your end of the connections is well-known and unchanging, there's a huge variety of servers as well as fun network congestion issues. It's basically an endless source of traffic. Be sure to check with your higher ups as your org may object to being a potential source of malicious traffic (even though there is a strong precedent of non-liability). I've gotten around that issue by running it/capturing at home, then bringing in the pcaps.