port to netfilter-persistent?

[phabricator-migrator]

Information

ID: 487
PHID: PHID-TASK-w4s7a4zwtnzanvswulam
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal

Description

• port to netfilter-persistent?
  ** It might be more appropriate to get the firewall loaded before any networking gets up than whonix-firewall.service.
  ** Could therefore simplify the setup, and
  ** allow additional custom/extension-package firewall rules being load before and after Whonix Firewall.

---

• NOT iptables-persistent
  ** (which is more useful to local system administrators rather than distribution maintainers)

---

cat /usr/share/doc/netfilter-persistent/README
netfilter-persistent and its plugins
------------------------------------

netfilter-persistent does no work on its own. You need the accompanying
plugins (for example, iptables-persistent) to load and save filter rules.

However, commands are run from netfilter-persistent. For example, to save
all filter rules:

   netfilter-persistent save

or to load them:

   netfilter-persistent start

For more details, see `man netfilter-persistent`.

The system service will try to load rules at startup if enabled, but by
default it will not flush rules at shutdown. This behaviour can be changed
by editing /etc/default/netfilter-persistent.

 -- Jonathan Wiltshire <jmw@debian.org>  Sat, 02 Jan 2016 00:00:00 +0000

---

DESCRIPTION
       netfilter-persistent uses a set of plugins to load, flush and save netfilter rules at boot and halt time.  Plugins can be written in any suitable language and stored in
       /usr/share/netfilter-persistent/plugins.d

PLUGINS
       Plugins  can  be written in any language and are merely executed by netfilter-persistent with a single argument.  All plugins are stored in /usr/share/netfilter-persis‐
       tent/plugins.d

       Plugins must implement the start flush and save arguments and must not rely on additional arguments for other functionality.
       Plugins must return 0 on success and any other code on failure.

       Plugins are free to use and extend the configuration in /etc/default/netfilter-persistent and to implement their own configuration files.

---

• netfilter-persistent loads firewall rules too late
• netfilter-persistent systemd service does not lock the network if netfilter-persistent wrapper is failing at system bootup
• add dpkg trigger for /usr/share/netfilter-persistent/plugins.d folder to have newly installed plugins take effect

---

related:

systemd feature request:
please provide a firewall scripts drop-in folder

Comments

---

rAntOCauDgb

2016-03-29 01:45:02 UTC

Would porting to netfilter-persistent negate any need for a (development time) iptables-dump diff’ing facility, or such’s (potential) whonixcheck use if such were ever integrated into whonixcheck? i.e. Before I start prodding at a iptables-dump diff’ing facility [to my mind a precursor to this task, as a sanity check facility for this task], instead of zigging towards an iptables-save basis for such, should I be zagging deeper into netfilter-persistent as it already contains within it the desired functionality?

---

Patrick

2016-03-29 14:44:53 UTC

! In T487#8482, @rAntOCauDgb wrote:
Would porting to netfilter-persistent negate any need for a (development time) iptables-dump diff’ing facility,

I don’t think so.

Bolt on for whonix_firewall - best place to put files? - #26 by Patrick

instead of zigging towards an iptables-save basis for such, should I be zagging deeper into netfilter-persistent as it already contains within it the desired functionality?

netfilter-persistent doesn’t have this feature. It’s rather simple. In a nutshell:

• it runs before network systemd target
• runs programs/scripts in a .d folder with an argument

---

rAntOCauDgb

2016-03-30 02:29:13 UTC

OK. Thanks.

Then, note to selves - any replacement functionality will have to be able to duplicate whonix_firewall / this’s ability to run after boot and re-reset iptables. Running whonix_firewall while running is wonderfully reassuring to reset iptables after beating upon it. Presumably this would be by whonix_firewall being replaced with something that calls the same thing systemd triggers at boot.

From Patrick’s original comments, the advantage to netfilter-persistent over current would be that there is currently a theoretical deficiency in whonix_firewall in terms of flexibility of sucking in (hook) functionality at multiple points, and this flexibility is already present in netfilter-persistent. Thus, rather than reinventing the wheel with hooks in whonix_firewall, migrate whonix_firewall to netfilter-persistent. ([He] Proposed.)

---

Patrick

2017-11-05 23:38:59 UTC

netfilter-persistent may not be ready for prime time.

netfilter-persistent bug reports:

• netfilter-persistent loads firewall rules too late
• netfilter-persistent systemd service does not lock the network if netfilter-persistent wrapper is failing at system bootup

netfilter-persistent feature request:

• add dpkg trigger for /usr/share/netfilter-persistent/plugins.d folder to have newly installed plugins take effect

---

systemd feature request:
please provide a firewall scripts drop-in folder

netfilter feature request:
please provide a firewall scripts drop-in folder

---

Patrick

2016-10-12 14:38:59 UTC

netfilter-persistent still has too many issues. And I doubt it will be ready for Whonix 14. In meanwhile whonix-firewall.service will do. Maybe some day.