A smaller attack surface.
A synthetic application ran as root, had broadly readable configuration, permissive SSH settings, and an unnecessary exposed service.
The constraints shape the system.
Local Ubuntu/WSL2 execution with isolated server and client namespaces. Changes had to preserve the three-record application and retain a tested rollback path.
The implementation.
- Capture a baseline before touching access or application configuration.
- Introduce a dedicated service identity and private 0600 configuration.
- Verify key-only SSH, firewall denial, and application behavior from an isolated owned peer.
- Exercise a safe failed-login test, backup integrity checks, and rollback.
What the checks showed.
RECORDED LAB OUTCOME
Two open tested ports were reduced to one. A controlled failed-login test triggered a real Fail2ban ban. The application stayed healthy and final host checks passed.
What this result means.
This was a local lab, not a production or Proxmox deployment. Same-disk backups and local health logs remained limitations.
What I would improve.
Off-host backups and external health reporting would reduce dependence on the host. Hardening needs repeated verification after application or operating-system changes.
Inspect the work.
Read the original case study, browse the preserved evidence, or inspect the implementation repository.
Related service: Linux & Systems. A production engagement starts with your actual workload, risks, and acceptance criteria.