nanog mailing list archives

Re: SYN flood messages flooding my mailbox


From: "Perry E. Metzger" <perry () piermont com>
Date: Mon, 16 Sep 1996 12:19:58 -0400


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


Current thread: