Prevent hidden Nmap scanning in Linux
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 efficient of its kind (especially in capable hands). Hidden NMAP scanning is called such because it is unlikely that the system log will record it because uses irregular combinations of TCP packet flags.
However, using the ability of netfilter to check flags in the TCP packet header 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 for the mandatory recording of events in the log. After the LOG target, the packet continues moving along the condition chain (unlike the DROP and ACCEPT targets. Accepted or rejected packets will not be sent for further verification). In this case, a packet that satisfies the first condition will satisfy the second one, according to which it will be rejected. The parameters --tcp-flags ACK, FIN FIN describe a combination of TCP flags. The first list of states (ACK, FIN) lists the flags under test, the second (FIN) lists those that are set. Thus, the condition corresponds to those packets in which there is a FIN-flag, but no ACK. With a normal TCP connection, this combination is not possible, but it is typical for hidden scanning.
')
Conduct an experiment: if you have two Linux systems, select one of them with a target, and on the second run something like
nmap -sF -p1-50 192.168.0.3
(substitute the desired IP address). Nmap will tell you about open ports. If you trace the fate of packets through Ethereal, you will see that FIN packets have reached the goal, and in response, RST and ACK packets were sent. 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 appear in the log (I have this / var / log / firewall). Ethereal will show that FIN packages still reach, but do not receive a response. You can learn a lot from such experiments.
However, using the ability of netfilter to check flags in the TCP packet header 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 for the mandatory recording of events in the log. After the LOG target, the packet continues moving along the condition chain (unlike the DROP and ACCEPT targets. Accepted or rejected packets will not be sent for further verification). In this case, a packet that satisfies the first condition will satisfy the second one, according to which it will be rejected. The parameters --tcp-flags ACK, FIN FIN describe a combination of TCP flags. The first list of states (ACK, FIN) lists the flags under test, the second (FIN) lists those that are set. Thus, the condition corresponds to those packets in which there is a FIN-flag, but no ACK. With a normal TCP connection, this combination is not possible, but it is typical for hidden scanning.
')
Conduct an experiment: if you have two Linux systems, select one of them with a target, and on the second run something like
nmap -sF -p1-50 192.168.0.3
(substitute the desired IP address). Nmap will tell you about open ports. If you trace the fate of packets through Ethereal, you will see that FIN packets have reached the goal, and in response, RST and ACK packets were sent. 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 appear in the log (I have this / var / log / firewall). Ethereal will show that FIN packages still reach, but do not receive a response. You can learn a lot from such experiments.
Source: https://habr.com/ru/post/101817/
All Articles