Blue Team Ops, 2004

What you will do

1. read the raw authentication log cat /var/log/auth.log

   auth.log (Debian/Ubuntu) or /var/log/secure (RHEL) records every login, sudo call and PAM event. It is the first place a defender looks.

2. view just the most recent log lines tail -n 10 /var/log/auth.log

   A live incident is almost always in the LAST few lines. tail -f would follow it in real time — here, -n 10 is the freeze-frame version.

3. filter the log to failed login attempts only grep "Failed password" /var/log/auth.log

   grep (1974, Bell Labs) turns a wall of text into a signal. "Failed password" is sshd's exact string for a rejected credential — the first pattern every blue teamer memorizes.

4. filter the log to successful logins only grep "Accepted password" /var/log/auth.log

   Every "Accepted" line is a door that opened. Cross-reference it against who SHOULD have been logging in at that time — that gap is where breaches hide.

5. find every privilege-escalation event in the log grep sudo /var/log/auth.log

   Every sudo call is logged with the acting user, the target user and the exact command — an audit trail purpose-built for "who did that, and as whom."

6. use awk to pull just the timestamp fields out of every line awk '{print $1, $2, $3}' /var/log/auth.log

   awk (Aho, Weinberger, Kernighan, 1977) thinks in whitespace-separated fields — $1 $2 $3 ... $NF. grep finds the lines; awk reshapes what is inside them.

7. query the systemd journal for one specific service journalctl -u sshd

   On a systemd host, journalctl -u <unit> is the modern equivalent of grepping a flat logfile — structured, indexed, and it survives log rotation.

8. check whether the host firewall is on, and what it allows ufw status

   ufw ("Uncomplicated Firewall", Ubuntu, 2008) is a friendly front end over the kernel's netfilter/iptables — the same enforcement engine, an easier command set.

9. explicitly allow SSH through the firewall ufw allow 22/tcp

   Default-deny is the core of host hardening: block everything, then allow exactly the ports the box needs to serve — nothing implicit, nothing assumed.

10. explicitly block an insecure legacy port (Telnet) ufw deny 23/tcp

    Telnet (RFC 854, 1973) sends credentials in plaintext. Blocking port 23 outright, rather than trusting nobody uses it, is defense in depth.

11. turn the firewall on and make it persistent across reboots ufw enable

    Rules configured but not enabled protect nothing. A firewall you forgot to enable is functionally identical to no firewall at all.

12. read the actual kernel firewall chains ufw is managing underneath iptables -L

    ufw writes rules INTO iptables' INPUT/FORWARD/OUTPUT chains. Reading iptables -L directly shows you the ground truth the kernel is enforcing.

13. list the active fail2ban jails fail2ban-client status

    fail2ban (started 2004) watches log files for repeated-failure patterns and auto-firewalls the offending IP — a firewall that reads logs for you.

14. inspect the sshd jail: failure counts and currently banned IPs fail2ban-client status sshd

    A "jail" is one fail2ban policy: which log to watch, which pattern means a failure, how many failures in what window trigger a ban, and for how long.

15. manually ban an IP through fail2ban, the way an automated jail would fail2ban-client set sshd banip 203.0.113.55

    fail2ban's automatic ban is just this same command, fired by the jail's own log-matching filter instead of a human typing it.

16. read the current SSH daemon configuration cat /etc/ssh/sshd_config

    A fresh sshd install still allows root login and password auth by default on many distros — exactly the two settings a hardening pass fixes first.

17. edit sshd_config: PermitRootLogin no, PasswordAuthentication no sudo nano /etc/ssh/sshd_config

    Disabling root login forces every admin action through a named account plus sudo — an audit trail. Disabling password auth kills brute force outright: there is no password to guess.

18. apply the sshd_config change by restarting the service sudo systemctl restart sshd

    Almost every config-file edit on Linux is inert until the service reloads or restarts and re-reads it from disk. Editing without restarting is a half-finished fix.

19. audit every service currently running on the host systemctl list-units --type=service --state=running

    Every running service is attack surface. A minimal, purpose-built host runs only what it actually needs — auditing the running list is how you find what to cut.

20. stop and permanently disable an unneeded, insecure service sudo systemctl disable --now telnet

    --now stops it immediately AND disables it for next boot in one command — the difference between "off until someone reboots" and actually gone.

21. manually open a TLS connection and inspect the handshake openssl s_client -connect servbg.lan:443

    openssl s_client is the Swiss-army-knife for "is TLS actually working here": it shows the full certificate chain, the negotiated cipher, and the verify result.

22. read a certificate's expiry window and subject (CN) without the raw PEM noise openssl x509 -noout -dates -subject

    An expired certificate is one of the most common self-inflicted outages in the industry. Checking notAfter proactively, before users see a browser warning, is basic operational hygiene.

23. read the sudoers policy — who can run what, as whom sudo cat /etc/sudoers

    /etc/sudoers is unreadable by non-root by design: it is the single file that decides who can become anyone. Guard it accordingly.

24. syntax-check sudoers safely, and spot an over-broad grant visudo -c

    visudo locks the file and validates syntax before saving — a typo in sudoers edited with a plain editor can lock every admin out of sudo, including you.

25. fix the over-broad rule: scope alice to specific commands instead of NOPASSWD: ALL sudo nano /etc/sudoers

    The principle of least privilege: grant exactly the access a role needs to do its job, never "ALL" out of convenience. NOPASSWD: ALL for one user is a standing full-compromise waiting to happen.

26. check one account's password status passwd -S carol

    passwd -S reports locked/usable (L/P) plus password-age fields in one line — the fastest way to audit an account without touching /etc/shadow directly.

27. lock an unused account so it cannot authenticate usermod -L guest

    usermod -L prefixes the password hash so no password will ever match it — the account still exists (for auditing) but is unusable until explicitly unlocked (-U).

28. review recent successful logins last

    last reads /var/log/wtmp — every session, who, from where, how long. It answers "who has actually been on this box lately," not just "who is allowed to be."

29. review recent FAILED login attempts lastb

    lastb reads /var/log/btmp, the failure twin of wtmp. A pile of failed attempts from one address, clustered in time, is the classic brute-force fingerprint.

30. review the ordered incident-response checklist before the boss scenario triage

    Security Operations, in one sentence: identify what happened, contain it, remediate the root cause, then document it — in that order, every time.

31. load the boss scenario — a live brute-force intrusion scenario start

    Everything above was practice. This is the job: a real (simulated) log, a real decision to make, under time pressure.

32. chain grep, awk, sort and uniq to rank source IPs by failed-login volume and find the attacker grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn

    This exact pipeline (filter, extract a field, sort, count duplicates, sort by count) is one of the most common one-liners in real incident response.

33. CONTAIN — block the attacking IP at the firewall ufw deny from 198.51.100.230

    Containment first, always: stop the bleeding before you diagnose the wound further. A banned IP cannot keep trying passwords while you investigate the rest.

34. CONTAIN — lock the compromised account so the attacker's foothold is cut off usermod -L svc_backup

    A successful login means that account is burned until proven otherwise — lock it immediately, investigate what it touched, and only unlock after a credential reset.

35. Boss missionFINAL STEP — file the incident report once the IP is banned, the account is locked, and sshd is hardened report

    Identify (the log + the pipeline), contain (ban + lock), remediate (harden sshd against the next attempt), document (this report). That four-step loop is the entire job.

Certificate

Nearby eras

All 25 eras in the Terminal Academy