SynFlood Mitigation

[elliotpea]

Hi there,

I run a small hosting company with a round 100 servers.  We have a 1Gbps Uplink, but only utilise around 120Mbps outbound.

Recently we've had the pleasure of a Spoofed SynFlood attack to one of our hosts.  This hasn't cause any network wide issues, just problems to that specific host (Linux based).  In 48 hours i've had a steep leaning curve on what a SynFlood attack actually is and the options to mitigate it.  So far any attempt to OS level mitigations have proved ineffective. Such as enabling syn cookies, increasing the backlog size, and other kernel tuning.

So i'm here looking for advice for an ASA which would be suitable for my requirements which would help protect the hosts behind it from such an attack. From what i understand this is done by the ASA proxying the syn requests, and only passing completed handshakes through to the hosts.

We're only a small company, so budget is a problem - i have been looking on ebay at two 5520's in HA.  However, i'm concerned about the number of concurrent connections.  

In my testing, i've managed to Synflood at test server with 300,000 open states.  This was a simple case of a Linux virtual machine attacking another one over a WAN connection - approx 10Mbps of traffic, 8K PPS and 300,000 concurrent states.

My testing was done with a freely available synflood spoof script from github (it scares me how easily this is to do).

Could you possibly advice on what cisco product i should be looking at, and if i'm going in the right direction?

Thanks,

Elliot

[luckymike33]

Hi,

The technology you are looking at using is TCP intercept which is used to protect against a large number of incomplete TCP sessions (what you have), the 'threshold' for this should be set to a value which is below the capabilites of the server you are trying to protect.

On the firewall, this is configured using a service policy; you configure:

- maximum concurrent connections

- max embryonic connections

- max per client connections

and you configure various timeout values to specify the behaviour of the firewall when embryonic connections start to occur.

So - you need a firewall which has capabilities above and beyond the server you are trying to protect, If you are saying you need to be able to defend against is 300,000 concurrent sessions - don't forget you will have other sessions passing through the firewall at the same time, so it would be better to get something large enough to handle all your traffic.

We use 5545X firewalls which I think can handle 750,000 concurrent sessions. #

The data sheets for older ASAs can be found here

http://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/product_data_sheet0900aecd802930c5.html

and for the next generation can be found here

http://www.cisco.com/c/en/us/products/collateral/routers/800-series-routers/data-sheet-c78-729807.html

and a good explanation of TCP intercept is here

http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_config/conns_connlimits.html

HTH

Best wishes

Mike

[elliotpea]

Hi Mike,

Thanks very much for taking the time to reply.  I've been studying the ASA documentation and CLI reference, so i've got a good idea now and your reply has confirmed my thoughts.

I've ordered an ASA 5550 from Ebay - at just over £1100.00 it offered the best £ per session/throughput ratio. Obviously it's last generation, but i i don't believe this will be an issue for us.

Once i have this one installed and running i'll probably end up getting another for HA, especially being used equipment, considering it's sitting directly on my entire companies uplink!

I plan to deploy this in transparent mode, we use on server software firewalls already for specific port blocking, which will stay in place as every customers requirement is different - the ASA will be used for DOS deflection and anything else it can do to ensure only 'clean' packets enter our network. I don't need it to go into the application level i don't believe. Which brings me onto my next question if i may?  What other features of the ASA are useful in this situation?  

I've picked this list from the connection section of the configuration guide, i think all of these will be useful to us:

Dead Connection Detection (DCD)

TCP Sequence Randomization

TCP Normalization

TCP State Bypass

But then i also wonder about some of the other features the ASA has.  Can you or anyone offer advice on what are useful features that i should focus on setting up for deploying the ASA at the network edge?

Thanks again,

Elliot

[luckymike33]

Hi Elliot,

That's not a bad start - although it can be very very hard to successfully defend against this kind of attack (mainly due to the distributed nature of them), But other things you can do are:

1. Configure the botnet traffic filter - this is something like a reputation based filter that filters against a known blacklist.

2. configure threat detection - although this is more of a monitoring tool, with some analysis it can provide valid info, on most vulnerable servers etc

3. Filter spoofed ip addresses, i.e. private ip addressing etc

4. consider increasing your bandwidth, increasing server capacity (can be expensive and futile though)

5. consider employing the services of a 3rd party ddos prevention - i.e. at & t.

These things can be very hard to defend against, but probably the best thing you can do is to tune your ASA TCP connection settings until you are happy that you are not throwing away genuine traffic whilst resetting the embryonic half open sessions.

Best of luck

Mike