Why logs are your first line of defense
An attacker can be quiet. They can use legitimate tools, avoid triggering alerts, and move slowly to stay under the radar. But they can’t operate without leaving traces in logs.
System logs continuously record what happens on a machine: SSH connections, authentication attempts, service starts, system errors, and sudo activity. If you can read them, you can reconstruct what happened—even after the fact.
A Blue Team analyst spends a lot of time reading logs. It’s one of the most fundamental defensive skills.
Essential log files on Linux
/var/log/auth.log (Debian/Ubuntu) or /var/log/secure (CentOS/RHEL)
This is one of the most important logs for security. It records authentication activity: successful and failed SSH logins, sudo usage, and password changes.
What you’re seeing: three failed logins from 192.168.1.105 against root, followed by one successful login from 192.168.1.10. The first IP looks suspicious—this is a common brute-force pattern.
/var/log/syslog or /var/log/messages
The general-purpose system log. It captures events from the kernel, services, and daemons. Useful for spotting abnormal service behavior.
That third line is critical: a cron job is downloading a script from an external server. That’s a strong persistence signal.
/var/log/kern.log
Linux kernel messages. Useful to detect low-level behaviors: suspicious module loads, memory errors, and potential kernel exploit attempts.
Using journald — the modern logging system
On modern systemd-based systems, logs are centralized in journald. The journalctl command replaces direct file reading.
Most useful journalctl options:
| Option | Meaning |
|---|---|
-u ssh | Filter by service (SSH here) |
-p err | Show only errors and above |
--since '2 hours ago' | Show logs since a relative time |
-f | Follow in real time (like `tail -f`) |
-n 100 | Show the last 100 lines |
Find suspicious patterns with grep
Reading raw logs is inefficient at scale. grep lets you quickly filter for the events that matter.
Detect SSH login failures:
This extracts the source IPs behind failed logins and counts them. 192.168.1.105 with 47 attempts is clearly brute-force behavior.
Detect sudo activity:
A user opening a root shell with sudo /bin/bash and then reading /etc/shadow is behavior worth investigating.
Analyze logs in real time
During an active incident, you want to watch logs as they arrive.
Key takeaways
| File / Command | What it contains | When to use it |
|---|---|---|
/var/log/auth.log | SSH auth, sudo, PAM | First place to look in most incidents |
/var/log/syslog | General system events | Weird service behavior, “what changed?” |
/var/log/kern.log | Kernel messages | Suspected kernel exploits, suspicious modules |
journalctl -u ssh -f | Live SSH logs | Active monitoring during an incident |
Which file contains SSH login attempts on Ubuntu?
How do you view SSH logs in real time with journalctl?
Which grep pipeline counts the IPs with the most SSH failures?
What’s the difference between /var/log/auth.log and /var/log/syslog?
Hands-on exercises
Exercise 1 — On your Linux VM, run sudo tail -100 /var/log/auth.log and identify all successful SSH logins. Write down the source IPs and the usernames.
Exercise 2 — Use grep 'Failed password' /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn to list the IPs with the most failed attempts. Do any IPs look suspicious?
Open questions
How do you distinguish an SSH brute-force attack from a simple user mistake in auth.log?
Next Lesson
You now know how to read and analyze system logs. The next lesson applies this skill to a real scenario: detecting Nmap scans in your logs and understanding what reconnaissance activity looks like from a defender's perspective.
Next: Detecting Nmap Scans