Yeah. I'm not the guy needing "clueing in", but I think that you are. This isn't beating a dead horse, this is an entirely different and new horse that has nothing what-so-ever to do with the dead one.
In case you missed it, and it is clear you did, I NEVER PRESENTED ANY POSITION ON THE SUBJECT OF VLANS IN A DMZ, PRO OR CON. In fact, I made it PERFECTLY CLEAR that I generally recommend the use of HUBS in DMZ's, not switches and not switches with VLANs. What I did do is ask for people to present *factual* evidence about the supposed problem, which no one could beyond historical (and long since patched), situations. In fact, you still don't seem to be able to refer to any timely information on the subject, including this exploit (which you completely misconstrue). Just to further clarify the FUD that you, Ron, seem to like throwing around in regards to VLANs, read the exploit again. It's a single VLAN exploit, not a multiple VLAN exploit. The data is being flooded to all ports on a single VLAN - not from one VLAN to another. As a result, this would happen with a single switch and a single VLAN in place (which is, oddly enough, exactly what the bug report states). What's more though, the problem does not occur what-so-ever when using the default VLAN (and since 99% of single VLAN implementations use the default VLAN, that further underscores the insignificance of the problem). In fact, the scenario defined makes it explicit that this is a "Single VLAN" (see the environment section for clarification of this point) problem, which does NOTHING to bolster your VLANS and DMZs statements. If anything, it further underscores that you can not present real credible reasons to not use VLANs for DMZ purposes, but must instead rely on FUD and misinformation to try to make your point. Me thinks you need to read up on how switches and VLANs work, and more so, you need to make sure you understand the problems and exploits before you go speaking about them. Heck, even this bug report makes it clear that there is no known exploit, and anyone who knows anything about switches can clearly see that, while this certainly should not be happening, the end result is nothing more than the switch acting like a hub in the given circumstances. While I appreciate the point, however incorrect and misguided, that you are trying to make, I fail to see how this exploit does anything to bolster the previously mentioned and discussed "packets traversing VLANs" exploits that you dredge up from history. Awaiting your response, and please try to make sure there is some validity in it before you post it. Wes Noonan, MCSE/CCNA/CCDA/NNCSS Senior QA Rep. BMC Software, Inc. (713) 918-2412 [EMAIL PROTECTED] http://www.bmc.com > -----Original Message----- > From: Ron DuFresne [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 16:25 > To: [EMAIL PROTECTED] > Subject: beating dead horses: Catalyst 4000 VLAN issues > > > > Hating to beat dead horses, but, feeling folks trusting VLANs as secure > should be clued there remain issues <Wesley? (grin) you out here?>: > > ---------- Forwarded message ---------- > Date: Mon, 20 May 2002 09:38:25 -0700 > From: "COULOMBE, TROY" <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: Catalyst 4000 > > Issue: > Unicast packets flooded out switch ports they shouldn't be. > > Platform: > Cisco Catalyst 4000 > > OS: > 5.5.5; 6.3.5; 7.1.2; probably all others > > Environment: > Single VLAN, non-default "VLAN 1"; No Spanning Tree; 10/100 48 port > blades. > NO SPAN session is created. > Using a sniffer to capture broadcasts/multicasts, etc only. > > Vendor, Vendor Notified, Date Notified: > Yes, Cisco, 04/10/2002; case C579249, no fix supplied > > Detailed description: > Middle of a TCP conversation, unicast packets sent to a host are > flooded out all ports. > > Using a sniffer [EtherPeek NX for Windows, NAI Sniffer Pro], the > Cat4006 floods TCP packets out > to all ports. Packets captured are unicast-mac and are not destined for > the > port the sniffer is on. > No SPAN session is created on the switch; only broadcasts/multicasts and > _initial_ session packets should be > flooded. Sniffer is on a different port than the workstation and servers. > > Given: > It is understood that if the switch doesn't know where a MAC is, it > will flood the packet out all > ports until the MAC is learned, and the CAM table is populated. Initial > TCP > packets are also captured by the > sniffer, however, these packets would be indicated by the "SYN" flag, and > are considered normal. > > However, what is happening, is that TCP session packets are being flooded, > although the switch _should_ have learned > the MAC. > > Example: > > 01) workstation --> DNS server > UDP DNS request packet > 02) workstation <-- DNS server > UDP DNS response packet > 03) workstation --> Server > Initial TCP SYN packet > 04) workstation <-- Server > TCP SYN-ACK packet > 05) workstation --> Server > TCP ACK Packet > 06) workstation <-- Server > TCP Packet W > 07) workstation <-- Server > TCP Packet X > 08) workstation <-- Server > TCP Packet Y > 09) workstation <-- Server > TCP Packet Z > > Packet #01 is _not_ seen by the sniffer, and rightly so, assuming the > switch > knows the MAC entry for the DNS server. > > Packet #02 is seen by the sniffer, but shouldn't have been. The switch > should have learned the workstation's MAC > entry from packet #01. > Packet #03 is _not_ seen by the sniffer, and rightly so, assuming the > switch > knows the MAC entry for the Server. > > Packet #04 is seen by the sniffer, but shouldn't have been; no matter > what. > The switch now has had 2 different packets > from the workstation to learn it's MAC. > > Packet #05 is _not_ seen by the sniffer, and rightly so... > > Packet #06 through #09 are seen by the sniffer, but shouldn't have been! > > Packet #10 is assumed to be an "ACK" from the workstation and suddenly the > switch registers the workstation's MAC. No > additional packets are seen for _this_ conversation. > > > I have captured telnet sessions, ftp sessions, etc; with a portion of a > telnet session's password visible. There is no > special setup required to see this other than physical Ethernet connection > & > sniffer software. > > Exploit: > Patience > > Workaround: > Setting the CAM agingtime to a larger time _helps_ but does not > completely eliminate the problem. "set cam agingtime xx 14400" where xx is > VLAN #. > Still waiting on an official fix from Cisco.. > > > Thanks, > Troy Coulombe > > > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > For Account Management (unsubscribe, get/change password, etc) Please go > to: > http://lists.gnac.net/mailman/listinfo/firewalls _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
