Securing a WebLogic Server Deployment

 

This section explains how to use the security features of WebLogic Server to protect your deployment. Specifically, it discusses the following topics:

• Why is Security Important for WebLogic Server?

• Determine the Security Needs of Your WebLogic Server Deployment

• Secure the Machine on Which WebLogic Server Runs

• Design Network Connections Carefully

• Manage the WebLogic Server Development and Deployment Environments

• Use Encryption

• Use the SSL Protocol

• Prevent Denial of Service Attacks

• Use Protected EJBs to Limit Access to Business Logic

• Use ACLs

• Use the Appropriate Security Realm

• Secure Your Database

• Use Auditing

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 CERT Coordination Center operated by Carnegie Mellon University.

This section 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:

• What WebLogic Server resources am I protecting?

  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.

• From whom am I protecting the WebLogic Server resources?

  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.

• What will happen if the protections on strategic resources fail?

  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:

• Keep your hardware in a secured area to prevent unauthorized users from tampering with the deployment machine or its network connections.

• Have an expert review network services such as the email program or directory service to ensure that there are no weaknesses that would permit a malicious attacker from accessing the operating system or system-level commands.

• Secure the file systems on the deployment machine, limiting directory and file access to a few, well-monitored user accounts. Some WebLogic Server configuration data (and some of your applications, including Java Server Pages (JSPs) and HTML pages guarded with access control lists (ACLs)) are stored in clear text on the file system. A user or intruder with read access to files and directories can easily defeat any security mechanisms you establish with WebLogic Server authentication and authorization schemes.

• Avoid creating multiple user accounts on deployment machines and avoid sharing file systems with other machines in the enterprise network.

• Create a weblogic user in the operating system and use the security controls of the operating system to give this user ownership and exclusive access to all files and directories in the WebLogic Server deployment. No other user needs write access to any files in the WebLogic Server deployment.

• Review active user accounts regularly and when personnel leave. Set a policy to expire passwords periodically. Never code passwords in client applications.

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 Deployment Environments

For many reasons, development and deployment are easier when you develop on machines that closely mimic the deployment environment. However, security concerns suggest the following differences in the deployment and development environments:

• Do not develop on a deployment machine. Develop first on a development machine and then move code to the deployment machine when it is completed and tested. This process prevents bugs in the development environment from affecting the security of the deployment environment.

• Do not put the development tools on the deployment machine. These tools include development product components including the javac, rmic, and ejbc compilers as well as other development tools you may use. Keeping the development tools off the deployment machine, reduces the leverage an intruder has should they get partial access to the WebLogic Server deployment machine.

• Protect your source code. Getting access to your source code allows an intruder to find security holes. Always keep source code off of the deployment machine. Comments in JSP files that are not meant for the end user should use the JSP syntax of <%/* ... */%> rather than the HTML syntax of <!-- ... --> because the JSP comments are deleted when the JSP is compiled and therefore cannot be viewed. Also, disable the Case Sensitive Extensions field on the File tab of the Administration console to further protect your JSP source.

Use Encryption

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:

• Encryption and decryption are computationally expensive algorithms that take CPU time to perform.

• Encryption can make debugging harder as you cannot review encrypted data to verify that it is correct.

• The loss of a secret key can render all encrypted data useless.Even the temporary loss of a secret key (for example, all the people who know the secret key are on vacation) can render a Web site useless until the secret key can be retrieved.

• Key management is an awkward problem.Who should know the secret key, where the secret key is stored, and whether the secret key itself should be encrypted are just some of the issues that must be addressed.

The questions to ask when designing the encryption for a WebLogic Server deployment are:

• What needs to be encrypted?

• What algorithm and strength should be used to encrypt data?

• Where will the keys be stored?

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 Denial of Service Attacks

A denial of service attack leaves a Web site running but unusable. Hackers accomplish this by depleting 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 bound checking.

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:

• Code that allows a user to place an order on your Web site might be in an ACL protected EJB that is only accessible to registered users of your Web site.

• Code that searches and displays the catalog of products on your Web site could be in an EJB that is accessible to all users

• Code that authorizes a return of merchandise may be in an ACL protected EJB that is only accessible to customer service personnel.

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.

Use ACLs

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:

• WebLogic Servers

• WebLogic Enterprise JavaBeans (EJBs)

• WebLogic Events

• WebLogic HTTP servlets/JSPs/HTML pages

• WebLogic JDBC connection pools

• WebLogic JMS destinations

• WebLogic JNDI contexts

Use the provided ACLs to protect the resources in your WebLogic Server deployment.

For more information, see the following sections:

• ACLs and Permissions

• "Defining ACLs" in Managing Security

• Programming WebLogic Enterprise JavaBeans for information about assigning ACLs to WebLogic EJBs.

• Deploying and Configuring Web Applications for information about assigning security roles in Weblogic Web applications.

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 SQLServer, 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.

Use Auditing

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.