Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Should nmap cause a DoS on cisco routers?
From: Lee <ler762 () gmail com>
Date: Thu, 1 Jul 2010 21:13:51 -0400

Has anyone been able to duplicate the OP's results?  I've been running
nmap on lab routers & nothin's fallen over yet...


The issue as described doesn't sound like broken code,

A while back, we had a few routers that weren't on current software.
They had a tendency to reboot when the security office did their
inventory scan...  No more problems after upgrading the code.

although that's
certainly possible (again, would be helpful if the OP would provide more
details, at least to PSIRT).

+1

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

Right.  But the OP's task was "to discover the SNMP version that our
servers and networking devices use."  so presumably the scan came from
a network that had full access to the routers.  That's a bit harder to
defend against.

Regards,
Lee




On 7/1/10, Dobbins, Roland <rdobbins () arbor net> wrote:

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.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]