Protecting Application Server Resources

There are primarily two ways to protect application server resources: network connection filters and J2EE sandbox security. This section discussed these topics:

• Using Network Connection Filters to Protect Application Server Resources
• Using J2EE Sandbox Security to Protect Application Server Resources

 

---

Using Network Connection Filters to Protect Application Server Resources

Security policies allow you to secure WebLogic Server resources using some characteristic of a user. However, you can add an additional layer of security by using connection filters to filter network connections. For example, you can deny any non-SSL connections originating outside of your corporate network.

Network connection filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names.

This section covers the following topics:

• Connection Filter Interfaces
• Connection Filter Classes
• Guidelines for Writing Connection Filter Rules
• Configuring the Default Connection Filter
• Developing Custom Connection Filters
• Connection Filter Examples

Connection Filter Interfaces

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

• ConnectionFilter interface
• ConnectionFilterRulesListener interface

ConnectionFilter interface

This interface defines the accept() method which is used to implement connection filtering. To program the server to perform connection filtering, you must instantiate a class that implements this interface and then define that class in the Administration Console. This is the minimum implementation requirement for connection filtering. However, implementing this interface alone does not permit the use of the Administration Console to enter filtering rules to restrict client connections, rather some other form (such as a flat file, which is defined in the console) must be used for that purpose.

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

ConnectionFilterRulesListener interface

This interface defines two methods which 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, you must 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
• ConnectionEvent Class

ConnectionFilterImpl Class

This class is a default connection filter implementation. This class implements the ConnectionFilter and ConnectionFilterRulesListener interfaces. It accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter.

This class is provided ready to use as part of the WebLogic Server product. To configure this class for use, see Configuring the Default 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.

For a code example of how to use this class, see Listing 5-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, which are located in the SAMPLES_HOME\server\src\examples\security\net directory, demonstrate both methods.

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

• Connection Filter Rules Syntax
• Types of Connection Filter Rules
• How Connection Filter Rules are Evaluated

Connection Filter Rules Syntax

The syntax of connection filter rules is as follows:

• Each rule must be written on a single line in the source code.
• 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.

All rules have the following format:

target localAddress localPort action protocols 

where

• target specifies one or more servers to filter.
• localAddress defines the host address of the server. (If you specify an asterisk (*), the match returns all local IP addresses.)
• localPort defines the port on which the server 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 server startup. 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 Systems 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.

Configuring the Default Connection Filter

To configure the default connection filter, connectionFilterImpl, perform the following steps on the Administration Console:

1. Bring up the Administration Console in a browser.
2. To configure the default connection filter class, perform the following steps:
   1. Select the domain node in the left pane. The domain node is the top-level node. It is the name of your server's domain.
   2. Click on the Security Tab.
   3. Click on the Filter tab.
   4. Enter weblogic.security.net.ConnectionFilterImpl in the Connection Filter field.
   5. Enter a connection filter rule in the Connection Rules field. For example, to deny access to the node with IP address of 192.168.81.0, enter:

   192.168.81.0  127.0.0.1 7001 deny

   Where the 192.168.81.0 is the IP address of the system to be denied access, 127.0.0.1 is the IP address is system running WebLogic Server, and 7001 is the port on which access is to be denied. For more information on connection filter rules syntax, see Connection Filter Rules Syntax.

3. Click Apply.
4. Restart your server, otherwise, the connection filter does not take effect.

   Note: Subsequent changes to the connection filter rules do not require a server restart.

5. To test whether the connection filter is working, perform the following steps:
   1. Open a browser on the system that has been denied access and enter the URL for Administration Console on the system running WebLogic Server. The URL format is as follows:

   http://hostname:port/console

   For example, http://pcwiz:7001/console

   2. If you are using Internet Explorer as your browser, the message "The Page cannot be displayed" is displayed in your browser.

Developing Custom Connection Filters

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 the 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. For an example of how to use a flat file to implement connection filtering, see the SimpleConnectionFilter.java file in the SAMPLES_HOME\server\src\examples\security\net directory.
3. If you choose to implement both interfaces in step 1, use the Administration Console to configure the class in WebLogic Server and enter the connection filtering rules in the Administration Console. 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 the ConnectionFilterRulesListener interface to implement connection filtering, see the SimpleConnectionFilter2.java file in the SAMPLES_HOME\server\src\examples\security\net directory.

If connection filtering is implemented when a Java client or Web browser client tries to connect to WebLogic Server, WebLogic Server 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 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, IIOP, or IIOPS). 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 provided with the WebLogic Server software. Both examples provide an efficient, generalized connection filter. Both examples parse 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 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 in the SAMPLES_HOME\server\src\examples\security\net directory provided by WebLogic Server.

SimpleConnectionFilter Example

The examples.security.net.SimpleConnectionFilter example is included in the SAMPLES_HOME\server\src\examples\security\net directory provided by WebLogic Server. 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 SAMPLES_HOME\server\src\examples\security\net directory provided by WebLogic Server. This example implements the ConnectionFilter and ConnectionFilterRulesListener interfaces and filters connections using the rules that you define on the Administration Console.

Example of the Accept Method Used in Filtering Network Connections

In Listing 5-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 SAMPLES_HOME\server\src\examples\security\net directory.

Listing 5-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;
  }

 

---

Using J2EE Sandbox Security to Protect Application Server Resources

WebLogic Server supports the J2EE requirements for sandbox security for Web, EJB and connector components. Furthermore, WebLogic Server extends the connector model of specifying additional policies in the deployment descriptor to the Web and EJB components.

J2EE has requirements for the Java 2 sandbox of different application types (see the J2EE 1.3 spec, section 6.2.2) as does the Connector 1.0 spec (see section 11.2).

Furthermore, the J2EE specification suggests that the deployer be able to add to these policies. For J2EE, this is done through comments in the deployment descriptor but the specification states: "A future version of this specification will allow these security requirements to be specified in the deployment descriptor for the application components." The connector specification already provides for deployment descriptors to specify additional policies using the security-permission tag as in the following example:

<security-permission >
<description> Optional explanation goes here </description>
<security-permission-spec>
<!—

A single grant statement following the syntax of http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax without the "codebase" and "signedBy" clauses goes here. For example:

-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>

WebLogic Server meets these requirements and in addition adds the security-permission tag to the weblogic.xml and weblogic-ejb-jar.xml files. This both extends the connector model to the two other application types providing a uniform interface to policies across all component types as well as anticipates future J2EE specification changes.

Each of the containers (web, EJB, connector) must register applications as they are deployed and undeployed. Upon a server reboot, each deployed application must be re-registered. To register them, the containers should call one of the following methods from weblogic.security.service.SupplementPolicyObject:

/**
* Set extra permissions for the specified URL. If there are 
* already extra permissions set (by a previous setPolicies*()),
* calling this will override them.
*
* @param url URL to set permissions for
* @param grantStatement text of grant statement for permissions
* to add to the URL
*/
static public void setPolicies (URL url,
                                  String grantStatement, 
                                  String defaultType);
/**
* Set extra permissions for the specified file. If there are 
* already extra permissions set (by a previous setPolicies*()),
* calling this will override them.
*
* @param filename file to set permissions for
* @param grantStatement text of grant statement for permissions
* to add to the file
*/
static public void setPolicies (String filename,
                                  String grantStatement,
                                   String defaultType);

The grantStatement should be all of the text within the security-permission-spec tags. The defaultType should be one of EJB_COMPONENT, WEB_COMPONENT, or CONNECTOR_COMPONENT defined in the same class.

When an application is undeployed, the containers should call the removePolicies() method in the same class:

static public void removePolicies(String filename);
static public void removePolicies(URL url);