Lockdown Lab #40 HIGH Linux (Ubuntu/RHEL)

Ship logs to remote syslog / SIEM

Ship logs to remote syslog / SIEM

Think an attacker won’t erase their tracks? Think again. The first thing a sophisticated adversary does after gaining access is try to disappear. This means tampering with, or outright deleting, local logs.

If your critical Linux logs are only sitting on the box they’re monitoring, you’re giving the attacker an easy win. You need those logs off-site, immediately, to an immutable system. This isn’t optional; it’s foundational.

The fix is straightforward: ship everything to a central SIEM or syslog server. For Ubuntu/RHEL, configure rsyslog to forward critical logs. A simple line like . @@siem.company.com:514 in your rsyslog config sends all events to a remote server. This buys you visibility even if the local machine is compromised.

If you’re not doing this, you’re operating blind the moment an attacker gets a foothold. Don’t rely on local logs that can be manipulated.

The fix

# /etc/rsyslog.conf (rsyslog)

*.* @@siem.company.com:514

# Or use Elastic Agent / Splunk UF / Azure AMA

Reference: CIS Linux Benchmark 4.2.1

Mark this as done

Open the interactive hardening checklist and tick this off in your environment.

Open interactive checklist →

Related Posts

Enable and configure auditd

Attackers love operating in the dark. If you're not logging critical security events on your Linux servers, you're handing them a permanent stealth cloak. Remember...

lockdown-labhardeninglinuxlogging
/Shimi Cohen

Enable and configure auditd

The SolarWinds attack showed us a painful truth: a lack of comprehensive audit logging allowed attackers to remain undetected for months. If you can't see...

lockdown-labhardeninglinuxlogging
/Shimi Cohen

Disable ICMP redirects

Thinking a Man-in-the-Middle (MitM) attack only happens over Wi-Fi? Think again. Your Linux servers, if not properly configured, can be tricked into redirecting traffic right...

lockdown-labhardeninglinuxnetwork
/Shimi Cohen