Home > SOC Analysis

Syslog Basics

Linux systems generate thousands of logs every second, covering authentication, system activity, kernel messages, network events, services, processes, and application behavior. All of these logs funnel into the syslog system, which acts as the central logging framework for Linux.
For SOC analysts, understanding syslog is the foundation of Linux security monitoring, threat detection, and incident response.

This chapter explains syslog with full-scale practical depth, including log locations, facility levels, structure, parsing, SIEM ingestion, attack visibility, and investigation workflows.

What Syslog Actually Is

Syslog is a standard logging system used by Linux to collect and store logs from:

  • System processes

  • Services (SSHD, cron, sudo, Apache, etc.)

  • Kernel

  • Applications

  • Authentication mechanisms

  • Network daemons

Syslog provides:

  • Log routing

  • Log formatting

  • Log storage

  • Log forwarding to SIEM

Linux sends all logs into syslog using a standard line-based format.

Syslog Daemons (What Generates and Stores Logs)

Linux uses one of these daemons to handle logs:

  • rsyslog (most common)

  • syslog-ng

  • journald (systemd-based systems)

Even if journald is used, logs can be sent to rsyslog for SIEM ingestion.

Syslog Log Locations (Practical Breakdown)

The main syslog directory:

/var/log/

Key files SOC analysts use:

/var/log/auth.log

Authentication events:

  • SSH login attempts

  • sudo usage

  • su commands

  • PAM authentication

/var/log/syslog

General system events:

  • Service start/stop

  • Errors

  • System activity

/var/log/messages

Kernel + system logs (RHEL/CentOS equivalent).

/var/log/secure

Authentication/security log on RHEL-based systems.

/var/log/kern.log

Kernel messages.

/var/log/dmesg

Hardware and boot messages.

/var/log/cron

Cron job execution logs.

/var/log/apache2/

Web server logs.

/var/log/audit/

SELinux and auditd logs.

Syslog gives the SOC complete visibility into Linux behavior.

Syslog Format (REAL Log Examples)

Every syslog line follows a predictable structure:

<PRI>TIMESTAMP HOSTNAME PROCESS[PID]: MESSAGE

Let’s break it down:

1. PRI (Facility + Severity)

Example:

<34>

2. Timestamp

Jan 10 14:33:22

3. Hostname

ubuntu-server01

4. Process Name and PID

sshd[1244]:

5. Message Body

Failed password for root from 185.33.22.10 port 55412 ssh2

Practical Syslog Examples (SOC Focused)

Below are real attacker footprints found in syslog.

1. SSH Brute Force

Jan 10 03:33:21 ubuntu-server sshd[1432]: Failed password for root from 185.22.10.44 port 50518 ssh2
Jan 10 03:33:22 ubuntu-server sshd[1432]: Failed password for root from 185.22.10.44 port 50518 ssh2

Attack Indicator: Repeated failures from same IP.

2. Successful SSH Login

Jan 10 03:35:44 ubuntu-server sshd[1441]: Accepted password for mayur from 185.22.10.44 port 50520 ssh2

If followed by sudo escalation → compromise.

3. Privilege Escalation (sudo)

Jan 10 03:36:10 ubuntu-server sudo: mayur : TTY=pts/0 ; COMMAND=/bin/bash

SOC checks if this is normal behavior for this user.

4. User Added (Potential Persistence)

useradd[1452]: new user 'backupadmin' created

Suspicious if created by attacker.

5. Cron-based Persistence

CRON[1551]: (root) CMD (/usr/bin/python3 /tmp/backdoor.py)

Cron logs reveal malicious scheduled tasks.

6. Service Tampering

systemd[1]: Stopped ssh.service

Attackers often disable security services.

7. Suspicious Shell Execution

bash[2001]: uid=0 gid=0 euid=0 executing /tmp/rootkit.sh

Evidence of privilege escalation scripts.

Syslog Facility & Severity Levels (SOC Interpretation)

Each log has a facility (log source category) and severity level.

Facility Examples

  • auth / authpriv → Authentication logs

  • daemon → Services

  • kern → Kernel

  • user → Applications

  • cron → Scheduled tasks

Severity Levels

From most severe to least:

  • emerg

  • alert

  • crit

  • err

  • warning

  • notice

  • info

  • debug

Example:

<34>
Facility = auth  
Severity = info

Facilities + severity help SIEM classify logs.

Syslog Forwarding to SIEM (Practical Setup)

To send syslog to SIEM:

/etc/rsyslog.conf

Add:

*.*  @10.0.0.20:514

Or for TCP:

*.*  @@10.0.0.20:514

Restart:

systemctl restart rsyslog

Now SIEM receives logs in real time.

Syslog in Real Attacks (Full Timeline)

Step 1 — Brute Force

auth.log: Failed password for root from 185.33.55.11

Step 2 — Successful Login

Accepted password for root from 185.33.55.11

Step 3 — Privilege Escalation

sudo: root : TTY=pts/0 ; COMMAND=/usr/bin/python3 -c "import pty"

Step 4 — Malware Installation

bash: executing /tmp/xmrig

Step 5 — Persistence

CRON: (root) CMD (/usr/bin/python3 /etc/cron.hourly/update.sh)

Step 6 — Service Manipulation

systemd: Stopped ufw.service

Syslog reveals almost the entire attack sequence.

SOC Investigation Workflow Using Syslog

  1. Identify suspicious source IP

  2. Check failed/accepted SSH login patterns

  3. Validate user identity and login times

  4. Check sudo logs for privilege escalation

  5. Review bash history logs

  6. Check cron logs for persistence

  7. Analyze process logs for malware execution

  8. Review system logs for service tampering

  9. Build timeline across all /var/log files

  10. Escalate if malicious behavior is confirmed

Intel Dump

  • Syslog is the central logging system on Linux, capturing authentication, system, kernel, process, and service activity.

  • Key log files include /var/log/auth.log, /var/log/syslog, /var/log/messages, /var/log/secure, /var/log/cron.

  • Syslog logs follow a structured format including timestamp, hostname, process, and message.

  • Practical use cases include detecting SSH brute force, privilege escalation, malicious cron jobs, user creation, tampering with services, and malware execution.

  • SOC analysts rely on syslog to track Linux compromise steps and build investigation timelines.

HOME LEARN COMMUNITY DASHBOARD