Chapter 3: Countermeasures
3.2 Final Countermeasures
3.2.5 Conclusion
The most effective ways to prevent OS fingerprinting on a Linux system have just been discussed. Recall that they are:
● Modification of the Type of Service field.
● The installation of the OSF module.
● Disabling port 0 communication.
● Blocking certain ICMP messages.
We will now conclude the findings from this project.
Recall that the first contact with a target system is through port scanning.
This activity involves searching for open ports as well as determining the operating system running on the target. The supplying of inaccurate information at this stage of the attack, could be useful to prevent the target system from being compromised any further.
IPv4 and OS fingerprinting were investigated and tests were performed to determine how secure the default installation of Suse 10.1 Linux operating system can be configured. It was found that the default installation of Suse 10.1 Linux was not that secure in terms of port scanning and active OS fingerprinting.
IPv6 was investigated and it was found that this is a solution, as Nmap does
not support OS fingerprinting in IPv6 at this stage. Since IPv6 is not going to be used worldwide for some time, it was then decided to investigate OS fingerprinting in IPv4.
It was initially thought that modifying the TCP/IP stack will prevent active OS fingerprinting after the techniques for OS fingerprinting were investigated. A number of OS fingerprinting tools were investigated, such as Nmap, Xprobe2, Strobe, SAINT, QueSo and NetworkActive Port Scanner and it was concluded that the best tools available are Nmap and Xprobe2.
Xprobe2 was relatively easy to deceive, and it relied on the ICMP messages it received from the target system. Nmap on the other hand was not that easy to deceive, due to the fact that it has such a large database of fingerprints, and should an alteration be made to the TCP/IP stack, this modified fingerprint could simply be added to Nmap's database. The fields in the TCP/IP stack that was modified to try and deceive Nmap were the TOS field, the IP TTL value, the TCP Window Scaling and the timestamps.
Other techniques to deceive OS fingerprinting tools, especially Nmap, were investigated. It was then decided that the technique that is being used against the target system is also to be used against the attacker. This is done by using the fingerprint of Nmap to identify any packets coming from it. All packets that are received from Nmap are simply dropped. This does not only prevent OS fingerprinting against the system but against port scanning as well.
This countermeasure is taken to be the best because when any new types of OS fingerprinting tools become available, it's fingerprint then can simply be added to the database. There were some OS fingerprinting and port scanning tool such as QueSo that was able to perform a fingerprint of the target's OS.
In the cases that Nmap performed a scan against a target system, it was
noted that it could not pin-point the OS running on the target. The attacker should be able to identify that the target system has detected a scan that is being performed against it and is blocking the scan. It should also be obvious to the attacker that a module such as OSF is present when it is known that a system has an open port, and a scan cannot be performed. It was found that with the installation of the OSF module, the CPU was not affected with processing overhead.
Nmap can, however, do an OS fingerprint of a system when the data length of the packet is changed. This is a weakness of the OSF module. To counteract this vulnerability, the OSF module should increase the TCP/IP analysis of more fields compared to the few fields currently observed.
An attacker will first try to perform a normal Nmap scan, and only when s/he identifies that a module such as OSF is blocking the packets, will the data length of the scanning packets be changed. The OSF module can be extended so that when it detects an Nmap scan, it replies with a fingerprint of either another OS or another network component, such as a printer or a router. It can be suggested that workstations return a printer's fingerprint, the attacker might become suspicious if a public web server returns a fingerprint of a printer, and will be able to know that the attacks are being counteracted. Therefore it is suggested that servers connected to the Internet return the fingerprint of another OS. There are programs and modules that could do this, but this could be added to the OSF module.
Other countermeasures were also investigated, and it was found that the TOS field in the Linux TCP stack should be set to 0x00 instead of the default 0xC0, which is mostly unique to Linux. Other suggestions are that all packets with a source or destination port of zero be dropped, and that certain ICMP messages leaving the system be blocked. The firewall to the network should also monitor the packets coming in and going out of the network. Packets must have legitimate fields and the source and destination addresses must be valid for the respective network.
With the above suggested countermeasures, it can be concluded that if they are implemented on a system, it will make a system considerably more secure against active OS fingerprinting using currently known techniques.