[pve-firewall] Is it to be taken seriously? Off until after network has been up ...

[esi_y]

Just started experimenting with what the firewall PVE provides, but before even getting to anything netfilter related...

I get several pings through during bootup of a machine at 2 different points.

A quick look at network-pre.target does NOT declare After=pve-firewall.service.

A look at pve-firewall.service does NOT declare Before=network-pre.target, only pve-guests.service.

What it does declare is After=pve-cluster.service (amongst others, such as network.target).

So this firewall does NOT RUN at boot for the host itself because it needs ... network to load its rules?

So during e.g. auto-reboots on node fencing, it is invariably exposed receiving all the traffic unfiltered.

And if the pve-cluster.service does not come up, the firewall never loads its rules with neatly logged Failed to start Proxmox VE firewall. But the networking is up.

How is this useful?

 

[dietmar]

All Proxmox VE related services depend on pve-cluster, so there is no single pve service, VM or Container running
unless that is up.

 

[esi_y]

All Proxmox VE related services depend on pve-cluster, so there is no single pve service, VM or Container running
unless that is up.

Thank you for your reply.

I understand that, it's why I mentioned it too, but if the host itself has any (non-PVE) service that has a vulnerability (e.g. SSH had zero days recently), it's going to be left sitting there in the open.

I believe it is quite possible to e.g.:

1) Load the rules locally (could be distributed corosync.conf style, not require /etc/pve mounted), then network-pre.target could be After=pve-firewall.service - this is the case e.g. even with stock ufw;

or at the least:

2) Load single DROP everything but local subnet rule prior network is up, only then proceed with network.

A proper firewall appliance would start booting with e.g. DROP everything rule then append custom rules to netfilter (NOT flush) and then remove the original rule for this very reason.

It is not something expected of a firewall and it is not documented.

 

[esi_y]

I just want to point out that I got to this stage to test the new nftables (was not interested in the old version), but the implementation is exactly the same. It is not firewall-related strictly speaking, it is a however wrong design choice for firewall (out of all things).

I went to check BZ and found total 124 entries (bugs + feature requests), it is quite rich, i.e. it appears lots of people depend on this firewall's capabilities and not just for intra-guests.

Amongst postponed/undecided/new I cannot see a single item about firewall not being up during boot-up (and until after /etc/pve is mounted) even as network is up.

I do not see value in having a HOST zone if the host is potentially not protected. Also, as the host zone is set individually for each host, it is quite reasonable to expect those rules are ALWAYS loaded and not depend on cluster except when network is down.

Consider root in stock configuration is password (un)protected and available as such via SSH and stock install leaves you with primary network interface bridged for the guests as well.

 

[esi_y]

Filed: https://bugzilla.proxmox.com/show_bug.cgi?id=5759

 

[LnxBil]

Filed: https://bugzilla.proxmox.com/show_bug.cgi?id=5759

Why don't you start with that instead of writing another thread where you're the main contributor?

 

[esi_y]

Why don't you start with that instead of writing another thread where you're the main contributor?

You will be less likely to see it there, i.e. in this case will be later warned about the issue. Lots of times there's no reply from anyone on BZ (no reply = not even POSTPONED/WONTFIX) for a long period. Also, Proxmox does not e.g. issue security bulletin when issue like this shows up on BZ.

I do not think it matters as much if you consider this an issue too, or a minor one, or not at all. What mattes is that you know about this. Now you do.

After I post here, others may comment (including you) why the e.g. do not consider it an issue themselves, possible workarounds, at times someone in the forum points me to existing BZ so I spare staff to mark DUPLICATES.

Once in BZ, I keep the "contributions" of mine there.

(All of my BZ items start in the forum, you suscribed to at least some of them if I remember well.)

 

[LnxBil]

Thanks your for the explanation. Makes sense.

 

[esi_y]

(All of my BZ items start in the forum, you suscribed to at least some of them if I remember well.)

Just a minor note, of course if I thought I found something not obvious already (to a potentiall attacker) in regards to security, I would send direct email first. This is not on that level, but I think it's an issue that can be resolved easily actually (opportunity is for the nftables proxmox-firewall especially).

 

[esi_y]

So, @LnxBil, one of the reasons I prefer to post about BUGS here is that even when it's filed and acknowledged in BZ, it does not go into DOCUMENTATION for anyone to see, even week after, even in case of FIREWALL:

https://bugzilla.proxmox.com/show_bug.cgi?id=5759

 

[esi_y]

Additional issues with pve-firewall:

https://forum.proxmox.com/threads/proxmox-firewall-not-working-status-update-error.155905/
https://forum.proxmox.com/threads/firewall-issues-in-8-2-7.155707/

 

[LnxBil]

Additional issues with pve-firewall:

https://forum.proxmox.com/threads/proxmox-firewall-not-working-status-update-error.155905/
https://forum.proxmox.com/threads/firewall-issues-in-8-2-7.155707/

Thank you for bringing this to my attention. I also experienced strange behaviour after updating to PVE 8, yet did not jump beyond the first two levels of the rabbit hole and did not find an answer besides disabling the firewall.

 

[esi_y]

Thank you for bringing this to my attention. I also experienced strange behaviour after updating to PVE 8, yet did not jump beyond the first two levels of the rabbit hole and did not find an answer besides disabling the firewall.

It's just that I wish these issues were brought up quickly into some sort of advisory that bumps up in the PVE itself. There's nothing wrong with going after bugs, I have issue with not warning everyone about these kinds of bugs.

NB I am not saying everything is caused by what I originally reported, but for me the principle of a firewall failure must always be ... if it cannot load the full proper ruleset, it must be stuck on DROP all, if it cannot even start, it must stop the dependent services to start as well, better yet, stop networking from going online even.