Using Network Connection Filters

The Benefits of Using Network Connection Filters

Network connection filters act as a firewall that can be used to allow or deny access to servers in your WebLogic domain based on certain protocols, network addresses and DNS node names.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, the network connection filters provide an additional layer of security at the network level. 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

Connection filter rules allow you to limit the number of network connections that are accepted. Learn how to create effective connection filter rules and how they are evaluated.

The weblogic.security.net API package 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. See Java API Reference for Oracle WebLogic Server for complete reference information on the network connection filter API.

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 WebLogic Server Administration Console. This interface is the minimum implementation requirement for connection filtering.

Note:

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

ConnectionFilterRulesListener Interface

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

Note:

You can 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 WebLogic Server Administration Console to enter filtering rules to restrict client connections.

Note:

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

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 WebLogic Server 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 WebLogic Server 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().

Guidelines for Writing Connection Filter Rules

There are certain guidelines for writing connection filter rules. If you do not specify connection rules, then 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 WebLogic Server Administration Console.

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 WebLogic Server Administration Console.

When entering the filter rules on the WebLogic Server 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 
```
- targetAddress 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, ldap, ldaps, iiop, iiops, and com. (Although the giop, giops, and dcom protocol names are still supported, their use is deprecated as of release 9.0; you should use the equivalent iiop, iiops, and com protocol names.)
  
  Note:
  
  The SecurityConfigurationMBean provides a CompatibilityConnectionFiltersEnabled attribute for enabling compatibility with previous connection filters.
- 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 hostname. Oracle recommends using numeric IP addresses instead.
Slow rules

A slow rule applies to part of a domain name. Because a slow rule requires a connect-time DNS lookup on the client-side in order to perform a match, it may take much longer to run than a 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.

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.

Note:

The default connection filter implementation interprets a target address of 0 (0.0.0.0/0) as meaning "the rule should apply to all IP addresses." By design, the default filter does not evaluate the port or the local address, just the action. To clearly specify restrictions when using the default filter, modify the rules.

Another option is to implement a custom connection filter.

Configuring the WebLogic Connection Filter

WebLogic Server provides an out-of-the-box network connection filter, which you can configure using the WebLogic Server Administration Console.For information about how to configure connection filters, see Configure connection filtering in the Oracle WebLogic Server Administration Console Online Help.

Developing Custom Connection Filters

If you do not want to use the WebLogic connection filter and want to develop you own, you can use the application programming interface (API) provided in the weblogic.security.net package to do so.

For a description of the weblogic.security.net package, see Network Connection Filter API.

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

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

Or, optionally, if you want to use the WebLogic Server Administration Console to enter and modify the connection filtering rules directly, write a class that implements both the ConnectionFilter interface and the ConnectionFilterRulesListener interface.
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 WebLogic Server Administration Console to configure the class in WebLogic Server. For instructions for configuring the class in the WebLogic Server Administration Console, see Using Connection Filters in Administering Security for Oracle WebLogic Server.
If you choose to implement both interfaces in step 1, use the WebLogic Server Administration Console to configure the class and to enter the connection filtering rules. For instructions on configuring the class in the WebLogic Server Administration Console, see Using Connection Filters in Administering Security for Oracle WebLogic Server.

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.