Fail2ban and Unattended Upgrades
Fail2ban and Unattended Upgrades
Migration in progress.
api.legendary-arena.comand its PostgreSQL are moving off Render onto a self-hosted DigitalOcean Ubuntu droplet fronted by Cloudflare, perdocs/PLAN.md. Until decommission, Render stays warm as the rollback target.
Summary
This step installs and enables fail2ban to auto-ban SSH brute-force attempts and configures unattended-upgrades to apply security patches daily. It is the Phase 1 hardening step that shifts ongoing patch responsibility from Render onto the self-hosted host.
Mechanics
The entity is owned by infra/scripts/07-fail2ban-upgrades.ps1
, an idempotent PowerShell provisioner that runs under Set-StrictMode -Version Latest and $ErrorActionPreference = 'Stop' and requires root (per docs/PLAN.md
).
- Root gate.
Require-Rootensures the process is uid 0. - Install.
apt-get update, thenapt-get install -y fail2ban unattended-upgrades apt-listchanges. - Enable fail2ban.
systemctl enable --now fail2banstarts and persists the service, which bans SSH brute-force via its default jail. - Auto-upgrade config. Writes
/etc/apt/apt.conf.d/20auto-upgradeswithAPT::Periodic::Update-Package-Lists "1";andAPT::Periodic::Unattended-Upgrade "1";— daily package-list refresh and unattended security upgrades. - Enable unattended-upgrades.
systemctl enable --now unattended-upgradesstarts and persists the upgrade service.
It is idempotent because apt-get install is a no-op on already-installed packages and the config write plus enable --now are declarative.
Interactions
- SSH Hardening . Complementary host-security layer — SSH Hardening removes password/root login while fail2ban bans repeated brute-force attempts against the remaining key-only daemon.
- UFW Firewall . The third layer of the same posture — UFW closes unlisted ports, fail2ban polices the allowed SSH port, and unattended-upgrades keeps the host patched.
- Systemd Service . Reboot survival matters here: an unattended upgrade may want a reboot, and the la-server systemd unit is what brings the API back afterward.
Edge Cases
- Upgrade-triggered reboot. Unattended-upgrades can pull a kernel or security update that wants a reboot. The box must come back cleanly; confirm the auto-reboot policy is what you want and that Systemd Service restores the API on boot.
- Patching is now your responsibility. On Render the platform handled patching; on the self-hosted droplet this service is the whole story. If it is disabled or fails, the host silently falls behind on security fixes.
- Default jail assumes standard SSH logging. fail2ban’s default jail watches the standard SSH log path; a non-standard SSH setup can leave the jail watching the wrong source and silently ineffective.
- Reboot without service recovery. If an upgrade reboots the host but the la-server unit is not enabled, the API stays down — pair this step with Systemd Service .
Execute
sudo pwsh -File infra/scripts/07-fail2ban-upgrades.ps1
Verify
sudo fail2ban-client status
# expected: lists active jail(s), including the sshd jail
systemctl status unattended-upgrades --no-pager
# expected: Active: active (running) — or the enabled/loaded unit
References
- infra/scripts/07-fail2ban-upgrades.ps1 — the owning provisioner
- docs/PLAN.md — Phase 1 hardening and script conventions