Week 1 Day 5 — NETW-0014 Advanced Operating Systems

0:00–0:30
fail2ban

0:30–1:00
Written

1:00–1:45
Practical

1:45–2:00
Review + Preview

Before 0:00 Instructor setup

Classroom setup before students arrive

Written assessment sheets printed and placed face-down on each desk. Students should not see them until instructed.
Practical scenario prepared — either printed face-down or ready to distribute digitally after the written portion. The practical requires each student to have a running VM (S1 minimum).
Write on the board: fail2ban lab — 30 min (open book). Written — 30 min, no computer. Practical — 45 min, S1 only, man pages allowed, no internet.

0:00 – 0:30 fail2ban lab · 30 min · open book

Install fail2ban, configure an SSH jail, trigger and verify a ban

What fail2ban does

fail2ban is a log-monitoring daemon. It watches specified log files for patterns (typically repeated authentication failures) and responds by creating temporary firewall rules to block the offending IP. For SSH, it watches /var/log/auth.log. After a configurable number of failed attempts within a time window, it adds an iptables DROP rule for that source IP.
Key configuration terms: jail — a named configuration block that monitors a specific service. filter — the regex patterns that define what constitutes a failure. bantime — how long the block lasts (seconds). findtime — the window in which failures are counted. maxretry — the number of failures that triggers a ban.

Step 1 — Install and verify (5 min)

sudo apt install fail2ban. Verify it's running: sudo systemctl status fail2ban. Check the default jails that ship with it: sudo fail2ban-client status.

Step 2 — Create jail.local (10 min)

fail2ban uses two config files: jail.conf (default, never edit directly — it gets overwritten on updates) and jail.local (your local overrides — create this). Create the file:
sudo nano /etc/fail2ban/jail.local
Add the following:
[DEFAULT]
bantime = 600
findtime = 300
maxretry = 5

[sshd]
enabled = true
port = 2222
logpath = /var/log/auth.log
maxretry = 5
(Replace 2222 with your actual SSH port if different.)
Restart fail2ban: sudo systemctl restart fail2ban. Verify the sshd jail is active: sudo fail2ban-client status sshd. You should see the jail is active with 0 currently banned IPs.

Step 3 — Trigger and verify a ban (15 min)

From Windows, attempt SSH to S1 five times with a wrong password (use -o PubkeyAuthentication=no to force password auth). After five failures, further connection attempts should hang or be immediately refused.
On S1, check the ban: sudo fail2ban-client status sshd — your Windows host IP should appear in the "Banned IP list". Check the fail2ban log: sudo tail /var/log/fail2ban.log — you should see the ban event with timestamp and banned IP.
Unban yourself to restore access: sudo fail2ban-client set sshd unbanip [your-windows-ip]. Verify you can SSH again. Record the ban and unban log entries in your lab sheet.

Instructor note: The fail2ban lab is brief by design — it leads directly into the assessment. Students who finish the ban/unban cycle early can experiment with different bantime values (e.g., 60 seconds for faster testing). Have them check iptables -L -n during an active ban to see the DROP rule fail2ban creates.

0:30 – 1:00 Written assessment · 30 min · 30% of Mini-Assessment 1

Written portion — SSH theory, sshd_config directives, fail2ban concepts

Pen and paper. No computer, no phone, no notes. 30 minutes. Distribute sheets face-up when instructed.

Section A — Short answer (15 marks)

Q1 (3 marks): Explain how SSH key authentication works. Your answer must describe the role of both the public and private key, and explain what travels over the network during authentication.
Q2 (2 marks): A student generates an SSH key pair and copies the file id_rsa to the server's authorized_keys file. Key auth does not work. Identify the mistake and explain the correct action.
Q3 (2 marks): What is the purpose of the AllowUsers directive in sshd_config? Give an example of when you would use it.
Q4 (2 marks): A student sets PasswordAuthentication no in sshd_config but password logins still work. Name two possible reasons why.
Q5 (3 marks): Explain the difference between the SSH Banner (/etc/ssh_banner) and the MOTD (/etc/motd). When does each appear during an SSH connection?
Q6 (3 marks): Describe how fail2ban protects an SSH server. Your answer must mention: what it monitors, what triggers a ban, and how the ban is enforced at the network level.

Section B — Scenario (10 marks)

Q7 (4 marks): You have inherited a Linux server with the following sshd_config settings. For each setting, state whether it is a security concern and briefly explain why:
· PasswordAuthentication yes
· PermitRootLogin yes
· LoginGraceTime 0
· Port 22
Q8 (3 marks): A fail2ban jail is configured with bantime = 300, findtime = 60, maxretry = 3. An attacker makes 2 failed attempts, waits 65 seconds, then makes 2 more failed attempts. Is the attacker banned? Explain your reasoning.
Q9 (3 marks): You need S1 to route internet traffic for S2. List the two configuration steps required on S1, and explain what each step does.

1:00 – 1:45 Practical assessment · 45 min · 70% of Mini-Assessment 1

Practical — diagnose and repair a broken SSH configuration

Students receive access to S1 via the Hyper-V console (no SSH — that's part of what's broken). They must diagnose and repair the SSH configuration so that key-based authentication works, then demonstrate each hardening setting is in place. No notes, no internet. Man pages (man sshd_config, man fail2ban) are allowed.

Practical scenario — instructor setup

Before the practical begins, make the following deliberate errors to each student's S1 (or use a pre-prepared assessment VM):
· SSH port changed to 9999 (students must find and restore it to their correct port)
· PasswordAuthentication yes re-enabled
· AllowUsers root (wrong user, locks out the student account)
· authorized_keys permissions changed to 644 (key auth silently fails)
· fail2ban stopped and disabled

Practical tasks (students are graded on these)

Task 1 (15 marks): Restore SSH access from Windows Terminal — key-based auth must work on the correct port. Show the instructor a successful key-based connection.
Task 2 (10 marks): Demonstrate that password authentication is disabled. Show the instructor the rejection message when attempting a password connection.
Task 3 (10 marks): Restore the remaining hardening settings (LoginGraceTime, MaxAuthTries, AllowUsers student, PermitRootLogin no). Show sshd_config to instructor.
Task 4 (15 marks): Restart and verify fail2ban. Trigger a ban, show the instructor the active ban with fail2ban-client status sshd, then unban the IP and restore access.

1:45 – 2:00 Review + Week 2 Preview · 15 min

Review the most commonly missed written questions. Q4 (why password auth still works after setting it to no) catches students every time — the sshd_config.d drop-in directory is the answer in Ubuntu 22+.
Ask: "The servers are now locked down for access. But we haven't thought at all about what's happening on the network. What kind of traffic is flowing between these servers right now? How would you find out?" — Preview Week 2: tcpdump, packet capture, and Mausezahn. We switch from access security to network visibility.
Remind students: all three VMs must be fully functional (SSH, key auth, NAT routing) before Week 2 begins. Anyone with outstanding lab work should finish it before Monday.

Mini-Assessment 1 — marking summary

Component	Format	Weight	Key topics
Written — Section A	Short answer	15 marks (30%)	Key cryptography, sshd_config directives, fail2ban mechanism, banners
Written — Section B	Scenario analysis	10 marks (30%)	Config vulnerability identification, fail2ban logic, NAT routing requirements
Practical — Task 1	Live demonstration	15 marks (70%)	Restore key-based SSH access on correct port
Practical — Task 2	Live demonstration	10 marks (70%)	Verify password auth disabled
Practical — Task 3	Config review	10 marks (70%)	All hardening directives correctly set
Practical — Task 4	Live demonstration	15 marks (70%)	fail2ban operational, ban triggered and cleared

← Day 4 Week 1 Overview Week 2 →