pfctl - control the packet filter (PF) and network address translation (NAT) device
Packet filtering restricts the types of packets that pass through network interfaces entering or leaving the host based on filter rules as described in pf.conf5. The packet filter can also replace addresses and ports of packets. Replacing source addresses and ports of outgoing packets is called NAT (Network Address Translation) and is used to connect an internal network (usually reserved address space) to an external one (the Internet) by making all connections to external hosts appear to come from the gateway. Replacing destination addresses and ports of incoming packets is used to redirect connections to different hosts and/or ports. A combination of both translations, bidirectional NAT, is also supported. Translation rules are described in pf.conf5.
When the variable pf is set to YES in rc.conf.local5, the rule file specified with the variable pf_rules is loaded automatically by the rc(8) scripts and the packet filter is enabled.
The packet filter does not itself forward packets between interfaces. Forwarding can be enabled by setting the sysctl(8) variables net.inet.ip.forwarding and/or net.inet6.ip6.forwarding to 1. Set them permanently in sysctl.conf5.
The pfctl utility provides several commands. The options are as follows:
Anchors are referenced by name and may be nested, with the various components of the anchor path separated by `/' characters, similar to how file system hierarchies are laid out. The last component of the anchor path is where ruleset operations are performed.
Evaluation of anchor rules from the main ruleset is described in pf.conf5.
For example, the following will show all filter rules (see the -s flag below) inside the anchor ``authpf/smith(1234)'' which would have been created for user ``smith'' by authpf(8), PID 1234:
# pfctl -a "authpf/smith(1234)" -s rules
Private tables can also be put inside anchors, either by having table statements in the pf.conf5 file that is loaded in the anchor, or by using regular table commands, as in:
# pfctl -a foo/bar -t mytable -T add 1.2.3.4 5.6.7.8
When a rule referring to a table is loaded in an anchor, the rule will use the private table if one is defined, and then fall back to the table defined in the main ruleset, if there is one. This is similar to C rules for variable scope. It is possible to create distinct tables with the same name in the global ruleset and in an anchor, but this is often bad design and a warning will be issued in that case.
By default, recursive inline printing of anchors applies only to unnamed anchors specified inline in the ruleset. If the anchor name is terminated with a `*' character, the -s flag will recursively print all anchors in a brace delimited block. For example the following will print the ``authpf'' ruleset recursively:
# pfctl -a 'authpf/*' -sr
To print the main ruleset recursively, specify only `*' as the anchor name:
# pfctl -a '*' -sr
# pfctl -k host
To kill all of the state entries from ``host1'' to ``host2''
# pfctl -k host1 -k host2
To kill all states originating from 192.168.1.0/24 to 172.16.0.0/16:
# pfctl -k 192.168.1.0/24 -k 172.16.0.0/16
A network prefix length of 0 can be used as a wildcard. To kill all states with the target ``host2''
# pfctl -k 0.0.0.0/0 -k host2
# echo "set loginterface fxp0" | pfctl -mf -
basic optimization does does four things:
If profile is specified, the currently loaded ruleset will be examined as a feedback profile to tailor the optimization of the quick rules to the actual network behavior.
It is important to note that the ruleset optimizer will modify the ruleset to improve performance. A side effect of the ruleset modification is that per-rule accounting statistics will have different meanings than before. If per-rule accounting is important for billing purposes or whatnot, either the ruleset optimizer should not be used or a label field should be added to all of the accounting rules to act as optimization barriers.
To retain compatibility with previous behaviour, a single -o without any options will enable basic optimizations, and a second -o will enable profiling.
# pfctl -Tl -f pf.conf
For the add delete replace and test commands, the list of addresses can be specified either directly on the command line and/or in an unformatted text file, using the -f flag. Comments starting with a `#' are allowed in the text file. With these commands, the -v flag can also be used once or twice, in which case pfctl will print the detailed result of the operation for each individual address, prefixed by one of the following letters:
Each table maintains a set of counters that can be retrieved using the -v flag of . For example, the following commands define a wide open firewall which will keep track of packets going to or coming from the Ox FTP server. The following commands configure the firewall and send 10 pings to the FTP server:
# printf "table <test> { ftp.openbsd.org }\n \
pass out to <test>\n" | pfctl -f-
# ping -qc10 ftp.openbsd.org
We can now use the table show command to output, for each address and packet direction, the number of packets and bytes that are being passed or blocked by rules referencing the table. The time at which the current accounting started is also shown with the ``Cleared'' line.
# pfctl -t test -vTshow
129.128.5.191
Cleared: Thu Feb 13 18:55:18 2003
In/Block: [ Packets: 0 Bytes: 0 ]
In/Pass: [ Packets: 10 Bytes: 840 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 10 Bytes: 840 ]
Similarly, it is possible to view global information about the tables by using the -v modifier twice and the -s Tables command. This will display the number of addresses on each table, the number of rules which reference the table, and the global packet statistics for the whole table:
# pfctl -vvsTables
--a-r- test
Addresses: 1
Cleared: Thu Feb 13 18:55:18 2003
References: [ Anchors: 0 Rules: 1 ]
Evaluations: [ NoMatch: 3496 Match: 1 ]
In/Block: [ Packets: 0 Bytes: 0 ]
In/Pass: [ Packets: 10 Bytes: 840 ]
In/XPass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 10 Bytes: 840 ]
Out/XPass: [ Packets: 0 Bytes: 0 ]
As we can see here, only one packet - the initial ping request - matched the table, but all packets passing as the result of the state are correctly accounted for. Reloading the table(s) or ruleset will not affect packet accounting in any way. The two ``XPass'' counters are incremented instead of the ``Pass'' counters when a ``stateful'' packet is passed but doesn't match the table anymore. This will happen in our example if someone flushes the table while the ping(8) command is running.
When used with a single -v pfctl will only display the first line containing the table flags and name. The flags are defined as follows:
|
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |