POLL: Current Firewall Design, what is your ...

[egberts]

This is a POLL thread in an attempt on covering all the models of firewall and Proxmox to help us better guage the future direction which we all collectively think that Proxmox should be supporting.

Assumption must be made here for brevity of your reply: you make uses of Debian 10.6 and Proxmox 6.4+. No need to indicate either Linux 4.x or 5.x (we know that bridge connection tracking got support (finally) in Linux 5.4.2).

In your reply, please indicate which approach(es) that your Proxmox setup is using as well as listing any secondary feature that you also use .

Approaches​

• Use Proxmox firewall entirely
  • CLI - pve-firewall
  • PVE GUI Firewall
• Use Linux firewall entirely
  • iptables in raw format
    • apf-firewall (last update 2019, link)
    • ferm (current, link)
    • firehol (current, link)
    • ufw (2018, link)
  • iptables-legacy after installing nftables (you can check if your ls -l /etc/alternatives/iptables is linked to iptables-legacy)
  • nft(default IP filter toolset)
    • conntrack - connection tracking (current, C, link)
    • nftlb - load-balancer (current, C, link)
    • sshguard (current, C, link)
    • freedombox (home setup, Python3, link)
    • lxc - Linux containers user tools (current, C, link)
  • all Linux firewall types (iptables, iptables-legacy, nft)
    • shorewall (CLI, Perl)
    • firewalld (GUI/CLI, Python3)
    • fwbuilder (GUI, C, KDE/X11)
• Mixing Proxmox and Linux firewall rules (list two or more of above options)

Secondary Supports​

Analyzers​

These passive (listening-only) analyzers also requires firewall settings that allows packets to be cloned (via tap interface) or redirected to by-process (PID-based) to support the following feature sets:

• port scanning detection (portsentry, psad)
• intrusion detection/prevention system (IDS/IPS), (snort, suricata, Bro)
• authentication attempts/failures (fail2ban)

DBus​

Often times, there will be a temporary or dynamic network device(s) coming into play and this is where D-Bus comes in and assist. Such network device would be WiFi, Ethernet-USB, proxy-port, or CAN-BUS. Some firewall tools that support D-Bus can only be used with iptables (and not nft) such as firewalld. This D-Bus approach is often not a desirable feature to have from a security vantage POV, because too many applications have access to D-Bus and today's ACLs for D-Bus access are poorly defined.

DDoS​

Flooding of packets (a form of distributed denial-of-servce) often requires some control feedback mechanism at firewall level into dynamically updating its ruleset that addresses such issue(s) and often for a temporary duration. fail2ban is one such package.

portknockers​

Simple portknocker would respond to packets arriving toward an hard-coded sequence of port numbers. Advanced portknockers now have custom port-number selector algorithms based on NTP-supplied time. fwknop-client,

 

[egberts]

I use strictly all nftables/nft settings (no pve-firewall).

Custom port-scanning detector, custom portknockers, custom DDoS mitigation. No D-Bus.

snort, bro, suricata on tap.

However, in interest of seeing where this pve-firewall is going, my .nft firewall text configuration files also uses the same table names and chain names created and used by Proxmox pve-firewall.

 

[j.io]

OK, so I am a non-professional, to be clear upfront.

I use dedicated firewall appliances (currently OPNsense), running dynamically updated IP + DNS blocklists, (soon) proxy filtering and IDS / IPS (Suricata) on top. I am diving into logging etc. currently, so I am not an expert here.

I am very well aware of the concepts of firewall rules, but I did not easily understand the way that Proxmox handles the rules. There are rules on datacenter, machine (?) and VM level. This is fine, but given that I have this setup on top, I just did not take the time to dive into Proxmox' firewall concept.

HOWEVER: I think it is very helpful to additional harden the rules from the client (= Proxmox) perspective, even if there is a dedicated firewall appliance on top. Often, at least for home-use, you only require a HTTPS port, or maybe a handful of other ports for some services. I bet the Proxmox firewall could do all this iptables stuff already, but I find the UI and user guidance a bit clumsy in the current implementation. It feels like this is not on the top priority list of the developers and kind of a "hey, yes, it can do that, but actually, it's not the product's scope"-feature.

To be easily applicable, I think there's definitely optimisation potential.

@egberts Nice compiled list btw!

 

[fsoy]

Hi guys,
searching how to harden Proxmox nodes, I wonder if my need can be considered as a 'model of firewall' here
Unlike j.io, I don't use a firewall on top of the cluster, but into it : this is a (2 in fact, in cluster) VM with PFSense, connected for WAN to the public interface of the nodes, and for LAN to the private interface (dedicated private LAN between nodes). Then, all VMS have only one interface on private LAN with a gateway to PFsense LAN side, and are protected by PFSense firewall VM.
I use some specific functions on PFSense (for example : Proxy ARP, PFblocker, Snort...) that I suppose are not available on pve-firewall.

So, my problem is to :
- protect the Proxmox node which are not behind a firewall
- not block nor restrict access all to the VM, especially the firewall VM(s), to avoid having to manage 2 firewalls rules each time I want to open a simple port to a VM !

Am I clear enough ? Is there a way to protect only nodes with pve-firewall without blocking anything to the VMs ?

 

[j.io]

The easiest, if you have dedicated NICs, is to go for a physically separated "Management LAN", which handles all the HTTPS connections on port :8006. This dedicated LAN can be used to separate traffic completely and thus makes it easy to manage firewall rules.

With regard to your second question: I am not sure about PFsense, but OPNsense has the HA feature, which kind of "syncs" multiple OPNsense appliances with regard to their settings. If you setup a smart network infrastructure without overlaps, this could be one possible route to take.

 

[fsoy]

Sorry I'm not sure to understand how a physically separated Management LAN can help me here ?
About PFSense, I confirm that it is already a cluster of 2 PFsense, each VM on one separate node and sync together. My second question was, if I use this PFSense VMs as firewall for all other VM, how to protect only the nodes that are exposed to internet on their public interface ?

 

[j.io]

Sorry I'm not sure to understand how a physically separated Management LAN can help me here ?
About PFSense, I confirm that it is already a cluster of 2 PFsense, each VM on one separate node and sync together. My second question was, if I use this PFSense VMs as firewall for all other VM, how to protect only the nodes that are exposed to internet on their public interface ?

Best would be to upload a drawing of your setup and networks to understand and help you better. Still don't know if I got everything right, but why don't you use VLANs and Virtual IPs?

It's difficult and too time consuming to discuss this on a generic level. Please provide some concrete information.

 

[spirit]

I'm running full pve-firewall for 4000 vms with about 100 hypervisors + suricata running on each host + anti-ddos at my provider side . No nat, public ips inside the vms.

I was running previously central expensive palo-alto firewall, with a lot of performance problems. No more problem since I'm distributing firewalling at the hypervisor side.


about nftables in pve-firewall, I don't known if it's already on the roadmap, but it should be possible to implement now that bridge conntrack has been added in recent kernel.

 

[fsoy]

Best would be to upload a drawing of your setup and networks to understand and help you better. Still don't know if I got everything right, but why don't you use VLANs and Virtual IPs?

It's difficult and too time consuming to discuss this on a generic level. Please provide some concrete information.

Here is the best I could do try to illustrate the problem. Which is, for recall : VMs are protected, how to protect WAN interface of nodes ?

 

[fsoy]

I'm running full pve-firewall for 4000 vms with about 100 hypervisors + suricata running on each host + anti-ddos at my provider side . No nat, public ips inside the vms.

I was running previously central expensive palo-alto firewall, with a lot of performance problems. No more problem since I'm distributing firewalling at the hypervisor side.

I see, it's another way to do it... But not the one we've chosen

 

[fsoy]

UP ?

 

[fsoy]

UP UP ?

 

[tom]

UP UP ?

Please stop doing posts without any content.