Note The information described in this section does not apply to OMi in an Operations Bridge Suite container deployment. For information on this topic in a container environment, see the Operations Bridge Suite help.
The hardening guidelines deal with the configuration required to implement a more secure OMi. The hardening guidelines relate to both single-server (where all OMi components are installed on the same machine) and distributed (where all OMi components are installed on separate machines) deployments.
If the deployment includes HPE Operations Agent installations, consider hardening the agent system by restricting access from the OMi server to the agent system. For more information, see Restrict access rights.
The hardening information provided is intended primarily for OMi administrators, and for the technical operator of each component that is involved in the implementation of a secure OMi (for example, the web server). These people should familiarize themselves with the hardening settings and recommendations prior to beginning the hardening procedures.
Note In this document, the term reverse proxy also refers to load balancing in Layer 7 load balancing except for BBC channel reverse proxy configuration (see Configure BBC port 383 connection on reverse proxy).
Learn more
Secure communication using TLS
Transport Layer Security (TLS) technology secures communication by encrypting data and providing authentication. Without TLS encryption, packets of information travel over networks in full view.
Communication between the OMi clients and the OMi servers is by default configured to use HTTPS. Client authentication using a client-side certificate is optional with OMi clients. For more information, see Use TLS in OMi.
Secure browser
The web browser must be configured to securely handle Java scripts, applets, and cookies. The Transport Layer Security (TLS) communication protocol secures the connection between the client and the server. URLs that require a TLS connection start with HTTPS instead of HTTP.
Firewalls
To avoid direct access between the OMi clients and the OMi servers, you can isolate OMi servers in their own internal segment behind a firewall.
You can also configure a firewall on the OMi gateway and data processing servers. However, in order to do this you must ensure that the OMi servers can still communicate freely. To do this, you must set up a host-to-host tunnel (or VPN) between all OMi gateway and data processing servers.
Password encryption algorithm
You can change the encryption algorithm used by OMi to encrypt passwords, but only before running the configuration wizard.
Open the encryption properties file, <OMi_HOME>/conf/encryption.properties, and choose one of the predefined crypt configuration entries (crypt.conf.x) by setting crypt.conf.active.id to the appropriate index. If you want to add another entry, follow the standard Java Cryptography Extension (JCE) format.
Additional hardening recommendations
-
OMi installation directory. Restrict access to the OMi installation directory to privileged users. We recommend only allowing the SYSTEM account and Administrators groups to access this directory.
-
LDAP servers and databases. Follow all security guidelines for LDAP servers and databases.
-
SNMP and SMTP servers. Run SNMP and SMTP servers with low permissions.
Note SNMP and mail traffic may not be secure.
-
Run Processes as non-root. On Linux, the OMi processes by default run under root. To configure OMi to run under a non-root user account, see the
Note SNMP and mail traffic may not be secure.
Log file management
OMi uses the log4j framework for managing log files. If you wish to change the locations of log files, these can be set in the log4j appenders, which are located in:
<OMi_HOME>/conf/core/Tools/log4j
There is a separate directory for each process, for example jboss for the application server.
Reverse proxy architecture
One of the more secure and recommended solutions is to deploy OMi using a reverse proxy. OMi fully supports reverse proxy architecture as well as secure reverse proxy architecture.
The following security objectives can be achieved by using a reverse proxy in DMZ proxy HTTP/HTTPS communication with OMi:
-
No OMi logic or data resides on the DMZ.
-
No direct communication between OMi clients and servers is permitted.
-
No direct connection from the DMZ to the OMi database is required.
-
The protocol used to communicate with the reverse proxy can be HTTP or HTTPS. HTTP can be statefully inspected by firewalls if required.
-
A static, restricted set of redirect requests can be defined on the reverse proxy.
-
Most of the web server security features are available on the reverse proxy (authentication methods, encryption, and others).
-
The reverse proxy screens the IP addresses of the real OMi servers as well as the architecture of the internal network.
-
The only accessible client of the web server is the reverse proxy.
-
This configuration supports NAT firewalls.
-
The reverse proxy requires a minimal number of open ports in the firewall.
The reverse proxy provides good performance compared to other bastion host solutions. It is strongly recommended that you use a reverse proxy with OMi to achieve a secure architecture. For details on configuring a reverse proxy for use with OMi, see Configure secure access to the OMi reverse proxy.
If you must use another type of secure architecture with your OMi, contact HPE Software Support to determine which architecture is the best one for you to use.