There are lots of different ways to approach security - and the nice thing about open source is that you have the option of doing what you think is right.
Like I said, it’s really easy to install firewalld and the necesssary modules to configure it. So go forth and configure it the way you decide is necessary to meet your security needs and requirements.
And if something else better meets those needs, then by all means, use that. It’s always your choice to do what you feel is the right thing, and nobody can take that away from you.
If you want a more in-depth discussion about the design goals, though, user support forums (which this is) is probably not the right place - you probably want to get involved in the mailing lists, where the developers tend to hang out. Then you can ask more questions about the design goals and why they were made, and make your case for changes like adding firewalld by default.
ETA: I don’t speak for the project; my opinions are my own. Just so we’re clear there.
You are muddying the waters here. Silverblue is one distribution. openSUSE is a project, some of its distributions include firewalld by default, which according to reports is even more restrictive than Fedora distributions (re: ports > 1024). The openSUSE MicroOS/Aeon variant doesn’t ship firewalld by default. You were told more than once you can install it there yourself. This is a support forum after all, not a development board.
Nothing prevents it, all you have to do is run the following commands (as root):
zypper in -t pattern yast2_desktop
zypper in firewalld yast2-firewall yast2-control-center-qt
(not all of the packages I listed are strictly needed - you don’t need the qt package if you’re fine with using the TUI interface for YaST; you really don’t even need YaST and can use firewall-cmd if you really want to)
Then you need to enable the firewall:
systemctl enable firewalld
Reboot, and you’re good to go. Use YaST or whatever tool to configure to your heart’s content.
Just don’t expose the containers’ ports to the outside world in the containers’ configuration. This is the recommended configuration for containers, regardless of whether a firewall is present on the system.
Adding a firewall would require duplicating the port configuration in both the firewall and the container’s settings.
Configuring the ports twice is redundant and unnecessary in my opinion. Properly configuring containers already provides a “firewalled” setup without the need for an additional firewall. If you don’t want the containers’ ports exposed to the public, build the container that way - a firewall is not required for that purpose.
It’s funny this community is more strict on the definitions about (Open)SUSE than security and the nature of immutable distributions.
Yes, you can install firewalld on an immutable OS. But the point of such a system is to not touch the base system, unless absolutely necessary. It’s frowned upon to do so. And if you have to tell users both to respect the immutable nature of the OS and not to forget to install a firewall after first booting, then sorry, you lost my interest. I know, I’m not important. But I’m quite sure more people will scratch their heads over this one.
I’m really worried about the amount of people here that think a firewall is not needed and so much trust is put in people configuring their containers right. Defense in depth, once again. Look it up. Surely you also have a firewall running for this Discourse forum, right? I also run a Disourse forum. VPS and local firewall enabled, because double firewalls are part of defense in depth as well. Because firewalls can have bugs too. And on the local firewall I also have IDS/IPS in conjunction with firewalld. Because that’s what admins do to protect their data.
Please don’t change the tone of my reply into some kind of personal attack. I’m worried in a technical and professional sense. Usually it’s a red flag when someone disables or uninstalls a firewall on a production machine, let alone downplays the benefits of a firewall.
A firewall is not a nonplusultra. As already pointed out, there are other ways to reach same security. And not all use cases require a firewall. Micro OS/SUSE Aeon is not intended for a home user like your mom.
Security is done on multiple levels, check e.g. the OSI model, you have to apply security on each one. Just applying something on the application layer is bad, lazy and prone for mistakes. But I’m clearly preaching to the wrong crowd and the point of defense in depth is not understood. I really didn’t expect this from the OpenSUSE community.
It’s funny that you say Aeon is not for my mom, I agree on that. In fact she and other family members use Fedora Silverblue with ease, because the system is out of the box secure, stable and usable for both normies and pros. And pros really don’t disable firewalls, ever. Unless I’m already getting too old and this is the latest trend?
Anyway, I won’t disturb this forum any longer with my ranting Maybe I’ll be back one day, because as I said, OpenSUSE looks nice. It’s just not for me yet, apparently.
I’m fine with you deciding Aeon is not for you. Can you please acknowledge we (openSUSE) have other distributions that do include firewalld, enabled by default with very restricted access?
Also, since you demonstrate being a highly opinionated person, what do you think about distros opening ports > 1024 by default? Do you happen to use such distros? What do you need to do after installation? What do non-tech-savvy family members do?
You wouldn’t use an Aeon installation to provide NAT for your network. It’s specifically designed to be a desktop distribution. And that is all. If you want to put an openSUSE machine together as a firewall/NAT/DHCP/whatever other network use for other clients on a network, you should be using Tumbleweed, or Leap, or MicroOS.
If the Aeon machine is the only thing on the network, exactly what do you need NAT for?
So MicroOS doesn’t have a firewall by default? While that isn’t the decision I would make, I can see how you could potentially get to it. The intention is that there should not be any services running on the host so a firewall is just needless overhead.
However, that logic doesn’t apply if you run a desktop environment on it. Now you have all kinds of applications running that have the potential to open up network connections and listen on ports. Combine this with the fact that in the modern network, the likelihood of an attack coming from inside the network is fairly high, it seems quite irresponsible to ship without a firewall enabled.
As I am relatively new to the project, what is the appropriate way to discuss something like that if the forum isn’t the place?
I see where your confusion is. You’re reading “a firewall isn’t needed with MicroOS” to mean “a firewall is never needed”.
Rest assured that that’s not the case. MicroOS is designed for a really specific set of use cases where a firewall is duplicative.
Like you, I also run a discourse instance myself. I use a firewall (in fact, I use multiple layers, not just firewalls - I also use a reverse proxy that provides an optional authentication layer if I so desire).
I also don’t run it on openSUSE Aeon (a desktop distribution not intended as a services host) or MicroOS (intended for container workloads). I run it on Tumbleweed. And I use the openSUSE firewall, the firewall on my router, and the reverse proxy that sits in front of it all behind my router firewall.
Aeon does come in a version that is set up to both be a desktop and a container host, which is what I’ve installed in VMware so I can learn more about it.
Now, we’ve talked about how Docker (and Podman, which is the container engine used in MicroOS/Aeon) handles exposing ports as part of the use of container-based services. What we haven’t really talked about is how it actually does this.
Containerization services actually run services not just at the application layer - they encompass all layers. If you’ve played with K8S in any form, you know that you can create networks for groups of services and run them isolated from your public network. In a K8S cluster, you can even do that across nodes.
Similarly, in a Docker or Podman environment, you can create these ‘virtual networks’. That’s not done at the application layer of the OSI model you love to talk about.
It’s done at the network layer. Using iptables, as it happens.
So while firewalld is not used as a firewall on Aeon or MicroOS, iptables is, managed by podman.
Which is why using firewalld is redundant - iptables already is present as the firewall. And since the purpose of MicroOS specifically is to run containerized workloads, having two firewalls on the box is not necessary.
Where Aeon is concerned as a desktop environment, again, it’s not intended to be used as a services host. Firewalld is not an egress firewall, it’s an ingress firewall. No services running on the desktop means no listeners (possibly with a few exceptions like sshd for remote management, but you’re using key-based authentication for that and securing your keys properly, right? Not allowing root to login via ssh and following all the other best practices for security around that service?). Firewalld will let you shut the port if the service is running, but that kinda limits your ability to use the service, doesn’t it?
A default installation of Aeon has exactly 1 TCP port open - port 22. Confirmed with an nmap port scan.
Scanning udp ports obviously takes a bit longer, but lsof shows that there are UDP listeners on the network interface for avahi-daemon. cupsd is there (TCP), but only for localhost (and not the NIC), and chronyd has UDP listeners for localhost on 323, as expected.
Every other connection is outbound, which firewalld isn’t designed to do anything about, because it’s an ingress firewall.
If Aeon or MicroOS doesn’t meet your needs from the openSUSE project, you have Leap and Tumbleweed which are designed to provide more flexibility - and which BTW do include firewalld.
But on a desktop, almost any application can open a port, especially on unprivileged ports. Also, desktops tend to need to run services to do desktop-related things. Even if these might not be enabled by default, they can easily pop open without the user realizing it from installing a package or enabling a service.
So unless the expected use case is to deploy it and run it without applications running, the idea that you don’t need a firewall here is flawed. The firewall protects us against all the unknown risks that come with a desktop.
Let me ask a different question, with a desktop use case, why would you not want to install a firewall by default in 2023? Sure, some people will disable it but isn’t it better to ship secure by default in this case?
Looking at it from the opposite angle, why would it make sense to ship leap and tumbleweed desktops with a firewall but not Aeon? The immutable base shouldn’t really change the need for a firewall one way or the other.
I’m not deeply involved in Aeon, so I can’t speak to the design principles behind the decisions. karlggest said something about Richard Brown’s principle being a “Chromebook experience” - and as I noted, iptables is on the system as installed, so you do have a firewall, it’s just not firewalld.
If you’re running applications that open ports, then Aeon is probably not the distribution you are looking for. You’re probably looking instead to use Leap or Tumbleweed. Aeon is for a really specific desktop use case: Minimal applications rather than hosting services.
For more information about what the design principles and goals are, I’d suggest reaching out on the channels that sfalken provided, as that’ll get you a conversation with those who are actually working on it.
These forums are user support forums, and are generally not monitored by the developers (there are a small number of devs who pop in here from time to time).