Was ist das hier?

Origin whitelist, Auth, Rate-Limits, sichere Headers. (Operator Guide für AWS Lightsail).

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)?

Origin-Check (Nginx Snippet)

# Block wildcard origins, allow only your domain
if ($http_origin !~* ^https://(www.)?deine-domain.com$) { return 403; }

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

• Origin strikt whitelisten (kein * / wildcard).
• Auth auf WS Handshake (token/cookie) erzwingen.
• Rate limits: connect rate + msg rate + concurrent connections.
• Proxy/WAF: Upgrade headers + timeouts korrekt setzen.
• Verifikation: disallowed Origin → 403, allowed Origin → OK.

Verifikation

aws sts get-caller-identity
aws ec2 describe-security-groups --max-items 5

aws cloudtrail lookup-events --max-results 10

Prävention / Guardrails

• CloudTrail aktiv + Alerts auf IAM-Key-Erstellung & Policy-Änderungen
• Security Groups: default-deny, nur benötigte Ports/Quellen
• Keys in Secrets Manager statt .env / Git

Warnungen

• Keys zuerst rotieren, dann forensisch arbeiten (Stop the bleeding).

Was andere Tools nicht sagen

Die meisten Guides zeigen nur den Happy Path. Was wirklich wichtig ist: Origin whitelist, Auth, Rate-Limits, sichere Headers. (Operator Guide für AWS Lightsail). – 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.