Securing a WebLogic Server Deployment
The following sections explain how to use the security features of WebLogic Server to protect your deployment:
Why Is Security Important for WebLogic Server?
An application server resides in the sensitive layer between end users and your valuable data and resources. WebLogic Server provides authentication, authorization, and encryption services with which you can guard your resources. These services cannot provide protection, however, from an intruder who gains access by discovering and exploiting a weakness in your deployment environment.
Whether you deploy WebLogic Server on the Internet or on an intranet, it is a good idea to hire an independent security expert to go over your security plan and procedures, audit your installed systems, and recommend improvements.
Another good strategy is to read as much as possible about security issues. For the latest information about securing Web servers, BEA recommends reading the Security Improvement Modules, Security Practices, and Technical Implementations information available from the CERTTM Coordination Center operated by Carnegie Mellon University.
BEA suggests that you apply the remedies recommended in our security advisories. In addition, you are advised to apply every Service Pack as they are released. Service Packs include a roll up of all bug fixes for each version of the product, as well as each of the previously released Service Packs. As a policy, if there are any security-related issues with any BEA product, BEA will distribute an advisory and instructions with the appropriate course of action. If you are reponsible for security related issues at your site, please register to receive future notifications. BEA has established an e-mail address (email@example.com) to which you can send reports of any possible security issues in BEA products.
In addition, there are partner products that can help you in your effort to secure the WebLogic Server production environment. For more information, see the BEA Partner's Page.
This topic makes some specific and general recommendations related to WebLogic Server.
Determine the Security Needs of Your WebLogic Server Deployment
Before securing your WebLogic Server deployment, it is important to understand the security needs of your WebLogic Server environment. To better understand the security needs, ask yourself the following questions:
There are many resources in the WebLogic Server environment that can be protected including information in the database accessed by WebLogic Server, the availability of the Web site, the performance of the Web site, and the integrity of the Web site. Consider the resources you want to protect when deciding the level of security you must provide.
For most Web sites resources must be protected from everyone on the Internet. But should the Web site be protected from the employees on the intranet in your enterprise? Should your employees have access to all WebLogic Server resources? Should the system administrators have access to all WebLogic Server resources? Should the system administrators be able to access all data? You might consider giving access to highly confidential data or strategic resources to only a few well trusted system administrators. Perhaps it would be best to allow no system administrators access to the data or resources.
In some cases, a fault in your security scheme is easily detected and considered nothing more than an inconvenience. In other cases, a fault might cause great damage to companies or individual clients that use the Web site. Understanding the security ramification of each resource will help you to properly protect it.
As you read the following suggestions for securing your site, keep the answers to these questions in mind.
Secure the Machine on Which WebLogic Server Runs
A WebLogic Server deployment is only as secure as the security of the machine on which it is running. Therefore, it is important that you secure the physical machine, the operating system, and all other software that is installed on the host machine. The following are suggestions for securing the deployment machine, however, you should check with the manufacturer of the machine, operating system, and installed software for additional suggestions:
Accessing Protected Ports on UNIX
On UNIX systems, only processes that run under a privileged user account (in most cases, root) can bind to ports lower than 1024.
However, long-running processes like WebLogic Server should not run under these privileged accounts. Instead, you can do either of the following:
If you use Node Manager to start the server instance, configure Node Manager to accept requests only on a secure port and only from a single, known host.
See "Binding to Protected Ports on UNIX" in the Administration Console Online Help.
Design Network Connections Carefully
When designing network connections, you want to use the easiest-to-manage solution. This choice must be weighed against the need to protect strategic WebLogic Server resources. Placing WebLogic Server resources further from potential intruders reduces the risk of a security breach. Inserting firewalls carefully in your enterprise increases security and can prevent a small security fault from turning into a security crisis. For example, it is a good idea to protect a database that contains critical data behind a firewall. In addition, protect the host machine for the database as well as the usernames and passwords for the database. Still, if someone acquires the username and passwords for the database, it is not nearly as damaging if the database is protected by a firewall and cannot receive connections from computers on the Internet.
There are many ways to combine firewalls, WebLogic Server, and other network servers. Figure 3-1 illustrates a typical setup with a firewall that filters traffic destined for a WebLogic Server cluster.
Figure 3-1 Typical Firewall Setup
Another common firewall configuration restricts access to only HTTP or HTTPS Web connections. The firewall permits clients to connect only to a Web server which usually runs at the standard HTTP port 80 or HTTPs port 443. The Web server may be a WebLogic Server or a third-party Web server set up to proxy requests to a WebLogic Server. For example, Netscape Enterprise Server, Microsoft Internet Server, and Apache Server can be set up to serve static Web pages and proxy servlet and JSP requests to WebLogic Server. Figure 3-2 illustrates this configuration.
In Figure 3-2, the Web server is a gateway operating in a demilitarized zone (DMZ). In computer networks, a DMZ is a computer host or small network inserted as a neutral zone between a company's private network and the outside public network. It prevents outside users from getting direct access to a server on which company data resides. A DMZ is an optional and more secure implementation of a firewall which can also act as a proxy server. WebLogic Server connections come only from proxied Web server requests, enhancing the security of your WebLogic Server applications and back-end resources. In the configuration shown in Figure 3-2, clients interact exclusively with the Web server and WebLogic Server connections are made only by proxied Web server requests. As a result, the security of WebLogic Server applications and back-end resources that are configured in this way are enhanced.
Figure 3-2 Firewall with Web Server Gateway
In addition to setting up a firewall, you can restrict who connects to your WebLogic Server deployment by implementing the weblogic.security.net.ConnectionFilter interface. This interface allows you to accept or reject a network connection based on the host name and network address of the originating machine as well as the protocol used.
Manage the WebLogic Server Development and Production Environments
For many reasons, development and production are easier when you develop on machines that closely mimic the production environment. However, security concerns suggest the following differences in the deployment and production environments:
Encryption is the process of taking text or other data and scrambling it so that it cannot be understood. Decryption reverses the process making the text or data understandable. The decryption process always requires knowledge of a secret key or password. The secret key is a long string of bits that is required as an argument to the decryption algorithm to make it work correctly. The strength of an encryption algorithm is measured by the number of bits in its key.
There are many types of encryption and each type of encryption comes in many strengths. The biggest differences between the algorithms is how much CPU time it takes to decrypt the data and how many keys there are (symmetric key algorithms have just one key that is used to both encryption and decrypt while public key algorithms have two keys, one to encryption and one to decrypt).
Encryption is typically used in places where sensitive information is stored or communicated. These places can include but are not limited to information on network machines, on disk, in a database, in memory, and in legacy systems.
There are drawbacks to using encryption:
The questions to ask when designing the encryption for a WebLogic Server deployment are:
Use the SSL Protocol
Data that is sent over the network (either the Internet or an intranet) can be viewed by other parties on the network. This is unavoidable because of the design of networks. To prevent sensitive data from being compromised, the data should be encrypted.
To send encrypted data over the Internet you should use the HTTPS protocol (HTTP over the Secure Sockets Layer (SSL)) rather than the HTTP protocol. To configure your Web application for the SSL protocol you must use the user-data-constraint tag in the web.xml file and set the transport-guarantee to CONFIDENTIAL.
The demonstration digital certificates provided with WebLogic Server are for testing only. Everyone who downloads WebLogic Server has the private keys for these digital certificates. Do not use these digital certificates in a deployed WebLogic Server. Check the filerealm.properties file to make sure that the demonstration digital certificates have been removed from the deployed WebLogic Server.
Use the strongest encryption WebLogic Server supports: 1024-bit keys, 128-bulk data encryption on your data. The WebLogic Server version you download allows just 512-bit keys and 40-bit bulk encryption. Contact your BEA sales representative to request the stronger version.
Prevent Man-in-the-Middle Attacks
When using the SSL protocol, the data sent between the communicating parties can be vulnerable to man-in-the-middle attacks. A man-in-the-middle attack occurs when a machine inserted into the network captures, modifies, and retransmits messages to the unsuspecting parties. One way to avoid man-in-the-middle attacks is to validate that the host to which a connection is made is the intended or authorized party. An SSL client can compare the host name of the SSL server with the digital certificate of the SSL server to validate the connection. WebLogic Server provides a HostName Verifier to protect SSL connections from man-in-the-middle attacks.
By default, the HostName Verifier is enabled. However, during the implementation of WebLogic Server at your site, this functionality may have been disabled. To ensure a HostName Verifier is being used with your WebLogic Server deployment, check that the SSL.Ignore.HostName.Verification attribute on the SSL tab of the Servers node of the Administration Console is not checked.
Prevent Denial of Service Attacks
A Denial of Service attack leaves a Web site running but unusable. Hackers accomplish this by depleting or deleting one or more critical resources of the Web site. While a denial of service attack can happen if a hacker gets administrative privileges to your Weblogic Server, it usually occurs when an unprivileged user removes a required resource from a WebLogic Server deployment.
To perpetrate a Denial of Service attack on a WebLogic Server, an intruder bombards with many requests that are either very large in size, are slow to complete, or never complete so that the client stops sending data before completing the request. To prevent Denial of Service attacks, WebLogic Server allows you to restrict the size of a message as well as the maximum time it takes a message to arrive. You can set this information individually for each of the three protocols used by WebLogic Server: T3, HTTP and IIOP. See the online help for the Administration Console for information on setting the MaxT3MessageSize, CompleteT3MessageTimeout, MaxHTTPMessageSize, CompleteHTTPMessageTimeout, MaxIIOPMessageSize, and CompleteIIOPMessageTimeout fields. These fields have a default of 2 gigabytes for the maximum message size and 480 seconds for the complete message timeout. A value of 0 for any of the fields disables that check.
Secure the HTTP Response Header
Consider preventing WebLogic Server from sending its name and version number in HTTP responses.
By default, when an instance of WebLogic Server responds to an HTTP request, its HTTP response header includes the server's name and WebLogic Server version number. This poses a potential security risk if an attacker knows about some vulnerability in the specific version of WebLogic Server.
To prevent a WebLogic Server instance from sending its name and version number, disable the Send Server Header attribute in the Administration Console. The attribute is located on the Server
Protect User Accounts
In a dictionary attack, a hacker sets up a script to attempt logins using passwords out of a "dictionary". WebLogic Server provides a set of configurable attributes which protect user accounts from dictionary attacks. These attributes are configurable in a number of ways (for example, you can disable all the attributes, increase the number of invalid login attempts required before locking the account, increase the time period in which invalid login attempts have to take place before locking the account, and change the amount of time the user account is locked). It is up to site administrators to determine how these attributes should be set. Use this feature to protect accounts with maximum security. WebLogic Server ships with the maximum security enforced.
Note: If during development you reduce security by changing these attributes, remember to reset the attributes before deploying.
For more information, see Protecting Passwords.
Protect Application Content
By default, WebLogic Server uses a single directory, known as the web document root directory, as the location that contains static application content (HTML files and images) and dynamic application content (JSP and jHTML files). A potential vulnerability may occur if an application is allowed to create or modify files containing dynamic content within the web document root directory.
If an application is capable of modifying existing files in the web document root directory, there is the potential that the application could insert executable code in the form of JSP or jHTML tags in an existing file. If the particular file provides dynamic content, the inserted code would be executed the next time the file was served to a client.
To prevent the scenario under which this vulnerability could occur, BEA recommends the following supplemental security measures:
Replace HTML Special Characters in User-Supplied Data
The ability to return user-supplied data can present a security vulnerability called cross-site scripting, which can be exploited to steal a user's security authorization. For a detailed description of cross-site scripting, refer to "Understanding Malicious Content Mitigation for Web Developers" (a CERT security advisory) at http://www.cert.org/tech_tips/malicious_code_mitigation.html.
To remove the security vulnerability, before you return data that a user has supplied, scan the data for HTML special characters. If you find any such characters, replace them with their HTML entity or character reference. Replacing the characters prevents the browser from executing the user-supplied data as HTML.
For more information, see "Securing User-Supplied Data in JSPs" and "Securing Client Input in Servlets."
Use Protected EJBs to Limit Access to Business Logic
Some parts of your Web application are more sensitive than other parts. For example, the part of your application that renders HTML is less sensitive than the part of the application that accesses a key database table. More effort should be placed on protecting the sensitive parts of your Web application. One way to protect the sensitive parts of your Web application is to wrap them in Enterprise JavaBeans (EJBs) and use ACLs to protect the EJBs. This security technique ensures that only properly authenticated and authorized users can execute the EJBs.
The following is an example of how to use EJBs and ACLs to protect sensitive parts of your Web application:
The exact choice of what to protect and to whom to grant access to specific operations must be considered on a per-application basis.
Remember your Web application is going to evolve over time. This makes hard-to-understand schemes even harder to manage. One way to help prevent future mistakes is to organize security by package. For example, you could have one package where all methods on all classes are available to registered users and another package where all methods on all classes are available only to customer service personnel. The final decision as to whom has what access is up to the EJB deployer but a security scheme based on package is an easy mechanism for the deployer to implement.
ACLs are data structures with multiple entries that guard access to WebLogic Server resources. WebLogic Server provides ACLs that protect the following WebLogic Server resources:
Use the provided ACLs to protect the resources in your WebLogic Server deployment.
ACLs and permissions for WebLogic EJBs differ from ACLs and permissions for other kinds of WebLogic Server resources in the following ways:
For more information, see the following sections:
Use the Appropriate Security Realm
Security in WebLogic Server is based on the concept of a security realm. A security realm in WebLogic Server is a collection of Users and Groups, data about the Users and Groups, and permissions for WebLogic Server resources assigned to the Users and Groups. WebLogic Server offers many different types of security realms.
The default security realm, the File realm, is the least secure of security realms. Do not use the File realm for deployed WebLogic Servers. WebLogic Server provides a set alternate security realms that offer authorization and authentication through the facilities of the security realm. For more information about the available security realms, see the Security Realms section of the Concepts chapter.
Secure Your Database
Most Web applications use a database to store their data. Common databases used with WebLogic Server are Oracle, Microsoft's SQL Server, and Informix. The databases frequently hold the Web application's sensitive data including customer lists, customer contact information, credit card information, and other proprietary data. When creating your Web application you must consider what data is going to be in the database and how secure you need to make that data. You also need to understand the security mechanisms provided by the manufacturer of the database and decide whether they are sufficient for your needs. If the mechanisms are not sufficient, you can use other security techniques to improve the security of the database. One common technique is to encrypt sensitive data before writing it to the database. For example, you might leave all customer data in the database in plain text except for the credit card information which is encrypted.
Auditing is the process of recording key security events in your WebLogic Server environment. The audit record is usually kept separate from the WebLogic Server log file. Reviewing the auditing records can help you determine whether there has been a security breach or an attempted breach. Noting things such as repeated failed logon attempts or a surprising pattern of security events may be the key to preventing serious problems. To use auditing, implement the weblogic.security.audit package. For more information, see the "Auditing Security Events" section in Managing Security.
Control Access to Multiple Domains
If the WebLogic Server Administration Console is used to create multiple domains, the System user in one domain can access the other domains created by that instance of the Administration Console. This behavior can present a security risk in a production environment. If you do not want this behavior, make sure that each domain in your enviroment in created in a different location (meaning on a different host or through a different WebLogic Server instance). You can also use the file protections offered through the operating system to protect the config.xml file so that only the appropriate System user has access to the file.
Copyright © 2001 BEA Systems, Inc. All rights reserved.