Protecting Servers From Nmap's Idlescan?

Istealmymusic asks: "Now that Nmap 3.00's idlescan technique is fully documented, thousands of vulnerable NT and Linux hosts on the Internet are being exploited to perform stealthy port-scanning. My employer's Linux cluster was a victim of these attacks; apparently he has been used to perform hundreds of port scans on DDN machines. Needless to say we where contacted by the sysadmin and forced to blacklist the cracker. However, our Linux cluster is still vulnerable to the idlescan exploit from other attackers, and I believe our company has a false sense of security. OpenBSD is the only OS I know of which randomizes the IPID sequence therefore making it invulnerable to the idlescan, but we have neither the time nor urge to migrate to OpenBSD. How can one secure their Linux or NT TCP/IP stack from malicious idlescanning?"

Comments

This trick might work

[mfos.org]

Generate some local traffic that will increment your IPID. The offending scanner will will see that your system is unsuitable.

My humble opinion...

[GreyWolf3000]

OpenBSD is the only OS I know of which randomizes the IPID sequence therefore making it invulnerable to the idlescan, but we have neither the time nor urge to migrate to OpenBSD. How can one secure their Linux or NT TCP/IP stack from malicious idlescanning?

My advice--take the bull by it's horns and migrate if this vulnerability is so important to you. Sketchy patchwork can't always reliably fix this sort of thing, and can lead to a messier situation in the long run, and you'll likely find yourself having less drive and urge to migrate. Otherwise, keep existing setups as simple and locked-down as possible--hence, if a quick-n-easy fix does come up, go for it.

SE Linux

[MBCook]

There are enhancements to the kernel in the form of patches (they are applied by default to Gentoo's kernel) that let you controll all sorts of things in the name of security. If I remember correctly, one of them was to allow random response numbers and other such things. Why not look into that?

PATCH - problem solved

[Permission Denied]

Just for fun, I decided to see how fast I could write this patch (never having examined Linux source code before).

The way I set it up is that RSTs that originate from misdirected SYN|ACK will be sent with a IPID of zero, but other regular RSTs will be sent with incremental IPIDs. This is not the way other OSes do it and it confuses nmap (because IPID will be incremental for most RSTs, but not when receiving a misdirected SYN|ACK). The wise scholar will note that this may open you up for another zombie attack, but it prevents nmap from working (so it stops the kiddies :).

engels% sudo nmap -P0 -p22 -sI 172.16.42.245:7 172.16.42.254
Password:

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Idlescan using zombie 172.16.42.245 (172.16.42.245:7); Class: Incremental
Your IPID Zombie (172.16.42.245; 172.16.42.245) is behaving strangely -- suddenly cannot obtain valid IPID distance.
QUITTING!

This is great fun :)

Here's the patch, against kernel 2.2.22:

Actually, fuck it. I'm spending more time trying to get the god-damned patch past the lameness filter than it took me to write the piece of shit. It's a fucking 24-line patch, but apparently, I must describe the details in slashdot-grammar English instead of C. Jesus.

Reply to this post if you want me to send it to you by mail from some throw-away account (trying to keep some semblance of anonymity).

CALL TO PERL PROGRAMMERS: I need a slashdot anti-lameness-filter filter. I just spent two hours in the bowels of Linux TCP - I'm not up for perl right now.

This keyboard cannot describe how livid I am right now. I AM NOT VERY HAPPY WITH YOU SLASHDOT.