Release 9.2.0
Part Number A96670-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle Enterprise Manager Administrator's Guide Release 9.2.0 Part Number A96670-01 |
|
This appendix discusses how to configure firewall and virtual private networks (VPNs) to allow communication between various components of Oracle Enterprise Manager.
This appendix covers the following topics:
Firewalls protect a company's IT infrastructure by providing the ability to restrict network traffic by examining each network packet and determining the appropriate course of action. Firewall configuration typically involves restricting the ports that are available to one side of the firewall, for example the Internet. It can also be set up to restrict the type of traffic that can pass through a particular port such as HTTP. If a client attempts to connect to a restricted port (a port not covered by a security `rule') or uses a protocol that is incorrect, then the client will be disconnected immediately by the firewall. Firewalls can also be used within a company Intranet to restrict user access to specific servers.
The various components of Enterprise Manager 9i (Console, Oracle Management Server, and Intelligent Agents) can be deployed on different nodes, which in turn can be separated by firewalls. This section describes how firewalls can be configured to allow communication between the different components of Enterprise Manager. The three most common deployments are covered:
In this configuration, the Enterprise Manager Console and Management Server are separated by a firewall.
Text description of the illustration firewala.gif
Special configuration is not required for either the Console or the Management Server in this case.
In this configuration, the Intelligent Agent that runs on the managed node and the Management Server are on opposite sides of the firewall, as shown in the following illustration.
Text description of the illustration firewalb.gif
To enable network communication between the Management Server and Intelligent Agents on managed targets, several network ports must be opened in the firewall to allow TCP traffic. Functional assignments for these ports are shown in the following table.
No special setup and configuration is required for the Management Server or Intelligent Agents in this situation.
If the Management Server and administered database (or other managed target) are separated by a firewall, then the Management Server acts as a proxy for the Enterprise Manager Console, resulting in the remote database viewing the Management Server as the client. For this reason, there must be a SQL*Net proxy between the Management Server and the administered database. If the Console is launched in Standalone Mode, there must be a SQL*Net proxy between the Console and the Management Server, and between the Management Server and ALL collections services (Data Gatherer) connections.
Some firewalls use a feature called Network Address Translation (NAT). This feature masks the true IP address of a client by translating it to a different IP address. Packets sent from a remote client to a server through the firewall will be known to the server by this translated address. As the client and server communicate, the NAT software handles the mapping of the true IP address to its translated address. Of the two Enterprise Manager configurations previously discussed, only an Enterprise Manager Console and Management Server can be separated by firewalls using NAT. No changes are required for Enterprise Manager to support NAT in this configuration.
The Management Server and Intelligent Agent cannot be separated by firewalls using NAT because the Management Server and Agent communication includes the other's host address information, which is stored in the data packet rather than in the IP header. Since NAT only looks for (and translates) addresses in the IP header, NAT will not work with Management Server/Agent communication.
Virtual Private Networks (VPNs) allow remote employees to connect in a secure fashion to a corporate server located in the corporate Local Area Network (LAN) using the routing infrastructure provided by a public network (such as the Internet). From the user's perspective, the VPN is a point-to-point connection between the user's computer and a corporate server. The nature of the intermediate network is irrelevant to the user because it appears as if the data is being sent over a dedicated private link.
Text description of the illustration virprivn.gif
In order to provide a secure point-to-point channel of communication, VPN software includes services such as user authentication and data encryption. It also implements security standards defined by the IP Security (IPSEC) protocol. IPSEC is a series of guidelines for the protection of Internet Protocol (IP) communications. It specifies standardized ways for securing private information transmitted over public networks. Communication between security systems developed by different vendors is possible if they comply with the IPSEC standards.
To create secure VPNs, VPN software typically operates in IPSEC Tunnel Mode. In this mode, data sent from a client is first encrypted and then encapsulated before being transmitted over an insecure, public network such as the Internet. Upon arriving at its destination, VPN software unpacks, decrypts and authenticates the data received, then forwards it on to its final destination.
Many e-businesses use both VPNs and firewalls as part of their security infrastructure. In these configurations, the firewall must allow IPSEC-compliant traffic to pass through (port 500 is used by default). Application data that is sent via VPN is first encapsulated and tunnelled through port 500 in the firewall, unpacked, and sent to its final destination. Targets that have been set up to use VPN thus avoid having to open up additional ports in the firewall. Applications that run on VPN-enabled nodes can also communicate safely and securely across the firewall.
As previously discussed, VPNs that comply with IPSEC standards allow the secure transfer of information over the internet: Remote clients can connect to a secure server with minimum configuration and maximum security. It is also possible to use VPNs in conjunction with firewalls. The following example shows a VPN environment with the Enterprise Manager Console and the Management Server on opposite sides of the firewall.
Text description of the illustration firewalc.gif
In this example, both the Console and Management Server machines have VPN software configured to provide a secure communication channel between the two. Specifically, the machine running Enterprise Manager client must have the VPN client software installed. The machine running the Management Server must have the VPN gateway software installed. Additionally, the firewall must be configured to allow only IPSEC traffic (IPSEC by default uses port 500). In this configuration, all the network traffic between the Console and the Management Server will be tunneled automatically through port 500 by the VPN software.
No additional configuration is required for Enterprise Manager components since the VPN software handles communication tasks automatically.
When the Enterprise Manager Console is launched, the user may be prompted by a VPN client software dialog to enter user security information. Once a valid username and password are provided to the VPN client, subsequent communication between the Console and Management Server across the virtual network will appear seamless.
No additional changes are required for the firewall configuration if IPSEC traffic is already allowed.
Some VPN providers may allow server processes on different nodes to communicate. In these configurations, it is possible to deploy the Management Server on one VPN-enabled node and the Agent on another VPN-enabled node. The same principles as described in the previous section apply. It is important to note that communication between the Management Server node and Agent node is bi-directional, so each would need to function as both a VPN client and VPN server. Hence, both the VPN client and server software must be installed on each node.
|
Note: Sun Solaris version 8 supports VPN server process communication. Refer to the Solaris System Administrator's Guide for more details. |
If the Enterprise Manager Console is launched in Standalone mode, the Console connects directly to a managed target (e.g. database) in the traditional client-server mode, using SQL*Net to communicate. If a firewall separates the Console and its target, several options are available. These include:
In this case, the setup will be similar to the Console - Management Server using VPN setup as described in the previous section.
Several firewall vendors (e.g. CheckPoint) include an Oracle Net proxy capability which allows SQL*Net traffic to pass through its firewalls. This functionality is primarily available from the firewall vendors.
Oracle Net's Connection Manager provides database connection pooling capabilities. Client applications connect to Connection Manager which in turn redirects the connection to the database. In this case, firewalls need to allow connections from the client to Connection Manager.
Refer to the Oracle Net documentation for more details.
The Performance Manager or Capacity Planner applications can be launched separately in order to connect directly to the Intelligent Agent (which incorporates the data collection services) on a target node. If a firewall separates Performance Manager and the Agent, or Capacity Planner and the Agent, then the firewall needs to be configured as follows:
No additional configuration is required for Performance Manager, Capacity Planner or the Intelligent Agent.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|
