ufw should be enabled by default

[Jamie Strandboge]

Binary package hint: ufw

ufw should be enabled by default in Ubuntu.

[Jamie Strandboge (jdstrand)]

This is a wishlist bug that was already triaged. It is not a security vulnerability. Please do not assign and manipulate bugs without following the regular bug triage practices.

[Jamie Strandboge (jdstrand)]

ufw can't be enabled by default in the upstream version. marking Invalid.

[Fred (eldmannen+launchpad)]

Windows comes with firewall enabled by default.
Does Mac OS X?
Perhaps Linux should too?

[Terry (wearenotamused)]

I don't have a strong opinion one way or the other about whether ufw should enable itself upon installation, but what other operating systems do is a very poor basis upon which to make that decision.

[Terry (wearenotamused)]

Sorry for the separate comment. Thoughts occurred to me just after posting.

A good firewall (i.e. one that offers security without interfering with your intended activity) requires configuration and some decisions on the part of the user. There's ultimately no way of getting around that.

If a firewall like ufw enabled itself upon installation, it would allow no window for configuration before its default one potentially shut down ongoing intended traffic on that system. (This may not be a big deal for home users, but keep in mind the number of critical systems around the world that run on Linux. You wouldn't want to make your package a pain to get going smoothly for admins of such systems.) If you made the default configuration fairly permissive to try to mitigate that, you run the very real risk of giving a false sense of security to those home users---sys admins would presumably know better than to just blindly trust the default. This is particularly true for (relative) linux noobs like myself who are not at all eager to trudge through configuration files. If a firewall enabled itself out of the box, many people would leave it at the default.

Given that I think the best course is to leave an opportunity for configuration before it gets enabled, but also make it very clear during installation that it is being left disabled.

[Jamie Strandboge (jdstrand)]

This can't be enabled until there is a graphical tool in the default desktop installation. Once that is done and there is proper integration with the desktop, it can be reconsidered. At present ufw can be preseeded in all Ubuntu installations to be enabled on first boot.

[Christopher Forster (christopherforster)]

See also: Feature Request: Allow / Deny incoming connections, outbound detection dialog #689818

[Santeri Kannisto (santerikannisto)]

What is the point in adding ufw to a distribution if it's disabled by default? Surely those users who know how to enable it are also able to also disable, install and uninstall it as well. Ordinary desktop users using computers as tools have no idea what a firewall is and why it's needed.

[Santeri Kannisto (santerikannisto)]

Here is a patch for this bug and #1795370 set default LOGLEVEL=off

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Fix default values to enable ufw and set logging off, and start the firewall for fresh installs" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Jeremy Bícha (jbicha)]

Santeri, see comment #6. There still is no graphical tool in Ubuntu's default desktop to enable and disable ufw. Therefore, we won't be able to accept your patch.

I am unsubscribing ubuntu-sponsors. Please re-subscribe ubuntu-sponsors if you have something else that needs sponsoring.

[Santeri Kannisto (santerikannisto)]

Jeremy,

I believe that without a graphical tool it is even more critical to have ufw enabled and running by default. Anyway, no worries about my patch and bug reports. I forked and patched ufw and have the package available in my PAA at https://launchpad.net/~santerikannisto/+archive/ubuntu/desktop

At this point I don't see any point or need in implementing a GUI config tool for ufw by myself nor participating in such effort. For my needs it's enough that ufw is enabled and running out-of-the-box blocking by default all incoming traffic with logging switched off.

Cheers,

Santeri

[Raymond Wan (rwan)]

Sorry to bring up a 4 month old topic, but I wouldn't want to see ufw enabled by default without a proper discussion.

I've previously managed servers (both real and virtual) remotely and if installing ufw meant that the firewall suddenly went up, I might lose my remote connection to the servers. For me, that would be a disaster...

And, I'm not sure if separating ufw into a desktop version and a server version is worthwhile.

Comment #3 from 2010 about having it enabled by default may be one OS' way of taking the marketshare. I'm not convinced it's done for the user's sake. On a Windows machine, I purchased another program to manage my firewall, but I still get reminders about not having the Microsoft firewall brought up. If it was for my protection, then the existence of a firewall by another vendor should remove the Microsoft firewall (and its reminders) completely...

[Sam T (qxcv)]

I've been a Ubuntu user for 10 years and was astonished to learn today that iptables just lets everything through by default on Ubuntu desktop. I'm a grad student in a CS department at a university, and had to learn this the hard way after one of the desktop machines in our lab was compromised.

In our case, the breach was a result of three layers of failure:

1. Some past owner of the machine let Docker listen on 0.0.0.0:2375. This is a really bad idea because it gives root access to anyone on the same network, but unfortunately there are people on the web that recommend doing this without explaining the ramifications. For instance, here is someone recommending this as a workaround for a minor configuration issue in the default Docker install, which could easily be resolved without listening on a public interface: https://gist.github.com/styblope/dc55e0ad2a9848f2cc3307d4819d819f

2. This insecure default could have been caught by an OS firewall, but unfortunately the FW was disabled by default.

3. Even the above two holes could have been made slightly less severe with NAT, or firewalling at the university level, but unfortunately our university assigns every ethernet-connected machine a public IP and allows all traffic in by default (except port 22, because 'security').

The machine was in this configuration for years until the campus intrusion detection system noticed some suspicious traffic to the machine, which prompted our discovery of the three issues above.

Hopefully it's clear from my explanation that the problem here was not just UFW. Docker should never have been configured to listen on a public interface. The university should probably not be letting random inbound traffic to desktop machines by default (or should at least clearly communicate that this is the case). The person who set up the desktop should have realized they had to enable a firewall.

Nevertheless, I'm sharing this anecdote to illustrate that even fairly sophisticated users can easily get burned by insecure configurations. Having no firewall enabled by default makes this worse. The desktop in this story was previously used by a research engineer and then a CS PhD student. If they can't get it right, then what hope does the average Ubuntu user have?

I'm sympathetic to the concerns raised above about unexpected config changes. It would be unacceptable if an apt upgrade suddenly brought down a web server or cut off ssh access. However, I expect there are ways that the majority of Ubuntu users could be protected without hurting running systems. For instance, you could enable ufw by default in the Ubuntu Desktop install media.

------

Addendum: you may think "hah, what idiot would open up a remote root access hole on 0.0.0.0?" Unfortunately, I've seen this as the *default* configuration for lots of software that really has no need to listen on public interfaces. The worst was a somewhat-popular scientific visualization tool that had no authentication and allowed for remote code execution by design. It's surprising how many developers don't realize what a terrible idea this is, and ultimately their users suffer for it.