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 [email protected] Keys Botzum, formerly Senior Technical Staff Member © 2012 IBM Corporation

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

last update:June 12, 2013

IBM Software Group | WebSphere software

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

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

2


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

Fixed in V8.5

Fixed in V8

– Your thoughts and ideas are welcome

– Disclaimer: Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Scope – WebSphere Application Server (WAS) V7 thru 8.5 Distributed (Unix, Linux and Windows) • Previous versions are not discussed – There are significant additional issues in previous versions Liberty V8.5 – Includes 8.5 Liberty Profile details – WAS on other platforms is similar, but not covered here – Web Services Security specific issues are not covered

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

3


WHY HAVE SECURITY?

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

WAS isn't the only infrastructure component you need to secure. Identify and document all of the threats you wish to protect yourself from. Many are internal. Materials may not be reproduced in whole or in part without the prior written permission of IBM

4


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.


5


Table of Contents

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


6


Basic Topology


7


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.

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

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

8


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


9


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



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

H

S ession & S IB DB

J

J

H F W B row ser

F W

A pplication S erver

J W

S

L

N ode A gent N ode W eb S ervices

A pp DB

L W

I

LD A P D eploym ent M anager

L

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

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

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


17


Enabling application security in Liberty

Liberty V8.5

appSecurity-1.0

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.


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)


21


(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

22


(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


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

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


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


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

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

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

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

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:

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


37


(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


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

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


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

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


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


43


Specifying SSL Configuration for LDAP


44


Encrypting LDAP connections in Liberty ssl-1.0

Liberty V8.5

45


Agenda



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


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

48


(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

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


49


Don’t 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//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 user’s 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


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

Liberty V8.5

Multiple principals can be bound to that role.


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


56


Administrative Roles First Administrative User AdminSecurityManager

Administrator

Deployer Partial

iscadmins

Configurator

Auditor

Edit Security

Edit Audit

Partial

Operator

Partial

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

57


(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


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:

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


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


61


Encrypting the DCS Link


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) – Microsoft’s SQLServer driver supports it - http://msdn.microsoft.com/enus/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 N WAS Materials may not be reproduced in whole or in part without the prior written permission of IBM

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

To set httpSession cookie

There is no equivalent to set all cookies in Liberty.

65


Agenda



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


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


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


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

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


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


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


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

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

82


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


83


Agenda



84


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


85


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


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


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


NMEI 93


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


NMEI 94


Exchanging Signers with Web Plugin Key Store


95


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.


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

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


10


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


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

Recommend Documents