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. > > 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. > > I wouldn't put money on either spanning tree or Cisco Discovery Protocol > > not > > having a problem or two even this late in the game (heck SNMP has been > > around for ever and the last round of stuff *only* looked at V1 of the > > protocol.) > > This is a bad jump of logic. The SNMP "stuff" has existed and been *known* > for over 10 years. It's only when a vendor came out with a product to scan > for the vulnerabilities that they suddenly became issues. 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. > > I'm not sure how the "fill up the CAM table" thing works these days, but I > > doubt that the default "broadcast on every port" logic is completely > > ripped out of the switch code for each set of things that would ever > > trigger it. > > You are making an uninformed statement here. Either it is, or it isn't but > saying "I doubt" isn't really a credible statement in this context. 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. > > 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, *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- especially when the switch's maintenance is dictated by any issues on the internal network. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
