In this section
LX0.7 The Linux Distribution Landscape
cat /var/log/auth.log — file not found. Is the log deleted by the attacker, or does this system use a different log path? You waste 10 minutes searching before discovering this is a RHEL-based system where the file is /var/log/secure. Meanwhile, volatile evidence degrades. The first command on any Linux system must identify the distribution, because the distribution determines where every piece of evidence lives, which package manager was used, which init system manages services, and which security framework is active. Without this mapping, you are investigating blind.The Distribution Landscape: What Changes Between Ubuntu, RHEL, and Alpine
Why distributions matter for investigation
Linux is not one operating system — it is a kernel with hundreds of distributions built on top of it, each making different decisions about where to put files, how to manage services, and which tools to include. An investigator who knows Ubuntu's evidence paths but encounters a RHEL server will look for /var/log/auth.log and find it does not exist. The equivalent file is /var/log/secure. The commands are the same (cat, grep, journalctl), but the paths, filenames, and sometimes the log formats are different.
The distribution differences that matter for investigation fall into five categories: log file locations, package management, init system and service management, security frameworks, and filesystem layout conventions. Each category affects where you look for specific evidence types.
# The FIRST command on any compromised Linux system — identify the distro
# Run this before any evidence collection commands
cat /etc/os-release
# Key fields to note:
# ID=ubuntu → Debian family (auth.log, apt, AppArmor)
# ID=rhel → RHEL family (secure, dnf, SELinux)
# ID=amzn → Amazon Linux (RHEL-derived + SSM agent)
# ID=alpine → Alpine (minimal, musl, OpenRC, no systemd)
# VERSION_ID=22.04 → specific version (affects available features)
# Fallback identification if os-release is missing or modified
cat /etc/debian_version 2>/dev/null && echo "→ Debian family"
cat /etc/redhat-release 2>/dev/null && echo "→ RHEL family"
cat /etc/alpine-release 2>/dev/null && echo "→ Alpine"
# If all three are missing, check the package manager:
which apt 2>/dev/null && echo "→ Debian family (has apt)"
which dnf 2>/dev/null && echo "→ RHEL family (has dnf)"
which apk 2>/dev/null && echo "→ Alpine (has apk)"Distribution Family 1: Debian and Ubuntu
# On Amazon Linux — check for SSM-based access in addition to SSH
# SSM sessions do NOT appear in auth.log or secure
cat /var/log/amazon/ssm/amazon-ssm-agent.log | grep -i "session" | tail -10
# SSM access evidence is also in AWS CloudTrail:
# EventName: StartSession, TerminateSession
# An attacker with compromised AWS IAM credentials can use SSM to
# access instances without any SSH key or passwordMyth: "All Linux distributions use the same log paths — just look in /var/log."
Reality: The log filenames differ between distribution families. Debian/Ubuntu uses auth.log for authentication; RHEL/CentOS uses secure. Debian uses syslog; RHEL uses messages. On RHEL 9+, rsyslog may not be installed at all — there are no traditional log files, only the systemd journal accessible via journalctl. On Alpine containers, there may be no log files whatsoever. An investigator who assumes Debian paths on a RHEL system wastes time looking for files that do not exist, while the attacker's session timer ticks. The first command is always cat /etc/os-release — everything flows from the distribution identification.
Decision points: which distribution details matter for your investigation
Not every distribution difference affects every investigation. The decision points that matter most:
RHEL 9+ without rsyslog: If rpm -q rsyslog returns "not installed," there are no traditional log files. Your entire log analysis shifts to journalctl. This is a fundamental change in investigation methodology — not a minor path difference.
Alpine containers without syslog: If the container has no syslog daemon, evidence inside the container is limited to the filesystem and running processes. Shift focus to the container runtime logs (docker logs, kubectl logs) and the orchestrator audit log.
Amazon Linux with SSM Agent: Always check for SSM-based access in addition to SSH. An attacker who used SSM to connect is invisible in auth.log and secure — the evidence is in CloudTrail and the SSM agent log.
SELinux vs AppArmor: This determines where MAC violation evidence appears. SELinux denials: ausearch -m avc. AppArmor violations: journalctl -k | grep apparmor. Checking the wrong framework returns nothing — not because there are no violations, but because you queried the wrong subsystem.
Troubleshooting: when distribution identification fails
/etc/os-release is missing or modified: The attacker may have modified or deleted the file to confuse investigators. Fall back to distribution-specific files (/etc/debian_version, /etc/redhat-release, /etc/alpine-release). If all are missing, check the package manager: which apt && echo Debian or which dnf && echo RHEL or which apk && echo Alpine. The package manager binary is harder to fake.
Unfamiliar distribution or custom build: Some organizations build custom Linux images with non-standard paths. Check the init system (pidof systemd && echo systemd or pidof openrc-init && echo OpenRC), then check where syslog writes: grep -r "auth\." /etc/rsyslog.d/ /etc/rsyslog.conf 2>/dev/null shows you the actual path the syslog daemon uses for authentication events.
Container with almost nothing installed: Minimal container images may lack basic tools. If cat is not available (BusyBox image without it), try head -1 /etc/os-release. If the shell itself is limited (sh instead of bash), adjust your command syntax accordingly — avoid bash-specific features like process substitution and arrays.
Try it yourself
Identify the distribution of every Linux system you have access to.
Identify the distribution of every Linux system you have access to. Run cat /etc/os-release on each one. Note the ID field and VERSION_ID. Then verify: does this system use auth.log or secure? Does it use apt or dnf? Is systemd the init system (pidof systemd returns a PID)? Does it have SELinux (getenforce) or AppArmor (aa-status)? Build a table of your infrastructure's distributions and evidence paths — you will need this reference during an incident. Complete the distribution identification triage card (worked artifact above) for each system.
Beyond this investigation
Distribution differences affect every investigation scenario in this course. The Northgate Engineering environment runs Ubuntu 22.04, so the primary evidence paths used in scenarios are Debian-derived. However, LX10 (Cloud VM Compromise) includes an Amazon Linux instance, and LX9 (Container Compromise) involves Alpine-based container images. The distribution reference in this subsection applies across all of them.
Check your understanding:
1. You SSH into a compromised server and run cat /var/log/auth.log — the file does not exist. What is your immediate next step to identify the correct authentication log location? 2. What does rpm -Va report, and why is its output forensically significant on a compromised RHEL system? 3. A container is running Alpine Linux. You need to check recent authentication events. Why might traditional log files not exist, and where would you look instead? 4. On an Amazon Linux 2023 instance, why should you check for SSM Session Manager access in addition to SSH access?
You are investigating a Linux server and discover evidence of both a cryptominer (resource abuse) and an SSH key theft (lateral movement preparation). The cryptominer is consuming 95% CPU and impacting production. Which do you address first?
Address the lateral movement first. The cryptominer is visible, noisy, and contained to this server — it is causing performance impact but not spreading. The SSH key theft is silent, potentially already exploited, and may have given the attacker access to additional servers. Contain the lateral movement risk: rotate the stolen SSH keys, check the target servers for unauthorized access, and apply network restrictions. Then address the cryptominer: kill the process, remove the binary and persistence mechanisms. Prioritizing the noisy but contained threat over the silent but spreading threat is the most common Linux IR prioritization mistake.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.