SHOREWALL-BLRULES(5)

💅 SHOREWALL-BLRULES(5) — blrules, the Blacklist file bestie ✨

okay so welcome to the blrules manual page, aka shorewall's Blacklist file — yes that's the whole NAME, we're keeping it cute but complete 🎀

---

✨ SYNOPSIS ✨

/etc/shorewall[6]/blrules

---

🌸 DESCRIPTION 🌸

bestie. this file is literally where you do your blacklisting and your whitelisting. it's giving gatekeeper energy, but make it firewall 🫶

the rules in here get applied based on how BLACKLIST is set in shorewall.conf(5). no cap, that setting controls the whole vibe of this file.

the format of the rules in this file? same format as the rules in shorewall-rules(5). identical. the only difference between the two files is in the ACTION column, which is the first column. that's it, that's the plot twist 😭

🦋 ACTION 🦋

{ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)]}[:{log-level|none}[!][:tag]]

this tells shorewall what to do with a packet when it matches the rule. it has to be one of these, periodt:

• BLACKLIST — added way back in Shorewall 4.5.3. this one is actually a macro, and it expands like this:
  • if BLACKLIST_LOGLEVEL is specified in shorewall.conf(5), then the macro expands to blacklog.
  • otherwise it expands to the action specified for BLACKLIST_DISPOSITION in shorewall.conf(5).
• blacklog — you may only use this if BLACKLIST_LOGLEVEL is specified in shorewall.conf(5). it logs, audits (if that's specified), and applies the BLACKLIST_DISPOSITION from shorewall.conf(5).
• ACCEPT | CONTINUE | WHITELIST — exempts the packet from the remaining rules in this file. the packet is free 💖
• DROP — ignore the packet. not today.
• A_DROP — the audited version of DROP. this needs AUDIT_TARGET support in the kernel and in ip6tables.
• REJECT — disallow the packet and return an icmp-unreachable or an RST packet.
• A_REJECT — the audited versions of REJECT. requires AUDIT_TARGET support in the kernel and ip6tables.
• LOG — simply log the packet and continue on with the next rule. just observing, no interference 💅
• QUEUE — queue the packet to a user-space application like ftwall (http://p2pwall.sf.net). that application may reinsert the packet for further processing.
• NFLOG[(nflog-parameters)] — queues matching packets to a back end logging daemon via a netlink socket, then continues to the next rule. check shorewall-logging(5) for the tea.
• NFQUEUE — queues the packet to a user-space application using the nfnetlink_queue mechanism. if a queuenumber isn't specified, queue zero (0) is assumed.
• ?COMMENT — the rest of the line gets attached as a comment to the Netfilter rule(s) generated by the following entries. that comment shows up delimited by /* ... */ in the output of shorewall show <chain>. to stop the comment from being attached to further rules, just include ?COMMENT on a line by itself.
• action — the name of an action declared in shorewall-actions(5) or in /usr/share/shorewall/actions.std.
• macro — the name of a macro defined in a file named macro.macro. if the macro accepts an action parameter (peep the macro source to see if it has PARAM in the TARGET column) then the macro name is followed by the parenthesized target (ACCEPT, DROP, REJECT, ...) to be substituted for the parameter.

example: FTP(ACCEPT).

the ACTION may optionally be followed by : and a syslog log level (e.g., REJECT:info or Web(ACCEPT):debug). this causes the packet to be logged at the specified level. so extra, so iconic ✨

and if the ACTION names an action declared in shorewall-actions(5) or in /usr/share/shorewall/actions.std, then:

• if the log level is followed by ! then all rules in the action are logged at the log level.
• if the log level is not followed by ! then only those rules in the action that don't specify logging get logged at the specified level.
• the special log level none! suppresses logging by the action.

you may also specify NFLOG (it must be in upper case) as a log level. this will log to the NFLOG target for routing to a separate log through use of ulogd (shorewall-logging.htm).

actions that specify logging may be followed by a log tag (a string of alphanumeric characters) which gets appended to the string generated by the LOGPREFIX (in shorewall.conf(5)).

for all the remaining columns, go see shorewall-rules(5). i'm not re-explaining my bestie's whole lore here 💀

---

🌈 EXAMPLES 🌈

IPv4 Example 1: Drop 6to4 packets from the net.

DROP          net:192.88.99.1            all

IPv4 Example 2: Don't subject packets from 70.90.191.120/29 to the remaining rules in the file.

WHITELIST     net:70.90.191.120/29       all

IPv6 Example 1: Drop Teredo packets from the net.

DROP          net:[2001::/32]            all

IPv6 Example 2: Don't subject packets from 2001:DB8::/64 to the remaining rules in the file.

WHITELIST     net:[2001:DB8::/64]        all

---

🎀 FILES 🎀

• /etc/shorewall/blrules
• /etc/shorewall6/blrules

---

🦋 SEE ALSO 🦋

• https://shorewall.org/blacklisting_support.htm
• https://shorewall.org/configuration_file_basics.htm#Pairs
• shorewall(8)

---

💜 NOTES 💜

1. shorewall.conf https://shorewall.org/manpages/shorewall.conf.html
2. shorewall-rules(5) https://shorewall.org/manpages/shorewall-rules.html
3. shorewall-logging(5) https://shorewall.org/manpages/shorewall-logging.html
4. shorewall-actions https://shorewall.org/manpages/shorewall-actions.html
5. https://shorewall.org/blacklisting_support.htm https://shorewall.org/blacklisting_support.htm
6. https://shorewall.org/configuration_file_basics.htm#Pairs https://shorewall.org/configuration_file_basics.htm#Pairs

---

and that's the whole page, bestie!! this one's from the Configuration Files manual, dated 09/24/2020, and it answers to the name SHOREWALL-BLRULES(5) 💖✨ go forth and blacklist responsibly 👑