Living Next Door to the
DMZ Making the System z platform the ideal
host for a business-critical DMZ
BY PETER SPERA
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
ensure the safety of each border and provide
stability far beyond those borders. All social and
political tensions aside, the DMZ is actually a
relatively safe place compared to the interstate
highway. It’s safe because each side is vigilant
about monitoring and securing the physical
I L L U S T R AT I O N B Y B O B S C O T T
space between the two countries. Nobody can
get in or out of the DMZ without each side
knowing about it, and inspections and valida-
tions are required to gain entry.
As this term is applied to computer security
37 JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE JANUARY/FEBRUARY 2007
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
borders of the DMZ must be carefully evaluated.
If the need to pass through the DMZ is authentic
and validated, passage through the DMZ is per-
mitted. If a questionable path is taken or an
inappropriate package or payload’s discovered,
progress through the DMZ must be denied. The
DMZ is bounded by two firewalls, which are
very much like the fences and fortresses of the
military DMZ. These firewalls are the enforcers—
or guards—responsible for the validation and
passage of traffic in and out of the DMZ.
IBM SYSTEMS MAGAZINE 37
 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

38 JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE 38
 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

39 JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE 39
 Now that we have a physically secure and certified operating
environment, it’s necessary for the images that comprise the
DMZ to communicate. This can be done in two ways, ensuring
no communications are visible outside the System z platform
and yet maintaining the isolation needed to preserve the
integrity of the DMZ and the end-to-end solution.
LPAR-to-LPAR communications and networking is provided
by HiperSockets*, while communication within the z/VM envi-
ronment is provided by virtual LANs (VLANs). Multiple
HiperSockets or VLANs can be configured, all working together
to create the necessary environment and isolation points. Each
HiperSocket or VLAN is configured independently from the
various images and only the permitted, or configured, end-
points are allowed to communicate with each other. This
ensures the isolation and, later, the necessary capability to
audit and ensure the security of the end-to-end solution.
As Linux* has matured along with the various distributions,
there’s been a shift to provide a secure, enterprise-ready Linux
offering. Technologies such as firewall, mandatory access con-
trol, audit, etc., are all now an integral part of Linux distribu-
tions. Taking this commitment a step further, both Red Hat and
Novell have gained Common Criteria certifications (EAL4 aug-
mented with flaw remediation, ALC_FLR.3) on their offerings.
With the hardware and software technologies and certifications
40 JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE JANUARY/FEBRUARY 2007
previously mentioned, we can see the System z platform is
well-suited to host and maintain a business-critical DMZ.
Different Firewall Flavors
The next step in building a successful DMZ is to recognize fire-
walls aren’t a one-size-fits-all proposition. To understand how
various firewalls can be best utilized in a System z environ-
ment, it’s important to know at least three types of firewalls
can come into play in a simple enterprise DMZ. Network fire-
walls, application firewalls and personal firewall must all be
considered.
Network firewalls are generally associated with the term
firewall appliance. They provide robust interrogation of net-
work traffic, along with basic IP filtering and many other fea-
tures. They must play a central role in any end-to-end DMZ
solution, but it’s important to recognize they aren’t the only
firewall needed for a complete solution.
Next, we must consider the utility of a personal firewall.
While the term “personal” hardly fits the scheme of an enter-
prise DMZ, the utility of a simple IP filter with basic intrusion
detection/prevention certainly has its place. 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.
IBM SYSTEMS MAGAZINE 40
 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
firewall technologies have matured to the point of handling
these basic attacks. This, unfortunately, doesn’t stop malicious
attackers from uncovering new exploitable avenues. Some
attacks target application flaws or poorly configured applica-
tions. This highlights the need for a new type of firewall—the
application firewall—needed to protect the DMZ at the applica-
tion level.
Firewall Choices
StoneGate, from Atlanta-based StoneSoft, is a Linux
technology-based network firewall that can meet the stringent
requirements of a DMZ. StoneGate can provide the simple IP
41 JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE JANUARY/FEBRUARY 2007
traffic flowing to the Web server, ensuring the Web server or
Web-site guidelines, policies and rules are enforced and
auditable. When the application firewall is in place, it can
check for attacks (e.g. buffer overruns, defacement, URL para-
meter tampering, SQL injection, cookie tampering, etc.).
Thwarting these types of attacks before they get to the Web
server ensures errant transactions won’t get through to appli-
cation servers or corrupt data servers running on z/OS.
Putting the Pieces Together
Figure 3 (below) shows how all of the pieces outlined in this
article come together to create a secure DMZ. The System z
Figure 3
IBM SYSTEMS MAGAZINE 41
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 webApp.secure 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

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