I would like to know if it's possible to stop a TCP SYN OR ICMP Flood attacks if these attacks are detected at time. What is the most accurate process to filter these addresses if the only way is to block the IP addresses of the botnet.
Chances are these attacks will be done using IP spoofing, the first line of defence is encouraging your ISP to adopt BCP38 to avoid IP spoofing.
The problem with a Denial of Service attack is that often you need to prevent the malicious traffic from reaching you in the first place. You can not do a lot locally, but you can always opt in for a service like CloudFare (who also implement BCP38) as they can scrub these kind of packets before they reach you.
|show 2 more comments|
SYN Flood can be mitigated by enabling SYN Cookies. SYN Cookies prevent an attacker from filling up your SYN queues and make your services unreachable to the legitimate user.
On Linux, those are some settings you can use to enable and set up SYN Cookies efficiently:
To make those settings load automatically on startup, add those lines to the file
It is possible to protect a Windows box too, as its described in this article by Microsoft. Windows Vista and above have SYN attack protection enabled by default.
As of UDP flood, unfortunately there isnt much you can do about it. Howover, in a ICMP/Ping flood, you can setup your server to ignore Pings, so an attack will be only half-effective as your server won't consume bandwidth replying the thousands of Pings its receiving.
You can do that by running this configuration:
And naturally, add this line to the file
But bewere some watchdog systems require ICMP Echo to be enabled in order to work. Some rent servers will require you to leave ICMP Echo enabled because of that. But you can still use
On Windows this can be done with the command:
Windows Firewall must be active.
As an example of a severe UDP attack, I'm Senior Network Admin at a University in CA, and a couple days ago we had a severe UDP flood attack from no less than 553 separate hosts around the world.. Yes really.. I was only able to throttle down our (Large) incoming pipes from our provider and partially filter some of the incoming, and some of the resulting answering UDP.. This is a really nasty attack vector.. Still working on coming up with a better response countermeasures suite to deploy when this happens again.