|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SYN flood messages flooding my mailbox
> 1. Make the host less susseptible [teach engineers to spell?] > > Specific code fragments were given for BSD and Solaris. BSDI is > already in very good shape with recent kernel patch (that preceeded > the attacks and was intended to improve HTTP server performance). I just put up a page (pretty raw and for techies for now) that gives objects for sun4c and sun4m architectures under SunOS 4.1.x, and gives pointers to what to fix for those with NetBSD/FreeBSD/BSDi and kernel source. It's at http://www.netaxs.com/~freedman/syn/ I'm going to send a blurb about it off to inet-access, though it's possible that corporate customers (non-ISPs) would be attacked and might come to providers for assistance. (If they could even figure out what was going on...) You can point customers at this if they're being SYN-stormed. With these mods, even a Sparc 1+ can resist any realistic net-based SYN attack. > implementation. This is a denial of service exposure that has gone > unaddressed in host implementations until recently. BSD now uses a > hash table on the TCP PCBs (protocol control blocks in the kernel) and > with change of removal of the check can support close to 64K-2000 PCBs Hmm. Interesting. I was told that NetBSD did not... Which version of BSD should I look at? A hash table on a static array of PCBs is a much better solution than letting a linked list get to 2000 entries... > (until TCP port numbers are exhausted). At a 75 second hold time, For production I set this to 15 seconds, though we didn't hear any complaints when I ran our web server at 7 seconds for a few days. > this is well under 1kpps (rapid reuse of port numbers has other > problems). Some advantage is gained by the fact that SYN ACKs will be > sent and legitimate hosts will respond with RST, clearing the port > number for reuse. > > There was also a suggestion of a server to prescreen TCP SYNs. I > don't think that is needed. If your customer has Macs or NT boxes, it might be. A box that sits there and sends RSTs for all packets it believes to be part of a SYN storm would help Macs and other platforms for which we don't have kernel source :) > 2. Filter based on source address on inbound packets from singly > homed sites. > > A singly homed site cannot have assymetric routing since there is no > ohter path. All that is needed is for the router to look up the > source address in the forwarding table and if the route does not point > to the interface the packet came in on, dispose of the packet. This > would mean that even a singly homed university could not become the > source of SYN attacks unless the hacker was willing to use source > addresses in the range of the addresses of the university. This would > make tracing back to the source very easy. This would be a very cool router feature but can be done fairly well with outbound garbage filters. > What I am asking for ("we" if there is agreement) is the following. > > 1. Create an option to look up the source address in the forwarding > table. If the forwarding entry for the source address does not point > to the interface from which the packet came, drop the packet. Enable > this by default. Allow it to be shut off on a per interface basis. > This is most important on end system routers so if it cannot be made > to run on some routers with hardware assist without overly impacting > the forwarding path speed, then that's OK. Yes. > 2. Create an option to pack 1 in N packet into ... (what I have > written above as #3). It would be real handy if this could be done on > all routers, including those with hardware assist. This would mean > that any Cisco based ISP could very easily trace the source of SYN > attack to their own border and there would be no excuse not to. > [We've also asked for this feature for a number of other reasons > having to do with network capacity planning and statistical studies.] This sounds good as well. > Best Regards to all that are contributing to solving this problem, > > Curtis Avi - - - - - - - - - - - - - - - - -
|