North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Syn flooding attacks

  • From: Kenneth E. Gray
  • Date: Tue Oct 21 15:54:55 1997

OK, it may be noise pollution ... but, 

[swallow]

1.The TCP Intercept feature is available in Cisco IOSTM software release
11.2(4)F - Enterprise and Service Provider images.
2.Once a TCP connection has been fully established the session (including
sequence number fix-up) is Fast Switched .... 

yadada, yadada, yadada ... there's a monitor and scream at the operator
mode based on threshold and an intercept and seek only terminating sessions
mode.

[belch]

At 12:09 PM 10/20/97 -0500, Phil Howard wrote:
>Paulo Maffei wrote...
>
>>     Hi, I had heard about a solution to Syn Floodind attack, but I'd
>> like to be sure about it so I could keep researching about these
>> solutions. I had heard that I could set up a filter in my router that
>> would wait for the second ACK packet after the SYN request and SYN-ACK
>> response before finish the whole connection with the server. Is it true?
>
>The problem is the server getting the first SYN.  For the router to help
>the server, the router would have to suspend the SYN.  But there will not
>be a followup ACK from the client unless the router fabrications the SYNACK
>to go back to the client.  But how will it know what sequence number the
>server would use on its side?  In order to proceed with a valid connection
>the router would have to be translating sequences for the remainder of the
>connection life.  You might as well have a proxy server.  Either a stateful
>connection router or a proxy server would then itself be susceptible to
>the SYN attack.
>
>There are ways to deal with this attack.
>
>The router could discard the SYN, remembering it, and let pass the retry SYN
>that usually occurs with valid connections and does not with invalid ones.
>This memory of SYNs would have to be large enough to handle all peak traffic
>over the time that SYN attempts would timeout and retry in clients.
>
>The router could pass on the SYN, remembering it, and if it does not see the
>SYNACK come through in some reasonable time, it can fabricate the RST and
>clear the server.
>
>I don't know of any routers that have these or other means of dealing with
>the SYN attacks.
>
>The server can enlarge its table of pending connections and shorten it's
>timeout on them.  Currently I think this is on the order of 2 to 3 minutes
>and I think I can live with shortening it to 20 seconds, if I could get in
>the kernel to make that change (easy for Linux, FreeBSD, etc, but not for
>most commercial systems like Solaris, NT, etc).
>
>-- 
>Phil Howard  +-------------------------------------------------------------+
>KA9WGN       | House committee changes freedom bill to privacy invasion !! |
>phil at      | more info:  http://www.news.com/News/Item/0,4,14180,00.html |
>milepost.com +-------------------------------------------------------------+
>
>