Labs · Cyber Security

Lab: Mini Capstone: Harden, Monitor and Back Up One Lab Server End to End, Then Prove Every Control Works

By Ravindra Bagale · Last updated: 8 October 2026

Suppose we are…

Suppose we have just been hired as a junior security engineer at Nykaa, and our manager hands us one new Ubuntu server: "Make it production-ready. Harden it, make sure we would notice an intruder, make sure we can recover it, and show me proof for each." This capstone is that first assignment, done on our own lab VM.

Goal of this lab

By the end you will have one Ubuntu VM with:

• Harden: all updates, automatic security updates, key-only SSH, no root login, UFW, fail2ban, no extra sudo or SUID (Labs 23, 26, 32).
• Monitor: auditd watching identity, sudoers and SSH config (Lab 36).
• Back up: a daily compressed backup of /etc and /var/www with 7-day retention, and a successful restore test.
• A one-page scorecard: control, command used to verify, result, date.

What you need (all free)

• A fresh snapshot of your own Ubuntu Server VM (take one named before-capstone), reachable over SSH from your laptop.
• Notes from Labs 23, 26, 32 and 36. About 90 minutes; you can split it over two days.

Part 1: harden (hints, details are in the earlier labs)

1. Updates and automatic security updates (Lab 23):

   sudo apt update && sudo apt upgrade -y && sudo apt install -y unattended-upgrades
   

2. Key-only SSH and no root login with /etc/ssh/sshd_config.d/10-keys-only.conf, tested with sshd -t and a second session (Lab 32).

3. UFW: allow OpenSSH (and Nginx Full if you run a web server), default deny incoming, enable (Lab 32).
4. fail2ban sshd jail with jail.local, test ban and unban 203.0.113.9 (Lab 32).
5. sudo and SUID review: getent group sudo, sudo grep -rn NOPASSWD /etc/sudoers /etc/sudoers.d/, save ~/suid-baseline.txt (Lab 26).

Part 2: monitor

6. auditd with /etc/audit/rules.d/lab.rules for identity, sudoers and sshd_config, loaded with augenrules --load (Lab 36).
7. Trigger one safe event (sudo touch /etc/ssh/sshd_config) and find it with sudo ausearch -k sshd_config -i | tail -n 5.

Part 3: back up and restore

8. Create a backup folder only root can read:

   sudo mkdir -p /root/backups && sudo chmod 700 /root/backups
   

9. Create the backup script:

   sudo tee /usr/local/sbin/daily-backup.sh > /dev/null <<'SCRIPT'
   #!/bin/bash
   set -euo pipefail
   D=$(date +%F)
   tar -czf /root/backups/server-$D.tgz /etc /var/www 2>/dev/null || tar -czf /root/backups/server-$D.tgz /etc
   find /root/backups -name 'server-*.tgz' -mtime +7 -delete
   SCRIPT
   sudo chmod 700 /usr/local/sbin/daily-backup.sh
   sudo /usr/local/sbin/daily-backup.sh && sudo ls -lh /root/backups
   

   👁 What you should see: a file like server-2026-10-08.tgz of a few MB.

10. Schedule it every day at 02:30 (server time):

    echo "30 2 * * * root /usr/local/sbin/daily-backup.sh" | sudo tee /etc/cron.d/daily-backup
    

11. Restore test. A backup is only real when a restore works. Extract to a test folder and compare one file:

    sudo mkdir -p /tmp/restore-test
    sudo tar -xzf /root/backups/server-$(date +%F).tgz -C /tmp/restore-test etc/ssh/sshd_config.d
    sudo diff -r /etc/ssh/sshd_config.d /tmp/restore-test/etc/ssh/sshd_config.d && echo "RESTORE OK"
    

    👁 What you should see: RESTORE OK.

12. Copy the backup off the server (a backup on the same disk dies with the disk). On the server, hand a copy to your user; then download it from your laptop and remove the copy:

    sudo install -m 600 -o $USER /root/backups/server-$(date +%F).tgz ~/server-backup.tgz
    

    From your laptop: scp student@<vm-ip>:server-backup.tgz ., then on the server rm ~/server-backup.tgz.

Part 4: prove it (the scorecard)

13. Run each check and fill the scorecard with Control, Verify command, Expected, Result, Date:

    apt list --upgradable 2>/dev/null | wc -l          # expect 1 (only the "Listing..." line)
    sudo sshd -T | grep -E "passwordauthentication|permitrootlogin"   # expect no / no
    sudo ufw status | head -n 1                       # expect Status: active
    sudo fail2ban-client status sshd | grep "Currently banned"
    sudo auditctl -l | wc -l                          # expect 5 or more
    sudo ls /root/backups                             # expect today's file
    

    👁 What you should see: every line matches the expected value. Anything that does not is your to-do list.

14. Final test from your laptop: ssh -o PubkeyAuthentication=no student@<vm-ip> must fail with Permission denied (publickey), and your normal key login must work.

Common mistakes

Self-check checklist

Try-at-home challenge

Write the recovery steps (a "runbook") for this situation: the VM's disk is lost and you must rebuild the server from a fresh Ubuntu install and your off-server backup. What are the steps, and how long would they take?

Samjla ka? Harden, monitor, back up, restore, prove it on one page. Aata pudhe jaauya: Chapter 46 prepares you to explain all this in an interview.