IPF(4)IPF(4)NAME
ipf, ipf.conf, ipf6.conf - files containing filter rules for HP-UX
IPFilter
DESCRIPTION
The and files contain filter rules for HP-UX IPFilter. By default, HP-
UX IPFilter reads IPv4 filter rules from the file file and reads IPv6
filter rules from the file at system startup time. You can specify
alternate rule files for system startup time in the file You can also
specify alternate filter rule files in the runstring. The utility can
also read files from
GRAMMAR
The format for filter rules can be described using the following gram‐
mar in Backus-Naur Form (BNF):
filter-rule = [ insert ] action in-out [ options ] [ tos ] [ ttl ]
[ proto ] [ ip ] [ group ] .
insert = "@" decnumber .
action = block | "pass" | log | "count" | skip | auth | call .
in-out = "in" | "out" .
options = [ log ] [ "quick" ] [ "on" interface-name ] .
tos = "tos" decnumber | "tos" hexnumber .
ttl = "ttl" decnumber .
proto = "proto" protocol .
ip = srcdst [ flags ] [ with withopt ] [ with v6hdrs ] [ icmp ] [ keep ] .
group = [ "head" decnumber ] [ "group" decnumber ] .
block = "block" [ icmp[return-code] | "return-rst" ] .
auth = "auth" | "preauth" .
log = "log" [ "body" ] [ "first" ] [ "or-block" ] [ "level" loglevel ]
["limit" | "limit" "freq" decnumber ] .
call = "call" [ "now" ] function-name .
skip = "skip" decnumber .
protocol = "tcp/udp" | "udp" | "tcp" | "icmp" | "icmpv6" | decnumber .
srcdst = "all" | fromto .
fromto = "from" [ "!" ] object "to" [ "!" ] object .
icmp = "return-icmp" | "return-icmp-as-dest" .
icmpv6 = "return-icmpv6" | "return-icmpv6-as-dest" .
object = addr [ port-comp | port-range ] .
addr = "any" | iprange | nummask | host-name [ "mask" ipaddr | "mask" hexnumber ] .
port-comp = "port" compare port-num .
port-range = "port" port-num range port-num .
flags = "flags" flag { flag } [ "/" flag { flag } ] .
with = "with" | "and" .
icmp = "icmp-type" icmp-type [ "code" decnumber ] .
icmpv6 = "icmpv6-type" decnumber [ "code" decnumber ] .
return-code = "("icmp-code")" .
keep = "keep" "state" | "keep" "frags" | "keep" "state" "keep" "frags"
| "keep" "limit" count | "keep" "limit" count "cumulative" .
loglevel = facility"."priority | priority .
count = decnumber .
nummask = host-name [ "/" decnumber ] .
iprange = ipaddr"-"ipaddr .
host-name = ipaddr | hostname | "any" .
ipaddr = host-num "." host-num "." host-num "." host-num .
host-num = digit [ digit [ digit ] ] .
port-num = service-name | decnumber .
withopt = [ "not" | "no" ] opttype [ withopt ] .
opttype = "ipopts" | "short" | "frag" | "opt" ipopts .
v6hdrs = v6opttype .
optname = ipopts [ "," optname ] .
v6opttype = "hopopts" | "dstopts" | "routing" | "ah" | "esp" | "mobility" | "ipv6" .
ipopts = optlist | "sec-class" [ secname ] .
secname = seclvl [ "," secname ] .
seclvl = "unclass" | "confid" | "reserv-1" | "reserv-2" | "reserv-3" |
"reserv-4" | "secret" | "topsecret" .
icmp-type = "unreach" | "echo" | "echorep" | "squench" | "redir" |
"timex" | "paramprob" | "timest" | "timestrep" | "inforeq" |
"inforep" | "maskreq" | "maskrep" | decnumber .
icmp-code = decumber | "net-unr" | "host-unr" | "proto-unr" | "port-unr" |
"needfrag" | "srcfail" | "net-unk" | "host-unk" | "isolate" |
"net-prohib" | "host-prohib" | "net-tos" | "host-tos" |
"filter-prohib" | "host-preced" | "cutoff-preced" .
optlist = "nop" | "rr" | "zsu" | "mtup" | "mtur" | "encode" | "ts" |
"tr" | "sec" | "lsrr" | "e-sec" | "cipso" | "satid" | "ssrr" |
"addext" | "visa" | "imitd" | "eip" | "finn" .
facility = "kern" | "user" | "mail" | "daemon" | "auth" | "syslog" |
"lpr" | "news" | "uucp" | "cron" | "ftp" | "authpriv" |
"audit" | "logalert" | "local0" | "local1" | "local2" |
"local3" | "local4" | "local5" | "local6" | "local7" .
priority = "emerg" | "alert" | "crit" | "err" | "warn" | "notice" |
"info" | "debug" .
hexnumber = "0" "x" hexstring .
hexstring = hexdigit [ hexstring ] .
decnumber = digit [ decnumber ] .
compare = "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" |
"gt" | "le" | "ge" .
range = "<>" | "><" .
hexdigit = digit | "a" | "b" | "c" | "d" | "e" | "f" .
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" .
flag = "F" | "S" | "R" | "P" | "A" | "U" .
This syntax is somewhat simplified for readability; some combinations
that match this grammar are disallowed by the software because they do
not make sense (such as tcp for non-TCP packets).
HP-UX IPFilter is enhanced to support the keyword which provides
Dynamic Connection Allocation (DCA) functionality. See the IPFilter
product manual for information. DCA is not supported on HP-UX 11.00.
FILTER RULES
The simplest valid rules are currently no-ops and are of the form:
block in all
pass in all
log out all
count in all
By default, IPFilter evaluates the rules sequentially and applies the
last rule that matches the packet. You can modify this behavior by
specifying the keyword in a rule, as described below.
By default, IPFilter adds new rules at the end of the active ruleset,
which is stored in the kernel. Prepending a rule with causes it to be
inserted as the nth entry in the current list. This is useful when mod‐
ifying and testing active filter rulesets. See ipf(1) for more informa‐
tion.
ACTIONS
The action indicates what to do with the packet if it matches the rest
of the filter rule. Each rule MUST have an action. IPFilter supports
the following actions:
indicates that the packet should be flagged to be dropped. In response
to blocking a packet, the filter may be instructed to send a
reply packet, either an ICMP packet an ICMP packet masquerading
as being from the original packet's destination or a TCP RESET
An ICMP packet may be generated in response to any IP packet,
and its type may optionally be specified, but a TCP reset may
only be used with a rule which is being applied to TCP packets.
If you specify or IPFilter sends an ICMP Destination Unreachable
message. You can specify the ICMP type for the Destination
Unreachable message, such as Network Unreachable, Port Unreach‐
able or Administratively Prohibitied. To do this, specify the
ICMP code, enclosed in parentheses after or as follows. You can
specify the code as a decimal value, or use the code names
listed in the definition shown for in the BNF syntax. For exam‐
ple:
block return-icmp(11) ...
returns a ICMP message with type Destination Unreachable and
code Type-Of-Service (TOS).
flags the packet to be let through the filter.
causes the packet to be logged (as described in the LOGGING section
below) and has no effect on whether the packet is allowed
through the filter.
causes the packet to be included in the accounting statistics kept by
the filter, and has no effect on whether the packet is allowed
through the filter. These statistics are viewable with ipfs‐
tat(8).
this action is used to invoke the named function in the kernel, which
must conform to a specific calling interface. Customised actions
and semantics can thus be implemented to supplement those avail‐
able. This feature is for use by knowledgeable hackers, and is
not currently documented.
causes the filter to skip over the next n filter rules. If a rule is
inserted or deleted inside the region being skipped over, then
the value of n is adjusted appropriately.
this allows authentication to be performed by a user-space program run‐
ning
and waiting for packet information to validate. The packet is
held for a period of time in an internal buffer whilst it waits
for the program to return to the kernel the real flags for
whether it should be allowed through or not. Such a program
might look at the source address and request some sort of
authentication from the user (such as a password) before allow‐
ing the packet through or telling the kernel to drop it if from
an unrecognised source.
tells the filter that for packets of this class, it should look in the
pre-authenticated list for further clarification. If no further
matching rule is found, the IPFilter drops the packet (the
FR_PREAUTH is not the same as FR_PASS). If a further matching
rule is found, the result from that is used instead. This might
be used in a situation where a person logs in to the firewall
and it sets up some temporary rules defining the access for that
person. The next word must be either or Each packet moving
through the kernel is either inbound (just been received on an
interface, and moving towards the kernel's protocol processing)
or outbound (transmitted or forwarded by the stack, and on its
way to an interface). There is a requirement that each filter
rule explicitly state which side of the I/O it is to be used on.
OPTIONS
The list of options is brief, and all are indeed optional. Where
options are used, they must be present in the order shown here. These
are the currently supported options:
indicates that if this the last last matching rule, IPFilter
will write the packet header to the log (as described in the
LOGGING section below).
modifies rule processing so that if
a packet matches the filter rule, this rule will be the last
rule checked, and IPFilter immediately stops processing rules
for the packet. The current status of the packet (after any
effects of the current rule) determine whether it is passed or
blocked.
If this option is missing, the rule is taken to be a "fall-
through" rule, meaning that the result of the match (block/pass)
is saved and IPFilter continues processing rules to see if there
are any more matches.
allows an interface name to be incorporated into the matching
procedure. Interface names are as printed by If this option is
used, the rule only matches if the packet is going through that
interface in the specified direction (in/out). If this option is
absent, the rule is taken to be applied to a packet regardless
of the interface it is present on (i.e. on all interfaces).
Filter rulesets are common to all interfaces, rather than having
a filter list for each interface.
This option is especially useful for simple IP-spoofing protec‐
tion: packets should only be allowed to pass inbound on the
interface from which the specified source address would be
expected, others may be logged and/or dropped.
MATCHING PARAMETERS
The keywords described in this section are used to describe attributes
of the packet to be used when determining whether rules match or don't
match. The following general-purpose attributes are provided for match‐
ing, and must be used in this order:
packets with different Type-Of-Service values can be filtered.
Individual service levels or combinations can be filtered upon.
The value for the TOS mask can either be represented as a hex
number or a decimal integer value.
packets may also be selected by their Time-To-Live value. The value
given in
the filter rule must exactly match that in the packet for a
match to occur. This value can either be represented as a hexa‐
decimal number or a decimal integer value.
allows a specific protocol to be matched against. All protocol names
found in /etc/protocols are recognised and may be used. How‐
ever, the protocol may also be given as a DECIMAL number, allow‐
ing for rules to match your own protocols, or new ones which
would out-date any attempted listing.
The special protocol keyword matches either a TCP or a UDP
packet, and has been added as a convenience to save duplication
of otherwise-identical rules.
The and keywords are used to match against IP addresses (and optionally
port numbers). Rules must specify BOTH source and destination parame‐
ters.
IP addresses may be specified in one of two ways: as or as
You can also use the reserved word to match all IP addresses.
A numerical_address can be an IPv4 address in dotted-decimal notation,
or an IPv6 address in colon-hexadecimal notation. A numerical address
can also be specified as a decimal value, or as hexadecimal value pre‐
fixed by
A hostname must be a valid hostname, from either the hosts file or DNS
(depending on your configuration and library). There is no special
designation for networks but network names are recognised. Note that
if you specify a hostname, DNS may be used to resolve the hostname to
an IP address, which can introduce a security vulnernability. HP recom‐
mends that you do not use hostnames in rules.
For IPv4 addresses, the value for mask can be a decimal number indicat‐
ing a prefix length, or an IPv4 network bitmask in dotted-decimal or
hexadecimal notation. For IPv6 addresses, the value for mask must be a
decimal number indicating a prefix length. Note that all the bits of
the IP address indicated by a bitmask must match the address on the
packet exactly; there isn't currently a way to invert the sense of the
match, or to match ranges of IP addresses which do not express them‐
selves easily as bitmasks.
If the source or destination address specification includes a number
destination, then it is applied only to TCP or UDP packets. If the rule
does not specify a parameter, IPFilter checks the port number in both
TCP and UDP packets. This is equivalent to specifying The value for a
can be a service name defined in /etc/services or an integer port num‐
ber. Port comparisons may be done in a number of forms, with a number
of comparison operators, or port ranges may be specified. When the port
is specified as part of a object, it matches the source port number;
when it is specified as part of the object, it matches the destination
port number. See the examples for more information.
Specifying the keyword is equivalent to specifying with no other match
parameters.
Following the source and destination matching parameters, the following
additional parameters may be used:
is used to match irregular attributes that some packets may have
associated with them. To match the presence of IP options in
general, use To match packets that are too short to contain a
complete header, use To match fragmented packets, use For more
specific filtering on IP options, individual options can be
listed.
You can insert or before any arguments used after the keyword to
only match if the option or options are not present.
You can specify multiple, consecutive clauses. Alternatively,
you can specify the keyword instead of to make the rules more
readable ("with ... and ..."). When multiple clauses are
listed, they must all match to cause a match of the rule.
is only effective for TCP filtering. Each of the letters possible
represents one of the possible flags that can be set in the TCP
header. The association is as follows:
F - FIN
S - SYN
R - RST
P - PUSH
A - ACK
U - URG
The various flag symbols may be used in combination, so that
"SA" would represent a SYN-ACK combination present in a packet.
There is nothing preventing the specification of combinations,
such as "SFR", that would not normally be generated by law-abid‐
ing TCP implementations. However, to guard against weird aber‐
rations, it is necessary to state which flags you are filtering
against. To allow this, it is possible to set a mask indicating
which TCP flags you wish to compare (i.e., those you deem sig‐
nificant). This is done by appending "/<flags>" to the set of
TCP flags you wish to match against, e.g.:
... flags S
# is equivalent to "flags S/AUPRFS" and matches
# packets with ONLY the SYN flag set.
... flags SA
# is equivalent to "flags SA/AUPRFS" and matches
# packets with only the SYN and ACK flags set.
... flags S/SA
# matches any packet with just the SYN flag set
# out of the SYN-ACK pair; the common "establish"
# keyword action. "S/SA" will NOT match a packet
# with BOTH SYN and ACK set, but WILL match "SFP".
is only effective when used with
and must NOT be used in conjuction with There are a number of
types, which can be referred to by an abbreviation recognised by
this language, or the numbers with which they are associated can
be used. The most important from a security point of view is
the ICMP redirect.
KEEP HISTORY
The second last parameter which can be set for a filter rule is whether
or not to record historical information for that packet, and what sort
to keep. The following information can be kept:
keeps information about the flow of a communication session. State can
be kept for TCP, UDP, and ICMP packets.
keeps information on fragmented packets, to be applied to later
fragments.
allowing packets which match these to flow straight through, rather
than going through the access control list.
GROUPS
The last pair of parameters control filter rule "grouping." By
default, all filter rules are placed in group 0 if no other group is
specified. To add a rule to a non-default group, the group must first
be started by creating a group head. If a packet matches a rule which
is the head of a group, the filter processing then switches to the
group, using that rule as the default for the group. If is used with a
rule, rule processing does not stop until it has returned from process‐
ing the group.
A rule may be both the head for a new group and a member of a non-
default group and can be used together in a rule).
creates a new group (number
specifies that the rule is to be put in group number
n instead of group 0.
LOGGING
When a packet is logged, with either the action or option, the headers
of the packet are written to the packet logging psuedo-device. Immedi‐
ately following the keyword, the following qualifiers may be used (in
order):
indicates that the first 128 bytes of the packet contents will be
logged after the headers.
If log is being used in conjunction with a "keep" option, it is recom‐
mended
that this option is also applied so that only the triggering
packet is logged and not every packet which thereafter matches
state information.
This enables logging when keep limit rules are active and limit
entries are created. It creates two types of log records.
The Alert log records are logged every time a configured con‐
nection limit is exceeded. If the logging frequency is speci‐
fied, then these records are logged first time the config‐
ured connection limit is exceeded and then logged for every
connections which exceed the configured connection limit.
The Summary log records are written to /dev/iplimit when the
limit entries expire. The -A option to ipmon is used to
read these records. Also see the -r option in ipmon(8).
indicates that, if for some reason the filter is unable to log the
packet (such as the log reader being too slow) then the rule
should be interpreted as if the action was for this packet.
indicates what logging facility and priority, or just priority with
the default facility being used, will be used to log information
about this packet using the option.
See ipl(4) for the format of records written to this device. The
ipmon(8) program can be used to read and format this log.
EXAMPLES
The option is useful for rules such as:
which matches any packet with a non-standard header length (IP options
present) and abort further processing of later rules, recording a match
and also that the packet should be blocked.
The "fall-through" rule parsing allows for effects such as this:
block in from any to any port < 6000
pass in from any to any port >= 6000
block in from any to any port > 6003
which sets up the range 6000-6003 as being permitted and all others
being denied. Note that the effect of the first rule is overridden by
subsequent rules. Another (easier) way to do the same is to configure
the following rules:
block in from any to any port 6000 <> 6003
pass in from any to any port 5999 >< 6004
Note that both the and keywords are required to effect a result because
a failed match on the action does not cause IPFilter to pass the
packet, it only causes the rule to not match. To then allow ports <
1024, you must configure a rule such as:
pass in quick from any to any port < 1024
before the first block. To create a new group for processing all
inbound packets on lan0, lan1, and lo0, with the default being to block
all inbound packets, configure rules such as:
block in all
block in quick on lan0 all head 100
block in quick on lan1 all head 200
block in quick on lo0 all head 300
Then, allow ICMP packets in on lan0, only, configure the following
rule:
pass in proto icmp all group 100
Note that because only inbound packets on lan0 are used processed by
group 100, there is no need to respecify the interface name. Likewise,
we could further break up processing of TCP, etc, as follows:
block in proto tcp all head 110 group 100
pass in from any to any port = 23 group 110
and so on. The last line, if written without the groups would be:
pass in on lan0 proto tcp from any to any port = telnet
Note that to specify you must also specify because the parser inter‐
prets each rule on its own and qualifies all service/port names with
the protocol specified.
FILES
/dev/ipauth
/dev/ipl
/dev/ipstate
/etc/hosts
/etc/services
SEE ALSOipftest(1M), mkfilters(1M), ipnat(4), ipf(1M), ipfilter(1M), ipfs‐
tat(1M)AUTHOR
IPFilter was originally developed by Darren Reed. This HP-UX
enhanced version of IPFilter is based on the open source version
3.5 Alpha 5.
IPF(4)
