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.

Firewalls

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.

Request Rate Limiting

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.

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="10.20.30.40, 10.20.50.60" />

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" />

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:

<webAppSecurity trackLoggedOutSSOCookies="true" />

Virtual hosts

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:

<virtualHost id="secure-app-host">
    <hostAlias>example_host:9080</hostAlias>
</virtualHost>

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/*" />