1 IPF(4) File Formats and Configurations IPF(4)
2
3
4
5 NAME
6 ipf, ipf.conf, ipf6.conf - IP packet filter rule syntax
7
8 DESCRIPTION
9 A rule file for ipf may have any name or even be stdin. As ipfstat
10 produces parsable rules as output when displaying the internal kernel
11 filter lists, it is quite plausible to use its output to feed back into
12 ipf. Thus, to remove all filters on input packets, the following could
13 be done:
14
15 # ipfstat -i | ipf -rf -
16
17 GRAMMAR
18 The format used by ipf for construction of filtering rules can be
19 described using the following grammar in BNF:
20 filter-rule = [ insert ] action in-out [ options ] [ tos ] [ ttl ]
21 [ proto ] ip [ group ].
22
23 insert = "@" decnumber .
24 action = block | "pass" | log | "count" | skip | auth | call .
25 in-out = "in" | "out" .
26 options = [ log ] [ tag ] [ "quick" ] [ "on" interface-name [ dup ]
27 [ froute ] [ replyto ] ] .
28 tos = "tos" decnumber | "tos" hexnumber .
29 ttl = "ttl" decnumber .
30 proto = "proto" protocol .
31 ip = srcdst [ flags ] [ with withopt ] [ icmp ] [ keep ] .
32 group = [ "head" decnumber ] [ "group" decnumber ] .
33
34 block = "block" [ return-icmp[return-code] | "return-rst" ] .
35 log = "log" [ "body" ] [ "first" ] [ "or-block" ] [ "level" loglevel ] .
36 tag = "tag" tagid .
37 skip = "skip" decnumber .
38 auth = "auth" | "preauth" .
39 call = "call" [ "now" ] function-name .
40 dup = "dup-to" interface-name [ ":" ipaddr ] .
41 froute = "fastroute" | "to" interface-name [ ":" ipaddr ] .
42 replyto = "reply-to" interface-name [ ":" ipaddr ] .
43 protocol = "tcp/udp" | "udp" | "tcp" | "icmp" | decnumber .
44 srcdst = "all" | fromto .
45 fromto = "from" [ "!" ] object "to" [ "!" ] object .
46
47 return-icmp = "return-icmp" | "return-icmp-as-dest" .
48 return-code = "(" icmp-code ")" .
49 object = addr [ port-comp | port-range ] .
50 addr = "any" | nummask | host-name [ "mask" ipaddr | "mask" hexnumber ] .
51 addr = "any" | "<thishost>" | nummask |
52 host-name [ "mask" ipaddr | "mask" hexnumber ] .
53 port-comp = "port" compare port-num .
54 port-range = "port" port-num range port-num .
55 flags = "flags" flag { flag } [ "/" flag { flag } ] .
56 with = "with" | "and" .
57 icmp = "icmp-type" icmp-type [ "code" decnumber ] .
58 return-code = "(" icmp-code ")" .
59 keep = "keep" "state" [ "(" state-options ")" ] | "keep" "frags" .
60 loglevel = facility"."priority | priority .
61
62 nummask = host-name [ "/" decnumber ] .
63 host-name = ipaddr | hostname | "any" .
64 ipaddr = host-num "." host-num "." host-num "." host-num .
65 host-num = digit [ digit [ digit ] ] .
66 port-num = service-name | decnumber .
67 state-options = state-opts [ "," state-options ] .
68
69 state-opts = "age" decnumber [ "/" decnumber ] | "strict" |
70 "no-icmp-err" | "limit" decnumber | "newisn" | "sync" .
71 withopt = [ "not" | "no" ] opttype [ withopt ] .
72 opttype = "ipopts" | "short" | "frag" | "opt" optname .
73 optname = ipopts [ "," optname ] .
74 ipopts = optlist | "sec-class" [ secname ] .
75 secname = seclvl [ "," secname ] .
76 seclvl = "unclass" | "confid" | "reserv-1" | "reserv-2" | "reserv-3" |
77 "reserv-4" | "secret" | "topsecret" .
78 icmp-type = "unreach" | "echo" | "echorep" | "squench" | "redir" |
79 "timex" | "paramprob" | "timest" | "timestrep" | "inforeq" |
80 "inforep" | "maskreq" | "maskrep" | decnumber .
81 icmp-code = decumber | "net-unr" | "host-unr" | "proto-unr" | "port-unr" |
82 "needfrag" | "srcfail" | "net-unk" | "host-unk" | "isolate" |
83 "net-prohib" | "host-prohib" | "net-tos" | "host-tos" |
84 "filter-prohib" | "host-preced" | "cutoff-preced" .
85 optlist = "nop" | "rr" | "zsu" | "mtup" | "mtur" | "encode" | "ts" |
86 "tr" | "sec" | "lsrr" | "e-sec" | "cipso" | "satid" | "ssrr" |
87 "addext" | "visa" | "imitd" | "eip" | "finn" .
88 facility = "kern" | "user" | "mail" | "daemon" | "auth" | "syslog" |
89 "lpr" | "news" | "uucp" | "cron" | "ftp" | "authpriv" |
90 "audit" | "logalert" | "local0" | "local1" | "local2" |
91 "local3" | "local4" | "local5" | "local6" | "local7" .
92 priority = "emerg" | "alert" | "crit" | "err" | "warn" | "notice" |
93 "info" | "debug" .
94
95 hexnumber = "0" "x" hexstring .
96 hexstring = hexdigit [ hexstring ] .
97 decnumber = digit [ decnumber ] .
98
99 compare = "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" |
100 "gt" | "le" | "ge" .
101 range = "<>" | "><" .
102 hexdigit = digit | "a" | "b" | "c" | "d" | "e" | "f" .
103 digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" .
104 flag = "F" | "S" | "R" | "P" | "A" | "U" .
105
106 This syntax is somewhat simplified for readability, some combinations
107 that match this grammar are disallowed by the software because they do
108 not make sense (such as tcp flags for non-TCP packets).
109
110 FILTER RULES
111 The "briefest" valid rules are (currently) no-ops and are of the form:
112 block in all
113 pass in all
114 log out all
115 count in all
116
117 Filter rules are checked in order, with the last matching rule
118 determining the fate of the packet (but see the quick option, below).
119
120 Filters are installed by default at the end of the kernel's filter
121 lists, prepending the rule with @n will cause it to be inserted as the
122 n'th entry in the current list. This is especially useful when
123 modifying and testing active filter rulesets. See ipf(1M) for more
124 information.
125
126 ACTIONS
127 The action indicates what to do with the packet if it matches the rest
128 of the filter rule. Each rule MUST have an action. The following
129 actions are recognised:
130
131 block indicates that the packet should be flagged to be dropped. In
132 response to blocking a packet, the filter may be instructed to
133 send a reply packet, either an ICMP packet (return-icmp), an
134 ICMP packet masquerading as being from the original packet's
135 destination (return-icmp-as-dest), or a TCP "reset" (return-
136 rst). An ICMP packet may be generated in response to any IP
137 packet, and its type may optionally be specified, but a TCP
138 reset may only be used with a rule which is being applied to TCP
139 packets. When using return-icmp or return-icmp-as-dest, it is
140 possible to specify the actual unreachable `type'. That is,
141 whether it is a network unreachable, port unreachable or even
142 administratively prohibited. This is done by enclosing the ICMP
143 code associated with it in parenthesis directly following
144 return-icmp or return-icmp-as-dest as follows:
145 block return-icmp(11) ...
146
147 Would return a Type-Of-Service (TOS) ICMP unreachable error.
148
149 pass will flag the packet to be let through the filter.
150
151 log causes the packet to be logged (as described in the LOGGING
152 section below) and has no effect on whether the packet will be
153 allowed through the filter.
154
155 count causes the packet to be included in the accounting statistics
156 kept by the filter, and has no effect on whether the packet will
157 be allowed through the filter. These statistics are viewable
158 with ipfstat(1M).
159
160 call this action is used to invoke the named function in the kernel,
161 which must conform to a specific calling interface. Customised
162 actions and semantics can thus be implemented to supplement
163 those available. This feature is for use by knowledgeable
164 hackers, and is not currently documented.
165
166 skip <n>
167 causes the filter to skip over the next n filter rules. If a
168 rule is inserted or deleted inside the region being skipped
169 over, then the value of n is adjusted appropriately.
170
171 auth this allows authentication to be performed by a user-space
172 program running and waiting for packet information to validate.
173 The packet is held for a period of time in an internal buffer
174 whilst it waits for the program to return to the kernel the real
175 flags for whether it should be allowed through or not. Such a
176 program might look at the source address and request some sort
177 of authentication from the user (such as a password) before
178 allowing the packet through or telling the kernel to drop it if
179 from an unrecognised source.
180
181 preauth
182 tells the filter that for packets of this class, it should look
183 in the pre-authenticated list for further clarification. If no
184 further matching rule is found, the packet will be dropped (the
185 FR_PREAUTH is not the same as FR_PASS). If a further matching
186 rule is found, the result from that is used in its instead.
187 This might be used in a situation where a person logs in to the
188 firewall and it sets up some temporary rules defining the access
189 for that person.
190
191 The next word must be either in or out. Each packet moving through the
192 kernel is either inbound (just been received on an interface, and
193 moving towards the kernel's protocol processing) or outbound
194 (transmitted or forwarded by the stack, and on its way to an
195 interface). There is a requirement that each filter rule explicitly
196 state which side of the I/O it is to be used on.
197
198 OPTIONS
199 The list of options is brief, and all are indeed optional. Where
200 options are used, they must be present in the order shown here. These
201 are the currently supported options:
202
203 log indicates that, should this be the last matching rule, the
204 packet header will be written to the ipl log (as described in
205 the LOGGING section below).
206
207 tag tagid
208 indicates that, if this rule causes the packet to be logged or
209 entered in the state table, the tagid will be logged as part of
210 the log entry. This can be used to quickly match "similar"
211 rules in scripts that post process the log files for e.g.
212 generation of security reports or accounting purposes. The tagid
213 is a 32 bit unsigned integer.
214
215 quick allows "short-cut" rules in order to speed up the filter or
216 override later rules. If a packet matches a filter rule which
217 is marked as quick, this rule will be the last rule checked,
218 allowing a "short-circuit" path to avoid processing later rules
219 for this packet. The current status of the packet (after any
220 effects of the current rule) will determine whether it is passed
221 or blocked.
222
223 If this option is missing, the rule is taken to be a "fall-
224 through" rule, meaning that the result of the match (block/pass)
225 is saved and that processing will continue to see if there are
226 any more matches.
227
228 on allows an interface name to be incorporated into the matching
229 procedure. Interface names are as printed by "netstat -i". If
230 this option is used, the rule will only match if the packet is
231 going through that interface in the specified direction
232 (in/out). If this option is absent, the rule is taken to be
233 applied to a packet regardless of the interface it is present on
234 (i.e. on all interfaces). Filter rulesets are common to all
235 interfaces, rather than having a filter list for each interface.
236
237 This option is especially useful for simple IP-spoofing
238 protection: packets should only be allowed to pass inbound on
239 the interface from which the specified source address would be
240 expected, others may be logged and/or dropped.
241
242 dup-to causes the packet to be copied, and the duplicate packet to be
243 sent outbound on the specified interface, optionally with the
244 destination IP address changed to that specified. This is useful
245 for off-host logging, using a network sniffer.
246
247 to causes the packet to be moved to the outbound queue on the
248 specified interface. This can be used to circumvent kernel
249 routing decisions, and even to bypass the rest of the kernel
250 processing of the packet (if applied to an inbound rule). It is
251 thus possible to construct a firewall that behaves
252 transparently, like a filtering hub or switch, rather than a
253 router. The fastroute keyword is a synonym for this option.
254
255 MATCHING PARAMETERS
256 The keywords described in this section are used to describe attributes
257 of the packet to be used when determining whether rules match or don't
258 match. The following general-purpose attributes are provided for
259 matching, and must be used in this order:
260
261 tos packets with different Type-Of-Service values can be filtered.
262 Individual service levels or combinations can be filtered upon.
263 The value for the TOS mask can either be represented as a hex
264 number or a decimal integer value.
265
266 ttl packets may also be selected by their Time-To-Live value. The
267 value given in the filter rule must exactly match that in the
268 packet for a match to occur. This value can only be given as a
269 decimal integer value.
270
271 proto allows a specific protocol to be matched against. All protocol
272 names found in /etc/protocols are recognised and may be used.
273 However, the protocol may also be given as a DECIMAL number,
274 allowing for rules to match your own protocols, or new ones
275 which would out-date any attempted listing.
276
277 The special protocol keyword tcp/udp may be used to match either
278 a TCP or a UDP packet, and has been added as a convenience to
279 save duplication of otherwise-identical rules.
280
281 The from and to keywords are used to match against IP addresses (and
282 optionally port numbers). Rules must specify BOTH source and
283 destination parameters.
284
285 IP addresses may be specified in one of two ways: as a numerical
286 address/mask, or as a hostname mask netmask. The hostname may either
287 be a valid hostname, from either the hosts file or DNS (depending on
288 your configuration and library) or of the dotted numeric form. There
289 is no special designation for networks but network names are
290 recognised. Note that having your filter rules depend on DNS results
291 can introduce an avenue of attack, and is discouraged.
292
293 There is a special case for the hostname any which is taken to be
294 0.0.0.0/0 (see below for mask syntax) and matches all IP addresses.
295 Only the presence of "any" has an implied mask, in all other
296 situations, a hostname MUST be accompanied by a mask. It is possible
297 to give "any" a hostmask, but in the context of this language, it is
298 non-sensical.
299
300 The numerical format "x/y" indicates that a mask of y consecutive 1
301 bits set is generated, starting with the MSB, so a y value of 16 would
302 give 0xffff0000. The symbolic "x mask y" indicates that the mask y is
303 in dotted IP notation or a hexadecimal number of the form 0x12345678.
304 Note that all the bits of the IP address indicated by the bitmask must
305 match the address on the packet exactly; there isn't currently a way to
306 invert the sense of the match, or to match ranges of IP addresses which
307 do not express themselves easily as bitmasks (anthropomorphization;
308 it's not just for breakfast anymore).
309
310 If a port match is included, for either or both of source and
311 destination, then it is only applied to TCP and UDP packets. If there
312 is no proto match parameter, packets from both protocols are compared.
313 This is equivalent to "proto tcp/udp". When composing port
314 comparisons, either the service name or an integer port number may be
315 used. Port comparisons may be done in a number of forms, with a number
316 of comparison operators, or port ranges may be specified. When the port
317 appears as part of the from object, it matches the source port number,
318 when it appears as part of the to object, it matches the destination
319 port number. See the examples for more information.
320
321 The all keyword is essentially a synonym for "from any to any" with no
322 other match parameters.
323
324 Following the source and destination matching parameters, the following
325 additional parameters may be used:
326
327 with is used to match irregular attributes that some packets may have
328 associated with them. To match the presence of IP options in
329 general, use with ipopts. To match packets that are too short to
330 contain a complete header, use with short. To match fragmented
331 packets, use with frag. For more specific filtering on IP
332 options, individual options can be listed.
333
334 Before any parameter used after the with keyword, the word not
335 or no may be inserted to cause the filter rule to only match if
336 the option(s) is not present.
337
338 Multiple consecutive with clauses are allowed. Alternatively,
339 the keyword and may be used in place of with, this is provided
340 purely to make the rules more readable ("with ... and ...").
341 When multiple clauses are listed, all those must match to cause
342 a match of the rule.
343
344 flags is only effective for TCP filtering. Each of the letters
345 possible represents one of the possible flags that can be set in
346 the TCP header. The association is as follows:
347
348 F - FIN
349 S - SYN
350 R - RST
351 P - PUSH
352 A - ACK
353 U - URG
354
355 The various flag symbols may be used in combination, so that
356 "SA" would represent a SYN-ACK combination present in a packet.
357 There is nothing preventing the specification of combinations,
358 such as "SFR", that would not normally be generated by law-
359 abiding TCP implementations. However, to guard against weird
360 aberrations, it is necessary to state which flags you are
361 filtering against. To allow this, it is possible to set a mask
362 indicating which TCP flags you wish to compare (i.e., those you
363 deem significant). This is done by appending "/<flags>" to the
364 set of TCP flags you wish to match against, e.g.:
365
366 ... flags S
367 # becomes "flags S/AUPRFS" and will match
368 # packets with ONLY the SYN flag set.
369
370 ... flags SA
371 # becomes "flags SA/AUPRFS" and will match any
372 # packet with only the SYN and ACK flags set.
373
374 ... flags S/SA
375 # will match any packet with just the SYN flag set
376 # out of the SYN-ACK pair; the common "establish"
377 # keyword action. "S/SA" will NOT match a packet
378 # with BOTH SYN and ACK set, but WILL match "SFP".
379
380 icmp-type
381 is only effective when used with proto icmp and must NOT be used
382 in conjunction with flags. There are a number of types, which
383 can be referred to by an abbreviation recognised by this
384 language, or the numbers with which they are associated can be
385 used. The most important from a security point of view is the
386 ICMP redirect.
387
388 KEEP HISTORY
389 The second last parameter which can be set for a filter rule is whether
390 or not to record historical information for that packet, and what sort
391 to keep. The following information can be kept:
392
393 state keeps information about the flow of a communication session.
394 State can be kept for TCP, UDP, and ICMP packets.
395
396 frags keeps information on fragmented packets, to be applied to later
397 fragments.
398
399 allowing packets which match these to flow straight through, rather
400 than going through the access control list.
401
402 GROUPS
403 The last pair of parameters control filter rule "grouping". By
404 default, all filter rules are placed in group 0 if no other group is
405 specified. To add a rule to a non-default group, the group must first
406 be started by creating a group head. If a packet matches a rule which
407 is the head of a group, the filter processing then switches to the
408 group, using that rule as the default for the group. If quick is used
409 with a head rule, rule processing isn't stopped until it has returned
410 from processing the group.
411
412 A rule may be both the head for a new group and a member of a non-
413 default group (head and group may be used together in a rule).
414
415 head <n>
416 indicates that a new group (number n) should be created.
417
418 group <n>
419 indicates that the rule should be put in group (number n) rather
420 than group 0.
421
422 LOGGING
423 When a packet is logged, with either the log action or option, the
424 headers of the packet are written to the ipl packet logging pseudo-
425 device. Immediately following the log keyword, the following qualifiers
426 may be used (in order):
427
428 body indicates that the first 128 bytes of the packet contents will
429 be logged after the headers.
430
431 first If log is being used in conjunction with a "keep" option, it is
432 recommended that this option is also applied so that only the
433 triggering packet is logged and not every packet which
434 thereafter matches state information.
435
436 or-block
437 indicates that, if for some reason the filter is unable to log
438 the packet (such as the log reader being too slow) then the rule
439 should be interpreted as if the action was block for this
440 packet.
441
442 level <loglevel>
443 indicates what logging facility and priority, or just priority
444 with the default facility being used, will be used to log
445 information about this packet using ipmon's -s option.
446
447 See ipl(4) for the format of records written to this device. The
448 ipmon(1M) program can be used to read and format this log.
449
450 EXAMPLES
451 The quick option is good for rules such as:
452 block in quick from any to any with ipopts
453
454 which will match any packet with a non-standard header length (IP
455 options present) and abort further processing of later rules, recording
456 a match and also that the packet should be blocked.
457
458 The "fall-through" rule parsing allows for effects such as this:
459
460 block in from any to any port < 6000
461 pass in from any to any port >= 6000
462 block in from any to any port > 6003
463
464 which sets up the range 6000-6003 as being permitted and all others
465 being denied. Note that the effect of the first rule is overridden by
466 subsequent rules. Another (easier) way to do the same is:
467
468 block in from any to any port 6000 <> 6003
469 pass in from any to any port 5999 >< 6004
470
471 Note that both the "block" and "pass" are needed here to effect a
472 result as a failed match on the "block" action does not imply a pass,
473 only that the rule hasn't taken effect. To then allow ports < 1024, a
474 rule such as:
475
476 pass in quick from any to any port < 1024
477
478 would be needed before the first block. To create a new group for
479 processing all inbound packets on le0/le1/lo0, with the default being
480 to block all inbound packets, we would do something like:
481
482 block in all
483 block in quick on le0 all head 100
484 block in quick on le1 all head 200
485 block in quick on lo0 all head 300
486
487 and to then allow ICMP packets in on le0, only, we would do:
488
489 pass in proto icmp all group 100
490
491 Note that because only inbound packets on le0 are used processed by
492 group 100, there is no need to respecify the interface name. Likewise,
493 we could further breakup processing of TCP, etc, as follows:
494
495 block in proto tcp all head 110 group 100
496 pass in from any to any port = 23 group 110
497
498 and so on. The last line, if written without the groups would be:
499
500 pass in on le0 proto tcp from any to any port = telnet
501
502 Note, that if we wanted to say "port = telnet", "proto tcp" would need
503 to be specified as the parser interprets each rule on its own and
504 qualifies all service/port names with the protocol specified.
505
506 FILES
507 /dev/ipauth
508 /dev/ipl
509 /dev/ipstate
510 /etc/hosts
511 /etc/services
512
513 SEE ALSO
514 ipnat(4), ipf(1M), ipfstat(1M), ipfilter(5)
515
516
517
518 March 18, 2015 IPF(4)