Slashdot Mirror

← Back to Stories (view on slashdot.org)

Protecting Servers From Nmap's Idlescan?

Posted by Cliff on from the obtaining-extra-security dept.

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?"

17 of 37 comments (clear)

  1. This trick might work by mfos.org · · Score: 3, Interesting

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

  2. Random IPID is also available for FreeBSD by questionlp · · Score: 5, Informative

    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.

  3. My humble opinion... by GreyWolf3000 · · Score: 4, Interesting
    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.

    --
    Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
    1. Re:My humble opinion... by Rick+the+Red · · Score: 3, Insightful
      Or, just get a humble P90 box with two network cards and make an OpenBSD firewall. Just use it to pass all traffic through. You need few if any rules, you won't need NAT, or dhcpd or bind or anything. Just a small IPID randomizer between your current setup and the big, bad internet. If you can put it in or take it out without affecting anything, then it's configured correctly. Test it with Nmap to prove it works, then relax.

      No -- I mean DON'T relax, you should keep up with the latest threats and remain vigilant. But you can stop worrying about Idlescan.

      --
      If all this should have a reason, we would be the last to know.
  4. Re:who cares if you are scanned? by agnosonga · · Score: 5, Informative

    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

  5. no need to migrate by norwoodites · · Score: 4, Insightful

    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.

  6. Linux 2.4 by Tom7 · · Score: 5, Informative

    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?

  7. SE Linux by MBCook · · Score: 4, Interesting

    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.
  8. Linux is secure by tswinzig · · Score: 5, Insightful

    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 ... he's gone."
    1. Re:Linux is secure by Tom7 · · Score: 4, Informative

      > 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).

  9. From the page: by agnosonga · · Score: 5, Informative

    * 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.

  10. Bad wording by ActiveSX · · Score: 4, Insightful

    from the obtaining-extra-security dept.

    A misnomer. You can't obtain security, you can only remove insecurities.

  11. Stateful firewall by Permission+Denied · · Score: 5, Informative
    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 :)

  12. Re:grsecurity by fava · · Score: 5, Informative

    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.

  13. Re:How about. . . by Permission+Denied · · Score: 5, Informative
    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.

  14. PATCH - problem solved by Permission+Denied · · Score: 5, Interesting
    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.

  15. Uhm, how about READING the article you link to ??? by Eivind · · Score: 5, Informative
    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". ???