Network security hardening

Employ best practices with Open Liberty to harden your network for production against potential attacks. Network attacks occur when unauthorized users access network activity to alter traffic and steal network resources.


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.

Security in container environments

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.

TLS connectivity

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:

<httpEndpoint id="defaultHttpEndpoint" httpPort="-1" httpsPort="9445" />

Mutual authentication

For production environments, use mutual TLS authentication whenever possible. Mutual authentication, also known as 2-way authentication, is certificate-based authentication for clients. Methods of authentication are configurable per application. For example, one application might use client authentication while the other application uses basic authentication. Open Liberty has two modes for client certificate authentication:

  • Supported: The client might present a TLS certificate, but it is not required. If the client presents an untrusted certificate, the certificate is ignored. If the certificate is trusted, it can be used for application authentication. For supported mode, set the clientAuthenticationSupported attribute to the value of true in your TLS configuration.

  • Required: The client must present a trusted TLS certificate. If the certificate isn’t sent or an untrusted certificate is sent, the connection is rejected. For required mode, set the clientAuthentication attribute to the value of true in your TLS configuration.

If you use mutual authentication along with a proxy, consider specifying the httpDispatcher configuration element with the trustedHeaderOrigin or trustedSensitiveHeaderOrigin attributes. This configuration element permits proxies by using the specified IP addresses to pass along certificate details on behalf of clients, as shown in the following example:

<httpDispatcher trustedSensitiveHeaderOrigin=“,” />

If your Open Liberty deployment doesn’t include any proxies, set the following attributes in the server.xml file:

<webContainer trusted=“false” /> or
<httpDispatcher trustedHeaderOrigin=“none” />

The trusted attribute on the webContainer configuration element enables the application server to use inbound private headers from the web server plug-in. By default, the trustedHeaderOrigin attribute on the httpDispatcher configuration element is set to the value of * so that all non-sensitive private headers are trusted from any host. However, when the trusted attribute on the webContainer configuration element is set to the value of false, the configurations of the trustedHeaderOrigin attribute and the trustedSensitiveHeaderOrigin attribute are overridden. These configurations are overridden so that no inbound private headers are processed, which secures the network against attackers that can connect directly to the application server and bypass the web server.

LDAP servers

Ensure that any links from the Open Liberty server to LDAP servers are secured by TLS. Securing these LDAP connections with TLS encrypts communication so that your network configuration is hardened for production. To secure LDAP connections with TLS, enable the Lightweight Directory Access Protocol Over Secure Socket Links (LDAPS) protocol in your feature configuration. For more information about enabling and configuring LDAPS, see the LDAP User Registry feature.

LTPA best practices

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:

<webAppSecurity ssoRequiresSSL='true' />

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:

<webAppSecurity httpOnlyCookies='true' />

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:

<httpSession cookieHttpOnly='true' />

Welcome page and headers

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:

<httpDispatcher enableWelcomePage="false" />

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:

<httpOptions removeServerHeader="true" />

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:

<webContainer disableXPoweredBy="true" />

Session overflow

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:

<httpSession allowOverflow="false" maxInMemorySessionCount="1000" alwaysEncodeURL="true" cookieSecure="true" cookieHttpOnly="true" />

JMX connector

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:

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ibm/api/*" />
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/IBMJMXConnectorREST/*" />