SHOREWALL-ACTIONS(5)

πŸ“¦
version 5.2.8 Β· 2 versions
  • 5.2.8 Β· alpine 3.22, alpine 3.23, alpine 3.24, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 5.2.3.4 Β· ubuntu jammy
, in alpine 3.22, alpine 3.23, alpine 3.24, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ SHOREWALL-ACTIONS ✨

okay bestie, buckle up πŸ’– this is the page from the Configuration Files manual section β€” shorewall-actions(5) β€” and it's literally the glow-up guide for your firewall's custom actions. no cap, it's giving main character energy for your packet filtering. let's go πŸ¦‹


🌸 NAME 🌸

actions β€” the Shorewall action declaration file πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

/etc/shorewall[6]/actions

πŸ’œ DESCRIPTION πŸ’œ

So here's the vibe: this file is where you get to invent brand-new ACTIONS for use in rules (peep shorewall-rules(5)). You write the actual iptables rules that make up an ACTION over in /etc/shorewall/action.action-name. yes, one file per action, very demure, very mindful 🧚

The columns are:

🌟 NAME 🌟

The name of the action, periodt. ACTION names should start with an upper-case letter β€” that's how you tell them apart from the chain names Shorewall generates all on its own. And they should be made of letters, digits or numbers. One more thing: if you're planning to log from the action, then with the standard LOGFORMAT the name has to be no longer than 11 characters. that's the limit, bestie, no negotiating 😭

🌈 OPTIONS 🌈

Added in Shorewall 4.5.10. The options you can pick from are:

  • audit β€” Added in Shorewall 5.0.7. With this one on, the action is expected to have at least two parameters: the first is a target, and the second is either 'audit' or just... omitted. If that second one is 'audit', then the first one must be an auditable target β€” that's ACCEPT, DROP or REJECT. no other options, sorry 🫢
  • builtin β€” Added in Shorewall 4.5.16. This defines the action as a rule target that your iptables supports but Shorewall doesn't directly support. The action can then be used as the rule target in an INLINE rule in shorewall-rules(5).

Starting with Shorewall 4.6.0, you can also say which Netfilter table(s) the builtin works in: filter, nat, mangle and raw. If you don't name any tables, filter is assumed. The table names come right after builtin, separated by commas β€” for example, "FOOBAR builtin,filter,mangle" would make FOOBAR a builtin target usable in the filter and mangle tables. iconic ✨

Starting with Shorewall 4.6.4, you may specify the terminating option along with builtin to tell the Shorewall optimizer that the action is terminating β€” meaning the current packet will not be passed to the next rule in the chain. πŸ’€

  • inline β€” Makes the action body (defined in action.action-name) get expanded in-line, like a macro, instead of living in its own chain. Fun fact: you can list Shorewall Standard Actions in this file to specify the inline option.
Caution 🚨 Some of the Shorewall standard actions simply cannot be used in-line. If you try, you'll get a warning and the compiler will just ignore inline: - DropSmurfs - IfEvent - Invalid (Prior to Shorewall 4.5.13) - NotSyn (Prior to Shorewall 4.5.13) - RST (Prior to Shorewall 4.5.13) - TCPFlags
  • logjump β€” Added in Shorewall 5.0.8. Does the exact same thing as nolog (down below πŸ‘‡), except it also logs the jump to the action's chain if a log level is specified on the action invocation. For inline actions, this option is identical to nolog. same energy fr fr
  • mangle β€” Added in Shorewall 5.0.7. Says this action is meant to be used in shorewall-mangle(5) rather than shorewall-rules(5).
  • nat β€” Added in Shorewall 5.0.13. Says this action is meant to be used in shorewall-snat(5) rather than shorewall-rules(5). Heads up: mangle and nat are mutually exclusive β€” pick one, you cannot have both πŸ™ˆ
  • noinline β€” Makes any later inline option for the same action get ignored, with a warning. bye bestie πŸ‘‹
  • nolog β€” Added in Shorewall 4.5.11. When you use this, the compiler stops automatically slapping the log level and/or tag from the action's invocation onto all the rules inside the action. Instead, it just sets the $_loglevel and $_logtag shell variables, which you can use inside the action body to apply those logging options to only a subset of the rules. chef's kiss, so much control πŸ’…
  • proto=protocol β€” Added in Shorewall 5.1.10. Says the action is only usable with the specified protocol (name or number). When the action is invoked with no protocol in the PROTO column, or if the action is used as a Policy Action, then the named protocol gets assumed. But if a protocol is specified in the PROTO column of an invocation, then it has to match the named protocol.

Also: the proto option has no effect if the inline or builtin option is specified. And you'll get a warning if proto shows up alongside builtin.

  • dport=portorservice β€” Added in Shorewall 5.2.6. Requires that the proto option was already given, and says this action may only be applied to flows with the specified protocol and portorservice. That portorservice can be a valid port number, or the name of a service defined in /etc/services that's usable with the specified protocol. If a port or service is specified in the DPORT column of an invocation, then it must match the named portorservice.
  • section β€” Added in Shorewall 5.1.1. With this one on, the rules file section name plus a comma gets prepended to the parameters passed to the action (if there are any). Which means β€” plot twist β€” the first parameter passed to the action by the user is actually the second parameter to the action. And if the action is invoked out of the blrules file, 'BLACKLIST' is used as the section name. 😭

Also, since neither the snat nor the mangle file is sectioned, this parameter has no effect when mangle or nat is specified.

  • state={UNTRACKED|NEW|ESTABLISHED|RELATED|INVALID} β€” Added in Shorewall 5.0.7. Reserved for use by Shorewall in actions.std. hands off, that one's not yours πŸ’–
  • terminating β€” Added in Shorewall 4.6.4. When used with builtin, it indicates that the built-in action is termiating (i.e., if the action is jumped to, the next rule in the chain is not evaluated). yes, the typo is canon, we don't touch it πŸŽ€

πŸ¦‹ FILES πŸ¦‹

  • /etc/shorewall/actions
  • /etc/shorewall6/actions

πŸ‘‘ SEE ALSO πŸ‘‘


πŸ“ NOTES πŸ“

  1. shorewall-rules(5) https://shorewall.org/manpages/shorewall-rules.html
  2. shorewall-mangle(5) https://shorewall.org/manpages/shorewall-mangle.html
  3. shorewall-snat(5) https://shorewall.org/manpages/shorewall-snat.html
  4. https://shorewall.org/Actions.html https://shorewall.org/Actions.html

okay that's the whole page, you ate it up 🌟 this came out of the Configuration Files section, dated 09/24/2020, and it's the SHOREWALL-ACTIONS(5) page β€” go write some iconic actions, bestie, i'm so proud of you πŸ’–πŸŽ€πŸ¦‹βœ¨πŸ’