Re: segmentation of DMZs

[Mikael Olsson <mikael.olsson () clavister com>]

Hullo,

As usual, I'm disagreeing with stuff :)

Carson Gaspar wrote:
> b) Every system is on a seperate segment
>
> Con:
>
> Address space nightmare (can be solved with a bridging firewall)

I personally think that I have quite a bit of experience with segmenting 
public as well as private boxes.  We've got about a dozen zones at the
head office network.  I've personally got _five_ zones in my home 
network! :)

Of course, my experiences in this area is mainly limited to using our 
gear, but, at least from that perspective, I can't agree with this 
address space nightmare objection.  With a reasonable proxy arp setup, 
spreading a single /28 over half a dozen zones is, in my experience, 
not a problem at all.  And this is with routing firewalls, mind you.

In fact, separate zones can make some things easier, for instance when 
address translation is involved. In a flat DMZ with private addresses, 
one needs to make sure that the boxes involved always connect to the
private addresses if they need to talk to eachother, OR, if they 
ever connect to the public addresses (because, say, that's where the
MX pointer points?), one needs to also translate the SOURCE of requests 
as they pass through the firewall, so that the response always passes 
back through the firewall.  (If the client sent its TCP SYN to 1.2.3.4, 
it will NOT accept ACKs from 10.0.0.5!)

With a fully segmented DMZ, this "just works", since all packets
always travel through the firewall.


> Application architecture must be explicitly provisioned, every time it
> changes (may be seen as a Pro)

Definately a pro :)


> Enormous firewall port count (802.1q helps)

Um. 
"I want to install a firewall. 
 Pro: This can help security.
 Con: You need a firewall." 
...? :)

I'd just like to add a word of caution: I personally do not want to
trust the more sensitive separations to VLANs. I've seen way too
many switches go Tango Uniform just because a mac address in
port based VLAN 1 suddenly appears on port based VLAN 2.
Aren't they supposed to be _separated_? :)

Of course, this doesn't mean that one shouldn't use VLANs at all.
If I have a dozen machines that I want to separate, but only a 
handful of physical interfaces, maybe I can group them into a few
major trust levels and give each group a physical interface each. 
Then I can use separate VLAN switches to further separate the 
boxes in each group.


> Complex routing / bridging

- Set all boxes to use the same network
- Set route to box1 through if1
- Set route to box2 through if2
- Set route to box3 through if3
  (etc...)
- Enable proxy ARP for all routes/interfaces involved.
- Done.

Of course, if you can't do proxy ARP, or use a firewall with very
rigid ideas of how routing tables should look, I can definately see 
how this rapidly can become very ugly.


> High operational / debugging complexity

Why? All of a sudden I can even get logs of all connections opening
and closing, which I couldn't easily get before.  I can even do
monitoring and alerting when connections that I expect to happen 
suddenly _aren't_ happening between two boxes!

However, if by this you meant "it takes more time to set up", _that_
I can agree with.  You need to understand the protocols that the boxes 
want to use.  You need to not accept blanket vendor statements of 
"open ports x,y,z and 1024-65535 in both directions", etc. But that's
part of securing _anything_.



Now, I'll add a con of my own:

Protocols not designed to live outside a single LAN are a PITA.
No, I'm not necessarily thinking of windows networking here; that 
can usually be solved with WINS and/or lmhosts files.  I'm thinking 
about ones that absolutely need to use broadcasts and scream UDP 
at eachother on random ports.  Ick.  If you get one of those, you
can basically forget about separation.  Maybe you can shoehorn a 
firewall in between two such boxes, but you'll likely end up opening 
so many ports that the value in separating them becomes highly 
questionable.  Fortunately, most protocols don't behave this way.




-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards