linux-server-hardening

Interactive Ubuntu golden-path hardening CLI — born from a real production VPS mission (ZENORA), industrialized for the next ones.

Not a silent magic one-liner. An operator-in-the-loop accelerator: prompts first, ordered phases second, checkpoints before anything that can lock you out.

---

Why this exists

Replaying a 12-phase fortress by hand on every client VPS is slow and forgetful. This repository encodes that battlefield-proven path as a modular Bash product:

• Core always on: SSH fortress, patches, unattended-upgrades, sysctl, UFW, Fail2Ban, AIDE/Lynis baseline, NTP, ops finalize
• Optional on demand: Docker, Nginx, Naxsi, CSF, CrowdSec, Cloudflare helpers, monitoring
• Anti-lockout first: dual-port SSH cutover, sshd -T asserts, automatic rollback
• Resumable & auditable: state files, safe config export, timestamped logs, backup manifests
• Honest dry-run / doctor: no fake “done” markers; reports measure effective state

Origin mission: ZENORA Ubuntu production hardening. Product id in the author portfolio: interactive script industrialization of that runbook.

---

Quick start

git clone https://github.com/barthez-kenwou/linux-server-hardening.git
cd linux-server-hardening
sudo ./harden.sh

Useful variants:

sudo ./harden.sh --profile web          # Nginx + CrowdSec + Cloudflare helpers
sudo ./harden.sh --profile fortress     # Full stack including CSF + Docker
sudo ./harden.sh --profile minimal      # Bastion-style core only
sudo ./harden.sh --dry-run --profile web --show-plan
sudo ./harden.sh --resume               # After reboot / interrupted run
sudo ./harden.sh --doctor               # Effective posture diagnostics
sudo ./harden.sh --rollback ssh         # Restore SSH from latest backup

---

Requirements

Item	Requirement
OS	Ubuntu 22.04 or 24.04 LTS
Privileges	root / sudo
Access	Working SSH (or console) before lockdown
Network	Outbound HTTPS for package / CrowdSec / CSF downloads
Operator	Human judgment — this tool assists, it does not replace you

---

Architecture (short)

CLI splash → preflight → interactive interview
        ↓
 ordered modules (core + selected optionals)
        ↓
 backups + logs + exported config + final report

Layer	Modules
Core	baseline, SSH, updates, unattended-upgrades, tools, NTP, sysctl, UFW, iptables extras, Fail2Ban, AIDE/Lynis, ops finalize
Optional	Docker, Nginx, Naxsi, CSF, CrowdSec, Cloudflare, monitoring

Deep dive: docs/ARCHITECTURE.md · phase map: docs/PHASES.md · anti-lockout: docs/ANTI_LOCKOUT.md

---

Interactive interview

The script asks (with short necessity briefs):

1. Profile (minimal / web / fortress / custom)
2. Hostname & timezone
3. Admin SSH usernames (AllowUsers)
4. SSH port
5. Alert email (AIDE / reports)
6. Trusted admin IP/CIDR
7. Optional modules: Docker, Nginx (+ Naxsi), CSF, CrowdSec, Cloudflare, monitoring

Silent installs that “assume fortress” are how people brick production. Defaults stay conservative; optionals are opt-in.

---

Project layout

harden.sh                 # Entry point
lib/                      # UI, prompts, logging, system helpers
modules/                  # Ordered phase implementations
templates/                # sshd, sysctl, fail2ban, nginx, monit, …
profiles/                 # minimal | web | fortress
config/                   # Documented default knobs
docs/                     # English documentation
scripts/doctor.sh         # Health / posture check
tests/syntax-check.sh     # bash -n across the tree

---

Safety model

• Config files are backed up under backups/<timestamp>/ with a MANIFEST.txt
• SSH uses dual-port listen → proven second session → final lockdown → sshd -T asserts
• Failed SSH cutover triggers --rollback ssh automatically
• UFW enable and CSF production cutover require typing YES; CSF reload is verified before disabling UFW
• --dry-run does not write to /etc, state/, or backups/
• --non-interactive refuses critical steps unless --force-yes (explicit foot-gun)
• Profiles / last-run files are parsed as KEY=value — they are never sourced as shell

---

Customization

• Edit templates in templates/
• Add a profile under profiles/myorg.conf and run --profile myorg
• Pass --config path/to/file.conf for automation labs
• See docs/CUSTOMIZATION.md and docs/MODULES.md

---

Validation status

Validated on clean lab VMs, local Ubuntu environments, and real friend VPS runs — enough confidence for missions, enough humility to keep prompts and checkpoints.

This is not a substitute for human judgment on critical production.

---

Documentation

Doc	Topic
ARCHITECTURE.md	Design, flow, module contracts
PHASES.md	Golden-path phase map
ANTI_LOCKOUT.md	SSH / FW lockout prevention
MODULES.md	Per-module reference
CUSTOMIZATION.md	Profiles, templates, hooks
OPERATIONS.md	Day-2 supervision
TROUBLESHOOTING.md	Common failures
SECURITY.md	Vulnerability reporting
CONTRIBUTING.md	Contribution guide

---

License

MIT © Barthez Kenwou

---

Credits

• Field origin: ZENORA Ubuntu VPS hardening mission
• Productization: this repository — interactive golden path for future client missions