Using Network Connection Filters

This section covers the following topics:

 

The Benefits of Using Network Connection Filters

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

Connection filters are particularly useful when using the Administration port. Depending on your network firewall configuration, you may be able to use a connection filter to further restrict administration access. A typical use might be 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.

Note: Implementing this interface alone does not permit the use of the Administration Console to enter and modify filtering rules to restrict client connections, rather, some other form (such as a flat file, which is defined in the Administration Console) must be used for that purpose. To use the Administration Console to enter and modify filtering rules, also implement the ConnectionFilterRulesListener interface. For a description of the ConnectionFilterRulesListener interface, see ConnectionFilterRulesListener Interface.

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

 

ConnectionFilterRulesListener Interface

The server uses this interface to determine if the rules specified in the Administration Console in the ConnectionFilterRules field are valid during startup and at runtime based on the setRules() and checkRules() methods.

Note: You can optionally implement this interface or just use the WebLogic connection filter implementation, weblogic.security.net.ConnectionFilterImpl, which is provided as part of the WebLogic Server product.

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.

Note: To be able to enter and edit connection filtering rules on the Administration Console, implement the ConnectionFilterRulesListener interface; otherwise some other means must be used. For example, you could use a flat file.

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. It implements 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. Applications use the methods provided by this class (getLocalAddress(), getLocalPort(), getRemoteAddress(), getRemotePort(), and hashcode()) to create a new ConnectionEvent instance.

For a code example of how to use this class, see Listing 6-1.

 

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.

Connection filter rules can be written in a flat file or input directly on the Administration Console, depending on how you implement connection filtering. The Network Connection Filter code examples demonstrate both methods. The Network Connection Filter code examples are http://dev2dev.bea.com/code/wls.jsp available at on the BEA dev2dev Web site.

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:

  • Each rule must be written on a single line.
  • Tokens in a rule are separated by white space.
  • A pound sign (#) is the comment character. Everything after a pound sign on a line is ignored.
  • Whitespace before or after a rule is ignored.
  • Lines consisting only of whitespace or comments are skipped.

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.

  • When entering the filter rules on the Administration Console, enter them in the following format: 
    targetAddress localAddress localPort action protocols
  • When specifying rules in the filter file, enter them in the following format: 
    targetAddress action protocols

where

    • target specifies one or more systems to filter.
    • localAddress defines the host address of the WebLogic Server instance. (If you specify an asterisk (*), the match returns all local IP addresses.)
    • localPort defines the port on which the WebLogic Server instance is listening. (If you specify an asterisk, the match returns all available ports on the server).
    • action specifies the action to perform. This value must be allow or deny.
    • protocols is the list of protocol names to match. The following protocols may be specified: http, https, t3, t3s, giop, giops, dcom, ftp. If no protocol is defined, all protocols will match a rule.

 

Types of Connection Filter Rules

Two types of filter rules are recognized:

  • Fast rules

    A fast rule applies to a hostname or IP address with an optional netmask. If a hostname corresponds to multiple IP addresses, multiple rules are generated (in no particular order). Netmasks can be specified either in numeric or dotted-quad form. For example: 

dialup-555-1212.pa.example.net  127.0.0.1 7001 deny t3 t3s  # http(s) OK 

192.168.81.0/255.255.254.0   127.0.0.1 8001 allow   # 23-bit netmask 

192.168.0.0/16   127.0.0.1 8002 deny   # like /255.255.0.0

Hostnames for fast rules are looked up once at startup of the WebLogic Server instance. While this design greatly reduces overhead at connect time, it can result in the filter obtaining out of date information about what addresses correspond to a host name. BEA recommends using numeric IP addresses instead.

  • Slow rules

    A slow rule applies to part of a domain name. Since a rule requires a connect-time DNS lookup on the client-side in order to perform a match, a slow rule may be much slower than the fast rule. Slow rules are also subject to DNS spoofing. Slow rules are specified as follows:

    *.script-kiddiez.org 127.0.0.1 7001 deny

    An asterisk only matches at the head of a pattern. If you specify an asterisk anywhere else in a rule, it is treated as part of the pattern. Note that the pattern will never match a domain name since an asterisk is not a legal part of a domain name.

 

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.

If you want 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 a network connection filter as part of the product. It is ready to use out of the box. To use it, simply configure it using the Administration Console. For information on how to configure connection filters, see Managing WebLogic Security.

 

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:

  1. Write a class that implements the ConnectionFilter interface (minimum requirement).

    Or, optionally, if you want to use the Administration Console to enter and modify the connection filtering rules directly, write a class that implements both the ConnectionFilter interface and the ConnectionFilterRulesListener interface.

  2. If you choose the minimum requirement in step 1 (only implementing the ConnectionFilter interface), enter the connection filtering rules in a flat file and define the location of the flat file in the class that implements the ConnectionFilter interface. Then use the Administration Console to configure the class in WebLogic Server. For instructions for configuring the class in the Administration Console, see the Configuring Connection Filtering" section in Managing WebLogic Security. For an example of how to use a flat file to implement connection filtering, see the SimpleConnectionFilter.java file in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.
  3. If you choose to implement both interfaces in step 1, use the Administration Console to configure the class and to enter the connection filtering rules. For instructions on configuring the class in the Administration Console, see Configuring Connection Filtering" in Managing WebLogic Security. For an example of how to use the ConnectionFilterRulesListener interface to implement connection filtering, see the SimpleConnectionFilter2.java file in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.

Notes: 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, GIOP, GIOPS, DCOM, or FTP). 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

Two connection filter examples are available for use with WebLogic Server. Both examples provide an efficient, generalized connection filter. To download the connection filter examples, go to http://dev2dev.bea.com/code/wls.jsp. Both examples parse the rules and set 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 may, 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.html file included with in the Network Connection Filter code examples.

This section covers the following topics:

 

SimpleConnectionFilter Example

The examples.security.net.SimpleConnectionFilter example is included in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site. This example implements the ConnectionFilter interface and filters connections using rules that you define in the filter file.

 

SimpleConnectionFilter2 Example

The examples.security.net.SimpleConnectionFilter2 example is included in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site. This example implements the ConnectionFilter and ConnectionFilterRulesListener interfaces and filters connections using the rules that you define using the Administration Console.

 

Example of the accept Method Used in Filtering Network Connections

In Listing 6-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 examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.

Listing 6-1 Example of Filtering Network Connections 

  public void accept(ConnectionEvent evt)


  throws FilterException


{


  InetAddress remoteAddress = evt.getRemoteAddress();


  String protocol = evt.getProtocol().toLowerCase();


  int bit = protocolToMaskBit(protocol);


  // this special bitmask indicates that the


  // connection does not use one of the recognized 


  // protocols


  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;


}

Skip navigation bar  Back to Top Previous Next