1. 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 1

2. 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 Intranet
Less More
Secure Secure
Firewall Firewall Firewall
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.
2 Firewall Magic

3. T ivoli
G ateway
S erver
E ndpoint 1 E ndpoint 2
Figure 2 Simple Tivoli environment
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

4. 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 G a te w a y B
P o rt
R ange
App App
App 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 G a te w a y B
App P o rt App
9401
App App
P o rt
App 9401 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.
4 Firewall Magic

5. Before After
GW GW
Listening port Listening port Listening port
(9495) (ephemeral) (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.
1
Whether a particular Tivoli application can user Upcall Port Consolidation is dependent on its Verison and Release
level. Please check with your Tivoli representative.
5

6. Zone
GWP EPP GW
TMA + TMA + TMA +
Upcaller Upcaller 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.
6 Firewall Magic

7. No direct routing
DMZ1 DMZ2
Internet Intranet
Less More
Secure Secure
Firewall Firewall Firewall
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
GW
Relay
Proxy
Firewall
GW
Relay
Proxy
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.
7

8. 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 Intranet
Less More
Secure Secure
Firewall Firewall Firewall
Server Server Server Server
Allowed Not 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.
8 Firewall Magic

9. TEC Server
TEC Gateway
More Secure
Firewall Firewall Proxies Firewall
Less Secure
Tivoli Endpoint
Event Sink
Non-TME Non-TME
Adapter Adapter
Figure 10 TEC event sink
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.
9

10. 10 Firewall Magic

11. 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

12. 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(logo)™ Tivoli Enterprise™
Redbooks™ Tivoli® 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