Solution To DoS Attacks

Steve Gibson of grc.com claims to have come up with a way of preventing DoS attacks by spoofed SYN flooding. The idea is that no information is retained by the server after the initial SYN is received. The server's resources aren't used until the ACK is received from the client (which must have a real address to receive the reply from the server). The SYN/ACK back from the server is encrypted to prevent "ACK flooding." It can be implemented in a way that is transparent to clients, so only servers need alteration. I'm skeptical (and this only solved one kind of DoS), but it's worth looking at.

Comments

Re:this is an old old idea

[daw]

It was originally invented as part of Karn's key exchange protocol, yes, though the general idea of having a handshake without the server having to keep state (by encoding the state as a "cookie" sent to the client and then verifying and reconstituting the state from the cookie when the client sends it back) is useful for non-encrypted TCP as well (but you need to use cryptographic methods to verify the integrity of the cookie of course). Like I said it's in the Linux kernel.

The whole reason you don't want to use an array like you describe is that it requires that the server dedicate resources -- an array entry -- to a connection before the client's location is verified by the three-way handshake. This is exactly why syn floods work, by filling up the queue with bogus connection requests that never complete.

Dan Bernstein also has an old old web page in which he describes this idea in the context of IPV4:

http://cr.yp.to/syncookies.html

... but I still think Phil Karn is the real inventor.

this is an old old idea

[daw]

This idea -- invented by Phil Karn for IPV6 and known as Photuris cookies there -- was long ago implemented in IPV4 to prevent SYN floods. It's descried in several RFCs and it's available in the Linux Kernel as the "SYN cookies" option.

this is old news -- already in linux -- details

[sagei]

we put this into the linux kernel in early 2.1. the define is CONFIG_SYN_COOKIES and it also needs a sysctl/proc option to be enabled (net.ipv4.tcp_syncookies)

basically, you make your syn a function of the session's data (local and remote port, hostname, and syn) and some secret. then when the ACK returns with your SYN (and all the original data), you can inverse the function to see if it matches.

if you make this function a cryptographically strong one-way hash and use a good secret, the cookie is fairly undeterministic

in linux, we do this exactly:
our_initial_syn = one_way_hash(src.port, dst.port, src.host, dst.host, secret) + src.initial.syn;

by adding on, and not using as an argument, the initial syn, we can keep our syns properly spaced. the secret is a counter that is incremented every minute. this acts as a method for checking for old acks, too.

the TSB is not created until the final ack is received. the MSS is encoded in 3-bits in our syn (so our syn is 2^28 bits secure). no TSBs until ACK means no queue size ... it works.

see http://cr.yp.to/syncookies.html for the initial discussion of implementation.

robert m love
my initials at tech9 dot net

Re:This ain't gonna work

[Captain Derivative]

"To me it seems completely bogus to base your design on the assumption that you will reboot frequently."

In related news, Microsoft announced today that the forced-weekly-reboot feature of Windows 2000 + IIS allows for greater security, because it forces the system to generate a new key. A Microsoft spokesperson criticized the use of Linux for web servers as "Irresponsible -- why, you're using the same key for 817 days! With our system, you'd be hard pressed to get the system to use the same key for more than five days straight!"

(or maybe not...)

--

The *REAL* solution

[b0z]

Ok...look at who the majority of people doing these DoS attacks are. Normally they are teenage boys who's hormones are going wild. This is not always the case but it is a safe bet that it is true over 50% of the time. So...here is the solution to prevent these kids from doing DoS attacks:

1) Legalize drugs.
2) Legalize prostitution.
3) Create a welfare type program for those who do not get enough sex or need to do drugs in order to not use the computer.

That should take care of just about all the problems in society. You're welcome.

It's a joke, laugh.

This ain't gonna work

[BitKat]

I don't need to tell anyone what the weakness will be when this scheme uses a fixed key. So, they say they want to generate a new key each time the system restarts (sic!). Last time I booted my server it had been up for 817 days. To me it seems completely bogus to base your design on the assumption that you will reboot frequently. (Or, for that matter, on any assumption at all)

Not new, and not complete

[mayoff]

This guy's "innovations" aren't new; IPV4 SYN cookies were invented by Eric Schenk and Dan Bernstein back in 1996. Not only that, but GRC's solution (as described on that page) doesn't address MSS or even discuss TCP options. See http://cr.yp.to/syncookies.html for a much better discussion of TCP cookies.