From owner-freebsd-security Tue Apr 10 11:49:23 2001 Delivered-To: freebsd-security@freebsd.org Received: from sgi04-e.std.COM (sgi04-e.std.com [199.172.62.134]) by hub.freebsd.org (Postfix) with ESMTP id DFA1F37B422 for ; Tue, 10 Apr 2001 11:49:19 -0700 (PDT) (envelope-from lowell@world.std.com) Received: from world.std.com (world-f.std.com [199.172.62.5]) by sgi04-e.std.COM (8.9.3/8.9.3) with ESMTP id OAA4509183 for ; Tue, 10 Apr 2001 14:49:17 -0400 (EDT) Received: (from lowell@localhost) by world.std.com (8.9.3/8.9.3) id OAA18045; Tue, 10 Apr 2001 14:49:16 -0400 (EDT) To: freebsd-security@freebsd.org Subject: Re: Theory Question References: <20010410094541.A13808@Odin.AC.HMC.Edu> From: Lowell Gilbert Date: 10 Apr 2001 14:49:16 -0400 In-Reply-To: brooks@one-eyed-alien.net's message of "10 Apr 2001 18:46:25 +0200" Message-ID: Lines: 70 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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