0:00–0:20
Command Reference
0:20–1:00
Scenario A — SSH & Firewall
1:00–1:40
Scenario B — NTP & Logging
1:40–2:00
Open Lab / Q&A
0:00 – 0:20Command Reference · 20 min
Quick-fire command reference — Weeks 1 and 2
Ask students to supply each command before showing it. The goal is instant recall, not explanation — save the "why" for the scenario walk-throughs.
- Week 1 — SSH:
ssh-keygen -t rsa -b 4096 · sudo sshd -t (always test before restart) · sudo fail2ban-client status sshd
- Week 2 — Packet analysis:
sudo tcpdump -i eth0 -n -s 0 -w capture.pcap · sudo mz eth1 -c 20 -t udp -A [spoofed-src] -B [dst]
- Week 2 — Firewall:
sudo iptables -L -n -v · sudo nft list ruleset · sudo ufw status numbered
- Week 2 — NTP/Logging:
sudo ntpq -p · timedatectl timesync-status · sudo journalctl -u rsyslog -n 20
0:20 – 1:00Scenario Walk-through A · 40 min
SSH lockout and firewall rule ordering — the two mistakes that recur every term
- Scenario 1: "A student sets PasswordAuthentication no and restarts sshd before confirming their key works. They are now disconnected." Walk through why this happens, and why the correct order is always: install the key, test the key in a second session, then disable password auth — never in the same session you might lose.
- Scenario 2: Put a two-rule iptables sequence on the board where a DROP-all rule precedes a more specific ACCEPT rule for the same protocol. Ask: does the ACCEPT ever fire? Reinforce that firewall rules are evaluated top-to-bottom and the first match wins — order is not cosmetic, it's the whole rule.
- Discussion: Why fail2ban is a second layer, not a replacement for key-based auth — it slows down brute force, but a stolen valid key defeats it entirely.
1:00 – 1:40Scenario Walk-through B · 40 min
Reading an ntpq -p table and diagnosing a broken rsyslog forward
- ntpq -p interpretation drill: Put a sample ntpq -p table on the board. Ask students to identify: which line is the active sync source (the * prefix), what the refid column tells you, and what a reach value of 177 (octal) versus 377 means.
- rsyslog forwarding diagnosis: A student reports that S2's auth events aren't appearing on S1. Walk through the diagnostic sequence live: is rsyslog running on both ends (systemctl status rsyslog), is the forwarding line present and syntactically correct in 50-default.conf, is the firewall on S1 allowing UDP 514 from S2, and does a test event (logger "test") actually appear.
- Key habit reinforced: Check the log, then check the config, then check the network path — in that order. This is the pattern the practical exam rewards.
1:40 – 2:00Open Lab / Q&A · 20 min
Students catch up on any outstanding Week 1–2 lab work
Circulate and help with anything from Lab 0, Lab 1B, or Labs 2A–2D that isn't finished. If everyone is caught up, use the time for open questions on SSH, tcpdump, firewalling, NTP, or rsyslog.
Instructor note: Keep a running list on the board of questions students ask across the week — it's a useful signal for what to spend more time on during Tuesday and Wednesday's walk-throughs.