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.
TR7 verwaltet Blockseiten mit vorkonfigurierten Vorlagen, EJS-Rendering, nativer Antwortausgabe und Reason-Code-Injection.
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.
CAPTCHA-Seiten werden mit EJS-Vorlagen erstellt. Theme, Größe, Hintergrund, Textfarbe und Sprachwörterbuch können beim Rendering angewendet werden.
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 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.
Die TR7-Blockseiten-Anpassung verwaltet HTML-, CAPTCHA-, Challenge- und JSON-Antworten für verschiedene WAAP-Entscheidungen zentral.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Für den zuverlässigen Betrieb von Blockseiten werden Dateiausgabe, Sprach-Hinzufügung, Statuscode-Auswahl, dynamische Variablen und statische Asset-Verwaltung gemeinsam geplant.
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.
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.
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.
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, 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.
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.
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.
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.
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.
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.
Anpassbare Blockseiten für DDoS, CAPTCHA, Bot-Schutz und WAAP-Aktionen. Wir sehen gemeinsam, wie es in Ihrer eigenen Konfiguration funktioniert.