One of your primary concerns when you connect your AS/400 to the Internet should be preventing harm to your system. Simply plugging into your connection and enabling the OS/400 TCP/IP servers is an open invitation to problems. Some of the techniques you can use to help protect your AS/400 are
- installing and using a firewall (either Firewall for AS/400 or another firewall)
- using exit point programs for TCP/IP servers that support exit points
- using IP packet filtering (available starting with OS/400 V4R3)
This article shows how to configure IP packet filtering on the AS/400. The sample configuration causes the AS/400 to record a journal entry each time the AS/400 FTP server is accessed from another computer. Because of the complexity of Internet security issues, this example isn’t meant to show a viable configuration but, rather, simply to walk you through the steps required to set up and work with IP packet filtering.
Locating TCP/IP Services
Before configuring an IP packet filter, you need to know the name of the TCP/IP service you want to filter and the ports and protocols associated with it. You can use the WRKSRVTBLE (Work with Service Table Entries) command to review a list of TCP/IP services available on the AS/400. Figure 1 shows a sample of the command output, scrolled forward to the point where the entries for FTP services are listed. You can create IP packet filters for any of the TCP/IP services listed in the WRKSRVTBLE display.
As Figure 1 shows, four services are associated with FTP on two ports. FTP control (port 21) is used when the AS/400 receives a request for FTP processing — for example, a get request. FTP data (port 20) is used when the server responds to the request. Although TCP is the usual protocol used for FTP, the AS/400 also supports FTP using the User Datagram Protocol (UDP). You need to know this information to configure comprehensive IP packet filters. (A third protocol, Internet Control Message Protocol, or ICMP, is not shown as being used with FTP, but it is used with other services, and you can specify it in a filter.)
The IP Packet Security Program
You access the AS/400 IP Packet Security program through AS/400 Operations Navigator (OpsNav). Under My AS/400 Connections, click Network and IP Security. Right-click the IP Packet Security entry in the right frame, and select the pop-up menu’s Configuration item to display the IP Packet Security program (Figure 2).
The program lets you perform two major functions:
- configuring Network Address Translation (NAT), to "hide" internal IP addresses from the external network. This function is commonly used when you allow access to the Internet through your AS/400. Using NAT, you can configure the AS/400 so that all Internet access appears to originate from only one IP address. When receiving incoming response traffic, NAT determines the original requester of the data and forwards it to that requester. I don’t describe NAT any further in this article.
- IP packet filtering, which lets you create a set of rules to determine what should be done with IP packets on your AS/400. You can allow or reject packets based on the type of service, the source or destination address, the direction of the packets (inbound, outbound, or both), and the physical interface (communications line) that the packets use.
If you have multiple TCP/IP interfaces defined for your system, you must define a set of filter rules for all or none of those interfaces. For example, you might have two Ethernet adapters in your AS/400, the first connected to a router out to the Internet and the second used for your internal network. You’ll probably want to apply stringent rules to the externally connected adapter. Although you might not want to apply any filter rules to the internal adapter, you’ll need to create a filter for that adapter, too. In this case, the filter for the internal adapter would probably be an "allow all" filter.
If you’re configuring stringent filters for multiple interfaces, you should consider using the "includes" technique to configure commonly used rules. Although this article does not show how to create include sets, an include set is simply an individual file of filter rules that is identified and included in another file of filter rules.
For example, if you need to restrict FTP access on one external interface, you may need to restrict it on other external interfaces as well. Rather than enter all the same filter rules for multiple interfaces, you can create one set of rules for FTP and then include that set in the configuration for each interface. Creating include sets of rules has two advantages:
- It is easier to create, verify, and implement one set of rules than to create a separate set for each interface.
- If you need to change a rule — for example, to relax it or make it more stringent — you need to make the change in only one place rather than for each individual interface.
If you have only one or two interfaces on your AS/400, however, it’s probably not necessary to create include sets.
The Default "Deny All" Rule
You need to be especially aware of the default "deny all access" rule that is automatically added to your IP filtering rules once you specify any filter rule. This awareness is important because it’s possible to create a working, verified set of packet-filtering rules, activate that set, and then find yourself locked out of your system. For example, I wanted to create a simple set of rules to log FTP requests. After verifying and applying that set of rules, I suddenly found that OpsNav and all PC5250 emulation sessions were frozen. I also couldn’t start new sessions.
In such a case, you need to sign on to your AS/400 using a non-TCP/IP connection. I used an ASCII workstation–attached terminal. For newer AS/400 systems, you may need to use a PC attached with the Client Access console cable. Once back on the system, I ran the RMVTCPTBL (Remove TCP/IP Table) command to remove the filtering rules from the system. The rules are commonly stored as files in the AS/400 integrated file system (IFS). The files themselves aren’t removed, but the rules are deactivated so you can get back into your system.
In most cases, you probably want the "deny all" rule to be in effect because you usually define rules in terms of the few cases you’ll allow and deny everything else. However, I simply wanted to log when the FTP server was used, so, in addition to the filter rule that logs FTP start-up requests, I added an "allow all" rule to permit all other packets to be accepted. Because my "allow all" rule is in the set of rules that I defined, the system encounters it before the default "deny all" rule. With packet filtering, the first applicable rule is used; rules following that rule are skipped. Because my "allow all" is encountered first, I am able to log FTP and let everything else through.
Given my experience with defining rules, you may find it prudent to define packet filter rules only when everyone else is off the system. You also need to have physical access to a device that can contact your AS/400 using a connection type other than TCP/IP in case you need to deactivate the rules tables.
Although doing so is not required, you can define and name services to which you want to apply filter rules. You define a service by right-clicking Services in the left frame of the IP Packet Security window (Figure 2) and selecting the New Service Alias menu item from the resulting pop-up menu. Figure 3 shows the resulting Service Alias Properties dialog box.
Using this dialog box, you define the service name, which you will probably want to correlate with the WRKSRVTBLE command display name (see Figure 1). You then define the protocol, which can be one of the following:
- TCP — used for all packets that use the TCP protocol
- TCP/Starting — used for packets that use the TCP protocol when the service is started
- UDP — used for all packets that use the UDP protocol
- * — used for all packets that use any of these protocols
If you plan to filter (deny or accept) all packets for a service, you will probably specify the * option. For my purpose, which is to log FTP requests to my AS/400, I select the TCP/Starting option because I’m interested only in packets sent when an FTP request is initiated.
The Source port and Destination port fields let you specify which ports apply to the service. For inbound requests (packets sent to your AS/400), you will probably specify the Source port as = * (equal to "any") because you may not know the port number on the system from which a request is originating. The Destination port option specifies "=" and "21", which is the port assigned to the FTP control function on the AS/400 (from the WRKSRVTBLE display).
Defining Filter Properties
You define the actual filter rules that will be applied to IP packets by creating one or more filter rules. Right-click Filters in the left frame of the IP Packet Security window, and then click the New Filter item on the resulting pop-up menu. Figure 4 shows the resulting Filter Properties dialog box.
You use the Set name entry to assign filter conditions to an interface. You can use this field as a convenience for grouping filter rules together. For example, if you know you’re going to define 10 filter rules, eight of which will be used for multiple interfaces, you can assign the same set name to the eight rules and assign other set names to the remaining two rules. When you assign filters to the interfaces, you then assign rules by the set names, not by individual rule names. Nothing requires you to have multiple filter rules with the same set name, so if it makes more sense to have sets of one, simply assign a unique set name to each filter rule.
For the Action field, you choose either Permit or Deny. The Direction field is Inbound, Outbound, or * (both).
You use the Source address name and Destination address name fields to identify specific IP addresses from which packets originate or to which they are directed. I used the special value * for both addresses, which, combined with Permit in the Action field, means that all source and destination addresses are permitted.
The Fragments value can be None, Headers, or *. Because some security considerations apply when you allow fragmented packets, you may want to use the default value of None if you’re using packet filtering to help secure your system.
You use the Journaling option to indicate whether you want a journal entry written when this filter rule is used. Possible values are None and Full. I want to log FTP access, so I select the Full option. You use the journaling option when you want to gather statistics about the types of IP packets being processed by your system. After gathering a few days’ worth of typical packet usage data, you’ll have a good idea of the types of filter rules you need to create. Another use for journaling would be a "deny all" rule that follows "permit" rules. In that case, the journal would show you which types of IP packets are being denied — information that might indicate that your system is being probed.
Figure 5 shows the Services tab of the Filter Properties dialog box. You use this tab to identify the type of service to which the filter applies. The Service name field specifies that this filter rule uses the previously created service alias for FTP control packets (see Figure 3). If you compare Figure 3 with the Service entries shown in Figure 5 (the grayed-out fields in the middle of the panel), you’ll see that the same entry fields are used. This points out the advantage of defining the service alias: You specify all the entry fields once and assign a name to the service. If you didn’t use the service alias and you needed to create filter rules for several interfaces, you would need to repeatedly enter the protocol and port specifications. There is less chance of making a keying error when you use the service alias.
You use the Services tab’s ICMP service option if you need to filter ICMP packets. In addition to the service alias, you can create an ICMP alias if you’ll be creating multiple filters using the same rules.
Assignment to an Interface
Once you have your filter rules in place, you can assign them to your interfaces. In the IP Packet Security window, right-click Filter Interfaces, and then select New Filter Interface from the pop-up menu. Figure 6 shows the resulting Filter Interface Properties dialog box.
You can select an interface in one of three ways:
- Line name. The selection list contains the list of TCP/IP interfaces defined on your AS/400.
- IP address. You can enter the IP address assigned to the TCP/IP interface.
- Point-to-point profile name. If you’ve defined a point-to-point interface, you specify its name.
After selecting the interface, click the Add button to add a set name to the interface. You can add as many set names as you need to the interface by clicking the Add button again and entering another set name.
The order in which you add sets is important because filter rules are processed in the order in which they are added to the interface. If you make a mistake in order, you can use the Remove button to remove a set from the list. You can also manually rearrange the order of filter rules by clicking All Security Rules in the IP Packet Security window and dragging and dropping the statements in the upper-right frame (Figure 7).
You must add at least one set name for each TCP/IP interface on your AS/400. If you want to remove packet filter rules from an interface, you must remove the rules from all interfaces.
Verify and Activate
After configuring your interfaces, you can verify your rules. In the IP Packet Security window, select the File menu and then select Verify (or click the magnifying glass icon on the toolbar). The verification process examines all the filter rules you’ve configured and sends error and completion messages to the bottom of the IP Packet Security window, as shown in Figure 7.
I found the error messages almost incomprehensible. A great deal of the problem is probably my unfamiliarity with the terminology used for packet security configuration. To make things easier, verify your rules as you go along. Rather than adding all the rules and then attempting to verify them all, enter a rule or two, then verify. You particularly want to verify rules when a relationship exists between statements — for example, when a statement for an interface depends on the set name entered on a filter rule.
After successfully verifying the rules, you can activate them. If this is the first time you are activating rules, you should be positive that you have access to a non-TCP/IP–connected device so that you can run the RMVTCPTBL command if necessary. You can use the Activate item on the File menu or click the right-pointing arrow icon in the toolbar to activate the rules. Assuming that your rules don’t lock you out of your system, you can start testing the effect of your rules on your TCP/IP services.
The Packet Filter Journal
Because I selected the option to journal FTP packets, a new journal was automatically created when I activated the rules. Two journals are actually created for you, both in library QUSRSYS:
- QIPFILTER, which contains journal entries related to packet-filtering activities
- QIPNAT, which contains journal entries related to NAT activities
Figure 8 shows a sample journal entry from the QIPFILTER journal. This journal entry shows that the Permit rule was used to accept a packet addressed to port 21 (the FTP control port) and that the packet originated from TCP/IP address 10.1.1.41.
Along with the two journals, there are two system-supplied files:
- QSYS/QATOFIPF — output file for the IP packet-filter journal entries
- QSYS/QATOFNAT — output file for the NAT journal entries
Figure 9 shows the format of output file QATOFIPF. By specifying this file name on the OUTFILE parameter of the DSPJRN (Display Journal) command, you create a physical file of data from the journal that can be used in programs or queries that you develop to analyze the data.
When you enable IP packet filtering, you require your AS/400 to inspect every IP packet it receives. This activity obviously has some impact on performance. If you then add journaling, the performance impact is even more significant.
IBM performed an informal test and documented it in the Redbook V4 TCP/IP for AS/400: More Cool Things Than Ever (SG24-5190). The test suggests that on average, compared to a configuration with no packet filtering, filtering without journaling results in a 47 percent increase in average response time, and filtering with journaling results in an 87 percent increase in average response time. Journaling is obviously very "expensive," but if your purpose is to gather statistics so you can decide which rules to implement, it’s worthwhile because it’s easy to enable and disable.
Use Where Needed
You may not need to use AS/400 IP packet filtering. For example, if you have a firewall or a router that filters packets before they enter your network, there may be no point in performing the same filtering again on the AS/400. However, you may want to implement filtering if you are directly connecting your AS/400 to the Internet or if you are using Point-to-Point Protocol (PPP) for your connection. Although the chances may be slight that your AS/400 will be compromised over a PPP connection, you should be aware of the tools provided by IP packet filtering so that you can enable them if necessary.
My feeling is that AS/400 IP packet filtering can be quite involved to configure correctly. Unless you’re a network engineer, you probably won’t have many chances to practice configuring IP packet filters, so the odds of creating an incorrect configuration are high. However, IP packet filtering is certainly better than nothing (no firewall) if you’re connecting to an external network.
This article is reprinted from AS/400 Network Solutions (October/November 1999).
Craig Pelkie works for a dot-com startup in the San Diego area. He’s also a frequent speaker at NEWS/400 seminars on topics including TCP/IP and the Web.