Was ist das hier?

Default deny, minimal offene Ports, sichere Defaults. (Operator Guide für Cloudflare).

Schnell‑Triage (5 Minuten)

• Was ist exponiert (Ports, Admin, Webhooks, Origins, Buckets)?
• Sind gerade Anomalien sichtbar (Spikes, 4xx/5xx, Login‑Fehler, Bot‑Traffic)?
• Sind Secrets/Keys kompromittiert (Repo, CI, Logs, Chat)?

Minimal-Regeln (UFW Beispiel)

ufw default deny incoming
ufw default allow outgoing
ufw allow 80/tcp
ufw allow 443/tcp
# SSH: lieber nur via VPN / Allowlist
# ufw allow from <your-ip> to any port 22 proto tcp
ufw enable
ufw status verbose

Fix‑Schritte (Copy/Paste‑fähig)

• Default deny inbound, allow established/related.
• Nur notwendige Ports öffnen (typisch: 80/443, evtl. 22 via VPN/Allowlist).
• Admin-Ports (DB/Redis) niemals public.
• Logging an: dropped packets zählen (Abuse erkennen).
• Verifikation: extern portscan, intern healthchecks.

Verifikation

Cloudflare Dashboard → Security → Events (WAF / Rate Limiting / Bot)

Cloudflare → Analytics → Traffic (spikes / geo / user agents)

Prävention / Guardrails

• Managed WAF Rules baseline
• Rate Limits auf Login/Webhooks
• Bot protection aktivieren

Warnungen

• WAF kann legitime Requests blocken: verifiziere per Security Events.

Was andere Tools nicht sagen

Die meisten Guides zeigen nur den Happy Path. Was wirklich wichtig ist: Default deny, minimal offene Ports, sichere Defaults. (Operator Guide für Cloudflare). – aber erst nach einem erfolgreichen Smoke Test zählt es als erledigt. Viele Admins vergessen den Rollback-Plan und das Monitoring nach dem Change.

• Defaults allein reichen nicht – ohne Verifikation ist jeder Fix unvollständig.
• Externe Scantools sehen oft nicht den Unterschied zwischen 'konfiguriert' und 'wirksam'.
• Incident-Postmortems zeigen: 60% der Rückfälle entstehen durch fehlende Guardrails, nicht durch falschen Fix.