0611 Botzum WAS 60 Security Hardening

IBM Software Group
WebSphere Application Server Version 6 Security: Infrastructure Hardening May 2006
Keys Botzum, Senior Technical Staff Member keys@us.ibm.com IBM Software Services for WebSphere http://www.ibm.com/WebSphere/developer/services
Cameron Martin, Senior IT Specialist cameron.martin@uk.ibm.com
2006 IBM Corporation
last update: November 20, 2006
IBM WebSphere
WebSphere Security Presentation Series

This presentation is part of the WebSphere Security Presentation Series led by Keys Botzum with help from so many others
Available internally at http://pokgsa.ibm.com/~keys/documents/securitySeries
Related presentations
We assume youve seen or are familiar with Core Concepts WAS Security Introduction WAS Advanced Authentication (cross cell trust issues) You may be interested in Application Isolation Application Hardening Hardening MQ SSL Configuration
Security Hardening
IBM WebSphere
Change is the Only Constant

This presentation reflects
Our current opinions regarding WAS security The product itself continues to evolve (even in Refresh Packs) This will be revised as we learn more Your thoughts and ideas are welcome
Scope
WAS 6.0.2 Distributed (Unix, Linux and Windows)
New in 6.0
New in 6.1
Most information here applies to V5.0.x and V5.1.x as well An introduction to the relevant changes in V6.1 is included Extended Deployment and Programming Model Extensions are not specifically covered WAS on other platforms is similar, but not covered here Web Services Security specific issues are not covered
Security Hardening
IBM WebSphere
WHY HAVE SECURITY?
A secure infrastructure protects your system from unwanted intrusions. WAS is one key part of that infrastructure. We are going to discuss how to secure WAS.
WAS isn't the only infrastructure component you need to secure. Identify and document all of the threats you wish to protect yourself from. Many are internal.
4
Security Hardening 2006 IBM Corporation
IBM WebSphere
Intrusions
People and systems with IP connectivity to your network
Outsiders on the Internet Insiders on your Intranet In many ways more dangerous as they have knowledge, access, and possibly a grudge Several sources state that the majority of attacks are internal Email/browser exploits that serve as entry points to the company network
WAS provides a robust infrastructure for addressing most of these challenges. with some assembly required.
Security Hardening
IBM WebSphere
Agenda
Introduction SSL Overview Infrastructure Preventative Measures Advanced Considerations Protecting your Desktop Environment Wrap-up
Security Hardening
IBM WebSphere
SSL Overview
Public Certificate Authority Sign Public Private
Generate Server Keys
Private
Server Certificate CA Certificate Public Public

T rust ed
Se cu r e
Offline operations that occur before client first contacts server
Server Certificate Public Client Encrypted Message Public Server
Security Hardening
IBM WebSphere
SSL Authentication
Server side SSL authentication in brief
Server sends its certificate to client along with secret encrypted using its private key (from key store) Client validate the servers certificate by checking its expiration date and signature Signature is verified using signing certificate in trust store If certificate signature isnt right, connection will be refused Client side authentication is basically the same with the parties reversed
SSL authentication does not imply the system is secure!!

It merely validated that the certificate was acceptable Given plenty of signers (all known default CAs) SSL hasnt really done much yet for us in terms of security Usually some later component uses the verified certificate to determine real identity of other party and then performs some form of authorization E.g., browsers ensure that certificate subject name is same as host name of web server E.g., WAS maps certificates to J2EE user identities in registry
Security Hardening
IBM WebSphere
Limiting Connections to Trusted Clients

Sometimes it is difficult to insert proper authorization into an existing connection path
E.g. WAS does not provide for authorization of Web Server plugin connections
If we limit the signers we trust on the server, we can limit the clients that can complete the SSL handshake
With self-signed certificates, there is only one signer Hence, only one valid client side private key that can be used to connect We can also limit the signers we trust on the client to ensure the client only connects to the right servers
We can use this technique to limit connections to trusted clients

Several situations where this technique is useful that well explore later
Security Hardening
IBM WebSphere
Implementing Trusted Tunnel with SSL

Using ikeyman (or built in certificate tools in V6.1)
Create two sets of key stores and trust stores Key store and trust store for client Another key store and trust store for the server Remove all trusted signers from all stores (V6.1 trust stores are empty by default) Now none can be used to validate any other certificate Create a self signed certificate in each key store Export the signing certificate from each key store and import into the trust store of the other party (client to server and server to client) Now each trust store can be used to validate exactly one certificate the one that corresponds to the private key just created in the key store
New in 6.1
Basically the same if have only a single key store on either side
Trust store and key store are the same file E.g., native KDB databases used by IBM HTTP Server and WAS Web Server plugin
Ensure client certificate authentication is enabled (server cert authentication is always on)
10
IBM WebSphere
Agenda
Introduction SSL Overview Infrastructure Preventative Measures Advanced Considerations Protecting your Desktop Environment Wrap-up
11
Security Hardening
IBM WebSphere
Basic Topology
MQ Server Application Server Application Server with ME MQ W, M J J Session & SIB DB
W eb Server H H
I, W
Application Server Browser S W Node Agent Node W eb Services I W
App DB
L L LDAP Deploym ent M anager
H W EJB Client
wsadm in
Adm in Browser
12
Security Hardening
IBM WebSphere
Protocols Used
H = HTTP traffic
Usage: browser to web server, web server to app server, and admin web client Firewall friendly
W = WAS internal communication

Usage: admin clients and WAS internal server admin traffic Protocol: RMI/IIOP or SOAP/HTTP. Client protocol is configurable. File transfer service (between node agent and DMgr) uses HTTP(S) DCS (Distributed Consistency Service), RMM (Reliable Multicast Messaging). Private protocol. SOAP/HTTP firewall friendly if using SOAP/HTTP. DCS can be firewall friendly
I = RMI/IIOP communication
Usage: EJB clients (standalone and web container) Firewall hostile
M = SIB messaging protocol

Usage: JMS client to messaging engine Protocol: Proprietary Firewall friendly as fixed ports can be used. Likely NAT firewall hostile.
New in 6.0
13
Security Hardening
IBM WebSphere
Protocols Used
MQ = WebSphere MQ protocol
Usage: MQ clients (true clients and application servers) Protocol: Proprietary Firewall feasible (there are a number of ports to consider). Refer to MQ supportpac MA86.
L = LDAP communication
Usage: WAS verification of user information in registry Protocol: TCP stream formatted as defined in LDAP RFC Firewall friendly
J = JDBC database communication via vendor JDBC drivers

Usage: application JDBC access and WAS session DB access Protocol: Network protocol is proprietary to each DB. Firewall aspects depend on database (generally firewall friendly)
S = SOAP
Usage: SOAP clients Protocol: generally SOAP/HTTP Firewall friendly
14
Security Hardening
IBM WebSphere
Attack on multiple levels

Network - subvert network level protocols by altering traffic, or just looking at traffic with confidential information Machine - leverage machine access to see and modify what they shouldnt External Application legitimate and illegitimate users that leverage application level protocols (RMI/IIOP, HTTP, etc) to try to do things they shouldnt be doing. These attacks usually require the least skill and are potentially the most dangerous. Internal Application Isolation - legitimate applications that try to get around application server and Java runtime restrictions The type of attack(s) that a measure defends against is highlighted on the relevant slides
NMEI
15
IBM WebSphere
The Standard Configuration with Firewalls

MQ S erver A pplication S erver A pplication S erver w ith ME MQ W, M J J S ession & S IB DB
W eb S erver H H F W B row ser S F W
I, W
A pplication S erver W N ode A gent N ode
A pp DB
L L W D eploym ent M anager LD A P
W eb S ervices
H W E JB FW C lient
w sadm in
A dm in B row ser
16
Security Hardening
IBM WebSphere
Put the Web Server in the DMZ without WAS

Nothing in the DMZ but the Web Server
Very simple configuration, small attack surface Stripped OS install with few tools Follow the principles of least function and lowest complexity
Inbound network traffic from outside must be terminated in the DMZ

Network transparent load balancer is not sufficient
DMZ firewalls strictly limit traffic to

Allow only inbound HTTP(S) traffic on specific ports Deny all outbound initiated traffic unless explicitly permitted by policy
The Application Servers and other components go behind a second firewall on a "production" subnet
NMEI
17
IBM WebSphere
Separate your Production Network from your Intranet

Protect WAS against internal as well as external threats Notice the third firewall between production subnet(s) and the corporate intranet
Web Administration Console will go through firewall if correct ports opened wsadmin will go through firewall if using SOAP and correct ports opened Can configure firewalls to allow IIOP, just more difficult
Can take addition steps to further protect against internal network access; need to take additional steps will vary
Consider limiting access to Administrative functions (e.g. Web Administration Console) to trusted VLANs or internal VPN Might even consider a full internal DMZ
NMEI
18
IBM WebSphere
What about Additional Firewalls?

Every component (WAS, DB, Web server, LDAP) could get its own subnet using VLANs
Firewall between every subnet ("virtual" firewalls) Consider internal client connection and manageability issues Complexity increases rapidly with diminishing value Any firewalls that separate EJB clients from the WAS services need to be IIOP friendly We prefer to focus firewalls on traffic from outside of cell rather than trying to block WAS internal traffic In most cases we explicitly recommend against firewalls within a WAS cell
NMEI
19
IBM WebSphere
Beyond Firewalls
Firewalls are a valuable component in an overall security plan, but they are not sufficient Now that we have firewalls in place
Lets continue to harden WAS from attack This list is in priority order
Just be systematic and patient
20
Security Hardening
IBM WebSphere
Enable Global Security

Enable Administrative Security
Prior to v6.1 this was called global security Most internal links are now encrypted and authenticated WAS internal communication (SOAP and RMI/IIOP) runs over SSL
Includes admin clients, EJB clients, and WAS internal communication Even the WAS Web Administration Console switches to HTTPS
Does not protect all network links, but most key ones well cover the rest soon Administrators will now be required to authenticate Does not prevent network sniffing attacks until you change the default keys
WAS admin security is independent of application security

Enabling admin security makes WAS infrastructure secure it is up to the applications to explicitly leverage application security to secure themselves
WAS V5/V6.0 vs WAS V6.1

V5.x/V6.0 - global security enables admin and application security Application security was *disabled* by disabling "server security" V6.1 - admin security enabled by default Performed as part of a standard installation by default Application security is a separate configuration option
21
Security Hardening
New in 6.1
NMEI
IBM WebSphere
Use HTTPS from the Browser

If your site performs any authentication or has any confidential information then configure your web server to support HTTPS
Refer to your Web Servers documentation for instructions Popular web browsers ship with around 50 odd pre-trusted CA certificates. Youll want to support one of them. Purchase a certificate from a well-known CA.
You may need to configure a virtual host alias for the HTTPS port (WAS assumes port 443 by default) WAS can enforce that HTTPS is used by an application by specifying a data constraint in web.xml You should use SSL for any confidential information - including LTPA Tokens, session IDs etc.
NMEI
22
IBM WebSphere
Configure Secure File Transfer

Node Agents retrieve configuration updates from the Deployment Manager using the File Transfer application
By default, no authentication (it is encrypted) System application, not normally visible in admin console Potential for attackers to upload arbitrary files; theoretically may be feasible to download certain files
To enable authentication, simply replace the existing File Transfer application with the secured version
cd <profilehome>\bin wsadmin.bat wsadmin>source ../../../bin/redeployFileTransfer.jacl wsadmin>fileTransferAuthenticationOn <cellName> <dmgrName> dmgr wsadmin>$AdminConfig save
WAS V6.1 uses the secured version by default

when Administrative Security is enabled
23
Security Hardening
New in 6.1
NMEI
IBM WebSphere
Protect JNDI
J2EE applications use JNDI to find other applications and resources Too many have too much access by default
By default anyone in your registry can destroy a cell Everyone read All Authenticated read, write, create, delete Allow everyone read only access Everyone read All Authenticated nothing Applications that explicitly write to JNDI in application code will need to be granted access (rare) WAS will ensure that its own components always have read/write access so core function (e.g. binding EJBs, Datasources into the namespace) will continue to work Everyone nothing
Unauthenticated threads (e.g, anonymous servlets) cant read JNDI > MDBs cant access JNDI > Local refs (e.g., java:comp/env) will not work > Applications must authenticate users or authenticate themselves using JAAS or RunAs
Recommended configuration
Somewhat safer, but breaks some applications not recommended
All Authenticated read
Permission are set in the admin console via Environment > Naming > CORBA Naming Service Groups WAS V6.1 by default uses the above recommended configuration
New in 6.1
NMEI
24
Security Hardening
IBM WebSphere
New in 6.0
Ensure Meaningful Authorisation on Default Messaging

Once created, buses are too accessible by default
Anyone in your registry can perform any action against any destination
Configure a more appropriate subset of users using wsadmin, for example:

cd <profilehome>\bin wsadmin.bat wsadmin>$AdminTask removeGroupFromBusConnectorRole {-bus mySIB group AllAuthenticated wsadmin>$AdminTask addUserToBusConnectorRole {-bus mySIB user userYouDetermine} wsadmin>$AdminConfig save
Youll also need to ensure client components (MDBs, JMS) authenticate using an appropriate identity (userYouDetermine) WAS V6.1 will by default require users and groups that are authorised to access the bus to be explicitly configured
No AllAuthenticated access by default
25
Security Hardening
New in 6.1
NMEI
IBM WebSphere
Bus Security in V6.1
New in 6.1
26
Security Hardening
IBM WebSphere
Restrict Access to WebSphere MQ Messaging

Two ways to authenticate WAS to MQ
Bindings Mode No built in fine grained authentication, relies on process level authentication Userid/password info specified on JMS resource is ignored All that matters is that the process id that WAS runs as has access to MQ should be in the appropriate mqm group, etc. Client/Server Mode (remote TCP access) By default, does not perform any user authentication totally insecure! Userid/password info specified on JMS resource is passed to MQ but ignored by default by MQ
To ensure that there is meaningful authentication of the MQ connection

Custom security exits for client authentication. These exits can access the userid/password information on the connection. A simpler approach is to implement custom MQ authentication using SSL client authentication, and to ensure that MQ only trusts the certificate possessed by WAS
See the URL for a paper on securing WAS-MQ connections at the end of these slides
NMEI
27
IBM WebSphere
Encrypt LDAP Link

The Application Servers, Node Agents and Deployment Manager communicate with LDAP
Each send user passwords, including Admin passwords, to LDAP for verification Queries lots of information which may be sensitive
To protect this link

Create an SSL configuration for LDAP using Security > SSL > New JSSE repertoire WAS needs to posses certificate for CA/signer that issued LDAP certificate Using ikeyman, add the LDAP signer certificate to the trust file used by the SSL configuration that LDAP will be using recommend creating a new SSL New configuration specific to LDAP in 6.1 In V6.1 use admin console GUI to get certificate for LDAP server Specify SSL enabled on the LDAP User Registry page in Security > Global Security > User Registries > LDAP and choose the SSL configuration created earlier
If using a Custom User Registry, ensure this link is encrypted and authenticated method will vary by User Registry
NMEI
28
IBM WebSphere
Change the Default Key File

All WAS internal SSL traffic (HTTP, SOAP, and IIOP) is based around the keys in the key files used by WAS. These are controlled by the SSL configurations. By default, there is one SSL configuration shared by all of WAS and it is using a DummyKeyFile that shipped with product
Every user of WAS gets shipped the same private key. Not very private.
As appropriate, you need to create new SSL configurations with new key and trust files In most cases to address the Default Key problem, sufficient to update the existing default SSL configurations that are shared by the WAS components (there are typically two in a cell)
Create new key databases (key and trust) with new private key & certificate using ikeyman Update SSL config (Security > SSL > DefaultSSLSettings) to use the new key database
WAS V6.1 will generate a installation unique keys at time of installation -- no more DummyKeyFile.
More on following slides 29
Security Hardening
New in 6.1
NMEI
IBM WebSphere
Update all the Key Files Pre WAS 6.1

Dont forget to update the related key files so everything will work All nodes and the deployment manager have these files each has its own <root>/etc directory, update them everywhere The web server plugin needs to recognize the new server certificate. Update plugin-key.kdb. Make sure you update the one actually used by the web server (check plugin-cfg.xml). WAS IIOP/SOAP clients
WAS admin clients are just IIOP/SOAP clients Update the client trust file with the signing cert Need to update the product *.client.props file to point to updated trust file New Key file names and passwords On *all* nodes and dmgr Dont forget remote clients
New in 6.1
See next slide for WAS 6.1-specific info

30
IBM WebSphere
Update all the Key Files WAS 6.1

These are in PKCS12 format key.p12 and trust.p12
New in 6.1
WAS 6.1 will create unique certs and keyfiles for each profile out of the box For base profiles, these are created in the node dir of the config repository Upon federation to cell, the signer of these is added to the cellwide trust store in the cell config directory For the plugin, this is all managed for you, which removes a considerable admin task from previous versions in keeping the keystores in sync
All of this can be managed with the admin console Of course, we dont recommend making the web server hosting the plugin a managed node, so manual copying of automatically generated keyfiles to plugin will likely still be necessary
31
Security Hardening
IBM WebSphere
Choosing a Certificate Signer

How you generate the new private key and certificate affects what you must update in the client trust files
Well known CA as signer CA cert it is probably already in the standard WAS client trust file No update needed for client trust files (or plugin-key.kdb) Must buy cert from CA and renew yearly Your own CA as signer or a self-signed certificate Create a trust file for the client using ikeyman Add the WAS or CA certificate as a signer Create/update a sas.client.props or soap.client.props file for all of the clients Saves money, but now you must distribute the keys to your clients
Generally self-signed certificates are best choice unless you have many Java clients
Self signed certificates are not less secure than CA issued, just harder to manage Not much harder in V6.1 since Java client can import new signers if user allows
New in 6.1
32
Security Hardening
IBM WebSphere
Configure Certificates for Browser Validation

With Global Security enabled, connecting to the Administration Console will typically trigger warnings in the Browser like these
Certificate not issued by a trusted Certificate Authority Site name does not match hostname
WAS V6.1 will by default generate a certificate that uses the deployment manager hostname
Certificate is still not issued by a trusted Certificate Authority
33
Security Hardening
New in 6.1
NMEI
IBM WebSphere
Configure Certificates for Browser Validation

To address the certificate trust problem
Option 1: use a well-known CA to issue WAS certificates Expensive, must renew yearly Option 2: simply accept the certificate in the browser on the first use as trusted Make sure its the right cert; recommend at least verifying the fingerprint
To address the site name not matching hostname problem

Obtain a certificate with the dmgrs hostname as the subject to avoid browser warnings about the name mismatch on every access Since the dmgr hostname cant change this should not be a problem
Train your admins that if this message ever comes up again there is a problem!
People are the weakest link; ignoring the warning leaves you open to a potential man in the middle attack
NMEI
34
Security Hardening
IBM WebSphere
Harden the Web Server Host

Your Web Server might be running in the DMZ the first point for external connections, so
Harden the operating system; limit other running processes Limit the Web Server modules being loaded Review the Web Server configuration; minimise the opportunity for attack Ensure that the WAS plugin is configured to only forward traffic for the right applications (if WAS generates the plugin-cfg.xml file this should happen naturally)
WAS 6.0 introduces the ability to manage Web Servers as part of a cell
Two options New in 6.0 Managed Node a regular Node Agent collocated with web server (in the DMZ) IHS Admin Server Both approaches increase the potential attack surface; not recommended for use in a DMZ for a production environment (although convenient for a test environment).
Remove the JDKs installed when installing the Web Server and the Plug-in
IHS installer leaves behind one JDK and the plug-In installer leaves behind two JDKs Zip up these installations if required for later uninstallation or fixpacks In WAS 6.1 only 2 JREs left behind, rather than the prior 3 JDKs One JRE for the plugin, one for the web server (if IHS) New These should still be archived and removed in 6.1
NMEI
35
IBM WebSphere
Harden the Proxy Host

Harden whatever is in the DMZ
Maybe your web server isnt in the DMZ You are using an proxy server E.g., Tivoli Access Manager WebSEAL Standard operating system hardening applies Ensure that the proxy is only forwarding requests that should be forwarded e.g., look at the URLs it is proxying and make sure the list is just what is needed and no more Even better, if you are using WebSEAL, use Tivoli AMoS (OS hardening) with WebSEAL No charge option if using WebSEAL
Best bet for Web services proxy: DataPower

Hardened, application solution
No spinning media, no true OS, insanely secure and fast Supports WS-security and many other related standards Provides for XML threat protection nearly impossible to secure Web services without something like DataPower!!
36
Security Hardening
IBM WebSphere
Dont Run Samples in Production

WAS ships with several excellent samples which demonstrate various aspects of WAS and can serve as diagnostic tools
Samples arent designed to be secure Some samples, like showCfg and Snoop reveal a wealth of information about your production environment Precisely the type of information you do not want to give a potential attacker, so remove them or ensure that these applications are not started
NMEI
37
IBM WebSphere
Consider Authenticating Web Server to WAS Link

Plugin transmits information from the Web Server to the Application Server
This information may be security sensitive - in particular, authentication information (passwords or user identity from certificates) No action is required after configuring web server to use HTTPS and updating plugin key file to contain correct signing certificate (the one you created earlier) By default, plug-in will use HTTPS to connect to Application Server only if Browser used HTTPS By default, the Application Server does not authenticate the Web Server. Usually this doesnt matter.
In some cases it is critical that you can limit Web Container access only to trusted Web Servers
If using client certificates (WAS is trusting Web Server to verify cert) If using a Trusted Association Interceptor (TAI) that uses unverifiable information (e.g. only a userid only is forwarded to TAI) To limit Web Container access to trusted Web Servers Limit the Application Server to HTTPS transport (delete HTTP transport) Update the Web Server plugin and web container key and trust files such that each can talk only to the other using the limiting connections to trusted clients approach described earlier Update SSL configuration used for HTTPS to require client authentication
NMEI
38
IBM WebSphere
Protect Your Configuration Files & Private Keys

There are numerous files in a typical WAS install that need to be protected because of what they contain
The configuration repository XML files in config contain topology information and many embedded passwords (e.g., LDAP, WAS root, databases, enterprise systems, etc) Note: As of WAS 6.0.2, clients can write their own custom password module to encrypt them (see programming hints & tips presentation)
etc/DummyServerKeyFile.jks (you will probably change the name of the file) - a JKS keystore containing WAS' private key etc/plugin-key.kdb - web server's private key etc/plugin-key.sth - the password for access to the plugin-key.kdb. sas.client.props or soap.client.props - config file may contain a user UID and password installedApps files for applications that have been installed. Users other than WAS shouldnt be able to modify. Might contain sensitive information.
Leverage operating system protection to protect file system

(usually) Make everything owned by WAS. Read/Write by no one else.
Dont put private keys on a shared file system Dont share private keys between test and production environments Use caution when sending configuration files externally they contain passwords!
39
Security Hardening
NMEI
IBM WebSphere
Configure and Use TAIs Carefully

Trust Association Interceptors (TAIs) extend the trust domain
They must be carefully designed and carefully deployed Make sure you understand the implications of configuring and using a TAI Mistakes result in serious security weaknesses Weak point is usually server to server trust how does TAI know caller is server trusted to assert identity information
Examples
Weve seen TAIs that validate the host name in the HTTP header as an indicator of trust Since headers can be trivially forged this is completely insecure WebSEAL configuration WebSEAL TAI is quite secure IF configured properly
mutualSSL property on TAI means assume that HTTP input is completely trusted and do no validation > Did you configure a trusted HTTPS tunnel from WebSEAL to WAS? > Deprecated with new TAM WebSEAL TAI (aka TAMPlus TAI) Password authentication > If no loginId property specified ANY valid userid and password combination is assumed to be a trusted server!
40
Security Hardening
IBM WebSphere
Use Only the New LTPA Cookie Format

The WAS LTPA token prior to V5.1.1 has some theoretical weaknesses
No known compromises
New token (as of WAS 5.1.1) uses stronger cryptographic techniques

Random salt Stronger ciphers All data is signed All data is encrypted
Old and new cookies supported simultaneously for compatibility with older WAS versions, WPS, Lotus Domino, TAM, etc.
Can use only new format if all WAS 5.1.1 or greater disable Interoperability Mode on Security > Global Security > Authentication Mechanisms > LTPA > Single Sign-on configuration panel
NMEI
41
IBM WebSphere
Use Only the New LTPA Cookie Format
42
Security Hardening
IBM WebSphere
Dont Specify Passwords on the Command Line

WAS security runtime needs a password if security enabled
Can be stdin, prompt, properties, or specified programmatically Can specify userid & password on command line (usually user & -password) Never do this. Exposes password to anyone that can see process list on same machine
WAS tools will prompt (often graphically) as of 6.0.2 or later if password not provided
Prior to 6.0.2 can force prompt by using RMI JMX connector conntype RMI port <bootstrap port>.
Bootstrap is usually 9809 on dmgr and 2809 for nodes. Applies to most cmd line tools, including wsadmin. If you leave out port or there is an error, will silently fall back to SOAP. tperfviewer is special, use ./tperfviewer.bat localhost 9809 RMI
Installer bug makes this sometimes not work. If so, try this tech note:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websp here.express.doc/info/exp/ae/rtrb_wsadminprobs.html
To use stdin instead of GUI prompt, edit sas.client.props (for RMI) and/or soap.client.props (for SOAP)
soap.client.props: com.ibm.SOAP.loginSource=stdin, or sas.client.props: com.ibm.IIOP.loginSource=stdin Beware that RMI is firewall hostile
NMEI
43
Security Hardening
IBM WebSphere
Encrypt Default Messaging Links

Default Messaging communicates over unencrypted links unless link encryption is configured To enforce the use of encrypted links at the server
New in 6.0
For each application server, disable the InboundBasicMessaging transport clients will then only be able to use the InboundSecureMessaging transport
To enable a client to connect using the encrypted links

JMS clients need to specify the InboundSecureMessaging transport on the Connection Factory panel MDBs need to specify InboundSecureMessaging on the Activation specification panel (new in 6.0.2) Inter-ME communication within the bus needs to be configured to use InboundSecureMessaging (on the main bus panel) If Cross Bus communication is being used; configure this as the Inter-Engine transport chain on the bus configuration panel
WAS V6.1 by default encrypts these links

So the following two slides are pre-WAS 6.1 config
New in 6.1
NMEI
44
IBM WebSphere
Disabling InboundBasicMessaging
45
Security Hardening
IBM WebSphere
Configuring a Connection Factory to use a Secure Transport
46
Security Hardening
IBM WebSphere
Encrypt WebSphere MQ Messaging Links

WebSphere MQ supports SSL between Queue Managers and from clients when using MQ in client mode Specify the required SSL CIPHER SUITE property in WAS admin console on the MQ Connection Factory panel See MQ SSL presentation or the paper on securing WAS/MQ links at the end of this presentation
NMEI
47
IBM WebSphere
Encrypt Distribution and Consistency Services Link

Distribution and Consistency Services (DCS) is used by a number of WAS components
Dynamic Cache Service HTTP Session Replication Stateful Session Bean Replication Distributed Replication Service Core Groups
New in 6.0
DCS always authenticates messages when Global Security is enabled, but maximise security by encrypting this link
For each Core Group, select a transport type of channel framework and DCS-Secure as channel chain name
NMEI
48
IBM WebSphere
Encrypting the DCS Link
49
Security Hardening
IBM WebSphere
Protect Application Server to Database Link

Many databases do not provide encrypted links from JDBC clients to the database, but this is changing for the better
DB2 UDB V8.2 supports encryption Oracle Advanced Security supports encryption DataDirect Sequelink driver supports encryption (w/ SQL Server)
If you cant swing DB encryption, protect this link as best as you can
Inside your intranet. NEVER expose DB to internet. Use firewalls to protect production database from non-production networks Use clever network routing and/or firewalls to limit access to DB to "trusted" client machines Use VPN technology (such as IPSEC) to encrypt links between DB and WAS
NMEI
50
IBM WebSphere
Create Separate Administrative User IDs

Need a root/Administrator" WAS user id in the WAS user registry (Server User ID)
Does not need administrative privileges in the registry. Certainly doesnt need to be root. Used by WAS servers when authenticating internally Should not be used by WAS administrators when authenticating WAS V6.1 separates this into two identities New in 6.1 Server user id server to server stuff not in registry, no password WAS administrator in user registry
Create a WAS user id account for each person that will administer the WAS domain
Create in your registry, then Using the admin console Specify additional administrators: System Administration >Console Users/Groups. These are users/groups from the underlying WAS registry. Grant these users/groups CosNamingCreate, CosNamingDelete in CORBA namespace or they wont be able to log into the admin console
As of WAS 5.0.2, all administrative actions that result in changes to the configuration will be audited by the Deployment Manager
Including the identity of the principal that made the change These records are much more useful if each administrator has a separate identity 51
Security Hardening
NMEI
IBM WebSphere
Take Advantage of Administrative Roles

WAS admin authority has 4 levels:
Monitor look, but not touch Operator start/stop, but not change Configurator configure, but not start/stop. Cant edit some sensitive data. Administrator - everything
Ideally use registry groups to represent these roles

Then registry admins (perhaps security team) control who has what authority to WAS
Now, you can limit administrative access based on need. This is valuable, for example:
During development, the lead developer can give all developers the ability to start/stop app servers, but not mess with the repository During production, you can give people permissions based on job role Monitoring tools (which often store passwords in a file) can have only monitoring permissions
Access is cell wide. Split into multiple WAS cells to restrict access. WAS V6.1 provides administrative isolation
Only available using the command line; does not apply to Admin Console
New in 6.1
NMEI
52
Security Hardening
IBM WebSphere
Administrative Roles
Administrator
Configurator
Sensitive Config
Operator
Monitor
53
Security Hardening
IBM WebSphere
Warning: Trace Vulnerability

Any user with operator, configurator, or administrator role (but not monitor) can configure trace viewer in admin console to display contents of ANY file that WAS can read, including security.xml which contains passwords!!!
54
Security Hardening
IBM WebSphere
Choose an Appropriate Process Identity

The WAS processes must run under some Operating System identity, so lets discuss the choices
Everything as Root/Privileged User Everything as Normal User Node Agent as Root/Privileged User, Application Servers as Normal User
Option #1: Everything as Root/Privileged User

Default, out of the box configuration no configuration required Can use local OS as user registry All WAS processes have read/write access to all WAS related files (and everything else) WAS administrators have implicit root authority Can configure so that nothing else (other than root) has access to WAS files
NMEI
55
IBM WebSphere

Option #2: Node Agent as root
People often choose this in order to isolation applications by using operating systems permissions it doesnt work!! Does not achieve administrative and application isolation WAS is managed as single trust domain Assign OS user accounts for app servers to limit access wasrun - is the OS user that the app server "runs as"
member of wasgroup Can limit access to files not owned by that application server (doesnt address shared application servers) Read & write privileges solely for application server profile(s)
Node manager runs as the root (or root-like) OS user Read & write privileges for the application server profile(s) plus Node Agent profiles WAS administrators have implicit root authority Difficult to configure Can use LocalOS registry, but have to set special property (WAS_UseRemoteRegistry) Has almost no meaningful impact on security, but can be useful for application server level accounting
NMEI
56
IBM WebSphere

Option #3: Everything as a Normal user
All Application Servers must run under the same, non-privileged OS user as the Node Manager (e.g. wasuser) The OS user (wasuser) needs read/write access to WAS directories. All WAS processes have equal read/write access to WAS directories. WAS administrators don't have root access Fairly easy to configure Simple chmod/chown of the WAS files and you are on your way
NMEI
57
IBM WebSphere
Options Summary
All as root user WAS admins have implicit root authority Some WAS admin tasks may require root access Cant use Operating System Registry Fairly complex file ownership/permission issues Node as root All as non-root
Application isolation cannot be address by operating system permissions. Need Java 2 security and MUCH more. Refer to application isolation materials.
58
IBM WebSphere
Enforce CSIv2 Transport SSL use

WAS clients and servers using CSIv2 IIOP will negotiate a mutually acceptable level of transport security CSIv2 is supported over SSL or cleartext; by default both parties will negotiate to use SSL
However if either party requests cleartext, then cleartext will be used Most likely scenario when cleartext is in use would be a mis configured client
If you want to assure that traffic is encrypted; ensure that SSL is the only acceptable option at negotiation time
Security > Authentication Protocol > CSIv2 > Inbound Transport and Security > Authentication Protocol > CSIv2 > Outbound Transport Change Transport from SSL-supported to SSL-required
NMEI
59
IBM WebSphere
Keep Up to Date with Patches and Fixes

The IBM Support Website provides you with information on Securityrelated Updates
http://www.ibm.com/software/webservers/appserv/was/support/
http://www.ibm.com/support/mysupport
Several ways to monitor updates

Subscribe to IBM Flashes via Request Email Updates Monitor updates by subscribing to an RSS Feed News Feeds of New Content Regularly review Recommended Updates support page
Warning: Security fixes are usually rolled into the next Cumulative Fix or Refresh Pack for every supported release and then no longer listed on the recommended updates page Keep up to date with all your infrastructure components Operating Systems, LDAP, Database, Web Server etc not just WAS
NMEI
60
IBM WebSphere
Disable Unused Ports

Basic principle of security hardening is to minimise the potential attack surface, even when no known security issues
If a service isnt required, disable it
Potential candidates for disablement include

SAS_SSL_SERVERAUTH_LISTENER_ADDRESS used for compatibility with WAS V4 and earlier releases (old IIOP security protocol replaced by CSIv2) Take out of service by selecting CSI as the active protocol on Global Security panel SIB_ENDPOINT_* - used by the default messaging engine Not started unless the messaging engine is enabled SIB_MQ_* - used by the messaging engine when connecting to MQ Not started unless the messaging engine is enabled WC_adminhost* - used for administrative Web Browser access Can be removed from the Web Container Transport Chain Configuration Panel for servers that arent the Dmgr Check to ensure these ports are not re-enabled after cloning WC_defaulthost* - default Web container listening ports if youve added custom listener ports these might not be needed Can be removed from the Web Container Transport Chain Configuration Panel
NMEI
61
IBM WebSphere
Disable Password Caching

WAS caches user information to improve performance, including passwords
Password caching (in memory) is often frowned upon by security experts Note: cache is actually a one way password hash not a big risk! Issues: Can still authenticate with old password when registry updated Can still authenticate if account locked in registry using cache Some custom login scenarios dont work right because cached data is used rather than calling login modules
This could result in bypass of the expected login process!!
Password caching can be disabled by setting a JVM system property as follows: com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled
62
Security Hardening
IBM WebSphere
Agenda
Introduction SSL Overview Infrastructure Preventative Measures Advanced Considerations
Cross Cell Trust WAS Weaknesses
Protecting your Desktop Environment Wrap-up
63
Security Hardening
IBM WebSphere
Cross Cell Trust

It is often desirable to have SSO across WAS cells for good business reasons
Need to understand that cross cell communication impacts trust and raises significant security issues When cells trust each other, compromise of one may compromise another Three technical issues to consider which all relate to cross cell SSO Shared LTPA keys CSIv2 identity assertion Subject propagation callbacks
64
Security Hardening
IBM WebSphere
Shared LTPA Keys

Ordinarily, WAS cells cant communicate with each other securely
Can configure cells to communicate securely (implies trust boundary is now both cells) Share same registry Share same LTPA encryption key Have compatible SSL keyrings Then either cell can create credentials for the other If either is compromised, so is the other!
Cell A could forge WAS admin credentials and use it to hack cell B
Published APIs exist for becoming any user!!

Only Java 2 security blocks
65
Security Hardening
IBM WebSphere
CSIv2 Server to Server Identity Assertion

Scenario: cell A servers call cell B servers and not the reverse
Servers in cell A perform identity assertion to servers in cell B Compromise of cell A always compromises B Cell A can assert any userid to cell B (including admin) If cell A uses password based server to server authentication Cell B knows security server id and password for cell A Therefore, compromise of B compromises A If use certificate authentication for based server to server authentication Cell B cannot assume any identity in cell A Cell B cannot compromise cell A
Net: Identity assertion can slightly reduce risk over shared LTPA keys WAS V6.1 allows cell A to use a defined account in cell Bs user registry
Eliminates need to share cell Bs security server id password with cell A Specify an alternative trusted identity on CSIv2 outbound panel
New in 6.1
66
Security Hardening
IBM WebSphere
Safe Server to Server Authentication

Certificate
Password
67
Security Hardening
IBM WebSphere
Subject Propagation Callbacks

Servers can optionally share customized subjects, even across cells Consider two servers that share an SSO domain. User with customized subject accesses server A and obtains an authentication session. Then, goes to server B.
This requires Subject propagation Subject propagation uses DynaCache (within a replication domain) or callbacks
JMX callback involves a secure call from server B to server A to obtain the users tokens (authentication information)
Server B authenticates to server A by sending its admin userid and password Server A authorizes server B by verifying that the userid has administrative authority
Trust leak is then

Server B has administrative authority to server A Server A is receiving server Bs admin userid and password Irrelevant within a cell, but potentially significant across cells Keep in mind that SSO across cells already requires significant trust
New in 6.1
WAS V6.1 allows the use of an LTPA token instead of a password

Eliminates leakage of server Bs admin user password but still requires significant trust
Security Hardening
68
IBM WebSphere
Agenda
Introduction SSL Overview Infrastructure Preventative Measures Advanced Considerations
Cross Cell Trust WAS Weaknesses
Protecting your Desktop Environment Wrap-up
69
Security Hardening
IBM WebSphere
Corner Cases: Weaknesses in WAS Security

Certificate Authentication Limitations
Doesnt check Certificate Revocation Lists (CRLs) for RMI/IIOP traffic You could write a custom user registry to perform certificate verification and CRL checking Doesnt check that destination of request is in fact intended party Would require that caller identify hostname or identity expected of server being contacted Subject to man in the middle attacks
WAS V6.1 supports CRL checking as well as hostname verification

This is done by configuration of the trust manager
New in 6.1
NMEI
70
IBM WebSphere
Agenda
Introduction SSL Overview Infrastructure Preventative Measures Application Preventative Measures Advanced Considerations Protecting your Desktop Environment Wrap-up
71
Security Hardening
IBM WebSphere
WebSphere Studio/Rational Application Developer Hardening

The embedded test environment includes a fully functional WAS environment
Listens on remote ports Accepts admin commands, include application installation and execution An attacker could easily request that WAS install and run arbitrary code if the test server is running Code could delete users files, read files, or just cause havoc If desktop user has administrative authority, the attacker can leverage operating system administrative commands to cause even more damage Attack could be launched using wsadmin, SOAP/JMX, or even a web browser!
The Agent Controller is installed by default and is used for monitoring application servers
By default (prior to 6.0.1), the Agent Controller accepts requests from any host without authentication -- could be used to read any file from your computer
72
Security Hardening
IBM WebSphere
Harden the Embedded Application Server

Option #1: Harden embedded WAS
Enable Global Security in the embedded application server Prevents most serious attacks To enable Global Security, youll need a registry
LocalOS but require an Administrator account LDAP not always readily available Best alternative: configure a custom file registry, see the InfoCenter.
Other hardening steps (from this presentation) worth considering but not as critical Other weaknesses can be used to damage embedded test environment which will be frustrating, but shouldnt result in compromise of entire desktop WAS V6.1 will enable Administrative Security by default and includes a supported file registry
New in 6.1
Option #2: Install a desktop firewall to block access to the computer

Take care to configure carefully a desktop firewall which trusts your entire internal corporate network is of little value
73
IBM WebSphere
Harden the Agent Controller

Option #1: Secure the Agent Controller
When you first install the Agent Controller, configure it to accept requests only from this computer or configure it to authenticate requests If you have already installed the Agent Controller, the installation can be hardened after the fact Edit <RAC_INSTALL>\config\serviceconfig.xml and look for the Hosts configuration stanza. Change the Hosts configuration from allowing all hosts to only allowing local
<Hosts configuration="default"> <Allow host="LOCAL"/> </Hosts>
New in 6.1
WAS V6.1 AST does not include Agent Controller Presumably RAD V7 will and this should be addressed by default Appears to be part of an open source project: http://www.eclipse.org/tptp/
Option #2: Install a desktop firewall as in previous example
74
Security Hardening
IBM WebSphere
Agenda
Introduction SSL Overview Infrastructure Preventative Measures Application Preventative Measures Advanced Considerations Protecting your Desktop Environment Wrap-up
75
Security Hardening
IBM WebSphere
Dont Forget: Consider the Whole Environment

Other components
Operating system Network Databases LDAP directories Enterprise systems: CICS, IMS, etc SAP, PeopleSoft, etc.
Denial of Service and Distributed Denial of Service Attacks

This is a very hard problem and goes well beyond WAS. Read a lot and hire the experts! Out of scope
76
Security Hardening
IBM WebSphere
Dont Forget Applications

Applications need to be hardened against attack
See Application Hardening presentation
Applications might try to harm other applications

See Application Isolation presentation
77
Security Hardening
IBM WebSphere
Non IT Security Issues

Far more to secure systems than just IT stuff Physical Security if the intruder can walk into your data center and just take what they want, WAS authentication isnt going to help! Social Engineering
If the humans in your business can be compromised, a lot of IT security become irrelevant Human beings routinely make bad security decisions You need firm and well understood security policies and strong enforcement E.g., Dont give someone your password if they ask.
78
Security Hardening
IBM WebSphere
Audit, audit, audit ...

You spent months in meetings to come up with a security policy. Fine. How do you know if anybody read it. Make sure a regular audit is part of your policy.
Monitor employees for non-compliance
You should also be monitoring system logs, including the WAS serious event stream
Events tell you something about the system activity and may help detect intruders or failures Ideally using automated tools to correlate events
79
Security Hardening
IBM WebSphere
FAQ: What about a Security Proxy?

Tivoli Access Manager (TAM) is an example of a good security proxy Does a security makes this any easier? no
Security proxies (such as TAM) adds other features (web SSO, auditing, security monitoring, etc), but they are unrelated to the issues I covered here
Does a security proxy make this any worse? no

In fact, in some ways, it will make it better with another layer of security
Does security make this any harder? yes

You still have to do everything here, plus the proxy configuration and management. However, if you need the function, the extra effort is justified
Proxies do not eliminate the need for WAS security

You must ensure that the proxy provides for security integration with WAS, usually via Trust Association Interceptors
80
Security Hardening
IBM WebSphere
FAQ: Operating System Hardening

IBM WebSphere development does not test or recommend any hardened operating system configurations We require and test for the standard operating system packaging from your vendor Anecdotal evidence from several customers suggests that WAS can run on a hardened operating system
Platform-specific hardening info at http://cisecurity.org
81
Security Hardening
IBM WebSphere
IBM provides several tools to help

IBM Security Scanner for WebSphere Application Server
Checks for many potential security configuration issues Does not check for all the issues mentioned in this presentation http://www.ibm.com/support/docview.wss?uid=swg24009963
ACert tool
Checks SSL certificates for expiration dates http://www.ibm.com/support/docview.wss?uid=swg24006797
New in 6.1
WAS V6.1 provides a security report

Basically a list of your configuration, provided with v6.1
82
Security Hardening
IBM WebSphere
References
WebSphere Security Presentation Series
http://pokgsa.ibm.com/~keys/documents/securitySeries
WebSphere Application Server V6 Security Handbook

SG24-6316-00 available from http://www.redbooks.ibm.com V6.1 version coming soon
IBM WebSphere: Deployment and Advanced Administration
ISBN 0131468626
http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=0131468626&itm=5
WAS V6 Security Hardening Paper

Covers all the topics in this presentation WSDD - http://www-
128.ibm.com/developerworks/websphere/techjournal//0512_botzum/0512_botzum1.ht ml
Securing connections between WebSphere Application Server and WebSphere MQ

Part 1 http://www128.ibm.com/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.html Part 2 (SIBus to MQ via MQ Link) - http://www128.ibm.com/developerworks/websphere/techjournal/0601_smithson/0601_smithson.html
83
Security Hardening
IBM WebSphere
Appendix
84
Security Hardening
IBM WebSphere
So you think you dont need security?

We still occasionally encounter those that claim they dont need security because the production network is secure To this we ask the following question:
If you don't need security how about if we remove all passwords from your production operating systems (e.g., make the root password blank). If they don't think they need security on WAS or their apps, then to be logically consistent the same should be true for the operating systems.
85
Security Hardening
IBM WebSphere
What about Process Server? First Thoughts

Everything in this presentation applies, plus SCA components with exported interfaces (callable across modules) result in implicit EJBs with remote interfaces
You must secure those using the SCA tools Specify a security permission as a Quality of Service qualifier Be aware that if you SCA components arent true EJBs that
You cant use EJB constraints as there are no real EJB methods You likely cant use JACC for the same reason There are no SCA security APIs equivalent to the J2EE APIs (e.g., isCallerInRole)
SCA components that read from or write to queues require authentication if security is enabled
Specify authentication alias information on the connection in the bindings panel
Lots of potential to export Web Services which means you need to secure those in the usual manner E.g., web services authentication (WS-Security or transport), plus EJB authorization Human tasks use the Staff registry for making authorization decisions, not the users authenticated Subject
Custom group information in subject will be ignored 86
IBM WebSphere

WBI adapters communicate with SIBus youll need to secure that link
Authenticate using MQ authentication and set proper SIB authorization Unclear if can encrypt consider VPN solution
Authorization Issues
Coarse grained authorization you dont have much control over who can edit/manage particular instances of something Weak default authorization some components have rather open authorization (typically all authenticated) by default Look at
87
Rules Processes Human task administration CEI etc

IBM WebSphere

CEI event store to a DataSource
Assumes authentication data is defined on resource cant protect from illegal access
88
Security Hardening
IBM WebSphere
Visas Recommended Standards

http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_ PCI_Data_Security_Standard.pdf The PCI-DSS is actually more general though. It defines twelve requirements:
Requirement 1: Install and maintain a firewall configuration to protect data Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Requirement 3: Protect stored data Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks Requirement 5: Use and regularly update anti-virus software Requirement 6: Develop and maintain secure systems and applications Requirement 7: Restrict access to data by business need-to-know Requirement 8: Assign a unique ID to each person with computer access Requirement 9: Restrict physical access to cardholder data Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 11: Regularly test security systems and processes. Requirement 12: Maintain a policy that addresses information security
89
Security Hardening
IBM WebSphere
Legal
Copyright IBM Corporation 2004, 2005. All rights reserved. IBM, the IBM logo, the e-business logo and other IBM products and services are trademarks or registered trademarks of the International Business Machines Corporation, in the United States, other countries or both. References in this publication to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this publication may change at any time at IBMs sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries or both. Microsoft, Windows, Windows NT and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries or both.
All other trademarks, company, products or service names may be trademarks, registered trademarks or service marks of others.
90
Security Hardening

0611 Botzum WAS 60 Security Hardening

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0611 Botzum WAS 60 Security Hardening

Uploaded by

Copyright:

Available Formats

IBM Software Group

WebSphere Application Server Version 6 Security: Infrastructure Hardening May 2006

Cameron Martin, Senior IT Specialist cameron.martin@uk.ibm.com

2006 IBM Corporation

last update: November 20, 2006

WebSphere Security Presentation Series

2006 IBM Corporation

Change is the Only Constant

2006 IBM Corporation

WHY HAVE SECURITY?

2006 IBM Corporation

2006 IBM Corporation

Generate Server Keys

Server Certificate CA Certificate Public Public

Offline operations that occur before client first contacts server

Server Certificate Public Client Encrypted Message Public Server

2006 IBM Corporation

SSL authentication does not imply the system is secure!!

2006 IBM Corporation

Limiting Connections to Trusted Clients

We can use this technique to limit connections to trusted clients

2006 IBM Corporation

Implementing Trusted Tunnel with SSL

2006 IBM Corporation

Application Server Browser S W Node Agent Node W eb Services I W

L L LDAP Deploym ent M anager

2006 IBM Corporation

W = WAS internal communication

M = SIB messaging protocol

2006 IBM Corporation

J = JDBC database communication via vendor JDBC drivers

2006 IBM Corporation

Attack on multiple levels

The Standard Configuration with Firewalls

W eb S erver H H F W B row ser S F W

A pplication S erver W N ode A gent N ode

L L W D eploym ent M anager LD A P

2006 IBM Corporation

Put the Web Server in the DMZ without WAS

Inbound network traffic from outside must be terminated in the DMZ

DMZ firewalls strictly limit traffic to

Separate your Production Network from your Intranet

What about Additional Firewalls?

Just be systematic and patient

2006 IBM Corporation

Enable Global Security

WAS admin security is independent of application security

WAS V5/V6.0 vs WAS V6.1

Use HTTPS from the Browser

Configure Secure File Transfer

WAS V6.1 uses the secured version by default

Somewhat safer, but breaks some applications not recommended

All Authenticated read

Ensure Meaningful Authorisation on Default Messaging

Configure a more appropriate subset of users using wsadmin, for example:

Bus Security in V6.1

2006 IBM Corporation

Restrict Access to WebSphere MQ Messaging

To ensure that there is meaningful authentication of the MQ connection

Encrypt LDAP Link

To protect this link

Change the Default Key File

Update all the Key Files Pre WAS 6.1