On Mon, Apr 15, 2002 at 08:06:39AM -0500, Noonan, Wesley wrote: > > position that seems to be so prevalent on this list. I think it is bad > practice to make such blanket generalizations. >
OK... lessee what happens if we take another approach to this whilst holding this thought in your head: "trusting that the layer above below you will do the correct thing with invalid data leads to security breaches", consider the following: a) VLANs are implemented by putting data into an otherwise unused part of the IP header. Anyone can easily craft a packet with the right data in the right place given the right tools and access. b) A switch which receives a packet with VLAN information on it on a non-trunk port should treat the packet as bad (well IMHO) and either drop the packet or scrub the invalid information. The reality is that the behaviour will be "implementation defined" Given these two points, can it be considered wise to trust the implementation of VLANs on a particular switch? Well, perhaps, if you can verify the switch behaviour by extensive testing but what if you miss something (this sounds like FUD, I know) - just take the example of overlapping packet fragments being used to bypass firewall checks not that long ago, or what if the tested switch fails and you get a new one - do you repeat your tests because the ASIC's in the switch may have changed? Given the cost vs risk it is simpler and more cost effective just to get two separate switches. > > Bingo!!! This is what I have been trying to get across. Everything has it's > place, and in many cases VLANs have their place as an aspect of a perimeter > design. Is it the "best" design? Maybe, maybe not. Can it be the best design > for the circumstances and requirements? Absolutely. > ok - so, you are saying that multple switches does not scale well but look at what you are suggesting, something that you are saying is pretty much unacceptable in a single host situation suddenly becomes ok in a large scale deployment? Where you have much more complexity and exposure? I am not so certain that this is a good thing - I am not suggesting a "damn the torpedoes" solution of a small switch for every connection but one must be wary of trying to make a lame duck fly simply by expanding the size of the duck. > > Certainly not. However, chasing boogeymen isn't a good practice > either. > Hmmmm there have been times when today's boogeyman is tomorrow's nightmare. One must not be complacent. > As > security people, and in opinions expressed on this list many times, people > seem to forget that business still has to get done. Security is, and should > be, secondary to making money. This is, after all, business and capitalism. > Security policies and practices that prevent business are BAD. > Sorry, no. A security policy is there to help you STAY in business. A BAD security policy stops you doing what you need to do. Security is not convenient. It is not fun. I would much prefer not having to manage a firewall, update virus patterns, lock things down but because of a whole load of twerps we are forced to do this or suffer having the resources we manage soaked up by said twerps serving up porn or warez to their community - there is no money in doing that so we do our best to prevent it happening. Security is a fine balance between getting what you need done without exposing yourself to being used for some unprofitable purpose. > > Agreed. Again, this is the point that I was trying to make. It's not cookie > cutter. There are a LOT of variables to weigh, and I just think it is bad > practice to make statements like I have seen from others on this list. > It is not a cookie cutter but proposing to use VLAN's to enforce a security perimeter seems to place a large amount of trust in the fact that the switch will deal with "erroneous" packets correctly[1] AND that the switch has been configured correctly[2] AND that any replacement switch will be similarly configured. [1] Actually, there were some reports on bugtraq that people had managed to get packets to jump vlans on 3com and cisco switches. [2] Some 3com enterprise switches default (well, used to at least) to "open mode" which means that they do not constrain the VLAN traffic to ports that are members of that VLAN, you needed to put the switch into "closed mode" to fix this. -- Brett Lymn _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
