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?"
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.
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
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?
* 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.
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
> You need some sort of firewall that doesn't respond to SYN requests on closed ports.
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).
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".
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". ???