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

Random IPID is also available for FreeBSD

[questionlp]

If you want to enable random IPID under FreeBSD, add the following line to your kernel configuration file and re-compile your kernel:

options RANDOM_IP_ID

I don't know if it's the same as OpenBSD's random IPID nor if NetBSD or Mac OS X have the option or not... but it worth a try for those running FreeBSD servers.

Re:who cares if you are scanned?

[agnosonga]

The problem is that people will scan other hosts using your IP as a "Zombie" so that it looks like the scan is coming from you
this can get you into trouble REAL fast

Linux 2.4

[Tom7]

Uh, the article you point us to says that Linux 2.4 is not vulnerable to this because it uses peer-specific IPID values. (It also zeros the IPID field when DF=1). Is that not true?

Linux is secure

[tswinzig]

The person posting asks how you can protect Linux computers from malicious idlescanning, since OpenBSD is the only OS he knows of that doesn't use sequential IPID.

However, the document he linked to (!) clearly states, "The latest versions of Linux, Solaris, and OpenBSD are immune as zombies..."

Of course, you can't keep Linux from being scanned by a zombie, but that has nothing to do with the IPID sequencing. You need some sort of firewall that doesn't respond to SYN requests on closed ports.

From the page:

[agnosonga]

* Configure your firewalls/border routers to deny incoming packets with bogus source addresses (eg. that appear to come from machines within your network, reserved IPs like 10.X.X.X or 192.168.X.X, localhost IPs 127.X.X.X, etc. Any good firewall guide should provide more detailed guidance on these essential rules.
* Stateful firewall rules can also help against these sorts of attacks -- make sure your firewall offers this feature and that it is enabled.
* Try to run operating systems with less predictable IP ID sequences, such as recent versions of OpenBSD, Solaris, or Linux. While these operating systems are immune from becoming zombies with the current version of Nmap, they may not stop all IPID-related attacks. Further investigation is needed.
* Implement egress filtering to prevent spoofed packets from leaving your network. This prevents your employees/students from launching some of these attacks.

Stateful firewall

[Permission Denied]

Note: I've never heard of this before, but I do a fair amount of network programming. The article is quite informative, however.

This is pretty easy. Just throw a stateful firewall in front of your Linux boxen. Set it up so that it does not send a RST unless it has a session going. I can show you the appropriate ipfw or ipf rules if you're OK with throwing them behind a BSD box (not too fond of the Linux firewall stuff). You could also run a host-based firewall on the machines, but Linux 2.2 does not do stateful firewalls (and if you were running 2.4, this wouldn't be an issue).

You didn't mention what exactly your Linux cluster does. If it's a computational cluster, throwing it behind a firewall is a no-brainer. OTOH, if it's a server cluster, this might be more difficult.

I can write a kernel patch to do something clever - but this is completely pointless since Linux 2.4 already does peer-specific IPID numbers. I'm guessing you cannot upgrade your Linux cluster to 2.4 (which is perfectly legitimate), so it might be worthwhile to back-port the changes. Perhaps it would be much easier to set DF in all RST packets and simply zero the IPID for packets with DF set - this should be a much easier change, touching much less code than peer-specific IPID numbers. Let me know if anyone wants this, and I should be able to cook something up :)

Re:grsecurity

[fava]

Its called the grsecurity patch and consists of a whole bunch of seperate security enhancements to the linux 2.4 kernel including randomizing sequence numbers and ttl's.

Be careful though, some of the option change the assumed behavior that other programs rely on. For example kde will not run with some of the options.

The patch in included by default in the gentoo kernel but it is up to the user to enable it. The install docs gives a number of recommondations about which options to enable.

Re:How about. . .

[Permission Denied]

This will not work with Linux 2.2 (no stateful firewall) and is not needed with Linux 2.4 (since Linux 2.4 uses peer-based IPID).

I'm guessing the original poster read the article he linked to and that he's looking for a solution for Linux 2.2. This requires a kernel patch.

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.

Uhm, how about READING the article you link to ???

[Eivind]

Hello ! Anybody home ? Any editors here willing to atleast *READ* the article before they link to it ?

This question is completely bogus, infact the very article linked to gives the answers sought in a section apropriately named "Defences".

You claim: 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

This is stupid and wrong, infact the very article you link to says: Try to run operating systems with less predictable IP ID sequences, such as recent versions of OpenBSD, Solaris, or Linux. While these operating systems are immune from becoming zombies

And this is just one of the many lines of defence mentioned in the article. What's the point of sending a question to slashdot, asking a question which is answered (around 10 times !) in the very article you link to....

And editors: Is it REALLY too much to ask for that you bother to read the article before posting the nonsense "story". ???