[Firehol-support] Re: Understanding firehole.conf

[John Dalton]

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


----- Original Message ----- 
From: "Costa Tsaousis" <costa at tsaousis.gr>
To: "Daniel Pittman" <daniel at rimspace.net>
Cc: "Costa Tsaousis" <costa at tsaousis.gr>; "John Dalton" <john.dalton at nunatak.com.au>; <rwallace at a--i--m.com>; <firehol-support at lists.sourceforge.net>
Sent: Tuesday, August 26, 2003 10:42 AM
Subject: Re: [Firehol-support] Re: Understanding firehole.conf


Hi all,

Since the matter (I guess) deserves some attention and since I have many
e-mails at my mailbox asking similar stuf, here are my understandings.

Definition (abstract from webopedia):

Short for demilitarized zone, a computer or small subnetwork that sits
between a trusted internal network, such as a corporate private LAN, and
an untrusted external network, such as the public Internet.


So, the above simply means:


 CASE A: 2-iface


 Internet --- DMZ --- Trusted LAN



But also:


 CASE B: 3-iface


 Internet --- DMZ --- System Administators
               |
               |
            Servers



and also:


 CASE C: 4-iface


         Corporate LAN
               |
               |
 Internet --- DMZ --- System Administrators
               |
               |
          Data Center


I believe that the above (CASE C) is the best for corporations that have
employees in the Corporate LAN that cannot be trusted (like secretaries,
accountants, salesmen, etc).

Personally, I run a big data center with several dozens of servers, that
looks similar to this (simplified a bit):


  Internet --- DMZ --- Servers Farms A --- DMZ --+-- hidden server A
                                                 |
  Internet --- DMZ --- Servers Farms B --- DMZ --+-- hidden server B
                                                 |
  Internet --- DMZ --- Servers Farms C --- DMZ --+-- hidden server C
                                                 |
                                                 |
  Internet ------------------------------------ DMZ --- Admins
                                                 |
                                                 |
                                            Corporate LAN


I use several DMZs to isolate and control different kinds/levels of trust,
some of which (DMZs) route traffic while others NAT unroutable traffic and
others handle the traffic with their own applications that redo the
requests at their other side (proxy like).

Of course, FireHOL runs on all DMZs but also the servers themselves.

The important thing about security is that every case is different. For
example, if you have a critical web application that is a great risk for
your organization, it might be necessary to install a squid in
"transparent httpd acceleration" mode to isolate completely the client
from the server (with such a setup, a client cannot have a direct socket
to your web server, so even if an attacker manages to e.g. buffer overflow
your web application, he cannot have a socket to it and even if the
overflow contains code to open back a socket, the web server app will not
be able to open it because it has an unroutable IP or because there is no
"client xxx accept" in its firehol.conf - so the intruder cannot know what
happened).

To create your DMZs, I suggest to think and design what is appropriate for
you. There is no "magic firewall" or "ideal DMZ setup". Security is a tool
for managing risk, YOUR RISK. Your risk might be (and in most of the
cases, is) completely different than mine (or any other's), since risk is
a business value, not a technical one. This is also why I tried to make
FireHOL a human understandable iptables firewall design tool and not a
firewall script that creates some kind of a firewall.

Hope all these help...

Costa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.firehol.org/pipermail/firehol-support/attachments/20030826/a75b2800/attachment-0003.html>