How to harden your firewall against the powerful tools nmap and hping3, based on the Thylacine iptables based host firewall. This is part 3 : D.O.S attacks
by Emeric Nasi
Note: In order to understand this document it is strongly recommended that you know about the TCP/IP protocol and have iptables, nmap and hping3 installed. I recommend also the use of wireshark that is a great tool to learn about network protocols.
License : Copyright Emeric Nasi, some rights reserved
This work is licensed under a Creative Commons Attribution 4.0 International License.
III Iptables versus D.O.S (flooding)
Denial of service and distributed denial of service attacks based on packet flooding are the plague of the Internet. It is quite impossible to fight against a massive DDOS attack coming from thousands of machines, however, it is possible to do something against smaller attacks.
In this part I am going to use hping3 to generate the flooding attacks.
3.1 ICMP flood
ICMP flooding consists to send a maximum ICMP data to a machine in the minimum amount of time, for example pings. In the "old" times it was possible to corrupt a machine using a single huge ping (the ping of death), hopefully these times are over, but it is still possible to attack the bandwidth and process time of any machine who accept ICMP packets.
Example of an ICMP flood using hping 3 :
hping3 -q -n -a 10.0.0.1 --id 0 --icmp -d 56 --flood 192.168.0.2
The -q option means quiet, the -n means no name resolving, —id 0 if for ICMP echo request (ping), -d is size of the packet (56 is the normal size for a ping).
hping3 -q -n --rawip -a 10.0.0.1 --ipproto 1 --file "./icmp_echo_request.bin" -d 64 --flood 192.168.0.2
How to protect against ICMP flooding? You can always completely turn off ICMP but it is a bit radical and is problematic for a server.
Block all ICMP packets :
iptables -p icmp -j DROP
In the Thylacine firewall I choose to blacklist for 3 minutes any IP that sends more than a certain amount of ICMP packet per minute.
3.2 UDP flood
It is the same concept as in ICMP flood except that you send a huge amount of UDP data. UDP flood can be very dangerous for the network bandwidth.
Generating UDP flood with hping3 is easy :
hping3 -q -n -a 10.0.0.1 --udp -s 53 --keep -p 68 --flood 192.168.0.2
With UDP you must precise a source and a destination port, here I chose DNS and BOOTPC (for dhclient) port. The BOOTPC (68) port is very often opened on personnal computers since most people use DHCP to connect themselves to a network.
How I fight UDP flood in Thylacine :
3.3 SYN flood
SYN flood is the most used scan technique, and the reason for this is because it is the most dangerous. SYN flood consists in sending a huge amount of TCP packets with only the SYN flag on. Because a SYN packet is normally used to open a TCP connection, the victim’s box will try to open all these connections. These connections, stored in the connection tables, will stay open for a certain amount of time while the attacker continues to flood with SYN packets. Once the victim’s connection table is filled up, it won’t accept any new connections, so if it is a server it means it is no more accessible by anyone.
Example of a SYN flood attack using hping3 :
hping3 -q -n -a 10.0.0.1 -S -s 53 --keep -p 22 --flood 192.168.0.2
To limit syn flooding I used the same kind of iptables features I used for ICMP and UDP flood.
3.4 Other TCP flood attacks
There are lots of possibilities of flooding using TCP. Just set the various TCP flags as you whish. Some TCP flooding techniques consist in setting a lot of unusual flags to perturb week O.S.
Example with the SARFU scan :
hping3 -q -n -a 10.0.0.1 -SARFU -p 22 --flood 192.168.0.2
Here we set the flags SYN, ACK, RST, FIN and URG.
There is a very simple way to avoid these kind of TCP flooding. Since all TCP connections should start by a SYN, simply delete all TCP new connections that do not.
iptables -A INPUT -p tcp ! --syn -m state --state NEW -m comment --comment "Drop TCP connection not starting by SYN" -j DROP
However in the case of the SARFU scan Thylacine will also log that it detected a kind of Xmas scan and blacklist the IP source. If you don’t know why, you should (re)read the second part of this article!
This article is now finished. You probably realized I "forgot" to talk about a lot of things (smurf attack, hping3 file transfer and traceroute features, nmap O.S. fingerprinting, etc.).
When I’ll have the time I will complete this article with the missing parts. If you already want to look at other firewall features, you should have a look at the Thylacine source code, or download and run Thylacine beta on your box.