| Oracle® Communications IP Service Activator Security Guide Release 7.2 E35657-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Security Guide Release 7.2 E35657-01 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of Oracle Communications IP Service Activator security.
The following principles are fundamental to using any application securely:
Keep software up to date. This includes the latest product release and any patches that apply to it.
Keep up to date on security information. Oracle regularly issues security-related patch updates and security alerts. You must install all security patches as soon as possible. See Critical Patch Updates and Security Alerts on the Oracle Web site:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
Limit privileges as much as possible. Users should be given only the access necessary to perform their work. User privileges should be reviewed periodically to determine relevance to current work requirements.
Monitor system activity. Establish who should access which system components, and how often, and monitor those components.
Install software securely. For example, use firewalls, secure protocols such as SSL, and secure passwords. See "Performing a Secure IP Service Activator Installation" for more information.
Learn about and use the IP Service Activator security features. See "Implementing IP Service Activator Security" for more information.
Use secure development practices. For example, take advantage of existing database security functionality instead of creating your own application security. See "Security Considerations for Developers" for more information.
When planning an IP Service Activator implementation, consider the following:
Which resources need to be protected?
For example:
You must protect internal data.
You must protect system components from being disabled by external attacks or intentional system overloads.
You must protect the archived device configurations.
You must protect the IP Service Activator object information model (the database).
Who are you protecting data from?
For example, you must protect customer data from other customers, but someone in your organization might need to access that data in order to manage it. You can analyze your workflows to determine who needs access to the data; for example, it is possible that a system administrator can manage your system components without needing to access the system data.
What will happen if protections on a strategic resource fail?
In some cases, a fault in your security scheme is nothing more than an inconvenience. In other cases, a fault might cause great damage to you or your customers. Understanding the security ramifications of each resource helps you protect it properly.
IP Service Activator security is designed to protect IP Service Activator users, IP Service Activator modules, the router configuration data, the database, the application logs, and the IP Service Activator Web service.
IP Service Activator application security: Users of the application are authenticated using the Oracle IP Service Activator object model, based on the roles and groups defined in it. This applies both to the IP Service Activator user interface (client) and the command line interface.
IP Service Activator module security: Module security follows the same methods for validation and authentication as the client.
Router configuration data security: The router configurations are stored in the Oracle Database, which requires database credentials or can be accessed by using Configuration Management. Configuration Management is stored securely by IP Service Activator application security.
Database security: Different interfaces are stored differently. The client and command line interface use credentials encrypted in a file. The IP Service Activator Web service and the Configuration Management module credentials are stored securely inside the Java Database Connectivity (JDBC) data source in the Oracle WebLogic server.
Application log security: The application, settings and properties, and logs are protected by the user authorization and authentication procedures of the host system (UNIX or Oracle Linux). Only the installed user has access to the files, based on file permissions.
IP Service Activator Web service security: The Web service is secured by an Oracle WebLogic security policy, along with a WebLogic user and group created using the IP Service Activator Configuration GUI.
IP Service Activator comprises the various components shown in Figure 1-1, including the components to which it connects. Each installed or integrated component requires special steps and configurations to ensure system security.
Figure 1-1 IP Service Activator Components
This section describes recommended deployment topologies for IP Service Activator.
Figure 1-2 shows a single-computer deployment topology: the simplest IP Service Activator deployment architecture.
Figure 1-2 Single-Computer Deployment Topology
In this topology, all the application components and data are kept on a single system, protected from external attacks by a firewall. The firewall can be configured to block known illegal traffic types. There are fewer resources to secure because all the components are on a single system and all the communication is local. Fewer ports have to be opened through the firewall. Conversely, there are fewer points of attack, and, if security is compromised, an attacker would have access to the entire system and data.
Oracle recommends that you run the whole system inside the customer's intranet and not expose components or computers to the public Internet.
A single-computer installation topology is best suited for test and lab environments or a small network. See IP Service Activator Installation Guide for information about the system setup depending on your network size.
Figure 1-3 shows a tiered deployment topology: a scalable IP Service Activator deployment offering greater security.
In this topology, firewalls isolate the application tier from the intranet. Oracle recommends that you run the whole system inside your intranet and not expose components or computers to the public Internet. Two layers of firewall protect the database and servers from potential attacks. Both firewalls can be configured to block known illegal traffic types. The two layers of firewall provide intrusion containment. Although there are a greater number of components to secure, and more ports have to be opened to allow secure communication between the tiers, the attack surface is spread out.
The application tier has components like the Policy Server and Web Server. The other tier has components like the Network Processor, database, and routers.
This section lists IP Service Activator-specific operating system security configurations.
For more information, see the following documents:
Guide to the Secure Configuration of Red Hat Enterprise Linux 5
Hardening Tips for the Red Hat Enterprise Linux 5
IP Service Activator uses the default ports shown in Table 1-1. If you are not using the defaults, ensure that the correct values are entered by using the IP Service Activator Configuration GUI.
Table 1-1 IP Service Activator Default Ports
| Port | Value |
|---|---|
|
HTTP |
80 |
|
CORBA |
2809, 2810 |
|
FTP (Configuration Management) |
20, 21 - (not configurable) |
|
TFTP (Configuration Management) |
69 - (not configurable) |
|
Syslog (Configuration Management) |
514 (UDP) -(not configurable) |
|
WebLogic Port(s) - Admin Server Port, and the Managed Server Port(s) |
7001, 7003 (defined at domain creation) |
|
Oracle Database port |
1521 |
|
SSH |
22 (not configurable) |
|
Configuration GUI ORB Server Ports (ports configured in the Configuration GUI) |
2810-2828 |
|
Telnet |
23 (not configurable) |
|
Logreader Socket Port |
4446 |
|
TACACS (device communication) |
49 (not configurable) |
If IP Service Activator computers do not use the secure tunnels (see "Secure Integration of IP Service Activator") to communicate between computers, Oracle recommends that you lock the client to a particular port, unless the firewall allows any port to establish a reverse connection from the Policy Server to the client.
If you are using the Network Processor audit and the client is on the other side of the firewall, the port that needs to be forwarded is port 2814 (the default value from the Configuration GUI). For more information, see the knowledge article available on the Oracle Support Web site: https://support.oracle.com [ID 1335658.1].
If you are using Configuration Management, the WebLogic port needs to be open between:
The computer with IP Service Activator Engine (WebLogic Server) and the browser client.
The computer with IP Service Activator Engine and the computer with the Configuration Management Collector installed.
Oracle recommends that the port on which the WebLogic Administration console runs not be open to the public Internet and be restricted to inside the firewall so that only administration operations can be contained within the customer's network.
This section describes how to secure the configuration between the IP Service Activator computers if the deployment is a multi-computer installation.
Oracle recommends that, if your installation is on multiple computers, the communication between the computers be secured by enabling an encrypted SSH tunnel. This tunnel has all IP Service Activator traffic on it. Configuring this tunnel is well documented in Windows, Linux, and UNIX documentation. At a minimum, the client and the server components will be on different computers, so a tunnel should be set up between the client computer and the Policy Server.
For example, on the Windows computer where the client is installed, the user must redirect all IP Service Activator traffic on the Windows client through the tunnel. To do this, you need administrator rights.
To forward IP Service Activator traffic:
Pin down all the floating IP Service Activator ports using the BOAiiop_name_port command line option. Take note of all the fixed IP Service Activator ports (for example, naming service).
Configure the tunnel to do port forwarding from each of the pinned down or fixed ports into the tunnel (bi-directionally).
To set up the client, modify the IP Service Activator User Interface shortcut found in the Start menu. Go to the properties of the shortcut, and modify the target command line to include the following text at the end of the line:
BOAiiop_name_port 127.0.0.1:1970
This forwards the client to run on port 1970.
Three other ports must be configured so that the client can communicate with the Policy Server. Do the following:
Configure the SSH port forwarding tunnel from the client to the IP Service Activator naming service. The default is to use 127.0.0.1:2809 as the Destination.
Configure the SSH port forwarding tunnel from the client to the IP Service Activator policy server. The default is to use 127.0.0.1:2810 as the Destination.
Configure the remote SSH port forwarding tunnel from the Policy Server to IP Service Activator. The default is to use 127.0.0.1:1970 as the Destination.
If you are using Citrix as a terminal server, using the client locked to a BOaiiop_port might be a problem because all client instances are connecting from the same IP.
If you are integrating IP Service Activator and Oracle Communications Order and Service Management (OSM), you must secure the configuration between them. For information about OSM and IP Service Activator integration, see IP Service Activator Concepts.
OSM secures Oracle Communications ASAP and IP Service Activator Web service interactions using a Web services user name and password located in the WebLogic server of the activation system (either ASAP or IP Service Activator). Communication is through Java Message Service (for Activation) and HTTP (for view framework). You must store this user name and password within the Fusion Middleware Credential Store Framework (CSF) using the credStoreAdmin.bat script located in the OSM_Home/SDK/XMLImportExport folder (where OSM_Home is). The credStoreAdmin.bat script creates a map and a key that correspond to the activation system Web Service user name and password. For more information about this script, see the OSM System Administrator's Guide.
Figure 1-4 Design Studio Activation Task Tab
In Oracle Communications Design Studio, when you configure an activation task for the IP Service Activator activation system (on the Activation Task Details tab), you can choose which protocol to use to submit the request.
For enhanced security, Oracle recommends using Web services because you must also then specify a map name and a key name (shown in Figure 1-4). During installation and configuration, the OSM SDK credStoreAdmin.bat script runs and creates a credential store in WebLogic. The map name and key name are used to access IP Service Activator Web Services credentials at run time. At run time, WebLogic also requires user authorization of the OSM user, which allows the OSM user to use the map name and key name to securely extract the IP Service Activator Web service credentials.
IP Service Activator uses other Oracle products, such as Oracle Database and Oracle WebLogic Server. See the following documents, as they apply to IP Service Activator:
Oracle Database Security Guide.
Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server.
|
 Copyright © 2012, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
