Logs

Overview

Logs are the recorded history of what happened on a system — who logged in, what services did, what errors occurred. For security, they are often the single most important source of evidence. This lesson explains Linux logs and where to find them.

Learning objectives

• Explain what system logs are and why they matter.
• Locate key log files under /var/log.
• Read logs with common command-line tools.

Core concept

Logs are timestamped records that services and the system write as events occur. On traditional Linux systems they are text files under /var/log:

• /var/log/auth.log (Debian) or /var/log/secure (RHEL) — authentication and privilege events (logins, sudo).
• /var/log/syslog or /var/log/messages — general system messages.
• Service-specific logs (e.g. web server logs).

You read them with tools like cat, less, tail (especially tail -f to follow live), and grep to filter.

How it works

As events happen, the logging system appends lines to the appropriate file, each typically carrying a timestamp, the host, the program, and a message. Because logs are usually plain text, the shell toolkit applies directly: grep to find relevant lines, tail -f to watch new entries in real time, and pipelines to count or summarize. Logs are also rotated (older logs compressed/archived) to manage size, so historical entries may be in files like auth.log.1 or .gz archives.

Practical example

$ sudo tail -f /var/log/auth.log
... Sep 21 10:15:01 host sshd[1520]: Accepted password for alice from 192.168.1.20
... Sep 21 10:16:44 host sshd[1602]: Failed password for invalid user admin from 203.0.113.9

Following the auth log live shows a successful login by alice and a failed attempt for a non-existent admin user from an external IP — the kind of entry that, if repeated, signals a brute-force attempt.

Cybersecurity relevance

Logs are the backbone of detection, incident response, and forensics: authentication logs reveal login attempts and privilege escalations, service logs reveal misuse, and system logs reveal errors and anomalies. Analysts grep logs for indicators, follow them live during an incident, and reconstruct timelines from them. Because logs are so valuable, attackers may try to delete or alter them — which is why log integrity, permissions, and forwarding to a central/remote log store matter (expanded in later lessons and the SOC path).

Common mistakes

• Not knowing which log holds what (auth vs syslog vs service logs), slowing investigation.
• Forgetting log rotation, then missing older entries archived in .1/.gz files.
• Assuming logs are complete and untampered — attackers may alter them.

Key takeaways

• Logs are timestamped event records; on traditional systems they live as text files under /var/log (auth.log/secure, syslog/messages, service logs).
• Read them with cat/less/tail -f/grep; logs are rotated, so history may be in archived files.
• Logs are central to detection and forensics and are a tampering target, making their integrity and protection important.

Check your understanding

• Which log file would you check for failed SSH login attempts, and what tool lets you watch it live?
• Why might older log entries not appear in the current log file, and why do attackers target logs?