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.

Solution 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.

Solution 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.

Solution 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.

Solution 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.

Solution 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.

View more solutions

Comments

[rlf]

Very good question. Ubuntu server doesn't even come with iptables pre-installed! I guess people just trying to take the end-to-end principle to the layer 7 extreme...

[SaAtomic]

What's your reason to state that iptables is "unknwon to most"?

[StrongBad]

I asked something similar a while back unix.stackexchange.com/questions/127397/…

[mYnDstrEAm]

@marcelm How so if any change to firewall rules requires root?

[cat]

@mYnDstrEAm for example because you give those programs' install scripts root access when you give sudo your password as in sudo apt-get install package ...

[marcelm]

@mYnDstrEAm Because installing and updating Debian packages runs various scripts (pre/post update/install/etc hooks) from the package as root.

[mYnDstrEAm]

@marcelm cat Okay so the way Debian updates/installs packages and/or the way the firewall is implemented seems to be flawed in that it doesn't notify me about firewall changes / allow me to prohibit such firewall changes.

[user2948306]

I usually don't like long answers like this :) but you touch on a very relevant point. If you run a web server, it needs to accept connections to the web server. It's questionable what value you get from configuring a second piece of software to say: yes, I want to accept web requests sent to my web server. And this use case seems to be more cared for inside Debian than the desktop is.

[Lizardx]

I'm glad you qualified the comment re ubuntu with 'for someone trying to learn', I think in a sense that's the actual answer, debian is not a system created for that group, and ubuntu's existence might actually come down to that fact. As someone not trying to learn, that's the exact reason I always prefer debian over ubuntu, for example. I used to play with local firewalls, but in the end, I started to see them more as toys than real utilities, I mean gui stuff, not iptables etc. Your 1. and 2. points I think cover the thinking behind this decision, I agree with that decision by the way.

[user2948306]

@Lizardx I've edited to try and emphasize how discouraging I find the situation with rpcbind + public wifi networks :). I think I know where you're coming from in that comment, but I don't entirely agree. I'm happy to have access to an arsenal of footguns in the repo, but I like to have a defined default (or several, e.g. if you count XFCE as the popular "not GNOME3" option) as a reliable base to build out from.

[Lizardx]

Public wifi is obviously the use case where firewalls on a system matter a lot for regular users. But as indicated in other answers, Debian assumes that you know this if you install it and happen to use it in that way. Maybe closer to how FreeBSD or OpenBSD might view this question? Speaking only for me, I'm a HUGE non fan of Debian default package group selections, I've never seen them create something I'd actually want to run, unlike say, XUbuntu, or various Debian spins that have created nice default installs. With this said, I agree, a not GNOME 3, XFCE, option would be very nice.

[Alen Milakovic]

@sourcejedi As far as I can recall, Debian's default install has been very similar since at least potato, which is when I started using it. So, I'm not sure what you mean.

[user2948306]

I'm sorry I don't know the exact detail of the top of my head, but you can definitely find multiple reports about rpcbind online. unix.stackexchange.com/questions/20356/…

[Alen Milakovic]

I do see that exim4's priority has changed from standard to optional (it looks like), so I suppose that's one more service that Debian thinks a base install can do without. Though personally, I think that a mailserver is normally needed for most things on a system, even if only internally. But I suppose Debian thinks it shouldn't force you to use it.

[Alen Milakovic]

"Plus of course, there is really no such thing as Debian". I'm not sure what you mean by this - there is definitely such a thing as Debian. It's the operating system that is produced by the Debian project. Technically it is a family of operating systems, but of course, the Linux variant is very much dominant. There are various methods of installation, but they all install the same system. Of course, you have a lot of freedom about which parts of it to install.

[Lizardx]

Hard to explain,but I'll try: I don't install 'Debian', I install say, Debian Testing/Buster, 64 bit variant, from the netinstall iso. So Debian is the umbrella, that runs and creates what I install. This is I've come to realize over the years why I like Debian so much, they have strict rules, and those rules to me are what really define something as Debian and not Ubuntu. So for example, if you take a set of packages from Debian, and create Ubuntu, when does it stop being Debian? it's the same packages, at least for a while, and I'd suggest, it stops when you stop following the dfsg rules.

[user2497]

gufw is horrible. ufw makes almost no sense, and doesn't it store the rules in XML? ugh. even a manual iptables ruleset is easier to deal with.

[hobbs]

@FaheemMitha the previous default wasn't for it to accept connections from outside, anyhow :)

[Alessio]

+1 for tries to avoid making choices for you.. There are many different tools for managing firewalls, each with different pros and cons, each with different use cases. and there are an even greater number of ways that a firewall can be configured. defense in depth (e.g. a standalone firewall/router AND per-host iptables rules) is good, but i would find it very annoying if the debian installer presumed to know how my network was setup and what firewall rules i wanted. that's for me to know and me to decide.

[user]

"Not in the sense of [Debian] referring to one thing." In that case there is no such thing as Windows either. There are 32-bit Intel versions, 64-bit Intel/AMD versions, various ARM versions, ... plus you have editions like Home, Pro, Ultimate. Then add the fact that there are server variants and client variants, each of which indeed do come in different editions. That doesn't stop us from talking about Windows, nor should the fact that different variants of Debian exist prevent us from talking about Debian in general. That said, in some cases you may still need to be explicit and specific.

[Alen Milakovic]

Excellent and detailed summary of the issue. However, you wrote "Second, a closed port isn't a significant vulnerability, even on a system not connected through a separate firewall." Did you possibly mean to write "open"? If not, can you expand on how a closed port is a vulnerability? Thanks.

[Jules]

"It replaced ipchains some time in the kernel 2.5 development, if I recall correctly. That's something like 15 years ago now." -- 2.3, actually. Which makes it closer to 20.

[a4xrbj1]

Nice answer, although "Debian avoids making the choice for you [as] there are a number of choices available" does not make much sense to me. Debian is already making choices (e.g. picking Apache over lighttpd when I select "Web server", deb over rpm... well obviously) where alternatives are available. Isn't the very point of a distro the one of making choices?

[Alen Milakovic]

@gd1 It's true; Debian does provide and install defaults - e.g. Exim, historically. But they're easy to change. And I suppose iptables is a default for Debian too. But one thing Debian does not do on its own is non-obvious system configuration for the user.

[Ruslan]

tries to avoid making choices for you — does it? The whole point of a Linux distribution is in a default set of applications and configs. What would remain of Debian if it didn't e.g. choose the default shell, default X server (and even default windowing system itself), default desktop, default text editor etc.?

[wizzwizz4]

@Ruslan It lets you choose what GUI to use - the windowing system and X server are chosen, but that's about it as far as GUI is concerned. It tries to avoid it, but people need something usable to start with. (It even includes multiple terminal emulators!)

[bgvaughan]

IIRC, firewalls for personal computers were a response to one of the security vulnerabilities with Windows 95, which was that all ports were open by default. On most operating systems, before and since, a port is only open if there's actually a service listening on that port. Secondarily, firewalls are often configured to drop packets silently, rather than explicitly reject them, so that it's difficult to tell there's a system at an IP address at all.

[marcelm]

@sourcejedi Although exim4 was included in the default install of Debian (up to 8, at least), it was configured by default to not listen on the network. You have a point about rpcbind though, and I'm glad to see it removed from the default install.

[Lizardx]

The problem, of course, with running Debian, is that once you install, it can be ages before you reinstall, this sounds like a new feature, but it's been so long since I've even seen that maybe it's improved, that would be good.

[Lizardx]

Ruslan, this i the problem with referring to an installation of packages from the set of Debian apt package pools as 'Debian'. For example, I never install Debian the way you describe, I do a base install, then install the packages I want. In that base install, there are some defaults, you need after all some things, like OpenSSH, but there really are not a lot in that set. I've never in my life installed a 'web server' deb, I've installed Apache2.x. This is basically user error in my opinion, Debian does provide default packages and groups if you want to use them, but nobody forces that.

[Lizardx]

Excellent answer, agreed. I'd also add that when you install from the minimal possible installation iso, currently netinstall, part of the install process is actually to install the packages from apt over the network, so your installation is not out of date out of the box, it's current, which is exactly what you want, though you can also choose to install from disk, so that installation really does need an immediately working network connection. But this answer was very good.

[Lizardx]

I think the source of confusion is believing that the dvd installer iso is 'Debian' per se, it's not, it's a convenient set of defaults selected for those users who want to install that way, but those defaults have nothing to do with Debian in essence, they are simply some choices the install DVD maintainers make. If you pick say the advanced install option on the netinstall iso, you pick what to install. You may be offered some package groups, but those are not 'Debian', they are just shortcuts. I never use those shortcuts, yet I run Debian.

[wizzwizz4]

@Ruslan More than I expected! When LXDE is enabled, it "only" has lxterminal and xterm available (from the pseudo-start bar).

[allo]

I am not sure what you mean with an open port without a listening service. Where should the packet go and why should this be a security hole? And dropping packets in your firewall will not hide you, but make it even more obvious, that there is a machine with a firewall. When your system is not online, the router before your system sends an "unreachable" answer. It does not when your machine is there (neither when you accept, reject or drop packets). You can check the effect yourself by using doing a traceroute to your system.

[bgvaughan]

I'm a bit confused about your proposed traceroute experiment, but it reads like you're making a lot of assumptions about how the router is configured. As for the firewall, DROP doesn't send a response, but REJECT does; simple as that. IIRC, older Windows systems, like 95 and I think XP, would hold all ports open, even if there were no running services; it was very difficult to control what went in and out of an unpatched old Windows box, and there were lots of bizarre exploits involving hitting a port with certain sorts of traffic.

[allo]

When I start a traceroute to you, then i may see 7 hops. The first is my pc, the last is the entry point to your network. When your PC is offline, the 6th hop sends a "unreachable" reply. When your PC is connected but firewalled, the 6th hop sends a normal reply and the 7th drops (or rejects) the packet. And you're not in control of the 6th hop, so you cannot fake or drop packets there.

[allo]

"older Windows systems, like 95 and I think XP, would hold all ports open, even if there were no running services" I have absolutely no idea, what you're meaning with holding a port open without listening. When a packet comes in, you can either send it to a listening program, reject it or drop it. There is no "port open without listening" concept. Maybe you mean dropping (accepting without sending it to a program).

[bgvaughan]

Hmm. I don't have a setup (i.e., publicly addressable systems behind a router under my control) that I can test, but that makes sense. About the only use case I can think of right now for a simple firewall is for a laptop that you sometimes use with public wifi, and even then it seems like it would be just as easy to shut down services as to bring up a firewall. About the open ports on Windows 95: I'm going on memory of an operating system from twenty years ago, before I knew anything about networking, so my memory is likely flawed.

[bgvaughan]

I'd say the core of Debian is the packaging system, and that as you move away from that core, there are defaults, but they are weak defaults, by which I mean there's no particular expectation that you accepted the defaults. Contrast that with, e.g., Linux Mint, where there are strong defaults. With weak defaults, it's easier for an experienced user to customize the system to their preferences; with strong defaults, it's easier to write documentation for novice users that makes assumptions about how the system is configured.

[Alen Milakovic]

Belated comment: "Remember that Ubuntu started out as a fork of Debian, and to this day still retains a great similarity to Debian." As far as I know, Ubuntu is still derived from Debian. It's not a fork.

[Alen Milakovic]

@Lizardx "it stops when you stop following the dfsg rules." Actually, you are almost certainly thinking of Debian Policy.