Security Hardening of WebSphere Application Server Installations

It is a known fact that an out of the box WAS installation with security enabled is not entirely secure. There is a number of steps that has to be taken in order to “harden” the installation. Most of the steps are documented in the WebSphere hardening guide, which should be closely studied and followed by any WAS administrator or developer. The hardening guide, however, is a little light on the specifics regarding how to secure WAS at the OS level. For example, hardening should normally include changing file and directory permissions to restrict access to sensitive configuration files.

Why bother hardening the installation at the OS level? This helps defend against external threats, i.e., a server hosting the installation is compromised and against internal threats, i.e., an unauthorized access from inside.

Here are some of the things you can do to secure your installation on a Unix/Linux platform:

* If you installed WAS as a non-root account, make sure that this account is not part of the “users” group. Create a separate group for all administrators, say “wasadmins”. If you’re doing this the post-install, make sure that you changed the ownership of all WAS files and profiles. To do that, bring all WAS processes down and run chgrp -R wasadmins $WAS_INSTALL_ROOT.
* Refrain from running WAS using root. There is no reason to do it on Unix/Linux, unless you absolutely have to use low ports. Yes, you can use sudo to tighten down access to root, but it is safer just to stay away from it. You can actually install WAS using root so it can be properly registered with the OS, but you can later change the installation to be owned by a non-root account.
* Following the principle of least privilege, remove read access from “others”. Why do you need to do it? There are many sensitive files that are part of WAS install, including files containing encoded passwords (see below). It’s better to err on a side of caution and disallow general read access altogether. We should revoke execute access as well. On the other hand, we may want to grant write/execute to all members of wasadmins groups, assuming the membership in this group is going to be tightly controlled:
chmod -R 770 $WAS_INSTALL_ROOT
* You may want to allow access to logs to “others” so that developers can view logs. Since we just revoked read permissions from the root WAS install directory and from all profile directories, you can’t just “chmod” the “logs” directory. You need to redirect logs to some other directory which is not under “$WAS_INSTLALL_ROOT” or profile roots. In order to do it, change LOG_ROOT WAS variable. You can do it from the console (Environment/WebSphere variables). By default, “LOG_ROOT” is defined at a node level. If the location is going to be the same on all nodes (which it should), just create LOG_ROOT at the cell level. You’ll need to restart WAS servers after this. You can redirect logs to, say, /var/log/was. Make sure that “wasadmin” system account has write permissions to this directory.
* Do not allow login to the system account used to run WAS. You can read this guide explaining how to do it for various login mechanisms. You also need to disable “sudo su wasadmin” and only allow sudo for the specific commands/scripts that are needed to run WAS. You will need to add something like this to the sudoers file:

%wasadmins ALL=(wasadmin) WAS_INSTLALL_ROOT/bin/, PROFILE_ROOT/bin/

This configuration allows all member of “wasadmins” group to run commands from “bin” using “sudo -u”, e.g., sudo -u wasadmin ./startServer.sh server1.
You may relax this a little bit by allowing sudo access without having to enter password every time:

%wasadmins ALL=(wasadmin) NOPASSWD: WAS_INSTLALL_ROOT/bin/, PROFILE_ROOT/bin/

It’s a bit of a pain having to run all commands via sudo (although, of course, it can be scripted), but it gives you complete audit trail of who did what in the environment. By the way, by default sudo logs via syslog, but you can redirect sudo’s log into its own file by adding this directive in sudoers:

Defaults logfile=PATH_TO_LOG_FILE

* Secure “sensitive” files. As any WAS administrator knows, passwords stored in WAS are not really encrypted, they are just encoded, so they can be decoded pretty easily (there is a way to plug in custom encryption, but that’s a different story). Therefore, it is imperative to properly protect files containing encoded passwords. To do that, we’re going to revoke any access to these files from “wasadmins” group. That way, only the “wasadmin” system account (which we can’t even login into) or root can read these files. Encoded passwords are stored in “security.xml” and “wim/wimconfig.xml” (if you have LDAP configured). All these files reside under “$PROFILE_ROOT/config/cells/$CELL_NAME”. “fileRegistry.xml” also contains passwords, although these passwords are properly encrypted.
You may also want to protect keystores (key.p12). Note that in addition to the cell key store, each node has its own keystore. You don’t need to worry as much about trust stores (trust.p12), in fact it might be convenient to keep group-level access to trust stores so that administrators can modify them outside of WAS (e.g., by adding a signer cert using ikeyman). While you’re on it, make sure that you don’t use the default password (WebAS) for any of the keystores/truststores.
To revoke group access to any of the files mentioned above, just run “chmod 600” on them, e.g., chmod 600 security.xml. Note that you’ll have to repeat it for each profile, including deployment manager and application server profiles (unless you have a standalone install).
Node synchronization built into WAS fully supports changing permissions on config files. The changes will not disappear after node sync (provided you updated the DM profile).
* If your environment has a DMZ utilizing IHS, make sure that you don’t have WAS installation on the DMZ boxes. It is convenient to have node agents running on the IHS servers, so you can manage IHS from admin console, but, unfortunately, it is a security risk. Deployment manager pushes all configuration files, including “security.xml” to all nodes, and we certainly don’t want this file sitting in the DMZ (even with “600” permissions).
* Repeat all changes on every server containing WAS installation. You may want to script them or, better yet, use a tool like Puppet to automate OS-level configuration changes across multiple machines. For example, see this guide on how to centralize management of the sudoers file.

This post is part of the series on WebSphere Application Server administration. Please subscribe to our blog if you’d like to receive updates.

We offer professional services in the area of WebSphere architecture, implementation and operations. If you’re looking for help with any of these tasks, please let us know.