RE: [fw-wiz] Defense in Depth to the Desktop
From: Chris Pugrud (cpugrud_at_yahoo.com)
Date: 12/06/04
- Previous message: Devdas Bhagat: "Re: [fw-wiz] How to Save The World (was: Antivirus vendor conspiracy theories)"
- In reply to: Ben Nagy: "RE: [fw-wiz] Defense in Depth to the Desktop"
- Next in thread: Scott Stursa: "RE: [fw-wiz] Defense in Depth to the Desktop"
- Reply: Scott Stursa: "RE: [fw-wiz] Defense in Depth to the Desktop"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Ben Nagy <ben@iagu.net>, firewall-wizards@honor.icsalabs.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
- Previous message: Devdas Bhagat: "Re: [fw-wiz] How to Save The World (was: Antivirus vendor conspiracy theories)"
- In reply to: Ben Nagy: "RE: [fw-wiz] Defense in Depth to the Desktop"
- Next in thread: Scott Stursa: "RE: [fw-wiz] Defense in Depth to the Desktop"
- Reply: Scott Stursa: "RE: [fw-wiz] Defense in Depth to the Desktop"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
