Websphere Lockdown

gregglarkin

gregglarkin

Legendary Poster
Question

How many sites running Websphere 5 or Websphere 6 have taken the time to lock down the Websphere Administration console? By default, Websphere is installed without security enabled. If you leave it like that, it is possible to log in to the websphere admin console, FROM ANY BROWSWER, and wreak havock. I took my JDE web training on Websphere 4. For those that have had a more current class, do they cover locking down Websphere?

Gregg Larkin
Praxair North American System Admin
JDE CNC and Security, Websphere, Tidal, Princeton Softech
 
Those of you who have websphere 5 or 6, try the following expirement. Open your local browser, type in the following: http://yourserver:9060/ibm/console/

Substitute the name of your websphere webserver and the port that the admin console is running on. If the admin console pops up and does not ask you for a user id AND a password, you've got a nasty security hole.

Second question - would instructions on how to fix that hole be an interesting Quest topic?

Gregg Larkin
Praxair North American System Admin
JDE CNC and Security, Websphere, Tidal, Princeton Softech
 
I think it would be a good topic.

We get to the Websphere Admin using:

http://<servername>:<port>/admin

The one thing we do to prevent access is to simply not start it. By default, when we installed Websphere, the admin piece sits in server1 and the e811 sits in AS_JS_81. We only start AS_JS_81. Going to http://<servername>:9090/admin gives an invalid page error. If we need to make changes, we'll start server1, make the changes, then stop it.
 
If you're running WAS on the iSeries then you have to enter a valid AS/400 profile to gain access.

If you're running WAS on LUW (Lunix-Unix-Windows) then there is no security by default. The available options are:

1. Don't start the admin service
2. Implment WAS Global Security
a) Local OS Authentication
b) LDAP Authentication
3. Use the HTTP Server to lock down the admin page and promot users for a passsword.

The easiest and more secure option is 2.a) - Local OS Authentication. Since you likely don't have tons of Admins who need different access then LDAP is kinda like killing a fly with SUV.

For local OS authentication just add the users, activate local security (do not activate Java 2 Security). You also need to lock down access to the local file system since security just adds a file and anyone who has access to the WAS file can just remove it, bounce the service and then gain access. In this way it's also impossible to lock your self out since as the admin you can just remove the security file (yes in the beginning I did lock myself out plenty of times).

The only real pain to the Security is that everytime you do a new JAS tools tools release or upgrade it asks you for the credentials and it take a lot longer to install. I just rename the security file before the upgrade, bounce server1 and then reimplement security.

Colin
 
Hi,

Just to clarify : you need a valid OS/400 profile to
get into the HTTP Admin at http://server:2001, but
you don't need any valid OS/400 profile to get into
the WAS at http://server:9090/admin (at least with
WAS 5.0.2.x).
If its security is not configured, you can even enter
with blank or JOHNDOE users.
However, you can later configure WAS security to require
you some authentication (LDAP, Local accounts, etc) or
you can keep the "server1" instance stopped.
 
If you're going with Local OS authentication on Windows, the following may be helpful:
----------------------
11.3.4 – Establish security for the administration console:
11.3.4.1 – Back up the security.xml file via:
· cd D:\Program Files\WebSphere\AppServer\config\cells\server
· copy security.xml to security_orig.xml
11.3.4.2 – From a browser enter the following URL to connect to the Administration Console:
· http://server:9090/admin
11.3.4.3 – Supply “admin_was5” as the userid.
11.3.4.4 – Specify the local userid that will have rights to login to the Administration Console after global security is turned on:
· admin console path: Security / User registries / Local OS
· Specify the userid as “admin_was5” and enter the password used by that local userid as it is defined to the OS.
· Click “Apply”, “Save”, “Save”.
11.3.4.5 – Enable global security:
· Admin console path: Security / Global security
· Ensure the following check box settings:
o Check “Enabled”
o Do NOT check “Enforce Java 2 Security”
o Do NOT check “Use Domain Qualified Userids”
o Check “SWAM”
o Check “Local OS”
· Apply the settings. If prompted supply the “admin_was5” userid and its password.
· Specify the userid as “admin_was5” and enter the password used by that local userid as it is defined to the OS.
· Click “Apply”, “Save”, “Save”.
11.3.4.6 – Ensure userid rights:
· Admin console path: System Administration / Console Users
· Add “admin_was5” with Administrator rights.
· Click “Apply”, “Save”, “Save”.
11.3.4.7 – Ensure the server1 WebSphere service starts automatically. Update the following file with the admin_was5 userid and password:
· D:/Program Files\WebSphere\AppServer\properties\soap.client.props

The section in “SOAP Client Security Enablement” and should look like this:

#----------------------------------------------------------------
# SOAP Client Security Enablement
# - security enabled status ( false[default], true )
#----------------------------------------------------------------
com.ibm.SOAP.securityEnabled=false
# JMX SOAP connector identity
com.ibm.SOAP.loginUserid=admin_was5
com.ibm.SOAP.loginPassword=xxxx <= admin_was5 password goes here

11.3.4.8 – Cycle the WebSphere service to activate all security changes.
11.3.4.9 – From a browser enter the following URL to connect to the Administration Console:
· http://server:9090/admin
11.3.4.10 – Login to the Administration Console with the admin_was5 userid.
 
[ QUOTE ]
The definitive reference...........

ftp://ftp.software.ibm.com/software/webserver/appserv/library/v60/wasv600nd_security.pdf

[/ QUOTE ]

That's a good reference, but it takes IBM 30 pages (out of 200 or so in the redbook) to describe a simple process. I have a whitepaper in the editing process right now that describes the lockdown process from a CNC's point of view. I included screenshots and two alternate methods, LDAP and OS level security lockdown. I wrote it in a step by step process aimed at both novice as well as experienced CNCs. It will be published in October and I will be submitting it to Quest as a topic for the next conference. If anyone on the list is interested in obtaining this whitepaper once it is published, drop me an email offline and I will send it along. [email protected]

Gregg Larkin
Praxair North American System Admin
JDE CNC and Security, Websphere, Tidal, Princeton Softech
 
Back
Top