Connection Filtering

At the connection level, WebLogic provides two security features: filtering and SSL. Chapter 16 provides a detailed look at SSL. Let's take a look at connection filtering here. A connection filter allows the server to reject unwanted connections based on some criteria. For example, a connection filter would allow you to configure WebLogic to permit T3 or IIOP connections only from within your intranet, and reject any T3 or IIOP connection request from outside the intranet. So, connection filtering provides network-level access control.

WebLogic comes equipped with a default connection filter that examines one or more connection filter rules defined in the Administration Console. Alternatively, you can create your own custom connection filter that evaluates the basis that incoming connections are accepted by the server. A custom connection filter is a Java class that implements WebLogic's ConnectionFilter interface. The interface is dead simple the class must implement the accept( ) method, which simply throws a FilterException to indicate that an incoming connection request should not be allowed through. Here is an example of a connection filter that refuses T3 connections from hosts unless their IP address matches 10.*.*.*:

import weblogic.security.net.*;

public class MyConnectionFilter implements ConnectionFilter {
 public void accept(ConnectionEvent evt) throws FilterException {
 if ( evt.getProtocol( ).equals("t3") ) {
 byte [] addr = evt.getRemoteAddress( ).getAddress( );
 if ( !(addr[0]==10))
 throw new FilterException( );
 }
 };
}

This filter simply throws a FilterException whenever the filter criteria have been violated. If the method completes without throwing any exceptions, the connection is allowed through. The method receives a single parameter, a ConnectionEvent object, that encapsulates vital information about the connection request. Typically, you will use this information to implement the acceptance criteria for the filter. The ConnectionEvent class provides various methods to access this information:

getProtocol( )

Retrieves a string value that represents the protocol used to establish the connection.

getRemoteAddress( )

Retrieves a java.net.InetAddress object that represents the client's address.

getRemotePort( )

Returns the client's port number used to establish the connection.

getLocalAddress( )

Retrieves a java.net.InetAddress object that represents the server's listen address.

getLocalPort( )

Obtains the server's port number to which the connection is being made.

Once you have compiled the filter class, you need to install it. First, you need to ensure the class can be located from the server's classpath. Then, using the Administration Console, expand the topmost node indicating your domain and choose the View Domain-Wide Security Settings option. The Configuration/Filter tab contains the settings for connection filters. WebLogic 7.0 users should select the Security/Filter tab after expanding the domain node from the left pane.

Enter the name of your connection filter class in the Connection Filter setting. You will also notice the Connection Filter Rules setting. Use this option if your filter class also implements the optional ConnectionFilterRulesListener interface. In this case, the connection filter will be able to receive and process filter rules defined in the Administration Console.

17.2.1 The Default Connection Filter

WebLogic comes preconfigured with a useful connection filter that can process a number of filter rules defined using the Administration Console in the Connection Filter Rules setting. The connection filter attempts to match an incoming connection against all the rules, beginning from the first rule in the list. If a matching rule is found, the connection is allowed (or disallowed) depending on the rule's action. If no matching rule is found, the incoming connection is permitted.

You can specify any number of rules; each rule should be on a single line. The syntax for a connection filter rule is shown here:

target localAddress localPort action protocolList

Here are the definitions for the parameters of a connection filter rule:

• The target parameter specifies the client hosts that the rule must examine. We discuss its syntax later.
• The localAddress parameter refers to the server's host address to which the client connects. If you specify an asterisk (*), this matches all local IP addresses.
• The localPort parameter indicates the server port to which the client connects. If you specify an asterisk (*), this matches all available ports.
• The action parameter indicates whether the rule should allow or reject the incoming connection request. It can take two possible values: allow or deny.
• Use the protocolList parameter to define a space-separated list of protocol names that should be matched. The protocol names can be: http, https, t3, t3s, giop, giops, dcom, or ftp. If no protocols are listed, the rule checks for all protocols. Versions of WebLogic 7.0 and WebLogic 8.1 also permit the ldap protocol to be specified.

You also can include a # character anywhere on the line. Any text after this character until the end of the line is treated as a comment.

A filter rule can define the target parameter in two forms:

• It can be a "fast" rule if the value for the target parameter is either a hostname or an IP address.
• It can be a "slow" rule if the value for the target parameter is a domain name.

For fast rules, you can specify either the client's hostname or IP address. The IP address can be followed by an optional netmask, the two being separated by a / character. If you supply a hostname that resolves to a list of IP addresses, the server automatically generates multiple versions of the same rule for each IP address when it boots up. These rules are called "fast" because the server eventually has a list of rules that use static IP addresses; therefore, no connect-time DNS lookups are required once the server is up and running. All hostnames are resolved to their IP addresses when the server boots and goes through all the filter rules. Here are a few examples of fast rules:

www.oreilly.com 127.0.0.1 7001 allow t3 # allow t3 requests from www.oreilly.com
10.0.20.30/255.255.0.0 127.0.0.1 7001 allow t3 t3s http https

Notice how the second filter rule uses a netmask.

For slow rules, the value for the target parameter is a domain name beginning with an asterisk (*). An asterisk may be used only at the head of the domain name. Here is an example of a slow rule:

*.oreilly.com 127.0.0.1 7001 allow t3

This rule allows incoming T3 connections on port 7001 from any client that runs on a host within the oreilly.com domain. It's called a "slow" rule because it requires a connect-time DNS lookup in order to execute the match, so it is literally slower than the fast rules.

The following rule is very handy for denying all access to your server:

0.0.0.0/0 deny # refuse the connection request

You can define this rule at the end of the list of filter rules, and thereby deny access to all connections that fail to match any of the previous rules in the list. In this way, you can ensure that an incoming connection request is allowed only if it matches one of the preceding filter rules.