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
