anyone know how to deter nmap from finding out such detailed OS fingerprint information on my linux 2.4 box?


Thanks

What's running vs needs to run?

I tend to drop everything unsolicited / don't respond to anything external to the lan (and only "known good" requests inside), but might not be an option for you.

BTW - Nmap will still _nearly_ always give the Linux, kernel 2 dot-something to kernel 2 dot something-higher, it's just less confident about specifics.
(Even if you set your box to drop ICMP, nmap -P0 will show the above - it will just take longer)

Assuming you're not running unnecessary services and have made a decent effort at locking down the box, I wouldn't lose too much sleep about what nmap thinks your OS is.

[edit: Obviously, putting a bog-standard router / any other box as a proxy in front of $target_machine will cloak what it is from the outside world. But I assume you're scanning $target_machine from the lan]

I always feel if they can't talk to in anyway they can't find anything. IE Basically anything that should not be there is dropped externally on my firewall. If internal is the case you might not have that luxury.

--tarballedtux

If you are running anything that requires externally-initiated connections to succeed, then the fingerprinters have a good chance at a correct guess. If you completely lock down your box(es) to only allow outward-bound traffic then passive traffic analysis can still be done on any packets that can be seen externally ( http://lcamtuf.coredump.cx/p0f.shtml ). Trying to hide your operating system is one of the poorer attempts at security through obscurity. If you really must hide your operating system, then you should be looking at the TCP/IP stack. All the fingerprinting is done dependant on the implementation-defined elements of the stack. Change a few of the timings, sizes, etc around and you no longer match a fingerprint - but, this will only stop weak attempts at fingerprinting, determined users can still work it out. Also, realise that the values that are currently in the stack have been chosen because they are deemed to be the most suitable - hence, you may degrade network performance by changing them.

A better solution is to limit or eradicate any network accessable processes. If the remote user cannot interact with a userland process, then they would have to rely on a kernel vulnerability in the TCP/IP stack - which are, fortunately, pretty rare. Then all you need to do is make sure that none of the users with local access use remotely exploitable programs (ie, an MUA with a vulnerability could be abused from someone not on the system).

Also, the biggest thing (though I accuse nobody of it), is to not `stealth' your system and go through all these obscurity measures AND then put `powered by distro-x kern-x-x' on a web page. You might also want to check banners (eg, if OpenSSH just says OpenSSH then you are looking at an OpenBSD box most likely) as they can give a lot away - though be careful, as some banners (ie, SSH and maybe others) are used for `quirks' mode interoperability.

What I have said above is by no means a complete analysis of this area, but hopefully you can see that hiding your OS is often fairly futile.