DMZ: DeMilitarized Zone in Networks

In the computer network world, a DeMilitarized Zone (DMZ) is a part of a network

separated from other systems by a Firewall which allows only certain types of n
etwork traffic to enter or leave. A DMZ or perimeter network is a network area (
a subnetwork) that sits between an organisation's internal network and an extern
al network, usually the Internet. For example, Public web servers might be place
d in such a DMZ. With the DMZ approach, large companies with complex e-commerce
Internet and extranet applications may have a two-tiered approach to firewall se
curity. The point of a DMZ is that connections from the internal and the externa
l network to the DMZ are permitted, whereas connections from the DMZ are only pe
rmitted to the external network---hosts in the DMZ may not connect to the intern
al network. This allows the DMZ's hosts to provide services to the external netw
ork while protecting the internal network in case intruders compromise a host in
the DMZ.
DMZ (demilitarized zone) is a computer host or small network inserted as a "neut
ral zone" between a company's private network and the outside public network. It
prevents outside users from getting direct access to a server that has company
data. (The term comes from the geographic buffer zone that was set up between No
rth Korea and South Korea following the UN "police action" in the early 1950s.)
A DMZ is an optional and more secure approach to a firewall and effectively acts
as a proxy server as well.
In a typical DMZ configuration for a small company, a separate computer (or host
in network terms) receives requests from users within the private network for a
ccess to Web sites or other companies accessible on the public network. The DMZ
host then initiates sessions for these requests on the public network. However,
the DMZ host is not able to initiate a session back into the private network. It
can only forward packets that have already been requested.
Users of the public network outside the company can access only the DMZ host. Th
e DMZ may typically also have the company's Web pages so these could be served t
o the outside world. However, the DMZ provides access to no other company data.
In the event that an outside user penetrated the DMZ host's security, the Web pa
ges might be corrupted but no other company information would be exposed. Cisco,
the leading maker of router s, is one company that sells products designed for
setting up a DMZ.
The De-Militarized Zone, or DMZ, is an expression that comes from the Korean War
. There, it meant a strip of land forcibly kept clear of enemy soldiers. The ide
a was to accomplish this without risking your own soldiers' lives, thus mines we
re scattered throughout the DMZ like grated Romano on a plate of fettucine :) Th
e term has been assimilated into networking, without the cheese :)
Network geeks use it to mean: "a portion of your network which, although under y
our control, is outside your heaviest security." Compared to the rest of your ne
twork, machines you place in the DMZ are less protected, or flat-out unprotected
, from the Internet.
Once a machine has entered the DMZ, it should not be brought back inside the net
work again. Assuming that it has been compromised in some way, bringing it back
into the network is a big security hazard.
Use of the DMZ
If you decide to build one, what do you do with it? Machines placed in the DMZ u
sually offer services to the general public, like Web services, domain name serv
ices (DNS), mail relaying and FTP services (all these buzzwords will be explaine
d next). Proxy servers can also go in the DMZ. If you decide to allow your users
Web access only via a proxy server, you can put the proxy in the firewall and s
et your firewall rules to permit outgoing access only to the proxy server.
As long as you've attended to the following points, your DMZ should be ok:
If you put a machine in the DMZ, it must be for a good reason. Sometimes, compan
ies will set up a few workstations with full Internet access within the DMZ. Emp
loyees can use these machines for games and other insecure activities. This is a
good reason if the internal machines have no Internet access, or extremely limi
ted access. If your policy is to let employees have moderate access from their d
esktops, then creating workstations like this sends the wrong message. Think abo
ut it: The only reason why they would use a DMZ machine is if they were doing so
mething inappropriate for the workplace !
It should be an isolated island, not a stepping stone. It must not be directly c
onnected to the internal network. Furthermore, it shouldn't contain information
that could help hackers compromise other parts of the network. This includes use
r names, passwords, network hardware configuration information etc.
It must not contain anything you can't bear to lose. Any important files placed
on the DMZ should be read-only copies of originals located within the network. F
iles created in the DMZ should not be able to migrate into the network unless an
administrator has examined them. If you're running a news server and would like
to archive news, make sure the DMZ has its own archival system.
What sort of things shouldn't you do? Example: If you're running an FTP server i
n the DMZ, don't let users put confidential information on there so they can get
it from home later.
It must be as secure a host as you can make it. Just because you're assuming it'
s secure doesn't guarantee that it is. Don't make it any easier for a hacker tha
n absolutely necessary. A hacker may not be able to compromise your internal net
work from your DMZ, but they may decide to use it to compromise somebody else's
network. Give serious thought to not running Windows on your DMZ machines; it's
inherently insecure and many types of intrusions can't be detected on Windows. L
inux or openbsd can provide most, if not all, the needed functionality along wit
h a more secure environment.

Security zones
The following list describes some types of network security zones that can be ap
plied to an organization.
Internet (uncontrolled zone)
Typically, the uncontrolled zone is the portion of the global Internet that is o
utside the boundaries of your organization. The untrusted zone is the most vulne
rable to security breaches because there might be few or no controls in place to
block intrusions to your intellectual property.
Do not install Tivoli Identity Manager components in an uncontrolled part of the
network. Do not allow Tivoli Identity Manager components to communicate with on
e another across an uncontrolled network without using secure communication mech
anisms such as SSL authentication.
Internet DMZ (controlled zone)
The Internet DMZ is an Internet-facing controlled zone that contains components
with which clients may directly communicate. The Internet DMZ provides a buffer
between the uncontrolled internet and your internal networks. This zone is typic
ally bounded by two firewalls, which enable you to control:
Incoming traffic from the internet to hosts in the DMZ
Outgoing traffic from hosts in the DMZ to the internet
Incoming traffic from internal networks to hosts in the DMZ
Outgoing traffic from hosts in the DMZ to internal networks.
Access control software can be deployed in the DMZ to control and monitor user a
ccess to resources in restricted and other controlled zones. Tivoli Identity Man
ager integrates with access control software, such as Tivoli Access Manager, to
protect access to the HTTP server that is used by the Tivoli Identity Manager Se
rver. The access manager product you implement should work with the bounding fir
ewalls to enable secure connectivity to Web clients without directly exposing Ti
voli Identity Manager components to potential attacks from the internet. For exa
mple, a user should be able to authenticate to the access management server, and
the access management server then determines which Web applications the user is
authorized to use.
If you do not intend to use integrated software to control access to the Tivoli
Identity Manager Web server, you can increase data security using reverse proxy
servers in each Internet DMZ. Each reverse proxy server can connect across a fir
ewall to the Web server, which resides in a more restricted intranet zone.
Production network (restricted zone)
A restricted zone supports functions to which access must be strictly controlled
; direct access from an uncontrolled network should not be permitted. In a large
enterprise, several network zones might be designated as restricted. As with an
internet DMZ, a restricted zone is typically bounded by one or more firewalls t
hat filter incoming and outgoing traffic.
Plan to place your Tivoli Identity Manager Server components as well as your bac
k-end servers (that do not directly interact with users) in a restricted zone.
Intranet (controlled zone)
Typically, a controlled zone, such as a corporate intranet behind one or more fi
rewalls, is not heavily restricted in use, but an appropriate span of control is
in place to assure that network traffic does not compromise the operation of cr
itical business functions.
You might need to place certain Tivoli Identity Manager components, such as the
database server or directory server, in the intranet network to maximize the per
formance of data throughput or the availability of certain components or applica
tions. In such cases, ensure that you do not compromise security in accessing th
ese components or in the data flow between the components.
Management network (secured zone)
In a secured zone, access is tightly controlled and available to only to a small
number of authorized users. Access to one area of the zone does not necessarily
apply to another area of the zone.
Depending on your security requirements, you can establish a secured zone that a
llows certain personnel to access specific Tivoli Identity Manager functions and
tasks.
Figure 9 illustrates how Tivoli Identity Manager can be deployed in an enterpris
e environment with different security zones. In this illustration, an access con
trol product, such as Tivoli Access Manager, controls access to Tivoli Identity
Manager functions that are made available through the Web server. In this scenar
io, the Tivoli Identity Manager Server uses back-end servers to store data in a
different security zone. In this case, the communication link should use encrypt
ion and authentication to protect the data flow.
Figure 9. Tivoli Identity Manager deployed in an access controlled environment
For more information about security planning, see Enterprise Security Architectu
re using IBM Tivoli Security Solutions, SG24-6014, available through the IBM Red
books Web site.