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

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

(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 :slight_smile:

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.


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,