Webanwendungen mit SafeLine absichern
Vorgeschaltet
Veröffentlicht in Ausgabe 04/2026 - SCHWERPUNKT
Wer einen Webdienst öffentlich anbietet, muss damit rechnen, dass automatisierte Scanner, Bots oder gezielte Angriffe nicht lange auf sich warten lassen. Die Frage ist daher nicht, ob ein Webserver angegriffen wird, sondern wie er abgesichert ist. Eine klassische Firewall filtert in erster Linie nach IP-Adressen, Protokollen und Ports.
Für einen öffentlich erreichbaren Webserver müssen jedoch mindestens die Ports 80 (HTTP) und 443 (HTTPS) geöffnet sein. Der Dienst ist damit technisch erreichbar – für legitime Besucher ebenso wie Angreifer. Eine klassische Firewall kann den Inhalt einer HTTP-Anfrage in der Regel nicht bewerten. Genau hier setzt eine Web Application Firewall (WAF) an.
So funktioniert eine WAF
Eine WAF wird typischerweise als Reverse-Proxy zwischen Client und Webserver betrieben. Für den Browser tritt sie als Webserver auf, für den eigentlichen Webserver als Client. Der gesamte HTTP- und HTTPS-Verkehr fließt damit durch die zusätzliche Instanz, bevor er die Anwendung erreicht.
Wer einen Webdienst öffentlich anbietet, muss damit rechnen, dass automatisierte Scanner, Bots oder gezielte Angriffe nicht lange auf sich warten lassen. Die Frage ist daher nicht, ob ein Webserver angegriffen wird, sondern wie er abgesichert ist. Eine klassische Firewall filtert in erster Linie nach IP-Adressen, Protokollen und Ports.
Für einen öffentlich erreichbaren Webserver müssen jedoch mindestens die Ports 80 (HTTP) und 443 (HTTPS) geöffnet sein. Der Dienst ist damit technisch erreichbar – für legitime Besucher ebenso wie Angreifer. Eine klassische Firewall kann den Inhalt einer HTTP-Anfrage in der Regel nicht bewerten. Genau hier setzt eine Web Application Firewall (WAF) an.
So funktioniert eine WAF
Eine WAF wird typischerweise als Reverse-Proxy zwischen Client und Webserver betrieben. Für den Browser tritt sie als Webserver auf, für den eigentlichen Webserver als Client. Der gesamte HTTP- und HTTPS-Verkehr fließt damit durch die zusätzliche Instanz, bevor er die Anwendung erreicht.
Da die WAF im Datenpfad sitzt, kann sie Anfragen prüfen, filtern oder bei Bedarf blockieren. Das Regelwerk ähnelt dem einer klassischen Firewall, bezieht jedoch Protokolldetails wie Header, URL oder Anfragerate mit ein. Beide Komponenten schließen sich nicht aus, sondern ergänzen sich im Sicherheitskonzept. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt für öffentlich erreichbare Webanwendungen den Einsatz einer Web Application Firewall [1].
Webserver sind auch ohne dedizierte WAF nicht völlig schutzlos. Nginx oder der Apache HTTP Server bieten eigene Filtermechanismen, blockieren IP-Adressen oder lassen sich mit Werkzeugen wie Fail2ban kombinieren. Mit ModSecurity existiert zudem seit vielen Jahren ein Schutzmodul für Apache, Nginx und IIS. Eine eigenständige WAF trennt jedoch Schutzfunktion und Webanwendung konsequent voneinander und wird als separate Instanz vor die Anwendung geschaltet.
Idealerweise verfügt sie über zwei Netzadapter – einen in Richtung Internet, einen zum internen Webserver. So lässt sich verhindern, dass Clients die Schutzinstanz umgehen. Da sämtliche Anfragen durch die WAF fließen, kann sie diese anhand von Regeln bewerten. Neben IP-Adressen und Ports spielen dabei auch HTTP-Header, URL-Pfade oder Anfrageraten eine Rolle. Wie sich ein solches Konzept konkret umsetzen lässt, zeigt die WAF SafeLine.
SafeLine unter GPL-Lizenz mit proprietärem Kern
Der chinesische Anbieter Chaitin entwickelt seit 2023 an seiner WAF SafeLine [2]. Ausgeliefert wird sie als Container-Paket für Docker oder Podman; klassische Installationspakete für Debian, Red Hat & Co. fehlen. SafeLine steht unter der GPL-3-Lizenz und der Quellcode liegt öffentlich auf GitHub. Der kostenfreie Tarif ist beim Funktionsumfang und Durchsatz eingeschränkt, genügt für kleinere Umgebungen jedoch durchaus.
Beim genaueren Hinsehen zeigt sich allerdings ein Open-Core-Ansatz. Der innere Kern ist nicht vollständig quelloffen. Wer versucht, SafeLine selbst aus dem Quellcode zu kompilieren, stößt auf nicht öffentlich erreichbare Go-Module, sodass der Build-Prozess scheitert – ein Umstand, den der Anbieter in GitHub-Issues bestätigt.
Ein vollständiger Einblick in die Software bleibt damit verwehrt, doch ganz intransparent ist sie nicht. Werkzeuge wie Trivy oder Grype prüfen die bereitgestellten Container-Images auf bekannte Schwachstellen und listen vorhandene CVEs auf. Das Risiko lässt sich so zumindest von außen bewerten, auch wenn SafeLine streng genommen kein vollständig quelloffenes Projekt ist.
Installation als Container-Deployment
SafeLine ist genügsam, was die Systemressourcen betrifft, und kommt mit einem Prozessorkern, 1 GByte Arbeitsspeicher und 5 GByte Festplattenplatz aus. Hinsichtlich der Linux-Distribution gibt es keine Einschränkungen oder Empfehlungen. Solange Docker läuft, nehmen die SafeLine-Container ihre Arbeit auf. Eigene Tests zeigen einen problemfreien Betrieb mit Debian, Rocky Linux und Ubuntu.
Die Installation erfolgt per Skript. Das angebotene Python-Skript erfragt das Installationsverzeichnis und bietet an, die Docker-Software auf den neuesten Stand zu bringen. Anschließend holt es die insgesamt sieben Container-Images auf den lokalen Rechner:
wget https://waf.chaitin.com/ release/latest/manager.py
python3 manager.py --en
Die Anzahl der Container mag hoch erscheinen, aber die Entwickler halten sich an das Credo: ein Dienst pro Container. Im PostgreSQL-Container liegt die Datenbank für die Konfigurationen. Der mgt-Container stellt die administrative Weboberfläche bereit, und im tengine-Container arbeitet der Webserver Nginx eingehende Anfragen von Clients ab.
Am Ende zeigt das Skript die Zugangsdaten und die Webadresse der Administrationsoberfläche an, etwa "https:// 192.0.2.1:9443". Haben Sie diesen Schritt verpasst oder manuell installiert, können Sie sich neue Zugangsdaten ziehen:
docker exec safeline-mgt resetadmin
Die Konfigurationswebseite begrüßt Sie nun mit einem Software License Agreement nebst Zustimmungsknopf. Nach dem Login zeigt das Dashboard umfangreiche Statistiken, deren Werte anfangs allesamt null sind.
Erste Anwendung in SafeLine konfigurieren
Die WAF ist für den aufrufenden Webbrowser zwar transparent, benötigt aber eine explizite Konfiguration für jeden angebotenen Dienst. Den Anfang macht eine simple Webseite, wie sie der Apache HTTP Server automatisch mitbringt. Per WAF soll diese Webseite öffentlich erreichbar werden.
Erstellen Sie im Webmenü der SafeLine-WAF im Bereich "Applications" eine neue Anwendung. Die Einstellungen aus Bild 1 bewirken, dass die Firewall unter der URL "http://www.example.net" ihre Dienste anbietet. Ersetzen Sie diese entsprechend durch den Namen Ihrer zukünftigen Webanwendung.
Tragen Sie bei "Upstream" noch die IP-Adresse eines internen Webservers ein, der in diesem Beispiel eine einfache HTML-Seite ausgibt.
Schalten Sie die frisch erstellte Applikation vom "Defense mode" in den "Audited Mode", damit die WAF sämtliche Angriffe lediglich berichtet und nicht verhindert. Dadurch arbeitet SafeLine wie ein gewöhnlicher Reverse-Proxy ohne Filterfunktion.
Damit Ihre zukünftigen Clients den neuen Webdienst über die WAF erreichen können, muss der DNS-Eintrag auf die IP-Adresse von SafeLine zeigen und nicht auf die Adresse des Webservers.
Sobald ein Webbrowser den neuen Dienst erreichen kann, folgt der nächste Schritt: die Absicherung per HTTPS und gültigem Zertifikat.
HTTPS mit eigenem Zertifikat aktivieren
Die Verschlüsselung mit HTTPS verhindert fremden Einblick in die übertragenen Daten, und das ist fast schon obligatorisch. Damit der Browser keine Zertifikatswarnung anzeigt, benötigt SafeLine ein gültiges Zertifikat.
Die SafeLine-Webkonsole akzeptiert unter "Settings / Protections / Add Cert" Zertifikate in Dateiform oder per Copy and Paste. Vergessen Sie nicht mögliche Zwischenzertifikate und beachten Sie die Reihenfolge: zuerst das Serverzertifikat, gefolgt vom Intermediate-Zertifikat. Alternativ können Sie mit der Option "Get free cert" ein Zertifikat von Let's Encrypt beziehen. Dazu muss Ihre SafeLine-WAF über TCP-Port 80 aus dem Internet erreichbar sein, da Let's Encrypt diesen Port für die Validierung verlangt. Um die Zwischenzertifikate kümmert sich der Certbot im Hintergrund.
Sobald das Zertifikat vorliegt, sollte die Applikation dieses nutzen. Wechseln Sie zurück in die Eigenschaften Ihrer Applikation und klicken neben "Basic" auf das Bleistift-Symbol. Fügen Sie Port 443 für HTTPS hinzu und wählen das Zertifikat aus. Am Upstream müssen Sie nichts ändern, auch wenn dieser per HTTP erreichbar ist.
Jetzt sollte der Zugriff auf den Webserver via SafeLine per "https://www.example.net" möglich sein. Wenn der Browser vor der sicheren Verbindung warnt, lohnt sich ein Blick in das erhaltene Zertifikat sowie die Zertifikatskette bis zur Root-CA. Hierbei helfen Tools wie "certigo" oder "openssl".
Wer sich die Übertragungsprotokolle bis hierhin genau anschaut, bemerkt eine verschlüsselte HTTPS-Verbindung zwischen Client und WAF, gefolgt von einer unverschlüsselten Verbindung von WAF zum Webserver. Sofern der interne Transportweg zwischen WAF und Webserver als vertrauenswürdig gilt, ist dieses Vorgehen in der Praxis unproblematisch. Beim SSL-Off-loading terminiert die WAF die TLS-Verbindung und entlastet damit den Webserver von der kryptografischen Verarbeitung.
Filterregeln und Schutzmechanismen konfigurieren
Der Webdienst ist nun erreichbar, allerdings filtert die WAF den Datenverkehr noch nicht aktiv. SafeLine kann als Webfilter den Zugang einschränken, damit mögliche Angreifer weniger Schaden anrichten. Im Webmenü bei "Allow & Deny" tummeln sich in der Event-Liste eventuell schon ein paar neugierige IP-Adressen. Wechseln Sie oben rechts in den Bereich "Custom Rules". Die vorinstallierten Regeln blockieren alles, was auf öffentlichen Blocklisten steht.
Mit einer neuen Regel beginnt die eigene Sicherheitsrichtlinie. SafeLine filtert anhand von Quelladresse, Anwendung, URL, HTTP-Methode und Kopfzeilen der Anfrage oder Antwort. Die Suche nach dem gewünschten Muster nutzt Equals, Contains, Regex oder Fuzzy. Mehrere dieser Suchfilter lassen sich per UND sowie ODER beliebig kombinieren. Wenn die Aktion der Regel "Deny" lautet, dann greift der Modus der App: Defense mode blockiert, Audited mode erlaubt und berichtet.
Ein weiterer Filter fällt ins Auge: JA4-Fingerprint. Mithilfe des Fingerabdrucks lässt sich ein TLS-Client zuverlässig wiedererkennen. Der Fingerabdruck bösartiger Clients kommt in die öffentliche JA4-Datenbank und steht allen Web-Firewalls kostenlos zur Verfügung [3]. SafeLine nutzt diese Datenbank in seinem Produkt, jedoch ist die Regel anfangs inaktiv. Bei Interesse aktivieren Sie die Regel "Malicious JA4 Fingerprint", triggern unter "Settings" den Download der knapp 200 MByte großen Datenbank und profitieren anschließend von bekannten TLS-Saboteuren. Die Abfragen der JA4-Fingerprints erfolgen lokal auf der WAF, da diese ihre Kopie der Datenbank stets aktuell hält.
Mit dem "BOT Protect" schalten Sie eine JavaScript-basierte Challenge vor Ihre Webanwendung, die ein Besucher erst lösen muss. Die Aufgabe ist in JavaScript formuliert, das der Webbrowser ohne menschliches Eingreifen abarbeitet. Damit reduziert die WAF die Anfragerate potenzieller Angreifer. Der Trick beim Webschutz besteht darin, dass die große Last beim Client und nicht beim Server liegt. Der Client erhält die schwierige Aufgabe, während der Server lediglich prüft, ob das Ergebnis stimmt.
Den Bot-Schutz können Sie pro Applikation aktivieren. Im kostenfreien Modus verlangt BOT-Protect jede Stunde eine Challenge vom Client. Der Bot-Schutz eignet sich nicht für jede Webanwendung. Wenn Webinhalte eingebettet sind, per WebDAV verfügbar sind oder als API aufgerufen werden, ignoriert der Client eventuell die Challenge und kann die Inhalte nicht darstellen.
Unsichere TLS-Versionen deaktivieren
In der kostenfreien Variante akzeptiert SafeLine neben TLS 1.2 und 1.3 auch ältere Protokollversionen. Diese lassen sich über die Weboberfläche nicht deaktivieren, was bei einem Sicherheitsaudit negativ auffallen kann. Abhilfe schafft ein direkter Eingriff in die Konfigurationsdatenbank. Dabei wird der erlaubte TLS-Umfang manuell auf die aktuellen Versionen beschränkt. Der folgende Befehl setzt TLS 1.2 und 1.3 als einzige zulässige Protokolle für neu angelegte Applikationen:
docker exec -it safeline-pg psql -U safeline-ce -d safeline-ce
UPDATE mgt_proxy_config
SET ssl_protocols = '{"value": "TLSv1.2 TLSv1.3", "global": false}'
WHERE site_id = 0;
exit
Sollen bestehende Applikationen angepasst werden, ist die WHERE-Bedingung zu entfernen. Aber Achtung: Der Eingriff erfolgt direkt in der PostgreSQL-Datenbank und ist nicht Bestandteil der offiziellen Konfigurationsoberfläche. Änderungen erfolgen auf eigene Verantwortung und können bei Produktupdates überschrieben werden.
Leistungsbedarf der WAF ermitteln
Nun gilt es, die Leistung der Hardware auf die Anforderungen der WAF abzustimmen. SafeLine empfiehlt drei Größen, die sich an den Anfragen pro Sekunde (QPS) orientieren. Doch wie viele Anfragen prasseln auf die vorhandenen Webdienste ein? Eine schnelle Antwort liefert das Tool "apachetop". Der Name suggeriert zwar einen Apache-Webserver, funktioniert aber auch für Nginx, Lighttpd und – mit etwas Konfigurationsaufwand – Caddy.
Allerdings handelt es sich bei dieser Methode nur um eine Momentaufnahme. Für eine Langzeitauswertung müssen AWStats oder ein Web-Analytics-Tool wie Matomo ran. Wer es weniger genau braucht, kann einen Blick in die Logdatei seines Webservers werfen und anhand der Zugriffsstatistik abschätzen.
Bei weniger als 100 Anfragen pro Sekunde empfiehlt SafeLine [4] zwei CPU-Kerne und 4 GByte Arbeitsspeicher. Steigt die Rate auf bis zu 1000, sollten es vier CPU-Kerne und 8 GByte Memory sein. Oberhalb von 1000 Anfragen pro Sekunde verdoppelt sich die Anforderung auf acht CPUs und 16 GByte RAM. Beim Sizing ist zu beachten, dass die kostenfreie "Personal Edition" auf 800 QPS limitiert ist. Erst die Pro Edition schöpft das volle Potenzial aus.
Beispielkonfiguration: Gitea absichern
Wer seinen Quellcode mit der Versionsverwaltung Gitea selbst hosten möchte, sollte den Webzugang zu seinem geistigen Eigentum robust per WAF absichern. Eine frisch installierte Gitea-Instanz lauscht auf Port 3000 auf HTTP-Anfragen. In diesem Anwendungsfall soll die WAF Webzugriffe per HTTPS annehmen, Zugangsdaten erfragen und schließlich den Upstream-Server auf Port 3000 kontaktieren.
Die Einrichtung einer weiteren Applikation in SafeLine orientiert sich an den bisherigen Erklärungen. Für die Benutzeranmeldung erwartet SafeLine in der Anwendung eine Auth-Callback-URL. Darüber erfragt die Applikation, also Gitea, bei der WAF den Benutzernamen der begonnenen HTTP-Verbindung. Wer den Aufwand scheut, den notwendigen Code im Upstream-Server zu implementieren, kann auf die klassische Basic-Authentifizierung zurückgreifen.
Offiziell unterstützt SafeLine die Basic-Auth zwar nicht, aber der verwendete Nginx-Webserver bietet diese Form der Anmeldung mit zwei Konfigurationszeilen. Wechseln Sie im Web-UI in die Details der jeweiligen Applikation und wählen die Advanced-Ansicht. Fügen Sie im Bereich "Custom NGINX Config" die folgenden Zeilen hinzu:
auth_basic "Gitea";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_set_header X-WEBAUTH-USER $remote_user;
Die dritte Zeile instruiert SafeLine, den Benutzernamen im HTTP-Header mitzusenden, damit Gitea diesen erkennt. Die Syntax ist spezifisch für Gitea und gilt nicht allgemein für andere Webdienste, ähnelt diesen aber meist.
Bei Basic-Auth ist die Benutzerdatenbank eine Textdatei mit Benutzernamen und Kennwörtern, Letztere natürlich verschlüsselt. Die Syntax und das benötigte Kommando stammen vom Apache-HTTP-Server. Führen Sie die folgenden Befehle im Hostsystem aus, auf dem die SafeLine-Container laufen. Alternativ lässt sich ein Eintrag für die htpasswd-Datei mit dem Kommando "htpasswd" erzeugen:
apt install apache2-utils
cd /data/safeline/resources/nginx/
htpasswd -bcB .htpasswd user1 4M2tYFelEM
htpasswd -bB .htpasswd user2 auSoJQWE3J
Mit dieser Konfiguration fragt die WAF den Benutzer nach seinen Zugangsdaten, aber zusätzlich fragt Gitea auch. Glücklicherweise ist Gitea für den Betrieb hinter einer WAF geeignet und lässt sich über Variablen der Konfigurationsdatei "/etc/gitea/app.ini" auf SafeLine abstimmen:
ENABLE_BASIC_AUTHENTICATION = false
ENABLE_REVERSE_PROXY_AUTO_REGISTRATION = true
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
Die Einstellungen bewirken, dass Gitea selbst keine Benutzeranmeldung durchführt. Die vorgeschaltete WAF sendet den Usernamen im HTTP-Header als X-WEBAUTH-USER mit. Gitea vertraut diesem Wert und legt den Benutzer beim ersten Login in seiner internen Datenbank an. Jetzt darf SafeLine seinen Webschutz hochfahren und das Dashboard mit Werten füllen (Bild 2).
WAF mit TLS-Check und Lasttest prüfen
Bevor die WAF ihre Arbeit aufnehmen darf, muss sie sich beweisen. Unterziehen Sie Ihre Firewall einem TLS-Check. Das kann eine Bewertung durch Anbieter wie Qualys [5] sein oder Sie prüfen Ihre WAF in Eigenregie. Holen Sie sich dazu das Skript von testssl.sh [6] auf einen Linux-Rechner mit Internetzugang. Richten Sie das Skript mit
./testssl.sh www.example.net gegen Ihre WAF und gedulden sich ein paar Minuten. Im anschließenden Testbericht erfahren Sie, ob es noch Sicherheitslücken gibt.Wenn es etwas Stärkeres sein darf: Mit HTTPH4mm3r prasselt eine HTTP-Flut auf Ihre WAF ein [7]. Aber Vorsicht: Hierbei handelt es sich nicht mehr um einen harmlosen Test, sondern um ein reales Angriffswerkzeug. Achten Sie darauf, dass Sie die Erlaubnis des Kunden oder Arbeitgebers einholen, bevor der Hammer zuschlägt:
python3 HTTPH4mm3r.py --url https://gitea.example.net --port 443
SafeLine per API ins Monitoring einbinden
Heutzutage gehört eine Programmierschnittstelle zu den guten Umgangsformen. So lässt sich auch SafeLine per API steuern und Werte entlocken. Der Zugriff auf das API benötigt ein Zugangstoken, das Sie im Web-UI unter "Settings / Management / API Token" erzeugen können. Der aufrufende Client muss dieses Token im HTTP-Header mitsenden. Das folgende cURL-Kommando erfragt den Systemstatus der WAF. SafeLine formuliert die Antwort im JSON-Format, das sich mit Tools wie jq leicht weiterverarbeiten lässt:
curl https://safeline.example.net: 9443/api/open/system --header 'X-SLCE-API-TOKEN: XOuEMO...' --header 'accept: application/json'
Per API können Sie die WAF in ein Monitoringsystem einbinden und auf interne Zustände reagieren. Beispielsweise befragt Grafana in Bild 3 das SafeLine-API und visualisiert die Anzahl der Webzugriffe.
Editionen und Lizenzgrenzen im Überblick
Die kostenpflichtigen Funktionen sind in der Webseite im freien Modus sichtbar und sollen neugierig machen. Manche Funktionen haben ein hellblaues Zeichen neben dem Namen; ein Hinweis auf ein Feature der Lite- oder Pro-Version. Bei anderen Funktionen erfahren Sie erst nach der Einrichtung beim Klick auf "Save", dass es sich um ein kostenpflichtiges Extra handelt.
Die monatlichen Preise kommuniziert der Hersteller offen auf seiner Webseite [8]. Weniger offensichtlich ist der Preis von 1 US-Dollar für eine Evaluationslizenz, die sieben Tage gültig ist. Eine kostenpflichtige Lizenz steht an, wenn die installierte WAF mehr als 800 Anfragen pro Sekunde beantworten soll, die elfte Applikation beginnt, oder ein Feature von Lite/Pro interessant wird.
Fazit
SafeLine positioniert sich als containerisierte Web Application Firewall für eigene Infrastrukturen. Die Community-Variante ist kostenfrei erhältlich, allerdings sind Funktionsumfang und maximaler Durchsatz begrenzt. Für kleinere Umgebungen bietet sie jedoch ausreichend Möglichkeiten, Webanwendungen per Browser-Challenge, Rate Limiting und HTTP-spezifischem Regelwerk abzusichern. Neben der lokalen Variante steht die WAF auch als Cloudangebot bereit, bei dem der Anbieter Betrieb und Updates übernimmt. Hier sollte geprüft werden, in welchen Regionen die Verarbeitung erfolgt und welche Complianceanforderungen gelten. Auch wenn SafeLine nicht zu den etablierten globalen Plattformen zählt, deckt es die wesentlichen Funktionen einer klassischen WAF ab und eignet sich insbesondere für selbst betriebene Webdienste.
(ln)
Links
[1] BSI: Webanwendungen und Webservices (PDF): https://it-a.eu/q4z11
[2] SafeLine auf GitHub: https://it-a.eu/q4z12
[3] JA4+ Database: https://it-a.eu/q4z13
[4] Empfohlene SafeLine-Konfiguration: https://it-a.eu/q4z14
[5] Qualys SSL-Servertest: https://it-a.eu/hapb1
[6] Test der TLS/SSL-Verschlüsselung: https://it-a.eu/n2pe8
[7] HTTPH4mm3r: HTTP Flood Script: https://it-a.eu/q4z17
[8] Lizenzpläne für SafeLine: https://it-a.eu/q4z18