Long lines

For rules lines that are particularly long, it is possible to split them over multiple lines implicity like this:

pass in on bgeo proto tcp from 1.1.1.1 port > 1000
to 2.2.2.2 port < 5000 flags S keep state

or explicitly using the backslash ('\') character:

pass in on bgeo proto tcp from 1.1.1.1 port > 1000 \
to 2.2.2.2 port < 5000 flags S keep state

Comments

Comments in the ipf.conf file are indicated by the use of the '#' character. This can either be at the start of the line, like this:

# Allow all ICMP packets in
pass in proto icmp from any to any

Or at the end of a like, like this:

pass in proto icmp from any to any # Allow all ICMP packets in

Filter rule keywords

The first word found in any filter rule describes what the eventual outcome of a packet that matches it will be. Descriptions of the many and various sections that can be used to match on the contents of packet headers will follow on below.

The complete list of keywords, along with what they do is as follows:

Matching Network Interfaces

On systems with more than one network interface, it is necessary to be able to specify different filter rules for each of them. In the first instance, this is because different networks will send us packets via each network interface but it is also because of the hosts, the role and the resulting security policy that we need to be able to distinguish which network interface a packet is on.

To accomodate systems where the presence of a network interface is dynamic, it is not necessary for the network interface named in a filter rule to be present in the system when the rule is loaded. This can lead to silent errors being introduced and unexpected behaviour with the simplest of keyboard mistakes - for example, typing in hem0 instead of hme0 or hme2 instead of hme3.

On Solaris systems prior to Solaris 10 Update 4, it is not possible to filter packets on the loopback interface (lo0) so filter rules that specify it will have no impact on the corresponding flow of packets. See below for Solaris specific tips on how to enable this.

Some examples of including the network interface in filter rules are:

block in on bge0 all
pass out on bge0 all

Address matching (basic)

The first and most basic part of matching for filtering rules is to specify IP addresses and TCP/UDP port numbers. The source address information is matched by the "from" information in a filter rule and the destination address information is matched with the "to" information in a filter rule.

The typical format used for IP addresses is CIDR notation, where an IP address (or network) is followed by a '/' and a number representing the size of the netmask in bits. This notation is used for specifying address matching in both IPv4 and IPv6. If the '/' and bitmask size are excluded from the matching string, it is assumed that the address specified is a host address and that the netmask applied should be all 1's.

Some examples of this are:

pass in from 10.1.0.0/24 to any
block out from any to 10.1.1.1

It is not possible to specify a range of addresses that does not have a boundary that can be defined by a standard subnet mask.

Names instead of addresses

Protocol Matching

To match packets based on TCP/UDP port information, it is first necessary to indicate which protocol the packet must be. This is done using the "proto" keyword, followed by either the protocol number or a name which is mapped to the protocol number, usually through the /etc/protocols file.

pass in proto tcp from 10.1.0.0/24 to any
block out proto udp from any to 10.1.1.1
pass in proto icmp from any to 192.168.0.0/16

Sending back error packets

When a packet is just discarded using a block rule, there is no feedback given to the host that sent the packet. This is both good and bad. If this is the desired behaviour and it is not desirable to send any feedback about packets that are to be denied. The catch is that often a host trying to connect to a TCP port or with a UDP based application will send more than one packet because it assumes that just one packet may be discarded so a retry is required. The end result being logs can become cluttered with duplicate entries due to the retries.

To address this problem, a block rule can be qualified in two ways. The first of these is specific to TCP and instructs IPFilter to send back a reset (RST) packet. This packet indicates to the remote system that the packet it sent has been rejected and that it shouldn't make any further attempts to send packets to that port. Telling IPFilter to return a TCP RST packet in response to something that has been received is achieved with the return-rst keyword like this:

block return-rst in proto tcp from 10.0.0.0/8 to any

When sending back a TCP RST packet, IPFilter must construct a new packet that has the source address of the intended target, not the source address of the system it is running on (if they are different.)

For all of the other protocols handled by the IP protocol suite, to send back an error indicating that the received packet was dropped requires sending back an ICMP error packet. Whilst these can also be used for TCP, the sending host may not treat the received ICMP error as a hard error in the same way as it does the TCP RST packet. To return an ICMP error it is necessary to place return-icmp after the block keyword like this:

block return-icmp in proto udp from any to 192.168.0.1/24

When electing to return an ICMP error packet, it is also possible to select what type of ICMP error is returned. Whilst the full compliment of ICMP unreachable codes can be used by specifying a number instead of the string below, only the following should be used in conjunction with return-icmp. Which return code to use is a choice to be made when weighing up the pro's and con's. Using some of the codes may make it more obvious that a firewall is being used rather than just the host not responding.

TCP/UDP Port Matching

Having specified which protocol is being matched, it is then possible to indicate which port numbers a packet must have in order to match the rule. Due to port numbers being used differently to addresses, it is therefore possible to match on them in different ways. IPFilter allows you to use the following logical operations:

< x

is true if the port number is greater than or equal to x and less than or equal to y is true if the port number in the packet is less than x

<= x

is true if the port number in the packet is less than or equal to x

> x

is true if the port number in the packet is greater than x

>= x

is true if the port number in the packet is greater or equal to x

= x

is true if the port number in the packet is equal to x

!= x

is true if the port number in the packet is not equal to x

Additionally, there are a number of ways to specify a range of ports:

x <> y

is true if the port number is less than a and greater than y

x >< y

is true if the port number is greater than x and less than y

x:y

is true if the port number is greater than or equal to x and less than or equal to y

Some examples of this are:

block in proto tcp from any port >= 1024 to any port < 1024
pass in proto tcp from 10.1.0.0/24 to any port = 22
block out proto udp from any to 10.1.1.1 port = 135
pass in proto udp from 1.1.1.1 port = 123 to 10.1.1.1 port = 123
pass in proto tcp from 127.0.0.0/8 to any port = 6000:6009

If there is no desire to mention any specific source or destintion information in a filter rule then the word "all" can be used to indicate that all addresses are considered to match the rule.

IPv4 or IPv6

If a filter rule is constructed without any addresses then IPFilter will attempt to match both IPv4 and IPv6 packets with it. In the next list of rules, each one can be applied to either network protocol because there is no address specified from which IPFilter can derive with network protocol to expect.

pass in proto udp from any to any port = 53
block in proto tcp from any port < 1024 to any

To explicitly match a particular network address family with a specific rule, the family must be added to the rule. For IPv4 it is necessary to add family inet and for IPv6, family inet6. Thus the next rule will block all packets (both IPv4 and IPv6:

block in all

but in the following example, we block all IPv4 packets and only allow in IPv6 packets:

block in family inet all
pass in family inet6 all

To continue on from the example where we allowed either IPv4 or IPv6 packets to port 53 in, to change that such that only IPv6 packets to port 53 need to allowed blocked then it is possible to add in a protocol family qualifier:

pass in family inet6 proto udp from any to any port = 53

First match vs last match

To change the default behaviour from being the last matched rule decides the outcome to being the first matched rule, the word "quick" is inserted to the rule.

Beyond using plain addresses

On firewalls that are working with large numbers of hosts and networks or simply trying to filter discretely against various hosts, it can be an easier administration task to define a pool of addresses and have a filter rule reference that address pool rather than have a rule for each address.

In addition to being able to use address pools, it is possible to use the interface name(s) in the from/to address fields of a rule. If the name being used in the address section can be matched to any of the interface names mentioned in the rule's "on" or "via" fields then it can be used with one of the following keywords for extended effect:

broadcast use the primary broadcast address of the network interface for matching packets with this filter rule;

pass in on fxp0 proto udp from any to fxp0/broadcast port = 123

peer use the peer address on point to point network interfaces for matching packets with this filter rule. This option typically only has meaningful use with link protocols such as SLIP and PPP. For example, this rule allows ICMP packets from the remote peer of ppp0 to be received if they're destined for the address assigned to the link at the firewall end.

pass in on ppp0 proto icmp from ppp0/peer to ppp0/32

netmasked use the primary network address, with its netmask, of the network interface for matching packets with this filter rule. If a network interface had an IP address of 192.168.1.1 and its netmask was 255.255.255.0 (/24), then using the word "netmasked" after the interface name would match any addresses that would match 192.168.1.0/24. If we assume that bge0 has this IP address and netmask then the following two rules both serve to produce the same effect:

pass in on bge0 proto icmp from any to 192.168.1.0/24
pass in on bge0 proto icmp from any to bge0/netmasked

network using the primary network address, and its netmask, of the network interface, construct an address for exact matching. If a network interface has an address of 192.168.1.1 and its netmask is 255.255.255.0, using this option would only match packets to 192.168.1.0.

pass in on bge0 proto icmp from any to bge0/network

Another way to use the name of a network interface to get the address is to wrap the name in ()'s. In the above method, IPFilter looks at the interface names in use and to decide whether or not the name given is a hostname or network interface name. With the use of ()'s, it is possible to tell IPFilter that the name should be treated as a network interface name even though it doesn't appear in the list of network interface that the rule ias associated with.

pass in proto icmp from any to (bge0)/32

Using address pools

Rather than list out multiple rules that either allow or deny specific addresses, it is possible to create a single object, call an address pool, that contains all of those addresses and reference that in the filter rule. For documentation on how to write the configuration file for those pools and load them, see ippool.conf(5) and ippool(8). There are two types of address pools that can be defined in ippool.conf(5): trees and hash tables. To refer to a tree defined in ippool.conf(5), use this syntax:

pass in from pool/trusted to any

Either a name or number can be used after the '/', just so long as it matches up with something that has already been defined in ipool.conf(5) and loaded in with ippool(8). Loading a filter rule that references a pool that does not exist will result in an error.

If hash tables have been used in ippool.conf(5) to store the addresses in instead of a tree, then replace the word pool with hash:

pass in from any to hash/webservers

There are different operational characteristics with each, so there may be some situations where a pool works better than hash and vice versa.

Matching TCP flags

The TCP header contains a field of flags that is used to decide if the packet is a connection request, connection termination, data, etc. By matching on the flags in conjunction with port numbers, it is possible to restrict the way in which IPFilter allows connections to be created. A quick overview of the TCP flags is below. Each is listed with the letter used in IPFilter rules, followed by its three or four letter pneumonic.

S SYN - this bit is set when a host is setting up a connection. The initiator typically sends a packet with the SYN bit and the responder sends back SYN plus ACK.

A ACK - this bit is set when the sender wishes to acknowledge the receipt of a packet from another host

P PUSH - this bit is set when a sending host has send some data that is yet to be acknowledged and a reply is sought

F FIN - this bit is set when one end of a connection starts to close the connection down

U URG - this bit is set to indicate that the packet contains urgent data

R RST - this bit is set only in packets that are a reply to another that has been received but is not targetted at any open port

C CWN

E ECN

When matching TCP flags, it is normal to just list the flag that you wish to be set. By default the set of flags it is compared against is "FSRPAU". Rules that say "flags S" will be displayed by ipfstat(8) as having "flags S/FSRPAU". This is normal. The last two flags, "C" and "E", are optional - they may or may not be used by an end host and have no bearing on either the acceptance of data nor control of the connection. Masking them out with "flags S/FSRPAUCE" may cause problems for remote hosts making a successful connection.

pass in quick proto tcp from any to any port = 22 flags S/SAFR
pass out quick proto tcp from any port = 22 to any flags SA

By itself, filtering based on the TCP flags becomes more work but when combined with stateful filtering (see below), the situation changes.

Matching on ICMP header information

The TCP and UDP are not the only protocols for which filtering beyond just the IP header is possible, extended matching on ICMP packets is also available. The list of valid ICMP types is different for IPv4 vs IPv6.

As a practical example, to allow the ping command to work against a specific target requires allowing two different types of ICMP packets, like this:

pass in proto icmp from any to webserver icmp-type echo
pass out proto icmp from webserver to any icmp-type echorep

The ICMP header has two fields that are of interest for filtering: the ICMP type and code. Filter rules can accept either a name or number for both the type and code. The list of names supported for ICMP types is listed below, however only ICMP unreachable errors have named codes (see above.)

The list of ICMP types that are available for matching an IPv4 packet are as follows:

echo (echo request), echorep (echo reply), inforeq (information request), inforep (information reply), maskreq (mask request), maskrep (mask reply), paramprob (parameter problem), redir (redirect), routerad (router advertisement), routersol (router solicit), squence (source quence), timest (timestamp), timestreq (timestamp reply), timex (time exceeded), unreach (unreachable).

The list of ICMP types that are available for matching an IPv6 packet are as follows:

echo (echo request), echorep (echo reply), fqdnquery (FQDN query), fqdnreply (FQDN reply), inforeq (information request), inforep (information reply), listendone (MLD listener done), listendqry (MLD listener query), listendrep (MLD listener reply), neighadvert (neighbour advert), neighborsol (neighbour solicit), paramprob (parameter problem), redir (redirect), renumber (router renumbering), routerad (router advertisement), routersol (router solicit), timex (time exceeded), toobig (packet too big), unreach (unreachable, whoreq (WRU request), whorep (WRU reply).

Stateful filtering options

The following options can be used with stateful filtering:

limit limit the number of state table entries that this rule can create to the number given after limit. A rule that has a limit specified is always permitted that many state table entries, even if creating an additional entry would cause the table to have more entries than the otherwise global limit.

pass ... keep state(limit 100)

age sets the timeout for the state entry when it sees packets going through it. Additionally it is possible to set the tieout for the reply packets that come back through the firewall to a different value than for the forward path. allowing a short timeout to be set after the reply has been seen and the state no longer required.

strict only has an impact when used with TCP. It forces all packets that are allowed through the firewall to be sequential: no out of order delivery of packets is allowed. This can cause significant slowdown for some connections and may stall others. Use with caution.

pass in proto tcp ... keep state(strict)

noicmperr prevents ICMP error packets from being able to match state table entries created with this flag using the contents of the original packet included.

pass ... keep state(noicmperr)

sync indicates to IPFilter that it needs to provide information to the user land daemons responsible for syncing other machines state tables up with this one.

pass ... keep state(sync)

nolog do not generate any log records for the creation or deletion of state table entries.

pass ... keep state(nolog)

icmp-head rather than just precent ICMP error packets from being able to match state table entries, allow an ACL to be processed that can filter in or out ICMP error packets based as you would with normal firewall rules. The icmp-head option requires a filter rule group number or name to be present, just as you would use with head.

max-srcs allows the number of distinct hosts that can create a state entry to be defined.

pass ... keep state(max-srcs 100)
pass ... keep state(limit 1000, max-srcs 100)

max-per-src whilst max-srcs limits the number of individual hosts that may cause the creation of a state table entry, each one of those hosts is still table to fill up the state table with new entries until the global maximum is reached. This option allows the number of state table entries per address to be limited.

pass ... keep state(max-srcs 100, max-per-src 1)
pass ... keep state(limit 100, max-srcs 100, max-per-src 1)

Whilst these two rules might seem identical, in that they both ultimately limit the number of hosts and state table entries created from the rule to 100, there is a subtle difference: the second will always allow up to 100 state table entries to be created whereas the first may not if the state table fills up from other rules.

Further, it is possible to specify a netmask size after the per-host limit that enables the per-host limit to become a per-subnet or per-network limit.

pass ... keep state(max-srcs 100, max-per-src 1/24)

If there is no IP protocol implied by addresses or other features of the rule, IPFilter will assume that no netmask is an all ones netmask for both IPv4 and IPv6.

Tieing down a connection

For any connection that transits a firewall, each packet will be seen twice: once going in and once going out. Thus a connection has 4 flows of packets:

forward inbound packets

forward outbound packets

reverse inbound packets

reverse outbound packets

IPFilter allows you to define the network interface to be used at all four points in the flow of packets. For rules that match inbound packets, out-via is used to specify which interfaces the packets go out, For rules that match outbound packets, in-via is used to match the inbound packets. In each case, the syntax generalises to this:

pass ... in on forward-in,reverse-in \
out-via forward-out,reverse-out ...

pass ... out on forward-out,reverse-out \
in-via forward-in,reverse-in ...

An example that pins down all 4 network interfaces used by an ssh connection might look something like this:

pass in on bge0,bge1 out-via bge1,bge0 proto tcp \
from any to any port = 22 flags S keep state

Working with packet fragments

Fragmented packets result in 1 packet containing all of the layer 3 and 4 header information whilst the data is split across a number of other packets.

To enforce access control on fragmented packets, one of two approaches can be taken. The first is to allow through all of the data fragments (those that made up the body of the original packet) and rely on matching the header information in the "first" fragment, when it is seen. The reception of body fragments without the first will result in the receiving host being unable to completely reassemble the packet and discarding all of the fragments. The following three rules deny all fragmented packets from being received except those that are UDP and even then only allows those destined for port 2049 to be completed.

block in all with frags
pass in proto udp from any to any with frag-body
pass in proto udp from any to any port = 2049 with frags

Another mechanism that is available is to track "fragment state". This relies on the first fragment of a packet that arrives to be the fragment that contains all of the layer 3 and layer 4 header information. With the receipt of that fragment before any other, it is possible to determine which other fragments are to be allowed through without needing to explicitly allow all fragment body packets. An example of how this is done is as follows:

pass in proto udp from any prot = 2049 to any with frags keep fags

Decapsulation

Rule groups also form a different but vital role for decapsulation rules. With the following simple rule, if IPFilter receives an IP packet that has an AH header as its layer 4 payload, IPFilter would adjust its view of the packet internally and then jump to group 1001 using the data beyond the AH header as the new transport header.

decapsulate in proto ah all head 1001

For protocols that are recognised as being used with tunnelling or otherwise encapsulating IP protocols, IPFilter is able to decide what it has on the inside without any assistance. Some tunnelling protocols use UDP as the transport mechanism. In this case, it is necessary to instruct IPFilter as to what protocol is inside UDP.

decapsulate l5-as(ip) in proto udp from any \
to any port = 1520 head 1001

Currently IPFilter only supports finding IPv4 and IPv6 headers directly after the UDP header.

If a packet matches a decapsulate rule but fails to match any of the rules that are within the specified group, processing of the packet continues to the next rule after the decapsulate and IPFilter's internal view of the packet is returned to what it was prior to the decapsulate rule.

It is possible to construct a decapsulate rule without the group head at the end that ipf(8) will accept but such rules will not result in anything happening.

Policy Based Routing

With firewalls being in the position they often are, at the boundary of different networks connecting together and multiple connections that have different properties, it is often desirable to have packets flow in a direction different to what the routing table instructs the kernel. These decisions can often be extended to changing the route based on both source and destination address or even port numbers.

To support this kind of configuration, IPFilter allows the next hop destination to be specified with a filter rule. The next hop is given with the interface name to use for output. The syntax for this is interface:ip.address. It is expected that the address given as the next hop is directly connected to the network to which the interface is.

pass in on bge0 to bge1:1.1.1.1 proto tcp \
from 1.1.2.3 to any port = 80 flags S keep state

When this feature is combined with stateful filtering, it becomes possible to influence the network interface used to transmit packets in both directions because we now have a sense for what its reverse flow of packets is.

pass in on bge0 to bge1:1.1.1.1 reply-to hme1:2.1.1.2 \
proto tcp from 1.1.2.3 to any port = 80 flags S keep state

If the actions of the routing table are perfectly acceptable, but you would like to mask the presence of the firewall by not changing the TTL in IP packets as they transit it, IPFilter can be instructed to do a "fastroute" action like this:

pass in on bge0 fastroute proto icmp all

This should be used with caution as it can lead to endless packet loops. Additionally, policy based routing does not change the IP header's TTL value.

A variation on this type of rule supports a duplicate of the original packet being created and sent out a different network. This can be useful for monitoring traffic and other purposes.

pass in on bge0 to bge1:1.1.1.1 reply-to hme1:2.1.1.2 \
dup-to fxp0:10.0.0.1 proto tcp from 1.1.2.3 \
to any port = 80 flags S keep state

Matching IPv4 options

The design for IPv4 allows for the header to be upto 64 bytes long, however most traffic only uses the basic header which is 20 bytes long. The other 44 bytes can be uesd to store IP options. These options are generally not necessary for proper interaction and function on the Internet today. For most people it is sufficient to block and drop all packets that have any options set. This can be achieved with this rule:

block in quick all with ipopts

This rule is usually placed towards the top of the configuration so that all incoming packets are blocked.

If you wanted to allow in a specific IP option type, the syntax changes slightly:

pass in quick proto igmp all with opt rtralrt

The following is a list of IP options that most people encounter and what their use/threat is.

lsrr (loose source route) the sender of the packet includes a list of addresses that they wish the packet to be routed through to on the way to the destination. Because replies to such packets are expected to use the list of addresses in reverse, hackers are able to very effectively use this header option in address spoofing attacks.

rr (record route) the sender allocates some buffer space for recording the IP address of each router that the packet goes through. This is most often used with ping, where the ping response contains a copy of all addresses from the original packet, telling the sender what route the packet took to get there. Due to performance and security issues with IP header options, this is almost no longer used.

rtralrt (router alert) this option is often used in IGMP messages as a flag to routers that the packet needs to be handled differently. It is unlikely to ever be received from an unknown sender. It may be found on LANs or otherwise controlled networks where the RSVP protocol and multicast traffic is in heavy use.

ssrr (strict source route) the sender of the packet includes a list of addresses that they wish the packet to be routed through to on the way to the destination. Where the lsrr option allows the sender to specify only some of the nodes the packet must go through, with the ssrr option, every next hop router must be specified.

The complete list of IPv4 options that can be matched on is: addext (Address Extention), cipso (Classical IP Security Option), dps (Dynamic Packet State), e-sec (Extended Security), eip (Extended Internet Protocol), encode (ENCODE), finn (Experimental Flow Control), imitd (IMI Traffic Descriptor), lsrr (Loose Source Route), mtup (MTU Probe - obsolete), mtur (MTU response - obsolete), nop (No Operation), nsapa (NSAP Address), rr (Record Route), rtralrt (Router Alert), satid (Stream Identifier), sdb (Selective Directed Broadcast), sec (Security), ssrr (Strict Source Route), tr (Tracerote), ts (Timestamp), ump (Upstream Multicast Packet), visa (Experimental Access Control) and zsu (Experimental Measurement).

Security with CIPSO and IPSO

IPFilter supports filtering on IPv4 packets using security attributes embedded in the IP options part of the packet. These options are usually only used on networks and systems that are using lablled security. Unless you know that you are using labelled security and your networking is also labelled, it is highly unlikely that this section will be relevant to you.

With the traditional IP Security Options (IPSO), packets can be tagged with a security level. The following keywords are recognised and match with the relevant RFC with respect to the bit patterns matched: confid (confidential), rserve-1 (1st reserved value), rserve-2 (2nd reserved value), rserve-3 (3rd reserved value), rserve-4 (4th reserved value), secret (secret), topsecret (top secret), unclass (unclassified).

block in quick all with opt sec-class unclass
pass in all with opt sec-class secret

Matching IPv6 extension headers

Just as it is possible to filter on the various IPv4 header options, so too it is possible to filter on the IPv6 extension headers that are placed between the IPv6 header and the transport protocol header.

dstopts (destination options), esp (encrypted, secure, payload), frag (fragment), hopopts (hop-by-hop options), ipv6 (IPv6 header), mobility (IP mobility), none, routing.

Logging

There are two ways in which packets can be logged with IPFilter. The first is with a rule that specifically says log these types of packets and the second is a qualifier to one of the other keywords. Thus it is possible to both log and allow or deny a packet with a single rule.

pass in log quick proto tcp from any to any port = 22

When using stateful filtering, the log action becomes part of the result that is remembered about a packet. Thus if the above rule was qualified with keep state, every packet in the connection would be logged. To only log the first packet from every packet flow tracked with keep state, it is necessary to indicate to IPFilter that you only wish to log the first packet.

pass in log first quick proto tcp from any to any port = 22 \
flags S keep state

If it is a requirement that the logging provide an accurate representation of which connections are allowed, the log action can be qualified with the option or-block. This allows the administrator to instruct IPFilter to block the packet if the attempt to record the packet in IPFilter's kernel log records (which have an upper bound on size) failed. Unless the system shuts down or reboots, once a log record is written into the kernel buffer, it is there until ipmon(8) reads it.

block in log proto tcp from any to any port = smtp
pass in log or-block first quick proto tcp from any \
to any port = 22 flags S keep state

By default, IPFilter will only log the header portion of a packet received on the network. A portion of the body of a packet, upto 128 bytes, can also be logged with the body keyword. ipmon(8) will display the contents of the portion of the body logged in hex.

block in log body proto icmp all

When logging packets from ipmon(8) to syslog, by default ipmon(8) will control what syslog facility and priority a packet will be logged with. This can be tuned on a per rule basis like this:

block in quick log level err all with bad
pass in log level local1.info proto tcp \
from any to any port = 22 flags S keep state

ipfstat(8) reports how many packets have been successfully logged and how many failed attempts to log a packet there were.

Filter rule comments

If there is a desire to associate a text string, be it an administrative comment or otherwise, with an IPFilter rule, this can be achieved by giving the filter rule a comment. The comment is loaded with the rule into the kernel and can be seen when the rules are listed with ipfstat.

pass in quick proto tcp from any \
to port = 80 comment "all web server traffic is ok"
pass out quick proto tcp from any port = 80 \
to any comment "all web server traffic is ok"

Tags

To enable filtering and NAT to correctly match up packets with rules, tags can be added at with NAT (for inbound packets) and filtering (for outbound packets.) This allows a filter to be correctly mated with its NAT rule in the event that the NAT rule changed the packet in a way that would mean it is not obvious what it was.

For inbound packets, IPFilter can match the tag used in the filter rules with that set by NAT. For outbound rules, it is the reverse, the filter sets the tag and the NAT rule matches up with it.

pass in ... match-tag(nat=proxy)
pass out ... set-tag(nat=proxy)

Another use of tags is to supply a number that is only used with logging. When packets match these rules, the log tag is carried over into the log file records generated by ipmon(8). With the correct use of tools such as grep, extracting log records of interest is simplified.

block in quick log ... set-tag(log=33)

Table of visible variables

A list of all of the tunables, their minimum, maximum and current values is as follows.

Name Min Max Current
active 0 0 0
chksrc 0 1 0
control_forwarding 0 1 0
default_pass 0 MAXUINT 134217730
ftp_debug 0 10 0
ftp_forcepasv 0 1 1
ftp_insecure 0 1 0
ftp_pasvonly 0 1 0
ftp_pasvrdr 0 1 0
ftp_single_xfer 0 1 0
hostmap_size 1 MAXINT 2047
icmp_ack_timeout 1 MAXINT 12
icmp_minfragmtu 0 1 68
icmp_timeout 1 MAXINT 120
ip_timeout 1 MAXINT 120
ipf_flags 0 MAXUINT 0
ips_proxy_debug 0 10 0
log_all 0 1 0
log_size 0 524288 32768
log_suppress 0 1 1
min_ttl 0 1 4
nat_doflush 0 1 0
nat_lock 0 1 0
nat_logging 0 1 1
nat_maxbucket 1 MAXINT 22
nat_rules_size 1 MAXINT 127
nat_table_max 1 MAXINT 30000
nat_table_size 1 MAXINT 2047
nat_table_wm_high 2 100 99
nat_table_wm_low 1 99 90
rdr_rules_size 1 MAXINT 127
state_lock 0 1 0
state_logging 0 1 1
state_max 1 MAXINT 4013
state_maxbucket 1 MAXINT 26
state_size 1 MAXINT 5737
state_wm_freq 2 999999 20
state_wm_high 2 100 99
state_wm_low 1 99 90
tcp_close_wait 1 MAXINT 480
tcp_closed 1 MAXINT 60
tcp_half_closed 1 MAXINT 14400
tcp_idle_timeout 1 MAXINT 864000
tcp_last_ack 1 MAXINT 60
tcp_syn_received 1 MAXINT 480
tcp_syn_sent 1 MAXINT 480
tcp_time_wait 1 MAXINT 480
tcp_timeout 1 MAXINT 480
udp_ack_timeout 1 MAXINT 24
udp_timeout 1 MAXINT 240
update_ipid 0 1 0

IPFilter matching expressions

An experimental feature that has been added to filter rules is to use the same expression matching that is available with various commands to flush and list state/NAT table entries. The use of such an expression precludes the filter rule from using the normal IP header matching.

pass in exp { "tcp.sport 23 or tcp.sport 50" } keep state

Filter rules with BPF

On platforms that have the BPF built into the kernel, IPFilter can be built to allow BPF expressions in filter rules. This allows for packet matching to be on arbitrary data in the packt. The use of a BPF expression replaces all of the other protocol header matching done by IPFilter.

pass in bpf-v4 { "tcp and (src port 23 or src port 50)" } \
keep state

These rules tend to be write-only because the act of compiling the filter expression into the BPF instructions loaded into the kernel can make it difficut to accurately reconstruct the original text filter. The end result is that while ipf.conf() can be easy to read, understanding the output from ipfstat might not be.