SYN flood attacks

bigearsbilly · 02-07-2014, 05:23 AM

I suspect we are getting SYN flood attacks, seems unlikey to me though.

(I have numbered the lines)

Code:

....
   243  tcp        0      0 193.35.157.165:80       5.135.135.42:26919      SYN_RECV   
   244  tcp        0      0 193.35.157.165:80       5.135.135.42:186        SYN_RECV   
   245  tcp        0      0 193.35.157.165:80       5.135.135.42:20411      SYN_RECV   
   246  tcp        0      0 193.35.157.165:80       5.135.135.42:36017      SYN_RECV   
   247  tcp        0      0 193.35.157.165:80       5.135.135.42:41719      SYN_RECV   
   248  tcp        0      0 193.35.157.165:80       5.135.135.42:63233      SYN_RECV   
   249  tcp        0      0 193.35.157.165:80       5.135.135.42:11949      SYN_RECV   
   250  tcp        0      0 193.35.157.165:80       5.135.135.42:27161      SYN_RECV   
   251  tcp        0      0 193.35.157.165:80       5.135.135.42:10715      SYN_RECV   
   252  tcp        0      0 193.35.157.165:80       5.135.135.42:39373      SYN_RECV   
   253  tcp        0      0 193.35.157.165:80       5.135.135.42:61258      SYN_RECV   
   254  tcp        0      0 193.35.157.165:80       5.135.135.42:61700      SYN_RECV   
   255  tcp        0      0 193.35.157.165:80       5.135.135.42:54005      SYN_RECV   
   256  tcp        0      0 193.35.157.165:80       5.135.135.42:62755      SYN_RECV

if i tcpdump I am getting a continual stream of SYNs

IP 5.135.135.42.52096 > 193.35.157.165.80: Flags [S]

(These are being ACKED, cksums are reported correct)

Does this look like a SYN flood?
I cannot for the life of me see why anyone would do this to our little company.

Anyway if it is how to deal with?

use the sysctl stuff or netfilter

Ser Olmy · 02-07-2014, 06:13 AM

A few hundred SYN packets would not constitute a very effective SYN flood attack, but sure, that could be what you're seeing.

Do you have TCP_SYNCOOKIES enabled in the kernel? It makes the server pretty much immune to SYN flood attacks.

bigearsbilly · 02-07-2014, 06:37 AM

yes tried SYNCOOKIES in sysctl didnt make any difference.

This is only a dev server though so shouldn't get hits apart from me and the team.
No customers anyway.

Ser Olmy · 02-07-2014, 06:43 AM

What do you mean by "it didn't make any difference"? SYNcookies can't stop a SYN flood attack, but it ensures the attack doesn't use any resources (memory) on the server being attacked. Bandwidth will still be consumed, of course.

If you're publishing a web server on the public internet, you should expect HTTP requests from random IP addresses. There are lots of script kiddies out there scanning for web servers. If you don't want people to access your server, you shouldn't make it available to them.

bigearsbilly · 02-07-2014, 08:26 AM

Quote:

Originally Posted by Ser Olmy

What do you mean by "it didn't make any difference"?

Apologies I was expecting it to stop, I stand corrected. However I don't think a netstat full of SYN_RECV
looks very neat, Call me old-fashioned.

Quote:

If you don't want people to access your server, you shouldn't make it available to them.

No, I want to stop the SYN attack, there is a very subtle difference.

Thanks for your help.

juliuswh · 02-07-2014, 09:48 AM

If it's only 1 ip, you can try to blackhole it.

# ip route add blackhole 5.135.135.42 (or even "ip ro ad bl 5.135.135.42" for the laziests)

All packets coming from and to 5.135.135.42 will be dev-nulled.

Hope it helps.

bigearsbilly · 02-07-2014, 11:22 AM

Hmm interesting.

That doesn't make sense to me as at first glance as it appears to stop outbound, but...
I gave it a go and It has cleaned it up!

Still seeing the SYN packets coming in,

But of course, I guess there is no way of physically stopping the SYN packets from being delivered by the ISP router!
So they will always appear on the tcpdump?

Make sense?

(excuse me I am using this as a learning exercise!)

I guess sending anything back to the attacker is ignored anyway. In this sort of attack anyway.

juliuswh · 02-07-2014, 11:37 AM

Quote:

Originally Posted by bigearsbilly

Hmm interesting.

That doesn't make sense to me as at first glance as it appears to stop outbound, but...
I gave it a go and It has cleaned it up!

Still seeing the SYN packets coming in

Of course they're still sent by the attacker. But now they are ignored by your OS.

Quote:

Originally Posted by bigearsbilly

But of course, I guess there is no way of physically stopping the SYN packets from being delivered by the ISP router!
So they will always appear on the tcpdump?
Make sense?
(excuse me I am using this as a learning exercise!)

Yes you'll still see it on a tcpdump but only what is coming from the attacker. You should see no reply from your server.

Do the test, fire a tcpdump with and without the "blackholing" (type "ip ro del bl <ip>" to remove it from the routing)

Quote:

Originally Posted by bigearsbilly

I guess sending anything back to the attacker is ignored anyway. In this sort of attack anyway.

Indeed, the goal of this attack is a denial of service.

bigearsbilly · 02-07-2014, 11:48 AM

yes I did check with and without, excellent.

thanks, that is in my toolbox!

crate of champagne on the way.