IBM Software Group

WebSphere Application Server

Version 7, 8, 8.5 Security: Infrastructure Hardening
Sept 2012

Martin Lansche, Senior Management Consult ant

[email protected]
Keys Botzum, formerly Senior Technical Staff Member
2012 IBM Corporation

IBM Software Services for WebSphere

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

last update:June 12, 2013

IBM Software Group | WebSphere software

WebSphere Security Presentation Series

This presentation is part of the WebSphere Security Presentation
Series formerly led by Keys Botzum with help from so many others
Available internally at
http://pokgsa.ibm.com/~lansche/documents/securitySeries

Related presentations
We assume youve seen or are familiar with

Core Concepts
Key, Certificate, and SSL Management
Security Introduction
You may be interested in

Firewalls
Hardening MQ SSL Configuration
Application Isolation
Application Hardening
Cross Cell SSO
Service Integration Bus
PCI Considerations
WPS Security Overview
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

IBM Software Group | WebSphere software

Change is the Only Constant

This presentation reflects
Our current opinions regarding WAS security
The product itself continues to evolve (even in fix packs)
Presentation is based on WAS V7, V8 and V8.5
This will be revised as we learn more

Fixed
in V8.5

Fixed
in V8

Your thoughts and ideas are welcome

Disclaimer: Information regarding potential future products is intended to outline our

general product direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment,
promise, or legal obligation to deliver any material, code or functionality. Information
about potential future products may not be incorporated into any contract. The
development, release, and timing of any future features or functionality described for our
products remains at our sole discretion.

Scope
WebSphere Application Server (WAS) V7 thru 8.5 Distributed (Unix, Linux and Windows)
Previous versions are not discussed
There are significant additional issues in previous versions
Liberty V8.5
Includes 8.5 Liberty Profile details
WAS on other platforms is similar, but not covered here
Web Services Security specific issues are not covered

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

IBM Software Group | WebSphere software

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.
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

IBM Software Group | WebSphere software

Potential 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
Even if you trust everyone in your building (a dangerous assumption)
are you also certain they are all computer security experts?
> What about email/browser exploits that serve as entry points to the
company network?
> What about free software that includes dangerous code?
> What about your employees inserting unknown CDs or USB keys
into your computers?

WAS provides a robust infrastructure for addressing most of

these challenges. with some assembly required.

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

IBM Software Group | WebSphere software

Table of Contents

Introduction
Hardening High Importance
Hardening Medium Importance
Hardening Low Importance
Other Considerations

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

IBM Software Group | WebSphere software

Basic Topology

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

IBM Software Group | WebSphere software

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. Not covered in
this presentation.

The type of attack(s) that a measure defends

against is highlighted on the relevant slides

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

IBM Software Group | WebSphere software

Secure By Default

WAS V6.1 has greatly improved security hardening along several
key dimensions
Secure by default

Administrative security is on by default

Most subsystems default automatically to a reasonable level of
authentication, authorization, and encryption
This presentation will discuss areas where you may want to improve on the
defaults

Certificates are automatically generated and managed by default

This presentation ASSUMES you accepted the defaults during the

initial configuration
If you have changed the initial configuration without careful consideration,
you may have weakened security
If you have migrated a cell to WAS V6.1 or later from a previous version, the
cell does NOT assume the latest security defaults it remains as (in)secure
as it was before the migration! This is a particular concern when migrating
from releases prior to V6.1 where there were significant weaknesses

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

IBM Software Group | WebSphere software

Administrative Security and the Liberty Profile

Traditional Profile based on remote administrative model.

Admin Console

wsadmin

JMX

Multiple JVMs in cell, NodeAgents, DMgr

V8.5 Liberty Profile based on local OS file access.

Liberty V8.5

Remote admin access is enabled via JMX Connector features

localConnector-1.0 requires remote access application to run on

same server, under same OS userid.
restConnector-1.0 requires ssl-1.0 and appSecurity-1.0.
Without an admin user defined, connector cannot authenticate
and connect to Liberty server.

All Profiles:

R/W Local OS file access enables complete admin control.

10

IBM Software Group | WebSphere software

Priority Order

The hardening slides are organized in rough priority order
High

Items that should be addressed in all production environments

Failure to address them is very dangerous
Notice that many significant issues from previous release are gone!
Medium

Items that should be addressed in any environment where security is

taken seriously
Low

There are real risks here but they are obscure and difficult for a hacker to
leverage
> Some reasonable people will ignore these issues
> Highly sensitive systems should address these as well
Many of the issues raised are judgment calls, so carefully consider your own
requirements and security policies

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

11

IBM Software Group | WebSphere software

Agenda

Introduction
Hardening High Importance
Hardening Medium Importance
Hardening Low Importance
Other Considerations

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

12

IBM Software Group | WebSphere software

Use Firewalls - The Standard Configuration

MQ
S erver
A pplication
S erver

W eb
S erver

A pplication
S erver w ith
ME

I, W

MQ
W, M

S ession &
S IB
DB

H
F
W
B row ser

F
W

A pplication
S erver

J
W

N ode
A gent
N ode
W eb
S ervices

A pp
DB

L
W

LD A P
D eploym ent
M anager

H
W

(1) Two firewall DMZ

E JB

No WAS in the DMZ
C lient

(2) Firewall protecting production from intranet

See Firewall presentation for more

FW

w sadm in

A dm in
B row ser

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

NMEI
13

IBM Software Group | WebSphere software

(3) Do not put On Demand Router in the DMZ

ODR is a full Java environment

Proxy it with Web Server

Alternative: use DataPower SOA Appliance with Application
Optimization (AO) feature

NMEI
14

IBM Software Group | WebSphere software

(4) Use HTTPS from the Browser

If your site performs any authentication or has any confidential
information then configure your Web server to support HTTPS
For maximum protection you should use SSL for all pages in an application that has
ANY sensitive information

An intruder might even be able to modify web page content for public pages which
could also confuse your users
This is because an intruder might be able to capture cookies sent in the clear
(before or after login) and then act as that user
This attack has been demonstrated at public WiFi access points

Configuring/Enforcing
Refer to your Web servers documentation for instructions
Popular web browsers ship with 100s of pre-trusted CA certificates. Youll likely 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

Testing

Go to www.ssllabs.com

Select Server Test and input your website
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

NMEI
15

IBM Software Group | WebSphere software

(5) Keep Up to Date with Patches and Fixes

The 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
By monitoring the security bulletins
http://www01.ibm.com/support/docview.wss?rs=180&uid=swg21368398

By reading the websphere security zone

http://www.ibm.com/developerworks/websphere/zones/was/security/
Weve been collecting the most significant recent vulnerabilities in this
presentation and they are at the end

Keep up to date with all your infrastructure components

Operating Systems, LDAP, Database, Web Server etc not just
WAS

NMEI

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

16

IBM Software Group | WebSphere software

(6) Enable Application Security

Enable application security so that applications can leverage Java EE security

Experience shows that very few applications can develop their own custom
authentication mechanism successfully most are laughably insecure
It is not necessary to enable Java 2 security

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

17

IBM Software Group | WebSphere software

Enabling application security in Liberty

Liberty V8.5

<featureManager>
<feature>appSecurity-1.0</feature>
</featureManager>

18

IBM Software Group | WebSphere software

(7) Use ldapRegistry instead of quickStartSecurity or the

basicRegistry
Liberty V8.5

V8.5 Liberty Profile includes two trivial security registry

configurations ideal for development environments.

They should not be used beyond basic integration testing
environments.

19

IBM Software Group | WebSphere software

(8) Restrict Access to WebSphere MQ Messaging

Two ways to connect 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 MQ 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 MQ SSL presentation or the paper on securing WAS/MQ links in

references section

Warning: These changes are only discussing how to secure the WAS to
MQ link. These do not make MQ secure. Significant work is required to
secure MQ. Contact ISSW for help.

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

20

IBM Software Group | WebSphere software

(9) Harden the Web Server and 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
Harden the Web server

Limit the Web server modules being loaded

Review the Web server configuration; minimise the opportunity for attack
Consider limiting the SSL strength allowed - e.g., do you want to allow 40-bit export quality
encryption? Consider using FIPS 140-2 or SP800-131 compliant ciphers (see #38)
Refer to Apache hardening book in references
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 and later can manage Web servers as part of a cell
Two options

Managed Node a regular Node Agent collocated with Web server (likely in the DMZ)
IHS Admin Server
Both approaches increase the attack surface
Not recommended for use in a DMZ for a production environment (although convenient for a test
environment)

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

21

IBM Software Group | WebSphere software

(10) Remove JREs from Web Servers in DMZ

Remove the JREs installed when installing the Web server and the
Web server plugin
You wont be able to run the patch installer or ikeyman (both depend on
Java)
Zip/tar up these JREs just in case

22

IBM Software Group | WebSphere software

(11) 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
Harden the proxy
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

Best bet for Web services proxy: DataPower

Hardened, application solution

Purpose built operating system not a general computing device,
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!!
Note: WAS V7 proxy is not a replacement for DataPower with Web
Services no XML threat protection

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

23

IBM Software Group | WebSphere software

Beware Proxy or Web Server Bypass

Web servers may perform security critical action such as
certificate authentication

Proxy servers provide many useful functions

Authentication

Authorization

Auditing

Custom headers over HTTP that applications can leverage (maybe)

Unfortunately, there is a trust gap in the architecture

WAS Web Container
Proxy
Browser

HTTPS

Authn
Authz
Audit
Add Headers

user
misc headers
HTTPS

Web
Server

user
misc headers

TAI

HTTPS

Application
- get User Identity
- get Headers

Potential Trust Gap

What prevents bypass??
Evil
Client

user
misc headers

HTTPS

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

24

IBM Software Group | WebSphere software

Proxy Server Bypass - Real World Example

25

IBM Software Group | WebSphere software

Proxies and Web Server Bypass

If I can connect directly to the web server or web container I can
potentially seriously breach system security

Bypassing proxy auditing and authorization dangers

If proxy auditing isnt done what are the implications?

Does the application do sufficient authorization independently of the proxy?

Perhaps it would be best if applications repeat authorizations done by

proxy

Forging HTTP headers can be done easily using any browser and a
graphical plugin such as Tamper Data. I could then

Forge certificate information by sending it directly to web container if web
server is performing certificate authentication (see next slide)

Possibly trick applications by falsifying proxy or web server provided headers

Do your applications look at HTTP headers to make security decisions?

How do you know that an evil HTTP client hasnt specified forged
values for those headers?

Possibly act as someone other than myself by falsifying identity information
provided by proxy or web server

How do your applications determine identity?

If they use a TAI, is it configured securely?
If they examine HTTP headers, see previous point
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

26

IBM Software Group | WebSphere software

A Proxy Bypass Example

The user accesses an application via the proxy and authenticates

E.g., https//proxy.ibm.net/EasyApp

The proxy authenticates the user, - builds an authentication

header, and authorizes the user for EasyApp

Request is securely sent to the Web Container. The identity is
asserted after confirming it travelled through the proxy server.

An LtpaToken2 cookie for *.ibm.net is returned

The attacker now bypasses the proxy directly accessing the Web
Container or Web Server

https://wasserver.ibm.net/RestrictedApp or
https://webserver.ibm.net/RestrictedApp

Webserver of course blindly forwards headers onto wasserver

Because there is an LtpaToken2 cookie, request is allowed

Notice that proxy authorization and auditing on this next request has
been bypassed

Notice that proxy headers the application uses could be forged

Note: virtual hosts do not help at all with this

The attacker can set the $WS* headers to trick the web container that the
request was sent to proxy.ibm.net:80

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

27

IBM Software Group | WebSphere software

Client Certificate Authentication Bypass Risk

When a web application is configured to accept client certificate
authentication, a vulnerability is opened
Certificate information comes via the SSL handshake if web client connects
directly to web container
Certificate information comes from web server if it fronts web container (thus
terminating SSL connections)

Certificate description is actually in hidden HTTP headers sent to web

container

How does WAS know if the client sending certificate description

really is the trusted web server?

It doesnt!!!! Danger!!!

If using certificates for direct connections to the web container

Disable trusted assertion of information by setting trusted property to
false on Web Container custom properties

Note that this means you cannot authenticate to a web server using
certificates and expect that information to propagate

If you have a web server and use client certificate authentication to it, read on

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

28

IBM Software Group | WebSphere software

Bypass Prevention

Firewalls

Typically a firewall will prevent access from the internet to the web server and
web container

What about users on the internal network?

You should have internal firewalls as well

What about legitimate administrators?

How many people have legitimate access to your production network?

Firewalls are a good first line of defense, but may not be sufficient

Number of people with access to the production network may be large

Difficult to validate that the configuration remains correct over time
Make a mistake and you are silently insecure

Thought question: is there really a security perimeter?

Only good guys are inside and only bad guys are outside?

What about attacks that compromise the browsers of your trusted admins on
the inside?

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

29

IBM Software Group | WebSphere software

Bypass Prevention

Preventing bypass using transport tricks

Configure every web server to listen only to proxy server IP address and
every web container to listen only to web server IP address

Configure every web server to require mutual SSL and trust only proxy
server certificates and configure every web container to require mutual
SSL and trust only web server certificates

Extremely difficult to configure (see appendix)

Additional issues as with previous item

But, previous approaches are problematic

May prevent legitimate access to web server or web container what

about internal web services or REST calls?
How do you keep current the trusted server information as you add
new web servers and proxy servers
Are difficult to configure and leave you laughably insecure if you
make a mistake, e.g.,
If I forget to limit the trusted IPs (or add one I shouldnt) system
is wide open
If I leave open an HTTP transport or add too many signers to
the trust store system is wide open
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

30

IBM Software Group | WebSphere software

Detecting Bypass

Detecting bypass at web container is the best option

Verify that request really did come from trusted web server or proxy
server

While may be complicated to configure, if configuration is wrong, system
will fail rather than being insecure

For authentication must verify trust path during authentication

step

WAS calls TAIs automatically at that point

A proper TAI will create a trusted identity which is good for

applications that use JEE security

If using certificate authentication to the web server, youll need a custom
TAI to verify the certificate authentication trust path (see next slide)

For HTTP header usage, audit bypass, and authorization bypass,

EVERY single request must verify trust path

This will require custom application code

If only concerned about HTTP headers, my preference is to ban the use
of HTTP headers by applications

Find another way to get same information

Perhaps collect during TAI execution or query from LDAP
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

31

IBM Software Group | WebSphere software

Detecting Bypass More Details

Two suggested approaches for trust path verification (there are
others)

Verify a secret password that is part of the request

This is what the WebSEAL TAI does

Use certificate authentication and authorize the request based upon the
certificates

Leverage WAS specific APIs to look at the certificate used to connect

to the web container and JEE APIs to see the certificate used to
connect to the web server
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic
=/com.ibm.websphere.express.doc/info/exp/ae/csec_trust.html
Authorize request if direct certificate used to connect to web
container is on trusted list

If authenticating end user using certificates, then JEE provided
certificate is end users certificate. A TAI could use this as the
users idenity

If validating trust path from proxy, then JEE provided certificate
is proxys certificate and you can authorize request based upon
this
Refer to programming hints and tips for more
ISSW has an asset that demonstrates how to do the above
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

32

IBM Software Group | WebSphere software

(12) Detecting Bypass - 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

Bad 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 laughably insecure

Long ago deprecated WebSEAL TAI can be configured insecurely if you are not careful

Do you understand how to do this properly?

mutualSSL=true
Property on TAI means assume that HTTP input is completely trusted and do no
validation
Not supported by the newer TAMPlus TAI since most people got this wrong
Password authentication (verifies AUTHORIZATION header userid & password)
If no loginId property specified then ANY valid userid and password combination
is assumed to be a trusted server!
Loginid mandatory with the newer TAMPlus TAI
NM
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

EI

33

IBM Software Group | WebSphere software

(13) Use certificate authentication carefully

Revocation

You must plan for WHEN not IF a private key is compromised.

Without revocation, there is only One way to stop the use of a
compromised key.

Use a different CA and reissue/distribute all certificates.

$$$$

Online Certificate Status Protocol (OCSP)

Not supported by V8.5 Liberty servers.

Certificate Revocation List

Liberty V8.5

Self-Signed certs.

Web Authentication trust risk

SSL is point-to-point.

If SSL is terminated by Web Server, certificate details flow from Plugin to
WAS via unverified headers ($WSCC). See item #14.

If SSL is terminated at Web Container, see next chart.

34

IBM Software Group | WebSphere software

How to Disable trust of unverified certificate headers.

If SSL clients authenticate directly to Web client,

Liberty:
<webcontainer trusted=false/>

Liberty V8.5

Full Profile

35

IBM Software Group | WebSphere software

(14) Authenticate Web Servers to Web Container

Scenarios:

User is authenticated at Web Server or other proxy

User identity flows via custom header

Also applies to SSL Client Auth to Web Server

Mitigation:

Use SSL Client Auth to Web Container (Direct Connection Peer)

(New 7.0.0.7) HTTP request attribute

com.ibm.websphere.ssl.direct_connection_peer_certificates
Confirm only authorized SSL Direct connections Peers

Use SSL Tunnel with Self-signed certs.

36

IBM Software Group | WebSphere software

(15) 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, such as
Snoop reveal a wealth of
information about your
production environment

When creating a profile for
production, uncheck the samples

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

37

IBM Software Group | WebSphere software

(16) 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
Node Agent as Root/Privileged User, Application Servers as Normal User
Everything as Normal User

Option #1: Everything as Root/Privileged User

Default, out of the box configuration if installed by root 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
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

38

IBM Software Group | WebSphere software

Choose an Appropriate Process Identity

Option #2: Node Agent as root and application servers under different OS
identities
Assign separate OS user accounts for each application server

Can limit access to files not owned by that application server (doesnt address
application servers running multiple applications)

Node agent must run as root (or root-like) OS user in order to start application servers

Read & write privileges for the configuration data

WAS administrators have implicit root authority because they can ask the node
agent to start any application server as any user

Can use LocalOS registry by using WAS_UseRemoteRegistry property

Difficult to configure

What do you do about the WAS configuration files?

Application servers need to read access to most of this and its shared

People often choose this in order to isolate applications it doesnt work!!

WAS is managed as single trust domain

Has almost no meaningful impact on security
Using WAS JMX APIs malicious applications can easily circumvent these
restrictions (in fact running the node agent as root makes this worse!)

Can be useful for application server level accounting by OS identity

Materials may not be reproduced in whole or in part without the
prior written permission of IBM

NMEI
39

IBM Software Group | WebSphere software

Choose an Appropriate Process Identity

Option #3: Everything as a Normal user
Default, out of the box configuration if you install as non-root no
configuration required

Easy to configure post install if you did the install as root

Simple chmod/chown of the WAS files and you are on your way
All Application Servers must run under the same, non-privileged OS user as
the Node agent
The OS user 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

Variation of this option

Could run node agents with different userids

Then all applications on those nodes will share that common userid, but
different nodes can have different userids
Could even run multiple node agents on a single machine
Doesnt scale well if you need lots of userids (one node agent per id per host)
Not a big fan of this, but it is workable in limited circumstances

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

40

IBM Software Group | WebSphere software

Options Summary Choose Run as non-root User

All as root Node as
user
root

All as nonroot

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

Application isolation cannot be addressed by operating system

permissions. Need Java 2 security and MUCH more. Refer to
application isolation materials.
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

41

IBM Software Group | WebSphere software

(17) 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 under config contain topology information and
many embedded passwords (e.g., LDAP, databases, enterprise systems, etc)
Note 1: As of WAS 6.0.2, clients can write their own custom password module to
encrypt them (see Programming Hints & Tips presentation)
Note 2: VMM file repository stores password hashes, not the passwords
Lots of key stores containing the private keys for every node and Web server
The LTPA encryption keys with this I can forge LTPA credentials and act as anyone
sas.client.props or soap.client.props - files may contain a userid 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

Start everything owned by WAS. Read/Write by no one else.
Grant read access selectively as needed such as to log files

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!

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

42

IBM Software Group | WebSphere software

(18) 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 a new trust store for LDAP at the global scope

WAS needs to be able to complete the SSL handshake so it needs the

signer certificate for the LDAP server or the certificate itself
Put into the trust store either the LDAP servers signing certificate or the
LDAP servers certificate
Create an SSL configuration for LDAP at the global scope

Define it to use the new trust store

Specify SSL enabled on the LDAP User Registry page 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
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

43

IBM Software Group | WebSphere software

Specifying SSL Configuration for LDAP

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

44

IBM Software Group | WebSphere software

Encrypting LDAP connections in Liberty

<featureManager>
<feature>ssl-1.0</feature>
</featureManager>
<ssl id="ldapSSLConfig" keyStoreRef="ldapTrustStore"
trustStoreRef="ldapTrustStore"/>

Liberty V8.5

<keyStore id="ldapTrustStore" location="ldapTrustStore.jks"

type="JKS" password="123456" />
<ldapRegistry id="IBMDiretoryServerLDAP"
realm="SampleLdapIDSRealm
host="host.domain.com" port=636" ignoreCase="true"
baseDN="o=domain,c=us"
ldapType="IBM Tivoli Directory Server"
idsFilters="myidsfilters"
sslEnabled="true
sslRef="ldapSSLConfig" />

45

IBM Software Group | WebSphere software

Agenda

Introduction
Hardening High Importance
Hardening Medium Importance
Hardening Low Importance
Other Considerations

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

46

IBM Software Group | WebSphere software

(19) Ensure LTPA Cookie Only Travels Over HTTPS

By default cookies are sent by the browser over HTTPS or HTTP

Given that the LTPAToken is rather sensitive, best to protect it

If stolen a third party intruder can act as that user until the token expires
Cookies support the attribute of secure which tells the browser to send the
cookie over HTTPS only

Note that there are other more subtle attacks related to this that are discussed in
the application hardening presentation

(7.0.0.9 required)

Liberty V8.5

<webAppSecurity ssoRequiresSSL=true/>

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

47

IBM Software Group | WebSphere software

(20) Replace LTPA Keys Periodically

By default, LTPA Keys are created once
and used forever

Good cryptographic practice requires that they
be changed from time to time

Regenerate them manually using the

Key Set Group functions on the
CellLTPAKeySetGroup

Warning: do not use the Automatically

generate keys option. This can cause issues

if you share keys with other cells or products
(such as DataPower)

Warning: the default setting for Automatically

generate keys has changed across release
and fixpack boundaries

More recent fixpacks automatic

generation is disabled.

No mechanism in Liberty to regenerate

LTPA keys.

Liberty V8.5
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

48

IBM Software Group | WebSphere software

(21) Dont Specify Passwords on the Command Line

WAS security runtime needs a password if security enabled

Can be obtained from standard in, a graphical prompt, properties, specified

programmatically, or provided on the command line

Do not specify passwords on the command line

Exposes password to anyone that can see process list on same machine

Exposes passwords to anyone that can look over your shoulder

Try to avoid specifying in a properties file unless you have no other choice

Notice what any non-root user can see!!!

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

49

IBM Software Group | WebSphere software

Dont Specify Passwords on the Command Line

Let WAS prompt!
WAS tools will automatically prompt (often graphically) as of 6.0.2 or later if password
not provided
Graphical prompt can be annoying when using command line tools

To force 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

Does not apply to Liberty Profile

Liberty V8.5

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

NMEI
50

IBM Software Group | WebSphere software

(22) Use more salt for File based VMM passwords

config/cells/<cellname>/fileregistry.xml contains one-way hashed
passwords with fixed salt.

WAS 8.0 allows you to specify how much salt to use.

Improves defense against brute force/rainbow table off-line
attacks.

This does not apply to the Liberty Profile

Liberty V8.5

51

IBM Software Group | WebSphere software

(23) Use longer key lengths for generated certificates

WAS 7.0 specify key lengths via wsadmin

WAS 8.0

specify key lengths via Admin console

Default key length now 2048

Key Lengths 512-16834 (multiples of 8)

This does not apply to Liberty profile

Liberty V8.5

52

IBM Software Group | WebSphere software

(24) Create Separate Administrative User IDs

WAS uses its own internal id for
internal communication

This id is not in the registry

Human beings need ids in the registry in order to authenticate to and manage WAS
The profile creation process ensures there is one root WAS admin user
Limit the use of this id

In particular, avoid sharing it among multiple people

Sharing the id makes audit information useless and weakens security significantly what if that ONE
password is compromised!!

NMEI

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

53

IBM Software Group | WebSphere software

Create Separate Administrative User IDs

Grant individual users administrative authorities to WAS

Create in your registry a user id (or use the users existing registry id)

Using the admin console

Specify additional
administrators as individuals
or as groups
Users and Groups >
Administrative User/Group
Roles
These are users/groups from
the underlying WAS registry

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

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

54

IBM Software Group | WebSphere software

(25) Take Advantage of Administrative Roles

WAS admin authority has several roles:
Monitor look, but not touch
Operator start/stop, but not change
Configurator configure, but not start/stop. Cant edit security configuration.
Administrator everything but AdminSecurityManager authority
AdminSecurityManager can grant users administrative authorities
(except audit) and can manage administrative authorization groups
Iscadmins can create users in federated repository
Deployer can modify and start/stop applications
Auditor can change auditing settings and grant auditor role, but not
anything else (separation of concerns!)

Liberty profile has a single admin role.

Liberty V8.5

Multiple principals can be bound to that role.

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

55

IBM Software Group | WebSphere software

Take Advantage of Administrative Roles

Ideally grant these roles to registry groups, not individual users
Then registry administrators (perhaps the security team) control who has
what authority to WAS

Now, you can limit administrative access based on need

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

Fine grained administration

By default administrative authorities are cell wide

You can limit authorities to particular nodes, servers, applications, clusters,

etc. via authorization groups
Supported by

Admin console and wsadmin in V7

Note: cell level Monitor authority is required to access admin console

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

56

IBM Software Group | WebSphere software

Administrative Roles
First Administrative User
AdminSecurityManager

Administrator

Deployer
Partial

iscadmins

Configurator

Auditor

Edit Security

Edit Audit

Partial

Operator

Partial

Monitor
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

57

IBM Software Group | WebSphere software

(26) Consider Encrypting 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 normally required after configuring Web server to use HTTPS and
copying updated plugin key file to Web server machine

By default, plug-in will use HTTPS to connect to application server only if Browser used
HTTPS

Exception: if sensitive data is generated in proxy or Web server and forwarded to

WAS, e.g., secret password is sent (WebSEAL sends a secret password)

Then you should encrypt that link for *all* traffic

To do this, just disable the

HTTP transport on Web

Container (forcing all traffic to
use HTTPS) and regenerate
the plugin-cfg.xml for the web
server

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

58

IBM Software Group | WebSphere software

Ensuring HTTPS only to Web Container in Liberty

Define httpEndpoint element in server.xml

Include httpsPort attribute

Do not include httpPort attribute

Liberty V8.5

Example:
<httpEndpoint id="defaultHttpEndpoint"
host="localhost"httpsPort="9443" />

59

IBM Software Group | WebSphere software

(27) Encrypt WebSphere MQ Messaging Connections

WebSphere MQ supports SSL between Queue Managers and from
clients when using MQ in client mode

See MQ SSL presentation or the paper on securing WAS/MQ in the
references

This does not apply to the V8.5 Liberty Profile

Liberty V8.5

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

60

IBM Software Group | WebSphere software

(28) Encrypt DCS 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

DCS always authenticates messages when admin security is

enabled, but maximize security by encrypting this link
For each Core Group, select a transport type of channel framework and
DCS-Secure as channel chain name

This does not apply to V8.5 Liberty Profile

Liberty V8.5

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

61

IBM Software Group | WebSphere software

Encrypting the DCS Link

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

62

IBM Software Group | WebSphere software

(29) Protect Application Server to Database Link

Most databases now provide for encrypted links from JDBC
clients to the database
DB2 UDB V8.2 supports encryption

http://www.ibm.com/developerworks/db2/library/techarticle/dm0806sogalad/?S_TACT=105AGY82&S_CMP=GENSITE
Internal link with step by step for WAS:
http://w3.ibm.com/connections/wikis/home?lang=en#/wiki/Jens%20Engelk
e/page/Using%20SSL%20with%20JDBC%20to%20communicate%20with
%20DB2
Oracle Advanced Security supports encryption (built into 10g)
DataDirect Sequelink driver supports encryption (with SQL Server)
Microsofts SQLServer driver supports it - http://msdn.microsoft.com/enus/library/bb879935%28v=SQL.100%29.aspx

If you cant swing DB encryption, protect this link as best as you

can
Use clever network routing to limit who can see packets

E.g., if WAS and DB are connected by switch in closed data center

network, seeing packets is not easy
Use VPN technology (such as IPSEC) to encrypt links between DB and
N
WAS
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

MEI
63

IBM Software Group | WebSphere software

(30) Consider Restricting LTPA Cookies to HTTP Only

With cross site scripting it is possible for an intruder to steal a
cookie (via javascript) and then use it maliciously

Stealing LTPA cookies is a pretty bad thing

WAS (7.0.0.9) added two separate features (via properties) that

support a browser specific feature (not all browsers support) to
block this attack vector

com.ibm.ws.security.addHttpOnlyAttributeToCookies=true

Sets LTPA cookies to HTTP Only

com.ibm.ws.webcontainer.httpOnlyCookies
Default
in V8

Comma separate list of cookie names (* for all)

Enabled by default in 8.0 and 8.5

HTTP Only cookies for use only as part of the http request stream,
making it unavailable to javascript

This might break some javascript intensive applications, so be careful

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

64

IBM Software Group | WebSphere software

V8.5 Liberty Profile HTTP Only support

These are the defaults - no action is required.

To set LTPA cookie
Liberty V8.5

<webAppSecurity httpOnlyCookies=true />

To set httpSession cookie

<httpSession cookieHttpOnly=true />

There is no equivalent to set all cookies in Liberty.

65

IBM Software Group | WebSphere software

Agenda

Introduction
Hardening High Importance
Hardening Medium Importance
Hardening Low Importance
Other Considerations

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

66

IBM Software Group | WebSphere software

(31) Think About Signer Importing Train Users

There may be numerous times when you have the option to import
or trust signer certificates. DO NOT!

At least not before validating them.

Examples:

Connecting with the administrative console to the secured port.

Connecting to WebSphere with wsadmin from a remote system.

Importing signers from a remote cell.

When you accept the signers, you are saying that you are willing
to trust that they are who they claim to be.

How can you accept their claim without validating they are in fact who they
say they are?

You can validate by verifying that the fingerprints are genuine

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

67

IBM Software Group | WebSphere software

Think About Signer Importing Train Users

Since version 6.1, WebSphere creates its self-signed (v6.1) or
chained certificates (v7.0 and later) for its nodes

This means that browsers will receive certificate warnings when connecting
to the administrative console.

This means clients can not talk to WebSphere unless they add the signers or
the certificates to the client trust store (<profileroot>/etc/trust.p12 by default).

WebSphere clients prompt to add certificates automatically

Just like Web browsers and SSH (this is risky unless you validate)

The user will be shown the fingerprint for the certificate and asked if it should
be trusted

You can find the fingerprint for a certificate in the WebSphere admin
console. Share that information with your users.

You can also import certificates into the server using the
Retrieve From Port option

Here again it is critical that you verify the fingerprint

At least this operation is controlled by administrators that (hopefully) know
better

NMEI

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

68

IBM Software Group | WebSphere software

Personal Certificate Fingerprint in WAS

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

69

IBM Software Group | WebSphere software

Client Signer Import

Users should be trained to verify that fingerprint!!!

$ ./wsadmin.bat
*** SSL SIGNER EXCHANGE PROMPT ***
SSL signer from target host localhost is not found in trust store
C:/IBM/WebSphere/AppServer/profiles/AppSrv02/etc/trust.p12
Here is the signer information (verify the digest value matches what is
displayed at the server):
Subject DN: CN=keysbotzum, O=IBM, C=US
Issuer DN: CN=keysbotzum, O=IBM, C=US
Serial number: 1151337276
Expires:
Tue Jun 26 11:54:36 EDT 2007
SHA-1 Digest:
53:43:75:86:A8:C3:55:15:98:35:54:E7:49:B7:15:AF:16:A9:53:6F
MD5 Digest: 29:36:B1:9C:22:5A:36:AD:78:B3:7E:FD:D3:B1:B4:19
Add signer to the trust store now? (y/n)
Alternatively, consider disabling this feature by editing ssl.client.props and set
this property
com.ibm.ssl.enableSignerExchangePrompt=false

NMEI

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

70

IBM Software Group | WebSphere software

Admin Browser Certificate Validation

WAS by default generates a certificate for the deployment manager node that
uses the deployment manager hostname

Certificate is still not issued by a trusted Certificate Authority

Connecting to the Administration Console will typically trigger this browser
warning

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

71

IBM Software Group | WebSphere software

Admin Browser Certificate Validation

To address the certificate trust problem

Option 1: use a well-known CA to issue WAS certificates

Expensive, must renew yearly

Option 2: accept the certificate on the first use as trusted after verifying the fingerprint

Train your administrators that if the

warning 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
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

72

IBM Software Group | WebSphere software

(32) Consider Limiting Sizes of HTTP Data

HTTP data size should be limited at your web server or firewall

Relying on WAS for DoS protection means the attack has already impacted your
network

However, you may wish to limit things in WAS as well

Maximum header field size

Maximum size in bytes for an HTTP header that can be included on an HTTP
request

Default is 32768 bytes

Maximum headers

Maximum number of headers that can be included in a single HTTP request

Default is 50

Limit request body buffer size

Maximum request body buffer size

Maximum size limit for the body of an HTTP request. If this size is exceeded, the
request is not processed.

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/c
om.ibm.websphere.nd.doc/info/ae/ae/urun_chain_typehttp.html
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

73

IBM Software Group | WebSphere software

(33) Limit trusted Signers

New issue
in V7

WAS defaults are quite good

Profiles created under early fixpacks of 7.0 included a DataPower signing certificate that signs
the default certificate used by every DataPower box is in cell level trust store by default.

Profiles created under later fixpacks do not have this certificate

Check your truststores, and KDB files. If there, remove it.

Carefully consider effects of adding other signers to your Cell truststores

Especially common CA signers.

Instead, define special purpose SSL Configuration - not a change to the Cell truststore.

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

Fixed
in some
V7 Fixpack

74

IBM Software Group | WebSphere software

(34) 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, cleartext will be used
Most likely scenario when
cleartext is in use would be a
misconfigured client

If you want to ensure that traffic is

encrypted; ensure that SSL is the
only acceptable option at
negotiation time

By default
in V8

Do this for outbound transport as well

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

75

IBM Software Group | WebSphere software

(35) Port Filtering

For connections that
use the Channel
Framework
(everything but IIOP)
you can limit who can
connect based on
host or IP
Set on the TCP
channel for
application server
ports

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

76

IBM Software Group | WebSphere software

(36) Disable Unused Ports

Basic principle of security hardening is to minimize the
potential attack surface, even when no known security issues
If a service isnt required, disable it

Potential candidates for disablement include

SIB_ENDPOINT_* - for the default messaging engine
Not started unless the messaging engine is enabled
SIB_MQ_* - for the messaging engine when connecting to MQ
Not started unless the messaging engine is enabled
WC_adminhost* - for administrative Web Browser access
Can be removed from the Web Container Transport Chain Configuration
Panel for servers that arent the Dmgr
These ports are routinely configured on new servers based on the default
template
However, in V7 and later they are disabled by default. Yea!
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
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

77

IBM Software Group | WebSphere software

Transports on a Typical Application Server

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

78

IBM Software Group | WebSphere software

(37) SSL Hostname verification.

MITM attacker can return a trusted cert that has different
hostname

Browsers verify hostname in Server SSL cert was expected
hostname.

Other SSL clients do not.

Susceptible to MITM attacks.

Can enable within a JVM via security custom property

com.ibm.ssl.performURLHostNameVerification=true

Affects ALL SSL connections.

Make sure you test carefully!!!

79

IBM Software Group | WebSphere software

(38) Consider Disabling 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

Until cache entry expires

Can authenticate with old password even if registry updated with new
password
Can still authenticate if account locked in registry
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
Beware: logins using passwords will be slightly slower
Could be an issue for stateless web services

NMEI

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

80

IBM Software Group | WebSphere software

(39) Consider Enabling FIPS 140-2 or SP800-131

Compliance

WAS can be forced to use FIPS 140-2 compliant cryptography for those
clients that require this checkbox
Specify FIPS in the admin console security panel
Specify FIPS in the ssl.client.props file

Warning - interoperability
For the old LTPAv1 token, the FIPS and non-FIPS crypto is not the same. Non-FIPS
LTPAv1 uses proprietary DES encryption and proprietary RSA signatures. FIPS
LTPAv1 uses the IBMJCEFIPS provider with "DESede/ECB/PKCS5Padding"
encryption and "SHA1withRSA" signatures.

Domino SSO token sharing will stop working with FIPS since it supports only LTPA
V1
In the future Domino will support LTPA V2

For the LTPA v2 token, both the IBMJCE or IBMJCEFIPS providers use
"AES/CBC/PKCS5Padding" encryption and "SHA1withRSA" signatures

References:
WAS doc
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websp
here.nd.doc/info/ae/ae/tsec_fips.html
JVM doc - http://www.ibm.com/developerworks/java/jdk/security/60/FIPShowto.html
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

81

IBM Software Group | WebSphere software

SP800-131 / Suite B

FIPS 140-2 is old standard

NIST updated to an even stronger SP800-131 standard

NSA defined own Suite B standard.

Both prohibit use of TLS 1.0 and TLS 1.1

WAS 7.0.0.23, 8.0.0.4, 8.5.0.0 add support

Transition Mode allows FIPS-120 and SP800-131

Strict Mode allows only SP800-131

Warning: All your clients must be able to support these restrictive
ciphers.

See Whats new in WAS 8.5 Security presentation for gory
details.

82

IBM Software Group | WebSphere software

Corner Cases: Weaknesses in WAS Security

HIDDEN

Certificate Authentication Limitations
By default, doesnt check that destination of request (hostname) is in fact
intended party (aka hostname verification)

In theory, subject to man in the middle attacks

However, not possible by default
WAS uses self-signed certificates and only accepts those thus
making this attack impossible
However, if you use CA issued certificates this could occur
Addressing if using CA issued certificates

Enable host name verification on trust manager

Custom property com.ibm.ssl.performURLHostNameVerification=true
> May need to be set as custom security property
Only applies for URL identified traffic
Generally doesnt help with IIOP or existing WAS internal
communication
Write custom trust manager to do more advanced checking

NMEI
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

83

IBM Software Group | WebSphere software

Agenda

Introduction
Hardening High Importance
Hardening Medium Importance
Hardening Low Importance
Other Considerations

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

84

IBM Software Group | WebSphere software

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

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

85

IBM Software Group | WebSphere software

Dont Forget

Firewalls
See Firewall presentation

Applications need to be hardened against attack

See Application Hardening presentation

Applications might try to harm other applications

See Application Isolation presentation

Cross Cell SSO Security Risks

Increases the size of the trust domain
See SSO Cross Cell presentation

Development Tools
Next slide

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

86

IBM Software Group | WebSphere software

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.

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

87

IBM Software Group | WebSphere software

Audit, audit, audit ...

Enforce your policies
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

http://www.darkreading.com/document.asp?doc_id=141002&f_src=darkre
ading_section_296
about 35 percent of workers routinely make a conscious decision to
break enterprise security policy because they want to expedite their
work or increase their own productivity.

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

88

IBM Software Group | WebSphere software

Audit, audit, audit ...

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

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

89

IBM Software Group | WebSphere software

References

WebSphere Security Presentation Series
http://pokgsa.ibm.com/~keys/documents/securitySeries

WebSphere Application Server V6.1 Security Handbook

SG24-6316-01 available from http://www.redbooks.ibm.com

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://www128.ibm.com/developerworks/websphere/techjournal//0512_botzum/0512_botzum1.html

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

Preventing Web Attacks with Apache, ISBN 0-321-32128-6

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

90

IBM Software Group | WebSphere software

Futures

Nothing here is an IBM commitment

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

91

IBM Software Group | WebSphere software

Appendix

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

92

IBM Software Group | WebSphere software

Limiting Web Container Access to Trusted Servers

Steps to create a secure trusted mutually authenticated SSL tunnel
Create new trust store that contains only the Web server plugins signers
Create a new SSL configuration
Configure it to use the new trust store and the usual default key store for that server
Configure it to require client authentication (Quality of Protection setting)
Disable Default Host transport chain on Web Container
Also disable admin host transports if they are there
Configure remaining SSL transport Chains on Web Container to use the new SSL
configuration
Ensure web plugin uses certificate when doing client authentication
The plugin uses the default certificate from the KDB file when performing client
authentication
Edit the CMS/KDB file used by the Web server plugin directly in the WAS config
directory using ikeyman to specify a default certificate (the admin console tools dont
support this)
This cant be set using the admin console
Warnings
Just enabling client authentication on the SSL configuration is usually not good enough
since the CellDefaultTrustStore probably contains too many signers!!
The certificate used by the plugin for authentication will expire. Plan accordingly!!
If you have any legitimate need for access to the web server (perhaps a server to
server call) it will now fail
If you make a mistake, the system is insecure

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

NMEI
93

IBM Software Group | WebSphere software

Limiting Web Server Access to Trusted Proxies

Steps to create a secure trusted mutually authenticated SSL tunnel
Web server specific, well assume IHS, but others are similar
Create new key store that contains only the proxys certificate

There can be no other trusted signers

Configure the web server to support HTTPS/SSL (create a virtual host)
Remove non-HTTPS listeners (e.g., remove port 80)
Require mutual SSL

Add SSLClientAuth required to SSL virtual host

Warning

If you have any legitimate need for access to the web server (perhaps a
server to server call) it will now fail
If you make a mistake, the system is insecure

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

NMEI
94

IBM Software Group | WebSphere software

Exchanging Signers with Web Plugin Key Store

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

95

IBM Software Group | WebSphere software

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 WAS admin 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 password authentication on WAS, then
to be logically consistent the same should be true for the operating systems.

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

96

IBM Software Group | WebSphere software

FAQ: Using CA Certificates vs WAS Built in Certs

If CA issued certs for WAS communcation (replacing the ones
WAS creates) are used there are a few considerations:

unrelated cells can now talk using SSL without additional configuration
required. This is good or bad depending on your goals.

since WAS does not do hostname verification when opening an SSL
request, using CA issued certs makes WAS more vulnerable to man in
the middle attacks. The risk is minor, but it is there.

there are cases (such as securing the link from the plugin to the app
server) where self signed certs MUST be used as documented in this
paper: http://www128.ibm.com/developerworks/websphere/techjournal//0512_botzum/0512
_botzum1.html. Refer to the SSL overview section and items #14 and
#15.

if CA issued certs are being used, you'll need to address certificate
revocation. While this is supported in WAS, configuration is not obvious.
Fortunately these certs are for server traffic so compromise (and thus the
need for revocation) is less likely, but the risk is still real.

Net: in general using CA issued certs for WAS traffic provides

little value and has a slight negative impact on security. While I do
not oppose using them I do not encourage their use.
Materials may not be reproduced in whole or in part without the
prior written permission of IBM

97

IBM Software Group | WebSphere software

FAQ: What About Earlier WAS Versions?

Many more issues because not secure by default
Refer to older version of this presentation or referenced white paper which is
for WAS V6

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

98

IBM Software Group | WebSphere software

FAQ: What about a Security Proxy?

Tivoli Access Manager (TAM) WebSEAL is an example of a good
security proxy

Does a security proxy 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 covered here

Does a security proxy make this any worse? maybe

In some ways, it will make it better with another layer of security
If implemented badly however a proxy can introduce vulnerabilities

Does a security proxy 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

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

99

IBM Software Group | WebSphere software

FAQ: Operating System Hardening

IBM WebSphere development does not test or recommend any
hardened operating system configurations
This includes SELinux: http://www01.ibm.com/support/docview.wss?uid=swg21264941

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

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

What Differences are There on iSeries?

WAS on i has never run under a privileged user profile, the WAS
runtime profile has no special authorities

Files (any in the install or profile) are automatically protected by default
(not accessible by 'non-super' users)

Scripts are 'locked down', meaning OS special authority is needed to
run most scripts (eg wsadmin) regardless of whether WAS security is
enabled

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

FAQ: What about Process Server?

Process Server has a number of components that have weak
default security configurations

You will need to take specific steps to harden WPS beyond the
steps discussed in this presentation

WPS Security presentation which is part of the security
presentation series

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

What about More Firewalls?

People often ask about putting firewalls within a WAS cell

Between a Dmgr and the nodes

Between nodes

WAS requires a network connection between all WAS components. If

there is a firewall along that connection it should be transparent to
WAS and as such not effect WAS operation. The Support Center will
accept WAS usage/defect-related service requests for WAS even when
there is a firewall implemented between WAS components. However,
during the trouble shooting process, IBM may require that the problem
be recreated without a firewall being in the flow between WAS
components to check if the problem is related to the implemented
firewall or not.

Note that WAS Support team will not provide assistance in
implementing a firewall between WAS components.

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

What about Wildcard Certificates?

Wildcard certificates can be shared by multiple servers

*.ibm.com is good for a.ibm.com, b.ibm.com, etc.

Is there a risk here?

Possibly, but its fairly subtle

Obviously if many different servers share the same private key that raises
a big risk

You dont have to share the same private key for every wildcard
certificate if your CA allows it

If DNS is compromised a request for a.ibm.com could be routed
b.ibm.com successfully even over SSL

It is conceivable that this could result in a security issue

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

FAQ: How do I Harden a System?

How do I think about attacks?

How do I look for potential holes?

I cant provide you with a good algorithm or approach
Fundamentally, I look at every access path in the system and ask myself
what if?

What if the client passes in the wrong information?

What if the client doesnt authenticate?
What if there is an error?
What if someone connects this other way?

The following slides contain a few bits of information on

hardening from other sources

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

Fundamental Principle of Hardening

That which is not explicitly permitted

is forbidden
Give the user (or service) the least
privilege required to perform a task

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

DREAD Table

"A DREAD table is a representation of threats used by Microsoft
Corp. and is here described in more detail:

Damage Potential - If this vulnerability is successfully exploited,
what is the worst that can happen?

Reproducibility - How easy is it to reproduce an attack on this
vulnerability?

Exploitability - How easy is it to attack based on this vulnerability?

Affected users - What percentage of users is likely to be affected
by this vulnerability?

Discoverability - How easy is it to find this vulnerability?"

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

Risk Analysis - Annualized Loss Expectancies

How do you determine what risks to focus on?
How can you justify the right level of expenditure on spending?

Single Loss
x
Expectancy (cost)

Expected Annual
=
Rate of Occurrences

Annualized Loss
Expectancy (cost/year)

Useful to compare potential losses with cost to mitigate

Useful as a prioritisation tool, although somewhat subjective
Exercise for the reader: to build a generic WAS specific analysis

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

Risk Analysis - Attack Trees

Attack Trees model the difficulty for an attacker to reach a given
goal

Assign Costs, Effort or Feasibility to each Leaf Node

Exercise for the reader: build a generic WAS specific analysis

Transfer funds
from an account

Obtain user
password

Hijack
user session

Modify
Source Code

Decrypt HTTPS
connection

Compromise
Web Server

Compromise
Application Server

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

10

IBM Software Group | WebSphere software

V7: disabling password cache

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

11

IBM Software Group | WebSphere software

Copyright IBM Corporation 2004-2013. All rights reserved.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corp., registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at Copyright and trademark information at
www.ibm.com/legal/copytrade.shtml

Materials may not be reproduced in whole or in part without the

prior written permission of IBM

11