Re: SYN flood messages flooding my mailbox

[Avi Freedman <freedman () netaxs com>]

> 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
- - - - - - - - - - - - - - - - -