SHOREWALL-ACCOUNTIN(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 (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

✨ NAME ✨

accounting β€” the Shorewall Accounting file πŸ’… (yes bestie, this is THE file where you count stuff)


🌸 SYNOPSIS 🌸

/etc/shorewall[6]/accounting

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so, accounting rules exist for one reason and one reason only: to count packets and bytes in whatever categories you decide to define in this file. that's it. that's the whole vibe. πŸŽ€

you can flex your counters and see all the rules with their packet + byte counts by running shorewall show accounting. iconic.


Beginning with Shorewall 4.4.18, the accounting structure can be built with three root chains:

  • accountin β€” rules that are valid in the INPUT chain (may not specify an output interface)
  • accountout β€” rules that are valid in the OUTPUT chain (may not specify an input interface or a MAC address)
  • accounting β€” other rules

The new structure gets enabled by sectioning the accounting file kinda the same way you section the rules file[1]. 🫢

The sections are INPUT, OUTPUT and FORWARD, and they must appear in that order (tho any of them can be omitted, no pressure). The first non-commentary record in the accounting file must be a section header when you're using sectioning. periodt.

⚠️ Warning ⚠️ If sections are not used, the Shorewall rules compiler literally cannot detect certain violations of netfilter restrictions. and those violations can result in run-time errors like this one: iptables-restore v1.4.13: Can't use -o with INPUT not cute. use sections. πŸ’€

Beginning with Shorewall 4.4.20, the ACCOUNTING_TABLE setting was added to shorewall.conf and shorewall6.conf. That setting decides which Netfilter table (filter or mangle) the accounting rules get added to. When you set ACCOUNTING_TABLE=mangle, the sections available to you are PREROUTING, INPUT, OUTPUT, FORWARD and POSTROUTING. πŸ¦‹

Section headers look like this:

?SECTION section-name

When sections are enabled:

  • A jump to a user-defined accounting chain must appear before entries that add rules to that chain. This eliminates loops and unreferenced chains.
  • An output interface may not be specified in the PREROUTING and INPUT sections.
  • In the OUTPUT and POSTROUTING sections:
    • An input interface may not be specified
    • Jumps to a chain defined in the INPUT or PREROUTING sections that specifies an input interface are prohibited
    • MAC addresses may not be used
    • Jump to a chain defined in the INPUT or PREROUTING section that specifies a MAC address are prohibited
  • The default value of the CHAIN column is:
    • accountin in the INPUT section
    • accountout in the OUTPUT section
    • accountfwd in the FORWARD section
    • accountpre in the PREROUTING section
    • accountpost in the POSTROUTING section
  • Traffic addressed to the firewall goes through the rules defined in the INPUT section.
  • Traffic originating on the firewall goes through the rules defined in the OUTPUT section.
  • Traffic being forwarded through the firewall goes through the rules from the FORWARD sections.

okay so the columns in the file are as follows β€” and real quick, whenever a column name is followed by a different name in parentheses, that different name is what gets used in the alternate specification syntax. iykyk. πŸ’…

🌈 ACTION

{COUNT|DONE|chain[:{COUNT|JUMP}]|ACCOUNT(table,network)|[?]COMMENT comment}

What to do when a matching packet is found. πŸ‘‘

  • COUNT β€” Simply count the match and continue with the next rule
  • DONE β€” Count the match and don't attempt to match any other accounting rules in the chain specified in the CHAIN column.
  • chain[:COUNT] β€” where chain is the name of a chain; shorewall will create the chain automatically if it doesn't already exist. If a second chain is mentioned in the CHAIN column, then a jump from this second chain to chain is created. If no chain is named in the CHAIN column, then a jump from the default chain to chain is created. If :COUNT is included, a counting rule matching this entry will be added to chain. The chain may not exceed 29 characters in length and may be composed of letters, digits, dash (-) and underscore (_).
  • chain:JUMP β€” Like the previous option without the :COUNT part.
  • ACCOUNT(table,network) β€” This action implements per-IP accounting and was added in Shorewall 4.4.17. Requires the ACCOUNT Target capability in your iptables and kernel (peep the output of shorewall show capabilities).
    • table β€” is the name of an accounting table (you choose the name). All rules specifying the same name will have their per-IP counters accumulated in the same table.
    • network β€” is an IPv4 network in CIDR notation (e.g., 192.168.1.0/24). The network can be as large as a /8 (class A).

One nice feature of per-IP accounting is that the counters survive shorewall restart. This has a downside, however. If you change the network associated with an accounting table, then you must shorewall stop; shorewall start to have a successful restart (counters will be cleared). πŸ™ˆ

The counters in a table are printed using the iptaccount utility. For a command synopsis, type:

iptaccount --help

As of February 2011, the ACCOUNT Target capability and the iptaccount utility are only available when xtables-addons[2] is installed. See https://shorewall.org/Accounting.html#perIP[3] for additional information.

  • INLINE β€” Added in Shorewall 4.5.16. Allows free form iptables matches to be specified following a ;. In the generated iptables rule(s), the free form matches will follow any matches that are generated by the column contents.
  • NFACCT({object[!]}[,...]) β€” Added in Shorewall 4.5.7. Provides a form of accounting that survives shorewall stop/shorewall start and shorewall restart. Requires the NFaccnt Match capability in your kernel and iptables. object names an nfacct object (see man nfaccnt(8)). Multiple rules can specify the same object; all packets that match any of the rules increment the packet and bytes count of the object.

Prior to Shorewall 4.5.16, only one object could be specified. Beginning with Shorewall 4.5.16, an arbitrary number of objects may be given. ✨

With Shorewall 4.5.16 or later, an nfacct object in the list may optionally be followed by ! to indicate that the nfacct object will be incremented unconditionally for each packet. When ! is omitted, the object will be incremented only if all of the matches in the rule succeed.

  • NFLOG[(nflog-parameters)] β€” Added in Shorewall-4.4.20. Causes each matching packet to be sent via the currently loaded logging back-end (usually nfnetlink_log) where it is available to accounting daemons through a netlink socket.
  • ?COMMENT β€” The remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word ?COMMENT.

πŸŽ€ CHAIN

{-|chain}

The name of a chain. If specified as - the accounting chain is assumed when the file is un-sectioned. When the file is sectioned, the default is one of accountin, accountout, etc. depending on the section. This is the chain where the accounting rule is added. The chain will be created if it doesn't already exist. The chain may not exceed 29 characters in length.

πŸ’œ SOURCE

{-|any|all|interface|interface:address|address}

Packet Source. 🌸

The name of an interface, an address (host or net) or an interface name followed by ":" and a host or net address. An ipset name is also accepted as an address.

🧚 DEST

{-|any|all|interface|interface:address|address}

This column was formerly named DESTINATION. πŸ‘‘

Packet Destination.

Format same as SOURCE column.

πŸ’– PROTO

{-|{any|all|protocol-name|protocol-number|ipp2p[:{udp|all}]}[,...]}

This column was formerly named PROTOCOL.

A protocol-name (from protocols(5)), a protocol-number, ipp2p, ipp2p:udp or ipp2p:all.

Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

πŸ¦‹ DPORT

{-|any|all|ipp2p-option|port-name-or-number[,port-name-or-number]...}

Destination Port number. Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136).

You may place a comma-separated list of port names or numbers in this column if your kernel and iptables include multi-port match support.

If the PROTOCOL is ipp2p then this column must contain an ipp2p-option ("iptables -m ipp2p --help") without the leading "--". If no option is given in this column, ipp2p is assumed.

This column was formerly named DEST PORT(S).

⭐ SPORT

{-|any|all|port-name-or-number[,port-name-or-number]...}

Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136).

You may place a comma-separated list of port numbers in this column if your kernel and iptables include multi-port match support.

Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DPORT. Use of '=' requires multi-port match in your iptables and kernel.

This column was formerly labelled SOURCE PORT(S).

🌈 USER

[!][user-name-or-number][:group-name-or-number][+program-name]

This column was formerly named USER/GROUP and may only be non-empty if the CHAIN is OUTPUT. πŸ’…

When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given).

Examples:

joe
    program must be run by joe

:kids
    program must be run by a member of the 'kids' group

!:kids
    program must not be run by a member of the 'kids' group

+upnpd
    #program named upnpd
πŸ’€ Important πŸ’€ The ability to specify a program name was removed from Netfilter in kernel version 2.6.14.

MARK β€” [!]value[/mask][:C]

Okay so this column is literally a vibe check for your packet or connection mark πŸ‘‘. It defines a test on the existing mark, and the rule only matches if that test comes back true. No cap.

If you don't wanna define a test but still need to put something in the columns after this one? Just drop a - in this field, bestie. That's the move. πŸ’…

Now the sub-parts:

  • ! β€” inverts the test, so it's giving "not equal" energy. Not like other tests, fr fr.
  • value β€” the actual value of the packet or connection mark. The main character, honestly. ✨
  • mask β€” a mask that gets applied to the mark before the test. It's like a little filter, iykyk. πŸŽ€
  • :C β€” designates a connection mark. If you leave it out, then the packet mark's value is the one getting tested. So choose your fighter. πŸ’–

IPSEC β€” option-list

Optional β€” added in Shorewall 4.4.13 but broken until 4.5.4.1 😭 (so if you're on an old version, it's giving bug energy, not slay).

The option-list is a comma-separated list of options from the following list. Only packets that will be encrypted or have been decrypted via an SA that matches these options will have their source address changed. So it's a whole glow-up for your source address, but only for the right packets. ✨

  • reqid=number β€” where number is specified using setkey(8) using the 'unique:number option for the SPD level. (Yes, that's exactly how it's written, no cap.)
  • spi=<number> β€” where number is the SPI of the SA used to encrypt/decrypt packets. SPI stands for Security Parameters Index, and it's giving very specific. πŸ”₯
  • proto=ah|esp|ipcomp β€” IPSEC Encapsulation Protocol. Pick your protocol, bestie. πŸ¦‹
  • mss=number β€” sets the MSS field in TCP packets. It's a little tweak, but it matters. πŸ’…
  • mode=transport|tunnel β€” IPSEC mode. Transport or tunnel, choose your adventure. πŸš€
  • tunnel-src=address[/mask] β€” only available with mode=tunnel. So if you're not in tunnel mode, this one's not for you. πŸ™ˆ
  • tunnel-dst=address[/mask] β€” also only available with mode=tunnel. Same vibe. πŸŽ€
  • strict β€” means that packets must match all rules. No exceptions, periodt. πŸ‘‘
  • next β€” separates rules; can only be used with strict. It's like a little divider, but strict-only. βœ‚οΈ
  • yes or ipsec β€” when used by itself, causes all traffic that will be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule. So it's a catch-all for the encrypted girlies. πŸ”
  • no or none β€” when used by itself, causes all traffic that will not be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule. The opposite vibe. 🚫
  • in β€” may only be used in the FORWARD section and must be the first or the only item the list. Indicates that matching packets have been decrypted in input. (Note: the original says "item the list", we're keeping it exactly, no shade.) πŸ“₯
  • out β€” may only be used in the FORWARD section and must be the first or the only item in the list. Indicates that matching packets will be encrypted on output. πŸ“€

If this column is non-empty and sections are not used, then:

  • A chain NAME appearing in the ACTION column must be a chain branched either directly or indirectly from the accipsecin or accipsecout chain.
  • The CHAIN column must contain either accipsecin or accipsecout or a chain branched either directly or indirectly from those chains.
  • These rules will NOT appear in the accounting chain. So if you're looking for them there, they ghosted you. πŸ’€

In all of the above columns except ACTION and CHAIN, the values -, any and all may be used as wildcard'gs. Omitted trailing columns are also treated as wildcard'g. So basically, you can be a little lazy with trailing columns, and it's fine. πŸ’–


✨ FILES ✨

  • /etc/shorewall/accounting
  • /etc/shorewall6/accounting

That's it. Two files, two vibes. 🌸

πŸ‘€ SEE ALSO πŸ‘€

πŸ“ NOTES πŸ“

  1. rules file https://shorewall.org/manpages/shorewall-rules.html
  2. xtables-addons http://xtables-addons.sourceforge.net/
  3. https://shorewall.org/Accounting.html#perIP https://shorewall.org/Accounting.html#perIP
  4. shorewall-logging(5) https://shorewall.org/manpages/shorewall-logging.htm
  5. https://shorewall.org/configuration_file_basics.htm#Pairs https://shorewall.org/configuration_file_basics.htm#Pairs

And that's the whole page, bestie. This absolute icon of a manpage comes from the Configuration Files section, dated 09/24/2020, and it's SHOREWALL-ACCOUNTIN(5). Periodt. πŸ’–βœ¨πŸŽ€