Continuing our blog series on OBIEE security, when discussing WebLogic security, the WebLogic Scripting Tool (WLST) needs to understood. From a security risk perspective, consider WLST analogous to how DBAs use SQL to manage an Oracle database. Who is using WLST and how they are using it needs to be carefully reviewed as part of any WebLogic security assessment.
WebLogic Scripting Tool (WLST)
The WebLogic Scripting Tool (WLST) is a command-line scripting environment that is used to create, manage, and monitor WebLogic. It is based on the Java scripting interpreter, Jython, version 2.2.1. In addition to supporting standard Jython features such as local variables, conditional variables, and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server.
From a security risk perspective, consider WLST analogous to how DBAs use SQL to manage an Oracle database. Who is using WLST and how they are using it needs to be carefully reviewed as part of any WebLogic security assessment.
WLST uses the WebLogic Security Framework to enforce the same security rules as when using the WebLogic user interface. WLST scripts, similar to SQL scripts, are created and edited using any text editor and the operating system user running a WLST script can easily be different than the user referenced in the script. WLST scripts can be run in either on or offline mode and, aside from modifying and copying configurations, (e.g. to create a test server), they can be used to add, remove, or modify users, groups, and roles.
Securing the WLST Connection
Both Integrigy Corporation and Oracle recommend that when using WLST only connect through the administration port. The administration port is a special, secure port that all WebLogic Server instances in a domain can use for administration traffic.
By default, this port is not enabled, but it is recommended that administration port be enabled in production. Separating administration traffic from application traffic ensures that critical administration operations (starting and stopping servers and changing configurations) do not compete with application traffic on the same network connection.
The administration port is required to be secured using SSL. As well, by default, the demonstration certificate is used for SSL. The demo SSL certificate should not be used for production.
Writing and Reading Encrypted Configuration Values
Some attributes of a WebLogic Server configuration are encrypted to prevent unauthorized access to sensitive data. For example, JDBC data source passwords are encrypted. It is highly recommended to follow the WebLogic scripting tool documentation for specific instructions on working with encrypted configuration values however WLST is used - manually (ad-hoc), in scripts, offline and on line. A security assessment should include a discussion, if not a review, of WLST scripts that set or manipulate encrypted values.
Running WLST Scripts
WLST scripts permit unencrypted passwords at the command line. WebLogic security policies need to address how WLST scripts should provide passwords. Storing passwords incorrectly can easily and needlessly expose passwords in scripts, on monitor screens and in logs files. When entering WLST commands that require an unencrypted password, the following precautions should be taken:
- Enter passwords only when prompted. If a password is omitted from the command line, it is subsequently prompted for when the command is executed
- For scripts that start WebLogic Server instances, create a boot identity file. The boot identity file is a text file that contains user credentials. Because the credentials are encrypted, using a boot identity file is much more secure than storing unencrypted credentials in a startup or shutdown script.
- For WLST administration scripts that require a user name and password, consider using a configuration file. This file, can be created using the WLST storeUserConfig command and contains:
- User credentials in an encrypted form
- A key file that WebLogic Server uses to unencrypt the credentials
If you have questions, please contact us at firstname.lastname@example.org
-Michael Miller, CISSP-ISSMP