01
Sicherheitsereignisse als Liste, nicht als Logdatei
Ausgelöste WAF-Regeln stehen mit Site, Regel und Bewertung in der Oberfläche. Ausnahmen werden je Site gepflegt, statt eine Regel global abzuschalten, weil eine einzelne Anwendung sie auslöst.
TLS Zugriffslisten Rate Limiting WAF Cache Lastverteilung Backend
Reverse Proxy, WAF und Cache — zentral verwaltet, verteilt betrieben.
Für Betreiber mehrerer Sites: Backends, Zertifikate und WAF-Regeln liegen in einer Verwaltung, ausgeliefert wird an verteilten Standorten.
Betriebsmodell
Betrieben von ITWorxx. Keine Installation beim Kunden, keine kostenlose Stufe.
Unterschied zum eigenen Stack
Was ein Konfigurationsverzeichnis nicht leistet
Sites, Backends, Zertifikate und Regeln pflegen Sie an einer Stelle — nicht in nginx-Dateien auf einzelnen Maschinen. Ein nginx-Setup kann fachlich dasselbe; der Unterschied liegt darin, was passiert, nachdem die Konfiguration geschrieben wurde.
02
Jede Änderung bleibt nachvollziehbar
Jede Änderung erzeugt eine Revision. Sie vergleichen zwei Stände und aktivieren einen früheren wieder. Eine fehlerhafte Änderung muss nicht aus Backups, alten Konfigurationsdateien oder Chatverläufen rekonstruiert werden.
03
Organisationen statt Dateirechte
Sites, Benutzer und Berechtigungen sind nach Organisation getrennt. Wer mehrere Mandanten oder Kunden betreut, braucht dafür keine getrennten Installationen.
Weg einer Anfrage
Wie eine Anfrage durchläuft
Die Reihenfolge ist festgelegt und für alle Sites gleich. Was Sie je Site einstellen, ist der Inhalt der einzelnen Stufen.
Anfrage
Internet
Standort
Point of Presence
- 01 TLS Verbindung wird terminiert
- 02 Zugriffslisten IP-Bereiche erlauben oder sperren
- 03 Rate Limiting Anfragen je Quelle begrenzen
- 04 WAF Regelwerk prüft die Anfrage
- 05 Cache Treffer wird direkt beantwortet
Verteilung
Lastverteilung
Wählt ein Backend nach dem eingestellten Verfahren und dem Ergebnis der Gesundheitsprüfung.
- BackendOrigin 1
- BackendOrigin 2
- BackendOrigin 3
TLS Zugriffslisten Rate Limiting WAF Cache Lastverteilung Backend
Vier Verfahren
Verkehr steuern
Vier Verfahren stehen zur Wahl: Round Robin, Least Connections, IP Hash, EWMA. Darunter steuern Sie jeden Backend-Server einzeln.
Wenn Sie sich nicht festlegen wollen: EWMA. Round Robin verteilt gleichmäßig, aber blind — sobald die Maschinen ungleich sind, merkt man den Unterschied.
- Gewichtung
- Jeder Server bekommt einen Anteil am Verkehr. Ungleiche Maschinen belasten Sie ungleich.
- Verbindungsobergrenze
- Ist die Grenze erreicht, wird der Server bei der Auswahl übergangen, statt ihn weiter zu belasten.
- Reserve-Server
- Springt erst ein, wenn kein regulärer Server mehr verfügbar ist.
- Aus dem Verkehr nehmen
- Ein Server bekommt keine neuen Anfragen mehr. Bestehende Verbindungen müssen dafür nicht abgebrochen werden — Wartung ohne Fehlerseite.
- Langsam hochfahren
- Nach einem Neustart steigt der Anteil eines Servers über ein Zeitfenster an, statt sofort voll zu treffen. Ein kalter Cache oder ein noch startender Prozess bekommt keine volle Last.
TLS Zugriffslisten Rate Limiting WAF Cache Lastverteilung Backend
Gesundheitsprüfung
Ausgefallene Backends erkennen
Backends werden aktiv geprüft, nicht erst dann bemerkt, wenn Besucher Fehlerseiten sehen.
Für jeden Pool legen Sie fest, nach wie vielen fehlgeschlagenen Prüfungen ein Server als ausgefallen gilt und nach wie vielen erfolgreichen er wieder in den Verkehr genommen wird. Die zweite Schwelle verhindert, dass ein instabiler Server zwischen den Zuständen pendelt.
Fällt ein Server aus, übernehmen die verbleibenden. Ist ein Reserve-Server eingetragen, springt er ein, sobald kein regulärer Server mehr verfügbar ist.
TLS Zugriffslisten Rate Limiting WAF Cache Lastverteilung Backend
OWASP Core Rule Set
Prüfung dort, wo der Verkehr ankommt
Die WAF arbeitet an der Kante, bevor eine Anfrage das Backend erreicht.
Grundlage ist das OWASP Core Rule Set. Je Site stellen Sie ein, wie streng geprüft wird und ab welcher Bewertung eine Anfrage abgewiesen wird. Ausgelöste Regeln landen als Ereignis in der Oberfläche.
Neue Sites schalten wir im Erkennungsmodus auf und sehen uns die Ereignisse an, bevor blockiert wird. Das Regelwerk kennt Ihre Anwendung nicht.
Wenn eine Regel den falschen Treffer meldet
Anwendungen lösen Regeln aus, ohne dass ein Angriff vorliegt — ein Redakteur speichert ein Code-Beispiel, ein Formular überträgt SQL-ähnlichen Text. Für diesen Fall nehmen Sie einzelne Regeln je Site aus, statt sie überall abzuschalten.
Zugriff begrenzen
Rate Limiting begrenzt die Anfragen je Quelle. IP-Zugriffslisten erlauben oder sperren Bereiche je Site, organisationsweite Sperrlisten gelten für alle Sites einer Organisation.
TLS Zugriffslisten Rate Limiting WAF Cache Lastverteilung Backend
Ausstellung und Erneuerung
Zertifikate an einer Stelle
EdgeWall stellt Zertifikate aus und erneuert sie automatisch. Eigene Zertifikate hinterlegen Sie selbst.
Für die Ausstellung stehen HTTP-01 und DNS-01 über PowerDNS zur Verfügung. Die Erneuerung startet 30 Tage vor Ablauf, ohne dass jemand einen Termin im Kalender führen muss.
Beim Hochladen eines eigenen Zertifikats wird geprüft
- Das Zertifikat ist ein gültiges X.509-Zertifikat
- Der private Schlüssel passt zum Zertifikat
- Der Gültigkeitszeitraum liegt nicht in der Vergangenheit
- Die enthaltenen Domainnamen passen zur Site
Ein Zertifikat, das nicht zum Schlüssel oder nicht zur Domain passt, wird beim Hochladen abgewiesen — nicht erst beim nächsten Neustart.
Änderungen
Konfiguration ohne Raten
Jede Änderung wird als Revision gespeichert. Einen früheren Stand sehen Sie ein und aktivieren ihn wieder.
-
Schritt 1
Ändern
Eine Anpassung an Site, Backend oder Regelwerk erzeugt eine neue Revision.
-
Schritt 2
Vergleichen
Sie stellen zwei Stände gegenüber. Sichtbar wird, was sich geändert hat — nicht nur, dass sich etwas geändert hat.
-
Schritt 3
Anwenden
Die Revision wird an die Standorte ausgerollt. Der Stand je Standort ist einsehbar.
-
Schritt 4
Zurückrollen
War die Änderung falsch, wird der vorherige Stand wieder aktiviert.
Zusätzlich hält ein Protokoll fest, wer welche Änderung vorgenommen hat.
Mandantenfähigkeit
Für mehrere Organisationen gebaut
Sites, Benutzer und Berechtigungen gehören zu einer Organisation. Rollen regeln, wer lesen, ändern und verwalten darf. Bevor eine Domain aufgeschaltet wird, weist die Organisation nach, dass sie über sie verfügt.
Betrieb
Sie verwalten, wir betreiben
EdgeWall wird als betriebener Dienst angeboten. Es gibt keine Software, die Sie installieren, und keine Standorte, die Sie selbst betreiben. Sie pflegen Ihre Sites und Regeln, der Betrieb der Standorte und die Aktualisierung der Software laufen im Hintergrund.
Standorte in Deutschland, Finnland, Niederlande, Frankreich, Österreich und Italien.
Zwei Architekturmodelle
Wer HTTP-Traffic auf dem Weg zum Backend prüfen und zwischenspeichern möchte, hat im Wesentlichen zwei Architekturmodelle zur Wahl.
Globale Plattform
Viele Standorte weltweit, hohe Kapazitäten, ausgebaute Produktpalette. Der Traffic läuft über die Infrastruktur des Anbieters, die für viele Kunden gleichzeitig gebaut wurde. Ansprechpartner ist der Support-Kanal eines großen Dienstes.
Eigener Dienstleister
Wenige Knoten, kein weltweites Standortnetz. Der Traffic läuft über Infrastruktur, die ein bestimmter Betreiber verwaltet. Ansprechpartner ist diese Person oder dieses Unternehmen direkt.
Beide Modelle haben ihre Berechtigung.
Für manche Betreiber ist die Frage, wer diese Schicht betreibt und wer bei Problemen zuständig ist, Teil der Architekturentscheidung. EdgeWall richtet sich an diejenigen, die Reverse Proxy und WAF näher an ihrem eigenen Dienstleister haben wollen.
Was EdgeWall in diesem Modell nicht mitbringt: kein weltweites Standortnetz, keine Skalierungsvorteile eines globalen Anbieters.
Grenzen
Was EdgeWall nicht macht
EdgeWall ist ein Reverse Proxy mit WAF und Cache. Was jenseits davon liegt, ist nicht Teil des Produkts.
- Kein globales CDN.
- Es gibt keine verteilten Standorte weltweit. Latenzoptimierung durch geografische Nähe zum Endnutzer ist kein Bestandteil.
- Keine DDoS-Mitigation als Produktfunktion.
- Volumetrische Angriffe fängt EdgeWall nicht ab. Die Standorte liegen an Anschlüssen, deren Anbieter einen Grundschutz gegen volumetrische Angriffe auf Netzebene mitbringen; das gehört zur Anbindung, ist nicht über EdgeWall konfigurierbar und keine zugesicherte Leistung. Rate Limiting je Site arbeitet auf Anwendungsebene und ist etwas anderes.
- Keine Bot-Erkennung, keine JavaScript-Challenges, kein CAPTCHA.
- Anfragen werden nach WAF-Regelwerk und Ratenlimits bewertet. Verhaltensbasierte Fingerprinting-Mechanismen oder Challenge-Verfahren gehören nicht dazu.
- Keine Länder- oder ASN-Sperren.
- Zugriffslisten arbeiten auf IP-Ebene, je Site oder netzweit über nftables. Geografische oder ASN-basierte Einschränkungen sind kein vorgesehenes Werkzeug.
- Kein DNS-Hosting.
- Domain-Eigentumsnachweis läuft über DNS-TXT-Eintrag; die Zonenverwaltung bleibt beim Betreiber.
- Keine Edge Functions oder Workers.
- Es gibt kein Laufzeitsystem für nutzerdefinierten Code an der Edge.
- Kein Zero Trust.
- EdgeWall ist kein Identity-Proxy und kein Access Gateway. Authentifizierung und Autorisierung liegen beim Backend oder einem vorgelagerten System.
- Keine Bildoptimierung.
- Cache und Proxy, aber keine Transcoding-Pipeline für Bilder oder andere Medien.
Passt das auf Ihren Aufbau?
Sinnvoll ist ein Gespräch über Ihre Sites, Ihre Backends und das, was Sie heute selbst pflegen. Daraus ergibt sich, ob ein Wechsel etwas bringt.
Schreiben Sie an support@itworxx.de. Diese Seite hat kein Kontaktformular und setzt keine Cookies.