Restricting IP interfaces used by servers

Many TCP/IP servers do not provide an option to bind to only a subset of the available TCP/IP interface addresses on the system. Instead, they bind to the INADDR_ANY or in6addr_any address, which allows the server to accept connections to any system address. TCP/IP filter rules can be used to selectively permit or deny TCP/IP packets based on IP addresses and TCP or UDP ports. This filtering can allow you to restrict servers to specific IP addresses with appropriate filter rules if the server does not provide this option.

The following is an example of TCP/IP filter rules that restrict certain servers to accept connections on specific addresses. Assume the IBM i system has the following TCP/IP interfaces:

Following are rules that restrict the FTP server (TCP ports 21 and 990), the telnet server (TCP ports 23 and 992), and the TFTP server (UDP port 69). The FTP server is allowed to accept connections only on IP addresses 192.168.31.53 and 192.168.41.53. The TFTP server is allowed to accept connections only on IP addresses 192.168.41.53 and 192.168.51.53. The telnet server is allowed to accept connections on all interfaces except for 10.5.15.119.

Lines 1 - 5 define the protocols and ports used by the servers. These statements are optional but help make the later FILTER statements clearer. It is only necessary to define inbound packet filter rules for the servers to enforce the desired interface restrictions, so the choice of destination port and source port reflects that. For inbound packets, the destination port is the server’s well-known port; the client’s port (the source port for an inbound packet) doesn’t matter and is specified as * to match any client port.

Lines 7 - 9 define the local interface addresses that each server is allowed to use or is restricted from using.

Lines 11 - 14 define a set of filter rules applicable to the FTP server. Line 11 permits inbound traffic from any source address (*) to only the allowed local addresses for the FTP server on port 21 (defined by the FTP_SERVICE rule), while line 12 denies traffic for all other destination addresses for the same server port. Similarly, lines 13 and 14 restrict traffic for the FTP server on port 990.

Lines 16 - 19 define a similar set of filter rules for the telnet server, however since these rules are intended to deny only traffic to specific local addresses while allowing traffic to all other addresses, the order of the PERMIT and DENY rules is reversed. When a FILTER SET is processed, the first rule matching the packet determines its processing, so the more specific rule (in this case the rule with a destination address specified versus one with any destination address) must be defined first.

Lines 21 and 22 define the set of filter rules to permit inbound traffic to the TFTP server destined only to the specified addresses.

Line 24 defines a rule that permits all packets that are not matched by one of the previous rules. When filter rules are applied to a physical interface, the default behavior is to discard all packets not matching any of the rules. For this example, we’re instead assuming that all other traffic is allowed rather than discarded. This rule is specified with a direction of * so that it applies to both inbound and outbound packets. Even though no other rules are defined for outbound packets, the default discard behavior still applies for any lines with rules loaded. If your system already has existing rules, this rule might be unnecessary or inappropriate, and you need to merge any new rules with your existing rules.

Finally, lines 26 - 29 specify on which lines the system loads the sets of filter rules and the order in which the sets of rules are processed on each line. The rules should be applied to all the lines on which inbound TCP/IP packets could be received. If VLANs are used on IBM i Ethernet line descriptions, rules are specified separately for each VLAN on that line. The rules are applied to both ETH2 and ETH2.4 (ETH2 with VLAN ID 4), in this example. *VIRTUALIP interfaces do not define a line on which packets can be received, so no FILTER_INTERFACE statement is required for it. The ALLOW_ANYTHING_ELSE rule is listed last for each line so that it is the last rule that is applied to packets sent or received on the line.

To define your own rules, follow these steps to start the Rules Editor:

1. In IBM Navigator for i, expand IBM i Management > Network > IP Policies and click Packet Rules.
2. From the Packet Rules list, select Action, then Rules Editor.

Use the Rules Editor to define or edit your packet rules. To add rules like the example rules, use Insert > Service, Address, Filter, or Filter Interface from within the Rules Editor to create each rule statement. Using the Rules Editor ensures that the syntax of the statements is correct. Using Insert from the top of the Rules Editor panel adds the new statement to the end of the current rules. Selecting an existing statement and choosing Insert from the Select Action pull-down menu adds the new statement before the selected statement. You can also add rules through the Text Editor input box and clicking the Insert button. The insert button adds the statement before the selected statement, or if no existing statement is selected, it adds the statement to the end. To change an existing statement, select the statement and choose Properties from the Select Action pull-down menu. To save the rules, use File > Save or Save As and save the rules with a file extension of “.i3p”.

The order of SERVICE, ADDRESS, and FILTER_INTERFACE statements within the file is unimportant. The rule loader uses two passes to interpret the statements, allowing named elements (for example, service, address, or set names) to be defined after they are referenced. However, the order of FILTER SET statements relative to other FILTER SET statements for the same named set is important as it determines the order each rule is checked against packets. 

Once complete, File > Verify Rules can be used to verify the rules and File > Activate Rules to load and activate the new rules. Active packet rules are automatically reloaded when TCP/IP restarts. The Load/Unload IP Filter (LODIPFTR) command can also be used to activate packet rules.

It’s important that your packet rules don’t block your current IBM Navigator for i session. If that occurs, the LODIPFTR command can also be used to deactivate (unload) filter rules.

The IP filtering and network translation topic in the IBM Knowledge Center provides further information on IP filtering and packet rules.