[Firehol-support] Re: Understanding firehole.conf

[Costa Tsaousis]

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