HP-UX IPFilter V17 Administrator Guide

HP-UX 1 1i v2 and HP-UX 1 1i v3

HP Part Number: 5900-0395A Published: October 2009 Edition: 1

 Copyright 2001-2009 Hewlett-Packard Development Company, L.P Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental, or consequential damages in connection with the furnishing, performance, or use of this material. Warranty A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your

local Sales and Service Office. U.S. Government License Proprietary computer software. Valid license from HP required for possession, use, or copying. Consistent with FAR

12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendors standard commercial license. Copyright Notice Copyright 20012009 Hewlett-Packard Development Company, L.P. All rights reserved. Reproduction, adaptation, or

translation of this document without prior written permission is prohibited, except as allowed under the copyright laws. Trademark Notices UNIX is a registered trademark of The Open Group.

Table of Contents
About This Document .....................................................................................................13
Intended Audience................................................................................................................................13 New and Changed Information in This Edition...................................................................................13 New Features in this Release...........................................................................................................13 Fixes in this Release.........................................................................................................................14 Fixes for HP-UX 11i v3...............................................................................................................14 QXCR1000923645Provide tunable to enable/disable NAT functionality..........................14 QXCR1000923671Enhancement to list interfaces not covered..........................................14 QXCR1000888008The ipfstat -io and ipfilter -q commands return the wrong status.....................................................................................................................................14 QXCR1000866813The ipfilter(8) command removes secondary and further IP addresses by -d option.........................................................................................................14 QXCR1000926632The pfilboot script does not unplumb interface when interface is down.....................................................................................................................................14 QXCR1000926637The ipfstat -Q command causes panic when pfil module is not bound to any interface..........................................................................................................14 QXCR1000926726Multicast packets more than 84 bytes are corrupted in IPFilter and dropped in IP module...........................................................................................................14 QXCR1000950055The ipmon utility does not format IP addresses and protocol correctly.................................................................................................................................14 QXCR1000971666ipfboot stop forces ip_forward_directed_broadcasts back to 1 ........................................................................................................................................14 Fixes for HP-UX 11i v2...............................................................................................................15 QXCR1000923645Provide tunable to enable/disable NAT functionality..........................15 QXCR1000926726Multicast packets more than 84 bytes are corrupted in IPFilter and dropped in IP module...........................................................................................................15 QXCR1000950055The ipmon utility does not format IP addresses and protocol correctly.................................................................................................................................15 QXCR1000971666ipfboot stop forces ip_forward_directed_broadcasts back to 1 ........................................................................................................................................15 Typographic Conventions.....................................................................................................................15 Related Information..............................................................................................................................16 Publishing History................................................................................................................................17 HP Encourages Your Comments..........................................................................................................17

1 Overview.......................................................................................................................19
1.1 Benefits and Features......................................................................................................................19 1.2 Supported and Unsupported Features............................................................................................20

2 Installing HP-UX IPFilter................................................................................................21

2.1 Overview of HP-UX IPFilter Installation........................................................................................21 2.1.1 Installation and Configuration Checklist................................................................................21 2.2 Step 1: Checking HP-UX IPFilter Installation Prerequisites...........................................................21 2.3 Step 2: Installing HP-UX IPFilter.....................................................................................................21 2.4 Step 3: Verifying the Installation.....................................................................................................23 2.5 Step 4: (Optional) Modifying Kernel Tunable Parameters..............................................................23 2.6 Removing HP-UX IPFilter...............................................................................................................23

Table of Contents

3 Configuring and Loading IPv4 Filter Rules................................................................25

3.1 IPv4 Filter Rules Configuration File................................................................................................27 3.1.1 Format.....................................................................................................................................27 3.1.2 Rule Order and Processing......................................................................................................27 3.2 Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports...............28 3.2.1 pass and block: Specifying the Filter Action...........................................................................28 3.2.2 in and out: Specifying the Filter Direction..............................................................................28 3.2.3 proto: Specifying the Upper Layer Protocol...........................................................................28 3.2.4 from and to: Specifying IP Addresses and Subnets................................................................28 3.2.4.1 Examples.........................................................................................................................29 3.2.4.2 all: Specifying All IP Addresses......................................................................................29 3.2.4.2.1 Example...................................................................................................................29 3.2.5 port: Specifying TCP and UDP Ports......................................................................................29 3.2.5.1 Service Names.................................................................................................................30 3.3 Rate-based Filtering.........................................................................................................................30 3.4 Processing Options: Logging Packets, Optimizing Rule Processing, and Specifying Interfaces....31 3.4.1 Option Order...........................................................................................................................31 3.4.2 log: Logging Packets................................................................................................................31 3.4.3 quick: Optimizing IPFilter Rules Processing..........................................................................31 3.4.4 on: Filtering by Network Interfaces........................................................................................32 3.5 Protocol Options: TCP Flags, IP Options and Fragments, ICMP Types and State Information.....33 3.5.1 Option Order...........................................................................................................................33 3.5.2 flags: Specifying TCP Header Flags........................................................................................33 3.5.3 with opt and ipopts: Specifying IP Options............................................................................34 3.5.3.1 not opt: Specifying Options Not Set................................................................................34 3.5.3.2 ipopts: Specifying Any IP Options..................................................................................34 3.5.4 with frag and with short: Selecting Fragmented IP Packets...................................................35 3.5.4.1 with frag: Selecting IP Packet Fragments........................................................................35 3.5.4.2 with short: Selecting Short Fragments............................................................................35 3.5.5 icmp-type and code: Filtering ICMP Traffic by Type and Code.............................................35 3.5.6 keep state: Protecting TCP, UDP, and ICMP Sessions.............................................................35 3.5.6.1 Allocating Memory for the State Table...........................................................................36 3.5.6.2 Using Keep State with TCP.............................................................................................36 3.5.6.2.1 Idle Timeout............................................................................................................37 3.5.6.3 Using Keep State with UDP............................................................................................37 3.5.6.3.1 Idle Timeout............................................................................................................37 3.5.6.4 Using Keep State with ICMP...........................................................................................37 3.5.6.4.1 Idle Timeout............................................................................................................37 3.5.6.4.2 ICMP Error Status Messages...................................................................................37 3.5.7 State Aging..............................................................................................................................37 3.5.7.1 Rule Examples.................................................................................................................38 3.5.8 keep frags: Handling IP Fragments........................................................................................38 3.6 Sending Responses for Blocked TCP and UDP Packets..................................................................39 3.6.1 return-rst: Responding to Blocked TCP Packets.....................................................................39 3.6.2 return-icmp-as-dest: Responding to Blocked UDP Packets....................................................39 3.7 Improving Performance with Rule Groups ....................................................................................40 3.8 Loading IPv4 Filter Rules................................................................................................................42 3.8.1 Verifying IPv4 Filter Rules......................................................................................................42 3.8.2 Removing IPFilter Rules..........................................................................................................43 3.9 Rule Tags.........................................................................................................................................43 3.9.1 Log Tags...................................................................................................................................43 3.9.2 NAT Tags.................................................................................................................................43

Table of Contents

4 Configuring and Loading IPv6 Filter Rules................................................................45

4.1 IPv6 Filter Rules Configuration File................................................................................................45 4.2 Features Not Supported with IPv6..................................................................................................46 4.3 IPv6 Filter Rule Syntax Differences.................................................................................................46 4.3.1 Specifying Addresses..............................................................................................................46 4.3.2 Filtering ICMPv6 Packets........................................................................................................46 4.3.2.1 Stateful ICMPv6..............................................................................................................46 4.3.3 IPv6 Extension Headers..........................................................................................................47 4.3.4 Filtering Tunneled Packets......................................................................................................47 4.3.5 Filtering IPv6 Fragments.........................................................................................................48 4.3.6 Sending ICMPv6 Responses....................................................................................................48 4.4 Loading IPv6 Filter Rules................................................................................................................49 4.4.1 Verifying IPv6 Filter Rules......................................................................................................49

5 Configuring and Loading Dynamic Connection Allocation (DCA) Rules...............51

5.1 DCA with HP-UX IPFilter...............................................................................................................52 5.1.1 Overview: DCA Functionality................................................................................................52 5.1.1.1 Using DCA......................................................................................................................52 5.2 DCA Rules Configuration Files.......................................................................................................52 5.3 DCA Rule Syntax and Keywords....................................................................................................53 5.3.1 DCA Rule Conditions..............................................................................................................53 5.4 keep limit: Limiting Connections....................................................................................................53 5.4.1 Limiting Connections by IP Address......................................................................................53 5.4.2 Limiting Connections by Subnet.............................................................................................54 5.4.3 Limiting Connections by IP Address Range...........................................................................54 5.4.4 Default Individual Connection Limits....................................................................................54 5.5 return-rst: Returning RESET Packets..............................................................................................54 5.6 cumulative: Limiting Cumulative Connections..............................................................................54 5.7 log limit: Logging Exceeded Connections.......................................................................................54 5.7.1 Summary Logs and Cumulative Limits..................................................................................55 5.8 log limit freq: Log Frequency .........................................................................................................55 5.9 Loading and Modifying DCA Rules...............................................................................................57 5.9.1 Updating keep limit Rules......................................................................................................57 5.9.1.1 Changing the Current Individual, Subnet, or IP Address Range Rule...........................57 5.9.1.2 Updating a Subnet or IP Address Range Rule................................................................58 5.9.2 Adding New keep limit Rules.................................................................................................58 5.9.2.1 To Add a New Individual keep limit Rule:.....................................................................58 5.9.2.2 To Add a New Subnet or IP Address Range Rule:.........................................................58 5.9.3 Integrating keep limit Rules....................................................................................................58 5.9.4 Extracting an Individual Rule from a Subnet Rule.................................................................59 5.10 Enabling and Disabling DCA........................................................................................................60 5.10.1 Enabling and Disabling DCA Using ipf................................................................................60 5.10.2 Configuring IPFilter to Enable DCA at System Startup Time..............................................60 5.11 Using IPFilter Utilities with DCA..................................................................................................60 5.11.1 keep limit Rules and Rule Hits..............................................................................................61 5.11.1.1 Limits and Hit Counts...................................................................................................61 5.12 Monitoring and Allocating Memory for DCA Data......................................................................62

6 Configuring and Loading Network Address Translation (NAT) Rules....................63

6.1 NAT Rules Configuration File.........................................................................................................63 6.1.1 Format.....................................................................................................................................63 6.1.2 Rule Order and Processing......................................................................................................63 6.1.2.1 Using NAT Rules with Filter Rules.................................................................................63
Table of Contents 5

6.1.2.1.1 Inbound Packets......................................................................................................63 6.1.2.1.2 Outbound Packets...................................................................................................64 6.2 NAT Keywords................................................................................................................................65 6.2.1 Rule Examples.........................................................................................................................65 6.3 map and portmap: Mapping Outbound Packets............................................................................66 6.3.1 Examples.................................................................................................................................66 6.3.2 portmap Keyword...................................................................................................................66 6.3.3 map-block: Mapping to a Block of Addresses........................................................................67 6.4 rdr: Redirecting Inbound Packets....................................................................................................68 6.4.1 Redirecting Packets to a Specific Port.....................................................................................68 6.4.2 Using NAT Redirection with Filtering....................................................................................68 6.4.3 Using the rdr and round-robin Keywords for Load Balancing..............................................69 6.4.4 Sticky NAT Sessions................................................................................................................69 6.4.5 Checking Connection Health with l4check..........................................................................69 6.4.5.1 Syntax..............................................................................................................................69 6.4.5.2 Options............................................................................................................................69 6.4.5.3 Sample config File...........................................................................................................70 6.5 bimap: Bidirectional Mapping........................................................................................................71 6.6 Loading NAT Rules.........................................................................................................................72

7 Address Pooling...........................................................................................................73
7.1 The ippool Utility............................................................................................................................73 7.2 The ippool.conf File.........................................................................................................................73 7.3 Configuring Address Pool...............................................................................................................73 7.3.1 Syntax......................................................................................................................................73 7.3.2 Examples.................................................................................................................................74

8 Tips for Securing Your System.....................................................................................75

8.1 Blocking Services by Port Number and Protocol............................................................................75 8.1.1 Example: Firewall on a Web Server.........................................................................................75 8.1.2 Example: Firewall for Multiple Services.................................................................................75 8.2 Creating a Complete Filter by Interface..........................................................................................76 8.3 Combining IP Address and Network Interface Filtering................................................................76 8.4 Using Bidirectional Filtering...........................................................................................................77 8.5 Using HP-UX IPFilter with End System Security Features.............................................................77

9 Troubleshooting HP-UX IPFilter....................................................................................79

9.1 Viewing IPFilter Statistics and Active Rules with ipfstat...............................................................80 9.1.1 Syntax......................................................................................................................................80 9.1.2 Options....................................................................................................................................80 9.1.3 Examples.................................................................................................................................81 9.2 Testing Rules with ipftest................................................................................................................85 9.2.1 Syntax......................................................................................................................................85 9.2.2 Options....................................................................................................................................85 9.2.3 Example...................................................................................................................................86 9.3 Logging IPFilter Packets..................................................................................................................88 9.3.1 Using the log keyword to Configure IPFilter Logging...........................................................88 9.3.1.1 level log-level.............................................................................................................88 9.3.1.2 first...................................................................................................................................88 9.3.1.3 body.................................................................................................................................89 9.3.2 Using ipmon to View IPFilter Log Entries..............................................................................90 9.3.2.1 Syntax..............................................................................................................................90
6 Table of Contents

9.3.2.2 Options............................................................................................................................90 9.3.2.3 Examples.........................................................................................................................90 9.3.2.4 ipmon and DCA Logging................................................................................................91 9.3.3 Analyzing IPFilter Log Events................................................................................................91 9.3.3.1 Syntax..............................................................................................................................92 9.3.3.2 ipmon.conf File Syntax....................................................................................................92 9.4 Troubleshooting Tips.......................................................................................................................92 9.5 Reporting Problems.........................................................................................................................94

10 HP-UX IPFilter Utilities.................................................................................................95

10.1 The ipf Utility................................................................................................................................95 10.1.1 Syntax....................................................................................................................................95 10.1.2 Options..................................................................................................................................95 10.1.3 Example.................................................................................................................................97 10.2 The ipnat Utility.............................................................................................................................98 10.2.1 Syntax....................................................................................................................................98 10.2.2 Options..................................................................................................................................98 10.2.3 Example.................................................................................................................................98 10.3 The ipfilter Utility (HP-UX 11i v3)................................................................................................99 10.3.1 Syntax....................................................................................................................................99 10.3.2 Options..................................................................................................................................99 10.3.3 Example.................................................................................................................................99 10.4 The ippool Utility..........................................................................................................................99 10.4.1 Syntax....................................................................................................................................99 10.4.2 Global Options.....................................................................................................................100 10.4.3 Command Options..............................................................................................................100

1 1 HP-UX IPFilter and ICMP..........................................................................................101

11.1 Filtering ICMPv4 Packets by Type and Code (icmp-type and code)..........................................101 11.2 Configuring ICMPv4 Kernel Parameters....................................................................................102 11.2.1 Dead Gateway Detection (ip_ire_gw_probe)......................................................................103 11.2.1.1 IPFilter Configuration..................................................................................................103 11.2.2 ICMP Source Quench (ip_send_source_quench)................................................................103 11.2.2.1 IPFilter Configuration..................................................................................................103 11.2.3 ICMP Redirects (ip_send_redirects)....................................................................................104 11.2.3.1 IPFilter Configuration..................................................................................................104 11.2.4 PMTU Discovery (ip_pmtu_strategy).................................................................................104 11.2.4.1 IPFilter Configuration..................................................................................................104 11.2.5 ICMP Echo Request Broadcasts (ip_respond_to_echo_broadcast).....................................105 11.2.6 Using ndd to Configure ICMPv4 Kernel Parameters..........................................................105 11.3 Filtering ICMPv6 Packets by Type and Code (icmpv6type and code)......................................106 11.4 Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages..............................107 11.4.1 Configuring ipf_icmp6_passthru........................................................................................107 11.4.1.1 Configuring ipf_icmp6_passthru on HP-UX 11i v2 and HP-UX 11i v3......................107 11.4.1.2 Configuring ipf_icmp6_passthru on HP-UX 11i v1....................................................107

12 HP-UX IPFilter and FTP.............................................................................................109

12.1 FTP Basics....................................................................................................................................109 12.2 WU-FTPD on HP-UX...................................................................................................................109 12.3 Running an FTP Server................................................................................................................110 12.3.1 Active FTP............................................................................................................................110 12.3.2 Passive FTP..........................................................................................................................110 12.4 Running an FTP Client................................................................................................................110
Table of Contents 7

12.4.1 Active FTP............................................................................................................................110 12.4.2 Passive FTP..........................................................................................................................111

13 HP-UX IPFilter and NFS and RPC...........................................................................113

13.1 Introduction.................................................................................................................................113 13.2 Configuring NFS to Use Fixed Ports...........................................................................................113 13.3 Using the rpc.ipfboot Script to Update IPFilter Rules.................................................................114 13.3.1 Rules Files............................................................................................................................114 13.3.2 RPC Rules Configuration File..............................................................................................115

14 HP-UX IPFilter and IPSec .........................................................................................117

14.1 IPFilter and IPSec Basics..............................................................................................................117 14.2 IPSec UDP Negotiation................................................................................................................117 14.3 When Traffic Appears to Be Blocked...........................................................................................118 14.4 Allowing Protocol 50 and Protocol 51 Traffic..............................................................................119 14.5 IPSec Gateways............................................................................................................................120

15 HP-UX IPFilter and Serviceguard............................................................................121

15.1 Using HP-UX IPFilter with Serviceguard ...................................................................................121 15.1.1 Enabling or Disabling IPFilter.............................................................................................121 15.1.2 Local Failover.......................................................................................................................121 15.1.3 Remote Failover...................................................................................................................122 15.1.3.1 Filtering on a Package IP Address...............................................................................122 15.1.3.2 Mandatory Rules.........................................................................................................122 15.1.3.2.1 Rules for Intra-Cluster Communication..............................................................123 15.1.3.3 Rules for External Access............................................................................................124 15.1.3.3.1 WBEM Access......................................................................................................124 15.1.3.3.2 Quorum Server....................................................................................................124 15.1.3.3.3 Remote Command Execution..............................................................................124 15.1.3.3.4 Cluster Object Manager.......................................................................................125 15.1.3.3.5 Serviceguard Manager Plug-in............................................................................125 15.1.3.3.6 Serviceguard Manager Standalone.....................................................................125 15.1.3.3.7 Consolidated Log (clog)....................................................................................126 15.1.4 DCA Remote Failover..........................................................................................................126

A Product Specifications...............................................................................................127
A.1 Configuration Files.......................................................................................................................127 A.1.1 Example Configuration Files................................................................................................127 A.2 Unsupported Features..................................................................................................................128 A.3 Supported Utilities.......................................................................................................................128 A.4 Unsupported Utilities...................................................................................................................128 A.5 Supported and Unsupported Interfaces.......................................................................................128

B HP-UX IPFilter Configuration Examples....................................................................131

B.1 BASIC_1.FW..................................................................................................................................131 B.2 BASIC_2.FW..................................................................................................................................132 B.3 example.1.......................................................................................................................................133 B.4 example.2.......................................................................................................................................133 B.5 example.3.......................................................................................................................................133 B.6 example.4.......................................................................................................................................134 B.7 example.5.......................................................................................................................................134
8 Table of Contents

B.8 example.6.......................................................................................................................................134 B.9 example.7.......................................................................................................................................135 B.10 example.8.....................................................................................................................................135 B.11 example.9.....................................................................................................................................135 B.12 example.10...................................................................................................................................135 B.13 example.11...................................................................................................................................135 B.14 example.12...................................................................................................................................136 B.15 example.13...................................................................................................................................136 B.16 example.sr....................................................................................................................................137 B.17 firewall.........................................................................................................................................138 B.18 server...........................................................................................................................................138 B.19 tcpstate.........................................................................................................................................138 B.20 BASIC.NAT..................................................................................................................................139 B.21 nat.eg...........................................................................................................................................139 B.22 nat-setup......................................................................................................................................140 B.23 ipmon.conf...................................................................................................................................141 B.24 pool.conf......................................................................................................................................141

C HP-UX IPFilter Kernel Tunable Parameters...............................................................143

C.1 Overview.......................................................................................................................................143 C.2 fr_tcpidletimeout..........................................................................................................................144 C.3 fr_statemax....................................................................................................................................144 C.4 ipf_icmp6_passthru......................................................................................................................144 C.5 ipl_buffer_sz.................................................................................................................................144 C.5.1 Displaying Logging Buffer Statistics....................................................................................145 C.6 ipl_suppress..................................................................................................................................145 C.7 ipl_logall.......................................................................................................................................145 C.8 Configuring and Viewing Kernel Tunable Parameters................................................................145 C.8.1 Configuring Kernel Tunable Parameters on HP-UX 11i v3..................................................145 C.8.2 Configuring Kernel Tunable Parameters on HP-UX 11i v1 and HP-UX 11i v2...................146 C.8.2.1 Configuring Kernel Tunable Parameters Using ndd....................................................146 C.8.2.2 Configuring fr_statemax and fr_tcpidletimeout Using kmtune or kctune..................146 C.9 Enabling and Disabling NAT Functionality.................................................................................147

D HP-UX IPFilter Static Linking......................................................................................149

D.1 Overview......................................................................................................................................149 D.2 Static Linking of HP-UX IPFilter on HP-UX 11i v2 and HP-UX 11i v3........................................149 D.3 Static Linking of HP-UX IPFilter on HP-UX 11i v1......................................................................149

E Performance Guidelines............................................................................................151
E.1 System Configuration...................................................................................................................151 E.2 Rule Loading.................................................................................................................................152 E.3 Rule Configuration........................................................................................................................152 E.4 Traffic.............................................................................................................................................153 E.5 Performance Monitoring...............................................................................................................154

Index...............................................................................................................................155

Table of Contents

List of Figures
14-1 14-2 14-3 14-4 14-5 14-6 14-7 E-1 E-2 IPFilter and IPSec ........................................................................................................................117 Scenario One................................................................................................................................117 Scenario Two................................................................................................................................118 Scenario Three.............................................................................................................................118 Packet with Unencrypted TCP Data............................................................................................119 Packet with IPSec-Encrypted TCP Data .....................................................................................119 Scenario Four...............................................................................................................................119 Processing packets through a system..........................................................................................151 System Operation........................................................................................................................154

10

List of Figures

List of Tables
1 11-1 A-1 E-1 Publishing History Details............................................................................................................17 ICMP Type and Codes.................................................................................................................101 HP-UX IPFilter Supported Interfaces........................................................................................129 Processing Packets through a System..........................................................................................151

11

12

About This Document

This document describes how to install, configure, and troubleshoot HP-UX IPFilter version 17. The latest version of this document can be found online at http://docs.hp.com.

Intended Audience
This document is intended for network managers or network security administrators who install, configure, and troubleshoot HP-UX IPFilter on HP 9000 systems. Administrators are expected to have knowledge of HP-UX operating system concepts, commands, and configuration. Administrators are also expected to have knowledge of TCP/IP networking concepts and network configuration. This document is not a tutorial.

New and Changed Information in This Edition

The documentation reflects the following changes to the HP-UX IPFilter product.

New Features in this Release

IMPORTANT: The following new features are supported on HP-UX 11i v3 only. This new feature controls packet flow by defining the rate (packets per second) of matching packets passing through a machine. For more information, see Rate-based Filtering (page 30). Address pools establish a single reference to name a group of address/netmask pairs. For more information, see Chapter 7 (page 73). This new feature simplifies IPFilter log analysis and allows monitoring for specific log events. For more information, see Logging IPFilter Packets (page 88). NAT and ipf rules can refer to each other with a tag, creating an implied join that forms part of the packet matching. For more information, see Rule Tags (page 43). You can override the default values and specify a different state age in IPFilter rules using age options. For more information, see State Aging (page 37). Rule groups can now be referenced by name. For more information, see Improving Performance with Rule Groups (page 40). NAT sessions can be redirected to the same destination IP to achieve source IP-based persistence. For more information, see Sticky NAT Sessions (page 69). The l4check utility monitors for dead IP/port pairs and dynamically removes them from the list of load balanced IP addresses. For more information, see Checking Connection Health with l4check (page 69).

Rate-based filtering

Address pooling

ipmon configuration file

Rule tags

State aging

Named groups

Sticky NAT sessions

The l4check utility

Intended Audience

13

Fixes in this Release

Fixes for HP-UX 1 1i v3
QXCR1000923645Provide tunable to enable/disable NAT functionality. The new ipnat_enable tunable is provided to enable/disable NAT functionality. By default, this tunable is set to 1. If you do not use NAT functionality, disabling this tunable will improve performance. QXCR1000923671Enhancement to list interfaces not covered. The -l option to ipfilter is provided. This option lists the interfaces and shows which are protected or unprotected by IPFilter. For more information, seeThe ipfilter Utility (HP-UX 11i v3) (page 99). QXCR1000888008The ipfstat -io and ipfilter -q commands return the wrong status. The ipfstat -io and ipfilter -q commands could show IPFilter status as up and running when it is not plumbed into the stack. Two new messages have been added: IPFilter enabled but not filtering. IPFilter enabled and filtering traffic. QXCR1000866813The ipfilter(8) command removes secondary and further IP addresses by -d option. When the ipfilter interactive mode -i option is used with -e or -d, a warning is issued. QXCR1000926632The pfilboot script does not unplumb interface when interface is down. This occurs when IPFilter is disabled and does not recognize a down interface that has the pfil module loaded. In this case, the pfilboot script does not unplumb all interfaces and unload the pfil module. QXCR1000926637The ipfstat -Q command causes panic when pfil module is not bound to any interface. The pfil module is a stream module. When it is not plumbed to any interface and the ipfstat -Qv command is run, the system panics. QXCR1000926726Multicast packets more than 84 bytes are corrupted in IPFilter and dropped in IP module. Multicast packets more than 84 bytes are now received properly when IPFilter is enabled. QXCR1000950055The ipmon utility does not format IP addresses and protocol correctly. The IP addresses are formatted as IPv6 addresses when they are IPv4 addresses. Protocol is displayed as 159 instead of TCP, but can be any other value. QXCR1000971666ipfboot stop forces ip_forward_directed_broadcasts back to 1 ip_forward_directed_broadcasts is an ndd tunable that enables broadcast messages to pass through the system. When IPFilter is enabled, the IPFilter startup rc script, ipfboot is executed as ipfboot start. The ipfboot script sets the ip_forward_directed_broadcasts value to "0" using the ndd command: /usr/bin/ndd -set /dev/ip ip_forward_directed_broadcasts 0 This value is set to stop broadcast storms for security reasons. When IPFilter is disabled with ipfboot stop, the ip_forward_directed_broadcasts value is reset to "1" using the ndd command:
14

/usr/bin/ndd -set /dev/ip ip_forward_directed_broadcasts 1 You can specify ndd tunable values in the /etc/rc.config.d/nddconf file. Prior to this fix, if you set the ip_forward_directed_broadcasts value to "0" in nddconf, the ipfboot stop script reset the value back to "1" without referring to the nddconf file. Now, the /etc/rc.config.d/nddconf file is checked when ipfboot stop is executed. If the ip_forward_directed_broadcasts value is set in nddconf to 0 or 1, the ip_forward_directed_broadcasts value in the ipfbot script is not modified with the ndd command.

Fixes for HP-UX 1 1i v2

QXCR1000923645Provide tunable to enable/disable NAT functionality. The new ipnat_enable tunable is provided to enable/disable NAT functionality. By default, this tunable is set to 1. If you do not use NAT functionality, disabling this tunable will improve performance. QXCR1000926726Multicast packets more than 84 bytes are corrupted in IPFilter and dropped in IP module. Multicast packets more than 84 bytes are now received properly when IPFilter is enabled. QXCR1000950055The ipmon utility does not format IP addresses and protocol correctly. The IP addresses are formatted as IPv6 addresses when they are IPv4 addresses. Protocol is displayed as 159 instead of TCP, but can be any other value. QXCR1000971666ipfboot stop forces ip_forward_directed_broadcasts back to 1 ip_forward_directed_broadcasts is an ndd tunable that enables broadcast messages to pass through the system. When IPFilter is enabled, the IPFilter startup rc script, ipfboot is executed as ipfboot start. The ipfboot script sets the ip_forward_directed_broadcasts value to "0" using the ndd command: /usr/bin/ndd -set /dev/ip ip_forward_directed_broadcasts 0 This value is set to stop broadcast storms for security reasons. When IPFilter is disabled with ipfboot stop, the ip_forward_directed_broadcasts value is reset to "1" using the ndd command: /usr/bin/ndd -set /dev/ip ip_forward_directed_broadcasts 1 You can specify ndd tunable values in the /etc/rc.config.d/nddconf file. Prior to this fix, if you set the ip_forward_directed_broadcasts value to "0" in nddconf, the ipfboot stop script reset the value back to "1" without referring to the nddconf file. Now, the /etc/rc.config.d/nddconf file is checked when ipfboot stop is executed. If the ip_forward_directed_broadcasts value is set in nddconf to 0 or 1, the ip_forward_directed_broadcasts value in the ipfbot script is not modified with the ndd command.

Typographic Conventions
This document uses the following typographical conventions: %, $, or # A percent sign represents the C shell system prompt. A dollar sign represents the system prompt for the Bourne, Korn, and POSIX shells. A number sign represents the superuser prompt. A manpage. The manpage name is audit, and it is located in Section 5.
Typographic Conventions 15

audit(5)

Command Computer output Ctrl+x

A command name or qualified command phrase. Text displayed by the computer. A key sequence. A sequence such as Ctrl+x indicates that you must hold down the key labeled Ctrl while you press another key or mouse button. The name of an environment variable, for example, PATH. The name of an error, usually returned in the errno variable. The name of a keyboard key. Return and Enter both refer to the same key. The defined use of an important word or phrase. Commands and other text that you type. The name of a placeholder in a command, function, or other syntax display that you replace with an actual value. The contents are optional in syntax. If the contents are a list separated by |, you must choose one of the items. The contents are required in syntax. If the contents are a list separated by |, you must choose one of the items. The preceding element can be repeated an arbitrary number of times. Indicates the continuation of a code example. Separates items in a list of choices. A warning calls attention to important information that if not understood or followed will result in personal injury or nonrecoverable system problems. A caution calls attention to important information that if not understood or followed will result in data loss, data corruption, or damage to hardware or software. This alert provides essential information to explain a concept or to complete a task A note contains additional information to emphasize or supplement important points of the main text.

ENVIRONMENT VARIABLE [ERROR NAME] Key Term User input Variable [] {} ...

| WARNING

CAUTION

IMPORTANT NOTE

Related Information
Additional information about HP-UX IPFilter can be found at the http://docs.hp.com in the Internet and Security Solutions collection under HP-UX IPFilter at: http://docs.hp.com/en/internet.html#IPFilter Documents in this collection include: HP-UX IPFilter Version 17 Release Notes HP-UX IPFilter Version 16 Performance White Paper

For information about HP-UX Bastille, see the HP-UX Bastille user guide. This guide is available at: http://docs.hp.com

16

Publishing History
Table 1 Publishing History Details
Manufacturing Part Number 59000395 Supported Operating Systems 11i v2 11i v3 11i v2 11i v3 11i v1 11i v2 11i v3 B9901-90031 11i v1 11i v2 5991-7705 B9901-90021 11i v3 11.0 11i v1 11i v2 A.03.05.13 A.03.05.09 January 2007 February 2004 Supported Versions A.11.23.17 A.11.31.17 A.11.23.16 A.11.31.16 A.11.11.15.01 A.11.23.15.01 A.11.31.15.01 A.03.05.14 December 2006 December 2008 October 2007 Publication Date October 2009

B9901-90044 B9901-90042

HP Encourages Your Comments

HP encourages your comments concerning this document. We are committed to providing documentation that meets your needs. Send any errors found, suggestions for improvement, or compliments to: feedback@fc.hp.com Include the document title, manufacturing part number, and any comment, error found, or suggestion for improvement you have concerning this document.

Publishing History

17

18

1 Overview
HP-UX IPFilter, product number B9901AA version 17, is a TCP/IP packet filter suitable for use as a system firewall. The version strings are as follows:
OS Version HP-UX 11i v3 HP-UX 11i v2 HP-UX IPFilter Version String A.11.31.17 A.11.23.17

HP-UX IPFilter functions as a firewall by examining and limiting packets allowed in and out of an HP-UX system, which can be either an end node or an IP router. Although HP-UX IPFilter is a superset of the functionality in the IPFilter 3.5 Alpha 5 open source version of the product (developed by Darren Reed), HP does not support some of the perimeter firewall features in that release, such as firewall stealth (fastroute). If you are using features that are not supported by HP, you can request support from the open source IPFilter web site at the following URL: http://caligula.anu.edu.au/~avalon For a complete list of commands and utilities that are not supported by HP, see Supported and Unsupported Features (page 20). HP-UX IPFilter version 17 is available from the HP Software Depot at the following URL: http://www.software.hp.com.

1.1 Benefits and Features

HP-UX IPFilter provides the following key benefits: Protects an individual host on an intranet against internal attacks Protects an individual host on an intranet against external attacks that have breached perimeter defenses Provides an alternative to the restricted configuration of Internet Services Protects a bastion host on the perimeter of a private network or in the demilitarized zone (DMZ) Explicitly permit or deny a packet from passing through based on: IP address or a range of IP addresses IP protocol (IP/TCP/UDP) IP fragments IP options IP security classes TCP ports and port ranges UDP ports and port ranges ICMP message type and code Combination of TCP flags Network interface Control incoming TCP connections through Dynamic Connection Allocation (DCA) Support for NAT, which lets an intermediate HP-UX system act as a translator of IP addresses and network ports Send back ICMP error/TCP reset messages for blocked packets Keep packet state information for TCP, UDP, and ICMP Keep fragment state information for any IPv4 packet and the same rule to all related fragments
1.1 Benefits and Features 19

The following major features are included with HP-UX IPFilter:

Drop all fragmented traffic if specified by rule Create extensive logs when required

1.2 Supported and Unsupported Features

See Appendix A (page 127) for a list of supported and unsupported features, including utilities and commands distributed with the open source IPFilter product but not supported by HP. This appendix also lists the network interfaces that are supported and unsupported with HP-UX IPFilter.

20

Overview

2 Installing HP-UX IPFilter

This chapter describes the procedures to install and configure HP-UX IPFilter software on your system. It contains the following sections: Overview of HP-UX IPFilter Installation (page 21) Step 1: Checking HP-UX IPFilter Installation Prerequisites (page 21) Step 2: Installing HP-UX IPFilter (page 21) Step 3: Verifying the Installation (page 23) Step 4: (Optional) Modifying Kernel Tunable Parameters (page 23)

This chapter also describes how to remove HP-UX IPFilter software from your system (Removing HP-UX IPFilter (page 23)).

2.1 Overview of HP-UX IPFilter Installation

The following section summarizes each step in the HP-UX IPFilter installation process.

2.1.1 Installation and Configuration Checklist

The complete the following steps to install HP-UX IPFilter. 1. 2. 3. 4. Check that your system meets the prerequisites. See Step 1: Checking HP-UX IPFilter Installation Prerequisites (page 21) for detailed information about this task. Install HP-UX IPFilter using swinstall. See Step 2: Installing HP-UX IPFilter (page 21) for detailed information about this task. Run the ipf -V and kmadmin commands to verify the installation as described in Step 3: Verifying the Installation (page 23). (Optional) Modify IPFilter kernel tunable parameters.

2.2 Step 1: Checking HP-UX IPFilter Installation Prerequisites

1. Verify that your system uses one of the following operating systems: HP-UX 11i v3 HP-UX 11i v2 To determine the OS version, execute the following command: uname -a 2. Install any required patches. IMPORTANT: Check the latest HP-UX IPFilter Release Notes for all other patch information.

To obtain information about a patch, execute the command: swlist -l patch patch_id 3. Verify that you have superuser or appropriate HP-UX capabilities.

2.3 Step 2: Installing HP-UX IPFilter

The HP-UX IPFilter installation requirements and procedures differ according to the HP-UX version as follows: HP-UX 11i v3 HP-UX IPFilter is installed and disabled by default. You must manually enable IPFilter the first time you install it, or enable it by configuring Bastille/ITS with the Sec20MngDMZ or Sec30DMZ install-time security level.

2.1 Overview of HP-UX IPFilter Installation

21

HP-UX 11i v2 HP-UX IPFilter is installed by default. When installed, HP-UX IPFilter is always enabled.

Use the following steps to load HP-UX IPFilter software using the HP-UX swinstall program. 1. 2. Verify that you have superuser or appropriate capabilities. If the system is an HP-UX 11i v3 system and already has HP-UX IPFilter installed, disable the existing version: /opt/ipf/bin/ipfilter -d CAUTION: HP recommends that you enable or disable IPFilter when interrupting network connectivity is not disruptive. HP recommends that you do not enable or disable HP-UX IPFilter when critical network applications are running. Disabling or enabling IPFilter using briefly brings down all IP interfaces, then brings up only the IP interfaces configured in the /etc/rc.config.d/netconf and /etc/ rc.config.d/netconf-ipv6 files. IP addresses not configured in the netconf or netconf-ipv6 file, such as Serviceguard relocatable IP addresses, are not re-enabled. Enabling or disabling IPFilter causes the system to briefly lose network connectivity. If a system has several IP interfaces or there is heavy network traffic, the time required to re-establish network connectivity might be interpreted as a network or card failure. For example, Serviceguard might interpret a network interruption as a card failure, which can cause it to reform the cluster. 3. 4. If you are installing HP-UX IPFilter from removable media (disk), insert the media (disk) into the appropriate drive. Run the swinstall program using the command: swinstall The Software Selection window and Specify Source window open. 5. Change the Source Host Name, if necessary, enter the depot directory or the mount point of the media drive in the Source Depot Path field. Click OK to return to the Software Selection window. Click Help for more information. The Software Selection window now contains a list of available software bundles to install. 6. 7. Highlight the HP-UX IPFilter software for your system type. Select Mark for Install from the Actions menu to select the product to be installed. With an exception of the manpages, you must install the complete IPFilter product. 8. Select Install from the Actions menu to begin the product installation and open the Install Analysis window. 9. Click OK in the Install Analysis window when the Status field displays a Ready message. 10. Click Yes on the Confirmation window to confirm that you want to install the software. The Install window opens. The Status field in the Install window to check the status. When the fileset is loaded, the Statusfield will be Ready and the Note window opens. The estimated time for processing is three to five minutes. 11. Click OK on the Note window to reboot the system. The user interface disappears and the system reboots. 12. After the system reboots, check the log files in /var/adm/sw/swinstall.log and /var/ adm/sw/swagent.log to verify that the installation was successful.
22 Installing HP-UX IPFilter

13. On HP-UX 11i v3 systems, enable HP-UX IPFilter using the following command: /opt/ipf/bin/ipfilter -e NOTE: Do not run the HP-UX IPFilter product when the system is booted in single-user mode.

2.4 Step 3: Verifying the Installation

Use the following commands to verify the HP-UX IPFilter installation. Verify that HP-UX IPFilter is running using the -V option of the ipf command:
ipf -V ipf: HP IP Filter: v3.5alpha5 (A.11.31.17) (488) Kernel: HP IP Filter: v3.5alpha5 (A.11.31.17) Enabled: yes Filtering: yes Log Flags: 0 = none set Default: pass all, Logging: available Active list: 1

Verify that HP-UX IPFilter has been correctly loaded. On HP-UX 11i v2 and HP-UX 11i v3, enter the following commands:
# kcmodule -v -q pfil # kcmodule -v -q ipf

Verify that the state is loaded.

2.5 Step 4: (Optional) Modifying Kernel Tunable Parameters

HP-UX IPFilter supports kernel tunable parameters that affect IPFilter logging behavior and the IPFilter state table. For information about modifying them, see Appendix C (page 143). In addition, Chapter 11 (page 101) describes system kernel tunable parameters that control ICMP features and how to configure them to optimize security. NOTE: The HP-UX IPFilter installation script disables subnet broadcast packet forwarding by setting the kernel tunable parameter ip_forward_directed_broadcasts to 0. HP recommends that you leave this feature disabled unless you have a specific need for your node to forward subnet broadcast packets. Attackers can use subnet broadcast packet forwarding to amplify attacks in Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks.

2.6 Removing HP-UX IPFilter

Use the following procedure to remove HP-UX IPFilter. 1. On HP-UX 11i v3 systems, disable HP-UX IPFilter: /opt/ipf/bin/ipfilter -d CAUTION: HP recommends that you enable or disable IPFilter when interrupting network connectivity is not disruptive. HP recommends that you do not enable or disable HP-UX IPFilter when critical network applications are running. Disabling or enabling IPFilter using briefly brings down all IP interfaces, then brings up only the IP interfaces configured in the /etc/rc.config.d/netconf and /etc/ rc.config.d/netconf-ipv6 files. IP addresses not configured in the netconf or netconf-ipv6 file, such as Serviceguard relocatable IP addresses, are not re-enabled. Enabling or disabling IPFilter causes the system to briefly lose network connectivity. If a system has several IP interfaces or there is heavy network traffic, the time required to
2.4 Step 3: Verifying the Installation 23

re-establish network connectivity might be interpreted as a network or card failure. For example, Serviceguard might interpret a network interruption as a card failure, which can cause it to reform the cluster. 2. Use swremove to remove HP-UX IPFilter: swremove IPFilter

24

Installing HP-UX IPFilter

3 Configuring and Loading IPv4 Filter Rules

This chapter describes how to configure IPFilter rules to filter IPv4 packets. It first describes how to use the basic rule syntax to create rules that pass or block IPv4 packets based on IP addresses, protocol, and port number. The chapter then describes additional options and features you can use to filter IPv4 packets. This chapter contains the following sections: IPv4 Filter Rules Configuration File (page 27) Format (page 27) Rule Order and Processing (page 27) Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports (page 28) pass and block: Specifying the Filter Action (page 28) in and out: Specifying the Filter Direction (page 28) proto: Specifying the Upper Layer Protocol (page 28) from and to: Specifying IP Addresses and Subnets (page 28) port: Specifying TCP and UDP Ports (page 29) Rate-based Filtering (page 30) Processing Options: Logging Packets, Optimizing Rule Processing, and Specifying Interfaces (page 31) Option Order (page 31) log: Logging Packets (page 31) quick: Optimizing IPFilter Rules Processing (page 31) on: Filtering by Network Interfaces (page 32) Protocol Options: TCP Flags, IP Options and Fragments, ICMP Types and State Information (page 33) Option Order (page 33) flags: Specifying TCP Header Flags (page 33) with opt and ipopts: Specifying IP Options (page 34) with frag and with short: Selecting Fragmented IP Packets (page 35) icmp-type and code: Filtering ICMP Traffic by Type and Code (page 35) keep state: Protecting TCP, UDP, and ICMP Sessions (page 35) State Aging (page 37) keep frags: Handling IP Fragments (page 38) Sending Responses for Blocked TCP and UDP Packets (page 39) return-rst: Responding to Blocked TCP Packets (page 39) return-icmp-as-dest: Responding to Blocked UDP Packets (page 39) Improving Performance with Rule Groups (page 40) Loading IPv4 Filter Rules (page 42) Verifying IPv4 Filter Rules (page 42) Removing IPFilter Rules (page 43) Rule Tags (page 43)

25

NOTE: Most of the information in this chapter has been derived from the IPFilter-based Firewalls HOWTO document written by Brendan Conoby and Erik Fichtner. You can find this document at the following URL: http://www.obfuscation.org/ipf/

26

Configuring and Loading IPv4 Filter Rules

3.1 IPv4 Filter Rules Configuration File

The default HP-UX IPFilter IPv4 filter rules file is /etc/opt/ipf/ipf.conf. To specify an alternate IPv4 filter rules file name, set the IPF_CONF parameter in the IPFilter startup file, /etc/ rc.config.d/ipfconf. When HP-UX IPFilter is first installed, the /etc/opt/ipf/ipf.conf rules file is empty. Appendix B (page 131) contains example rules files you can use to create your ruleset.

3.1.1 Format
Entries in IPFilter rule files must meet the following requirements: Each rule must be contained on one line. Line continuation characters are not supported. IPFilter interprets all text to the right of a number symbol (#) as a comment. Extra white space is allowed and encouraged to keep the rules readable.

3.1.2 Rule Order and Processing

Rules are processed in order from top to bottom of the rules file. By default, IPFilter uses the last filter rule that matches the packet it is evaluating. For example, a rules file contains the following entries:
block in all pass in all

The first rule (block in all) blocks all packets, and the last rule (pass in all) allows all packets. Any given packet will match both rules, but the last matching rule takes precedence. IPFilter will apply the last rule that matches the packet (pass in all) and allow it to pass. You can modify IPFilter rules processing by using the quick keyword in a rule to force IPFilter to immediately apply a matching rule and stop processing rules. See quick: Optimizing IPFilter Rules Processing (page 31) for more information. TIP: Many administrators find it easier to use the quick keyword in each rule and then order the rules from most specific to least specific. You can also modify IPFilter rules processing by configuring rule groups. See Improving Performance with Rule Groups (page 40) for more information.

3.1 IPv4 Filter Rules Configuration File

27

3.2 Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports
A simplified syntax for IPFilter rules is as follows: block|pass in|out [proto protocol] ip_selector The ip_selector can use the from and to keywords to specify IP addresses and the port keyword to specify port numbers: block|pass in|out [proto protocol] from ip_address[/prefix] [port = port] to ip_address[/prefix] [port = port] Alternatively, the ip_selector can be the keyword all to specify all IP addresses: block|pass in|out [proto protocol] all The sections that follow describe the parameters and options for this simplified syntax. For the complete IPFilter rule syntax, see ipf(5).

3.2.1 pass and block: Specifying the Filter Action

The first keyword in an IPFilter rule specifies the action, and is usually pass or block. The keyword pass allows packets allows packets to pass in or out of IPFilter, and the keyword block blocks or drops packets.

3.2.2 in and out: Specifying the Filter Direction

The in and out keywords specify the whether the rule applies to inbound or outbound packets. Inbound traffic is traffic that enters the IPFilter system. Outbound traffic is traffic the system transmits, whether generated by the local system or forwarded by the system. For example, the following rule uses the keyword pass and the IP selector all to allow incoming packets from all IP addresses:
pass in all

The following rule drops outgoing packets to all IP addresses:

block out all

NOTE: If you do not specify any outbound rules, the implied default is pass out all. If you do not specify any inbound rules, the implied default is pass in all.

3.2.3 proto: Specifying the Upper Layer Protocol

IPFilter can filter traffic based on the upper layer protocol, such as TCP or ICMP, using the proto keyword: proto tcp|udp|tcp/udp|icmp|protocol_number The literal tcp/udp specifies both TCP and UDP, and is useful for applications that use both the TCP and UDP protocol, such as portmap and NFS. For example, you could configure the following rule to block inbound TCP and UDP portmap packets:
block in proto tcp/udp from any to 20.20.20.0/24 port = 111

The value for protocol_number can be any valid decimal number for an upper-layer protocol (0 - 255).

3.2.4 from and to: Specifying IP Addresses and Subnets

IPFilter can pass or block packets based on both source and destination IP addresses. The addresses can be individual node addresses, subnet addresses, or address ranges. The format for specifying IP addresses is as follows: from ip_address[/prefix]|any to ip_address[/prefix]|any
28 Configuring and Loading IPv4 Filter Rules

where: ip_address is the source or destination IPv4 address in decimal-dot notation. The IPv4 address can also be a decimal value, or a hexadecimal value with the prefix 0x. prefix is the decimal subnet prefix length. It can also be a network bitmask specified in dotted-decimal notation. any specifies any IP address. To specify an address range, enter the start address and end address, separated by a dash (-). To specify packets that do not match an address, insert an exclamation point (!) in front of the address. You can also specify an individual host name instead of an IP address, but you cannot use an exclamation point or range specification with host names.

3.2.4.1 Examples
The following rule blocks all inbound packets from the 10.10.10.0 subnet to any IP address:
block in from 10.10.10.0/24 to any

The following rule blocks all inbound packets from the addresses 10.10.10.1, 10.10.10.2, and 10.10.10.3 to any IP address:
block in from 10.10.10.1-10.10.10.3 to any

The following rule blocks all inbound packets with the destination address 192.168.2.1:
block in from any to 192.168.2.1

The following rule blocks all inbound packets that do not have the destination address 10.1.1.1:
block in from any to !10.1.1.1

3.2.4.2 all: Specifying All IP Addresses

The all keyword is and alternative to the from and to IP address selector and specifies all IP addresses. 3.2.4.2.1 Example
block in all

IPFilter expands this rule to block in from any to any.

3.2.5 port: Specifying TCP and UDP Ports

You can use IPFilter to block traffic for specific TCP or UDP ports. This is useful for blocking requests to network services such as telnet or rlogin, which are sent to the well-known or IANA registered port number for each service. For example, you can block incoming telnet service requests (which are sent to TCP port 23) with the following rule:
block in proto tcp from any to any port = 23

You can also pass or block traffic on a range of ports, such as the range of dynamic port numbers used by client telnet processes. The following is a list of operands you can use with port numbers:
Operand < > = != Alias lt gt eq ne Result true if port is less than the specified value true if port is greater than the specified value true if port is equal to the specified value true if port is not equal to the specified value 29

3.2 Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports

Operand <= >=

Alias le ge

Result true if port is less than or equal to the specified value true if port is greater than or equal to the specified value

3.2.5.1 Service Names

You can specify a service name defined in the /etc/services file instead of the port number when specifying a single port (when using the = operand). For example, you can configure the following rule:
block in proto tcp from any to any port = telnet

3.3 Rate-based Filtering

Packet flow is controlled by defining the rate in packets per second of matching packets passing through a machine. This function is useful against a SYN/ACK flood type of attack. For example, to allow 10 outbound packets per second from any source address to the destination address 10.1.1.42:
pass out from any to 10.1.1.42/32 pps 10

NOTE:

This is available only on HP-UX 11i v3.

30

Configuring and Loading IPv4 Filter Rules

3.4 Processing Options: Logging Packets, Optimizing Rule Processing, and Specifying Interfaces
IPFilter supports options to perform the following processing options: Log packet information (log) If the filter matches the packet, immediately apply the rule action and stop searching for rules (quick) Apply the rule only to the specified interface (on)

3.4.1 Option Order

If you specify processing options, you must insert them after the in or out keyword: block|pass in|out [processing_options] [proto protocol] ip_selector If you specify more than one processing option, you must specify them in the following order: 1. log 2. quick 3. on For example:
block in log quick on lan0 from 20.20.20.0/24 to any

3.4.2 log: Logging Packets

The log keyword directs IPFilter to log incoming and outgoing packets. Logging enables you to determine if your IPFilter system is being attacked, and records information about the packets. You can use the log keyword with any IPFilter rule. TIP: In most cases, it is not necessary to log every passed packet. Administrators often log only blocked packets, and, in some cases, log only selected blocked packets. HP recommends that you select the most important rules or the rules that are most likely to block attacks on your system and log only those rules. Indiscriminate logging can clutter a log file and make it difficult to detect notable events. For example, if you want to log blocked packets from a specific subnet, such as 20.20.20.0/24, use the following rule:
block in log from 20.20.20.0/24 to any

NOTE: You can use the log keyword with several other options to control and enhance logging functionality and performance. See Logging IPFilter Packets (page 88) for more information.

3.4.3 quick: Optimizing IPFilter Rules Processing

By default, HP-UX IPFilter evaluates the entire ruleset for each packet and selects the last rule that matches the packet. The quick keyword enables you to control rule processing and reduce the overhead of running IPFilter on your system. If IPFilter matches a packet to a rule that contains the quick keyword, IPFilter immediately selects that rule without continuing to evaluate the other rules in the ruleset. For example, a ruleset contains the following rules:
block in quick from 10.10.10.66 to any pass in all

If the system receives a packet from the 10.10.10.66, IPFilter matches the packet to the first rule. Because the first rule includes the quick keyword, IPFilter does not evaluate the second rule in the ruleset and uses the first rule.

3.4 Processing Options: Logging Packets, Optimizing Rule Processing, and Specifying Interfaces

31

TIP: Using the quick keyword also enables you to order rules from most specific to least specific.

3.4.4 on: Filtering by Network Interfaces

The on keyword directs IPFilter to apply a rule to the specified network interface only. The syntax is for specifying the on keyword is as follows: on interface_name where: interface_name is a physical network interface name, such as lan0. NOTE: The interface_name must be a physical interface name, such as lan0. It cannot be a logical interface name, such as lan0:1. For example, your system has two interfaces, lan0 and lan1, and you want to block packets received on the lan0 interface. You configure the following rules:
block in quick on lan0 all pass in all

The on keyword in the first rule specifies that the rule applies only to packets processed for the named interface, lan0; because the direction for this rule is in, the rule applies only to inbound packets received on lan0, which IPFilter blocks. If the system receives an inbound packets on another interfaces, such as lan1, the first rule does not match. The second rule matches and IPFilter allows the packet to pass. You can also filter traffic using both IP addresses and network interface names. For example, you want IPFilter to allow all inbound packets received from the subnet 192.168.0.0/16 only if they are received on lan1. Configure the following rules:
pass in quick on lan1 from 192.168.0.0/16 to any block in from 192.168.0.0/16 to any

The first rule allows packets from the 192.168.0.0/16 subnet to pass if they are received on the lan1 interface. The on lan1 specification directs IPFilter to pass these packets only if they are received on the lan1 interface. If the system receives a packet from the 192.168.0.0/16 subnet on any other interface, the packet matches the second rule and IPFilter blocks it.

32

Configuring and Loading IPv4 Filter Rules

3.5 Protocol Options: TCP Flags, IP Options and Fragments, ICMP Types and State Information
IPFilter supports options to filter packets based on the following protocol information: TCP flags (flags) IP options (with opt and with ipopt) IP fragments (with frag and with short) ICMP type and codes (icmp-type and code) State information (keep state) IP fragments (keep frags)

3.5.1 Option Order

If you specify protocol options, you must insert them after the ip_selector: block|pass in|out [processing_options] [proto protocol] ip_selector [protocol_options] The ip_selector is the from...to IP address and port number specification or the keyword all, as defined in Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports (page 28). If you specify more than one processing option, you must specify them in the order listed below: 1. 2. 3. 4. 5. 6. flags with opt and with ipopt with frag and with short icmp-type and code keep state keep frags

In the following example, the user specifies the flags option and the keep option, and specifies them in that order:
pass in quick proto tcp from any to 10.1.1.1 flags S keep state

3.5.2 flags: Specifying TCP Header Flags

Use the flags option to filter traffic by flags (control bits) in the TCP header. To specify the flags option, you must also specify proto tcp. The syntax for the flags option is as follows: flags flags[/flags_checked] where flags are the TCP flags that must be set to match the filter and flags_checked are the TCP flags checked. The values for flags and flags_checked are sequences of characters, where each character is the initial character of a TCP flag name: A (ACK - Acknowledgement) F (FIN - No more data) P (PUSH - Push function) R (RST - Reset the connection) S (SYN - Sychronize sequence numbers) U (URG - Urgent) See RFC 793, Transmission Control Protocol Specification for descriptions of TCP flags. Flags specified in the flags_checked sequence but not in the flags sequence must be clear to match the filter. For example, the specification flags S/SA matches packets with the SYN flag set and the ACK flag cleared, but does not match packets with both the SYN flag and the ACK flag set.
3.5 Protocol Options: TCP Flags, IP Options and Fragments, ICMP Types and State Information 33

If you omit /flags_checked, IPFilter checks all the TCP flags in the packet, so specifying flags S is equivalent to specifying flags S/AFPRSU, and matches TCP packets that have the SYN flag set and no other flags set. To accommodate applications or user protocols that also set the URG or PSH flags when initiating TCP connections, you can specify flags S/SAFR to allow SYN, SYN URG, or SYN PSH packets but not allow SYN ACK packets. However, it is more secure to specify flags S (or flags S/AFPRSU) when specifying flags S/SAFR or flags S/SA is not required. The flags keyword is typically used with the keep state feature, as described in Using Keep State with TCP (page 36).

3.5.3 with opt and ipopts: Specifying IP Options

IPFilter can filter packets based on IP options using the with opt and with ipopts keywords. Use the with opt keywords to filter packets with one or more IP options as follows:
with opt option[,option]

where option is one of the following abbreviations for an IP option: addext (Address Extension) cipso (Commercial Security) e-sec (Extended Security) eip (Extended Internet Protocol) encode (Encode) finn (Flow Control - experimental) imitd (IMI Traffic Descriptor) lsrr (Loose Source Route, or Loose Source Record Route) mtup (MTU Probe - decremented) mtur (MTU Response - decremented) nop (No Operation) rr (Record Route) satid (Stream ID) sec (Security) ssrr (Strict Source Route, or Strict Source Record Route) tr (Traceroute) ts (Time Stamp) visa (Access Control - experimental) zsu (Measurement - experimental) The IANA list of assigned IP option numbers specifies the numeric values for the IP options and lists the documents that define these options. This list is available at the following URL: http://www.iana.org/assignments/ip-parameters For example, the following rule blocks all IP packets with the Loose Source Record Route (LSRR) or Strict Source and Record Route (SSRR) option set:
block in quick all with opt lsrr, ssrr

3.5.3.1 not opt: Specifying Options Not Set

You can also configure rules to pass or block packets that do not have a specific option set:
with [opt option] not opt option

For example:
pass in from any to any with opt ssrr not opt lsrr

3.5.3.2 ipopts: Specifying Any IP Options

Use the keywords with ipopts to select packets with any IP options set or with not ipopts to select packets that have no IP options set. For example:
34 Configuring and Loading IPv4 Filter Rules

block in all with ipopts

3.5.4 with frag and with short: Selecting Fragmented IP Packets

The with frag and with short keywords enable you to select IP packet fragments and short IP packets.

3.5.4.1 with frag: Selecting IP Packet Fragments

The with frag keyword selects IP packet fragments (IP packets with a non-zero fragment offset). If you do not want IPFilter to pass IP packet fragments, specify the block action and the with frag keywords. For example:
block in all with frag

3.5.4.2 with short: Selecting Short Fragments

You can configure IPFilter to drop packet fragments that are too short for comparison using the with short keyword. This is useful for security purposes, because an attacker can use fragments to attempt to access the system. For example:
block in all with short

3.5.5 icmp-type and code: Filtering ICMP Traffic by Type and Code
You can filter specific types of ICMP traffic using the icmp-type and icmp-code keywords. These keywords are useful if you want to block most ICMP traffic to prevent Denial of Service (DoS) attacks, but must allow certain types of ICMP messages in and out of your system. These keywords are also useful when you want to block traffic from blocks of addresses but want to allow in ICMP packets required for normal network operation. See Chapter 11 (page 101) for more information.

3.5.6 keep state: Protecting TCP, UDP, and ICMP Sessions

Use keep state to select individual TCP, UDP, and ICMP sessions that exchange multiple packets. This enables you to use a rule to select the first packet in a session and then apply the same rule for all other packets in the session. For example, you can use the keep state option to allow bidirectional packets for a session that originates from the local system while blocking similar packets for session requests from remote systems. The keep state option also enables IPFilter to distinguish legitimate traffic from port scan attacks and Denial of Service (DoS) attacks. When a packet matches a rule with the keep state option, IPFilter creates an entry in its state table with the source and destination IP addresses and protocol. If the protocol is TCP or UDP, the entry also contains the source and destination port numbers. The entry is bidirectional and IPFilter checks both inbound and outbound packets against the state table, so you do not need to configure rules for the other inbound and outbound packets that match these parameters. You can use keep state to limit the number of rules you must configure. Use keep state to pass or block the first packet in a TCP, UDP, or ICMP session. If the protocol is TCP, you can specify flags S to match to first packet in a TCP session (a TCP packet with only the SYN flag set). For example, you can use the keep state keyword with IPFilter rules to protect an SSH server:
pass in quick proto tcp from any to 10.1.1.1/32 port block out all = 22 flags S keep state

The keep state keyword causes IPFilter to create an entry in the state table after the first SYN packet (flags S) received by the SSH server. The entry specifies the IP addresses, protocol, and port numbers for the session. IPFilter will not check subsequent inbound or outbound packets matching the state table entry against the IPFilter ruleset. This enables outbound responses for the SSH session to pass, despite the block out all rule. The following rules show keep state rules for TCP, UDP, and ICMP:
3.5 Protocol Options: TCP Flags, IP Options and Fragments, ICMP Types and State Information 35

pass out quick proto tcp from 10.1.1.1/32 to any keep state pass out quick proto udp from 10.1.1.1/32 to any keep state pass out quick proto icmp from 10.1.1.1/32 to any keep state

For more examples of correct uses of the keep state keyword, see Appendix B (page 131).

3.5.6.1 Allocating Memory for the State Table

The amount of memory allocated for the state table is determined by the kernel tunable parameter fr_statemax. In most deployments, the default value is sufficient. For information about modifying the fr_statemax value, see fr_statemax (page 144) .

3.5.6.2 Using Keep State with TCP

You can configure rules with the flags and keep state keyword to select packets for TCP connections initiated in a specific direction. To do this, use the flags option to select the first packet used to initiate a TCP connection and add the keep state keyword to select subsequent packets for the connection. The first packet used to initiate a TCP connection has the SYN flag set, but not the ACK flag, and in most cases have no other flags set other than the SYN flag. For example, the following ruleset uses the flags S specification to select packets for telnet connection requests (TCP port 23) sent from the local system (10.1.1.1). The keep state keywords also allows subsequent TCP packets for these connections to pass. These rules allow only the following packets: Outbound TCP connection requests (TCP SYN flag set and no other flags set) for telnet (port 23) The packets used to finish establishing the TCP connections for the outbound telnet requests Inbound and outbound packets for the established telnet connections

pass out quick proto tcp from 10.1.1.1/32 to any port = 23 flags S keep state block in quick all block out all

With the previous ruleset, IPFilter enters the first packet of an outbound telnet connection in the state table. When the three-way TCP handshake has been recorded by the state engine, the connection is marked as fully established (the state is set to 4/4). The state table entry is set for long-term data exchange until the connection ends; at that time the state changes again. You can see the current states for entries in the state table using ipfstat. See Viewing IPFilter Statistics and Active Rules with ipfstat (page 80) for more information. The flags keyword also prevents badly-formed TCP packets from entering your system. For example, you can configure a web server (10.2.2.2) with the following ruleset:
pass in quick proto tcp from any to 10.2.2.2/32 port = 80 flags S keep state block in quick all block out all

With the previous ruleset, IPFilter allows in valid connection requests (TCP packets with only the SYN flag set) for the HTTP service (TCP port 80). The keep state keywords directs IPFilter to enter packet information in the state table to allow subsequent packets for those connections. This rule set has two advantages: No badly-formed TCP packets are allowed in or added to the state table. TCP port scan attacks that send TCP packets with inappropriate flags set will fail, such as FIN scan attacks. In FIN scan attacks, an attacker sends TCP packets with the SYN and FIN flags set to elicit TCP RST packets and determine the ports open on a system for connection requests.

36

Configuring and Loading IPv4 Filter Rules

NOTE: The keep state keyword can create state entries even if it detects packets for a connection that are part of the middle of a connection. The only exception to this is when the rule specifies flags S. In this case, IPFilter creates a state table entry only when a TCP packet with the SYN flag set is sent, and TCP sends these packets only at connection establishment time. 3.5.6.2.1 Idle Timeout By default, IPFilter keeps TCP state table entries for idle, established TCP connections for 86,400 seconds (24 hours). If the connection is idle (no packets match the entry) for this time period, IPFilter deletes the entry. You can change the idle timeout value for TCP entries by modifying the fr_tcpidletimeout kernel parameter. See fr_tcpidletimeout (page 144) for more information.

3.5.6.3 Using Keep State with UDP

You can configure IPFilter rules for UDP connections using the keep state keyword. IPFilter adds an entry to the state table to match packets matching the filter specification in both directions. For example:
pass out on lan0 proto udp from any to any port 33434><33690 keep state

3.5.6.3.1 Idle Timeout If a UDP state table entry is idle (no packets match the entry) for 120 seconds, IPFilter deletes the entry.

3.5.6.4 Using Keep State with ICMP

For some ICMP messages, the ICMP protocol defines a request and a corresponding reply message. For example, the ICMP echo request (ICMP type 8) message (sent by the ping utility) has a corresponding ICMP echo reply (ICMP type 0) message. You can configure a rule to pass outbound ICMP echo requests and to pass in the subsequent ICMP echo replies. For example:
pass out on lan0 proto icmp from any to any icmp-type 8 keep state

NOTE: To configure rules to keep state on any outbound ICMP messages that might receive a reply ICMP message, you must specify both the proto icmp and the keep state options. To prevent an attacker from sending ICMP messages through your firewall when an active connection is known to be in your state table, check the incoming ICMP packet type and code, if applicable, in addition to the source and destination addresses (and ports, if applicable). 3.5.6.4.1 Idle Timeout If an ICMP state table entry is idle (no packets match the entry) for 60 seconds, IPFilter deletes the entry. 3.5.6.4.2 ICMP Error Status Messages If TCP or UDP generates an ICMP error status message for a packet that matches an active state table entry IPFilter will apply the rule for the TCP or UDP rule to the ICMP packet. For example:
pass out on lan0 proto udp from any to any port 33434><33690 keep state

If UDP generates an ICMP error status message (such as icmp-type 3 code 3 port unreachable or icmp- type 11 time exceeded) for this UDP session, IPFilter will apply the rule to the ICMP packet and allow it to pass.

3.5.7 State Aging

The system-defined state entry timeout values are:
3.5 Protocol Options: TCP Flags, IP Options and Fragments, ICMP Types and State Information 37

ICMP60 seconds UDP120 seconds TCP120 seconds

You can override the TCP default value when the connection is closed using the fr_tcptimewait tunable, or by using the age option on a per-rule basis. The value specified in the rule gets priority over the tunable value set at system level. The age option is supported for IPFilter rules on ICMP, UDP and TCP. For NAT rules, only TCP is supported. NAT provides the frnat_tcptimewait tunable to set the system level timeout. NOTE: This is available only on HP-UX 11i v3.

3.5.7.1 Rule Examples

To pass outbound ICMP echo requests and keep state entry for 30 Sec until it receives ICMP reply:
pass out on lan0 proto icmp from any to any icmp-type 8 keep state age 30

To keep UDP state entry for 40 Sec until it receives UDP reply back:
pass out on lan0 proto udp from any to any port 33434><33690 keep state age 40

To keep TCP state entry for 60 Sec after connection has been closed: IMPORTANT: Use age in TCP rule only in case of a DOS-type attack (ACK flood and so forth) because it modifies the timeout value of TIME_WAIT state in the TCP state table which can cause duplicate Initial Sequence Numbers (ISN).
pass out on lan0 proto tcp from any to any port 33434><33690 keep state age 60

3.5.8 keep frags: Handling IP Fragments

You can configure IPFilter to keep information about IP packets and to select subsequent IP packet fragments. The keep frags keyword lets you configure IPFilter to pass fragmented packets while blocking packets that might be forgeries or port scans trying to attack the system. The keep frags option is valid only when used with the keep state option. In the following example, the first two rules define the valid packets that are allowed to pass. The keep state and keep frags keywords enable related IP fragments for those packets to pass. The third and fourth block and log all other packets.
pass pass block block in quick on lan0 proto tcp from any to 20.20.20.1/32 out quick on lan0 proto tcp from any to any keep state in log quick all out log quick all port = 23 flags S keep state keep frags flags S keep frags

In this example, every valid packet is entered into the state table before the blocking rules are processed. To further protect the system, log initial SYN packets to detect SYN scans.

38

Configuring and Loading IPv4 Filter Rules

3.6 Sending Responses for Blocked TCP and UDP Packets

When you use the block keyword, IPFilter drops the blocked packet and no response is sent to the remote system that sent the packet. This can be a security risk, because it might alert an attacker that a packet filter is running on the system. You can use the return-rst and return-icmp-as-dest keywords to send appropriate responses to blocked packets.

3.6.1 return-rst: Responding to Blocked TCP Packets

When TCP receives a packet for a TCP port that is not open or a packet that is inappropriate for the TCP state, TCP normally sends a Reset (RST) packet. The return-rst keyword directs IPFilter to return an RST packet to the sender. The return-rst keyword is valid in the following rules: Rules that block inbound packets (block in rules). Dynamic Connection Allocation (DCA) rules (keep limit rules), as shown in DCA Rule Syntax and Keywords (page 53).

To use the return-rst keyword in a rule that blocks inbound packets, insert the return-rst keyword after the block keyword. For example, the following rule blocks inbound telnet requests and generates a TCP RST packet:
block return-rst in quick on lan0 proto tcp from any to 10.10.10.0/24 port = 23

When you configure a return-rst rule, HP recommends that you also configure a rule that explicitly allows the outbound RST packet to pass. For example:
block return-rst in quick on lan0 proto tcp from any to 10.10.10.0/24 port = 23 pass out quick on lan0 proto tcp from any port = 23 to any flags R/RSFUP

3.6.2 return-icmp-as-dest: Responding to Blocked UDP Packets

The return-icmp-as-dest keyword directs IPFilter to send an ICMP response. Specifying return-icmp-as-dest(port-unr) directs IPFilter to send an ICMP message with type destination unreachable and code port unreachable (port-unr). This ICMP message is the normal system response for packets sent to UDP ports that are not in use. Insert the return-icmp-as-dest(port-unr) keyword after block. For example:
block return-icmp-as-dest(port-unr) in quick proto udp from any to 20.20.20.0/24 port = 53

The return-icmp-as-dest directs IPFilter to send an ICMP response that uses the original destination address (the destination address of the incoming packet that triggered the response) as the source address instead of the local system's address. This prevents attackers from determining that you are using the local system as a packet filter. IPFilter also supports the return-icmp keyword, which causes IPFilter to send the return ICMP packet with the IP address of the local system (the address of the interface used to transmit the response), but HP recommends that you use the return-icmp-as-dest keyword instead.

3.6 Sending Responses for Blocked TCP and UDP Packets

39

3.7 Improving Performance with Rule Groups

Rule groups allow you to write your ruleset in a tree structure, instead of as a linear list, so if an incoming packet is unrelated to a set of rules, those rules will never be processed. This reduces IPFilter processing time on each packet and improves IPFilter system performance. The following is a simple rule group example:
block out quick on lan1 all head 10 pass out quick proto tcp from any to 20.20.20.64/26 port = 80 block out on lan2 all flags S keep state group 10

In this example, if a packet is not going to be transmitted using lan1, the head of rule group 10 does not match; IPFilter does not process any of the rules in group 10. Rules processing continues at the root level (group 0). If a packet is going to be transmitted using lan1, the quick keyword stops further processing at the group 0 level. IPFilter then evaluates all rules in group 10 against the packet. Rule groups can be used to break up a complex firewall ruleset. For example, there are three interfaces in the firewall with interfaces lan0, lan1, and lan2. lan0 is connected to external network 20.20.20.0/26. lan1 is connected to DMZ network 20.20.20.64/26. lan2 is connected to protected network 20.20.20.128/25.

A complete ruleset for this situation would be complex and significantly slow user connections to the network. To prevent this, a ruleset is created with rule groups:
block in quick on lan0 all head 1 block in quick on lan0 from 192.168.0.0/16 to any group 1 block in quick on lan0 from 172.16.0.0/12 to any group 1 block in quick on lan0 from 10.0.0.0/8 to any group 1 block in quick on lan0 from 127.0.0.0/8 to any group 1 block in log quick on lan0 from 20.20.20.0/24 to any group 1 block in log quick on lan0 from any to 20.20.20.0/32 group 1 block in log quick on lan0 from any to 20.20.20.63/32 group 1 block in log quick on lan0 from any to 20.20.20.64/32 group 1 block in log quick on lan0 from any to 20.20.20.127/32 group 1 block in log quick on lan0 from any to 20.20.20.128/32 group 1 block in log quick on lan0 from any to 20.20.20.255/32 group 1 pass in on lan0 all group 1 pass out on lan0 all block out quick on lan1 all head 10 pass out quick on lan1 proto tcp from any to 20.20.20.64/26 port pass out quick on lan1 proto tcp from any to 20.20.20.64/26 port pass out quick on lan1 proto tcp from any to 20.20.20.64/26 port pass out quick on lan1 proto tcp from any to 20.20.20.65/32 port pass out quick on lan1 proto udp from any to 20.20.20.65/32 port pass out quick on lan1 proto tcp from any to 20.20.20.66/32 port pass out quick on lan1 proto udp from any to 20.20.20.66/32 port

= = = = = = =

80 21 20 53 53 53 53

flags S keep state group flags S keep state group flags S keep state group flags S keep state group keep state group 10 flags S keep state group keep state group 10

10 10 10 10 10

For a host on the lan2 network, IPFilter bypasses all the rules in group 10 when a packet is not destined for hosts on that network. Multi-level grouping is also supported, allowing IPFilter rules to be arranged in hierarchical, nested groups. By using the head and group keywords in a rule, multi-level grouping allows the user to fine tune a range to improve performance. The following is an example of a multi-level rule grouping:
pass pass pass pass pass in in in in in proto proto proto proto proto tcp tcp tcp tcp tcp from from from from from 1.0.0.0-9.0.0.0 2.0.0.0-8.0.0.0 3.0.0.0-7.0.0.0 4.0.0.0-6.0.0.0 5.0.0.0-5.5.0.0 to to to to to any any any any any port port port port port = = = = = 23 23 23 23 23 keep keep keep keep keep state state state state state head 1 head 2 group 1 head 3 group 2 head 4 group 3 group 4

You can group your rules by protocol, system, netblock, or other logical criteria that help system performance. The maximum number of nested group levels you can configure is 128. For more information, see Appendix E (page 151). Rule groups can also be referenced by names on HP-UX 11i v3. Referencing groups by name makes rule configuration more readable and helps in assigning some meaningful group name. For example, if we have three groups for external network, DMZ network, and protected network, then we can refer to groups with the following group name:
40 Configuring and Loading IPv4 Filter Rules

block in quick on lan0 all head external-group block in quick on lan0 from 192.168.0.0/16 to any group external-group block in quick on lan0 from 172.16.0.0/12 to any group external-group
block out quick on lan1 all head DMZ-group pass out quick on lan1 proto tcp from any to 20.20.20.64/26 port = 80 flags S keep state group DMZ-group pass out quick on lan1 proto tcp from any to 20.20.20.64/26 port = 21 flags S keep state group DMZ-group block out quick on lan2 all head protected-group pass out quick on lan2 proto tcp from any to 20.20.20.164/26 port = 80 flags S keep state group protected-group pass out quick on lan2 proto tcp from any to 20.20.20.164/26 port = 21 flags S keep state group protected-group

3.7 Improving Performance with Rule Groups

41

3.8 Loading IPv4 Filter Rules

By default, HP-UX IPFilter starts on bootup and loads IPv4 filter rules from the /etc/opt/ipf/ ipf.conf file. If you do not want IPv4 filter rules to load on bootup, place your rules in an alternate location and then manually load the rules using the ipf command. The following tasks are some of the most commonly used: To add new rules to your ruleset from a file, use the -f option with the ipf command: ipf -f rules_file If a rule in the file is already loaded in the ruleset, IPFilter will print a message but continue processing the file. NOTE: When you load a ruleset, the new rules affect all matching packets immediately, including packets for established connections. For example, if you load a new rule that blocks telnet packets, IPFilter will block all telnet packets, including packets for established telnet connections. The only exception to this behavior is for packets that match entries in the IPFilter state table. In this case, IPFilter continues to apply the existing action (pass or block) for these packets until the state table entry times out or is deleted (such as when the connection is closed). To flush all rules from your ruleset, use the ipf -Fa command: ipf -Fa IPFilter maintains an active ruleset and an inactive ruleset. The active ruleset is the ruleset used for IPFilter operations, and the inactive ruleset is a supplementary, reserve ruleset. By default, IPFilter applies the flush (-F) and file (-f) operations to the active ruleset. You can also explicitly direct IPFilter to apply an operation to the active ruleset with the -A option. For example: ipf -Fa -A -f /etc/opt/ipf/ipf.conf This command flushes the all previously configured rules (-Fa), reads the rules in the /etc/ opt/ipf/ipf.conf file (-f), and loads these rules as the active rules (-A). To apply the ipf action to the inactive ruleset, specify the -I option. For example, the following command flushes all rules in the inactive ruleset and adds rules from the/etc/ opt/ipf/ipf.conf file to the inactive rule set: ipf -IFa -f /etc/opt/ipf/ipf.conf To swap the current active ruleset with the new inactive ruleset, specify the -s option: ipf -s To selectively flush only the inbound rules, specify the -Fi option. For example: ipf -Fi To selectively flush only the outbound rules, specify the -Fo option. For example: ipf -Fo You can also specify the -Fi or -Fo option with a filename. This flushes the inbound or outbound rules from the current ruleset, then reads in the rules from the specified file. For example: ipf -Fo -f /etc/opt/ipf/ipf.conf

3.8.1 Verifying IPv4 Filter Rules

You can use the following commands to verify IPv4 filter rules: Use the ipfstat -io command to list the active inbound and outbound rules.
42 Configuring and Loading IPv4 Filter Rules

Use the ipf -V command to verify that IPFilter is running. Use the ipfstat -ioh command to list the active inbound and outbound rules and the number of hits, or matching packets, for each rule.

For more information about IPFilter utilities, see Chapter 10 (page 95).

3.8.2 Removing IPFilter Rules

You can use the following command to remove rules that are listed in a file from the ruleset: ipf -r -f delete_rule_file You can use this command when IPFilter is running.

3.9 Rule Tags

3.9.1 Log Tags
This tag is used in IPF rules to help with parsing log files. Use log tags to find a particular logged packet belonging to an IPF rule. For example, to block all TCP packets from 10.1.1.42 and ipmon log packets in syslog and use log-tag (log-tag rule1) to help with parsing logfile:
block in log proto tcp from 10.1.1.42/32 to any set-tag(log=rule1)

3.9.2 NAT Tags

This tag creates implied join between IPF rules and NAT rules. NAT tags are used in both IPF rules and NAT rules. There are two kinds of NAT rules; map and rdr. The map rules are processed in OUT path and runs source address translation. The rdr rules are processed when packets enter the system and runs destination address translation. Use nat-tag in the rdr rule corresponding to the IPF rule in IN path. Use nat-tag in the map rule corresponding to the IPF rule in OUT path. In IN path, NAT processing takes place first, followed by filter checking. In OUT path, filter checking takes place first, followed by NAT processing. In the following example, nat-tag is in rdr (NAT) rule and IPF rule. The rdr rule packets coming to 10.1.1.40 are redirected to 10.1.1.41. In the IPF rule, if the same packet is coming from 10.1.1.42, then it matches the rule and blocks that packet. If nat-tag in the rdr (NAT) rule is changed to some other value, then the IPF rule does not match even if the packet is coming from 10.1.1.42, and the packet is allowed through.
rdr lan4 10.1.1.40/32 port 23 -> 10.1.1.41 tag test-tag block in from 10.1.1.42 to 10.1.1.41 set-tag(nat=test-tag)

The following example allows the packet to 10.1.1.41, and map rule changes the source address from 10.1.1.42 to 10.1.1.40 if nat-tag matches. If nat-tag is changed to some other value in the IPF rule, then map rule does not translate the source address, even if the packet is coming from 10.1.1.42.
pass out from 10.1.1.42 to 10.1.1.41 set-tag(nat=test-tag) map lan4 10.1.1.42/32 -> 10.1.1.40 tag test-tag

For more information, see the ipnat(4) and ipf(4) manpages. See also Chapter 6 (page 63). NOTE: This is available only on HP-UX 11i v3.

3.9 Rule Tags

43

44

4 Configuring and Loading IPv6 Filter Rules

This chapter describes how to configure and manage IPv6 filter rules. It contains the following sections: IPv6 Filter Rules Configuration File (page 45) Features Not Supported with IPv6 (page 46) IPv6 Filter Rule Syntax Differences (page 46) Loading IPv6 Filter Rules (page 49)

4.1 IPv6 Filter Rules Configuration File

HP-UX IPFilter maintains IPv4 and IPv6 rules as separate rule sets. You cannot not configure IPv6 filter rules in the same file with IPv4 filter rules, and you must administer IPv4 and IPv6 rule sets separately. The rule set (IPv4 or IPv6) for a rule is determined by the command-line options and file used to load the rule. These options are described in Loading IPv6 Filter Rules (page 49). The default name for the HP-UX IPFilter IPv6 filter rules file is /etc/opt/ipf/ipf6.conf. To specify an alternate IPv6 filter rules file name, set the IPF6_CONF parameter in the IPFilter startup file, /etc/rc.config.d/ipfconf. Any given rule will apply to either IPv4 or IPv6 according to the file and command options used to load the rule, but will not apply to both IPv4 and IPv6. This includes rules with wildcard addresses.

4.1 IPv6 Filter Rules Configuration File

45

4.2 Features Not Supported with IPv6

The following features are not supported with IPv6: IPFilter NAT functionality and the associated commands and utilities. Dynamic Connection Allocation (DCA) on HP-UX 11i v1 systems. DCA is not supported with IPv6 addresses on HP-UX 11i v1 systems, but is supported on HP-UX 11i v2 and HP-UX 11i v3 systems. The scripts and files used to generate and load IPFilter rules for Remote Procedure Call (RPC) ports, including /etc/opt/ipf/rpc.ipf. The ipftest utility IPFilter group rules Address pools

4.3 IPv6 Filter Rule Syntax Differences

The syntax for IPv6 filter rules is the same as the syntax for IPv4 rules, with the following differences and enhancements: Specifying Addresses (page 46) Filtering ICMPv6 Packets (page 46) IPv6 Extension Headers (page 47) Filtering Tunneled Packets (page 47) Filtering IPv6 Fragments (page 48) Sending ICMPv6 Responses (page 48)

Other filter rule features and syntax rules, such as TCP flags, stateful filtering for TCP and UDP, redirecting packets to other interfaces, and rule groups, are the same for IPv6 and IPv4.

4.3.1 Specifying Addresses

Specify IPv6 addresses in colon-hexadecimal notation. You can use two colons (::)once in an address to indicate a series of 0s. For example, use the following rule to block an inbound telnet connection: block in proto tcp from 2001:db8::1 to 2001:db8::2 port = 23 You can specify the all and any keywords in IPv6 rules. For example, you can create the following rule for IPv6 packets: block in from any to any Although the previous rule is valid for both IPv4 and IPv6 packets, IPFilter will apply this rule to IPv6 packets if you add it to the IPv6 filter configuration file and load it using the IPv6 (-6) option with the ipf command, as described in Loading IPv6 Filter Rules (page 49). Rules cannot contain both IPv4 and IPv6 addresses. For example, the following rule is not valid: pass in proto tcp from 10.1.1.1 to 2001:db8::2

4.3.2 Filtering ICMPv6 Packets

To filter ICMPv6 messages by type and code, specify proto icmpv6 (or proto ipv6icmp) and use the keywords icmpv6-type and code. See Filtering ICMPv6 Packets by Type and Code (icmpv6type and code) (page 106) for more information.

4.3.2.1 Stateful ICMPv6

IPFilter can retain state information for ICMPv6 Request-Response messages. The only supported message types are Echo Request and Echo Reply.

46

Configuring and Loading IPv6 Filter Rules

4.3.3 IPv6 Extension Headers

You can block or pass packets according to IPv6 extension headers. A simplified rule syntax is as follows block|pass in|out [processing_options] [proto protocol] ip_selector with v6hdrs ipv6_header where: processing_options is one or more processing options, such as quick. See Processing Options: Logging Packets, Optimizing Rule Processing, and Specifying Interfaces (page 31) for more information. ip_selector is the IP address specification using the keyword all, or the from and to keywords and IPv6 addresses and optional ports. See Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports (page 28) for more information. protocol is the protocol name or number. See Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports (page 28) for more information. ipv6_header is a series of one of the following IPv6 header extension types, separated by commas (,): dstopts (Destination options header) hopopts (Hop-by-hop options header) mobility (Mobile IPv6 Mobility header) routing (Routing options header) ah (IPsec Authentication Header) esp (IPSec Encapsulating Security Payload) ipv6 (IPv6 tunneled packets) For example, to block all TCP packets with a Routing options header, use the following rule: block in proto tcp from any to any with v6hdrs routing To block all UDP packets with destination option and mobility headers, use the following rule: block in proto udp from any to any with v6hdrs dstopts,mobility NOTE: Extension headers are matched explicitly. A packet with only a destination option header will not match the previous rule. Only packets with both mobility and destination option headers will match the rule.

4.3.4 Filtering Tunneled Packets

HP-UX IPFilter can filter the following types of tunnel packets: 6-in-4 Use the following rule to filter 6-in-4 tunnel packets:
block in proto 41 from any to any

6-in-6 Use the following rule to filter 6-in-6 tunnel packets:

block in proto 41 from any to any

4-in-6 Use the following rule to filter 4-in-6 tunnel packets:

block in proto ip from any to any

4.3 IPv6 Filter Rule Syntax Differences

47

4.3.5 Filtering IPv6 Fragments

You can filter IPv6 fragments by specifying the v6hdrs frags keywords. Use the following rule to filter IPv6 fragmented traffic: block in proto udp from any to any with v6hdrs frags Unlike IPv4, IPFilter does not maintain a fragment cache for IPv6 fragments.

4.3.6 Sending ICMPv6 Responses

IPFilter supports the return-icmpv6-as-dest and return-icmpv6 keywords for IPv6. These keywords are equivalent to the IPv4 keywords return-icmp-as-dest and return-icmp. The primary use for these keywords is to send an ICMPv6 message with type destination unreachable and code port unreachable in response to UDP packets sent to a blocked port. For example:
block return-icmp-as-dest(port-unr) in quick proto udp from any to 2001:db8::2 port = 53

See return-icmp-as-dest: Responding to Blocked UDP Packets (page 39) for guidelines and more information about sending ICMP responses.

48

Configuring and Loading IPv6 Filter Rules

4.4 Loading IPv6 Filter Rules

By default, HP-UX IPFilter starts on bootup and loads IPv6 filter rules from the /etc/opt/ipf/ ipf6.conf file. If you do not want IPFilter to load IPv6 filter rules at bootup, place your rules in an alternate location and then manually load the rules using the ipf command. To load, flush, and switch the IPv6 filter rulesets, insert the -6 option before the other ipf ruleset options. For example, to add new IPv6 rules to your ruleset from a file, use the -6 and -f options with the ipf command: ipf -6 -f rules_file NOTE: When you load a ruleset, the new rules affect all matching packets immediately, including packets for established connections. For example, if you load a new rule that blocks telnet packets, IPFilter will block all telnet packets, including packets for established telnet connections. The only exception to this behavior is for packets that match entries in the IPFilter state table. IPFilter will continue to apply the existing action (pass or block) for these packets until the state table entry times out or is deleted (such as when the connection is closed). For more examples of commands to manage and load rulesets, see Loading IPv4 Filter Rules (page 42) and The ipf Utility (page 95).

4.4.1 Verifying IPv6 Filter Rules

You can use the following commands to verify IPv6 filter rules: Use the ipf -V command to verify that IPFilter is running. Use the ipfstat -6io command to list the active inbound and outbound rules. Use the ipfstat -6ioh command to list the active inbound and outbound rules and the number of hits, or matching packets, for each rule. For more information about IPFilter utilities, see Chapter 10 (page 95).

4.4 Loading IPv6 Filter Rules

49

50

5 Configuring and Loading Dynamic Connection Allocation (DCA) Rules

This chapter describes Dynamic Connection Allocation (DCA). DCA helps protect and mitigate against DOS attacks where an attacker attempts to overload a system with TCP connection requests. DCA uses stateful packet inspection to limit the number of incoming TCP connections to a system. This chapter describes DCA keywords and syntax. It also contains procedures for changing DCA rules dynamically and setting DCA mode at startup. NOTE: On HP-UX 11i v1 systems, DCA is not supported with IPv6 addresses.

This chapter contains the following sections: DCA with HP-UX IPFilter (page 52) Overview: DCA Functionality (page 52) DCA Rules Configuration Files (page 52) DCA Rule Syntax and Keywords (page 53) DCA Rule Conditions (page 53) keep limit: Limiting Connections (page 53) return-rst: Returning RESET Packets (page 54) cumulative: Limiting Cumulative Connections (page 54) log limit: Logging Exceeded Connections (page 54) log limit freq: Log Frequency (page 55) Loading and Modifying DCA Rules (page 57) Updating keep limit Rules (page 57) Adding New keep limit Rules (page 58) Integrating keep limit Rules (page 58) Extracting an Individual Rule from a Subnet Rule (page 59) Enabling and Disabling DCA (page 60) Enabling and Disabling DCA Using ipf (page 60) Configuring IPFilter to Enable DCA at System Startup Time (page 60) Using IPFilter Utilities with DCA (page 60) keep limit Rules and Rule Hits (page 61) Monitoring and Allocating Memory for DCA Data (page 62)

51

5.1 DCA with HP-UX IPFilter

An HP-UX IPFilter system can act as a secure intermediary, tracking all incoming TCP connections to a system or network. DCA lets you limit incoming TCP connections passing through an IPFilter system. You can use DCA to limit the number of inbound connections based on the source IP address and optionally, the destination TCP port number. After a legal TCP connection is established, DCA uses TCP state information to allow subsequent packets for the connection to pass. NOTE: To use DCA functionality, you must explicitly enable DCA mode. For more information, see Enabling and Disabling DCA (page 60). DCA functionality does not work if DCA mode is not enabled. DCA uses IPFilter state table entries. To function correctly, you must have sufficient memory allocated for the IPFilter state table. See Monitoring and Allocating Memory for DCA Data (page 62).

5.1.1 Overview: DCA Functionality

DCA provides a set of flexible rules for controlling incoming TCP connections. You allocate a number of TCP connections to a system using the keywords keep limit and specifying a limit value. The limit value is the number of concurrent TCP connections that can be established by any given source. You can configure DCA rules to limit the number of connections from: A specific IP address. Each IP address in an IP subnet or IP address range. An IP subnet or IP address range where all the IP addresses in the subnet share the cumulative limit. Unknown IP addresses, where each unknown IP address has a connection limit.

When the configured limit is reached, IPFilter discards any additional connection requests. You can configure HP-UX IPFilter to send a TCP Reset packet when it discards a connection request. See return-rst: Responding to Blocked TCP Packets (page 39) for more information.

5.1.1.1 Using DCA

DCA helps protect systems from floods of TCP connections created by DoS attacks. For example, you can use DCA to: Protect a mail server from a flood of SMTP connection requests. IP addresses or subnets that are trying to overload the SMTP server can be slowed down. At the same time, known users can be given unlimited connection limits. This ensures that customers and partners can still access the mail server while attackers are prevented from consuming resources. Protect an LDAP server from a flood of bogus SSL connection requests or other types of connection requests used to overload the LDAP server.

5.2 DCA Rules Configuration Files

You can configure DCA rules in the same file as IPv4 or IPv6 filter rules. The default IPv4 filter rules file is/etc/opt/ipf/ipf.conf, and the default IPv6 filter rules file is /etc/opt/ipf/ ipf6.conf. See IPv4 Filter Rules Configuration File (page 27) and IPv6 Filter Rules Configuration File (page 45) for more information.

52

Configuring and Loading Dynamic Connection Allocation (DCA) Rules

5.3 DCA Rule Syntax and Keywords

The basic DCA syntax is as follows: pass in quick proto tcp from source_ip|any to dest_ip|any [port = port_num] keep limit limit_num The keep limit keywords indicate that this is a DCA rule. In addition, you can use the return-rst keyword in a DCA rule, and the following keywords that are specific to DCA: cumulative log limit log limit freq The syntax for using these keywords is as follows: pass [return-rst] in [log limit [freq num]] quick proto tcp from source_ip|any to dest_ip|any [port = port_num] keep limit limit_num [cumulative] The DCA keywords are described in the sections that follow.

5.3.1 DCA Rule Conditions

The keep limit keywords indicate that the rule is a DCA rule. In addition, a DCA rule must conform to the following conditions: The rule must be a quick rule. The rule must be an in rule. The rule can be used only with proto tcp. The log limit and log limit freq keywords can only be used with the keep limit rule. The source port must be a wildcard (not specified). The connection limit specified in a keep limit rule must be a non-zero, positive number. You cannot specify keep limit 0. You cannot use the keep state keywords and the keep limit keywords in the same rule. IPFilter creates a state table entry for each TCP connection that matches a DCA rule. If the connection exceeds the configured limit, IPFilter deletes the state table entry and refuses the connection request. If IPFilter cannot add an entry to the state table for a connection request, it will allow the connection request to pass. See Monitoring and Allocating Memory for DCA Data (page 62) for more information.

5.4 keep limit: Limiting Connections

Use the keep limit keyword to limit the number of connections made to an IPFilter system at a given time. Connections can be limited by IP address, subnet, cumulative limit of connections, and a default individual limit.

5.4.1 Limiting Connections by IP Address

The following rule is an example of a DCA rule that limits connections by IP address:
pass in quick proto tcp from 10.2.2.2 to any port = 25 keep limit 5

The example rule limits the maximum concurrent connections to five from IP address 10.2.2.2 to the SMTP port 25 of any host. If the limit is exceeded, IPFilter will block additional connection requests from 10.2.2.2.

5.3 DCA Rule Syntax and Keywords

53

5.4.2 Limiting Connections by Subnet

The following rule is an example of a DCA rule that limits connections by IP subnet:
pass in quick proto tcp from 192.168.5.0/24 to any port = 25 keep limit 4

This rule limits the maximum concurrent TCP connections to four from any individual host in subnet 192.168.5.0/24 to port 25 of any host.

5.4.3 Limiting Connections by IP Address Range

The following rule is an example of a DCA rule that limits connections for each IP address within an IP address range:
pass in quick proto tcp from 10.10.10.1-10.10.20.1 to any port = 25 keep limit 15

This rule allows 15 connections from each IP address within the IP address range of 10.10.10.1-10.10.20.1.

5.4.4 Default Individual Connection Limits

Use the following syntax to create default individual connection limits:
pass [return-rst] in proto tcp from any to any [port = port_num] keep limit limit_num

For example:
pass in proto tcp from any to any port = 25 keep limit 5

This rule specifies a connection limit of 5 for all hosts when trying to connect to port 25. IMPORTANT: file. The default individual connection limit must be the last rule in the configuration

5.5 return-rst: Returning RESET Packets

You can use the return-rst keyword in a DCA rule to send a TCP Reset packet to the TCP peer when IPFilter receives a connection request and the number of connections for the rule exceeds the limit. Using the following rule, if the system has five SMTP connections established from IP address 10.2.2.2 and receives a connection request for a sixth connection from that address, IPFilter will send a TCP Reset packet to the TCP peer.
pass return-rst in quick proto tcp from 10.2.2.2 to any port = 25 keep limit 5

5.6 cumulative: Limiting Cumulative Connections

Use the cumulative keyword at the end of a DCA rule to limit connections using a pooled cumulative limit for all source addresses in a subnet or address range. For example, the following rule limits the total concurrent connections to 15 from all hosts in subnet 10.10.10.0/24 to port 25:
pass in quick proto tcp from 10.10.10.0/24 to any port = 25 keep limit 15 cumulative

If you do not specify a destination port, IPFilter maintains a separate limit count for each destination port. The following rule allows a maximum of 15 concurrent connections from subnet 192.168.7.0/24 to each TCP port on the local system. Using this rule, the system can have 15 concurrent connections to the SMTP service, 15 concurrent connections to the HTTP service, and 15 concurrent connections to the telnet service, and so on.
pass in quick proto tcp from 10.10.10.0/24 to any keep limit 15 cumulative

5.7 log limit: Logging Exceeded Connections

Use the log limit option to log each connection that exceeds a configured limit in a keep limit rule. For example:
pass in log limit quick proto tcp from host1 to Server keep limit 10

54

Configuring and Loading Dynamic Connection Allocation (DCA) Rules

The system host1 is allowed to open only 10 concurrent connections. IPFilter blocks any subsequent connection requests. Since log limit is set, each additional connection attempt is logged. The log limit option generates two types of log records: Alert Log recordscreated when a source IP address attempts to exceed its configured connection limit. Every time the connection limit is exceeded, IPFilter creates an alert log record. Summary Log recordscreated when a limit entry ceases to exist after all the connections for that limit entry have been closed. A summary log record summarizes the connection activity for a particular source IP address.

The format of an alert log record is:

date_time_stamp interface_name source_ip,source_ port -> destination_IP,destination_port protocol TCP_flags keep_limit limit_type configured_limit current_#_of connections #_times_limit_exceeded log_freq packet_direction

The format of a summary log record is:

Date and time stamp, Source IP, Source port, Destination IP, Destination Port, protocol, TCP flags keep limit, Limit type, Configured Limit, Current # of connections, # times limit exceeded, Rule #, Time limit the entry was created

5.7.1 Summary Logs and Cumulative Limits

You can write the summary log records for cumulative limits to the IPFilter log file using the ipmon -r option. When ipmon -r is invoked, the summary log record is written and the connection exceeded counter for each cumulative limit is set to zero. NOTE: Unlike noncumulative limits, cumulative summary logs are not printed when all the connections under a cumulative limit are closed. The following is an example cumulative summary log:
06/02/2004 19:32:39.370000 LIMIT LOG 19.13.15.65-19.13.15.85,* -> 0.0.0.0,23 PR ip Type 4 Cur Lim 1 Exceeded 1 @0:1 First Time 19:32:35.800000

The example log record was written for the following IP address range cumulative rule:
pass in log limit freq 1 quick proto tcp from 19.13.15.65-19.13.15.85 to any port = 23 keep limit 1 cumulative

In the example summary log, the source IP address displayed is actually the IP address range specified in the rule. Wildcard IP addresses are shown as 0.0.0.0. The destination port information is also printed from the rule. The other fields are similar to a noncumulative summary record. For further information, see ipmon and DCA Logging (page 91).

5.8 log limit freq: Log Frequency

Use the log limit freq num keyword to control the frequency at which alert log records are logged. For example, log limit is set to 10 and log limit freq is set to 3. The system begins tracking exceeded connections at the eleventh connection. It logs every third exceeded connection, that is the fourteenth, seventeenth, twentieth, and so on. The log limit freq keyword can also be used with keep limit cumulative rules. For example:
pass in log limit freq 5 quick proto tcp from 18.9.90.0/24 to any keep limit 10 cumulative

5.8 log limit freq: Log Frequency

55

In the previous rule, log limit freq 5 specifies that the log records should be printed for every five connections that exceeds the connection limit of 10. If 100 connections are established, IPFilter logs the eleventh, sixteenth, twenty-first, and so on. Cumulative limits are shared by different IP addresses and it is possible that IPFilter will not log connections from some source IP addresses. For example, the initial connections might come from ipaddr1 and the next 10 from ipaddr2. IPFilter will not log the connections from ipaddr1, but will log the connections from ipaddr2, because one of its connections will be the eleventh connection.

56

Configuring and Loading Dynamic Connection Allocation (DCA) Rules

5.9 Loading and Modifying DCA Rules

The following sections describe how to load and modify DCA rules when HP-UX IPFilter is running. NOTE: HP recommends configuring a redundant rule (such as pass in all) in all DCA rule files. IPFilter does not process packets without a rule. To load DCA rules, use the ipf utility to read the new rules from a file: ipf -f rules_file To load IPv6 DCA rules, specify the -6 option: ipf -6-f rules_file NOTE: When you load a ruleset, the new rules normally affect all matching packets immediately, including packets for established connections. However, IPFilter creates state table entries for packets matching DCA rules, and if the DCA rule is noncumulative, IPFilter continues to apply the action in the state table for subsequent packets that match the state table entry until the state table entry times out or is deleted. To force a new rule to take effect immediately, follow the procedures described in Updating keep limit Rules (page 57). Alternately, use the following procedure to modify an inactive rules file and switch it with the active rules file: 1. 2. Enter the following command to add or modify rules in an inactive rules file: ipf [-6] -If rules file Run the following command to switch the active rules file with the inactive rules file you modified: ipf [-6] -s When you modify an inactive rules file, then switch it with an active rules file, DCA processes new connections according to the new rules file whether or not there are existing connection limit entries in the limit table. TIP: For performance-critical applications, HP recommends that you load rules into the inactive list, then switch the inactive rules file with the active rules file.

5.9.1 Updating keep limit Rules

The following sections describe procedures for updating keep limit rules.

5.9.1.1 Changing the Current Individual, Subnet, or IP Address Range Rule

You can dynamically lower the number of connections a keep limit rule allows without letting DCA pass unwanted packets while it activates the updated rules. You can also increase the connection limit for an IP address, subnet, or IP address range. For example, your IPFilter system has many connections coming from a specific IP address range. You have a keep limit rule configured for that IP address range. You want to lower the connection limit in the rule so that DCA starts using the new limit immediately, before more packets from the suspect IP address range can pass through. To change the number of connections allowed by a keep limit rule:

5.9 Loading and Modifying DCA Rules

57

1.

Create a new rule identical to the current rule except for a different keep limit count. When adding a new rule, IPFilter recognizes it as the update of an existing rule. Current limit entries made by the old rule are updated with the new connection limit when a new connection is processed. New connections are processed with the new rule.

For example, the original rule is:

pass in quick proto tcp from 14.13.45.0-14.13.45.255 to any keep limit 10 cumulative

To decrease the limit to 5, add the following new rule:

pass in quick proto tcp from 14.13.45.0-14.13.45.255 to any keep limit 5 cumulative

DCA detects a similar rule in the ruleset, but the limit count has changed. DCA updates the limit count in the original rule and waits until the current number of connections drops to 5. During this period, DCA does not allow any new connections, but it does not terminate any existing connections. When the number of active connections drops to 5, DCA allows 5 or fewer connections from the specified IP address range. If you increase a connection limit from a specified IP address from 15 to 20, DCA detects the change and allows up to 20 connections from the specified IP address. If you increase the connection limit in a keep limit rule, DCA immediately updates the limit count and controls connections based on the new higher connection limit.

5.9.1.2 Updating a Subnet or IP Address Range Rule

To update a subnet or IP address range keep limit rule: 1. Add the same rule, changing only the keep limit value. Be sure the subnet or IP address range is identical to the old rule. IPFilter recognizes the new rule as an update to an existing rule. IPFilter uses the new connection limit instead of the old connection limit. Limit entries made by the old rule are updated when a new connection is processed. New connections are processed with the new rule.

5.9.2 Adding New keep limit Rules

The following procedures describe how to dynamically add new rules to active rules files.

5.9.2.1 To Add a New Individual keep limit Rule:

1. 2. Add the new rule on the line before the old rule which the new rule is to replace. Delete the old rule.

5.9.2.2 To Add a New Subnet or IP Address Range Rule:

1. 2. Add the new rule on the line before the old rule which the new rule is to replace. Delete the old rule. Limit entries made by the old rule are updated when a new connection is processed. New connections are processed with the new rule. To add a more specific subnet or IP address range rule, see the following section, Integrating keep limit Rules (page 58).

5.9.3 Integrating keep limit Rules

The following procedure describes how to add a specific subnet or IP address range rule before an existing general subnet or IP address range rule.

58

Configuring and Loading Dynamic Connection Allocation (DCA) Rules

1.

Add the new subnet or IP address range rule. Be sure to re-enter the old subnet or IP address range rule exactly as it was entered before. When a new connection matches an existing limit entry, the new connection will be processed by the new subnet or IP address range rule. The subnet or IP address range can be cumulative or noncumulative.

5.9.4 Extracting an Individual Rule from a Subnet Rule

To extract an individual rule from a subnet rule: 1. Add the new rule on the line before the subnet rule. Be sure the subnet or IP address range rule is identical to the old rule. When a new connection matches an existing limit entry, the new connection will be processed by the new individual rule. The subnet or IP address range can be cumulative or noncumulative.

5.9 Loading and Modifying DCA Rules

59

5.10 Enabling and Disabling DCA

To use DCA, you must enable DCA mode. You can enable or disable DCA mode using the ipf utility. If you want IPFilter to automatically enable DCA mode at system startup time, you must also modify the /etc/rc.config.d/ipfconf file.

5.10.1 Enabling and Disabling DCA Using ipf

There is a single DCA mode for both IPv4 and IPv6 addresses. You can use the ipf command to enable and disable DCA mode. You can also use ipf to query the state of DCA mode, and toggle between enabled and disabled mode. DCA mode is disabled by default. To enable DCA, use the following command: ipf -m e To disable DCA, use the following command: ipf -m d To query the current DCA setting, use the following command: ipf -m q You can toggle between being enabled or disabled by using the following command: ipf -m t

5.10.2 Configuring IPFilter to Enable DCA at System Startup Time

Use the following procedure to configure IPFilter to automatically enable DCA at system startup time:: 1. 2. Open /etc/rc.config.d/ipfconf, the IPFilter startup configuration file. Set the DCA_START flag to 1 to enable DCA. Alternatively, you can set the DCA_START flag to 0 to disable DCA. This is the default setting. NOTE: When there are no keep limit rules and no connection allocation configured, HP recommends that you disable DCA.

5.1 1 Using IPFilter Utilities with DCA

The IPFilter utilities support subcommands to collect data about the connections that are being controlled. This data includes the source and destination IP address, allocated number of connections, number of active connections, and number of times the allocated quota of connections was exceeded. These subcommands are as follows: The ipf Utility (page 95). ipf -Q interface_name ipf -E interface_name ipf -D interface_name ipf -m option Viewing IPFilter Statistics and Active Rules with ipfstat (page 80). ipfstat -L ipfstat -vL ipfstat -r group:rule Using ipmon to View IPFilter Log Entries (page 90). ipmon -r

60

Configuring and Loading Dynamic Connection Allocation (DCA) Rules

DCA also provides logging records that can serve as alert messages or as a summary of the connections made from a specific IP address. You can use the log records to identify IP addresses or subnets that you want to limit or block.

5.1 1.1 keep limit Rules and Rule Hits

Each time IPFilter processes a packet that matches a rule, IPFilter increments the hit count for the matching rule, whether or not the rule is the final rule (the rule used). For example: A packet matches a non-quick rule. If another rule match is later found on the list, IPFilter increments the hit count for both matching rules. A packet matches a rule that is a group head. If another matching rule is found within the group, IPFilter increments the hit count for both matching rules.

You can display rule hit counts using the command ipfstat -ioh. This command is useful as a troubleshooting mechanism, along with ipfstat -sl and ipfstat-vL, which allow connections to be examined in realtime. And lastly, logging can be used to analyze history for past connections.

5.1 1.1.1 Limits and Hit Counts

Configuring rules with cumulative and noncumulative limits affects rule hit counts. IPFilter registers rule hits differently for cumulative and noncumulative limits. A rule hit is usually registered only once for noncumulative limits. This is because IPFilter creates a limit entry when the connection matches a noncumulative keep limit rule and subsequent connections are controlled by that limit entry. For cumulative limits, each new connection registers a rule hit and increments the rule hit count because cumulative limit connections require a rule walk for each new connection.

5.11 Using IPFilter Utilities with DCA

61

5.12 Monitoring and Allocating Memory for DCA Data

IPFilter allocates entries in its state table for TCP connections that use a DCA rule. In addition, IPFilter keeps a limit table that counts the state table entries for a DCA rule. The amount of memory allocated for the state table is determined by the kernel tunable parameter fr_statemax. In most deployments, the default value is sufficient, but if you set this value too low and IPFilter is unable to create a state table entry for a TCP connection that uses a DCA rule, IPFilter will allow packets for the connection to pass, even if the connection would exceed the limit in the DCA rule. The maximum counter reported by the ipfstat -s command reports the number of times IPFilter attempted to create a state table entry but could not because the state table contained the maximum number of entries. In addition, the number of state table entries needed for TCP connections is affected by the kernel tunable parameter fr_tcpidletimeout. For information about modifying these parameters, see fr_statemax (page 144) and fr_tcpidletimeout (page 144).

62

Configuring and Loading Dynamic Connection Allocation (DCA) Rules

6 Configuring and Loading Network Address Translation (NAT) Rules

This chapter contains the following sections: NAT Rules Configuration File (page 63) Format (page 63) Rule Order and Processing (page 63) NAT Keywords (page 65) map and portmap: Mapping Outbound Packets (page 66) rdr: Redirecting Inbound Packets (page 68) Redirecting Packets to a Specific Port (page 68) Using NAT Redirection with Filtering (page 68) Using the rdr and round-robin Keywords for Load Balancing (page 69) Sticky NAT Sessions (page 69) Checking Connection Health with l4check (page 69) bimap: Bidirectional Mapping (page 71) Loading NAT Rules (page 72)

6.1 NAT Rules Configuration File

IPFilter loads and evaluates NAT rules separately from filter rules. Do not configure NAT rules in the same file with filter rules. The default name for the HP-UX IPFilter NAT rules file is /etc/ opt/ipf/ipnat.conf. To specify an alternate NAT rules file name, set the IPNAT_CONF parameter in the IPFilter startup file, /etc/rc.config.d/ipfconf. To load NAT rules, use the ipnat utility. See Loading NAT Rules (page 72) for more information. See also, Rule Tags (page 43). NOTE: NAT rules are not supported with IPv6 addresses or interfaces.

6.1.1 Format
Entries in IPFilter rule files must meet the following requirements: Each rule must be contained on one line. Line continuation characters are not supported. IPFilter interprets all text to the right of a number symbol (#) as a comment. Extra white space is allowed and encouraged to keep the rules readable.

6.1.2 Rule Order and Processing

Rules are processed in order from top to bottom of the rules file. By default, IPFilter uses the first NAT rule that matches the packet it is evaluating. NOTE: The selection algorithm that IPFilter uses for NAT rules (use the first matching rule) is the opposite of the default selection algorithm it uses for filter rules (use the last matching rule).

6.1.2.1 Using NAT Rules with Filter Rules

The order that IPFilter evaluates NAT rules and filter rules depends on the direction of the packet. 6.1.2.1.1 Inbound Packets When processing inbound packets, IPFilter evaluates rules in the following order: 1. NAT rules
6.1 NAT Rules Configuration File 63

2. Filter rules If you want to use filter and NAT rules to process inbound packets, you must specify the translated (target) IP address in the filter rules. 6.1.2.1.2 Outbound Packets When processing outbound packets, IPFilter evaluates rules in the following order: 1. Filter rules 2. NAT rules

64

Configuring and Loading Network Address Translation (NAT) Rules

6.2 NAT Keywords

IPFilter supports the following keywords for NAT (Network Address Translation) functionality: map and mapblock The map and mapblock keywords rewrite or translate source addresses and port numbers for outbound packets. rdr The rdr keyword redirects and translates destination addresses and port numbers for inbound packets. bimap The bimap keyword translates addresses and port numbers for inbound and outbound packets. age The age option is supported for IPFilter rules on ICMP, UDP and TCP. For NAT rules, only TCP is supported. NAT provides the frnat_tcptimewait tunable to set the system level timeout. NOTE: NOTE: This is available only on HP-UX 11i v3.

The maximum number of concurrent NAT connections IPFilter supports is 16,383.

6.2.1 Rule Examples

To pass outbound ICMP echo requests and keep state entry for 30 Sec until it receives ICMP reply:
pass out on lan0 proto icmp from any to any icmp-type 8 keep state age 30

To keep UDP state entry for 40 Sec until it receives UDP reply back:
pass out on lan0 proto udp from any to any port 33434><33690 keep state age 40

To keep TCP state entry for 60 Sec after connection has been closed: IMPORTANT: Use age in TCP rule only in case of a DOS-type attack (ACK flood and so forth) because it modifies the timeout value of TIME_WAIT state in the TCP state table which can cause duplicate Initial Sequence Numbers (ISN).
pass out on lan0 proto tcp from any to any port 33434><33690 keep state age 60

6.2 NAT Keywords

65

6.3 map and portmap: Mapping Outbound Packets

The map keyword rewrites or translates source addresses for outbound packets. When used with the portmap keyword, map also translates UDP or TCP port numbers. When an outbound packet matches the selectors in a map rule, IPFilter rewrites the source IP address with the specified target IP address. IPFilter also creates an entry in its map table, and checks this map table for both inbound and outbound packets. Checking the map table for inbound packets enables IPFilter to correctly remap and reroute the corresponding inbound packets to the original IP address. To map IP addresses, use the following syntax:
map interface_name source_ip -> target_ip

where: interface_name is the name of the network interface used to transmit the packets. For example, lan1. source_ip is the source IP address. This can a subnet address or 0/0 to match any address. target_ip is the target IP address. IPFilter translates the source IP address to the target IP address. This is usually the IP address assigned to the interface. If the interface has a dynamically assigned address, specify 0/32, and IPFilter will use the currently assigned interface address as the target IP address.

6.3.1 Examples
The following NAT rule replaces IP source addresses from the 192.168.1.0/24 subnet with the address 20.20.20.1 and transmits the packets using the lan0 interface:
map lan0 192.168.1.0/24 -> 20.20.20.1/32

The following NAT rule replaces IP source addresses from the 192.168.1.0/24 subnet with the current IP address for the lan0 interface, then transmits them using lan0:
map lan0 192.168.1.0/24 -> 0/32

6.3.2 portmap Keyword

You can use the portmap keyword to direct IPFilter to translate port numbers. When used with the map keyword, IPFilter maps the source port number to a specific port number or range of port numbers. You can use this feature to create a unique source IP address and source port number pair. This provides unique port and IP address pairs after IP address translation when the same source port number is used on multiple clients. It is also useful if there is another firewall or filtering node the packet must pass through. To use the portmap keyword with map rules, add the following options after the target_ip address:
portmap [protocol] port_range|auto

where: protocol is the upper-layer protocol. Valid values are: tcp udp tcp/udp The default is tcp. port_range is the range of ports to use for the mapped ports. auto directs IPFilter to automatically find an unused port to use as the mapped port. In the following example, the source port numbers for the translated TCP and UDP packets are translated to port numbers in the range 20000 - 30000.
map lan0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:30000

66

Configuring and Loading Network Address Translation (NAT) Rules

6.3.3 map-block: Mapping to a Block of Addresses

IPFilter NAT can map an IP address to a specific block of IP addresses in two ways. You can use the map-block keyword to statically map sessions from a host to a selected block of IP addresses. Configure the following rule:
map-block lan0 192.168.1.0/24 -> 20.20.20.0/24

Any outgoing packet with an IP address beginning with 192.168.1 is mapped to an IP address beginning with 20.20.20. Alternately, you can configure IPFilter NAT to translate to a block of IP addresses using only the map and portmap keywords. Configure the following rule:
map lan0 192.168.0.0/16 -> 20.20.20.0/24 portmap tcp/udp 20000:60000

6.3 map and portmap: Mapping Outbound Packets

67

6.4 rdr: Redirecting Inbound Packets

The rdr keyword redirects inbound packets and rewrites the destination address. To redirect inbound packets, use the following syntax:
rdr interface_name destination_ip -> target_ip

where: interface_name is the name of the network interface used to receive the packets. For example, lan1. destination_ip is the destination IP address. This can a subnet address or 0.0.0.0/0 to match any address. target_ip is the target IP address. IPFilter translates the destination IP address to the target IP address.

6.4.1 Redirecting Packets to a Specific Port

You can also use the rdr keyword with port and protocol specifications to redirect inbound packets from one port to another:
rdr interface_name destination_ip port destination_port -> target_ip port target_port [protocol]

where: interface_name is the name of the network interface used to transmit the packets. For example, lan1. destination_ip is the destination IP address. This can a subnet address or 0.0.0.0/0 to match any address. destination_port is the destination port number. target_ip is the target IP address. IPFilter translates the destination IP address to the target IP address. target_port is the target port number. IPFilter translates the destination port number to the target port number. protocol is the upper-layer protocol. Valid values are: tcp udp tcp/udp The default protocol is tcp. For example, you can redirect traffic destined for port 80 (the IANA-assigned port number for HTTP) to a port used by an alternate or more secure HTTP server, such as port 8080. Configure the following rule:
rdr lan0 20.20.20.5/32 port 80 -> 192.168.0.5 port 8080

You can redirect UDP and ICMP packets as well as TCP packets. To redirect UDP packets, add udp to the rule you configure. For example:
rdr lan0 20.20.20.0/24 port 31337 -> 127.0.0.1 port 31337 udp

6.4.2 Using NAT Redirection with Filtering

You can use NAT redirection and IPFilter filtering together to provide secure, redirected connections. For example, configure the following NAT rule:
rdr lan0 20.20.20.5/32 port 80 -> 192.168.0.5 port 8080

Then configure the following rule in your filter rules file:

pass in on lan0 proto tcp from 172.16.8.2 to 192.168.0.5/32 port = 8080 flags S keep state

68

Configuring and Loading Network Address Translation (NAT) Rules

When a packet comes in, IPFilter first evaluates the NAT rules. IPFilter rewrites the destination address and port number based on the NAT rule. IPFilter then evaluates the filter rules. With the rewritten destination address and port number, the packet matches the pass in rule.

6.4.3 Using the rdr and round-robin Keywords for Load Balancing
You can use the rdr keyword with the round-robin keyword to implement load-balancing systems and redirect traffic to multiple addresses. Separate the target addresses with a comma. For example:
rdr lan0 20.20.20.5/32 port 80 -> 192.168.0.5,192.168.0.6 port 8000 round-robin

You can specify only two target addresses in each round-robin rule, but you can configure two rdr rules for the same interface, for a total of four target addresses. IPFilter will load balance the packets equally between all four target addresses. For example:
rdr lan0 0.0.0.0 -> 192.168.0.1,192.168.0.2 round-robin rdr lan0 0.0.0.0 -> 192.168.0.3,192.168.0.4 round-robin

6.4.4 Sticky NAT Sessions

NAT sessions can be redirected to the same destination IP to achieve source IP-based persistence. This feature only works with rdr NAT rule. The following example creates sticky sessions with all packets coming to 10.1.1.40 redirected to 10.1.1.41 and 10.1.1.27. Round-robin algorithm is used for load balancing because the sticky session feature ensures that all packets go to same IP address as the first packet.
rdr lan4 10.1.1.40/32 port 23 -> 10.1.1.41,10.1.1.27 port 23 tcp round-robin sticky

For more information, see the ipnat(4) manpage. NOTE: This is available only on HP-UX 11i v3.

6.4.5 Checking Connection Health with l4check

A load balancer continually checks the health of the servers to ensure client connections are not forwarded to servers that are down or failed. Sometimes the server is up and responsive, but the application it is hosting is dead or unresponsive. Health checks can be in-band or out-of-band checks. In-band checks use the traffic flow between clients and servers to check server health. For example, the health of a TCP-based application is checked by monitoring the TCP 3-way handshake. An incomplete handshake indicates that the server or application is not working. This check can be followed by additional checks to confirm the situation. Out-of-band health checks are explicit health checks made by the load balancer. The l4check utility monitors for dead IP/port pairs and dynamically removes them from the list of load balanced IP addresses. This utility comes with the /etc/opt/ipf/l4check.conf file that is used to configure the remote IP addresses of servers where connection requests are redirected. NOTE: This is available only on HP-UX 11i v3.

6.4.5.1 Syntax
l4check -f <config file>

6.4.5.2 Options
-n -v Stops action. No NAT rules are added or deleted. Turns on verbose output.

6.4 rdr: Redirecting Inbound Packets

69

6.4.5.3 Sample config File

# # NOTE: ORDER IS IMPORTANT IN THIS FILE # # Interface to do the redirections on and the IP address which will be # targeted. # interface lan0 192.168.1.1,2100 # # # NOTE: ORDER IS IMPORTANT IN THIS FILE # # NOTE: ORDER IS IMPORTANT IN THIS FILE # # Interface to do the redirections on and the IP address which will be # targeted. # interface lan0 192.168.1.1,2100 # # # NOTE: ORDER IS IMPORTANT IN THIS FILE # # Interface to do the redirections on and the IP address which will be # targeted. # interface lan0 192.168.1.1,2100 # connect timeout 1 connect frequency 20 # # If no probe string is specified, a successful connection implies the # server is still alive. # probe string GET /\n\n #probe file http.check # response timeout 4 response string <HTML> #response file http.ok # # Here we have multiple servers, listed because that's what happens to be # used for testing of connect timeouts, read timeouts, success and things # which don't connect. # remote server 192.168.1.2,23 remote server 192.168.1.2,2101 remote server 192.168.1.3,25 remote server 192.168.1.254,8000 remote server 192.168.1.1,9

70

Configuring and Loading Network Address Translation (NAT) Rules

6.5 bimap: Bidirectional Mapping

The bimap keyword creates two map entries for the rule: one for inbound and one for outbound. Unlike the map keyword, an initial inbound packet is not required to create the outbound rule. The bimap keyword allows IPFilter to map IP addresses bidirectionally. You can use this when you want the IP address of a particular device on the NAT-supported system to appear to have a different IP address outside the system. For example:
bimap lan0 192.168.1.1/32 -> 20.20.20.1/32

In this example, the interface with IP address 192.168.1.1 on the NAT-supported system appears to have the IP address 20.20.20.1 outside the system.

6.5 bimap: Bidirectional Mapping

71

6.6 Loading NAT Rules

To load IPFilter NAT rules: 1. 2. Add NAT rules to the /etc/opt/ipf/ipnat.conf file, or to another NAT rules file you select. See The ipnat Utility (page 98) for information and instructions. Use the following command to load the NAT rules manually: ipnat -CF -f /etc/opt/ipf/ipnat.conf This command flushes any current mappings and NAT rules, and reads NAT rules from the specified rules file.

72

Configuring and Loading Network Address Translation (NAT) Rules

7 Address Pooling
This chapter describes address pooling. It contains the following sections: The ippool Utility (page 73) The ippool.conf File (page 73) NOTE: This is available only on HP-UX 11i v3.

7.1 The ippool Utility

Address pools establish a single reference that is used to name a group of address/netmask pairs. Address pools: Facilitate management of large groups of addresses Reduce time to match IP addresses with rules Improve performance The ippool utility manages information stored in the IP pools subsystem of IPFilter. Configuration file information can be parsed and loaded into the kernel. Configured pools can be removed, changed, or inspected. For more information, see the ippool(1M) and ippool(4) manpages.

7.2 The ippool.conf File

The IP pool configuration file defines a single object that contains a reference to multiple IP address/netmask pairs. A pool can consist of a mixture of netmask sizes from 0 to 32. NOTE: Only IPv4 addressing is supported.

The IP pool configuration file provides the following mechanisms to efficiently match IP addresses with rules: The table command defines a lookup table that provides a single filter rule reference to multiple targets. The following storage formats are provided: The hash table format is used with objects that contain the same netmask or a few different sized netmasks of non-overlapping address space. The tree structure supports exceptions to a covering mask. Searching is also supported. IMPORTANT: Pools defined in the configuration file must have an associated role. The only supported role is ipf. For more information and examples, see the ippool(4) manpage.

7.3 Configuring Address Pool

7.3.1 Syntax
table role = <role name> type = <storage format> name = <pool name> {Address list separated by semicolon}

Where table role type

Defines the reference for the multiple addresses. Specifies the role of the pool IN. The only role for reference is ipf. Specifies the storage format for the pool. There are two supported storage formats; tree (pool) and hash table.
7.1 The ippool Utility 73

number/name

Specifies the reference number/name that is used by the filtering rule.

7.3.2 Examples
The following example creates an address pool using the tree storage format that is referenced in the IPF rule which allows packets from this pool.
table role = ipf type = tree name = mypool { 10.1.1.41/32; 10.1.1.42/32; 192.168.1.0/24; } pass in from pool/mypool to any

The following example creates an address pool using the hash storage format that is referenced in the IPF rule which blocks packets from this pool.
table role = ipf type = hash name = myhash { 192.1.1.41/32; 192.1.1.42/32; 10.1.1.0/24; } block in from pool/myhash to any

74

Address Pooling

8 Tips for Securing Your System

This chapter describes specific configuration procedures for HP-UX IPFilter. It contains concepts for basic and advanced firewall design using HP-UX IPFilter features. It contains the following sections: Blocking Services by Port Number and Protocol (page 75) Creating a Complete Filter by Interface (page 76) Combining IP Address and Network Interface Filtering (page 76) Using Bidirectional Filtering (page 77) Using HP-UX IPFilter with End System Security Features (page 77)

NOTE: Most of the information in this chapter has been derived from the IP Filter-based Firewalls HOWTO document written by Brendan Conoby and Erik Fichtner. You can find this document at http://www.obfuscation.org/ipf/.

8.1 Blocking Services by Port Number and Protocol

To create a ruleset that explicitly passes packets for a specific service or services, but blocks all other traffic: 1. 2. Configure pass rules with the quick keyword to allow packets for specific services by port number and protocol. At the end of the ruleset, configure a rule to block all traffic (block in all).

NOTE: You must use the quick keyword in the pass rules so that IPFilter will stop processing rules after it has found a rule that matches a packet. Specifying the quick rule enables you to configure most specific rules first, then less specific rules.

8.1.1 Example: Firewall on a Web Server

For example, to create a firewall on a Web server that will accept connections on TCP port 80 only, configure the following ruleset:
pass in quick on lan0 proto tcp from any to 20.20.20.1/32 port block in all = 80

This system will pass in port 80 traffic for 20.20.20.1 and deny all other traffic. This ruleset provides a basic firewall.

8.1.2 Example: Firewall for Multiple Services

To configure IPFilter for effective security, use several techniques and building blocks together. For example, you can configure rules to allow rsh, rlogin, and telnet to run only on your internal network. Your internal network subnet is 20.20.20.0/24. All three services use specific TCP ports (513, 514, and 23). Configure the following rules in the order shown:
pass in log quick on lan0 proto tcp from any to 20.20.20.0/24 pass in log quick on lan0 proto tcp from any to 20.20.20.0/24 pass in log quick on lan0 proto tcp from any to 20.20.20.0/24 block in all port = 513 port = 514 port = 23

Be sure the rules for the services are placed before the block in all rule to block access to them from systems outside your network. To block UDP instead of TCP, replace proto tcp with proto udp. For example, you can block messages for syslog (UDP port 514) with the following rule:
block in log quick on lan0 proto udp from any to 20.20.20.0/24 port = 514

8.1 Blocking Services by Port Number and Protocol

75

Several services allow you to block by port number for security: syslog on UDP port 514. portmap on TCP port 111 and UDP port 111. You can specify proto tcp/udp with port=111. lpd on TCP port 515. NFS on TCP port 2049 and UDP port 2049. You can also configure NFS to use static (fixed) port numbers for the NFS statd, mountd, and lockd services, as described in Configuring NFS to Use Fixed Ports (page 113) X11 on TCP port 6000.

To get a complete listing of ports being listed on, use netstat -a, or check /etc/services.

8.2 Creating a Complete Filter by Interface

When you create a ruleset, you should configure rules for all directions and all interfaces. The default state of IPFilter is to pass packets both in and out. Instead of relying on the IPFilter default behavior, make every ruleset as specific as possible, interface by interface, until all possibilities are explicitly covered. For example, if you have an IPFilter system with a lan1 interface, and a lan0 interface, configure the following rules:
pass out quick on lan1 pass in quick on lan1 block out quick on lan0 from any to 192.168.0.0/16 block out quick on lan0 from any to 172.16.0.0/12 block out quick on lan0 from any to 10.0.0.0/8 pass out quick on lan0 from 20.20.20.0/24 to any block out quick on lan0 from any to any block in quick on lan0 from 192.168.0.0/16 to any block in quick on lan0 from 172.16.0.0/12 to any block in quick on lan0 from 10.0.0.0/8 to any block in quick on lan0 from 127.0.0.0/8 to any block in log quick on lan0 from 20.20.20.0/24 to any pass in all

In this example, no restrictions are on traffic in and out on lan1. IPFilter has significant restrictions for traffic both in and out of lan0. NOTE: When setting up your ruleset, be sure that you add rules for all appropriate directions and interfaces.

8.3 Combining IP Address and Network Interface Filtering

If you know that your system will send and receive packets only from specific IP addresses and interfaces, configure your IPFilter rules to only allow traffic from those addresses and interfaces. Also, there are addresses and subnets used for specific purposes on specific interfaces. The following examples show rulesets that block packets coming to or from addresses that should not have traffic. For example, the IANA reserves the following address blocks for private addresses: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 In addition, the IANA reserves the 127.0.0.0/8 address block for loopback packets (packets sent by the local system to the local system). By default, IP loopback packets are processed within the IP module and bypass IPFilter. Therefore, it is good practice to block any inbound packets with a loopback address as the source address
76 Tips for Securing Your System

The following ruleset blocks packets from private address blocks and the loopback address block received on lan0:
block in quick block in quick block in quick block in quick pass in all on on on on lan0 lan0 lan0 lan0 from from from from 192.168.0.0/16 to any 172.16.0.0/12 to any 10.0.0.0/8 to any 127.0.0.0/8 to any

If you have an internal network, you can allow only traffic destined for the network with source addresses from addresses within that network. If a packet that comes from an address on the internal network arrives on a dialup interface, it should be blocked by IPFilter. For example, if your internal network subnet is 20.20.20.0/24, use the following rules to keep traffic from the internal subnet from passing through on the external lan0 interface:
block in quick block in quick block in quick block in quick block in quick pass in all on on on on on lan0 lan0 lan0 lan0 lan0 from from from from from 192.168.0.0/16 to any 172.16.0.0/12 to any 10.0.0.0/8 to any 127.0.0.0/8 to an 20.20.20.0/24 to any

8.4 Using Bidirectional Filtering

You can use bidirectional filtering to limit packets leaving a system to those that come from a specific subnet. For example, to limit traffic passing out of the IPFilter system to packets coming from the 20.20.20.0/24 subnet, configure the following rules:
pass out quick on lan0 from 20.20.20.0/24 to any block out quick on lan0 from any to any

If a packet originates from IP address 20.20.20.1/32, it is sent out by the first rule. If a packet originates from IP address 1.2.3.4/32, it is blocked by the second rule. You can also configure similar rules for non-routable addresses. If a system routes a packet through IPFilter with a destination of 192.168.0.0/16, you can drop it to save bandwidth. Use the following ruleset:
block out quick on lan0 from any to 192.168.0.0/16 block out quick on lan0 from any to 172.16.0.0/12 block out quick on lan0 from any to 10.0.0.0/8

This enhances the security of other systems. Spoofed packets cannot be sent from your site. NOTE: The in and out directions refer to the IPFilter system only.

8.5 Using HP-UX IPFilter with End System Security Features

You can use HP-UX IPFilter on security features on end systems to complement local security features. The following example is a ruleset configured to run on a system that also uses TCP Wrapper to protect its network services.
pass in quick on lan0 all pass out quick on lan0 all block in log all block out all pass in quick proto tcp from any to any port = 113 flags S keep state pass in quick proto tcp from any to any port = 22 flags S keep state pass in quick proto tcp from any port = 20 to any port 39999 > < 45000 flags S keep state pass out quick proto icmp from any to any keep state pass out quick proto tcp/udp from any to any keep state keep frags

This IPFilter ruleset provides enhanced protection for the system and services using TCP Wrapper. Any security holes left by TCP Wrapper are plugged.

8.4 Using Bidirectional Filtering

77

78

9 Troubleshooting HP-UX IPFilter

This chapter contains the following sections: Viewing IPFilter Statistics and Active Rules with ipfstat (page 80) Testing Rules with ipftest (page 85) Logging IPFilter Packets (page 88) Troubleshooting Tips (page 92) Reporting Problems (page 94)

79

9.1 Viewing IPFilter Statistics and Active Rules with ipfstat

The ipfstat utility displays IPFilter statistics, including how many packets have been passed or blocked, whether the packets were logged or not, how many state entries have been made, and DCA statistics. You can also use options with ipfstat to display active rules.

9.1.1 Syntax
ipfstat [-options]

9.1.2 Options
For a complete list of ipfstat options, see the ipfstat manpage. If you do not specify any options, ipfstat displays total packet counts for all rules and general statistics. Shows the output for IPv6 rules. This option is valid only with the following -6 options, and must be specified before the other options: -i -o -h -r -vL If you do not specify the -6 option, these commands show the output for IPv4 rules only. For example, to list the active inbound and outbound (-io) IPv6 rules, use the following command: ipfstat -6 -io -i Displays the active rules for inbound packets. If you specify this option with the -6 option, ipfstat displays the IPv6 rules; if you specify this option without the -6 option, it displays the IPv4 rules. Displays the active rules for outbound packets. If you specify this option with the -6 option, ipfstat displays the IPv6 rules; if you specify this option without the -6 option, it displays the IPv4 rules. Displays the active rules and the number of matching packets (hit count) for each rule. Use with the -i or -o options. Displays state table statistics. Displays detailed state table statistics. When used with the -i or -o options, it displays the rules, preceded by group number and rule number in the format @group_number:rule_number. Displays global limit statistics. Displays detailed (verbose) global limit statistics. If you specify this option with the -6 option, ipfstatdisplays the IPv6 rule statistics; if you specify this option without the -6 option, it displays the IPv4 rule statistics. Displays the interfaces protected by IPFilter. Interfaces not supported by IPFilter are not displayed. This option is supported for HP-UX 11i v3 only. For a list of interface types supported by IPFilter, see Supported and Unsupported Interfaces (page 128). -r group:rule Displays the limit statistic by rule number. If you specify this option with the -6 option, ipfstatdisplays the IPv6 rule; if you specify this option without the -6 option, it displays the IPv4 rule.

-o

-h -s -sl -n

-L -Lv

-Q

80

Troubleshooting HP-UX IPFilter

-v

Sets verbose mode. Use for debugging. NOTE: Statistics counters cannot increment when both active in and out rulesets are empty. This is due to a performance optimization that bypasses IPFilter when there are no active rulesets present.

9.1.3 Examples
# ipfstat dropped packets: in 0 out 0 non-data packets: in 0 out 0 no-data packets: in 0 out 0 non-ip packets: in 0 out 0 bad packets: in 0 out 0 copied messages: in 0 out 0 input packets: blocked 15 passed 2647 nomatch 2537 counted 0 short 0 output packets: blocked 0 passed 245 nomatch 141 counted 0 short 0 input packets logged: blocked 0 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 TCP connections: in 5 out 50 log failures: input 0 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 5 lost 0 packet state(out): kept 0 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Invalid source(in): 0 Result cache hits(in): 14 (out): 0 IN Pullups succeeded: 0 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) none

The TCP Connections statistics are derived from the number of states added and are accurate only when keep limit or keep state rules are used for all TCP connections. For example, you have the following ruleset:
pass in log limit freq 500 quick proto tcp from any to any port = 80 keep limit 100

pass in log quick proto tcp from any to any port = 25 flags S keep state pass in log quick proto tcp from any to any port = 23 pass out log quick proto tcp from any port = 23 to any

These rules only count connections that match the first two rules. Both the third and fourth rule allow telnet connections but telnet connections are not counted, since the system is not keeping state on these connections. Example:
# ipfstat -ho 2451423 pass out on lan0 from any to any 354727 block out on ppp0 from any to any 430918 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 From to any keep state keep frags

This status report shows that the ruleset may not be working as intended. Many outbound packets are being blocked despite a pass out rule configured to pass most outbound packets. ipfstat cannot indicate whether a ruleset is configured correctly. It can only display what is happening at the present time with a given ruleset.
9.1 Viewing IPFilter Statistics and Active Rules with ipfstat 81

Set the -n option to display the rule number next to each rule. The rule number is displayed as @group:rule. This can help you determine which rules are incorrectly configured. For example:
# ipfstat -on
@0:1 pass out on lan0 from any to any @0:2 block out on ppp0 from any to any @0:3 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state keep frags

The following example uses the -s option to display the state table.
# ipfstat -s 281458 TCP 319349 UDP 0 ICMP 19780145 hits 5723648 misses 0 maximum 0 no memory 0 bkts in use 1 active 319349 expired 281419 closed

A TCP connection has one state entry. One fully established connection is represented by the 4/4 state. Other states are incomplete and will be documented later. The state entry has a time life of 24 hours, which is the default for an established TCP connection. The time-to-live (TTL) counter is decremented every second that the state entry is not used and will result in the connection being purged if it is left idle. The TTL counter is reset to 86400 whenever the state is used, ensuring the entry will not time out while it is being actively used. 196 packets consisting of about 17KB worth of data have been passed over this connection. The ports for the endpoints are 987 and 22; this state entry represents a connection from 100.100.100.1 port 987 to 20.20.20.1 port 22. The numbers in the second line are the TCP sequence numbers for this connection. These numbers help ensure that an attacker cannot insert a forged packet into your session. The TCP window is also shown. The third line is a synopsis of the implicit rule generated by the keep state code showing that this is an inbound connection. The ipfstat -sl option is often used in place of ipfstat -s to show held state information in the kernel, if present. The ipfstat -sl gives detailed information for each state entry that is active. The following is an example of the output information of the ipfstat -sl option:
# ipfstat -sl 15.13.106.175 -> 15.13.137.135 ttl 872678 pass 0x500a pr 6 state 4/4 pkts 31 bytes 1564 57906 -> 23 22c0861c:712c2bd9 32768:32768 cmsk 0000 smsk 0000 isc 0000000000000000 s0 22c085e0/712c2b7f sbuf[0] [\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0] sbuf[1] [\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0] pass in quick keep state IPv4 pkt_flags & 2(b2) = b, pkt_options & ffffffff = 0 pkt_security & ffff = 0, pkt_auth & ffff = 0 interfaces: in lan0[00000000480baf00] out -[0000000000000000]

The following is an example of the output information of the ipfstat -io option.
#ipfstat -sl empty list for ipfilter(out) 1 pass in quick proto tcp from 15.13.106.175/32 to any keep state

The following is an example of the output information of the ipfstat -L option.

Current connections to limited IP addresses Connection Type Active Limits Individual 2
82 Troubleshooting HP-UX IPFilter

Subnet Cumulative Unknown IP Total No Memory Logged Records Log Failures Limits Added Add Failures

3 5 9 19 0 13 0 13 0

The first six lines display the number of current active connections of each described type. No Memory is the number of times a limit entry could not be created because no memory was available. If this is a non-zero, positive value, then the system memory should be checked and, if necessary, increased. Logged Records is the number of limit entries logged, both summary and alert log records. Log Failures is the number of times log entries have not been logged. A non-zero, positive value for Log Failures indicates that the size of the kernel log buffer is small. The kernel log buffer ipl_buff_sz should be set to an appropriate value. Limits Added is the number of limit entries that have been added. Add Failures is the number of times a limit entry could not be created. This happens when a state entry is not added. The output of ipfstat -s should be used to further diagnose the problem.

These statistics are cumulative. They are automatically reset to zero when the ipf module is unloaded and loaded again. See Appendix C (page 143) for more information on setting the size of the state table, limit table, and log buffer. The following is an example of the output information of the ipfstat -vL option:
Type Rule S @0:3 S @0:1 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 U @0:1000 S @0:1000 U @0:1000 U @0:1000 Src IP Src 10.39.1.2 10.2.1.2 10.30.1.2 10.30.1.3 10.30.1.4 10.30.1.5 10.30.1.6 10.30.1.7 10.30.1.8 10.30.1.0 10.49.1.2 10.49.1.3 10.49.1.4 10.49.1.5 10.49.1.6 10.49.1.7 10.49.1.8 10.49.1.9 10.40.1.2 10.46.1.2 10.46.1.3 Port * * * * * * * * * * * * * * * * * * * * * Dest IP Dest Port Limit Current 10.133.1.5 80 50000 951 (0) 10.129.1.5 80 50000 942 (0) 10.130.1.5 80 10 10(102) 10.130.1.5 80 10 9 (501) 10.130.1.5 80 10 10(100) 10.130.1.5 80 10 10(118) 10.130.1.5 80 10 10(196) 10.130.1.5 80 10 10(198) 10.130.1.5 80 10 10(104) 10.130.1.5 80 10 10(111) 10.131.1.5 80 10 10 (55) 10.131.1.5 80 10 10 (53) 10.131.1.5 80 10 10(102) 10.131.1.5 80 10 9 (52) 10.131.1.5 80 10 9 (52) 10.131.1.5 80 10 10(103) 10.131.1.5 80 10 10(120) 10.131.1.5 80 10 10(50) 10.134.1.5 80 50000 943(0) 10.128.1.5 80 10 10 (49) 10.128.1.5 80 10 10 (41)

The Type column displays the type of limit being kept: IFully resolved individual IP SIP subnet CCumulative UUnknown IP

9.1 Viewing IPFilter Statistics and Active Rules with ipfstat

83

These limit entries are created through the default rule. See keep limit: Limiting Connections (page 53) for detailed information on the different types of limit entries. The Rule column displays the rule number that caused the creation of this limit entry. This information can in turn be used to get per-rule statistics using the ipfstat -r command. The third through sixth columns display IP-port pairs of the TCP connection. The Limit column displays the configured limit specified in the keep limit rule. The Current column displays the number of fully established connections under that limit entry. The figure in the parenthesis indicates the number of times the configured limit was exceeded. For example, the first entry shows that, even though the IP address 15.10.40.10 currently has two active connections, it had exceeded the configured limit of 10 connections twice. These numbers can serve as guide for adjusting and tuning the limit value for an IP address or IP subnet.
Individual @0:6 7 3 33 33

The following is an example of the output information of the ipfstat -r group:rule option.
Limit Type Group:Rule Number Configured Limit Current connections Limit Exceeded (#times) TCP RSTs sent (#times)

In this example, rule number 6 created a limit entry of type Individual. The rule specifies a connection limit of 7. There are three current connections using this rule. The limit has been exceeded 33 times. The rule included the return-rst keyword, so IPFilter sent a TCP Reset packet each time an attempt was made to exceed the configured limit. If the rule is deleted or switched to the inactive set, @(del) is displayed in the Group:Rule Number field.

84

Troubleshooting HP-UX IPFilter

9.2 Testing Rules with ipftest

The ipftest utility enables you to test a ruleset without loading it. You do not need superuser capabilities to run ipftest. The ipftest utility tests a ruleset using a set of packet descriptors that simulate network traffic. The ipftest utility determines the action IPFilter would take for each packet and writes the packet and the action to stdout. When you generate simulated traffic, you can use example data obtained from a packet probe or similar monitor. These packets can show the specifics of the traffic the subject system will encounter in a production environment. If you are testing TCP keep state rules, include the TCP flag values in the packet descriptor.

9.2.1 Syntax
ipftest [-6] -r ruleset_filename [-i input_filename]

9.2.2 Options
-6 -r ruleset_filename -i input_filename Specifies that the rules tested are IPv6 filter rules. Specifies the file from which to read rules. Specifies the file that contains packet descriptors. The default is stdin. Each packet descriptor must be contained on one line. By default, the format for each packet descriptor is as follows:
in|out [on interface] [protocol] src_host[,src_port] dest_host[,dest_port] [flags]

Where: interface protocol

Specifies the interface name, such as lan0. Specifies the protocol name. Valid values are: tcp udp icmp icmpv6

src_host src_port

Specifies the source IP address or host name. Specifies the source TCP or UDP port number. You must specify src_port if you specified the protocol tcp or udp. Specifies the destination IP address or host name. Specifies the destination TCP or UDP port number. You must specify dest_port if you specified the protocol tcp or udp. Specifies TCP flags as a sequence of one or more characters that indicate TCP flags. This parameter is valid only if you specified the protocol tcp. The valid characters are: A (ACK - Acknowledgement) F (FIN - No more data) P (PUSH - Push function) R (RST - Reset the connection) S (SYN - Sychronize sequence numbers) U (URG - Urgent)

dest_host dest_port

flags

9.2 Testing Rules with ipftest

85

The ipftestutility supports additional options to specify the input format and to control packet testing. For a complete list of options and their functions, see the ipftest manpage.

9.2.3 Example
The following ruleset is used for this example:
block in all pass in from 10.1.84.195 to any

The input file contains the following packet descriptors:

in on lan0 udp 10.1.84.195,16000 10.1.84.196,16000 in on lan1 udp 10.1.84.195,16000 10.1.85.196,16000 in on lan0 udp 10.1.84.195,16000 10.1.80.196,16000 in on lan0 udp 10.1.85.195,16000 10.1.84.196,16000 in on lan1 udp 10.1.85.195,16000 10.1.85.196,16000 in on lan0 udp 10.1.85.195,16000 10.1.80.196,16000 out on lan0 udp 10.1.84.196,16000 10.1.84.195,16000 out on lan1 udp 10.1.85.196,16000 10.1.84.195,16000 out on lan0 udp 10.1.80.196,16000 10.1.84.195,16000 out on lan0 udp 10.1.84.196,16000 10.1.85.195,16000 out on lan1 udp 10.1.85.196,16000 10.1.85.195,16000 out on lan0 udp 10.1.80.196,16000 10.1.85.195,16000 in on lan0 udp 10.1.81.195,16000 10.1.84.196,16000 in on lan1 udp 10.1.81.195,16000 10.1.85.196,16000 out on lan0 udp 10.1.84.196,16000 10.1.81.195,16000 out on lan1 udp 10.1.85.196,16000 10.1.81.195,16000 out on lan0 icmp 10.1.84.196 10.1.84.195 in on lan0 icmp 10.1.84.195 10.1.84.196 out on lan0 udp 10.1.80.196,16001 10.1.84.195,16000 out on lan0 udp 10.1.80.196,16001 10.1.85.195,16000 in on lan0 udp 10.1.84.195,16000 10.1.80.196,16001 in on lan0 udp 10.1.85.195,16000 10.1.80.196,16001

These packets are similar to a test system setup that is used in the actual testing of IPFilter. The name of the rules file is test01 and the name of the packet file is packets01. The packets are processed with ipftest using the following command:
ipftest -r test01 -i packets01

The following is the output of ipftest:

opening rule file "test01" input: in on lan0 udp 10.1.84.195,16000 10.1.84.196,16000 pass ip 28(20) 17 10.1.84.195,16000 > 10.1.84.196,16000 -------------input: in on lan1 udp 10.1.84.195,16000 10.1.85.196,16000 pass ip 28(20) 17 10.1.84.195,16000 > 10.1.85.196,16000 -------------input: in on lan0 udp 10.1.84.195,16000 10.1.80.196,16000 pass ip 28(20) 17 10.1.84.195,16000 > 10.1.80.196,16000 -------------input: in on lan0 udp 10.1.85.195,16000 10.1.84.196,16000 block ip 28(20) 17 10.1.85.195,16000 > 10.1.84.196,16000 -------------input: in on lan1 udp 10.1.85.195,16000 10.1.85.196,16000 block ip 28(20) 17 10.1.85.195,16000 > 10.1.85.196,16000 -------------input: in on lan0 udp 10.1.85.195,16000 10.1.80.196,16000
86 Troubleshooting HP-UX IPFilter

block ip 28(20) 17 10.1.85.195,16000 > 10.1.80.196,16000 -------------input: out on lan0 udp 10.1.84.196,16000 10.1.84.195,16000 nomatch ip 28(20) 17 10.1.84.196,16000 > 10.1.84.195,16000 -------------input: out on lan1 udp 10.1.85.196,16000 10.1.84.195,16000 nomatch ip 28(20) 17 10.1.85.196,16000 > 10.1.84.195,16000 -------------input: out on lan0 udp 10.1.80.196,16000 10.1.84.195,16000 nomatch ip 28(20) 17 10.1.80.196,16000 > 10.1.84.195,16000 -------------input: out on lan0 udp 10.1.84.196,16000 10.1.85.195,16000 nomatch ip 28(20) 17 10.1.84.196,16000 > 10.1.85.195,16000 -------------input: out on lan1 udp 10.1.85.196,16000 10.1.85.195,16000 nomatch ip 28(20) 17 10.1.85.196,16000 > 10.1.85.195,16000 -------------input: out on lan0 udp 10.1.80.196,16000 10.1.85.195,16000 nomatch ip 28(20) 17 10.1.80.196,16000 > 10.1.85.195,16000 -------------input: in on lan0 udp 10.1.81.195,16000 10.1.84.196,16000 block ip 28(20) 17 10.1.81.195,16000 > 10.1.84.196,16000 -------------input: in on lan1 udp 10.1.81.195,16000 10.1.85.196,16000 block ip 28(20) 17 10.1.81.195,16000 > 10.1.85.196,16000 -------------input: out on lan0 udp 10.1.84.196,16000 10.1.81.195,16000 nomatch ip 28(20) 17 10.1.84.196,16000 > 10.1.81.195,16000 -------------input: out on lan1 udp 10.1.85.196,16000 10.1.81.195,16000 nomatch ip 28(20) 17 10.1.85.196,16000 > 10.1.81.195,16000 -------------input: out on lan0 icmp 10.1.84.196 10.1.84.195 nomatch ip 48(20) 1 10.1.84.196 > 10.1.84.195 -------------input: in on lan0 icmp 10.1.84.195 10.1.84.196 pass ip 48(20) 1 10.1.84.195 > 10.1.84.196 -------------input: out on lan0 udp 10.1.80.196,16001 10.1.84.195,16000 nomatch ip 28(20) 17 10.1.80.196,16001 > 10.1.84.195,16000 -------------input: out on lan0 udp 10.1.80.196,16001 10.1.85.195,16000 nomatch ip 28(20) 17 10.1.80.196,16001 > 10.1.85.195,16000 -------------input: in on lan0 udp 10.1.84.195,16000 10.1.80.196,16001 pass ip 28(20) 17 10.1.84.195,16000 > 10.1.80.196,16001 -------------input: in on lan0 udp 10.1.85.195,16000 10.1.80.196,16001 block ip 28(20) 17 10.1.85.195,16000 > 10.1.80.196,16001 --------------

Each result is one of the following: pass, block, or nomatch. For HP-UX IPFilter, the default is pass. From the results you can verify that the filter should operate as expected. More complex rulesets and sample traffic can be tested to reflect a production environment.

9.2 Testing Rules with ipftest

87

9.3 Logging IPFilter Packets

This section describes how to use the log keyword in IPFilter rules to configure logging and how to use the ipmon utility to view IPFilter log records

9.3.1 Using the log keyword to Configure IPFilter Logging

To configure logging, specify the log keyword in an IPFilter rule after the in or out keyword, as described in log: Logging Packets (page 31). The log keyword directs IPFilter to log packets matching the rule to the IPFilter logging device, /dev/ipl. To view log entries, use the ipmon utility as described in Using ipmon to View IPFilter Log Entries (page 90) . You can use the ipmon -s command to send the output from /dev/ipl to syslog. IPFilter supports the following options with the log keyword to refine the log entries: level first body

9.3.1.1 level log-level

You can control the level of logging IPFilter does by specifying the level log-level option with the log keyword in a rule. The syntax for level is:
log level facility.priority | priority

The valid values for facility are:

kern daemon lpr cron audit local1 local4 local7 user auth news ftp logalert local2 local5 mail syslog uucp authpriv local0 local3 local6

The valid values for priority are:

emerg err info alert warn debug crit notice

Example:
block in log level auth.info quick on lan0 from 20.20.20.0/24 to any block in log level auth.alert quick on lan0 proto tcp from any to 20.20.20.0/24 port = 21

9.3.1.2 first
You can use the first option with the log keyword to log only the first instance of a certain type of packet. For example, it might not be important to log 500 attempts to probe your telnet port from one source. It is a good idea to log the first attempt, however.

88

Troubleshooting HP-UX IPFilter

The first option only applies to packets in a specific session. You can use the first option to monitor traffic on your system. For best results, use the first option in conjunction with rules that use pass and keep state. Example:
pass in log first proto tcp from amy to any flags S keep state

9.3.1.3 body
You can use the body option with the log keyword to track parts of an IP packet in addition to the packet header information. IPFilter logs the first 128 bytes of a packet if the body option is specified. For example:
block in log body proto tcp from 192.168.1.1 to any flags S keep state

NOTE: Using the body option with the log keyword can make your log files very long. Limit the use of the body option to necessary instances.

9.3 Logging IPFilter Packets

89

9.3.2 Using ipmon to View IPFilter Log Entries

The ipmon utility displays IPFilter log entries in human-readable format. To configure IPFilter to create log entries, specify the log keyword in IPFilter rules, as described in Using the log keyword to Configure IPFilter Logging (page 88). The ipmon utility can also display the state table log, the NAT log, or any combination of these three. You can run ipmon in the foreground or as a daemon that logs to syslog or a file. Log files include both IPv4 and IPv6 log records, ordered according to the time IPFilter receives the packets.

9.3.2.1 Syntax
ipmon -options

9.3.2.2 Options
-a -o [NSI] Opens and reads data from all available log files. Equivalent to -o NSI. Specifies which log file to read data from. Valid values are: NNAT log file SState log file IIPFilter log file Logs the summary records created for DCA logging. Prints the summary records to the summary log file and clears the block count for each limit entry. Flushes the packet log buffer. Output displays the number of bytes flushed. Maps IP addresses and port numbers to host names and services wherever possible. Reads rules and actions from the configuration file.

-A -r -F -n -C <ipmon configuration file>

For a complete list of ipmon options and their uses, see the ipmon manpage.

9.3.2.3 Examples
To view the state table as it updates, use the ipmon -o S command. Example:
# ipmon -o S 01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 ->20.20.20.15,53 PR udp 01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 ->128.167.1.69,123 PR udp 01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 ->128.173.14.71,123 PR udp 01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 ->20.20.20.15,53 PR udp Pkts 4 Bytes 356 01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 ->100.100.100.10,22 PR tcp 01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 ->100.100.100.10,22 PR tcp Pkts 63 Bytes 4604

A state entry for an external DNS request to the nameserver is displayed by ipmon. Two xntp pings to well-known time servers and a short outbound SSH connection are also displayed. You can also use ipmon to display packets that have been logged. To view the IPFilter packet log, use theipmon -o I command. Example:
# ipmon -o I

90

Troubleshooting HP-UX IPFilter

15:57:33.803147 lan0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp len 20 1488 -A:

The fields in this output are as follows: Field 1Time stamp Field 2The interface on which the event occurred Field 3Rule group number: rule number of the rule used for the packet, in the format @group_number:rule_number Field 4Action; blocked (b) or passed (p) packet Field 5Packet source, in the format ip_address,port Field 6Packet destination, in the format ip_address,port Field 7 and 8Protocol Field 9Packet size Field 10Flags set on packet

Use the ipfstat -in command to determine the text of the rule that created the log entry. In the previous example, you would use this command to look at rule 2 in rule group 0 (@0:2). IPFilter sometimes logs a packet matching a keep state rule in the normal (non-state) IPFilter log file. This occurs when a packet matching a keep state rule has the same sequence number as a packet matching a normal (non-state) rule that has logging enabled. IPFilter. This may also occur when a packet matching a keep state rule is the last packet in a stateful connection and arrives after IPFilter has deleted the state table entry. Example:
#ipfstat -n 12:46:12.470951 lan0 @0:1 S 20.20.20.254 -> 255.255.255.255 PR icmp len 20 9216 icmp 9/0

This is a ICMP router discovery broadcast packet. It is indicated by the ICMP type 9/0.

9.3.2.4 ipmon and DCA Logging

DCA logging uses different device files than normal IPFilter logging. The DCA module writes alert log records to /dev/ipl and writes summary log records to /dev/iplimit. To view the summary records, use ipmon with the -A option. Using ipmon -A prints a summary log for a limit entry before the entry being removed from the limit table. Example: ipmon -A /dev/iplimit > $LOGDIR/limit_summary.log & You can use ipmon -r to print the summary records to the log file for all existing limit entries that are active. For example, you have the following rule configured: pass in log limit quick proto tcp from host1 to Server keep limit 10 If host1 creates 70 connections, then 10 connections are let through and remaining 60 are blocked, which is the block count. When ipmon -r is called, a summary record is logged to the summary log records and the block count is set to 0. This is useful in a case where host1 created many connections and has a large block count, but subsequently has connections that are within the connection limit. ipmon -r works only on active limit entries. If there are no limit entries, ipmon -r does not log any Summary Log records. Summary logs are printed only for those limit entries which have a non-zero connection exceeded counter. For cumulative limits, this option is the only way to obtain summary logs.

9.3.3 Analyzing IPFilter Log Events

The ipmon feature simplifies IPFilter log analysis and allows monitoring for specific log events. When such an event is found, the rule configuration runs a shell command or logs the event to

9.3 Logging IPFilter Packets

91

syslog. The shell command can be an alert mailed to the administrator or an IPFilter command to update filter rules. For more information, see the ipmon(4) manpage. NOTE: This is available only on HP-UX 11i v3.

9.3.3.1 Syntax
ipmon -C <ipmon.conf file>

9.3.3.2 ipmon.conf File Syntax

match {<matching rules>} do {<action>} If an UDP packet is coming from 10.1.1.41 and it is blocked as per configured IPF rules, then ipmon sends a mail to the root account with the message "blocked UDP packet from 10.1.1.41". For example:
match { srcip = 10.1.1.41/32, protocol = udp, result = block } do {execute "/usr/bin/mail -s 'blocked UDP packet from 10.1.1.41' root" };

If an ICMP packet is going to 10.1.1.40 and it is allowed as per configured IPF rules, then ipmon logs this packet in syslog. For example:
match { dstip = 10.1.1.40/32, protocol = icmp, result = pass } do { syslog };

If a packet is coming on interface lan4 and it matches to a keep state rule, then ipmon logs it in syslog and saves the log in a separate file /state_save. For example:
match {interface = lan4, type = state} do { syslog, save "/state_save" };

9.4 Troubleshooting Tips

This section describes how to troubleshoot an HP-UX IPFilter configuration. It provides information about possible problems that might occur along with the steps needed to resolve them. HP-UX IPFilter is not filtering packets (it passes/allows all network packets). On HP-UX 11i v3 systems, verify that HP-UX IPFilter is enabled by entering the following command: ipfilter -q If IPFilter is not enabled, enable it by entering the following command: ipfilter -e Load the rulesets after enabling IPFilter. See Loading IPv4 Filter Rules (page 42), On all HP-UX versions, verify that HP-UX IPFilter is running by entering the following command: ipf -V The running field should say yes. If it says no, then the HP-UX IPFilter module has not been loaded. It might have been explicitly unloaded. To load IPFilter again, use: /sbin/init.d/ipfboot start To determine if the HP-UX IPFilter DLKM modules are loaded, execute either the kmadmin(1M) command on HP-UX 11i v1 or the kcmodule (1M) command on HP-UX 11i v2 and HP-UX 11i v3. See the respective manpages for more information. Load the rules and check again that IPFilter works. If it still does not work, reboot the system and check /etc/rc.log and /var/adm/syslog/syslog.log for errors.
92

The host does not seem to be on the network and ping messages do not go through.

Troubleshooting HP-UX IPFilter

Check the rules you have configured using ipfstat -io. This command will display the active inbound and outbound rules. NOTE: If you are using /etc/opt/ipf/ipf.conf as your rules file, then IPFilter will load it at boot time. The IPFilter startup script /sbin/init.d/ipfboot: Loads the IPFilter module. Starts the logging daemon, ipmon. Loads any uncommented rules in the /etc/opt/ipf/ipf.conf file. Loads any uncommented rules in the /etc/opt/ipf/ipf6.conf if IPv6 is enabled on the system. If your rules file blocks packets for network services that last effective rule amounts to block in all, the boot sequence might not complete, for example, when sendmail, SNMP, and NIS are configured on the system. Nothing is logged. Verify the following: ipf -V should show the logging file as available. ps -ef|grep ipmonto verify if ipmon is running. During bootup, ipmon is started. If it is not running, start it by using: ipmon -s D The -s option specifies that the log records go to /var/adm/syslog/syslog.log and the -D option directs ipmon to run as a daemon in the background. Errors occur when loading rules.
# ipf -f rule_file ioctl (add/insert rule); File Exists

This occurs when you try to add a rule that is already loaded. Use the following command to load rules: ipf -Fa -f rulefile The -Fa option will flush any previous rules present and all rules will be reloaded. In addition, you can use ipftest to test a set of filter rules without having to put them in place. See the ipftest(1) manpage for more information on this tool. IPFilter rules changed after using Bastille/Install-Time-Security level. If you configure an IPFilter ruleset-using Install-Time-Security level, or use HP-UX Bastille interactively to reconfigure IPFilter rules, existing rules will be overwritten. This will change IPFilter behavior. To reinsert your rules into the Bastille-setup firewall rules, edit /etc/opt/sec_mgmt/ bastille/ipf.customrules, and run bastille -b -f config file . Alternatively, to remove all of the security hardening performed by Bastille, including the firewall configuration, run bastille -r. For more information, see the Bastille documentation.

9.4 Troubleshooting Tips

93

9.5 Reporting Problems

Include the following information when reporting problems: A complete description of the problem and any error messages. Include information about: the local system (IP addresses) IP addresses of relevant remote systems IP interface information (netstat -i output) if appropriate routing table information (netstat -rn output) if appropriate Output from the following commands: ipf -V ipfstat -v ipfstat -nio ipfstat -aio ipfstat -hio ipfstat -Iio ipfstat -s ipfstat -sl ipfstat -f ipfstat -g ipfstat -Q (on HP-UX 11i v3 systems) Relevant IPFilter configuration files: /etc/rc.config.d/ipfcon /etc/opt/ipf/ipf.conf (or alternate IPv4 filter rules file) /etc/opt/ipf/ipnat.conf (or alternate NAT rules file) /etc/opt/ipf/ipf6.conf (or alternate IPv6 filter rules file) IP configuration file: /etc/rc.config.d/netconf

94

Troubleshooting HP-UX IPFilter

10 HP-UX IPFilter Utilities

This chapter describes utilities for administering IPFilter. It contains the following sections: The ipf Utility (page 95) The ipnat Utility (page 98) The ipfilter Utility (HP-UX 11i v3) (page 99) The ippool Utility (page 99) NOTE: Most of the information in this chapter has been derived from the IP Filter-based Firewalls HOWTO document written by Brendan Conoby and Erik Fichtner. You can find this document at http://www.obfuscation.org/ipf/.

10.1 The ipf Utility

The ipf utility performs a broad range of actions on the active and inactive IPFilter rulesets. You can use ipf to add rules, delete rules, switch active and inactive rulesets, and flush the existing ruleset from the system. You can perform other actions with ipf. See the ipf manpages for more information.

10.1.1 Syntax
ipf -options [-f rules_file_name]

10.1.2 Options
The following are a few of the common options used with the ipf utility: Apply the action to the IPv6 filter ruleset or rulesets, or IPv6 -6 processing. To use this option, insert it immediately after the ipf command and before any other options. If you do not specify the -6 option, IPFilter applies the option to the IPv4 ruleset or rulesets, or IPv4 processing.

10.1 The ipf Utility

95

-s

Switches the active ruleset with the inactive ruleset. IPFilter maintains an active ruleset and an inactive ruleset. The active ruleset is the ruleset used for IPFilter operations, and the inactive ruleset is a supplementary, reserve ruleset. If you specify this option with the -6 option, this option affects the IPv6 rulesets; if you specify it without the -6 option, this option affects the IPv4 rulesets.

-Fa

Flushes all rules in the specified ruleset. If you specify this option with the -6 option, this option affects the IPv6 rulesets; if you specify it without the -6 option, this option affects the IPv4 rulesets. Flushes only the IN rules in the ruleset. If you specify this option with the -6 option, this option affects the IPv6 rulesets; if you specify it without the -6 option, this option affects the IPv4 rulesets. Flushes only the OUT rules in the ruleset. If you specify this option with the -6 option, this option affects the IPv6 rulesets; if you specify it without the -6 option, this option affects the IPv4 rulesets. Specifies that the action applies to the inactive ruleset. If you specify this option with the -6 option, this option affects the IPv6 ruleset; if you specify it without the -6 option, this option affects the IPv4 ruleset. Zeroes out the TCP Connections counters displayed in the ipfstat output. Disables or enables DCA mode, queries the DCA mode, or toggles DCA between being enabled or disabled by using the following options: d Disables DCA. e Enables DCA. q Queries whether DCA is disabled or enabled. t Toggles DCA between disabled or enabled. There is a single DCA mode for both IPv4 and IPv6 DCA processing. Specifying the -6 option with the -m option has no effect. See Enabling and Disabling DCA (page 60) for more information about how to disable, enable, query, or toggle DCA. TIP: If you have no DCA rules (no keep limit rules), HP recommends that you disable DCA.

-Fi

-Fo

-I

-Z -m d|e|q|t

-E interface_name

Enables IPFilter processing for traffic on a given interface. If you specify this option with the -6 option, it enables IPv6 IPFilter processing; if you specify this option without the -6 option, it enables IPv4 IPFilter processing. Disables IPFilter processing for traffic on a given interface. If you specify this option with the -6 option, it disables IPv6 IPFilter processing; if you specify this option without the -6 option, it disables

-D interface_name

96

HP-UX IPFilter Utilities

IPv4 IPFilter processing. -Q interface_name Queries if IPFilter processing is enabled or disabled for a given interface. If you specify this option with the -6 option, it queries the status of IPv6 IPFilter processing; if you specify this option without the -6 option, it queries the status of IPv4 IPFilter processing. The -E, -D, and -Q commands let you control IPFilter processing on a given interface. For example, ipf -D lan0 disables IPv4 IPFilter processing for traffic on lan0. The command ipf -6 -E lan0 enables IPv6 IPFilter processing on lan0. The ipf -Q lan0 command queries if IPv4 IPFilter processing is enabled or disabled for lan0. NOTE: All ipf actions are performed on the active rules file by default. To perform actions on the inactive rules file, you must specify the -I option. For a complete list of ipf options and their uses, see the ipf(5) and ipf(8) manpages.

10.1.3 Example
Enter the following command to load a ruleset: ipf -Fa -f rules_file

10.1 The ipf Utility

97

10.2 The ipnat Utility

Use the ipnat utility to view and load NAT rules. The default NAT rules file is /etc/opt/ ipf/ipnat.conf.

10.2.1 Syntax
ipnat -options full_path_name

10.2.2 Options
-f -l -C -F -r Reads rules from a specified rules file. Lists NAT rules and active mappings. Deletes the current ruleset. Flushes active mappings. Removes rules from the NAT rules file.

10.2.3 Example
Enter the following command: ipnat -CF -f /etc/opt/ipf/ipnat.conf This command flushes any existing NAT rules and removes any active mappings, then loads the NAT rules in the ipnat.conf file.

98

HP-UX IPFilter Utilities

10.3 The ipfilter Utility (HP-UX 1 1i v3)

The ipfilter utility enables, disables, and reports the IPFilter state. The ipfilter utility is supported only on HP-UX 11i v3.

10.3.1 Syntax
/opt/ipf/bin/ipfilter -d|e|q|l|ei|di

10.3.2 Options
-e -d -q -l -ei -di Enables the HP-UX IPFilter module. Disables the HP-UX IPFilter module. Queries the HP-UX IPFilter module and displays whether it is enabled or disabled. Lists the interfaces and shows which are protected or unprotected by IPFilter. Enables IPFilter in interactive mode. Disables IPFilter in interactive mode.

CAUTION: HP recommends that you enable or disable IPFilter when interrupting network connectivity is not disruptive. HP recommends that you do not enable or disable HP-UX IPFilter when critical network applications are running. Disabling or enabling IPFilter using briefly brings down all IP interfaces, then brings up only the IP interfaces configured in the /etc/rc.config.d/netconf and /etc/rc.config.d/ netconf-ipv6 files. IP addresses not configured in the netconf or netconf-ipv6 file, such as Serviceguard relocatable IP addresses, are not re-enabled. Enabling or disabling IPFilter causes the system to briefly lose network connectivity. If a system has several IP interfaces or there is heavy network traffic, the time required to re-establish network connectivity might be interpreted as a network or card failure. For example, Serviceguard might interpret a network interruption as a card failure, which can cause it to reform the cluster. NOTE: The state of HP-UX IPFilter (enabled or disabled) remains the same after the system reboots. After you have enabled HP-UX IPFilter, there is no need to disable it or re-enable it for normal operation.

10.3.3 Example
Because enabling HP-UX IPFilter brings down all the network interface cards and then brings them back up, HP recommends that you query the current IPFilter state using the ipfilter -q command to verify that you need to enable it. # /opt/ipf/bin/ipfilter -q # /opt/ipf/bin/ipfilter -e

10.4 The ippool Utility

The ippool utility is used to manage information stored in the IP pools subsytem of IPFilter. For more information, see Chapter 7 (page 73) or the ippool(8) manpage.

10.4.1 Syntax
ippool -options

10.3 The ipfilter Utility (HP-UX 11i v3)

99

10.4.2 Global Options

-d -n -v Toggle debugging of processing the configuration file. Prevents ippool from making ioctl calls or altering the running kernel. Turns verbose mode on.

10.4.3 Command Options

-a -A -f <file> -F -l -r -R -s -i <ipaddr>[/<netmask>] Adds a new data node to an existing pool in the kernel. Adds a new (empty) pool to the kernel. Reads IP pool configuration information from the file and load it into the kernel. Flushes loaded pools from the kernel. Displays a list of pools currently loaded into the kernel. Removes an existing data node from a pool in the kernel. Removes an existing pool from within the kernel. Displays IP pool statistical information. Sets the IP address for the current operation with an all-ones mask. Optionally, a netmask can be specified in single integer or dotted-quad notation. Sets the pool name for the current operation. Sets the role to use with this pool. Only ipf, auth, and count are accepted as arguments to this option. Sets the hashing seed to the number specified. Use only with hash-type pools. Sets the type of pool being defined. Must be one of tree, hash, or group-map. Sets the hash table size to the number specified. Use only with hash type pools.

-m <name> -o <role> -S <seed> -t <type> -z <size>

100

HP-UX IPFilter Utilities

1 1 HP-UX IPFilter and ICMP

This chapter describes how to use HP-UX IPFilter to filter ICMP (ICMPv4) and ICMPv6 Packets. It also describes how to configure ICMP kernel parameters for optimal security. This chapter contains the following sections: Filtering ICMPv4 Packets by Type and Code (icmp-type and code) (page 101) Configuring ICMPv4 Kernel Parameters (page 102) Filtering ICMPv6 Packets by Type and Code (icmpv6type and code) (page 106) Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages (page 107)

1 1.1 Filtering ICMPv4 Packets by Type and Code (icmp-type and code)
You can filter specific types of ICMPv4 (ICMP) traffic using the icmp-type and code keywords. These keywords are useful if you want to block most ICMP traffic to prevent Denial of Service (DoS) attacks, but must allow certain types of ICMP messages in and out of your system. You must specify proto icmp to use the icmp-type and code keywords. A simplified rule syntax is as follows: block|pass in|out [processing_options] proto icmp ip_selector icmp-type type [code code_value] where: processing_options is one or more processing options, such as quick. See Processing Options: Logging Packets, Optimizing Rule Processing, and Specifying Interfaces (page 31). ip_selector is the IP address specification, as defined in Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports (page 28). type is the ICMP type, either the name listed in Table 11-1, or the decimal value. code_value is the decimal value for the ICMP code. For example, if you want to specifically allow echo replies (ping replies) into your system, configure the following rule:
pass in quick proto icmp from any to any icmp-type 0 code 0

Table 1 1-1 ICMP Type and Codes

Type Code icmp-type icmp-code 0 3 0 1 2 3 4 5 6 7 8 0 echorep unreach net-unr host-unr proto-unr port-unr needfrag srcfail net-unk host-unk isolate ECHO REPLY (ping reply) [RFC792] DESTINATION UNREACHABLE network unreachable host unreachable protocol unreachable port unreachable [RFC792] need fragmentation [RFC792] source route failed [RFC792] destination network unknown destination host unknown source host isolated [RFC792] (ping) Meaning

11.1 Filtering ICMPv4 Packets by Type and Code (icmp-type and code)

101

Table 1 1-1 ICMP Type and Codes (continued)

Type Code icmp-type icmp-code 9 10 11 12 13 14 15 4 5 0 net-prohib host-prohib net-tos host-tos filter-prohib host-preced cutoff-preced squench redir network host network & TOS host & TOS 8 0 0 0 11 echo routerad routesol timex ECHO REQUEST (ping request) ROUTER ADVERTISEMENT ROUTER SOLICITATION TIME EXCEEDED TTL=0 during transmit TTL=0 during reassembly 12 13 14 15 16 17 18 0 0 0 0 0 0 paramprob timest timestrep inforeq inforep maskreq maskrep PARAMETER PROBLEM TIMESTAMP REQUEST TIMESTAMP REPLY INFO REQUEST (obsolete) INFO REPLY (obsolete) ADDRESS MASK REQUEST ADDRESS MASK REPLY destination network administratively prohibited [RFC1256] destination host administratively prohibited [RFC1256] network unreachable for TOS [RFC792] host unreachable for TOS [RFC792] prohibited by filtering [RFC1812] host precedence violation [RFC1812] precendence cutoff in effect [RFC1812] SOURCE QUENCH REDIRECT Meaning

The ICMP code names are valid with the return-icmp and return-icmp-as-dest keywords, which send ICMP responses to blocked packets. See return-icmp-as-dest: Responding to Blocked UDP Packets (page 39) for an example.

1 1.2 Configuring ICMPv4 Kernel Parameters

Historically, ICMPv4 (ICMP) messages have been exploited and used in Denial of Service (DoS) attacks. This section describes how to optimize ICMP security by configuring ndd (system network) parameters for ICMP features and by configuring associated IPFilter rules. This section contains information about the following ICMP features:
102

Dead Gateway Detection (ip_ire_gw_probe) (page 103) ICMP Source Quench (ip_send_source_quench) (page 103)

HP-UX IPFilter and ICMP

ICMP Redirects (ip_send_redirects) (page 104) PMTU Discovery (ip_pmtu_strategy) (page 104) ICMP Echo Request Broadcasts (ip_respond_to_echo_broadcast) (page 105)

This section also describes how to use ndd to set the ICMP parameter values (Using ndd to Configure ICMPv4 Kernel Parameters (page 105)).

1 1.2.1 Dead Gateway Detection (ip_ire_gw_probe)

The ip_ire_gw_probe parameter enables or disables dead (non-operational) gateway detection. This feature is useful in topologies with redundant gateways. If you do not have redundant gateways, HP recommends that you disable this feature. By default, this feature is enabled.
Parameter Name ip_ire_gw_probe Valid Values 0 (disable) 1 (enable) Default Value 1

NOTE: Note: If your topology matches the following conditions, your system may mark gateways "down" and the system will lose connectivity to remote systems through those gateways. The local system is an HP-UX 11i v1 system without patch PHNE_35351 or later installed, or an HP-UX 11i v2 system without patch PHNE_35765 or later installed. The ip_ire_gw_probe feature is enabled (ip_ire_gw_probe is set to 1). IPFilter is configured to block ICMP echo requests and echo reply messages to or from the gateways. This includes IPFilter configurations that block all messages from a subnet address that matches the gateway addresses.

1 1.2.1.1 IPFilter Configuration

When this feature is enabled, you must configure IPFilter to allow ICMP Echo Request (type 8, code 0) and Echo Reply messages (type 0, code 0) to pass to and from the gateways. In the following example, the router addresses are 10.10.10.10 and 10.20.20.20:
pass out quick proto icmp from any to 10.10.10.10 icmp-type echo pass in quick proto icmp from 10.10.10.10 to any icmp-type echorep pass out quick proto icmp from any to 10.20.20.20 icmp-type echo pass in quick proto icmp from 10.20.20.20 to any icmp-type echorep

1 1.2.2 ICMP Source Quench (ip_send_source_quench)

The ip_send_source_quench parameter enables or disables the ICMP source quench feature. If you enable this feature, the system will send ICMP source quench messages if the inbound buffer of an upper-layer module (TCP or UDP) is full. HP recommends that you disable this feature in security-conscious topologies. Attackers can exploit systems that send ICMP source quench messages to discover the IP addresses of systems on a network.
Parameter Name ip_send_source_quench Valid Values 0 (disable) 1 (enable) Default Value 1

1 1.2.2.1 IPFilter Configuration

If you want to use the ICMP send source quench feature, configure IPFilter to allow outbound ICMP source quench packets (type 4). For example:
11.2 Configuring ICMPv4 Kernel Parameters 103

pass out quick proto icmp from any to any icmp-type 4

1 1.2.3 ICMP Redirects (ip_send_redirects)

The ip_send_redirects parameter enables or disables ICMP redirect transmissions. ICMP redirects are generally used by hosts to communicate alternate or optimal routes. If a forged ICMP redirect message is processed by a host, its routing table can be compromised and it may route subsequent traffic through an unsafe route. A forged ICMP redirect message can also cause a Denial of Service (DoS) attack by redirecting packets to nonexistent routers. This feature is useful only on systems that are IP routers. If the local system is not an IP router, HP recommends that you disable this feature.
Parameter Name ip_send_redirects Valid Values 0 (disable) 1 (enable) Default Value 1

1 1.2.3.1 IPFilter Configuration

HP recommends that you configure IPFilter to process ICMP redirect messages as follows: End systems On end systems, block all inbound ICMP redirect messages without logging them. Block all outbound ICMP redirect messages (end systems have no need to send ICMP redirect messages). For example:
block in quick proto icmp from any to any icmp-type redir block out quick proto icmp from any to any icmp-type redir

Routers On IP routers, allow outbound ICMP redirect messages (type 5) to pass. For example:
pass out quick proto icmp from any to any icmp-type redir

1 1.2.4 PMTU Discovery (ip_pmtu_strategy)

The ip_pmtu_strategy parameter enables or disables path maximum transmission unit (PMTU) discovery. When PMTU discovery is disabled, IP sends packets with the "Don't Fragment" bit cleared. This prevents intermediate nodes from fragmenting IP packets, and IP generally selects conservative (small) values for the MTU, which can decrease IP throughput. If PMTU discovery is enabled (the default setting), you must configure IPFilter to allow ICMP Destination Unreachable, Fragmentation Needed (type 3, code 4) messages.
Parameter Name ip_pmtu_strategy Valid Values 0 (disable and use 576 bytes as the PMTU) 1 (enable) 2 (deprecated) 3 (disable and use the link-local MTU as the PMTU) Default Value 1

1 1.2.4.1 IPFilter Configuration

If PMTU discovery is enabled (the default setting), you must configure IPFilter to allow ICMP Destination Unreachable, Fragmentation Needed (type 3, code 4) messages. For example:
pass in quick proto icmp from any to 10.1.1.1 icmp-type 3 code 4

If you configure IPFilter to block ICMP Fragmentation Needed messages, you must disable path MTU discovery to ensure full connectivity to remote nodes not attached to a local link. In this
104 HP-UX IPFilter and ICMP

case, HP recommends that you set ip_pmtu_strategy to 3 if this value is supported on your system, or to 0 if it is not supported. Note that for IPv4, the link-local MTU can be as low as 68 bytes. Setting ip_pmtu_strategy to 0 or 3 can significantly decrease IP throughput.

1 1.2.5 ICMP Echo Request Broadcasts (ip_respond_to_echo_broadcast)

A ping message (ICMP echo request) to a broadcast address solicits responses from multiple systems and can generate a lot of network traffic. In security-conscious environments, HP recommends that you disable responses to broadcast echo requests.
Parameter Name ip_respond_to_echo_broadcast Valid Values 0 (disable) 1 (enable) Default Value 1

1 1.2.6 Using ndd to Configure ICMPv4 Kernel Parameters

The ICMPv4 (ICMP) kernel tunable parameters in this chapter are all configured using the ndd utility. Parameter values that you set by running ndd are not retained when the system reboots. You can configure parameter values in the ndd startup file, /etc/rc.config.d/nddconf, so ndd will set the configured values each time the system starts up. To add an ICMP configuration value to /etc/rc.config.d/nddconf, specify ip as the transport name and use the following syntax:
TRANSPORT_NAME[index]=ip NDD_NAME[index]=parameter_name NDD_VALUE[index]=value

where: index is the index number for the entry in the nddconf file. Index numbers must start from 0 and increment sequentially. parameter_name is the name of the ICMP parameter, such as ip_ire_gw_probe. value is the parameter value. For example:
TRANSPORT_NAME[0]=ip NDD_NAME[0]=ip_ire_gw_probe NDD_VALUE[0]=0

To configure a value for an ICMP parameters using the ndd command, specify /dev/ip as the network device and use the following syntax: ndd -set /dev/ip parameter_name value For example: ndd -set /dev/ip ip_ire_gw_probe 0 Use the following syntax to query the value of a kernel tunable: ndd -get /dev/ip parameter_name For example: ndd -get /dev/ip ip_ire_gw_probe

11.2 Configuring ICMPv4 Kernel Parameters

105

1 1.3 Filtering ICMPv6 Packets by Type and Code (icmpv6type and code)
You can filter specific types of ICMPv6 traffic using the icmpv6-type and code keywords. You must specify proto icmpv6 to use the icmpv6-type and code keywords. A simplified rule syntax is as follows: block|pass in|out [processing_options] proto icmpv6 icmpv6-type type_value [code code_value] where: processing_options is one or more processing options, such as quick. See Processing Options: Logging Packets, Optimizing Rule Processing, and Specifying Interfaces (page 31). ip_selector is the IP address specification using the keyword all, or the from and to keywords and IPv6 addresses. See Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports (page 28). type_value is the decimal value for the ICMPv6 type. Note that by default, HP-UX IPFilter allows ICMPv6 Router Discovery and Neighbor Discovery to bypass IPFilter rulesets and always pass in and out of the system. See Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages (page 107) for more information. code_value is the decimal value for the ICMPv6 code. The IANA list of assigned ICMPv6 type numbers option numbers contains the registered ICMPv6 type and code values and the documents that define these values. This list is available at the following URL: http://www.iana.org/assignments/icmpv6-parameters For example, to block inbound Node Information Queries (type 139) to your system (2001:db8::1), create the following rule:
pass in quick proto icmp from any to 2001:db8::1 icmpv6-type 139

ip_selector

106

HP-UX IPFilter and ICMP

1 1.4 Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages

By default, HP-UX IPFilter allows ICMPv6 Router Discovery and Neighbor Discovery messages to bypass (pass through) IPFilter rulesets and always pass in and out of the system. These messages are: Router Solicitation (type 133) Router Advertisement (type 134) Neighbor Solicitation (type 135) Neighbor Advertisement (type 136) Neighbor Discovery Redirect (type 137) The kernel tunable parameter ipf_icmp6_passthru specifies whether or not IPFilter allows Router Discovery and Neighbor Discovery messages to bypass the IPFilter rulesets.
Parameter Name ipf_icmp6_passthru Valid Values Default Value

0 (Router Discovery and Neighbor 0 Discovery messages bypass IPFilter) 1 (IPFilter filters Router Discovery and Neighbor Discovery messages)

1 1.4.1 Configuring ipf_icmp6_passthru

HP strongly recommends that you use the default setting for ipf_icmp6_passthru. However, if you want to change the setting, use one of the procedures in the sections that follow.

1 1.4.1.1 Configuring ipf_icmp6_passthru on HP-UX 1 1i v2 and HP-UX 1 1i v3

On HP-UX 11i v2 and HP-UX 11i v3 systems, use the kctune utility to set the value of ipf_icmp6_passthru as follows:
kctune ipf_icmp6_passthru=value

where: value is 0 (bypass) or 1 (filter).

1 1.4.1.2 Configuring ipf_icmp6_passthru on HP-UX 1 1i v1

On HP-UX 11i v1 systems, use the ndd utility to set the value of ipf_icmp6_passthru as follows:
ndd -set /dev/pfil ipf_icmp6_passthru value

where: value is 0 (bypass) or 1 (filter). NOTE: You cannot configure ipf_icmp6_passthru in the ndd configuration file read at system startup time (/etc/rc.config.d/nddconf). When the system starts up, the value for ipf_icmp6_passthru is reset its default value (1).

11.4 Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages

107

108

12 HP-UX IPFilter and FTP

This chapter describes how to filter FTP services. It contains the following sections: FTP Basics (page 109) WU-FTPD on HP-UX (page 109) Running an FTP Server (page 110) Running an FTP Client (page 110) CAUTION: NAT and FTP are incompatible. If you are using FTP on your IPFilter system, do not use NAT rules.

12.1 FTP Basics

The File Transfer Protocol (FTP) is a user-level protocol for transferring files between host computers. An FTP session involves two separate connections: Control connection 1. The server listens for client connections on port 21. 2. The client opens a connection to the server port 21 on a client port above 1023. 3. The client uses this connection to send commands to, and receive replies from, the server. This connection lasts through the FTP session. Data connection The data connection is used for transferring data between the client and server. A new data connection is opened for each FTP command. The way the data connection is created depends on the type of FTP sessionactive or passive. In active FTP, the client actively opens a connection to the FTP server at port 21. It uses a port number in the dynamic port range (by default, a number greater than 1023) as its port for the control connection. The client then opens a new port (passive open) as its data port and sends this port number across to the server using the PORT command. The server then opens a data connection (active open) to the data port specified in the PORT command of the client. The server uses port 20 as its data connection port. In passive FTP, the control connection is established the same as it is in active FTP. In passive FTP, to establish a data connection the server opens an arbitrary data port in the dynamic port range . It uses the FTP PASV command to send the data port number to the client. The client connects to the port specified by the PASV command and uses a different port in the dynamic port range as its data port.

12.2 WU-FTPD on HP-UX

The HP implementation of the FTP daemon for HP-UX 11i core networking is based on the WU-FTPD daemon, version 2.4. Additional security correction has been added to WU-FTPD 2.6.1. HP recommends upgrading to WU-FTPD 2.6.1 for enhanced security. For systems on HP-UX 11.0, you can upgrade to WU-FTPD 2.6.1 from either the legacy FTP version that is delivered with the core networking products on 11.0, or from WU-FTPD 2.4, which has been made available as the patch PHNE_21936. WU-FTPD 2.6.1 is downloadable from the HP Software Depot for systems running HP-UX 11.0 or HP-UX 11i v1. The URL is http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/ displayProductInfo.pl?productNumber=3DWUFTPD26.
12.1 FTP Basics 109

WU-FTPD 2.6.1 is a core product on HP-UX 11i v2.

12.3 Running an FTP Server

This section describes active FTP and passive FTP server setup.

12.3.1 Active FTP

FTP Server port 21 (control port) port 20 (data port) Direction of Connection Initiated <-------------------------------> FTP Client any port 1024 or higher any port 1024 or higher

On an FTP server using active FTP, configure IPFilter rules to allow control connections in and data connections out. For example:
pass in quick proto tcp from any port > 1023 to server-ip port = 21 flags S keep state pass out quick proto tcp from any port = 20 to any port > 1023 flags S keep state block in from any to any block out from any to any

12.3.2 Passive FTP

FTP Server port 21 (control port) any port 1024 or higher (data port) Direction of Connection Initiated <---------------<---------------FTP Client any port 1024 or higher any port 1024 or higher

To use IPFilter to protect passive FTP sessions, you must limit the port range your system can use for FTP access. For example, you can allocate ports 15001-15500 as FTP ports and only open up that range of your firewall. In WU-FTPD, you use the passive portsdirective in the /etc/ftpaccess configuration file to designate the ports, as follows:
passive ports server_ip 15001 15500

See the ftpaccess(4) manpage for details on WU-FTPD configuration. Configure the following IPFilter rules to let the passive FTP traffic pass:
pass in quick proto tcp from any port > 1023 to server_ip port = 21 flags S keep state pass in quick proto tcp from any port > 1023 to server_ip port 15000 ><15501 flags S keep state block in from any to any block out from any to any

12.4 Running an FTP Client

As with FTP servers, there are two types of FTP client transfers, active and passive.

12.4.1 Active FTP

FTP Server port 21 (control port) port 20 (data port) Direction of Connection Initiated <-------------------------------> FTP Client any port 1024 or higher any port 1024 or higher

To let an FTP client open an active FTP session, configure IPFilter rules to allow control connections out and data connections in.
110 HP-UX IPFilter and FTP

pass out quick proto tcp from client_ip port > 1023 to any port = 21 flags S keep state pass in quick proto tcp from any port 20 to client_ip port > 1023 flags S keep state block in from any to any block out from any to any

NOTE: FTP Proxy is not supported by HP. For a complete list of unsupported utilities and commands, see Unsupported Utilities (page 128).

12.4.2 Passive FTP

FTP Server port 21 (control port) any port 1024 or higher (data port) Direction of Connection Initiated <---------------<---------------FTP Client any port 1024 or higher any port 1024 or higher

To let an FTP client open a passive FTP session, configure IPFilter to allow both the control and data connections out. Use the following ruleset for client-side, passive FTP:
pass out quick pass out quick block in from block out from proto tcp from client_ip port > 1023 to any port = 21 flags S keep state proto tcp from client_ip port > 1023 to any port > 1023 flags S keep state any to any any to any

TIP: For stronger security, configure IPFilter to allow only active FTP connections from FTP servers.

12.4 Running an FTP Client

111

112

13 HP-UX IPFilter and NFS and RPC

This chapter describes the use of NFS and RPC with IPFilter. It contains the following sections: Introduction (page 113) Configuring NFS to Use Fixed Ports (page 113) Using the rpc.ipfboot Script to Update IPFilter Rules (page 114)

13.1 Introduction
The NFS service uses multiple daemons. The NFS daemon, nfsd, listens for requests on the static (fixed) TCP and UDP port number 2049. By default, the auxiliary daemons used for the NFS servicesrpc.lockd (lockd), rpc.mountd (mountd), and rpc.statd (statd)listen for service requests on dynamic port numbers. These daemons use the Remote Procedure Call (RPC) protocol and register their port numbers with the port mapper daemon (rpc.portmap, or portmap) which uses the static port number 111. Clients send requests to the portmap daemon to get the dynamic port number of the service they want to access. There are two methods to use IPFilter to process packets for the NFS auxiliary daemons: 1. 2. Configure NFS to use static port numbers for the auxiliary daemons. You can then create IPFilter rules for these port numbers. See Configuring NFS to Use Fixed Ports (page 113). Use the script /etc/opt/ipf/rpc.ipf to query the portmap daemon and update IPFilter rules with the dynamic port numbers. You can use this procedure for any service that uses the RPC portmap mechanism. See Using the rpc.ipfboot Script to Update IPFilter Rules (page 114).

13.2 Configuring NFS to Use Fixed Ports

You can configure NFS to use static port numbers for the lockd, mountd, and statd daemons on the following systems: HP-UX 11.31 systems HP-UX 11.23 systems with the NFS patch PHNE_34550 or a patch that supersedes it HP-UX 11.11 systems with the NFS patch PHNE_34662 or a patch that supersedes it

On HP-UX 11.31 systems, the lockd daemon uses the static UDP port 4045 by default. Use the following procedure to configure the fixed port numbers for the auxiliary NFS daemons: 1. Add the following entries to the end of the /etc/rc.config.d/nfsconf file:
STATD_PORT=port_number MOUNTD_PORT=port_number

where port_number is the number of the port you want the daemon to use. This must be a port that is not already in use. HP recommends that you use a number between 49152 and 65536, the range reserved for dynamic or private ports by the IANA. On HP-UX 11.11 and HP-UX 11.23 systems, you must also add the following entry for lockd:
LOCKD_PORT=port_number

HP recommends that you use the value 4045 for the lockd daemon port to match the port number used by the HP-UX 11.31 version of the lockd daemon. 2. Stop and restart the NFS client and server services in a manner consistent with your operating procedures. For example, you can stop the NFS services by running the NFS control scripts with the following commands:
# /sbin/init.d nfs.client stop # /sbin/init.d nfs.server stop

You can also restart the NFS services with the following commands:
13.1 Introduction 113

# /sbin/init.d nfs.client start # /sbin/init.d nfs.server start

3.

(Optional) Enter the following command to verify the ports used by the NFS auxiliary daemons:
# rpcinfo -p

13.3 Using the rpc.ipfboot Script to Update IPFilter Rules

The /etc/opt/ipf/rpc.ipf/rpc.ipfboot script to queries the port mapper and updates IPFilter rules files with the appropriate port numbers. This script is useful if you cannot run the auxiliary NFS daemons using fixed ports as described in the previous section, or if you want IPFilter to process packets for other daemons that use the RPC mechanism. NOTE: The files and scripts used in this procedure serve as basic building blocks for use at startup time. All files are installed in /etc/opt/ipf/rpc.ipf. The configuration files must be present in the appropriate directories for the scripts to work correctly. To use the /etc/opt/ipf/rpc.ipf/rpc.ipfboot script: 1. Copy the sample file to /etc/rc.config.d/rpc_ipfconf cp rpc_ipfconf.sample /etc/rc.config.d/rpc_ipfconf Edit the file as needed. 2. Create the rpc.ipf directory and change to that directory. mkdir /etc/opt/ipf/rpc.ipf cd /etc/opt/ipf/rpc.ipf 3. 4. Create an empty RPC rules file. touch /etc/opt/ipf/rpc.ipf/rpc.rules Start the script configuration. ./rpc.ipfboot start

13.3.1 Rules Files

This section gives details on the two rules files that contain the IPFilter rules for RPC. The two rules files are: The IPFilter rules file specified in $IPF_CONF in /etc/rc.config.d/ipfconf The IPFilter RPC rules file specified in $RPC_RULES_FILE specified in /etc/rc.config.d/ rpc_ipfconf NOTE: See the following section for a description of /etc/rc.config.d/rpc_ipfconf. A sample file is also provided. To incorporate the dynamic ports used by the RPC processes, the administrator should decide the position from which RPC rule should be configured by setting RPC_RULE_POSITION to the desired value. For example: RPC_RULE_POSITION=5 The RPC rules will then be added from the 5th position onwards. If there are 10 RPC rules, they will be inserted at positions 5 to 14. The position must be chosen carefully. If there are only two rules present, then RPC_RULE_POSITION must be 1,2 or 3 [RPC_RULE_POSITION = current_#_of_rules]. The Original rules file specified in /etc/rc.config.d/ipfconf containing other rules is not modified.

114

HP-UX IPFilter and NFS and RPC

By default, all RPC rules are configured as the first rules, for example, RPC_RULE_POSITION=1. The RPC rules are well defined in terms of IP addresses and ports and will have unique matches and, since they are quick rules, they should be at top.

13.3.2 RPC Rules Configuration File

This file specifies details based on which IPFilter RPC rules will be generated. /etc/opt/ipf/ rpc.ipf/rpc_ipfconf.sample is provided as an example. The /etc/opt/ipf/rpc.ipf/rpc_ipfconf file contains the client list and program list. The sample file grants access to the program numbers listed from the IP addresses and IP subnets listed in the client list. The example shown in the sample file lists the program numbers used by an NFS server, rpc.mountd, rpc.statd, rpc.lockd, and nfsd. This file also has the following declared: ADD_RPC_IPFILTER_RULES=1 Set this to 1 to configure RPC IPFilter rules. RPC_RULE_POSITION=1 Must be 1 or greater, as noted in the previous section. RPC_RULES_FILE=./rpc.rules This is the path to the RPC rules file, which contains the rules to be added or deleted.

13.3 Using the rpc.ipfboot Script to Update IPFilter Rules

115

116

14 HP-UX IPFilter and IPSec

This chapter describes how HP-UX IPFilter and HP-UX IPSec work together. It contains the following sections: IPFilter and IPSec Basics (page 117) IPSec UDP Negotiation (page 117) When Traffic Appears to Be Blocked (page 118) Allowing Protocol 50 and Protocol 51 Traffic (page 119) IPSec Gateways (page 120)

14.1 IPFilter and IPSec Basics

IPSec and IPFilter will not panic or corrupt each other. However, there are situations in which one product might block traffic for the other. The following figure shows the positions of IPFilter and IPSec in the network stack: Figure 14-1 IPFilter and IPSec
IPSec

IPFilter

IPFilter, which is below IPSec in the networking stack, filters network packets before they reach IPSec. You can have both IPFilter and IPSec configured and running on a system without them negatively affecting each other. Figure 14-2 Scenario One
B <---------------> A <-----------------> C (IPSec) (IPFilter) (IPSec)

In Scenario One, you have IPFilter and IPSec on system A with IPFilter blocking packets from system B and IPSec encrypting packets from system C. When a packet arrives at system A, IPFilter checks to see if it is from system B, and, if so, blocks the packet. If not, the packet continues up the stack to IPSec. IPSec checks to see if it is from system C. If so, the packet arrives encrypted. No overlap is in the configurations of IPFilter and IPSec in this network topology, so there are no conflicts in Scenario One. CAUTION: HP-UX IPSec does not support NAT traversal. If you are using HP-UX IPFilter with HP-UX IPSec, do not use NAT functionality. However, it is possible that IPFilter and NAT can be used in network configurations containing other vendors IPSec products that do support NAT traversal.

14.2 IPSec UDP Negotiation

You can configure IPSec and IPFilter so that there is some overlap in the configurations. However, you must be sure the overlapping configurations do not block each other.
14.1 IPFilter and IPSec Basics 117

Before exchanging IPSec-encrypted or authenticated packets, IPSec negotiates security parameters using the Internet Key Exchange (IKE) protocol. The IKE protocol exchanges messages using UDP protocol port 500, or port 4500 if IPSec NAT traversal is used. If the IPFilter configuration is so broad that it blocks all UDP traffic, IPSec cannot complete IKE negotiations and packets that are configured to be secured by IPSec are dropped. The IPSec log on the initiating side will show the error MM negotiation timeout or Phase 1 negotiation timeout. To enable IPSec to complete IKE negotiations, configure IPFilter to allow the IKE negotiation packets through. Figure 14-3 Scenario Two
A 10.10.10.10 B 15.15.15.15

IPSec <---------------> TCP <-----------------> IPSec IPFilter -----UDP-----

In Scenario Two, IPFilter is configured to block UDP traffic on system A, you want all TCP traffic to pass through . From system B on the network, you want all TCP traffic encrypted. System A has IP address 10.10.10.10 and system B has IP address 15.15.15.15. You configure IPSec on each system to encrypt packets between two systems. When TCP traffic is initiated from A to B or from B to A, IPSec first negotiates security parameters using the IKE protocol (UDP port 500). You must configure IPFilter on system A to pass IKE packets. To do so, add the following rules to your configuration:
pass in quick proto UDP from 15.15.15.15 port = 500 to 10.10.10.10 port = 500 pass out quick proto UDP from 10.10.10.10 port = 500 to 15.15.15.15 port = 500 block in proto UDP block out proto UDP

These rules allow IKE packets to pass correctly. NOTE: You must configure IPFilter to pass traffic both in and out on UDP port 500 for IPSec to work properly. If IPFilter is used with IPSec requiring the NAT traversal function, UDP port 4500 must be set to pass for in and out traffic.

14.3 When Traffic Appears to Be Blocked

In the following scenario there is overlap in the configurations of IPFilter and IPSec. To get this negotiation through, you must configure IPFilter rules to let TCP traffic through. Figure 14-4 Scenario Three
A 10.10.10.10 B 15.15.15.15

IPSec <---------------> TCP <-----------------> IPSec IPFilter ---TCP-----

In Scenario Three, IPSec is configured to encrypt TCP traffic between system A and system B and IPFilter is configured to block all TCP traffic with the following rules:
block in proto TCP block out proto TCP

118

HP-UX IPFilter and IPSec

14.4 Allowing Protocol 50 and Protocol 51 Traffic

IPSec uses Encapsulating Security Payload (ESP) to provide data confidentiality and Authentication Header (AH) to provide data integrity at the IP layer. Depending on a users IPSec traffic policy configuration, IPSec inserts ESP, AH, or both as protocol headers into an IP datagram that immediately follows an IP header. The protocol field of that IP header will be 50 (ESP) or 51 (AH) to indicate the next protocol. Figure 14-5 Packet with Unencrypted TCP Data
IP header protocol # = 6 TCP header Data

Figure 14-6 Packet with IPSec-Encrypted TCP Data

IP header protocol # = 50 ESP header Encrypted

IPFilter never sees the TCP packets between system A and system B with a protocol number of 6. These packets are encrypted (or wrapped) in a packet that has a protocol number of 50. If you configure IPFilter to block packets with protocol number 6, it lets protocol number 50 pass through. IPSec takes apart the packet and decrypt the TCP data. If the IPFilter configuration is so broad that it blocks protocol 50 or protocol 51 traffic, then IPSec traffic will not get through. Figure 14-7 Scenario Four
A 10.10.10.10 B 15.15.15.15

IPSec <---------------> TCP <-----------------> IPSec IPFilter -----block !TCP-----

In Scenario Four, IPSec is configured to encrypt TCP traffic between the two systems and IPFilter is configured to block non-TCP traffic. IPFilter rules are also configured to let UDP/500 traffic pass on system B.
# Allow IKE to/from system B pass in quick proto UDP from 15.15.15.15 port 500 to 10.10.10.10 port = 500 pass out quick proto UDP from 10.10.10.10 port 500 to 15.15.15.15 port = 500 # Let in encrypted IPSec traffic pass in quick proto 50 from 15.15.15.15 to 10.10.10.10 pass out quick proto 50 from 10.10.10.10 to 15.15.15.15 # Allow TCP traffic to/from anywhere pass in quick proto TCP pass out quick proto TCP # Block all other traffic to/from anywhere block in from any to any block out from any to any

14.4 Allowing Protocol 50 and Protocol 51 Traffic

119

NOTE: If IPSec is configured to use AH rather than ESP, you must configure IPFilter to let protocol 51 traffic pass. If IPSec uses nested AH and ESP, IPFilter can be configured to let only protocol 51 (ah) traffic pass.

14.5 IPSec Gateways

You can configure IPSec to encrypt and authenticate traffic to a gateway between two end hosts. A configuration that encrypts IPSec packets to a gateway is called an IPSec tunnel. IPFilter can coexist with IPSec tunnels without conflict. However, you must configure IPFilter to allow IPSec traffic with the gateway instead of the end node. The IPFilter rules for the UDP/500 and protocol 50/51 traffic must be passed to and from the gateway IP address rather than the end node IP address.

120

HP-UX IPFilter and IPSec

15 HP-UX IPFilter and Serviceguard

This chapter describes configuration procedures for HP-UX IPFilter used in a Serviceguard environment. It contains the following sections for using HP-UX IPFilter with Serviceguard: Enabling or Disabling IPFilter (page 121) Local Failover (page 121) Remote Failover (page 122) Filtering on a Package IP Address (page 122) Mandatory Rules (page 122) DCA Remote Failover (page 126)

15.1 Using HP-UX IPFilter with Serviceguard

HP-UX IPFilter supports local failover in a Serviceguard environment. CAUTION: NAT functionality is not supported with Serviceguard.

15.1.1 Enabling or Disabling IPFilter

CAUTION: HP recommends that you enable or disable IPFilter when interrupting network connectivity is not disruptive. HP recommends that you do not enable or disable HP-UX IPFilter when critical network applications are running. Disabling or enabling IPFilter using briefly brings down all IP interfaces, then brings up only the IP interfaces configured in the /etc/rc.config.d/netconf and /etc/rc.config.d/ netconf-ipv6 files. IP addresses not configured in the netconf or netconf-ipv6 file, such as Serviceguard relocatable IP addresses, are not re-enabled. Enabling or disabling IPFilter causes the system to briefly lose network connectivity. If a system has several IP interfaces or there is heavy network traffic, the time required to re-establish network connectivity might be interpreted as a network or card failure. For example, Serviceguard might interpret a network interruption as a card failure, which can cause it to reform the cluster.

15.1.2 Local Failover

NOTE: See the Serviceguard documentation for information on configuring a local failover system in Serviceguard. IPFilter local failover is transparent to users. Network sessions are not disrupted during failover or failback. You do not need to configure any additional rules in IPFilter. When an interface fails over, the HP-UX IPFilter rules that specify interface names are automatically changed. For example, a node in a Serviceguard cluster has a primary interface named lan0 and a standby interface named lan1. The following rule is configured for lan0:
pass in on lan0 proto tcp from any to any port = telnet

Upon failover, the rule is automatically modified to:

pass in on lan1 proto tcp from any to any port = telnet

The rule will be changed back automatically on failback.

15.1 Using HP-UX IPFilter with Serviceguard

121

All rules that filter on interface names are changed at failover and failback in both the active ruleset and the inactive ruleset. In addition, logging reflects the changes; the standby interface name will appear in logs and reports when it is in use.

15.1.3 Remote Failover

HP-UX IPFilter is a system firewall and as such should be installed on end systems. Connections to an IPFilter system that are lost during a remote failover must be reinitiated. Install and configure HP-UX IPFilter on each node of a Serviceguard cluster that must be protected. The IPFilter configuration for the primary node might be different from the configuration for the backup nodes. For example, the backup node might be multihomed and require a different ruleset. Also, rules could be configured to filter on the static IP address of the receiving node that would be different for each node in the cluster. Rules that filter on interface names will also be different on different nodes in a cluster.

15.1.3.1 Filtering on a Package IP Address

HP-UX IPFilter can filter on a package IP address. The package IP address is an IP address that corresponds to a logical network interface. For example, a telnet connection is made to the primary cluster node with a package IP address of 17.13.24.105. You want to configure IPFilter to let telnet traffic through. Configure the following rule for incoming telnet connections made to the telnet package: pass in proto tcp from any to 17.13.24.105 flags S keep state You can replace 17.13.24.105 with the package name in this rule if the package has been configured properly and has a DNS entry. Configure this rule on the backup nodes as well. This ensures that when the telnet package fails to a backup, there is a rule on the backup that lets telnet connections pass through as required. This type of configuration can be used with any package.

15.1.3.2 Mandatory Rules

Each node in a Serviceguard cluster has specific rules that must be configured. These rules ensure that: Normal remote failovers are not disrupted. No false remote failovers occur because traffic is blocked by IPFilter that should not be blocked. Intra-Cluster Communication Quorum Server Remote Command Execution Cluster Object Manager Serviceguard Manager
# High Availability (HA) Quorum Server # HA LVM configuration # High Availability (HA) Cluster heartbeat # High Availability (HA) Cluster heartbeat # HA Cluster General Services # HA Cluster TCP configuration # HA Cluster UDP configuration # HA Cluster TCP probe # HA Cluster UDP probe

The classes of mandatory rules cover:

Do not block traffic for the following ports:

hacl-qs 1238/tcp clvm-cfg 1476/tcp hacl-hb 5300/tcp hacl-hb 5300/udp hacl-gs 5301/tcp hacl-cfg 5302/tcp hacl-cfg 5302/udp hacl-probe 5303/tcp hacl-probe 5303/udp
122 HP-UX IPFilter and Serviceguard

hacl-local 5304/tcp hacl-test 5305/tcp hacl-dlm 5408/tcp hacl-poll 5315/ tcp

# HA Cluster commands # HA Cluster test # HA Cluster distributed lock manager #HA Cluster TCP polling cmappserver for hpvm

NOTE: This list of HA services is not exhaustive. In addition, Serviceguard also uses dynamic ports (typically in the 4915265535 range) for some cluster services. If you have adjusted the dynamic port range using kernel tunable parameters, alter your rules accordingly. This list does not include all HA applications (such as Continental Cluster). New HA applications might be developed that use port numbers in addition to the listed numbers. You must add new rules as appropriate to ensure that all HA applications run properly. The current list of ports used by Serviceguard are documented in the Serviceguard Release Notes. 15.1.3.2.1 Rules for Intra-Cluster Communication To ensure proper operation of your Serviceguard cluster, you must configure IPFilter rules for each configured Serviceguard heartbeat subnet to allow intra-cluster communication. There are two methods to do this: Configure rules that allow all intra-cluster packets Configure rules that allow intra-cluster packets with specific protocols and ports

15.1.3.2.1.1 Configuring Rules to Allow All Intra-Cluster Packets

For a simplified HP-UX IPFilter configuration, add the following rules to allow all intra-cluster packets:
pass in quick from cluster_nodes to cluster_nodes pass out quick from cluster_nodes to cluster_nodes 15.1.3.2.1.2 Configuring Rules to Allow Specific Intra-Cluster Packets

For more restrictive HP-UX IPFilter configurations, use the following rules to allow only packets for the required cluster services to pass through. The cluster_nodes address in these rules is the IP subnet address for all nodes in the cluster, including the local node.
pass in quick proto tcp from cluster_nodes to cluster_nodes port 5299 >< 5305 flags S keep state

pass in quick proto udp from cluster_nodes to cluster_nodes port = 5300 keep state pass in quick proto udp from cluster_nodes to cluster_nodes port = 5302 keep state
pass in quick proto tcp from cluster_nodes to cluster_nodes port = 5408 flags S keep state pass in quick proto tcp from cluster_nodes to cluster_nodes port 49151><65536 keep state pass in quick proto udp from cluster_nodes to cluster_nodes port 49151><65536 keep state
pass out quick proto tcp from cluster_nodes to cluster_nodes port 5299 >< 5305 flags S keep state

pass out quick proto udp from cluster_nodes to cluster_nodes port = 5300 keep state pass out quick proto udp from cluster_nodes to cluster_nodes port = 5302 keep state
pass out quick proto tcp from cluster_nodes to cluster_nodes port = 5408 flags S keep state pass out quick proto tcp from cluster_nodes to cluster_nodes port 49151><65536 keep state pass out quick proto udp from cluster_nodes to cluster_nodes port 49151><65536 keep state

pass in quick proto udp from cluster_nodes to cluster_nodes port = 9 keep state pass out quick proto udp from cluster_nodes to cluster_nodes port = 9 keep state

If you are using the Cluster SNMP Agent Daemon (cmsnmpd), configure the following rules:
# Allow cmsnmpd to send and receive traps between cluster nodes pass out quick proto udp from cluster_nodes to cluster_nodes port = snmp-trap keep state pass in quick proto udp from cluster_nodes to cluster_nodes port = snmp-trap keep state # Allow cmsnmpd to send and receive snmpGet, snmpSet between cluster nodes pass in quick proto udp from cluster_nodes to cluster_nodes port = snmp keep state pass out quick proto udp from cluster_nodes to cluster_nodes port = snmp keep state

If you are using package IP monitoring, configure the following rules:

15.1 Using HP-UX IPFilter with Serviceguard

123

# Allow ping incoming connections for package ip monitoring pass in quick proto icmp from cluster_nodes to cluster_nodes icmp-type 8 pass out quick proto icmp from cluster_nodes to cluster_nodes icmp-type 8

If you are using cmappserver, configure the following rules:

# Allow hacl-poll for HA Cluster TCP polling (cmappserver for hpvm or APPSERV) pass in quick proto tcp from cluster_nodes to cluster_nodes port = 5315 flag S keep state pass out quick proto tcp from cluster_nodes to cluster_nodes port = 5315 flag S keep state

To enable users on cluster nodes to run the cmscancl command, you must configure rules to allow remote shell packets (TCP port 514).

15.1.3.3 Rules for External Access

The following subsections describe rules to allow packets for external clients and servers used in a Serviceguard environment. These sections provide guidelines only. You might need to modify them to work with your network configuration and the applications you use. Specific applications used within the Serviceguard cluster might require additional ports to be opened. 15.1.3.3.1 WBEM Access Configure the following rules on each cluster node to allow non-secure WBEM client access:
#wbem-http for using Cluster WBEM Agent Daemon (cmwbemd) pass in quick proto tcp from wbem_clients to cluster_nodes port = 5988 flags S keep state pass out quick proto tcp from cluster_nodes port = 5988 to wbem_clients flags S keep state

Configure the following rules to allow secure WBEM client access:

#wbem-https if using Cluster WBEM Agent Daemon (cmwbemd) pass in quick proto tcp from wbem_clients to cluster_nodes port = 5989 flags S keep state pass out quick proto tcp from cluster_nodes port = 5989 to wbem_clients flags S keep state

In the previous rule sets, cluster_nodes is an IP subnet address for are all nodes in the cluster that allow WBEM access and wbem_clients is an IP subnet address for WBEM clients. 15.1.3.3.2 Quorum Server If your Serviceguard configuration uses a Quorum Server, each node in the cluster must have the following rule configured:
pass out quick proto tcp from cluster_nodes to quorum_server port = 1238 flags S keep state

Any node providing Quorum Service for another cluster must have the following rule configured:
pass in quick proto tcp from cluster_nodes to quorum_server port = 1238 flags S keep state

In the previous set of rules, cluster_nodes is the IP subnet address for are all nodes in the cluster utilizing the Quorum Service and quorum_server is the IP address used to access the Serviceguard Quorum Service software. 15.1.3.3.3 Remote Command Execution If you want nodes outside the cluster to execute Serviceguard commands, as specified in the etc/cmcluster/cmclnodelist file, additional rules are required. Each node in the cluster must have the following rules configured:
pass in quick proto tcp from remote_nodes to cluster_nodes port = 5302 flags S keep state

pass in quick proto udp from remote_nodes to cluster_nodes port = 5302 keep state
pass out quick proto tcp from cluster_nodes to remote_node port 49151><65536 keep state pass out quick proto udp from cluster_nodes to remote_node port 49151><65536 keep state

Each remote node must have the following rules configured:

pass in quick proto tcp from cluster_nodes to remote_node port 49151 >< 65536 keep state pass in quick proto udp from cluster_nodes to remote_node port 49151 >< 65536 keep state pass out quick proto tcp from remote_nodes to cluster_nodes port = 5302 flags S keep state

pass out quick proto udp from remote_nodes to cluster_nodes port = 5302 keep state

124

HP-UX IPFilter and Serviceguard

In the previous set of rules, cluster_nodes the IP subnet address for all nodes in the cluster, and remote_nodes are all other nodes outside the cluster that are designated in the cmclnodelist file for remote command access. To enable users on remote nodes to run the cmscancl command, you must also configure rules to allow remote shell packets (TCP port 514). 15.1.3.3.4 Cluster Object Manager If you are using a Cluster Object Manager (COM) on a node outside of the cluster to provide connections to Serviceguard Manager clients, each node in the cluster must have the following rules configured:
pass in quick proto tcp from com_node to cluster_nodes port = 5302 flags S keep state pass in quick proto udp from com_node to cluster_nodes port = 5302 keep state
pass out quick proto tcp from cluster_nodes to com_node port 49151 >< 65536 keep state pass out quick proto udp from cluster_nodes to com_node port 49151 >< 65536 keep state

The node running COM must have the following rules configured:
pass in quick proto tcp from com_client to com_node port = 5302 flags S keep state pass in quick proto tcp from cluster_nodes to com_node port 49151 >< 65536 keep state pass in quick proto udp from cluster_nodes to com_node port 49151 >< 65536 keep state
pass out quick proto tcp from com_node to cluster_nodes port = 5302 flags S keep state

pass out quick proto udp from com_node to cluster_nodes port = 5302 keep state

Each COM client must have the following rules configured:

pass out quick proto tcp from com_client to com_node port = 5303 flags S keep state

In the previous set of rules, cluster_nodes is the subnet address for all nodes in the cluster, com_client are nodes that are clients of COM for Serviceguard Manager or Continental Clusters products, and com_node is the node running the COM. 15.1.3.3.5 Serviceguard Manager Plug-in If you are using the plug-in version of the Serviceguard Manager (supported with Serviceguard versions A.11.18 and later), you must configure rules to allow packets between the Serviceguard nodes and the System Management Homepage (SMH) Management Station. Configure the following rules on each cluster node:
pass pass pass pass in in in in quick quick quick quick proto proto proto proto tcp udp tcp udp from from from from smh_mgmt smh_mgmt smh_mgmt smh_mgmt to to to to cluster_nodes cluster_nodes cluster_nodes cluster_nodes port port port port = = = = 2381 2381 2301 2301 keep keep keep keep state state state state

In the previous set of rules, cluster_nodes is the subnet address for all nodes in the cluster and smh_mgmt is the address of the SMH Management Station. 15.1.3.3.6 Serviceguard Manager Standalone If you are using the standalone version of Serviceguard Manager (supported with Serviceguard versions A.11.14 - A.11.17), you must configure rules to allow all nodes in the cluster exchange SNMP packets with the Serviceguard Manager node. Configure the following rules on each cluster node:
pass in quick proto udp from SGMgr_node to cluster_nodes port = 161 keep state pass out quick proto udp from cluster_nodes to SGMgr_node port = 162 keep state

Each Serviceguard Manager node must have the following rules configured:
pass out quick proto udp from SGMgr_node to cluster_nodes port = 161 keep state pass in quick proto udp from cluster_nodes to SGMgr_node port = 162 keep state

In the previous set of rules, cluster_nodes is the subnet address for all nodes in the cluster, and SGMgr_node is address of the node or nodes running Serviceguard Manager.

15.1 Using HP-UX IPFilter with Serviceguard

125

15.1.3.3.7 Consolidated Log (clog) If you are using the consolidated log package, clog, add the following rules for the configured clog TCP port number:
pass in quick proto tcp from smh_mgmt to cluster_nodes port = clog_tcp keep state pass out quick proto tcp from cluster_nodes to smh_mgmt keep state

In the previous set of rules, cluster_nodes are all nodes in the cluster, smh_mgmt is the address of the SMH Management Station, and clog_tcp is the TCP port configured for the clog package.

15.1.4 DCA Remote Failover

Normally, IPFilter keep state rules are configured with the flags S parameter. This parameter instructs IPFilter to create a TCP state entry only when a SYN packet is parsed. To enable transparent failover between IPFilter DCA nodes, do not use flags S with keep limit rules. If incoming TCP/IP traffic is switched from the active to the standby node, DCA can rebuild the previous IPFilter state table and IPFilter DCA limit tables from the data stream. Without flags S in the keep limit rule, IPFilter creates a new state entry from any TCP/IP packet, not just a SYN packet. A limit table entry is created. Any new connections that exceed the connection limit are rejected. After the state table entry is created for a particular IP address source/destination and TCP port source/destination 4-tuple, further packets of this connection are processed in the state table entry. These packets are not processed by the rules table. For example, when Serviceguard detects that the primary IPFilter DCA gateway has failed, the IP addresses of the primary systems are switched to the standby DCA system. The standby system contains the same set of configured rules as the primary system. Therefore, the standby system can completely rebuild the TCP state tables and limit entries that were previously on the primary system. If a client has active connection to an IPFilter system and is attempting to make new connections when Serviceguard fails over, the new connections replace the existing connections in the limit table entry for the client only if the established connections are not generating traffic.

126

HP-UX IPFilter and Serviceguard

A Product Specifications
This appendix contains the following sections: Configuration Files (page 127) Unsupported Features (page 128) Supported Utilities (page 128) Unsupported Utilities (page 128) Supported and Unsupported Interfaces (page 128)

A.1 Configuration Files

HP-UX IPFilter uses the following configuration files: /sbin/init.d/ipfboot The startup script for the ipf module. /etc/rc.config.d/ipfconf Configuration file for the ipfboot startup script. The information in this file determines how HP-UX IPFilter starts when the system is booted and also specifies the location of the rules files. /etc/opt/ipf/ipf.conf The default IPFilter IPv4 rules file. Any rules present in this file are automatically loaded at bootup by the ipfboot startup script. /etc/opt/ipf/ipnat.conf The default IPFilter NAT rules file. /etc/opt/ipf/ipf6.conf The default IPFilter IPv6 rules file.

A.1.1 Example Configuration Files

HP-UX IPFilter includes example configuration files, installed in the /opt/ipf/examples directory. See Appendix B (page 131) for more information.

A.1 Configuration Files

127

A.2 Unsupported Features

HP-UX IPFilter does not support the following features: Filtering loopback packets. The HP-UX transport stack is optimized so that loopback packets are not passed to any modules below IP, such as IPFilter. Loopback packets include the following: Packets with the destination address in the range 127.0.0.0 - 127.255.255.255 Packets with a destination address that is assigned to a local network interface card Packets sent to or received from the loopback interface (lo0) IPFilter NAT functionality for IPv6 Dynamic Connection Allocation (DCA) functionality for IPv6 on HP-UX 11i v1 Using the Remote Procedure Call (RPC) script /etc/opt/ipf/rpc.ipf with IPv6. This script generates IPFilter rules for RPC ports. Note that you can still configure IPFilter rules for NFS services by configuring NFS to use static port numbers. See Chapter 13 (page 113) for more information.

A.3 Supported Utilities

HP-UX IPFilter supports the following utilities: /sbin/ipf /sbin/ipfstat /opt/ipf/bin/ipmon /opt/ipf/bin/ipftest /sbin/ipnat /opt/ipf/bin/ipfilter (supported on HP-UX 11i v3 only)

A.4 Unsupported Utilities

HP does not support the following public domain IPFilter utilities and commands: Rule keywords dup-to fastroute to Commands ipscan ipsyncs ipsyncm ipfs ipsend ipresend Application proxy

A.5 Supported and Unsupported Interfaces

The following table lists the interfaces supported for the current versions of HP-UX IPFilter. CAUTION: For all versions of HP-UX IPFilter, the unsupported interfaces do not interact with IPFilter. IPFilter does not block or protect the system from traffic on unsupported interfaces. On HP-UX 11i v3 systems, you can use the ipfstat -Q command to list the IP interfaces that are protected by IPFilter. HP-UX IPFilter is not tested with any third party products.

128

Product Specifications

Table A-1 HP-UX IPFilter Supported Interfaces

IPFilter Version Supported Interfaces Ethernet (10Base-T) Fast Ethernet (100Base-T) Gigabit Ethernet (1000Base-T) 10 Gigabit Ethernet APA VLAN FDDI Token Ring InfiniBand (supported on HP-UX 11i v2 only) X.25 (supported on HP-UX 11i v3 only) Ethernet (10Base-T) Fast Ethernet (100Base-T) Gigabit Ethernet (1000Base-T) 10 Gigabit Ethernet APA VLAN FDDI Token Ring InfiniBand (supported on HP-UX 11i v2 only) X.25 (supported on HP-UX 11i v3 only) Ethernet (10Base-T) Fast Ethernet (100Base-T) Gigabit Ethernet (1000Base-T) APA VLAN FDDI Token Ring InfiniBand (supported on HP-UX 11i v2 only) X.25 (supported on HP-UX 11i v3 only) Ethernet (10Base-T) Fast Ethernet (100Base-T) Gigabit Ethernet (1000Base-T) APA VLAN FDDI Token Ring InfiniBand (supported on HP-UX 11i v2 only)

HP-UX A.11.xx.17

HP-UX A.11.xx.16

HP-UX A.11.xx.15.01

Open source versions: A.03.05.14 (HP-UX 11i v1 and HP-UX 11i v2) A.03.05.13 (HP-UX 11i v3) A.03.05.12 A.03.05.11.01 A.03.05.10 A.03.05.10.02 A.03.05.10.04 A.03.05.06.v2 Open source versions: A.03.05.09 A.03.05.08 A.03.05.07 A.03.05.06

Ethernet (10Base-T) Fast Ethernet (100Base-T) Gigabit Ethernet (1000Base-T) APA VLAN FDDI Token Ring

The following interfaces are unsupported (not protected by HP-UX IPFilter): ATM Hyperfabric
A.5 Supported and Unsupported Interfaces 129

InfiniBand (supported on HP-UX 11i v2, but not on other HP-UX versions) X.25 (supported on HP-UX 11i v3, but not on previous HP-UX versions) Frame Relay PPP

130

Product Specifications

B HP-UX IPFilter Configuration Examples

This appendix provides IPFilter configuration examples. These examples are also included in the/opt/ipf/examples directory with HP-UX IPFilter. You can take useful rules that you find in these examples and copy them into /etc/opt/ipf/ipf.conf, which is your HP-UX IPFilter configuration file. These files are taken from the files provided with the open source IPFilter product.

B.1 BASIC_1.FW
#!/sbin/ipf -f ## SAMPLE: RESTRICTIVE FILTER RULES # # ppp0 - (external) PPP connection to ISP, address a.b.c.d/32 # # lan0 - (internal) network interface, address w.x.y.z/32 # # This file contains the basic rules needed to construct a # firewall for the above connections. # #------------------------------------------------------# Block short packets which are packets fragmented too short to # be real packets. block in log quick all with short #------------------------------------------------------# Group setup. # ============ # By default, block and log all packets. This may result in # too much information to be logged (especially for lan0) # and needs to be further refined. # block in log on ppp0 all head 100 block in log proto tcp all flags S/SA head 101 group 100 block out log on ppp0 all head 150 block in log on lan0 from w.x.y.z/24 to any head 200 block in log proto tcp all flags S/SA head 201 group 200 block in log proto udp all head 202 group 200 block out log on lan0 all head 250 #------------------------------------------------------# Localhost packets. # ================== # Packets going in/out of network interfaces that arent on the # loopback interface should *NOT* exist. block in log quick from 127.0.0.0/8 to any group 100 block in log quick from any to 127.0.0.0/8 group 100 block in log quick from 127.0.0.0/8 to any group 200 block in log quick from any to 127.0.0.0/8 group 200 #------------------------------------------------------# Invalid Internet packets. # ========================= # # Deny reserved addresses. # block in log quick from 10.0.0.0/8 to any group 100 block in log quick from 192.168.0.0/16 to any group 100 block in log quick from 172.16.0.0/12 to any group 100 # # Prevent IP spoofing. # block in log quick from a.b.c.d/24 to any group 100 # #------------------------------------------------------# Allow outgoing DNS requests (no named on firewall) # pass in quick proto udp from any to any port = 53 keep state group 202 # # If you are running named on the firewall and all internal # hosts talk to it,use the following: # pass in quick proto udp from any to w.x.y.z/32 port = 53 keep state group 202 pass out quick on ppp0 proto udp from a.b.c.d/32 to any port = 53 keep state # # Allow outgoing FTP from any internal host to any external FTP # server.

B.1 BASIC_1.FW

131

# pass in quick proto tcp from any to any port = ftp keep state group 201 pass in quick proto tcp from any to any port = ftp-data keep state group 201 pass in quick proto tcp from any port = ftp-data to any port > 1023 keep state group 101 # # Allow NTP from any internal host to any external NTP server. # pass in quick proto udp from any to any port = ntp keep state group 202 # # Allow outgoing connections: SSH, TELNET, WWW # pass in quick proto tcp from any to any port = 22 keep state group 201 pass in quick proto tcp from any to any port = telnet keep state group 201 pass in quick proto tcp from any to any port = www keep state group 201 # #------------------------------------------------------block in log proto tcp from any to a.b.c.d/32 flags S/SA head 110 group 100 # # Allow the following incoming packets types to the external # firewall interface: mail, WWW, DNS pass in log quick proto tcp from any to any port = smtp keep state group 110 pass in log quick proto tcp from any to any port = www keep state group 110 pass in log quick proto tcp from any to any port = 53 keep state group 110 pass in log quick proto udp from any to any port = 53 keep state group 100 #------------------------------------------------------# Log these: # ========== # * Return RST packets for invalid SYN packets to help the #other end close block return-rst in log proto tcp from any to any flags S/SA group 100 # * Return ICMP error packets for invalid UDP packets block return-icmp(net-unr) in proto udp all group 100

B.2 BASIC_2.FW
# SAMPLE: PERMISSIVE FILTER RULES # # ppp0 - (external) PPP connection to ISP, address a.b.c.d/32 # # lan0 - (internal) network interface, address w.x.y.z/32 # # This file contains the basic rules needed to construct a # firewall for the above situation. # #------------------------------------------------------# Short packets which are packets fragmented too short to be # real packets. block in log quick all with short #------------------------------------------------------# Group setup. # ============ # By default, block and log all packets. This may result in # too much information to be logged (especially for lan0) and # the rules needs to be further refined. # block in log on ppp0 all head 100 block out log on ppp0 all head 150 block in log on lan0 from w.x.y.z/24 to any head 200 block out log on lan0 all head 250 #------------------------------------------------------# Invalid Internet packets. # ========================= # # Deny reserved addresses. # block in log quick from 10.0.0.0/8 to any group 100 block in log quick from 192.168.0.0/16 to any group 100 block in log quick from 172.16.0.0/12 to any group 100 # # Prevent IP spoofing. #
132 HP-UX IPFilter Configuration Examples

block in log quick from a.b.c.d/24 to any group 100 # #------------------------------------------------------# Localhost packets. # ================== # packets going in/out of network interfaces that arent on the # loopbackinterface should *NOT* exist block in log quick from 127.0.0.0/8 to any group 100 block in log quick from any to 127.0.0.0/8 group 100 block in log quick from 127.0.0.0/8 to any group 200 block in log quick from any to 127.0.0.0/8 group 200 #------------------------------------------------------# Allow any communication between the inside network and the # outside only. # # Allow all outgoing connections (SSH, TELNET, FTP, WWW, # gopher, etc) # pass in log quick proto tcp all flags S/SA keep state group 200 # # Support all UDP connections initiated from inside. # # Allow ping out # pass in log quick proto icmp all keep state group 200 #------------------------------------------------------# Log these: # ========== # * return RST packets for invalid SYN packets to help the # other end close block return-rst in log proto tcp from any to any flags S/SA group 100 # * return ICMP error packets for invalid UDP packets block -icmp(net-unr) in proto udp all group 100

B.3 example.1
# # block all incoming TCP packets on lan0 from host 10.1.1.1 to # any destination. # block in on lan0 proto tcp from 10.1.1.1/32 to any

B.4 example.2
## block all outgoing TCP packets on lan0 from any host to port # 23 of host 10.1.1.2 # block out on lan0 proto tcp from any to 10.1.1.3/32 port = 23

B.5 example.3
# block all inbound packets. # block in from any to any # # # allow a variety of individual hosts to send any type of IP # packet to any other host. # pass in from 10.1.3.1/32 to any pass in from 10.1.3.2/32 to any pass in from 10.1.3.3/32 to any pass in from 10.1.3.4/32 to any pass in from 10.1.3.5/32 to any pass in from 10.1.0.13/32 to any pass in from 10.1.1.1/32 to any
B.3 example.1 133

pass in from 10.1.2.1/32 to any # # # block all outbound packets. # block out from any to any # # # allow any host to send any IP packet out to a limited number # of hosts. # pass out from any to 10.1.3.1/32 pass out from any to 10.1.3.2/32 pass out from any to 10.1.3.3/32 pass out from any to 10.1.3.4/32 pass out from any to 10.1.3.5/32 pass out from any to 10.1.0.13/32 pass out from any to 10.1.1.1/32 pass out from any to 10.1.2.1/32

B.6 example.4
# # block all ICMP packets. # block in proto icmp from any to any #

B.7 example.5
# # test ruleset # # allow packets coming from foo to bar through. # pass in from 10.1.1.2 to 10.2.1.1 # # allow any TCP packets from the same subnet as foo is on # through to host 10.1.1.2 if they are destined for port 6667. # pass in proto tcp from 10.2.2.2/24 to 10.1.1.2/32 port = 6667 # # allow in UDP packets that are NOT from port 53 and are # destined for localhost # pass in proto udp from 10.2.2.2 port != 53 to localhost # # block all ICMP unreachables. # block in proto icmp from any to any icmp-type unreach # # allow packets through that have a non-standard IP header # length (ie there are IP options such as source-routing # present). # pass in from any to any with ipopts #

B.8 example.6
# # block all TCP packets with only the SYN flag set (this is the # first packet sent to establish a connection) out of the # SYN-ACK pair. # block in proto tcp from any to any flags S/SA
134 HP-UX IPFilter Configuration Examples

B.9 example.7
# block all ICMP packets. # block in proto icmp all # # allow in ICMP echos and echo-replies. # pass in on lan1 proto icmp from any to any icmp-type echo pass in on lan1 proto icmp from any to any icmp-type echorep # # block all ICMP destination unreachable packets which are # port-unreachables # block in on lan1 proto icmp from any to any icmp-type unreach code 3

B.10 example.8
# # block all incoming TCP connections but send back a TCP-RST # for ones to the ident port # block in proto tcp from any to any flags S/SA block return-rst in quick proto tcp from any to any port = 113 flags S/SA # # block all inbound UDP packets and send back an ICMP error. # block return-icmp in proto udp from any to any

B.1 1 example.9
# drop all packets without IP security options # block in all pass in all with opt sec # # only allow packets in and out on lan0 which are top secret # block out on lan0 all pass out on lan0 all with opt sec-class topsecret block in on lan0 all pass in on lan0 all with opt sec-class topsecret

B.12 example.10
# # pass ack packets (ie established connection) # pass in proto tcp from 10.1.0.0/16 port = 23 to 10.2.0.0/16 ... flags A/A pass out proto tcp from 10.1.0.0/16 port = 23 to 10.2.0.0/16... flags A/A # # block incoming connection requests to my internal network # from the internet. # block in on lan0 proto tcp from any to 10.1.0.0/16 flags S/SA # block the replies: block out on lan0 proto tcp from 10.1.0.0 to any flags SA/SA

B.13 example.1 1
# # allow any TCP packets from the same subnet as foo is on
B.9 example.7 135

# through to host 10.1.1.2 if they are destined for port 6667. # pass in proto tcp from 10.2.2.2/24 to 10.1.1.2/32 port = 6667 # # allow in UDP packets which are NOT from port 53 and are # destined for localhost # pass in proto udp from 10.2.2.2 port != 53 to localhost # # block any packet trying to get to X terminal ports, X:0 to # X:9 # block in proto tcp from any to any port 5999 >< 6010 # # allow any connections to be made,except to BSD # print/r-services this will also protect syslog. # block in proto tcp/udp all pass in proto tcp/udp from any to any port 512 <> 515 # # allow any connections to be made, except to BSD # print/r-services # this will also protect syslog. # pass in proto tcp/udp all block in proto tcp/udp from any to any port 511 >< 516

B.14 example.12
# # get rid of all short IP fragments (too small for valid # comparison) # block in proto tcp all with short # # drop and log any IP packets with options set in them. # block in log all with ipopts # # log packets with BOTH ssrr and lsrr set # log in all with opt lsrr,ssrr # # drop any source routing options # block in quick all with opt lsrr block in quick all with opt ssrr

B.15 example.13
# # log all short TCP packets to lan3, with 10.3.3.3 as the # intended destination for the packet. # block in on lan0 to lan3:10.3.3.3 proto tcp all with short # # log all connection attempts for TCP # pass in on lan0 dup-to lan1:10.3.3.3 proto tcp all flags S/SA # # route all UDP packets through transparently. # pass in on lan0 proto udp all # # route all ICMP packets to network 10 out through lan1, to
136 HP-UX IPFilter Configuration Examples

# 10.3.3.1 # pass in on lan0 to lan1:10.3.3.1 proto icmp all

B.16 example.sr
# # # # # # # # # log all inbound packets on lan0 which has IP options present log in on lan0 from any to any with ipopts block any inbound packets on lan0 which are fragmented and "too short" to do any meaningful comparison on. This actually only applies to TCP packets which can be missing the flags/ports (depending on which part of the fragment you see).

block in log quick on lan0 from any to any with short frag # # log all inbound TCP packets with the SYN flag (only) set # (NOTE: if it were an inbound TCP packet with the SYN flag #set and it had IP options present, this rule and the above #would cause it to be logged twice). # log in on lan0 proto tcp from any to any flags S/SA block and log any inbound ICMP unreachables block in log on lan0 proto icmp from any to any icmp-type unreach # block and log any inbound UDP packets on lan0 # which are going to port 2049 (the NFS port). block in log on lan0 proto udp from any to any port = 2049 # # quickly allow any packets to/from a particular pair of hosts # pass in quick from any to 10.1.3.2/32 pass in quick from any to 10.1.0.13/32 pass in quick from 10.1.3.2/32 to any pass in quick from 10.1.0.13/32 to any # # block (and stop matching) any packet with IP options present. # block in quick on lan0 from any to any with ipopts # # allow any packet through # pass in from any to any # # block any inbound UDP packets destined # for these subnets. # block in on lan0 proto udp from any to 10.1.3.0/24 block in on lan0 proto udp from any to 10.1.1.0/24 block in on lan0 proto udp from any to 10.1.2.0/24 # # block any inbound TCP packets with only the SYN flag set that # are destined for these subnets. # block in on lan0 proto tcp from any to 10.1.3.0/24 flags S/SA block in on lan0 proto tcp from any to 10.1.2.0/24 flags S/SA block in on lan0 proto tcp from any to 10.1.1.0/24 flags S/SA # # block any inbound ICMP packets destined for these subnets. #
B.16 example.sr 137

block in on lan0 proto icmp from any to 10.1.3.0/24 block in on lan0 proto icmp from any to 10.1.1.0/24 block in on lan0 proto icmp from any to 10.1.2.0/24

B.17 firewall
#Configuring IP Filter for firewall usage. ========================================= Step 1 - Block out "bad" IP packets. -----------------------------------Run a) b) c) the perl script "mkfilters". This will generate a list of blocking rules which: blocks all packets which might belong to an IP Spoofing attack; blocks all packets with IP options; blocks all packets which have a length which is too short for any legal packet;

Step 2 - Convert Network Security Policy to filter rules. --------------------------------------------------------Draw up a list of which services you want to allow users to use on the Internet (e.g. WWW, ftp, etc). Draw up a separate list for what you want each host that is part of your firewall to be allowed to do, including communication with internal hosts. Step 3 - Create TCP "keep state" rules. --------------------------------------For each service that uses TCP, create a rule as follows: pass in on <int-a> proto tcp from <int-net> to any port <ext-service> flags S/SA keep state where * "int-a" is the internal interface of the firewall. That is, it is the closest to your internal network in terms of network hops. * "int-net" is the internal network IP# subnet address range. This might be something like 10.1.0.0/16, or 128.33.1.0/24 * "ext-service" is the service to if it doesnt have a proper name, translation of "ext-service" as a controlled with the /etc/services which you wish to connect or a number can be used. The name to a number is file.

B.18 server
# # For a network server, which has two interfaces, 128.1.40.1 #(lan0) and 128.1.2.1 (lan1), we want to block all IP spoofing # attacks. lan1 is connected to the majority of the network, # while lan0 is connected to a leaf subnet. # Were not concerned about filtering individual services # # pass in quick on lan0 from 128.1.40.0/24 to any block in log quick on lan0 from any to any block in log quick on lan1 from 128.1.1.0/24 to any pass in quick on lan1 from any to any

B.19 tcpstate
# # Only allow TCP packets in/out of lan0 if there is an outgoing # connection setup somewhere, waiting for it. # pass out quick on lan0 proto tcp from any to any flags S/SAFR keep state block out on lan0 proto tcp all block in on lan0 proto tcp all # # allow nameserver queries and replies to pass through, but no # other UDP #
138 HP-UX IPFilter Configuration Examples

pass out quick on lan0 proto udp from any to any port = 53 keep state block out on lan0 proto udp all block in on lan0 proto udp all

B.20 BASIC.NAT
#!/sbin/ipnat -f # # THIS EXAMPLE IS WRITTEN FOR IP FILTER 3.3 # # ppp0 - (external) PPP connection to ISP, address a.b.c.d/32 # # lan0 - (internal) network interface, address w.x.y.z/32 # # If only one valid IP address from the ISP, then use this # rule: # map ppp0 w.x.y.z/24 -> a.b.c.d/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.z/24 -> a.b.c.d/32 # # If a different dialup IP address is assigned each time, then # use this rule: map ppp0 w.x.y.z/24 -> 0/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.z/24 -> 0/32 # # If using a class C address space of valid IP addresses from # an ISP, then use this rule: # map ppp0 w.x.y.z/24 -> a.b.c.d/24 portmap tcp/udp 40000:60000 map ppp0 w.x.y.z/24 -> a.b.c.d/24 # # If using a small number of PCs, use this rule: # map ppp0 w.x.y.v/32 -> a.b.c.E/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.v/32 -> a.b.c.E/32 map ppp0 w.x.y.u/32 -> a.b.c.F/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.u/32 -> a.b.c.F/32 map ppp0 w.x.y.t/32 -> a.b.c.G/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.t/32 -> a.b.c.G/32 map ppp0 w.x.y.s/32 -> a.b.c.H/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.s/32 -> a.b.c.H/32 map ppp0 w.x.y.r/32 -> a.b.c.I/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.r/32 -> a.b.c.I/32 map ppp0 w.x.y.q/32 -> a.b.c.J/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.q/32 -> a.b.c.J/32 map ppp0 w.x.y.p/32 -> a.b.c.K/32 portmap tcp/udp 40000:60000 map ppp0 w.x.y.p/32 -> a.b.c.K/32 # # For ftp to work using the internal ftp proxy, use the # following rule: # map ppp0 w.x.y.z/24 -> a.b.c.d/32 proxy port ftp ftp/tcp

B.21 nat.eg
# # # # # # # # map all tcp connections from 10.1.0.0/16 to 240.1.0.1, changing the source port number to something between 10,000 and 20,000 inclusive. For all other IP packets, allocate an IP # between 240.1.0.0 and 240.1.0.255, temporarily for each new user.

B.20 BASIC.NAT

139

map lan1 10.1.0.0/16 -> 240.1.0.1/32 portmap tcp 10000:20000 map lan1 10.1.0.0/16 -> 240.1.0.0/24 # # Redirection is triggered for input packets. # For example, to redirect FTP connections through this box # to the local ftp port and force them to connect # through a proxy, you would use: # rdr lan0 0.0.0.0/0 port ftp -> 127.0.0.1 port ftp

B.22 nat-setup
Configuring NAT on your network. ================================ To start setting up NAT, we need to define which is your "internal" interface and which is your "external" interface. The "internal" interface is the network adapter connected to the network with private IP addresses which you need to change for communicating on the Internet. The "external" interface is configured with a valid internet address. For example, your internal interface might have an IP address of 10.1.1.1 and be connected to your ethernet, whilst your external interface might be a PPP connection with an IP number of 204.51.62.176. Thus your network might look like this: <Internal Network> [pc] [pc] | | +-+---------+------+ | [firewall] | | Internet <External Network> Writing the map-rule. --------------------When you're connected to the Internet, you will either have a block of IP addresses assigned to you, maybe several different blocks, or you use a single IP address, i.e. with dialup PPP. If you have a block of addresses assigned, these can be used to create either a 1:1 mapping (if you have only a few internal IP addresses) or N:1 mappings, where groups of internal addresses map to a single IP address and unless you have enough Internet addresses for a 1:1 mapping, you will want to do "portmapping" for TCP and UDP port numbers. For an N:1 situation, you might have: map ppp0 10.1.0.0/16 -> 209.23.1.5/32 portmap tcp/udp 10000:40000 map ppp0 10.1.0.0/16 -> 209.23.1.5/32 portmap where if you had 16 addresses available, you could do: map ppp0 10.1.0.0/16 -> 209.23.1.0/28 portmap tcp/udp 10000:40000 map ppp0 10.1.0.0/16 -> 209.23.1.0/28 portmap Or if you wanted to allocate subnets to each IP#, you might do: map ppp0 10.1.1.0/24 -> 209.23.1.2/32 portmap tcp/udp 10000:40000 map ppp0 10.1.2.0/24 -> 209.23.1.3/32 portmap tcp/udp 10000:40000 map ppp0 10.1.3.0/24 -> 209.23.1.4/32 portmap tcp/udp 10000:40000 map ppp0 10.1.1.0/24 -> 209.23.1.2/32 portmap map ppp0 10.1.2.0/24 -> 209.23.1.3/32 portmap map ppp0 10.1.3.0/24 -> 209.23.1.4/32 portmap *** NOTE: NAT rules are used on a first-match basis only! Filtering with NAT. ------------------IP Filter will always translate addresses in a packet _BEFORE_ it checks its access list for inbound packets and translates addresses _AFTER_ it has checked the access control lists for outbound packets.
140 HP-UX IPFilter Configuration Examples

For example (using the above NAT rules), if you wanted to prevent all hosts in the 10.1.2.0/24 subnet from using NAT, you might use the following rule with ipf: block out on ppp0 from 10.1.2.0/24 to any block in on ppp0 from any to 10.1.2.0/24 and use these with ipnat: map ppp0 10.1.0.0/16 -> 209.23.1.0/28 portmap tcp/udp 10000:40000 map ppp0 10.1.0.0/16 -> 209.23.1.0/28 portmap

B.23 ipmon.conf
match { logtag = 10000 } do { execute "/usr/bin/mail -s 'logtag 10000' root" }; match { logtag = 2000, protocol = tcp } do { execute "echo 'XXXXXXXX tag 2000 packet XXXXXXXX'" }; # match { protocol = udp, result = block } do { execute "/usr/bin/mail -s 'blocked udp' root" }; # match { srcip = 10.1.0.0/16, dstip = 192.168.1.0/24 } do { execute "/usr/bin/mail -s 'from 10.1 to 192.168.1' root" }; # match { rule = 12, logtag = 101, direction = in, result = block, protocol = udp, srcip = 10.1.0.0/16, dstip = 192.168.1.0/24 } do { execute "run shell command" };

B.24 pool.conf
table role = ipf type = tree number = 100 { 1.1.1.1/32; 2.2.0.0/16; 2.2.2.0/24; }; table role = ipf type = hash number = 100 size = 5 { 1.1.1.1/32; 2.2.0.0/16; 2.2.2.0/24; };

B.23 ipmon.conf

141

142

C HP-UX IPFilter Kernel Tunable Parameters

HP-UX IPFilter supports kernel tunable parameters that affect IPFilter behavior. This chapter describes the parameters and how to configure them. This chapter contains the following sections: Overview (page 143) fr_tcpidletimeout (page 144) fr_statemax (page 144) ipf_icmp6_passthru (page 144) ipl_buffer_sz (page 144) ipl_suppress (page 145) ipl_logall (page 145) Configuring and Viewing Kernel Tunable Parameters (page 145) Enabling and Disabling NAT Functionality (page 147)

C.1 Overview
HP-UX IPFilter supports the following kernel tunable parameters:
Name fr_tcpidletimeout fr_statemax ipf_icmp6_passthru Description The timeout period for TCP entries in the state table. Specifies the maximum number of state table entries that can be created. If set to 0, IPFilter allows ICMPv6 Router Discovery and Neighbor Discovery messages to bypass normal IPFilter rule processing and always pass through the system. Size of the IPFilter logging buffer for /dev/ipl. If enabled (set to 1), IPFilter does not write identical log records separately, but counts them as Nx, where N is the number of times the log record occurs. Default Value 86,400 seconds 800,000 entries 0

ipl_buffer_sz ipl_suppress

8192 bytes 1 (enabled)

ipl_logall

If enabled (set to 1), IPFilter includes the entire packet when 0 (disabled) the log body keywords are specified in a rule. Otherwise, it includes only the first 128 bytes. Used to enable or disable NAT functionality. Value can be 0 or 1. This is supported on 11.23 and 11.31. It is modified using the kctune command. 1 (enabled)

ipnat_enable

fr_tcptimewait

Used to set TCP state entry age at system level after 120 Sec (enabled) connection is closed. Value can be between 2-120 Sec. This is supported only on 11.31. It is modified using the kctune command. Used to set TCP NAT entry age at system level after 120 Sec connection is closed. Value can be between 2-120 Sec. This is supported only on 11.31. It is modified using the kctune command.

frnat_tcptimewait

The following sections provide information about the remaining kernel tunable parameters and how to use the kctune, kmtune, and ndd commands to configure these parameters.

C.1 Overview

143

C.2 fr_tcpidletimeout
The fr_tcpidletimeout is the timeout period for state table entries for TCP connections that are established and idle. If the state table has an entry for an established TCP connection and no packets match the state entry for that period, IPFilter deletes the entry.
Name fr_tcpidletimeout Range HP-UX 11i v1: 300 - 86,400 seconds HP-UX 11i v2 and HP-UX 11i v3: 240 - 86,400 seconds Default Value 86,400 seconds (24 hours) Configuration Utility HP-UX 11i v1: kmtune HP-UX 11i v2 and HP-UX 11i v3: kctune

C.3 fr_statemax
The fr_statemax parameter specifies the maximum number of entries in the IPFilter state table.
Name fr_statemax Range 4,000 - 1,600,00 entries Default Value 800,000 entries Configuration Utility HP-UX 11i v1: kmtune HP-UX 11i v2 and HP-UX 11i v3: kctune

IPFilter allocates state table entries for packets using stateful (keep state) and Dynamic Connection Allocation (keep limit) rules. IPFilter also maintains a limit table to count the state table entries for DCA rules. IPFilter allocates memory for the state table in 500-Kbyte chunks, where each chunk can store 1,300 entries (each state table entry is approximately 384 bytes). CAUTION: HP-UX IPFilter keeps memory allocated for state and limit table entries in its private free pool and does not return this allocated memory back to the kernel memory pool for general use. Setting fr_statemax to a large value can affect system memory availability. When the number of entries reaches fr_statemax, IPFilter checks if entries have exceeded their idle lifetime and are eligible to be freed. The idle lifetimes are based on the protocol type and are as follows: ICMP: 60 seconds TCP: the value of fr_tcpidletimeout (by default, 84,600 seconds) UDP: 120 seconds If IPFilter is unable to create a state table entry for a packet that matches a DCA rule, it allows the packet to pass. The maximum counter reported by the ipfstat -s command reports the number of times IPFilter attempted to create a state table entry but could not because the state table contained the maximum number of entries.

C.4 ipf_icmp6_passthru
The parameter ipf_icmp6_passthru is described in Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages (page 107).

C.5 ipl_buffer_sz
The ipl_buffer_sz parameter specifies the size of the IPFilter logging buffer.
Name ipl_buffer_sz Range 1024 - 163840 bytes Default Value 8192 bytes Configuration Utility HP-UX 11i v1 and HP-UX 11i v2: ndd HP-UX 11i v3: kctune

144

HP-UX IPFilter Kernel Tunable Parameters

C.5.1 Displaying Logging Buffer Statistics

On HP-UX 11i v3 systems, the ipfstat B command displays the size of the log buffer, the current number of bytes used, and the high-water mark (the maximum number of bytes used). On HP-UX 11i v1 and HP-UX 11i v2 systems, use the following command to get the logging buffer statistics: ndd -get /dev/pfil cur_iplbuf_sz The parameter cur_iplbuf_sz is a read-only parameter.

C.6 ipl_suppress
The ipl_suppress parameter specifies the IPFilter logging behavior for identical log records. When this feature is enabled (the value is 1), IPFilter suppresses identical log records; instead of does not writing duplicate records, it writes the record and N where N is the number of times the record was repeated. If this feature is disabled, IPFilter writes all log records, including duplicate records.
Name ipl_suppress Range 0 (disabled) - 1 (enabled) Default Value 1 Configuration Utility HP-UX 11i v1 and HP-UX 11i v2: ndd HP-UX 11i v3: kctune

C.7 ipl_logall
The ipl_logall parameter specifies if IPFilter includes the first 128 bytes of a packet in log records or all the contents of a packet when the log body keywords are specified in a rule. By default, this feature is disabled (ipl_logall is set to 0). Note that enabling this feature generates large log files. For information on changing the ipl_logall variable, see Configuring and Viewing Kernel Tunable Parameters (page 145).
Name ipl_logall Range 0 (disabled) - 1 (enabled) Default Value 0 Configuration Utility HP-UX 11i v1 and HP-UX 11i v2: ndd HP-UX 11i v3: kctune

C.8 Configuring and Viewing Kernel Tunable Parameters

The tool used to configure and view HP-UX IPFilter kernel tunable parameters depends on the HP-UX version and the parameter.

C.8.1 Configuring Kernel Tunable Parameters on HP-UX 1 1i v3

On HP-UX 11i v3 systems, use the kctune command to configure and view HP-UX IPFilter kernel tunable parameters. Use the following syntax to configure the value of a kernel tunable: kctune parameter_name=value For example: kctune ipl_logall=1 Use the following syntax to query the value of a kernel tunable: kctune parameter_name For example: kctune ipl_logall

C.6 ipl_suppress

145

C.8.2 Configuring Kernel Tunable Parameters on HP-UX 1 1i v1 and HP-UX 1 1i v2

On HP-UX 11i v1 and HP-UX 11i v2, use the ndd command to configure all HP-UX IPFilter kernel tunable parameters, with the following exceptions: fr_statemax and fr_tcpidletimeout: Use the kmtune command to modify these parameters. ipf_icmp6_passthru: On HP-UX 11i v2, use the kctune command to modify this parameter, as described in Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages (page 107)

C.8.2.1 Configuring Kernel Tunable Parameters Using ndd

On HP-UX 11i v1 and HP-UX 11i v2 systems, use the ndd utility to configure and view the following IPFilter kernel tunable parameters: ipl_buffer_sz ipl_suppress ipl_logall cur_iplbuf_sz (read only) On HP-UX 11i v1, you can also use the ndd utility to configure and view the ipf_icmp6_passthru parameter, as described in Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages (page 107). NOTE: You cannot add the IPFilter ndd variables to the ndd configuration file read at system startup time (/etc/rc.config.d/nddconf). When the system starts up, the IPFilter ndd variables are reset to their default values. The network device for the IPFilter parameters is /dev/pfil. Use the following syntax to configure the value of an IPFilter ndd kernel tunable parameter: ndd -set /dev/pfil parameter_name value For example: ndd -set /dev/pfil ipl_logall 1 Use the following syntax to query the value of a kernel tunable: ndd -get /dev/pfil parameter_name For example: ndd -get /dev/pfil ipl_logall

C.8.2.2 Configuring fr_statemax and fr_tcpidletimeout Using kmtune or kctune

On HP-UX 11i v1 systems, use the kmtune utility to query and configure fr_statemax and fr_tcpidletimeout values. On HP-UX 11i v2 systems, use the kctune utility to query and query these values. For new values to take effect, you must unload, reconfigure, and reload the ipf module as follows: 1. Unload the ipf module: /sbin/init.d/ipfboot stop 2. On HP-UX 11i v1 systems, use the following kmtune syntax to set the value of the tunable parameter: kmtune -s parameter_name=value For example: kmtune -s fr_tcpidletimeout=10800 (3 hours) On HP-UX 11i v2 systems, use the following kctune syntax to set the value of the tunable parameter: kctune -s parameter_name=value For example:

146

HP-UX IPFilter Kernel Tunable Parameters

kctune -s fr_statemax=6000 3. Configure the module for the new value using the following commands: cd /stand/ipf config -M ipf -u Reload the ipf module: /sbin/init.d/ipfboot start

4.

C.9 Enabling and Disabling NAT Functionality

The new ipnat_enable tunable is provided to enable/disable NAT functionality. By default, this tunable is set to 1. If you do not use NAT functionality, disabling this tunable will improve performance. NOTE: This available only on 11i v3.

C.9 Enabling and Disabling NAT Functionality

147

148

D HP-UX IPFilter Static Linking

This appendix provides instructions for statically linking the HP-UX IPFilter kernel modules to the kernel.

D.1 Overview
IPFilter has two kernel modules, pfil, a streams module and ipf, a WSIO pseudo driver. These are dynamically loadable kernel modules. When IPFilter is installed on an HP-UX system using swinstall, these two modules are loaded and configured as dynamically linked modules. They can be loaded and unloaded when required without shutting down the system as long as the modules are not currently in use.

D.2 Static Linking of HP-UX IPFilter on HP-UX 1 1i v2 and HP-UX 1 1i v3

Use the following steps to statically link the IPFilter modules to the kernel with HP-UX 11i v2 and HP-UX 11i v3: 1. Set up the IPFilter modules to be statically linked to the kernel using the kcmodule command. The modules will be statically linked at the next system boot. See the kcmodule (1M) manpage for further details. For example: $ kcmodule -K -h -s pfil=static $ kcmodule -K -h -s ipf=static 2. Reboot the system. Use the following steps to return the system back to dynamic linking. 1. Set up the IPFilter modules to be dynamically linked to the kernel using the following commands: $ kcmodule -K -h -s pfil=auto $ kcmodule -K -h -s ipf=auto 2. Reboot the system.

CAUTION: If you need to remove or update IPFilter software, you must reconfigure the ipf and pfil modules to link dynamically into the kernel. The install and remove scripts for IPFilter assume the IPFilter modules to be dynamically linked. Do not try installing a newer version or removing the existing IPFilter product if it is statically linked to the kernel.

D.3 Static Linking of HP-UX IPFilter on HP-UX 1 1i v1

As with any other DLKM modules for HP-UX 11i v1, these modules can be statically linked to the kernel. Follow these steps to statically link the IPFilter modules to the kernel: 1. Use the kmadmin command to find out if the modules have been loaded dynamically. See the kmadmin(1M) manpage for usage information. For example: $ kmadmin -s
Name pfil ipf ID 1 2 Status LOADED LOADED Type STREAMS WSIO

D.1 Overview

149

2.

Use the kmsystem command to find the status of each module. See the kmsystem(1M) manpage for more detail. For example: $ kmsystem -q pfil
Module pfil Configured Y Loadable Y

The output is similar for the ipf module. This output shows that the pfil module is loadable. 3. Use the kmsystem command to set the loadable parameter to N. $ kmsystem -l N -c Y ipf $ kmsystem -q ipf
Module ipf Configured Y Loadable N

$ kmsystem -l N -c Y pfil 4. 5. Use the following command to build the new kernel with the modified configuration: $config /stand/system Use the kmupdate command to prepare the system to boot from the new kernel during the next system shutdown. $ kmupdate /stand/build/vmunix_test $ shutdown -r 0 # Shutdown the system now This boots the system using the new kernel that has both IPFilter modules statically linked.

CAUTION: If you need to remove or update IPFilter software, you must reconfigure the ipf and pfil modules to link dynamically into the kernel. The install and remove scripts for IPFilter assume the IPFilter modules to be dynamically linked. Do not try installing a newer version or removing the existing IPFilter product if it is statically linked to the kernel.

150

HP-UX IPFilter Static Linking

E Performance Guidelines
This appendix provides performance guidelines for the use of HP-UX IPFilter. You must take operating environment limits in to account when you configure HP-UX IPFilter. HP-UX does not enforce maximum configuration limits to provide flexibility. However, you must take care not to overburden HP-UX IPFilter systems or unpredictable consequences may result. This appendix contains the following sections: System Configuration (page 151) Rule Loading (page 152) Rule Configuration (page 152) Traffic (page 153) Performance Monitoring (page 154)

E.1 System Configuration

The following are four suggestions for HP-UX system configuration for optimal performance: Figure E-1 Processing packets through a system

Table E-1 Processing Packets through a System

Packets from the Internet 1 2 3 4 Packets enter the system Processed by inbound IPFilter processing Processed by outbound IPFilter processing Packets leave the system Packets to the Internet 5 6 7 8 Packets enter the system Processed by inbound IPFilter processing Processed by outbound IPFilter processing Packets leave the system

Packets are processed twice (2 and 3)

Packets are processed twice (6 and 7)

1.

2.

On an intermediate system, disable the interface on the intranet side. By default, there is redundant processing for each packet through an intermediate system, as shown in Figure E-1. By disabling the intranet interface, using ipf -D lan2 in this example, each packet is processed only once in each direction (2 and 7). Do not disable any interface on an end system. If your system has multiple CPUs and LAN cards, be sure traffic is divided evenly between the CPUs. Interrupt migration and PerfView utilities can be used to determine that traffic is spread evenly between CPUs.

E.1 System Configuration

151

3. 4.

Dedicate a CPU to each LAN card, if possible. Avoid configuring one CPU to share an application and a LAN, especially if the application is data or computationally intensive. Use the HP-UX Processor Set (PSET) utility to separate applications and LAN processing. If you are configuring an intermediate system, dedicate that system to HP-UX IPFilter. Do not share the system with other standalone applications.

E.2 Rule Loading

When you load a large number of new rules to a ruleset, the system must search existing rulesets for duplicate rules. This slows down the loading process. For example, if there is no group rule and there are 5000 rules on the system, the system searches through all 5000 rules to be sure there is no duplication before adding each new rule. HP-UX IPFilter searches for duplicate rules by group. To speed the search process when loading rules, divide the rules into groups. See Improving Performance with Rule Groups (page 40) for information on rule groups. HP recommends configuring a maximum of 5000 rules per group and 5000 groups per system. You do not need to flush and reload an entire ruleset to modify some rules within the ruleset. Adding rules that already exist slows processing. If you are modifying a large ruleset, follow these steps: 1. Find the difference between the new ruleset and the current ruleset using the diff command. 2. Delete the old rules using the ipf -rf command. 3. If your ruleset contains keep limit rules, modify the rules with the ipf -f command. 4. Add the new rules using the ipf -f command. If a rule must be in a specific place in the ruleset, specify the rule number using @rule_number before the rule. You can also modify an inactive ruleset and then switch the inactive ruleset for the active ruleset with the ipf -s command.

E.3 Rule Configuration

To configure IPFilter rules for optimal system performance: Avoid using return-rst whenever possible. From both security and performance perspectives, it is better for IPFilter to block packets anonymously rather than returning a Reset packet with a known address. Avoid logging whenever possible. Excessive logging can impact both storage and CPU performance on the system. Determine the appropriate logging level for your environment. Use the quick keyword whenever possible. The quick keyword stops the rule search for a packet a rule matches. Otherwise, IPFilter searches the entire ruleset, which can impact performance if there are a large number of rules. Use keep state or keep limit rules whenever possible. Each connection that matches the keep state or keep limit rule searches through the ruleset only once. The following packets for that connection will match the existing state entry and not search the rest of the ruleset. Use group rules whenever possible. For more information, see Improving Performance with Rule Groups (page 40). In the following example, a connection from 15.13.104.72 must search 102 rules before finding a match.
pass in quick proto tcp from 15.13.2.1 to any port = 23 keep limit 1 pass in quick proto tcp from 15.13.2.2 to any port = 23 keep limit 2 . (15.13.2.3 to 15.13.2.99) . 152 Performance Guidelines

pass pass pass pass pass pass

in in in in in in

quick proto tcp from 15.13.2.100 to any port = 23 quick proto tcp from 15.13.103.0/24 to any port = quick proto tcp from 15.13.104.0/24 to any port = quick proto tcp from 15.13.105.0/24 to any port = quick proto tcp from 15.13.106.0/24 to any port = log limit freq 20 quick proto tcp from any to any

keep limit 100 23 keep limit 500 23 keep limit 500 23 keep limit 500 23 keep limit 500 port = 23 keep limit 4

If the ruleset in the previous example is modified to use the group keyword, it is only necessary for the packet to search four rules before finding a match. For example:
pass in quick proto tcp from 15.13.2.1-15.13.2.100 to any port = 23 head 1 pass in quick proto tcp from 15.13.2.1 to any port = 23 keep limit 1 group 1 pass in quick proto tcp from 15.13.2.2 to any port = 23 keep limit 2 group 1 . (15.13.2.3 to 15.13.2.99) . pass in quick proto tcp from 15.13.2.100 to any port = 23 keep limit 100 group 1 pass in quick proto tcp from 15.13.103.0/24 to any port = 23 keep limit 500 pass in quick proto tcp from 15.13.104.0/24 to any port = 23 keep limit 500 pass in quick proto tcp from 15.13.105.0/24 to any port = 23 keep limit 500 pass in quick proto tcp from 15.13.106.0/24 to any port = 23 keep limit 500 pass in log limit freq 20 quick proto tcp from any to any port = 23 keep limit 4

Consolidate rules whenever possible, to minimize searching. For example:

pass pass pass pass pass pass pass pass pass pass in in in in in in in in in in quick quick quick quick quick quick quick quick quick quick proto proto proto proto proto proto proto proto proto proto tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp from from from from from from from from from from 15.13.103.72 to any keep limit 80 15.13.103.0-15.13.103.6 to any keep limit 44 15.13.103.7 to any keep limit 33 15.13.103.8 to any keep limit 33 15.13.103.9 to any keep limit 33 15.13.103.10-15.13.103.255 to any keep limit 44 15.13.104.0/24 to any keep limit 44 15.13.105.0/24 to any keep limit 44 15.13.106.0/24 to any keep limit 44 15.13.107.0-15.13.107.78 to any keep limit 44

The previous ruleset can be condensed to the following:

pass in quick proto tcp from 15.13.103.0-15.13.107.78 to any keep limit 33 head 1 pass in quick proto tcp from 15.13.103.72 to any keep limit 80 group 1 pass in quick proto tcp from !15.13.103.7-15.13.103.9 to any keep limit 44 group 1

For keep limit rules, avoid the cumulative rule whenever possible. If a large number of connections have the same source IP, destination IP, and destination port, system performance is impacted by cumulative rules. Non-cumulative keep limit rules keep a cache based on the source IP, destination IP, and destination port. Cumulative rules do not keep a cache based on these parameters.

E.4 Traffic
To manage IPFilter for optimal system performance: Keep the state entries at a manageable level. A large number of state entries requires many CPU cycles to process them. Too many state entries can cause noticeable performance degradation on a system. Keep packet searches on rulesets as short as possible. On a 750-MHz PA-RISC system, a 1000 to 2000 rule search is acceptable. If IPFilter traffic is light, a 5000 rule search is the recommended maximum. The optimal number of rules is dependent on your specific operating environment, including factors such as type of rules and amount of traffic. Keep IPFilter traffic at a manageable level. Do not run at peak load all the time. Keep the average CPU usage rate at around 60% to accommodate unexpected peak loads. At peak load times the system compensates with schemes such as dropping packets. However, it is never a good idea to push a system beyond its intended capacity. For example, the normal region in Figure E-2 shows normal system operation. The system should not operate in the marginal region for a long period of time. Configure your system to raise an alarm if the system reaches the critical level. Define these criteria based your operating environments.

E.4 Traffic

153

Figure E-2 System Operation

E.5 Performance Monitoring

The performance of an IPFilter system depends primarily on four major factors: Number and length of rule searches (rule organization) Types of rules Network traffic System configuration Monitor your system performance to ensure proper operation. HP recommends they following: Use ipfstat -ioh to monitor the rule searches. If a rule has a high hit count, this indicates that the rule can be optimized. Use other ipfstat options to monitor IPFilter activities. If you know the normal operating behavior statistics, you can diagnose problems during peak hours more easily. Use a performance tool, such as PerfView, to monitor system usage. Most performance problems can be resolved by changing the system configuration and the IPFilter rule configuration. In some instances, systems may be overwhelmed by network traffic. In these cases, you can implement other traffic-sharing alternatives, such as APA, cluster, and load balancer.

154

Performance Guidelines

Index
A
active rules list, 42 adding keep limit rules, 58 address pooling, 73 Dynamic Connection Allocation (see DCA) dynamic linking, 149

E
enabling, 99 examples configuration basic, 131, 132 TCP, 138 extension headers IPv6, 47 extracting keep limit rules, 59

B
bidirectional filtering in keyword, 28 out keyword, 28 bidirectional filtering with IPSec, 118 bimap keyword, 71 block keyword, 28 blocked traffic IPSec correcting, 118

F
filtering bidirectional, 28 by interface, 32 by IP address, 28 by subnet, 28 by TCP header flags, 33 ICMP packets, 35, 101 IP address and interface, 28 IPv6, 46 localhost, 77 on IP options, 34 package IP address, 122 port number, 29 rate-based, 30 filtering on flags confusing with keeping state, 36 firewall basic configuration, 26 flags keyword, 33 fr_statemax, 144 fr_tcpidletimeout, 144 fragmentation IPv6, 48 from keyword, 28 FTP active FTP client, 110 server, 110 how it works, 109 passive FTP client, 111 server, 110 WU-FTPD, 109

C
checklist installation and configuration, 21 commands unsupported, 128 configuration checklist, 21 DCA rules file, 52 IPv6 rules file, 45 NAT rules file, 63 rules file, 27 rules processing, 27, 63 verifying, 23 configuration examples, 131 configuring file conventions, 27, 42, 45, 49, 63 configuring kernel tunables, 145 configuring variables, 146

D
DCA file configuration, 52 keywords, 53 logging command, 91 overview, 52 processing commands, 97 remote failover, 126 rule modifications, 57 setting mode, 60, 96 syntax, 53 DCA keywords keep limit, 53 log limit, 54 log limit freq, 55 DCA_START configuration option, 60 debugging ipfstat utility, 81 Denial of Service attack defense, 28 disabling, 99

G
group keyword, 40

H
high availability, 121

I
ICMP
155

error status messages, 37 filtering on, 35, 101 keeping state with, 37 icmp-type keyword, 35, 101 ICMPv6 IPv6, 46 in keyword, 28 inactive rules list, 42 installation checklist, 21 loading software, 22 prerequisites, 21 verifying, 23 integrating keep limit rules, 58 interface-specific filtering, 32 interfaces supported, 128 unsupported, 128 interoperability IPSec, 117 IP address filtering by, 28 limiting connections by, 53 ipf, 95 -6 option, 95 -A option, 42 -D option, 96 -E option, 96 -f option, 42, 49 -Fa option, 42, 96 -Fi option, 96 -Fo option, 96 -I option, 42, 96 -m d option, 60, 96 -m e option, 60, 96 -m option, 96 -m q option, 60, 96 -m t option, 60, 96 -Q option, 97 -s option, 42, 96 -V option, 23 -Z option, 96 adding rules, 42, 49 IPv6, 49 ipf module, 149 ipf.conf bootup start, 42, 49 syntax in, 27 ipfboot, 92, 127 IPFilter disabling, 99 enabling, 99 removing, 23 ipfilter, 99 -d option, 99 -di option, 99 -e option, 99 -ei option, 99 -l option, 99
156 Index

-q option, 99 IPFilter modules ipf, 149 pfil, 149 ipfstat, 80 -6 option, 80 -h option, 80 -i option, 80 -L option, 80, 82 -Lv option, 80 -n option, 82 -o option, 80 -r option, 80, 84 -s option, 82 -sl option, 82 -v option, 81 -vL option, 83 ipfstat -io option, 82 ipfstat -Q option, 80 ipftest, 85 -i option, 85 -r option, 85 input file format, 85 ipl_buffer_sz, 144 ipl_logall, 145 ipl_suppress, 145 ipmon, 88, 90, 92, 93 -A option, 90 -a option, 90 -C option, 90 -F option, 90 -o option, 90 -r option, 55, 90 ipnat, 63, 98 -C option, 98 -F option, 98 -f option, 98 -l option, 98 -r option, 98 ipopts keyword, 34 ippool, 73, 99 -A option, 100 -a option, 100 -d option, 100 -F option, 100 -f option, 100 -i option, 100 -l option, 100 -m option, 100 -n option, 100 -o option, 100 -r option, 100 -s option, 100 -t option, 100 -v option, 100 -z option, 100 ippool.conf, 73 IPSec allowing protocol 50 and 51 traffic through, 119

allowing traffic through the firewall, 118 bidirectional with IPFilter, 118 debugging blocked traffic with, 118 gateway, 120 UDP negotiation, 117 IPSec and IPFilter, 117 IPv6 differences, 46 extension headers, 47 features, 46 file configuration, 45 filter rules, 46 fragmentation, 48 ICMPv6 filtering, 46 ipf, 49 protocol-based filtering, 46 rules configuration, 45 stateful ICMPv6, 46 tunneled packets, 47 unsupported features, 46, 128

K
kcmodule, 23 static linking, 149 kctune, 145 keep frags keyword, 38 keep limit keyword, 53 keep limit rules adding, 58 adding a subnet or IP address range rule, 58 adding individual rule, 58 changing current rule, 57 extracting, 59 integrating, 58 rule hits, 61 updating, 57 updating a subnet or IP address range, 58 keep state ICMP, 37 keyword, 35, 36 state table dump, 82 when to use, 36 keeping state UDP, 37 with servers and flags, 36 kernel tunables configuring, 145 fr_statemax, 144 fr_tcpidletimeout, 144 ipl_buffer_sz, 144 ipl_logall, 145 ipl_suppress, 145 keywords bimap, 71 block, 28 flags, 33 from, 28 group, 40

icmp-type, 35, 101 in, 28 ipopts, 34 keep frags, 38 keep limit, 53 keep state, 35 log, 31, 88 log limit, 54 log limit freq, 55 map, 66 map-block, 67 on, 32 opt, 34 out, 28 pass, 28 port, 29 portmap, 66 proto, 28 quick, 31 rdr, 68 return-icmp-as-dest, 39 return-rst, 39 to, 28 with frags, 35 with short, 35 kmadmin static linking, 149 kmsystem static linking, 150 kmtune, 146 kmupdate static linking, 150

L
l4check, 69 limiting connections by IP address, 53 by subnet, 54 cumulative, 54 default individual limit, 54 loading software, 22 localhost filtering, 77 log keyword, 31, 88 body option, 89 first option, 88 log limit freq keyword, 55 log limit keyword, 54 log tags, 43 logging, 92 packets, 31 problems, 93 logging exceeded connections, 54 logging techniques, 88

M
map keyword, 66 map-block keyword, 67 memory allocation, 144 modifying DCA rules, 57
157

monitoring IPFilter, 90 multi-level grouping, 40

N
NAT file configuration, 63 viewing and loading rules, 98 NAT keywords bimap, 71 map, 66 map-block, 67 portmap, 66 rdr, 68 nat tags, 43 netstat, 94 nslookup, 37

O
on keyword, 32 opt keyword, 34 out keyword, 28

P
package IP address, 122 pass keyword, 28 patch dependencies, 21 performance guidelines, 151 performance monitoring, 154 rule configuration, 152 rule loading, 152 system configuration, 151 traffic, 153 performance improvement, 40 performance information, 80 performance monitoring guidelines, 154 pfil module, 149 ping, 37 port keyword, 29 port number filtering, 29 portmap keyword, 66 prerequisites installation, 21 patch dependencies, 21 proto keyword, 28 protocol 50 and 51 traffic, 119 protocol-based filtering IPv6, 46

Q
quick keyword, 31

R
rdr keyword, 68 reloading IPFilter, 92 removing, 23 removing IPFilter software static linking, 149, 150 reporting problems, 37, 94 return-icmp-as-dest keyword, 39
158 Index

return-rst keyword, 39 rule configuration guidelines, 152 rule groups, 40 rule loading guidelines, 152 rule tags, 43 rules active list, 42 adding rules to a rules file, 42, 49 bimap keyword, 71 block keyword, 28 errors occur when loading, 93 file configuration, 27 flags keyword, 33 flushing, 42 from keyword, 28 grouping, 40 icmp-type keyword, 35, 101 in keyword, 28 inactive list, 42 interface-specific, 32 IP address-specific, 28 ipopts keyword, 34 IPv6, 45 keep frags keyword, 38 keep limit keyword, 53 keep state keyword, 35, 36 log keyword, 31, 88 log limit freq keyword, 55 log limit keyword, 54 map keyword, 66 map-block keyword, 67 on keyword, 32 opt keyword, 34 out keyword, 28 outbound traffic, 28 pass keyword, 28 performance improvement with, 40 port keyword, 29 portmap keyword, 66 processing order, 27, 63 proto icmp keep state, 37 proto keyword, 28 quick keyword, 31 rdr keyword, 68 removing, 43 return-icmp-as-dest keyword, 39 return-rst keyword, 39 Serviceguard, 122 swapping active and inactive rules lists, 42 taking effect, 42, 49, 57 to keyword, 28 with frags keyword, 35 with short keyword, 35

S
Serviceguard, 121 Cluster Object Manager, 125 filtering on a package IP address, 122 intra-cluster communication, 123

mandatory rules, 122 Quorum Server, 124 remote command execution, 124 Serviceguard Manager, 125 services, 122 single-user mode, 23 software, loading, 22 state aging, 37 state table dump, 82 static linking, 149 HP-UX 11i v1, 149 HP-UX 11i v2, 149 HP-UX 11i v3, 149 removing IPFilter software, 149, 150 sticky NAT sessions, 69 summary logs for cumulative limits, 55 supported interfaces, 128 swinstall, 22 swlist, 21 system configuration guidelines, 151 system traffic guidelines, 153

W
with frags keyword, 35 with short keyword, 35 WU-FTPD, 109

T
TCP configuration example, 138 TCP filtering, 29 TCP Wrapper, 77 testing IPFilter, 85 to keyword, 28 tracing layer 4, 94 tree structure, 40 troubleshooting, 92 rule change after using Bastille, 93 TTL counter, 82 tunneled packets IPv6, 47

U
UDP keeping state with, 37 negotiation with IPSec, 117 UDP filtering, 29 uname, 21 uninstalling IPFilter software static linking, 149, 150 unsupported interfaces, 128 unsupported utilities and commands, 128 updating keep limit rules, 57 utilities ipf, 95 ipfstat, 80 ipftest, 85 ipmon, 90 ipnat, 98 ippool, 99 unsupported, 128

159