This chapter summarizes the steps to configure security for a WebLogic Server environment, with emphasis on tasks to perform before, during, and after creating the WebLogic domains that operate in that environment.
This chapter includes the following sections:
Obtaining Private Keys, Digital Certificates, and Trusted Certificate Authority Certificates
Storing Private Keys, Digital Certificates, and Trusted Certificate Authority Certificates
For a complete checklist of all components in the WebLogic Server that should be secured in a production environment, including specific tasks recommended for securing the WebLogic Server host, the WebLogic Security Service, files and databases used by WebLogic Server, see Securing a Production Environment for Oracle WebLogic Server.
If you are installing WebLogic Server in a production environment, Oracle strongly recommends the guidelines described in the following sections:
Before you start the WebLogic Server installation program, complete the following tasks:
Create a My Oracle Support account so that you can register your WebLogic Server installation with Oracle and receive security updates automatically. For more information, visit http://www.oracle.com/support/index.html.
Secure the host machine, operating system, and file system to ensure that access is restricted only to authorized users. For example:
Keep your hardware in a secured area to prevent unauthorized operating system users from gaining access to the machine and its network connections.
Make sure the host machine has the latest operating system patches and security updates.
Note:
As new patches become available, you should download and install them promptly.Secure networking services and the file system that the operating system provides to prevent unauthorized access. For example, make sure that any file system sharing is secured.
Set operating system file access permissions to restrict access to data stored on disk that will be used or managed by WebLogic Server, such as the security LDAP database and directories into which keystores are created and managed.
Limit the number of user accounts on the host machine. Create a group to contain only the following user accounts:
The user who installs WebLogic Server only.
The user who creates the WebLogic domain and uses Node Manager to start the Administration Server and each Managed Server instance in the domain.
Restrict the privileges of these user accounts to only the following directories:
Oracle home — Root directory created for all Oracle Fusion Middleware products on a host computer
WebLogic home — Root directory of the WebLogic Server installation
Domain home — Root directory of the WebLogic domain
Note:
Some processes also need access to temporary directories by default, such as/tmp on Unix platforms. If the privileges of a user account are restricted to only the Oracle home, WebLogic home, and WebLogic domain directories, the user must change environment variables, such as TEMP or TMP, to point to a directory to which that user does have access.Ensure that any Web servers on the host machine run only as an unprivileged user, never as root. See also "Security Practices & Evaluations" information available from the CERT Coordination Center at http://www.cert.org/.
Ensure no software development tools or sample software is installed.
Consider using additional software to secure your operating system, such as a reputable intrusion detection system (IDS).
See "Securing the WebLogic Server Host" in Securing a Production Environment for Oracle WebLogic Server for more information.
During installation, make sure you do the following:
Do not install the sample applications component.
On the Specify Security Updates installer screen, select I wish to receive security updates via My Oracle Support.
For more information, see "Read Security Publications" and "Install WebLogic Server in a Secure Manner" in Securing a Production Environment for Oracle WebLogic Server.
Remove the Derby DBMS database, which is bundled with WebLogic Server for use by the sample applications and code examples as a demonstration database. Derby DBMS is located in the WL_HOME/common/derby directory.
Visit the Critical Patch Updates and Security Alerts page at the following location to review WebLogic Server security advisories:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
When configuring a WebLogic domain for use in a production environment, using tools such as the Configuration Wizard, the pack/unpack commands, or WLST:
Configure the domain to run in production mode. The domain mode determines default settings regarding security and logging. In production mode, the security configuration is relatively stringent, such as requiring a user name and password to deploy applications and start the Administration Server.
If you are using the unpack command to create a full WebLogic domain, or a subset of a domain that is used for a Managed Server domain directory on a remote machine, use the -server_start_mode=prod parameter to configure production mode.
Note that it is possible to change the domain mode from development to production, and vice versa. However, for production environments with more stringent security requirements, Oracle recommends setting the production domain mode at the time you create the domain (as opposed to changing a development mode domain to production mode).
For more information, see "Development and Production Modes" in Understanding Domain Configuration for Oracle WebLogic Server.
If the domain will interoperate with other WebLogic domains, or has the potential for that use at some future point, choose resource names carefully. Many resource names are fixed at the time a domain is created, and stringent requirements must be observed for resource names when using Cross-Domain Security, transactions, and messaging.
For more information, see "Requirements for Transaction Communication" in Developing JTA Applications for Oracle WebLogic Server.
When creating domains using WLST, do not enter unencrypted passwords in commands for configuring entities that require them, such as passwords for:
Domain administrator
Node Manager user
Database user
JKS keystores (both when creating the keystores and again when configuring them with WebLogic Server)
Wallet
Specifying unencrypted passwords in WLST commands is a security risk: they can be easily viewed from the monitor screen by others, and they are displayed in process listings that log the execution of those commands. Instead, omit the password from the command. When the command is executed, WLST automatically prompts you for any passwords needed to complete the domain configuration.
After you have created your domain and have started it, perform the following tasks to optimize the domain's security:
Configure the Password Validation provider to manage and enforce password composition rules. The Password Validation provider is configured out-of-the-box to work with several WebLogic authentication providers.
For more information, see Chapter 17, "Configuring the Password Validation Provider".
As you create or add users to the security realm, check that the User Lockout options on user accounts are set for maximum protection. Note that the configuration of User Lockout is defined on a per realm basis. Therefore, if the default User Lockout settings are not suitable for your needs, you might need to customize these settings whenever you create a new security realm.
For more information, see Protecting User Accounts and How Passwords Are Protected in WebLogic Server.
If you have configured Node Manager to start, shut down, and restart the Administration Server and Managed Server instances distributed across multiple machines, make sure that Node Manager security is properly configured.
If you are using Java Node Manager (recommended for production environments), see "Configuring Java-based Node Manager Security" in Administering Node Manager for Oracle WebLogic Server.
If you are using Script Node Manager, which may be suitable for environments that have less stringent security requirements, see "Step 2: Configure Node Manager Security" in Administering Node Manager for Oracle WebLogic Server.
Enable auditing, which provides an automated way of collecting and storing information about events and other activity occurring in the system. Auditing is available through either of the following means:
Configuration auditing — When this is enabled, the Administration Server emits log messages and generates audit events when a user changes the configuration of any resource within a domain or invokes management operations on any resource within a domain.
WebLogic Auditing provider — Optional security provider that collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. When configuration auditing is enabled, the WebLogic Auditing provider also logs configuration auditing events.
Note that auditing may impose a performance overhead that should be taken into consideration. However, by adjusting how auditing is configured, this additional overhead can be minimized. When enabling auditing, make sure that sufficient disk space is available for the audit log. For more information, see Chapter 8, "Configuring the WebLogic Auditing Provider".
Make sure that the JVM platform MBean server cannot be accessed remotely. For more information, see "Monitoring and Management Using JMX Technology" at http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html.
If you have a requirement to comply with Federal Information Processing Standards (FIPS) 140-2, complete the appropriate procedures described in Chapter 36, "Enabling FIPS Mode".
Make sure configuration settings for complete message time out are sized appropriately for your system. For more information, see "Configuring Network Resources" in Administering Server Environments for Oracle WebLogic Server.
Create and configure the keystores used for holding identity and trust; that is, the keystores containing identity certificates and the keystore containing trusted Certificate Authority (CA) certificates. See Chapter 29, "Configuring Keystores".
If you are using the Oracle OPSS Keystore Service (KSS) for use with WebLogic Server, see Chapter 30, "Configuring Oracle OPSS Keystore Service".
Configure certificate validation and revocation checking to ensure that:
Each certificate in a certificate chain was issued by a certificate authority, as explained in Chapter 34, "SSL Certificate Validation".
The revocation status of each certificate WebLogic Server validates is current. See Chapter 39, "X.509 Certificate Revocation Checking".
Configure a host name verifier. When making an SSL connection, the host name verifier ensures that the host name in the URL to which the client connects matches the host name in the digital certificate that the server sends back. For information, see Chapter 31, "Using Host Name Verification".
Configure SSL for the administration port, network channels, database connections, LDAP server connections, and other resources handling communication that must be secured. In particular, make sure that connections to remote server instances in the domain are secured with SSL. The specific components for which either one- or two-way SSL needs to be configured depends on the overall topology of the production environment. For details, see the following topics:
Table 4-1 SSL Configuration Topics
| For information about . . . | . . . see the following topic |
|---|---|
|
An overview of using SSL to secure communications in a basic WebLogic domain |
"Secure Sockets Layer (SSL)" in Understanding Security for Oracle WebLogic Server |
|
Where to use one-way and two-way SSL in a basic WebLogic domain |
"One-way/Two-way SSL Authentication" in Understanding Security for Oracle WebLogic Server |
|
Steps to configure SSL in a basic WebLogic domain |
|
|
Configuring an administration port for secure communication with the domain Administration Server |
"Administration Port and Administrative Channel" in Administering Server Environments for Oracle WebLogic Server |
|
Securing database connections |
"Understanding Data Source Security" in Administering JDBC Data Sources for Oracle WebLogic Server |
|
An overview of using SSL in Oracle Fusion Middleware to secure components in web, middle, and data tiers |
"About SSL in Oracle Fusion Middleware" in Administering Oracle Fusion Middleware |
|
Best practices for configuring SSL in WebLogic Server |
"Section 2. Security Best Practices" in Document ID 1074055.1, available from My Oracle Support at |
Notes:
Note the following:By default, WebLogic Server is configured for one-way SSL authentication; however, the SSL port is disabled. Oracle strongly recommends enabling the SSL port in all server instances in a production domain.
The demonstration digital certificates, private keys, and trusted CA certificates provided in WebLogic Server should never be used in a production environment.
Restrict the size and the time limit of requests on external channels to prevent Denial of Service attacks. For information, see "Reducing the Potential for Denial of Service Attacks" in Tuning Performance of Oracle WebLogic Server.
If you use multiple Authentication providers, be sure to set the JAAS control flag correctly. For information, see Using More Than One Authentication Provider.
Ensure that you have correctly assigned users and groups to the default WebLogic Server security roles. For information, see "Users, Groups, And Security Roles" in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
You have multiple choices for obtaining private keys, digital certificates, and trusted CA certificates for your WebLogic Server environment. When choosing, note the following considerations:
For production environments, Oracle strongly recommends obtaining private keys and digital certificates only from a reputable certificate authority such as Entrust or Symantec Corporation. For information, see Obtaining and Storing Certificates for Production Environments.
For development environments only, you can use the digital certificates, private keys, and trusted CA certificates provided by WebLogic Server. You can also use keytool or the CertGen utility to generate self-signed certificates. For information, see Using Keystores and Certificates in a Development Environment.
Once you have obtained private keys, digital certificates, and trusted CA certificates, you need to store them so that WebLogic Server can use them to find and verify identity. Private keys, their associated digital certificates, and trusted CA certificates are stored in keystores. Then you need to configure those keystores with WebLogic Server.
| For information about . . . | . . . see the following topic |
|---|---|
| Creating a keystore | Creating a Keystore |
| Configuring a keystore to be used with WebLogic Server | Configuring Keystores with WebLogic Server |
| A step-by-step example of using the keytool utility to create a keystore and store keys and certificates in it | Creating a Keystore: An Example |
| Displaying the certificates contained in a keystore | Viewing Keystore Contents |
| Updating certificates that are due to expire | Replacing Expiring Certificates |
WebLogic Server defines a set of configuration options to protect user accounts from intruders. In the default security configuration, these options are set for maximum protection. You can use the WebLogic Server Administration Console to modify these options using the Configuration > User Lockout page, which is available for each security realm.
As a system administrator, you have the option of turning off all the configuration options, increasing the number of login attempts before a user account is locked, increasing the time period in which invalid login attempts are made before locking the user account, and changing the amount of time a user account is locked. Remember that changing the configuration options lessens security and leaves user accounts vulnerable to security attacks. See "Set user lockout attributes" in the Oracle WebLogic Server Administration Console Online Help.
Notes:
The User Lockout options apply to the default security realm and all its security providers. User Lockout works in all security realms, is layered on top of all configured providers, including custom ones, and is enabled by default.If you are using an Authentication provider that has its own mechanism for protecting user accounts, consider if disabling User Lockout on the security realm is appropriate because other Authentication providers might be configured in the security realm.
If a user account becomes locked and you delete the user account and add another user account with the same name and password, the User Lockout configuration options will not be reset.
For information about unlocking a locked user account, see "Unlock user accounts" in the Oracle WebLogic Server Administration Console Online Help. Unlocking a locked user account can be done through either the WebLogic Server Administration Console or the clearLockout attribute on the UserLockoutManagerRuntimeMBean.
Connection filters allow you to deny access at the network level. They can be used to protect server resources on individual servers, server clusters, or an entire internal network or intranet. For example, you can deny any non-SSL connections originating outside of your corporate network. Network connection filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names.
Connection filters are particularly useful when using the Administration port. Depending on your network firewall configuration, you may be able to use a connection filter to further restrict administration access. A typical use might be to restrict access to the Administration port to only the servers and machines in the WebLogic domain. An attacker who gets access to a machine inside the firewall, still cannot perform administration operations unless the attacker is on one of the permitted machines.
WebLogic Server provides a default connection filter called weblogic.security.net.ConnectionFilterImpl. This connection filter accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter. To configure this connection filter to deny access, simply enter the connection filters rules in the WebLogic Server Administration Console.
You can also use a custom connection filter by implementing the classes in the weblogic.security.net package. For information about writing a connection filter, see "Using Network Connection Filters" in Developing Applications with the WebLogic Security Service. Like the default connection filter, custom connection filters are configured in the WebLogic Server Administration Console.
To configure a connection filter:
Enable the logging of accepted messages. This Connection Logger Enabled option logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.
Choose which connection filter is to be used in the domain.
To configure the default connection filter, specify weblogic.security.net.ConnectionFilterImpl in Connection Filter.
To configure a custom connection filter, specify the class that implements the network connection filter in Connection Filter. This class must also be specified in the CLASSPATH for WebLogic Server.
Enter the syntax for the connection filter rules.
For more information:
See "Configure connection filtering" in the Oracle WebLogic Server Administration Console Online Help.
For information about connection filter rules and writing a custom connection filter, see "Using Network Connection Filters" and "Developing Custom Connection Filters" in Developing Applications with the WebLogic Security Service.
You can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to create a new security configuration.