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