back to article Firewalls snuffed by 'BlackNurse' Ping of Death attack

A code artefact in a number of popular firewalls means they can be crashed by a mere crafted ping. The low-rate “Ping of death” attack, dubbed BlackNurse, affects firewalls from Cisco, Zyxel, and possibly Palo Alto. Since we don't imagine Switchzilla has started giving away the version of IOS running in its ASA firewalls, …

  1. Anonymous Coward
    Anonymous Coward

    Since we don't imagine Switchzilla has started giving away the version of IOS running in its ASA firewalls

    Probably a feature written by the same engineer who has done a tour of Californicatin' merry-go-round around all 4 companies.

  2. Anonymous Coward
    Anonymous Coward

    Nobody expects the Spanish Inquisition

    A failure to check for conditions you didn't imagine could happen.

    Or more generally, check your inputs.

    1. Version 1.0 Silver badge

      Re: Nobody expects the Spanish Inquisition

      It's a firewall - "drop all" should be the default and then only permit what you need. And I don't want no stinkin' IMCP packets.

      1. hmv

        Re: Nobody expects the Spanish Inquisition

        Dropping all ICMP packets regardless of whether they're legitimate or not, is generally a pretty good indicator of someone I don't want to be anywhere near any of my firewalls.

      2. Preston Munchensonton

        Re: Nobody expects the Spanish Inquisition

        It's a firewall - "drop all" should be the default and then only permit what you need. And I don't want no stinkin' ICMP [sic] packets.

        For virtually every firewall, that is the case. But even then, the firewall must inspect these ICMP packets to know that they should be dropped. It's the inspection that triggers the borked condition. In fact, I'm sure things are even worse for some, since they include IPS/IDS features yet seem unable to prevent the DOS condition from starting.

        I've tried it myself on the couple self-built devices that I use (Linux 4.2 iptables & OPNSense 16.7) and neither seem to get borked, even up to 1Gbps (nice to have access to Smartbits).

      3. gnarlymarley

        Re: Nobody expects the Spanish Inquisition

        And I don't want no stinkin' IMCP packets.

        ICMP in IPV6 will not fully function unless you allow for some ICMP packets. MTU communication was moved into ICMP. Therefore, it is a really bad idea to just drop ICMP packets. This is noted if the MTU is not 1500 as expected. IPv6 is built to handle larger MTUs that than.

        Now dropping just the ICMP ping packets and the ICMP ping response packets is a different story. Dropping all ICMP is just saying you do not like TCP on your DNS, where larger DNS responses migrate from UDP to TCP.

        As said by others, straight dropping of packets without a knowledge of what you are truly dropping, is bad for business and gives firewalls a bad name.

  3. Lee D Silver badge

    I had an external penetration test done on the school network that I manage.

    One of the items (apart from "DON'T OFFER WEBMAIL!!!!!!", which was a little stupid) was that pings were enabled.

    Okay, it was marked as "low risk" but I couldn't see what kind of risk results from having ping enabled. They gave me the "Oh, it lets you see if a system is online" junk - well... my port 25 is going to be open, as well as 80, 443, and a bunch of others for necessary services. Are you telling me that hackers run nmap without the -P0 option?

    But the rest of the report was similarly junk as well (apparently, webmail could open me up to brute-force attacks - which I'd accept if they hadn't also said I wasn't vulnerable to such password-guessing attacks as I had an account lockout policy and suitable limiting - they still rated that as HIGH though), so I've basically ignored it. I read through it. I commented each line. I told my boss what junk it was. They agree. Game over.

    But I'm not surprised that more esoteric ICMP packets are a problem if you program abysmally. At worst, though, it's a DoS. And that's not really in our scope to defend against. If we were to defend against all kinds of DoS, we'd spent millions and achieve very little.

    The question is really why nobody has noticed sooner, and why an ICMP packet for "unreachable" sucks up so much resources. You don't want to block those ICMP packets, really, though. That's just papering over the cracks. You need a firmware that doesn't jam up on such simple things because unreachable packets are otherwise saving you from a lot of genuine clients retrying over and over with much bigger packets to try to make a connection that isn't being explicitly refused.

    1. Tom 7

      RE:The question is really why nobody has noticed sooner

      I've written 'throw any kind of shit at the ports program' for penetration testing, having done the same previously for functions when coding, and it interesting to try it. The number of permutations is astronomical - and therefore so is the time required to cycle through all possibilities. So you choose ones to limit the search area. And of course you do this in a stupidly biased way.

      Or you discover this and keep it to yourself for possibly dubious reasons.

    2. storner
      Childcatcher

      I agree with the "(most) pen tests are crap" statement, but you should still consider disabling ping responses. It is trivial to spoof the source of a ping request, so pulling off a DDoS with your host (and many others) being used to flood someone else with ping responses is simple.

      Same reason you don't respond when someone sends a packet for a closed/non-existing service, but just drop it with no response.

  4. Anonymous South African Coward Bronze badge
    Trollface

    Pity Windows firewalls aren't susceptible to this fun... would've loved to kill some windows boxen...

    Brings back memories of Teardrop and the such...

  5. This post has been deleted by its author

  6. Diginerd

    Read the Farkin' RFCs - This is "Normal"

    Type 3 ICMP messages indicate a problem in the Forwarding Plane, and require a "Punt" up the stack to the device's processor to enable it to work out what to do as a result of the message.

    RFC792 (From September 1981) covers ICMP in gory detail...

    The challenge is when the RFC was written, NAT was barely a concept - much less a multi-billion dollar "Firewall Industry".

    General blocking all ICMP frequently causes more problems than it solves. Not least, OSI networks (e.g. The Interwebz) rely on RFC conformance to operate "Correctly", so a more granular approach to risk is usually preferred.

    The classic problem of path MTU was covered in the article, and crops up frequently when ICMP Type 3, Code 4 messages ("fragmentation needed and DF set") are dropped silently by an intermediate device. DON'T do this unless you REALLY know why you're doing it. Your users will thank you.

    Networking is complex to do correctly, but it's essentially collection of interacting logic puzzles.

    A cool sounding name doesn't make this sexy & don't expect huge vendor responses to something "Working as Intended". Mitigation here is a situation specific configuration issue.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like