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

DEPRECATED

14       The direct interface has been deprecated. It will be removed in a
15       future release. It is superseded by policies, see
16       firewalld.policies(5).
17

DESCRIPTION

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

CAVEATS

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

EXAMPLE

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

NOTES

208       firewalld home page:
209           http://firewalld.org
210
211       More documentation with examples:
212           http://fedoraproject.org/wiki/FirewallD
213

AUTHORS

215       Thomas Woerner <twoerner@redhat.com>
216           Developer
217
218       Jiri Popelka <jpopelka@redhat.com>
219           Developer
220
221       Eric Garver <eric@garver.life>
222           Developer
223
224
225
226firewalld 1.0.1                                            FIREWALLD.DIRECT(5)