SafeLine im Detailblick: die selbst gehostete WAF aus Go zwischen Bewertungstabelle und GPL-Pflichten
SafeLine ist ein selbstgehosteter WAF (Web Application Firewall)/Reverse-Proxy zum Schutz Ihrer Webanwendungen vor Angriffen und Exploits.
Auf einen Blick
- Was ist das?
- Wie chaitin/SafeLine als Reverse-Proxy vor Webanwendungen arbeitet, welche fünf Schutzmechanismen das README ausweist und warum die eigene Effect Evaluation mit Vorsicht zu lesen ist.
- Für wen ist es gedacht?
- SafeLine passt zu Betreibern, die eine selbst gehostete WAF mit eigener Kontrolle suchen und bereit sind, das Deployment über die externe Doku unter docs.waf.chaitin.com abzuwickeln. Weniger geeignet ist sie, wenn eine verwaltete Cloud-Lösung mit Supportvertrag gewünscht ist.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
SafeLine als Reverse-Proxy vor dem eigenen Server
SafeLine von Chaitin ist eine selbst gehostete Web Application Firewall, die Webanwendungen vor Angriffen und Exploits abschirmen soll. Die Codebasis steht unter GPL-3.0 und ist in Go geschrieben; das Repository verzeichnet 22.459 Sterne, 1.512 Forks und lediglich 64 offene Issues, der main-Branch wurde zuletzt am 17. August 2026 gepusht.
Das Architekturprinzip beschreibt das README in Netzwerkbegriffen: Die WAF stellt sich als Reverse-Proxy zwischen Internet und Anwendung. Ein gewöhnlicher Proxy schützt die Identität eines Clients; hier kehrt sich die Richtung um, denn die Clients passieren die Firewall, bevor sie den Server erreichen, und der Server bleibt so vor direkter Exponierung bewahrt. Als Angriffsklassen nennt das README unter anderem SQL-Injection, XSS, Code-Injection, OS-Command-Injection, CRLF- und LDAP-Injection, RCE, XXE, SSRF, Path Traversal, Backdoors, Brute Force, HTTP-Flood sowie Bot-Missbrauch. Wer die eigene Anwendung bewerten will, sollte diese Liste gegen die tatsächliche Angriffsfläche der eigenen App halten, denn nicht jede Klasse ist in jedem Stack relevant.
Fünf Schutzmechanismen von Rate Limiting bis Dynamic Protection
Der Feature-Abschnitt des README gruppiert die Fähigkeiten in fünf Blöcke. Block Web Attacks deckt die genannten Injektions- und Exploit-Klassen ab. Rate Limiting drosselt Verkehr jenseits definierter Grenzen und richtet sich gegen DoS-Versuche, Brute Force und Verkehrsspitzen. Die Anti-Bot-Challenge lässt Menschen durch und blockiert Crawler sowie Bots.
Der vierte Block ist die Authentication Challenge: Ist sie aktiviert, müssen Besucher ein Passwort eingeben, sonst bleiben sie draußen. Das eignet sich für Staging-Umgebungen oder interne Werkzeuge, weniger für öffentliche Seiten. Der fünfte Block, Dynamic Protection, verschlüsselt HTML- und JS-Code bei jedem Aufruf dynamisch neu, was Scraping und automatisierte Analyse erschweren soll. Zusätzlich nennt der Einführungsteil IP-basiertes Rate Limiting und Web Access Control Lists als Kernfähigkeiten. Eine Live-Demo steht unter demo.waf.chaitin.com auf Port 9443 bereit, dort lassen sich die Mechanismen ohne eigene Installation ansehen.
Deployment außerhalb des README: der Weg über docs.waf.chaitin.com
Der Quickstart-Abschnitt enthält auffällig wenig: keine Installationsbefehle, keine Systemvoraussetzungen. Beides verlagert das Projekt auf externe Seiten, den Deploy-Leitfaden unter docs.waf.chaitin.com/en/GetStarted/Deploy und die Anleitung zum Schutz von Anwendungen unter docs.waf.chaitin.com/en/GetStarted/AddApplication. Wer die WAF bewerten will, muss diese Dokumente also separat prüfen; das Repository allein reicht nicht aus.
Bemerkenswert ist eine Warnung am Anfang des Quickstart: Anwender auf dem chinesischen Festland könnten bei der internationalen Version keine Verbindung zu den Cloud-Diensten bekommen, weshalb auf eine eigene, chinesischsprachige Installationsdokumentation unter docs.waf-ce.chaitin.cn verwiesen wird. Diese Spaltung in zwei Installationspfade zeigt, dass Teile der Funktionalität an Cloud-Dienste des Herstellers hängen. Genau das sollte man vor dem Einsatz klären, denn eine WAF, deren Schutz in der Path-to-Production-Doku beginnt, verlangt eine saubere Nachverfolgung der verwendeten Version.
Die Effect-Evaluation mit 33.669 Samples: selbst berichtet und ohne Methode
Im Abschnitt More Informations steht eine Vergleichstabelle mit dem Titel Effect Evaluation. Sie beziffert Detection, False Positives und Accuracy für vier Konfigurationen: ModSecurity auf Level 1, CloudFlare Free, SafeLine im Balance-Profil und SafeLine im Strict-Profil, jeweils über 33.669 Samples.
Die Zahlen lauten wie folgt. Detection: 69,74 Prozent für ModSecurity, 10,70 Prozent für CloudFlare Free, 71,65 Prozent für Balance und 76,17 Prozent für Strict. Fehlalarme: 17,58 Prozent für ModSecurity, 0,07 Prozent für CloudFlare und Balance, 0,22 Prozent für Strict. Accuracy: 82,20, 98,40, 99,45 und 99,38 Prozent. Das sind laut README also Eigenangaben, und genau da liegt der Haken: Die Tabelle nennt weder Herkunft der Samples noch Testzeitraum noch Umgebung. Der Sprung von 10,70 auf 71,65 Prozent Detection liest sich stark, doch ohne reproduzierbaren Aufbau bleibt er eine Marketingaussage. Eigene Tests mit replizierten Angriffspatterns der eigenen Anwendung sind daher unverzichtbar, bevor man diesen Werten Operationsentscheidungen anvertraut.
MCP Server, Ingress-NGINX und Kong: die Integrationsschicht von SafeLine
Neben der WAF-Kernfunktion baut das Projekt eine Ökosystemschicht auf. Das README führt einen SafeLine MCP Server im Pfad mcp_server/README.md, der KI-gestützte Verwaltung und Steuerung der Firewall ermöglichen soll. Damit lässt sich ein Teil der Administration aus einem Modell heraus ansprechen, was bei einer Sicherheitskomponente sowohl Komfort als auch neue Angriffsfragen aufwirft, denn der Modellzugang braucht eigene Absicherung.
Zwei weitere Bausteine richten sich an Traffic-Ketten. Ein Plugin für Ingress-NGINX im Pfad sdk/ingress-nginx/ schützt Kubernetes-Ingress-Verkehr, ein weiteres Plugin im sdk-Verzeichnis zielt auf den Kong Gateway. Wer ohnehin schon Ingress-NGINX oder Kong betreibt, kann die WAF damit in die bestehende Infrastruktur einhängen, statt einen separaten Hop zu pflegen. Die Plugin-Dokumente liegen im Repository, sie sollten vor dem Entschluss gelesen werden, weil sich daraus ergibt, ob die eigene Version der Gateway-Software unterstützt wird.
GPL-3.0, Release v9.4.0 und die Grenzen der Selbstauskunft
Die Versionshistorie zeigt mit SafeLine-CE 9.3.10, 9.3.11 und 9.4.0 drei Releases zwischen dem 10. Juli und dem 17. August 2026. Der enge Takt spricht für aktive Pflege, zwingt aber auch dazu, beim Upgrade einer produktiven Firewall die Änderungen je Release gegen die eigene Regelkonfiguration zu prüfen, denn eine WAF sitzt im kritischen Pfad.
Das README behauptet Produktionsreife und stützt sie auf Zahlen aus einem externen Cyber-Press-Artikel: mehr als 400.000 Installationen weltweit, über 1.000.000 geschützte Websites und mehr als 30.000.000.000 HTTP-Anfragen täglich. Daneben stehen Anerkennungen wie eine 10,0/10-Bewertung von HelloGitHub und die Listung in awesome-selfhosted. Alles das sind Fremd- und Eigenzitate, keine reproduzierbaren Messungen. Die GPL-3.0 schließlich erlaubt Nutzung und Änderung, verlangt aber Offenlegung abgeleiteter Werke bei Weitergabe. Wer die WAF unverändert als Appliance vor eigene Anwendungen setzt, bleibt unberührt; wer sie in ein eigenes verteiltes Produkt einbaut, muss Quellcode liefern.
Redaktionelles Fazit
SafeLine passt zu Betreibern, die eine selbst gehostete WAF mit eigener Kontrolle suchen und bereit sind, das Deployment über die externe Doku unter docs.waf.chaitin.com abzuwickeln. Weniger geeignet ist sie, wenn eine verwaltete Cloud-Lösung mit Supportvertrag gewünscht ist. Vor dem Produktiveinsatz die Balance- und Strict-Profile gegen den eigenen Datenverkehr testen, Fehlalarme in der Konsole prüfen und prüfen, ob die GPL-3.0 mit der eigenen Vertriebsform vereinbar ist.
Community-Notizen