[Firehol-support] Re: Understanding firehole.conf

[Costa Tsaousis]

Thank you John.

I totally agree with you, however I have just one question:

Are you suggesting that the term DMZ should be used *only* with such 3-way
setups?

When there are different levels/kinds of trust and you install firewalls
in-bitween some server farms (or zones), in any topology, can you say
"this is a DMZ setup" or not?

Actually, in my examples, the DMZs are not necessary the firewall and for
sure is not just one server. It might be and it might not be.

For example, is this a DMZ setup?



 Internet --- Firewall A --- Server Zone 1
                                  |
                                  |
                              Firewall B
                                  |
                                  |
                             Server Zone 2
                                  |
                                  |
                              Firewall C
                                  |
                                  |
 Internet --- Firewall D ------ Admins


It uses firewalls to isolate and control trust, but would you name this a
DMZ?

In general, in my data center topologies, I try to have completely
different LANs for serving requests and others for administering the
servers (the public LAN is there for serving the public, while the
internal LAN is there to handle inter-systems communication and give me
admin control). I believe this gives the maximum of security, since, for
example, SSH, SNMP, and other administration stuf is not even listening at
the public view of the network.

I consider this:


  Internet --- Firewall --- Servers
                  |
                  |
                Admins


as too risky for large setups.

Costa


> Hi All,
>
> Firstly, let me just state that I agree wholeheartedly with Costa's last
> paragraph - security needs to be managed according to your own risks and
> needs, so that there's no "ideal" setup.
>
> Secondly, the definition of DMZ that I use differs slightly, so I thought
> I'd offer it here for comparison.  After all, if this is going to be
> updated in the documentation we ought to make sure that it's as clear as
> possible.
>
> A DMZ is not a host - it's a "zone".  It's a conceptual rather than a
> physical thing.  It's a section of your network that is isolated from
> everything else by a firewall/gateway, and usually has some fairly strict
> rules applied.
>
> My idea of a "typical" DMZ:
>
>                           |---------------------|
> Internet --- Firewall --- | --------+----+----+ |
>                  |        |  Server A    B    C |
>                  |        |       ( DMZ )       |
>               Private     |---------------------|
>               Network
>
> Servers that are located in the DMZ can not be contacted directly by any
> other host - all traffic between the DMZ and any other network must pass
> through the firewall.  This allows you to do things with your firewall
> such as perform NAT or port forwarding on any requests for servers located
> in the DMZ, or allow only specific services in and no traffic out unless
> it has already been established by an incoming connection.  This is
> something that FireHOL makes very easy, by the way.
>
> Why might you want to use a DMZ?  The whole point is that you really don't
> trust anything on either side of it.  You don't trust people outside of it
> (whether they're coming from the internet or your private network) because
> they're all nasty hackers.  You don't even trust the DMZ servers
> themselves, because if somebody exploits a vulnerability in a service you
> run publically you don't want them to gain access to your internal
> network, or to use your server as a staging platform for further attacks
> out on the internet.  A DMZ is a compromise between maintaining security
> and having to provide a publically-available service.  After all, the only
> secure box is one with the network cable unplugged ;)
>
> Finally, as Costa said - you should be running FireHOL on each of your
> servers as well as your firewall - that way a misconfiguration of your
> firewall won't suddenly open up everything on your web server (for
> example) to the whole world.
>
> I hope this helps,
>
> John Dalton