Craig Pelkie Bits & Bytes Programming, Inc. craig@web400.com

Transcription

1 Craig Pelkie Bits & Bytes Programming, Inc. The Basics of IP Packet Filtering

2 Edition IPFILTER_ Published by Bits & Bytes Programming, Inc. Valley Center, CA Copyright 2002, Craig Pelkie. All Rights Reserved You are allowed to print copies of this document for your own personal use and for the use of others in your company or organization. Otherwise, no part of this document or any accompanying computer source code may be reproduced or distributed in any form or by any means, or stored in a database or data retrieval system, without the prior written permission of Craig Pelkie, who is the author of the document and the computer source code. All computer source code distributed with this document, either on diskettes, CD-ROM, or available for downloading from sources such as the Internet is Copyright 2002 Craig Pelkie, All Rights Reserved. The source code is for use in computer programs that you develop for internal use within your company, or for use within programs that you develop for the use of your clients. No part of the computer source code distributed with this document shall be reproduced in source code format, either printed or in electronic format, by you or by others who you allow to have access to the source code. You shall not cause the source code to be stored on any information retrieval system, such as the Internet. You shall not develop any written articles, books, seminar materials, or other presentations that include the source code provided on the diskettes accompanying this document or within the document itself. For any questions regarding your rights and responsibilities using the computer source code distributed with this document, contact Craig Pelkie, Bits & Bytes Programming, Inc., who is the owner of the source code. LIMITATION OF LIABILITY AND DISCLAIMER OF WARRANTY No representation is made that any of the techniques, programs, computer source code, commands, or configurations described and depicted in this document and on the computer source code accompanying this document are error-free and suitable for any application that you may develop. Craig Pelkie makes no warranty of any kind, expressed or implied, including the warranties of merchantability or fitness for a particular purpose, with regard to the information, examples, and computer source code presented in this document and on the accompanying diskettes. Everything provided in this document and on the accompanying computer source code, if any, is provided as is. Craig Pelkie shall not be liable in any event for incidental or consequential damages or any other claims, pursuant to your use of any of the techniques presented in this document, or your use of the computer source code, even if Craig Pelkie has been advised of the possibility of such damages. You are responsible for testing any and all programs, configurations, commands, and procedures described in this document prior to using the programs, configurations, commands, and procedures with important user data. You must ensure that adequate and sufficient backup of important user data is available, in the event that recovery of the important user data is required.

3 One of the primary concerns you should have when you connect your AS/400 to the Internet is how to prevent harm to your system. Simply plugging in 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 include: Install and use a firewall Use Exit Point programs for TCP/IP servers that support Exit Points Starting with OS/400 V4R3, use IP Packet Filtering This article shows a sample of how to use IP Packet Filtering on the AS/400 system. Using the sample configuration, your AS/400 will 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 is not meant to show a viable configuration, but rather, walks you through the steps required to create and work with an IP packet filtering configuration. 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, the ports and the protocols it is associated with. You can review a list of TCP/IP services available on the AS/400 system with the Work with Service Table Entries (WRKSRVTBLE) command. Figure 1 shows a sample of the command output, scrolled forward to 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. Figure 1: The WRKSRVTBLE display shows a list of TCP/IP services, ports and protocols used. IPF01 1

4 As shown in Figure 1, there are four services associated with FTP on two ports. FTP control (port 21) is used when a request for FTP processing is received at the AS/400 system, for example, a get request. FTP data (port 20) is used when the server responds to the request. Although Transmission Control Protocol (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 so that you can configure the IP packet filters, if you intend to create comprehensive filters. A third protocol, Internet Control Message Protocol (ICMP) is not shown as being used with FTP, but is used with other services and can be specified in a filter. The IP Packet Security Program The AS/400 IP Packet Security program is accessed through AS/400 Operations Navigator. You get to the program in the Network, IP Security branch, as shown in Figure 2. Right-click the IP Packet Security entry in the right panel and select the Configuration item in the pop-menu to display the IP Packet Security program (Figure 3). Figure 2: The IP Packet Security program is located in the AS/400 Operations Navigator. IPF02 2

5 Figure 3: The IP Packet Security dialog is used to configure rules for NAT and IP filters. There are two major functions of the IP Packet Security program: Configure Network Address Translation (NAT), which lets you hide internal IP addresses from the external network. This 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 be originating from only one IP address. When receiving incoming response traffic, NAT determines the original requester of the data and forwards it to them. NAT is not further described 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 upon the type of service, the source or destination address, the direction (inbound, outbound or both) of the packets, and the physical interface (communications line) the packets use. IPF03 3

6 Filtering Requirements If you have multiple TCP/IP interfaces defined in your system, you must define a set of filter rules for each interface, if you define filter rules for any interface. For example, you might have two Ethernet adapters in your AS/400 system, the first connected to a router out to the Internet, the second used for your internal network. You will 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 need to create a filter for that adapter, which will probably be an allow all filter. If you are 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 of the same filter rules for the multiple interfaces, you can create one set of rules for FTP, then include that set in the configuration for each interface. There are two advantages to creating include sets of rules: It is easier to create, verify and implement one set of rules, rather than a separate set for each interface. If you need to change a rule, for example, to relax it or make it more stringent, you only need to make the change in one place, rather than for each individual interface. If you only have one or two interfaces on your AS/400 system, it will probably not make much sense 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. In most cases, you probably want the deny all rule to be in effect, as you usually define rules in terms of the few cases you will allow, followed by deny all for everything not explicitly allowed. If you don t understand the deny all rule, you might create a working, verified set of packet filtering rules, activate the rules, then find yourself locked out of your system. For example, in my tests, I created a simple rule to log FTP requests. After verifying and applying the rules, I found that Operations Navigator and all PC5250 emulation sessions were frozen. I also could not start new sessions. To recover, I had to sign-on using a terminal with a non-tcp/ip connection (for example, twinax or ASCII workstation controller). You can also use a PC attached with the Client Access console cable. Once back on the system, I ran the Remove TCP/IP Table (RMVTCPTBL) command to remove the filtering rules from the system. The rules are stored as files in the AS/400 Integrated File System (IFS). The files themselves are not removed, but the rules are deactivated so that you can get back in to your system. To complete my tests to log FTP server usage, I added an allow all rule to allow all other packets to be accepted. Because the allow all rule is in the set of rules that I defined, it is encountered before the default deny all rule. With packet filtering, the first applicable rule is used; rules following that rule are skipped. Since my allow all is encountered first, I am able to log FTP usage and let everything else through. Based on my experience with defining rules, it may be prudent to not define packet filter rules until you can get everybody off the system. You also need to have physical access to a device that can contact your AS/400 system using a connection type other than TCP/IP, in case you need to deactivate the rules tables. 4

7 Defining Services Although not required, you can define and name services that you want to apply filter rules to. You define a service by right-clicking on the Services branch in the left frame of the IP Packet Security dialog (Figure 3), then select the New Service Alias menu item from the pop-up menu. The Service Alias Properties dialog shown in Figure 4 is displayed. Figure 4: Configure a Service Alias so that you can easily refer to a protocol and the ports used. Using the dialog, 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 for all packets using TCP protocol TCP/Starting for packets using TCP protocol when the service is started UDP for all packets using UDP protocol * - for all packets using any of these protocols If you intend to filter (deny or accept) all packets for a service, you will probably specify the * option. For my purpose, which was to log FTP requests to my AS/400, I could select the TCP/Starting option, since I am only interested in packets sent when an FTP request is initiated. The Source port and Destination port options let you specify which ports apply to the service. For inbound requests (packets sent to your AS/400 system), you will probably specify the Source port as = * (equal to any ), since you may not know the port number on the system where the request is originating. The Destination port specifies = 21, which is the port assigned to the FTP control function on the AS/400 (from the WRKSRVTBLE display). IPF04 5

8 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 on the Filters branch in the left frame of the IP Packet Security program, then click the New Filter item on the pop-up menu. The Filter Properties dialog shown in Figure 5 is displayed. Figure 5: You define a new filter using the Filter Properties dialog. The Set name is used 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 are going to define ten filter rules, eight of which will be used on two different interfaces, you can assign the same set name to the eight rules, and assign another set name 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. If it makes more sense to have only one rule per set, simply assign a unique set name to each filter rule. The Action entry is either Permit or Deny. Direction is Inbound, Outbound, or * (both). The Source address name and Destination address name entries are used to identify specific IP addresses that packets originate from or are directed to. I used the special value * for both addresses, which means that all source and destination addresses are permitted. Fragments can be None, Headers or *. Because there are some security considerations when you allow fragmented packets, you may want to use the default value None if you are using packet filtering to help secure your system. The Journaling option is used to indicate whether or not you want to write a journal entry when this filter rule is used. The options are None and Full. In my FTP logging test I selected the Full option. You can 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 day s worth of typical packet usage data, you will have a good idea of IPF05 6

9 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 what types of IP packets are being denied, which may possibly indicate that your system is being probed. The Services panel of the Filter Properties dialog is shown in Figure 6. Use this panel to identify the type of service that the filter applies to. The Service name option is used to specify that this filter rule uses the previously created service alias for FTP control packets (see Figure 4). If you compare Figure 4 with the Service entries shown in Figure 6 (the grayed-out fields in the middle of the panel), you will see that the same entry fields are used. This points out the advantage of defining the Service Alias: you specify all of the entry fields once, and assign a name to the service. If you did not 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 by using the Service Alias. The ICMP service is used if you need to filter ICMP packets. Like the Service Alias, you can also create an ICMP Alias if you will be creating multiple filters using the same rules. Figure 6: The Services tab of the Filter Properties dialog is used to assign a service to a filter rule. IPF06 7

10 Assignment to an Interface Once you have your filter rules in place, you can assign them to your interfaces. On the IP Packet Security dialog (Figure 3), right-click the Filter Interfaces branch, then select New Filter Interface from the pop-up menu. The Filter Interface Properties dialog shown in Figure 7 is displayed. Figure 7: You define a filter interface for each TCP/IP interface on your system. 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 system. IP address you can enter the IP address assigned to the TCP/IP interface. Point-to-point profile name if you have defined a point-to-point interface, you specify its name. After selecting the interface, click the Add button to add the first Set name to the interface. The set name is specified when you create the filter rule, as shown in Figure 5. You can add as many set names as you need to the interface, by simply clicking the Add button again and entering the set name. The order that you add sets is important, since filter rules are processed in the order 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 on the IP Packet Security dialog (Figure 8), by dragging and dropping a statement in the right side panel of the dialog. You need to add at least one set name for each of the TCP/IP interfaces on your AS/400 system. If you want to remove packet filter rules from an interface, you must remove the rules from all interfaces. IPF07 8

11 Figure 8: The IP Packet Security dialog, after all filter rules have been defined. Verify and Activate After configuring your interfaces, you can verify your rules. On the IP Packet Security dialog (Figure 8), click the File, Verify menu item (you can also click the toolbar icon that looks like a magnifying glass). The verification process examines all of the filter rules that you configured and sends error and completion messages to the bottom of the IP Packet Security dialog (Figure 9). IPF08 Figure 9: Packet filter verification errors are displayed at the bottom of the panel. IPF09 9

12 In my tests, I found the error messages to be almost incomprehensible. A great deal of the problem is probably my unfamiliarity with the terminology used for packet security configuration. What my tests pointed out is that it is advantageous to verify your rules as you go along. Rather than add and attempt to verify all of the rules, enter a rule or two, then verify. You particularly want to verify rules when there is a relationship between statements, for example, a statement for an interface depends upon the set name entered on a filter rule. After successfully verifying the rules, you can activate the rules. 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 File, Activate menu item or click the rightpointing arrow icon in the toolbar. Assuming that your rules do not then lock you out, 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. There are actually two journals that are created for you, both in library QUSRSYS: QIPFILTER contains journal entries related to packet filtering activities QIPNAT contains journal entries related to Network Address Translation activities A sample journal entry from the QIPFILTER journal is shown in Figure 10. 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 Figure 10: The IP filter journal shows the Permit rule being applied for FTP. IPF10 10

13 Along with the two journals, there are two system supplied files you can use in the OUTFILE parameter on the Display Journal (DSPJRN) command to format the data in the journal entries: QSYS/QATOFIPF output file for the IP Packet Filter journal entries QSYS/QATOFNAT output file for the NAT journal entries The format of the QATOFIPF output file is shown in Table 1. By specifying the output file on the DSPJRN command, you create a data file from the journal that can be used in programs or queries to analyze the journal. Field Name TFENTL TFSEQN TFCODE TFENTT TFTIME TFRES TFLINE TFREVT TFPDIR TFRNUM TFFACT TFPROT TFSRCA TFSRCP TFDSTA TFDSTP TFTEXT Description Entry length. Sequence number. Journal code, always M. Entry type, always TF. Timestamp. Reserved. Line description. Rule event: L* or L when rules loaded U* when rules unloaded. A when filter action. IP packet direction: I inbound O outbound Rule number. Filter action taken, DENY or PERMIT Transport protocol 1 ICMP 6 TCP 17 UDP Source IP address. Source port. Destination IP address. Destination port. Additional text. Table 1: Fields used in file QSYS/QATOFIPF. 11

14 Performance Impacts When you enable IP packet filtering, your AS/400 system inspects every IP packet it receives. This obviously has some impact on performance. If you then add journaling, the performance impact is even greater. IBM performed an informal test and documented it in the Redbook, V4 TCP/IP for AS/400: More Cool Things Than Ever (SG ). The test suggests that on average, compared to a configuration with no packet filtering, filtering without journaling results in a 47% increase in average response time, and filtering with journaling results in an 87% increase in average response time. Journaling is obviously very expensive in this context, but if your purpose is to gather statistics so that you can decide which rules to implement, it represents a good trade-off, since it is easy to enable and disable. Use Where Needed In some cases, you won t need to use IP packet filtering. For example, if you have a firewall or router that is performing packet filtering for your network, there may not be any point in performing the same filtering on the AS/400 system. 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 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. IP packet filtering can be quite involved to configure correctly. Unless you are a network engineer, you probably won t have many chances to practice configuring IP packet filters, so the chances for creating an incorrect configuration are high. However, IP packet filtering is certainly better than nothing (no firewall) if you are connecting to an external network. 12