http://www.wikio.fr WebSphere And Tivoli Tricks: April 2012

Thursday, April 5, 2012

Security Hardening of WebSphere Application Server Installations

It is a known fact that an out of the box a 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.

Monday, April 2, 2012

WebSphere MQ Security Vulnerability: potential buffer overflow on unsecured WebSphere MQ client connections

Abstract

WebSphere MQ Security Vulnerability: There is a potential buffer overflow which can occur when the MQ server is processing inbound data on a client connection.

Content

There is a potential buffer overflow which can occur when the MQ server is processing inbound data on a client connection.

This exposure applies to all WebSphere MQ V6 and higher queue managers and resolution will ship in 6.0.2.7 and 7.0.1.0. This issue is not present in releases prior to WebSphere MQ V6.

Links to associated interim fixes can be found here:
http://www.ibm.com/support/docview.wss?rs=171&uid=swg24023135

Vulnerability information:
http://xforce.iss.net/xforce/xfdb/50641

Unauthorized users are unable to exploit this on any queue manager which is secured with SSL and/or authentication security exits.

Specifying the userid in the SSL certificate label for an MQ client

Question

Does the standard WebSphere MQ SSL configuration require the personal certificates' label name with a special format as below?

WebSphere MQ Client: ibmwebspheremq + <User ID>
WebSphere MQ Server (queue manager): ibmwebspheremq + <QM Name>

Where the User ID or queue manager name must be folded to lower case in the label. For example, for a queue manager named QM1, the label is ibmwebspheremqqm1.

You want to know if you must comply with the rule for all of your MQ Clients, because you have many clients and it will be a big job to create unique certificates.
Cause

The original design and intent of MQ was that the answer to this question should be YES. It is still the intent that it is necessary to have a separate personal certificate with a label of 'ibmwebspheremq<username>' for each client connection. However, depending on what MQ maintenance level you are using, you may not see this working as designed in some circumstances. In certain scenarios, you may be able to get around the intended design.

Answer

The gsk6cmd command from GSKit provides -setdefault and -getdefault options to set or display a default certificate in a key repository. The behavior of this area of code has changed a few times, so here is a description of the expected behavior depending on your MQ maintenance level.

WebSphere MQ V5.3

    WebSphere MQ V5.3 CSD09 or earlier
    The default certificate will be used if: a default certificate is present, and there is no ibmwebspheremq certificate.
    This behavior was a defect which was corrected by APAR IC43762.
    WebSphere MQ V5.3 CSD10 through CSD12
    The default certificate will never be used. If you are at this level and require default certificate functionality, then you will need the fix for IC50156 and you must set the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable, as described in IC50156 APAR text.
    WebSphere MQ V5.3 CSD13 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate

WebSphere MQ V6

    WebSphere MQ 6.0.0.0 through 6.0.1.1
    The default certificate will never be used. If you are at this level and require default certificate functionality, then you will need the fix for IC50156 and must set the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable.
    WebSphere MQ 6.0.2.0 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate.

WebSphere MQ V7 & LATER Version

    WebSphere MQ 7.0.0.0 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate.


Notes:

1. All of the above holds true if you are using the MQ C client. If you are using MQ Java™ or MQ JMS clients the answer is NO, you do not need a unique certificate for every client userid. In the MQ Java and MQ JMS client environment the label is not used to do the certificate look up. However, a personal certificate for the queue manager end still needs a label of 'ibmwebspheremq<qmgrname>'.

2. The above information does not apply to platforms which do not use GSKit, such as z/OS for example or MQ v5.3 for Windows. MQ v6 for Windows does use GSkit, so the information is applicable on MQ V6 for Windows..

Warning:

Please note that the decision to remove default certificate support from WebSphere MQ was not made lightly, and was made for a number of security concerns. Although we have restored this in a limited way due to specific unique requests, this was not the functionality which we expected to see widely used. It is certainly not an approach which we recommend.

The administration of an SSL environment is something which we would advise you to consider carefully. Certificates are intended to provide a unique identification of a specific entity. The ability to establish a chain of trust from a trusted signer down to individual certificates allows for some of this administration to be delegated, however the use of default certificates makes it possible for far greater reuse and sharing of certificates to be achieved than is intended. In an extreme case, one default self-signed certificate could be used by every client and queue manager on a network, greatly increasing the risk of exposure to your network if the certificate becomes compromised.


If authentication of clients is not required, then you may find that setting SSLCAUTH to OPTIONAL in your channel definitions is a better solution for your needs. However, if authentication of clients is important, then you should consider whether wide reuse of a default certificate meets that need.