ipf man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

IPF(4)									IPF(4)

       ipf,  ipf.conf,	ipf6.conf  -  files  containing filter rules for HP-UX

       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

       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.

       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‐

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

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

       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

	      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.

       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‐

       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

       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

	      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.

       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

       allowing packets which match these to  flow  straight  through,	rather
       than going through the access control list.

       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.

       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

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

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


       ipftest(1M),  mkfilters(1M),  ipnat(4),	ipf(1M),  ipfilter(1M),	 ipfs‐

       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.


List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net