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