Production Security Strategies


In this section, we will review some of the key concepts and practices associated with locking down and securing your WebLogic Server installation above and beyond the WebLogic Server and J2EE security topics covered in Chapter 10. First, we will review the importance of understanding your application architecture and the potential security threats. We ll then proceed to discuss firewall and DMZ design, connection filtering, locking down Web applications, some miscellaneous security practices, and SSL acceleration approaches.

Understanding Application Data Flow

It s important to first understand the underlying data flow of your application architecture to better define the overall network layout and potential security threats. Once this review is complete you can begin defining and mapping application security requirements to the WebLogic Server security services and J2EE security features. As discussed in Chapter 10 and depicted in Figure 10.1, two general types of clients will be calling into the server: Web, or thin , clients and application, or fat , clients.

The first client type is the thin client, typically a browser or other Web Services client. Thin clients may call in to the application via the HTTP protocol using direct connections with the WebLogic Server or through a Web server running a WebLogic Server proxy plug-in component. Thin clients normally call Web application components and Web services in the server s servlet engine.

The second client type is the fat client, or application client. Fat clients may use the HTTP, T3, IIOP, or COM protocols to call directly into the server, invoking Web application components, Web services, EJB components, or JMS services in the server. Both thin- and fat-client calls can be routed through a single firewall or a set of firewalls for security. We will talk about suggested firewall layouts later in this section.

To define the specific security threats, also known as the threat model , you need to define both what you are protecting and who you are protecting it from. Once you have identified all of the client types and request paths for your application, you should then identify the data and operations on the server that they will be accessing and the required security for those resources. The security requirement could be as simple as requiring only SSL connections for all authentication or as complex as requiring an X.509 client certificate signed by a specific certificate authority for access. Consider each type of operation or data that will be used by clients and the ramifications if that resource were compromised in some way. Once you understand the security requirements for the server-side data and operations, the various clients, and the network types they will use, you have defined your threat model.

Note  

One assumption we make in this discussion is the security of the underlying machine on which WebLogic Server runs. The physical security of the machine, the operating system, the user accounts on the machine, and other programs running on the machine, is critical to good security and should be thought through meticulously.

Understanding Firewall Layouts

Firewalls provide a high level of security from untrusted traffic if used and configured properly. In this section, we will discuss the positives and negatives of some of the common firewall layouts used to separate corporate resources from the Internet and provide a layered security approach. The specific firewall used in this discussion could be any of the major firewall types. The most basic firewall is a stateless, packet-filtering firewall that performs network address translation (NAT). You can also use the more complex, stateful, packet-inspection firewalls if circumstances warrant their use. Regardless of type, by grouping our network layout in firewalls, we define specific, contiguous regions of a network that operate under a single, uniform security policy.

Another important point about using NAT firewalls is that you need to configure your WebLogic Server instances to be aware of the external addresses that the clients use to contact WebLogic Server. See Chapter 11 for a thorough discussion of this topic.

The simplest and most common firewall layout is a single perimeter firewall protecting the entire application from the untrusted zone, a configuration depicted in Figure 14.9. This untrusted zone might be the Internet, your company s extranet, or even anything outside your data center. This layout is typical of a small enterprise or division. The disadvantage of a single firewall is the lack of a layered approach to security ”a single implementation flaw or configuration error in the firewall can lead to a complete loss of security.

click to expand
Figure 14.9:  Single perimeter firewall layout.

Some corporate security policies can be very strict and may require several well-defined network regions, commonly referred to as demilitarized zones (DMZs), having their own security policies. The concept is simple: Putting servers or network appliances, with or without application code, in the DMZ limits your overall security exposure if the machines in that area were somehow compromised. A DMZ could include anything from only a router or hardware load balancer to the entire application; in the latter case, the application has a lower level of protection than other corporate resources not in the DMZ. Typically, the DMZ contains only a hardware load balancer and/or Web servers configured with a WebLogic Server Web server plug-in. Figure 14.10 shows a conceptual overview one of the most common configurations.

Of course, we have barely scratched the surface of what is possible with firewall configuration. Most companies have their own policies about how the network should be laid out. Therefore, we will move on to talk about connection filters.

Using a Connection Filter

One of the first rules of security is to refuse connections from unknown or untrusted sources, denying these sources any foothold in the environment. Connection filters are a powerful way to control the types of connections accepted by WebLogic Server instances, providing a programmatic control over every new connection with the server. There are two primary ways to configure a connection filter: use the built-in connection filter in WebLogic Server or write a custom implementation of the ConnectionFilter interface.

WebLogic Server s Built-In Connection Filter

The first and easiest way to filter connections uses WebLogic Server s built-in connection filter facility. You can enable and configure this facility using the Security folder s Filter Configuration tab in the WebLogic Console by defining rules that govern the types and sources of network connections to be accepted or denied. By default, there are no rules defined in the built-in connection filter, so all connections are accepted. Rules are very specific in format, and ordering is also very important. The first matching rule wins, even if another rule further down contradicts it. Because performance can also be a concern, place more general rules at the top of the list to allow most new connections to be identified quickly and allowed or denied .

Each rule is defined using the following syntax:

 target localAddress localPort action [protocols]+ 

The target parameter defines the source IP address, including any subnet mask, to be filtered; the localAddress and localPort parameters define the WebLogic Server IP address and port for this rule, making it possible to filter connections on some network channels and not on others. You must set the action argument to either allow or deny , and the optional protocols parameters must be one or more of the following values: http , https , t3 , t3s , giop , giops , dcom , or ftp .

click to expand
Figure 14.10:  Typical DMZ firewall layout.

Let s look at a couple of examples. Imagine that you want to restrict access to any port on your WebLogic Server listening on 216.148.48.51 to anyone using an IP address that starts with 192.168 for both the HTTP and IIOP protocols. The following entry would accomplish this:

 192.168.0.0/255.255.0.0 216.148.48.51 * deny http giop 

You can also block access specifically to port 7001 on your site to anyone trying to access the site from any host in the baddomain.com domain. The following entry accomplishes this by denying access regardless of the protocol:

 *.baddomain.com 216.148.48.51 7001 deny 

Note that this rule requires a run-time DNS lookup to evaluate the rule properly for each network connection attempt, potentially creating a performance problem. Try to use IP addresses rather than domain names whenever possible.

This rule-based technique for configuring the connection filter provides significant flexibility. By combining allow and deny rules, you can configure the connection filter to refuse connections of certain types, perhaps http or t3 , from all external IP addresses while allowing these connections from other servers in the cluster, Web servers, or hosts in the corporate LAN subnet.

Custom Connection Filters

The second way to filter connections involves writing a custom implementation of the weblogic.security.net.ConnectionFilter interface and configuring WebLogic Server to use this filter rather than the built-in connection filter. Your custom implementation class will receive a ConnectionEvent object via the accept() callback method whenever a new connection attempt takes place. This ConnectionEvent object contains information regarding the inbound connection, including the remote address and port, the local address and port, and the protocol. Your implementation of the accept() method should interrogate this object and determine whether to accept the connection, returning from the method without an exception if the connection should be accepted and raising a FilterException if the connection should be refused .

What follows is an example implementation of the ConnectionFilter interface that accepts all connections from the IP address 127.0.0.1 but refuses all other connection attempts:

 class SimpleConnectionFilter implements ConnectionFilter  {     public void accept(ConnectionEvent event)         throws FilterException      {         String target =             event.getRemoteAddress().getHostAddress();         if (! 127.0.0.1.equals(target))             throw FilterException(Connection refused!);     } } 

Locking Down Web Applications

Several security considerations related to Web applications are not obvious and can lead to confusion if not understood . This section will supplement the general security information in Chapter 10 with some additional topics related to Web applications.

Access-Control Checks during Server-Side Forwards

A Web application deployed on WebLogic Server will restrict access to specific pages and resources based on the various security-constraint elements defined in its web.xml deployment descriptor. If the Web application sends an HTTP redirect to the client with a new resource URL, the client will send a new request to the server for the new URL. This second request will be required to pass any access-control checks using the same security-constraint elements in the deployment descriptor.

If the Web application does a server-side forward to a new resource URL, however, the client is never involved and no second request is made and checked against the security constraints. The same HTTP request is simply moved on to the next resource on the server side, evading a full access-control check. You can configure the Web application to perform a full access-control check for all server-side forwarding using the check-auth-on-forward element in the WebLogic-specific weblogic.xml deployment descriptor:

 <weblogic-web-app>   <container-descriptor>   <  check-auth-on-forward/  >   </container-descriptor>   ... </weblogic-web-app> 

Session ID Cookies Safety

Web applications that run over both secure (HTTPS) and insecure (HTTP) sockets must be designed very carefully to avoid compromising the session ID stored in the cookie. Recalling previous discussions in Chapter 1 and elsewhere, the cookie is a token that is generated on the server and sent to the browser client for the purposes of identifying that browser session during subsequent HTTP requests . The browser will resend the cookie with every subsequent request it makes to that domain, and the server will identify the client by the uniquely generated session ID contained in the cookie. In other words, if the browser has authenticated itself, either via FORM or BASIC HTTP authentication, the session ID in the cookie serves as the only information the server needs for proof of the client s identity.

The problem is that if a user begins accessing a Web application over a plain-text, or insecure, socket, the cookie and the session ID in it are sent in plain text in the HTTP headers. This scenario is very common, and it could represent something like a catalog and shopping-cart area in an e-commerce site where it is perfectly acceptable to begin the session over plain text as no private information is being sent over the wire.

The real security problem occurs if the Web application later switches to a secure socket and allows the same cookie and session ID to be used during secure operation, the default behavior of a Web application. Continuing the e-commerce example, the site might switch to secure mode once a shopping cart is full and the user must log in or provide credit-card information to complete the transaction. This new user information and authentication context is still associated with the original session ID and cookie transmitted over plain text even though the secure protocol was used to perform the subsequent authentication or data-gathering steps. This is obviously a major concern because anyone who sniffed , or intercepted, the original session ID from the plain-text socket cookie can now impersonate the newly authenticated user with it, perhaps gaining access to user information or the data gathered during the secure communication. Note that the problem described here is nothing specific to WebLogic Server, but rather a problem in the way secure and insecure HTTP communication is used in typical Web applications.

The best solution to this insecure cookie problem involves designing your Web application to avoid it completely by splitting your Web application into two separate applications: an insecure portion and a secure portion. The first application would, for example, contain all of the catalog and shopping-cart functionality in your e-commerce site, establishing a user session and providing the session ID in a plain-text cookie. The second application would use a separate secure-only cookie and provide the secure authentication and data-gathering steps required for checkout. Data gathered during the insecure shopping-cart application would have to be supplied to the secure application via some mechanism other than the HttPSession because this would not be shared across the two applications. Alternatives include POST parameters referring to database-based storage or some other form of server-side storage.

To implement this solution you must first create two separate Web applications and scope the cookies to each Web application rather than allowing them to be global, domain-specific cookies. If the cookies are global, the default setting, the same session ID will be used across all Web applications in the server. You need to defeat this cookie sharing by declaring the cookie in the second, secure Web application to be a secure-only cookie using the following stanza in the weblogic.xml descriptor file for that application:

 <session-param>   <param-name>CookieSecure</param-name>   <param-value>true</param-value> </session-param> 

You should also scope the Web application cookie by setting the CookiePath for the WebLogic Server session cookie to include the Web application context rather than the global / value alone. You can accomplish this using the following entry in the session-descriptor element of the weblogic.xml deployment descriptor:

 <session-param>   <param-name>CookiePath</param-name>   <param-value>/mywebapp</param-value> </session-param> 

To further complicate matters, different browsers exhibit different cookie behavior when combining secure and insecure cookies for the same domain. Browsers store many cookies from various sites and will typically store these cookies in a table either in memory or on disk. Some browsers keep a single table for both secure and insecure cookies, and if a new secure-only cookie comes in from a domain, it overrides any previous cookie from that domain ”for example, Netscape uses this strategy. Other browsers, like Internet Explorer, keep two tables, one secure and one plain text. This means that if a new secure-only cookie comes in from a domain, it is stored in addition to the previous plain-text cookie. This is troublesome because if that two-table browser moves back to a plain-text socket (HTTP) communication mode, the original plain-text cookie and session ID will be used and not the new secure one. This can result in an authentication failure if the server has already invalidated the insecure cookie, although it does prevent the secure cookie from being sent over an insecure socket connection.

Examining Other Security Considerations

This section offers additional recommendations and best practices for locking down various parts of a WebLogic Server installation. These include the following:

Use separate development and production systems.    This eliminates any inconveniences associated with production-environment security during application development and early-stage testing. Areas such as the physical security of the machine, the operating system, the user accounts on the machine, and other programs running on the machine should all be as secure as you can make them. Having separate environments and a specific transfer audit will significantly reduce the risks of improper installation often associated with vulnerabilities.

Precompile all Java Server Pages (JSPs) on the production system.    Some corporate security policies do not allow any source code on live systems. By using the weblogic.jspc or weblogic.appc utilities to precompile all JSPs, you not only improve the initial response time of the Web application but also have a cleaner security audit. To totally eliminate the need for JSP source files on your production system, you would need to register all of the JSP-generated servlets and their corresponding URL mapping in the web.xml deployment descriptor, just as you would any other servlet.

Use JSP comments rather than HTML comments.    Also consider using only JSP comments in your JSP code, as the JSP comments are removed from the final class at compile time whereas HTML comments are sent to the client and may provide internal implementation details.

Use SSL/TLS whenever possible.    While it is certainly true that the performance of SSL is not as good as a plain-text socket, the security benefit cannot be overlooked. SSL is a top-heavy protocol. The initial handshake, which uses asymmetric cryptography, is the real performance bottleneck. After the handshake is complete a shared secret exists, and better-performing symmetric cryptography is used. This is why it is important to understand SSL session resumption, a technique that allows an SSL client to remember specific SSL session information for reuse when connecting back to an SSL server. The client will then be able to present its SSL session information to the server and skip the expensive SSL handshake.

Use the best possible SSL strength.    The default installation of WebLogic Server represents an exportable-strength SSL implementation. This means that the maximum SSL strength is 512-bit keys with 40-bit bulk encryption, levels not considered safe for many businesses. A stronger, domestic-strength WebLogic Server can be requested through your BEA sales representative.

Using two-way SSL can prevent man-in-the-middle attacks.    If possible, distribute client certificates and set up the server to verify them. By telling the server which certificate authority to use, you know precisely what SSL clients are connecting to the server. This is commonly called a public key infrastructure (PKI). While some significant management concerns are associated with PKI, the authentication is very secure and could be worth the management and configuration investment.

Modify the time-out and maximum size values for the incoming protocol ports on the server to prevent denial-of-service attacks.    The values for some of the main server protocols of T3, HTTP, COM, and IIOP can be adjusted via the server s Protocols tab in the WebLogic Console. The settings are located in the Advanced Options section of the General , HTTP , jCOM , and IIOP subtabs, respectively. The default time-outs are typically acceptable, but the default maximum message size should likely be lowered for each of the protocols, subject to the needs of your business applications.

Understand the user-password lockouts.    The default user-password lockout values are probably fine, but looking them over is always a good idea. This configuration resides in the security realm s User Lockout tab in the WebLogic Console. If a user does become locked out, you can manually unlock the account before the lockout time is up using the server s Security Monitoring tab.

Use the underlying operating system file system security to protect the various applications and libraries of the WebLogic Server.    While we have already recommended running with a secure and audited operating system on your production environment, you can also gain superior protection for the applications by using the file system security. Adjusting the ownership of the applications directory for access only by the user account that runs the server can be very helpful, and never install or run your WebLogic Server software as root . If you need to bind to a privileged port, make sure to configure the server to switch to a nonroot user using the machine s General Configuration tab in the WebLogic Console.

Use external system security facilities when possible.    When connecting to a database from the WebLogic Server, you should enunciate a username and credential to use. By locking down the database to that specific user, you have reduced the threat against the database significantly. Using a firewall around the database will also limit the threat. The same recommendations hold true for any type of external system we might use from the WebLogic Server. Many back-end EIS systems have credentials applied via the Credential Mapper in the WebLogic Server security framework.

Audit the WebLogic Server log file often.    By routinely monitoring the WebLogic Server system log and the security audit log, you will become familiar with normal operation and be able to identify abnormal use more readily. Without a baseline to compare against, the usefulness of the log files and audit trails is greatly reduced. You might also consider using the audit provider in the security framework as a nonrepudiation framework, useful in case an attack succeeds and legal proof of identity is required.

Have a security audit performed by an internal or external auditing group .     This can help catch security flaws overlooked in the design, implementation, or deployment of an application. An audit can also qualify the current application deployment and help develop a longer- term security policy for your group or company.

BEA Systems has an email notification list for vulnerabilities found on the WebLogic Server platform. Email notifications contain information on the vulnerability as well as patching information. This is extremely valuable information for any WebLogic Server production system. It can be found online at http://dev2dev.bea.com/resource-library/advisories.jsp .

Using SSL Hardware Acceleration

There are at least two good ways to increase your server s SSL performance:

  • Use a load balancer with built-in SSL support.

  • Run WebLogic Server on a machine having SSL hardware via the Java Cryptography Extension (JCE).

The first technique uses an external load balancer to handle the SSL. In this solution, the SSL socket is between the client and the load balancer, and all encryption and decryption take place on the load balancer s specialized hardware. The load balancer then uses the plain-text HTTP cookie in the decrypted socket to associate the session with a specific stand-alone server or a server in a cluster. This feature of load balancers is called SSL persistence , and many load balancers, such as Nortel and F5, incorporate it in their product offerings.

The second way to accelerate SSL with hardware is via the Java Cryptography Extension (JCE). The Java Cryptography Extension 1.2.2 is an optional package on JDK 1.2 and 1.3 and is part of JDK 1.4. WebLogic Server SSL packages use JCE for all cryptographic functions in the server. JCE is a pluggable framework for various cryptographic implementations . New providers for specific features can be added seamlessly and used without requiring modifications to application code. By configuring JCE with a hardware provider, WebLogic Server will be able to use accelerated cryptographic functions available on that platform. This pluggable JCE feature has been supported in WebLogic Server only since version 7.0 Service Pack 2. Prior to that, JCE providers were not configurable in any way.

One thing to remember is that to use specialized JCE hardware, the hardware, the device drivers, and the JCE classes all need to be installed and working correctly. Also note that for JDK 1.2 and 1.3, the additional JCE 1.2.2 classes and configuration files need to be downloaded and installed. See the WebLogic Server documentation at http://edocs.bea.com/wls/docs81/secmanage/ssl.html for more information about setting up JCE providers.




Mastering BEA WebLogic Server. Best Practices for Building and Deploying J2EE Applications
Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications
ISBN: 047128128X
EAN: 2147483647
Year: 2003
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net