Why are we offering such White-Paper

We strongly believe in the virtues of shared knowledge. This is the reason why we are providing this study free of charge to everyone willing to use it in a non-commercial way.
Our engineering team is involved since twenty years in the development, setup, deployment and maintenance of critical Cloud Infrastrucutres entirely based on Open Source softwares. We have developed a very specific knowledge in this area and we believe that sharing part of this knowledge will help enhance the security of infrastructure following the same approach.

Please do get in touch with us if you need some consulting services, or network design and architecture for the deployment of your CEPH or ZFS clusters based on Proxmox!

This study has 46 security points, 15 pages, only 10 pointsd are displayed below. To download the complete study in PDF, simply fill the form below.

Cybersecurity of the Proxmox system

Proxmox is a virtualization system which integrates the Virtual Machine (VM) KVM management system and the Container (CT) LXC system. In addition to these basic building blocks, Proxmox allows the deployment of Virtual Machines and Containers on multiple File System environments (EXT4, ZFS, CEPH) but also on network based systems (NFS, iSCSI) for example.
The remarkable integration between these different systems makes Proxmox the most popular Open Source "Hypervisor" on the market. Its performance is so remarkable that Proxmox now competes with VMWare, not only in terms of price (as you might have expected), but also in terms of reliability, performances and ease of maintenance of the solution.
The objective of this memo is to understand how to secure Proxmox environments in order to be hardened.
Our work is largely inspired by the document proposed by ANSSI to secure ESXi environments.  

Pooling of resources

As expressed in the ANSSI framework document, VM isolation is one of the main objectives that will ensure a good level of security for hosted VMs.

The first recommendation (R1) will therefore be expressed as :
avoid hosting VM with different security levels within the same hypervisor
avoid exposure of VMs that do not need to be exposed.

Second recommendation (R2) is to restrict the routing and filtering functions between VMs of different sensitivity.
You can translate it as :
limit the attack surface (i.e. the number of services deployed)
isolate logical network levels with separate and unconnected hardware

Maintaining in a secure condition

The third recommendation (R3 and R4) is to subscribe to software vulnerability notification services for your Hypervisor AND its constituent VMs and CTs.

• Care should be taken to purchase a Proxmox VE Enterprise support subscription to ensure that your hypervisor benefits from regular updates.
• We can also plan to deploy on Proxmox a Container dedicated to the deployment of the vuls software.  
• Or more simply use the debsecan package

The drivers for your hardware must be duly identified and downloaded only from the manufacturer's sites (R5).
Hardware drivers (BIOS) for hosting platforms are rarely OpenSource. However, when powerful drivers exist in Open Source to replace the manufacturers' BIOSes, we recommend that you use them.
In fact, OpenSource BIOSes are very few in number and support very little hardware, especially on server motherboards.
Using Open Source software has a significant advantage, because although hardware manufacturers can be trusted, experience in recent years has shown that doubt is better than absolute trust.
In any case, and in the absence of a viable alternative, it is imperative to regularly update your BIOS to ensure that your hypervisors do not contain software with identified security vulnerabilities (CVS).

Item R6 is specific to VMWare and signature of binaries distributed as part of updates.
For this issue, we recommend that you subscribe to the Proxmox Enterprise Subscription Service to have access to signed binaries from their enterprise directory.

Point R7 is to make sure that Kernel modules originate 100% from identified sources.
As in point R6, we recommend that you subscribe to Proxmox "Enterprise" services to ensure you have a secure and up-to-date Linux kernel.
A strong point of Proxmox compared to VCenter is that Proxmox updates, even on major versions, are going very well. The update steps are detailed by Proxmox teams and can be found here :

• https://pve.proxmox.com/wiki/Upgrade_from_2.3_to_3.0
• https://pve.proxmox.com/wiki/Upgrade_from_3.x_to_4.0
• https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0

At this point if the first two links are relevant to you: it's because you haven't read our recommendations properly, it's high time to take matters into your own hands!
Normally you should already be at version 6 of Proxmox.

Point R8 can be interpreted as the need to use sudo in order to limit access to the root account, while still being able to conduct the necessary update operations for your system.

R9 is a critical point and the Proxmox policy does not allow copying their APT directory for offline updates in order to synchronize your VMs on it.
A possible partial solution is to use a Proxy server to ensure that only one server has access to the Internet. For the projects that would be carried by Highly Critical Enterprises, it is possible to negotiate specific licenses that allow offline access to Proxmox resources, please contact us about this.

If you want to download the complete study, simply fill the form below :