North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Syn flooding attacks
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 +-------------------------------------------------------------+ > >
|