Re: Should nmap cause a DoS on cisco routers?

[Christian Sciberras <uuf6429 () gmail com>]

> I've noticed that even if the orginazation has a
very capable security staff
> Again,  it's a environment that's 'magical' and not well
understood so once it's 'working',  don't touch anything!

If you call that "capable security staff" I'd expect you to call Windows a
"unix-like" os...

> typo in your Perl script, and your network is gone, even if the
Simple, Perl is quite difficult to maintain. If you can't maintain it and
understand it very little, *then DON'T use it*.


On Fri, Jul 2, 2010 at 12:54 PM, Champ Clark III [Softwink] <
champ () softwink com> wrote:

> On Fri, Jul 02, 2010 at 09:45:20AM +0000, Florian Weimer wrote:
> > > On Jul 1, 2010, at 11:12 PM, Florian Weimer wrote:
> > > > And it's certainly a bug worth fixing.
> > >
> > > I doubt it's a 'bug' which can be 'fixed', just the same as sending
> > > enough legitimate HTTP requests to a Web server to bring it to its
> > > knees isn't a 'bug' which can be 'fixed', but rather a DoS which
> > > must be mitigated via a variety of mechanisms.
> >
> > I was referring to single-packet (or single-request) crashers.
> > Reputable vendors still ship devices that have those bugs in 2010.
> >
> > Chances are that Shang Tsung's nmap run triggered one of those.  As I
> > wrote, it happened before.  The nmap command line posted further
> > uptrhead does not actually cause a high pps flood.  Such level of SNMP
> > scanning is quite common in enterprise networks because some printer
> > drivers use it to locate printers, so your network devices are better
> > prepared to handle that.
>
>         One environment that I've noticed this is 'acceptable',  in the
> eyes of the network management,  is VoIP installations.   I've done
> assessments in several large scale,  production level VoIP installations
> and in many cases,  you'll run into the same potential DoS when using
> tools like nmap.   I've noticed that even if the orginazation has a
> very capable security staff,  in many cases,  they don't get to touch
> the VoIP network due to it's 'magical' properties (IMHO).   I won't
> even go into the obvious lack of security practices (no IDS/IPS,  very
> out of date systems, etc) in such networks due to the 'magic' of these
> networks.
>
>        It sometimes seems that no matter how lightly you try to
> tread,  you'll find these things.   Be it due to the lack of security
> within
> the network or a actual vendor problem.
>
>        I've seen this across the board.  Cisco,  Avaya (Nortel)
> installations down to out-of-date Asterisk based installations.
>
>        In one case,  we found a potential DoS condition with a vendors
> product.  Getting the vendor to look into it was no problem.  Getting
> the _client_ to work with the vendor on addressing the issue was a
> complete pain!  The response from the client was,  'just don't run
> any scanners (nmap included) within the network'.   Yes,  put that
> in the /etc/motd so that attackers know not to do that :)
>
>        Somehow,  I don't find that acceptable.
>
>        Again,  it's a environment that's 'magical' and not well
> understood so once it's 'working',  don't touch anything!
>
> > And even if you applied control plane protection, you still need to
> > monitor those devices from your management network.  The brittleness
> > described in this thread makes this an extremely risky endeavor: one
> > typo in your Perl script, and your network is gone, even if the
> > monitoring station never had the credentials for enable access.
> > Those bugs might not be security-relevant, but they can be very
> > annyoing nevertheless.
>
>         Couldn't agree with you more.  _When_ and _if_ they apply
> control plane protection.  I don't know what the rest of the lists
> experience is with VoIP networks,  but in many cases they seem to
> be stuck in the way-back-machine in reguards to network security.
> Not always,  but a heck of a lot.  Accidental 'DoS' conditions seem
> to pop-up a lot in these environments,  IMHO.
>
> --
>        Champ Clark III | Softwink, Inc | 800-538-9357 x 101
>                     http://www.softwink.com
>
> GPG Key ID: 58A2A58F
> Key fingerprint = 7734 2A1C 007D 581E BDF7  6AD5 0F1F 655F 58A2 A58F
> If it wasn't for C, we'd be using BASI, PASAL and OBOL.
>
> _______________________________________________
> 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/