Dear All: Mr. DuFresne message and the various replies harken back to my Fall 2000 topic (Proper architecture for firewalls connected to switches) which is summarized at http://archives.neohapsis.com/archives/firewalls/2000-q3/1418.html. Specifically, I stressed my view that to prevent a compromise of a firewall's protection, its ports should be connected to physically separated media. That media can be hubs, switches, or actual cabling. In any case, with full physical isolation, a failure of the external media will not produce a bypass of the firewall.
Respectfully yours; Marc Mandel At 12:06 AM 05/22/2002 -0500, Wesley Noonan wrote: > > -----Original Message----- > > From: Ron DuFresne [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 21, 2002 23:00 > > To: Noonan, Wesley > > Cc: [EMAIL PROTECTED] > > Subject: RE: beating dead horses: Catalyst 4000 VLAN issues > > ><snip> > > Who got who's attention? > >Oh, no doubt you got mine. As I said, I don't like people misrepresenting my >statements. You are no exception to this. > > > Like it or not, you non-stance on the issue in > > fact is a stance. > >Fine, here is my stance. > >1) Use hubs. They are cheap and it makes it easy to sniff all the traffic on >the DMZ. I like that for things like IDS implementation. >2) If making it easy to sniff all the traffic on the DMZ is a security >issue, then use switches. Cheaper the better. Don't get manageable switches >unless you need them. >3) If you do use a switch, refrain from using VLANs that include any part of >the internal network. Multi-DMZ VLANs aren't as high a priority to me, >though if I had my druthers I wouldn't use them either. While there are no >current issues related to traffic hopping VLANs (thanks to Ron and Paul for >making this point clear), it has happened before (again, thanks to Ron and >Paul for making this point clear), so why create a design where you need to >worry about it? Follow the KISS principle, which states that physically >separate switches are easier to maintain and manage in a DMZ environment >than VLANs are. Simplicity of design can often be a security measure in and >of itself. > > > Your rejection of historical issues is a stance. > >I never rejected historical issues. I rejected the crap you produced as fact >when you couldn't prove or support any of it (OK, you were able to back up >ONE thing which was valid at one point in time in regards to VLANs and >DMZs). > >I am doing the same thing with this issue as well. Even now, you take a >completely unrelated issue, and try to make it sound like it is in some way >relevant to VLANs and DMZs. They are so not related to each other, it's >pathetic. Just because a bug report uses the term VLAN, doesn't mean that it >has something to do with your "VLANs and DMZs are evil" quest. On a side >note, you would probably have a lot more success with your position if you >left the speculation and rhetoric to the side, and stuck with simple concise >facts. A number of other folks on this list did a masterful job of summing >the issues and reasons for/not for using VLANs with DMZs when they left the >FUD at the door. > ><snip> > > > > > > > The switch was *not* doing what it was supposed to do, it was working > > proper, then not then working proper then not, it was fading in and out > > intermittently, often mid tcp stream; > > ><snip> > >But Ron, flooding the packets isn't the problem, no matter how hard you want >to make it the problem. Flooding the packets is *by design*. > > > > 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. > > > > > > > agreed! which includes VLAN segments in a security setting, which is > > after all what a DMZ is... > >Which *may* include VLAN segments... > ><snip> > > > > > > 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. > > > > > > > had learned the MAC address it would seem, afterall it found a > > destination, then the switch *forgot* what it had learned, and a number > > of times the posting indicated, this was not a pre-learning issue, nor > > was it a one time issue, it seemed to be indicated this was an issue that > > popped in and out. > >Sure, it appears that the switch learns, then forgets. When it forgets, it >can do nothing other than flood. Do you understand this point? The flooding >isn't the problem, it's the symptom. The problem is the switch forgetting. > ><snip> > > > > Ahh, yes, ethernet, but, this was *not* an issue at all related to 802.x > > specifications. It was a failing of the switch to deal with ports > > properly. > >Wrong, it is a failing of the switch to deal with it's port to MAC address >filtering properly. When that occurs (switch doesn't know what port the >destination is on), per basic switch design, the switch defaults to standard >Ethernet rules and function. IOW, it acts like a hub, flooding packets to >all ports. Do you really not get this? I have been pretty snotty with you >about it because, well... because I figured you had to know this and you >were simply being an ass about it and I know you have thick skin. The more I >read though, the more I am wondering if you really don't know this about >switches, and rather than taking cheap shots at you, if I should be trying >to teach you how it works... You understand that switches flood data to >ports if they don't know what port the destination is on, right? This isn't >a bug, it's an intentional design. If you want more info, I will be happy to >provide it, seriously. > > > the packets went where they were not supposed to go, the > > switch failed, it's VLAN setup failed. > >What??!?! Where does it say the VLAN setup failed? At what point does it say >anything other than "the traffic floods to all ports on that VLAN". The VLAN >has nothing to do with the problem, beyond the fact that the problem does >not occur if one uses default VLAN1. The VLAN is simply an environmental >variable. > > > Where was it mentioned that the > > port sniffed was setup to read all traffic flowing across the switch, I > > think it was pretty clear this was not the setup in question. > >And this is in response to what? There is no dispute about where the sniffer >is located. You are really reaching here. > > > > 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. > > > > > > > Yet, it was traversin ports it was not ment to. > >Wrong, but running with your statement, traversing ports <> traversing >VLANs. Read up on how switches work. Besides, in the situation given (the >switch does not know what port the destination is on), the switch is >actually behaving EXCACTLY like it should. The problem has nothing to do >with the passing of data to other ports - this is intentional and by design, >and everything to do with the switch losing that port to MAC address mapping >in the first place. > > > If the switch is failing > > so, what makes one presume the switch has only those problems? > >So this is the heart of your position? If a switch has this problem, who >says it doesn't have others? Give me a break Ron. Hell, under that logic, >you can pick apart anything that has ever been exploited. Might as well go >back to using sneakernet and slide rules (rulers? hell I'm too young to know >and too lazy to look it up). > > > The VLAN > > in qustion failed to function as it was supposed to do, who knows what > > other issues it has, I'm sure you might well agree. > >No, I wouldn't. The VLAN has nothing to do with the problem, aside from the >circumstance that permits the problem to occur (only happens on a VLAN other >than VLAN1). The VLAN didn't fail to function as it was supposed to. The >more you hammer on this, the more clear it becomes that, while you may know >firewalls and Unix, you are really lacking in understanding of switch design >and function. > ><snip> > > > > It has in the past, so, seeing issues of port hopping makes one feel less > > positive that the switch works as designed, yes? > >Ron, I don't have time to chase ghosts. Apparently you do. I prefer to >operate in reality. The switch isn't port hopping. It is sending data as it >is designed to, given the circumstance that the switch does not know where >the destination host is located. > > > Past issues have been > > documented of packets crossing VLANS, now we are seeing packets hoping to > > ports they are not destined for. > >I think I have addressed this point enough. You clearly do not understand >how switches function, much less the nature of the bug report as it relates >to switch function. > > > Perhaps not all the problems supposedly > > fixed in past patches fixed all the issues, or then again, perhaps past > > fixes introduced new issues. Of course, this is not too surprising this > > we'd be seeing problems again. Afterall, switches are fairly new toys as > > compared to some of the other devices we all play with, including hubs, > > unix systems, that stable windows environment <cough>, and routers, etc. > >Yes, anything newer than 1962 sucks. Whatever... If all that old stuff was >so grand, people wouldn't use new technologies (did you get the pun Ron? >Don't want you to think I don't have a sense of humor) > > > > > <chuckle> Wes, you need to inject a sense of humor into the personality > > there, it helps keep from getting those fingers so stressed with blood > > flow as you pound on the keys. Seriously, it helps one avoid burnout in a > > tense industry. > >I appreciate your concern. I will endeavor to do some yoga or something >alleviate my stress? > >Burnout isn't the issue, any more than stress or your perception that I am >busting a vein as a result of this conversation. Truth be told, I think it >is quite funny that me, someone that you seem to deem unworthy and lacking >of skills, could so readily and easily point out how terribly flawed your >statements on this matter are. There, I guess I was a little wrong. I do see >some humor in the situation. Perhaps I should use emoticons more often... > >Oh, and what I have found helps to avoid burnout in a tense industry... is >being educated on the stuff I am responsible for. The more educated I am, >the less time I find myself chasing ghosts and the unknown. The less time I >chase ghosts, the more time I have to goof off on mailing lists and play >foosball (trying to get out of the losers bracket... yeah, I choked like the >Spurs or the 'stros...) >_______________________________________________ >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
