Debian Bug report logs - #942631
nftables: Failed start results in all traffic allowed

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Paul Dreik <debianbugs@pauldreik.se>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: nftables: Failed start results in all traffic allowed

Date: Sat, 19 Oct 2019 10:18:18 +0200

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

Message #10 received at 942631@bugs.debian.org (full text, mbox, reply):

From: Arturo Borrero Gonzalez <arturo@debian.org>

To: Paul Dreik <debianbugs@pauldreik.se>, 942631@bugs.debian.org

Cc: 942631-done@bugs.debian.org

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

Date: Mon, 21 Oct 2019 11:14:37 +0200

On 10/19/19 10:18 AM, Paul Dreik wrote:
> 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?
> 

I have 2 comments:

* there is a risk in using DNS names to configure your firewall. The risk is
exactly what you experimented: what if DNS resolution fails? Then firewall would
not load, of course. My suggestion at this point is to avoid using DNS names.

* if you want systemd to keep restarting the service, you can configure your
unit .service file with something like 'Restart=always' (see systemd.service(5)).
This has nothing to do with nftables specifically. That is a local config you
can do to any systemd service in any machine.

Hope this helps clarify your question.

Closing bug now.

Send a report that this bug log contains spam.