Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs   |   Site Map   |   Search   |   Contact   |   Glossary   |   WebLogic Server Documentation

An application server resides in the sensitive layer between end users and your valued data and resources. WebLogic Server provides authentication, authorization, and encryption services, but these are no protection from an intruder who gains access by discovering and exploiting some weakness in your deployment environment.

This document describes the measures you should take to secure a WebLogic Server deployment. It describes assumptions that WebLogic Server makes about the security of your environment and how to configure WebLogic Server security parameters for optimum security.

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. This document makes some specific and general recommendations related to WebLogic Server, but a well-secured deployment depends on the total environment.

For specific WebLogic Server security configuration and documentation information, see the Guide to WebLogic Server Security Documentation.

WebLogic Server depends upon a well-secured environment, including physical plant, operating system, file system, network, and organizational security policies and procedures. Here are some general recommendations on policies and practices concerning your security environment:

• Keep your hardware in a secured area to prevent unauthorized users from tampering with computers or network connections.

• Have an expert review network services such as sendmail or DNS to ensure that there are no weaknesses that would permit a malicious attacker to access the operating system or system-level commands.

• Secure the file systems on your deployment computers, limiting directory and file access to a very few, well-monitored user accounts. Some WebLogic Server configuration data (and some of your applications, including JSP and HTML pages guarded with WebLogic Server 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 application security you establish with WebLogic Server authentication and authorization.

• Avoid creating multiple user accounts on your deployment hosts and avoid sharing deployed file systems with other hosts on your network.

• Create a "weblogic" user in the operating system and use your operating system's facilities to give this user ownership and exclusive access to all files and directories in the WebLogic Server installation. No other user needs write access on any file in the WebLogic Server installation.

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

• Protect your network with a firewall. If you must provide outside access to destinations within the firewall, set up a secure VPN (Virtual Private Network).

• The computers where you develop and test should be configured the same as the computers you deploy on, but they should be isolated from your deployment systems. Do not share file systems between these systems

• Never permit development activity on a deployed system. Code should be tested first on a development system and then moved to the deployment system.

• Keep application source code on your development systems, but not on your deployment systems. Access to source code makes an attacker's work easier and potentially more harmful.

• Check native libraries, DLLs, and Java classes included in your system. Be sure you know the source of each and can verify that it has not been tampered with.

Setting up a Firewall

A firewall limits traffic between two networks. Firewalls can be a combination of software and hardware, including routers and dedicated gateway machines. They employ filters that allow or disallow traffic to pass based on the protocol, the service requested, routing information, and the origin and destination hosts or networks. They may also allow access for authenticated users.

There are many ways to combine firewalls, WebLogic Server, and other network servers. Figure 6-1 illustrates a typical setup with a firewall that filters traffic destined for a WebLogic Server cluster.

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 SSL port 443. The web server could be a WebLogic Server or a third-party web server set up to proxy requests to WebLogic Server. For example, you could set up Netscape Enterprise Server, Microsoft Internet Server, or an Apache Server to serve static web pages and proxy servlet and JSP requests to WebLogic Server. Figure 6-2 illustrates the architecture.

With this configuration, the web server is a gateway, operating in the "demilitarized zone" (DMZ). Clients interact exclusively with the web server. WebLogic Server connections come only from proxied web server requests, enhancing the security of your WebLogic Server applications and back-end resources.

If you use a supported third-party web server as a gateway, you can use the WebLogic-to-Netscape Enterprise Server Bridge (NSAPI), WebLogic-to-Microsoft IIS Bridge (ISAPI), or WebLogic-to-Apache Server Bridge to redirect requests to WebLogic Server. If you use WebLogic Server as the gateway, no bridge is needed to redirect to another WebLogic Server or cluster.

• The demonstration certificates provided with WebLogic Server are for testing only. Everyone who downloads WebLogic Server has the private keys for these certificates. Do not use these certificates in a deployed system. Look through the weblogic.properties file to make sure that the certificates have been removed.

• Use the strongest encryption WebLogic Server supports: 1024-bit keys, 128-bit bulk data encryption. 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.

• To permit only high-strength SSL connections, set the weblogic.security.SSL.ciphersuites property to a list of the high-strength ciphersuites, excluding the low-strength ciphersuites.

• To require two-way SSL authentication for SSL connections, set the property weblogic.security.enforceClientCert to "true".

• To permit clients with low-strength (40-bit) certificates to establish two-way authenticated SSL connections, WebLogic Server generates a temporary 40-bit key from your 128-bit certificate, a feature defined in the SSL 3.0 specification. Generating this key is a computationally-intensive, and so the key is generated once and reused 500 times (by default) before a new key is generated. You can change the number of times the key is reused by setting the weblogic.security.key.lifespan property in the weblogic.properties file.

Realm and Acl Configuration

• For better security, install an alternative security realm in WebLogic Server. An alternative realm retrieves authentication data (and sometimes authorization data) from an external store instead of from the weblogic.properties file. BEA provides alternative realms for LDAP servers, the Windows NT security domain, UNIX operating system authentication, and an RDBMS. Using the LDAP realm, with an SSL connection between WebLogic Server and the LDAP server is a common, very secure authentication solution. You can also build your own security realm using the WebLogic Security SPI.

• Set the WebLogic "system" user password to an unguessable string and change it frequently.

• Disabling the "guest" user can help you discover applications that are not explicitly protected with Acls. Disable the "guest" user by adding a weblogic.password.guest=new_passwd property or by setting the weblogic.security.disableGuest property to "true." If you alter the "guest" user with either of these methods, be sure to test your applications thoroughly before you deploy them.

• Review all weblogic.allow properties in the weblogic.properties file regularly.

• To protect individual files or directories served via HTTP, you must create a URLAcl policy file. Acls you create for HTTP resources in the weblogic.properties file determine if a user has permission to execute the servlets that serve pages, including HTML and JSP pages. These Acls do not apply to specific files or directories. A URLAcl policy file lets you grant or deny access on files and directories.

• If you do not need the WebLogic Console, disable it by setting the weblogic.system.enableConsole property to false.

• Review WebLogic Server and operating system logs regularly, watching for any suspicious activity.

• You can audit security events by providing an implementation of the weblogic.security.audit.AuditProvider interface. WebLogic Server sends the class security events, such as failed login attempts and rejected certificates. Your implementation selects events of interest and takes any actions you want, such as logging messages or sending email.

• You can implement the weblogic.security.net.ConnectionFilter interface to examine client connections and accept or reject them, based on their origin (host name or network address) and protocol.

• The "everyone" group automatically includes all users. Calling isMember() on the "everyone" group always returns true. Be sure this is the behavior you expect before you grant permissions to "everyone".

• The weblogic.properties file, as distributed, registers several Admin servlets and defines Acls that allow only the "system" user to execute them. For example:

  weblogic.httpd.register.AdminMain=adminMain
  weblogic.httpd.register.AdminRealm=adminRrealm
  .  .  .
  weblogic.allow.execute.weblogic.servlet.AdminMain=system
  weblogic.allow.execute.weblogic.servlet.AdminRealm=system

  Review these servlets to determine which, if any, you want to have registered in your deployed system.