SOC › Module 4 › Lesson 2
Linux Auth Logs
Linux auth literacy names auth.log, sshd, sudo, and PAM patterns — parse YOUR $SOC_LAB syslog snippets without stranger server access.
Visual · t29_linux_auth_logs
Linux auth literacy. $SOC_LAB only. Original Cyberlium.
Opening
Failed password for invalid user — literacy reads sshd lines on lab syslog before you SSH into systems you do not own.
Linux authentication logs typically land in /var/log/auth.log or journald: sshd accepted/ failed, sudo sessions, PAM errors. Patterns: 'Failed password,' 'Invalid user,' 'Accepted publickey,' 'session opened for user root.' Brute-force literacy counts failures by source IP on lab files — not live ssh scanning. Cyberlium maps Linux auth patterns on YOUR $SOC_LAB synthetic syslog — fake hosts and users only. Next: Network/Proxy Logs.
1. Linux auth log patterns (named)
sshd: Failed password, Invalid user, Accepted publickey. sudo: COMMAND= lines for privilege use. PAM: authentication failures and account lockouts. Defender rules: threshold failed ssh from one IP, sudo by unexpected user.
On $SOC_LAB, grep one pattern (Failed password) and note source IP field in YOUR sample.
Command guide
Try these commands — Linux auth log patterns (named)
═══ TOOLS & WEBSITES ═══ Browse / read these (authorized learning only — stay in YOUR lab / program scope)
Linux auth log format — https://man7.org/linux/man-pages/man5/auth.log.5.html MITRE T1078 — https://attack.mitre.org/techniques/T1078/ Elastic sysmon — https://www.elastic.co/guide/en/security/current/prebuilt-rules.html
═══ INSTALL ═══
Linux (Debian/Ubuntu):
Command — copy this
sudo apt install python3
macOS:
Command — copy this
brew install python3
Windows: Download https://python.org/downloads/
═══ LINUX / macOS ═══
Command — copy this
export SOC_LAB=${SOC_LAB:-$HOME/cyberlium-lab/t29-soc}
cat > "$SOC_LAB/logs/linux-auth.sample" <<'EOF'
Aug 22 02:10:01 lab-web sshd[1234]: Failed password for invalid user admin from 203.0.113.77 port 4422 ssh2
Aug 22 02:10:03 lab-web sshd[1234]: Failed password for invalid user admin from 203.0.113.77 port 4422 ssh2
Aug 22 02:11:15 lab-web sshd[1250]: Accepted password for deploy from 10.0.2.20 port 55102 ssh2
Aug 22 02:12:00 lab-web sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/systemctl restart nginx
EOFCommand — copy this
grep 'Failed password' "$SOC_LAB/logs/linux-auth.sample" grep -E '203\.0\.113|Failed' "$SOC_LAB/logs/linux-auth.sample"
Primary tools to practice this lesson: grep, python3. Reference sites: Linux auth log format (https://man7.org/linux/man-pages/man5/auth.log.5.html); MITRE T1078 (https://attack.mitre.org/techniques/T1078/); Elastic sysmon (https://www.elastic.co/guide/en/security/current/prebuilt-rules.html). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Why syslog format varies
Distros and rsyslog templates change field order — L1 learns pattern keywords before assuming fixed columns. UTC timestamps matter for cross-source correlation with Windows auth.
Students document sample line anatomy on lab notes — not production server shell access.
3. Literacy ≠ unauthorized SSH
Forbidden: ssh scanning stranger IPs to 'make auth logs.' Allowed: Linux auth card — three patterns, two defender questions, $SOC_LAB filename.
Ship: Linux auth card for YOUR lab syslog. Next: Network/Proxy Logs.
4. What you ship: Linux auth card for $SOC_LAB
sshd/sudo patterns and defender questions. $SOC_LAB named. NO live scanning. chmod 600.
5. What you record before the next lesson
Date. Linux auth card. $SOC_LAB named. File t29-m04-l02-linux-auth-logs.txt chmod 600.
6. Wrong vs right: stranger SIEM vs YOUR sample logs
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
Wrong
SSH brute force stranger server for log practice. Paste production auth.log without scope.
Right
Write Linux auth card for YOUR $SOC_LAB syslog. Next: Network/Proxy Logs.
Mission: parse Linux auth on YOUR lab syslog
1) Write three sshd patterns to search. 2) Note sudo line purpose. 3) Write count-failures-by-IP question. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Invalid user failures often mean scanning — separate from valid user bad password on lab samples.
Knowledge Check
APPLY: 'Failed password' in auth.log typically comes from:
Multiple choice
Knowledge Check
APPLY: True or False: sudo logs show privileged commands executed.
True or False
Knowledge Check
APPLY: Linux auth literacy on Cyberlium avoids:
Multiple choice