Is firewalld installed & enabled by default on the new trixie alpha installer?

[Praxis]

I needed to do a fresh install for my little mini computer home server after a borked upgrade from stable to testing necessitated by a hardware upgrade (a new Intel n150 board/graphics). I used [Debian GNU/Linux trixie-DI-alpha1 _Trixie_ - Official Alpha amd64 NETINST with firmware 20241230-11:26] to reinstall my OS.

I restored my programs and data and found that I could not connect to my server using samba, my approx HTTP-based proxy server for Debian-style package archives or the apache2 web server, making the install pretty useless to me as a home server. I could ping the new server and connect using ssh, but that was it. Also, samba, apache2 & approx all worked from the machine itself. If I had had hair I would have been pulling it out.

Finally it occurred to me that there might be a firewall running (sue me, I'm slow on the uptake and I've never had a firewall installed and enabled by default in 20 years of using Debian and Ubuntu).

Code: Select all

$ systemctl --type=service
  UNIT                                                                                      LOAD   ACTIVE SUB     DESCRIPTION>
  accounts-daemon.service                                                                   loaded active running Accounts S>
  apache2.service                                                                           loaded active running The Apache>
  apparmor.service                                                                          loaded active exited  Load AppAr>
  cron.service                                                                              loaded active running Regular ba>
  cryptmount.service                                                                        loaded active exited  cryptmount>
  cups-browsed.service                                                                      loaded active running Make remot>
  cups.service                                                                              loaded active running CUPS Sched>
  dbus.service                                                                              loaded active running D-Bus Syst>
  firewalld.service                                                                         loaded active running firewalld >

Ouch. OK, it is easy enough to disable the service with:

Code: Select all

service firewalld stop

Everything was working properly again. I can figure out how to permanently disable, remove or make rules for firewalld later.

From glancing over my /var/log/apt/history.log file it looks like firewalld:amd64 (2.3.0-1, automatic) was installed at the time I ran the installer, not dragged in as a dependency with some other package.

If that is the case I think it is not a good idea to have firewalld enabled by default without having some sort of mechanism in place to warn the user that the firewall is rejecting service requests and maybe point the user to a GUI tool to configure the firewall (I gather plasma-firewall:amd64 was installed at the same time, I'm not in front of the screen at the moment, so I haven't played with it). Maybe I'm in a minority of one, but this was very unexpected & jarring behaviour to me.

Edit:
The plasma-firewall applet in Plasma KDE systemsettings is pretty straight forward and allows adding and subtracting rules. There you can permit protocols like http: for apache2, as well as samba with a couple of clicks. If you happen to have the approx proxy installed you can enable it from the command line with:

Code: Select all

sudo firewall-cmd --add-port=9999/tcp

I still think installing and enabling firewalld by default in the installer is a misteak absent any sort of warning to the user.

[Uptorn]

It seems this is a KDE-ism

Per the thread at Why does Debian ship a preconfigured firewall?:

installing Debian testing with KDE currently sets up firewalld by default, which sets up a firewall blocking all incoming connections apart from DHCPv6 and SSH.

Technically, firewalld ends up installed because the KDE Plasma desktop recommends the plasma-firewall package, which recommends firewalld. Those dependencies are optional and can be removed. firewalld isn’t installed by default with KDE in Debian 12, but that’s because the plasma-desktop package specifies an invalid version for plasma-firewall!

Another (messy) way of checking whether a package was pulled in as a dependency is to run an apt search:

Code: Select all

apt search firewalld

Does the firewalld search result display an entry with "[installed,automatic]" next to it?

[Praxis]

Yep.

Code: Select all

firewalld/testing,testing,now 2.3.0-1 all [installed,automatic]
  dynamically managed firewall with support for network zones

Thanks for the information, Uptorn. I really think KDE should at least disable the firewall by default, and let the user enable it from systemsettings if they want it. Maybe I'll nose around and see if there is a bug report on the subject. I suppose if you aren't using your machine as some sort of a server you might not even notice the firewall, but I was using the box as a local file & web server.

I've used Linux for personal use for 20 years and never seen the point of a firewall (other than my router) or antivirus for that matter, though I've messed with clamav to scan friends' Windows boxen. My machines always seemed secure. (That wasn't always the case when I ran Windows). Mind you, I'm not managing a corporate server, just a little household LAN, but professionals who would benefit from a firewall would undoubtedly know how to turn it on.

At least now I'm aware of what is going on, I can temporarily or permanently disable firewalld if a service doesn't work properly. Sometimes I wish Debian came with those little pop-up desktop thingies with important information and links like many distros do. They are easy enough to turn off and can be very helpful, especially for less experienced users.

Finally after a week I'm becoming comfortable with my new aptly-named trixie server, though if I had to do it over I wouldn't have ordered the newest hardware so I could have stuck with Debian stable & not broken my install by upgrading at a bad time in the cycle.