Filter Rules

For each client connection, Enterprise Server scans the rules specified for the endpoint, if there are any, and the rules for the communications process and server, if any. Each of the rules which match the client's IP address, or its fully qualified hostname, if there are any hostname rules, are ranked based on how well the rule matches. A rule with no wildcards and matches is an exact match and overrides any rule containing wildcards. Rules with wildcards are ranked based on how many characters the wildcard replaces; fewer replaced characters means a closer, or more exact match.

For example, if the client's IP address is 192.168.1.100, then for the following rules:

deny:**: This would match with rank 14.
allow:192.168.2.*: This would not match.
allow:192.168.1.*: This would match with rank 4.
Note: Lower rank is a closer match.
deny:192.168.1.100: This would be an exact match, or rank 0.

The result would be that the last rule would be applied to the client and the connection would be denied (blocked).

Note: The rule applied is always selected based on rank. The order of the rules that are specified in the Configuration Information field does not determine rank.

You can configure rules using the Enterprise Server Common Web Administration (ESCWA) interface. Specify the rules in the Configuration Information or Custom Configuration field, in any or all of the following locations:

An enterprise server region's General Properties page:
1. In the ESCWA menu bar, click Native.
2. In the navigation pane, expand Directory Servers.
3. Click the enterprise server region you want to configure.
4. Click General > Properties.
5. In the Configuration Information field, type the filter rules you want to apply.
6. Click Apply.
The Communications Processes page for the communications process control:
Note: Rules configured here apply to all listeners under the communications process.
1. In the ESCWA menu bar, click Native.
2. In the navigation pane, expand Directory Servers.
3. Click the enterprise server region you want to configure.
4. Click General > Listeners.
5. In the communications process navigation pane, click the communications process you want to configure.
6. Click Configure to expand the configuration options.
7. In the Custom Configuration field, type the filter rules you want to apply.
8. Click Apply.
The Communications Processes page for each individual listener:
1. In the ESCWA menu bar, click Native.
2. In the navigation pane, expand Directory Servers.
3. Click the enterprise server region you want to configure.
4. Click General > Listeners.
5. In the communications process navigation pane, click the listener you want to configure.
6. In the Custom Configuration field, type the filter rules you want to apply.
7. Click Apply.

In the Configuration Information or Custom Configuration field, add the [Connection rules] section header if it does not already exist, and then type your rules. One rule per line. Comments can be added after a hash "#" and can go to the end of the line. Blank lines are also permitted.

The rule options in the connection rules section:

[Connection rules]
action:source[:options]

where:

action: Can be allow or deny.
source: Specifies which clients the rule applies to, described below.
options: Optional - Currently the only option is log, which causes additional logging when the rule applies to a client connection.

The source has four possible forms, which can include the wildcards "*" and "**". The "*" wildcard matches zero or more characters but not the "." character; the "**" wildcard matches anything, including ".". The source forms are:

IPv4 address, for example, 192.168.1.2 or 192.**.
IPv6 address, for example 2600:1405:1000::17d0:8c09, ::1, or 2600:1405:*.
Note: IPv6 addresses do not use the "." character, so the "**" wildcard does not need to be used with them.
IPv4 CIDR network address, for example, 192.168.1.0/24 or 10/8. Any valid CIDR network length can be used, and trailing 0 octets can be omitted as in the second example.
Fully-qualified DNS name, for example, *.opentext.com.

Additional considerations

Micro Focus recommends you do not create rules using DNS names. Such rules are processed using a reverse DNS (PTR record) query, and reverse DNS can be unreliable, insecure, and slow.

Mixing IPv4-address rules and CIDR-network rules might produce unexpected results. Network rules are matched against the binary representation of the IPv4 address, while address rules are matched against the decimal representation. So a network rule such as 192.168/16 is outranked by the address rule 192.**, even though the network rule is technically more specific. Try to avoid ambiguous sets of rules that mix these two forms.

Earlier versions of the product documentation described the source ** as matching all conversations, making it suitable for a generic or default rule. This is not correct. The source ** is interpreted as an IPv4 address (which is all wildcards), so it does not match IPv6 connections. Also, as described above, it might outrank IPv4 CIDR-network rules because it is applied to the decimal representation of the address. The preferred way to specify default behavior, for example to deny all conversations not allowed by a more-specific rule, is with a pair of rules for IPv4 (using CIDR) and IPv6:

deny:0.0.0.0/0
deny:[*]

The first rule blocks IPv4 connections that do not match any allow rules; the second blocks IPv6 connections that do not match any allow rules.