Protecting Servers From Nmap's Idlescan? 37
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?"
This trick might work (Score:3, Interesting)
Re:This trick might work (Score:2, Funny)
Random IPID is also available for FreeBSD (Score:5, Informative)
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.
My humble opinion... (Score:4, Interesting)
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.
Re:My humble opinion... (Score:3, Insightful)
No -- I mean DON'T relax, you should keep up with the latest threats and remain vigilant. But you can stop worrying about Idlescan.
Re:who cares if you are scanned? (Score:5, Informative)
this can get you into trouble REAL fast
Re:who cares if you are scanned? (Score:1)
that seems dangerous because it means I can waste fascist system administrator time chasing down problems that don't exist.
ports are scanned. lets get over it and find real work for system administrators to do.
Re:who cares if you are scanned? (Score:1)
WWU [wwu.edu] blocks everybody that scans them. They wont even accept telnet/ssh connections unless you are a registered domain
no need to migrate (Score:4, Insightful)
Re:no need to migrate (Score:2)
Linux 2.4 (Score:5, Informative)
SE Linux (Score:4, Interesting)
Re:grsecurity (Score:5, Informative)
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.
Linux is secure (Score:5, Insightful)
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.
Re:Linux is secure (Score:4, Informative)
That won't help either -- to the zombie scanner, your closed ports that don't respond and your closed ports that respond with a Reset will look exactly the same. Not responding to SYNs on closed ports probably doesn't do you much good in general unless you don't have any ports listening (then you will be invisible) or if you just want to be annoying to a port scanner (it will have to wait for timeouts for SYN/ACK).
From the page: (Score:5, Informative)
* 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.
Bad wording (Score:4, Insightful)
A misnomer. You can't obtain security, you can only remove insecurities.
Stateful firewall (Score:5, Informative)
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 :)
PATCH - problem solved (Score:5, Interesting)
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 :).
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.
Re:lameness filters are lame (Score:2)
But these days I am getting the "it's been 16 seconds since your last post" (when it has obviously been HOURS or even a day since my last post). I don't know what crack Slash is smoking.
How about. . . (Score:2, Informative)
step 2: iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
step 3: iptables -A INPUT -j DROP
Re:How about. . . (Score:2)
Re:How about. . . (Score:5, Informative)
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.
Yes this can be solved with a firewall (Score:2, Informative)
With OpenBSD's PF the rule "scrub in on $ext_if all" takes care of these nasty packets. This was mentioned before. With IPF this is taken care of by limiting connections to valid open ports by only allowing SYN packets (flag) to start the connection. It is done with a rule like "pass in quick on interface proto tcp from any to 192.168.0.50 port = 80 flags S keep state"
Any firewall worth its weight will give you the ability to limit TCP packets by flags. Linux's Netfilter does it too. Refer to the post with this. I think it was "iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT".
Uhm, how about READING the article you link to ??? (Score:5, Informative)
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". ???
Re:Uhm, how about READING the article you link to (Score:1, Funny)
Did you even read up about Idlescan? (Score:1)
did you even RYOFA? (Score:2)
Defenses
Fortunately, there are several defenses which can be deployed to prevent most IPID-related attacks:
Network Administrators:
It's nice of you to provide the answer in your question.
Dear Slashdot, YHBT. YHL. HAND. (no text) (Score:2)