1SHOREWALL-POLICY(5)           Configuration Files          SHOREWALL-POLICY(5)
2
3
4

NAME

6       policy - Shorewall policy file
7

SYNOPSIS

9       /etc/shorewall[6]/policy
10

DESCRIPTION

12       This file defines the high-level policy for connections between zones
13       defined in shorewall-zones[1](5).
14
15           Important
16           The order of entries in this file is important
17
18           This file determines what to do with a new connection request if we
19           don't get a match from the shorewall-blrules[2](5) or
20           shorewall-rules[3](5) files. For each source/destination pair, the
21           file is processed in order until a match is found ("all" will match
22           any source or destination).
23
24           Important
25           Intra-zone policies are pre-defined
26
27           For $FW and for all of the zones defined in shorewall-zones[1](5),
28           the POLICY for connections from the zone to itself is ACCEPT (with
29           no logging or TCP connection rate limiting) but may be overridden
30           by an entry in this file. The overriding entry must be explicit
31           (specifying the zone name in both SOURCE and DEST) or it must use
32           "all+" (Shorewall 4.5.17 or later).
33
34           Similarly, if you have IMPLICIT_CONTINUE=Yes in
35           shorewall.conf[4](5), then the implicit policy to/from any sub-zone
36           is CONTINUE. These implicit CONTINUE policies may also be
37           overridden by an explicit entry in this file.
38
39       The columns in the file are as follows (where the column name is
40       followed by a different name in parentheses, the different name is used
41       in the alternate specification syntax).
42
43       SOURCE - zone[,...[+]]|$FW|all[+][!ezone[,...]]
44           Source zone. Must be the name of a zone defined in
45           shorewall-zones[1](5), $FW, "all" or "all+".
46
47           Support for all+ was added in Shorewall 4.5.17.  all does not
48           override the implicit intra-zone ACCEPT policy while all+ does.
49
50           Beginning with Shorewall 5.0.12, multiple zones may be listed
51           separated by commas. As above, if '+' is specified after two or
52           more zone names, then the policy overrides the implicit intra-zone
53           ACCEPT policy if the same zone appears in both the SOURCE and DEST
54           columns.
55
56           Beginning with Shorewall 5.2.3, a comma-separated list of excluded
57           zones preceded by "!" may follow all or all+.
58
59       DEST - zone[,...[+]]|$FW|all[+][!ezone[,...]]
60           Destination zone. Must be the name of a zone defined in
61           shorewall-zones[1](5), $FW, "all" or "all+". If the DEST is a bport
62           zone, then the SOURCE must be "all", "all+", another bport zone
63           associated with the same bridge, or it must be an ipv4 zone that is
64           associated with only the same bridge.
65
66           Support for "all+" was added in Shorewall 4.5.17. "all" does not
67           override the implicit intra-zone ACCEPT policy while "all+" does.
68
69           Beginning with Shorewall 5.0.12, multiple zones may be listed
70           separated by commas. As above, if '+' is specified after two or
71           more zone names, then the policy overrides the implicit intra-zone
72           ACCEPT policy if the same zone appears in both the SOURCE and DEST
73           columns.
74
75           Beginning with Shorewall 5.2.3, a comma-separated list of excluded
76           zones preceded by "!" may follow all or all+.
77
78       POLICY -
79       {ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]|NONE}[:{[+]policy-action[:level][,...]|None}]
80           Policy if no match from the rules file is found.
81
82           If the policy is neither CONTINUE nor NONE then the policy may be
83           followed by ":" and one of the following:
84
85            1. The word "None" or "none". This causes any default action
86               defined in shorewall.conf[4](5) to be omitted for this policy.
87
88            2. The name of an action with optional parameters enclosed in
89               parentheses. The action will be invoked before the policy is
90               enforced.
91
92           Actions can have parameters specified.
93
94           Beginning with Shorewall 4.5.10, the action name can be followed
95           optionally by a colon and a log level. The level will be applied to
96           each rule in the action or body that does not already have a log
97           level.
98
99           Beginning with Shorewall 5.1.2, multiple action[:level]
100           specification may be listeded, separated by commas. The actions are
101           invoked in the order listed. Also beginning with Shorewall 5.1.2,
102           the policy-action list can be prefixed with a plus sign ("+")
103           indicating that the listed actions are in addition to those listed
104           in the related _DEFAULT setting in shorewall.conf[4](5).
105
106           Possible policies are:
107
108           ACCEPT
109               Accept the connection.
110
111           DROP
112               Ignore the connection request.
113
114           REJECT
115               For TCP, send RST. For all other, send an "unreachable" ICMP.
116
117           BLACKLIST
118               Added in Shorewall 5.1.1 and requires that the
119               DYNAMIC_BLACKLIST setting in shorewall.conf[4](5) specifies
120               ipset-based dynamic blacklisting. The SOURCE IP address is
121               added to the blacklist ipset and the connection request is
122               ignored.
123
124           QUEUE
125               Queue the request for a user-space application such as
126               Snort-inline.
127
128           NFQUEUE
129               Queue the request for a user-space application using the
130               nfnetlink_queue mechanism. If a queuenumber1 is not given,
131               queue zero (0) is assumed. Beginning with Shorewall 4.6.10, a
132               second queue number (queuenumber2) may be given. This specifies
133               a range of queues to use. Packets are then balanced across the
134               given queues. This is useful for multicore systems: start
135               multiple instances of the userspace program on queues x, x+1,
136               .. x+n and use "x:x+n". Packets belonging to the same
137               connection are put into the same nfqueue. Beginning with
138               Shorewall 5.1.0, queuenumber2 may be followed by the letter 'c'
139               to indicate that the CPU ID will be used as an index to map
140               packets to the queues. The idea is that you can improve
141               performance if there's a queue per CPU. Requires the NFQUEUE
142               CPU Fanout capability in your kernel and iptables.
143
144               Beginning with Shorewall 4.6.10, the keyword bypass can be
145               given. By default, if no userspace program is listening on an
146               NFQUEUE, then all packets that are to be queued are dropped.
147               When this option is used, the NFQUEUE rule behaves like ACCEPT
148               instead.
149
150           CONTINUE
151               Pass the connection request past any other rules that it might
152               also match (where the source or destination zone in those rules
153               is a superset of the SOURCE or DEST in this policy). See
154               shorewall-nesting[5](5) for additional information.
155
156           NONE
157               Assume that there will never be any packets from this SOURCE to
158               this DEST. Shorewall will not create any infrastructure to
159               handle such packets and you may not have any rules with this
160               SOURCE and DEST in the /etc/shorewall/rules file. If such a
161               packet is received, the result is undefined. NONE may not be
162               used if the SOURCE or DEST columns contain the firewall zone
163               ($FW) or "all".
164
165       LOGLEVEL (loglevel) - [log-level|ULOG|NFLOG]
166           Optional - if supplied, each connection handled under the default
167           POLICY is logged at that level. If not supplied, no log message is
168           generated. See syslog.conf(5) for a description of log levels.
169
170           You may also specify ULOG or NFLOG (must be in upper case). This
171           will log to the ULOG or NFLOG target and will send to a separate
172           log through use of ulogd
173           (http://www.netfilter.org/projects/ulogd/index.html).
174
175           For a description of logging, see shorewall-logging(5)[6].
176
177           If you don't want to log but need to specify the following column,
178           place "-" here.
179
180       RATE (rate) - [-|limit]
181           where limit is one of:
182               [-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:burst]
183               [name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}[:burst2]
184           If passed, specifies the maximum TCP connection rate and the size
185           of an acceptable burst. If not specified, TCP connections are not
186           limited. If the burst parameter is omitted, a value of 5 is
187           assumed.
188
189           When s: or d: is specified, the rate applies per source IP address
190           or per destination IP address respectively. The name may be chosen
191           by the user and specifies a hash table to be used to count matching
192           connections. If not give, the name shorewall is assumed. Where more
193           than one POLICY or rule specifies the same name, the connections
194           counts for the policies are aggregated and the individual rates
195           apply to the aggregated count. Beginning with Shorewall 5.2.1, the
196           s or d may be followed by a slash ("/") and an integer vlsm. When a
197           vlsm is specified, all source or destination addresses encountered
198           will be grouped according to the given prefix length and the
199           so-created subnet will be subject to the rate limit.
200
201           Beginning with Shorewall 4.6.5, two limits may be specified,
202           separated by a comma. In this case, the first limit (name1, rate1,
203           burst1) specifies the per-source IP limit and the second limit
204           specifies the per-destination IP limit.
205
206           Example: client:10/sec:20,:60/sec:100
207
208           Beginning with Shorewall 5.2.1, the table name, if any, may be
209           followed by two integers separated by commas and enclosed in
210           parentheses. The first integer (ht-buckets) specifies the number of
211           buckets in the generated hash table. The second integer (ht-max)
212           specifies the maximum number of entries in the hash table.
213
214           Example: s:client(1024,65536):10/sec
215
216       CONNLIMIT - limit[:mask]
217           May be used to limit the number of simultaneous connections from
218           each individual host to limit connections. While the limit is only
219           checked on connections to which this policy could apply, the number
220           of current connections is calculated over all current connections
221           from the SOURCE host. By default, the limit is applied to each host
222           individually but can be made to apply to networks of hosts by
223           specifying a mask. The mask specifies the width of a VLSM mask to
224           be applied to the source address; the number of current connections
225           is then taken over all hosts in the subnet source-address/mask.
226

EXAMPLE

228        1. All connections from the local network to the internet are allowed
229
230        2. All connections from the internet are ignored but logged at syslog
231           level KERNEL.INFO.
232
233        3. All other connection requests are rejected and logged at level
234           KERNEL.INFO.
235
236                   #SOURCE         DEST            POLICY          LOG           BURST:LIMIT
237                   #                                               LEVEL
238                   loc             net             ACCEPT
239                   net             all             DROP            info
240                   #
241                   # THE FOLLOWING POLICY MUST BE LAST
242                   #
243                   all             all             REJECT          info
244

FILES

246       /etc/shorewall/policy
247
248       /etc/shorewall6/policy
249

SEE ALSO

251       https://shorewall.org/configuration_file_basics.htm#Pairs[7]
252
253       shorewall(8)
254

NOTES

256        1. shorewall-zones
257           https://shorewall.org/manpages/shorewall-zones.html
258
259        2. shorewall-blrules
260           https://shorewall.org/manpages/shorewall-blrules.html
261
262        3. shorewall-rules
263           https://shorewall.org/manpages/shorewall-rules.html
264
265        4. shorewall.conf
266           https://shorewall.org/manpages/shorewall.conf.html
267
268        5. shorewall-nesting
269           https://shorewall.org/manpages/shorewall-nesting.html
270
271        6. shorewall-logging(5)
272           https://shorewall.org/shorewall_logging.html
273
274        7. https://shorewall.org/configuration_file_basics.htm#Pairs
275           https://shorewall.org/configuration_file_basics.htm#Pairs
276
277
278
279Configuration Files               09/24/2020               SHOREWALL-POLICY(5)
Impressum