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.

  • 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...
    – rlf
    Commented Jul 31, 2017 at 22:15
  • 10
    What's your reason to state that iptables is "unknwon to most"?
    – SaAtomic
    Commented Aug 1, 2017 at 10:31
  • 1
    I asked something similar a while back unix.stackexchange.com/questions/127397/…
    – StrongBad
    Commented Aug 1, 2017 at 12:29
  • 1
    "Even if all ports are closed by default various installed, updated or downloaded programs could open them ..." - If you assume malice, then installed, updated, or downloaded programs could also clear the firewall rules.
    – marcelm
    Commented Aug 1, 2017 at 15:21
  • 2
    @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 ...
    – cat
    Commented Aug 1, 2017 at 15:50

6 Answers 6


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.

  • 4
    @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. Commented Jul 31, 2017 at 23:26
  • 1
    @FaheemMitha the previous default wasn't for it to accept connections from outside, anyhow :)
    – hobbs
    Commented Aug 1, 2017 at 2:41
  • 1
    +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.
    – cas
    Commented Aug 1, 2017 at 3:01
  • 4
    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?
    – gd1
    Commented Aug 1, 2017 at 12:43
  • 1
    @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. Commented Aug 1, 2017 at 13:08

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.

  • 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. Commented Aug 1, 2017 at 10:05
  • "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.
    – Jules
    Commented Aug 1, 2017 at 11:04
  • 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
    Commented Aug 1, 2017 at 17:57
  • 1
    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. Commented Nov 1, 2017 at 6:17

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.

  • 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.
    – sourcejedi
    Commented Jul 31, 2017 at 22:55
  • sourcejedi, lol, had it not been long, I wouldn't have gotten to the webserver question, that was the last thing I added. But in this case, you have a user who is clearly new, less experienced, who may not realize that different distros cover radically differing use cases and users. So they have basically no information, and at that point, it's hard to know what they know and don't know, ergo, too many words. Or just enough. Hard to know.
    – Lizardx
    Commented Jul 31, 2017 at 22:59
  • "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. Commented Jul 31, 2017 at 23:33
  • Not in the sense of it referring to one thing. What you note as what it is technically is what I mean. That is, is Debian the dvd installer image this person referred to? Is it the core install you get on netinstall? Is it the apt package pool for the specific architecture? Is it the sid pool for that? The testing pool? and so on. In terms of how users define thing, I'd say there is no such thing, what there actually is is the project, Debian, that governs the packaging rules and packages that define apt and .deb. This is why I like it, by the way, it's the rules that define the project.
    – Lizardx
    Commented Aug 1, 2017 at 0:05
  • 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.
    – Lizardx
    Commented Aug 1, 2017 at 0:08

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. (your local LAN IP), instead of (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.

  • 1
    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.
    – bgvaughan
    Commented Aug 1, 2017 at 15:44
  • 1
    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.
    – allo
    Commented Aug 2, 2017 at 15:54
  • 1
    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
    Commented Aug 3, 2017 at 14:53
  • 1
    "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).
    – allo
    Commented Aug 3, 2017 at 14:56
  • 1
    Personally I have a deny by default firewall as well as safe fallback. But I understand when debian let's the user install the firewall. I am experimenting a lot, others choose web server in tasksel and are done. No idea about the win95 thing, but i guess it doesn't matter today anyway ;).
    – allo
    Commented Aug 4, 2017 at 8:18

Are people expected to connect to the Internet before


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.


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.

  • 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.
    – Lizardx
    Commented Jul 31, 2017 at 22:56
  • @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.
    – sourcejedi
    Commented Jul 31, 2017 at 23:15
  • 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.
    – Lizardx
    Commented Jul 31, 2017 at 23:21
  • 4
    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.
    – user2497
    Commented Aug 1, 2017 at 0:55

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .