SHOREWALL-POLICY(5)

okay bestie, pull up a chair because shorewall-policy(5) is a whole journey and I'm gonna walk you through every single line of it 💖 no cap, nothing skipped.

---

✨ NAME ✨

policy — the Shorewall policy file. That's the name, that's the job, iconic behavior only 🎀

🌸 SYNOPSIS 🌸

/etc/shorewall[6]/policy

Yep, that's the path, [6] and all — do not "fix" it, that's literally how it's written 💅

🦋 DESCRIPTION 🦋

So this file is where you define the high-level policy for connections between the zones you set up over in shorewall-zones(5). That's the vibe. Zones go in, policies come out.

⚠️ Important — the order of entries in this file is important

Like, actually important. This file is what decides what happens to a new connection request when we get no match from the shorewall-blrules(5) or shorewall-rules(5) files. And for each source/destination pair, the file gets processed in order until a match is found — and all will match any source or destination, so yeah, it'll gobble up whatever it can. Order is the whole game, bestie.

⚠️ Important — intra-zone policies are pre-defined

For $FW and for every zone defined in shorewall-zones(5), the POLICY for connections from a zone to itself is ACCEPT — with no logging and no TCP connection rate limiting — but you can override it with an entry in this file. Your override has to be explicit, meaning you put the zone name in both SOURCE and DEST, or it has to use all+ (that's Shorewall 4.5.17 or later, iykyk).

And similarly, if you've got IMPLICIT_CONTINUE=Yes in shorewall.conf(5), then the implicit policy to/from any sub-zone is CONTINUE. Those implicit CONTINUE policies can also be overridden by an explicit entry in this file. Slay.

The columns in the file go like this — and hey, where a column name is followed by a different name in parentheses, that different name is what you use in the alternate specification syntax. Cute, right? 💫

💜 SOURCE 💜

zone[,...[+]]|$FW|all[+][!ezone[,...]]

The source zone, babe. It must be the name of a zone defined in shorewall-zones(5), or $FW, or "all", or "all+".

• Support for all+ was added in Shorewall 4.5.17. all does not override the implicit intra-zone ACCEPT policy, while all+ does.
• Beginning with Shorewall 5.0.12, you can list multiple zones separated by commas. And like above, if + is specified after two or more zone names, then the policy overrides the implicit intra-zone ACCEPT policy if the same zone appears in both the SOURCE and DEST columns.
• Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones preceded by "!" may follow all or all+.

🦋 DEST 🦋

zone[,...[+]]|$FW|all[+][!ezone[,...]]

The destination zone. Same energy — it must be the name of a zone defined in shorewall-zones(5), or $FW, or "all", or "all+". But heads up: if the DEST is a bport zone, then the SOURCE must be "all", "all+", another bport zone associated with the same bridge, or it must be an ipv4 zone that is associated with only the same bridge. No mixing, sorry.

• Support for "all+" was added in Shorewall 4.5.17. "all" does not override the implicit intra-zone ACCEPT policy while "all+" does.
• Beginning with Shorewall 5.0.12, multiple zones may be listed separated by commas. As above, if + is specified after two or more zone names, then the policy overrides the implicit intra-zone ACCEPT policy if the same zone appears in both the SOURCE and DEST columns.
• Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones preceded by "!" may follow all or all+.

👑 POLICY 👑

{ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]|NONE}[:{[+]policy-action[:level][,...]|None}]

This is the policy used when no match from the rules file is found.

If the policy is neither CONTINUE nor NONE, then the policy may be followed by ":" and one of these two things:

1. The word "None" or "none". This causes any default action defined in shorewall.conf(5) to be omitted for this policy.
2. The name of an action with optional parameters enclosed in parentheses. That action will be invoked before the policy is enforced.

Actions can have parameters specified. Periodt.

• Beginning with Shorewall 4.5.10, the action name can be followed optionally by a colon and a log level. That level gets applied to each rule in the action or body that doesn't already have a log level.
• Beginning with Shorewall 5.1.2, multiple action[:level] specification may be listed, separated by commas. The actions are invoked in the order listed. Also beginning with Shorewall 5.1.2, the policy-action list can be prefixed with a plus sign ("+") indicating that the listed actions are in addition to those listed in the related _DEFAULT setting in shorewall.conf(5).

And now the possible policies themselves, bestie — collect them all:

• ACCEPT — Accept the connection. Yes, just let them in 💖
• DROP — Ignore the connection request. Not rejected, just... ignored. Ghosted.
• REJECT — For TCP, send RST. For all other, send an "unreachable" ICMP. Loud rejection, no subtlety.
• BLACKLIST — Added in Shorewall 5.1.1, and it requires that the DYNAMIC_BLACKLIST setting in shorewall.conf(5) specifies ipset-based dynamic blacklisting. The SOURCE IP address is added to the blacklist ipset and the connection request is ignored. Blocked and forgotten 💀
• QUEUE — Queue the request for a user-space application such as Snort-inline.
• NFQUEUE — Queue the request for a user-space application using the nfnetlink_queue mechanism. If a queuenumber1 is not given, queue zero (0) is assumed. Beginning with Shorewall 4.6.10, a second queue number (queuenumber2) may be given. This specifies a range of queues to use. Packets are then balanced across the given queues. This is useful for multicore systems: start multiple instances of the userspace program on queues x, x+1, .. x+n and use "x:x+n". Packets belonging to the same connection are put into the same nfqueue. Beginning with Shorewall 5.1.0, queuenumber2 may be followed by the letter 'c' to indicate that the CPU ID will be used as an index to map packets to the queues. The idea is that you can improve performance if there's a queue per CPU. Requires the NFQUEUE CPU Fanout capability in your kernel and iptables. Fancy 🔥
  • Beginning with Shorewall 4.6.10, the keyword bypass can be given. By default, if no userspace program is listening on an NFQUEUE, then all packets that are to be queued are dropped. When this option is used, the NFQUEUE rule behaves like ACCEPT instead.
• CONTINUE — Pass the connection request past any other rules that it might also match (where the source or destination zone in those rules is a superset of the SOURCE or DEST in this policy). See shorewall-nesting(5) for additional information. It's giving "keep it moving" 🦋
• NONE — Assume that there will never be any packets from this SOURCE to this DEST. Shorewall will not create any infrastructure to handle such packets, and you may not have any rules with this SOURCE and DEST in the /etc/shorewall/rules file. If such a packet is received, the result is undefined. And listen: NONE may not be used if the SOURCE or DEST columns contain the firewall zone ($FW) or "all". That one's a hard no, bestie.

🎀 LOGLEVEL (loglevel) 🎀

[log-level|ULOG|NFLOG]

Optional — if you supply it, each connection handled under the default POLICY is logged at that level. If you don't supply it, no log message is generated at all. See syslog.conf(5) for a description of log levels.

You may also specify ULOG or NFLOG — and those must be in upper case. This will log to the ULOG or NFLOG target and will send to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html).

For a description of logging, see shorewall-logging(5).

And if you don't want to log but you still need to specify the following column, just place "-" here. Easy ✨

🍓 RATE (rate) 🍓

[-|limit]

where limit is one of:

[-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:burst]
[name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}[:burst2]

If passed, this specifies the maximum TCP connection rate and the size of an acceptable burst. If not specified, TCP connections are not limited. And if the burst parameter is omitted, a value of 5 is assumed.

When s: or d: is specified, the rate applies per source IP address or per destination IP address respectively. The name may be chosen by the user and specifies a hash table to be used to count matching connections. If not given, the name shorewall is assumed. Where more than one POLICY or rule specifies the same name, the connections counts for the policies are aggregated and the individual rates apply to the aggregated count. Beginning with Shorewall 5.2.1, the s or d may be followed by a slash ("/") and an integer vlsm. When a vlsm is specified, all source or destination addresses encountered will be grouped according to the given prefix length and the so-created subnet will be subject to the rate limit.

Beginning with Shorewall 4.6.5, two limits may be specified, separated by a comma. In this case, the first limit (name1, rate1, burst1) specifies the per-source IP limit and the second limit specifies the per-destination IP limit.

Example: client:10/sec:20,:60/sec:100

Beginning with Shorewall 5.2.1, the table name, if any, may be followed by two integers separated by commas and enclosed in parentheses. The first integer (ht-buckets) specifies the number of buckets in the generated hash table. The second integer (ht-max) specifies the maximum number of entries in the hash table.

Example: s:client(1024,65536):10/sec

🌈 CONNLIMIT 🌈

limit[:mask]

This one may be used to limit the number of simultaneous connections from each individual host — yes, connection limiting, we love to see it. While the limit is only checked on connections to which this policy could apply, the number of current connections is calculated over all current connections from the SOURCE host. By default, the limit is applied to each host individually, but it can be made to apply to networks of hosts by specifying a mask. That mask specifies the width of a VLSM mask to be applied to the source address; the number of current connections is then taken over all hosts in the subnet source-address/mask.

---

and that's where part 1 wraps, bestie — hold that thought, because there's more coming 🫶

✨ EXAMPLE ✨

ok so here's a whole lil scenario bestie, three rules, three vibes 💅

1. Every connection coming from the local network out to the internet? Allowed. no questions, go off king 👑
2. Every connection coming from the internet? Ignored, but logged at syslog level KERNEL.INFO. so we're not answering, we're just... taking notes 📝
3. Every other connection request? Rejected, and also logged at level KERNEL.INFO. bye 💀

#SOURCE         DEST            POLICY          LOG           BURST:LIMIT
#                                               LEVEL
loc             net             ACCEPT
net             all             DROP            info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all             all             REJECT          info

okay the all all REJECT info line being last is not a suggestion, it's the law of the land — the comment in the file literally yells it at you and honestly? she's right 🫶

---

🌸 FILES 🌸

• /etc/shorewall/policy
• /etc/shorewall6/policy

---

🦋 SEE ALSO 🦋

• https://shorewall.org/configuration_file_basics.htm#Pairs[7]
• shorewall(8)

---

🎀 NOTES 🎀

1. shorewall-zones https://shorewall.org/manpages/shorewall-zones.html
2. shorewall-blrules https://shorewall.org/manpages/shorewall-blrules.html
3. shorewall-rules https://shorewall.org/manpages/shorewall-rules.html
4. shorewall.conf https://shorewall.org/manpages/shorewall.conf.html
5. shorewall-nesting https://shorewall.org/manpages/shorewall-nesting.html
6. shorewall-logging(5) https://shorewall.org/shorewall_logging.html
7. https://shorewall.org/configuration_file_basics.htm#Pairs https://shorewall.org/configuration_file_basics.htm#Pairs

---

ok that's the whole page bestie, you ate it, no crumbs left 🍓✨ this one's from the Configuration Files section, dated 09/24/2020, and it's SHOREWALL-POLICY(5) — go forth and configure responsibly, mwah 💖