Slashdot Mirror
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?"
Microsoft Windows XP
Generate some local traffic that will increment your IPID. The offending scanner will will see that your system is unsuitable.
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.
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.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
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
Just put a machine right after the router that is in coming and put OpenBSD on it and turn on bridging and "srub all on $ext" and you have a great firewall that is transparent to the inside and to the outside.
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?
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?
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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.
"And like that
* 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.
from the obtaining-extra-security dept.
A misnomer. You can't obtain security, you can only remove insecurities.
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 :)
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.
step 1: iptables -P INPUT DROP
step 2: iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
step 3: iptables -A INPUT -j DROP
It's all going according to
I just don't see why this scan is even newsworthy. Yeah, the technique is kinda cool, but the results of a scan or not.
In response to your sig "Why do people hate Muslims?"... Why do Muslims hate non-Muslims, eh?
I realize that not all Muslims hate non-Muslims. You should realize that not all people hate Muslims.
the article mention that some operating system just increase the counter for each connection. my concern is if we use a webserver or any running workstation as a zombie, the server might get/initiate other connection other than to/from the attacker. this will eventually increase the counter.. therefore the result of the probe will become false since the counter will alway gets increased
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.
Yes this can be solved with a firewall. Some other responses have mentioned this. If your being used as a zombie then the first packets you see are SYN/ACK or RST packets.The first packet of a valid connection should only be a SYN packet. If your seeing SYN/ACK or RST as the first packet of a new connection then something fishy is probally going on.So setup some type of decent firewall in front of this cluster (I can't believe you don't have one now) here some ideas from a few rulesets.Start with a default deny policy.
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".
do you mean to say that if I send traffic that makes it look like you're my zombie, I can get you in trouble "REAL fast"?
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.
The number of people I've seen griping about lameness filters is ridiculous.
I wanted to break up stuff into a bulletized list to make it easier to read. The lameness filters wanted more characters per line.
I wanted to include a snippit of source. The lameness filters didn't like it (too many "nonstandard" characters).
Now this person wants to post a tiny patch, and the filters freak out.
I *hate* Slashdot "behavior modification" limits. The "two minutes between posts" rule. The "twenty seconds at least to write a post" rule. The "fifty posts per day rule". I've hit them all, and they're a bloody PITA.
May we never see th
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". ???
The article clearly states that "The latest versions of Linux, Solaris, and OpenBSD are immune as zombies..." so I suppose that if you want to keep using linux, just upgrade to whatever version started being invulnerable to this type of attack.
Move sig!
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.
So apparently this guy doesn't have the same amazing grasp of TCP/IP that your majesty does. Big fucking deal. Plenty of others (who I'm certain know atleast as much as you do) have provided useful, worthwhile information - regardless of the fact that his question might be answered in the article. So what if it is? How many people, who wouldn't have read the article in question otherwise, might now be aware of a potential security threat? Berating the editors is a great idea though. Lets all rant at Slashdot for trying to help a fellow linux user by posting a story that we weren't required to read. That'll help. Good job whistle blower. You've uncovered a major flaw with the community. No more asking questions you don't know the answer to! God I fucking hate know-it-all, pretentious, angry eccentric nerds.
WWU blocks everybody that scans them. They wont even accept telnet/ssh connections unless you are a registered domain
no text
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare