| StorageTek Automated Cartridge System Library Software Security Guide Release 8.3 E49313-02 |
|
 Previous |
 Next |
| StorageTek Automated Cartridge System Library Software Security Guide Release 8.3 E49313-02 |
|
Previous |
Next |
This section outlines the planning and implementation process for a secure installation and configuration and describes recommended deployment topologies for ACSLS.
To better understand security needs, the following questions must be asked:
The key resources that ACSLS manages are tape libraries, drives, and cartridges. They need to be protected from inadvertent as well as malicious access. For example, prevent people from mistakenly logging into a different ACSLS server by using different passwords for the ACSLS user IDs on different servers.
You want to protect the tape storage resources from both unauthorized internal and external access.
ACSLS can mount cartridges on tape drives. If a user can connect to the tape drive through the data path, they can read data on the tape if it is not encrypted.
Users who have access to both ACSLS and a tape library can enter and eject cartridges from a tape library.
When securing ACSLS and required infrastructure components, follow this procedure to ensure that ACSLS will continue to function after the changes are made:
Install ACSLS.
Verify that ACSLS is functioning correctly. Include configuring and auditing libraries, mounting and dismounting tapes, entering and ejecting tapes, and backing-up and restoring the database.
Implement the change to increase security.
Verify that ACSLS still functions correctly.
This section describes recommendations for deploying ACSLS to secure Internet access.
ACSLS and the tape libraries it supports should be deployed behind the corporate firewall. If people working remotely need to login to the ACSLS server, they can access it through a VPN.
|
Note: If you have an IPv4-based edge firewall, it should be configured to drop all outbound IPv4 protocol 41 packets and UDP port 3544 packets to prevent Internet hosts from using any IPv6-over-IPv4 tunnelled traffic to reach internal hosts. |
If client applications, which use ACSLS to mount tapes and manage tape libraries, are separated from ACSLS by a firewall, we recommend enabling the Firewall Security Option. Even if the client applications are not separated from ACSLS by a firewall, implementing the Firewall Security Option provides additional ACSLS security by restricting the ports used for communication between ACSLS and its client applications, as shown below. For these reasons, the CSI_FIREWALL_SECURE static variable defaults to TRUE in ACSLS 8.1 and later releases.
For details, see the ”Firewall Security Option” appendix in the ACSLS Administrator's Guide.
The following ports are used on the ACSLS server. Ensure that any firewalls are configured to allow traffic to these ports. This included firewalls implemented by ipfilter on Solaris or iptables on Linux.
22 both directions – used for ssh access.
111 portmapper, unless portmapper has been disabled.
115 used for SFTP (Secure File Transfer Protocol).
161 default port for ACSLS SNMP agent - get/set/walk.
162 default port for ACSLS SNMP agent - traps.
|
Note: The ports used by the ACSLS SNMP agent are configurable by the command:AcslsAgtdSnmpConf [ -p port ] [-t trap port] [-d]. The -d option displays the current setting. After changing the port setting, you must restart the agent with the command, agentRegister. |
5432 default port for internal communication from ACSLS to the PostgreSQL database (the PGPORT environment variable for the acsss user ID).
If port 5432 is taken, the next available higher port number is used.
|
Note: Port 5432 only needs to be accessible from localhost (127.0.0.1). |
7001 and 7002 - used by WebLogic and the ACSLS GUI.
30031 or the ACSLS CSI's listening port, set by CSI_INET_PORT.
50003 port used for internal communication from the ACSLS GUI and Java components to legacy ACSLS processing. This is not configurable.
For client applications to communicate with ACSLS through the ACSAPI, the following ports must be open:
The client application must be able to communicate with the ACSLS CSI's listening port. This defaults to 30031, and is set by the CSI_INET_PORT static variable.
You can discover which ports are in use by ACSLS to listen for requests from ACSAPI clients with the following command from your Unix shell:
rpcinfo -p | egrep "300031 | 536871166"
The port IDs will be listed in the last field of the display.
The ACSAPI client (for example, a NetBackup or SAM-QFS server) sets its fixed incoming port using the SSI_INET_PORT environmental variable. Specify a port in the range of 1024-65535, excluding ports 50001 and 50004. The ACSLS server must be able to communicate with this port.
|
Note: On an ACSAPI client server, ports 50001 and 50004 are used for AF_INET domain IPC communication to the mini-Event Logger and from client applications to the SSI. |
See the Firewall Security Option appendix in the ACSLS Administrator's Guide for more details about communication between client applications and ACSLS.
Ports that must be open on an SL8500 or SL3000 library:
ACSLS communicates with these ports on an SL8500 or SL3000 library's 2A and 2B Ethernet connections. If communication from ACSLS to these ports is blocked, ACSLS cannot manage the library.
50001 – Used for all normal communication between ACSLS and the library
50002 – Used for by ACSLS HA to determine whether the alternate HA node can communicate with the library before failing over to the alternate node
Besides external firewalls, firewall protection can be implemented on your ACSLS server through ipfilter on Solaris or iptables on Linux. This describes how to manage these firewalls running on your ACSLS server.
Managing ipfilter on Solaris:
Consult the man pages for ipf and ipfilter for detailed information.
The ipfilter firewall is enabled (disabled) by 'root' using the command:
svcadm enable ipfilter (svcadm disable ipfilter)
To learn the current status of ipfilter:
svcs ipfilter
Firewall policies are defined in the file: /etc/ipf/ipf.conf
To allow free communication between components on the local host (e.g. between ACSLS and WebLogic or between the GUI and the ACSLS database), include a statement such as:
pass in quick from 127.0.0.1 to 127.0.0.1
or
pass in quick from 127.0.0.1 to all
You need to define policies that allow access to all of the ports that are needed for ACSLS. For example, to include a policy allowing remote Web-based browsers to access the ACSLS GIU, you need to open up ports 7001 and 7002.
pass in quick from any to any port = 7001
pass in quick from any to any port = 7002
After you discover which ports are used by ACSLS to listen for requests from ACSAPI clients, add 'pass in quick' statements for each of these ports.
It may be necessary to include a 'pass in quick' statement for the RPC portmapper port, 111.
The last statement in your proposed rule set, "block in from any", states that no traffic should reach the host unless specifically allowed in previous statements.
Managing iptables on Linux:
The iptables firewall is enabled (disabled) by 'root' using the command:
service iptables start (service iptables stop)
To check the status of iptables:
service iptables status
The policy file for iptables is /etc/sysconfig/iptables:
You need to define policies that allow access to all of the ports that are needed for ACSLS. For example, to include a policy that allows remote http/https access to the ACSLS GUI, you should update that file to include exceptions for ports 7001 and 7002 using statements like:
-A input -p tcp --dport 7001 -j ACCEPT
-A input -p tcp --dport 7002 -j ACCEPT
After you discover which ports are used by ACSLS to listen for requests from ACSAPI clients, you will need to add exceptions for each of these to the iptables policy file. It may be necessary to include an exception statement for the RPC portmapper port, 111.
This section describes how to install and configure Solaris securely.
Suggestions include:
Apply all significant security patches to the OS and to services installed with the OS. Please apply these patches selectively, because applying all available updates may install new features and even new OS releases that ACSLS and ACSLS HA have not been tested with.
Disable telnet and rlogin. Use ssh instead. Also disable ftp and use sftp instead.
Disable the telnet, rlogin, and ftp services by issuing the following commands as root.
To see all the services:
svcs
To disable telnet, rlogin, and ftp:
svcadm disable telnet
svcadm disable rlogin
svcadm disable ftp
Don't disable ssh. You want users to remotely login to the ACSLS using ssh, not telnet or rlogin. Also do not disable sftp.
ACSLS requires rpc-bind. Do not disable it.
If Solaris is installed with the Secure by Default option, you need to alter a network configuration property for rpc-bind to permit ACSAPI clients to send requests to ACSLS.
See the ACSLS Installation manual, "Installing ACSLS on Solaris" chapter, "Installing Solaris" section for details.
Some Ethernet ports on the ACSLS server need to be open for communication with ACSLS. Client applications use specific Ethernet ports for communication with ACSLS, and ACSLS communicates with specific ports on tape libraries. See Ethernet Ports Used for ACSLS Communication for the ports that need to be available for ACSLS communication. On the ACSLS server ensure that ipfilter is configured to allow traffic to the ports used by ACSLS.
Determine your Solaris auditing policy. The ”Auditing in Oracle Solaris” section in "Oracle System Administration: Security Services" can help you plan for what events to audit, where your audit logs should be saved, and how you want to review them.
Suggestions to install and configure Linux securely:
Apply all significant security patches to the OS and to services installed with the OS. Please apply these patches selectively, because applying all available updates may install new features and even new OS releases that ACSLS and ACSLS HA have not been tested with.
Make sure that telnet and rlogin are not installed or disabled. Use ssh instead.
Also make sure that ftp is not installed or disabled, and use sftp instead.
To see all services, login as root and:
service –-status-all
To delete services permanently, use:
svccfg delete -f service-name
Don't disable ssh. You want users to remotely login to the ACSLS using ssh, not telnet or rlogin. Also do not disable sftp.
Network services, specifically rpcbind, must be enabled to allow ACSLS client communication.
When launching rpc on Linux, launch it with the –i flag.
Some Ethernet ports on the ACSLS server need to be open for communication with ACSLS. Client applications use specific Ethernet ports for communication with ACSLS, and ACSLS communicates with specific ports on tape libraries. See Ethernet Ports Used for ACSLS Communication for the ports that need to be available for ACSLS communication. On the ACSLS server ensure that iptables is configured to allow traffic to the ports used by ACSLS.
Determine your Linux auditing policies. The ”Configuring and Using Auditing” section in Oracle Linux: Security Guide for Release 6 can help you plan for what events to audit, where your audit logs should be saved, and how you want to review them.
Some useful logs and commands for auditing Linux security include:
View var/log/secure as root to see the history of login attempts and other access messages.
The parameter 'last' | more gives you a history of users logged in.
The /var/log/audit/audit.log.[0-9] keeps a log of access attempts that were denied by SE Linux. You must be user root to view these.
ACSLS 8.3 is designed to run in optional Security Enhanced Linux environments. SELinux provides access control to files, directories, and other system resources that go beyond the traditional protection found standard in Unix environments. In addition to owner-group-public permission access, SELinux includes access control based on user role, domain, and context. The agent that enforces access control over all system resources is the Linux kernel.
The root user on a Linux system can set enforcement on or off with the setenforce command.
setenforce [Enforcing | Permissive | 1 | 0 ]
Use Enforcing or 1 to put SELinux in enforcing mode. Use Permissive or 0 to put SELinux in permissive mode
To view the current system enforcement status, use the command getenforce.
Three SELinux policy modules are loaded into the kernel when you install ACSLS: allowPostgr, acsdb, and acsdb1. These modules provide the definitions and enforcement exceptions that are necessary for ACSLS to access its own database and other system resources while SELinux enforcement is active. With these modules installed, you should be able to run normal ACSLS operations, including database operations such as bdb.acsss, rdb.acsss, db_export.sh and db_import.sh without the need to disable SELinux enforcement.
For more information, refer to the section on SELinux in the ”Troubleshooting” Appendix in the StorageTek ACSLS 8.3 Administrator's Guide.
This section explains how to securely install ACSLS.
Performing a standard ACSLS installation ensures that you will have all necessary components.
If you are migrating to a latter ACSLS release from a previous ACSLS release, review your settings for dynamic and static variables to see if you want to use more secure options, especially regarding the Firewall Secure Option.
ACSLS requires the ACSLS user IDs: acsss, acssa, and acsdb. Choose strong passwords for these IDs, and change the passwords on a regular basis.
ACSLS generally restricts access to the ACSLS files to only acsls group, which includes the acsss, acssa, acsdb, and root user IDs. Some database and diagnostic files are only accessible by a single acsls user ID. ACSLS runs with a umask setting of 027.
ACSLS files should not be made world readable or writable. However, restricting access beyond the installation defaults may cause ACSLS functions to fail.
The installation script advises customers that the effective user id of 'root' must be set (setuid) in three executable files in the /export/home/ACSSS file system:
acsss (This binary must be run with 'root' privileges because it is used to start and stop system services required by the ACSLS application.)
db_command (This binary starts and stops the PostgreSQL database engine that controls and maintains the ACSLS database.)
get_diags (This binary is invoked by a customer to collect comprehensive system diagnostic information that may be needed in the context of a service support call.)
During the installation of ACSLS with pkgadd, customers are prompted Do you want to install these as setuid/setgid files? By answering y to the prompt, you allow these three commands to be run by users in the acsls group, even though the utilities perform certain system operations that require root privileges.
The ACSLS static and dynamic variables control the behavior of many ACSLS functions. Set these variables using the acsss_config utility. Secure settings for many of these variables are discussed in this document. When the options for a variable are presented by acsss_config, replying with a question mark (?) will cause a detailed explanation of the variable to be displayed. This information is also available in the ”Setting Variables that Control ACSLS Behavior” chapter of the ACSLS Administrator's Guide.
ACSLS 8.1 and later releases use WebLogic for its web server. WebLogic is installed with ACSLS.
Refer to Oracle Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.5) for the options for securing a WebLogic server, and the audit trail possibilities with WebLogic.
The userAdmin.sh menu-driven utility is used to administer ACSLS GUI user passwords. You can add users, remove users, list users, and change user passwords. WebLogic must be running to use this utility. If it is not up, this utility starts WebLogic and confirms that it is online before displaying the menu.
The userAdmin.sh utility must be run by root, and requires acsls_admin authentication. The acsls_admin user account is configured during ACSLS installation.
To use ACSLS GUI, you need to install the latest JRE Version and access the ACSLS GUI through a browser.
Make sure the latest version of the Java Runtime Environment (JRE) 1.6 is installed on the systems that will use the ACSLS GUI to access ACSLS.
|
Note: ACSLS 8.3 requires JRE 1.6 or 1.7. |
Open a browser and enter a URL with the server hostname or IP address in the following format:
https://myAcslsHostName.myDomainName:7002/SlimGUI/faces/Slim.jsp or https://127.99.99.99:7002/SlimGUI/faces/Slim.jsp
It is best to use the fully-qualified host name or the IP address of the host machine. Some pages, including the ACSLS help pages, may not display properly if the URL cannot be fully resolved by WebLogic.
If you use http with port 7001, WebLogic will automatically re-route you to https on port 7002.
Since WebLogic is using the secure https protocol, your browser may warn you that the site security certificate has not been registered, and therefore is untrusted. If you are confident that the URL is your local ACSLS machine, you are safe to proceed. At this point, you should see the login screen.
|
 Copyright © 2013, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|