Slashdot Mirror
New Denial-of-Service Attack Is a Killer
ancientribe writes "Hacker RSnake blogs about a newly discovered and deadly denial-of-service attack that could well be the next big threat to the Internet as a whole. It goes after a broadband Internet connection and KOs machines on the other end such that they stay offline even after the attack is over. It spans various systems, too: the pair of Swedish researchers who found it have already contacted firewall, operating system, and Web-enabled device vendors whose products are vulnerable to this attack." Listen to the interview (MP3) — English starts a few minutes in — and you might find yourself convinced that we have a problem. The researchers claim that they have been able to take down every system with a TCP/IP stack that they have attempted; and they know of no fix or workaround.
Some DOS attack on Slashdot in progress?
While it is pretty interesting, and disturbing, we are once again faced with a "The Internet Will Cease To Exist And Your Brain Will Explode" vulnerability. We dont know exactly how it works, we dont know exactly what to do to stop it, fixes are not available, and we are all doomed. The podcast goes into enough detail about how they discovered it to be replicated by skilled evildoers without too much trouble, but nobody knows how long, easy or invasive a fix is going to be.
People who think they know everything are a great annoyance to those of us who do.
Doesn't affect me. I haven't used DOS in YEARS. Some folks need to move up to Windows 3.1. That is where it is at.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Unless it's a generic vulnerability in the TCP spec, in which case almost every implementation of it would be vulnerable - including all those Linux machines. Linux is not some magical shield, it takes responsible use to keep it secure.
Forget world peace, bring on -1 pointless
Here's a link to an article in English:
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html
From the article:
Many TCP servers use a technique known as a SYN cookie in order to prevent attackers using spoofed IP addresses from launching SYN flood denial-of-service attacks against them. The cookie is essentially a chosen TCP initial sequence number that is calculated using some specific hashed metadata that reflects the details of the specific TCP connection. Once the client returns a correct packet to the server, the server knows that the client isn't using a forged IP address.
Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. "We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it," Lee said.
Typical /. reaction to potential danger:
"Hah. Until I don't taste nuclear winter snow I don't believe that's gonna happen'"
Give the man his nuke. He earned it.
mov ax,4c00h
int 21h
Here's a better story with more info: http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html Looks like they're able to mess with the session parameters, as you said.
This doesn't me since use I UDP all communications communications for.
This
Sockstress computes and stores so-called client-side SYN cookies
This isn't supposed to be possible. SYN cookies are supposed to contain at least 24 bits worth of entropy, produced by running a server-side secret through a one-way hashing function. You can easily obtain a SYN cookie by performing the initial SYN with the server. A SYN+ACK comes back which contains the SYN cookie (as the initial sequence number). The cookie so received is unique per TCP connection (IP address and port numbers at both ends), and valid only for a limited time. The server side does not maintain any state information until the cookie is returned in the client's ACK.
If they are actually computing SYN cookies on the client side, it's evidence of a weak SYN cookie implementation. Computation of the cookie should be infeasible without access to the server-side secret. Of course, this may be a case of sloppy reporting. As usual, we aren't given all the details of this earth-shattering vulnerability. We are simply left to guess whether these folks (and those that report on them) know what they're talking about or not.
They could be guessing cookies, and that would explain the "it will hurt intermediate systems" excuse they used for not demonstrating it, since they'd need to flood the peer TCP with millions of randomly-guessed initial sequence numbers. Incidentally, if this is a TCP SYN-flood attack of this sort, the "after effects" they mention have to do with the fact that all the TCP connections must time out naturally -- a process which might take several minutes per connection, depending on the configuration of the listening server application. The process is naturally limited by bandwidth and the size of the TCP state table: you have to be able to send successful fake ACKs fast enough to fill the TCP state table. All the usual mitigations for TCP SYN floods apply, such as increasing the state table size and reducing the timeout for open but idle connections.
It's not at all clear that this is any worse than the kind of DDoS attack that a typical botnet can unleash. In that case, you get thousands of perfectly real TCP connections from multiple addresses almost simultaneously. So maybe this attack doesn't require a botnet, but I don't see that it's a big new threat (as I've described it).
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
Now we see that a little bit of knowledge can be a dangerous thing.
The point that's in the grandparent's post is not that your own syn-cookies can be used against you. Syn cookies on your server are doing the right thing and are protecting you against normal syn floods.
What's happening in this attack is that the client side (the attacker) is using their own syn cookies to store information about connections on your server (instead of in their own memory). This allows them to handle more connections than otherwise. Unfortunately there is nothing you can do to stop this. They are using required behavior of the TCP stack for their information storage.
Some mitigation strategies that I can think of
The parents "fix" will make things slightly worse during this attack since turning off syn-cookies will mean that your server will have to track even more TCP connections. Not just those that are active, but also those that have just started. Of course, it will also make the new attack pointless since they can just do a normal syn-flood instead.
The best current full fix I can think of is to use IPSEC and ensure that all incoming connections are authorised. Your own users will still be able to DOS you, but at least you can hunt them down.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Oh no, me too!!
C:\Documents and Settings\Adam>cat /proc/sys/net/ipv4/tcp_syncookies
'cat' is not recognized as an internal or external command, operable program or batch file.
Any sufficiently simple magic can be passed off as mere advanced technology.