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? -- Paulo Maffei Email : Paulo.Maffei@br.global-one.net
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 +-------------------------------------------------------------+
Phil Howard wrote:
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).
On the latest Linux kernels (and perhaps on other free UNIXs) there is a feature known as "SYN cookies". Basically this feature lets servers eliminate the table of half open connections by carefully crafting the ACK so that the next packet from the originating host has enough information to fully open the connection. This was widely discussed on nanog and other lists when SYN flooding attacks first became popular a year or so ago. Check the archives for more information or check out the Linux TCP code in the latest kernels. Jeff
Phil Howard <phil@charon.milepost.com> wrote: [about SYN flooding] |I don't know of any routers that have these or other means of dealing with |the SYN attacks. If you search cco for "tcp intercept", you should find something interesting. This feature was available in 11.2(4)F. ((paraphrased from memory)) Basically the router completed the handshaking then passed on the completed connection to the inside host. When under attack, it halves the timeouts (progressively?) for half-open connections. I don't know what happened to the F branch. It seems to have been left behind. Peter ----* -- The Lost Patrol. Level 30~36, HP 800, AC -2. The Highway Patrol of The Random Road, they keep the peace, they eat donuts. -TRR '97 O_u \\ // P-Chan ya \\ Global OnLine Japan U \Beh! \\ // P-Moji-Yo! \\ Steam Engineering
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 +-------------------------------------------------------------+
participants (5)
-
Jeffrey C. Ollie -
Kenneth E. Gray -
Paulo Maffei -
Peter Evans -
Phil Howard