全部博文(24)
分类: 网络与安全
2010-02-08 15:32:19
SYN flooding had been considered by security experts before.It was generally considered insoluble.See, for example, ``Practical UNIX and Internet Security,''by Garfinkel and Spafford, page 778:
The recipient will be left withmultiple half-open connectionsthat are occupying limited resources.Usually, these connection requests have forged source addressesthat specify nonexistent or unreachable hosts that cannot be contacted.Thus, there is also no way to trace the connections back. ...There is little you can do in these situations. ...any finite limit can be exceeded.Large SYN queues and random early dropsmake SYN flooding more expensive but don't actually solve the problem.
SYN cookies use cryptographic techniques to solve the problem.I pointed outon 16 September 1996;Eric Schenk and I worked outover the next few weeks.Jeff Weisberg released a SunOS implementation in October 1996,and Eric Schenk released a Linux implementation in February 1997.
SYN cookies are now a standard part of Linux and FreeBSD.They are, unfortunately, not enabled by default under Linux.To enable them, add
echo 1 > /proc/sys/net/ipv4/tcp_syncookiesA server that uses SYN cookiesdoesn't have to drop connections when its SYN queue fills up.Instead it sends back a SYN+ACK,exactly as if the SYN queue had been larger.(Exceptions: the server must reject TCP options such as large windows,and it must use one of the eight MSS values that it can encode.)When the server receives an ACK,it checks that the secret function works for a recent value of t,and then rebuilds the SYN queue entry from the encoded MSS.
A SYN flood is simply a series of SYN packets from forged IP addresses.The IP addresses are chosen randomlyand don't provide any hint of where the attacker is.The SYN flood keeps the server's SYN queue full.Normally this would force the server to drop connections.A server that uses SYN cookies, however,will continue operating normally.The biggest effect of the SYN flood is to disable large windows.
Attackers can try to cryptanalyze the server-selected secret function:inspect a series of valid cookiesand then intelligently guess a new cookie.For a secure function,the attacker's chance of success is not noticeably betterthan the chance of success for a uniform random guess.Secret-key message authenticators are designedto provide exactly this type of security.The following function is extremely fast and appears to be secure:encode the input in 16 bytes;feed the result through Rijndael with a secret key;extract the first 24 bits of the result.
No matter what function is used,the attacker will succeed in a connection forgeryafter millions of random ACK packets.Servers can make this attack more expensive in two ways:
I think I was the first to point outthat TCP servers can use cookies without any changes to the TCP protocol.(Perry Metzger subsequently claimed that he had pointed this out earlier.However, Metzger didn't respond when Ifor copies of the relevant messages.NANOG archives show that Metzger stated on 9 September 1996that cookies would require a new ``TCP++'' protocol,and on 17 September 1996 that ISPs had to filter their outbound packets.)
My first proposal didn't comply with the TCP requirementto use increasing initial sequence numbers.Eric Schenk had the idea of adding something tothe client's initial sequence number.
I proposed time-dependent SYN cookies.The time dependence prevents attackers from (1) collecting valid cookies at a public computer and subsequently(2) reusing the cookies in a blind attack from somewhere else.
I invited Kuznetsov to either retract or defend his claims.He refused to do so.I'm sure he's aware by now that his claims are false,and that any attempted defense will be promptly ripped to shreds;but he's still not admitting his errors.It's unfortunate that he doesn't have more respect for the truth.
I also invited Akkerman to either retract or defend his claims.He did not respond.