Disable networking.firewall by default

[aszlig]

This got a bit off-topic in #12927 by my comment against having it enabled by default, so let's continue here instead.

As stated in the comment, we really should focus on not opening ports that are not needed to world instead of putting additional netfilter/conntrack modules in front that will increase the attack vector.

After all, if you want a service to be available to the world, the netfilter can't help you either and if you don't want it to be available, why enable the service (or listening to ::) in the first place? Everything that we might want to block or disable can be disabled without relying on netfilter, except a few very specific corner cases (like for example port knocking) which where people can still enable it.

The pull request still lacks documentation in the release notes and is primarily there for discussion, in addition to that I'd like to add a few tests (and module fixes) here to ensure that we don't listen to ports that are unnecessary.

[mention-bot]

By analyzing the blame information on this pull request, we identified @edolstra, @wkennington and @bluescreen303 to be potential reviewers

[copumpkin]

I still wouldn't say I'm a fan of turning it off by default, since I don't really see a strong argument for doing that. I also don't really understand the argument that turning iptables on will increase the attack surface. It seems far easier to trust that one module than dozens of ad-hoc services and individual users sitting on your computer.

[aszlig]

The netfilter modules had vulnerabilities in the past, but that's not the point, because every piece of software has its bugs, but adding more stuff instead of removing stuff is the same way as AV vendors are approaching this, by blacklisting stuff that's known to be bad instead of whitelisting stuff that's known to be good.

As for the netfilter, the "dozens" of ad-hoc services are only relevant for desktop systems if users aren't careful enough to disable them in the first place, on dedicated servers however there shouldn't run any "ad-hoc services" which you don't explicitly enable in your NixOS config.

And even if it comes to "ad-hoc services" in terms of nixpkgs, we should rather make listening to these ports optional than make it the default.

For example if you have an IM client and want to transfer files, you may actively want to open ports and the only thing the netfilter is doing is making it even harder for you to actually do what you want to do.

[copumpkin]

What I meant by dozens isn't that you're simultaneously running dozens of services, but it's a single reasonably well known and tested entity blocking entry vs. a suite of codebases of varying quality, even if you're only ever enabling one of them at a time. If I'm spinning up a service, I don't want to have to trust that your netstat listener catching code catches all cases, or that the service has been configured properly to not listen on my public IP, or that it might start listening on my outbound IP after a few minutes because it wants to index some large data file first. The firewall may not be perfect, but gives me assurance that I don't want to have to get through a handful of other imperfect systems that are likely less well tested.

[aszlig]

That netstat listener catching code was only an example intended for example for NixOS VM tests to make sure we have good quality modules that do not bind on ports that are unnecessary.

[copumpkin]

Then I'm even less confident in this being a good idea. I don't want to trust a whole bunch of module authors to have done this properly and have working VM tests that catch this. Most services in NixOS don't have VM tests, and while I'd like that to improve, this seems like a lot more potential holes in exchange for a bit of convenience when running p2p desktop sharing programs.

[edolstra]

Previous discussion: #2135, NixOS/nixos#55

I don't really see what changed, so I'm 👎 on this - I don't think we should ship without a firewall by default. People who care can disable it easily enough.

[jagajaga]

I agree with @edolstra

[aszlig]

@edolstra: Still your argument on defense in depth really doesn't hold, because it does not protect services that are already exempt from firewall rules. It only protects you from rogue programs that are randomly binding to everything. Programs like this should not run on your machine and if they're really necessary you'd exempt them anyway... or even sandbox them properly.

[dezgeg]

Another problem caused by the firewall being on by default: #10101

[astsmtl]

@aszlig, what if such rogue program is some malware?

[aszlig]

@astsmtl: If malware is on your system, then you're doomed anyway and it can still use outbound connections as well as bind to ports that are exempt from the rules. And if it has root access it can even disable these rules directly.

[jgillich]

👍 from me. We should have as little as possible enabled by default; on a properly configured system, netfilter doesn't add any security.

[peti]

This has been discussed before and we've through a lot of trouble at the time to enable the firewall by default in a way that doesn't break people's existing installations. I believe having the firewall enabled by default was the right choice then and it's still the right choice now. 👎 from me on this issue; please don't change the current default setting.

[heydojo]

Please just no. 👎

Is implementing https://github.com/t-woerner/firewalld one way to fix this? (Is it maybe not an ideal fit for NixOS because of it's design?) firewalld integrates well with network manager and allows you to have multiple switch-able zones (which are themselves individual configuration rule sets) which can be toggled without any of the reloading of kernel modules normally required to complete configuration changes.

After all, if you want a service to be available to the world, the netfilter can't help you either and if you don't want it to be available, why enable the service (or listening to ::) in the first place?

Many have often wondered why we have this thing called dbus which does; things.
People are also asking why we need kdbus which as I understand it; does some other things.
Try adding a portcullis and a retractable bridge to each of the gates in your castle analogy (as would be the norm for most medieval castles) if you follow.

Ports in applications or services are dynamic and therefore the port itself does not describe the use case.

From:
https://fedoraproject.org/wiki/FirewallD#Port_metadata_information_.28proposed_by_Lennart_Poettering.29

Whether to enable a firewall is often a question found in an operating system installer and I am yet to use an installer where the option is disabled by default.
I think that if the consensus was that firewalls did not work then no one would use them anyway.

[devhell]

👍 from me. If people want a firewall they can just as easily enable it.

[aszlig]

Many have often wondered why we have this thing called dbus which does; things.
People are also asking why we need kdbus which as I understand it; does some other things.
Try adding a portcullis and a retractable bridge to each of the gates in your castle analogy (as would be the norm for most medieval castles) if you follow.

In case of dbus, we need it because systemd depends on it, so it is not an unnecessary dependency.

And the reason why most installers of other distros enable it by default is that they tend to enable services on installation (like for example Debian does or at least has done in the past). NixOS however doesn't have a notion of "installation" but a configuration.nix where we can exactly state what we want to run.

But anyway, I guess in respect to #12987, let's at least get rid of nf_conntrack, because that's a module we really don't need for just blocking ports programs may run at random.

[Profpatsch]

I am in favor of disabling the firewall by default.

Back as a new user I was astounded that my python -m http.server &c. were not working. After some search I found out about the firewall, but it induced a considerable amount of stress.
I think the principle of least astonishment should be applied in this case.

[Profpatsch]

We just discovered that the firewall blocks avahi as well. avahi-browse doesn’t find any services for example, without any notice. That is very bad for the end user.

[heydojo]

That is very bad for the end user.

I disagree. It is doing exactly what was intended.

[copumpkin]

I imagine there's a fairly clean split on this issue between people using NixOS as a server vs. those using it as a desktop OS.

[Profpatsch]

I disagree. It is doing exactly what was intended.

So blocking avahi functionality (with services.avahi enabled) is the intended behavior? I think not.

What do you want to do about that? Implicitly disable networking.firewall when enabling services.avahi? That would be the only sensible thing to do in that case. Yet …

[heydojo]

So blocking avahi functionality (with services.avahi enabled) is the intended behavior? I think not.

When a firewall is turned on it blocks all traffic by default. This is the intended behaviour.
I am sorry that you are unable to discuss this rationally.
I don't want to do anything about that. I also do not want to discuss this any further.
This thread is becoming silly.

[dezgeg]

The problem is that this firewall is turned on without the user even knowing about it, it's kind of hard to suspect breakage due to an option you didn't even know exists.

[bjornfor]

I was going to suggest to make the nixos installer put networking.firewall.enable = $WHATEVER into the initial configuration.nix file, because then I don't think the default value matters as much; the user will become aware of this important setting and set it to his/her liking.

But then I realized that this is what this PR does.

So +1 from me. (I don't care that much about the default setting, but it clearly needs to be more visible, and this PR does that.)

[sternenseemann]

@bjornfor's point is an important one on this topic in my opinion.

👍 from me also.

[fpletz]

FWIW, I agree with the points made by @bjornfor and @aszlig, so 👍.

Enabled firewalls by default are only useful if you as the user don't know what you're and the package maintainer doesn't know what he's doing, but this is NixOS and not Fedora, so I guess not that many newbies who don't know about firewalls will use it. Enabling it explicitly and by default in the generated configuration.nix for new installs is the way to go because this is be the first thing a new NixOS user will try and thus will become aware of the firewall. But advanced users that build qemu images or deploy via nixops should know if they need the firewall or not and thus set it explicitly.

As a compromise for the people who are against this: Should/could we demand that all services listen on localhost by default except when they can be considered to be secure enough in its default state, e.g. sshd has password authentication disabled so it's quite safe to have it listening on all public IPs.

[peti]

The change as-is now works fine for people who install a fresh 16.03 system, but people who upgrade to that release from an existing installation might implicitly have their firewall disabled without noticing.

[Profpatsch]

@peti Then let’s put it in a big fat warning box in the release notes.

[edolstra]

I don't see a consensus for changing this again with no new arguments (we really don't want to turn the firewall on and off every few releases), and the firewall can be turned off easily for people who don't want it. Since this discussion is likely to go around in circles for a long time I'm going to close this issue. However, we could add a networking.firewall.enable line to the nixos-generate-config template to make it easier to disable.

Aside: this is not an appropriate use of system.stateVersion, which is only intended to preserve legacy behaviour for stateful data on disk (such as SSH host keys or PostgreSQL databases), not to make a NixOS release behave like an older version with respect to general option defaults. Because then you could have situations where destroying and recreating an EC2 instance originally upgraded from 15.09 to 16.03 would suddenly no longer have a firewall. Maybe we need to have a system.configVersion attribute for the purpose of setting some option defaults to legacy values.