Topic 20 · Deep Dive

20.6 Practical Laboratory Exercises and Rehearsal Workflows

Lane One: Harden a Containerized Web App

Take any small web application and containerize it the unsafe way first -- root user, latest tag, writable filesystem -- then harden it and diff the risk. Pin the base image to a specific version or digest so a future upstream change cannot silently alter behavior. Create a dedicated non-root user inside the image with a COPY or adduser instruction and a USER directive, so a web-shell compromise lands in an unprivileged account. Run the container with a read-only root filesystem, mounting only the paths the app truly writes to as volumes or tmpfs -- this breaks file-drop persistence. Drop Linux capabilities you do not need, keep only what the service requires to bind and read, and add a no-new-privileges flag so suid binaries cannot escalate. Verify from your attacker VM: a successful exploit attempt that once wrote a web shell should now fail on the read-only mount. Record the exact flags and the failed attack output side by side.

Lane Two: Mine Raw Access Logs for Attack Signatures

Generate traffic against your lab web app with a mix of benign browsing and deliberately crafted probes, then analyze the raw access log with text tools -- no SIEM allowed, because raw parsing teaches the signatures. Search for path traversal with a pattern matching dot-dot-slash sequences and encoded variants like %2e%2e%2f; search for SQL injection with patterns for union select, quoted or-true forms, and sleep calls; grep for script tags to surface reflected-XSS attempts. Then pivot from strings to statistics: count requests per source IP, histogram status codes, and look for a 403 burst followed by retries, which betrays an exploratory scanner rather than a user. Time-window the hits, reconstruct the probe sequence per IP, and write the resulting incident note: signature seen, source, timeline, suggested block or rule.

Lane Three: Run a Configuration Baseline Check

Write a small compliance script that asserts a minimal baseline on your defender VM: SSH forbids root login and empty passwords, no world-writable files in system paths, no unexpected setuid binaries, expected service ports only. Emit one PASS or FAIL line per check plus a nonzero exit code on any FAIL, then deliberately break the baseline in a snapshot and rerun to confirm the script catches drift. Repeat it after every experiment; the exit code becomes your lab health signal.

Architecture Diagram

Hardening lane USER + read-only fs Log forensics lane grep + status counts Baseline lane PASS/FAIL script Lab journal host-only lab, no LAN route evidence + next step
Three rehearsable bench lanes -- harden, mine logs, verify baseline -- all terminate in the lab journal entry that makes the result reusable.

Key Takeaways

« Back to Topic 20« 20.5