Chapter 3: Countermeasures
3.1 OS Fingerprinting Tools Detection
3.1.1 Detecting Nmap
The database of P0f (Zalewski 2004) was investigated, and it was noted that Nmap itself has a fingerprint because of the unique way it sends the probing packets to a target system. It was then thought to use the same tool against the attacker that is used on the target. By this it is meant that one should monitor the packets being received and identify if they come from Nmap. Should the packets come from Nmap then the system should
either drop them or respond appropriately.
As Nmap is not able to determine the OS if it cannot find at least one open port, a system could react to all probes from Nmap as if the port is closed.
Evgeniy Polyakov used the fact that Nmap has a unique signature and combined this with IPtables, to design the OSF (Operating System Fingerprinting) module. OSF can be downloaded from http://tservice.net.ru/~s0mbre/archive/osf/. The OS fingerprints can be downloaded from http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.os.
Evgeniy Polyakov states that this is the best countermeasure for active OS fingerprinting tools such as Nmap. This won't prevent passive OS fingerprinting tools, but a user from the target system would have to connect to the attacker's machine first. The task is rather to block active OS fingerprinting tools.
The procedure to get OSF working is really involved and somewhat complicated for first time users. The Makefile is first edited and the path of the IPtables source files is specified. Once this is done, the source code is built that generates the libipt_osf.ko kernel module. The library file is then also compiled which generates the libipt_osf.so shared library. The kernel module is then installed and the pf.os file is loaded into the /proc/sys/net/osf path. Once this has been done, it can be implemented with Iptables. The installation procedure is described in Appendix D.
Nmap has the fingerprints presented below. The order of the fingerprints are as follows:
<Window Size>:<Initial TTL>:<Don't Fragment bit>:<Overall SYN packet size>: <Options in Order if used>: Nmap scan or OS
1024:64:0:40: Nmap SYN scan 1
2048:64:0:40: Nmap SYN scan 2
3072:64:0:40: Nmap SYN scan 3
4096:64:0:40: Nmap SYN scan 4
1024:64:0:60:W10,N,M265,T: Nmap OS detection probe 1
2048:64:0:60:W10,N,M265,T: Nmap OS detection probe 2
3072:64:0:60:W10,N,M265,T: Nmap OS detection probe 3
4096:64:0:60:W10,N,M265,T: Nmap OS detection probe 4
NAST, another OS fingerprinting tool has got the following fingerprint:
32767:64:0:40: NAST SYN scan
Due to the fact that Windows 2003 has a similar fingerprint to Nmap, it is suggested that the statement for the detecting of Nmap is placed at the end of the IPtables list, therefore allowing communication from Windows 2003. The main options used are --log and --ttl.
The statement used for the blocking of Nmap packets is:
iptables -I INPUT -p tcp -m osf --genre Nmap --log 2 --ttl 2 -j REJECT
The above statement rejects all TCP packets coming in from Nmap.
The firewall settings are shown in Appendix B.3, which were used once the OSF module was loaded. When Nmap was used to fingerprint the OS of the target system, the following output was observed:
linux:/# nmap -O -vv 10.0.0.6
Starting Nmap 4.00 ( http://www.insecure.org/nmap/ ) at 2006-09-15 23:48 SAST Initiating ARP Ping Scan against pc-wvl-6.cs.ukzn.ac.za [1 port] at 23:48
The ARP Ping Scan took 0.01s to scan 1 total hosts.
DNS resolution of 1 IPs took 13.00s. Mode: Async [#: 1, OK: 0, NX: 0, DR: 1, SF: 0, TR: 3, CN: 0]
Initiating SYN Stealth Scan against pc-wvl-6.cs.ukzn.ac.za [1672 ports] at 23:48 Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 5 to 10 due to max_successful_tryno increase to 5
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 10 to 20 due to max_successful_tryno increase to 6
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 20 to 40 due to max_successful_tryno increase to 7
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 40 to 80 due to max_successful_tryno increase to 8
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 80 to 160 due to max_successful_tryno increase to 9
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 160 to 320 due to 11 out of 12 dropped probes since last increase.
SYN Stealth Scan Timing: About 2.82% done; ETC: 00:06 (0:17:22 remaining)
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 320 to 640 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for pc-wvl-6.cs.ukzn.ac.za from 640 to 1000 due to 11 out of 19 dropped probes since last increase.
SYN Stealth Scan Timing: About 65.20% done; ETC: 00:15 (0:09:32 remaining) The SYN Stealth Scan took 1668.84s to scan 1672 total ports.
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Host pc-wvl-6.cs.ukzn.ac.za appears to be up ... good.
All 1672 scanned ports on pc-wvl-6.cs.ukzn.ac.za are: filtered MAC Address: 00:30:18:66:7A:0B (Jetway Information Co.) Too many fingerprints match this host to give specific OS details TCP/IP fingerprint:
SInfo(V=4.00%P=i586-suse-linux%D=9/16%Tm=450B2637%O=-1%C=- 1%M=003018)
T5(Resp=N) T6(Resp=N) T7(Resp=N) PU(Resp=N)
Nmap finished: 1 IP address (1 host up) scanned in 1690.096 seconds Raw packets sent: 1851 (76.1KB) | Rcvd: 1673 (114KB)
As it can be seen from the above output, Nmap was not able to determine the OS running on the target system as it was not able to find an open port.
The file /var/log/messages was investigated, and the following was seen:
Sep 15 11:48:13 linux-xegw kernel: ipt_osf: Windows [.NET::Windows .NET Enterprise Server] : 10.0.0.5:57418 -> 10.0.0.6:716 hops=206
Sep 15 11:48:13 linux-xegw kernel: ipt_osf: NMAP [syn scan:2:NMAP syn scan (2)]
: 10.0.0.5:57418 -> 10.0.0.6:716 hops=15
OSF first thought that it was receiving packets from a Windows .NET Enterprise Server, and then it found that it was receiving packets from Nmap. With the '-j REJECT' option, the system will send ICMP error messages to the attacking system, if ICMP messages are not disabled. It is therefore better to have the line:
iptables -I INPUT -p tcp -m osf --genre Nmap --log 2 --ttl 2 -j DROP
Vmstat was executed when the OSF module was installed and removed, and the following was shown respectively:
procs ---memory--- ---swap-- ---io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 0 400708 47268 451152 0 0 122 31 279 320 8 1 88 3
procs ---memory--- ---swap-- ---io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 421140 43220 436220 0 0 148 34 278 351 10 1 86 3
From this it is seen that with the OSF module installed, less free memory was available, but this could also be due to other programs that are running. The time that was spent running kernel code (in system time) does not differ.
It can be concluded that OSF solves the problem of active OS fingerprinting by Nmap as well as port scanning, and is therefore the best countermeasure found. As the target system logs the IP address of the system performing the scans, the system administrator can block any
further packets received from that system.