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.
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:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
To make those settings load automatically on startup, add those lines to the file
net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 3
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:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
And naturally, add this line to the file
net.ipv4.icmp_echo_ignore_all = 1
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
iptables to disable Ping in only some interfaces.
On Windows this can be done with the command:
netsh firewall set icmpsetting 8 disable
Windows Firewall must be active.
thank you for this useful information, now coming to the case that I'm already attacked, and that the flooding is happening how can I filter the attacking hosts and is it possible to stop the attack? Apr 13, 2013 at 7:22
You must contact your ISP for assistance, there is nothing you can do. You must understand that even if you put rules to drop the malicous traffic, you would still receive it before the rule drop it. There is no way to prevent it from reaching your server. If the attacker is contacting you, I strongly recommend you ignore him and his damands. Don't even talk to him, giving attention to this kind of retard is doing exactly what they want.– HavenardApr 13, 2013 at 7:25
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.
Thanks for your reply. Does it mean that once the attack begins it's impossible to get rid of it? I was thinking that if I can find some pattern in the ip addresses from which the attack comes or in the timing of the syn packets it would be possible to blocks these adresses.. Apr 13, 2013 at 7:08
The problem is when the packets reach you will need to spend time inspecting the IP headers, then you are already allocating resources (cpu time/bandwidth), which is something you want to avoid. Apr 13, 2013 at 7:19
but what if I have an automated process that would filter them for me? would it be possible to know which hosts are participating to the attack and which packets are part of the half opened TCP hand shake? Apr 13, 2013 at 7:25
that entirely depends if the IPs are spoofed or not Apr 13, 2013 at 7:25
1If he's done a porper job, it's entirely random Apr 13, 2013 at 7:30
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.