HPUX Ip Filter

HP-UX IPFilter V17 Administrator Guide
HP-UX 11i v2 and HP-UX 11i 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 vendor’s standard commercial license.
Copyright Notice © Copyright 2001–2009 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
QXCR1000923645—Provide tunable to enable/disable NAT functionality..........................14
QXCR1000923671—Enhancement to list interfaces not covered..........................................14
QXCR1000888008—The ipfstat -io and ipfilter -q commands return the wrong
status.....................................................................................................................................14
QXCR1000866813—The ipfilter(8) command removes secondary and further IP
addresses by -d option.........................................................................................................14
QXCR1000926632—The pfilboot script does not unplumb interface when interface is
down.....................................................................................................................................14
QXCR1000926637—The ipfstat -Q command causes panic when pfil module is not
bound to any interface..........................................................................................................14
QXCR1000926726—Multicast packets more than 84 bytes are corrupted in IPFilter and
dropped in IP module...........................................................................................................14
QXCR1000950055—The ipmon utility does not format IP addresses and protocol
correctly.................................................................................................................................14
QXCR1000971666—ipfboot stop forces ip_forward_directed_broadcasts back
to 1 ........................................................................................................................................14
Fixes for HP-UX 11i v2...............................................................................................................15
QXCR1000923645—Provide tunable to enable/disable NAT functionality..........................15
QXCR1000926726—Multicast packets more than 84 bytes are corrupted in IPFilter and
dropped in IP module...........................................................................................................15
QXCR1000950055—The ipmon utility does not format IP addresses and protocol
correctly.................................................................................................................................15
QXCR1000971666—ipfboot 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
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
4 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
11 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.3 ICMP Redirects (ip_send_redirects)....................................................................................104
11.2.4 PMTU Discovery (ip_pmtu_strategy).................................................................................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 (icmpv6–type 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 9
List of Figures
14-1 IPFilter and IPSec ........................................................................................................................117
14-2 Scenario One................................................................................................................................117
14-3 Scenario Two................................................................................................................................118
14-4 Scenario Three.............................................................................................................................118
14-5 Packet with Unencrypted TCP Data............................................................................................119
14-6 Packet with IPSec-Encrypted TCP Data .....................................................................................119
14-7 Scenario Four...............................................................................................................................119
E-1 Processing packets through a system..........................................................................................151
E-2 System Operation........................................................................................................................154
10 List of Figures
List of Tables
1 Publishing History Details............................................................................................................17
11-1 ICMP Type and Codes.................................................................................................................101
A-1 HP-UX IPFilter Supported Interfaces........................................................................................129
E-1 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.
Rate-based filtering 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 pooling Address pools establish a single reference to name a group
of address/netmask pairs. For more information, see
Chapter 7 (page 73).
ipmon configuration file This new feature simplifies IPFilter log analysis and allows
monitoring for specific log events. For more information,
see “Logging IPFilter Packets” (page 88).
Rule tags 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).
State aging 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).
Named groups Rule groups can now be referenced by name. For more
information, see “Improving Performance with Rule
Groups ” (page 40).
Sticky NAT sessions 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 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).
Intended Audience 13
Fixes in this Release
Fixes for HP-UX 11i v3
QXCR1000923645—Provide 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.
QXCR1000923671—Enhancement 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, see“The ipfilter Utility (HP-UX 11i
v3)” (page 99).
QXCR1000888008—The 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.
QXCR1000866813—The 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.
QXCR1000926632—The 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.
QXCR1000926637—The 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.
QXCR1000926726—Multicast 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.
QXCR1000950055—The 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.
QXCR1000971666—ipfboot 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
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 11i v2

QXCR1000923645—Provide tunable to enable/disable NAT functionality.
performance.
QXCR1000926726—Multicast 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.
QXCR1000950055—The 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.
QXCR1000971666—ipfboot 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:
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:
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.
audit(5) A manpage. The manpage name is audit, and it is located in
Section 5.
Typographic Conventions 15
Command A command name or qualified command phrase.
Computer output Text displayed by the computer.
Ctrl+x 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.
ENVIRONMENT VARIABLE The name of an environment variable, for example, PATH.
[ERROR NAME] The name of an error, usually returned in the errno variable.
Key The name of a keyboard key. Return and Enter both refer to the
same key.
Term The defined use of an important word or phrase.
User input Commands and other text that you type.
Variable 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.
WARNING A warning calls attention to important information that if not
understood or followed will result in personal injury or
nonrecoverable system problems.
CAUTION 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.
IMPORTANT This alert provides essential information to explain a concept or
to complete a task
NOTE A note contains additional information to emphasize or
supplement important points of the main text.
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 Supported Operating Supported Versions Publication Date
Systems
5900–0395 11i v2 A.11.23.17 October 2009

11i v3 A.11.31.17
B9901-90044 11i v2 A.11.23.16 December 2008

11i v3 A.11.31.16
B9901-90042 11i v1 A.11.11.15.01 October 2007

11i v2 A.11.23.15.01
11i v3 A.11.31.15.01
B9901-90031 11i v1 A.03.05.14 December 2006

11i v2
5991-7705 11i v3 A.03.05.13 January 2007
B9901-90021 11.0 A.03.05.09 February 2004

11i v1
11i v2
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 IPFilter Version String
HP-UX 11i v3 A.11.31.17
HP-UX 11i v2 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)
The following major features are included with HP-UX IPFilter:
• 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
• 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. Check that your system meets the prerequisites. See “Step 1: Checking HP-UX IPFilter
Installation Prerequisites” (page 21) for detailed information about this task.
2. Install HP-UX IPFilter using swinstall. See “Step 2: Installing HP-UX IPFilter” (page 21)
for detailed information about this task.
3. Run the ipf -V and kmadmin commands to verify the installation as described in “Step 3:
Verifying the Installation” (page 23).
4. (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. Verify that you have superuser or appropriate capabilities.
2. 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. If you are installing HP-UX IPFilter from removable media (disk), insert the media (disk)
into the appropriate drive.
4. 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. Highlight the HP-UX IPFilter software for your system type.
7. 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.

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
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

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/

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

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 Result
< lt true if port is less than the specified value
> gt true if port is greater than the specified value
= eq true if port is equal to the specified value
!= ne true if port is not equal to the specified value
3.2 Basic Rule Syntax: Specifying the Action, Direction, Protocol, IP Addresses, and Ports 29
Operand Alias Result
<= le true if port is less than or equal to the specified value
>= ge 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.

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.

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:
[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. flags
2. with opt and with ipopt
3. with frag and with short
4. icmp-type and code
5. keep state
6. 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:

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 = 22 flags S keep state
block out all
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:
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.

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

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).

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:
• ICMP—60 seconds
• UDP—120 seconds
• TCP—120 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.
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 in quick on lan0 proto tcp from any to 20.20.20.1/32 port = 23 flags S keep state keep frags
pass out quick on lan0 proto tcp from any to any keep state flags S keep frags
block in log quick all
block out log quick all
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.

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 flags S keep state group 10
block out on lan2 all
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 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
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 = 80 flags S keep state group 10
pass out quick on lan1 proto udp from any to 20.20.20.65/32 port = 53 keep state group 10
pass out quick on lan1 proto udp from any to 20.20.20.66/32 port = 53 keep state group 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 in proto tcp from 1.0.0.0-9.0.0.0 to any port = 23 keep state head 1
pass in proto tcp from 2.0.0.0-8.0.0.0 to any port = 23 keep state head 2 group 1
pass in proto tcp from 5.0.0.0-5.5.0.0 to any port = 23 keep state 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:

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.

• 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).
3.9 Rule Tags 43

44
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 ipv6–icmp)
and use the keywords icmpv6-type and code. See “Filtering ICMPv6 Packets by Type and
Code (icmpv6–type 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.

4.3.3 IPv6 Extension Headers
You can block or pass packets according to IPv6 extension headers. A simplified rule syntax is
as follows
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
block in proto 41 from any to any
• 4-in-6
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.

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.
• “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: The default individual connection limit must be the last rule in the configuration
file.
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

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 records—created 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 records—created 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.

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. Enter the following command to add or modify rules in an inactive rules file:
ipf [-6] -If rules file
2. 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. Add the new rule on the line before the old rule which the new rule is to replace.
2. Delete the old rule.
5.9.2.2 To Add a New Subnet or IP Address Range Rule:

1. Add the new rule on the line before the old rule which the new rule is to replace.
2. 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.

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. Open /etc/rc.config.d/ipfconf, the IPFilter startup configuration file.
2. 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.11 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

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.11.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.11.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).

6 Configuring and Loading Network Address Translation
(NAT) Rules
• “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: 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

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

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.
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.
6.4.5.1 Syntax
l4check -f <config file>
6.4.5.2 Options
-n Stops action. No NAT rules are added or deleted.
-v 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
#
#
#
#
# targeted.
#
interface lan0 192.168.1.1,2100
#
#
#
# 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.254,8000

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. 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.
2. 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.

7 Address Pooling
This chapter describes address pooling. It contains the following sections:
• “The ippool Utility” (page 73)
• “The ippool.conf File” (page 73)
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 Defines the reference for the multiple addresses.
role Specifies the role of the pool IN. The only role for reference is ipf.
type 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. Configure pass rules with the quick keyword to allow packets for specific services by port
number and protocol.
2. 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 = 80
block in all
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 port = 513
block in all
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
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
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:
pass in all
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 on lan0 from 127.0.0.0/8 to an
pass in all
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:
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
• “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.
-6 Shows the output for IPv6 rules. This option is valid only with the following
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.
-o 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.
-h Displays the active rules and the number of matching packets (hit count)
for each rule. Use with the -i or -o options.
-s Displays state table statistics.
-sl Displays detailed state table statistics.
-n 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.
-L Displays global limit statistics.
-Lv 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.
-Q 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.

-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

Subnet 3
Cumulative 5
Unknown IP 9
Total 19
No Memory 0
Logged Records 13
Log Failures 0
Limits Added 13
Add Failures 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 Src IP Src Port Dest IP Dest Port Limit Current
S @0:3 10.39.1.2 * 10.133.1.5 80 50000 951 (0)
S @0:1 10.2.1.2 * 10.129.1.5 80 50000 942 (0)
U @0:1000 10.30.1.2 * 10.130.1.5 80 10 10(102)
U @0:1000 10.30.1.3 * 10.130.1.5 80 10 9 (501)
U @0:1000 10.30.1.4 * 10.130.1.5 80 10 10(100)
U @0:1000 10.30.1.5 * 10.130.1.5 80 10 10(118)
U @0:1000 10.30.1.6 * 10.130.1.5 80 10 10(196)
U @0:1000 10.30.1.7 * 10.130.1.5 80 10 10(198)
U @0:1000 10.30.1.8 * 10.130.1.5 80 10 10(104)
U @0:1000 10.30.1.0 * 10.130.1.5 80 10 10(111)
U @0:1000 10.49.1.2 * 10.131.1.5 80 10 10 (55)
U @0:1000 10.49.1.3 * 10.131.1.5 80 10 10 (53)
U @0:1000 10.49.1.4 * 10.131.1.5 80 10 10(102)
U @0:1000 10.49.1.5 * 10.131.1.5 80 10 9 (52)
U @0:1000 10.49.1.6 * 10.131.1.5 80 10 9 (52)
U @0:1000 10.49.1.7 * 10.131.1.5 80 10 10(103)
U @0:1000 10.49.1.8 * 10.131.1.5 80 10 10(120)
U @0:1000 10.49.1.9 * 10.131.1.5 80 10 10(50)
S @0:1000 10.40.1.2 * 10.134.1.5 80 50000 943(0)
U @0:1000 10.46.1.2 * 10.128.1.5 80 10 10 (49)
U @0:1000 10.46.1.3 * 10.128.1.5 80 10 10 (41)
• The Type column displays the type of limit being kept:
I—Fully resolved individual IP
S—IP subnet
C—Cumulative
U—Unknown 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.
The following is an example of the output information of the ipfstat -r group:rule option.
Limit Type Individual
Group:Rule Number @0:6
Configured Limit 7
Current connections 3
Limit Exceeded (#times) 33
TCP RSTs sent (#times) 33
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.

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 Specifies that the rules tested are IPv6 filter rules.
-r ruleset_filename Specifies the file from which to read rules.
-i input_filename 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 Specifies the interface name, such as lan0.
protocol Specifies the protocol name. Valid values are:
tcp
udp
icmp
icmpv6
src_host Specifies the source IP address or host name.
src_port Specifies the source TCP or UDP port number. You
must specify src_port if you specified the
protocol tcp or udp.
dest_host Specifies the destination IP address or host name.
dest_port Specifies the destination TCP or UDP port number.
You must specify dest_port if you specified the
protocol tcp or udp.
flags 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)
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
--------------
pass ip 28(20) 17 10.1.84.195,16000 > 10.1.85.196,16000
--------------
pass ip 28(20) 17 10.1.84.195,16000 > 10.1.80.196,16000
--------------
block ip 28(20) 17 10.1.85.195,16000 > 10.1.84.196,16000
--------------
block ip 28(20) 17 10.1.85.195,16000 > 10.1.85.196,16000
--------------

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
--------------
nomatch ip 28(20) 17 10.1.85.196,16000 > 10.1.84.195,16000
--------------
nomatch ip 28(20) 17 10.1.80.196,16000 > 10.1.84.195,16000
--------------
nomatch ip 28(20) 17 10.1.84.196,16000 > 10.1.85.195,16000
--------------
nomatch ip 28(20) 17 10.1.85.196,16000 > 10.1.85.195,16000
--------------
nomatch ip 28(20) 17 10.1.80.196,16000 > 10.1.85.195,16000
--------------
block ip 28(20) 17 10.1.81.195,16000 > 10.1.84.196,16000
--------------
block ip 28(20) 17 10.1.81.195,16000 > 10.1.85.196,16000
--------------
nomatch ip 28(20) 17 10.1.84.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
--------------
nomatch ip 28(20) 17 10.1.80.196,16001 > 10.1.84.195,16000
--------------
nomatch ip 28(20) 17 10.1.80.196,16001 > 10.1.85.195,16000
--------------
pass ip 28(20) 17 10.1.84.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 user mail
daemon auth syslog
lpr news uucp
cron ftp authpriv
audit logalert local0
local1 local2 local3
local4 local5 local6
local7
The valid values for priority are:
emerg alert crit
err warn notice
info debug
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.

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 Opens and reads data from all available log files.
Equivalent to -o NSI.
-o [NSI] Specifies which log file to read data from. Valid values are:
• N—NAT log file
• S—State log file
• I—IPFilter log file
-A Logs the summary records created for DCA logging.
-r Prints the summary records to the summary log file and
clears the block count for each limit entry.
-F Flushes the packet log buffer. Output displays the number
of bytes flushed.
-n Maps IP addresses and port numbers to host names and
services wherever possible.
-C <ipmon configuration Reads rules and actions from the configuration file.
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

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 1—Time stamp
• Field 2—The interface on which the event occurred
• Field 3—Rule group number: rule number of the rule used for the packet, in the format
@group_number:rule_number
• Field 4—Action; blocked (b) or passed (p) packet
• Field 5—Packet source, in the format ip_address,port
• Field 6—Packet destination, in the format ip_address,port
• Field 7 and 8—Protocol
• Field 9—Packet size
• Field 10—Flags 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.
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.
• The host does not seem to be on the network and ping messages do not go through.

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

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:
-6 Apply the action to the IPv6 filter ruleset or rulesets, or IPv6
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.
-Fi Flushes only the IN rules in the ruleset. If you specify this option
-Fo Flushes only the OUT rules in the ruleset. If you specify this option
-I 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.
-Z Zeroes out the TCP Connections counters displayed in the
ipfstat output.
-m d|e|q|t 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.
-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.
-D interface_name 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

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 Reads rules from a specified rules file.
-l Lists NAT rules and active mappings.
-C Deletes the current ruleset.
-F Flushes active mappings.
-r 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.

10.3 The ipfilter Utility (HP-UX 11i 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 Enables the HP-UX IPFilter module.
-d Disables the HP-UX IPFilter module.
-q Queries the HP-UX IPFilter module and displays whether it is enabled or disabled.
-l Lists the interfaces and shows which are protected or unprotected by IPFilter.
-ei Enables IPFilter in interactive mode.
-di Disables IPFilter in interactive mode.
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 Toggle debugging of processing the configuration file.
-n Prevents ippool from making ioctl calls or altering the running kernel.
-v Turns verbose mode on.
10.4.3 Command Options

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

11 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.
• “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 (icmpv6–type and code)” (page 106)
• “Controlling ICMPv6 Router Discovery and Neighbor Discovery Messages” (page 107)
11.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:
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 11-1 ICMP Type and Codes
Type Code icmp-type Meaning
icmp-code
0 0 echorep ECHO REPLY (ping reply) [RFC792]
3 unreach DESTINATION UNREACHABLE
0 net-unr network unreachable
1 host-unr host unreachable
2 proto-unr protocol unreachable
3 port-unr port unreachable [RFC792]
4 needfrag need fragmentation [RFC792]
5 srcfail source route failed [RFC792]
6 net-unk destination network unknown
7 host-unk destination host unknown
8 isolate source host isolated [RFC792] (ping)
11.1 Filtering ICMPv4 Packets by Type and Code (icmp-type and code) 101
Table 11-1 ICMP Type and Codes (continued)
Type Code icmp-type Meaning
icmp-code
9 net-prohib destination network administratively prohibited [RFC1256]
10 host-prohib destination host administratively prohibited [RFC1256]
11 net-tos network unreachable for TOS [RFC792]
12 host-tos host unreachable for TOS [RFC792]
13 filter-prohib prohibited by filtering [RFC1812]
14 host-preced host precedence violation [RFC1812]
15 cutoff-preced precendence cutoff in effect [RFC1812]
4 0 squench SOURCE QUENCH
5 redir REDIRECT
network
host
network & TOS
host & TOS
8 0 echo ECHO REQUEST (ping request)
0 routerad ROUTER ADVERTISEMENT
0 routesol ROUTER SOLICITATION
11 timex TIME EXCEEDED
TTL=0 during transmit
TTL=0 during reassembly
12 paramprob PARAMETER PROBLEM
13 0 timest TIMESTAMP REQUEST
14 0 timestrep TIMESTAMP REPLY
15 0 inforeq INFO REQUEST (obsolete)
16 0 inforep INFO REPLY (obsolete)
17 0 maskreq ADDRESS MASK REQUEST
18 0 maskrep ADDRESS MASK REPLY
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.
11.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:
• “Dead Gateway Detection (ip_ire_gw_probe)” (page 103)
• “ICMP Source Quench (ip_send_source_quench)” (page 103)

• “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)).
11.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 Valid Values Default Value
ip_ire_gw_probe 0 (disable) 1
1 (enable)
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.
11.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
11.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.
ip_send_source_quench 0 (disable) 1
1 (enable)

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
11.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.
ip_send_redirects 0 (disable) 1
1 (enable)

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
11.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.
ip_pmtu_strategy 0 (disable and use 576 bytes as the PMTU) 1

1 (enable)
2 (deprecated)
3 (disable and use the link-local MTU as the
PMTU)

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

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.
11.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.
ip_respond_to_echo_broadcast 0 (disable) 1
1 (enable)
11.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

11.3 Filtering ICMPv6 Packets by Type and Code (icmpv6–type 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 ip_selector
icmpv6-type type_value [code code_value]
where:
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

11.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.
ipf_icmp6_passthru 0 (Router Discovery and Neighbor 0

Discovery messages bypass
IPFilter)
1 (IPFilter filters Router Discovery
and Neighbor Discovery
messages)
11.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.
11.4.1.1 Configuring ipf_icmp6_passthru on HP-UX 11i v2 and HP-UX 11i 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).
11.4.1.2 Configuring ipf_icmp6_passthru on HP-UX 11i 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 session—active 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 Direction of Connection FTP Client

Initiated
port 21 (control port) <---------------- any port 1024 or higher
port 20 (data port) ----------------> 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 out from any to any
12.3.2 Passive FTP

Initiated
any port 1024 or higher (data port) <---------------- 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
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

Initiated
port 20 (data port) ----------------> 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
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

Initiated
any port 1024 or higher (data port) <---------------- 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 proto tcp from client_ip port > 1023 to any port = 21 flags S keep state
pass out quick proto tcp from client_ip port > 1023 to any port > 1023 flags S keep state
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 services—rpc.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. 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).
2. 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. Create an empty RPC rules file.
touch /etc/opt/ipf/rpc.ipf/rpc.rules
4. 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 B
10.10.10.10 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 B
10.10.10.10 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

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 user’s
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 B
10.10.10.10 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
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.

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
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.
The classes of mandatory rules cover:
• Intra-Cluster Communication
• Quorum Server
• Remote Command Execution
• Cluster Object Manager
• Serviceguard Manager
Do not block traffic for the following ports:
hacl-qs 1238/tcp # High Availability (HA) Quorum Server
clvm-cfg 1476/tcp # HA LVM configuration
hacl-hb 5300/tcp # High Availability (HA) Cluster heartbeat
hacl-hb 5300/udp # High Availability (HA) Cluster heartbeat
hacl-gs 5301/tcp # HA Cluster General Services
hacl-cfg 5302/tcp # HA Cluster TCP configuration
hacl-cfg 5302/udp # HA Cluster UDP configuration
hacl-probe 5303/tcp # HA Cluster TCP probe
hacl-probe 5303/udp # HA Cluster UDP probe

hacl-local 5304/tcp # HA Cluster commands
hacl-test 5305/tcp # HA Cluster test
hacl-dlm 5408/tcp # HA Cluster distributed lock manager
hacl-poll 5315/ tcp #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 49152–65535 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 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 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
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:

# 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

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 in quick proto tcp from smh_mgmt to cluster_nodes port = 2381 keep state
pass in quick proto udp from smh_mgmt to cluster_nodes port = 2381 keep state
pass in quick proto tcp from smh_mgmt to cluster_nodes port = 2301 keep state
pass in quick proto udp from smh_mgmt to cluster_nodes port = 2301 keep 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.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.

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
HP-UX A.11.xx.17
• VLAN
• FDDI
• Token Ring
• InfiniBand (supported on HP-UX 11i v2 only)
• X.25 (supported on HP-UX 11i v3 only)
• 10 Gigabit Ethernet
• APA
HP-UX A.11.xx.16
• VLAN
• FDDI
• Token Ring
• APA
HP-UX A.11.xx.15.01 • VLAN
• FDDI
• Token Ring
Open source versions: • Ethernet (10Base-T)

A.03.05.14 (HP-UX 11i v1 and HP-UX 11i v2) • Fast Ethernet (100Base-T)
A.03.05.13 (HP-UX 11i v3) • Gigabit Ethernet (1000Base-T)
• APA
A.03.05.12
• VLAN
A.03.05.11.01 • FDDI
A.03.05.10 • Token Ring
A.03.05.10.02 • InfiniBand (supported on HP-UX 11i v2 only)
A.03.05.10.04
A.03.05.06.v2
Open source versions:
A.03.05.09 • Gigabit Ethernet (1000Base-T)
A.03.05.08 • APA
A.03.05.07 • VLAN
A.03.05.06 • 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 aren’t 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
#-------------------------------------------------------
# Invalid Internet packets.
# =========================
#
# Deny reserved addresses.
#
#
# 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
#
#
#
# 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.
#
#
# 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 aren’t on the
# loopbackinterface should *NOT* exist
#-------------------------------------------------------
# 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.
#
# #
# 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
B.3 example.1 133

#
#
# block all outbound packets.
#
# #
# 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
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

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.11 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.11
#
# 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

# 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 any inbound TCP packets with only the SYN flag set that
# are destined for these subnets.
#
#
# 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
B.17 firewall
#Configuring IP Filter for firewall usage.
=========================================
Step 1 - Block out "bad" IP packets.

------------------------------------
Run the perl script "mkfilters". This will generate a list of blocking rules which:
a) blocks all packets which might belong to an IP Spoofing attack;
b) blocks all packets with IP options;
c) 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 which you wish to connect or

if it doesn’t have a proper name, a number can be used. The
translation of "ext-service" as a name to a number is
controlled with the /etc/services 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.
# We’re 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
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
#

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
#
#
#
# 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
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
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.

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
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 Description Default Value
fr_tcpidletimeout The timeout period for TCP entries in the state table. 86,400 seconds
fr_statemax Specifies the maximum number of state table entries that 800,000 entries
can be created.
ipf_icmp6_passthru If set to 0, IPFilter allows ICMPv6 Router Discovery and 0

Neighbor Discovery messages to bypass normal IPFilter
rule processing and always pass through the system.
ipl_buffer_sz Size of the IPFilter logging buffer for /dev/ipl. 8192 bytes
ipl_suppress If enabled (set to 1), IPFilter does not write identical log 1 (enabled)
records separately, but counts them as Nx, where N is the
number of times the log record occurs.
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.
ipnat_enable Used to enable or disable NAT functionality. Value can be 1 (enabled)

0 or 1. This is supported on 11.23 and 11.31. It is modified
using the kctune command.
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.
frnat_tcptimewait 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.
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 Range Default Value Configuration Utility
fr_tcpidletimeout HP-UX 11i v1: 300 - 86,400 86,400 seconds (24 HP-UX 11i v1: kmtune
seconds hours) HP-UX 11i v2 and HP-UX 11i
HP-UX 11i v2 and HP-UX 11i v3: v3: kctune
240 - 86,400 seconds
C.3 fr_statemax
The fr_statemax parameter specifies the maximum number of entries in the IPFilter state
table.
fr_statemax 4,000 - 1,600,00 entries 800,000 entries 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.
ipl_buffer_sz 1024 - 163840 bytes 8192 bytes 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.
ipl_suppress 0 (disabled) - 1 (enabled) 1 HP-UX 11i v1 and HP-UX 11i v2: ndd
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).
ipl_logall 0 (disabled) - 1 (enabled) 0 HP-UX 11i v1 and HP-UX 11i v2: ndd
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 11i 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
kctune parameter_name
For example:
kctune ipl_logall
C.6 ipl_suppress 145

C.8.2 Configuring Kernel Tunable Parameters on HP-UX 11i v1 and HP-UX 11i 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
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
4. Reload the ipf module:
/sbin/init.d/ipfboot start
C.9 Enabling and Disabling NAT Functionality

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 11i v2 and HP-UX 11i 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 11i 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 ID Status Type
pfil 1 LOADED STREAMS
ipf 2 LOADED 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 Configured Loadable
pfil Y 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 Configured Loadable
ipf Y N
$ kmsystem -l N -c Y pfil
4. Use the following command to build the new kernel with the modified configuration:
$config /stand/system
5. 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 Packets to the Internet
1 Packets enter the system 5 Packets enter the system
2 Processed by inbound IPFilter processing 6 Processed by inbound IPFilter processing
3 Processed by outbound IPFilter processing 7 Processed by outbound IPFilter processing
4 Packets leave the system 8 Packets leave the system
Packets are processed twice (2 and 3) Packets are processed twice (6 and 7)
1. 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.
2. 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. 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.
4. 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.
.
(15.13.2.3 to 15.13.2.99)
.
152 Performance Guidelines

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
.
(15.13.2.3 to 15.13.2.99)
.
• Consolidate rules whenever possible, to minimize searching. For example:
pass in quick proto tcp from 15.13.103.72 to any keep limit 80
pass in quick proto tcp from 15.13.103.0-15.13.103.6 to any keep limit 44
pass in quick proto tcp from 15.13.104.0/24 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
Dynamic Connection Allocation (see DCA)
A dynamic linking, 149
active rules list, 42
adding keep limit rules, 58 E
address pooling, 73 enabling, 99
examples
B configuration
bidirectional filtering basic, 131, 132
in keyword, 28 TCP, 138
out keyword, 28 extension headers
bidirectional filtering with IPSec, 118 IPv6, 47
bimap keyword, 71 extracting keep limit rules, 59
block keyword, 28
blocked traffic F
IPSec filtering
correcting, 118 bidirectional, 28
by interface, 32
C by IP address, 28
checklist by subnet, 28
installation and configuration, 21 by TCP header flags, 33
commands ICMP packets, 35, 101
unsupported, 128 IP address and interface, 28
configuration IPv6, 46
checklist, 21 localhost, 77
DCA rules file, 52 on IP options, 34
IPv6 rules file, 45 package IP address, 122
NAT rules file, 63 port number, 29
rules file, 27 rate-based, 30
rules processing, 27, 63 filtering on flags
verifying, 23 confusing with keeping state, 36
configuration examples, 131 firewall
configuring basic configuration, 26
file conventions, 27, 42, 45, 49, 63 flags keyword, 33
configuring kernel tunables, 145 fr_statemax, 144
configuring variables, 146 fr_tcpidletimeout, 144
fragmentation
D IPv6, 48
DCA from keyword, 28
file configuration, 52 FTP
keywords, 53 active FTP
logging command, 91 client, 110
overview, 52 server, 110
processing commands, 97 how it works, 109
remote failover, 126 passive FTP
rule modifications, 57 client, 111
setting mode, 60, 96 server, 110
syntax, 53 WU-FTPD, 109
DCA keywords
keep limit, 53 G
log limit, 54 group keyword, 40
log limit freq, 55
DCA_START configuration option, 60 H
debugging high availability, 121
ipfstat utility, 81
Denial of Service attack defense, 28 I
disabling, 99 ICMP
155
error status messages, 37 -q option, 99
filtering on, 35, 101 IPFilter modules
keeping state with, 37 ipf, 149
icmp-type keyword, 35, 101 pfil, 149
ICMPv6 ipfstat, 80
IPv6, 46 -6 option, 80
in keyword, 28 -h option, 80
inactive rules list, 42 -i option, 80
installation -L option, 80, 82
checklist, 21 -Lv option, 80
loading software, 22 -n option, 82
prerequisites, 21 -o option, 80
verifying, 23 -r option, 80, 84
integrating keep limit rules, 58 -s option, 82
interface-specific filtering, 32 -sl option, 82
interfaces -v option, 81
supported, 128 -vL option, 83
unsupported, 128 ipfstat -io option, 82
interoperability ipfstat -Q option, 80
IPSec, 117 ipftest, 85
IP address -i option, 85
filtering by, 28 -r option, 85
limiting connections by, 53 input file format, 85
ipf, 95 ipl_buffer_sz, 144
-6 option, 95 ipl_logall, 145
-A option, 42 ipl_suppress, 145
-D option, 96 ipmon, 88, 90, 92, 93
-E option, 96 -A option, 90
-f option, 42, 49 -a option, 90
-Fa option, 42, 96 -C option, 90
-Fi option, 96 -F option, 90
-Fo option, 96 -o option, 90
-I option, 42, 96 -r option, 55, 90
-m d option, 60, 96 ipnat, 63, 98
-m e option, 60, 96 -C option, 98
-m option, 96 -F option, 98
-m q option, 60, 96 -f option, 98
-m t option, 60, 96 -l option, 98
-Q option, 97 -r option, 98
-s option, 42, 96 ipopts keyword, 34
-V option, 23 ippool, 73, 99
-Z option, 96 -A option, 100
adding rules, 42, 49 -a option, 100
IPv6, 49 -d option, 100
ipf module, 149 -F option, 100
ipf.conf -f option, 100
bootup start, 42, 49 -i option, 100
syntax in, 27 -l option, 100
ipfboot, 92, 127 -m option, 100
IPFilter -n option, 100
disabling, 99 -o option, 100
enabling, 99 -r option, 100
removing, 23 -s option, 100
ipfilter, 99 -t option, 100
-d option, 99 -v option, 100
-di option, 99 -z option, 100
-e option, 99 ippool.conf, 73
-ei option, 99 IPSec
-l option, 99 allowing protocol 50 and 51 traffic through, 119
156 Index
allowing traffic through the firewall, 118 icmp-type, 35, 101
bidirectional with IPFilter, 118 in, 28
debugging blocked traffic with, 118 ipopts, 34
gateway, 120 keep frags, 38
UDP negotiation, 117 keep limit, 53
IPSec and IPFilter, 117 keep state, 35
IPv6 log, 31, 88
differences, 46 log limit, 54
extension headers, 47 log limit freq, 55
features, 46 map, 66
file configuration, 45 map-block, 67
filter rules, 46 on, 32
fragmentation, 48 opt, 34
ICMPv6 filtering, 46 out, 28
ipf, 49 pass, 28
protocol-based filtering, 46 port, 29
rules configuration, 45 portmap, 66
stateful ICMPv6, 46 proto, 28
tunneled packets, 47 quick, 31
unsupported features, 46, 128 rdr, 68
return-icmp-as-dest, 39
K return-rst, 39
kcmodule, 23 to, 28
static linking, 149 with frags, 35
kctune, 145 with short, 35
keep frags keyword, 38 kmadmin
keep limit static linking, 149
keyword, 53 kmsystem
keep limit rules static linking, 150
adding, 58 kmtune, 146
adding a subnet or IP address range rule, 58 kmupdate
adding individual rule, 58 static linking, 150
changing current rule, 57
extracting, 59 L
integrating, 58 l4check, 69
rule hits, 61 limiting connections
updating, 57 by IP address, 53
updating a subnet or IP address range, 58 by subnet, 54
keep state cumulative, 54
ICMP, 37 default individual limit, 54
keyword, 35, 36 loading software, 22
state table dump, 82 localhost filtering, 77
when to use, 36 log keyword, 31, 88
keeping state body option, 89
UDP, 37 first option, 88
with servers and flags, 36 log limit freq keyword, 55
kernel tunables log limit keyword, 54
configuring, 145 log tags, 43
fr_statemax, 144 logging, 92
fr_tcpidletimeout, 144 packets, 31
ipl_buffer_sz, 144 problems, 93
ipl_logall, 145 logging exceeded connections, 54
ipl_suppress, 145 logging techniques, 88
keywords
bimap, 71 M
block, 28 map keyword, 66
flags, 33 map-block keyword, 67
from, 28 memory allocation, 144
group, 40 modifying DCA rules, 57
157
monitoring IPFilter, 90 return-rst keyword, 39
multi-level grouping, 40 rule configuration guidelines, 152
rule groups, 40
N rule loading guidelines, 152
NAT rule tags, 43
file configuration, 63 rules
viewing and loading rules, 98 active list, 42
NAT keywords adding rules to a rules file, 42, 49
bimap, 71 bimap keyword, 71
map, 66 block keyword, 28
map-block, 67 errors occur when loading, 93
portmap, 66 file configuration, 27
rdr, 68 flags keyword, 33
nat tags, 43 flushing, 42
netstat, 94 from keyword, 28
nslookup, 37 grouping, 40
icmp-type keyword, 35, 101
O in keyword, 28
on keyword, 32 inactive list, 42
opt keyword, 34 interface-specific, 32
out keyword, 28 IP address-specific, 28
ipopts keyword, 34
P IPv6, 45
package IP address, 122 keep frags keyword, 38
pass keyword, 28 keep limit keyword, 53
patch dependencies, 21 keep state keyword, 35, 36
performance guidelines, 151 log keyword, 31, 88
performance monitoring, 154 log limit freq keyword, 55
rule configuration, 152 log limit keyword, 54
rule loading, 152 map keyword, 66
system configuration, 151 map-block keyword, 67
traffic, 153 on keyword, 32
performance improvement, 40 opt keyword, 34
performance information, 80 out keyword, 28
performance monitoring guidelines, 154 outbound traffic, 28
pfil module, 149 pass keyword, 28
ping, 37 performance improvement with, 40
port keyword, 29 port keyword, 29
port number filtering, 29 portmap keyword, 66
portmap keyword, 66 processing order, 27, 63
prerequisites proto icmp keep state, 37
installation, 21 proto keyword, 28
patch dependencies, 21 quick keyword, 31
proto keyword, 28 rdr keyword, 68
protocol 50 and 51 traffic, 119 removing, 43
protocol-based filtering return-icmp-as-dest keyword, 39
IPv6, 46 return-rst keyword, 39
Serviceguard, 122
Q swapping active and inactive rules lists, 42
quick keyword, 31 taking effect, 42, 49, 57
to keyword, 28
R with frags keyword, 35
rdr keyword, 68 with short keyword, 35
reloading IPFilter, 92
removing, 23 S
removing IPFilter software Serviceguard, 121
static linking, 149, 150 Cluster Object Manager, 125
reporting problems, 37, 94 filtering on a package IP address, 122
return-icmp-as-dest keyword, 39 intra-cluster communication, 123
158 Index
mandatory rules, 122 W
Quorum Server, 124 with frags keyword, 35
remote command execution, 124 with short keyword, 35
Serviceguard Manager, 125 WU-FTPD, 109
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
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

HPUX Ip Filter

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HPUX Ip Filter

Transféré par

Droits d'auteur :

Formats disponibles

HP-UX IPFilter V17 Administrator Guide

HP-UX 11i v2 and HP-UX 11i v3

HP Part Number: 5900-0395A

Trademark Notices UNIX® is a registered trademark of The Open Group.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

New and Changed Information in This Edition

New Features in this Release

QXCR1000923671—Enhancement to list interfaces not covered.

QXCR1000866813—The ipfilter(8) command removes secondary and further IP addresses

QXCR1000971666—ipfboot stop forces ip_forward_directed_broadcasts back to

Fixes for HP-UX 11i v2

QXCR1000971666—ipfboot stop forces ip_forward_directed_broadcasts back to

5900–0395 11i v2 A.11.23.17 October 2009

B9901-90044 11i v2 A.11.23.16 December 2008

B9901-90042 11i v1 A.11.11.15.01 October 2007

B9901-90031 11i v1 A.03.05.14 December 2006

5991-7705 11i v3 A.03.05.13 January 2007

B9901-90021 11.0 A.03.05.09 February 2004

HP Encourages Your Comments

OS Version HP-UX IPFilter Version String

HP-UX 11i v3 A.11.31.17

HP-UX 11i v2 A.11.23.17

1.1 Benefits and Features

1.2 Supported and Unsupported Features

2.1 Overview of HP-UX IPFilter Installation

2.1.1 Installation and Configuration Checklist

2.2 Step 1: Checking HP-UX IPFilter Installation Prerequisites

2.3 Step 2: Installing HP-UX IPFilter

2.1 Overview of HP-UX IPFilter Installation 21

22 Installing HP-UX IPFilter

2.4 Step 3: Verifying the Installation

2.5 Step 4: (Optional) Modifying Kernel Tunable Parameters

2.6 Removing HP-UX IPFilter

2.4 Step 3: Verifying the Installation 23

24 Installing HP-UX IPFilter

26 Configuring and Loading IPv4 Filter Rules

3.1.2 Rule Order and Processing

3.1 IPv4 Filter Rules Configuration File 27

3.2.1 pass and block: Specifying the Filter Action

3.2.2 in and out: Specifying the Filter Direction

3.2.3 proto: Specifying the Upper Layer Protocol

3.2.4 from and to: Specifying IP Addresses and Subnets

28 Configuring and Loading IPv4 Filter Rules

3.2.4.2 all: Specifying All IP Addresses

3.2.5 port: Specifying TCP and UDP Ports

Operand Alias Result

< lt true if port is less than the specified value

> gt true if port is greater than the specified value

= eq true if port is equal to the specified value

!= ne true if port is not equal to the specified value