Steps and information to configure properly the security features on was 8.5....
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
IBM Software Group | WebSphere software
Change is the Only Constant This presentation reflects – Our current opinions regarding WAS security – The product itself continues to evolve (even in fix packs) • Presentation is based on WAS V7, V8 and V8.5 – This will be revised as we learn more
Fixed in V8.5
Fixed in V8
– Your thoughts and ideas are welcome
– Disclaimer: Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Scope – WebSphere Application Server (WAS) V7 thru 8.5 Distributed (Unix, Linux and Windows) • Previous versions are not discussed – There are significant additional issues in previous versions Liberty V8.5 – Includes 8.5 Liberty Profile details – WAS on other platforms is similar, but not covered here – Web Services Security specific issues are not covered
Materials may not be reproduced in whole or in part without the prior written permission of IBM
3
IBM Software Group | WebSphere software
WHY HAVE SECURITY?
A secure infrastructure protects your system from unwanted intrusions. WAS is one key part of that infrastructure. We are going to discuss how to secure WAS.
WAS isn't the only infrastructure component you need to secure. Identify and document all of the threats you wish to protect yourself from. Many are internal. Materials may not be reproduced in whole or in part without the prior written permission of IBM
4
IBM Software Group | WebSphere software
Potential Intrusions People and systems with IP connectivity to your network – Outsiders on the Internet – Insiders on your Intranet
• •
In many ways more dangerous as they have knowledge, access, and possibly a grudge Several sources state that the majority of attacks are internal – Even if you trust everyone in your building (a dangerous assumption) are you also certain they are all computer security experts? > What about email/browser exploits that serve as entry points to the company network? > What about “free” software that includes dangerous code? > What about your employees inserting unknown CDs or USB keys into your computers?
WAS provides a robust infrastructure for addressing most of these challenges…. with some assembly required.
Materials may not be reproduced in whole or in part without the prior written permission of IBM
5
IBM Software Group | WebSphere software
Table of Contents
Introduction Hardening – High Importance Hardening – Medium Importance Hardening – Low Importance Other Considerations
Materials may not be reproduced in whole or in part without the prior written permission of IBM
6
IBM Software Group | WebSphere software
Basic Topology
Materials may not be reproduced in whole or in part without the prior written permission of IBM
7
IBM Software Group | WebSphere software
Attack on multiple levels Network - subvert network level protocols by altering traffic, or just looking at traffic with confidential information Machine - leverage machine access to see and modify what they 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
IBM Software Group | WebSphere software
Secure By Default WAS V6.1 has greatly improved security hardening along several key dimensions – Secure by default
• • •
Administrative security is on by default Most subsystems default automatically to a reasonable level of authentication, authorization, and encryption This presentation will discuss areas where you may want to improve on the defaults
– Certificates are automatically generated and managed by default
This presentation ASSUMES you accepted the defaults during the initial configuration – If you have changed the initial configuration without careful consideration, you may have weakened security – If you have migrated a cell to WAS V6.1 or later from a previous version, the cell does NOT assume the latest security defaults – it remains as (in)secure as it was before the migration! This is a particular concern when migrating from releases prior to V6.1 where there were significant weaknesses
Materials may not be reproduced in whole or in part without the prior written permission of IBM
9
IBM Software Group | WebSphere software
Administrative Security and the Liberty Profile Traditional Profile based on remote administrative model. Admin Console wsadmin JMX Multiple JVMs in cell, NodeAgents, DMgr
V8.5 Liberty Profile based on local OS file access.
Liberty V8.5
Remote admin access is enabled via JMX Connector features
• •
localConnector-1.0 requires “remote” access application to run on same server, under same OS userid. restConnector-1.0 requires ssl-1.0 and appSecurity-1.0. − Without an admin user defined, connector cannot authenticate and connect to Liberty server.
All Profiles: R/W Local OS file access enables complete admin control.
10
IBM Software Group | WebSphere software
Priority Order The hardening slides are organized in rough priority order – High
•
Items that should be addressed in all production environments – Failure to address them is very dangerous • Notice that many significant issues from previous release are gone! – Medium
•
Items that should be addressed in any environment where security is taken seriously – Low
•
There are real risks here but they are obscure and difficult for a hacker to leverage > Some reasonable people will ignore these issues > Highly sensitive systems should address these as well – Many of the issues raised are judgment calls, so carefully consider your own requirements and security policies
Materials may not be reproduced in whole or in part without the prior written permission of IBM
11
IBM Software Group | WebSphere software
Agenda
Introduction Hardening – High Importance Hardening – Medium Importance Hardening – Low Importance Other Considerations
Materials may not be reproduced in whole or in part without the prior written permission of IBM
12
IBM Software Group | WebSphere software
Use Firewalls - The “Standard” Configuration MQ S erver A pplication S erver
W eb S erver
A pplication S erver w ith ME
I, W
MQ W, M
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
Materials may not be reproduced in whole or in part without the prior written permission of IBM
NMEI 13
IBM Software Group | WebSphere software
(3) Do not put On Demand Router in the DMZ ODR is a full Java environment Proxy it with Web Server Alternative: use DataPower SOA Appliance with Application Optimization (AO) feature
NMEI 14
IBM Software Group | WebSphere software
(4) Use HTTPS from the Browser If your site performs any authentication or has any confidential information then configure your Web server to support HTTPS – For maximum protection you should use SSL for all pages in an application that has ANY sensitive information
• •
An intruder might even be able to modify web page content for public pages which could also confuse your users This is because an intruder might be able to capture cookies sent in the clear (before or after login) and then act as that user • This attack has been demonstrated at public WiFi access points
Configuring/Enforcing – Refer to your Web 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
IBM Software Group | WebSphere software
(5) Keep Up to Date with Patches and Fixes The IBM Support Website provides you with information on Security-related Updates – http://www.ibm.com/software/webservers/appserv/was/support/ – http://www.ibm.com/support/mysupport
Several ways to monitor updates
• • •
Subscribe to IBM Flashes via “Request Email Updates” Monitor updates by subscribing to an RSS Feed “News Feeds of New Content” By monitoring the security bulletins – http://www01.ibm.com/support/docview.wss?rs=180&uid=swg21368398
– By reading the websphere security zone – http://www.ibm.com/developerworks/websphere/zones/was/security/ – 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
Materials may not be reproduced in whole or in part without the prior written permission of IBM
16
IBM Software Group | WebSphere software
(6) Enable Application Security Enable application security so that applications can leverage Java EE security
– Experience shows that very few applications can develop their own custom authentication mechanism successfully – most are laughably insecure – It is not necessary to enable Java 2 security
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
17
IBM Software Group | WebSphere software
Enabling application security in Liberty
Liberty V8.5
appSecurity-1.0
18
IBM Software Group | WebSphere software
(7) Use ldapRegistry instead of quickStartSecurity or the basicRegistry Liberty V8.5
V8.5 Liberty Profile includes two trivial security registry configurations ideal for development environments. They should not be used beyond basic integration testing environments.
19
IBM Software Group | WebSphere software
(8) Restrict Access to WebSphere MQ Messaging Two ways to connect WAS to MQ – Bindings Mode • No built in fine grained authentication, relies on process level authentication • Userid/password info specified on JMS resource is ignored • All that matters is that the process id that WAS runs as has access to MQ – should be in the appropriate MQ group, etc. – Client/Server Mode (remote TCP access) • By default, does not perform any user authentication – totally insecure! • Userid/password info specified on JMS resource is passed to MQ but ignored by default by MQ
To ensure that there is meaningful authentication of the MQ connection – Custom security exits for client authentication. These exits can access the userid/password information on the connection. – A simpler approach is to implement custom MQ authentication using SSL client authentication, and to ensure that MQ only trusts the certificate possessed by WAS
See MQ SSL presentation or the paper on securing WAS/MQ links in references section Warning: These changes are only discussing how to secure the WAS to MQ link. These do not “make MQ secure.” Significant work is required to secure MQ. Contact ISSW for help.
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
20
IBM Software Group | WebSphere software
(9) Harden the Web Server and Host Your Web Server might be running in the DMZ – the first point for external connections, so – Harden the operating system; limit other running processes – Harden the Web server
• • •
Limit the Web server modules being loaded Review the Web server configuration; minimise the opportunity for attack Consider limiting the SSL strength allowed - e.g., do you want to allow 40-bit export quality encryption? Consider using FIPS 140-2 or SP800-131 compliant ciphers (see #38) • Refer to Apache hardening book in references – Ensure that the WAS plugin is configured to only forward traffic for the right applications (if WAS generates the plugin-cfg.xml file this should happen naturally)
WAS 6.0 and later can manage Web servers as part of a cell – Two options
• •
Managed Node – a regular Node Agent collocated with Web server (likely in the DMZ) IHS Admin Server – Both approaches increase the attack surface – Not recommended for use in a DMZ for a production environment (although convenient for a test environment)
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
21
IBM Software Group | WebSphere software
(10) Remove JREs from Web Servers in DMZ Remove the JREs installed when installing the Web server and the Web server plugin – You won’t be able to run the patch installer or ikeyman (both depend on Java) – Zip/tar up these JREs just in case
22
IBM Software Group | WebSphere software
(11) Harden the Proxy Host Harden whatever is in the DMZ – Maybe your Web server 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
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
23
IBM Software Group | WebSphere software
Beware Proxy or Web Server Bypass Web servers may perform security critical action such as certificate authentication Proxy servers provide many useful functions Authentication Authorization Auditing Custom headers over HTTP that applications can leverage (maybe)
Unfortunately, there is a trust gap in the architecture WAS Web Container Proxy Browser
HTTPS
Authn Authz Audit Add Headers
user misc headers HTTPS
Web Server
user misc headers
TAI
HTTPS
Application - get User Identity - get Headers
Potential Trust Gap What prevents bypass?? Evil Client
user misc headers
HTTPS
Materials may not be reproduced in whole or in part without the prior written permission of IBM
24
IBM Software Group | WebSphere software
Proxy Server Bypass - Real World Example
25
IBM Software Group | WebSphere software
Proxies and Web Server Bypass If I can connect directly to the web server or web container I can potentially seriously breach system security Bypassing proxy auditing and authorization dangers If proxy auditing 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
IBM Software Group | WebSphere software
A Proxy Bypass Example The user accesses an application via the proxy and authenticates E.g., https//proxy.ibm.net/EasyApp
The proxy authenticates the user, - builds an authentication header, and authorizes the user for EasyApp Request is securely sent to the Web Container. The identity is asserted after confirming it travelled through the proxy server. An LtpaToken2 cookie for *.ibm.net is returned The attacker now bypasses the proxy directly accessing the Web Container or Web Server https://wasserver.ibm.net/RestrictedApp or https://webserver.ibm.net/RestrictedApp
•
Webserver of course blindly forwards headers onto wasserver Because there is an LtpaToken2 cookie, request is allowed Notice that proxy authorization and auditing on this next request has been bypassed Notice that proxy headers the application uses could be forged
Note: virtual hosts do not help at all with this The attacker can set the $WS* headers to trick the web container that the request was sent to proxy.ibm.net:80
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
27
IBM Software Group | WebSphere software
Client Certificate Authentication Bypass Risk When a web application is configured to accept client certificate authentication, a vulnerability is opened – Certificate information comes via the SSL handshake if web client connects directly to web container – Certificate information comes from web server if it fronts web container (thus terminating SSL connections)
•
Certificate description is actually in hidden HTTP headers sent to web container
How does WAS know if the client sending certificate description really is the trusted web server? It 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
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
28
IBM Software Group | WebSphere software
Bypass Prevention Firewalls Typically a firewall will prevent access from the internet to the web server and web container What about users on the internal network? You should have internal firewalls as well
•
What about legitimate administrators? − How many people have legitimate access to your production network? Firewalls are a good first line of defense, but may not be sufficient
• • •
Number of people with access to the production network may be large Difficult to validate that the configuration remains correct over time Make a mistake and you are silently insecure
Thought question: is there really a security perimeter? Only good guys are inside and only bad guys are outside? What about attacks that compromise the browsers of your trusted admins on the inside?
Materials may not be reproduced in whole or in part without the prior written permission of IBM
29
IBM Software Group | WebSphere software
Bypass Prevention Preventing bypass using transport tricks Configure every web server to listen only to proxy server IP address and every web container to listen only to web server IP address Configure every web server to require mutual SSL and trust only proxy server certificates and configure every web container to require mutual SSL and trust only web server certificates
• •
Extremely difficult to configure (see appendix) Additional issues as with previous item But, previous approaches are problematic
• • •
May prevent legitimate access to web server or web container – what about internal web services or REST calls? How do you keep current the trusted server information as you add new web servers and proxy servers Are difficult to configure and leave you laughably insecure if you make a mistake, e.g., − If I forget to limit the trusted IPs (or add one I 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
IBM Software Group | WebSphere software
Detecting Bypass Detecting bypass at web container is the “best” option Verify that request really did come from trusted web server or proxy server While may be complicated to configure, if configuration is wrong, system will fail rather than being insecure
For authentication must verify trust path during authentication step WAS calls TAIs automatically at that point
•
A proper TAI will create a trusted identity which is good for applications that use JEE security If using certificate authentication to the web server, 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
IBM Software Group | WebSphere software
Detecting Bypass – More Details Two suggested approaches for trust path verification (there are others) Verify a secret password that is part of the request
•
This is what the WebSEAL TAI does Use certificate authentication and authorize the request based upon the certificates
Leverage WAS specific APIs to look at the certificate used to connect
to the web container and JEE APIs to see the certificate used to connect to the web server http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic =/com.ibm.websphere.express.doc/info/exp/ae/csec_trust.html Authorize request if direct certificate used to connect to web container is on trusted list If authenticating end user using certificates, then JEE provided certificate is end 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
IBM Software Group | WebSphere software
(12) Detecting Bypass - Configure and Use TAIs Carefully Trust Association Interceptors (TAIs) extend the trust domain – They must be carefully designed and carefully deployed
•
Make sure you understand the implications of configuring and using a TAI
– Mistakes result in serious security weaknesses
•
Weak point is usually server to server trust – how does TAI know caller is server trusted to assert identity information
Bad Examples – 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
IBM Software Group | WebSphere software
(13) Use certificate authentication carefully Revocation You must plan for WHEN not IF a private key is compromised. Without revocation, there is only One way to stop the use of a compromised key.
• •
Use a different CA – and reissue/distribute all certificates. $$$$ Online Certificate Status Protocol (OCSP)
•
Not supported by V8.5 Liberty servers. Certificate Revocation List
Liberty V8.5
Self-Signed certs.
Web Authentication trust risk SSL is point-to-point. If SSL is terminated by Web Server, certificate details flow from Plugin to WAS via unverified headers ($WSCC). See item #14. If SSL is terminated at Web Container, see next chart.
34
IBM Software Group | WebSphere software
How to Disable trust of unverified certificate headers. If SSL clients authenticate directly to Web client, Liberty:
Liberty V8.5
Full Profile
35
IBM Software Group | WebSphere software
(14) Authenticate Web Servers to Web Container Scenarios: User is authenticated at Web Server or other proxy User identity flows via “custom” header
•
Also applies to SSL Client Auth to Web Server
Mitigation: Use SSL Client Auth to Web Container (Direct Connection Peer)
•
(New 7.0.0.7) HTTP request attribute com.ibm.websphere.ssl.direct_connection_peer_certificates • Confirm only authorized SSL Direct connections Peers Use SSL Tunnel with Self-signed certs.
36
IBM Software Group | WebSphere software
(15) 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
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
37
IBM Software Group | WebSphere software
(16) Choose an Appropriate Process Identity The WAS processes must run under some Operating System identity, so 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
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
38
IBM Software Group | WebSphere software
Choose an Appropriate Process Identity Option #2: Node Agent as root and application servers under different OS identities – Assign separate OS user accounts for each application server
•
Can limit access to files not owned by that application server (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
IBM Software Group | WebSphere software
Choose an Appropriate Process Identity Option #3: Everything as a Normal user – Default, out of the box configuration if you install as non-root – no configuration required
• •
Easy to configure post install if you did the install as root Simple chmod/chown of the WAS files and you are on your way – All Application Servers must run under the same, non-privileged OS user as the Node agent – The OS user needs read/write access to WAS directories. All WAS processes have equal read/write access to WAS directories. – WAS administrators don't have root access
Variation of this option – Could run node agents with different userids
•
Then all applications on those nodes will share that common userid, but different nodes can have different userids • Could even run multiple node agents on a single machine – 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
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
40
IBM Software Group | WebSphere software
Options Summary – Choose Run as non-root User All as root Node as user root
All as nonroot
WAS admins have implicit root authority
Some WAS admin tasks may require root access 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
IBM Software Group | WebSphere software
(17) Protect Your Configuration Files & Private Keys There are numerous files in a typical WAS install that need to be protected because of what they contain – The configuration repository XML files under config – contain topology information and many embedded passwords (e.g., LDAP, databases, enterprise systems, etc) • Note 1: As of WAS 6.0.2, clients can write their own custom password module to encrypt them (see Programming Hints & Tips presentation) • Note 2: VMM file repository stores password hashes, not the passwords – Lots of key stores containing the private keys for every node and Web server – The LTPA encryption keys – with this I can forge LTPA credentials and act as anyone – sas.client.props or soap.client.props - files may contain a userid and password – installedApps – files for applications that have been installed. 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!
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
42
IBM Software Group | WebSphere software
(18) Encrypt LDAP Link The Application Servers, Node Agents and Deployment Manager communicate with LDAP – Each send user passwords, including Admin passwords, to LDAP for verification – Queries lots of information which may be sensitive
To protect this link – Create a new trust store for LDAP at the global scope
•
WAS needs to be able to complete the SSL handshake so it needs the signer certificate for the LDAP server or the certificate itself • Put into the trust store either the LDAP 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
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
43
IBM Software Group | WebSphere software
Specifying SSL Configuration for LDAP
NMEI Materials may not be reproduced in whole or in part without the prior written permission of IBM
44
IBM Software Group | WebSphere software
Encrypting LDAP connections in Liberty ssl-1.0
Liberty V8.5
