You are on page 1of 8

Living Next Door to the

DMZ Making the System z platform the ideal

host for a business-critical DMZ

M any of us remember news clips

or history lessons about demili-
tarized zones (DMZs). If we were
lucky, we didn’t live near one, but we under-
stood the need for these buffers, designed to
and network topology, the origins of a DMZ
should be kept in mind. Physical separation or
isolation needs to be guaranteed; monitoring
and maintenance of the DMZ must be diligent;
and who or what’s allowed to pass through the
ensure the safety of each border and provide borders of the DMZ must be carefully evaluated.
stability far beyond those borders. All social and If the need to pass through the DMZ is authentic
political tensions aside, the DMZ is actually a and validated, passage through the DMZ is per-
relatively safe place compared to the interstate mitted. If a questionable path is taken or an
highway. It’s safe because each side is vigilant inappropriate package or payload’s discovered,
about monitoring and securing the physical progress through the DMZ must be denied. The

space between the two countries. Nobody can DMZ is bounded by two firewalls, which are
get in or out of the DMZ without each side very much like the fences and fortresses of the
knowing about it, and inspections and valida- military DMZ. These firewalls are the enforcers—
tions are required to gain entry. or guards—responsible for the validation and
As this term is applied to computer security passage of traffic in and out of the DMZ.

attacks from the Internet while allowing legitimate customers
Defining the Computing DMZ
to safely access and manage bank accounts via the Web server.
To ensure the same terminology is used as the DMZ moves
from the military to the enterprise, the following is a baseline
definition: In the enterprise, a DMZ should be thought of as a
perimeter network, or the space between an external network—
often the Internet—and a private or protected network. The
perimeter network is home to a publicly available service, pro-
viding isolation—with the ultimate goal of protecting the pri-
vate network and its private services in the enterprise. Figure 1
(right) helps illustrate the DMZ and the terminology as it
applies to the enterprise.
There are many ways to talk about or describe the firewalls
and areas of a DMZ in the enterprise. Some use tactical mili-
tary terms like “bastion” and “choke point” for the firewalls,
while others use the colors of a stoplight to describe the zones
that firewalls create. The red zone is unsafe, identifying an area
where users aren’t trusted, likely the area outside the
bastion firewall. The yellow zone brings the notion of caution
with a little more trust and control. This is the area found
between the bastion and choke firewalls. The green zone is an
area of safety in the enterprise, sitting protected behind the
choke firewall. No matter how you describe the DMZ, as the
necessary elements to fortify mission-critical data and applica-
tions are examined, it’s clear the IBM* System z* platform
should play a role.
As the fundamentals of a DMZ are examined, the strengths
of System z hardware and software will become evident for
this critical enterprise entity. The DMZ can exist next door to
the enterprise jewels running on z/OS*, with both the DMZ and
enterprise data safe and sound at home on the mainframe. The
DMZ needs to be bounded or protected by two firewalls to
create a safe environment or zone for a publicly available ser-
vice, such as a Web server.
The bastion firewall protects the service from the outside
world and the many attacks that can come from this unpro-
tected environment. The choke firewall sits between the public
service—a Web server in this case—and the private network,
acting as the last line of defense between the safer, more con-
trolled DMZ and the critical business applications found in the
private network. The choke firewall will only let known traffic
from the service pass through to the secure private network. A
typical scenario is illustrated in Figure 2 (right), with a Web
server that’s available via the Internet. The Web server needs to
be isolated, via a DMZ, from the enterprise’s internal network
and transaction and data services and, more importantly, from
the potential attacks and threats found on the Internet.
In this example, it’s seen that an Internet-banking customer
can access the bank’s Web site to transfer funds from a savings
account to a checking account. The bastion firewall will thwart

with a system integrity statement akin to that provided by
Figure 1 z/OS*.

Figure 2

The choke firewall provides another layer of protection or level

of indirection by only permitting the known Web server to
pass traffic through to the application server. All other traffic
would be stopped. There’s no communication path for a mali-
cious user or any malicious code to get through the DMZ, since
there’s no networking path from the Bastion firewall to the
choke firewall.

Technologies and Building Blocks

Now that the anatomy of a basic DMZ is understood, the criti-
cal System z technologies and required building blocks can be
identified. To start, we need to ensure the various images and
networks that run with the physically secure System z environ-
ment are isolated from one another. This can be accomplished
with an LPAR and z/VM*. They can be used separately or in
conjunction to provide the image isolation needed to construct
a flexible, expandable, workload-balanced DMZ. IBM’s LPAR
technology has been Common Criteria certified at EAL4 and
EAL5 for several hardware generations. In addition, z/VM is
also Common Criteria certified at EAL3, incorporating
Resource Access Control Facility (RACF*) as its security man-
ager. The z/VM OS also demonstrates a security commitment

Now that we have a physically secure and certified operating previously mentioned, we can see the System z platform is
environment, it’s necessary for the images that comprise the well-suited to host and maintain a business-critical DMZ.
DMZ to communicate. This can be done in two ways, ensuring
no communications are visible outside the System z platform Different Firewall Flavors
and yet maintaining the isolation needed to preserve the The next step in building a successful DMZ is to recognize fire-
integrity of the DMZ and the end-to-end solution. walls aren’t a one-size-fits-all proposition. To understand how
LPAR-to-LPAR communications and networking is provided various firewalls can be best utilized in a System z environ-
by HiperSockets*, while communication within the z/VM envi- ment, it’s important to know at least three types of firewalls
ronment is provided by virtual LANs (VLANs). Multiple can come into play in a simple enterprise DMZ. Network fire-
HiperSockets or VLANs can be configured, all working together walls, application firewalls and personal firewall must all be
to create the necessary environment and isolation points. Each considered.
HiperSocket or VLAN is configured independently from the Network firewalls are generally associated with the term
various images and only the permitted, or configured, end- firewall appliance. They provide robust interrogation of net-
points are allowed to communicate with each other. This work traffic, along with basic IP filtering and many other fea-
ensures the isolation and, later, the necessary capability to tures. They must play a central role in any end-to-end DMZ
audit and ensure the security of the end-to-end solution. solution, but it’s important to recognize they aren’t the only
As Linux* has matured along with the various distributions, firewall needed for a complete solution.
there’s been a shift to provide a secure, enterprise-ready Linux Next, we must consider the utility of a personal firewall.
offering. Technologies such as firewall, mandatory access con- While the term “personal” hardly fits the scheme of an enter-
trol, audit, etc., are all now an integral part of Linux distribu- prise DMZ, the utility of a simple IP filter with basic intrusion
tions. Taking this commitment a step further, both Red Hat and detection/prevention certainly has its place. A personal firewall
Novell have gained Common Criteria certifications (EAL4 aug- can be deployed in a separate image for purposes of isolation,
mented with flaw remediation, ALC_FLR.3) on their offerings. or it could be integrated into the image it’s protecting, much
With the hardware and software technologies and certifications like the firewall used to protect individual workstations.

A personal firewall can be deployed in
a separate image for purposes of isolation,
or it could be integrated into the image
it’s protecting, much like the firewall used
to protect individual workstations.
Over the years, networking threats have been defined and traffic flowing to the Web server, ensuring the Web server or
firewall technologies have matured to the point of handling Web-site guidelines, policies and rules are enforced and
these basic attacks. This, unfortunately, doesn’t stop malicious auditable. When the application firewall is in place, it can
attackers from uncovering new exploitable avenues. Some check for attacks (e.g. buffer overruns, defacement, URL para-
attacks target application flaws or poorly configured applica- meter tampering, SQL injection, cookie tampering, etc.).
tions. This highlights the need for a new type of firewall—the Thwarting these types of attacks before they get to the Web
application firewall—needed to protect the DMZ at the applica- server ensures errant transactions won’t get through to appli-
tion level. cation servers or corrupt data servers running on z/OS.

Firewall Choices Putting the Pieces Together

StoneGate, from Atlanta-based StoneSoft, is a Linux Figure 3 (below) shows how all of the pieces outlined in this
technology-based network firewall that can meet the stringent article come together to create a secure DMZ. The System z
requirements of a DMZ. StoneGate can provide the simple IP
Figure 3

filtering needed by the choke firewall and the complex packet
filtering and real-time intrusion prevention the bastion firewall
needs. StoneSoft provides a built-in VPN for managing multi-
ple firewalls and enforcing diverse security policies across an
enterprise, all from a centralized management console.
StoneGate has proven its commitment to the System z plat-
form through its support of HiperSockets, Queued Direct I/O
(QDIO) and CTC, providing physically secure communications
through the DMZ to mission-critical applications running on
z/OS. Additionally, StoneGate supports the idea of a
workload-balanced firewall farm that can be configured to
meet the load peaks and high-availability (HA) requirements of
the enterprise without the need for additional hardware.
Since the DMZ is a physically secure environment, addi-
tional alternatives should be considered. Linux ships with a
simple IP filtering firewall—known as IP/Tables—which can be
used to meet the needs of a choke firewall. If the choke firewall
is at the boundary of a z/OS system, the Intrusion Detection
Services (IDS) provided by Communications Server for z/OS
should strongly be considered to fulfill this need.
WebScurity’s is an example of an application
firewall. It’s important to note application firewalls alone aren’t
enough, but when used with traditional network firewalls, they
provide an additional layer of security in the DMZ. In the pre-
vious example of a Web server, a Web-application firewall
would be inserted into the DMZ between the bastion firewall
and the Web server. Its job would be to interrogate the actual

hardware is divided using the certified LPAR and z/VM tech- IBM Commitment
nologies. Network firewalls (StoneGate and IP/Tables), a per- IBM continues to show a commitment to security as an
sonal firewall (Communication Server for z/OS IDS) and an increasing number of end-to-end scenarios and enterprise
application firewall ( can all play a critical solutions, including DMZ, are tested. Components are tested as
role. In the case of StoneGate, centralized policy manage- part of the normal production cycle. However, more complex,
ment is an asset in managing both Internet and intranet customer-driven scenarios are deployed to perform internal
traffic, along with additional images for workload balanc- ethical hacking on end-to-end solutions and to document
ing. Once the Internet or intranet traffic enters the tested scenarios as well as best practices. In some cases, such
StoneGate or Bastion firewall, it’s no longer physically as with StoneGate and, this testing was more
accessible by the external networks, and all traffic is iso- stringently documented in support of an initiative for Linux
lated via strictly configured HiperSocket or VLAN connec- Utilities for IBM System z platforms.
tions. An image can’t communicate with another image Clearly, the safety of z/OS can be enhanced by bringing the
unless a path is configured. critical components of the DMZ into the System z platform,
Once the end-to-end solution is deployed and secured, it’s where the hardware and software can work together to provide
important to be able to audit and ensure the solution remains the security, isolation, function and auditability needed for an
secure. Auditability at each level is an additional benefit of end-to-end enterprise solution.
the System z DMZ solution. From the hard ware-
management console (HMC) through z/VM to Linux, the DMZ Peter Spera is a senior software engineer with
can be constructed and audited to ensure it meets the needs IBM. He’s been involved in various aspects of
of the enterprise today and in the future. The HiperSocket mainframe and system security since he joined the
configuration is audited at the HMC while the VLAN configu- company in 1992. Currently, he’s focused on
ration is audited via z/VM. Additionally, StoneSoft provides a security for Linux on System z, but he’s involved in other areas,
management console for auditing the policies on each of such as system integrity and vulnerability reporting. Peter can
their firewalls. be reached at