On Fri, 12 Apr 2002, Noonan, Wesley wrote: > 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".
Informed, insightful and proven statments like "Fixed to my knowledge?" "This has happened, this sort of thing generally happens, therefore this is bad" is a much more accurate characterization of my comments in this thread. > > 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. No, it's results of others research which is unconfirmed being passed as such- that's why I'm careful to use terms like "rumblings." Nobody's broken into my laptop- that's not proof that it's secure. It's configuration, along with the historical exposure of its services, the sorts of things that generally happen to laptops and my experience with them is a heck of a lot more than FUD, and is the same sort of thing I've presented, whilst all you've presented is "I don't like that." Please provide some substance for your point, "It hasn't happend in the last 45 days that I know of." isn't substantative. > 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. People are responsible for their own implementations- all of the companies on the CERT advisory have QA departments, trying to make it an Open-source arugment is silly. If you're asserting that Nortel isn't accountable for its products because they used an open-source library, you're a raving loon. > > > 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. Cool, then tell me WHICH statement meets "In fact, you are doing that in the above statement." I've presented which of my statements I *represented* as fact, and assertions as to why they're represented as such- you can at least point out your counter-example. > > 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. You've provided *nothing* absent "I don't like how you present information," despite the fact that I've couched my terms with indicators of the level of confidence I have in the information I present. > <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. Then you should read the reports, the book I cited and draw your own conclusions. That doesn't make mine any less valid. If you want to wait for a dog to bite instead of taking action when it barks, that's your choice, but don't characterize someone paying attention to the barking as alarmist when you don't have better information. Especially when that person is familiar with the behaviour of that breed and that particular dog. It's like when NT first came out, and someone said (on this list) "NT doesn't have the security problems that Unix does." (paraphrase) That's turned out to be completely not true, it's had many of the same problems, they just hadn't been discovered yet- you're trying to make the same argument about VLANs, and it holds as much water. > <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. Yet you can't seem to come up with any facts as to why it's a good design other than "As far as I know, all the problems have been fixed." Sorry, that doesn't hold water. > 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 No, I know that code has been written, you're apparently unable to acknowledge the fact that the advisories were the result of someone actually running code to find the vulnerabilities. > > > 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? Bzzzt. That doesn't get you past the layer 3 device. > > 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. You're welcome to your opinion. Your definition of "outdated" apparently fits only one vendor and with everything not patched to the currently current rev. > > 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. Probability is what risk management and assessment are all about. Once again, VLANs amplify the problem, ergo you need a pretty compelling business need to recommend the solution unless you're into selling the flavor of the week. > What?? Debatability isn't a solid metric and doesn't change the end result. > > > 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. If history, experience, probability and reliable informants are dogma in your book, then I suppose so. "That's not good enough for me, but I don't have anything better." isn't a valid counter-argument. > Simplicity of design is not what you have been presenting though. No doubt, Yes, it's a part of what I've been presenting- it's an underlying theme in the entire "protocols like this" section. > 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". It's been pointed out to me that the majority of the vendor community doesn't support VLANs as solid security boundaries. I'd also like to point out that I'm *sure* that a *lot* of vendors have done a LOT worse than Cisco has in deploying technologies like this. I offer the examples because that's the technology I tend to use, I'd be hard pressed to go to any other vendor for a switch for a network I personally operate. Cisco has gone out of their way to do things like extend spanning tree to try to limit network exposure to problems in protocol specifications outside of their control. As I said originally, VLANs weren't originally designed to be security barriers- no ammount of "I don't like your rationale" will change that. The Cisco book on switching is a must read for anyone who uses their switches. I'd lay money on other vendors having more and worse failure modes, and I applaud the fact that Cisco has documented thiers so that people can make their own decisions about how and where to deploy their technology. 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
