Captains Log: Sending Proxmox Logs to EDR via Syslog

A Practical Guide for MSP Partners

Modern MSP environments rely heavily on virtualisation platforms. While VMware and Hyper-V have traditionally dominated this space, Proxmox VE has rapidly gained popularity thanks to its flexibility, open architecture, and strong community support.

However, one area that’s often overlooked is security monitoring of the hypervisor itself.

If you're running OpenText Core EDR, integrating your Proxmox hosts into your logging pipeline can provide valuable visibility into the infrastructure layer. This allows your SOC to detect suspicious activity, operational failures, and potential attacks much earlier in the incident lifecycle.

In this guide, we’ll walk through how to configure Proxmox to forward meaningful security events to OpenText Core EDR using Syslog, while keeping noise low and signal high.

The configuration described here is designed to be:

• SOC-friendly
• Easy to deploy across multiple hosts
• Low-noise and operationally safe
• Simple enough for MSP engineers to understand and maintain

Lab Architecture Used in This Guide

If you plan to follow along, the configuration described in this article was tested in the following environment.

Apart from the specific command syntax and configuration file formats, the overall procedure described in this article can be adapted to other Linux systems or Windows-based Syslog relays.

Platform Requirements

Before beginning, ensure the following OpenText Core services are available.

OpenText Core EDR relies on additional platform components for endpoint telemetry collection and log storage.

Your environment must include:

Without Compliance Storage, Syslog ingestion will not be available in the OpenText portal.

Log Sources Used in This Example

In this guide, we configure two infrastructure log sources:

1. Proxmox Hypervisor
   Uses the rsyslog service to forward selected system events.
    
2. UniFi Console
   Uses its native SIEM integration feature to send structured security events.

Both systems transmit Syslog messages containing CEF-formatted payloads to a designated Syslog Forwarder host.

This host is simply a machine running an OpenText Core EDR agent configured to act as a Syslog Forwarder.

The forwarder then sends the logs into OpenText Core EDR for processing and analysis.

Infrastructure Devices      │      │ Syslog (UDP 514 / CEF)      │      ▼ Syslog Relay Server(OpenText Core EDR Agent)      │      │      ▼ OpenText Core EDR(SIEM, SOC, Alerting, Threat Analysis, Workflows and Remediation)

Why Monitor the Hypervisor?

The hypervisor is often the control plane of the entire virtual infrastructure. It hosts domain controllers, application servers, backups, and business-critical workloads.

If an attacker gains administrative access to a hypervisor, they may be able to:

• Stop or manipulate virtual machines
• Access storage volumes
• Modify virtual networking
• Interfere with backup operations
• Deploy malicious virtual machines
• Snapshot or copy sensitive data

Forwarding hypervisor logs into OpenText Core EDR provides visibility into events such as:

Why Not Simply Install an EDR Agent on the Hypervisor?

Installing an EDR agent directly on the hypervisor may seem like the obvious solution, but hypervisors are foundational infrastructure systems.

Installing additional software introduces potential risks:

• Kernel compatibility issues
• Performance overhead
• Interference with virtualisation components
• Increased operational complexity

Many infrastructure teams prefer to keep hypervisors as close as possible to vendor-supported configurations to reduce operational risk. Syslog provides valuable infrastructure visibility with minimal operational impact.

The Challenge: Proxmox Logs Are Very Noisy

Forwarding all Proxmox logs can create excessive log volume and operational noise.

Examples include:

• Network bridge transitions
• TAP interface changes
• Firewall bridge activity
• System session events
• Cluster messaging

A single “VM start” operation generates dozens of kernel and networking events.

For SOC teams, most of these events have little security value.

A Better Strategy: Forward Only the Events That Matter

Instead of forwarding everything and filtering later, we recommend filtering events at the source.

Benefits include:

• Reduced log volume
• Higher signal-to-noise ratio
• Lower storage costs
• Simpler SOC analysis

The following is a list of example categories we are going to forward:

Design Goals

To keep the configuration operationally safe and easy to maintain, we intentionally keep the design simple:

• Use Proxmox’s native rsyslog
• Forward only high-signal events using an allow-list
• Maintain consistent formatting using CEF (Common Event Formatting)
• Avoid complex parsing or fragile regex rules

This ensures the deployment remains predictable, repeatable, and easy to standardise across multiple hosts.

Implementation Guide

The following section walks through the configuration process step by step, starting with validating the Syslog ingestion path before enabling log forwarding on the Proxmox host.

Step 1 — Configure the Syslog Source in OpenText Core EDR

Enable Syslog forwarding on an OpenText Core Endpoint Protection agent via:

Agents → More → Settings → Enable Syslog Forwarder

Step 2 — Test Network Connectivity

Run on: Proxmox Host

ping <the IP of Hostname of your Syslog Forwarder>

Alternative test:

nc -vz -u <the IP of Hostname of your Syslog Forwarder>

Firewall Considerations

Ensure UDP port 514 is allowed between the Proxmox host and relay server.

Example for Ubuntu UFW:

ufw allow 514/udp

Step 3 — Verify Logs Arrive at the Syslog Relay

Before checking the OpenText Core EDR platform, we should first confirm that Syslog packets are reaching the relay server.

Because the OpenText Syslog Forwarder agent processes incoming messages directly, test events will not appear in /var/log/syslog on the relay host.

Instead, we can verify the packets in real-time using tcpdump.

Start a packet capture on the Syslog relay server before sending the test message.

Run on: Syslog Relay

tcpdump -n udp port 514

This command listens for incoming Syslog packets on UDP port 514.
Leave this command running.

Step 4 — Send a Test Log from the Proxmox Host

With tcpdump running on the relay server, switch to the Proxmox host and send a test log message.

Run on: Proxmox Host

logger "Proxmox syslog connectivity test"

Return to the relay server and observe the packet capture output.

If everything is working correctly, you should see a new Syslog packet appear immediately, something like:

12:00:00.0000 IP xxx.xxx.xxx.0000 > yyy.yyy.yyy.yyy.514: UDP, length 120

Where:

• xxx.xxx.xxx.xxx = Proxmox host
• yyy.yyy.yyy.yyy = Syslog relay server

This confirms:

• Network connectivity between the Proxmox host and relay server
• UDP/514 traffic is reaching the Syslog forwarder
• The relay server is receiving Syslog messages successfully
   

Step 5 — Confirm Logs in OpenText Core EDR

To see your syslog log in the OpenText Core EDR SIEM:

1. Navigate to the Search section.
2. Select the SYSLOG log index and a  timeframe using the dropdown menus in the top-right corner.
3. Use the search bar to search for Proxmox syslog connectivity test 

Step 6 — Configure & Tune Proxmox Log Forwarding

Now that the Syslog pipeline has been verified, we can configure Proxmox to forward ONLY selected events to the Syslog relay server.

Proxmox uses rsyslog as its system logging service. Rather than modifying the main rsyslog configuration file, we will create a dedicated configuration file inside the /etc/rsyslog.d/ directory.

This approach has several advantages:

• keeps the configuration modular
• prevents accidental modification of system files
• makes the configuration easier to manage or remove later
• aligns with standard Linux logging practices

The configuration we are about to apply performs four main tasks:

1. Defines the Syslog destination (relay server)
2. Creates a CEF log template
3. Matches specific log messages and program names
4. Forwards only high-value security and infrastructure events

Run on: Proxmox Host

nano /etc/rsyslog.d/60-proxmox-syslog.conf

Now create the configuration file.
If you are going to use the sample below, replace the example IP address with the IP address of your Syslog relay server.

set $.soc_host="192.0.2.10";
set $.soc_port="514";

set $!sig="PVE-LOG";
set $!name="Proxmox Event";
set $!cefsev="3";

template(name="ProxmoxCEF" type="string"

string="<%pri%>%timestamp:::date-rfc3339% %hostname% %programname%: CEF:0|Proxmox|PVE|8.1|%$!sig%|%$!name%|%$!cefsev%|dhost=%hostname% cs1Label=program cs1=%programname% cs2Label=facility cs2=%syslogfacility-text% cs3Label=syslogSeverity cs3=%syslogseverity-text% msg=%msg:1:$%\n"
)

if ($programname == "sudo") then {
 set $!sig="PVE-SUDO";
 set $!name="Privilege Escalation";
 set $!cefsev="6";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}
if ($programname == "sshd") then {
 set $!sig="PVE-AUTH";
 set $!name="SSH Authentication";
 set $!cefsev="5";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}

if ($msg contains "successful auth for user") then {
 set $!sig="PVE-AUTH";
 set $!name="Proxmox Authentication";
 set $!cefsev="5";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}

if ($msg contains "UPID:" and (
$msg contains ":qmstart:" or
$msg contains ":qmstop:" or
$msg contains ":qmshutdown:" or
$msg contains ":qmmigrate:"
)) then {
 set $!sig="PVE-VM-STATE";
 set $!name="VM Lifecycle";
 set $!cefsev="4";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}

if ($msg contains "vzdump") then {
 set $!sig="PVE-VM-BACKUP";
 set $!name="VM Backup Job";
 set $!cefsev="4";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}

if ($msg contains "I/O error" or
$msg contains "blk_update_request" or
$msg contains "Buffer I/O error") then {
 set $!sig="PVE-STORAGE";
 set $!name="Storage Fault";
 set $!cefsev="8";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}

if ($programname == "kernel" and (
$msg contains "panic" or
$msg contains "BUG:" or
$msg contains "Oops"
)) then {
 set $!sig="PVE-KERNEL";
 set $!name="Kernel Crash";
 set $!cefsev="10";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}

if ($programname == "qemu-server" or $msg contains "qmp command failed") then {
 set $!sig="PVE-VM-CRASH";
 set $!name="VM Runtime Failure";
 set $!cefsev="8";
 action(type="omfwd" target=$.soc_host port=$.soc_port protocol="udp" template="ProxmoxCEF")
 stop
}

After pasting or creating the configuration, save the changes and exit the editor.

• Press: Ctrl + O - This writes the file to disk.
• When prompted to confirm the filename, press: Enter
• Then exit nano by pressing: Ctrl + X

This will return you to the command line.

The example configuration file defines the CEF (Common Event Format). as a template.

template(name="ProxmoxCEF" type="string"

string="<%pri%>%timestamp:::date-rfc3339% %hostname% %programname%: CEF:0|Proxmox|PVE|8.1|%$!sig%|%$!name%|%$!cefsev%|dhost=%hostname% cs1Label=program cs1=%programname% cs2Label=facility cs2=%syslogfacility-text% cs3Label=syslogSeverity cs3=%syslogseverity-text% msg=%msg:1:$%\n"
)

Where:

CEF is widely used by security platforms and ensures logs are structured consistently, improving:

• event parsing
• searchability
• correlation inside the SOC platform

The template includes metadata such as:

• hostname
• program name
• facility
• severity
• message content

Step 7 — Validate Configuration

Run on: Proxmox Host

rsyslogd -N1

This command validates the rsyslog configuration without restarting the service.

Expected:

End of config validation run. Bye.

If any syntax errors are present, rsyslog will report them here.

Step 8 — Restart rsyslog

Restart the logging service to apply the new configuration.

Run on: Proxmox Host

systemctl restart rsyslog

Verify the service status:

systemctl status rsyslog

The service should show active (running).

Step 9 — Generate a Test Event

We can now simulate a VM runtime failure event.

logger "Proxmox syslog connectivity test"

Run on: Proxmox Host

logger -t qemu-server "qmp command failed - VM 999 not running (SOC test)"

This command generates a log entry that matches the VM Runtime Failure rule.

Step 10 — Confirm the Event Reaches the SOC

Search specifically portal for:

qmp command failed

You should see an event similar to:

VM Runtime FailureSource: Proxmox HostProgram: qemu-server

This confirms that:

• the Proxmox host is forwarding events
• the Syslog relay is receiving them
• OpenText Core EDR is ingesting them successfully

Lessons Learned — Common Syslog Gotchas

During writing this, we encountered several issues that are worth highlighting. These are fairly common when integrating infrastructure logs into SOC platforms.

Understanding them ahead of time can save significant troubleshooting time.

Syslog Packets Marked “Invalid”

With a malformed template, packets appeared in the platform as invalid syslog messages.

This typically occurs when the log payload does not contain a valid syslog header.

Many SOC platforms expect messages to include standard syslog fields such as:

• priority
• timestamp
• hostname
• program name

Without these fields, the message may still be received, but cannot be parsed correctly.

Solution

The CEF template used in this guide includes a properly formatted RFC-compliant syslog header:

<%pri%>%timestamp:::date-rfc3339% %hostname% %programname%:

This ensures the message structure conforms to standard syslog expectations.

Once the header was included, the platform parsed the events correctly.

Leading Spaces Breaking Parsers

Some syslog messages generated by Proxmox contain a leading space before the message body.

While this may seem harmless, certain downstream parsers treat this as malformed input and may fail to extract fields correctly.

Solution

The template removes the first character of the message body using:

msg=%msg:2:$%

This trims the leading space and ensures consistent parsing.

Logger Tests Not Matching Filtering Rules

When testing syslog rules, it is common to generate events using the logger command.

However, by default the logger utility sets the program name to the current shell username.

This can confuse when rsyslog rules are matching specific program names, such as:

qemu-server

Example Problem

If the test command is run as root:

logger "test message"

The program name becomes:

root

This will not match the rules expecting qemu-server.

Solution

Use the -t option to define the program name explicitly.

Run on: Proxmox Host

logger -t qemu-server "test message"

This ensures the event matches the intended rsyslog rule.

sudo tcpdump -ni ens18 -nn -s0 -A udp port 514

Time Synchronisation

Accurate timestamps are critical for security investigations.

Ensure that both the Proxmox host and the Syslog relay server are synchronised using NTP or another reliable time source.

Time drift between systems can make it difficult for SOC analysts to reconstruct event timelines during incident investigations.

rsyslog Requirement on Proxmox

Proxmox normally relies on rsyslog for traditional Syslog forwarding.

However, in some installations rsyslog may not be installed or enabled by default. If the service is not present on your host, you will need to install it before continuing.

Run on: Proxmox Host

Check if rsyslog is installed:

systemctl status rsyslog

If the service is not found, install it:

apt updateapt install rsyslog

Enable and start the service:

systemctl enable rsyslog
systemctl start rsyslog

Verify it is running:

systemctl status rsyslog

Testing with tcpdump Helps Isolate Issues

When troubleshooting syslog pipelines, it is extremely helpful to verify each stage of the log flow independently.

Using tcpdump on the relay server allows you to confirm that packets are arriving before investigating ingestion issues inside the SOC platform.

Run on: Syslog Relay

sudo tcpdump -ni ens18 -nn -s0 -A udp port 514

If packets appear here but not inside the SOC platform, the issue is likely related to:

• parsing
• formatting
• platform configuration

If packets do not appear here, the problem is typically:

• firewall rules
• routing
• incorrect destination IP
• incorrect port

This layered troubleshooting approach can dramatically reduce debugging time.

Viewing Syslog Events in OpenText Core EDR

Once your Proxmox host is forwarding logs successfully, you can explore them in the OpenText Core EDR SIEM interface.

Saved searches can then be used to create automated alerts and response workflows.

OpenText Core EDR workflows allow security teams to trigger alerts and automated actions directly from these searches.

For more information on workflows, see: https://help.uk1.pillrplatform.com/setup/intro_to_workflows.html

Final Thoughts

Integrating Proxmox with OpenText Core EDR extends security visibility into the virtual infrastructure layer.

With a small rsyslog configuration, you can:

• Reduce SOC noise
• Capture meaningful hypervisor events
• Detect operational failures early
• Strengthen infrastructure monitoring

For MSP partners managing Proxmox environments, this configuration can easily become part of a baseline infrastructure security deployment.

Once implemented, your SOC gains valuable insight into hypervisor activity — helping protect both the virtualisation platform and the workloads it runs.