Die dem Benutzer angezeigte Blockseite ist das sichtbare Gesicht der Sicherheitsentscheidung.
Wird ein Benutzer blockiert, ist die generische „access denied“-Meldung, die er sieht, nicht nur eine technische Ausgabe; sie ist Teil des Sicherheitserlebnisses des Unternehmens. Ein Unternehmenskunde, ein Bürger, ein Geschäftspartner oder ein Endbenutzer möchte verstehen, warum er aufgehalten wird, was er tun muss und ob dies vorübergehend oder dauerhaft ist. Grobe und markenlose Fehlerseiten verwandeln die Sicherheitsentscheidung in ein unprofessionelles Erlebnis.
Während eines DDoS- oder Bot-Angriffs genügt es oft nicht, dem Benutzer nur einen Fehler zu zeigen. Dem echten Benutzer sollte vermittelt werden, dass er kurz warten soll, dass seine Anfrage verifiziert wird, dass der automatisierte Verkehr getrennt wird und dass der Vorgang fortgesetzt wird. Countdown-, Challenge- und CAPTCHA-Ablauf erfüllen an dieser Stelle sowohl eine Sicherheits- als auch eine Kommunikationsaufgabe.
In mehrsprachigen und mandantenfähigen Umgebungen ist dieselbe Seite nicht für jeden passend. Eine Bank möchte womöglich eine Erklärung in ihrer Sprache und mit den Unternehmensfarben zeigen; ein Dienstanbieter möchte womöglich für jeden Tenant ein anderes Logo und einen anderen Text verwenden; ein API-Endpunkt sollte hingegen statt HTML eine JSON-Fehlermeldung zurückgeben. Eine einzige feste Blockseite kann diese Anforderungen nicht erfüllen.
Auch für Helpdesk- und Sicherheitsteams ist der Reason-Code wichtig. Erhält ein Benutzer einen Fehler, muss das Support-Team verstehen können, welche Regel, welche Bot-Entscheidung oder welche WAAP-Aktion aktiviert wurde. Diese Information muss jedoch kontrolliert ausgegeben werden; in manchen Fällen wird sie dem Benutzer gezeigt, in anderen nur im Log und im Support-Ablauf gehalten.
Der Ansatz von TR7 nimmt Blockseiten die Eigenschaft einer nach der Sicherheitsentscheidung zurückgegebenen statischen Fehlerausgabe; er verwandelt sie in ein anpassbares WAAP-Erlebnis mit Marke, Sprache, Reason-Code, CAPTCHA, DDoS-Challenge und API-Antwortformaten.
Unser Ansatz
TR7 verwaltet Blockseiten mit vorkonfigurierten Vorlagen, EJS-Rendering, nativer Antwortausgabe und Reason-Code-Injection.
Vorkonfigurierte Seitenkategorien decken verschiedene Sicherheitsaktionen ab
Für DDoS-Challenge, JavaScript-Verifizierung, CAPTCHA, Bot-Schutz-Fehler und AAM 503 gibt es separate Vorlagenstrukturen. Jeder Seitentyp kann nach unterschiedlichem Benutzererlebnis und unterschiedlicher Sicherheitsentscheidung gestaltet werden.
EJS-Vorlagen verwalten Theme, Farbe und Sprache
CAPTCHA-Seiten werden mit EJS-Vorlagen erstellt. Theme, Größe, Hintergrund, Textfarbe und Sprachwörterbuch können beim Rendering angewendet werden.
Die Seite wird direkt aus der Übergangsebene ausgeliefert
TR7 kann die Block- oder Challenge-Antwort zurückgeben, ohne zum Backend-Dienst zu gehen. Dieser Ansatz verringert sowohl die Latenz als auch die unnötige Belastung der Anwendungsebene im Angriffsmoment.
Reason-Code und Request-Variablen können in die Seite eingearbeitet werden
Reason-Code und benutzerdefinierte Request-Variablen können kontrolliert in die Vorlage eingebettet werden. Dies hilft Support-Teams, die Fehlerursache zu unterscheiden und dem Benutzer bei Bedarf eine sinnvolle Erklärung zu geben.
Fähigkeiten
Die TR7-Blockseiten-Anpassung verwaltet HTML-, CAPTCHA-, Challenge- und JSON-Antworten für verschiedene WAAP-Entscheidungen zentral.
Die DDoS-Challenge-Seite hält den echten Benutzer auf, ohne ihn in Panik zu versetzen
TR7 kann für DDoS-Szenarien spezielle Challenge-Seiten verwenden. Diese Seiten können Countdown, Benutzerinformation und Verifizierungsmeldungen enthalten. Dem echten Benutzer wird vermittelt, dass seine Anfrage verarbeitet wird und in Kürze fortgesetzt wird. So wird im Angriffsmoment nicht nur ein Block, sondern ein steuerbares Benutzererlebnis geboten.
Die JavaScript-Verifizierungsseite hilft, automatisierten Verkehr zu trennen
DDoS-JS-Solver-Seiten unterstützen einen Verifizierungsablauf über das Browserverhalten. Mit clientseitiger Kontrolllogik wird die Trennung automatisierten Verkehrs angestrebt. Vorkonfigurierte Dateien in TR und EN können verwendet werden. Der Bedarf an einer neuen Sprache oder einem anderen Text kann über die Vorlagenstruktur gedeckt werden.
Die CAPTCHA-EJS-Vorlage verwaltet Theme, Größe und Sprache flexibel
CAPTCHA-Vorlagen erzeugen das CAPTCHA-Erlebnis. Die Theme-Optionen `auto`, `dark` und `light` sowie die Größen `small`, `medium` und `large` können verwendet werden. Hintergrund- und Textfarbe können mit Parametern eingestellt werden. Diese Struktur macht die Sicherheitsverifizierung mit der visuellen Identität des Unternehmens vereinbar.
Text- und unsichtbare CAPTCHA-Typen werden an verschiedene Abläufe angepasst
In der CAPTCHA-Konfiguration können Text- oder unsichtbare Typen verwendet werden. Das Text-CAPTCHA eignet sich für Situationen, die eine explizite Antwort des Benutzers erfordern. Der unsichtbare Modus kann in Szenarien bevorzugt werden, in denen geringere Reibung gewünscht ist. So wird dieselbe Sicherheitskontrolle an unterschiedliche Ziele des Benutzererlebnisses angepasst.
Das Sprachwörterbuch unterstützt das Hinzufügen mehrerer Sprachen auf Vorlagenebene
TR7 kommt mit vorkonfigurierten CAPTCHA-Textwörterbüchern in TR und EN. Etwa 16 Textfelder wie Titel, Beschreibung, Eingabefeld, Senden, Aktualisieren, Wird verifiziert, Erfolgreich, Fehlgeschlagen, Fehler und Abgelaufen können je Sprache verwaltet werden. Neue Sprachen können durch Hinzufügen zum Übersetzungsobjekt innerhalb der Vorlage erweitert werden. Der Benutzer kann die gewünschte Sprache selbst hinzufügen; die Mehrsprachigkeit wird auf diese Weise bereitgestellt.
Die Per-vService-CAPTCHA-Konfiguration ermöglicht die Trennung von Tenant und Anwendung
Jeder vService kann mit seinem eigenen CAPTCHA-Konfigurationswert ein anderes Aussehen und Verhalten nutzen. Dies ist in mandantenfähigen, MSSP- oder unter verschiedenen Marken laufenden Anwendungen wichtig. Auf demselben TR7 kann jede Anwendung mit ihrer eigenen Farbe, Sprache, ihrem Text und Verifizierungsstil arbeiten. Während die Sicherheitskontrolle zentral bleibt, wird das Benutzererlebnis getrennt.
Die Bot-Schutz-Fehlerseite behandelt schlechten automatisierten Verkehr separat
Für Bot-Schutz-Entscheidungen kann eine spezielle Fehlerseite verwendet werden. Wird ein schlechter User-Agent, ein Automatisierungsverhalten oder eine Bot-Schutz-Regel ausgelöst, kann dem Benutzer eine separate Antwort zurückgegeben werden. Diese Seite kann nach Markensprache und Support-Prozess angepasst werden. Der technische Reason-Code kann bei Bedarf intern gehalten oder kontrolliert angezeigt werden.
Die AAM-503-Seite gibt eine kontrollierte Meldung, wenn der Backend-Dienst nicht erreichbar ist
Ist der Backend-Dienst nicht erreichbar oder kann der Pool vorübergehend keinen Dienst leisten, kann eine spezielle AAM-503-Seite verwendet werden. Diese Seite verhindert, dass der Benutzer einen leeren Browserfehler oder einen sinnlosen Verbindungsabbruch sieht. Geplante Wartung, vorübergehende Auslastung oder ein Dienstzugriffsproblem können mit einer verständlicheren Meldung dargestellt werden. Das Unternehmen wahrt selbst im Fehlermoment Marke und Support-Lenkung.
Benutzerdefinierte WAAP-Aktionen können HTML- oder JSON-Antworten zurückgeben
TR7 kann bei WAAP-Aktionen eine benutzerdefinierte Antwort mit bestimmtem Statuscode, Content-Type und Dateiinhalt zurückgeben. Eine HTML-Seite, Klartext oder ein JSON-Fehler-Body für API-Endpunkte kann verwendet werden. Ein dateibasiertes oder Inline-Inhaltsmodell kann angewendet werden. Diese Flexibilität erzeugt ein unterschiedliches Block-Erlebnis für Web-Benutzer und API-Clients.
Reason-Code-Injection erleichtert die Support- und Incident-Unterscheidung
In den Seiteninhalt können Request-Variablen oder Reason-Codes auf Transaktionsebene eingebettet werden. Der Helpdesk kann anhand eines vom Benutzer eingesandten Screenshots oder Fehlercodes schneller verstehen, welche Sicherheitsentscheidung aktiviert wurde. Das Sicherheitsteam kann per Richtlinie festlegen, welche Informationen dem Benutzer gezeigt werden und welche nur auf der Log-Seite bleiben. Diese Struktur erhöht die Debug-Geschwindigkeit und hält zugleich das Risiko eines Informationslecks unter Kontrolle.
Operative Tiefe
Für den zuverlässigen Betrieb von Blockseiten werden Dateiausgabe, Sprach-Hinzufügung, Statuscode-Auswahl, dynamische Variablen und statische Asset-Verwaltung gemeinsam geplant.
Sprach-Hinzufügungsmodell
Um der CAPTCHA-Vorlage eine neue Sprache hinzuzufügen, kann dem betreffenden Übersetzungsobjekt ein neues Sprachwörterbuch definiert werden. Titel-, Fehler-, Verifizierungs- und Wartetexte werden je Sprache getrennt. Dieser Ansatz bindet die Mehrsprachigkeit nicht an eine feste Produktliste, sondern an eine erweiterbare Vorlagenstruktur.
Asset-Dateipfade
Für CAPTCHA- und Challenge-Seiten können Base-Path, JavaScript-Servierpfad, HTML-Datei und JavaScript-Datei mit separaten Konfigurationsfeldern verwaltet werden. Diese Trennung sorgt dafür, dass statische Inhalte über den richtigen Pfad ausgeliefert werden. Bei mehreren Seitentypen bleibt die Dateiordnung besser lesbar.
Native Antwortausgabe
Bei Eintreten einer bestimmten Bedingung kann TR7 mit der Logik der nativen Antwortausgabe direkt eine HTML- oder JSON-Antwort erzeugen. Diese Antwort wird erzeugt, ohne zum Backend-Dienst zu gehen. Bei Challenge-, CAPTCHA- und benutzerdefinierten WAAP-Aktionen werden Latenz und Anwendungslast auf diese Weise verringert.
Statuscode-Flexibilität
Für verschiedene Szenarien können unterschiedliche HTTP-Statuscode-Werte verwendet werden. Während der CAPTCHA-Ablauf mit 200 bereitgestellt werden kann, können Limit- oder Block-Entscheidungen mit Codes wie 403, 413, 451 oder 503 zurückgegeben werden. Die Wahl des semantisch korrekten Codes für API- und Web-Benutzer erhöht die Integrationsqualität.
Logo- und SVG-Nutzung
Logo, SVG oder Bildinhalte können inline oder als Base64 in das HTML eingebettet werden. Diese Methode kann die Abhängigkeit von separaten Assets verringern und das Erstellen einer benutzerdefinierten Einzeldateiseite erleichtern. Die Unternehmensmarke kann über ein benutzerdefiniertes HTML-Layout in die Seite eingefügt werden.
Dateisynchronisation
Vorkonfigurierte DDoS-Challenge- und JS-Verifizierungsdateien können mit einem dynamischen Datei-Bindungsmechanismus verfolgt werden. Wird eine Datei aktualisiert, wird der betreffende Inhalt in die Servierebene übernommen. Diese Struktur hilft, statische Seiten aktuell zu halten, ohne sie in einen manuellen Dienst-Neustart-Vorgang zu verwandeln.
In welchen Szenarien es eingesetzt wird
Gebrandete Blockseite für eine Bank
Eine Bank kann eine benutzerdefinierte CAPTCHA- oder Blockseite mit einem weiß/blauen Theme, Unternehmenslogo, einer Erklärung in ihrer Sprache und einem Support-Link verwenden. Während der Reason-Code vor dem Benutzer verborgen bleibt, kann das Support-Team die tatsächliche Ursache über das Log einsehen.
DDoS-Challenge im Moment eines starken Angriffs im E-Commerce
Steigt während einer Kampagne der automatisierte Verkehr, kann dem echten Benutzer eine DDoS-Challenge-Seite mit Countdown gezeigt werden. Während der Benutzer nach einer kurzen Verifizierung mit dem Einkaufsablauf fortfährt, wird der Bot-Verkehr getrennt.
Regionsbasierte Zugriffsmeldung in einem Behördenportal
Eine Behörde kann bei bestimmten Zugriffsentscheidungen eine benutzerdefinierte Seite mit einer Erklärung in der Landessprache zurückgeben. Dem Benutzer wird in der Unternehmenssprache erklärt, warum der Zugriff eingeschränkt wurde und an welchen Support-Kanal er sich wenden soll.
JSON-Block-Antwort für einen API-Endpunkt
Bei API-Diensten ist es korrekter, statt einer HTML-Seite eine 403- oder 429-Antwort im JSON-Format zurückzugeben. TR7 arbeitet mit einer benutzerdefinierten WAAP-Aktion den Reason-Wert in den JSON-Body ein und ermöglicht es Client-Anwendungen, den Fehler programmatisch zu verarbeiten.
Häufig gestellte Fragen
Für welche Sicherheitsentscheidungen kann eine benutzerdefinierte Blockseite verwendet werden?
Wie ist das Hinzufügen einer neuen Sprache zur CAPTCHA-Seite möglich?
Belastet die Blockseite den Backend-Dienst?
Kann für API-Endpunkte statt HTML eine JSON-Fehlerantwort zurückgegeben werden?
Muss der Reason-Code dem Benutzer immer gezeigt werden?
Kann in einer mandantenfähigen Umgebung jede Anwendung eine andere Seite verwenden?
Passen Sie auch das Erlebnis nach der Sicherheitsentscheidung an Ihre Marke an
Anpassbare Blockseiten für DDoS, CAPTCHA, Bot-Schutz und WAAP-Aktionen. Wir sehen gemeinsam, wie es in Ihrer eigenen Konfiguration funktioniert.