Securing a Clustered Solution

When you design the physical architecture for your enterprise application using clusters of WebLogic instances, you need to determine which resources are directly exposed to external clients, and which resources need not be on the front line but instead require extra defenses. This means you need to outline a demilitarized zone (DMZ), a conceptual area of hardware and software resources that is directly exposed to the outside world. All resources that live behind the DMZ are protected. A DMZ is often created by employing a firewall, which can deny access to specific ports and IP addresses (and hence physical machines) participating in a WebLogic domain. The firewall lets you clearly define which services on which machines ought to be accessible to external clients. Generally, the smaller the extent of your DMZ, the safer your architecture is from malicious attacks.

Your application setup also impacts the scope of your DMZ. For instance, if you adopt the combined-tier architecture as illustrated earlier in Figure 14-6, you are forced to include all of the servers in the DMZ, even though you may wish to grant clients direct access only to the servlets, JSPs, and static web resources, and not to the EJBs and RMI objects deployed to the cluster. Instead, if you adopt the more complex multi-tier application setup, you have the option of physically denying access to the object tier machines, thereby excluding them from the DMZ.

Firewalls can provide network address translation (NAT) services as well, which let you hide internal IP addresses and make them inaccessible to clients on the other side of the firewall. We shall look at configuration implications of using a firewall, especially if it's configured for NAT.

14.6.1 Firewall Placement and Address Translation

Firewalls generally are placed before the web tier, presentation tier, and data tier. Figure 14-9 depicts how you can position a firewall before a bank of web servers (web tier). In this situation, the DMZ includes only the HTTP servers running on the web tier itself. That is, you can configure the firewall to permit access only to the servers in the web tier. If your application demands it, you also may configure the firewall to grant access only to the HTTP and HTTPS ports.

Figure 14-9. Firewall before the web tier

Figure 14-10 illustrates how you can place a firewall between the web and presentation tiers.

Figure 14-10. Firewall between the web and presentation tiers

A firewall between the web and presentation tiers creates a slight configuration problem if your firewall also performs NAT. Imagine that an external client performs a JNDI lookup for an RMI object. The stub returned to the client holds the addresses of the servers that host the RMI object. Because these addresses are behind the NAT layer, an external client will fail if it uses the stub to invoke a method on the RMI object. The same problem will manifest for proxy plug-ins that try to forward requests for servlets and JSPs to the presentation tier, or when WebLogic creates a session cookie that records the locations of the primary and secondary servers that maintain the client's HTTP session-state information.

To avoid these issues, you should not bind a WebLogic instance to an IP address. If you do, the internal, untranslated IP address is sent back to the external client, which is useless. Instead, you should bind your WebLogic instances to DNS names. In this way, the client can resolve the DNS name to an IP address, which then can be translated by the firewall to the internal IP address of the server that provides the required service. If your internal DNS names differ from their external DNS names, again you will have same naming problems. This issue can be resolved as well by setting the External Listen Address[1] for each WebLogic instance. This setting is located in the Configuration/General tab for each server in the Administration Console.

[1] This option is called External DNS Name in WebLogic 7.0.

14.6.2 Firewalls and Load Balancers

You may position a firewall before a load balancer. This setup greatly simplifies the firewall configuration, as the firewall needs to limit access to only the load balancer. That is, the DMZ consists of the load balancer only. Figure 14-11 depicts this configuration.

Figure 14-11. Firewall with both external and internal client access

You easily can expand this setup to support internal clients of the web and presentation/object tiers. This scenario is indicated by the dotted lines in Figure 14-11. In this case, the firewall would be configured to permit HTTP and HTTPS requests from external clients, and HTTP, HTTPS, and RMI requests from internal clients that live behind the firewall.

14.6.3 Databases

Databases also can be protected by a firewall. This provides additional security in case the frontend firewalls have been breached somehow. In this case, you could simply configure the database firewall with an application-level policy that permits only servers in the object tier (if it exists) to connect to the database. Figure 14-12 illustrates this configuration.

Figure 14-12. Firewall before the data tier