Redbooks Redpaper

Dave Thiessen

Overview
Here is an overview of the topics that we cover in this Redpaper: Firewalls and DMZs - A Quick Overview Tivoli Framework Communications - A Quick Overview Tivoli Framework 3.7.1 Single Port Bulk Data Transfer Endpoint Upcall Port Consolidation Firewall Solutions Toolbox Endpoint and Gateway Proxy - Bringing the Infrastructure Inside Relays - Crossing Multiple DMZs Unidirectional Communications The Event Sink - Collecting TEC Events from Non-TEC Sources Summary

Firewalls and DMZs - A Quick Overview

All businesses today increasingly rely on internet technologies to interact with employees, partners, suppliers, and customers. Customers use a company's web server to directly browse catalogs and order products, tracking them all the way to delivery. Web applications allow them to automatically place "just in time" orders to their suppliers for components required to produce their product. Employees use web applications to select their benefits, submit their expenses, do price quotations for their customers, submit and track their orders, and most of the other activities in their job. Everyone knows the internet is an indispensable medium for doing business. While the internet provides many benefits and opportunities, it also presents many threats. Web servers that provide valuable applications contain product and customer data that is private to the company and critical to their survival. Protecting that data and the systems they are stored on from competitors and hackers is of utmost importance. Therefore all companies using the internet will employ some level of firewall security to "let the good guys in, and keep the bad guys out".

Copyright IBM Corp. 2002. All rights reserved.

ibm.com/redbooks

A firewall is a device that controls the types of communication allowed between different points in a network. Firewalls are configurable to allow or disallow communications based on various characteristics. The most common criteria used for restricting communications are by ports, by protocols, and by direction. For example a firewall might be configured to only allow communications from the external network (internet) using port 80 and HTTP protocol. The external network (internet) is referred to as "outside" the firewall and the internal network (intranet) is referred to as "inside" the firewall. In most cases though, companies will not just have one firewall in place. Rather they will implement multiple layers of security between the internet and their internal systems, each separated by a group of firewalls. These layers of security are known as Demilitarized Zones (DMZs), with the outer layers being least secure and the inner layers being most secure. The following picture shows a network with two DMZs between the internet and the intranet or internal network.

DMZ1

DMZ2

Internet
Less Secure

Intranet Firewall Firewall Firewall

More Secure

Server

Server

Server

Server

Figure 1 Example of network with two DMZs

Besides being able to enforce different levels of security within different zones, the use of DMZs provides additional buffers of security that a single firewall could not. Typically a network containing DMZs will be set up such that there is no direct routing allowed. This means that a system in one zone is only able to establish communications with a system in the adjacent zone. In other words, no system on the external internet would ever be allowed to directly contact a system in the intranet or most secure zone for any reason, no matter what port or what protocol they were using. This puts another challenge in the way of hackers on the internet who would like to access the company's internal systems. They cannot access the most sensitive machines by gaining access to one system in a DMZ, but would have to navigate their way through several stages.

Tivoli Framework Communications - A Quick Overview

A simple Tivoli environment consists of the Tivoli server, gateway, and endpoints. The endpoints communicate with the server through a gateway and the gateway communicates directly with the server.

Firewall Magic

T ivoli S erver

G ateway

E ndpoint 1
Figure 2 Simple Tivoli environment

E ndpoint 2

Your Tivoli environment can be as simple or complex as your network demands. You can install multiple gateways in a Tivoli region to manage large numbers of endpoints effectively. These gateways can be geographically dispersed from the server or centralized, according to the requirements of the installation. Several types of communication are employed between the Tivoli server, gateways and endpoints. For instance, when an endpoint joins the network, it identifies itself to its gateway through a login process. Once it is logged in, the endpoint communicates to its gateway through upcalls when it has data or responses to return to the gateway or the server. For example, an upcall would occur when an inventory scan has completed on the endpoint, and the data is ready to be returned to the server. Also the gateway communicates to the endpoint through downcalls. For example, if the gateway has a software distribution package to deliver, it will perform a downcall to the endpoint. The protocol or language used for communications between a gateway and its endpoints is a proprietary protocol called Endpoint Communication Protocol or ECP. ECP is a high-level protocol that uses TCP/IP as its transport mechanism. It requires certain known ports to be enabled for its communications. Almost all management functions also require communication between the server and the gateway, or even between gateways. For instance, software distributions are passed from server to gateway, perhaps by way of several repeater systems, using a Tivoli facility called Bulk Data Transport or BDT. When one or more firewalls exist in a Tivoli environment, between servers and gateways, or between gateways and endpoints, the communication channels permitted by these firewalls are limited. In past releases, the Tivoli management applications required communications over a range of open ports. This was not conducive to a highly secure environment. In a secure firewall environment, clearly the fewer ports that are open for communications across the firewall, the better. Also the fewer protocols that are allowed to cross the firewall, the better. Tivoli needed to provide solutions to allow its applications to work in an environment with multiple firewalls and DMZs without compromising the security goals of its customers. These solutions have been delivered in several stages, and all of them are available today.

Tivoli Framework 3.7.1

The first stage of the solution was delivered with the Tivoli Management Framework 3.7.1, with two solutions designed to consolidate port usage. For communications between servers and gateways, Single Port Bulk Data Transfer was introduced. Connections between gateways and endpoints were addressed by Endpoint Upcall Port Consolidation. Each of these solutions are described briefly below. 3

Single Port Bulk Data Transfer

Included in the base release of Tivoli Management Framework 3.7.1 was a mechanism to reduce the exposure from Tivoli communications between servers and gateways. For Bulk Data Transfers between these systems, such as for software distributions, communications could now be consolidated to a single port between systems. The solution is illustrated below.

S erver A App App App

P o rt R ange

G a te w a y B App App App

F ir e w a ll
Figure 3 Bulk Data Transfer environment before Tivoli Management Franework 3.7.1

S e rve r A App App App

P o rt 9401 P o rt 9401

G a te w a y B App App App

F ir e w a ll
Figure 4 Bulk Data Transfer environment with Tivoli Management Franework 3.7.1

This solution addressed the challenge of making connections between servers and gateways more secure, by consolidating communications on a single port.

Endpoint Upcall Port Consolidation

Endpoint Upcall Port Consolidation is delivered with Fixpack 1 for Tivoli Management Framework 3.7.1. It affects the behavior of management applications that need to initiate communications from an endpoint to a server. An example of this would be an application that needs to deliver events to the Tivoli Enterprise Console (TEC) server. Before Tivoli had this capability, management applications running on an endpoint behaved as in the Before picture below.

Firewall Magic

Before
GW GW

After

Listening port (9495)

Listening port (ephemeral)

Listening port (9495)

TMA

Upcaller

TMA

Upcaller

Figure 5 Upcall port consolidation

When a management application (Upcaller) on the endpoint needed to communicate with the server throught its gateway, it first contacted its Tivoli Management Agent (TMA). The agent would inform the gateway of the request. After this, the gateway would directly contact the endpoint application on an ephemeral (dynamically chosen) port and complete the conversation on that port without further involvement of the TMA. The fact that a different port could be used for each communication caused an obvious security issue. With the installation of Upcall Port Consolidation in Fixpack 1, all communications between an upcalling application and its gateway are now channelled through the listening port of the endpoint's TMA (by default port 9495). 1 This solution consolidates communications between a single endpoint and its gateway onto a single port. But what about the situation where you have multiple endpoints and gateways needing to communicate with each other over a firewall, especially where gateways and endpoints may not all be using the same ports? This and other issues involving communication across firewalls between gateways and endpoints are addressed in several ways by the Tivoli Firewall Solutions Toolbox, which we will describe next.

Firewall Solutions Toolbox

The Tivoli Firewall Solutions Toolbox was introduced in 2002 as patch 1.2-TFST-0001. It is available for download from the Tivoli Support web site at http://www.tivoli.com/support. The Firewall Solutions Toolbox completes the picture by incorporating a group of firewall solutions, each with increasing levels of security. Each customer can choose which level is appropriate for them.

Endpoint and Gateway Proxy - Bringing the Infrastructure Inside

To more completely consolidate communications over a firewall between gateways and endpoints, the Tivoli Security Toolbox introduces the Endpoint and Gateway Proxy functions. On the secure side of the firewall, there is an endpoint proxy that connects to the gateway as if it were the endpoint itself. On the less secure side of the firewall, the endpoints are connected to a gateway proxy, which acts as if it were the real gateway. The gateway proxy and the endpoint proxy then communicate with each other through the firewall.

Whether a particular Tivoli application can user Upcall Port Consolidation is dependent on its Verison and Release level. Please check with your Tivoli representative.

Zone
GWP EPP GW

TMA + Upcaller

TMA + Upcaller

TMA + Upcaller

Firewall

Figure 6 Endpoint and Gateway proxies

Just as multiple endpoints can connect to a single gateway and multiple gateways to a single server, multiple endpoints can connect to a single gateway proxy and multiple gateway proxies can connect to a single endpoint proxy. The endpoint proxy emulates all the endpoints to the gateway that manages them. The endpoint and gateway proxies consolidate all communications between multiple endpoints and gateways over a single port. All such communications are encapsulated in a connection-based TCP protocol. Another benefit to the endpoint and gateway proxies is that they allow customers to keep all of their Tivoli Management infrastructure (servers and gateways) inside their most secure zones, and only the endpoints and their gateway proxies outside. The endpoint and gateway proxy solution effectively addresses the issues of communicating over a firewall between the gateway and the endpoint. But what if there is more than one firewall between these systems? In most installations, there will be multiple security zones or DMZs, each separated by a firewall layer, between a gateway and its endpoints. For these environments, the next component, relays, provides a solution.

Relays - Crossing Multiple DMZs

When a network includes several firewalls separating demilitarized zones (DMZs) of progressively lower security as they approach the Internet, the configuration becomes more complex. Although the gateway proxy and endpoint proxy continue to communicate with the endpoint and the gateway, respectively, they are usually not allowed to connect directly across multiple zones. This would defeat the purpose of having multiple firewall zones in place. An important principle of DMZ security is to prevent direct routing across multiple zones. Adhering to a typical security policy, a machine in one zone is only allowed to communicate directly with a machine in its adjacent zone.

Firewall Magic

No direct routing
DMZ1 DMZ2

Internet
Less Secure

Intranet Firewall Firewall Firewall

More Secure

Server

Server

Server

Server

Figure 7 Crossing DMZs

To comply with this requirement, the Tivoli Management Framework Firewall Security Toolbox provides a relay function, which can be installed between the firewalls in each of the DMZs. Each relay passes information to and from a relay in the next DMZ and ultimately, to and from the endpoint proxy and gateway proxy. This concept is illustrated by the following picture.

EP Proxy

Firewall

Relay

GW Proxy

Firewall
GW Proxy

Relay

Firewall
GW Proxy
Figure 8 Using relays to cross DMZs

In most multiple DMZ environments, a different port will be required to cross each firewall boundary. This series of staggered ports creates another barrier for intruders wanting to access the most secure parts of the network. The relays are easily configured to comply with this requirement. With this solution, multiple DMZ zones are traversed safely, as each component only communicates with components in the adjacent zone.

Unidirectional Communications
In many secure environments, administrators will impose a restriction on the direction of communications. This restriction will, with the exception of web site access, only allow connections to be initiated by machines in more secure zones to machines in less secure zones. The restriction seeks to prevent unauthorized machines, posing as legitimate systems, from accessing the secure side of the network. This is known as unidirectional communications, and is illustrated by the following picture.

DMZ1

DMZ2

Internet
Less Secure

Intranet Firewall Firewall Firewall

More Secure

Server

Server

Server

Server
Not Allowed

Allowed

Figure 9 Unidirectional communications across firewalls

The Tivoli Security Toolbox solution allows for the configuration of endpoint and gateway proxies, and relays, such that all connections are initiated only from more secure zones to less secure zones. This configuration is transparent to the Tivoli applications, using the proxies and relays to complete the management tasks while conforming to the unidirectional communications rule. Simply stated, when an endpoint initiates an upcall saying it has data to send, the upcall is intercepted and held at its gateway proxy. At configurable intervals, the endpoint proxies poll their gateway proxies to see if any of them have data to send. In this way, all communications originate from the most secure side of the network, and Tivoli is able to accomplish its management tasks.

The Event Sink - Collecting TEC Events from Non-TEC Sources

Tivoli Enterprise Console, or TEC, consolidates events from many sources to a central console, where they are correlated and presented to an administrator for automated or explicit responses. When these events are collected from machines in the Tivoli environment (running the Tivoli Management Agent), the interaction with the TEC server is handled in a secure environment using the facilities described above. Even the unidirectional communications requirement is solved by implementing a polling mechanism from the secure side of the network. The one remaining challenge is how to collect events from non-Tivoli machines in this environment. For this requirement, the Tivoli Security Toolbox includes the Event Sink. The Event Sink, which is installed on an endpoint outside the firewall, collects events sent from non-Tivoli machines as if it were the TEC server itself. It then sends these events on to the real TEC server as though they were Tivoli events. The Event Sink can be accessed and used by multiple non-Tivoli event-generating machines, as illustrated in the following picture.

Firewall Magic

TEC Server TEC Gateway

More Secure
Firewall

Firewall Proxies

Firewall

Less Secure

Tivoli Endpoint Event Sink

Non-TME Adapter
Figure 10 TEC event sink

Non-TME Adapter

Summary
With the solutions described in this whitepaper, Tivoli does a complete job of accomplishing its management functions without asking administrators to compromise the security of their installations. Tivoli applications can consolidate their communications on a single port, use relays to navigate across multiple security zones, and conform to a unidirectional communication requirement. These capabilites give Tivoli a strong competitive advantage over other system management solutions, which often still require their customers to open a range of communication ports and protocols through firewall environments. Customers are advised to carefully compare Tivoli's Firewall solutions with those of other vendors when considering a system management investment.

10

Firewall Magic

Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Send us your comments in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an Internet note to: redbook@us.ibm.com

Copyright IBM Corp. 2002. All rights reserved.

11

Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493 U.S.A.

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:
IBM Redbooks Redbooks(logo) Tivoli Tivoli Enterprise Tivoli Enterprise Console

The following terms are trademarks of International Business Machines Corporation and Lotus Development Corporation in the United States, other countries, or both:
Lotus Word Pro

The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.

12

Tivoli Firewall Magic