WebSphere Application Server 8.5 Security Hardening

IBM Software Group

© 2012 IBM Corporation

WebSphere Application ServerVersion 7, 8, 8.5 Security: Infrastructure Hardening

Sept 2012

Martin Lansche, Senior Management Consult ant

[email protected]

Keys Botzum, formerly Senior Technical Staff Member

IBM Software Services for WebSpherehttp://www.ibm.com/WebSphere/developer/services last update:June 12, 2013

IBM Software Group | WebSphere software

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

WebSphere Security Presentation Series

� This presentation is part of the WebSphere Security PresentationSeries 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 you’ve 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



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

– 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

– Includes 8.5 Liberty Profile details

– WAS on other platforms is similar, but not covered here

– Web Services Security specific issues are not covered

Fixed

in V8.5

Fixed

in V8

Liberty V8.5



WAS isn't the only infrastructure component you need to secure. Identify and document all of the threats you wish to protect yourself from. Many are internal.

WHY HAVE SECURITY?

A secure infrastructure protects your system from unwanted intrusions. WAS is one key part of that infrastructure. We are going to discuss how to secure WAS.



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 shouldn’t

� External Application – legitimate and illegitimate users that leverage application level protocols (RMI/IIOP, HTTP, etc) to try to do things they shouldn’t be doing. These attacks usually require the least skill and are potentially the most dangerous.

� Internal Application Isolation - legitimate applications that try to get around application server and Java runtime restrictions. Not covered in this presentation.

N M E I

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



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)secureas it was before the migration! This is a particular concern when migrating from releases prior to V6.1 where there were significant weaknesses


10

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.

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

Liberty V8.5



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



Agenda




Use Firewalls - The “Standard” Configuration

Node

AppDB

LDAP

Session & SIBDB

ApplicationServer

Application Server with

ME

NodeAgent

Browser

W ebServer

ApplicationServer

W ebServices

EJB

Client

AdminBrowser

wsadmin

DeploymentManager

L

L

H

L

J

J

I

HW

W

W , M

I, W

H

S

W

MQServer

MQJ

FW

FW

FW

N M E I

�(1) Two firewall DMZ

� No WAS in the DMZ

�(2) Firewall protecting production from intranet

� See Firewall presentation for more


14

(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

N M E I



(4) Use HTTPS from the Browser

� If your site performs any authentication or has any confidentialinformation 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 server’s documentation for instructions

– Popular web browsers ship with 100s of ‘pre-trusted’ CA certificates. You’ll 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 N M E I



(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://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21368398

– By reading the websphere security zone– http://www.ibm.com/developerworks/websphere/zones/was/security/

– We’ve 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

N M E I



(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

N M E I


18

Enabling application security in Liberty

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

</featureManager>

Liberty V8.5


19

(7) Use ldapRegistry instead of quickStartSecurity or the basicRegistry

� V8.5 Liberty Profile includes two trivial security registry configurations ideal for development environments.

� They should not be used beyond basic integration testing environments.

Liberty V8.5



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

N M E I



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

N M E I


22

(10) Remove JREs from Web Servers in DMZ

� Remove the JREs installed when installing the Web server and the Web server plugin

– You won’t be able to run the patch installer or ikeyman (both depend on Java)

– Zip/tar up these JREs just in case



(11) Harden the Proxy Host

� Harden whatever is in the DMZ

– Maybe your Web server isn’t in the DMZ

• You are using an proxy server

• E.g., Tivoli Access Manager WebSEAL

– Standard operating system hardening applies

– 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

N M E I



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

Browser

ProxyAuthn

Authz

Audit

Add Headers

Web Server

WAS Web Container

TAI Application

HTTPS - get User Identity

- get Headers

HTTPSHTTPS

user misc headers

user misc headers

Evil Client

HTTPS

user misc headers

Potential Trust GapWhat prevents bypass??


25

Proxy Server Bypass - Real World Example



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 isn’t 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 hasn’t 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



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

N M E I



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 doesn’t!!!! 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

N M E I



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?



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 shouldn’t) system is wide open

− If I leave open an HTTP transport or add too many signers to the trust store system is wide open



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, you’ll 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



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 toconnect 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 providedcertificate is end user’s certificate. A TAI could use this as the user’s idenity

� If validating trust path from proxy, then JEE provided certificate is proxy’s 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



(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

– We’ve seen TAIs that validate the host name in the HTTP header as an indicator of “trust”

• Since headers can be trivially forged this is 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 N M E I


34

(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

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

Liberty V8.5


35

How to Disable trust of unverified certificate headers.

� If SSL clients authenticate directly to Web client,

� Liberty:

<webcontainer trusted=’false’/>

� Full Profile

Liberty V8.5


36

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



(15) Don’t Run Samples in Production

� WAS ships with several excellent samples which demonstrate various aspects of WAS and can serve as diagnostic tools

– Samples aren’t designed to be secure

– Some samples, such as Snoop reveal a wealth of information about your production environment

�When creating a profile for production, uncheck the samples

N M E I



(16) Choose an Appropriate Process Identity

� The WAS processes must run under some Operating System identity, so let’s 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

N M E I



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

– People often choose this in order to isolate applications – it doesn’t 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 N M E I



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

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

N M E I



Options Summary – Choose Run as non-root User

All as root user

Node as root

All as non-root

WAS admins have implicit root authority

Some WAS admin tasks may require root access

Can’t use Operating System Registry

Fairly complex file ownership/permission issues

Application isolation cannot be addressed by operating system

permissions. Need Java 2 security and MUCH more. Refer to

application isolation materials.



(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. User’s other than WAS shouldn’t 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

� Don’t put private keys on a shared file system

� Don’t share private keys between test and production environments

� Use caution when sending configuration files externally – they contain passwords!

N M E I



(18) Encrypt LDAP Link

� The Application Servers, Node Agents and Deployment Manager communicate with LDAP

– Each send user passwords, including Admin passwords, to LDAP forverification

– 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 server’s signing certificate or the LDAP server’s 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

N M E I



Specifying SSL Configuration for LDAP

N M E I


45

Encrypting LDAP connections in Liberty

<featureManager><feature>ssl-1.0</feature>

</featureManager><ssl id="ldapSSLConfig" keyStoreRef="ldapTrustStore"

trustStoreRef="ldapTrustStore"/>

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

Liberty V8.5



Agenda




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

<webAppSecurity ssoRequiresSSL=’true’/>

Liberty V8.5



(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



(21) Don’t 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

N M E I

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



Don’t Specify Passwords on the Command Line

N M E I

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

Liberty V8.5Does not apply to Liberty Profile


51

(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 ProfileLiberty V8.5


52

(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



(24) Create Separate Administrative User IDs

� WAS uses its own internal id for internal communication

– This id is not in the registry

N M E I

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



Create Separate Administrative User IDs

� Grant individual users administrative authorities to WAS

– Create in your registry a user id (or use the user’s existing registry id)

N M E I

� 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

� 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



(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. Can’t 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.

� Multiple principals can be bound to that role.

N M E I

Liberty V8.5



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

N M E I



First Administrative User

Administrative Roles

Administrator

Configurator Operator

Monitor

iscadmins

AdminSecurityManager

Partial

Edit Security Edit AuditDeployer

Auditor

PartialPartial



(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

N M E I

� 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


59

Ensuring HTTPS only to Web Container in Liberty

� Define httpEndpoint element in server.xml

� Include httpsPort attribute

� Do not include httpPort attribute

Example:<httpEndpoint id="defaultHttpEndpoint"

host="localhost"httpsPort="9443" />

Liberty V8.5



(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

N M E I

Liberty V8.5



(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

N M E I

Liberty V8.5



Encrypting the DCS Link

N M E I



(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/dm-0806sogalad/?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%20Engelke/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)

– Microsoft’s SQLServer driver supports it - http://msdn.microsoft.com/en-us/library/bb879935%28v=SQL.100%29.aspx

� If you can’t 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 WAS N M E I



(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) toblock this attack vector

� com.ibm.ws.security.addHttpOnlyAttributeToCookies=true

• Sets LTPA cookies to HTTP Only

� com.ibm.ws.webcontainer.httpOnlyCookies

• 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

Default

in V8


65

V8.5 Liberty Profile HTTP Only support

� These are the defaults - no action is required.

� To set LTPA cookie

<webAppSecurity httpOnlyCookies=’true’ />

� To set httpSession cookie<httpSession cookieHttpOnly=’true’ />

� There is no equivalent to set all cookies in Liberty.

Liberty V8.5



Agenda




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

N M E I



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

N M E I



Personal Certificate Fingerprint in WAS



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.p12Here is the signer information (verify the digest value matches what is displayed at the server):Subject DN: CN=keysbotzum, O=IBM, C=USIssuer DN: CN=keysbotzum, O=IBM, C=USSerial number: 1151337276Expires: Tue Jun 26 11:54:36 EDT 2007SHA-1 Digest: 53:43:75:86:A8:C3:55:15:98:35:54:E7:49:B7:15:AF:16:A9:53:6FMD5 Digest: 29:36:B1:9C:22:5A:36:AD:78:B3:7E:FD:D3:B1:B4:19Add 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=falseN M E I



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

N M E I



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

N M E I

�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



(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=/com.ibm.websphere.nd.doc/info/ae/ae/urun_chain_typehttp.html



(33) Limit trusted Signers� 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.

New issue

in V7

Fixed

in some

V7 Fixpack



(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

N M E I

Do this for outbound transport as well

By default

in V8



(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

N M E I



(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 isn’t 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 aren’t 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 you’ve added custom listener ports these might not be needed

• Can be removed from the Web Container Transport Chain Configuration Panel

N M E I



Transports on a Typical Application Server


79

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



(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 don’t work right because cached data is used rather than calling login modules

– This could result in bypass of the expected login process!!

– Password caching can be disabled by setting a JVM system property as follows:

• com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled

• Beware: logins using passwords will be slightly slower

– Could be an issue for stateless web servicesN M E I



(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.websphere.nd.doc/info/ae/ae/tsec_fips.html

– JVM doc - http://www.ibm.com/developerworks/java/jdk/security/60/FIPShowto.html


82

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 “What’s new in WAS 8.5 Security” presentation for gory details.



Corner Cases: Weaknesses in WAS Security

� HIDDEN� Certificate Authentication Limitations

– By default, doesn’t 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 doesn’t help with IIOP or existing WAS internal communication

• Write custom trust manager to do more advanced checking

N M E I



Agenda




Don’t 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



Don’t 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



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 isn’t going to help!

� Social Engineering

– If the humans in your business can be compromised, a lot of IT security become irrelevant

– Human beings routinely make bad security decisions

• You need firm and well understood security policies and strong enforcement

• E.g., “Don’t give someone your password if they ask.”



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=darkreading_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. …



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



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

� Securing connections between WebSphere Application Server and WebSphere MQ

– Part 1 – http://www-128.ibm.com/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.html

– Part 2 (SIBus to MQ via MQ Link) - http://www-128.ibm.com/developerworks/websphere/techjournal/0601_smithson/0601_smithson.html

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



Futures

� Nothing here is an IBM commitment



Appendix



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 plugin’s 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 configdirectory using ikeyman to specify a default certificate (the admin console tools don’t support this)

• This can’t 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

N M E I



Limiting Web Server Access to Trusted Proxies� Steps to create a secure trusted mutually authenticated SSL tunnel

– Web server specific, we’ll assume IHS, but other’s are similar

– Create new key store that contains only the proxy’s 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

N M E I



Exchanging Signers with Web Plugin Key Store



So you think you don’t need security?

� We still occasionally encounter those that claim they don’t need security because the production network is “secure”

� To this we ask the following question

– If you don't need 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.



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://www-128.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.



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



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


100

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

FAQ: Operating System Hardening

� IBM WebSphere development does not test or recommend any hardened operating system configurations

– This includes SELinux: http://www-01.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


101


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


102


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


103

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. Ifthere 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 implementedfirewall or not.

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



104


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 it’s fairly subtle

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

• You don’t 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


105


FAQ: How do I Harden a System?

� How do I think about attacks?� How do I look for potential holes?� I can’t 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 doesn’t 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


106


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”


107


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


108


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?

– 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

Single LossExpectancy (cost)

Expected AnnualRate of Occurrences

Annualized LossExpectancy (cost/year)

x =


109


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 fundsfrom an account

Obtain userpassword

Hijackuser session

ModifySource Code

CompromiseWeb Server

CompromiseApplication Server

Decrypt HTTPSconnection


110


V7: disabling password cache


111


© 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

WebSphere Application Server 8.5 Security Hardening

Documents

Transcript of WebSphere Application Server 8.5 Security Hardening