IBM i > Administrator > Networks

IP Packet Filtering: Your iSeries Gatekeeper

I recommend creating a named address for all entities, such as the iSeries server IP address, the mail gateway in the DMZ, etc. A named address can be an individual IP address, a list of IP addresses, a range of IP addresses, a subnet or host names. After creating all named addresses, continue creating the filter rules using the rules wizard. The wizard provides a pre-defined list of services to choose from when defining the filter rules. Currently, three different wizards are available-Permit a Service, Spoof Protection and Address Translation.

 

To allow certain traffic to flow in to and out of the system, use the Permit a Service wizard. The usefulness of the wizard becomes obvious when you define the filter rules that allow iSeries Access for Windows clients to connect to the iSeries server. If you ever used the Netstat interface to check out all of the ports that iSeries Access (formerly Client Access) uses for all of its services, you noticed that 11 ports (449, 8470-8479) are listening for the common tasks you can perform with iSeries Access. This doesn't include ports that are used for Management Central or traffic protected via SSL (9470-9479).

Fortunately, the Permit a Service wizard is familiar with the ports and automatically enters the appropriate ports for the selected service when creating the rules. Figure 3 shows the Service to Permit page that contains the service selection list.

If you're using non-standard ports for a specific service or an application service that isn't included in the pre-defined list of services, you can also define a service manually by specifying the corresponding port and protocol. By following the wizard, you will be prompted to specify the source and destination IP addresses. Because you defined named addresses for all of the entities in the network, select the corresponding address name from a list. The last user input requested is the interface on which the filter rules should be applied along with the direction.

A summary page at the end of the wizard lets you verify your input. In the example of iSeries Access (CLIENTACCESS service), the wizard creates 48 filter rules, an interface rule and an include directive. The include directive created by the wizard specifies a services file. This file contains a list of named services similar to the named addresses that you defined previously. As with named addresses, named services are easier to work with and make your filter rules file more readable. You can also use include directives to add different rules sets that are defined in logical groups in different rules files.

I recommend using the wizard. Even though the wizard might create more rules for traffic than you actually want to permit, it's easier to remove a few filter rules than to create all of the rules manually. For example, if you use the wizard to permit Telnet traffic for the remote workers clients, the wizard creates filter rules for non-secure (port 23) and secure (port 992) Telnet traffic. Because the requirements specify that only secure Telnet should be permitted for these clients, delete the two rules for non-secure Telnet to meet your requirements.

 

Tweet