LKRG — the Linux Kernel Runtime Guard, included in RLC Pro Hardened — watches the kernel from the inside and flags exploitation the moment it happens: a privilege escalation attempt, or credentials swapped outside their normal path. That is a strong alarm. The problem is where it rings by default. It lands in the local journal of the very host that may already be compromised, where nobody is watching it and an attacker can wipe it.
This tutorial gets that alarm off the box and into Wazuh, decoded into structured fields and firing alert rules your security team can act on. Two things come with it. Your team sees kernel events in Wazuh's console next to their host and application alerts, and you keep a durable log record out of band, where it survives whatever happens to the host. As LKRG's designer Solar Designer, who wrote LKRG's remote logging, has noted, local logs are exactly what you cannot trust after an incident — they may be missing, incomplete, or tampered with.
This tutorial assumes RLC Pro Hardened is installed and LKRG is running, and that a Wazuh Manager is reachable from your hosts. It covers two collection architectures — choose the one that fits your environment.
Two architectures: choose before you configure
LKRG includes its own remote logging capability in the lkrg-logger sub-package, which sends kernel security events to a remote destination independently of the host's syslog stack. This separation matters: if an attacker achieves persistent kernel access despite LKRG's detection, the local journal or syslog may be compromised before your team begins forensics. LKRG's remote logging path operates outside that window.
Architecture A (syslog proxy): LKRG remote logging sends events to a central syslog proxy (rsyslog or syslog-ng). The proxy aggregates events across hosts and forwards them to the Wazuh Manager's remote syslog listener. Use this in environments with many hosts, where you want a durable intermediate store, or where a central syslog proxy is already part of your pipeline.
Architecture B (Wazuh Agent): LKRG events flow to the systemd journal on each host. A per-host rsyslog configuration writes LKRG messages to a dedicated log file, which the Wazuh Agent collects. No central proxy required. Use this in environments where a Wazuh Agent is already deployed on each host, or where the proxy model adds complexity without a clear return.
Both architectures deliver LKRG events to the Wazuh Manager for decoding and alerting. Architecture A is more resilient if a host is fully compromised before logs are forwarded; Architecture B is simpler when the Wazuh Agent is already part of your host baseline.
Set up LKRG remote logging (Architecture A)
Install the lkrg-logger sub-package on each RLC Pro Hardened host:
sudo dnf install lkrg-logger
Configuration and full setup instructions are in /usr/share/doc/lkrg-logger/LOGGING. The package includes the userspace components that receive LKRG kernel events and forward them to your configured remote destination.
On the proxy server, configure rsyslog to receive LKRG events and forward them to the Wazuh Manager's remote syslog listener:
module(load="imudp")
input(type="imudp" port="514")
if $msg contains "p_lkrg" then {
action(
type="omfwd"
target="YOUR_WAZUH_MANAGER"
port="514"
protocol="udp"
)
stop
}
On the Wazuh Manager, enable the remote syslog listener in /var/ossec/etc/ossec.conf if it is not already configured:
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>YOUR_PROXY_IP</allowed-ips>
</remote>
Replace YOUR_PROXY_IP with the IP or CIDR block of your syslog proxy. Restart the Wazuh Manager after saving:
sudo systemctl restart wazuh-manager
Configure Wazuh Agent collection (Architecture B)
For agent-based collection, configure rsyslog on each host to write LKRG journal entries to a dedicated file. Create /etc/rsyslog.d/lkrg.conf:
module(load="imjournal")
if $msg contains "p_lkrg" then {
action(
type="omfile"
file="/var/log/lkrg.log"
)
}
Restart rsyslog to apply:
sudo systemctl restart rsyslog
In the Wazuh Agent's ossec.conf, add a localfile block to collect from the LKRG log:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/lkrg.log</location>
</localfile>
Restart the Wazuh Agent:
sudo systemctl restart wazuh-agent
A healthy configuration shows the agent sending events from /var/log/lkrg.log in the Wazuh Manager's agent log view.
Already running RLC Pro Hardened and expanding SIEM coverage? See what ships in RLC Pro Hardened →
Write a custom decoder for LKRG events
Without a custom decoder, Wazuh processes LKRG messages as generic syslog entries. The lkrg.severity and lkrg.message fields remain unextracted, and alert rules cannot filter on LKRG-specific attributes.
LKRG log lines follow a consistent format, with severity in brackets:
p_lkrg: [ALERT] <process name>[PID:<n>] <description of integrity violation>
p_lkrg: [WARNING] <description of anomalous condition>
Add the following to /var/ossec/etc/decoders/local_decoder.xml on the Wazuh Manager:
<decoder name="lkrg">
<prematch>p_lkrg: </prematch>
</decoder>
<decoder name="lkrg-fields">
<parent>lkrg</parent>
<regex>p_lkrg: \[(\w+)\] (.+)</regex>
<order>lkrg.severity, lkrg.message</order>
</decoder>
The parent decoder matches any log line containing p_lkrg:. The child decoder extracts the severity level (ALERT or WARNING) and the full event description into named fields.
Validate the decoder before restarting using wazuh-logtest:
sudo /var/ossec/bin/wazuh-logtest
Paste a sample LKRG log line, for example:
p_lkrg: [ALERT] bash[PID:1234] Privilege escalation attempt detected
The tool should show lkrg.severity: ALERT and lkrg.message: bash[PID:1234] Privilege escalation attempt detected in the decoded output. If fields do not appear, verify the regex against the actual format in your LKRG version.
Create alert rules that reflect LKRG's signal quality
LKRG ALERTs are not threshold events. When LKRG raises an ALERT, it has observed a real kernel integrity concern — a privilege escalation attempt, a credential modification outside expected paths, or a violation of kernel data structure integrity. Alert rules should trigger on a single ALERT event, not after a count threshold is reached.
Add the following to /var/ossec/etc/rules/local_rules.xml on the Wazuh Manager:
<group name="lkrg,">
<rule id="100001" level="15">
<decoded_as>lkrg-fields</decoded_as>
<field name="lkrg.severity">ALERT</field>
<description>LKRG: Kernel integrity violation detected - $(lkrg.message)</description>
<group>lkrg,alert,</group>
</rule>
<rule id="100002" level="8">
<decoded_as>lkrg-fields</decoded_as>
<field name="lkrg.severity">WARNING</field>
<description>LKRG: Kernel anomaly detected - $(lkrg.message)</description>
<group>lkrg,warning,</group>
</rule>
</group>
Rule 100001 uses Wazuh's maximum severity level (15), which triggers an immediate alert regardless of event count. Rule 100002 at level 8 fires on any WARNING event; add a <frequency> element and <timeframe> to group warnings if notification volume becomes a concern.
Do not add frequency thresholds to rule 100001. If an LKRG ALERT fires and investigation finds no malicious activity, that indicates a software compatibility issue between LKRG and a specific kernel or userspace version — something to report to CIQ support so it can be addressed at the source. Suppressing the alert delays that diagnosis.
Restart the Wazuh Manager after saving rules:
sudo systemctl restart wazuh-manager
Verify the full pipeline
With collection, decoders, and rules in place, run through these checks:
- In the Wazuh dashboard, search for events with
rule.groups: lkrgand confirmlkrg.severityandlkrg.messageare populated on recent entries. - Confirm both rules (100001 and 100002) appear as active in the Wazuh Rules view.
- Trigger a test event using LKRG's instrumentation test procedures (documented in the
lkrg-loggerpackage) and confirm rule 100001 fires and routes to your configured integration.
A complete integration gives your security team two things: real-time kernel security visibility in Wazuh's unified console, and a durable out-of-band log record for post-incident analysis regardless of what happens to the local host.
Evaluating RLC Pro Hardened for your environment? Request a demo.
