Securing (also referred to as "hardening") your WebSphere Application Server environment is one of the most important activities for deploying a new application into production, but it's also a complicated topic and requires an in-depth understanding of the entire environment from the operating system to the application code itself. One of the reasons that it's so complicated is because securing your environment often comes with usability trade-offs, and thus your approach to hardening, say, a photo browsing application, is going to be very different from your approach to hardening a banking application.
First, let's talk about what we're protecting against when we harden a deployment. The obvious answer to that question is that we're protecting against malicious attacks from unknown, outside, hackers, and while that's certainly true, we also need to think about threats from inside a company. When you envision how to protect against external hackers, for example, you tend to think of firewalls, demilitarized zones, and TLS encryption of client requests. These are all important, but a disgruntled employee who wants to attack from within might have a totally different vector of attack. For example, they might already have access to the machine the application is running on and so instead of trying to attack the server via the HTTP port, they might instead look to take advantage of files with loose permissions, or an ability to elevate their user privileges to those of an admin. As the previous example shows, it's important to consider both internal and external avenues of attack, since the steps to harden against each type of attack are very different.
To that end, the hardening guidelines for WebSphere Application Server are broken down into three main categories, operating system hardening, network hardening, and application hardening:
- Operating system hardening is mostly about making sure that file system permissions are set up properly so that only people with an absolute need to read or modify application related files can do so. As a basic example on a Linux server, you should remove any permissions given to "all users" for any application related files (e.g. chmod -R 750). Going even further, write access to those files should be extremely limited, preferably to only one administrative account without the ability to perform a direct login. Any administrator who needs to perform an administrative function would switch user (using the su command) to the administrative account, thereby preventing the need to share the administrator password and also providing an audit trail of who switched to the administrative account and when. Operating system hardening of this sort is important to protect against internal threats, but it can also help prevent external hacks from escalating. For example, let's say that an external hacker is able to find an exploit in a web application that lets them point to any file on the server and the web application will attempt to send the contents of that file back to the user. If the user identity that the application server is running as is properly locked down, the damage that the hacker can cause with this exploit is greatly reduced because that user identity will simply not have access to read or write to the vast majority of files on the server. As this example shows, multiple different layers of security hardening can be combined to not only prevent attacks, but mitigate how serious they are.
- Network hardening is about properly isolating your application server so that client requests flow only over a carefully curated path. For example, WebSphere Application Server should always be run behind a network demilitarized zone (DMZ). Client connections should be terminated inside a DMZ at an IBM HTTP Server or appropriate network appliance and then proxied through the inner firewall to the application server. Another aspect of network hardening is ensuring that confidential information is always TLS-encrypted.
- Application hardening is about analyzing the entry points to your application and making sure that they are all properly protected by Java Enterprise Edition roles. As an example, an authorization constraint should be set up so that, by default, all application endpoints are inaccessible to everyone, forcing new application endpoints to be specifically configured with security roles before they can be accessed. This prevents new endpoints from being accidentally exposed in an insecure way when applications are updated.
Each of these areas can be a huge topic in and of themselves, so coming shortly I'll be hosting two ExpertTV sessions to go into more detail.
In the meantime, you can find in-depth security hardening information in the following areas: