> -----Original Message----- > From: Ron DuFresne [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 20:11 > To: Noonan, Wesley > Cc: [EMAIL PROTECTED] > Subject: RE: beating dead horses: Catalyst 4000 VLAN issues > <snip> > > <chuckle> Damn! <we are awaiting to see how many broked content scanners > are going to go nuts here, sicne it's already demonstrated that 'bitch' is > so offnesive to so many> It's getting to easy, not even a challenge > these days, to get a rise outta ya <grin>.
It's really simple Ron. I don't like it when people attribute statements to me that I never made. I didn't like it the first time that it was done, and I don't like it now. It is bad enough to happen, but it is worse when it occurs on a public list. I decided that, after trying to explain it to you the last time didn't work, I would try a different tactic this time. It would appear as though I got your attention this time around. > Yet, I tend to think that it remains a mistake to ignore historical > reference, see below; Certainly this is no worse than making the mistake of misunderstanding the implications of something and reacting based on that misunderstanding. <snip> > > Does this imply that all other VLAN implimentations are not vulnerable? > Perhaps, perhaps not, it may well remain to be seen. So how about you wait to proclaim that other VLAN implementations (spell checker in Outlook is a good thing) are vulnerable until you know that, or do you always jump to conclusions? > Yet, on a historical note, the fact that this is *normal* traaffic that is > passing, no exploit required nor intended for this to happen, makes one Uhh... Ron... this is what switches do when they don't know the port the destination MAC address is on. Passing the traffic isn't the problem. The switch losing the port to address mappings is. Come on, I know you are smart enough to figure this out. > wonder how secure any VLAN setup is under harsher condistions. It doesn't make you wonder how secure VLAN setup is, it makes you wonder how secure switches are... then again, if someone is implementing a switch solely for security, they are a fool. > Additionally, there is a strong hint there that this might well be tied to > older exploitable conditions; i.e. cam table flooding and MAC address > spoofing. Strong hint? No hint. There is nothing in the report that implies this, even remotely. Nothing in the cam table is being flooded and nothing is spoofing MAC addresses. > <quote> > > 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 #. > > </quote> Read up on what "set cam agingtime" does Ron. > This report makes it clear no exploit is needed, not that one needs to be > written up: > > <quote> > > ... > > However, what is happening, is that TCP session packets are being flooded, > although the switch _should_ have learned > the MAC. Correct. This is the only problem. The switch *should* have learned the address. That is the *only* problem. Nothing to do with passing traffic between VLANs, nothing to do with buffer overflows, nothing to do with spoofing, simply the switch should have learned the address mappings and didn't. > ... > > 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. Uh, Ron... this is how Ethernet (among pretty much every other shared media topology) works. Maybe you should go tell the IEEE that this is occurring and ask them to change the 802.x specifications. See, this is a symptom Ron. Good troubleshooting dictates that you don't waste time on symptoms (flooding unknown data), but rather you address the problems (why is the switch losing the mapping) directly. The worst thing about this issue though, is that the guy who reported the problem seems to understand perfectly well what is going on... it's just when amateur hacks get involved that things start getting confused and convoluted... <snip> > > I think what was presented in the advisory is enough to ake all secrurity > related implimentations of VLAN/DMZ etups suspect, And why again would you think this, when the "problem" has nothing to do with traffic traversing a VLAN? Having uninformed opinions is not a good practice. Making recommendations to others, based on those uniformed opinions is even worse. > until at least cisco > comes up with a fix. Of course, this does not speak to the > implimentations of other switch vendors, of which there are some. > You do get that this issue only occurs on a single VLAN, yes? IOW, as long as you have a switch with a single VLAN (not default VLAN1), this is a problem. If you use VLAN1, this isn't a problem. If you use multiple VLANs, the problem only occurs on the individual VLANs, no cross VLAN traffic gets passed. > > <chuckle> You get so 'cute' when yer fingers get all red pounding out > frustrations! > And you sound so old and bitter when you lose the technical ground on which your flawed opinions are based. Unless you have something new and productive to add, I am done with this subject, and you. I think that I have made it abundantly clear that you are talking out of your ass on this subject, and that was my goal. I also wanted to make it painfully clear that what you were attributing to me was a load of crap, and I think I did that as well. Case closed. _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
