[4415] in North American Network Operators' Group
Re: SYN flood messages flooding my mailbox
daemon@ATHENA.MIT.EDU (Perry E. Metzger)
Mon Sep 16 12:37:59 1996
To: curtis@ans.net
cc: nanog@merit.edu
In-reply-to: Your message of "Mon, 16 Sep 1996 11:30:35 EDT."
<199609161530.LAA00556@brookfield.ans.net>
Reply-To: perry@piermont.com
Date: Mon, 16 Sep 1996 12:19:58 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Curtis Villamizar writes:
> There have been three areas in which defense of SYN flooding has been
> suggested (maybe more, three that will help):
>
> 1. Make the host less susseptible
> 2. Filter based on source address on inbound packets from singly
> homed sites.
> 3. Improve the ability to trace such attacks back to source
>
> I'll argue that all three of these are needed since none of them alone
> can completely solve the problem.
Highly agreed.
> At issue is whether a stream of TCP SYNs can swamp a host TCP
> 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
> (until TCP port numbers are exhausted).
No hash table was being used for the infant connection queue. This
needs to be fixed. An adaptive mechanism to lower the hold time also
is needed.
> 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.
I want to double-emphasize this -- responsible netizens have to put
filtering in at their routers to prevent this sort of thing.
> 3. Improve the ability to trace such attacks back to source
And here we have a problem -- the providers are not, currently, well
equipped to deal with this sort of tracing. I've had a lot of trouble
getting action on this sort of thing. Given good characteristics for
the packet filters it is pretty doable to find the rogue packets even
in extremely heavy traffic flows, but without cooperation to put
equipment to do this up it is not possible to take advantage of the
technology.
Perry
