Had Proxmox already had a zero day vulnerability?
- Thread starter mfgamma
- Start date
The basic principle is that a hypervisor has no place on the Internet. The HV itself belongs in an internal network and needs to be secured. Proxmox VE is ultimately based on Debian, so PVE itself also has corresponding gaps. A firewall can also have gaps, so if you're concerned about security, it's better to use two different ones in a row. Otherwise, one or simply a VPN is enough to manage the node.
by virtue of being a Linux-based software alone, yes. but like sb-jw said, for production setups you want to reduce the parts you expose to the public net as much as possible anyway. the management interface of the hypervisor should not be exposed (can be achieved with a firewall in front or not, that's an implementation detail).
Depends entirely in how far you'd trust pfsense/opnsense. This week I finally had time to dive into the OPNSense Suricate service crashing issue. This issue is poorly documented or I missed out on where it is documented. Now I do have a bit more trust in OPNSense.
Obviously chances an freemium product will effectively protect against unknown vulnerability is quite low. Snort/Suricata ruleset to have a reputation for occassionally providing such protection. At least that was so in the days technical people were in charge, now i don't trust it as much.
When using Proxmox+OPNSense there is need to implement both properly to have an as secure as possible environment if that's what you desire. Also consider to take into account any switches, routers, firewalls etc in between the internet and the proxmox+opnsense setup.
In all, the combo works quite well. Once you get some quirks ironed out.
check this page https://forum.proxmox.com/threads/how-to-fix-opnsense-with-suricata-ips-service-failures.139828/ for a review on how to get Suricata to stay up in a Proxmox hosted OPNSense (same for pfSense it seems)
Last edited:
Hi JL
thanks for these info
so my conclusion is that we will put at least a dedicated firewall as front end, hoping that the proxmox firewall will not have the same zero day vulnerabilities as the front end firewall opnsense
@mfgamma not sure what you mean with that.
In terms of attack surface OPNsense inside or outside of Proxmox is not so much different.
To make the picture more complete.
Know it is possible yet of low likelihood a vulnerability will exist in both Linux and BSD.
Of the top of my head I only know of an IP stack vulnerability existing for both Linux and BSD.
Obviously, services can run on both Linux and BSD and be equally or differently vulnerable.
Should an attack happen against Proxmox (Linux) and this is also targeting OPNsense (FreeBSD) there are just 4 contexts and 3 attack paths.
This with 4 attack surfaces: Network, Proxmox, OPNsense, physical/virtual hosts.
I'm not going into detail here but I try to be somewhat complete, this is for informative purposes only and a sketch more than tutorial.
Evaluating the likelihood for these attacks.
What I'm trying to say is you should think about the network and the network infrastructure (including Proxmox) as a whole with parts,
not as parts by themselves.
Take measures accordingly.
In terms of attack surface OPNsense inside or outside of Proxmox is not so much different.
To make the picture more complete.
Know it is possible yet of low likelihood a vulnerability will exist in both Linux and BSD.
Of the top of my head I only know of an IP stack vulnerability existing for both Linux and BSD.
Obviously, services can run on both Linux and BSD and be equally or differently vulnerable.
Should an attack happen against Proxmox (Linux) and this is also targeting OPNsense (FreeBSD) there are just 4 contexts and 3 attack paths.
This with 4 attack surfaces: Network, Proxmox, OPNsense, physical/virtual hosts.
I'm not going into detail here but I try to be somewhat complete, this is for informative purposes only and a sketch more than tutorial.
- Proxmox is exposed+compromised, the attacker now has full access and a majority of access and control. Very very bad, direct results.
- OPNsense is exposed+compromised, the attacker can mess with traffic, capture traffic, maybe steal password hashes. Very bad. Slow results.
- the VM integrity and isolation is compromised and the attacker just broke out of the VM into Proxmox. Game over, direct results.
- network>proxmox>opnsense ............. > hosts ? networks ?
- network>opnsense>proxmox ............. > hosts ? networks ?
- network>proxmox-VM>proxmox ....... > hosts ? networks ?
- Proxmox is attacked and OPNsense is the target. Seems unlikely. Anyone who can break into Proxmox now has far more access.
- OPNsense is attacked and Proxmox is the target. Seems unlikely anyone would 'just know' where to target a properly implemented firewall.
- A host in the network is attacked passing through OPNsense running dedicated and/or in Proxmox as a VM. Most likely again the feasibility greatly depends on the implementation of OPNsense and Proxmox and how both are implemented in the LAN.
- A virtual machine is attacked by the user and so doing the attacker has visibility on OPNsense/Proxmox services or has a vulnerability to use to escape the virtual machine. The VM escape is a game-over scenario. Congratulations, you must be a very valuable organisation or individual. Highly unlikely random civilians and civilian organisation are target because VM escape exploits are very desirable, therefor expensive.
- Attacking Proxmox is either through ssh, webui, VM escape. Both SSH and WebUI vulnerabilities are high priority risks to consider.
- Attacking OPNsense is either trough ssh, webui, service vulnerabilities. These are all plausible points of attack.
- Attacking from a VM, this bypasses any network defenses put in place for both Proxmox and OPNsense.
What I'm trying to say is you should think about the network and the network infrastructure (including Proxmox) as a whole with parts,
not as parts by themselves.
Take measures accordingly.
Last edited: