bfcli
¶
bfcli
is part of bpfilter
sources, it has been created in order to speed up bpfilter
development by providing a CLI using a trivial communication format with the daemon. For this reason, bfcli
is the main CLI used to develop bpfilter
, and it uses the new features of bpfilter
before any other front-end.
bfcli
can read a ruleset from a source file (using --file
) or from its arguments (using --str
):
bfcli --file myruleset.tx
bfcli --str "chain BF_HOOK_XDP policy ACCEPT rule ip4.saddr in {192.168.1.1} ACCEPT"
The following sections will use the dollar sign ($
) to prefix values that should be replaced by the user, and brackets ([]
) for optional values (whether it’s a literal or a user-provided value).
Example of a ruleset:
chain $HOOK policy $POLICY
rule
$MATCHER
$VERDICT
[...]
[...]
- A ruleset is composed of chain(s), rule(s), and matcher(s):
A chain is a set of rule(s) to match the packet against. It will use the rules to filter packets at a specific location in the kernel: a
$HOOK
. There can be only one chain defined for a given kernel hook. Chains also have a$POLICY
which specify the action to take with the packet if none of the rules matches.A rule defines an action to take on a packet if it matches all its specified criteria. A rule will then apply a defined action to the packet if it’s matched.
A matcher is a matching criterion within a rule. It can match a specific protocol, a specific field, a network interface… The number of matchers supported by
bpfilter
andbfcli
is constantly growing.
Note
Lines starting with #
are comments and bfcli
will ignore them.
Chains¶
Chains are defined such as:
chain $HOOK{$OPTIONS} policy $POLICY
- With:
$HOOK
: hook in the kernel to attach the chain to:BF_HOOK_XDP
: XDP hook.BF_HOOK_TC_INGRESS
: ingress TC hook.BF_HOOK_NF_PRE_ROUTING
: similar tonftables
andiptables
prerouting hook.BF_HOOK_NF_LOCAL_IN
: similar tonftables
andiptables
input hook.BF_HOOK_CGROUP_INGRESS
: ingress cgroup hook.BF_HOOK_CGROUP_EGRESS
: egress cgroup hook.BF_HOOK_NF_FORWARD
: similar tonftables
andiptables
forward hook.BF_HOOK_NF_LOCAL_OUT
: similar tonftables
andiptables
output hook.BF_HOOK_NF_POST_ROUTING
: similar tonftables
andiptables
postrouting hook.BF_HOOK_TC_EGRESS
: egress TC hook.
$POLICY
: action taken if no rule matches the packet, eitherACCEPT
forward the packet to the kernel, orDROP
to discard it.
$OPTIONS
are hook-specific comma separated key value pairs:
Option |
Supported values |
Notes |
---|---|---|
|
|
Interface index to attach the program to. |
|
|
Path to the cgroup to attach to. |
|
Allowed patern: |
Name of the chain, will be reused as the name of the BPF program. A same name can be reused for multiple chains. Must be at most |
|
|
If |
Note
name=$CHAIN_NAME
will only change the name of the BPF program loaded into the kernel. It won’t affect the map names, not the pin path. Defining multiple programs with the same name is possible, but a name clash could prevent the program from being pinned.
Rules¶
Rules are defined such as:
rule
[$MATCHER...]
[counter]
$VERDICT
- With:
$MATCHER
: zero or more matchers. Matchers are defined later.counter
: optional literal. If set, the filter will counter the number of packets and bytes matched by the rule.$VERDICT
: action taken by the rule if the packet is matched against all the criteria: eitherACCEPT
orDROP
.
In a chain, as soon as a rule matches a packet, its verdict is applied, and the subsequent rules are not processed. Hence, the rules’ order matters. If no rule matches the packet, the chain’s policy is applied.
Matchers¶
Matchers are defined such as:
$TYPE [$OP] $PAYLOAD
- With:
$TYPE
: type of the matcher, defined which part of the processed network packet need to be compared against. All the exact matcher types are defined below.$OP
: comparison operation, not all$TYPE
of matchers support all the existing comparison operators:eq
: exact equality.not
: inequality.any
: match the packet against a set of data defined as the payload. If any of the member of the payload set is found in the packet, the matcher is positive. For example, if you want to match all theicmp
andudp
packets:ip4.proto any icmp,udp
.all
: match the packet against a set of data defined as the payload. If all the member of the payload set are found in the packet, the matcher is positive, even if the packet contains more than only the members defined in the payload. For example, to match all the packets containing at least theACK
TCP flag:tcp.flags all ACK
.in
: matches the packet against a hashed set of reference values. Using thein
operator is useful when the packet’s data needs to be compared against a large set of different values. Let’s say you want to filter 1000 different IPv4 addresses, you can either define 1000ip4.saddr eq $IP
matcher, in which casebpfilter
will compare the packet against every IP one after the other. Or you can useip4.saddr in {$IP0,IP1,...}
in which casebpfilter
will compare the packet’s data against the hashed set as a whole in 1 operation.
$PAYLOAD
: payload to compare to the processed network packet. The exact payload format depends on$TYPE
.
Meta matchers
Matches |
Type |
Operator |
Payload |
Notes |
---|---|---|---|---|
Interface index |
|
|
|
For chains attached to an ingress hook, |
L3 protocol |
|
|
|
|
L4 protocol |
|
|
|
|
IPv4 matchers
Matches |
Type |
Operator |
Payload |
Notes |
---|---|---|---|---|
Source address |
|
|
|
|
|
||||
|
|
Only support |
||
Destination address |
|
|
|
|
|
||||
|
|
Only support |
||
Protocol |
|
|
|
Only |
IPv6 matchers
Matches |
Type |
Operator |
Payload |
Notes |
---|---|---|---|---|
Source address |
|
|
|
|
|
||||
Destination address |
|
|
||
|
TCP matchers
Matches |
Type |
Operator |
Payload |
Notes |
---|---|---|---|---|
Source port |
|
|
|
|
|
||||
Destination port |
|
|
|
|
|
||||
Flags |
|
|
|
|
|
||||
|
||||
|
UDP matchers
Matches |
Type |
Operator |
Payload |
Notes |
---|---|---|---|---|
Source port |
|
|
|
|
|
||||
Destination port |
|
|
|
|
|