Network security hardening

Production environments need to run inside a firewall. Firewalls help prevent security intrusions by monitoring network traffic and blocking specific traffic based on security rules. Use a firewall to shield production Open Liberty servers so that they don’t run in the DMZ. The DMZ is an intermediary zone where proxy and web servers run between public and private networking zones. Typically, a network setup includes two firewalls, a perimeter firewall and a backend firewall. The perimeter firewall exists between the public zone and the DMZ, and the backend firewall exists between the DMZ and the private zone. The backend firewall, or overall network design, limits ingress traffic to trusted addresses and limits egress traffic to the minimum addresses required by the application.

Rate limiting can prevent individual users from consuming disproportionate server resources and also help to prevent denial of service attacks. Configure your reverse proxy servers or web application firewalls (WAFs) to enforce rate limitations.

In container environments, running either on-premises or in the cloud, applications can be spread across multiple nodes. Another best practice is to isolate workloads from one another across a cluster of nodes. When Open Liberty is deployed in container environments, segment network traffic based on users, teams, or applications. Collections of containers, or pods, apportioned by namespace, offer the ability to provide IP and port isolation. By default, don’t allow pods with different namespaces to interact. For more information about network security in container environments, see the information about network isolation in Ten layers of container security.

The Transport Security feature enables TLS for HTTP connections and adds the ability to configure outbound transports with TLS. For production purposes, TLS connections are essential for network communications to circumvent and reduce the risk of network intrusions.

TLS uses key pairs and signed X.509 certificates to protect HTTP, IIOP, LDAP, IBM MQ, JDBC, and messaging traffic among Open Liberty messaging engines, J2C, and SOAP traffic. The default TLS configuration is simple to configure, but it is not suitable for use in production because it generates a self-signed certificate. The automatically generated certificate is convenient for development purposes, but a certificate that’s used in production must be signed by a trusted authority, such as Verisign. If you use SSO for user authentication, all SSO endpoint URLs must use the HTTPS protocol, and the client must check the TLS server certificate.

With Open Liberty, ingress proxies are configurable and no proxies are trusted by default. For protection at the transport level when traffic comes in by proxy, make required Open Liberty servers accessible to only trusted proxies. Disable non-TLS ports wherever possible. Exposing only TLS-enabled ports requires careful consideration of the server.xml file because some features automatically enable non-TLS ports. Disable non-TLS ports by setting them to the value of -1 in the server.xml file, as shown in the following example:

Lightweight Third-Party Authentication (LTPA) is a single sign-on (SSO) technology that uses cookies or binary tokens for authentication. You can take several measures to harden your network when you use LTPA. By default, LTPA cookies are sent over HTTPS or HTTP connections. For production purposes, the cookie that carries the LTPA token must be protected. If this cookie is stolen, an intruder can act in place of the authenticated user until the token expires. Cookies support the secure attribute, which tells the browser to send a cookie over HTTPS connections only. Set the following attribute in the server.xml file to require that LTPA cookies are sent over TLS connections:

As a best practice, replace LTPA keys regularly. Replacing LTPA keys regularly reduces the risk vector in which a bad actor is able to access a copy of a file and decrypt its contents. To replace the keys, delete the ltpa.keys file and wait for the server to automatically regenerate them. Then, copy the new keys file to the file systems for other servers that share the keys.

In production environments, the cookie for LTPA must be used only for HTTP requests and not for anything else, such as JavaScript applications. The following example tells browsers to restrict the use of LTPA cookies to only HTTP connections:

You can also use the cookieHttpOnly attribute to help prevent cross-site scripting attacks. When the value is set to true, this attribute specifies that session cookies must include the HttpOnly field. Browsers that support the HttpOnly field don’t allow client-side scripts to access cookies:

When a user logs out from an application that is protected by LTPA, the LTPA token value is destroyed on the client side. To ensure that an LTPA token cannot be reused on the same server after a user logs out, set the trackLoggedOutSSOCookies attribute to true. This attribute specifies whether to track LTPA tokens that are logged out on a server so that a token cannot be reused on the same server after logout:

To keep Open Liberty administrative traffic separate from application requests, configure applications to run on a virtual host other than the default host for the server. Furthermore, when you define aliases for virtual hosts, avoid wildcard values (*) in alias hostnames. Rather than using wildcards, alias hostname values must match only the specific hosts that administrators expect a server to handle. Define a virtual host by specifying the virtualHost configuration element in your server.xml file:

For more information, see Isolate incoming application requests with virtual hosts.

For production, you can disable the Open Liberty welcome page. The welcome page is enabled by default, and accessing the / root context displays the Open Liberty welcome page. Disable this welcome page by setting the enableWelcomePage attribute to the value of false in the server.xml file:

Open Liberty server headers are also enabled by default. Because these headers are enabled by default, in certain situations, information might be returned to browsers or web clients about the server implementation that is running. Setting the removeServerHeader attribute to the value of true removes server implementation information from HTTP headers:

You can disable the X-Powered-By header if you don’t want to reveal that an Open Liberty server is running. Setting the disableXPoweredBy attribute to the value of true disables the X-Powered-By header, which prevents the header from being sent on the HTTP response:

Restrict the number of sessions that can be created for applications that use in-memory sessions by disabling HTTP session overflow. Restricting sessions can help prevent denial-of-service attacks in which attackers continually generate new sessions until all JVM memory is exhausted. You can disable HTTP session overflow by setting the allowOverflow attribute to the value of false:

When you use the IBM HTTP Server, you can secure access to the Open Liberty JMX connector for remote administrative services in the web server plug-in by removing or commenting out the following entries: