[pkg-netfilter-team] Bug#942631: nftables: Failed start results in all traffic allowed

[Paul Dreik]

Source: nftables
Version: 0.7-1
Severity: wishlist

In case nftables has trouble starting, the result is a system with no rules at
all, resulting in everything allowed. This is surprising (for me), since the
entire point of having a firewall (for me) is to restrict access.

This is how I setup my system (following https://wiki.debian.org/nftables):
 - new installed of stretch system
 - install nftables
 - modify /etc/nftables.conf
 - enable and start the nftables service
 - verify that network traffic is blocked correctly
 - fine, all good!

The surprise came after the next reboot. I found entries in my mail log
indicating people trying to connect, which were supposed to be blocked. I found
that the service was not running, because of trouble starting. The problem was
that I used a host name instead of ip address, and name resolution had a
temporary failure so the service failed. I suspect it runs early in the boot,
while the network is not fully configured yet. But my exact cause of the
problem is unimportant - I believe there are other reasons nftables could
refuse to start.

I wonder if it would be possible to have some kind of fallback for this kind of
situation.
 - the service retries again, if it fails to start the first time
 - default "block all" rules are applied

The first option would potentially leave the network open for some time.
The second option would potentially lock people out from administration/updates
causing the system to be unreachable.

I "solved it" by adding a crontab job checking if the service was not running
("service nftables status") and started it.

This bug report is a request for comments - could something be written on the
Debian wiki? What is the recommended way of handling the situation? Could the
Debian systemd service file be modified such that it retries by default?

Note: I report this system on Debian Buster, so the auto attached system
information is irrelevant because it happened on another system running Debian
Stretch.



-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled