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

Monday, December 31, 2012

IBM Web Server Plug-in Analyzer for WebSphere Application Server



A tool that detects improper or ill-advised WebSphere Application Server plug-in configurations and corresponding HTTP request/response failures.
What is IBM Web Server Plug-in Analyzer for WebSphere Application Server? 

IBM® Web Server Plug-in Analyzer for WebSphere® Application Server helps discover potential problems with trace and configuration files during use of WebSphere Application Server. The tool parses both plug-in configuration and corresponding trace files and then applies pattern recognition algorithms in order to alert users of possible inconsistencies. 

The tool provides a list of HTTP return codes, URI and graphical presentations of available clusters, and server topologies from the configuration and trace files. 

The primary automatic capabilities of this tool are as follows: 

detection of incorrect or potentially problematic configurations that could cause service interruption or performance degradation 
identification of request failure or response failure 
HTTP return code tracking 
URI failure tracking 
graphical presentation of WebSphere Application Server and cluster topology 
cluster and cluster member tracking. 
The package includes the stand-alone code, documentation, and license files. 

How does it work?

The tool parses WebSphere Application Server plug-in configuration files and trace files. Based on results obtained from a pattern recognition engine, IBM Web Server Plug-in Analyzer provides information about any potential problems within the configuration. 
The pattern recognition engine maintains various patterns of configurations that are not usually recommended and provides warnings if these same patterns are detected in the configuration files. 

The tool takes the following approach: 

It parses configuration files. 
It provides warnings or clues to information when configurations appear to be set inappropriately. 
It collects WebSphere Application Server cluster and member topology information within the configuration file. 
It displays a visual mapping of the cluster and member topology. 
It parses the plug-in trace files and creating models based on HTTP request/response header/body information, HTTP return code, URI, start/end time, cluster name, and server name. 
It displays the requested trace information based on query. The trace information has HTTP return code analysis and HTTP request/response header/body analysis. 

References:
http://www.alphaworks.ibm.com/tech/wspa

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.