By now, you’re probably aware that IBM has dropped support for the AS/400 Firewall product. This less-than-stellar package, while never up for an award as one of the world’s finest Internet security products, was still fairly well used in the AS/400 world.

With the demise of the Firewall product, you may be thinking that your ability to protect your Internet-connected AS/400 has been cut off at the knees. Well, if you’re lying awake at night worrying that some 13-year-old kid is attempting to hack and sack your system, you can relax. Even though the AS/400 no longer has a specific firewall product, there are still several ways to protect it while it is attached to the Internet. One of those ways is using IP filtering to define a set of rules that let you control which users have access to which services on your system.

It’s Simple

Every system using the TCP/IP protocol uses, for the most part, a series of well-known ports for common services. For example, when someone attempts to Telnet into your system to start an emulation session, they use port 23 to get there. If someone attempts to access your system via a Web browser, they’ll use port 80, and so on. By filtering, you can restrict access to any port to a given set of users based on their TCP/IP addresses.

So, by filtering, you set up rules that allow Tom Trustworthy, who uses a TCP/IP address of 207.200.200.1, to get into your system, but Harry Hacker, using an IP address of 219.201.2, won’t be able to. Here’s another scenario. Perhaps you want to protect all of the ports and services on your system except for HTTP. By using IP filtering, you can allow access to port 80, used by HTTP, while denying access to all other ports.

This is the way it works. When Tom Trustworthy types your AS/400’s TCP/IP Host name or IP address into his browser and clicks the Submit button, an IP packet is created. This packet is sent across the Internet, passing through several networks along the way, until it reaches your AS/400. Once the IP packet arrives at your AS/400, its header information is checked. Inside the header is the originating IP address. It is this IP address that is compared with the IP filtering rules you’ve defined for your AS/400. If the IP address matches an allowed address in your filter rules, that IP packet is passed to the appropriate service on your AS/400. If it doesn’t match, it is discarded.

That’s really all there is to IP filtering. Simple, huh? And when it’s combined with another IP security feature known as Network Address Translation, or NAT, you can

define a set of rules that keep all but the most determined hackers out of your AS/400. IP filtering can be used either in conjunction with NAT or by itself, depending on your particular needs. (Barry Kline will take an in-depth look at NAT in another issue of MC). For now, take a look at how to set up and use IP filtering on your AS/400.

Getting Started

To define the IP filtering rules for your AS/400, you need to have TCP/IP services configured and running on the AS/400. Next, you need a PC connected to the AS/400 via TCP/IP, with AS/400 Client Access Express V4R4 and Operations Navigator loaded onto it. Make sure that the OpsNav client has the Network component installed, because that will be the area you’ll need to get into to configure IP filtering. If it’s not installed, use the Selective Setup option of AS/400 Client Access to install it.

Now you’re ready to start whacking away at your keyboard and changing things on your system. Before you change anything, you need to gather some information first. The following is a list of information you need to have in hand before you can define the IP filters:

• The name of the line, or point-to-point configuration, for which you’ll be defining rules. (For example, if you are using an Ethernet connection for Internet access, you need to know the name of that Ethernet line.)

• The types of TCP/IP services you want to filter (e.g., Telnet)

• The port numbers used by the TCP/IP services you want to filter

• The TCP/IP addresses of those sites/users who will be authorized to access the various services on your AS/400

Defining the Rules

Once you have all of the necessary information, you’re ready to define the IP filtering rules for your AS/400. Follow these steps to get to the IP Packet Security panel in OpsNav (which is where you’ll configure IP filtering):

1. From your TCP/IP-connected PC, start an OpsNav session.
2. Expand the entries under your system name by clicking the plus (+) sign next to it.
3. Expand the Network node functions by clicking the plus (+) sign next to it.
4. Double-click the IP Security node.
5. In the resulting panel, in the right-hand pane, right-click the IP Packet Security node and select Configuration from the context menu that appears. (You should end up with a panel like the one shown in Figure 1.)

Right-click the All Security Rules node, and you’ll be presented with a context menu that will let you select one of the following:

• Defined Address
• Filter Interface
• Filter
• Service Alias
• ICMP (Internet Control Message Protocol) Service
• Hidden Address
• Mapped Address
• Include
• Comment

You could also right-click one of the nodes beneath the All Security Rules node to access the options available from the context menu. Take a look at some of these options in a bit more detail.

As shown in Figure 2, the New Defined Address panel lets you identify a single IP address or a group of contiguous or noncontiguous IP addresses with a single name. (You will use this name to refer to these addresses within the Filter Interface configuration panel, where you have the option of entering an interface name, such as a Point-to-Point configuration name or the name of a TCP/IP interface you created when you configured TCP/IP.)

If you don’t want to use an interface name, you can also set up a list of individual IP addresses. You can enter a single IP address, a group of IP addresses, or even a starting and ending IP address. (For example, you could enter a starting IP address of
200.100.99.1 and an ending IP address of 200.100.99.99.) The name you enter in the Address name field would then refer to all IP addresses in this range.

The last required entry in the New Defined Address panel is the Type field. The choices in this field are TRUSTED, UNTRUSTED, or BORDER. Trusted means that the IP addresses or interface name in this definition is on your internal AS/400 network. Untrusted means that the addresses or interface name is from outside your local system. Border means that the addresses or interface name is on a network that connects the trusted system to the outside world (untrusted).

The Filter Interface panel lets you add the addresses you defined in the New Defined Address panel to a single IP filter name. You can specify whether these addresses apply to a single line (Ethernet or Token-Ring) or a Point-to-Point configuration profile.

The New Filter option (Figure 3) lets you define the type of filter you want to apply to the groups of names or addresses for which you defined a filter interface. In this panel, you will enter following information:

• Set name—In this field, you enter the name of your filter interface.

• Action—In this field, you indicate whether to permit or deny access to this filter interface.

• Direction—In this field, you indicate whether your filter interface is for inbound or outbound (or both) transactions.

• Source address name—In this field, you enter the name or IP address of the originating system (i.e., the system that sends requests to your AS/400). You can also enter an asterisk
(*) here to indicate that this filter rule applies to all outside systems.

• Destination address name—In this field, you enter the name or IP address of the destination system (this will most likely be your AS/400 that is connected to the Internet or an intranet, or it could be another system behind the AS/400 that is connected to the Internet or an intranet). You can also enter an asterisk (*) here to indicate that this filter rule applies to all destination systems.

• Fragments—In this field, you define whether or not you will allow fragmented IP transactions. A fragmented IP transaction can occur when an IP request is broken up in transit to your site. This happens for many reasons (e.g., one of the networks that your IP transaction crosses on its way to your system is busy so the transaction cannot pass the entire packet, or perhaps the IP packet is broken up by a network that has decided, based on IP forwarding rules, to route the partial IP packets around multiple networks to increase performance).

Whatever the reason, IP packet fragmentation happens all the time, and you need to allow for it. This option in the IP filtering rules allows you to specify whether or not this rule will check incoming datagrams for fragmentation. You can specify Headers here if you want to ensure that IP fragments match the IP headers when the IP packet is reassembled at your system. Specify NONE to indicate that only unfragmented datagrams are allowed, or specify an asterisk (*) to indicate that no checking will be performed.

• Journaling—In this field, you can record all actions that pertain to this filter. If you start journaling on this filter, you can keep a log of all the activity that matches this filter. This is a good way to get a handle on how your filtering rules are working out. Journal entries are made to a journal in library QUSRSYS on your AS/400 in a file named QIPFILTER.

You can also define which IP services this filter applies by clicking the Services tab on the New Filter panel. If you already defined a service interface with that menu option under the IP Packet Security node in OpsNav, you can specify its name here. Otherwise, select the Service type (i.e., TCP, ESP, UDP) as well as the IP port number it will use. You can also specify the ICMP service here, rather than the IP service, by selecting that radio button instead. ICMP services include such things as PING and TRACERT, which echo messages back to a sending system. The Services panel should be used only by experienced users.

Order Is Important

That’s basically all there is to setting up IP filtering on your AS/400. When you’ve finished creating your rules (or at any point along the way), save your rules to a file in the AS/400 Integrated File System (AS/400 IFS). This file is saved as a type of *.IP3, but don’t let that fool you; it’s really nothing more than a text file and can be edited as such. Once you create this file, it might be a good idea to use a PC text editor to view the contents of this file to see how it’s laid out. You could also use the AS/400 Edit File (EDTF) command to view the contents of this file. You can even manually add entries to the rules file, but it’s not recommended, because you could easily introduce errors.

Another thing to keep in mind when creating IP filters is that the IP filtering rules are evaluated in the order that you create them, which makes sense when you realize that the filters are being parsed out of the filter rules text file you saved in the AS/400 IFS. It’s a simple read of the file, so naturally it will be in FIFO order. As the filter rules are applied to incoming IP packets, they are evaluated in FIFO order, too. This may not be a big deal, and then again, it might. It all depends on how you define your filters.

Assume that you created three filters. The first filter allows any source IP address to have access to your HTTP server (port 80), the second filter denies all access to every other port on your system, and the third filter allows access to any source IP address for your FTP server (port 21). If someone attempts to get into your HTTP server via a browser and they pass all other security rules you’ve set up, such as the standard HTTP directives they will have no problems. If, on the other hand, they attempt to get to your FTP server, they will be denied access to your system because you have denied service to all ports on your system with the second filter rule. That second filter rule is applied before the rule that allows access to your FTP server. To remedy this problem, remove the Deny All rule and add it after the Allow FTP rule. These are easy issues to work out. Mostly, it’s a trial-and- error situation until you get all the filtering rules stabilized.

After you’ve defined the rules, you’re ready to start the IP filtering. To do so, click the green arrow icon on the tool bar of the OpsNav IP Security panel. To stop it, click the stop sign icon on the OpsNav IP Security panel tool bar. That’s it!

Other Security Considerations

While IP filtering, especially when combined with NAT, gives you a pretty good security wall to keep out unwanted traffic, by itself, it’s not enough to keep your critical data secure. You must also follow good security practices and policies for the rest of your AS/400 data. Take a look at some examples:

• If you allow HTTP browsing of your AS/400, you need to ensure that the libraries, files, and other objects that are accessible via HTTP are secured. You can use a variety of methods to accomplish this, including HTTP directives and object-level security. (For information about securing your HTTP server, check out “Three Steps to a Secure HTTP Server” in the June 2000 issue of MC.)

• If you allow FTP access to your system, you need to not only keep out unwanted traffic but also limit access to only those directories and FTP commands that you deem necessary. The best way to do this is by using an FTP Exit program. (For a great resource, with examples of using FTP exit points, check out “Locking Down Your FTP Server” in the December 1999 issue of MC. Also check out Brad Stone’s FTP Tools [FTPTOOL] application available at the BVS/Tools Web site at www.bvstools.com/ftptool.html, which allows you to control FTP security at many different levels. Be aware, however, that this tool is shareware and requires a nominal fee to use.)

For other Internet security issues, check out the Resource CD (available from the Midrange Computing Storefront Web site at www.mc-store.com), which contains dozens of AS/400 security-related articles and all the back issues of the MC Security Patrol column. Another great resource is the IBM AS/400 Information Center Web site at publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/ info/index.htm.

Sleep Easy

With the loss of the AS/400 Firewall, many companies have been scrambling to find a replacement product. This time, IBM didn’t let them down by dropping a product without providing some type of comparable assistance. By using IP filtering and the other IP security features available through the OpsNav client, you can sleep easy, knowing that your AS/400 is protected and secure from those who would cause it harm.

REFERENCES AND RELATED MATERIALS

• BVS/Tools Web site: www.bvstools.com/ftptool.html
• IBM Information Center Web site: publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/info/index.htm
• “Locking Down Your FTP Server,” Alex Garrison, MC, December 1999
• Midrange Computing Storefront Web site: www.mc-store.com
• “Three Steps to a Secure HTTP Server,” Bradley V. Stone, MC, June 2000

Figure 1: Start configuring IP filters from this OpsNav panel.

Figure 2: Define the filter interface from this panel.

Figure 3: You set the filter rules for your AS/400 in this panel.

Shannon O'Donnell has held a variety of positions, most of them as a consultant, in dozens of industries. This breadth of experience gives him insight into multiple aspects of how the AS/400 is used in the real world. Shannon continues to work as a consultant. He is an IBM Certified Professional--AS/400 RPG Programmer and the author of an industry-leading certification test for RPG IV programmers available from ReviewNet.net.

 

Also Read

Securing IBM i: A Dual Responsibility

Top IBM i Security Issues of 2024

Why Cleaning Up Is an Important Part of Your IBM i Security Practice