Front cover Implementing IBM Tivoli Remote Control Across Firewalls Achieve Remote Control without sacrificing security Guide for TCP/IP ports used and troubleshooting Set up a secure Remote Control environment based on realistic scenarios Edson Manoel Francesca Balzi Sebastien Fardel Venkata R Reddy ibm.
International Technical Support Organization Implementing IBM Tivoli Remote Control Across Firewalls April 2003 SG24-6944-00
Note: Before using this information and the product it supports, read the information in “Notices” on page xiii. First Edition (April 2003) This edition applies to the following products: IBM Tivoli Remote Control 3.8, IBM Tivoli Management Framework 4.1, and Tivoli Firewall Security Toolbox 1.3. © Copyright International Business Machines Corporation 2003. All rights reserved. Note to U.S.
Contents Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Trademarks . . . . .
Chapter 3. Implementation scenario: Standalone Proxies . . . . . . . . . . . . 93 3.1 Scenario overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 3.2 Environment description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 3.2.1 Technical infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.2.2 Data flow description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.
Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Event Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Tivoli environments with single firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Tivoli environments with multiple firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Sending events across firewalls . . . . . . . . . . . . . . . . . . . . . . .
vi IBM Tivoli Remote Control Across Firewalls
Figures 1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 1-9 2-1 2-2 2-3 2-4 2-5 3-1 3-2 3-3 3-4 3-5 4-1 4-2 4-3 5-1 5-2 5-3 5-4 5-5 5-6 A-1 A-2 A-3 Parent-Child hierarchy in RC Proxy-TFST architecture . . . . . . . . . . . . . 11 RC session data flow in a single-TMR environment . . . . . . . . . . . . . . . 14 RC session data flow in a multi-TMR environment . . . . . . . . . . . . . . . . 22 RC session data flow in an RC Gateway/single-TMR environment. . . . 32 RC session data flow in an RC Gateway/multi-TMR environment.
viii IBM Tivoli Remote Control Across Firewalls
Tables 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 2-10 2-11 2-12 2-13 2-14 3-1 3-2 3-3 4-1 4-2 4-3 4-4 4-5 4-6 4-7 RC ports for unidirectional communication - Parent/initiator . . . . . . . . . 63 RC ports for unidirectional communication - Parent/listener . . . . . . . . . 64 RC ports for unidirectional communication - Relay - Parents/initiators . 65 RC ports for unidirectional communication - Relay - Parents/listeners . 67 RC ports for bidirectional communication . . . . . . . . . . . . . . . . . . . . . . .
x IBM Tivoli Remote Control Across Firewalls
Examples 1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 1-9 1-10 1-11 1-12 1-13 1-14 1-15 1-16 1-17 1-18 1-19 1-20 1-21 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 3-12 3-13 3-14 3-15 3-16 4-1 RC session trace in a single-TMR environment. . . . . . . . . . . . . . . . . . . 16 The remote_control method from a single-TMR environment . . . . . . . . 19 The is_proxied_ep method from a single-TMR environment . . . . . . . . . 20 The nd_start_target method from a single-TMR environment . . . . . . . .
4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-10 4-11 4-12 4-13 5-1 5-2 5-3 5-4 5-5 5-6 5-7 5-8 5-9 5-10 5-11 5-12 5-13 5-14 5-15 5-16 5-17 5-18 5-19 xii RC Target Proxy configuration file example . . . . . . . . . . . . . . . . . . . . 130 Modification settings example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 The Relay.cfg after the installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 The Relay.cfg file after the changes . . . . . . . . . . . . . . . . . . . . . . . . . .
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.
Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX® CT™ ™ Illustra™ IBM® ibm.com® pSeries™ Redbooks™ Redbooks (logo) SecureWay® SP™ SP1® ™ Tivoli Enterprise™ Tivoli Enterprise Console® Tivoli® TME 10™ TME® 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.
Preface System administrators and help desk personnel sometimes need access to remote PCs in order to resolve problems and assist users with important business applications. Most organizations will, at some point, need to expand their management of systems from their regular systems management environment to those that exist on the other side of firewalls.
Sebastien Fardel is an Advisory IT Specialist at IBM Corporation, Global Services, Switzerland, acting as a Tivoli Architect in the Performance and Availability and Configurations and Operations areas. He has been in the IT industry since 1996 and has experience in IT infrastructure management, programming, and Systems Management area. His e-mail is sfa@ch.ibm.com. Venkata Reddy is a software Engineer working for IBM Software Labs in Bangalore, India.
Comments welcome Your comments are important to us! We want our Redbooks™ to be as helpful as possible. Send us your comments about this or other Redbooks 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 Mail your comments to: IBM Corporation, International Technical Support Organization Dept.
xviii IBM Tivoli Remote Control Across Firewalls
Part 1 Part 1 Concepts and planning © Copyright IBM Corp. 2003. All rights reserved.
2 IBM Tivoli Remote Control Across Firewalls
1 Chapter 1. Remote Control sessions overview System administrators often need to manage servers or workstations in distant secure locations — for example, in an outsourcing project. If a problem on one of these machines requires attention, the administrator traditionally has two options: try to resolve the problem over the telephone with an authorized person (with a high chance of miscommunication); or relocate to the user’s location for problem determination (which is often impractical).
1.1 IBM Tivoli Remote Control overview The purpose of this chapter is not only to explain how IBM Tivoli Remote Control works in general, but to emphasize its architecture and functionality in a firewall environment. Even though the architecture and implementation of IBM Tivoli Remote Control may differ when firewalls are involved from implementation to implementation, the IBM Tivoli Remote Control functionality will remain the same.
Managed Node A Tivoli Managed Node runs the same software that runs on a TMR Server. Managed Nodes maintain their own Object DataBases, which can be accessed by the TMR Server. When Managed Nodes communicate directly with other Managed Nodes, they perform the same communication or security operations as they would perform with the TMR Server. Although there is no clear distinction between managed systems and managing systems, the introduction of the Endpoints architecture leads to a paradigm shift.
6 Relay The Relay component’s purpose is to pass information sent to it up or down the chain to an Endpoint Proxy, Gateway Proxy, or other Relays. This component is optional and is part of the Tivoli Firewall Security Toolbox. It must be installed in the network zone between the Endpoint Proxy and the Gateway Proxy. Multiple Relays could be chained to allow this connection if Endpoint Proxy and Gateway Proxy are separated by multiple network zones.
For more information about TMR Server, Managed Node, Endpoint Gateway, Endpoint and Policy Region, refer to Tivoli Management Framework Planning for Deployment Guide, GC32-0803. For more information about Endpoint Proxy, Gateway Proxy and Relay, refer to Firewall Security Toolbox User ’s Guide, GC23-4826 and to Tivoli Enterprise Management Across Firewalls, SG24-5510. 1.1.
RC Target The Remote Control Target component is automatically installed on each Endpoint when a session from a Remote Control Controller is initiated. This component is also known as Target. RC Controller Proxy The Remote Control Controller Proxy is an optional component which could be used to simplify the communication between Controllers and Targets in a firewall environment through a common port.
Endpoint, Remote Control Controller or Remote Control Target Policy Region (blue line) Collection (blue line) Remote Control Tool Endpoint Proxy or Gateway Proxy (black line) Remote Control Target Proxy or Remote Control Controller Proxy Instance 1 of the Tivoli Firewall Security Toolbox Relay (black line) Firewall Network zone secured by a firewall (red line) Tivoli Framework communication (black line) Tivoli Remote Control session communication (blue line) Tivoli proprietary protocol encapsulat
1.1.4 Parent-Child concept The hierarchy of the components of either the Tivoli Firewall Security Toolbox or the Remote Control Proxies (either RC Target Proxy or RC Controller Proxy) is presented in terms of a Parent-Child relationship. Such hierarchy is a subset of the whole Tivoli Top-Down hierarchy. It means that the starting point is the TMR Server and the ending point is the Endpoint. The components close to the TMR Server will be Parents and the ones close to the Endpoints will be Children.
Parent RC Target Proxy TMR Server Endpoint GW Endpoint Proxy Parent Firewall Child Parent DMZ Relay Firewall Child Child Firewall Gateway Proxy Gateway Proxy Endpoint Endpoint Child RC Contr. Proxy DMZ Child RC Contr. Proxy External Figure 1-1 Parent-Child hierarchy in RC Proxy-TFST architecture Note: Understanding this hierarchy is important when you install and configure the components. 1.1.
Bidirectional communication: In simple secure environments, communications could be initiated either by a component on the less secure zone or by the one located on the more secure zone. For example, an Endpoint initiates an upcall that is intercepted by the Gateway Proxy and further sent to the Endpoint Proxy, which in turn will forward it to the Tivoli Endpoint Gateway. In reverse, the Endpoint Proxy could initiate a downcall to the Endpoint without any restrictions.
The Remote Control session scenarios could be divided into the following categories. Sessions in a single-TMR environment with no firewall restrictions. It is important to understand how these kinds of sessions work, because the basic concepts remain valid for all others scenarios. Sessions in a multi-TMR environment with no firewall restrictions. At first it seems similar to the way Remote Control works in a single-TMR environment.
1.2.1 Session in a single-TMR environment In order to fully understand how a Remote Control session works, it is important to know in detail the entire data flow between the different elements of IBM Tivoli Remote Control, starting with the most simple scenario. Data flow for single-TMR session Figure 1-2 shows in detail how a Remote Control session works in a single-TMR environment without firewall restrictions.
B As soon as the RC Tool is opened, the Remote Control Server needs to validate the Controller by checking: – If the Controller is an Endpoint – If the label of the Endpoint is the same as of the hostname of the Controller – If the interpreter of the Controller is supported and able to start a Remote Control session In order to get this information, the Remote Control Server needs to contact the Endpoint Manager.
I As soon as the Target is started, the Remote Control Server sends the nd_start_controller method to the Controller and waits for the process to start. The local process started on the Controller machine is named EQNRSMAI.EXE. J The Remote Control session is now established. It is important to notice that once the session established, the Controller talks directly with the Target; this is a peer-to-peer communication.
******************************************************************************* “Basis” Remote Control Policies are loaded. ******************************************************************************* 1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_define 1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_uncheckedlist 0.0.0 get_name_registry 1562174364.1.26 lookup 1562174364.1.14#TMF_SysAdmin::Library# find_members 1562174364.1.184#TMF_SysAdmin::InstanceManager# find_members 1562174364.1.
1562174364.1.1413#PcRC::RemoteControl# remote_control 1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_gw 1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_ports 1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_encryption 1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_proxy 1562174364.1.26 lookup 1562174364.1.531#TMF_LCF::EpMgr# get_endpoint_key_value 1562174364.21.517+#TMF_Endpoint::Endpoint# _get_label 1562174364.17.517+#TMF_Endpoint::Endpoint# _get_label 1562174364.1.26 lookup 1562174364.1.
Example 1-2 The remote_control method from a single-TMR environment loc-ic 687 M-hdoq 1-426 776 Time run: [Mon 27-Jan 17:11:33] Object ID: 1562174364.1.1413#PcRC::RemoteControl# Method: remote_control Principal: ITSO\Administrator@ITSO (8731208/0) Path: /w32-ix86/TME/PCREMOTE/pcremote Trans Id: { 1562174364:1,1562174364:1,220:135 } #4 Input Data: (encoded): { 251658240 [ "WD_DIALOG_OWNER=1562174364.1.
Example 1-3 The is_proxied_ep method from a single-TMR environment loc-oc 699 Results: (encoded): false 9 Example 1-4 details the nd_start_target method. It refers to the following line in Example 1-1 on page 16: 1562174364.21.517+#TMF_Endpoint::Endpoint# nd_start_target This method is used to start the local Remote Control process on the Target. The wtrace command output doesn’t show much information about this method in this type of architecture.
1.2.2 Session in a multi-TMR environment In order to continue to master the Remote Control session processes, it is also important to know in detail the whole data flow between the different elements of IBM Tivoli Remote Control in a multi-TMR environment. In a HUB-Spoke architecture, all managed resources should be placed in the Spoke TMR, and all profiles dedicated for the management should be created in the HUB TMR. As RC Tools are managed resources, we assume that they are created in the Spoke TMR.
A HUB TMR Server E K K HUB RCL Collection HUB Endpoint GW Controller Spoke RC Tool Spoke TMR Server K Spoke PR K HUB RC Server A D HUB Endpoint Mgr B G C L Spoke RC Tool F Spoke RC Server J J I H Spoke Endpoint Mgr Spoke Endpoint GW Target Figure 1-3 RC session data flow in a multi-TMR environment Based on Figure 1-3, here we detail each step from the time when the Tivoli Administrator opens an RC Tool from a Collection located in the HUB TMR until the connection is established b
– If the label of the Endpoint is the same as of the hostname of the Controller – If the interpreter of the Controller is supported and able to start a Remote Control session. In order to get this information, the Spoke Remote Control Server needs to contact the Spoke Endpoint Manager.
H The Spoke Endpoint Manager is able to provide information for the Target machine as this Endpoint is part of the same TMR. However, for the Controller, once again, it could not find any information for it inside its Endpoint Database. The Spoke Endpoint Manager needs to extract the Region ID of the Controller Object ID and must find a way to contact the HUB Endpoint Manager.
From Example 1-7, we could analyze that all methods needed to get information from the HUB TMR are initiated on the Spoke TMR. Furthermore, all of these methods will be found again in the HUB TMR trace file. Even if these methods are initiated by the Spoke TMR, they are nevertheless managed by the HUB TMR.
1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value 1519322503.1.26 lookup 1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value 1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value 1519322503.1.707#PcRC::RemoteControl# get_policy_region 1519322503.1.707#PcRC::RemoteControl# get_policy_region_name 1519322503.1.707#PcRC::RemoteControl# _get_label ******************************************************************************* “Basis” Remote Control Policies are loaded.
1519322503.1.707#PcRC::RemoteControl# remote_control 1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_gw 1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_ports 1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_encryption 1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_proxy 1519322503.1.26 lookup 1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value 1519322503.18.522+#TMF_Endpoint::Endpoint# _get_label 1380596993.7.522+#TMF_Endpoint::Endpoint# _get_label 1519322503.1.26 lookup 1519322503.1.
Example 1-8 details the remote_control method started from the Spoke TMR Server which could also be named the Target request. It refers to the following line in Example 1-7 on page 25: 1519322503.1.707#PcRC::RemoteControl# remote_control Example 1-8 The remote_control method from a Spoke TMR loc-ic 4778 M-hdoq 1-4728 782 Time run: [Tue 28-Jan 17:47:15] Object ID: 1519322503.1.707#PcRC::RemoteControl# Method: remote_control Principal: root@lpar07.itsc.austin.ibm.
Example 1-9 The is_proxied_ep method from a Spoke TMR loc-oc 4695 Results: (encoded): false 9 Example 1-10 details the nd_start_target method started from the Spoke TMR Server. It refers to the following line in Example 1-7 on page 25: 1519322503.18.522+#TMF_Endpoint::Endpoint# nd_start_target This method is used to start the local Remote Control process on the Target. The return code of this method is 0; this means that the session starts without error.
[ "/I9.3.4.247 / ], ,((!?+; ] /Ntic01006 / ], ,((!?+; ] /B18 /A /T / ] ;+?!((,, ] /HRoot_tic01010-region(root@lpar07.itsc.austin.ibm.com) / ] ;+?!((,, ] " ] } 65540 rem-oc "9.3.4.244" 4795 Results: (encoded): 0 12 Example 1-12 details the nd_start_controller method started from the HUB TMR Server. It refers to the following line in Example 1-6 on page 25: 1380596993.7.
1.2.3 Session using a Remote Control Gateway In the following sections we describe how Remote Control sessions are established in a firewall environment using the Remote Control Gateway component for both single-TMR and multi-TMR environments. As this technology had been previously developed to allow Remote Control sessions in a firewall environment before the Remote Control Proxy technology was announced, we won’t go into details on this process, and no trace will be discussed.
TMR Server A D PR I A I RC Tool Endpoint GW C Controller J E B RC Server F H J J H H G Endpoint Mgr Firewall Endpoint GW RC Gateway Target DMZ Figure 1-4 RC session data flow in an RC Gateway/single-TMR environment Based on Figure 1-4, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target.
informed the Controller (step I) to use the Remote Control Gateway in order to contact the Target. As the Controller knows on which Managed Node the Remote Control Gateway is installed and which port has to be used, it starts to communicate with the Target using this specific network path. The Remote Control session is now established.
echo "YES tic01002 8877 64 IP:0" exit 0 Data flow for an RC Gateway/multi-TMR session Figure 1-5 shows in detail how a Remote Control session works using a Remote Control Gateway in a multi-TMR environment with firewall restrictions.
The legend used in Figure 1-5 is explained as follows: Steps A, B,C, D, E, F, G, H, I, J, and K remain the same as for a Remote Control session in a multi-TMR environment without the firewall restriction. Refer to “Data flow for a multi-TMR session” on page 21 for detailed information about these steps.
The RC Target Proxy emulates the Target located in another network zone to the Controller. The Target Proxy must be able to communicate with the Controller without any firewall constraints, and thus must be located in the same network zone as the Controller. On the other side, the RC Controller Proxy emulates the Controller located in another zone to the Target.
Based on Figure 1-6, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target using the Remote Control Proxies. The legend used in Figure 1-6 is explained as follows: Steps A, B,C, D, E, F, G, H and I are similar to a Remote Control session in single-TMR environment without firewall restriction. Refer to “Data flow for single-TMR session” on page 14 for detailed information about these steps.
configuration file. However, if you decided to change this port, you need to also review the rc_def_proxy policy. For more information about the RC Proxies configuration files, refer to IBM Tivoli Remote Control User’s Guide, SC23-4842. Sometimes, the Controller could be in a secure zone and managed by a local Tivoli Endpoint Gateway and the Target could be in another secure zone and also be managed by a local Tivoli Endpoint Gateway.
# # # # # # # # # # # # # # # # # # # # # # # # # # # the machine where the target proxy runs. Identifies the machine where the target proxy runs. You must use this parameter only with the manual configuration type. Identifies the port that the target proxy uses to communicate with the controller or the controller proxy. Default value: NO Examples follow. First example: YES manual 192.168.100.50 3501 Second example: YES auto 3501 Third example: NO echo "YES manual 9.
A HUB TMR Server E K K HUB RCL Collection HUB Endpoint GW Spoke RC Tool Controller Spoke TMR Server L K Spoke PR K HUB RC Server A HUB Endpoint Mgr D RC Target Proxy L Spoke RC Tool F L L B G H C Spoke RC Server I Target RC Controller Proxy J Firewall J J Spoke Endpoint Mgr Endpoint GW DMZ Figure 1-7 RC session data flow in an RC Proxy Standalone/multi-TMR Based on Figure 1-7, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the
has been informed of that on step F. The Remote Control server then has informed the Controller (step K) to use the RC Target Proxy in order to contact the Target. The Controller is able now to transfer the connection request to the RC Target Proxy as it got its IP address. When the RC Target Proxy receives the request containing the IP address of the requested Target, it can start searching in the rcproxy.route file for the RC Controller Proxy the Target is connected to.
In order to implement the Remote Control session to use Remote Control Proxies, the rc_def_proxy default policy method needs to be configured as shown in Example 1-14 on page 38. This has to be done in the Spoke TMR where the Remote Control Object is located. Tracing for RC Proxy Standalone The Tivoli methods used to start a session in a Remote Control Proxy Standalone architecture are the same used to start a session in a non-secure environment.
Example 1-15 The is_proxied_ep method for an RC Proxy Standalone architecture rem-ic 695 M-H 1-683 21 Time run: [Thu 30-Jan 11:42:46] Object ID: 1519322503.29.522+#TMF_Endpoint::Endpoint# Method: is_proxied_ep Principal: root@tic01002 (0/0) Path: Input Data: (encoded): "10.10.10.7" rem-oc 695 Results: (encoded): false 9 Example 1-16 details the nd_start_target method started from either the TMR Server in a single-TMR architecture or from the Spoke TMR Server in a multi-TMR architecture.
"" 0 Example 1-17 details the nd_start_controller method started from the Spoke TMR Server in a multi-TMR architecture because it shows more useful information to understand how the information about the Target Proxy is passed to the Controller. It refers to the following line in Example 1-7 on page 25: 1380596993.7.522+#TMF_Endpoint::Endpoint# nd_start_controller This method is used to start the local Remote Control process on the Controller.
rem-oc 972 Results: (encoded): 0 12 1.2.5 Session using Remote Control Proxies in a TFST environment In the following sections we describe the Remote Control Proxy architecture running on top of Tivoli Firewall Security Toolbox for both single-TMR and multi-TMR environments. The Remote Control Proxy components enable machines on one side of a firewall to communicate, through a common definable port, with machines on the other side of the firewall.
A D I TMR Server Endpoint GW Controller J PR A RC Tool I RC Target Proxy H C J E B J RC Server H F Endpoint Proxy G H Endpoint Mgr J RC Contr.
Endpoint Communication Protocol packets. In a TFST environment, these packets are encapsulated by the Endpoint Proxy inside common HTTP packets. HTTP protocol has been chosen, as it is “firewall friendly” protocol. The packets are then rebuilt into Tivoli proprietary communication protocol by the Gateway proxy to let the distant Targets understand the order to start an RC session.
name of the Gateway Proxy which the Target is connected to. As the RC Controller Proxy must be installed on the same machine as the Gateway Proxy, the RC Target proxy is able to connect to this RC Controller Proxy and forward the Target request using the Gateway Proxy IP Address provided by the Endpoint Proxy. The RC Controller Proxy then uses the Target information stored in the first request to start a session with the Target. The Remote Control session is now established.
Example 1-18 The rc_def_proxy default policy method for Remote Control #!/bin/sh # # Default policy method for Remote Control Proxy # # This policy method determines whether to use Remote Control Proxies. # If you use Remote Control Proxies, rc_def_proxy defines how the controller # uses the Remote Control Proxies to start a session with a target across a # firewall. # # Possible values: # # NO Do not use the Remote Control Proxies.
# # # # # # # # # First example: YES manual 192.168.100.
A E L K HUB TMR Server K RC Target Proxy L L HUB Endpoint GW HUB RCL Collection Controller J Spoke RC Tool Endpoint Proxy J Spoke TMR Server DMZ Firewall K K HUB RC Server Spoke Endpoint GW Spoke PR L Relay 2 TFST J A HUB Endpoint Mgr D Spoke RC Tool J F Relay 1 TFST B G H J J J Firewall C L Spoke RC Server L Gateway Proxy I L Spoke Endpoint Mgr External Target RC Contr.
nd_start_target method is sent to the Target using the standard Endpoint Communication Protocol packets. In a TFST environment, these packets are encapsulated by the Endpoint Proxy inside common HTTP packets. HTTP protocol has been chosen, as it is considered a “firewall friendly” protocol. The packets are then rebuilt into Tivoli proprietary protocol by the Gateway proxy to let the distant Targets understand the order to start an RC session.
Gateway Proxy on which the Target is connected to. As the RC Controller Proxy must be installed on the same machine as the Gateway Proxy, the RC Target proxy is able to connect to this RC Controller Proxy and forward the Target request using the Gateway Proxy Address provided by the Endpoint Proxy. The RC Controller Proxy uses the Target information stored in the first request to start a session with the Target. The Remote Control session is now established.
Tracing for RC Proxy-TFST The methods used to start a session in a Remote Control Proxy-TFST architecture are the same that are used to start a session in a non-secure environment. Refer to Example 1-1 on page 16 for a subset of an IBM Tivoli Management Framework odstat command output for a single-TMR architecture; and to Example 1-6 on page 25 and Example 1-7 on page 25 for multi-TMR architecture.
Example 1-20 The nd_start_target method for an RC Proxy-TFST architecture loc-oc 11621 Results: (encoded): "" 0 23 Example 1-21 details the nd_start_controller method started from the Spoke TMR Server in a multi-TMR architecture and it shows more useful information to understand how the information about the Target Proxy is passed to the Controller. It refers to the following line in Example 1-7 on page 25: 1380596993.7.
] ;+?!((,, ] /HRoot_tic01002-region(root@tic01002) / ] ;+?!((,, ] " ] } 65540 "9.3.4.
2 Chapter 2. Implementation planning In this chapter we provide considerations to ensure an effective implementation of IBM Tivoli Remote Control (ITRC) within environments across an enterprise protected by firewalls.
2.1 Design In this section we address design considerations for the implementation of IBM Tivoli Remote Control in a secure environment. In fact, we assume that the Tivoli environment is already deployed within the enterprise. Thus, no information on planning for the IBM Tivoli Management Framework and the Tivoli Firewall Security Toolbox is provided in this section.
The remaining RC Policies should follow the same rules defined for all other RC Objects. They don’t have a direct impact on the way IBM Tivoli Remote Control works across firewalls. However, they could also be reviewed in order to fulfill some new requirements concerning the type of actions (for example, Remote Control, File Transfer, or Chat) that a Tivoli Administrator is able to use in a secure environment.
2. Scenarios where the Targets and/or Controllers are separated from their standard Tivoli Endpoint Gateway by a firewall. In this case, a Tivoli Firewall Security Toolbox is needed to manage these Endpoints. IBM Tivoli Remote Control must be installed on top of the Tivoli Firewall Security Toolbox architecture in order for it to be able to contact the Endpoint separated from their TMR Server by, at least, one firewall or more.
Having decided where to place the different components, you need now to decide on the Parent-Child relationship. In other words, to define which one of the RC Target Proxy or the RC Controller Proxy must be the Parent and which one must the Child. For more information about the Parent-Child concept, refer to the 1.1.4, “Parent-Child concept” on page 10.
Regarding the network communication for IBM Tivoli Remote Control, it is important to notice that the communication pipe between the RC Proxies is always opened and started as soon as the local RC Proxies services are started. If a Relay is part of the architecture, the communication pipes between the RC Proxies and the Relay are also always opened and started at the service startup time.
Table 2-1 RC ports for unidirectional communication - Parent/initiator Source Destination Protocol Description Type (Service) Port (Single / Range) Type (Service) Port (Single / Range) Controller (eqnrsmai) random or defined1 (single) Target Proxy (rcproxy) 9494 2 (single) TCP Started at request. Communication in the same network zone. No firewall rule needed.
6. This default port is for a Remote Control session and could be changed in the rc_def_ports RC Policy. The default port for a File Transfer session is 2502 and could also be changed in the rc_def_ports RC Policy. For more information about how to configure the RC Policies or the Proxy configuration files, refer to the IBM Tivoli Remote Control User’s Guide, SC23-4842.
4. This port must be configured using the children-local-port parameter in the [communication-layer] section of the Parent rcproxy.cfg file, in this case the RC Target Proxy configuration file. This port must be the same as specified in the parent-remote-port parameter in the [communication-layer] section of the Child rcproxy.cfg file, in this case the RC Controller Proxy configuration file. 5.
Source Destination Protocol Description Type (Service) Port (Single / Range) Type (Service) Port (Single / Range) Relay (Relay) random or defined6 (single or range) Controller Proxy (rcproxy) defined7 (single) TCP Started at service time. Communication between two network zones. Firewall rule needed. Default polling interval is 2 seconds8 . Controller Proxy (rcproxy) random (single or range) Target (eqnrcmai) 25019 (single) TCP Started at request. Communication in the same network zone.
8. The default polling interval could be changed by configuring the polling-interval parameter in the [children-cm-info] section of the Relay Relay.cfg file, as it is the initiator. 9. This default port is for a Remote Control session and could be changed in the rc_def_ports RC Policy. The default port for a File Transfer session is 2502 and could also be changed in the rc_def_ports RC Policy.
Comments: 1. This port could be fixed in the rc_def_ports RC Policy 2. This default port could be changed using the proxy-port parameter in the [rcproxy] section of the Parent rcproxy.cfg file, in this case the RC Target Proxy configuration file. This port must be the same as defined in the rc_def_proxy RC Policy. 3. This port or port range could be fixed by configuring the local-port-range parameter in the [parent-cm-info] section of the Relay Relay.cfg file. 4.
Note: A Relay could, at the same time, be an initiator and a listener, as it is a Child towards the RC Target Proxy and a Parent towards the RC Controller Proxy in our scenario. The information provided in the Table 2-3 on page 65 and Table 2-4 on page 67 can help you to understand all scenarios. If the Relay is a Child listener and a Parent listener, get the Child listener communication ports in Table 2-3 on page 65 and the Parent listener ports in Table 2-4 on page 67.
Comments: 1. This port could be fixed in the rc_def_ports RC Policy 2. This default port could be changed using the proxy-port parameter in the [rcproxy] section of the Parent rcproxy.cfg file, in this case the RC Target Proxy configuration file. This port must be the same as defined in the rc_def_proxy RC Policy. 3. This port or port range could be fixed by configuring the local-port-range parameter in the [children-cm-info] section of the Parent rcproxy.
Table 2-6 RC ports for bidirectional communication with Relay Source Destination Protocol Description Type (Service) Port (Single / Range) Type (Service) Port (Single / Range) Controller (eqnrsmai) random or defined1 (single) Target Proxy (rcproxy) 94942 (single) TCP Started at request. Communication in the same network zone. No firewall rule needed. Target Proxy (rcproxy) random or defined3 (single or range) Relay (Relay) defined4 (single) TCP Started at service time.
4. This port must be configured using the parent-local-port parameter in the [communication-layer] section of the Relay Relay.cfg file. This port must be the same as specified in the children-remote-list parameter in the [communication-layer] section of the Parent rcproxy.cfg file, in this case the RC Target Proxy configuration file. 5. This port or port range could be fixed by configuring the local-port-range parameter in the [parent-cm-info] section of the Relay Relay.cfg file. 6.
Note: A Relay could, at the same time, be a Parent of the RC Controller Proxy and Child of the RC Target Proxy in our scenario. This means that the communication between the Relay and the RC Target Proxy could be unidirectional and bidirectional between the Relay and the RC Controller Proxy. The tables provided in 2.1.3, “Network considerations” on page 61 can help you to understand all of the scenarios.
Phase 1 1 1. Install a TRM Server 2. Define the IOM Range port and configure your Firewall 3. Install Endpoint Gateways in the more and less secure zone. 4. Deploy the Endpoints in the more and less secure zone Phase 2 TMR Server 5 5. Install a Remote Control Server 6. Create a new Policy Region with the RemoteControl managed resource 7. Create a new Remote Control Tool and configure the Remote Control policies to force the usage of the Remote Control Proxy. Phase 3a RC Server 8 8.
Phase 1 1 2 3 TMR Server Endpoint GW Endpoint 4 5 6 PR RC Tool 8 9 10 Endpoint Proxy Gateway Proxy Endpoint 1. Install a TRM Server 2. Install Endpoint Gateways in the more secure zone. 3. Deploy the Endpoints in the more secure zone Phase 2 4. Install a Remote Control Server 5. Create a new Policy Region with the RemoteControl managed resource 6. Create a new Remote Control Tool and configure the Remote Control policies to force the usage of the Remote Control Proxy. Phase 3a 7.
Supporting applications requirements Before installing any IBM Tivoli Remote Control Proxy, you must have the following software components installed, up and running: IBM Tivoli Management Framework 3.7.1 or higher. IBM Tivoli Remote Control 3.8 or higher. Tivoli Firewall Security Toolbox 1.3 or higher for an RC Proxy Non-Standalone architecture. In addition, you must install: IBM Tivoli Management Framework Agent of the IBM Tivoli Management Framework 3.7.
Software requirements Before starting the installation of the IBM Tivoli Remote Control Proxy, you should have installed the minimum product levels listed in the Table 2-8. These requirements are only for the IBM Tivoli Remote Control Proxies. If you plan to use a Non-Standalone solution, you should also take in consideration the software requirements for the Tivoli Firewall Security Toolbox.
This file system will contain the binaries and configuration files for the application. It is recommended to install such applications in another Logical Partition than the Operating System. Furthermore, a directory structure with no spaces in the name could be easier to manage — just in case the directory name might be used in a script, for example. – Type of installation: If you choose to add a label to this Proxy, then this Proxy will become a Child. Otherwise, the Proxy will become a Parent.
– A list of Tivoli Endpoints that will act as Targets with their dedicated Remote Control Proxy: This list will be used to find the route to contact the RC Target. This information will be saved in the rcproxy.route definition file. Note: This step only concerns an RC Proxy Standalone installation process. In a Non-Standalone process, this information is managed by the Endpoint Proxy and the RC Proxy does not need to maintain a local route file.
– The IP Address (or DNS name) of the Parent: This information will be saved in the parent-remote-host parameter in the [communication-layer] section of the rcproxy.cfg configuration file. – The listening port of the Parent: This information will be saved in the parent-remote-port parameter in the [communication-layer] section of the rcproxy.cfg configuration file.
This section provides some examples of the implementation planning that can be implemented for that particular scenario. It is meant to help systems administrators to understand the different solutions for using IBM Tivoli Remote Control across firewalls. However, it does not provide all details needed for a complete implementation.
We should also point out that a Tivoli Endpoint Gateway was already deployed before the Tivoli Firewall Security Toolbox technology had been announced, in order to manage the Endpoints in the Servers zone. Figure 2-3 depicts the current CSI Corporation Tivoli environment prior to the IBM Tivoli Remote Control Proxy solution deployment. The External zone represents the site where the first and second level support location. The DMZ, Internal, and Servers zones are all located at CSI’s main site.
Implementation Planning Case Study: Solution A Based on the information gathered in the previous section, we decide to install an RC Controller in the external zone, specifically on Endpoint A. Also, all Targets are located in both the Internal and Servers zone, represented by Endpoints B, C, and D in Figure 2-3. Thus, Endpoint A must be able to contact Endpoint B, Endpoint C, and Endpoint D.
DMZ External Endpoint GW Relay A1 GW Proxy A P=Parent C=Child Servers Internal TMR Server Endpoint GW EP Proxy A Relay A2 RC Target Proxy A RC Contr. Proxy A P:8115 C:8116 C:8114 C:81128113 Firewall 1 P:8100-8110 P:8111 Firewall 2 Firewall 3 Endpoint GW Controller 1 Target 2 Target 1 RC Target Proxy B2 C:9216 P:9215 C:9214 Controller 2 RC Target Proxy B1 P:92009210 Relay B1 P:9213 C:9212 Relay B2 RC Contr.
As per existing security guidelines, the Security Officer of the CSI Corporation imposes for this communication the same constraints defined for the Endpoint/Gateway Proxy A architecture. In other words, communication between the RC Controller Proxy A and the Relay A2 is set as bidirectional, and between this Relay A2 and the RC Target Proxy A is set as unidirectional. In this scenario, Controller 1 is able to contact Target 1 using the A path.
In this scenario, we decided on the more secure solution and decide to connect the RC Target Proxy B2 to the Relay B2. In addition to that, RC Controller Proxy B is the Parent and, as a Parent could have more than one Child, this allows us to connect the Relay B2 and the RC Target Proxy B1 to the RC Controller Proxy B or to connect the Relay B1 and the RC Target Proxy B2 to the Relay B2.
Table 2-10 RC Proxy network ports for firewall 2 - Solution A Source Destination Protocol Description Type (Service) Ports Type (Service) Ports Controller Proxy A (rcproxy) 81008110 Relay A2 (Relay) 8114 TCP Firewall rule needed. Initiated at service startup time Relay A2 (Relay) 81128113 Controller Proxy A (rcproxy) 8111 TCP Firewall rule needed. Initiated at service startup time. Relay B2 (Relay) 9213 Relay B1 (Relay) 9214 TCP Firewall rule needed.
Implementation Planning Case Study: Solution B In this scenario, the requirements imposed by CSI Corporation are the same as presented for Solution A. The goal for in this section is to provide an alternate solution design for CSI — in this case, a change on the existing physical design by eliminating the current Tivoli Endpoint Gateway installed in the Servers network zone.
Similarly to Solution A, there are three main requests that need to be addressed: Controllers in the External zone connecting Targets in the Internal zone: The change in the design has no affect on this request, and Controller 1 is able to connect to Target 1 using the A path, as described in “Implementation Planning Case Study: Solution A” on page 83.
Note that the ports provided in these tables are examples specific to this case study scenario. Table 2-12 RC Proxy network ports for firewall 1 - Solution B Source Destination Type (Service) Ports Type (Service) Ports Relay A2 (Relay) 8115 Target Proxy A (rcproxy) 8116 Protocol Description TCP Firewall rule needed. Initiated at service startup time. Polling interval is 2 seconds.
Part 2 Part 2 Implementation scenarios © Copyright IBM Corp. 2003. All rights reserved.
92 IBM Tivoli Remote Control Across Firewalls
3 Chapter 3. Implementation scenario: Standalone Proxies In this chapter we explain the techniques used to implement IBM Tivoli Remote Control 3.8 in a firewall environment. The scenario we describe will help you understand the requirements for establishing Remote Control sessions when a firewall is involved, using a more secure mechanism, the Remote Control Proxy technology in Standalone mode.
3.1 Scenario overview In this section, we provide an overview of our Remote Control in Standalone mode testing scenario. A typical Remote Control in Standalone mode is defined when the Tivoli Management Gateway (Gateway) and its Endpoints are separated from the Remote Control Controller by a firewall. The goal of this scenario is to provide detailed information to the System Administrators of the requirements and considerations that will help them work with session management across a firewall.
As described in Chapter 2, “Implementation planning” on page 57, the following are important items to be considered when planning IBM Tivoli Remote Control 3.
TMR Hub Hub TMR server AIX 5.1 - tic01010 Endpoint Windows TS server TMR Spoke Endpoint Spoke TMR server AIX 5.1 - tic01002 Endpoint Gateway AIX 5.1 - tic01002 Endpoint Windows tic01006 Firewall De-Militarized Zone (DMZ) Endpoint Windows tic01005 Endpoint Endpoint Gateway Windows - tic01005 Endpoint Windows tic01007 Endpoint Figure 3-1 General testing scenario This scenario includes interconnected TMR using the Hub and Spoke architecture, two different Gateways and a set of Endpoints.
For our testing, we used the following products and release levels: Operating systems: – IBM AIX 5.1 – Microsoft Windows 2000 Advanced Server – Microsoft Windows 2000 Professional Tivoli Software: – IBM Tivoli Management Framework 4.1 – IBM Tivoli Remote Control 3.
We defined both TMRs and the managed node as Tivoli Gateway resources, as shown in the Example 3-3 and Example 3-4 that list the wgateway command output. Example 3-3 Hub TMR Endpoint Gateway # wgateway Object 1380596993.1.578 Name tic01010-gw Status u Example 3-4 Spoke TMR Endpoint Gateway # wgateway Object 1519322503.1.578 1519322503.5.
TMR Hub Remote Control Connections Hub TMR server AIX 5.1 - tic01010 Framework Connections Endpoint Windows TS server TMR Spoke Spoke TMR server AIX 5.1 - tic01002 Endpoint Gateway AIX 5.
The schema reported in Figure 3-3 shows an overview of the data flow in our Remote Control StandAlone environment. Random Remote Control Controller 1 8888 Random 2 RC Target Proxy - parent - unidirectional - 30008 Random RC Controller Proxy - child - 3 2501 Target Endpoint Firewall Figure 3-3 Remote Control Data Flow Overview To briefly describe how the data flow structure is, we numbered each connection reported in Example 3-3, specifying the ports required to establish each connection.
The ports defined as random on the Controller and RC Target Proxy could be customized specifying a single port or a range of ports, depending on the number of connections to be established. For example, we could restrict the ports usage for the communication between the RC Target Proxy Parent and all the RC Controller Proxies Children, so that the configuration on the firewall could be more restrictive. This is further explained in 3.3.2, “Remote Control Proxy configuration” on page 104. 3.
The Remote Control Proxies components can be installed on any machine in your environment whether part of the TME environment or not. Refer to Chapter 2, “Implementation planning” on page 57, to check on the various supported operating systems and maintenance levels. The Remote Control Proxies components code is shipped with the IBM Tivoli Remote Control 3.8 media, the same you used to install the IBM Tivoli Remote Control Server component.
Parameter Description Our settings Remote Control Proxy label Controller Proxy label where the Endpoint Target are connected to tic01005 Proxy type Role of the Parent RC Proxy Target Port number Port on which this Proxy listens for connection from Controllers (must match with rc_def_proxy value). 8888 Command line port Command line port (used by the rcproxy command) 9000 The above settings are mandatory and, once the installation is completed, all this information is stored in the rcproxy.
The foregoing settings are mandatory and, once the installation is completed, all this information is stored in the rcproxy.cfg file located at the Remote Control Proxy installation directory. Inputs to modify the RC Controller Proxy configuration file are given in “The rcproxy.cfg configuration file” on page 104. 3.3.2 Remote Control Proxy configuration This section describes some of the configuration steps to modify the Remote Control Proxy settings.
Example 3-6, instead, shows the RC Controller Proxy configuration file as result of the installation process, and the values provided in Table 3-2 on page 103. Example 3-6 Remote Control Controller Proxy configuration file [log] log-file=rcproxy.
[children-cm-info] connection-mode=client [children-cm-info] connection-mode=client local-port-range=4000-4001 In order to make these changes effective, we need to stop/start the RC Target Proxy service. The rcproxy.route routing table configuration file The rcproxy.route file defines the route to the Target Endpoints. It contains the list of all the Targets the Controller needs to connect to and the related RC Controller Proxy which they belong to.
The rc_def_proxy policy method In order to customize the Remote Control Proxy in a Standalone environment, it is necessary to modify the rc_def_proxy policy method accordingly. This file determines how the Remote Control Proxies usage will be done and how the Controller can connect to the Targets across the firewall. Example 3-9 shows the settings we used in our rc_def_proxy policy method file: Example 3-9 The rc_def_proxy policy method contents #!/bin/sh # # Default value: NO echo "YES manual 9.3.4.
3.3.3 Firewall configuration table This section describes the correlation between the firewall customization and the Tivoli environment to be implemented, providing the information a firewall administrator should need in order to configure the ports properly on the firewall to make the remote control session working, for this particular scenario. Table 3-3 shows the components that will communicate through the firewall and the ports they use in our scenario.
3.3.4 Remote Control Proxy startup This section describes how you can start up the Remote Control Proxies. Once the installation has been completed, the RC Target and RC Controller proxies have been properly configured and the firewall administrator has granted the access to ports needed by the Tivoli application to work properly, then you can check if the proxy mechanism works by starting the RC Target and RC Controller Proxy services.
Figure 3-5 Startup of Remote Control Proxy using Service Applet The command rcproxy can also be used for other tasks, such as to check how many proxy connections are active, to stop the Proxy service and to kill any of the active Proxy sessions. Once the Target and Controller Proxy are up and running, their communication can be checked in two ways: Checking the rcproxy.log file Running the netstat command Example 3-12 and Example 3-13 show the rcproxy.
Example 3-13 The rcproxy.
tcp4 tcp4 tcp4 tcp4 tcp4 tcp4 tcp4 tcp4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 tic01002.926 tic01002.4000 tic01002.42982 tic01002.42983 tic01002.55345 tic01002.55346 tic01002.objcall tic01002.8888 tic01002.32781 tic01005.30008 tic01002.42983 tic01002.42982 tic01002.55346 tic01002.55345 tic01010.38466 *.
Example 3-16 lists the output of the rcproxy command, showing no active connections: Example 3-16 The output of the rcproxy -list command # ./rcproxy -list total sessions = 0 03/02/11 10:27:30 0 failed (e=1) 03/02/11 10:27:30 0 failed (e=1) 1 releaseLock [id=0x2020bfd8] - pthread_mutex_unlock() 1 releaseLock [id=0x2020bf98] - pthread_mutex_unlock() An example of netstat and rcproxy -list commands output during an active session is provided in the section “Remote Control Proxy startup” on page 133.
114 IBM Tivoli Remote Control Across Firewalls
4 Chapter 4. Implementation scenario: Tivoli Firewall Security Toolbox In this chapter we describe the techniques used to implement IBM Tivoli Remote Control 3.8 in a firewall environment. The scenario we present will help you understand the requirements for establishing Remote Control sessions when firewall is involved, using a more secure mechanism, the Remote Control Proxy technology using the Tivoli Firewall Security Toolbox.
4.1 Scenario overview In this section we provide an overview of our Remote Control Non-Standalone testing scenario. A typical Remote Control Non-Standalone architecture is implemented when the firewall stands between the Endpoint Targets and the Endpoint Gateway. A common environment, for example, could be managing the Endpoint in the DMZ with the Gateway located at the most secured zone.
We demonstrate how the Remote Control Proxy will allow remote control connections through the firewall with minimal impact on the connection policies enforced by the firewall itself. We explain the seamless integration the Remote Control Proxies have with the Tivoli Firewall Security Toolbox and its ability to handle concurrent sessions. Complex network may impose the usage of Remote Control across multiple firewalls.
TMR Hub Hub TMR server AIX 5.1 - tic01002 Endpoint Windows TS server TMR Spoke Endpoint Windows - tic01006 Spoke TMR server AIX 5.1 - tic01010 Endpoint Gateway AIX 5.
For our testing we used the following products and release levels: Operating systems: – IBM AIX 5.1 – Microsoft Windows 2000 Advanced Server – Microsoft Windows 2000 Professional Tivoli Software: – IBM Tivoli Management Framework 4.1 – IBM Tivoli Remote Control 3.8 – Tivoli Firewall Security Toolbox 1.
TMR Hub Remote Control Connections Hub TMR server AIX 5.1 - tic01002 Framework Connections Endpoint Windows TS server TMR Spoke Endpoint Windows - tic01006 Spoke TMR server AIX 5.1 - tic01010 Endpoint Gateway AIX 5.
Since there is a Relay placed in the DMZ to allow the proxies communication across multiple firewalls (Endpoint Proxy in the more secure side and the Gateway Proxy in the less secure side), we need to define an extra Relay instance on this network that will allow the communication between the RC Target Proxy and the RC Controller Proxy. This Relay will be configured as a Child of the RC Target Proxy and a Parent of the RC Controller Proxy.
Endpoint Proxy 1 Random Remote Control Controller 1 Gateway Proxy 2 5020 Range 4000-4010 2 7020 RC Target Proxy - parent - unidirectional - Range 3 4023-4024 Relay instance 2 Firewall 1 8020 Random RC Controller Proxy - child - 4 2501 Target Endpoint Firewall 2 Figure 4-3 Data flow overview: Non-Standalone scenario To briefly describe how the data flow structure is, we numbered each connection reported in Figure 4-3 specifying the ports required to establish each connection.
3. The second instance of the Relay is then responsible for initiating the connection with the RC Controller Proxy. This Relay uses a pre-defined range of ports (4023-4024) to establish a connection to port 8020 defined on the RC Controller Proxy. This range of ports needs to be defined after the installation of the second instance of the Relay. Information on how to customize it is given in 4.3.2, “Remote Control Proxy configuration” on page 129.
Since this label must be the same as the Controller Proxy, the RC Target Proxy also knows the Controller Proxy it needs to connect to. The RC Target Proxy then forwards the request to the RC Controller Proxy through the specified Relay instance. When the request is received by the RC Controller Proxy, it will be responsible for connecting to the IP address and port number of the Endpoint Target it has just collected. 4.2.
The port range must have as many ports as the number of Child Proxies the related proxy has. In our example we assume that the RC Target Proxy could have up to 10 additional Child Proxies, while the Relay could have 2 Child Proxies. 4.3 Scenario installation and configuration This section describes scenarios for installing RC Target and Controller Proxies in our Non-Standalone environment.
RC Target Proxy installation In our testing scenario the RC Target Proxy component should be installed on Windows 2000 Server operating system. The installation is performed using the Install Shield mechanism running the setup.exe command from the IBM Tivoli Remote Control 3.8 media as follows: \new\RCPROXY\w32-ix86\setup.exe As soon as the installation process starts, it automatically detects the TFST code already installed on the machine.
For additional information related to the Remote Control Proxy installation you can refer to the IBM Tivoli Remote Control User’s Guide, SC23-4842. Relay instance used by Remote Control In our testing scenario we have to install a second instance of the Relay to be used that will bridge the RC Target and Controller Proxies. The installation of the Relay component is started by the TivoliRelay.exe command provided by the Tivoli Firewall Security Toolbox 1.3 included in the IBM Tivoli Management Framework 4.
Parameter Description Our settings Unidirectional role in relation to the RC Controller Proxy Role of Relay when connection is unidirectional: - Initiator (client) - Listener (server) initiator (*) This parameter is mandatory during the installation. Since the connection type is unidirectional and the Relay is configured as listener, port 6020 will never be used.
After installing the RC Controller Proxy, all the setting are stored in the rcproxy.cfg file placed in the installation path directory. The file contents appear as shown in th Example 4-1. Example 4-1 RC Controller Proxy configuration file [log] log-file=rcproxy.
This file is located in the Remote Control Proxy installation directory that, by default, is c:\Program File\Tivoli Systems\Remote Control Proxy on Windows and /opt/Tivoli Systems/Remote Control Proxy on UNIX. Example 4-2 shows the RC Target Proxy configuration file based on the values we provided in Table 4-5 on page 126 immediately after the installation process. Example 4-2 RC Target Proxy configuration file example [log] log-file=rcproxy.
Children-remote-list=tic01004+7020 Children-cm-type=cm-tcp-unidirectional buffer-size=1024 [Children-cm-info] connection-mode=client local-port-range=4000-4010 In order to make these changes effective we need to stop/start the RC Target Proxy service. The Relay.cfg configuration file The relay.cfg file contains all the information related to the Relay settings we specified during the Relay component installation,. This file is located in the Relay installation directory and can be modified at any time.
Example 4-5 The Relay.cfg file after the changes [communication-layer] Children-local-port=7021 Children-remote-list=tic01005+8020 parent-local-port=7020 parent-remote-host=tic01003 parent-remote-port=6020 parent-cm-type=cm-tcp-unidirectional Children-cm-type=cm-tcp-unidirectional [log] log-file=Relay.
The wgetpolm and wputpolm commands are used to modify the rc_def_proxy policy method settings. The procedure is similar to the process shown for the Standalone case study scenario in Example 3-10 on page 107. 4.3.3 Remote Control Proxy startup The process for starting the Remote Control Proxies was described in 3.3.4, “Remote Control Proxy startup” on page 109 and is similar when installed on a Non-Standalone environment. In this section we just provide the content of the rcproxy.
Example 4-8 shows the Relay log file. Example 4-8 The Relay.log: Relay log file contents 03/02/13 10:52:35 3 844 logInit - Message logging initialized (level=3, logmax=1MB). 03/02/13 10:52:35 0 844 Relay version 1.3 - level 20020925 03/02/13 10:52:35 0 844 TCP/IP timeout 240 03/02/13 10:52:35 3 844 FSR0001W Relay Started 03/02/13 10:52:35 0 844 Initializing the communication layer ...
In order to check which ports these Proxies are using to communicate and to verify that no other ports are actually being used, we can use any network status command, such as the netstat -a command or similar. Example 4-10 shows the output of the netstat -a command on the RC Target Proxy.
TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP tic01004:4023 tic01004:7001 tic01004:7020 tic01004:8342 tic01004:38292 tic01004:netbios-ssn tic01004:1056 tic01004:4023 tic01004:7001 tic01004:7020 tic01004:0 tic01004:0 tic01004:0 tic01004:0 tic01004:0 tic01004:0 tic01004:0 tic01005:8020 tic01003:4011 tic01003:4000 LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING ESTABLISHED TIME_WAIT ESTABLISHED Example 4-12 shows the output of the netstat -a command on the RC Controller Proxy.
Example 4-13 lists the output of the rcproxy command that shows the active connection. Example 4-13 The output of the rcproxy -list command id=1, Target=tic01007, proxy_label=n/a total sessions = 1 Chapter 4.
138 IBM Tivoli Remote Control Across Firewalls
Part 3 Part 3 Troubleshooting © Copyright IBM Corp. 2003. All rights reserved.
140 IBM Tivoli Remote Control Across Firewalls
5 Chapter 5. Troubleshooting techniques IBM Tivoli Remote Control 3.8 aims to establish remote control session across firewalls using the Remote Control Proxy technology. While the systems administrator can perform many tasks relatively easy, the code Tivoli provides to achieve those tasks is extraordinarily complex. With the solid foundation of the Tivoli Management Framework, this complexity can remain largely masked from the administrator.
5.1 Generic problem determination outline To obtain an overall picture of what is happening on the IBM Tivoli Remote Control side when a session is established through a firewall, there are several troubleshooting steps to follow and logs that need to be analyzed.
The following sections show a series of flows that represent the fundamental steps you need to perform for troubleshooting issues when establishing Remote Control sessions through the firewall, from the time you click the Run button of the Remote Control Tool, to the time the session between the RC Controller and the RC Target is established.
Endpoint Troubleshooting Yes Is EP alive ? No Is GW alive ? Yes Is EP service started ? No Check gatelog & start GW Yes Yes Start EP service & check lcfd.log Is MN alive ? No Yes Is the MN behind a Firewall ? Is GW alive ? No Configure Firewall rules for Tivoli No Yes Is EP alive ? Yes No Is the Firewall configured ? No Yes Is the DNS configured ? No Is EP attached to a GWP ? Yes Yes No Configue DNS for Tivoli Yes TFST Troubleshooting Check epmgrlog gatelog lcfd.
From here on, the Endpoint problem determination process is explained in detail. However, for more detailed information regarding Endpoint troubleshooting, refer to the Tivoli Management Framework Maintenance and Troubleshooting Guide, GC32-0807. Is Endpoint alive? The Endpoint must be alive in order to let the pcremote process send it the necessary down calls.
If you get the version of the Endpoint, this means the downcall is working. Otherwise, you could face some local Endpoint security restrictions. To isolate the problem, you could refer to the epmgrlog, located on the TMR Server, the gatelog, located on the Endpoint Gateway, and the lcfd.log, located on the local machine, which could provide you with much information regarding the Endpoint communication.
The odstat and wtrace command outputs (for more information on how to get a Framework trace, refer to the Tivoli Management Framework Maintenance and Troubleshooting Guide, GC32-0807). Conversely, if every communication is working fine between the different components of the Framework, the problem could be located at the Remote Control Proxy level. To help you follow the necessary steps to determine if your RC Proxy environment is working, we have defined a specific process.
TFST Troubleshooting Yes Yes Is EP alive ? Yes Could EPP contact GWP ? Could EPP contact GW ? No No No Check lcfd.log gwp.log Check epp.log gwp.log Check gatelog epp.log Could EPP contact GWP ? Start EPP +GWP Services Yes Could EPP contact GW ? No No Are EPP+GWP serv. started ? No Yes Yes Yes Are EPP+GWP serv. started ? No Check Firewall rules & DNS Yes Could EPP contact GWP ? No Contact IBM Customer support No Is Ep alive ? Yes Is downcall working ? Check epmgrlog gatelog lcfd.
From here on, the TFST problem determination process is explained in detail. However, for more detailed information regarding the TFST troubleshooting refer to the Firewall Security Toolbox User ’s Guide, GC23-4826. Are Endpoint Proxy and Gateway Proxy services started? If these services or process are not up and running, you need to start them. If you are using a relay between the two proxies, you need to verify that the Relay service or process is up and running too.
Is Endpoint alive? The Endpoint must be alive in order to let the pcremote process send it the necessary down calls. The following command could be used: wep [Endpoint label] status If the Endpoint is not alive, you have to control if the Endpoint is able to communicate with its Gateway Proxy. Check the lcfd.log and the gwp.log to control if the Endpoint is using the correct IP address and port to communicate with its Gateway Proxy.
RC Proxy problem determination process Before starting the problem determination, we recommend that you follow these steps in order to have a clear picture of what is going wrong: 1. Edit the remcon.ini file on the RC Controller and RC Target, set trace_lavel parameter to 3 in the Generic section as explained in the IBM Tivoli Remote Control User’s Guide, SC23-4842 and restart the service. 2. Edit the relay.
RC Proxy Troubleshooting Yes Yes Could RCCP contact RCTP ? Yes Is eqnrsmai started ? No No Check lcfd.log pcremote traces Check lcfd.log pcremote traces Check rcproxy.log Yes Yes Is eqnrsmai started ? Is eqnrcmai started ? No No Could RCCP contact RCTP ? Is eqnrcmai started ? Yes Are RCTP+RCCP serv. started ? No Start RCTP +RCCP Services Yes Are RCTP+RCCP serv.
From here on, the RC Proxy problem determination process is explained in detail. Are RC Target Proxy and RC Controller Proxy services started? If these services or process are not up and running, you need to start them. If you are using a Relay between the two proxies, you need to verify that the Relay service or process is up and running too. Could the RC Target Proxy contact the RC Controller Proxy? When the components are started, they try to exchange signals, called a handshake.
Is the eqnrsmai process started on the RC Controller? If the eqnrcmai.exe is spawned at RC Target, you also need to verify if the eqnrsmai.exe process has been spawned on the RC Controller. This can be verified by either checking the lcfd.log file or by using a process monitor tool, such as Windows Task Manager. Could the RC Controller contact the RC Target Proxy? As soon as the eqnrcmai.
5.1.2 Session management If you experience problems once the session have been successfully established, you need to collect the related RC Controller and RC Target trace files according to the IBM Tivoli Remote Control User’s Guide, SC23-4842. It is recommended to check also the RC Target Proxy and RC Controller Proxy status in order to verify that the Proxy process isn't crashed or it has not been stopped after establishing the session. 5.
By default, the rcproxy.log file has debug level 3, the one we recommend, since it will display comprehensible information. But this parameter can have values between 0-11. Since values higher than 3 contain debugging information used by developers also, we recommend that you set them only if requested by the Customer Support Engineers, since this will notably affect the performance of the Remote Control Proxy service, and because the error messages may not be easily understood.
= 0 = 2104 = Proxy listen port: 5020 From the log, we are able to gather information regarding the Proxy name and type, if it is a Child or a Parent, if it is running on a TFST environment and, above all, if the connection with the other Proxies is working. Analyzing the log information showed in Example 5-2, we see that: This is a Target Proxy. 03/02/06 15:59:01 0 2104 Proxy type: target It runs on the Endpoint Proxy machine and therefore it is a Parent Proxy.
From this log we are able to gather information regarding the Proxy name, Proxy type, the number of sessions that this Proxy can handle at the same time, and the communication status. The last few lines of the rcproxy.log, marked in bold, show that the communication between Controller and Target Proxy is working. 5.2.2 The remcon.trc This is a generic trace file used to log information related to the Remote Control Controller or Target machine.
[2808] Thu Feb 06 17:10:45 2003 3 EP odnum is 12 [2808] Thu Feb 06 17:10:45 2003 3 CMainFrame::OnCreate - Creating status bar [2808] Thu Feb 06 17:10:45 2003 3 CMainFrame::OnCreate - Creating resizable toolbar [2808] Thu Feb 06 17:10:45 2003 3 Connection with proxy [2808] Thu Feb 06 17:10:45 2003 3 Connection port is: [5020] [2808] Thu Feb 06 17:10:45 2003 3 Connection was opened [2808] Thu Feb 06 17:10:45 2003 3 GetSIDofCurrentUser - Entering...
5.3 Troubleshooting examples In this section we provide a few troubleshooting examples for Remote Control session startup problems in a TFST environment, using the testing scenario in Figure 4-2. 5.3.1 Case 1: Controller not connecting to Target Proxy In this case we describe a troubleshooting example of a startup session problem when the Proxy configuration is not correct.
For this purpose we look at the WHO-TELL message in the Target (Example 5-5) and Controller (Example 5-6) rcproxy.log. Example 5-5 The Target Proxy log file 03/02/12 11:39:22 3 1340 logInit - Message logging initialized (level=3, logmax=1MB). 03/02/12 11:39:23 1 1340 sendCommandLineRequest: cannot connect to 127.0.0.
5. We check if the Controller connects to the Target Proxy by looking at the remcon.trc, Example 5-7, checking the value for the /C parameter and comparing the result with rcproxy.log (Target Proxy log file), Example 5-5. Example 5-7 The remcon.
5.3.2 Case 2: Target Proxy service is not active In this case we assume that the Target Proxy service is down and the connection between the two Proxies is not working. Based on this scenario we provide troubleshooting examples to discover and solve this issue. As soon as we start a Remote Control session with the Target Endpoint, we get the error message in Figure 5-5.
03/02/12 15:06:49 0 1860 Database path './' 03/02/12 15:06:49 0 1860 UDP forwarding enabled 03/02/12 15:06:49 0 1860 max sessions 256 03/02/12 15:06:49 3 1860 initGroupHandler - no Proxy groups created 03/02/12 15:06:49 0 1860 Using default port range of 6000-8000 03/02/12 15:06:49 3 1860 FSR0001W Endpoint Proxy Started 03/02/12 15:06:49 0 1860 Initializing the communication layer ...
03/02/12 15:01:56 0 1144 Maximum log size 1 (MB) 03/02/12 15:01:56 3 1144 FSR0001W Gateway Proxy Started 03/02/12 15:01:56 0 1144 gateway port 9494 03/02/12 15:01:56 0 1144 Using 0.0.0.0 for gateway interface 03/02/12 15:01:56 0 1144 TCP/IP timeout 240 03/02/12 15:01:56 0 1144 Gateway Proxy label tic01005-gw. 03/02/12 15:01:56 0 1144 Using default port range of 6000-8000 03/02/12 15:01:56 0 1144 max sessions 256 03/02/12 15:01:56 0 1144 Initializing the communication layer ...
03/02/12 15:06:54 3 1760 initRoutedSessionsManager: no network card specified for children-local-host, using random interface 03/02/12 15:06:54 2 1760 initRoutedSessionsManager: children-remote-file parameter not specified 03/02/12 15:06:54 3 1736 routingManager: TELL command received [l=tic01005-gw] 03/02/12 15:06:55 3 1736 routingManager: WHO reply command received [l=tic01005-gw] Example 5-13 The Relay log file (instance used by remote control proxies) 03/02/12 14:24:34 3 1544 logInit - Message logging
5.3.3 Case 3: Wrong Proxy configuration In this case we assume that the Target Proxy is not configured properly and the communication between remote control proxies does not work, while the gateway and Endpoint Proxy communication works fine. Based on this scenario we provide troubleshooting examples to discover and solve this issue. As soon as we start the session, we get the error message in Figure 5-6.
03/02/12 16:09:16 2 1920 initRoutedSessionsManager: children-remote-file parameter not specified 03/02/12 16:09:17 1 1920 tcpunidir.open [line=683]: connect() failed (e=9, le=10061, wsa_le=10061) 03/02/12 16:09:17 1 1920 tcpunidir.open: cannot connect to 9.3.4.248+7021 03/02/12 16:09:17 1 1920 ERROR tcpunidir.open: cannot open connection 03/02/12 16:09:17 1 1920 ERROR multiplex.
The we look at the Controller Proxy log file as in Example 5-17. Example 5-17 The remote control Controller log file 03/02/12 16:03:34 3 1820 logInit - Message logging initialized (level=3, logmax=1MB). 03/02/12 16:03:35 1 1820 sendCommandLineRequest: cannot connect to 127.0.0.
parent-cm-type=cm-tcp-unidirectional children-cm-type=cm-tcp-unidirectional [log] log-file=relay.log debug-level=3 max-size=1 [parent-cm-info] connection-mode=server [children-cm-info] connection-mode=client local-port-range=4023 From the configuration file, we find that the Relay uses port 7020 to communicate with the Target Proxy, but the Target Proxy looks for port 7021, as shown in Example 5-15. This means that the rcproxy.cfg of the Target Proxy needs to be changed accordingly.
5.4 Troubleshooting the firewall This section describes some of the important points to consider if things go wrong in the firewall environment. The firewall is an important entity when it comes to Tivoli network management across firewalls. There is every chance that some troubleshooting will be required on the firewall to check that firewall rules are properly set up to allow the permitted traffic and deny the unwanted traffic.
8. When you alter any configuration on the firewall, some services require that you stop and restart those services. Check if you are missing this point for any of the services or configuration changes you made. 9. Check netstat -rn command output and make sure the routing information on the firewall is proper. Check netstat -an command output and see that the required protocol ports are in the proper state (listening/established).
Part 4 Part 4 Appendixes © Copyright IBM Corp. 2003. All rights reserved.
174 IBM Tivoli Remote Control Across Firewalls
A Appendix A. Tivoli Firewall Security Toolbox overview In this appendix we provide a brief overview of Tivoli Firewall Security Toolbox, (TFST). We present the basic ideas on the purpose, installation, configuration, and usage of TFST. For additional information, refer to the Firewall Security Toolbox User ’s Guide, GC23-4826. © Copyright IBM Corp. 2003. All rights reserved.
Introduction Tivoli Firewall Security Toolbox enables Tivoli network management across firewalls without compromising security. When one or more firewalls exist between Endpoint and Gateway, the communication channels permitted by the firewall are limited. The Tivoli firewall Security Toolbox enables the Endpoint and Gateway communication across firewalls while respecting firewall restrictions.
Event Sink This component emulates the Tivoli Enterprise Console® (TEC) Server. All non-TME adapters served by this Event Sink are configured to point to this as their TEC Server. In the firewall environment where the firewall separates non-TME adapter machine from the Gateway, the Event Sink collects the events sent from non-TME adapters as if it were a TEC server and sends the events to the TEC server. The Event Sink can collect the events from multiple non-TME adapters.
Just as multiple Gateways can connect to a single Gateway and multiple Gateways to a single Tivoli server, multiples Endpoints can connect to a single Gateway Proxy and multiple Gateway proxies can connect to a single Endpoint Proxy. And the communication between these Tivoli components is based on a Tivoli Proprietary protocol over TCP/IP.
Sending events across firewalls Tivoli adapters use Endpoints to send events to the TEC Server through Tivoli connections. When the firewall separates the Endpoint from the TEC server, the machines connect through the Gateway and Endpoint Proxies. Machines that are not part of the Tivoli environment use non-TME adapters to send events to TEC servers through non-Tivoli connections.
Installation and configuration of TFST This section explains how to install and configure the components of Tivoli Firewall Security Toolbox. Installation of TFST Refer to the Firewall Security Toolbox User ’s Guide, GC23-4826, for the prerequisite software and hardware details of Tivoli Firewall Security Toolbox. To install TFST, decompress the tar file or self-extracting EXE file.
Installing Relay instances You can install multiple instances of Relay on the same machine. Do the following to install the first Relay instance: To install Relay on a UNIX based machine, go to the Relay directory and then to the subdirectory for the platform on which Relay will run and run install.sh from the subdirectory. Follow the steps provided in Firewall Security Toolbox User ’s Guide, GC23-4826. To install Relay on a Windows machine, run setup.
Following are the different sections available: Endpoint Proxy The [Endpoint-Proxy] section lists the mail options for the Endpoint Proxy. Refer to Table 2 in the Firewall Security Toolbox User ’s Guide, GC23-4826, under “Configuring the Endpoint Proxy” subsection for the [Endpoint-Proxy] keywords and their descriptions available. Log The [log] section lists the log options.
Gateway-Proxy The [Gateway-Proxy] section lists the main options for the Gateway Proxy. Refer to Table 6 in the Firewall Security Toolbox User ’s Guide, GC23-4826 under “Configuring the Gateway Proxy” subsection for the [Gateway-Proxy] keywords and their descriptions available. Log The [log] section lists the log options. Refer to Table 7 in the Firewall Security Toolbox User ’s Guide, GC23-4826 under “Configuring the Gateway Proxy” subsection for the [log] keywords and their descriptions available.
Log The [log] section lists the log options. Refer to Table 11 in the Firewall Security Toolbox User ’s Guide, GC23-4826 under “Configuring the Relay” subsection for the [log] keywords and their descriptions available. Communication layer The [communication-layer] section lists the options on how the Relay connects to its parent and children, Relays, Endpoint Proxy or Gateway Proxy.
Following are the different sections available: SENDING The [SENDING] section lists the options for sending events to the TEC server. Refer to Table 15 in the Firewall Security Toolbox User ’s Guide, GC23-4826 under “Configuring the Event Sink” subsection for the [SENDING] keywords and their descriptions available. RECEPTION The [RECEPTION] section lists the options for receiving events from non-TME adapters.
TFST components and operations In this section, we discuss the port requirements for the operations of Tivoli Firewall Security Toolbox components in general and Endpoint Proxy and Gateway Proxy in particular. Each component of TFST (Endpoint Proxy, Gateway Proxy and Relay) will use source and destination ports. TFST gives you the policies to control this port allocation. Note that TFST components can act as both client and server depending on the direction the connection is initiating from.
Effective Utilization of TFST across firewalls The following key points of TFST provide minimum filter rules on the firewall and securely and efficiently configure Tivoli Management Framework across firewalls: Select the Endpoint Proxy to the Relay or Gateway Proxy as unidirectional to permit connections initiated by only one machine. Select the Relay connect to the parent Relay or Endpoint Proxy as unidirectional to permit connections initiated by only one machine.
188 IBM Tivoli Remote Control Across Firewalls
B Appendix B. Introducing firewalls In this appendix we provide a basic overview of firewalls to give you an understanding of the various firewall functionalities, the important tools and components of firewalls, and some of the available firewall products in the market. © Copyright IBM Corp. 2003. All rights reserved.
Introduction A firewall is basically a security solution operating between one or more secure, internal private networks and other (non-secure) networks or the Internet. The main objective of a firewall is to prevent unwanted or unauthorized communication into or out of the secure network. The concept of firewalls started with this basic objective, but has extended its usage and functionality to the changing needs of this corporate world.
We provide a brief overview of each firewall tool and its components to give you a general understanding of each of these features. Packet filters Packet filters are the tools that inspect the information coming in and going out of the network packet by packet. Packet filters inspect packets at the session level based upon multiple criteria such as time of day, source/destination IP address and port number, packet type, and subnet.
This means that, when connecting through a proxy server, the TCP/IP connections are broken at the firewall, so the potential for compromising the secure network is reduced. Users may be required to authenticate themselves, using one of a number of authentication methods. One major advantage inherent in proxy servers is internal address hiding. All outbound proxy connections use the firewall address. Another major advantage of the proxy server is security.
SecureWay Policy Director integration with firewall The SecureWay Policy Director administers (writes to) the SecureWay Directory, which is IBM's implementation of the lightweight directory access protocol (LDAP). The firewall can access (reads from) the SecureWay Directory to authenticate firewall users of the following types of proxy services: FTP Telnet HTTP Socks Some firewalls provide the facility to customize a user exit to support any other authentication mechanism.
In the outbound direction, NAT converts the unregistered addresses into valid registered Internet addresses. In the inbound direction, NAT converts the registered Internet address back to the unregistered addresses. Furthermore, by using NAT, addresses in the private network are hidden from the external world providing an additional level of security.
Firewalls in the market Following are some of the firewall products currently in the market. You can check out the following URLs for more information about each firewall: IBM SecureWay firewall http://www-3.ibm.com/software/security/firewall Raptor firewall http://www.symantec.com Cisco PIX http://www.cisco.com Check Point firewall-1 http://www.checkpoint.com Firewall Toolkit http://www.fwtk.org/main.html Appendix B.
196 IBM Tivoli Remote Control Across Firewalls
Abbreviations and acronyms ACL Access Control List ACP Adapter Configuration Profile ADE API ICMP Internet Control Message Protocol Advanced Development Environment IETF Internet Engineering Task Force Application Programming Interface IKE Internet Key Exchange INV Inventory ARM Application Response Measurement IOM Inter Object Messaging IPX BDT Bulk Data Transfer Internetwork Packet Exchange BOA Basic Object Adapter IR Install Repository (SIS) CORBA Common Object Request Broker
SMB Server Message Block (Microsoft networking protocol) SNMP Simple Network Management Protocol SPX Sequenced Packet Exchange SSL Secure Sockets Layer SWD Software Distribution TACF Tivoli Access Control Facility TCP/IP Transmission Control Protocol/Internet Protocol TEC Tivoli Enterprise Console TFST Tivoli Firewall Security Toolbox TMA Tivoli Management Agent TME Tivoli Management Environment TMF Tivoli Management Framework TMR Tivoli Management Region TRIP Former acronym used
Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. IBM Redbooks For information on ordering these publications, see “How to get IBM Redbooks” on page 200.
Zwicky, et al, Building Internet Firewalls, O’Reilly and Associates, Inc., 2000, ISBN 1565928717 Online resources These Web sites and URLs are also relevant as further information sources: IBM Tivoli Remote Control Product Information http://www-3.ibm.com/software/tivoli/products/remote-control/ IBM SecureWay firewall http://www-3.ibm.com/software/security/firewall Raptor firewall http://www.symantec.com Cisco PIX http://www.cisco.com Check Point firewall-1 http://www.checkpoint.
Index Numerics 3DES 194 A Authentication 190 AutoSocks 192 B bidirectional 61 bidirectional communication 12, 61 bidirectional connection 61 C CDMF 194 collection 6 communication ports 62 communication types bidirectional 61 unidirectional 61 configuration files epproxy.cfg 12 gwproxy.cfg 12 rcproxy.
J P Java xiv Java 2 SDK 77 JRE 1.
rc_def_ports policy 58 rc_def_proxy 58, 107, 160 rc_def_proxy policy 37, 40, 47, 52, 107 rcproxy 109, 113 rcproxy.cfg 156 rcproxy.cfg file 37, 41, 48 rcproxy.log 155–156 rcproxy.route 106, 154 rcproxy.route file 37, 41 RCProxy-TFST 60 Redbooks Web site 200 Contact us xvii reexec 146 Relay 176 relay 6 relay.cfg 150 relay.log 150 remcon.ini 158 remcon.ini file 151 remcon.
wgetpolm 107 Who request 149, 153 wping 146 wputpolm 107 wtrace 18 204 IBM Tivoli Remote Control Across Firewalls
Implementing IBM Tivoli Remote Control Across Firewalls (0.2”spine) 0.17”<->0.
Back cover ® Implementing IBM Tivoli Remote Control Across Firewalls Achieve Remote Control without sacrificing security Guide for TCP/IP ports used and troubleshooting Set up a secure Remote Control environment based on realistic scenarios The primary objective of this IBM Redbook is to provide concepts, recommendations, and techniques when planning and implementing IBM Tivoli Remote Control 3.8 in an environment that involves firewalls.