> 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] < ch...@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/