Jump to: navigation, search

Dev/Firewall Refactoring

< Dev


How to refactor the firewall script while being sure there are no iptables changes[edit]

1) Get iptables-save-deterministic script.

2) Store current iptables rules to file a.

sudo ./iptables-save-deterministic > a

3) Refactor the Whonix firewall code.

4) Reload Whonix-Gateway Firewall.

If you are using Qubes-Whonix, complete the following steps:

Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named sys-whonix) -> Reload Whonix Firewall

If you are using a graphical Whonix-Gateway, complete the following steps:

Start Menu -> Applications -> System -> Reload Whonix Firewall

If you are using a terminal-only Whonix-Gateway, run:

sudo whonix_firewall

5) Store current iptables rules to file b.

sudo ./iptables-save-deterministic > b

6) Compare files a and b.

Use console diff viewer or...

diff a b

Use a graphical diff viewer.

meld a b

7) There should be no diff.

whonixcheck iptables test[edit]

Does not exist yet.

  • "whonixcheck (which is somewhat a replacement for the lack of test suite) could indeed be useful to check if the loaded iptables rules match a hardcoded iptables dump. Yes, with additional firewalll add-ons that would be hard. Then these firewall add-ons could ship a dump that also gets verified. (iptables-dumps.d folder checked by whonixcheck 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 Whonix project may be able to implement." (From (Forum) Bolt on for whonix_firewall - best place to put files? )
    • whonixcheck could use this iptables 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. iptables-save-whonix to establish a new baseline. whonixcheck would then pass, unless something else had changed things user unexpectedly, at which point whonixcheck would again warn.

Reference: (Forum) Bolt on for whonix_firewall - best place to put files?

Split Whonix 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, whonix-gw-firewall, whonix-ws-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 (iptables_cmd, ip6tables_cmd)


Converted to shell functions. And added to anon-shared-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 /etc/whonix_firewall.d could contain bash scripting of the form:
function ScriptFuncPreloadElement1() { script lines, e.g. $iptables_cmd ''blah''}
    • Optionally followed, for inline / immediate execution rather than hooking in later within whonix_firewall, 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 whonix_firewall_input_hook_end)" = "function" ]; then
   whonix_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
whonix_firewall_input_hook_end[${#whonix_firewall_input_hook_end[@]}]=ScriptFuncPreloadElement1
      • It would be up to the user to appropriately manage the array ordering.
    • Hooks within whonix_firewall would then walk the appropriate array at the appropriate time.

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


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

  • (begins) a corralling of a standard scripting framework.

See Also[edit]


Random News:

Did you know, that Whonix could provide protection against backdoors? See Verifiable Builds. Help wanted.


Impressum | Datenschutz | Haftungsausschluss

https | (forcing) onion
Share: Twitter | Facebook | Google+
This is a wiki. Want to improve this page? Help welcome, volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation. Whonix (g+) is a licensee of the Open Invention Network. Unless otherwise noted above, content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.