SYN Flooding involves flooding a victim with SYN messages (as part of the three-way handshake) but never actually completing the handshake. Further to this the source address is usually spoofed.
There are numerous methods to help you identify if you are undergoing this style of attack -
If you are running linux you can use the netstat tool to view the relevant connection states:
netstat -tuna | grep :<port> | grep SYN_RECV
For example if you were being attacked on port 80 we would issue:
netstat -tuna | grep :80 | grep SYN_RECV
Or maybe even more helpful:
netstat -tuna | grep :80 | wc -l
or in Windows:
netstat a | findstr ":80" | findstr "SYN_RECIEVED"
or within Wireshark
If the attack appears that it is originating from a single IP address we can simply add a firewall rule in place - such as:
sudo iptables -A INPUT -s 1.2.3.4 -j DROP
otherwise - if the attack appears to be originating from multiple IP's there are a few tweaks we can make to the kernel to help mitigate the attack:
- The net.ipv4.tcp_synack_retries parameter can be changed to 3 (opposed to it's default of 5) to close SYN_RECV states earlier.
- The net.ipv4.tcp_syncookies=1 parameter - which enable SYN cookies.
- Increasing the syn backlog queue size (not always effective dependent on scale of attack) - by setting the followinG: net.ipv4.tcp_max_syn_backlog = 2048
- Reducing the SYN_RECV timeout using the net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45 parameter.
We can do all of the above by issuing:
echo net.ipv4.tcp_synack_retries=3 >> /etc/sysctl.conf
echo net.ipv4.tcp_syncookies=1 >> /etc/sysctl.conf
echo net.ipv4.tcp_max_syn_backlog=2048 >> /etc/sysctl.conf
echo net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45 >> /etc/sysctl.conf
sysctl -p
0 comments:
Post a Comment