port to netfilter-persistent?
Open, NormalPublic
Actions

Assigned To

None

Authored By

	Patrick
	Mar 28 2016, 1:36 PM

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.

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

Details

Impact: Normal

Event Timeline

Patrick created this task.Mar 28 2016, 1:36 PM

Herald added a project: Whonix. · View Herald TranscriptMar 28 2016, 1:36 PM

Herald added a subscriber: • WhonixQubes. · View Herald Transcript

rAntOCauDgb added a subscriber: rAntOCauDgb.Mar 29 2016, 1:35 AM

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?

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.

https://forums.whonix.org/t/bolt-on-for-whonix-firewall-best-place-to-put-files/2222/26?u=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

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.)

netfilter-persistent may not be ready for prime time.

netfilter-persistent bug reports:

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 updated the task description. (Show Details)Jul 5 2016, 7:25 PM

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.

Patrick updated the task description. (Show Details)Nov 5 2017, 11:38 PM

port to netfilter-persistent?Open, NormalPublicActions

Description

Details

Event Timeline

port to netfilter-persistent?
Open, NormalPublic
Actions