Monday, August 15, 2011

SYN Attacks

Today while checking my Apache logs I saw a message that said: "possible SYN flooding on port 80. Sending cookies.". I'm familiar enough with DoS attacks that this made me immediately concerned so I went online to find out what I could. Googling this message turned up a number of good security articles about what it means and what can be done to try and protect oneself. Essentially a SYN flood is when a malicious host sends the first part of a TCP handshake (a segment with the SYNC flag set) and never responds to the SYN+ACK that it receives. The attacked server sits waiting for a response, holding the half-open connection in its backlog queue and attempting to re-send the SYN segment. Over time the backlog queue fills up and the server starts rejecting any new connection attempts.

Documented ways to confirm that you are actually under a SYN flood attack include using netstat to view half-open connections (listed as SYN_RECV) and using wget to try and load your site from the actual host to see how long it takes (doing it from the local host takes out some network considerations). In general though slow performance of your website or an inability to connect at all along with these kinds of logged messages are a good indication.

In my case, I ran netstat a few times over a number of minutes and while at one point I did see upwards of 8 SYN_RECV entries, for the most part there weren't a lot of half-open connections. I also checked netstat to get a total list of open connections by IP and didn't see anything suspicious there. Even though I knew that the source IPs were likely spoofed, I also used Geo IP tool to look up where the attacks were "coming from" just to satisfy my own curiosity.

Even though it seemed that I wasn't likely the victim of a SYN flood attack at this point (maybe some kid playing around somewhere and trying to get his/her newb hack on), I was very interested in what I was reading and also thought it best to use this as an opportunity to be proactive. I read about some standard settings to the kernel and TCP stack options that can be implemented in both Windows and Linux to help mitigate problems caused by this kind of activity. One of the basic ones involved implementing SYN cookies.

By enabling SYN cookies, the sequence number being sent back to the malicious host is used to complete the handshake. Usually this number is randomly generated, but in this case it is constructed according to specific rules. If your server then receives an ACK with that sequence number, it completes the connection. However it does this without relying on the backlog queue so you don't have to worry about it filling up and rejecting new legitimate connections. You can tell that this is effect when you see the message: possible SYN flooding on port 80. Sending cookies" in your logs.

So, it seems like I had this turned on on my server already, although in the file that controls this setting, /etc/sysctl.conf, the line for this was commented out. I uncommented it just to be on the safe side.

Other things that can be done are to increase the backlog queue size, change the timeout values for the SYN (in other words decreasing the number of retries and consequently how long it keeps half-opened connections in the backlog queue).

Resources I used for getting this information include:

No comments:

Post a Comment