Why does Debian come without a firewall enabled by default?

Question

I'm using Debian 9.1 with KDE and I'm wondering why it comes without a firewall installed and enabled by default? gufw is not even in DVD1's packages.

Are people expected to connect to the Internet before getting a firewall? Why? Even if all ports are closed by default various installed, updated or downloaded programs could open them (or not?) and I wish for not even a single bit leaving my machine without my permission.

Edit: So I just found out about iptables but I guess the question still remains as iptables as firewall seems to be rather unknown to most, its default rules, its accessability & ease of usage and the fact that by default any iptable-rules are reset at restart.

Answer 1

First, Debian tends to assume you know what you are doing, and tries to avoid making choices for you.

The default install of Debian is fairly small and is secure — it doesn't start any services. And even the standard optional extras (e.g., web server, ssh) that are added to an install are usually quite conservative and secure.

So, a firewall is not needed in this case. Debian (or its developers) assume that if you start up additional services, you'll know how to protect them, and can add a firewall if necessary.

More importantly, perhaps, Debian avoids making the choice for you regarding what firewall software to use. There are a number of choices available — which one should it use? And even regarding a basic firewall setting, what setting should be chosen? Having said that, iptables is of priority important, so it is installed by default. But of course, Debian doesn't know how you want it configured, so it doesn't configure it for you. And you might prefer to use iptables's successor, nftables, anyway.

Note also, that firewalling functionality is already built into the Linux kernel to a certain extent; e.g. nftables and netfilter. Debian and other Linux distributions do provide user space tools like iptables to manage that functionality. But what you do with them is up to you.

Note that these entities are not named consistently. To quote the Wikipedia nftables page:

nftables is configured via the user-space utility nft while netfilter is configured via the utilities iptables, ip6tables, arptables and ebtables frameworks.

Answer 2

First off, I do want to repeat what has already been said: Debian caters to a rather different group of users than many other mainstream distributions, particularly so Ubuntu. Debian is geared toward people who know how the system works, and who aren't afraid to tinker from time to time in return for a high degree of control over the system. Ubuntu, for example, caters to a very different target audience: people who just want things to work and don't (really) care what's going on under the hood, and certainly don't want to have to modify system configuration to make things work. This impacts a number of aspects of the resulting system. And to some extent, that's one beauty of Linux; the same base system can be used to build environments that cater to different needs. Remember that Ubuntu is a Debian derivative, and to this day still retains a great similarity to Debian.

gufw is not even in DVD1's packages.

The first disk contains the most popular software, as determined by opt-in gathering of anonymous statistics from installed systems. The fact that gufw is not on the first disk simply indicates that this is not a highly popular (in terms of installed base) package in Debian. It's also easy to install once you have the base system with networking up and running, if you prefer it over alternatives.

Are people expected to connect to the Internet before getting a firewall? Why?

Well, for one thing, I believe that Debian allows installing over a network. (Not only downloading packages from the network during a normal installation, but literally starting the installation from a different host than that being installed on.) A firewall configured by default with a restrictive rule set would risk interfering with that. Same with installations that need outgoing network access during the installation process for purposes other than merely downloading the most recent versions of packages being installed.

For another, there is that which I mentioned above; as a rule, Debian expects that you know what you are doing. If you want a firewall, you are expected to be able to configure it yourself, and it's expected that you know better than the Debian maintainers what your particular needs are. Debian is a bit like OpenBSD in that regard, just not as extreme. (When given the choice between making the base system a little more secure and making it a little more usable, the OpenBSD maintainers virtually always go for the security. That shows in their base system security vulnerability statistics, but has huge implications on usability.)

And of course, the technicality: Firewall support is included in the base system. It's just that it's set to an all-permissive rule set by default by the kernel, and a base Debian installation doesn't do anything to change that. You can run a couple of commands to restrict the traffic flow.

Even if all ports are closed by default various installed, updated or downloaded programs could open them (or not?) and I wish for not even a single bit leaving my machine without my permission.

First, firewalls are typically used to restrict incoming traffic. If you want to restrict outgoing traffic, that's a rather different kettle of fish; certainly doable, but needs much more tailoring to your specific situation. A default-block outgoing traffic firewall that leaves commonly used ports open (where commonly used ports might be ftp/20+21, ssh/22, smtp/25, http/80, https/443, pop3/110, imap/143 and a bundle of others), plus allowing traffic related to established sessions, wouldn't be much more secure than a default-allow firewall. It's better to make sure the set of packages installed by the base system is restricted to a set of well understood, configured secure as delivered packages, and allow the administrator to set up appropriate firewall rules if they need more protection than that.

Second, a closed port (one that responds to a TCP SYN with a TCP RST/ACK, typically reported as "connection refused" -- this is typically the default state of a TCP port on a live system supporting TCP/IP in absence of either configuration to the contrary, or software listening on it) isn't a significant vulnerability, even on a system not connected through a separate firewall. The only significant vulnerability in an all-closed configuration would be if there is a vulnerability within the kernel's TCP/IP stack implementation. But the packets are already passing through the netfilter (iptables) code in the kernel, and a bug could lurk there as well. The logic for responding with what results in a "connection refused" at the other end is simple enough that I have a hard time believing it would be a major source of bugs, let alone security-related bugs; bugs relating to network services are almost always within the services themselves, and if they aren't running or aren't listening on anything but loopback interfaces, there isn't really anything for an attacker to connect to and exploit.

Third, packages are typically installed as root, from which you (the package) can change the iptables rules without your knowledge anyway. So it's not like you gain anything like requiring the human administrator to manually allow traffic through the host firewall. If you want that kind of isolation, you should have a firewall separate from the host it is protecting in the first place.

So I just found out about iptables but I guess the question still remains as iptables as firewall seems to be rather unknown to most, its default rules and the accessability & ease of usage.

I would actually say that the opposite is true; iptables as a firewall is well known. It's also available on virtually every Linux system you are likely to come across. (It replaced ipchains during the development that led to Linux kernel version 2.4, around year 2000 or so. If I recall things correctly, the biggest user-visible change between the two for the common use case of firewalling was that the built-in rule chains were now named in uppercase, like INPUT, instead of lowercase, like input.)

If anything, iptables can do things other than firewalling which aren't widely used or understood. For example, it can be used to rewrite IP packets before they are passed through the firewall.

Answer 3

If I were to guess, without actually being in the head of a generation of Debian developers and maintainers, my guess would be this:

Debian is primarily designed as a server operating system, both sid and testing branches have as their primary purpose the creation of the next stable branch, and, at time of freeze, they are frozen, and the new stable is taken from testing, as just happened with Stretch.

Given this, I would further assume, I'd have to confirm this with a sysadmin friend, that datacenter firewalls are external devices, much higher security (at least one hopes this is the case)), to the servers, and handle the main firewalling tasks. Even on a small LAN with a router, this is the case, the router is the firewall, I don't use any local firewall rules on any of my systems, why would I?

I think maybe people confuse their local installs of desktop Debian or a single file server in an office or home with the actual work connected to Debian, which I believe focuses mainly on production use.

I'm not sure about this, but after over a decade of Debian use, that's my feeling, as both a developer, and supporter of Debian in many ways.

I can check on this, since it's actually a good question, but my guess would be that real networks are firewalled at the entrance points to the network, not on a per machine basis, or at least, that's the basic idea that would maybe drive Debian. Plus, of course, that if that were not the case, the sysadmin would be setting up the firewall rules on a per machine basis, using something like Chef, not relying on any default install, which wouldn't be something you'd tend to trust, for example, the default Debian ssh configurations are not what I would use personally as a default, for example, they allow root login by default, and it's up to the sysadmin to correct that if they find that to be a bad practice.

That is, there is an assumption of competence I think re Debian that may be absent in some other distros. As in, you'd change what you want to change, create images, manage them with site management software, and so on. Those are just a few possibilities. For example, you'd never use the DVD to create a new server, at least never in production, you'd probably use something like the minimal netinstall, that's what I always use, for example (I used to use an even smaller image, but they discontinued it). If you take a look at what is included in that base install, you get a decent sense of what Debian considers crucial and what it doesn't. ssh is there, for example. Xorg is not, Samba is not.

One could also ask why they went back to GNOME as a default desktop, but these are just decisions they make, and which their users basically ignore since you can make the systems the way you want (that is, to get Xfce desktops, I don't install Xdebian (as in, Xubuntu), I just install Debian core, Xorg, and Xfce, and off I go). In a similar way, if I wanted firewalling, I'd configure it, learn the ins and outs, etc, but I wouldn't personally expect Debian to ship with that enabled, it would actually be kind of annoying to me if it were. Maybe my views on this reflect a sort of consensus you might also find internally in Debian.

Plus of course, there is really no such thing as Debian, there's various install images, netinstall, full install, these all vary from barebones, cli only, to a reasonably complete user desktop. Production users would probably create images for example, which would be configured the way the user wants, I know if I were setting up a Debian server, I'd start with the raw basics, and build it up until it did what I wanted.

Then you have the world of webservers, which is an entirely different ball of wax, those have very different security questions, and, as an old friend of mine well connected to the hacker underground said, someone who runs a webserver without knowing how to secure it can also be called someone whose server is owned by crackers.

Answer 4

The general idea is, you should not need a firewall on most systems except for complex setups.

SSH is running,, when you installed a server. Nothing else should be listening and you probably want to be able to connect to ssh.

When you install an webserver, you would expect the webserver to be available, wouldn't you? And for basic tuning, you can bind the webserver, to the private lan interface only, e.g. 192.168.172.42 (your local LAN IP), instead of 0.0.0.0 (all ips). You still do not need a firewall.

Of course, everything can open a port >1024, but when you're having untrusted software (or untrusted users), you should do more than just installing a firewall. In the moment you need to distrust something or somebody you need a security concept not only a software. So it's a good thing when you need to actively think about your firewall solution.

Now there are of course more complex scenarios. But when you actually have one of these, you really need to fine tune the firewall yourself and don't let a half automatic system like ufw do it. Or you may even use ufw, but then you decided it and not the operation system's default.

Answer 5

Are people expected to connect to the Internet before

yes

getting a firewall?

Even if all ports are closed by default

Sorry, they are not. rpcbind seems to be installed, enabled, and listening on the network by default.

EDIT: I believe this has been fixed in the latest installer, i.e. for Debian 9 (Stretch). But with previous versions of Debian, I would not feel very safe installing (and then updating) them on a public wifi network.

Why?

I suspect people have an assumption that

1. the local network will not attack your network services
2. there is already a firewall between your local network and the wider internet.

While the latter is common practice e.g. by consumer routers, I do not believe it is guaranteed. Unsurprisingly the former assumption is not documented; nor is it a sensible one.

In my opinion, the issue with rpcbind is an example of a more general point. People can try to promote Debian, and it has many cool features. But Debian lags behind Ubuntu in how polished and friendly it is, or arguably even how reliable it is for those who want to learn such details.

downloaded programs could open them (or not?) and I wish for not even a single bit leaving my machine without my permission.

You're certainly free to install a firewall before you start downloading and running random software that you're not sure what it does :-p.

I agree in part, it is alarming to install Linux and not find any interface set up for what is a very well-known security layer. Personally I found it useful to understand how the default Windows firewall is set up. It wants you to be able to "trust" a home network, and in more recent versions the express install will even skip asking if you trust the current network. The main goal seems to be to distinguish between home networks, unprotected connections like a directly connected modem, and public wifi networks. Notice that UFW does not support this anyway.

Fedora Linux alone tried to provide something like this, in firewalld. (Packages appear to be available in Debian too...). The GUI for it is not as "friendly", let's say, as GUFW.

Answer 6

The traditional philosophy of Unix has been always KISS and running/exposing the minimum of services.

Several services also have to be installed explicitly, and even some come bound to localhost, and you have to enable for them to be visible in your local network/ in the Internet (MySQL, MongoDB, snmpd, ntpd, xorg...). This is a more sensible approach then enabling a firewall by default.

You only need the complexity a firewall bring from a certain point, and that need may be diminished being behind a corporate router or a home nating device, so it sounds sensible leaving up to the user that decision. A firewall, like so many other security software can also provide a false sensation of security if not properly managed.

The orientation of Debian has always been the more technically oriented folk who knows what iptables is; there also several well know wrappers, text or graphical mode interfaces that can be easily installed.

On top of that, whether it comes with too much or too less software installed comes to a matter of opinion. To a long time veteran, it comes with too much software and services installed by default, especially in server mode.