Date: 10 Apr 2001 14:49:16 -0400 From: Lowell Gilbert <lowell@world.std.com> To: freebsd-security@freebsd.org Subject: Re: Theory Question Message-ID: <rd67l0svbdf.fsf@world.std.com> In-Reply-To: brooks@one-eyed-alien.net's message of "10 Apr 2001 18:46:25 %2B0200" References: <Pine.BSF.4.10.10104072029260.31820-100000@bsdie.rwsystems.net> <20010410094541.A13808@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
I apologize for the length this message has reached... brooks@one-eyed-alien.net (Brooks Davis) writes: > It's true that older Vlan implementations have this problem, but modern > ones are implemented in hardward and do no leak packets. Cisco intends > its current VLAN implementations to be used for security partitioning. The term "VLAN" means different things to different people, and I don't think there's any way around the semantic confusion. There are a number of essentially unrelated concepts for which no better term exists than "virtual LAN". Some of these concepts are incompatible with security partitioning. Thus, in this sort of discussion, you always have to be careful that everybody is using the same definition of term, or else the discussion is useless. [I don't think this discussion is having this problem, but I'm not sure. Which serves, in its own way, to demonstrate the problem.] A short and non-exhaustive list of things that can reasonably be called VLANs (some of these are arguable, but I think at least a reasonable case can be made for each): - IPSEC tunnels - IP-over-(some other kind of encrypted tunnel) - nested MPLS paths - Ethernet VLAN tags - Ethernet switches with port-based broadcast (and, optionally, forwarding) domains - Ethernet switches with dynamically learned port- or MAC address- based broadcast (and, optionally, forwarding) domains I believe the discussion is centering on the last two. Even within those, there are reasons you'd want to use dynamic learning to reduce the load on the end stations, but you wouldn't necessarily want to do it in a way that enables security partitioning. The usual example is that setting up the broadcast domains completely dynamically requires less configuration than secure ways of containing broadcasts. Obviously, you can't use those easier approaches if you *need* the security, but in *many* environments, you don't. There are, to get back to Brooks Davis' point, implementations of VLANs on some Ethernet switches that can be used securely. There are even some which can let you run your "secure" VLAN on some ports, and do insecure dynamic address-based VLANs on other ports. [Well, actually, I'm not sure that such things exist today. I did one a few years ago, but that company bit the dust, and I don't know for a fact that anyone is shipping a similar switch today. However, I'd be surprised if there weren't a handful of such models.] That gives you a theoretically secure back-channel for network management, using your existing infrastructure (a truly separate back- channel would be even more secure from network-based attack, but might be less dependable in other ways). You still have to worry a bit about attacks on the switches themselves, and (as several other messages have discussed), the exposure of the "public-facing" interfaces of machines that also have interfaces onto your back- channel. However, your exposure is fairly limited at this point in that (to the best of your knowledge) any attacks on your monitoring capability have to be more sophisticated than they would be if the management traffic mingled with other traffic. This dovetails well with Crist Clark's point about security being something you improve through tradeoffs rather than absolutes. The place where FreeBSD can help you is in setting up your public- facing side of the devices that see both networks. That's a whole other topic, though, because there is a *huge* variety of things you might actually want to monitor or protect that way... Be well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rd67l0svbdf.fsf>