August 16, 2010 at 16:30Linux Hidden Nmap Scan Prevention
As you probably know, the NMAP network scanner is designed to scan machines or even entire networks for open ports and it is the most effective of its kind (especially in skilled hands). Hidden NMAP scanning is called such because it is unlikely that the system log will fix it because uses abnormal flag combinations of TCP packets.
However, using the ability of netfilter to check the flags in the header of the TCP packet and write events to the log, you can not only block such attempts, but also register the fact of their presence. Here are a couple of rules:
iptables -A INPUT -p tcp --tcp-flags ACK, FIN FIN -j LOG --log-prefix "Stealth scan"
iptables -A INPUT -p tcp --tcp-flags ACK, FIN FIN -j DROP
The first rule is to record the event in the log. After the LOG target, the packet continues to move along the chain of conditions (unlike the DROP and ACCEPT targets. Accepted or rejected packets will not go for further verification). In this case, a packet satisfying the first condition will satisfy the second one, according to which it will be rejected. Parameters --tcp-flags ACK, FIN FIN describe a combination of TCP flags. The first list of states (ACK, FIN) lists the flags to be tested, and the second (FIN) lists those that are set. Thus, the condition corresponds to those packets that have a FIN flag but no ACK. With a normal TCP connection, this combination is not possible, but typical for covert scanning.
Conduct an experiment: if you have two Linux systems, select one of them as a target, and on the second run something like
nmap -sF -p1-50 192.168.0.3
(substitute the desired IP address). Nmap will inform you of open ports. If you trace the fate of packets through Ethereal, you will see that the FIN packets have reached the goal, and RST, ACK packets have been sent in response. Now add the two rules shown above on the target system and try again. You will see that Nmap no longer detects open ports, and new messages have appeared in the log (I have it / var / log / firewall). Ethereal will show that FIN packets still arrive, but do not receive a response. You can learn a lot from such experiments.
However, using the ability of netfilter to check the flags in the header of the TCP packet and write events to the log, you can not only block such attempts, but also register the fact of their presence. Here are a couple of rules:
iptables -A INPUT -p tcp --tcp-flags ACK, FIN FIN -j LOG --log-prefix "Stealth scan"
iptables -A INPUT -p tcp --tcp-flags ACK, FIN FIN -j DROP
The first rule is to record the event in the log. After the LOG target, the packet continues to move along the chain of conditions (unlike the DROP and ACCEPT targets. Accepted or rejected packets will not go for further verification). In this case, a packet satisfying the first condition will satisfy the second one, according to which it will be rejected. Parameters --tcp-flags ACK, FIN FIN describe a combination of TCP flags. The first list of states (ACK, FIN) lists the flags to be tested, and the second (FIN) lists those that are set. Thus, the condition corresponds to those packets that have a FIN flag but no ACK. With a normal TCP connection, this combination is not possible, but typical for covert scanning.
Conduct an experiment: if you have two Linux systems, select one of them as a target, and on the second run something like
nmap -sF -p1-50 192.168.0.3
(substitute the desired IP address). Nmap will inform you of open ports. If you trace the fate of packets through Ethereal, you will see that the FIN packets have reached the goal, and RST, ACK packets have been sent in response. Now add the two rules shown above on the target system and try again. You will see that Nmap no longer detects open ports, and new messages have appeared in the log (I have it / var / log / firewall). Ethereal will show that FIN packets still arrive, but do not receive a response. You can learn a lot from such experiments.