> -----Original Message----- > From: Paul Robertson [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 12, 2002 14:57 > To: Noonan, Wesley > Cc: Gary Flynn; [EMAIL PROTECTED] > Subject: Re: VLANs and security... was RE: Cisco IDS > > "Fixed to my knowledge" is less useful as a metric than "historically been > broken" from a risk assessment viewpoint without some specific > qualifications. Ones that would mean a lot to me would be things like > "audited the codebase in the last year or so," "worked on the code and > there's a specific process that covers this," or "have some detailed > knowledge about a process or procedure and its rate of adoption at said > vendor which mitigates such risks." Without additional data, or perhaps a > lot of experience testing such products in such scenerios, it's really > difficult to see what assurance that statement brings to the table.
Sure, but passing FUD isn't really helpful either. People need to make informed, insightful and proven statements. Not "well this could happen, so it's bad". > People who's abilities I have a high degree of trust in have claimed some > interesting results from their testing. They don't do exploits- so no > "earthshattering" reports from customers, but neither do they necessarily > do vendor reports. If I had more time, I'd start playing a lot more with > code, but it's pretty far down my list of things and I don't see that > happening anytime soon. Until then though, FUD winds up getting passed around as fact. > If it's indeed been known for 10 years that the ASN.1 encoding/decoding > routines had implementation problems then I'm *glad* they're scrambling- > it's > not a protocol problem, it's an implementation problem and 10 years is > long > enough to fix an implementation's buffer size, no? Sure it is. That's one of the problems with an effectively open-source development effort though. No organized and accountable QA. Development can stick to their "it's not a bug, it was designed this way" mantra. > > > 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 > > Are you asserting that filling the CAM table on a Cisco switch never > triggered a "go into hub mode" failure? Are you asserting that my > statement that it isn't the only vulnerability that ever made a Cisco > switch act like a hub (hint: CPU starvation on a Cat5000 is another?) No, I'm not. > Those are the two statements above that are stated as fact. The "Absent > evidence" part is an invitation to provide such, because I certainly > haven't > seen it (nor do I have faith in every switch vendor on the planet not > making > the same types of mistakes.) Paul, I am not focusing in on any one statement of yours, but rather a general observation of the way you present information. <snip> > months or so, I'll go with caution. If you've got any URLs that mention > any such changes, I'd certainly appreciate the data. No, I don't but that is my point. I don't believe in making alarmist statements either. I deal in facts and what can be proven, not something that might be plausible but no one knows, or at least no one seems to know. <snip> > assertions and methods. When you go out of your way to say "I'm not > sure..." it's pretty frustrating to have someone say "Hey- you're not sure > about that" as if it were a revelation! That's the difference between you and I, I suppose. I don't say "I'm not sure..." then try to tell people what is/is not good design. > It's been what, about 2 1/2 years since the initial tagged queueing stuff > was done? Are you saying "there are no coded 802.1q exploits in the > last two years," or "There are no switches vulnerable to an 802.1q exploit > today," "Cisco fixed the 802.1q issues that were pointed out to them," or > "Cisco fixed all their 802.1q problems?" It's not clear here which you're > saying, and I've got 4 CDs *full* of exploits to go over in the next > month, so I'd like to know which thing I should be looking for. I said it before and I will say it again. I don't *know* that those exploits don't exist any more than you apparently know that they do. However, unlike you, I am not going to sit here and tell people using VLANs is good or bad since the reality is that I can't find anything of substance to say it is/is not. > > You can do this in a single switch environment *too*. Bad design is not > a > > uniquely VLAN problem. > > Cool, please show me a single switch design where the *default* switch OS > with a *default* configuration does this. I'm not, and have never said > bad design was uniquely a VLAN problem, I'm saying you have to try > significantly harder to not make it one in a VLAN environment. Let's see... when Bucky the network admin indiscriminately starts plugging cables in? > Internal/External VLANS are a bad idea from a security architecture > standpoint. Here you go making this statement again, but I am not seeing it backed by anything other than outdated anecdotal evidence. This is your opinion, an opinion that you have not been able to defend very well IMHO. > > > *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. > > No, unfortunately it's not still true- if the switch is mostly "internal" > with a single "external" segment, it'll have less security attention and > care and feeding than will the PIX. I'd bet on that for at least 20% of > installations. In a lot of companies, firewall admin != switch admin. > Giving people an architecture that will probably fail 1 in 5 times isn't > my idea of a good thing[1]. You are making generalizations now and presenting probablies. Once again, this is a *design flaw* and is not exclusive to VLAN vs. standalone switches. > > > 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). > > _Everything_ is debatable, and there are instatantiation-specific issues > and cures that aren't always accountable for without making a conversation > unintelligible. That doesn't make the value of the conversation (nor the > debate) worthwhile. What?? > There's a strong reason that physical compartmentalization has been an > essential part of good security practices since the dawn of time- and > it's not just a pure dogma issue. But so far, all you have had is dogma to support your recommendations. > The complexity of "Turn off spanning tree," "Turn off CDP," "make sure the > DMZ is never trunked with an internal VLAN," "Make sure that an internal > server is never plugged into an external port on that box (including when > you're swapping wires,)" "Ensure that the config hasn't been changed every > time someone leaves," "Believe that all the 802.1q issues have been > solved for this switch and its OS," "Believe that all the Ethernet issues > have been solved for this switch and its OS," "Hope there's never a worm > that exploits the "trusted" side of the switch," and "Believe the failure > modes of switches have changed from internal "get the traffic delivered" > to a higher threat condition?" > > compared to > > "Buy a small switch and external stuff gets plugged in over there." is a > no-brainer in my book. Simplicity of design is not what you have been presenting though. No doubt, it is much easier to just stick a separate box out there for the DMZ, but this isn't the same as saying "using VLANs is probably a disastrous practice". Wes Noonan _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
