You are here : Home » Learning security » Networks » Firewalls, IDS, IPS » Iptables firewall versus nmap and hping3

Iptables firewall versus nmap and hping3

Part 3 : D.O.S attacks

D 23 September 2010     H 08:53     A Emeric Nasi     C 0 messages


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.
Creative Commons License

This is the third part of the article "Iptables firewall versus nmap and hping3". If it is not already the case you should read the first part : The basics and the second part : Port scanning

Note : The iptables commands are from the Thylacine host firewall that you can find in the Thylacine security hardening tool.
Note2 : Even if this article is based on a host firewall, you can easily transpose the commands to a network iptables firewall.

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 --id 0  --icmp -d 56   --flood
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).

Note : Some systems configuration automatically drop ICMP generated by hping because of bad header settings (for example it is not possible to set sequence ID ). In this case, you can use wireshark to sniff a normal ICMP echo request packet, save it as a binary file, and replay it using hping3.
hping3 -q -n --rawip -a --ipproto 1  --file "./icmp_echo_request.bin" -d 64 --flood

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.

  1. # Create chain dedicated to ICMP flood
  2. iptables -N thyl-icmp-flood
  3. # Jump to that chain when ICMP detected
  4. iptables -A INPUT -p icmp -j thyl-icmp-flood
  5. # Get out of chain if packet rate for the same IP is below 4 per second with a burst of 8 per second
  6. iptables -A thyl-icmp-flood -m limit --limit 4/s --limit-burst 8 -m comment --comment "Limit ICMP rate" -j RETURN
  7. # Log as flood when rate is higher
  8. iptables -A thyl-icmp-flood -m limit --limit 6/h --limit-burst 1 -j LOG --log-prefix "Firewall>Probable icmp flood "
  9. # Blacklist IP for 3 minutes
  10. iptables -A thyl-icmp-flood -m recent --name blacklist_180 --set -m comment --comment "Blacklist source IP" -j DROP

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  --udp  -s 53 --keep -p 68 --flood
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 :

  1. # Create chain for UDP flood
  2. iptables -N thyl-udp-flood
  3. # Jump to chain if UDP
  4. iptables -A INPUT -p udp -j thyl-udp-flood
  5. # Limit UDP rate to 10/sec with burst at 20 (sometimes it is not enough, if you know a better average rate, let me know!)
  6. iptables -A thyl-udp-flood -m limit --limit 10/s --limit-burst 20 -m comment --comment "Limit UDP rate" -j RETURN
  7. # Log
  8. iptables -A thyl-udp-flood -m limit --limit 6/h --limit-burst 1 -j LOG --log-prefix "Firewall>Probable udp flood "
  9. # 3 minutes ban for flooders
  10. iptables -A thyl-udp-flood -m recent --name blacklist_180 --set -m comment --comment "Blacklist source IP" -j DROP

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  -S  -s 53 --keep -p 22 --flood  
To limit syn flooding I used the same kind of iptables features I used for ICMP and UDP flood.

  1. # Create syn-flood chain
  2. iptables -N thyl-syn-flood
  3. # Jump into syn-flood chain when a syn packet is detected
  4. iptables -A INPUT -p tcp --syn -j thyl-syn-flood
  5. # Limit packet rate to 2 per second with a 6 per second burst
  6. iptables -A thyl-syn-flood -m limit --limit 2/s --limit-burst 6 -m comment --comment "Limit TCP SYN rate" -j RETURN
  7. # Log flooders
  8. iptables -A thyl-syn-flood -m limit --limit 6/h --limit-burst 1 -j LOG --log prefix "Firewall>Probable syn flood "
  9. # Ban flooders for 3 minutes
  10. iptables -A thyl-syn-flood -m recent --name blacklist_180 --set -m comment --comment "Blacklist source IP" -j DROP
Note : If you are interested in fighting SYN flooding, I suggest you to search for informations about kernel settings like SYN cookies. In Thylacine, added to the firewall features I tweak the next kernel settings : net.ipv4.tcp_max_syn_backlog, net.ipv4.tcp_synack_retries, net.ipv4.tcp_syncookies and net.ipv4.tcp_keepalive_time.

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  -SARFU -p 22 --flood  
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.

Also in this section

21 September 2010 – Iptables firewall versus nmap and hping3

20 September 2010 – Iptables firewall versus nmap and hping3

Any message or comments?

This forum is moderated before publication: your contribution will only appear after being validated by an administrator.

Who are you?
Your post