> -----Original Message----- > From: Paul Robertson [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 12, 2002 10:50 > To: Noonan, Wesley > Cc: Gary Flynn; [EMAIL PROTECTED] > Subject: RE: Cisco IDS > > On Fri, 12 Apr 2002, Noonan, Wesley wrote: > > > > The ability to DoS the internal network if you can make the switch too > > > busy is the most obvious one- and that can be pretty easy in some > > > scenerios. > > > > Where is that one? How does one DoS a switch that generally has a >3GB > > backplane with traffic that comes from a generally <100MB pipe? > > Historically, "strange" 802.1q packets on Cisco switches have worked do > DoS the switch. Historically, forged spanning tree packets have worked to > DoS the switch. I believe there was also an interesting MAC address > attack using the switch's MAC, but I don't recall the details. The > backplane isn't the issue if you can make the CPU too busy to do its job, > especially if doing so places the device into broadcast mode.
Turn off spanning tree?? You only need it if you have loops. Point made on the CPU (wasn't thinking in that direction). I don't really see it as a real problem though. I would need to see writeups to be convinced that it is a problem, or that the switch would actually start passing traffic. I know what *was* possible, but those problems have been fixed to my knowledge. > > > There've been rumbles of very interesting taged queueing issues > > > (802.1q) for ~4 years now, I highly doubt the DoS attacks Cisco fixed > are > > > the end of that train. > > > > Rumbles don't always mean anything. People have been rumbling about how > > Linux is the next end all be all for years too. Still not seeing that. > > By the same token, rumbles sometimes mean a storm is coming. If you've > some information that gives an assurance that 802.1q issues have been > examined in more significant depth, please present it. Unfortunately, I am in no better position than you in this case. I don't have anything I have found. The whole "DMZ/VLAN" issue is a very hard to find documentation on topic... > Which doesn't say that the same sort of thing won't happen for CDP (and > the product wasn't from a vendor per-se.) The logic "Vendors who make > switches have had issues with longer-lived protocols than the ones their > switches use as a default to do topology related things, and it will > likely happen again" isn't a bad jump. Please cite an SNMP ASN.1 issue > from 10 years ago. The entire recent "issue" with SNMP revolved around *known* issues with SNMP V1 that had existed since it's inception. I would with a guy that sits on the IEEE committee. I have heard *all* too much about this problem as he has scrambled to try to address it... > The FACT stands that switches have traditionally had failure modes that > resulted in every packet going out of every port (historically, for Cisco > the easiest of those was filling up the CAM table- there have been > others and Cisco isn't the only vendor.) Absent evidence that > such failure modes have been changed due to the proliferation of VLANs on > switches, there exists doubt. Your evaluation of the credibility of the > statement is neither here nor there in regards to how it is offered. > Since I SAID "I'm not sure...," it's obviously not completely informed- > which is WHY I said it that way- sheesh. Here's the problem Paul. You present a *lot* of opinion as fact on this list. In fact, you are doing that in the above statement. While there is nothing necessarily wrong with this, you have a perception on this list as someone who is "in the know". That is cool and all, but that sometimes leads to people taking your opinion as fact and then moving forward as if "that's the way it works". That kind of misinformation, intentional or otherwise (and no, I don't think you intentionally do it) is a bad thing. Yes, in the *past* switches could be exploited during a failure by them passing data between VLANs that they shouldn't. I don't know of a single *current* exploit that exists that way though. While it may exist, since no one seems to be able to point it out, much less refer to it with anything or more substance than historic anecdotal evidence, I just think the credibility today is probably not very good anymore. > > > The most important thing though is that a single configuration change > > > completly and utterly destroys your security posture. Think about the > > > last few worms which have gotten to internal networks, add a switch > > > component to the mix and think about how "safe" that architecture is > > > (disallowing remote access to a DMZ-only switch is pretty easy, > internal > > > switches all tend to have IP addresses and SNMP on these days.) > > > > This is true in separate switch environments. > > It is *sometimes* true, however it is possible to engineer multiple switch > environments where this isn't the case, You can do this in a single switch environment *too*. Bad design is not a uniquely VLAN problem. > *and* in a multiple switch > enviornment, unless you're creating one big logical switch by hooking them > directly together, there's a layer 3 device in the middle that will likely > have more security attention paid to it (in the specific example in this > thread it was a PIX) than the switch generally gets- But this is still true with a VLAN switch. > especially when the > switch's maintenance is dictated by any issues on the internal network. Now this is the first point that you might have some validity on (I say might because it is still debatable). Wes Noonan, MCSE/MCT/CCNA/CCDA/NNCSS Senior QA Rep. BMC Software, Inc. (713) 918-2412 [EMAIL PROTECTED] http://www.bmc.com _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
