Skip to main content

Monitoring and response

Monitoring​

What's actually running is Beszel (stats) and Uptime Kuma (availability), plus SSH rate-limiting/banning via fail2ban — see Securing the system → Rate limiting. Nothing beyond that is set up. A deliberate gap for now, not an oversight — the options were evaluated (see Monitoring in the catalog: CrowdSec, Wazuh, OpenObserve) and left for later, split into what's actually still missing:

  • Intrusion/log-pattern detection — fail2ban only counts SSH failures within one narrow rule; nothing watches for broader attack patterns, and nothing watches HTTP traffic at all. CrowdSec or OpenObserve (with hand-written alert rules) would close this.
  • Active blocking on HTTP — separate from detection: even with visibility, nothing currently bans an abusive HTTP source the way fail2ban does for SSH. Traefik's own RateLimit/InFlightReq middleware, or a CrowdSec bouncer, would close this — deliberately deferred regardless of the detection choice, since blocking rules are only worth setting once there's real traffic data to calibrate them against, not guessed thresholds.
  • File-integrity monitoring — no tool watches for unexpected changes to system binaries or config. AIDE would close this; not yet in the catalog as its own evaluated entry.
  • Cross-service visibility (sites, infra, mail) — logs/metrics/traces beyond Beszel's host stats, and RUM for anything web-facing (WordPress, etc.). OpenObserve is the candidate if this becomes a real want, on its own merits, not just to close the security gap above.

Revisit before anything genuinely public-facing goes live (WordPress, mail) — that's specifically what draws the automated attack traffic these gaps matter most against.

Response to a breach​

Not a config line — a decision to actually make and write down: if this box is ever suspected compromised, rebuild, don't clean a live box. Two pieces make that a real recovery plan, not just a wish:

  • The box itself — OpenTofu reprovisions it from scratch, so there's nothing to salvage from a compromised instance in the first place.
  • Service data — Backups is what makes that rebuild not also a data-loss event: restore each service from its S3 backup onto the freshly rebuilt box, rather than needing the original instance to survive at all.

Rebuild without a working restore path is just reinstalling with nothing in it — the two only add up to an actual recovery together.