IP filter policy

An IP filter policy can stand alone to provide IP filtering and IPSec protection with manual key management. Used in conjunction with the two other policies, it is also required to provide IPSec protection with dynamic key management (IKE). Because filtering is crucial to secure traffic on a host, an IP security policy that contains no IpFilterPolicy statement block or an empty IpFilterPolicy statement block is considered an error, leaving the default policy that is provided by the stack in effect.

The IpFilterPolicy statement block consists of:

The purpose of the global configuration options is to control global policy items, such as whether logging is active or whether on-demand Security Association negotiations are allowed, and so forth. These global options apply to all of the IP filter rules that are contained in the policy. Each IP filter rule, in turn, contains data endpoints, traffic descriptions, and actions. When a packet entering or leaving the system matches the data endpoints and traffic description in an IP filter rule, the associated action is taken. If the action is an ipsec action, additional action statements are coded that define the parameters of the IPSec Security Association.

The following sample IpFilterRule statement allows web traffic on an internal server, and references a description of each line in the sample:

1  IpFilterRule             InternalNetWeb
2       {
3          IpSourceAddr          9.1.1.1
4          IpDestAddrSet         9.1.1.0/24
5          IpService
6          {
7             SourcePortRange        80
8             DestinationPortRange   1024 65535
9             Protocol               tcp
10            Direction              bidirectional InboundConnect
11            Routing                local
12            SecurityClass          0
13         }
14         IpGenericFilterActionRef  permit-nolog
15      }
Line
Description
1
The IpFilterRule keyword, followed by a required user-defined name for this rule.
2
An open brace ({) marks the start of an IpFilterRule statement block.
3
The source address of the rule. Outbound IP packets that match this rule must have 9.1.1.1 as the source address in the IP header.
4
The destination address of the rule. Outbound IP packets that match this rule must have an address in the range of 9.1.1.0 - 9.1.1.255 as the destination address in the IP header.
5
The IpService statement block describes the type of traffic that is allowed between the two data endpoints. The IpService block in this rule is inline to the rule, meaning that the entire definition of the IP service is included within the rule. Many policy statements, including the IpService statement, can be referenced rather than included inline.
6
An open brace ({) marks the start of the IpService statement block.
7
The range of source ports that is allowed for outbound packets. The value can be a single number, or a range of ports.
8
The range of destination ports that is allowed for outbound packets. The value can be a single number, or a range of ports.
9
The specific protocol that is allowed by this rule.
10
The direction specification for the IP packet.

Bidirectional indicates that this rule allows outbound traffic from local address 9.1.1.1 on local port 80 to any address in subnet 9.1.1.0/24 using any ephemeral port (that is, 1024-65535), and inbound traffic from any address in subnet 9.1.1.0/24 using any ephemeral port to local address 9.1.1.1 on local port 80. Without the use of the bidirectional keyword, it would be necessary to create two filter rules, one for outbound traffic and one for inbound traffic.

InboundConnect indicates that the rule will match inbound TCP connection attempts as well as bidirectional data on an established connection, but it will not match outbound TCP connection attempts.

11
The routing information for a packet matching this rule. For a packet to match this rule, the traffic must be local. In other words, this rule does not allow any packets that must be forwarded to another network node. Possible values are local, routed, or either.
12
The security class of the interface on which the packet must arrive or leave. The security class of an interface is defined using the SECCLASS parameter on the statement that is used to define the interface in the TCP/IP profile (that is, the LINK, INTERFACE, IPCONFIG DYNAMICXCF, or IPCONFIG6 DYNAMICXCF statement). Each interface on the system can be assigned a SECCLASS in the range 1 – 255. If the SECCLASS parameter is not coded in the TCP/IP profile for an interface, by default the interface is SECCLASS 255. In the SecurityClass parameter in this example, the value 0 indicates that a packet that matches this rule is not restricted and can traverse any interface (1 – 255).
13
A close brace (}) marks the end of the IpService block.
14
The action that is taken on a packet that matches this rule. In this case, permit the packet and log all occurrences of a match. All IP filter rules must include an IpGenericFilterActionRef statement. The IpGenericFilterAction statement itself should be defined elsewhere, outside of the IpFilterRule block, either in the common or the stack-specific IP security configuration file: 
IpGenericFilterAction     permit-nolog
{
  IpFilterAction          permit
  IpFilterLogging         no
}
15
A close brace (}) marks the end of the IpFilterRule statement block.
Rule: Do not include policy action statements inline. They must be referenced.
Parent topic: Component policies of IP security policy configuration files