DMZ. Many of us remember news clips. Living Next Door to the. Making the System z platform the ideal host for a business-critical DMZ

Transcription

1

2 DMZ Living Next Door to the Making the System z platform the ideal host for a business-critical DMZ BY PETER SPERA ILLUSTRATION BY BOB SCOTT Many of us remember news clips or history lessons about demilitarized zones (DMZs). If we were lucky, we didn t live near one, but we understood 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 space between the two countries. Nobody can get in or out of the DMZ without each side knowing about it, and inspections and validations are required to gain entry. As this term is applied to computer security 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 permitted. 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. JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE 37

3 Defining the Computing DMZ 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, providing isolation with the ultimate goal of protecting the private 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 military 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 applications 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 service, such as a Web server. The bastion firewall protects the service from the outside world and the many attacks that can come from this unprotected 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 controlled 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 attacks from the Internet while allowing legitimate customers to safely access and manage bank accounts via the Web server. Figure 1 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 malicious 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 critical 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 environment 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 manager. The z/vm OS also demonstrates a security commitment with a system integrity statement akin to that provided by z/os*. 38 JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE

4 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 environment 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, endpoints 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 control, audit, etc., are all now an integral part of Linux distributions. Taking this commitment a step further, both Red Hat and Novell have gained Common Criteria certifications (EAL4 augmented with flaw remediation, ALC_FLR.3) on their offerings. With the hardware and software technologies and certifications 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 firewalls aren t a one-size-fits-all proposition. To understand how various firewalls can be best utilized in a System z environment, it s important to know at least three types of firewalls can come into play in a simple enterprise DMZ. Network firewalls, application firewalls and personal firewall must all be considered. Network firewalls are generally associated with the term firewall appliance. They provide robust interrogation of network traffic, along with basic IP filtering and many other features. 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 enterprise 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. JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE 39

5 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 applications. This highlights the need for a new type of firewall the application firewall needed to protect the DMZ at the application 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 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 multiple firewalls and enforcing diverse security policies across an enterprise, all from a centralized management console. StoneGate has proven its commitment to the System z platform 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, additional 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 previous 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 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 parameter 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 application 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 40 JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE

6 hardware is divided using the certified LPAR and z/vm technologies. Network firewalls (StoneGate and IP/Tables), a personal 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 management is an asset in managing both Internet and intranet traffic, along with additional images for workload balancing. 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 isolated via strictly configured HiperSocket or VLAN connections. 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 hardwaremanagement 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 configuration is audited via z/vm. Additionally, StoneSoft provides a management console for auditing the policies on each of their firewalls. 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 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. JANUARY/FEBRUARY 2007 IBM SYSTEMS MAGAZINE 41