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.
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>
nmap -p22 192.168.0.2
nmap will answer if the port is open, closed or filtered.
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.
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.
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 :
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
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
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 :
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 :
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 :
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).
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.
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
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 runThylacine beta on your box.