Securing Best Practices

The section discusses WebLogic Server technologies and business practices to increase security of Web applications, WebLogic Server, and the hardware that supports your servers.

Setting User Lockout

With every realm, WebLogic Server provides attributes for protecting user account against dictionary attacks. Dictionary attacks occur when hackers attempt to log in as a user by guessing a password using every word in a dictionary. The user lockout attributes define incorrect logins and what behavior causes accounts to be locked.

These attributes are initially set to the highest level of protection. To change these settings, click on the realm name in the admin console and then click on the User Lockout tab in the right panel. This will display the Security Passwords form as shown in Figure 28.21. The most pertinent attributes are

• Lockout Enabled— If checked, user accounts are capable of being locked from access.

• Lockout Threshold— The maximum number of consecutive invalid login attempts before the account is locked. Default is 5.

• Lockout Duration— When locked, how many minutes the account is locked for.

• Lockout Reset Duration— The number of minutes in which consecutive invalid login attempts must occur for account to be locked.

After a user account has been locked, it can be unlocked. To do this in the admin console, click on the appropriate server on the left pane and then on the Monitoring tab in the right pane. Click on the Security tab and list the user that is locked. The Security details form will be displayed as shown in Figure 28.22. Click the Unlock button and that user will again be able to log in.

Connection Filtering

Connection filters allow WebLogic Server to accept or reject client connections based on their origin and the protocol used. This provides an extra level of security against unauthorized access and denial of service (DoS) attacks. Unfortunately, to implement this feature, you must obtain Java code that implements the ConnectionFilter and the ConnectionFilterRulesListener interfaces. WebLogic Server comes with examples for this in the examples.security.net package. For more information about using connection filters, please refer to http://e-docs.bea.com/wls/docs81/security/con_filtr.html.

BEA Dev2Dev Advisories and Notifications

From time to time, BEA releases patches for WebLogic Server that address security-related issues. You can sign up to be notified when new patches are released by entering your information at http://contact2.bea.com/bea/www/advisories/login.jsp. To view recent notifications, go to http://dev2dev.bea.com/resourcelibrary/advisories.jsp?highlight=advisoriesnotifications.

Securing the WebLogic Server Machine and File Systems

There's no point in configuring the WebLogic Server security framework without securing the actual machines that are running WebLogic Server. Hiring a security expert to ensure there are no weaknesses that would enable a hacker to access these machines through either operating system or applications loopholes is recommended.

You should create an OS-level user that will be the only user able to execute WebLogic Server and be able to view and modify WebLogic Server directories and files. Avoid sharing these files and directories with user accounts on other machines. This decreases the chances of creating security loopholes for hackers.

Machines executing WebLogic Server should be kept in a secured environment where unauthorized users will not have physical contact with the machine or its network connections.

Do not install development tools on a production machine so as to give hackers a chance to execute utilities such as Java and EJB compilers. In short, keep the number of applications and utilities on a production machine to a bare minimum.

Protecting Network Connections

Connections between the Internet, a Web server, WebLogic Server, databases, and EIS instances should be protected with firewalls. These firewalls should allow only protocols that clients should be using. For instance, a Web server should allow only HTTP and HTTPS connections and disallow any other protocols. Additionally, stateful firewalls can ensure that communications originating from your facility are in response to a client request and not from rogue code that's communicating with the hacker who placed it in your infrastructure. Of course, having this many firewalls does add cost and reduces performance of your infrastructure. What's needed is a balanced approach among security, cost, and performance. At the very least, a DMZ (demilitarized zone) should be created between the Internet and your IT infrastructure through the use of a single firewall.

Preventing Denial of Service Attacks

A denial of service (DoS) attack prevents legitimate users access to WebLogic Server applications and resources. Hackers usually accomplish this type of attack by sending WebLogic Server an enormous number of requests that can either be slow to respond to, are incomplete, or are very large. WebLogic Server can be configured to reduce the opportunities hackers have to cause DoS attacks.

To configure these options, expand the Servers node in the left panel of the administrator console and click on the server name. Click on the Protocols tab. This will display the Connection Protocols form shown in Figure 28.23.

For each of the T3, HTTP, IIOP, and COM protocols, a system administrator can set up a channel that restricts the maximum message size allowed and how long to wait before a complete message is delivered. Reducing the maximum message size restricts the amount of memory that WebLogic Server allocates. Reducing the message timeout guards against messages that never complete and take up WebLogic Server resources. Channels are a new feature of WebLogic Server 8.1 to allow more than one network interface card (NIC) to disperse traffic and to listen for requests on multiple ports. Each WebLogic Server can have multiple channels configured, but it must have a unique combination of protocol, listen address, and port.

Additional attributes specific to HTTP can be set in the Connections HTTP form shown in Figure 28.24. To configure these options, expand the Servers node in the left panel of the administrator console and click on the server name. Click on the Protocols tab in the right panel and then click on the HTTP tab.

The Post Timeout Secs setting determines how many seconds to wait between reading HTTP POST data. Some DoS attacks attempt to overload the server with HTTP POST data. Making this value higher gives WebLogic Server more time to digest the information and not overload its resources. The Max Post Time setting determines how long to wait for an HTTP POST operation to complete before timing it out. Some hackers send many incomplete HTTP POST requests, which can lock up the server—reducing this number frees up resources for other client requests. Max Post Size determines the largest chunk amount of HTTP POST data that WebLogic Server will accept. Hackers might try to overload the server with huge requests. Reducing this number reduces opportunities for WebLogic Server to be overloaded.

Turning On Auditing

When auditing is turned on, auditing events such as invalid logins are logged. Checking this log will show patterns of hacker activity. Setting up an audit provider turns on auditing. In the admin console, expand your default security realm, expand the Providers node, and click on the Auditing node. In the right panel, click on the Configure a new Default Auditor link. This enables you to use the WebLogic-supplied auditing security provider. You will then see the form for creating a new default auditing provider as shown in Figure 28.25.

Set the severity level you're interested in and click the Create button. You must then restart WebLogic Server for auditing to take place. Once auditing is turned on, the auditor will create and fill a log file at WL_HOME\yourdomain\DefaultAuditRecorder.log.

Additional Security Recommendations

For additional security recommendations, refer to the "Best Practices to Address Security Risks" section of Chapter 26, "Web Applications and Security," and at http://e-docs.bea.com/wls/docs81/lockdown/practices.html.