Slashdot Mirror
Techie Story On TCP Stacks
a9db0 writes: "Ars Technica is running an article on TCP stack research done by Stefan Savage at the University of Washington. Stefan presented one interesting tool and a couple of ingenious hacks. The tool measures response time more accurately between nodes without additional software on the server. The hacks are TCP modifications, one of which could help defeat DDoS attacks.
"
#1: Red Herring. We're talking about protocol-level enhancements that make attacks like TCP-based DDoS fundamentally difficult to perform. This is a totally different subject from "making sure all programs on my workstation are free of buffer overflows." It is also true that the types of solutions needed to correctly protect systems are usually fairly intrusive and systemic. As the article says (you did read the whole thing before posting, didn't you?),
#2: University IT departments treat researchers pretty uniformly as "clueless", and assume that their own employees are clueful. The result? Clueful hacker-researchers with well-maintained machines are all locked up behind firewalls and active monitoring unnecessarily, while wide-open boxen sit on the public subnets waiting for j0e h4x0r to set up a DDoS outpost.
The Web100 Project is working on putting automatic TCP tuning into the stack. This will allow a TCP connection to use all of the available bandwidth, without breaking any of the internal algorithms or stomping on other connections. It is already possible to tune most TCP implementations by measuring the bandwidth*delay product and tweaking the socket buffer size; the NLANR TCP Tuning page has instructions.
the `niceness' constraints in TCP: actually the strategy suggested
will get you blacklisted on quite a few routers, which means it will
simply drop all packets originating from your IP address. The routers
use standard traffic profiling tools to spot just the kind of tricks
Janotti describes.
To plug some work done in my department, Azer Bestavros has done
some nice work on network
profiling : the idea I liked most was a way to make the TCP binary
backoff work better by grouping together similar packets: this can be
done entirely end-to-end, and really gets big improvements in overall
performance. See in particular the paper `QoS Controllers for the Internet'.
Windows TCP/IP stacks already do this kind of retarded ACKing, and its trivial to modify others to do so. That's where intelligent traffic shaping comes in. Even if you don't modify the TCP/IP stack, you can write a proprietary program to open, say 50 connections to download the same file, or multiple files at the same time and use far more bandwidth than anyone else on the network.
HT Kung has been doing some work on this. MIT and Harvard share the same net link and pay the same price, but MIT has more net users and therefore more connections (as in streams) so they use much more bandwidth. So you do traffic shaping and stop all those nasty bastards opening 300 concurrent connections from their desktop at once from using the entire network.
A DDOS attack involves two layers of victims. The obvious victim is the recipient of the attack. But before the attack can be launched several (hundred) intermediate systems must be penetrated and exploited. It is this set of victim machines which launches the final attack.
The procedure proposed by Stephen is quite clever and could be used to trace the attack back to the first layer of victims. But that is where it would end. The procedure requires hundreds of packets to make its trace. But the attacking machine is only listening for a single packet - whose IP can be spoofed - for the command to launch the attack. So the perpetrator remains safe behind his proxy army until he starts bragging on irc.
I personally doubt that there is any defence against a propperly executed DDOS attack. Why? Because there is no difference between a propper DDOS and "The SlashDot Effect."
Forget the ICMP packets. Want to take down a web site? Flood it with web page requests. You now have nothing to filter on and the legitimate users are crowded out.
Check me if I'm wrong, but wouldn't simply having the server's TCP stack discard all data for which it had received an ACK, regardless of whether that data had been transmitted or not, in combination with a finite maximum window size and discarding ACKs that do not correspond with the end of a packet, make optimistic ACKing completely counter-productive?