Your message dated Mon, 21 Oct 2019 11:14:37 +0200
with message-id <[email protected]>
and subject line Re: [pkg-netfilter-team] Bug#942631: nftables: Failed start
results in all traffic allowed
has caused the Debian Bug report #942631,
regarding nftables: Failed start results in all traffic allowed
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
942631: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942631
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
