Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > CynderX-=-Security

Thread Tools


Posts: n/a

Building yourself a DMZ...
@ Articles -> Security Mar 07 2003, 04:13 (UTC+0)
danielrm26 writes: Building yourself a DMZ...
By danielrm26

Eventually, if you get interested enough in Security, you are going to
wonder what a DMZ is and why you should or should not have one. DMZ is
an acronym that stands for De-Militarized Zone, and in the 'real'
world it is the location between two hostile entities such as North
and South Korea. In the Security community, however, it is a separate,
untrusted network where boxes serving public services should be
placed. It is a buffer zone between a completely untrusted network
(like the Internet) and a relatively trusted network (like your
private LAN). The primary reason for implementing a DMZ is to keep
your public and private assets separated so that a compromise in the
public area does not automatically result in a compromise of your
private assets as well.

There are two main ways to implement a DMZ. The first is using three
NICs, as follows:

1 NIC for the WAN (your gateway to the Internet; everything comes and
goes through this NIC)
1 NIC for the LAN (behind this NIC is where you have all your private
assets, i.e. file servers, domain controllers, questionable material
collections, etc.)
1 NIC for the DMZ (this is where you put any machine that you want to
allow people on the Internet to connect to, i.e. web servers, ftp
servers, mail servers, game servers, etc.)

This is one method of creating a DMZ, but it is not the preferred
method. This configuration allows the security of both your DMZ and
your LAN to lie in one system. If your machine that has all three of
those NICs in it is compromised, so is your DMZ and your private
network as well. Basically, you are allowing the Internet to 'touch'
the very same machine that determines how secure your internal LAN is,
and this is not a good thing.

The better way to do this is with three separate networks - the
Internet, your DMZ, and your LAN. This is accomplished by using two
firewalls - one on the border of your WAN (which handles your
connection usually), and one on the border of your internal network.
Let's say that you have a broadband router (like a Netgear or Linksys)
and a Linux-based firewall (like Astaro or Smoothwall). What you do is
you put your router on your border (right behind your modem), and you
connect the LAN side of that router to a hub or switch. To that hub or
switch (your DMZ hub/switch) you use one of the ports to connect your
bastion host/public server(s). This machine (or machines) run the
services that you want people to be able to connect to from the
outside. This may be a web site, an FTP server, or a multiplayer game
like WCIII or Counterstrike. You want this machine to be hardened to
some degree (preferably very well), meaning that it is completely
patched and is not running anything that is vulnerable. As a general
rule though, you want anything put in the DMZ to be resistant to
attacks from the Internet since public access is the reason that you
are putting it out there in the first place. How to harden the servers
you put in your DMZ is outside the scope of this article, but suffice
it to say that you want to lock them down - no services running that
don't need to be, all updates applied, etc.

Now, to that same switch (the DMZ switch) you are going to attach
another network cable that goes to your internal firewall (your Linux
firewall). It is important to note that you want your strongest
firewall closest to your LAN; or, putting it another way, you want
your weakest firewall on your border. This may seem counterintuitive
but it's usually the right way to do things. Basically, you want the
most powerful and most configurable firewall protecting your LAN - not
your DMZ. As for your internal firewall, it's going to have two NICs
in it - one for the DMZ side and one for the private LAN side. Connect
the cable coming from your DMZ switch to the DMZ side of the internal
firewall (the external interface), and on the other side of the
firewall (the private LAN side) you connect a cable to another
hub/switch that all of your LAN computers will connect to.

If that was confusing, think of it this way:

Internet -> Modem
Modem -> Router
Router -> DMZ Switch
DMZ Switch -> WEB/FTP/Game Server
DMZ Switch -> Firewall External NIC
Firewall Internal NIC -> LAN Switch
LAN Switch -> LAN Systems

So let's take a look at the Security that is offered by this setup. At
the border you have NAT translation going on that passes only the
ports that you need to in order for the public to use the servers in
your DMZ. Let's say you are running a web server, an FTP server, and a
game server for a game called FooAttack. On your border
router/firewall you pass ports 80, 21, and 5347 (the FooAttack server
port). All other attempted connections to your external IP address
drop dead at your border; only those three ports passed above are
allowed through because of NAT. The nature of NAT dictates that only
return traffic (traffic is part of a connection that originated from
the inside of the NAT device) will be allowed back into the NAT'd
network. This side effect of NAT, while not its original or main goal,
is a fairly powerful Security feature. If your border device supports
filtering of any sort in addition to NAT then you can further lockdown
your network by restricting who can and cannot connect to the hosts in
your DMZ.

That first border layer, while being good, is just one piece of the
overall DMZ Security posture. The real beauty of this setup lies in
what happens if someone *does* get a hold of a machine in your DMZ.
Imagine that you have the setup like I laid out above, but unbeknownst
to you there is a major vulnerability in the web server you are
running. So here you are offering web content to the entire Internet
and someone runs the proper exploit vs. your machine and roots it. Now

Now nothing. Your second and more powerful firewall (the one that they
are still *outside* of) - does not pass *any* traffic from the DMZ
inside to the LAN. (In fact, you should have it where it won't even
answer ICMP requests from DMZ machines, so the odds are they won't
even know it's there.) And now, rather than being able to bounce
around on your juicy internal LAN like they planned, they are stuck in
the middle of a completely untrusted and unprivileged network that
doesn't have anything on it other than what you intended for public
viewing anyway.

This is a DMZ.

Even if they did know where the internal firewall was it wouldn't even
entertain the notion of passing connection attempts from the DMZ. This
internal layer of protection is NAT'd just like your first layer, only
there are no ports being passed inside like from the Internet to the
DMZ. Your second firewall actually has no idea what to do with packets
that are designed to initiate new connections with it, so it just
drops them. The only traffic that is going to make it through that
firewall is traffic that you specifically request be allowed through
by talking to a machine outside of that firewall, i.e. when you go to
/., it will allow the web content to come *back* to you so you can
view the page, but if someone tries to initiate a new connection to
you, they get dropped. Both NAT and SPI afford this protection to you,
each in different ways.

So, to sum it all up, imagine someone is scanning around looking for
web daemons to tear up and they find yours. Most inexperienced
attackers would assume that you are running something on your public
IP address, as if you have your main workstation is sitting right on
the Internet and it is running a web daemon. So, they connect to it,
get a web page, and then scurry to dig up their favorite HTTP exploit
tool that someone else wrote. What they don't know is that they are
actually connecting to a private IP in your DMZ. It has no 'real' IP
address as far as the Internet is concerned. If you didn't pass that
port at the border device then they wouldn't have seen anything at all
with their scan. But let's say they do see your web daemon because you
are passing port 80 through to your DMZ host running a web site, and
it turns out it has a vulnerability in it. They run their exploit and
get root on your box. This causes them tremendous joy, and they hurry
to tell all their buddies because they think they're Alan Cox. The
thing is, they have little to celebrate. All they have is a barebones
server with nothing of value on it - no vital info, no browsing
history, no personal information, nothing. In fact, all you have on
there is content that you wanted the public to see in the first place
(which is also safely backed up on your internal network and/or
removable media). So, they have root on the machine and ping around in
your DMZ and soon find that there isn't much there. If they are smart
they will do an ifconfig (or ipconfig if you swing that way) and find
out they are on a private subnet - but this gains them nothing. The
odds are that from there they'll either load some trash onto your
system or try and destroy it. Either way, it doesn't matter. The
moment you detect what has happened (tripwire, puresecure, etc) you
simply pull the plug, reinstall the box, and restore the backup.
Within a few minutes you have a brand-new system ready to go back
online, and at no point during the process was your private LAN in
danger. This is the benefit of running a true DMZ.

Hopefully this basic description of the general concept has been
helpful to someone. If you have any questions about DMZs or any other
Security topics, feel free to email me at hotmail.


(c) New Order /
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off