Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This article describes how to fool nmap in it's OS fingerprinting detection.

In short, nmap sends malformed packets to open and closed ports and listens to the responses. Because every OS implements it's own TCP/IP stack, the response can be matched against a database of known signatures and the OS guessed.

The two ways of mitigating this are

  • Patch the kernel source with "stealth patch"

This patch simply discards the TCP/IP packets received with the following matches:

  1. Packets with both SYN and FIN activated (tcp_ignore_synfin) (QueSO probe).

  2. Bogus Packets: if the TCP header has the res1 bit active (one of the reserved bits, then it's a bogus packet) or it does not have any of the following activated: ACK, SYN, RST, FIN (Nmap test 2).

  3. Packets with FIN, PUSH and URG activated (Nmap test 7).

  • Patch the kernel sources with "IP Personality" in order to modify the TCP/IP stack's behaviour in those corner-case situations, emulating another OS (Sega Dreamcast for example)

While the latter approach can have some efficiency/stability issues:

Tweaking those allow to fool a scanner but might break regular connectivity by changing network parameters. It could also make the system weaker if the emulated IP stack is not as strong as the initial one

the former has no drawbacks mentioned.

Why is this not default behaviour. Why do operating systems respond to those packets?

share|improve this question
    
It helps debugging –  copy Sep 5 '13 at 12:10
1  
It's security by obscurity –  symcbean Sep 5 '13 at 16:15

1 Answer 1

up vote 3 down vote accepted

OSes respond to invalid packets because that is very helpful in diagnosing network configuration problems. If you send a packet and nobody answers, you have no idea what happened to the packet: did some router eat it? Was its reply misrouted? Is there a connectivity problem? Or did the target receive the packet but not like it? If the target replies, you know why the packet was rejected, and you get a serious chance of being able to fix the problem.

OS fingerprinting is not a security issue. It's helpful for finding vulnerabilities, but only on systems with unpatched security holes. If you have a system with unpatched security holes, patch them: making your system unrecognizable by fingerprinting will only protect you against a small proportion of automated scans that need to optimize for bandwidth.

OS fingerprinting is a small privacy issue. It's not a major one: most people don't care, for good reason.

Furthermore, eliminating one method of fingerprinting isn't enough: you have to eliminate all methods. So your anti-fingerprinting protection is only good until someone tries another fingerprinting method.

The benefit is small and uncertain. The drawback is major. OS fingerprinting protection should default off.

share|improve this answer
1  
"eliminating one method of fingerprinting isn't enough" - What are alternative methods to fingerprinting an OS? –  Rubber Duck Sep 5 '13 at 12:32
2  
@RubberDuck Though a rather unreliable and ambiguous indicator, the TTL on a ping response can generally give you an idea what class of OS you're dealing with. Ping responses are typically left on for the same reasons Gilles mentions above - to assist with network troubleshooting. Besides that, attackers can still try to probe the ports with seemingly-legitimate connection requests to see what services are active. Systems must properly respond to these, otherwise those services would be unavailable to authorized users as well. On open SSH port? Probably Linux-based. Open RDP port? Windows. –  Iszi Sep 5 '13 at 13:12
    
In the end, the solution to prevent OS fingerprinting, or reduce its usefulness to near-zero, is back in Security Basics 101. Keep your systems patched, only enable essential services, and use firewalls to block incoming connections from unauthorized devices. –  Iszi Sep 5 '13 at 13:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.