Syn flooding attacks

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

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]