Proxmox VE Host OS Protection – Cortex XDR Agent Compatibility and Recommendations

[Rajan_Kumar.Jaiswal@sita.]

Hi,

We are evaluating security measures to protect the Proxmox VE host operating system in our infrastructure and would like to clarify the recommended approach for OS-level security and endpoint protection.

We would appreciate your guidance on the following questions:

1. Proxmox VE Host OS Protection

• What are the recommended security practices to protect the Proxmox VE host operating system?
• What security tools or endpoint protection solutions are recommended for Proxmox hosts?
• Are there any specific considerations when installing security agents on the Proxmox host?

2. Cortex XDR Agent Compatibility

• Can we install the Palo Alto Networks Cortex XDR Linux agent directly on the Proxmox VE host?
• Is the Cortex XDR agent officially supported on Proxmox VE and its underlying Debian-based OS?
• Are there any known compatibility issues with the Proxmox kernel, KVM, LXC, ZFS, or other virtualization components?
• Could installing the agent impact VM performance, host stability, or Proxmox cluster operations?
• If direct installation is not recommended, what alternative approach would you suggest for protecting Proxmox hosts?

Our objective is to implement OS-level endpoint protection without impacting Proxmox VE functionality, performance, or stability.

Any recommendations or official documentation would be appreciated.

 

[gasherbrum]

you typically do not install ANY AV/EDR on a hypervisor, regardless of vendor. you risk stability installing this type of agent. monitor logs using a SIEM, use 2fa, use a restricted network

 

[Johannes S]

I wouldn't do this since it might led to issues where you won't get support due to section 2 of the subscription conditions:

"2 Scope of Coverage
A Proxmox VE Subscription includes the following:
• Access to the Proxmox VE Enterprise Repository
• Installation support
• Usage
• Configuration
• Diagnosis
• Bug reports and fixes for packages in the Proxmox VE repository, including Ceph packages
Technical support only covers the latest stable release.
What is not included: We do not support modified packages, third party software, community projects
upon which our releases are based on, code development, system and network design, designing security
rules, backup/recovery strategies, data recovery and high availability design.
Technology previews are not supported in production environments." https://www.proxmox.com/en/download.../agreements/proxmox-ve-subscription-agreement

As explained in an bugzilla ticket (
https://bugzilla.proxmox.com/show_bug.cgi?id=7035 ) the part about third party software etc also covers CortexXDR and other antivirus/endpoint protection products and is true for all Proxmox products ( so also DatacenterManager, Backupserver, MailGateway etc)

So I would concentrate on hardening your ProxmoxVE hosts instead.

 

[UriShay-CyberSnap]

Agree with gasherbrum and Johannes, keep the EDR agent off the PVE nodes. Apart from the support question, anything that hooks the kernel on a box running KVM, ZFS and corosync is one more thing that can hang a node or fence it at a bad moment.

What tends to work better is treating the nodes like appliances. Nothing extra installed, the management interface on its own VLAN that you can only reach from a jump host, named accounts with TOTP or WebAuthn instead of everyone using root@pam, and API tokens scoped to what each tool actually needs. Then send journald and the PVE task log to your SIEM so you see logins, token use, config changes and things like a backup job being deleted or retention being cut. Run Cortex XDR inside the guests, that's where it's supported and where it actually sees the processes.

Also keep PBS out of the same blast radius. Its own credentials, not tied to the directory your PVE admins log in with, and ideally a second PBS that pulls from the first, so one stolen admin login can't wipe every copy.

One thing that gets missed: PBS verify jobs tell you the chunks are intact, not whether the data inside was already encrypted when the backup ran. If you ever have to pick which backup to bring VMs back from after an incident, look at the contents across a few dates first (file churn, renamed extensions, ransom notes in shares).

(I'm the founder of CyberSnap, which looks at existing snapshots for signs of encryption and file tampering.)