How to refactor the firewall script while being sure there are no nftables changes.

nftables[edit]

1. Store current nftables rules to file nftables-old.

sudo nft --stateless list ruleset > nftables-old

2. Refactor the Kicksecure firewall code.

3. Reload Kicksecure Firewall.

If you are using Kicksecure inside Qubes, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Kicksecure ProxyVM (commonly named kicksecure) → Reload Kicksecure Firewall

If you are using a graphical Kicksecure, complete the following steps.

Start Menu → Applications → System → Reload Kicksecure Firewall

If you are using a terminal-only Kicksecure, run. sudo kicksecure_firewall

4. Store current nftables rules to file nftables-new.

sudo nft --stateless list ruleset > nftables-new

5. Compare files nftables-old and nftables-new.

Use console diff viewer or...

diff nftables-old nftables-new

Use a graphical diff viewer.

meld nftables-old nftables-new

systemcheck nftables test[edit]

Does not exist yet.

"systemcheck (which is somewhat a replacement for the lack of test suite) could indeed be useful to check if the loaded nftables rules match a hardcoded nftables dump. Yes, with additional firewalll add-ons that would be hard. Then these firewall add-ons could ship a dump that also gets verified. (nftables-dumps.d folder checked by systemcheck or so.) But then multiple firewall add-ons gets hard. Mutliple firewall add-ons and dumping, that kind of flexibility might be stretching what the Kicksecure project may be able to implement." (From (Forum) Bolt on for whonix_firewall - best place to put files? )
- systemcheck could use this nftables diff facility to warn the user of non-standard / unexpected rules present. And, just like unwanted packages, could ask the user to run e.g. nftables-save-whonix to establish a new baseline. systemcheck would then pass, unless something else had changed things user unexpectedly, at which point systemcheck would again warn.

Split Kicksecure Firewall Script for better readability[edit]

From Patrick:
" I have been wondering for some time now if the firewall script should be split. A lot sections are being used by multiple packages, the firewall and vpn-firewall. Eventually further in future (corridor-gateway to be created one day)...

error_handler
source config folder
IPv4 DEFAULTS
IPv4 PREPARATIONS
IPv4 DROP INVALID INCOMING PACKAGES
IPv4 FORWARD
IPv6
more minor stuff (nftables_cmd)

Converted to shell functions. And added to helper-scripts.

The risk of changing firewall rules while refactoring is minimal because it can be verified:

However, the goal is to make the firewall scripts easier to read. Not more difficult to audit. I am not sure which style (all in one file vs split) makes it simpler at this point. "

Early files in firewall config foleder could contain bash scripting of the form:

function ScriptFuncPreloadElement1() { script lines, e.g. $nftables_cmd ''blah''}

- Optionally followed, for inline / immediate execution rather than hooking in later within firewall script, with:

ScriptFuncPreloadElement1
# (Within the same file == calling main().)

- This separates code definition from code execution.
"The other question with firewall code injection, pre/post hooks is when to dispatch them? When you want to dispatch them depends on what you actually want to implement."
e.g.

if [ "$(type -t firewall_input_hook_end)" = "function" ]; then
   firewall_input_hook_end
fi

- However, such would only allow a single call per hook. (User would have to chain all calls within whonix_firewall.d) Perhaps array variables instead. Code would then be something like ScriptFuncPreloadElement1() as above, then

firewall_input_hook_end[${#firewall_input_hook_end[@]}]=ScriptFuncPreloadElement1

- - It would be up to the user to appropriately manage the array ordering.
- Hooks within the firewall would then walk the appropriate array at the appropriate time.

Reference: (Forum) torrents, and being a good tor citizen
Solution, part b demonstrates an example sample set of nftables rules that could be injected, within the firewall. (Proof of concept, only.)

Reference: (Forum) Favourite (whonix?) bash script boilerplate template?

(begins) a corralling of a standard scripting framework.

Dev/Firewall Refactoring

Contents

nftables[edit]

systemcheck nftables test[edit]

Split Kicksecure Firewall Script for better readability[edit]

See Also[edit]

Navigation menu

Dev/Firewall Refactoring

nftables[edit]

systemcheck nftables test[edit]

Split Kicksecure Firewall Script for better readability[edit]

See Also[edit]

Navigation menu

Search