Configuring security for a WebLogic Server environment starts with a creating a secure installation of WebLogic Server. It also includes choosing the security configuration options that are appropriate for the environment in which the domain runs, such as obtaining and storing certificates, protecting user accounts, and securing the network on which the domain runs.
This chapter includes the following sections:
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 Ensuring the Security of Your Production Environment in Securing a Production Environment for Oracle WebLogic Server.
Performing a secure installation includes steps to secure the host machine on which WebLogic Server is installed, to limit access to that host to only authorized users, and to install Critical Patch Updates immediately after installation is complete.
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. Visit
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.
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
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
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
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 .
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.
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
Visit the Critical Patch Updates and Security Alerts page at the following location to review WebLogic Server security advisories:
Limit access to internal applications by disabling unused internal applications and enabling the Administration port. For more information about how to limit access to internal applications, see Install and Configure WebLogic Server in a Secure Manner in Securing a Production Environment for Oracle WebLogic Server .
To create a WebLogic domain for production use, consider the environment in which the domain will run, such as whether it will interoperate with other WebLogic domains, and how best to secure the accounts of users who have access to the domain.
When configuring a WebLogic domain for use in a production environment, using tools such as the Configuration Wizard, the
unpack commands, WLST, or the WebLogic Server Administration Console, consider the following:
Configure the domain to run in either production mode or secured 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.
See Secure your production domain in the Oracle WebLogic Server Administration Console Online Help for information about enabling secured production mode and related security settings using the Administration Console.
setOption WLST offline command while creating a domain, and set the
ServerStartMode argument to
secure to create a domain in secured production mode. See setOption in WLST Command Reference for Oracle WebLogic Server.
See Using WLST Online to Update an Existing WebLogic Domain in Understanding the WebLogic Scripting Tool to learn how to change your domain environment from production mode to secured production mode.
See Configure domain security in Administering Oracle WebLogic Server with Fusion Middleware Control to enable secured production mode and related security settings using Fusion Middleware Control.
Note:It is possible to change the domain mode from development to production, production to development, and from production to secured production mode. However, it is important to remember that to enable secured production mode, your domain must be in production mode.
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). See Development and Production Modes in Understanding Domain Configuration for Oracle WebLogic Server for more information about how to modify domain modes.
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.
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:
Node Manager user
JKS keystores (both when creating the keystores and again when configuring them with WebLogic Server)
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.
If your domain is running in secured production mode, then WebLogic Server logs a warning if the user lockout is configured to a value less than the default value.
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.
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. See Configuring the WebLogic Auditing Provider.
Note:If secured production mode is enabled for your domain, then WebLogic Server logs a warning if an Auditing provider is not configured. You can use the
WarnOnAuditingattribute in the SecureModeMBean to specify whether warnings should be logged or not if auditing is not enabled.
If you are using the Oracle OPSS Keystore Service (KSS) for use with WebLogic Server, see Configuring Oracle OPSS Keystore Service.
Configure certificate validation and revocation checking to ensure that:
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
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.
In secured production mode, WebLogic Server logs warnings if the SSL configuration is not secure. You can use the
WarnOnInsecureSSL attribute contained in the SecureModeMBean to specify whether warnings should be logged if the SSL configuration is not secure.
For production environments, Oracle strongly recommends obtaining private keys and digital certificates only from a reputable certificate authority such as Entrust or Symantec Corporation. 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. See Using Keystores and Certificates in a Development Environment.
|For information about . . .||. . . see the following topic|
Creating a keystore
Configuring a keystore to be used with WebLogic Server
A step-by-step example of using the keytool utility to create a keystore and store keys and certificates in it
Displaying the certificates contained in a keystore
Updating certificates that are due to expire
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.
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
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:
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.
Refer to the following topics:
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.
To improve security, WebLogic Server uses the JDK JEP 290 mechanism to filter incoming serialized Java objects and limit the classes that can be deserialized. The filter helps to protect against attacks from specially crafted, malicious serialized objects that can cause denial of service (DOS) or remote code execution (RCE) attacks.
WebLogic Server uses JEP 290 as follows:
Implements a WebLogic Server-specific object input filter to enforce a blacklist of prohibited classes and packages for input streams used by WebLogic Server. The filter also enforces a default value for the maximum depth of a deserialized object tree.
Provides system properties that you can use to add or remove classes and packages from the default filter to blacklist or whitelist particular classes. You can also use the system properties to filter deserialized classes based on the nesting depth of the deserialized object, the number of internal references in the deserialized object, the size of arrays, and/or the maximum size in bytes of a deserialized object.
For more information on JEP 290, see http://openjdk.java.net/jeps/290.
JEP 290 support is provided in WebLogic Server with the following Patch Set Update (PSU):
WebLogic Server October 2017 PSU or later. For details about the WebLogic Server PSUs, see the My Oracle Support document Patch Set Update (PSU) Release Listing for Oracle WebLogic Server (WLS) (Doc ID 1470197.1).
JEP 290 integration is available when WebLogic Server 22.214.171.124 is configured with the following JDK versions:
JDK 8 Update 121 (JDK 8u121) or later
JDK 7 Update 131 (JDK 7u131) or later
Note:WebLogic Server 126.96.36.199 is certified for use with JDK 8, and supported WebLogic Server 188.8.131.52 clients are certified for use with JDK 7 and JDK 8, as explained in JDK 8 and Server JRE 8 Certification in What's New in Oracle WebLogic Server 184.108.40.206.0.
If you are running a JDK that does not support JEP 290, then WebLogic Server continues to run and provide some protection against known deserialization attacks, but will not have the protection of the more advanced features of JEP 290.
At startup, WebLogic Server configures a default JEP 290 filter with the following characteristics:
The maximum depth of a graph
A set of prohibited classes that cannot be deserialized
These default settings can change over time. For a list of the most current default filter settings, see the My Oracle Support document Restricting Incoming Serialized Java Objects to Oracle WebLogic Server (Doc ID 2421487.1). You can access My Oracle Support at https://support.oracle.com/.
To ensure that your system is protected with the most current default filter, be sure to apply the latest Java and WebLogic Server Critical Patch Updates (CPUs) as soon as they are released. The Critical Patch Updates, Security Alerts and Bulletins page references the latest Java and WebLogic Server updates that are available on My Oracle Support.
WebLogic Server includes system properties that you can use to customize, replace, or disable the JEP 290 default filter if desired.
The following table describes the system properties and includes sample usage.
Table 4-2 WebLogic Server JEP 290 System Properties
Use this property to set a custom JEP 290 filter for WebLogic Server, using the standard JEP 290 filter syntax. For JEP 290 filter syntax, see the Process-wide Filter section in http://openjdk.java.net/jeps/290.
By default, this custom filter is combined with the default WebLogic Server filter, with the custom filter taking precedence over the default filter for any filter elements that conflict.
For example, to set a custom filter by adding a class named
This setting blocks the class
Use this property to specify the filter mode for the custom filter, which provides the ability to combine, replace, or disable the default WebLogic Server filter. Valid values are:
For example, to replace the default WebLogic Server filter with the custom filter, use:
Use this property to specify whether the filter should apply globally to the entire JVM (as if it had been configured using the Java SE
For example, to apply the WebLogic Server default or custom filter to the entire JVM instead of just internal WebLogic Server deserialization, use: