Creating IP filter rules

When you create a filter, you specify a rule that governs the IP traffic flow into and out of your system.

The rules you define specify whether the system should permit or deny packets that attempt to access your system. The system directs IP packets based on the type of information in the IP packet headers. It also directs the IP packet to the action that you have specified the system to apply. The system discards any packets that do not match a specific rule. This automatic discard rule is called the default deny rule. Located at the end of the file, the default deny rule is automatically activated any time a packet does not match the criteria in any of the preceding rules. You must have at least one filter rule activated for the default deny rule to be active.
Important: When you apply rules to an interface through which you are configuring the System i® platform, it is very important that you permit your own workstation or that of anyone else who might be configuring the system. Failure to do so will result in a loss of communication with the system. If this happens, you need to log on to the system using an interface that still has connectivity, such as the operators console. Use the RMVTCPTBL command to remove all the filters on the system.

Before you create your filter rules, you need to determine whether you need to use network address translation (NAT). If you use NAT rules, you must define addresses and services. NAT is the only function that requires a defined address, but you can use it for other functions as well. If you define addresses and services, you can reduce the number of rules that you must create as well as minimizing the possibility of typographical errors.

Here are some other ways you can use to minimize error and maximize efficiency when creating filter rules:
  • Define one filter rule at a time. For example, create all the permits for Telnet at the same time. This way you can group associate the rules whenever you refer to them.
  • Filter rules are processed in the order that they appear in the file. Be sure to order the rules the way you intend them to be applied when you create them. If the order is incorrect, your system is vulnerable to attack because the packets will not be processed as you intend them to be. To make things easier, consider the following optional actions:
    • Place your filter set names in the FILTER_INTERFACE statement in the same order in which the sets are physically defined in the file.
    • Place all filter rules in one set to avoid problems with set order.
  • Verify the syntax of each rule as you go along. This is easier and faster than debugging them all at once.
  • Create set names for groups of files that are logically associated with each other. This is important because only one rule file can be active at a time. See the following example.
  • Only write filter rules for the datagrams you want to permit. Everything else will be discarded by the automatic deny rule.
  • Write rules for high traffic volume first.

Example:

Look at the Create set names tip. You might want to enable Telnet access to a number of internal users, but not to all. To manage these rules easier, you can assign each of them the set name TelnetOK. A second criteria can enable Telnet through a specific interface and block Telnet traffic from all others. In this case, you need to create a second set of rules that block Telnet access entirely. You can assign these rules the set name TelnetNever. By creating set names, you make it easier to distinguish the purpose of the rule. It is also easier to determine which interfaces you intend to apply to particular sets. Use all of the tips above to ease the process of creating filters.

For instructions on how to create IP filter rules, use the Packet Rules Editor online help.

After you create your filters, you might want to include files in packet rules in the filter statement. If not, the next step is to Defining IP filter interfaces to which the rules apply.