full-disclosure - Re: Should nmap cause a DoS on cisco routers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 1 Jul 2010 21:13:51 -0400
From: Lee <ler762@...il.com>
To: "Dobbins, Roland" <rdobbins@...or.net>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Should nmap cause a DoS on cisco routers?

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@...or.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@...or.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/