Do FirewallD zones in Webmin that do not have corresponding /etc/firewalld/zones .xml files do anything?

There are a number of zones in FirewallD in a Webmin out-of-the-box installation which do not have corresponding /etc/firewall/zones/ .xml files. Are those active in any way?

An example is “dmz” which comes pre-configured for ssh port 22.

It makes sense that in whatever network or IP range you consider to be “de-militarized” you would allow SSH. But without an .xml file to correspond, is there actually a “dmz” (or any port or IP range that would be opened or closed of I deleted it)?

Thank you.

(I apologize for the re-ask, I think my original post on the subject was too broad.)

SYSTEM INFORMATION
OS type and version Ubuntu 24.0.2
Virtualmin version 7.30.4

The answer remains pretty much the same. I THINK the basic layout is probably set by your OS of choice with Webmin/Virtualmin opening/setting some default ports. All those zones are probably meant as place holders so you don’t have to start from scratch.

To understand what Firewalld is doing, I’d start here.

It’s the “probably” that worries me, since I aim to make a public-facing server. I was hoping that someone just plain knew for sure.

Yeah, we don’t invent anything new. We add a handful of allowed services and ports, that’s all we do. We don’t create any zones.

We try really hard to leave your system in a state you’d recognize if you’re very familiar with your OS. So, when we install a package, we make the minimal changes we have to make for our use case and for the needs we think most Virtualmin users will have.

And, for firewalls, a complicated firewall on a public server is stupid. Don’t make complicated firewalls on public servers. Turn off services you don’t need, use some kind of active firewall tool for brute force and DoS attacks (e.g. fail2ban in the case of a Virtualmin system, but sshguard or CSF or others can work fine). That’s it. Anything else is just spending time on theater. A static firewall on a public server is mostly useless; you shouldn’t run services on the public interface(s) that you don’t want to be available to the world, and services that aren’t running on the public interface(s) don’t need a firewall to protect them from the world.

To be blunt: I would be comfortable running a server with no firewall. fail2ban (or others tools of that sort) make it worthwhile to have the firewall, but if you’re manually editing a bunch of rules, you’re wasting time on stuff you shouldn’t be. There are more urgent security concerns than blocking a port that doesn’t even have anything on it.

Anyway, I have no idea what your OS package sets up in terms of zones and such. Webmin should show it correctly, and allow editing all the zones and such, and if it doesn’t it’s a bug. But, I don’t use firewalld in any way that would need anything more than allowing services and ports, and I don’t think most Virtualmin users should either.

1 Like

A true firewall appliance AHEAD of the server is the best option. Fighting a DDOS attack at the server level means you’ve lost already. The resources are being consumed.

The local firewall is more a safe guard against accidentally having things like your printer available from the outside due to sloppy practices. Maybe not yours, but the package maintainers trying to make sure they aren’t getting bugged by people who can’t get something to work.

So the short? Open the ports you want in the firewall and be done. Command line Linux firewall manipulation brings me to tears. Even the least knowledgeable package maintainer still knows 10X what I do.

Thanks for the details.

I don’t even think that’s all that useful in the majority of cases, it’s just another point of failure. Sure, DDoS is a potential problem that a local firewall may not be able to solve, but a separate firewall won’t stop it any better than a firewall on the device, unless the separate firewall is attached to a monster network connection and a massive database of information about current threats. This is why Cloudflare and Google and Amazon, etc. can offer DDoS protection that actually works quite well in the majority of cases (and it’s the one case I think Cloudflare is worthwhile, if you’re running the kind of site that gets DDoSed more than never).

So, a firewall, on the same box or separate, remains mostly useless, except as part of some dynamic thing that knows how to address a DDoS (which requires active management of the firewall or proxy rules or whatever is regulating traffic).

I run pfSense before my web server and it uses live blocklists for various threats. It uses a wide range of security feeds to form its blocklists and is updated between 1hour and 1day depending on the list. I did have SNORT running but I am not `100% how to get the best out of it.

SNORT is an intrusion detection system. It sniffs all network traffic for signs of malicious activity. Usually put on a promiscuous switch port so that it sees all traffic transversing the switch.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.