mailing list archives
Re: Should nmap cause a DoS on cisco routers?
From: "Dobbins, Roland" <rdobbins () arbor net>
Date: Fri, 2 Jul 2010 00:41:23 +0000
On Jul 2, 2010, at 7:01 AM, Dan Kaminsky wrote:
Permanent DoS's are unacceptable even from intentionally malicious traffic, let alone a few nmap flags. They're
unacceptable to us, they're unacceptable to Microsoft (see: MSRC bug bar), and even Cisco PSIRT has shown up on
thread desiring to clean things up.
Again, causing the RP CPU to go to 100% due to punted management-plane traffic isn't a new phenomenon - it's
well-understood amongst network operators, as are BCPs which mitigate the risk of such an occurrence.
Of course PSIRT will ask for details, as they should; my point is that there's likely nothing new to see here, and that
there are mechanisms available to ameliorate either deliberate or inadvertent attacks of this nature.
Even if there is something new, here - which I doubt - it's important that folks understand that there are BCPs they
can implement to protect their network infrastructure devices *right now*, rather than sitting about waiting for code
to drop from the sky, or whatever.
The original poster asked if this were a configuration issue - and the answer is, yes, there are things you can do with
your configuration to harden your network infrastructure against such things.
It's funny you bring up SNMP. Do you remember what happened when that protocol got fuzzed by the PROTOS guys in 2002?
Yes, and the PROTOS vulnerabilities were by and large real vulnerabilities - as opposed to merely saturating the RP of
a given network device with management-plane traffic. Some of them even had the potential for remote code execution.
And many of them could be mitigated via BCPs until such time as fixed code could be deployed, as well.
I will grant you that network isolation is indeed best practice, but broken code is not something to apologize for
The issue as described doesn't sound like broken code, although that's certainly possible (again, would be helpful if
the OP would provide more details, at least to PSIRT).
And I'm not 'apologizing' for anything - rather, I'm pointing out that there are ways to defend one's network
infrastructure against this sort of thing, right now, today, utilizing existing features and functionality built into
most modern network infrastructure equipment.
Roland Dobbins <rdobbins () arbor net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/