SYN flood messages flooding my mailbox
Avi Freedman
freedman at netaxs.com
Mon Sep 16 16:37:31 UTC 1996
> 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
More information about the NANOG
mailing list