The reason (in most cases) that SYN flooding works is not that it takes up your entire bandwidth like smurf or something would do. SYN flooding works because when a machine accepts a SYN packet it has to take CPU time and memory to setup an internal state of that packet (ie it assigns a chunck of memory and puts things like RemoteIP/RemotePort/timestamp etc in it...) so a SYN flood can usually either gobble up all availible memory or all CPU time long before it eat's up the pipe...I'm assuming (although I haven't had a chance to read the literature on thier page yet) that when they talk about using a client puzzlesit works something like this.. client --SYN---> Server server --Puzzle/ID--> client client --Puzzle Result/ID--> Server <server set's up internal socket state> the server would build a table of puzzles and ID's when it had free CPU time, when a client sends a SYN the server would send Puzzle/ID and not create an internal state for that connection, when it received it's response form the client it would erase that puzzle/id from it's list and create a new state... The problem with this is that it will not happen overnite...it would require a new TCP/IP stack... This is somewhat along the lines of what someone was talking about on the list earlier where server sends back SYN-ID only it adds another layer of work, so not only does the from IP have to be legit, it also has to do some work... At 11:36 PM 2/14/00 -0500, Michael B. Rash wrote: > >http://www.rsasecurity.com/rsalabs/staff/ajuels/papers/clientpuzzles.pdf > >So basically RSA seems to think that this technology could be used to help >stop the recent DoS attacks that gained so much media attention, but >either I am not understanding something, or they have made a mistake in >their architecture. > >The technology can be summarized by the following excerpt from the >paper's abstract: > >"...TCP SYN flooding is an example of a connection depletion attack in >which an attacker... <snip>. We introduce a countermeasure >that we refer to as a client puzzle protocol. When a server comes under >attack, it distributes small cryptographic puzzles to clients making >service requests. To complete its request, a client must solve its puzzle >correctly..." > >OK. First of all, "distributes puzzles" implies that the attacking >machine is listening for them in the first place, which most likely it >will not be (the TCP SYN packets would most likely be spoofed >anyway... where do they think they are going to "send the puzzle"?). An >attacking machine simply needs to create a bunch of SYN packets and get >them to the target, who will then begin generating the corresponding >SYN-ACK packets thereby overflowing its connection buffers. That's >it... that is the whole attack. The only advantage in doing something >like the client puzzle protocol would be to limit the number of >*legitimate* connections that a machine could make since the >computationally expensive cryptographic puzzles would start eating lots of >compute cycles if it tried to initiate 10,000 connections. If I'm an >attacker I don't care about legitimate connections... I don't even care if >I see *any* packet return from the target. > >What am I missing? How would the CPP help to prevent DoS attacks? > >(Note of course that we are talking about both a client and server side >modification to make all of this possible in the first place... sounds >like an upcoming product from RSA). > > >--Mike | "...the whole aim of practical politics is > | to keep the populace alarmed (and hence >http://www.math.umd.edu/~mbr | clamorous to be led to safety) by an > | endless series of hobgoblins..." -Mencken > mutated / aka daN. ph33r my l@me newBi3 sKillz
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:04:14 PDT