Is It Best Practice To Use Proxmox Firewall or Firewall In VM?

M

mhayhurst

Renowned Member
Jul 21, 2016
111
7
83
43
Hello everyone,

Just curious what others are doing, but is it best to use Proxmox's firewall that is available in the webgui for each VM or use the VM's firewall available within the OS (e.g. ufw, firewalld, etc...)? I'm on Proxmox 5.2-2 and most of my VM's are a Linux distro (Ubuntu, CentOS, FreeBSD) with the exception of one Windows VM if that makes a difference.
 
  • Like
Reactions: Ciprian Tomoiaga
Depends on what you want. If you compare stateful packet firewall's, i'd go with PVEs choice. If you need application level firewalling, do it on the guest.

The Proxmox VE firewall is very capable of securing your machine and cannot be influenced by a faulty VM firewall. I'd recommend to create security groups e.g. for virtual-DMZ etc. and use them to secure your machines. This is very easy and is working for any kind of guest OS.
 
  • Like
Reactions: Knight
LnxBil said:
Depends on what you want. If you compare stateful packet firewall's, i'd go with PVEs choice. If you need application level firewalling, do it on the guest.

The Proxmox VE firewall is very capable of securing your machine and cannot be influenced by a faulty VM firewall. I'd recommend to create security groups e.g. for virtual-DMZ etc. and use them to secure your machines. This is very easy and is working for any kind of guest OS.
Click to expand...

I want to keep devices on my LAN from accessing certain things like MySQL, Redis, etc... which have open ports but I will also have a few VM's (such as ownCloud) that will be using one of my static IP's with a direct connection to my WAN through a Linux Bridge (no LAN). I like that PVE's firewall is easily accessible from the webgui and more or less provides a central point to make changes on my VMs. You think what I'm trying to accomplish would be a good candidate for PVE's firewall?
 
I already said that I like the PVE integrated firewall and their ability to define and use security groups. You can create perfectly firewalled systems which allow only what you really want including disallowing outgoing connections. I recommend to use always REJECT (INPUT/OUTPUT) and only allow what you really, really need. I have a "catch-all" dmz group that I always put in the last spot that allows outgoing DNS to the servers only, incoming and outgoing ping (often used as simple uptime-check by most programs), linux packages mirror. Further, I have a security group for a webserver with only incoming http and https.
 
My PVE box is connected to my pfSense box, so I have not tried to make use of the internal PVE firewall. I have been noticing that the console to my VM as well as ssh login constantly drops on a regular basis. Sometime, trying to ssh into the VM, I don't even get a login before it times out. Could that be an issue with me not setting up the PVE firewall or it something going on with my networK? The VM is being bridged to my network so not doing any NAT or anything of that nature.
 
Without setting up the firewall, everything is accepted (so no rules are enabled). Could be network related, but in general not pve-firewall related if disabled.
 
  • Like
Reactions: kcallis
LnxBil said:
I already said that I like the PVE integrated firewall and their ability to define and use security groups. You can create perfectly firewalled systems which allow only what you really want including disallowing outgoing connections. I recommend to use always REJECT (INPUT/OUTPUT) and only allow what you really, really need. I have a "catch-all" dmz group that I always put in the last spot that allows outgoing DNS to the servers only, incoming and outgoing ping (often used as simple uptime-check by most programs), linux packages mirror. Further, I have a security group for a webserver with only incoming http and https.
Click to expand...

Thank you for sharing!
 
LnxBil said:
...I recommend to use always REJECT (INPUT/OUTPUT) and only allow what you really, really need...
Click to expand...
If you know the difference between "REJECT" and "DROP", then you also know why using "REJECT" is bad idea...
 
Rhinox said:
Do you realise your system could be tricked by botnet to be part of drdos, sending icmp-packets (as part of your REJECT policy) to innocent victim?
Click to expand...

This is also true for any spoofed packets that reach your system and you reply (ordinary icmp ping, webserver etc.), isn't it?
 
True, but only if those packets come to a few opened ports. I think the more I reduce this chance, the better...

Moreover, I do not use icmp at all (very unsecure protocol) and udp is strictly limited to dn-replies only for my clients. Then it is much easier to deal with tcp (i.e. for web), because if source-ip (be it true or spoofed) does not answer to syn-ack reply from my server in proper manner, it gets banned (again, with "reject"). So victim can get only single packet from me...

If you think all this is not your problem, maybe you could consider costs: every packet that goes through network-stack needs some resources (cpu, ram, bandwidth). I personally do not want to spend more resources on malformed traffic than absolutely necessary. And there are many more good reasons not to use "reject"...
 
Rhinox said:
True, but only if those packets come to a few opened ports. I think the more I reduce this chance, the better...
Click to expand...

That is right.

Rhinox said:
because if source-ip (be it true or spoofed) does not answer to syn-ack reply from my server in proper manner, it gets banned (again, with "reject"). So victim can get only single packet from me...
Click to expand...

how do you do that?

My main problem with DROP is that I often run into problems with guest OSs that e.g. yum update with DROP in place takes forever (waiting for timeout and process is in uninterruptible state) if you're not allowed to connect to the destination. Same for DNS. How do you deal with such situations?
 
As with everything, you can achieve it in many ways. For example I'm checking my firewall logs with fail2ban and if it finds pre-defined patterns, it takes care of banning IP with invalid traffic. In case of unfinished 3way handshake there is "connection died" or something like that (don't remember, and I do not have remote access to my server righ now). There are many tweaks I included, i.e. using synproxy target, filtering in mangle/prerouting instead of input/filter to speed things up and save resources, rules against port-scanning, against common attacks, rules for port-knocking, using sets, time-dependent rules, dynamic parameters, etc, etc. You can find many tricks for iptables on the net. And upcomming nftables are imho even better!

In case something does not work, you can always use LOG before DROP (using -limit/-limit-burst with LOG is obligatory, otherwise you might ddos yourself) and check the problem in server-logs, instead of client. With properly configured iptables you can filter full 1gbit without even using all cpu/ram. With improperly configured iptables even 100mbit packet flow can bring it to knees...
 
@mhayhurst I noticed you said you want your owncloud to directly connect to the internet with a static IP. I assume you mean a WAN IP no NAT. I would highly recommend against this. You don't want to connect your host or guests directly to the Internet.

You could put your VMs like owncloud in a separate VLAN and setup your main router (hopefully something that can handle VLANs like pfSense) to send that directly to the Internet and block access from your home subnets. Basically you would be using a VLAN to create a DMZ. If you have Static WAN IPs for each VM you could use 1:1 NAT or if not you could just forward the ports from your main router.

If you don't have a router that can handle VLANs or you truely want to plug your host directly into the internet then I would recommend setting up pfSense in a VM and just putting the internet facing VMs connecting via a bridge to the pfSense virtual router. You could also route your other VMs to your LAN with the same pfSense VM just on a different pfSense interface.

The PVE firewall is excellent but I wouldn't recommend connecting it directly to the internet. PfSense gives you extra protection like snort/suricata IDS, plus nothing else is running on the firewall so it's much simpler and secure.
 
Jay Quin said:
@mhayhurst I noticed you said you want your owncloud to directly connect to the internet with a static IP. I assume you mean a WAN IP no NAT. I would highly recommend against this. You don't want to connect your host or guests directly to the Internet.

You could put your VMs like owncloud in a separate VLAN and setup your main router (hopefully something that can handle VLANs like pfSense) to send that directly to the Internet and block access from your home subnets. Basically you would be using a VLAN to create a DMZ. If you have Static WAN IPs for each VM you could use 1:1 NAT or if not you could just forward the ports from your main router.

If you don't have a router that can handle VLANs or you truely want to plug your host directly into the internet then I would recommend setting up pfSense in a VM and just putting the internet facing VMs connecting via a bridge to the pfSense virtual router. You could also route your other VMs to your LAN with the same pfSense VM just on a different pfSense interface.

The PVE firewall is excellent but I wouldn't recommend connecting it directly to the internet. PfSense gives you extra protection like snort/suricata IDS, plus nothing else is running on the firewall so it's much simpler and secure.
Click to expand...


Thanks for the info! Yes, I already have pfSense running as a Proxmox VM and my switches support VLAN but I was trying to avoid all the hassle configuring and troubleshooting VLANs, 1:1 NAT, interface setup, etc... I would have to read up on all of that, make the changes and as we all know nothing ever goes as planned. I opened ports: 22, 80 (for Apache redirection) and 443 to the ownCloud VM which is configured to be the only VM on one of my Linux Bridge's (vmbr1) in Proxmox. Also, that bridge is the only bridge attached to a dedicated NIC port connected to my AT&T modem where I assigned the static IP. The VM appears to be isolated both physically and virtually so I'm confused on how this is not adequate versus pfSense? Could you provide an example of a vulnerability that I'm currently susceptible too versus if I setup pfSense your suggested way I wouldn't be susceptible too?
 
Last edited:
It's your choice but I would never put any device directly connected to the internet without some type of firewall like pfSense in front of it. If the VM is that isolated you are probably safe enough that nothing else on your network will be hacked, but I guarantee eventually that box will get hacked. All it takes is one vulnerability that you haven't patched yet or one simple misconfiguration and that VM is owned. A firewall like pfSense is specifcally designed to be simple and secure. No software like a webserver running on it so it's a lot harder to break into. Yes if the webserver was behind a firewall it could still be hacked but I believe it would be a lot safer.
If you want the simplest solution then setup a VM with pfSense on the same bridge ownclouds on. Then create a new bridge specifically to connect the LAN port on pfSense to the owncloud server so it was still isolated. You could turn off NAT and only forward the ports you need to the webserver. You could also use pfBlockerNG on pfSense to block lists of known malicious IP addresses and run snort to watch for hacks. Another benefit of a dedicated firewall. If you only connect from your own country to the webserver when not home then you could also use pfBlockerNG's GeoIP to only allow your country's IP addresses through. This one change would block like 80% of those trying to break in. If the server is only fo you and your family you could also put it behind a VPN server. There are large botnets of like 100,000 PCs that just try every possible combination of userid and password forever on open servers on the net.
It's your decision. At the very least keep very good backups of the owncloud VM and your data it connects to and keep an eye on that server. You will probably want to install a host IDS on the VM even something as simple as Logwatch that will alert you if something unusual shows up in your logs. FAIL2BAN is also another great idea. It automatically blocks IP addresses for short periods after a specific number of login failures. It's is VERY useful on a internet facing webserver.
 
Jay Quin said:
If the VM is that isolated you are probably safe enough that nothing else on your network will be hacked, but I guarantee eventually that box will get hacked. All it takes is one vulnerability that you haven't patched yet or one simple misconfiguration and that VM is owned. A firewall like pfSense is specifcally designed to be simple and secure. No software like a webserver running on it so it's a lot harder to break into.
Click to expand...

- If you're saying it just takes one vulnerability that I haven't patched or a simple misconfiguration on the VM then how would pfSense's firewall make any difference at that point? After all, at that point I have opened up the necessary ports on pfSense's firewall so any vulnerability on the VM falls back on the VM and not pfSense's firewall. Also, pfSense does run a web server, that's how the web-gui works...I believe it's NGINX...just FYI.

Jay Quin said:
Yes if the webserver was behind a firewall it could still be hacked but I believe it would be a lot safer.
Click to expand...

- I would have to open all the ports on pfSense's firewall that I currently have open on Proxmox's firewall. So how would using pfSense's firewall make me less vulnerable? Are you saying pfSense can somehow block ports better than Proxmox's firewall? Or am I missing something?

I understand that pfSense has extra features but are you saying if those features are not implemented then you are absolutely guaranteed to get hacked? I was using OpenVPN on pfSense to access my ownCloud VM but every time I want to access a file on ownCloud I must first start the OpenVPN on my device or when I take a picture on my phone and forget to start my OpenVPN then the picture does not upload to ownCloud. It was a pain to remember to start openVPN each time.

Jay Quin said:
FAIL2BAN is also another great idea. It automatically blocks IP addresses for short periods after a specific number of login failures. It's is VERY useful on a internet facing webserver.
Click to expand...

- Yes, I have Fail2ban running on the ownCloud VM as well. I've seen the logs and the massive amount of failed SSH attempts by the world's bots...surprisingly I have not seen any failed attempts on the ownCloud login page but that could change in the future.

I'm not opposed to using pfSense and the suggestions you made, I'm just trying to keep things simple, effective and secure for the time being. Configuring, vlans, virtual IP's, 1:1 NAT, new interfaces, firewall, etc... is definitely adding more complexity but is there really any advantage or is it just sentiment to a certain way and/or program? At this point the only advantages I see are the abilities to use Snort and pfBlockerNG within pfSense which IMO are optional and just add additional layers of security but are not a frontline of defense.
 
Don't be fulish... any super-mega firewall will not protect you more if your (buggy)network services are open using a firewall.

Security is not the same thing with a firewall. I use some hosts for many years without ANY firewall without any problems (postfix, dovecot, ssh, bind, and others).

But I use many others security layers who was able to reduce the attack surface. And a good monitoring system/ids/hids is more useful then any ip firewall.
Also a good and wise configuration for any network services could help a lot.

How a firewall could protect me if I use a bad service configuration? Think at a open relay mail server with a root bad password.


Security is not a tool (firewall, ids, antivirus, Admin guy, logs, hw box, whatever), it is a process with unnumbered small details that could make a big difference - my own opinion.

And the last important thing for me, is the fact that your security systemS cold not be better if you do not have hacked. After this firrst bad event, you will learn a lot (if you want) and your systems will be much...much better than before.... and I learn this on my own skin.
 
Last edited:
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back