Programming WebLogic Security

Using Network Connection Filters

This section covers the following topics:

The Benefits of Using Network Connection Filters

Security roles and security policies let you secure WebLogic resources at the domain level, the application level, and the application-component level. Connection filters let you deny access at the network level. Thus, network connection filters provide an additional layer of security. Connection filters can be used to protect server resources on individual servers, server clusters, or an entire internal network.

Connection filters are particularly useful for controlling access through the Administration port. Depending on your network firewall configuration, you might be able to use a connection filter to further restrict administration access. A typical use is to restrict access to the Administration port to only the servers and machines in the domain. Even if an attacker gets access to a machine inside the firewall, they will not be able to perform administration operations unless they are on one of the permitted machines.

Network connection filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names. For example, you can deny any non-SSL connections originating outside of your corporate network. This would ensure that all access from systems on the Internet would be secure.

Network Connection Filter API

This section describes the weblogic.security.net package. This API provides interfaces and classes for developing network connection filters. It also includes a class, ConnectionFilterImpl, which is a ready-to-use implementation of a network connection filter. For more information, see Javadocs for WebLogic Classes for this release of WebLogic Server.

This section covers the following topics:

Connection Filter Interfaces

To implement connection filtering, write a class that implements the connection filter interfaces. The following weblogic.security.net interfaces are provided for implementing connection filters:

ConnectionFilter Interface

This interface defines the accept() method, which is used to implement connection filtering. To program the server to perform connection filtering, instantiate a class that implements this interface and then configure that class in the Administration Console. This interface is the minimum implementation requirement for connection filtering.

For code examples that demonstrate of how to use this interface, see Connection Filter Examples.

ConnectionFilterRulesListener Interface

The server uses this interface to determine whether the rules specified in the Administration Console in the ConnectionFilterRules field are valid during startup and at runtime.

This interface defines two methods that are used to implement connection filtering: setRules() and checkRules(). Implementing this interface in addition to the ConnectionFilter interface allows the use of the Administration Console to enter filtering rules to restrict client connections.

For a code example of how to use this interface, see Connection Filter Examples.

Connection Filter Classes

Two weblogic.security.net classes are provided for implementing connection filters:

ConnectionFilterImpl Class

This class is the WebLogic connection filter implementation of the ConnectionFilter and ConnectionFilterRulesListener interfaces. Once configured using the Administration Console, this connection filter accepts all incoming connections by default, and also provides static factory methods that allow the server to obtain the current connection filter. To use this connection to deny access, simply enter connection filter rules using the Administration Console.

This class is provided as part of the WebLogic Server product. To configure this class for use, see Configuring the WebLogic Connection Filter.

ConnectionEvent Class

This is the class from which all event state objects are derived. All events are constructed with a reference to the object, that is, the source that is logically deemed to be the object upon which a specific event initially occurred. To create a new ConnectionEvent instance, applications use the methods provided by this class: getLocalAddress(), getLocalPort(), getRemoteAddress(), getRemotePort(), and hashcode().

For a code example of how to use this class, see Listing 7-1, Example of Filtering Network Connections, on page 7-9.

Guidelines for Writing Connection Filter Rules

This section describes how connection filter rules are written and evaluated. If no connection rules are specified, all connections are accepted.

Depending on how you implement connection filtering, connection filter rules can be written in a flat file or input directly on the Administration Console. The Connection Filter Examples on page 7-8 demonstrate both methods.

The following sections provide information and guidelines for writing connection filter rules:

Connection Filter Rules Syntax

The syntax of connection filter rules is as follows:

The format of filter rules differ depending on whether you are using a filter file to enter the filter rules or you enter the filter rules on the Administration Console.

Types of Connection Filter Rules

Two types of filter rules are recognized:

How Connection Filter Rules are Evaluated

When a client connects to WebLogic Server, the rules are evaluated in the order in which they were written. The first rule to match determines how the connection is treated. If no rules match, the connection is permitted.

To further protect your server and only allow connections from certain addresses, specify the last rule as:

0.0.0.0/0  *  *  deny

With this as the last rule, only connections that are allowed by preceding rules are allowed, all others are denied. For example, if you specify the following rules:

<Remote IP Address> * * allow https
0.0.0.0/0  *  *  deny

Only machines with the Remote IP Address are allowed to access the instance of WebLogic Server running connection filter. All other systems are denied access.

Configuring the WebLogic Connection Filter

WebLogic Server provides an out-of-the-box network connection filter. To use the filter, simply configure it using the Administration Console. For information on how to configure connection filters, see Securing WebLogic Server.

Developing Custom Connection Filters

If you decide not to use the WebLogic connection filter and want to develop you own, your can use the application programming interface (API) provided in the weblogic.security.net package to do so. For a description of this API, see Network Connection Filter API.

To develop custom connection filters with WebLogic Server, perform the following steps:

Note that if connection filtering is implemented when a Java or Web browser client tries to connect to a WebLogic Server instance, The WebLogic Server instance constructs a ConnectionEvent object and passes it to the accept() method of your connection filter class. The connection filter class examines the ConnectionEvent object and accepts the connection by returning, or denies the connection by throwing a FilterException.

Both implemented classes (the class that implements only the ConnectionFilter interface and the class that implements both the ConnectionFilter interface and the ConnectionFilterRulesListener interface) must call the accept() method after gathering information about the client connection. However, if you only implement the ConnectionFilter interface, the information gathered includes the remote IP address and the connection protocol: http, https, t3, t3s, ldap, ldaps, iiop, iiops, or com. If you implement both interfaces, the information gathered includes the remote IP address, remote port number, local IP address, local port number and the connection protocol.

Connection Filter Examples

This section refers to sample code which is available online at BEA’s dev2dev web site. The net directory contains ant build files, a package.html file which contains instructions, a connection filter file, and the following Java files which include examples of two connection filters:

Each connection filter example provides an efficient, generalized connection filter which parses the rules and sets up a rule-matching algorithm so that connection filtering adds minimal overhead to a WebLogic Server connection. If necessary, you can modify this sample code and reuse it. You might, for example, want to accommodate the local or remote port number in your filter or a more site-specific algorithm that will reduce filtering overhead. For instructions on how to build, configure, and run these samples, see the package-summary.html file included with in the examples.

The SimpleConnectionFilter example implements the ConnectionFilter interface and filters connections using rules that you define in the filter file.

public class SimpleConnectionFilter implements ConnectionFilter {
  public static final String FILTER_FILE = "filter";

  private FilterEntry[] rules;
  ...

The SimpleConnectionFilter2 example implements the ConnectionFilter and ConnectionFilterRulesListener interfaces and filters connections using the rules that you define using the Administration Console.

public class SimpleConnectionFilter2
  implements ConnectionFilter, ConnectionFilterRulesListener {

  private FilterEntry[] rules;
  private Vector entries;
  ...

In Listing 7-1, WebLogic Server calls the SimpleConnectionFilter.accept() method with a ConnectionEvent. The SimpleConnectionFilter.accept() method gets the remote address and protocol and converts the protocol to a bitmask to avoid string comparisons in rule-matching. Then the SimpleConnectionFilter.accept() method compares the remote address and protocol against each rule until it finds a match.

This code fragment is taken from the SimpleConnectionFilter.java file in the Network Connection Filter code example.

  public void accept(ConnectionEvent evt)
    throws FilterException
  {
    InetAddress remoteAddress = evt.getRemoteAddress();
    String protocol = evt.getProtocol().toLowerCase();
    int bit = protocolToMaskBit(protocol);

     if (bit == 0xdeadbeef)
    {
      bit = 0;
    }
    // Check rules in the order in which they were written.
    for (int i = 0; i < rules.length; i++)
    {
      switch (rules[i].check(remoteAddress, bit))
      {
      case FilterEntry.ALLOW:
         return;
      case FilterEntry.DENY:
         throw new FilterException("rule " + (i + 1));
      case FilterEntry.IGNORE:
         break;
      default:
         throw new RuntimeException("connection filter internal error!");
      }
    }
    // If no rule matched, we allow the connection to succeed.
    return;
  }