firewalld.direct(5)

1FIREWALLD.DIRECT(5)            firewalld.direct            FIREWALLD.DIRECT(5)
2
3
4

NAME

6       firewalld.direct - firewalld direct configuration file
7

SYNOPSIS

9       /etc/firewalld/direct.xml
10
11
12

DESCRIPTION

14       Direct configuration gives a more direct access to the firewall. It
15       requires user to know basic ip(6)tables/ebtables concepts, i.e.  table
16       (filter/mangle/nat/...), chain (INPUT/OUTPUT/FORWARD/...), commands
17       (-A/-D/-I/...), parameters (-p/-s/-d/-j/...) and targets
18       (ACCEPT/DROP/REJECT/...). Direct configuration should be used only as a
19       last resort when it's not possible to use firewalld.zone(5). See also
20       Direct Options in firewall-cmd(1).
21
22       A firewalld direct configuration file contains informations about
23       permanent direct chains, rules and passthrough ...
24
25       This is the structure of a direct configuration file:
26
27           <?xml version="1.0" encoding="utf-8"?>
28           <direct>
29             [ <chain ipv="ipv4|ipv6|eb" table="table" chain="chain"/> ]
30             [ <rule ipv="ipv4|ipv6|eb" table="table" chain="chain" priority="priority"> args </rule> ]
31             [ <passthrough ipv="ipv4|ipv6|eb"> args </passthrough> ]
32           </direct>
33
34
35
36   direct
37       The mandatory direct start and end tag defines the direct. This tag can
38       only be used once in a direct configuration file. There are no
39       attributes for direct.
40
41   chain
42       Is an optional empty-element tag and can be used several times. It can
43       be used to define names for additional chains. A chain entry has
44       exactly three attributes:
45
46       ipv="ipv4|ipv6|eb"
47           The IP family where the chain will be created. This can be either
48           ipv4, ipv6 or eb.
49
50       table="table"
51           The table name where the chain will be created. This can be one of
52           the tables that can be used for iptables, ip6tables or ebtables.
53           For the possible values, see TABLES section in the iptables,
54           ip6tables or ebtables man pages.
55
56       chain="chain"
57           The name of the chain, that will be created. Please make sure that
58           there is no other chain with this name already.
59
60       Please remember to add a rule or passthrough rule with an --jump or
61       --goto option to connect the chain to another one.
62
63   rule
64       Is an optional element tag and can be used several times. It can be
65       used to add rules to a built-in or added chain. A rule entry has
66       exactly four attributes:
67
68       ipv="ipv4|ipv6|eb"
69           The IP family where the rule will be added. This can be either
70           ipv4, ipv6 or eb.
71
72       table="table"
73           The table name where the rule will be added. This can be one of the
74           tables that can be used for iptables, ip6tables or ebtables. For
75           the possible values, see TABLES section in the iptables, ip6tables
76           or ebtables man pages.
77
78       chain="chain"
79           The name of the chain where the rule will be added. This can be
80           either a built-in chain or a chain that has been created with the
81           chain tag. If the chain name is a built-in chain, then the rule
82           will be added to chain_direct, else the supplied chain name is
83           used.  chain_direct is created internally for all built-in chains
84           to make sure that the added rules do not conflict with the rules
85           created by firewalld.
86
87       priority="priority"
88           The priority is used to order rules. Priority 0 means add rule on
89           top of the chain, with a higher priority the rule will be added
90           further down. Rules with the same priority are on the same level
91           and the order of these rules is not fixed and may change. If you
92           want to make sure that a rule will be added after another one, use
93           a low priority for the first and a higher for the following.
94
95       The args can be any arguments of iptables or ip6tables, that do not
96       conflict with the table or chain attributes.
97
98   passthrough
99       Is an optional element tag and can be used several times. It can be
100       used to add rules to a built-in or added chain. A rule entry has
101       exactly one attribute:
102
103       ipv="ipv4|ipv6|eb"
104           The IP family where the passthrough rule will be added. This can be
105           either ipv4, ipv6 or eb.
106
107       The args can be any arguments of iptables or ip6tables.
108
109       The passthrough rule will be added to the chain directly. There is no
110       mechanism like for the direct rule above. The user of the passthrough
111       rule has to make sure that there will be no conflict with the rules
112       created by firewalld.
113

CAVEATS

115       Depending on the value of FirewallBackend (see firewalld.conf(5))
116       direct rules behave differently in some scenarios.
117
118   Packet accept/drop precedence
119       Due to implementation details of netfilter inside the kernel, if
120       FirewallBackend=nftables is used direct rules that ACCEPT packets don't
121       actually cause the packets to be immediately accepted by the system.
122       Those packets are still be subject to firewalld's nftables ruleset.
123       This basically means there are two independent firewalls and packets
124       must be accepted by both (iptables and nftables). As an aside, this
125       scenario also occurs inside of nftables (again due to netfilter) if
126       there are multiple chains attached to the same hook - it's not as
127       simple as iptables vs nftables.
128
129       There are a handful of options to workaround the ACCEPT issue:
130
131        1. Rich Rules
132
133           If a rich rule can be used, then they should always be preferred
134           over direct rules. Rich Rules will be converted to the enabled
135           FirewallBackend. See firewalld.richlanguage(5).
136
137        2. Blanket Accept
138
139           Users can add an explicit accept to the nftables ruleset. This can
140           be done by adding the interface or source to the trusted zone.
141
142           This strategy is often employed by things that perform their own
143           filtering such as: libvirt, podman, docker.
144
145           Warning: This means firewalld will do no filtering on these
146           packets. It must all be done via direct rules or out-of-band
147           iptables rules.
148
149        3. Selective Accept
150
151           Alternatively, enable only the relevant service, port, address, or
152           otherwise in the appropriate zone.
153
154        4. Revert to the iptables backend
155
156           A last resort is to revert to the iptables backend by setting
157           FirewallBackend=iptables. Users should be aware that firewalld
158           development focuses on the nftables backend.
159
160       For direct rules that DROP packets the packets are immediately dropped
161       regardless of the value of FirewallBackend. As such, there is no
162       special consideration needed.
163
164       Firewalld guarantees the above ACCEPT/DROP behavior by registering
165       nftables hooks with a lower precedence than iptables hooks.
166
167   Direct interface precedence
168       With FirewallBackend=iptables firewalld's top-level internal rules
169       apply before direct rules are executed. This includes rules to accept
170       existing connections. In the past this has surprised users. As an
171       example, if a user adds a direct rule to drop traffic on destination
172       port 22 existing SSH sessions would continue to function, but new
173       connections would be denied.
174
175       With FirewallBackend=nftables direct rules were deliberately given a
176       higher precedence than all other firewalld rules. This includes rules
177       to accept existing connections.
178

EXAMPLE

180       Denylisting of the networks 192.168.1.0/24 and 192.168.5.0/24 with
181       logging and dropping early in the raw table:
182
183           <?xml version="1.0" encoding="utf-8"?>
184           <direct>
185             <chain ipv="ipv4" table="raw" chain="denylist"/>
186             <rule ipv="ipv4" table="raw" chain="PREROUTING" priority="0">-s 192.168.1.0/24 -j denylist</rule>
187             <rule ipv="ipv4" table="raw" chain="PREROUTING" priority="1">-s 192.168.5.0/24 -j denylist</rule>
188             <rule ipv="ipv4" table="raw" chain="denylist" priority="0">-m limit --limit 1/min -j LOG --log-prefix "denylisted: "</rule>
189             <rule ipv="ipv4" table="raw" chain="denylist" priority="1">-j DROP</rule>
190           </direct>
191
192
193

NOTES

203       firewalld home page:
204           http://firewalld.org
205
206       More documentation with examples:
207           http://fedoraproject.org/wiki/FirewallD
208

AUTHORS

210       Thomas Woerner <twoerner@redhat.com>
211           Developer
212
213       Jiri Popelka <jpopelka@redhat.com>
214           Developer
215
216       Eric Garver <eric@garver.life>
217           Developer
218
219
220
221firewalld 0.9.3                                            FIREWALLD.DIRECT(5)