[ previous ] [ next ] [ threads ]
 From:  Jim Gifford <jim at giffords dot net>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] DMZ (very long, beware, possible documentation candidate)
 Date:  Fri, 5 Mar 2004 13:35:40 -0500
On Fri, Mar 05, 2004 at 02:43:23AM -0800, steven murphy wrote:
> ok how do i set up a DMZ, and if i sert up a DMZ can it be a whole 
> network of computers(IP range or whole subnet), or is it a single 
> computer? how do I set up both of those?
> is m0n0 Wall compatable with this: 
> http://www.mobl.com/expansion/pci/7slot3233/index.html

My *guess* is that the pci expansion chassis is just a pci to pci bridge,
and might work with freebsd, and hence would work with m0n0wall.
However, the only way to know for sure would be to buy one and try it.

The rest of this email is quite long.  You might want to refill your
coffee cup before reading it.  :)

As for DMZ, different people use that term to mean different things.
Also, m0n0wall supports a few different way of configuring things to
deal with different network situations.  I'm hardly an expert on all of
these different ways of doing this type of setup, so I'll try to explain
as much as I can.

DMZ stands for "DeMilitarized Zone" and is a term borrowed from warfare.
This is fitting in a way if you think of being connected to the Internet
as being constantly under attack by enemies.  The point behind a DMZ zone
is to have an area that is exposed to WAN initiated traffic with very
tight restrictions.  This way, if a hostile attacker did compromise a
machine in the DMZ, they've only got access to the DMZ, and not to all
the machines in the LAN.

In every example of a DMZ I've seen, the DMZ was a separate network apart
from the Internet network (called "WAN" in m0n0wall) and the protected
computers (called "LAN" in m0n0wall).  The two common scenarios I've seen
are these:

Type A (I'll call it the nested firewall approach):

    WAN/Internet cloud
    | Firewall |
        |               +-------------------+
    DMZ network --------+ protected servers |
        |               +-------------------+
    | Firewall |
        |               +------------------------+
    LAN network --------+ protected workstations |

Type B (I'll call it the typical approach):

    WAN/Internet cloud
    +---+------+ (DMZ)  +-------------------+
    | Firewall +--------+ protected servers |
    +---+------+        +-------------------+
    | protected workstations |

Now, either of these scenarios can be expanded.  I've actually seen 3
firewalls nested in a bizarre configuration.  That looked a bit like

    WAN/Internet cloud
    | Firewall |
        |               +----------------------------+
    DMZ network 1 ------+ protected Internet servers |
        |               +----------------------------+
    | Firewall (including VPN link to corporate LAN) |
        |               +----------------------------+
    DMZ network 2 ------+ protected intranet servers |
        |               +----------------------------+
    | Firewall |
        |               +------------------------+
    LAN network --------+ protected workstations |

In this network setup, there was a set of Internet accessible servers
(dns and http), a set of intranet servers used for development which the
corporate office had access to via the VPN link, and the protected
developer workstations.  The developer workstations had access to
everything, but corporate's admins couldn't get access to the developer
workstations.  They had a habit of having machines get compromised and
try to compromise the rest of the company's LAN.

I've also seen a situation where type B used multiple DMZ networks, like

    WAN/Internet cloud
    +---+------+ (DMZ)  +-------------------+
    | Firewall +--------+ protected servers |
    +---+---+--+        +-------------------+
        |   |
        |   |           +-------------------------+
        |   +-----------+ other protected servers |
        |               +-------------------------+
    | protected workstations |

Obviously you can expand this scenario as wildly as you want.  You would
want to do this in a situation where DMZ servers in the two different DMZ
segments need to be protected from each other.

Now, having drawn out type B above, I'll attempt to explain how to get
m0n0wall to work that way.  First, you'll need to make sure you have 3
interfaces.  Then you'll need to assign your three interfaces.  One will
have to be WAN, one will have to be LAN, then the 3rd (and others) can be
OPT1 (thru OPTn).

Once you have LAN and WAN configured and working properly (ie, a
workstation in LAN can access WAN resources adequately), then it is time
to configure the DMZ network.  Go into m0n0wall's web gui, and find the
interface you wish to act as your DMZ (probably OPT1, but not always).
You can give this interface a description (I call mine 'DMZ').  Enable
this interface, and don't bridge it with any other interface.  Give this
interface a private IP address range.  Assuming that LAN is, then using for the DMZ makes sense.  Save
and apply your changes.

If you have more than one public IP address to use, then next go to the
Proxy ARP configuration page, and add the extra public IP addresses you
want m0n0wall to proxy for.  Save and apply your changes.  If you intend
to use the default WAN IP, then this step can be skipped.

Next go to the NAT section.  If you have more than one public IP address
to use, go to "Server NAT" and add the addresses you wish to use.  Save
and apply your changes.  If you are using the default WAN IP, you don't
need to do anything with Server NAT.

Go to NAT, then Inbound.  Click the (+) button.  Pick the interface you
want the traffic to come in on.  If you intend to use the default WAN
address, choose 'WAN' from the pulldown.  If you have other public IP
addresses that you have added for proxy ARP and Server NAT, they'll be in
the pulldown list.  Choose your protocol (most Internet services use TCP,
DNS uses mostly UDP and TCP in some situations), the external port range,
the server's NAT IP (192.168.2.something in our examples), the server's
port (probably matching the first port in the range), a description so
you can keep track of it (THIS IS IMPORTANT!), and click the button that
says "Auto-add a firewall rule to permit traffic through this NAT rule".
Save and apply your changes.

That auto-generated firewall rule will have a description that matches
the one you set for the inbound NAT, with the word "NAT" in front of it.
This helps you keep track of which rules go with which NATs.

At this point, your service should be accessible from the Internet.  Go
to a machine outside of your LAN and DMZ and try to access it.  I usually
SSH to a server I have in a colo facility, then connect back to whichever
port I'm testing.

If you want your DMZ hosts to have access to the Internet via NAT (for
example, to download and install security patches, or to sync to a time
server, or do DNS lookups) then you'll need to add a new firewall rule.
and click the bottom most (+) button.  Choose action of 'pass', interface
'DMZ', protocol TCP/UDP (or whichever you want to do), source 'DMZ
Subnet', Destination NOT (checkbox) LAN Subnet, choose to log or not
(paranoid admins will log everything), and give it a good description.
Save and apply your changes.  This permits the DMZ to have nearly
unlimited access to the Internet, and no access to the LAN.  You can do
more complex sets of rules if you wish, this is an example of one way to
do it.  Bear in mind that if your DMZ host(s) get compromised, they can
then initiate attacks against the rest of the Internet with this enabled.
Make sure you understand the ramifications of this.

I hope that this helps you decide how you might want to set up your DMZ,
and gives some pointers on some of the steps necessary in one particular
way of doing it.  The above has worked for me, your mileage may vary.

Hope this helps,

PS, if this email is "good enough", perhaps some of the information could
migrate itself into the documentation project...