Firewall Wizards mailing list archives
RE: Defense in Depth to the Desktop
From: Chris Pugrud <cpugrud () yahoo com>
Date: Mon, 6 Dec 2004 09:04:32 -0800 (PST)
--- Ben Nagy <ben () iagu net> wrote: [IPSEC Proposal] Ben, I have mixed feelings on inserting IPSEC into the mix directly. I do try and emphasize that I only feel that this is a small piece of the puzzle called defense in depth. I'm only trying to address the weaknesses of the network layer that I fell can taken care of with mostly existing hardware. Organizations with a Cisco core can upgrade to the firewall feature set to gain the stateful packet filtering required to implement the model, at least that's how I'm doing it in one fairly large environment.
You might also want to consider (ick) MS ISA Server for networks that have a predominantly MS client pool (most). That will give you much better state tracking for the tricksy SMB/CIFS/NetBIOS stuff, as well as user sensitive rules as a side benefit. There are not many Stateful Packet Filters that can do 'proper' state for ms-rpc and other nasty windows stuff which uses a lot of UDP. Many (most?) just open up the UDP port for return traffic for a time window. Well, at least they used to.
The ISA server would add some small benefits, but I doubt it could handle the throughput on more than a modest sized network. I haven't had any issues with the tricky ms-rpc stuff, except the idiotic MAPI protocol, because they are still pretty good at being client->server(rpc), client->server(service), so the one way model holds fairly well. MS is also moving more to TCP, including the switch to SMB/TCP rather than SMB/NetBIOS/UDP/TCP. Doing things "proper" would have it's advantages, but at this time I continue to see more advantage in "keeping it simple".
One small flaw in your model is the "lurker worm" that sits on a server and waits for a client to connect on the appropriate service. Imagine, for example, a 0day LSASS worm - if the server is infected then the client pool will be rapidly infected as well, because as soon as they talk to a domain controller (in windowsland) the DC will helpfully send them a copy of the worm for free. This doesn't invalidate the model, but it's an important clarification of limitations. This is kind of similar to download.ject and the recent IFRAME attacks which used an infected adserver. (so it's not an alien model to h4x0rs).
Very true. The model is only network layer, it can not defend against attacks that use "legitimate" protocols, such as e-mail. As a piece of the puzzle, I feel that servers are the best defended resources on the network. While nothing is truly invulnerable to a zero day, servers are the only machines that an organization really has control over making sure they are up to date with patches and AV signatures. That is why I felt it was appropriate to invert the usual protection model and protect the clients, and each other, from the servers, while exposing the servers to the risks of the clients. The clients are the biggest risk, but they are also the least defended. The model invites attackers to throw themselves at my best defences, where bright eyes and heavy fortifications are focused, by denying them the ability to even talk to my least defended assets (other than the one they've commandeered).
I also have some observations - you're using a LOT of vlans. How are you going to manage that for large client pools? I think that tagging only gives you 4096 IDs, right? Besides, tagging leaves you open for "side to side" client infections for clients that are new / misconfigured / not supposed to be there. I suppose you would want to use switchport based VLANs, but that sounds like switch config hell.
A slight communication error on my part. The clients all use the same vlan(s). MAC isolation (or private vlans in Cisco(tm) speak) block any traffic to vlan ports that are not designated as "community" or "public" ports. Systems on "private" ports in the vlan can not talk to each other in any way, they can only talk to "public" ports, generally the upstream security device.
Overall, I kinda like the model. I think your big vulnerabilities are the configuration management and the VLANs (also insert "VLANs were not made to enforce security barriers" rant here), and also the technical details of the statefulness of your firewall with respect to lurker worms.
VLANs are not made to enforce security barriers, but they are increasingly being used for this purpose and the vendors are being pushed to harden their implementations to address weaknesses in using VLANs as security tools. Physical isolation is still the best, without question, but we usually have to make "best" with the tools we have available. Lurker worms, any worm that attaches itself to the server process (think about logon scripts and profiles) are a huge vulnerability to any network. I'm just trying to close another wall in the maze and make organizations a bit more crunchy on the inside. Thank you for your excellent points, Chris _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Defense in Depth to the Desktop Chris Pugrud (Dec 05)
- Re: Defense in Depth to the Desktop Magosányi Árpád (Dec 07)
- Re: Defense in Depth to the Desktop Chris Pugrud (Dec 07)
- Re: Defense in Depth to the Desktop Magosányi Árpád (Dec 11)
- protection models Chris Pugrud (Dec 11)
- Re: Defense in Depth to the Desktop Chris Pugrud (Dec 07)
- Re: Defense in Depth to the Desktop Magosányi Árpád (Dec 07)
- Re: Defense in Depth to the Desktop Rogan Dawes (Dec 07)
- Re: Defense in Depth to the Desktop Chris Pugrud (Dec 07)
- RE: Defense in Depth to the Desktop Ben Nagy (Dec 07)
- RE: Defense in Depth to the Desktop Chris Pugrud (Dec 07)
- RE: Defense in Depth to the Desktop Scott Stursa (Dec 11)
- RE: Defense in Depth to the Desktop Chris Pugrud (Dec 11)
- RE: Defense in Depth to the Desktop Chris Pugrud (Dec 07)
- Re: Defense in Depth to the Desktop Chris Pugrud (Dec 13)
- Re: Defense in Depth to the Desktop Paul D. Robertson (Dec 13)
- Re: Defense in Depth to the Desktop Frederick M Avolio (Dec 13)
- Re: Defense in Depth to the Desktop Chris Pugrud (Dec 14)
- Re: Defense in Depth to the Desktop Chris Pugrud (Dec 14)
- Re: Defense in Depth to the Desktop Paul D. Robertson (Dec 14)