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.
"
Well, duh.
Because this researcher is telling you exactly what he is doing, so you can implement it in a compatible way, while MS is not telling how to build a modified Kerberos that is compatible with their scheme.
Basically roughly every 20,000 packets, a router chooses a packet at random and sends an ICMP traceback message to the packet's destination listing the router's address and the previous and next hop that the data packet took. At the receiver, if you're being seriously flooded, you start monitoring the traceback packets and when you get enough you can piece together the paths back to the attackers.
It won't stop the attack itself, but will at least help in discovering the cracked hosts being used to launch the attack.
-Fzz
Let's not forget that Microsoft BROKE Kerberos. This guy is proposing a change that allows existing TCP to continue working, unaffected.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
outgoing packets: it did not depend upon seeing the ack packets. This
kind of traffic analysis of this kind was made necessary by the MBONE
multicast protocol, which was built on top of UDP (which does not do
the same kind of binary backoff that TCP does): if there are widely
deployed protocols that do not respect binary backoff, then the
network really would grind to a halt, and so some external method of
`niceness checking' is required.
Cisco make routers that do the necessary tests to spot abuse. It's
worth noting that the consequence of being blacklisted is not having
your service blocked altogether, only that intermediate routers will
have to route around the routers that drop your packets: it will spoil
your performance but not interrupt it. Rememeber that IP makes no
assumptions about packets actually arriving. Yes it can be abused:
but we knew that anyway, and it's much harder to do that than the DDoS
attacks.
Proof? You could ask Cisco I suppose. If you're willing to put up
with less than proof look at all the IETF discussions about the MBONE
protocol. I'll have a look around and see if I find any online articles about testing for backoff.
--
OptAck has been around for a while, but any commercial IP stack isn't going to implement it. It can and does break TCP transfers, and lusers will just complain the network is broken.
:-) :-)
I did like the graph of how a flood of TCP packets shows up at the same time, essentally dumping all 60Mb of IE across a fat pipe all at once. That works when you are only a few hops away from the server (UoW to Redmond, line of sight), but it falls apart if you have 18-20 routers inbetween with widly fluctuating available bandwidth.
Time to hack this into the linux net3 stack as a switch during compile time. ENABLE_OPTIM_TCPACK_FLOOD=true and then get some hacked utilities taking advantage of it. Could be good for cable/dsl/OC3 people, but won't do much for poor modem users. A carefully controlled predictive TCP ACK can increase modem connections as well for big transfers. Another fun research project to take up my precious time AAAAUUUUGGGGGHHHHH!!!!
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
#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.
Very simple. It's not their job.
...
Researchers are paid to do research. Not system administration.
System administrators are paid to sysadmin. Not to do research.
I am a PhD student at a leading university, and know enough about networking to make some of our systems more secure than they are at present. However, sysadmins are a strange bunch -- they jealously protect their turf; they are NOT going to give root access to a mere 'researcher' like me, so that I can secure their systems for them. (Yeah, since their systems are so insecure, I probably could crack 'em and get root, and then fix it, but why bother? They'd never appreciate the 'help' -- they'd probably kill my user account for 'unauthorized activities' once I told them about it.) Besides, it's just not worth my time to do their job for them.
It's worse than that, though. Public universities just cannot keep up with the IT salaries. When you're paying a history prof with a PhD $40k, it's really hard to convince the regents/deans to fork over > $100k for a truly qualified sysadmin. So universities only pay rock-bottom salaries. This leads to two types of university sysadmins: (1) rock-bottom talent (2) 'temporary' -- they work in academia for reasons OTHER than salary; maybe they like the hours, or NOT being on call on the weekends, or they're working on a degree and want reduced tuition,
In case (1), it's easy to see why university computer systems are so unprotected. In case (2), the sysadmin job is NOT the person's primary focus in life, so some things (like keeping current on bugs/security fixes/best practices) fall through the cracks, no matter how talented the person is.
The answer? Fire some profs and use the money to hire a GOOD sysadmin at a salary that'll keep him around (e.g. near $100k), instead of jumping ship in six months when he gets an offer that doubles or triples his measly current salary of $30k.
And if you think there's a university out there willing to do that, I've got a bridge in Brooklyn for ya.
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.
What about it? All they can get is the IP address of the attacker. If you're making a legitimate connection, you haver to supply your IP address so that the results can reach you! The only reasons to spoof an IP address are nefarious.
Even then, this can only trace packet floods, because a huge number of packets are needed for a trace to be effective. IIRC, the article says 100*n packets minimum, where n=number of hops, are required. If you figure 10 hops to get somewhere interesting, you need 1.5 MB incoming traffic to get a trace. FTP or HTTP requests don't generate that kind of traffic in any reasonable time.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Colleges and universities are never going to be convinced to pay what is necessary for a good sysadmin. This is the way my the CS department at my college (a fairly major engineering/science school) dealt with this problem for their network and unix shop.
The CS department would hire a clueful sysadmin who was just out of college and did not have an impressive enough resume to get a full sysadmin job elsewhere, but had personal experience. They would place the SA underneath the professor who was a cluefull researcher in the area of networking and operating systems. My college also maintained a staff of part time student sysadmins who performed tasks for the lead sysadmin, and could help a new lead grow accustomed to the environment. Some of these students stayed over the summer to research and to do admin tasks that couldn't be done during the school year, and this is when the new lead was trained.
After a couple years, the lead would get a new job for twice what he was making for my college, and we would start looking for a new lead. This worked quite well for everyone involved, and the college didn't need to be convinced to pay real money.
- #3 - Insiders vs. Firewalls - Attacks by students. Firewalls are usually designed to keep unauthorised outsiders out. But universities have lots of bright kids with time and computer resources on their hands, who know a lot more about computers than they did in junior high school, know a lot more people who know a lot more about computers, and have a lot more computing resources than when they were using their Mom's AOL account and 486 Win3.1 box. One of the standard computer security problems is "How do you know you're talking to the server you think you're talking to and not to some grad student at Berkeley?" Well, if you're the sysadmin at Berkeley, that's a tough question
:-) It's harder than the corporate "disgruntled employee" situation, except that most of your security problem students aren't malicious - they're just more creative than you are....
- #4 - Newbies with lots of bandwidth - Most college students aren't experienced computer security experts - they're English Majors, and Chemical Engineers, and MBA-seekers, and pre-law or pre-meds, and Freshman CS Students who aren't all experienced yet, and most of them are running Windows versions that are fundamentally insecure even when administered well. And all these attractive targets are in one place with lots more bandwidth than dialup users and relatively stable IP addresses - so if you crack one of them, you can use it to search for more targets, and it's a lot easier on a campus LAN than in a dialup network. Once you've got your suckers, they can output a lot more bandwidth than AOL newbies you've suckered with a new game program like "Attack On Troy", though networked games are a fun attack at colleges as well - especially high-pressure high-tech schools where students do their recreation intensely as well.
- #5 - Not every school is MIT. Podunk Community College may not have quite the same resources to abuse, but it doesn't have the same level of defenses, either, and it may have more resources than half the small ISPs on the market.
- #6 - Early Adopters of Networked applications - Universities are great places to distribute things like napster://horse_with_no_name.mp3 and IRCfreefone and Quake 6.2: Mass Destruction and CryptoStealthGnuTella and UsenetPornHider and that eXcellent rave-support tool XFinder. Bad Guys don't need to infect everybody - just enough people to reach critical mass.
It's a target-rich environment out there. We've been lucky so far.Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Oh really? What makes you say that, I wonder?
IPv6 just provides a larger address space and adds support for IPSec (which can also be supported on IPv4.) It has got nothing to do with the problems you named. And ping and traceroute are the least sophisticated tools possible.
And ping and traceroute are the least sophisticated tools possible.
Yes, and as such, they are also the most useful.
If I was running a large site and I were concerned about people running 'predictive acknowledgers', could I not modify my stack to send packets of varied size? I could just modify the last bit or two of the packet size semi-randomly. The bogus ACK would be ignored, the luser using such a technique wouldn't get his download and would eventually play fair.
Also, if I tell the server to dump my 2Meg download into 1 packet, what happens when my wife picks up the phone and interrupts transmission? Will the whole 2Meg need to be resent? IOW, is this technique only useful on extremely reliable connections (which are VERY rare)?
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
A user connects. Server uses sting to determine network characteristics. If the user is ACKing faster than what is reasonably possible start decreasing the window size. That'll teach them to try to cheat!! Bwhahaha...
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
It is this set of victim machines which launches the final attack.
:)
I personally doubt that there is any defence against a propperly executed DDOS attack.
Stefan is not proposing a way to catch the perpetrator, but to locate the computers that are performing the DDoS attack.
As in the article simply put...
The basic idea behind the approach Stefan outlined is for each router that forwards a packet to mark it with information that will allow the recipient of the packet to trace it to it's source.
This is over simplified but in the article he explains a way to mark packets, in a kinda random way, in such a manner as to be able to trace the source and then taking the proper action. Temporarly shutting down the deliquent computer's internet connection.
This would not prevent the DDoS attack but it would speed up the process of shutting it down by removing the human factor in tracing the attacks.
Because there is no difference between a propper DDOS and "The SlashDot Effect."
Yes there is! A DDoS attack is a larg number of computers sending/requesting Massive amounts of information. The "Slashdot Effect" is Massive amounts of computers sending/requesiting moderate amounts of information. Except for large downloads then they are requesting Massive amounts of information, i.e. when netscape pre-6 was announced
If at first you don't succeed, skydiving is not for you.
Ok several questions about the method for identifying the DDOS user.
First the method employed is to XOR the addresses of the first and second routers on an edge. Now it is clear that you can trace back IF you are sure what the IP of the secondary router is. However given that the data can follow multiple paths how are you ever certain what this IP is. Secondly as it is a probablisitic process the second IP of the router may be one of many. Is this solved because the IP's of routers along the path are very sparse?
Secondly what prevents a DDos attack from faking this field. Make it look like the attack came through another nearby router.
Thirdly as most DDOS bounce pings off of remote boxes this doesn't let you catch the perpratrtor only identify what boxes are pinging you (these boxes most likely not being aware they are used in a DDOS attack won't be using these methods) thus as this method doesn't allow you to block the DOS attack (most of the packets will be encoded only with routers close to the destination and you don't want to cut off all trafic) what good is it?
If you liked this thought maybe you would find my blog nice too:
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'.
Congestion control was developed in response to a congestion *crisis* in the late 1980s. Proper congestion control is a requirement for the Internet to function. The LACK of congestion control is common streaming and multicast protocols is a commonly cited major hurdle for the deployment of multicast applications on the Internet.
It's been a nightmare scenario for awhile now that Microsoft (they of the "transient failure" RST packet) would unscrupulously try to gain a competitive advantage by manipulating congestion control. By "breaking the rules" they could make a faster stack. Another scary thought is that silly "Internet Accelerator" products could actually sell REAL accelerators, that provide horsepower boosts at the expense of the entire network.
What you DON'T want to see happen is for Linux to gain "turbocharging" via congestion-ignorance. What that does is set up an arms race between Linux and every other stack vendor, and particularly Microsoft. That arms race could easily lead to congestion collapse and yet another Internet scaleability crisis.
What Stefan Savage is describing are VULNERABILITIES in common TCP/IP stacks. They need to be fixed, and programs that take advantage of them need to be considered in the same light as programs that get rid of pesky security measures on remote computers --- as exploits.
Just chiming in here, because I think it's odd that people here are paying more attention to the clever backtracking hack Savage came up with and less attention to the important, new security vulnerabilities he has documented.
No. You are way wrong on number two. Our central systems where I work are much, much more secure than most people think. There is a full time person who does nothing but work on security things.
And, we dont packet filter here. We run nfr, yeah.. but the only time we packet filter is when a research group asks for full control of a machine, or in other words, they want us to lose responsibilty of that machines actions.
Then we firewall their machines.
It isn't 'clueless', its about where the 'blame' goes when one gets cracked and sits for weeks unnoticed. If it was to happen to the paid sysadmins, I would fire them on the spot if it were obvious there was a crack.
Hrm.
-- dieman - Scott Dier
Now I know what my next nonprofit time-wasting project will be! The prospect of even greater download speeds with a cable modem is just too great to pass up.
The place where he's addressing the DDOS attacks is at the end of the article. He's not actually stopping the attacks, he's just allowing the victim to analyze the flooding packets and find out where they're coming from. I guess that by analyzing the traffic more quickly (encoding route information in the TCP header) the good guys should be able to black hole the bad guys sooner, thus shutting down the attack.
Oh, go on, check out my job.
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.
He's looking for an academic job, and some of his papers (Especially the project team that created the SPIN kernel stuff) are quite impressive.
--
Gonzo Granzeau
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty