Angriff im Gange?

Doku — so funktioniert der Edge

Kein Beiwerk — nur das, was Sie brauchen, um eine Domain anzubinden und zu verstehen, was mit einer Anfrage passiert, sobald sie unseren Edge erreicht.

Erste Schritte

Die Anbindung ist eine DNS-Änderung, keine Migration. Ihr Origin-Server bleibt genau dort, wo er heute ist.

  1. Fügen Sie Ihre Domain im Portal hinzu.
  2. Zeigen Sie ihren DNS-Eintrag (einen A/AAAA-Eintrag oder einen CNAME) auf die Edge-Adresse, die das Portal Ihnen nennt.
  3. Sobald das DNS propagiert ist, läuft der Live-Verkehr über DNS → Edge (WAF) → Ihr Origin. Wir filtern jede Anfrage und leiten die sauberen weiter.

Wir binden frühe Kunden manuell an — wenn an Ihrem Setup etwas ungewöhnlich ist, geht ein Mensch es mit Ihnen durch, bevor Sie das DNS umstellen.

Was OWASP CRS 4.26 abdeckt

Der Edge führt das OWASP Core Rule Set v4.26.0 auf der Coraza-Engine aus. Zwei Coraza-Builds liegen in einem Edge-Image — eine proxy-wasm-Engine und eine libcoraza-FFI-Engine — und die Engine wird pro Route gewählt, sodass das Tuning einer Site nie eine andere stört.

CRS ist ein Regelwerk mit Anomalie-Scoring. Statt dass eine einzelne Regel über Durchlassen oder Blockieren entscheidet, summiert es Signale über die Anfrage hinweg (verdächtige Pfade, Injection-Muster, Protokoll-Anomalien) und handelt nach der Summe. Genau das macht die gängigen Angriffsklassen — SQL-Injection, Cross-Site-Scripting, Path Traversal, Remote-File-Inclusion — greifbar und hält die Fehlalarmschwelle einstellbar, statt dass Sie gegen sie ankämpfen.

Die Challenge-Leiter

Nicht jede verdächtige Anfrage sollte sofort blockiert werden, und nicht jeder Besucher sollte Reibung erleben. Wenn die Signale es rechtfertigen, eskaliert der Edge über eine Leiter, statt direkt zu blockieren:

  1. Proof-of-Work — eine leichte Rechenaufgabe, für normale Browser unsichtbar, die automatisierte Clients echte CPU kostet.
  2. CAPTCHA — eine einbindbare interaktive Prüfung (Turnstile oder hCaptcha) für Fälle, die die Proof-of-Work-Stufe nicht klärt.
  3. Web Bot Auth — kryptografische Bot-Verifikation über HTTP-Message-Signatures nach RFC 9421 mit Ed25519-Schlüsseln, sodass ein legitimer, deklarierter Bot beweisen kann, wer er ist, statt geprüft zu werden.

Jede Stufe ist optional und greift nur dort, wo Sie sie aktivieren — der Standardpfad bleibt reibungsfrei.

Zertifikate

TLS übernehmen wir. Jeder Tenant erhält am Edge über das nginx-acme-Modul sein eigenes Let’s Encrypt-Zertifikat, und die Erneuerung erfolgt automatisch. Sie laden nie einen privaten Schlüssel hoch und führen keinen certbot-Befehl aus — Ausstellung und Rotation leben am Edge, weshalb LE-Privatschlüssel ihn auch nie verlassen.

Häufige Fragen

Muss ich mein Hosting umziehen, um Smart WAF zu nutzen?

Nein. Ihr Origin-Server bleibt, wo er ist. Sie ändern nur das DNS, damit der Verkehr zuerst über unseren Edge läuft; wir filtern ihn und leiten die sauberen Anfragen an Ihren bestehenden Server weiter.

Welches WAF-Regelwerk setzen Sie ein?

OWASP Core Rule Set v4.26.0, ausgeführt auf der Coraza-Engine. CRS arbeitet mit Anomalie-Scoring: Es summiert Signale über eine Anfrage hinweg, statt auf einer einzelnen Regel auszulösen, wodurch die Fehlalarmschwelle einstellbar bleibt.

Wie viel Latenz fügt die WAF hinzu?

Wir entwickeln gegen ein Budget von ≤5 ms zusätzlicher Latenz bei normalem Verkehr. Das ist ein Design-Ziel; Benchmarks auf Produktions-Hardware laufen noch, und jede gemessene Zahl, die wir veröffentlichen, ist mit ihrer Umgebung gekennzeichnet.

Wer verwaltet das TLS-Zertifikat?

Wir. Jeder Tenant erhält sein eigenes Let's-Encrypt-Zertifikat, das am Edge automatisch ausgestellt und erneuert wird — Sie laden keine Schlüssel hoch und rotieren sie nicht selbst.