0611 Botzum WAS 60 Security Hardening

IBM Software Group

© 2006 IBM Corporation

WebSphere Application ServerVersion 6 Security: Infrastructure Hardening

May 2006

Keys Botzum, Senior Technical Staff [email protected]

IBM Software Services for WebSpherehttp://www.ibm.com/WebSphere/developer/services

last update: November 20, 2006

Cameron Martin, Senior IT [email protected]

http://www.ibm.com/WebSphere/developer/services

IBM WebSphere

© 2006 IBM CorporationSecurity Hardening2

WebSphere Security Presentation SeriesThis presentation is part of the WebSphere Security PresentationSeries led by Keys Botzum with help from so many others

– Available internally at http://pokgsa.ibm.com/~keys/documents/securitySeries

Related presentations– We assume you’ve 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

IBM WebSphere


Change is the Only ConstantThis 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)

• 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

Newin 6.0

Newin 6.1

IBM WebSphere


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.

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.

IBM WebSphere


IntrusionsPeople 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.

IBM WebSphere


AgendaIntroduction

SSL Overview

Infrastructure Preventative Measures

Advanced Considerations

Protecting your Desktop Environment

Wrap-up

IBM WebSphere


SSL Overview

Trus

ted

Certificate Authority

GenerateServerKeys

Public Private

Public Private

Server Certificate

Public

Sign

CA Certificate

Public

ServerClient

Secu

re

Server Certificate

Public

EncryptedMessage

Public

Offline operations thatoccur before clientfirst contacts server

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 server’s certificate by checking its expiration date and signature– Signature is verified using signing certificate in trust store

• If certificate signature isn’t 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 hasn’t 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

IBM WebSphere


Limiting Connections to Trusted ClientsSometimes it is difficult to insert proper authorization into anexisting 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 theclients 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 we’ll explore later

IBM WebSphere


Implementing “Trusted” Tunnel with SSLUsing 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

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 certauthentication is always on)

Newin 6.1

IBM WebSphere


AgendaIntroduction

SSL Overview




Wrap-up

IBM WebSphere


Basic Topology

Node

AppDB

LDAP

Session & SIBDB

ApplicationServer

Application Server with

ME

NodeAgent

Browser

WebServer

ApplicationServer

WebServices

EJB

Client

AdminBrowser

wsadmin

DeploymentManager

L

L

H

L

J

J

I

HW

W

W, M

I, W

H

S

W

MQServer

MQJ

IBM WebSphere


Protocols UsedH = 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.

Newin 6.0

IBM WebSphere


Protocols UsedMQ = 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

IBM WebSphere


Attack on multiple levelsNetwork - 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 shouldn’t

External Application – legitimate and illegitimate users that leverage application level protocols (RMI/IIOP, HTTP, etc) to try to do things they shouldn’t 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

N M E I

The type of attack(s) that a measure defendsagainst is highlighted on the relevant slides

IBM WebSphere


The “Standard” Configuration with Firewalls

Node

AppDB

LDAP

Session & SIBDB

ApplicationServer

Application Server w ith

M E

NodeAgent

Browser

W ebServer

ApplicationServer

W ebServices

EJB

Client

Adm inBrowser

wsadm in

Deploym entManager

L

L

H

L

J

J

I

HW

W

W , M

I, W

H

S

W

M QServer

M QJ

FW

FW

FW

IBM WebSphere


Put the Web Server in the DMZ without WASNothing 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

N M E I

IBM WebSphere


Separate your Production Network from your IntranetProtect 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”

N M E I

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

N M E I

IBM WebSphere


Beyond FirewallsFirewalls are a valuable component in an overall security plan, but they are not sufficient

Now that we have firewalls in place– Let’s continue to harden WAS from attack

– This list is in priority order

Just be systematic and patient

IBM WebSphere


Enable Global SecurityEnable 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 – we’ll 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 N M E I

Newin 6.1

IBM WebSphere


Use HTTPS from the Browser If your site performs any authentication or has any confidentialinformation then configure your web server to support HTTPS– Refer to your Web Server’s documentation for instructions

– Popular web browsers ship with around 50 odd ‘pre-trusted’ CA certificates. You’ll 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.

N M E I

IBM WebSphere


Configure Secure File TransferNode 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

WAS V6.1 uses the secured version by default– when Administrative Security is enabled

cd <profilehome>\binwsadmin.batwsadmin>source ../../../bin/redeployFileTransfer.jaclwsadmin>fileTransferAuthenticationOn <cellName> <dmgrName> dmgrwsadmin>$AdminConfig save

N M E I

Newin 6.1

IBM WebSphere


Protect JNDI J2EE applications use JNDI to find other applications and resourcesToo 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

Recommended configuration– 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 workSomewhat safer, but breaks some applications – not recommended– Everyone – nothing

– Unauthenticated threads (e.g, anonymous servlets) can’t read JNDI> MDBs can’t access JNDI> Local refs (e.g., java:comp/env) will not work> Applications must authenticate users or authenticate themselves using JAAS or RunAs

– All Authenticated – read

Permission are set in the admin console via Environment > Naming > CORBA Naming Service GroupsWAS V6.1 by default uses the above recommended configuration

N M E I

Newin 6.1

IBM WebSphere


Ensure Meaningful Authorisation on Default MessagingOnce 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:

You’ll 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

cd <profilehome>\binwsadmin.batwsadmin>$AdminTask removeGroupFromBusConnectorRole {-bus mySIB –group AllAuthenticatedwsadmin>$AdminTask addUserToBusConnectorRole {-bus mySIB –user userYouDetermine}wsadmin>$AdminConfig save

N M E I

Newin 6.0

Newin 6.1

IBM WebSphere


Bus Security in V6.1 Newin 6.1

IBM WebSphere


Restrict Access to WebSphere MQ MessagingTwo 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 MQTo 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

N M E I

IBM WebSphere


Encrypt LDAP LinkThe 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 configuration specific to LDAP

• 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

N M E I

Newin 6.1

IBM WebSphere


Change the Default Key FileAll 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… N M E INew

in 6.1

IBM WebSphere


Update all the Key Files – Pre WAS 6.1Don’t 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• Don’t forget remote clients

See next slide for WAS 6.1-specific info

Newin 6.1

IBM WebSphere


Update all the Key Files – WAS 6.1WAS 6.1 will create unique certs and keyfiles for each profile out of the box– These are in PKCS12 format – key.p12 and trust.p12

For base profiles, these are created in the node dir of the configrepository

Upon federation to cell, the signer of these is added to the cell-wide 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 don’t 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

Newin 6.1

IBM WebSphere


Choosing a Certificate SignerHow 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

IBM WebSphere


Configure Certificates for Browser ValidationWith 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 N M E I

Newin 6.1

IBM WebSphere


Configure Certificates for Browser ValidationTo 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 it’s the right cert; recommend at least verifying the fingerprint

To address the site name not matching hostname problem– Obtain a certificate with the dmgr’s hostname as the subject to avoid browser

warnings about the name mismatch on every access

– Since the dmgr hostname can’t 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 attackN M E I

IBM WebSphere


Harden the Web Server HostYour 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

• 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)• These should still be archived and removed

N M E I

Newin 6.0

Newin 6.1

IBM WebSphere


Harden the Proxy HostHarden whatever is in the DMZ– Maybe your web server isn’t 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!!

IBM WebSphere


Don’t Run Samples in ProductionWAS ships with several excellent samples which demonstrate various aspects of WAS and can serve as diagnostic tools– Samples aren’t 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

N M E I

IBM WebSphere


Consider Authenticating Web Server to WAS LinkPlugin 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 doesn’t

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

N M E I

IBM WebSphere


Protect Your Configuration Files & Private KeysThere 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. User’s other than WAS shouldn’t 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.

Don’t put private keys on a shared file system

Don’t share private keys between test and production environments

Use caution when sending configuration files externally – they contain passwords! N M E I

IBM WebSphere


Configure and Use TAIs CarefullyTrust 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– We’ve 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!

IBM WebSphere


Use Only the New LTPA Cookie FormatThe 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

N M E I

IBM WebSphere


Use Only the New LTPA Cookie Format

IBM WebSphere


Don’t Specify Passwords on the Command LineWAS 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.websphere.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

N M E I

IBM WebSphere


Encrypt Default Messaging LinksDefault Messaging communicates over unencrypted links unless link encryption is configuredTo enforce the use of encrypted links at the server– 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

N M E I

Newin 6.0

Newin 6.1

IBM WebSphere


Disabling InboundBasicMessaging

IBM WebSphere


Configuring a Connection Factory to use a Secure Transport

IBM WebSphere


Encrypt WebSphere MQ Messaging LinksWebSphere 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

N M E I

IBM WebSphere


Encrypt Distribution and Consistency Services LinkDistribution 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

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

N M E I

Newin 6.0

IBM WebSphere


Encrypting the DCS Link

IBM WebSphere


Protect Application Server to Database LinkMany 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 can’t 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

N M E I

IBM WebSphere


Create Separate Administrative User IDsNeed a “root/Administrator" WAS user id in the WAS user registry (Server User ID)– Does not need administrative privileges in the registry. Certainly doesn’t 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

• 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 won’t 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 N M E I

Newin 6.1

IBM WebSphere


Take Advantage of Administrative RolesWAS admin authority has 4 levels: – Monitor – look, but not touch

– Operator – start/stop, but not change

– Configurator – configure, but not start/stop. Can’t 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

N M E INewin 6.1

IBM WebSphere


Administrative Roles

Administrator

Configurator Operator

Monitor

Sensitive Config

IBM WebSphere


Warning: Trace VulnerabilityAny 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!!!

IBM WebSphere


Choose an Appropriate Process IdentityThe WAS processes must run under some Operating System identity, so let’s 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

N M E I

IBM WebSphere


Choose an Appropriate Process IdentityOption #2: Node Agent as root– People often choose this in order to isolation applications by using operating systems permissions –

it doesn’t 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 (doesn’t 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

N M E I

IBM WebSphere


Choose an Appropriate Process IdentityOption #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

N M E I

IBM WebSphere


Options SummaryAll as root user

Node as root

All as non-root

WAS admins have implicit root authority

Some WAS admin tasks may require root access

Can’t use Operating System Registry

Fairly complex file ownership/permission issues

Application isolation cannot be address by operating system permissions. Need Java 2 security and MUCH more. Refer to application isolation materials.

IBM WebSphere


Enforce CSIv2 Transport SSL useWAS 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 SSLis 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”

N M E I

IBM WebSphere


Keep Up to Date with Patches and FixesThe IBM Support Website provides you with information on Security-related 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 Fixor 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

N M E I

http://www.ibm.com/software/webservers/appserv/was/support/

http://www.ibm.com/support/mysupport

IBM WebSphere


Disable Unused PortsBasic principle of security hardening is to minimise thepotential attack surface, even when no known security issues– If a service isn’t 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 aren’t the Dmgr• Check to ensure these ports are not re-enabled after cloning

– WC_defaulthost* - default Web container listening ports – if you’ve added custom listener ports these might not be needed• Can be removed from the Web Container Transport Chain Configuration Panel

N M E I

IBM WebSphere


Disable Password CachingWAS 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 don’t 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

IBM WebSphere


AgendaIntroduction

SSL Overview


Advanced Considerations– Cross Cell Trust– WAS Weaknesses


Wrap-up

IBM WebSphere


Cross Cell TrustIt 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

IBM WebSphere


Shared LTPA KeysOrdinarily, WAS cells can’t 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

IBM WebSphere


CSIv2 Server to Server Identity AssertionScenario: 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 keysWAS V6.1 allows cell A to use a defined account in cell B’s user registry– Eliminates need to share cell B’s security server id password with cell A– Specify “an alternative trusted identity “ on CSIv2 outbound panel New

in 6.1

IBM WebSphere


“Safe” Server to Server AuthenticationCertificate

Password

IBM WebSphere


Subject Propagation CallbacksServers 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 user’s tokens (authentication information)

– Server B authenticates to server A by sending it’s 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 B’s admin userid and password

– Irrelevant within a cell, but potentially significant across cells• Keep in mind that SSO across cells already requires significant trust

WAS V6.1 allows the use of an LTPA token instead of a password– Eliminates leakage of server B’s admin user password but still requires significant trust

Newin 6.1

IBM WebSphere


AgendaIntroduction

SSL Overview


Advanced Considerations– Cross Cell Trust

– WAS Weaknesses


Wrap-up

IBM WebSphere


Corner Cases: Weaknesses in WAS SecurityCertificate Authentication Limitations– Doesn’t check Certificate Revocation Lists (CRLs) for RMI/IIOP traffic

• You could write a custom user registry to perform certificate verification and CRL checking

– Doesn’t 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

N M E I

Newin 6.1

IBM WebSphere


AgendaIntroduction

SSL Overview


Application Preventative Measures



Wrap-up

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 user’s 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

IBM WebSphere


Harden the Embedded Application ServerOption #1: Harden embedded WAS– Enable Global Security in the embedded application server

• Prevents most serious attacks• To enable Global Security, you’ll 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 shouldn’t result in compromise of entire desktop

– WAS V6.1 will enable Administrative Security by default and includes a supported file registry

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

Newin 6.1

IBM WebSphere


Harden the Agent ControllerOption #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>

– 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

Newin 6.1

IBM WebSphere


AgendaIntroduction

SSL Overview


Application Preventative Measures



Wrap-up

IBM WebSphere


Don’t Forget: Consider the Whole EnvironmentOther 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

IBM WebSphere


Don’t Forget ApplicationsApplications need to be hardened against attack– See Application Hardening presentation

Applications might try to harm other applications– See Application Isolation presentation

IBM WebSphere


Non IT Security IssuesFar 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 isn’t 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., “Don’t give someone your password if they ask.”

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

IBM WebSphere


FAQ: What about a Security Proxy?Tivoli Access Manager (TAM) is an example of a good security proxyDoes 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

IBM WebSphere


FAQ: Operating System HardeningIBM 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

IBM WebSphere


IBM provides several tools to helpIBM 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

WAS V6.1 provides a “security report”– Basically a list of your configuration, provided with v6.1

Newin 6.1

http://www.ibm.com/support/docview.wss?uid=swg24006797

IBM WebSphere


ReferencesWebSphere 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.html

Securing connections between WebSphere Application Server and WebSphere MQPart 1 – http://www-128.ibm.com/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.htmlPart 2 (SIBus to MQ via MQ Link) - http://www-128.ibm.com/developerworks/websphere/techjournal/0601_smithson/0601_smithson.html

http://www.redbooks.ibm.com/

http://www-128.ibm.com/developerworks/websphere/techjournal//0512_botzum/0512_botzum1.html



IBM WebSphere


Appendix

IBM WebSphere


So you think you don’t need security?We still occasionally encounter those that claim they don’t 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.

IBM WebSphere


What about Process Server? – First ThoughtsEverything in this presentation applies, plusSCA 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 aren’t “true” EJBs that

– You can’t use EJB constraints as there are no real EJB methods– You likely can’t 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 tosecure those in the usual manner – E.g., web services authentication (WS-Security or transport), plus EJB authorizationHuman tasks use the Staff registry for making authorization decisions, not the user’s authenticated Subject– Custom group information in subject will be ignored

IBM WebSphere


What about Process Server? – First ThoughtsWBI adapters communicate with SIBus – you’ll 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 don’t 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• Rules• Processes• Human task administration• CEI• etc

IBM WebSphere


What about Process Server? – First ThoughtsCEI event store – to a DataSource– Assumes authentication data is defined on resource – can’t protect from

illegal access

IBM WebSphere


Visa’s Recommended Standardshttp://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

http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf

http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf

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 IBM’s 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.

Documents

0611 Botzum WAS 60 Security Hardening