<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-7">
<META content="MSHTML 6.00.2800.1226" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff background="">
<DIV><FONT size=2></FONT><FONT size=2>Hi All,</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>My idea of a "typical" DMZ:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT face="Courier New"
size=2>
|---------------------|</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Internet --- Firewall --- |
--------+----+----+ |</FONT></DIV>
<DIV><FONT face="Courier New"
size=2>
| | Server A
B C |</FONT></DIV>
<DIV><FONT face="Courier New"
size=2>
|
| ( DMZ
) |</FONT></DIV>
<DIV><FONT face="Courier New"
size=2>
Private |---------------------|</FONT></DIV>
<DIV><FONT face="Courier New"
size=2>
Network</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>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 ;)</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>I hope this helps,</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>John Dalton</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><BR><FONT size=2>----- Original Message ----- <BR>From: "Costa Tsaousis"
<costa@tsaousis.gr><BR>To: "Daniel Pittman"
<daniel@rimspace.net><BR>Cc: "Costa Tsaousis" <costa@tsaousis.gr>;
"John Dalton" <john.dalton@nunatak.com.au>; <rwallace@a--i--m.com>;
<firehol-support@lists.sourceforge.net><BR>Sent: Tuesday, August 26, 2003
10:42 AM<BR>Subject: Re: [Firehol-support] Re: Understanding
firehole.conf<BR><BR><BR>Hi all,<BR><BR>Since the matter (I guess) deserves some
attention and since I have many<BR>e-mails at my mailbox asking similar stuf,
here are my understandings.<BR><BR>Definition (abstract from
webopedia):<BR><BR>Short for demilitarized zone, a computer or small subnetwork
that sits<BR>between a trusted internal network, such as a corporate private
LAN, and<BR>an untrusted external network, such as the public
Internet.<BR><BR><BR>So, the above simply means:<BR><BR><BR> CASE A:
2-iface<BR><BR><BR> Internet --- DMZ --- Trusted LAN<BR><BR><BR><BR>But
also:<BR><BR><BR> CASE B: 3-iface<BR><BR><BR> Internet --- DMZ ---
System
Administators<BR>
|<BR>
|<BR>
Servers<BR><BR><BR><BR>and also:<BR><BR><BR> CASE C:
4-iface<BR><BR><BR> Corporate
LAN<BR>
|<BR>
|<BR> Internet --- DMZ --- System
Administrators<BR>
|<BR>
|<BR> Data
Center<BR><BR><BR>I believe that the above (CASE C) is the best for corporations
that have<BR>employees in the Corporate LAN that cannot be trusted (like
secretaries,<BR>accountants, salesmen, etc).<BR><BR>Personally, I run a big data
center with several dozens of servers, that<BR>looks similar to this (simplified
a bit):<BR><BR><BR> Internet --- DMZ --- Servers Farms A --- DMZ --+--
hidden server
A<BR>
|<BR> Internet --- DMZ --- Servers Farms B --- DMZ --+-- hidden server
B<BR>
|<BR> Internet --- DMZ --- Servers Farms C --- DMZ --+-- hidden server
C<BR>
|<BR>
|<BR> Internet ------------------------------------ DMZ ---
Admins<BR>
|<BR>
|<BR>
Corporate LAN<BR><BR><BR>I use several DMZs to isolate and control different
kinds/levels of trust,<BR>some of which (DMZs) route traffic while others NAT
unroutable traffic and<BR>others handle the traffic with their own applications
that redo the<BR>requests at their other side (proxy like).<BR><BR>Of course,
FireHOL runs on all DMZs but also the servers themselves.<BR><BR>The important
thing about security is that every case is different. For<BR>example, if you
have a critical web application that is a great risk for<BR>your organization,
it might be necessary to install a squid in<BR>"transparent httpd acceleration"
mode to isolate completely the client<BR>from the server (with such a setup, a
client cannot have a direct socket<BR>to your web server, so even if an attacker
manages to e.g. buffer overflow<BR>your web application, he cannot have a socket
to it and even if the<BR>overflow contains code to open back a socket, the web
server app will not<BR>be able to open it because it has an unroutable IP or
because there is no<BR>"client xxx accept" in its firehol.conf - so the intruder
cannot know what<BR>happened).<BR><BR>To create your DMZs, I suggest to think
and design what is appropriate for<BR>you. There is no "magic firewall" or
"ideal DMZ setup". Security is a tool<BR>for managing risk, YOUR RISK. Your risk
might be (and in most of the<BR>cases, is) completely different than mine (or
any other's), since risk is<BR>a business value, not a technical one. This is
also why I tried to make<BR>FireHOL a human understandable iptables firewall
design tool and not a<BR>firewall script that creates some kind of a
firewall.<BR><BR>Hope all these
help...<BR><BR>Costa<BR><BR></FONT></DIV></BODY></HTML>