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