Hardening security configurations

You can use several techniques to protect the WebSphere® Application Server infrastructure and applications from different forms of attack. Sometimes a single attack can use multiple forms of intrusion to achieve the end goal.

• Install the latest application server and IBM SDK fix packs.

  Both products are updated to fix known security vulnerabilities and to enable stronger default security protocols. Additionally, the products are updated to add support for newer security protocols, which might be needed for the additional hardening steps in this procedure.

• Never deploy a production application server inside the demilitarized zone (DMZ) of the network.
  • Deploy production application servers only behind the inner firewall.
  • Allow only ports that are necessary for application access through the firewall.
  • The firewall or overall network design must limit ingress traffic to trusted addresses and limit egress traffic to the minimum addresses that are required by the application.
• Restrict access for the HTTP listening ports of an application server to trusted HTTP proxy servers, Content Delivery Networks (CDNs), or web application firewalls (WAFs).

  Allowing only these entities access to the HTTP listening ports protects the application server from malicious network attacks.

• Configure your reverse proxy servers or web application firewalls (WAFs) to enforce rate limiting.
  Rate limiting prevents individual users from consuming disproportionate server resources.
• At a minimum, ensure that administrative security is enabled in all application server processes.

  Administrative security protects access to the administrative ConfigService interface and managed beans (MBeans).

  For more information, see the topic about administrative security.

• Restrict the set of hostnames that applications respond to by replacing wildcard host aliases with individual hostnames.

  For more information, see the topic about configuring virtual hosts.

• Ensure that Transport Layer Security (TLS) or TLS client authentication is used whenever possible.

  TLS client authentication requires all clients to supply a trusted personal certificate to connect.

  For more information, see the topic on client authentication.

• Remove any unnecessary certificate authority (CA) signer certificates from your truststores.
• Configure a Federated Repository with one or more LDAP servers.

  LDAP provides advanced user account protection features, such as lockouts, for failed login attempts.

• Configure OpenId Connect (OIDC) or Security Assertion Markup Language (SAML) web single sign-on to allow authentication with third-party provider services.

  Third-party providers can provide advanced user account protection features such as lockouts for failed login attempts, multi-factor authentication, and fine-grained access delegation.

• Change your Lightweight Third-Party Authentication (LTPA) keys periodically and ensure that the LtpaToken2 cookie is only transmitted over encrypted transports by enabling the 'Requires SSL' setting.

  Use the instructions in Single sign-on settings to enable the 'Requires SSL' setting.

• Change the keystore password from the default value during or after profile creation, and then change the keystore password periodically.

  Run the AdminTask changeMultipleKeyStorePasswords command to change all keystore passwords or the AdminTask changeKeyStorePassword command to change the keystore password for a single keystore.

  For more information, see the topic about the KeyStoreCommands command group.

  For more information about changing default keystore passwords, see the topic about updating keystore passwords by using scripting.

• Change the LTPA keystore password from the default value during or after profile creation, and then change the LTPA keystore password periodically.

  Run the AdminTask changeKeyStorePassword command to change the LTPA keystore password.

  For more information, see the topic about the KeyStoreCommands command group.

• Enable the IBM® Java™ Cryptography Extension (JCE) Federal Information Processing Standard (FIPS) 140-2 Java runtime option.

  This option enables stronger encryption technology for applications that use the JCE FIPS provider, which is in the JVM.

  For more information, see the topic on the IBM JCE FIPS 140-2 cryptographic module security policy and the application server topic on configuring FIPS Java Secure Socket Extension files.

• Protect EJB applications and WebSphere Application Server resources, which can be looked up remotely through the CORBA Naming service.
  Implement all of the following protections:

  • Enable global security.
  • Protect the bootstrap port that is used for CosNaming lookups with a firewall.
  • For the CORBA naming service, replace the EVERYONE special subject with the ALL_AUTHENTICATED special subject.
• If you are not using the EJB query function, uninstall the query.ear file.

  The query.ear file contains the query application, which is installed by default to support the EJB dynamic query service. The query application makes an EJB remote interface available. By removing the query application, you remove remote access to the EJB that is provided by this application.