WebSphere Application Server 8.5 Security Hardening

IBM Software Group
WebSphere Application Server

Version 7, 8, 8.5 Security: Infrastructure Hardening
Sept 2012
Martin Lansche, Senior Management Consult ant

lansche@ca.ibm.com
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
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

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

Table of Contents

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

Basic Topology

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

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

11
Agenda

Introduction

12
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

NMEI
13
(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
(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
NMEI
15
(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

16
(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
17
Enabling application security in Liberty
Liberty V8.5
<featureManager>
<feature>appSecurity-1.0</feature>
</featureManager>
18
(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
(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
20
(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
21
(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
(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
23
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

24
Proxy Server Bypass - Real World Example
25
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
26
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
27
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
28
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?

29
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
30
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
31
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
32
(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
EI
33
(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
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
(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
(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
37
(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
38
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

NMEI
39
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
40
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.
41
(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
42
(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
43
Specifying SSL Configuration for LDAP
NMEI
44
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
Agenda

Introduction

46
(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/>

47
(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
48
(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
49
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

NMEI
50
(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
(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
(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

53
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
54
(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
55
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
56
Administrative Roles
First Administrative User
AdminSecurityManager
Administrator
Deployer
Partial
iscadmins
Configurator
Auditor
Edit Security
Edit Audit
Partial
Operator
Partial
Monitor
57
(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
58
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
(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
60
(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
61
Encrypting the DCS Link
NMEI
62
(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
MEI
63
(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

64
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
Agenda

Introduction

66
(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
67
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

68
Personal Certificate Fingerprint in WAS

69
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

70
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
71
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
72
(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
73
(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.

Fixed
in some
V7 Fixpack
74
(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
75
(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
76
(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
77
Transports on a Typical Application Server

78
(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
(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

80
(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
81
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
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
83
Agenda

Introduction

84
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

85
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

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

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

88
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

89
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

90
Futures
Nothing here is an IBM commitment

91
Appendix

92
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

NMEI
93
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

NMEI
94
Exchanging Signers with Web Plugin Key Store

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

96
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.
97
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

98
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

99
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

10
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

10
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

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

10
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

10
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

10
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

10
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?"

10
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

10
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

10
V7: disabling password cache

11
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

11

WebSphere Application Server 8.5 Security Hardening

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

WebSphere Application Server 8.5 Security Hardening

Încărcat de

Drepturi de autor:

Formate disponibile

IBM Software Group

WebSphere Application Server

Martin Lansche, Senior Management Consult ant

IBM Software Services for WebSphere

last update:June 12, 2013

IBM Software Group | WebSphere software

WebSphere Security Presentation Series

IBM Software Group | WebSphere software

Change is the Only Constant

Your thoughts and ideas are welcome

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

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

IBM Software Group | WebSphere software

WHY HAVE SECURITY?

A secure infrastructure protects

WAS isn't the only infrastructure component you need

IBM Software Group | WebSphere software

In many ways more dangerous as they have knowledge, access, and

WAS provides a robust infrastructure for addressing most of

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

IBM Software Group | WebSphere software

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

IBM Software Group | WebSphere software

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

IBM Software Group | WebSphere software

Attack on multiple levels

The type of attack(s) that a measure defends

IBM Software Group | WebSphere software

Administrative security is on by default

Certificates are automatically generated and managed by default

This presentation ASSUMES you accepted the defaults during the

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

IBM Software Group | WebSphere software

Administrative Security and the Liberty Profile

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

Remote admin access is enabled via JMX Connector features

localConnector-1.0 requires remote access application to run on

IBM Software Group | WebSphere software

Items that should be addressed in all production environments

Items that should be addressed in any environment where security is

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

IBM Software Group | WebSphere software

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

IBM Software Group | WebSphere software

Use Firewalls - The Standard Configuration

(1) Two firewall DMZ

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

IBM Software Group | WebSphere software

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

IBM Software Group | WebSphere software

(4) Use HTTPS from the Browser

IBM Software Group | WebSphere software

(5) Keep Up to Date with Patches and Fixes

Several ways to monitor updates

Subscribe to IBM Flashes via Request Email Updates

By reading the websphere security zone

Keep up to date with all your infrastructure components

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

IBM Software Group | WebSphere software

(6) Enable Application Security

IBM Software Group | WebSphere software

Enabling application security in Liberty

IBM Software Group | WebSphere software

(7) Use ldapRegistry instead of quickStartSecurity or the