Post on 29-Nov-2014
transcript
IBM Software Group
© 2006 IBM Corporation
WebSphere Application ServerVersion 6 Security: Infrastructure Hardening
May 2006
Keys Botzum, Senior Technical Staff Memberkeys@us.ibm.com
IBM Software Services for WebSpherehttp://www.ibm.com/WebSphere/developer/services
last update: November 20, 2006
Cameron Martin, Senior IT Specialistcameron.martin@uk.ibm.com
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening2
WebSphere Security Presentation SeriesThis presentation is part of the WebSphere Security PresentationSeries led by Keys Botzum with help from so many others
– Available internally at http://pokgsa.ibm.com/~keys/documents/securitySeries
Related presentations– We assume you’ve seen or are familiar with
• Core Concepts• WAS Security Introduction• WAS Advanced Authentication (cross cell trust issues)
– You may be interested in• Application Isolation• Application Hardening• Hardening MQ SSL Configuration
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening3
Change is the Only ConstantThis presentation reflects– Our current opinions regarding WAS security– The product itself continues to evolve (even in Refresh Packs)– This will be revised as we learn more– Your thoughts and ideas are welcome
Scope– WAS 6.0.2 Distributed (Unix, Linux and Windows)
• Most information here applies to V5.0.x and V5.1.x as well• An introduction to the relevant changes in V6.1 is included• Extended Deployment and Programming Model Extensions are not
specifically covered– WAS on other platforms is similar, but not covered here– Web Services Security specific issues are not covered
Newin 6.0
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening4
WAS isn't the only infrastructure component you need to secure. Identify and document all of the threats you wish to protect yourself from. Many are internal.
WHY HAVE SECURITY?
A secure infrastructure protects your system from unwanted intrusions. WAS is one key part of that infrastructure. We are going to discuss how to secure WAS.
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening5
IntrusionsPeople 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• Email/browser exploits that serve as entry points to the company network
WAS provides a robust infrastructure for addressing most of these challenges…. with some assembly required.
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening6
AgendaIntroduction
SSL Overview
Infrastructure Preventative Measures
Advanced Considerations
Protecting your Desktop Environment
Wrap-up
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening7
SSL Overview
Trus
ted
Certificate Authority
GenerateServerKeys
Public Private
Public Private
Server Certificate
Public
Sign
CA Certificate
Public
ServerClient
Secu
re
Server Certificate
Public
EncryptedMessage
Public
Offline operations thatoccur before clientfirst contacts server
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening8
SSL “Authentication”Server side SSL authentication in brief– Server sends its certificate to client along with secret encrypted using its private key
(from key store)– Client validate the server’s certificate by checking its expiration date and signature– Signature is verified using signing certificate in trust store
• If certificate signature isn’t right, connection will be refused– Client side authentication is basically the same with the parties reversed
SSL authentication does not imply the system is secure!!– It merely validated that the certificate was acceptable
• Given plenty of signers (all known default CAs) SSL hasn’t really done much yet for us in terms of security
– Usually some later component uses the verified certificate to determine real identity of other party and then performs some form of authorization• E.g., browsers ensure that certificate subject name is same as host name of web
server• E.g., WAS maps certificates to J2EE user identities in registry
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening9
Limiting Connections to Trusted ClientsSometimes it is difficult to insert proper authorization into anexisting connection path– E.g. WAS does not provide for authorization of Web Server plugin
connections
If we limit the signers we trust on the server, we can limit theclients that can complete the SSL handshake– With self-signed certificates, there is only one signer– Hence, only one valid client side private key that can be used to connect– We can also limit the signers we trust on the client to ensure the client only
connects to the “right” servers
We can use this technique to limit connections to trusted clients– Several situations where this technique is useful that we’ll explore later
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening10
Implementing “Trusted” Tunnel with SSLUsing ikeyman (or built in certificate tools in V6.1)– Create two sets of key stores and trust stores
• Key store and trust store for client • Another key store and trust store for the server
– Remove all trusted signers from all stores (V6.1 trust stores are empty by default)• Now none can be used to validate any other certificate
– Create a self signed certificate in each key store
– Export the signing certificate from each key store and import into the trust store of the other party (client to server and server to client)• Now each trust store can be used to validate exactly one certificate – the one that
corresponds to the private key just created in the key store
Basically the same if have only a single key store on either side– Trust store and key store are the same file
– E.g., native KDB databases used by IBM HTTP Server and WAS Web Server plugin
Ensure client certificate authentication is enabled (server certauthentication is always on)
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening11
AgendaIntroduction
SSL Overview
Infrastructure Preventative Measures
Advanced Considerations
Protecting your Desktop Environment
Wrap-up
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening12
Basic Topology
Node
AppDB
LDAP
Session & SIBDB
ApplicationServer
Application Server with
ME
NodeAgent
Browser
WebServer
ApplicationServer
WebServices
EJB
Client
AdminBrowser
wsadmin
DeploymentManager
L
L
H
L
J
J
I
HW
W
W, M
I, W
H
S
W
MQServer
MQJ
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening13
Protocols UsedH = HTTP traffic – Usage: browser to web server, web server to app server, and admin web client– Firewall friendly
W = WAS internal communication– Usage: admin clients and WAS internal server admin traffic – Protocol:
• RMI/IIOP or SOAP/HTTP. Client protocol is configurable. • File transfer service (between node agent and DMgr) uses HTTP(S)• DCS (Distributed Consistency Service), RMM (Reliable Multicast Messaging). Private protocol.
– SOAP/HTTP firewall friendly if using SOAP/HTTP. DCS can be firewall friendly
I = RMI/IIOP communication– Usage: EJB clients (standalone and web container)– Firewall hostile
M = SIB messaging protocol– Usage: JMS client to messaging engine– Protocol: Proprietary– Firewall friendly as fixed ports can be used. Likely NAT firewall hostile.
Newin 6.0
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening14
Protocols UsedMQ = WebSphere MQ protocol– Usage: MQ clients (true clients and application servers)
– Protocol: Proprietary
– Firewall feasible (there are a number of ports to consider). Refer to MQ supportpac MA86.
L = LDAP communication– Usage: WAS verification of user information in registry
– Protocol: TCP stream formatted as defined in LDAP RFC
– Firewall friendly
J = JDBC database communication via vendor JDBC drivers – Usage: application JDBC access and WAS session DB access
– Protocol: Network protocol is proprietary to each DB.
– Firewall aspects depend on database (generally firewall friendly)
S = SOAP– Usage: SOAP clients
– Protocol: generally SOAP/HTTP
– Firewall friendly
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening15
Attack on multiple levelsNetwork - 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
N M E I
The type of attack(s) that a measure defendsagainst is highlighted on the relevant slides
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening16
The “Standard” Configuration with Firewalls
Node
AppDB
LDAP
Session & SIBDB
ApplicationServer
Application Server w ith
M E
NodeAgent
Browser
W ebServer
ApplicationServer
W ebServices
EJB
Client
Adm inBrowser
wsadm in
Deploym entManager
L
L
H
L
J
J
I
HW
W
W , M
I, W
H
S
W
M QServer
M QJ
FW
FW
FW
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening17
Put the Web Server in the DMZ without WASNothing in the DMZ but the Web Server– Very simple configuration, small attack surface– Stripped OS install with few tools– Follow the principles of least function and lowest complexity
Inbound network traffic from outside must be terminated in the DMZ– Network transparent load balancer is not sufficient
DMZ firewalls strictly limit traffic to– Allow only inbound HTTP(S) traffic on specific ports– Deny all outbound initiated traffic unless explicitly permitted by policy
The Application Servers and other components go behind a second firewall on a "production" subnet
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening18
Separate your Production Network from your IntranetProtect WAS against internal as well as external threats
Notice the third firewall between production subnet(s) and the corporate intranet– Web Administration Console will go through firewall if correct ports opened
– wsadmin will go through firewall if using SOAP and correct ports opened• Can configure firewalls to allow IIOP, just more difficult
Can take addition steps to further protect against internal network access; need to take additional steps will vary– Consider limiting access to Administrative functions (e.g. Web Administration
Console) to trusted VLANs or internal VPN
– Might even consider a full “internal DMZ”
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening19
What about Additional Firewalls?Every component (WAS, DB, Web server, LDAP) could get its own subnet using VLANs– Firewall between every subnet ("virtual" firewalls)
– Consider internal client connection and manageability issues• Complexity increases rapidly with diminishing value• Any firewalls that separate EJB clients from the WAS services need to be
IIOP friendly– We prefer to focus firewalls on traffic from “outside” of cell rather than trying
to block WAS internal traffic• In most cases we explicitly recommend against firewalls within a WAS cell
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening20
Beyond FirewallsFirewalls are a valuable component in an overall security plan, but they are not sufficient
Now that we have firewalls in place– Let’s continue to harden WAS from attack
– This list is in priority order
Just be systematic and patient
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening21
Enable Global SecurityEnable Administrative Security– Prior to v6.1 this was called “global security”– Most internal links are now encrypted and authenticated
• WAS internal communication (SOAP and RMI/IIOP) runs over SSL– Includes admin clients, EJB clients, and WAS internal communication– Even the WAS Web Administration Console switches to HTTPS
• Does not protect all network links, but most key ones – we’ll cover the rest soon
– Administrators will now be required to authenticate– Does not prevent network sniffing attacks until you change the default keys
WAS admin security is independent of application security– Enabling admin security makes WAS infrastructure secure – it is up to the
applications to explicitly leverage application security to secure themselves
WAS V5/V6.0 vs WAS V6.1• V5.x/V6.0 - global security enables admin and application security
• Application security was *disabled* by disabling "server security"• V6.1 - admin security enabled by default
• Performed as part of a standard installation by default• Application security is a separate configuration option N M E I
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening22
Use HTTPS from the Browser If your site performs any authentication or has any confidentialinformation then configure your web server to support HTTPS– Refer to your Web Server’s documentation for instructions
– Popular web browsers ship with around 50 odd ‘pre-trusted’ CA certificates. You’ll 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
You should use SSL for any confidential information - including LTPA Tokens, session IDs etc.
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening23
Configure Secure File TransferNode Agents retrieve configuration updates from the Deployment Manager using the File Transfer application– By default, no authentication (it is encrypted)
– System application, not normally visible in admin console
– Potential for attackers to upload arbitrary files; theoretically may be feasible to download certain files
To enable authentication, simply replace the existing File Transfer application with the secured version
WAS V6.1 uses the secured version by default– when Administrative Security is enabled
cd <profilehome>\binwsadmin.batwsadmin>source ../../../bin/redeployFileTransfer.jaclwsadmin>fileTransferAuthenticationOn <cellName> <dmgrName> dmgrwsadmin>$AdminConfig save
N M E I
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening24
Protect JNDI J2EE applications use JNDI to find other applications and resourcesToo many have too much access by default– By default anyone in your registry can destroy a cell
• Everyone – read• All Authenticated – read, write, create, delete
Recommended configuration– Allow everyone read only access
• Everyone – read• All Authenticated – nothing
– Applications that explicitly write to JNDI in application code will need to be granted access (rare)• WAS will ensure that its own components always have read/write access so core function (e.g. binding EJBs,
Datasources into the namespace) will continue to workSomewhat safer, but breaks some applications – not recommended– Everyone – nothing
– Unauthenticated threads (e.g, anonymous servlets) can’t read JNDI> MDBs can’t access JNDI> Local refs (e.g., java:comp/env) will not work> Applications must authenticate users or authenticate themselves using JAAS or RunAs
– All Authenticated – read
Permission are set in the admin console via Environment > Naming > CORBA Naming Service GroupsWAS V6.1 by default uses the above recommended configuration
N M E I
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening25
Ensure Meaningful Authorisation on Default MessagingOnce created, buses are too accessible by default– Anyone in your registry can perform any action against any destination
Configure a more appropriate subset of users using wsadmin, for example:
You’ll also need to ensure client components (MDBs, JMS) authenticate using an appropriate identity (userYouDetermine)
WAS V6.1 will by default require users and groups that are authorised to access the bus to be explicitly configured– No AllAuthenticated access by default
cd <profilehome>\binwsadmin.batwsadmin>$AdminTask removeGroupFromBusConnectorRole {-bus mySIB –group AllAuthenticatedwsadmin>$AdminTask addUserToBusConnectorRole {-bus mySIB –user userYouDetermine}wsadmin>$AdminConfig save
N M E I
Newin 6.0
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening26
Bus Security in V6.1 Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening27
Restrict Access to WebSphere MQ MessagingTwo ways to authenticate 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 mqm 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 MQTo 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 the URL for a paper on securing WAS-MQ connections at the end of these slides
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening28
Encrypt LDAP LinkThe 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 an SSL configuration for LDAP using Security > SSL > New JSSE repertoire
• WAS needs to posses certificate for CA/signer that issued LDAP certificate• Using ikeyman, add the LDAP signer certificate to the trust file used by the SSL
configuration that LDAP will be using – recommend creating a new SSL configuration specific to LDAP
• In V6.1 use admin console GUI to get certificate for LDAP server– Specify “SSL enabled” on the LDAP User Registry page in Security > Global Security >
User Registries > LDAP and choose the SSL configuration created earlier
If using a Custom User Registry, ensure this link is encrypted and authenticated – method will vary by User Registry
N M E I
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening29
Change the Default Key FileAll WAS internal SSL traffic (HTTP, SOAP, and IIOP) is based around the keys in the key files used by WAS. These are controlled by the SSL configurations.
By default, there is one SSL configuration shared by all of WAS and it is using a DummyKeyFile that shipped with product– Every user of WAS gets shipped the same private key. Not very private.
As appropriate, you need to create new SSL configurations with new key and trust files
In most cases to address the “Default Key” problem, sufficient to update the existing default SSL configurations that are shared by the WAS components (there are typically two in a cell)
• Create new key databases (key and trust) with new private key & certificate using ikeyman
• Update SSL config (Security > SSL > DefaultSSLSettings) to use the new key database
WAS V6.1 will generate a installation unique keys at time of installation -- no more DummyKeyFile.– More on following slides… N M E INew
in 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening30
Update all the Key Files – Pre WAS 6.1Don’t forget to update the related key files so everything will work
All nodes and the deployment manager have these files – each has its own <root>/etc directory, update them everywhere
The web server plugin needs to recognize the new server certificate. Update plugin-key.kdb. Make sure you update the one actually used by the web server (check plugin-cfg.xml).
WAS IIOP/SOAP clients– WAS admin clients are just IIOP/SOAP clients
– Update the client trust file with the signing cert
– Need to update the product *.client.props file to point to updated trust file• New Key file names and passwords• On *all* nodes and dmgr• Don’t forget remote clients
See next slide for WAS 6.1-specific info
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening31
Update all the Key Files – WAS 6.1WAS 6.1 will create unique certs and keyfiles for each profile out of the box– These are in PKCS12 format – key.p12 and trust.p12
For base profiles, these are created in the node dir of the configrepository
Upon federation to cell, the signer of these is added to the cell-wide trust store in the cell config directory
For the plugin, this is all managed for you, which removes a considerable admin task from previous versions in keeping the keystores in sync– All of this can be managed with the admin console
– Of course, we don’t recommend making the web server hosting the plugin a ‘managed node’, so manual copying of automatically generated keyfiles to plugin will likely still be necessary
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening32
Choosing a Certificate SignerHow you generate the new private key and certificate affects what you must update in the client trust files– Well known CA as signer
• CA cert it is probably already in the standard WAS client trust file• No update needed for client trust files (or plugin-key.kdb)• Must buy cert from CA and renew yearly
– Your own CA as signer or a self-signed certificate• Create a trust file for the client using ikeyman• Add the WAS or CA certificate as a signer• Create/update a sas.client.props or soap.client.props file for all of the clients• Saves money, but now you must distribute the keys to your clients
Generally self-signed certificates are best choice unless you have many Java clients– Self signed certificates are not less secure than CA issued, just harder to manage– Not much harder in V6.1 since Java client can import new signers if user allows New
in 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening33
Configure Certificates for Browser ValidationWith Global Security enabled, connecting to the Administration Console will typically trigger warnings in the Browser like these– Certificate not issued by a trusted Certificate Authority
– Site name does not match hostname
WAS V6.1 will by default generate a certificate that uses the deployment manager hostname– Certificate is still not issued by a trusted Certificate Authority N M E I
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening34
Configure Certificates for Browser ValidationTo address the certificate trust problem– Option 1: use a well-known CA to issue WAS’ certificates
• Expensive, must renew yearly– Option 2: simply accept the certificate in the browser on the first use as
trusted• Make sure it’s the right cert; recommend at least verifying the fingerprint
To address the site name not matching hostname problem– Obtain a certificate with the dmgr’s hostname as the subject to avoid browser
warnings about the name mismatch on every access
– Since the dmgr hostname can’t change this should not be a problem
Train your admins that if this message 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 attackN M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening35
Harden the Web Server HostYour Web Server might be running in the DMZ – the first point for external connections, so– Harden the operating system; limit other running processes– Limit the Web Server modules being loaded– Review the Web Server configuration; minimise the opportunity for attack– 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 introduces the ability to manage Web Servers as part of a cell– Two options
• Managed Node – a regular Node Agent collocated with web server (in the DMZ)• IHS Admin Server
– Both approaches increase the potential attack surface; not recommended for use in a DMZ for a production environment (although convenient for a test environment).
Remove the JDKs installed when installing the Web Server and the Plug-in– IHS installer leaves behind one JDK and the plug-In installer leaves behind two JDKs– Zip up these installations if required for later uninstallation or fixpacks– In WAS 6.1 only 2 JREs left behind, rather than the prior 3 JDKs
• One JRE for the plugin, one for the web server (if IHS)• These should still be archived and removed
N M E I
Newin 6.0
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening36
Harden the Proxy HostHarden 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– 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
– Even better, if you are using WebSEAL, use Tivoli AMoS (OS hardening) with WebSEAL• No charge option if using WebSEAL
Best bet for Web services proxy: DataPower• Hardened, application solution
– No spinning media, no true OS, 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!!
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening37
Don’t Run Samples in ProductionWAS 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, like showCfg and Snoop reveal a wealth of information about your production environment• Precisely the type of information you do not want to give a potential
attacker, so remove them or ensure that these applications are not started
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening38
Consider Authenticating Web Server to WAS LinkPlugin 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 required after configuring web server to use HTTPS and updating plugin key file to
contain correct signing certificate (the one you created earlier)• By default, plug-in will use HTTPS to connect to Application Server only if Browser used HTTPS• By default, the Application Server does not authenticate the Web Server. Usually this doesn’t
matter.
In some cases it is critical that you can limit Web Container access only to trusted Web Servers– If using client certificates (WAS is trusting Web Server to verify cert)– If using a Trusted Association Interceptor (TAI) that uses unverifiable information (e.g. only a userid
only is forwarded to TAI)– To limit Web Container access to trusted Web Servers
• Limit the Application Server to HTTPS transport (delete HTTP transport)• Update the Web Server plugin and web container key and trust files such that each can talk only
to the other using the “limiting connections to trusted clients” approach described earlier• Update SSL configuration used for HTTPS to require client authentication
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening39
Protect Your Configuration Files & Private KeysThere are numerous files in a typical WAS install that need to be protected because of what they contain– The configuration repository XML files in config – contain topology information and many embedded
passwords (e.g., LDAP, WAS root, databases, enterprise systems, etc)• Note: As of WAS 6.0.2, clients can write their own custom password module to encrypt them
(see programming hints & tips presentation)– etc/DummyServerKeyFile.jks (you will probably change the name of the file) - a JKS keystore
containing WAS' private key
– etc/plugin-key.kdb - web server's private key
– etc/plugin-key.sth - the password for access to the plugin-key.kdb.
– sas.client.props or soap.client.props - config file may contain a user UID 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– (usually) Make everything owned by WAS. Read/Write by no one else.
Don’t put private keys on a shared file system
Don’t share private keys between test and production environments
Use caution when sending configuration files externally – they contain passwords! N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening40
Configure and Use TAIs CarefullyTrust 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
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 completely insecure
– WebSEAL configuration• WebSEAL TAI is quite secure IF configured properly
– mutualSSL property on TAI means “assume that HTTP input is completely trusted and do no validation”> Did you configure a trusted HTTPS tunnel from WebSEAL to WAS?> Deprecated with new TAM WebSEAL TAI (aka TAMPlus TAI)
– Password authentication> If no loginId property specified ANY valid userid and password combination is assumed to
be a trusted server!
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening41
Use Only the New LTPA Cookie FormatThe WAS LTPA token prior to V5.1.1 has some theoretical weaknesses
– No known compromises
New token (as of WAS 5.1.1) uses stronger cryptographic techniques– Random salt
– Stronger ciphers
– All data is signed
– All data is encrypted
Old and new cookies supported simultaneously for compatibility with older WAS versions, WPS, Lotus Domino, TAM, etc.
– Can use only new format if all WAS 5.1.1 or greater – disable “Interoperability Mode” on Security > Global Security > Authentication Mechanisms > LTPA > Single Sign-on configuration panel
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening42
Use Only the New LTPA Cookie Format
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening43
Don’t Specify Passwords on the Command LineWAS security runtime needs a password if security enabled– Can be stdin, prompt, properties, or specified programmatically– Can specify userid & password on command line (usually –user & -password)
• Never do this. Exposes password to anyone that can see process list on same machine
WAS tools will prompt (often graphically) as of 6.0.2 or later if password not provided– Prior to 6.0.2 can force prompt by using RMI JMX connector
• –conntype RMI –port <bootstrap port>. – Bootstrap is usually 9809 on dmgr and 2809 for nodes. – Applies to most cmd line tools, including wsadmin. If you leave out port or there is an error, will silently fall
back to SOAP.– tperfviewer is special, use “./tperfviewer.bat localhost 9809 RMI”
– Installer bug makes this sometimes not work. If so, try this tech note: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rtrb_wsadminprobs.html
To use 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
– Beware that RMI is firewall hostile
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening44
Encrypt Default Messaging LinksDefault Messaging communicates over unencrypted links unless link encryption is configuredTo enforce the use of encrypted links at the server– For each application server, disable the InboundBasicMessaging transport – clients will
then only be able to use the InboundSecureMessaging transport
To enable a client to connect using the encrypted links– JMS clients need to specify the InboundSecureMessaging transport on the Connection
Factory panel– MDBs need to specify InboundSecureMessaging on the Activation specification panel
(new in 6.0.2)– Inter-ME communication within the bus needs to be configured to use
InboundSecureMessaging (on the main bus panel)– If Cross Bus communication is being used; configure this as the Inter-Engine transport
chain on the bus configuration panel
WAS V6.1 by default encrypts these links– So the following two slides are pre-WAS 6.1 config
N M E I
Newin 6.0
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening45
Disabling InboundBasicMessaging
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening46
Configuring a Connection Factory to use a Secure Transport
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening47
Encrypt WebSphere MQ Messaging LinksWebSphere MQ supports SSL between Queue Managers and from clients when using MQ in client mode
Specify the required SSL CIPHER SUITE property in WAS admin console on the MQ Connection Factory panel
See MQ SSL presentation or the paper on securing WAS/MQ links at the end of this presentation
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening48
Encrypt Distribution and Consistency Services LinkDistribution 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 Global Security is enabled, but maximise security by encrypting this link– For each Core Group, select a transport type of channel framework and
DCS-Secure as channel chain name
N M E I
Newin 6.0
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening49
Encrypting the DCS Link
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening50
Protect Application Server to Database LinkMany databases do not provide encrypted links from JDBC clients to the database, but this is changing for the better– DB2 UDB V8.2 supports encryption
– Oracle Advanced Security supports encryption
– DataDirect Sequelink driver supports encryption (w/ SQL Server)
If you can’t swing DB encryption, protect this link as best as you can– Inside your intranet. NEVER expose DB to internet.
– Use firewalls to protect production database from non-production networks
– Use clever network routing and/or firewalls to limit access to DB to "trusted" client machines
– Use VPN technology (such as IPSEC) to encrypt links between DB and WAS
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening51
Create Separate Administrative User IDsNeed a “root/Administrator" WAS user id in the WAS user registry (Server User ID)– Does not need administrative privileges in the registry. Certainly doesn’t need to be
root.– Used by WAS servers when authenticating internally– Should not be used by WAS administrators when authenticating– WAS V6.1 separates this into two identities
• Server user id – server to server stuff – not in registry, no password• WAS administrator – in user registry
Create a WAS user id account for each person that will administer the WAS domain– Create in your registry, then – Using the admin console
• Specify additional administrators: System Administration >Console Users/Groups. These are users/groups from the underlying WAS registry.
• Grant these users/groups CosNamingCreate, CosNamingDelete in CORBA namespace or they won’t be able to log into the admin console
As of WAS 5.0.2, 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 N M E I
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening52
Take Advantage of Administrative RolesWAS admin authority has 4 levels: – Monitor – look, but not touch
– Operator – start/stop, but not change
– Configurator – configure, but not start/stop. Can’t edit some “sensitive” data.
– Administrator - everything
Ideally use registry groups to represent these roles– Then registry admins (perhaps security team) control who has what authority to WAS
Now, you can limit administrative access based on need. This is valuable, for example:– 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
Access is cell wide. Split into multiple WAS cells to restrict access.
WAS V6.1 provides administrative isolation– Only available using the command line; does not apply to Admin Console
N M E INewin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening53
Administrative Roles
Administrator
Configurator Operator
Monitor
Sensitive Config
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening54
Warning: Trace VulnerabilityAny user with operator, configurator, or administrator role (but not monitor) can configure trace viewer in admin console to display contents of ANY file that WAS can read, including security.xml which contains passwords!!!
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening55
Choose an Appropriate Process IdentityThe WAS processes must run under some Operating System identity, so let’s discuss the choices– Everything as Root/Privileged User
– Everything as Normal User
– Node Agent as Root/Privileged User, Application Servers as Normal User
Option #1: Everything as Root/Privileged User– Default, out of the box configuration – no configuration required
– Can use local OS as user registry
– All WAS processes have read/write access to all WAS related files (and everything else)
– WAS administrators have implicit root authority
– Can configure so that nothing else (other than root) has access to WAS files
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening56
Choose an Appropriate Process IdentityOption #2: Node Agent as root– People often choose this in order to isolation applications by using operating systems permissions –
it doesn’t work!!• Does not achieve administrative and application isolation• WAS is managed as single trust domain
– Assign OS user accounts for app servers to limit access• “wasrun” - is the OS user that the app server "runs as"
– member of wasgroup– Can limit access to files not owned by that application server (doesn’t address shared application servers)– Read & write privileges solely for application server profile(s)
– Node manager runs as the root (or root-like) OS user• Read & write privileges for the application server profile(s) plus Node Agent profiles• WAS administrators have implicit root authority
– Difficult to configure– Can use LocalOS registry, but have to set special property (WAS_UseRemoteRegistry)– Has almost no meaningful impact on security, but can be useful for application server level
accounting
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening57
Choose an Appropriate Process IdentityOption #3: Everything as a Normal user– All Application Servers must run under the same, non-privileged OS user as
the Node Manager (e.g. wasuser)
– The OS user (wasuser) 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
– Fairly easy to configure• Simple chmod/chown of the WAS files and you are on your way
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening58
Options SummaryAll as root user
Node as root
All as non-root
WAS admins have implicit root authority
Some WAS admin tasks may require root access
Can’t use Operating System Registry
Fairly complex file ownership/permission issues
Application isolation cannot be address by operating system permissions. Need Java 2 security and MUCH more. Refer to application isolation materials.
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening59
Enforce CSIv2 Transport SSL useWAS 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, then cleartext will be used
– Most likely scenario when cleartext is in use would be a mis configured client
If you want to assure that traffic is encrypted; ensure that SSLis the only acceptable option at negotiation time– Security > Authentication Protocol > CSIv2 > Inbound Transport and
– Security > Authentication Protocol > CSIv2 > Outbound Transport
– Change Transport from “SSL-supported” to “SSL-required”
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening60
Keep Up to Date with Patches and FixesThe 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”• Regularly review “Recommended Updates” support page
Warning: Security fixes are usually rolled into the next Cumulative Fixor Refresh Pack for every supported release and then no longer listed on the recommended updates page
Keep up to date with all your infrastructure components – Operating Systems, LDAP, Database, Web Server etc – not just WAS
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening61
Disable Unused PortsBasic principle of security hardening is to minimise thepotential attack surface, even when no known security issues– If a service isn’t required, disable it
Potential candidates for disablement include– SAS_SSL_SERVERAUTH_LISTENER_ADDRESS – used for compatibility with WAS
V4 and earlier releases (old IIOP security protocol replaced by CSIv2)• Take out of service by selecting CSI as the active protocol on Global Security panel
– SIB_ENDPOINT_* - used by the default messaging engine• Not started unless the messaging engine is enabled
– SIB_MQ_* - used by the messaging engine when connecting to MQ• Not started unless the messaging engine is enabled
– WC_adminhost* - used for administrative Web Browser access • Can be removed from the Web Container Transport Chain Configuration Panel for
servers that aren’t the Dmgr• Check to ensure these ports are not re-enabled after cloning
– WC_defaulthost* - default Web container listening ports – if you’ve added custom listener ports these might not be needed• Can be removed from the Web Container Transport Chain Configuration Panel
N M E I
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening62
Disable Password CachingWAS 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:
• Can still authenticate with old password when registry updated• Can still authenticate if account locked in registry using cache• 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
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening63
AgendaIntroduction
SSL Overview
Infrastructure Preventative Measures
Advanced Considerations– Cross Cell Trust– WAS Weaknesses
Protecting your Desktop Environment
Wrap-up
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening64
Cross Cell TrustIt is often desirable to have SSO across WAS cells for good business reasons– Need to understand that cross cell communication impacts trust and raises
significant security issues• When cells trust each other, compromise of one may compromise another
– Three technical issues to consider which all relate to cross cell SSO• Shared LTPA keys• CSIv2 identity assertion• Subject propagation callbacks
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening65
Shared LTPA KeysOrdinarily, WAS cells can’t communicate with each other securely
– Can configure cells to communicate securely (implies trust boundary is now both cells)
• Share same registry• Share same LTPA encryption key• Have compatible SSL keyrings
– Then either cell can create credentials for the other• If either is compromised, so is the other!
– Cell A could forge WAS admin credentials and use it to hack cell B• Published APIs exist for becoming any user!!
– Only Java 2 security blocks
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening66
CSIv2 Server to Server Identity AssertionScenario: cell A servers call cell B servers and not the reverse– Servers in cell A perform identity assertion to servers in cell B– Compromise of cell A always compromises B
• Cell A can assert any userid to cell B (including admin)– If cell A uses password based server to server authentication
• Cell B knows “security server id and password” for cell A • Therefore, compromise of B compromises A
– If use certificate authentication for based server to server authentication• Cell B cannot assume any identity in cell A• Cell B cannot compromise cell A
Net: Identity assertion can slightly reduce risk over shared LTPA keysWAS V6.1 allows cell A to use a defined account in cell B’s user registry– Eliminates need to share cell B’s security server id password with cell A– Specify “an alternative trusted identity “ on CSIv2 outbound panel New
in 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening67
“Safe” Server to Server AuthenticationCertificate
Password
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening68
Subject Propagation CallbacksServers can optionally share customized subjects, even across cells
Consider two servers that share an SSO domain. User with customized subject accesses server A and obtains an authentication session. Then, goes to server B.
– This requires Subject propagation
– Subject propagation uses DynaCache (within a replication domain) or callbacks
JMX callback involves a secure call from server B to server A to obtain the user’s tokens (authentication information)
– Server B authenticates to server A by sending it’s admin userid and password
– Server A authorizes server B by verifying that the userid has administrative authority
Trust leak is then– Server B has administrative authority to server A
– Server A is receiving server B’s admin userid and password
– Irrelevant within a cell, but potentially significant across cells• Keep in mind that SSO across cells already requires significant trust
WAS V6.1 allows the use of an LTPA token instead of a password– Eliminates leakage of server B’s admin user password but still requires significant trust
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening69
AgendaIntroduction
SSL Overview
Infrastructure Preventative Measures
Advanced Considerations– Cross Cell Trust
– WAS Weaknesses
Protecting your Desktop Environment
Wrap-up
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening70
Corner Cases: Weaknesses in WAS SecurityCertificate Authentication Limitations– Doesn’t check Certificate Revocation Lists (CRLs) for RMI/IIOP traffic
• You could write a custom user registry to perform certificate verification and CRL checking
– Doesn’t check that destination of request is in fact intended party• Would require that caller identify hostname or identity expected of server
being contacted• Subject to man in the middle attacks
WAS V6.1 supports CRL checking as well as hostname verification– This is done by configuration of the trust manager
N M E I
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening71
AgendaIntroduction
SSL Overview
Infrastructure Preventative Measures
Application Preventative Measures
Advanced Considerations
Protecting your Desktop Environment
Wrap-up
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening72
WebSphere Studio/Rational Application Developer Hardening
The embedded test environment includes a fully functional WAS environment– Listens on remote ports– Accepts admin commands, include application installation and execution– An attacker could easily request that WAS install and run arbitrary code if the
test server is running• Code could delete user’s files, read files, or just cause havoc• If desktop user has administrative authority, the attacker can leverage
operating system administrative commands to cause even more damage– Attack could be launched using wsadmin, SOAP/JMX, or even a web
browser!
The Agent Controller is installed by default and is used for monitoring application servers– By default (prior to 6.0.1), the Agent Controller accepts requests from any
host without authentication -- could be used to read any file from your computer
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening73
Harden the Embedded Application ServerOption #1: Harden embedded WAS– Enable Global Security in the embedded application server
• Prevents most serious attacks• To enable Global Security, you’ll need a registry
– LocalOS – but require an Administrator account– LDAP – not always readily available– Best alternative: configure a custom file registry, see the InfoCenter.
– Other hardening steps (from this presentation) worth considering but not as critical• Other weaknesses can be used to damage embedded test environment
which will be frustrating, but shouldn’t result in compromise of entire desktop
– WAS V6.1 will enable Administrative Security by default and includes a supported file registry
Option #2: Install a desktop firewall to block access to the computer– Take care to configure carefully – a desktop firewall which trusts your entire
internal corporate network is of little value
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening74
Harden the Agent ControllerOption #1: Secure the Agent Controller– When you first install the Agent Controller, configure it to accept requests
only from “this computer” or configure it to authenticate requests
– If you have already installed the Agent Controller, the installation can be hardened after the fact• Edit <RAC_INSTALL>\config\serviceconfig.xml and look for the Hosts
configuration stanza. Change the Hosts configuration from allowing all hosts to only allowing local<Hosts configuration="default">
<Allow host="LOCAL"/></Hosts>
– WAS V6.1 AST does not include Agent Controller• Presumably RAD V7 will and this should be addressed by default• Appears to be part of an open source project: http://www.eclipse.org/tptp/
Option #2: Install a desktop firewall as in previous example
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening75
AgendaIntroduction
SSL Overview
Infrastructure Preventative Measures
Application Preventative Measures
Advanced Considerations
Protecting your Desktop Environment
Wrap-up
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening76
Don’t Forget: Consider the Whole EnvironmentOther 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
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening77
Don’t Forget ApplicationsApplications need to be hardened against attack– See Application Hardening presentation
Applications might try to harm other applications– See Application Isolation presentation
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening78
Non IT Security IssuesFar 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.”
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening79
Audit, audit, audit ...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
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
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening80
FAQ: What about a Security Proxy?Tivoli Access Manager (TAM) is an example of a good security proxyDoes a security 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 I covered here
Does a security proxy make this any worse? – no– In fact, in some ways, it will make it better with another layer of security
Does security 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
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening81
FAQ: Operating System HardeningIBM WebSphere development does not test or recommend any hardened operating system configurations
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
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening82
IBM provides several tools to helpIBM Security Scanner for WebSphere Application Server– Checks for many potential security configuration issues
– Does not check for all the issues mentioned in this presentation
– http://www.ibm.com/support/docview.wss?uid=swg24009963
ACert tool – Checks SSL certificates for expiration dates
– http://www.ibm.com/support/docview.wss?uid=swg24006797
WAS V6.1 provides a “security report”– Basically a list of your configuration, provided with v6.1
Newin 6.1
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening83
ReferencesWebSphere Security Presentation Series
– http://pokgsa.ibm.com/~keys/documents/securitySeries
WebSphere Application Server V6 Security Handbook– SG24-6316-00 available from http://www.redbooks.ibm.com– V6.1 version coming soon
IBM WebSphere: Deployment and Advanced Administration– ISBN 0131468626 – http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=0131468626&itm=5
WAS V6 Security Hardening Paper– Covers all the topics in this presentation
WSDD - http://www-128.ibm.com/developerworks/websphere/techjournal//0512_botzum/0512_botzum1.html
Securing connections between WebSphere Application Server and WebSphere MQPart 1 – http://www-128.ibm.com/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.htmlPart 2 (SIBus to MQ via MQ Link) - http://www-128.ibm.com/developerworks/websphere/techjournal/0601_smithson/0601_smithson.html
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening84
Appendix
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening85
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 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 security on WAS or their apps, then to be logically consistent the same should be true for the operating systems.
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening86
What about Process Server? – First ThoughtsEverything in this presentation applies, plusSCA components with exported interfaces (callable across modules) result in implicit EJBs with remote interfaces– You must secure those using the SCA tools
• Specify a “security permission” as a Quality of Service qualifier • Be aware that if you SCA components aren’t “true” EJBs that
– You can’t use EJB constraints as there are no real EJB methods– You likely can’t use JACC for the same reason– There are no SCA security APIs equivalent to the J2EE APIs (e.g., isCallerInRole)
SCA components that read from or write to queues require authentication if security is enabled– Specify authentication alias information on the connection in the bindings panel
Lots of potential to export Web Services which means you need tosecure those in the usual manner – E.g., web services authentication (WS-Security or transport), plus EJB authorizationHuman tasks use the Staff registry for making authorization decisions, not the user’s authenticated Subject– Custom group information in subject will be ignored
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening87
What about Process Server? – First ThoughtsWBI adapters communicate with SIBus – you’ll need to secure that link– Authenticate using MQ authentication and set proper SIB authorization
– Unclear if can encrypt – consider VPN solution
Authorization Issues– Coarse grained authorization – you don’t have much control over who can
edit/manage particular instances of something
– Weak default authorization – some components have rather open authorization (typically all authenticated) by default
– Look at• Rules• Processes• Human task administration• CEI• etc
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening88
What about Process Server? – First ThoughtsCEI event store – to a DataSource– Assumes authentication data is defined on resource – can’t protect from
illegal access
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening89
Visa’s Recommended Standardshttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf
The PCI-DSS is actually more general though. It defines twelve requirements:– Requirement 1: Install and maintain a firewall configuration to protect data– Requirement 2: Do not use vendor-supplied defaults for system passwords and other
security parameters– Requirement 3: Protect stored data– Requirement 4: Encrypt transmission of cardholder data and sensitive information across
public networks– Requirement 5: Use and regularly update anti-virus software– Requirement 6: Develop and maintain secure systems and applications– Requirement 7: Restrict access to data by business need-to-know– Requirement 8: Assign a unique ID to each person with computer access– Requirement 9: Restrict physical access to cardholder data– Requirement 10: Track and monitor all access to network resources and cardholder data– Requirement 11: Regularly test security systems and processes.– Requirement 12: Maintain a policy that addresses information security
IBM WebSphere
© 2006 IBM CorporationSecurity Hardening90
Legal© Copyright IBM Corporation 2004, 2005. All rights reserved.
IBM, the IBM logo, the e-business logo and other IBM products and services are trademarks or registered trademarks of the International Business Machines Corporation, in the United States, other countries or both. References in this publication to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.
Product release dates and/or capabilities referenced in this publication may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries or both.
Microsoft, Windows, Windows NT and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries or both.
All other trademarks, company, products or service names may be trademarks, registered trademarks or service marks of others.