4 ipf, ipf.conf \- IPFilter firewall rules file format
7 The ipf.conf file is used to specify rules for the firewall, packet
8 authentication and packet accounting components of IPFilter. To load rules
9 specified in the ipf.conf file, the ipf(8) program is used.
11 For use as a firewall, there are two important rule types: those that block
12 and drop packets (block rules) and those that allow packets through (pass
13 rules.) Accompanying the decision to apply is a collection of statements
14 that specify under what conditions the result is to be applied and how.
16 The simplest rules that can be used in ipf.conf are expressed like this:
23 Each rule must contain at least the following three components
26 a decision keyword (pass, block, etc.)
28 the direction of the packet (in or out)
30 address patterns or "all" to match any address information
34 For rules lines that are particularly long, it is possible to split
35 them over multiple lines implicity like this:
38 pass in on bgeo proto tcp from 1.1.1.1 port > 1000
39 to 2.2.2.2 port < 5000 flags S keep state
42 or explicitly using the backslash ('\\') character:
45 pass in on bgeo proto tcp from 1.1.1.1 port > 1000 \\
46 to 2.2.2.2 port < 5000 flags S keep state
50 Comments in the ipf.conf file are indicated by the use of the '#' character.
51 This can either be at the start of the line, like this:
54 # Allow all ICMP packets in
55 pass in proto icmp from any to any
58 Or at the end of a like, like this:
61 pass in proto icmp from any to any # Allow all ICMP packets in
65 This section goes into detail on how to construct firewall rules that
66 are placed in the ipf.conf file.
68 It is beyond the scope of this document to describe what makes a good
69 firewall rule set or which packets should be blocked or allowed in.
70 Some suggestions will be provided but further reading is expected to
71 fully understand what is safe and unsafe to allow in/out.
72 .SS Filter rule keywords
74 The first word found in any filter rule describes what the eventual outcome
75 of a packet that matches it will be. Descriptions of the many and various
76 sections that can be used to match on the contents of packet headers will
79 The complete list of keywords, along with what they do is as follows:
83 rules that match a packet indicate to ipfilter that it should be
84 allowed to continue on in the direction it is flowing.
87 rules are used when it is desirable to prevent a packet from going
88 any further. Packets that are blocked on the "in" side are never seen by
89 TCP/IP and those that are blocked going "out" are never seen on the wire.
92 when IPFilter successfully matches a packet against a log rule a log
93 record is generated and made available for ipmon(8) to read. These rules
94 have no impact on whether or not a packet is allowed through or not.
95 So if a packet first matched a block rule and then matched a log rule,
96 the status of the packet after the log rule is that it will still be
100 rules provide the administrator with the ability to count packets and
101 bytes that match the criteria laid out in the configuration file.
102 The count rules are applied after NAT and filter rules on the inbound
103 path. For outbound packets, count rules are applied before NAT and
104 before the packet is dropped. Thus the count rule cannot be used as
105 a true indicator of link layer
108 rules cause the matching packet to be queued up for processing by a
109 user space program. The user space program is responsible for making
110 an ioctl system call to collect the information about the queued
111 packet and another ioctl system call to return the verdict (block,
112 pass, etc) on what to do with the packet. In the event that the queue
113 becomes full, the packets will end up being dropped.
116 provides access to functions built into IPFilter that allow for more
117 complex actions to be taken as part of the decision making that goes
121 rules instruct ipfilter to remove any
122 other headers (IP, UDP, AH) and then process what is inside as a new packet.
123 For non-UDP packets, there are builtin checks that are applied in addition
124 to whatever is specified in the rule, to only allow decapsulation of
125 recognised protocols. After decapsulating the inner packet, any filtering
126 result that is applied to the inner packet is also applied to the other
129 The default way in which filter rules are applied is for the last
130 matching rule to be used as the decision maker. So even if the first
131 rule to match a packet is a pass, if there is a later matching rule
132 that is a block and no further rules match the packet, then it will
134 .SS Matching Network Interfaces
136 On systems with more than one network interface, it is necessary
137 to be able to specify different filter rules for each of them.
138 In the first instance, this is because different networks will send us
139 packets via each network interface but it is also because of the hosts,
140 the role and the resulting security policy that we need to be able to
141 distinguish which network interface a packet is on.
143 To accomodate systems where the presence of a network interface is
144 dynamic, it is not necessary for the network interface named in a
145 filter rule to be present in the system when the rule is loaded.
146 This can lead to silent errors being introduced and unexpected
147 behaviour with the simplest of keyboard mistakes - for example,
148 typing in hem0 instead of hme0 or hme2 instead of hme3.
150 On Solaris systems prior to Solaris 10 Update 4, it is not possible
151 to filter packets on the loopback interface (lo0) so filter rules
152 that specify it will have no impact on the corresponding flow of
153 packets. See below for Solaris specific tips on how to enable this.
155 Some examples of including the network interface in filter rules are:
161 .SS Address matching (basic)
163 The first and most basic part of matching for filtering rules is to
164 specify IP addresses and TCP/UDP port numbers. The source address
165 information is matched by the "from" information in a filter rule
166 and the destination address information is matched with the "to"
167 information in a filter rule.
169 The typical format used for IP addresses is CIDR notation, where an
170 IP address (or network) is followed by a '/' and a number representing
171 the size of the netmask in bits. This notation is used for specifying
172 address matching in both IPv4 and IPv6. If the '/' and bitmask size
173 are excluded from the matching string, it is assumed that the address
174 specified is a host address and that the netmask applied should be
177 Some examples of this are:
180 pass in from 10.1.0.0/24 to any
181 block out from any to 10.1.1.1
184 It is not possible to specify a range of addresses that does not
185 have a boundary that can be defined by a standard subnet mask.
187 .B Names instead of addresses
190 Hostnames, resolved either via DNS or /etc/hosts, or network names,
191 resolved via /etc/networks, may be used in place of actual addresses
192 in the filter rules. WARNING: if a hostname expands to more than one
193 address, only the *first* is used in building the filter rule.
195 Caution should be exercised when relying on DNS for filter rules in
196 case the sending and receiving of DNS packets is blocked when ipf(8)
197 is processing that part of the configuration file, leading to long
198 delays, if not errors, in loading the filter rules.
200 .SS Protocol Matching
202 To match packets based on TCP/UDP port information, it is first necessary
203 to indicate which protocol the packet must be. This is done using the
204 "proto" keyword, followed by either the protocol number or a name which
205 is mapped to the protocol number, usually through the /etc/protocols file.
208 pass in proto tcp from 10.1.0.0/24 to any
209 block out proto udp from any to 10.1.1.1
210 pass in proto icmp from any to 192.168.0.0/16
212 .SS Sending back error packets
214 When a packet is just discarded using a block rule, there is no feedback given
215 to the host that sent the packet. This is both good and bad. If this is the
216 desired behaviour and it is not desirable to send any feedback about packets
217 that are to be denied. The catch is that often a host trying to connect to a
218 TCP port or with a UDP based application will send more than one packet
219 because it assumes that just one packet may be discarded so a retry is
220 required. The end result being logs can become cluttered with duplicate
221 entries due to the retries.
223 To address this problem, a block rule can be qualified in two ways.
224 The first of these is specific to TCP and instructs IPFilter to send back
225 a reset (RST) packet. This packet indicates to the remote system that the
226 packet it sent has been rejected and that it shouldn't make any further
227 attempts to send packets to that port. Telling IPFilter to return a TCP
228 RST packet in response to something that has been received is achieved
229 with the return-rst keyword like this:
232 block return-rst in proto tcp from 10.0.0.0/8 to any
235 When sending back a TCP RST packet, IPFilter must construct a new packet
236 that has the source address of the intended target, not the source address
237 of the system it is running on (if they are different.)
239 For all of the other protocols handled by the IP protocol suite, to send
240 back an error indicating that the received packet was dropped requires
241 sending back an ICMP error packet. Whilst these can also be used for TCP,
242 the sending host may not treat the received ICMP error as a hard error
243 in the same way as it does the TCP RST packet. To return an ICMP error
244 it is necessary to place return-icmp after the block keyword like this:
247 block return-icmp in proto udp from any to 192.168.0.1/24
250 When electing to return an ICMP error packet, it is also possible to
251 select what type of ICMP error is returned. Whilst the full compliment
252 of ICMP unreachable codes can be used by specifying a number instead of
253 the string below, only the following should be used in conjunction with
254 return-icmp. Which return code to use is a choice to be made when
255 weighing up the pro's and con's. Using some of the codes may make it
256 more obvious that a firewall is being used rather than just the host
261 (prohibited by filter)
262 sending packets to the destination given in the received packet is
263 prohibited due to the application of a packet filter
267 sending packets to the destination given in the received packet is
268 administratively prohibited.
272 the destination host address is not known by the system receiving
273 the packet and therefore cannot be reached.
277 it is not possible to reach the host as given by the destination address
278 in the packet header.
282 the destination network address is not known by the system receiving
283 the packet and therefore cannot be reached.
286 (network unreachable)
287 it is not possible to forward the packet on to its final destination
288 as given by the destination address
292 there is no application using the given destination port and therefore
293 it is not possible to reach that port.
296 (protocol unreachable)
297 the IP protocol specified in the packet is not available to receive
301 An example that shows how to send back a port unreachable packet for
302 UDP packets to 192.168.1.0/24 is as follows:
305 block return-icmp(port-unr) in proto udp from any to 192.168.1.0/24
308 In the above examples, when sending the ICMP packet, IPFilter will construct
309 a new ICMP packet with a source address of the network interface used to
310 send the packet back to the original source. This can give away that there
311 is an intermediate system blocking packets. To have IPFilter send back
312 ICMP packets where the source address is the original destination, regardless
313 of whether or not it is on the local host, return-icmp-as-dest is used like
317 block return-icmp-as-dest(port-unr) in proto udp \\
318 from any to 192.168.1.0/24
320 .SS TCP/UDP Port Matching
322 Having specified which protocol is being matched, it is then possible to
323 indicate which port numbers a packet must have in order to match the rule.
324 Due to port numbers being used differently to addresses, it is therefore
325 possible to match on them in different ways. IPFilter allows you to use
326 the following logical operations:
328 is true if the port number is greater than or equal to x and less than or
330 is true if the port number in the packet is less than x
332 is true if the port number in the packet is less than or equal to x
334 is true if the port number in the packet is greater than x
336 is true if the port number in the packet is greater or equal to x
338 is true if the port number in the packet is equal to x
340 is true if the port number in the packet is not equal to x
342 Additionally, there are a number of ways to specify a range of ports:
344 is true if the port number is less than a and greater than y
346 is true if the port number is greater than x and less than y
348 is true if the port number is greater than or equal to x and less than or
351 Some examples of this are:
354 block in proto tcp from any port >= 1024 to any port < 1024
355 pass in proto tcp from 10.1.0.0/24 to any port = 22
356 block out proto udp from any to 10.1.1.1 port = 135
357 pass in proto udp from 1.1.1.1 port = 123 to 10.1.1.1 port = 123
358 pass in proto tcp from 127.0.0.0/8 to any port 6000:6009
361 If there is no desire to mention any specific source or destintion
362 information in a filter rule then the word "all" can be used to
363 indicate that all addresses are considered to match the rule.
366 If a filter rule is constructed without any addresses then IPFilter
367 will attempt to match both IPv4 and IPv6 packets with it. In the
368 next list of rules, each one can be applied to either network protocol
369 because there is no address specified from which IPFilter can derive
370 with network protocol to expect.
373 pass in proto udp from any to any port = 53
374 block in proto tcp from any port < 1024 to any
377 To explicitly match a particular network address family with a specific
378 rule, the family must be added to the rule. For IPv4 it is necessary to
379 add family inet and for IPv6, family inet6. Thus the next rule will
380 block all packets (both IPv4 and IPv6:
386 but in the following example, we block all IPv4 packets and only allow
390 block in family inet all
391 pass in family inet6 all
394 To continue on from the example where we allowed either IPv4 or IPv6
395 packets to port 53 in, to change that such that only IPv6 packets to
396 port 53 need to allowed blocked then it is possible to add in a
397 protocol family qualifier:
400 pass in family inet6 proto udp from any to any port = 53
402 .SS First match vs last match
404 To change the default behaviour from being the last matched rule decides
405 the outcome to being the first matched rule, the word "quick" is inserted
407 .SH Extended Packet Matching
408 .SS Beyond using plain addresses
410 On firewalls that are working with large numbers of hosts and networks
411 or simply trying to filter discretely against various hosts, it can
412 be an easier administration task to define a pool of addresses and have
413 a filter rule reference that address pool rather than have a rule for
416 In addition to being able to use address pools, it is possible to use
417 the interface name(s) in the from/to address fields of a rule. If the
418 name being used in the address section can be matched to any of the
419 interface names mentioned in the rule's "on" or "via" fields then it
420 can be used with one of the following keywords for extended effect:
423 use the primary broadcast address of the network interface for matching
424 packets with this filter rule;
427 pass in on fxp0 proto udp from any to fxp0/broadcast port = 123
431 use the peer address on point to point network interfaces for matching
432 packets with this filter rule. This option typically only has meaningful
433 use with link protocols such as SLIP and PPP.
434 For example, this rule allows ICMP packets from the remote peer of ppp0
435 to be received if they're destined for the address assigned to the link
439 pass in on ppp0 proto icmp from ppp0/peer to ppp0/32
443 use the primary network address, with its netmask, of the network interface
444 for matching packets with this filter rule. If a network interface had an
445 IP address of 192.168.1.1 and its netmask was 255.255.255.0 (/24), then
446 using the word "netmasked" after the interface name would match any
447 addresses that would match 192.168.1.0/24. If we assume that bge0 has
448 this IP address and netmask then the following two rules both serve
449 to produce the same effect:
452 pass in on bge0 proto icmp from any to 192.168.1.0/24
453 pass in on bge0 proto icmp from any to bge0/netmasked
457 using the primary network address, and its netmask, of the network interface,
458 construct an address for exact matching. If a network interface has an
459 address of 192.168.1.1 and its netmask is 255.255.255.0, using this
460 option would only match packets to 192.168.1.0.
463 pass in on bge0 proto icmp from any to bge0/network
466 Another way to use the name of a network interface to get the address
467 is to wrap the name in ()'s. In the above method, IPFilter
468 looks at the interface names in use and to decide whether or not
469 the name given is a hostname or network interface name. With the
470 use of ()'s, it is possible to tell IPFilter that the name should
471 be treated as a network interface name even though it doesn't
472 appear in the list of network interface that the rule ias associated
476 pass in proto icmp from any to (bge0)/32
478 .SS Using address pools
480 Rather than list out multiple rules that either allow or deny specific
481 addresses, it is possible to create a single object, call an address
482 pool, that contains all of those addresses and reference that in the
483 filter rule. For documentation on how to write the configuration file
484 for those pools and load them, see ippool.conf(5) and ippool(8).
485 There are two types of address pools that can be defined in ippool.conf(5):
486 trees and hash tables. To refer to a tree defined in ippool.conf(5),
490 pass in from pool/trusted to any
493 Either a name or number can be used after the '/', just so long as it
494 matches up with something that has already been defined in ipool.conf(5)
495 and loaded in with ippool(8). Loading a filter rule that references a
496 pool that does not exist will result in an error.
498 If hash tables have been used in ippool.conf(5) to store the addresses
499 in instead of a tree, then replace the word pool with hash:
502 pass in from any to hash/webservers
505 There are different operational characteristics with each, so there
506 may be some situations where a pool works better than hash and vice
508 .SS Matching TCP flags
510 The TCP header contains a field of flags that is used to decide if the
511 packet is a connection request, connection termination, data, etc.
512 By matching on the flags in conjunction with port numbers, it is
513 possible to restrict the way in which IPFilter allows connections to
514 be created. A quick overview of the TCP
515 flags is below. Each is listed with the letter used in IPFilter
516 rules, followed by its three or four letter pneumonic.
519 SYN - this bit is set when a host is setting up a connection.
520 The initiator typically sends a packet with the SYN bit and the
521 responder sends back SYN plus ACK.
524 ACK - this bit is set when the sender wishes to acknowledge the receipt
525 of a packet from another host
528 PUSH - this bit is set when a sending host has send some data that
529 is yet to be acknowledged and a reply is sought
532 FIN - this bit is set when one end of a connection starts to close
536 URG - this bit is set to indicate that the packet contains urgent data
539 RST - this bit is set only in packets that are a reply to another
540 that has been received but is not targetted at any open port
548 When matching TCP flags, it is normal to just list the flag that you
549 wish to be set. By default the set of flags it is compared against
550 is "FSRPAU". Rules that say "flags S" will be displayed by ipfstat(8)
551 as having "flags S/FSRPAU". This is normal.
552 The last two flags, "C" and "E", are optional - they
553 may or may not be used by an end host and have no bearing on either
554 the acceptance of data nor control of the connection. Masking them
555 out with "flags S/FSRPAUCE" may cause problems for remote hosts
556 making a successful connection.
559 pass in quick proto tcp from any to any port = 22 flags S/SAFR
560 pass out quick proto tcp from any port = 22 to any flags SA
563 By itself, filtering based on the TCP flags becomes more work but when
564 combined with stateful filtering (see below), the situation changes.
565 .SS Matching on ICMP header information
567 The TCP and UDP are not the only protocols for which filtering beyond
568 just the IP header is possible, extended matching on ICMP packets is
569 also available. The list of valid ICMP types is different for IPv4
572 As a practical example, to allow the ping command to work
573 against a specific target requires allowing two different types of
574 ICMP packets, like this:
577 pass in proto icmp from any to webserver icmp-type echo
578 pass out proto icmp from webserver to any icmp-type echorep
581 The ICMP header has two fields that are of interest for filtering:
582 the ICMP type and code. Filter rules can accept either a name or
583 number for both the type and code. The list of names supported for
584 ICMP types is listed below, however only ICMP unreachable errors
585 have named codes (see above.)
587 The list of ICMP types that are available for matching an IPv4 packet
591 echorep (echo reply),
592 inforeq (information request),
593 inforep (information reply),
594 maskreq (mask request),
595 maskrep (mask reply),
596 paramprob (parameter problem),
598 routerad (router advertisement),
599 routersol (router solicit),
600 squence (source quence),
602 timestreq (timestamp reply),
603 timex (time exceeded),
604 unreach (unreachable).
606 The list of ICMP types that are available for matching an IPv6 packet
610 echorep (echo reply),
611 fqdnquery (FQDN query),
612 fqdnreply (FQDN reply),
613 inforeq (information request),
614 inforep (information reply),
615 listendone (MLD listener done),
616 listendqry (MLD listener query),
617 listendrep (MLD listener reply),
618 neighadvert (neighbour advert),
619 neighborsol (neighbour solicit),
620 paramprob (parameter problem),
622 renumber (router renumbering),
623 routerad (router advertisement),
624 routersol (router solicit),
625 timex (time exceeded),
626 toobig (packet too big),
627 unreach (unreachable,
628 whoreq (WRU request),
630 .SH Stateful Packet Filtering
632 Stateful packet filtering is where IPFilter remembers some information from
633 one or more packets that it has seen and is able to apply it to future
634 packets that it receives from the network.
636 What this means for each transport layer protocol is different.
637 For TCP it means that if IPFilter
638 sees the very first packet of an attempt to make a connection, it has enough
639 information to allow all other subsequent packets without there needing to
640 be any explicit rules to match them. IPFilter uses the TCP port numbers,
641 TCP flags, window size and sequence numbers to determine which packets
642 should be matched. For UDP, only the UDP port numbers are available.
643 For ICMP, the ICMP types can be combined with the ICMP id field to
644 determine which reply packets match a request/query that has already
645 been seen. For all other protocols, only matching on IP address and
646 protocol number is available for determining if a packet received is a mate
647 to one that has already been let through.
649 The difference this makes is a reduction in the number of rules from
650 2 or 4 to 1. For example, these 4 rules:
653 pass in on bge0 proto tcp from any to any port = 22
654 pass out on bge1 proto tcp from any to any port = 22
655 pass in on bge1 proto tcp from any port = 22 to any
656 pass out on bge0 proto tcp from any port = 22 to any
659 can be replaced with this single rule:
662 pass in on bge0 proto tcp from any to any port = 22 flags S keep state
665 Similar rules for UDP and ICMP might be:
668 pass in on bge0 proto udp from any to any port = 53 keep state
669 pass in on bge0 proto icmp all icmp-type echo keep state
672 When using stateful filtering with TCP it is best to add "flags S" to the
673 rule to ensure that state is only created when a packet is seen that is
674 an indication of a new connection. Although IPFilter can gather some
675 information from packets in the middle of a TCP connection to do stateful
676 filtering, there are some options that are only sent at the start of the
677 connection which alter the valid window of what TCP accepts. The end result
678 of trying to pickup TCP state in mid connection is that some later packets
679 that are part of the connection may not match the known state information
680 and be dropped or blocked, causing problems. If a TCP packet matches IP
681 addresses and port numbers but does not fit into the recognised window,
682 it will not be automatically allowed and will be flagged inside of
683 IPFitler as "out of window" (oow). See below, "Extra packet attributes",
684 for how to match on this attribute.
686 Once a TCP connection has reached the established state, the default
687 timeout allows for it to be idle for 5 days before it is removed from
688 the state table. The timeouts for the other TCP connection states
689 vary from 240 seconds to 30 seconds.
690 Both UDP and ICMP state entries have asymetric timeouts where the timeout
691 set upon seeing packets in the forward direction is much larger than
692 for the reverse direction. For UDP the default timeouts are 120 and
693 12 seconds, for ICMP 60 and 6 seconds. This is a reflection of the
694 use of these protocols being more for query-response than for ongoing
695 connections. For all other protocols the
696 timeout is 60 seconds in both directions.
697 .SS Stateful filtering options
699 The following options can be used with stateful filtering:
702 limit the number of state table entries that this rule can create to
703 the number given after limit. A rule that has a limit specified is
704 always permitted that many state table entries, even if creating an
705 additional entry would cause the table to have more entries than the
706 otherwise global limit.
709 pass ... keep state(limit 100)
713 sets the timeout for the state entry when it sees packets going through
714 it. Additionally it is possible to set the tieout for the reply packets
715 that come back through the firewall to a different value than for the
716 forward path. allowing a short timeout to be set after the reply has
717 been seen and the state no longer required.
721 pass in quick proto icmp all icmp-type echo \\
723 pass in quick proto udp from any \\
724 to any port = 53 keep state (age 30/1)
729 only has an impact when used with TCP. It forces all packets that are
730 allowed through the firewall to be sequential: no out of order delivery
731 of packets is allowed. This can cause significant slowdown for some
732 connections and may stall others. Use with caution.
735 pass in proto tcp ... keep state(strict)
739 prevents ICMP error packets from being able to match state table entries
740 created with this flag using the contents of the original packet included.
743 pass ... keep state(noicmperr)
747 indicates to IPFilter that it needs to provide information to the user
748 land daemons responsible for syncing other machines state tables up
752 pass ... keep state(sync)
756 do not generate any log records for the creation or deletion of state
760 pass ... keep state(nolog)
764 rather than just precent ICMP error packets from being able to match
765 state table entries, allow an ACL to be processed that can filter in or
766 out ICMP error packets based as you would with normal firewall rules.
767 The icmp-head option requires a filter rule group number or name to
768 be present, just as you would use with head.
772 pass in quick proto tcp ... keep state(icmp-head 101)
773 block in proto icmp from 10.0.0.0/8 to any group 101
778 allows the number of distinct hosts that can create a state entry to
782 pass ... keep state(max-srcs 100)
783 pass ... keep state(limit 1000, max-srcs 100)
787 whilst max-srcs limits the number of individual hosts that may cause
788 the creation of a state table entry, each one of those hosts is still
789 table to fill up the state table with new entries until the global
790 maximum is reached. This option allows the number of state table entries
791 per address to be limited.
794 pass ... keep state(max-srcs 100, max-per-src 1)
795 pass ... keep state(limit 100, max-srcs 100, max-per-src 1)
798 Whilst these two rules might seem identical, in that they both
799 ultimately limit the number of hosts and state table entries created
800 from the rule to 100, there is a subtle difference: the second will
801 always allow up to 100 state table entries to be created whereas the
802 first may not if the state table fills up from other rules.
804 Further, it is possible to specify a netmask size after the per-host
805 limit that enables the per-host limit to become a per-subnet or
809 pass ... keep state(max-srcs 100, max-per-src 1/24)
812 If there is no IP protocol implied by addresses or other features of
813 the rule, IPFilter will assume that no netmask is an all ones netmask
814 for both IPv4 and IPv6.
815 .SS Tieing down a connection
817 For any connection that transits a firewall, each packet will be seen
818 twice: once going in and once going out. Thus a connection has 4 flows
833 IPFilter allows you to define the network interface to be used at all
834 four points in the flow of packets. For rules that match inbound packets,
835 out-via is used to specify which interfaces the packets go out, For rules
836 that match outbound packets, in-via is used to match the inbound packets.
837 In each case, the syntax generalises to this:
840 pass ... in on forward-in,reverse-in \\
841 out-via forward-out,reverse-out ...
843 pass ... out on forward-out,reverse-out \\
844 in-via forward-in,reverse-in ...
847 An example that pins down all 4 network interfaces used by an ssh
848 connection might look something like this:
851 pass in on bge0,bge1 out-via bge1,bge0 proto tcp \\
852 from any to any port = 22 flags S keep state
854 .SS Working with packet fragments
856 Fragmented packets result in 1 packet containing all of the layer 3 and 4
857 header information whilst the data is split across a number of other packets.
859 To enforce access control on fragmented packets, one of two approaches
860 can be taken. The first is to allow through all of the data fragments
861 (those that made up the body of the original packet) and rely on matching
862 the header information in the "first" fragment, when it is seen. The
863 reception of body fragments without the first will result in the receiving
864 host being unable to completely reassemble the packet and discarding all
865 of the fragments. The following three rules deny all fragmented packets
866 from being received except those that are UDP and even then only allows
867 those destined for port 2049 to be completed.
870 block in all with frags
871 pass in proto udp from any to any with frag-body
872 pass in proto udp from any to any port = 2049 with frags
875 Another mechanism that is available is to track "fragment state".
876 This relies on the first fragment of a packet that arrives to be
877 the fragment that contains all of the layer 3 and layer 4 header
878 information. With the receipt of that fragment before any other,
879 it is possible to determine which other fragments are to be allowed
880 through without needing to explicitly allow all fragment body packets.
881 An example of how this is done is as follows:
884 pass in proto udp from any port = 2049 to any with frags keep frags
886 .SH Building a tree of rules
888 Writing your filter rules as one long list of rules can be both inefficient
889 in terms of processing the rules and difficult to understand. To make the
890 construction of filter rules easier, it is possible to place them in groups.
891 A rule can be both a member of a group and the head of a new group.
893 Using filter groups requires at least two rules: one to be in the group
894 one one to send matchign packets to the group. If a packet matches a
895 filtre rule that is a group head but does not match any of the rules
896 in that group, then the packet is considered to have matched the head
899 Rules that are a member of a group contain the word group followed by
900 either a name or number that defines which group they're in. Rules that
901 form the branch point or starting point for the group must use the
902 word head, followed by either a group name or number. If rules are
903 loaded in that define a group but there is no matching head then they
904 will effectively be orphaned rules. It is possible to have more than
905 one head rule point to the same group, allowing groups to be used
906 like subroutines to implement specific common policies.
908 A common use of filter groups is to define head rules that exist in the
909 filter "main line" for each direction with the interfaces in use. For
913 block in quick on bge0 all head 100
914 block out quick on bge0 all head 101
915 block in quick on fxp0 all head internal-in
916 block out quick on fxp0 all head internal-out
917 pass in quick proto icmp all icmp-type echo group 100
920 In the above set of rules, there are four groups defined but only one
921 of them has a member rule. The only packets that would be allowed
922 through the above ruleset would be ICMP echo packets that are
925 Rules can be both a member of a group and the head of a new group,
926 allowing groups to specialise.
929 block in quick on bge0 all head 100
930 block in quick proto tcp all head 1006 group 100
933 Another use of filter rule groups is to provide a place for rules to
934 be dynamically added without needing to worry about their specific
935 ordering amongst the entire ruleset. For example, if I was using this
939 block in quick all with bad
940 block in proto tcp from any to any port = smtp head spammers
941 pass in quick proto tcp from any to any port = smtp flags S keep state
944 and I was getting lots of connections to my email server from 10.1.1.1
945 to deliver spam, I could load the following rule to complement the above:
948 block in quick from 10.1.1.1 to any group spammers
952 Rule groups also form a different but vital role for decapsulation rules.
953 With the following simple rule, if IPFilter receives an IP packet that has
954 an AH header as its layer 4 payload, IPFilter would adjust its view of the
955 packet internally and then jump to group 1001 using the data beyond the
956 AH header as the new transport header.
959 decapsulate in proto ah all head 1001
963 are recognised as being used with tunnelling or otherwise encapsulating
964 IP protocols, IPFilter is able to decide what it has on the inside
965 without any assistance. Some tunnelling protocols use UDP as the
966 transport mechanism. In this case, it is necessary to instruct IPFilter
967 as to what protocol is inside UDP.
970 decapsulate l5-as(ip) in proto udp from any \\
971 to any port = 1520 head 1001
974 Currently IPFilter only supports finding IPv4 and IPv6 headers
975 directly after the UDP header.
977 If a packet matches a decapsulate rule but fails to match any of the rules
978 that are within the specified group, processing of the packet continues
979 to the next rule after the decapsulate and IPFilter's internal view of the
980 packet is returned to what it was prior to the decapsulate rule.
982 It is possible to construct a decapsulate rule without the group
983 head at the end that ipf(8) will accept but such rules will not
984 result in anything happening.
985 .SS Policy Based Routing
987 With firewalls being in the position they often are, at the boundary
988 of different networks connecting together and multiple connections that
989 have different properties, it is often desirable to have packets flow
990 in a direction different to what the routing table instructs the kernel.
991 These decisions can often be extended to changing the route based on
992 both source and destination address or even port numbers.
994 To support this kind of configuration, IPFilter allows the next hop
995 destination to be specified with a filter rule. The next hop is given
996 with the interface name to use for output. The syntax for this is
997 interface:ip.address. It is expected that the address given as the next
998 hop is directly connected to the network to which the interface is.
1001 pass in on bge0 to bge1:1.1.1.1 proto tcp \\
1002 from 1.1.2.3 to any port = 80 flags S keep state
1005 When this feature is combined with stateful filtering, it becomes
1006 possible to influence the network interface used to transmit packets
1007 in both directions because we now have a sense for what its reverse
1011 pass in on bge0 to bge1:1.1.1.1 reply-to hme1:2.1.1.2 \\
1012 proto tcp from 1.1.2.3 to any port = 80 flags S keep state
1015 If the actions of the routing table are perfectly acceptable, but
1016 you would like to mask the presence of the firewall by not changing
1017 the TTL in IP packets as they transit it, IPFilter can be instructed
1018 to do a "fastroute" action like this:
1021 pass in on bge0 fastroute proto icmp all
1024 This should be used with caution as it can lead to endless packet
1025 loops. Additionally, policy based routing does not change the IP
1028 A variation on this type of rule supports a duplicate of the original
1029 packet being created and sent out a different network. This can be
1030 useful for monitoring traffic and other purposes.
1033 pass in on bge0 to bge1:1.1.1.1 reply-to hme1:2.1.1.2 \\
1034 dup-to fxp0:10.0.0.1 proto tcp from 1.1.2.3 \\
1035 to any port = 80 flags S keep state
1037 .SS Matching IPv4 options
1039 The design for IPv4 allows for the header to be upto 64 bytes long,
1040 however most traffic only uses the basic header which is 20 bytes long.
1041 The other 44 bytes can be uesd to store IP options. These options are
1042 generally not necessary for proper interaction and function on the
1043 Internet today. For most people it is sufficient to block and drop
1044 all packets that have any options set. This can be achieved with this
1048 block in quick all with ipopts
1051 This rule is usually placed towards the top of the configuration
1052 so that all incoming packets are blocked.
1054 If you wanted to allow in a specific IP option type, the syntax
1058 pass in quick proto igmp all with opt rtralrt
1061 The following is a list of IP options that most people encounter and
1062 what their use/threat is.
1065 (loose source route) the sender of the packet includes a list of addresses
1066 that they wish the packet to be routed through to on the way to the
1067 destination. Because replies to such packets are expected to use the
1068 list of addresses in reverse, hackers are able to very effectively use
1069 this header option in address spoofing attacks.
1072 (record route) the sender allocates some buffer space for recording the
1073 IP address of each router that the packet goes through. This is most often
1074 used with ping, where the ping response contains a copy of all addresses
1075 from the original packet, telling the sender what route the packet took
1076 to get there. Due to performance and security issues with IP header
1077 options, this is almost no longer used.
1080 (router alert) this option is often used in IGMP messages as a flag to
1081 routers that the packet needs to be handled differently. It is unlikely
1082 to ever be received from an unknown sender. It may be found on LANs or
1083 otherwise controlled networks where the RSVP protocol and multicast
1084 traffic is in heavy use.
1087 (strict source route) the sender of the packet includes a list of addresses
1088 that they wish the packet to be routed through to on the way to the
1089 destination. Where the lsrr option allows the sender to specify only
1090 some of the nodes the packet must go through, with the ssrr option,
1091 every next hop router must be specified.
1093 The complete list of IPv4 options that can be matched on is:
1094 addext (Address Extention),
1095 cipso (Classical IP Security Option),
1096 dps (Dynamic Packet State),
1097 e-sec (Extended Security),
1098 eip (Extended Internet Protocol),
1100 finn (Experimental Flow Control),
1101 imitd (IMI Traffic Descriptor),
1102 lsrr (Loose Source Route),
1103 mtup (MTU Probe - obsolete),
1104 mtur (MTU response - obsolete),
1106 nsapa (NSAP Address),
1108 rtralrt (Router Alert),
1109 satid (Stream Identifier),
1110 sdb (Selective Directed Broadcast),
1112 ssrr (Strict Source Route),
1115 ump (Upstream Multicast Packet),
1116 visa (Experimental Access Control)
1117 and zsu (Experimental Measurement).
1118 .SS Security with CIPSO and IPSO
1120 IPFilter supports filtering on IPv4 packets using security attributes embedded
1121 in the IP options part of the packet. These options are usually only used on
1122 networks and systems that are using lablled security. Unless you know that
1123 you are using labelled security and your networking is also labelled, it
1124 is highly unlikely that this section will be relevant to you.
1126 With the traditional IP Security Options (IPSO), packets can be tagged with
1127 a security level. The following keywords are recognised and match with the
1128 relevant RFC with respect to the bit patterns matched:
1129 confid (confidential),
1130 rserve-1 (1st reserved value),
1131 rserve-2 (2nd reserved value),
1132 rserve-3 (3rd reserved value),
1133 rserve-4 (4th reserved value),
1135 topsecret (top secret),
1136 unclass (unclassified).
1139 block in quick all with opt sec-class unclass
1140 pass in all with opt sec-class secret
1142 .SS Matching IPv6 extension headers
1144 Just as it is possible to filter on the various IPv4 header options,
1145 so too it is possible to filter on the IPv6 extension headers that are
1146 placed between the IPv6 header and the transport protocol header.
1148 dstopts (destination options),
1149 esp (encrypted, secure, payload),
1151 hopopts (hop-by-hop options),
1153 mobility (IP mobility),
1158 There are two ways in which packets can be logged with IPFilter. The
1159 first is with a rule that specifically says log these types of packets
1160 and the second is a qualifier to one of the other keywords. Thus it is
1161 possible to both log and allow or deny a packet with a single rule.
1164 pass in log quick proto tcp from any to any port = 22
1167 When using stateful filtering, the log action becomes part of the result
1168 that is remembered about a packet. Thus if the above rule was qualified
1169 with keep state, every packet in the connection would be logged. To only
1170 log the first packet from every packet flow tracked with keep state, it
1171 is necessary to indicate to IPFilter that you only wish to log the first
1175 pass in log first quick proto tcp from any to any port = 22 \\
1179 If it is a requirement that the logging provide an accurate representation
1180 of which connections are allowed, the log action can be qualified with the
1181 option or-block. This allows the administrator to instruct IPFilter to
1182 block the packet if the attempt to record the packet in IPFilter's kernel
1183 log records (which have an upper bound on size) failed. Unless the system
1184 shuts down or reboots, once a log record is written into the kernel buffer,
1185 it is there until ipmon(8) reads it.
1188 block in log proto tcp from any to any port = smtp
1189 pass in log or-block first quick proto tcp from any \\
1190 to any port = 22 flags S keep state
1193 By default, IPFilter will only log the header portion of a packet received
1194 on the network. A portion of the body of a packet, upto 128 bytes, can also
1195 be logged with the body keyword. ipmon(8) will display the contents of the
1196 portion of the body logged in hex.
1199 block in log body proto icmp all
1202 When logging packets from ipmon(8) to syslog, by default ipmon(8) will
1203 control what syslog facility and priority a packet will be logged with.
1204 This can be tuned on a per rule basis like this:
1207 block in quick log level err all with bad
1208 pass in log level local1.info proto tcp \\
1209 from any to any port = 22 flags S keep state
1212 ipfstat(8) reports how many packets have been successfully logged and how
1213 many failed attempts to log a packet there were.
1214 .SS Filter rule comments
1216 If there is a desire to associate a text string, be it an administrative
1217 comment or otherwise, with an IPFilter rule, this can be achieved by giving
1218 the filter rule a comment. The comment is loaded with the rule into the
1219 kernel and can be seen when the rules are listed with ipfstat.
1222 pass in quick proto tcp from any \\
1223 to port = 80 comment "all web server traffic is ok"
1224 pass out quick proto tcp from any port = 80 \\
1225 to any comment "all web server traffic is ok"
1229 To enable filtering and NAT to correctly match up packets with rules,
1230 tags can be added at with NAT (for inbound packets) and filtering (for
1231 outbound packets.) This allows a filter to be correctly mated with its
1232 NAT rule in the event that the NAT rule changed the packet in a way
1233 that would mean it is not obvious what it was.
1235 For inbound packets, IPFilter can match the tag used in the filter
1236 rules with that set by NAT. For outbound rules, it is the reverse,
1237 the filter sets the tag and the NAT rule matches up with it.
1240 pass in ... match-tag(nat=proxy)
1241 pass out ... set-tag(nat=proxy)
1244 Another use of tags is to supply a number that is only used with logging.
1245 When packets match these rules, the log tag is carried over into the
1246 log file records generated by ipmon(8). With the correct use of tools
1247 such as grep, extracting log records of interest is simplified.
1250 block in quick log ... set-tag(log=33)
1252 .SH Filter Rule Expiration
1254 IPFilter allows rules to be added into the kernel that it will remove after
1255 a specific period of time by specifying rule-ttl at the end of a rule.
1256 When listing rules in the kernel using ipfstat(8), rules that are going
1257 to expire will NOT display "rule-ttl" with the timeout, rather what will
1258 be seen is a comment with how many ipfilter ticks left the rule has to
1261 The time to live is specified in seconds.
1264 pass in on fxp0 proto tcp from any \\
1265 to port = 22 flags S keep state rule-ttl 30
1267 .SH Internal packet attributes
1269 In addition to being able to filter on very specific network and transport
1270 header fields, it is possible to filter on other attributes that IPFilter
1271 attaches to a packet. These attributes are placed in a rule after the
1272 keyword "with", as can be seen with frags and frag-body above. The
1273 following is a list of the other attributes available:
1276 the packet's IP addresses and TCP ports match an existing entry in the
1277 state table but the sequence numbers indicate that it is outside of the
1281 block return-rst in quick proto tcp from any to any with not oow
1285 this is set by IPFilter when it receives notification that the link
1286 layer packet was a broadcast packet. No checking of the IP addresses
1287 is performned to determine if it is a broadcast destination or not.
1290 block in quick proto udp all with bcast
1294 this is set by IPFilter when it receives notification that the link
1295 layer packet was a multicast packet. No checking of the IP addresses
1296 is performned to determine if it is a multicast destination or not.
1299 pass in quick proto udp from any to any port = dns with mcast
1303 can be used to match a packet that is either a multicast or broadcast
1304 packet at the link layer, as indicated by the operating system.
1307 pass in quick proto udp from any to any port = ntp with mbcast
1311 the packet positively matched a NAT table entry.
1314 sanity checking of the packet failed. This could indicate that the
1315 layer 3/4 headers are not properly formed.
1318 when reverse path verification is enabled, this flag will be set when
1319 the interface the packet is received on does not match that which would
1320 be used to send a packet out of to the source address in the received
1324 an attempt to perform NAT on the packet failed.
1327 each one of the attributes matched using the "with" keyword can also be
1328 looked for to not be present. For example, to only allow in good packets,
1333 pass in all with not bad
1337 The ipf.conf file can also be used to tune the behaviour of IPFilter,
1338 allowing, for example, timeouts for the NAT/state table(s) to be set
1339 along with their sizes. The presence and names of tunables may change
1340 from one release of IPFilter to the next. The tunables that can be
1341 changed via ipf.conf is the same as those that can be seen and modified
1342 using the -T command line option to ipf(8).
1344 NOTE: When parsing ipf.conf, ipf(8) will apply the settings before
1345 loading any rules. Thus if your settings are at the top, these may
1346 be applied whilst the rules not applied if there is an error further
1347 down in the configuration file.
1349 To set one of the values below, the syntax is simple: "set", followed
1350 by the name of the tuneable to set and then the value to set it to.
1354 set state_size 10101;
1357 A list of the currently available variables inside IPFilter that may
1358 be tuned from ipf.conf are as follows:
1361 set through -s command line switch of ipf(8). See ipf(8) for detals.
1364 when set, enables reverse path verification on source addresses and
1365 for filters to match packets with bad-src attribute.
1368 when set turns off kernel forwarding when IPFilter is disabled or unloaded.
1371 the default policy - whether packets are blocked or passed, etc - is
1372 represented by the value of this variable. It is a bit field and the
1373 bits that can be set are found in <netinet/ip_fil.h>. It is not
1374 recommended to tune this value directly.
1377 set the debugging level of the in-kernel FTP proxy.
1378 Debug messages will be printed to the system console.
1381 when set the FTP proxy must see a PASV/EPSV command before creating
1382 the state/NAT entries for the 227 response.
1385 when set the FTP proxy will not wait for a user to login before allowing
1386 data connections to be created.
1389 when set the proxy will not create state/NAT entries for when it
1390 sees either the PORT or EPRT command.
1393 when enabled causes the FTP proxy to create very insecure NAT/state
1394 entries that will allow any connection between the client and server
1395 hosts when a 227 reply is seen. Use with extreme caution.
1398 when set the FTP proxy will only allow one data connection at a time.
1401 sets the size of the hostmap table used by NAT to store address mappings
1402 for use with sticky rules.
1405 default timeout used for ICMP NAT/state when a reply packet is seen for
1406 an ICMP state that already exists
1409 sets the minimum MTU that is considered acceptable in an ICMP error
1410 before deciding it is a bad packet.
1413 default timeout used for ICMP NAT/state when the packet matches the rule
1416 default timeout used for NAT/state entries that are not TCP/UDP/ICMP.
1421 this sets the debugging level for the proxy support code.
1422 When enabled, debugging messages will be printed to the system console.
1425 when set it changes the behaviour of "log body" to log the entire packet
1426 rather than just the first 128 bytes.
1429 sets the size of the in-kernel log buffer in bytes.
1432 when set, IPFilter will check to see if the packet it is logging is
1433 similar to the one it previously logged and if so, increases
1434 the occurance count for that packet. The previously logged packet
1435 must not have yet been read by ipmon(8).
1438 is used to set the TTL value that packets below will be marked with
1439 the low-ttl attribute.
1442 if set it will cause the NAT code to do a more aggressive flush of the
1443 NAT table at the next opportunity. Once the flush has been done, the
1444 value is reset to 0.
1447 this should only be changed using ipfs(8)
1450 when set, NAT will create log records that can be read from /dev/ipnat.
1453 maximum number of entries allowed to exist in each NAT hash bucket.
1454 This prevents an attacker trying to load up the hash table with
1455 entries in a single bucket, reducing performance.
1458 size of the hash table to store map rules.
1461 maximum number of entries allowed into the NAT table
1464 size of the hash table used for NAT
1467 when the fill percentage of the NAT table exceeds this mark, more
1468 aggressive flushing is enabled.
1471 this sets the percentage at which the NAT table's agressive flushing
1472 will turn itself off at.
1475 size of the hash table to store rdr rules.
1478 this should only be changed using ipfs(8)
1481 when set, the stateful filtering will create log records
1482 that can be read from /dev/ipstate.
1485 maximum number of entries allowed into the state table
1488 maximum number of entries allowed to exist in each state hash bucket.
1489 This prevents an attacker trying to load up the hash table with
1490 entries in a single bucket, reducing performance.
1493 size of the hash table used for stateful filtering
1496 this controls how often the agressive flushing should be run once the
1497 state table exceeds state_wm_high in percentage full.
1500 when the fill percentage of the state table exceeds this mark, more
1501 aggressive flushing is enabled.
1504 this sets the percentage at which the state table's agressive flushing
1505 will turn itself off at.
1508 timeout used when a TCP state entry reaches the FIN_WAIT_2 state.
1511 timeout used when a TCP state entry is ready to be removed after either
1512 a RST packet is seen.
1515 timeout used when a TCP state entry reaches the CLOSE_WAIT state.
1518 timeout used when a TCP state entry reaches the ESTABLISHED state.
1521 timeout used when a TCP NAT/state entry reaches the LAST_ACK state.
1524 timeout applied to a TCP NAT/state entry after SYN-ACK packet has been seen.
1527 timeout applied to a TCP NAT/state entry after SYN packet has been seen.
1530 timeout used when a TCP NAT/state entry reaches the TIME_WAIT state.
1533 timeout used when a TCP NAT/state entry reaches either the half established
1534 state (one ack is seen after a SYN-ACK) or one side is in FIN_WAIT_1.
1537 default timeout used for UDP NAT/state when a reply packet is seen for
1538 a UDP state that already exists
1541 default timeout used for UDP NAT/state when the packet matches the rule
1544 when set, turns on changing the IP id field in NAT'd packets to a random
1546 .SS Table of visible variables
1548 A list of all of the tunables, their minimum, maximum and current
1549 values is as follows.
1552 Name Min Max Current
1555 control_forwarding 0 1 0
1556 default_pass 0 MAXUINT 134217730
1562 ftp_single_xfer 0 1 0
1563 hostmap_size 1 MAXINT 2047
1564 icmp_ack_timeout 1 MAXINT 12
1565 icmp_minfragmtu 0 1 68
1566 icmp_timeout 1 MAXINT 120
1567 ip_timeout 1 MAXINT 120
1568 ipf_flags 0 MAXUINT 0
1569 ips_proxy_debug 0 10 0
1571 log_size 0 524288 32768
1577 nat_maxbucket 1 MAXINT 22
1578 nat_rules_size 1 MAXINT 127
1579 nat_table_max 1 MAXINT 30000
1580 nat_table_size 1 MAXINT 2047
1581 nat_table_wm_high 2 100 99
1582 nat_table_wm_low 1 99 90
1583 rdr_rules_size 1 MAXINT 127
1586 state_max 1 MAXINT 4013
1587 state_maxbucket 1 MAXINT 26
1588 state_size 1 MAXINT 5737
1589 state_wm_freq 2 999999 20
1590 state_wm_high 2 100 99
1591 state_wm_low 1 99 90
1592 tcp_close_wait 1 MAXINT 480
1593 tcp_closed 1 MAXINT 60
1594 tcp_half_closed 1 MAXINT 14400
1595 tcp_idle_timeout 1 MAXINT 864000
1596 tcp_last_ack 1 MAXINT 60
1597 tcp_syn_received 1 MAXINT 480
1598 tcp_syn_sent 1 MAXINT 480
1599 tcp_time_wait 1 MAXINT 480
1600 tcp_timeout 1 MAXINT 480
1601 udp_ack_timeout 1 MAXINT 24
1602 udp_timeout 1 MAXINT 240
1605 .SH Calling out to internal functions
1607 IPFilter provides a pair of functions that can be called from a rule
1608 that allow for a single rule to jump out to a group rather than walk
1609 through a list of rules to find the group. If you've got multiple
1610 networks, each with its own group of rules, this feature may help
1611 provide better filtering performance.
1613 The lookup to find which rule group to jump to is done on either the
1614 source address or the destination address but not both.
1616 In this example below, we are blocking all packets by default but then
1617 doing a lookup on the source address from group 1010. The two rules in
1618 the ipf.conf section are lone members of their group. For an incoming
1619 packet that is from 1.1.1.1, it will go through three rules: (1) the
1620 block rule, (2) the call rule and (3) the pass rule for group 1020.
1621 For a packet that is from 3.3.2.2, it will also go through three rules:
1622 (1) the block rule, (2) the call rule and (3) the pass rule for group
1623 1030. Should a packet from 3.1.1.1 arrive, it will be blocked as it
1624 does not match any of the entries in group 1010, leaving it to only
1625 match the first rule.
1631 call now srcgrpmap/1010 in all
1632 pass in proto tcp from any to any port = 80 group 1020
1633 pass in proto icmp all icmp-type echo group 1030
1637 group-map in role=ipf number=1010
1638 { 1.1.1.1 group = 1020, 3.3.0.0/16 group = 1030; };
1640 .SS IPFilter matching expressions
1642 An experimental feature that has been added to filter rules is to use
1643 the same expression matching that is available with various commands
1644 to flush and list state/NAT table entries. The use of such an expression
1645 precludes the filter rule from using the normal IP header matching.
1648 pass in exp { "tcp.sport 23 or tcp.sport 50" } keep state
1650 .SS Filter rules with BPF
1652 On platforms that have the BPF built into the kernel, IPFilter can be
1653 built to allow BPF expressions in filter rules. This allows for packet
1654 matching to be on arbitrary data in the packt. The use of a BPF expression
1655 replaces all of the other protocol header matching done by IPFilter.
1658 pass in bpf-v4 { "tcp and (src port 23 or src port 50)" } \\
1662 These rules tend to be
1663 write-only because the act of compiling the filter expression into the
1664 BPF instructions loaded into the kernel can make it difficut to
1665 accurately reconstruct the original text filter. The end result is that
1666 while ipf.conf() can be easy to read, understanding the output from
1667 ipfstat might not be.
1670 This configuration file, like all others used with IPFilter, supports the
1671 use of variable substitution throughout the text.
1675 pass in on $nif from any to any
1681 pass in on ppp0 from any to any
1684 Variables can be used recursively, such as 'foo="$bar baz";', so long as
1685 $bar exists when the parser reaches the assignment for foo.
1689 for instructions on how to define variables to be used from a shell
1696 /usr/share/examples/ipfilter Directory with examples.
1698 ipf(8), ipfstat(8), ippool.conf(5), ippool(8)
projects / FreeBSD / stable / 10.git / blob