Re: [fw-wiz] segmentation of DMZs

From: Mikael Olsson (mikael.olsson@clavister.com)
Date: 11/16/02


From: Mikael Olsson <mikael.olsson@clavister.com>
To: Carson Gaspar <carson@taltos.org>
Date: Sat Nov 16 18:48:43 2002

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


Relevant Pages

  • Re: [opensuse] setting up a home network
    ... win boxes in SMB shares. ... Do you have the firewall open on the appropriate ports? ... The firewall on the router takes care of the security; ... for his inner impulse must find suitable expression." ...
    (SuSE)
  • Re: Do you recommend anti-virus and/or a firewall?
    ... I have 3 different firewalls running on the XP boxes. ... Is there an idiot's guide, somewhere, to setting up the SUSE firewall that doesn't require you to know which ports are which *before you start - even a list of ports and their significance in firewall terms would be a help. ...
    (alt.os.linux.suse)
  • Re: Suggest firewall for Win98se+ICS(dialup)+NAV
    ... to go out and buy all new boxes capable of running Win 2000 Pro or Win XP ... |> either disable the firewall or otherwise change its settings. ... vulnerability in a small business environment is from the inside, ... Any disgruntled Win 98 SE user can obviously walk in and install something ...
    (comp.security.firewalls)
  • Re: Secure Network Design (DMZ, LAN, etc)
    ... separated from the dbs by a firewall - transparent or router (different ... Secure Network Design ... > then why have a separate network? ... > switch. ...
    (Security-Basics)
  • Fwd: Re: [Full-Disclosure] Microsoft urging users to buy Harware Firewalls
    ... In my exprerience, these boxes just work. ... So why should we have to stick a firewall in front of a machine ... NAT boxes and hardware firewalls are tools. ... I myself put my windows boxes ...
    (Full-Disclosure)