Iptables firewall versus nmap and hping3

Part1

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 suggest as well 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.
.

The well-known hping3 and nmap are worldwide used and are really powerful tools. You can find countless documents about “how-to monitor a firewall using nmap”. In this article I will go further and explain how to monitor a firewall using nmap/hping3 AND how to tweak your iptables firewall to prevent attacks from these tools.

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.

I divided this article into three sections:
Basics iptables features (block or accept particular IP and port)
Iptables versus port scanning attempts
Iptables versus flooding attempts

I. Basic iptables features

Iptables principal use is a port based firewall. Iptables can be way more than this (ex pattern matching, connection tracking, etc) but 90% of the people questioning about iptables ask : how to block or accept a given IP address and/or port.

1.1 Test a particular port/address using nmap and hping3

Test if a particular TCP port is open using nmap :
nmap -p <port1,portt2> <dest_host>
Example :
nmap  -p22 192.168.0.2
nmap will answer if the port is open, closed or filtered.

Note : Keep in mind that it is not because nmap tells you something that it is true.
For example, if a firewall is set to reject packets from a blacklisted IP with a TCP RST-ACK packet, an nmap scan coming from that IP will tell that the port is closed even if in fact it is filtered (other IP can access it).
For nmap, a TCP connection closed using RST-ACK flag means that the port is closed (because that is what happens normally when there is no firewall). That is why hping3 may be preferred for more advanced users because it does not interpret itself the results of the scans.

Test if a particular TCP port is open using hping3 :
hping3 -S -c1 -p<port> <dest_host>
If a response is received hping3 will display the header of the packet.
Here is a way to interpret hping3 results (and remember what is written in the previous note, interpretation is not 100% sure) :

• If the response is a TCP SYN-ACK packet (flags=SA) you can assume the port is open.
• If the response is a TCP RST-ACK packet (flags=RA) you can assume the port is closed.
• If the answer is an ICMP port unreachable packet, you can assume the port is filtered and your packet was rejected.
• If there is no answer you can assume the port is filtered and your packet was dropped.

And UDP???
Because UDP protocol is not connected (no acknowledgment packet) you never know if you get no response because the packet was dropped or because the packet was accepted. However if you receive an ICMP port unreachable packet, you can assume the port is closed.

1.2 Iptables basic settings

Here I will just give simple iptables settings examples.

Deny by default all connections :
iptables -P INPUT DROP
iptables -P OUTPUT DROP

Accept packets from a particular IPv4 address (here 192.168.0.2) :
iptables -A INPUT -s 192.168.0.2 -j ACCEPT

Reject packets from a particular IPv4 address :
iptables -A INPUT -s 192.168.0.2 -j REJECT

Drop packets from a particular IPv4 address :
iptables -A INPUT -s 192.168.0.2 -j DROP

Accept packets on port 22 TCP (SSH) :
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Accept outgoing packets from your port 22 TCP :
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

1.3 Fragmented packet

Tools such as nmap can use evasion techniques to avoid detection from IDS and firewalls. Fragmented packets is one of them and consist in sending several tiny packets instead of one normal size packet.
You can use fragmented packets with nmap using the “-f” option.
Example :
nmap -f -sF -p22 192.168.0.2

Nowadays most firewall and IDS detect fragmented packets, however if you are afraid about those you can brutally get rid of any incoming fragmented packets using the next iptables setting :
iptables -A INPUT -f -m comment --comment "Drop fragmented packets"  --jump DROP

1.4 IP black list

Iptables offer the possibility to create dynamic blacklist. I mean, the possibility to automatically and temporarily ban an IP address (In case of automatic ban, they should be temporary to avoid denial of service ). The “recent” module can be used to check packets and compare them to previously listed packets. You have the possibility to drop these packets according to various characteristics such as IP address, time, TTL, etc.
In Thylacine I create various dynamic blacklists I use to temporarily ban IP addresses involved in port scanning, D.O.S and other attacks.

A practical example, we will create a 3 minutes ban blacklist :
iptables -A  thyl-blacklist -m recent --name blacklist_180 --rcheck --seconds 180 -m comment --comment "Drop packet from IP inserted in blacklist last 180 sec" -j DROP
This will create a blacklist that is located in the /proc filesystem in /proc/net/xt_recent/blacklist_180 (or /proc/net/ipt_recent/blacklist_180 ). You can have a look at the blacklist by doing :
cat /proc/net/xt_recent/blacklist_180
A packet can be automatically dropped and source IP added in that blacklist using the next rule :
iptables -A INPUT <IPTABLES FILTERING OPTIONS> --name blacklist_180 --set -j DROP
You can also manually add an IP address to the blacklist, example :
echo +192.168.0.2 > /proc/net/xt_recent/blacklist_180
To manually remove an IP address :
echo -192.168.0.2 > /proc/net/xt_recent/blacklist_180

We finished with the basic part. You may now read the second part two bellow

Part2 

This is the second part of the article “Iptables firewall versus nmap and hping3”. If it is not already the case you should read the first part : Iptables firewall versus nmap and hping3 : Part1 the basics

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.

II Iptables versus port scan attempts

In this section I will give some tips to set iptables to block various scan attempts. Despite the fact that hping3 can be used to scan, here I will use nmap because it is worldwide known to be THE port scanner.

2.1 Null scan

It consists to scan TCP ports using TCP packets with no flags. Some firewall do not protect against this scan and it can be used to know which ports are closed.
Null scan with nmap example :
nmap -sN 192.168.0.2
Prevent null scan with iptables :
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
How I prevent null scan in Thylacine firewall :

1. # Log attack
2. iptables -A INPUT -p tcp –tcp-flags ALL NONE -m limit –limit 3/m –limit-burst 5 -j LOG –log-prefix “Firewall> Null scan “
3. # Drop and blacklist for 60 seconds IP of attacker
4. iptables -A INPUT -p tcp –tcp-flags ALL NONE -m recent –name blacklist_60 –set -m comment –comment “Drop/Blacklist Null scan” -j DROP

2.2 Xmas scan

Contrary to null scan Xmas scan consists into setting all or almost all of the TCP flags. Xmas attacks can be used to know which ports are closed but, like Null scan you cannot differentiate an opened port from a filtered port (you only receive the RST packet when you touch a closed port).
Xmas scan with nmap example :
nmap -sX 192.168.0.2

To prevent Xmas scans you need to configure your firewall to detect particular flags inside TCP packets.
How I prevent 3 kinds of Xmas scans in Thylacine firewall :

1. # Log attacks
2. iptables -A INPUT -p tcp –tcp-flags ALL FIN,PSH,URG -m limit –limit 3/m –limit-burst 5 -j LOG –log-prefix “Firewall> XMAS scan “
3. iptables -A INPUT -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -m limit –limit 3/m –limit-burst 5 -j LOG –log-prefix “Firewall> XMAS-PSH scan “
4. iptables -A INPUT -p tcp –tcp-flags ALL ALL -m limit –limit 3/m –limit-burst 5 -j LOG –log-prefix “Firewall> XMAS-ALL scan “
5. # Drop and blacklist for 60 seconds IP of attacker
6. iptables -A INPUT -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -m recent –name blacklist_60 –set -m comment –comment “Drop/Blacklist Xmas/PSH scan” -j DROP # Xmas-PSH scan
7. iptables -A INPUT -p tcp –tcp-flags ALL FIN,PSH,URG -m recent –name blacklist_60 –set -m comment –comment “Drop/Blacklist Xmas scan” -j DROP # Against nmap -sX (Xmas tree scan)
8. iptables -A INPUT -p tcp –tcp-flags ALL ALL -m recent –name blacklist_60 –set -m comment –comment “Drop/Blacklist Xmas/All scan” -j DROP # Xmas All scan

2.3 FIN scan

It consists in sending TCP packets with the FIN flag on. Depending on the targeted system you can discover closed ports (other ports are stated as open|filtered), on other system like windows you might not get any answers (it can be use for system fingerptinting too).
FIN scan with nmap example :
nmap -sF 192.168.0.2
Protecting from this scan consists in watching for packets with only fin flag set.

Example in Thylacine firewall :

1. #Log attack
2. iptables -A INPUT -p tcp –tcp-flags ALL FIN -m limit –limit 3/m –limit-burst 5 -j LOG –log-prefix “Firewall> FIN scan “
3. # Drop and blacklist for 60 seconds IP of attacker
4. iptables -A INPUT -p tcp –tcp-flags ALL FIN -m recent –name blacklist_60 –set -m comment –comment “Drop/Blacklist FIN scan” -j DROP

You use these kind of protections for any other kind of scan using abnormal flag settings. Lets have a look at other scan techniques.

2.4 ACK scan

It consists in sending TCP packets with the ACK flag set. In the TCP protocol, this flag is normally set when the packet is an acknowledgment of receipt of another packet. This scan uses the fact that a machine without a firewall will send a RST packet when receiving an acknowledgment of receipt of an unknown connection. The port may be opened or closed it does not matter here.
The thing is, if the port cannot be reached (because there is a firewall protecting it for example), then the machine won’t get the false ACK and won’t send back the RST packet. That means the goal of the ACK scan is to guess if a port is filtered or if it is not. If you combine that with a FIN scan or a XMAS scan you can guess which ports are opened, filtered and closed.
ACK scan with nmap example :
nmap -sA 192.168.0.2

If nmap receive an RST packet port is considered unfiltered, if there is no response, to port is considered filtered.To prevent this scan approach, there are several ways (like always). In the Thylacine firewall I chose to block any attempts of ACK scans, which means the result of an ACK scan displays that all ports are filtered.
There is a very simple way to do that :
iptables   -A INPUT -p tcp ! --syn -m state --state NEW  -m comment --comment "Drop TCP connection not starting by SYN" -j DROP
With this line any new connection must start with only a SYN flag. If it is not the case the packet is discarded. That way, ACK scan is no more possible.
Now you should say, wait a minute! With this only line we could also prevent all the previously mentioned scans! That is true. In the Thylacine firewall I choose another way to prevent these scans because I want these scans to be precisely logged and I want the attacker address to be temporarily banned.

2.5 SYN scan and TCP connect scan

SYN scan is the default scan mode when using nmap and it is also the most used scan technique. This scan method consists in sending TCP packets with only the SYN flag on. Depending on the answer you can guess if the port is opened, closed or filtered (see part I.1).
SYN scan with nmap example :
nmap -sS 192.168.0.2
Because SYN scan is agressive and can be detected by firewalls another more “TCP friendly” method can be used. It is called full connect scan. Instead of just sending a SYN scan and a RST if the port is opened, the full connect scan complete the TCP connection procedure :
1 – SYN is sent
2 – If SYN-ACK is received, ACK is sent
3 – RST-ACK is sent to close the connection.
Connect scan with nmap example :
nmap -sT 192.168.0.2

Preventing SYN scan is difficult for a firewall because starting a connection with a SYN packet is the normal way. Some IDS can use statistics to detect fast and abnormal SYN packets hitting various ports and raise an alert.
In the Thylacine firewall I use a trick against SYN scan. I called that trick “trapped ports”. When you think about it, you never opened all your ports, so imagine that some ports you are sure you do not need are trapped to react against any connection attempted to them…
For example, you know that any port scan attempt will target telnet port (TCP 23). Telnet is obsolete since a few years now and I assume that if you have a minimum security knowledge, you never use telnet. That makes port 23 a perfect candidate for a trapped port. How?

If port 23 receive any open connection attempt (SYN packet), blacklist the distant IP for three minutes!
A practical example now (note in the example I trapped port 23 and 79, you can modify that list and put whatever ports you do not need).

1. # log probable sS and full connect tcp scan
2. iptables -A INPUT -p tcp -m multiport –dports 23,79 –tcp-flags ALL SYN -m limit –limit 3/m –limit-burst 5 -j LOG –log-prefix “Firewall>SYN scan trap:”
3. # blacklist for three minuts
4. iptables -A INPUT -p tcp -m multiport –dports 23,79 –tcp-flags ALL SYN -m recent –name blacklist_180 –set -j DROP

These iptables setting will log and block most SYN stealth scan attempts. However there is a limit, if the attacker is cautious and has some time, he will use very slow SYN scan (a handful of port with one connection attempt every 5 minutes). Our “trapped port” technique won’t prevent that type of scan but the good thing is it will log the connection attempt to the trapped port (with informations like the IP of the attacker), so at least we know something is going wrong.

2.6 UDP scan

Scanning UDP open ports is not easy because UDP is not connected so you do not get any response if the port is open. The normal UDP port reaction when receiving a packet is, if the port is closed, is to return an “ICMP Port Unreachable” packet. If nothing is returned you can suppose the port is opened or filtered by a firewall.

UDP scan with nmap example :
nmap -sU 192.168.0.2
If nmap receives an ICMP Port Unreachable packet port is considered closed, if there is no response, to port is considered Opened/filtered.
In the Thylacine firewall, I use a simple mechanism to prevent UDP scans. When you analyze an UDP scan (nmap scan or default hping3 packet), you can see it does not have any data in it, just the UDP header. This is highly unlikely to happen in the real world where UDP is used by the application layer and carries data (ex DNS, DHCP, streaming, etc.). So a quick way to block UDP scan attempts consist to block all UDP packets with no content.

1. iptables -A INPUT -p udp -m limit –limit 6/h –limit-burst 1 -m length –length 0:28 -j LOG –log-prefix “Firewall>0 length udp “
2. iptables -A INPUT -p udp -m length –length 0:28 -m comment –comment “Drop UDP packet with no content” -j DROP

Note : UDP scan will still be available if data is added in the packet. Example (the port 53 is closed) :
hping3 -c 1 --udp -p 53 192.168.0.2
-> Returns nothing.
hping3 -c 1 --udp -p 53 -d 12 192.168.0.2
-> Returns ICMP Port Unreachable.

This is it for the second part , Port scanning.
You can now read the third part about bellow

Part3

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 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).

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 wiresharkto sniff a normal ICMP echo request packet, save it as a binary file, and replay it using hping3.
Example:
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.

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 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 :

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 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.

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 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 runThylacine beta on your box.