So stellen Sie SafeLine WAF auf einem Linux-VPS bereit

Zum Internet hin exponierte Webanwendungen werden routinemäßig auf SQL-Injection, Missbrauch von Anmeldedaten und bekannte Schwachstellenmuster abgetastet. SafeLine ist eine selbst gehostete WAF unter GPL-3.0 , die als Docker-Compose-Stack läuft und HTTP/S-Verkehr filtert, bevor zugelassene Anfragen an den Ursprungsserver weitergeleitet werden. Ihr kostenloser Personal-Tarif unterstützt bis zu 10 Anwendungen.

Dieses Tutorial behandelt die Installation und drei Bereiche, die besondere Aufmerksamkeit erfordern: die Entscheidung über die Reverse-Proxy-Architektur, die Docker-Netzwerkkonfiguration, wenn SafeLine hinter einem bestehenden Proxy wie Nginx Proxy Manager sitzt, und einen Prüfbefehl, den Sie nach der Installation ausführen können, um zu bestätigen, dass die WAF Angriffe tatsächlich abfängt.

Die Kurzfassung

• Installieren Sie SafeLine mit Docker Compose auf einem Linux-VPS. Verwenden Sie den einzeiligen Installer oder wählen Sie den manuellen Docker-Compose-Weg, um die Compose-Definition und die Umgebungskonfiguration zu prüfen, bevor Sie den Stack starten.
• Entscheiden Sie sich vor der Installation für die Reverse-Proxy-Architektur: SafeLine als einziger Proxy, SafeLine hinter einem bestehenden Nginx Proxy Manager oder SafeLine gemeinsam mit Caddy auf demselben Server. Jede Variante benötigt andere Portzuweisungen und X-Forwarded-For-Einstellungen.
• Überprüfen Sie die WAF nach der Installation, indem Sie mit curl eine SQL-Injection-Testanfrage an die geschützte URL senden. Im Modus Balanced oder Strict bestätigt eine 403-Antwort zusammen mit einem passenden Eintrag unter Attack Events die Blockierung. Im Modus Monitor bestätigt das passende Ereignis die Erkennung, auch wenn die Antwort erfolgreich bleiben kann.
• Der kostenlose Personal-Tarif umfasst bis zu 10 Anwendungen und die zentrale Erkennungs-Engine. Geoblocking, der Export von Angriffsprotokollen und externe Benachrichtigungen erfordern den Lite-Tarif; leistungsfähigere Angriffserkennung und Lastverteilung erfordern Pro.

Bevor Sie beginnen: Voraussetzungen und was dieses Tutorial behandelt

Dieses Tutorial setzt voraus, dass Sie einen Linux-VPS haben, auf den Sie sich per SSH mit Root- oder sudo-Zugriff verbinden können, und dass Docker installiert ist. Am Ende verfügen Sie über eine funktionierende SafeLine-Instanz, die mindestens eine Website schützt, sowie über einen Prüfbefehl, den Sie jederzeit erneut ausführen können.

Sie benötigen:

• Einen Linux-VPS. Die folgenden Befehle setzen ein System vom Typ Debian oder Ubuntu mit systemd voraus; überprüfen Sie Paket- und Dienstnamen bei anderen Distributionen.
• Mindestens 1 vCPU, 1 GB RAM und 5 GB Festplattenspeicher gemäß den offiziellen Bereitstellungsanforderungen. Für praxisgerechten Spielraum im Produktivbetrieb empfiehlt diese Anleitung 2 vCPU, 4 GB RAM und 20 GB Festplattenspeicher.
• Docker 20.10.14 oder neuer und Docker Compose 2.0 oder neuer.
• Eine x86_64-CPU mit SSSE3-Unterstützung; überprüfen Sie dies mit lscpu | grep ssse3 , anstatt anzunehmen, dass der Befehlssatz vorhanden ist.
• Eine Domain oder Subdomain, deren DNS auf die öffentliche IP des VPS zeigt, falls Sie die geschützte Anwendung über öffentliches HTTPS zugänglich machen möchten.
• Ports, die zur gewählten Topologie passen. Bei den Varianten A und C erhält SafeLine normalerweise die Ports 80 und 443, während Variante B diese Ports beim Nginx Proxy Manager belässt und SafeLine einen anderen Listener wie 10080 zuweist.
• Root- oder sudo-Zugriff.

Geben Sie in der Firewall oder Sicherheitsgruppe des VPS-Anbieters nur die öffentlichen Ports frei, die die gewählte Topologie benötigt. Beschränken Sie SSH und TCP 9443 auf vertrauenswürdige Administrationsquellen. Halten Sie in Variante B TCP 10080 für öffentliches IPv4 und IPv6 geschlossen und halten Sie Backend-Ports wie 8080 in jeder Topologie privat. Ein direkter Zugriff auf 10080 würde NPM umgehen und die X-Forwarded-For-Vertrauensgrenze aushebeln.

Hinweis: Für die manuelle ARM64-Bereitstellung setzen Sie ARCH_SUFFIX=-arm. SafeLines offizielle Bereitstellungsdokumentation gibt an, dass ARM eine Pro-Lizenz erfordert und dass die Personal Edition auf ARM nicht unterstützt wird. Verwenden Sie für die Personal Edition einen x86_64-VPS.

Überprüfen Sie Docker, bevor Sie beginnen:

docker --version
docker compose version

Beide Befehle sollten installierte Versionen zurückgeben. Fahren Sie nur fort, wenn Docker Version 20.10.14 oder neuer und Docker Compose Version 2.0.0 oder neuer ist; andernfalls führen Sie ein Upgrade durch, bevor Sie SafeLine installieren.

Wählen Sie zuerst Ihre Reverse-Proxy-Architektur

Auf einem frisch aufgesetzten VPS kann SafeLine die Ports 80 und 443 vollständig für sich beanspruchen. Auf einem VPS, der bereits Nginx Proxy Manager, Caddy oder das eigene Nginx der Anwendung betreibt, ist das nicht der Fall, und die Architekturentscheidung macht den Unterschied zwischen einer reibungslosen Installation und einem Portkonflikt beim ersten Start aus. Treffen Sie diese Entscheidung einmal richtig zu Beginn, und der Rest der Bereitstellung läuft mechanisch ab.

Die drei Varianten:

• Variante A, SafeLine als einziger Reverse-Proxy. SafeLine beansprucht die Ports 80 und 443 und verwaltet TLS für die geschützte Anwendung. Aktuelle CE-Releases enthalten einen Free-Cert-Workflow, während der manuelle Zertifikat-Upload weiterhin verfügbar bleibt; überprüfen Sie die genauen Zertifikatsoptionen im installierten Release. Das Backend läuft auf einem nicht öffentlichen Port, und SafeLine leitet dorthin weiter.
• Variante B, SafeLine hinter Nginx Proxy Manager (NPM). NPM behält die Ports 80 und 443 und übernimmt SSL. SafeLine lauscht auf Port 10080 (nur HTTP, da NPM TLS bereits terminiert hat). NPM leitet an SafeLine weiter; SafeLine leitet an das Backend weiter. Dies ist ein üblicher Aufbau, wenn NPM bereits bereitgestellt ist.
• Variante C, SafeLine neben Caddy. Caddys automatisches HTTPS konkurriert mit SafeLine um Port 443. Eine praktikable Anordnung gibt SafeLine die Ports 80 und 443 und verschiebt Caddy auf einen nicht öffentlichen internen HTTP-Port wie 8080 für den Sprung von SafeLine über Caddy zur Anwendung.

Wichtigste Erkenntnis: Variante A ist für einen frischen VPS am einfachsten; Variante B ist die richtige Wahl, wenn NPM bereits läuft; Variante C erfordert eine bewusste Neuzuweisung des Caddy-Ports.

SafeLine auf Ihrem VPS installieren

Die Installation selbst ist der einfache Teil. SafeLine bietet zwei Installationswege: einen automatisierten Installer, der ein Remote-Skript von waf.chaitin.com abruft, und einen manuellen Docker-Compose-Weg, mit dem Sie alles prüfen können, bevor es ausgeführt wird. Wählen Sie den Weg, der zu Ihrer Sicherheitsrichtlinie passt.

Schritt 1: Bestätigen Sie, dass Docker bereit ist

Überprüfen Sie erneut die Docker-Version und ob der Docker-Daemon läuft:

docker --version
docker compose version
sudo systemctl status docker

Die erwartete Ausgabe enthält active (running) für den Docker-Daemon. Falls er nicht läuft, starten Sie ihn mit sudo systemctl start docker und aktivieren Sie ihn beim Systemstart mit sudo systemctl enable docker.

Schritt 2: Führen Sie den SafeLine-Installer aus

Es gibt zwei Unterwege. Wählen Sie einen aus.

Schritt 2a, automatisierte Installation. Führen Sie den Installer mit Root-Rechten aus:

sudo bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Das Skript fragt, wo das SafeLine-Datenverzeichnis abgelegt werden soll, ruft die Docker-Images ab und startet den Stack. Führen Sie nach der Installation sudo docker exec safeline-mgt resetadmin aus, um die Administrator-Anmeldedaten abzurufen oder zurückzusetzen, wie im offiziellen Bereitstellungsleitfadenbeschrieben. Bewahren Sie die daraus resultierenden Anmeldedaten sicher auf.

Hinweis: Dieser Befehl lädt ein Remote-Shell-Skript von waf.chaitin.com herunter und führt es als Root aus. Der offizielle Einzeiler enthält curl -k, wodurch die TLS-Zertifikatsprüfung deaktiviert wird. Prüfen Sie das heruntergeladene Skript vor der Ausführung, oder verwenden Sie Schritt 2b, falls dieses Risiko nicht akzeptabel ist. SafeLine ist auch als Ein-Klick-Bereitstellung bei Cloudzy verfügbar, dieses Image verwendet jedoch /opt/safeline, /opt/safeline/.env, und /opt/safeline/docker-compose.yml. Verwenden Sie die in dieser Anleitung angegebenen /data/safeline Pfade nicht unverändert auf dem Cloudzy-Image.

Schritt 2b, manuelle Docker-Compose-Installation. Laden Sie die offizielle Compose-Datei herunter, prüfen Sie sie und starten Sie dann den Stack:

sudo mkdir -p /data/safeline
cd /data/safeline
sudo wget -O /data/safeline/compose.yaml "https://waf.chaitin.com/release/latest/compose.yaml"
POSTGRES_PASSWORD="$(openssl rand -hex 32)"
sudo tee .env >/dev/null <<EOF
SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0
EOF
unset POSTGRES_PASSWORD
# Also adjust SUBNET_PREFIX if your VPS already uses 172.22.222.0/24.
sudo chmod 600 /data/safeline/.env
sudo docker compose up -d

Nach docker compose up -d abgeschlossen ist, listen Sie die laufenden Container zur Bestätigung auf:

sudo docker compose ps

Sie sollten Container für safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi und safeline-chaos sehen. Falls ein Container Exitedanzeigt, finden Sie in Schritt 3 die beiden häufigsten Ursachen.

Schritt 3: Häufige Installationsfehler beheben

Zwei Fehler treten häufig genug auf, dass sie einen eigenen Schritt verdienen.

Subnetz-Überschneidung. Falls die Installation mit Pool overlaps with other one on this address spacefehlschlägt, kollidiert das Standard-SafeLine-Subnetz mit einem bestehenden Docker-Netzwerk. Wie in einer Schritt-für-Schritt-Anleitung zur SafeLine-Installationsfehlerbehebungdokumentiert, beheben Sie dies durch Bearbeiten von /data/safeline/.env:

sudo nano /data/safeline/.env
# Find the line:
#   SUBNET_PREFIX=172.22.222
# Change to an unused range, for example:
#   SUBNET_PREFIX=172.30.30
sudo docker compose -f /data/safeline/compose.yaml down
sudo docker compose -f /data/safeline/compose.yaml up -d

IPv6-Resolver-Fehler. Falls safeline-tengine mit nginx: [emerg] invalid IPv6 address in resolverabstürzt, prüfen Sie zuerst die Resolver-Datei und stellen Sie fest, wer sie verwaltet:

readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Bearbeiten Sie /etc/resolv.conf nicht direkt, falls sie von systemd-resolved, NetworkManager oder dem VPS-Anbieter erzeugt wird. Korrigieren Sie den fehlerhaften Nameserver-Wert in der Konfiguration des verwaltenden Dienstes, erzeugen Sie die Resolver-Datei neu und starten Sie dann Tengine neu:

sudo docker restart safeline-tengine

Schritt 4: Auf das Dashboard zugreifen

Das Management-Dashboard von SafeLine lauscht auf TCP 9443 über HTTPS. Lassen Sie diesen administrativen Port nicht für das gesamte Internet offen. Beschränken Sie ihn auf eine vertrauenswürdige Quelladresse oder ein VPN, oder sperren Sie den öffentlichen Zugriff und verwenden Sie einen SSH-Tunnel:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Öffne https://localhost:9443 durch den Tunnel. Beim ersten Zugriff ist eine Warnung wegen eines selbstsignierten Zertifikats zu erwarten; stellen Sie sicher, dass die SSH-Verbindung den vorgesehenen Server erreicht hat, bevor Sie fortfahren.

Falls Sie die ursprünglichen Anmeldedaten verloren haben, setzen Sie das Admin-Passwort vom Host aus zurück:

sudo docker exec safeline-mgt resetadmin

Der Befehl gibt Administrator-Anmeldedaten aus, mit denen Sie sich erneut anmelden können.

SafeLine für Ihre Architektur konfigurieren

SafeLine läuft jetzt, schützt aber noch nichts. Auf der Seite Applications im Dashboard teilen Sie SafeLine mit, welche Websites geschützt werden sollen und wohin der bereinigte Verkehr weitergeleitet wird. Die Konfiguration unterscheidet sich je nach der zuvor gewählten Architektur, daher erhält jede Variante einen eigenen Unterabschnitt. Bearbeiten Sie nur den, der zu Ihrem Aufbau passt.

Variante A: SafeLine als einziger Reverse-Proxy

Bei Variante A lauscht SafeLine direkt auf den Ports 80 und 443 und leitet den bereinigten Verkehr an Ihre Backend-Anwendung auf einem nicht öffentlichen Port weiter. Im Dashboard:

1. Navigieren Sie zu Applications, dann Add Application.
2. Setzen Sie den Listener-Port auf 443 und aktivieren Sie SSL. Verwenden Sie den Zertifikat-Workflow, der in Ihrem installierten SafeLine-Release verfügbar ist. Aktuelle CE-Releases umfassen die Free-Cert-Beantragung und -Erneuerung, während der manuelle Zertifikat-Upload weiterhin verfügbar bleibt.
3. Setzen Sie den Upstream auf http://127.0.0.1:8080. Falls das Backend in Docker läuft, veröffentlichen Sie seinen Port nur auf dem Loopback, zum Beispiel "127.0.0.1:8080:8080" im Ports-Abschnitt des Dienstes. Vermeiden Sie eine fest codierte Container-IP wie 172.17.0.5 , da sie sich ändern kann, wenn der Container neu erstellt wird.
4. Speichern Sie die Anwendung. SafeLine beginnt sofort, auf 443 zu lauschen und den bereinigten Verkehr an das Backend weiterzuleiten.
5. Stellen Sie sicher, dass der DNS-A-Eintrag Ihrer Domain auf die öffentliche IP des VPS zeigt und dass die Ports 80 und 443 von außen erreichbar sind.

Falls Port 443 bereits von einem anderen Prozess belegt war, kann der SafeLine-Container ihn nicht binden, und das Dashboard zeigt einen Fehler bei dieser Anwendung an. Stoppen Sie den in Konflikt stehenden Prozess oder wählen Sie einen anderen Port, bevor Sie die Anwendung hinzufügen.

Variante B: SafeLine hinter Nginx Proxy Manager

Variante B lässt NPM das tun, was es bereits tut (die Ports 80 und 443 beanspruchen, Let's Encrypt verwalten), und fügt SafeLine als dedizierte Sicherheitsebene dahinter ein. Der Verkehrsfluss ist: Client, dann NPM (Port 443, TLS-Terminierung), dann SafeLine (Port 10080, HTTP), dann die Backend-Anwendung.

Im SafeLine-Dashboard:

1. Applications, dann Add Application. Setzen Sie den Listener-Port auf 10080 und lassen Sie SSL deaktiviert (NPM hat TLS bereits terminiert).
2. Setzen Sie den Upstream auf die interne Adresse der Anwendung, wie bei Variante A beschrieben.
3. Speichern Sie die Anwendung.

In Nginx Proxy Manager:

1. Hosts, dann Proxy Hosts, dann Add Proxy Host.
2. Registerkarte Details: Legen Sie den Domainnamen fest, Schema http, und leiten Sie an Port 10080 weiter. Falls NPM direkt auf dem Host läuft, verwenden Sie 127.0.0.1 als Weiterleitungs-Hostname. Falls NPM in Docker unter Linux läuft, zeigt 127.0.0.1 auf den NPM-Container statt auf den VPS-Host. Fügen Sie Dockers host-gateway-Zuordnung zum NPM-Compose-Dienst hinzu und verwenden Sie dann host.docker.internal als Weiterleitungs-Hostname:

extra_hosts:
  - "host.docker.internal:host-gateway"

Führen Sie aus dem NPM-Compose-Verzeichnis sudo docker compose up -d aus, damit der Container mit der neuen Host-Zuordnung neu erstellt wird.

3. Registerkarte SSL: beantragen Sie ein Let's-Encrypt-Zertifikat, erzwingen Sie SSL und aktivieren Sie HTTP/2.
4. Lassen Sie die Registerkarte Advanced von NPM für X-Forwarded-For leer. In der aktuellen NPM-Vorlagewird Advanced-Inhalt auf Server-Ebene eingefügt und überschreibt gemäß den Vererbungsregeln von NGINXnicht die generierten Header auf Location-Ebene. Die generierte Location sendet:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Die zweite Direktive hängt die von NPM beobachtete Adresse als rechtesten Wert an den Header an.

5. Speichern Sie den Proxy Host.

Konfigurieren Sie in SafeLine die Extraktion der Quell-IP erst, nachdem Sie die tatsächliche Header-Kette bestätigt haben. SafeLine 9.3.1 hat eine flexible XFF-Extraktion mit Richtungs- und Indexauswahl eingeführt.

1. Settings, dann Advanced, dann Real IP from Header. Setzen Sie den Header-Namen auf X-Forwarded-For.
2. Verwenden Sie die benutzerdefinierte Extraktion vom Ende des Headers und wählen Sie die von NPM hinzugefügte rechteste Adresse aus. Die genauen Indexbezeichnungen variieren je nach Version, überprüfen Sie das Ergebnis daher unter Logs, dann Access. Falls das installierte Release älter als 9.3.1 ist, aktualisieren Sie es, bevor Sie dieser Topologie folgen.
3. Falls Cloudflare oder ein anderes CDN vor NPM sitzt, konfigurieren Sie NPM zunächst so, dass es nur den veröffentlichten Proxy-Bereichen dieses Anbieters vertraut, damit die von NPM angehängte Adresse vertrauenswürdig ist. Wählen Sie keine feste Position, bevor Sie die tatsächliche Header-Kette geprüft und getestet haben.
4. Speichern Sie die Anwendung und laden Sie sie neu.

Testen Sie die Konfiguration von einem Rechner außerhalb des VPS:

curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"

Das SafeLine-Zugriffsprotokoll sollte Ihre echte öffentliche Adresse anzeigen, nicht 1.2.3.4 oder die Bridge-Adresse von NPM.

Verhindern Sie, dass Benutzer SafeLine umgehen, indem Sie den Backend-Listener privat halten. Veröffentlichen Sie bei einem Docker-Compose-Backend den Port nur auf dem Loopback:

ports:
  - "127.0.0.1:8080:8080"

Bei einem Dienst, der direkt auf dem Host läuft, konfigurieren Sie ihn so, dass er auf 127.0.0.1:8080 lauscht statt auf 0.0.0.0:8080. Überprüfen Sie beide internen Ports von einem Rechner außerhalb des VPS:

curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:10080"
curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:8080"

Die TCP-Verbindungen sollten abgelehnt werden oder ins Zeitlimit laufen. Ein HTTP-Fehler oder „Empty reply from server" bedeutet dennoch, dass der Port öffentlich erreichbar ist und abgesichert werden muss. Falls eine Loopback-Bindung nicht möglich ist, erstellen Sie Firewall-Regeln, die auf die tatsächliche Schnittstelle, das Docker-Netzwerk und den Zielcontainer zugeschnitten sind, anstatt eine generische DOCKER-USER-Regel anzuwenden.

Variante C: SafeLine mit Caddy

Bei Variante C übernimmt SafeLine die Ports 80 und 443; Caddy wechselt auf einen nicht öffentlichen internen HTTP-Port. Der Verkehrsfluss ist: Client, dann SafeLine (443, TLS), dann Caddy (8080, internes HTTP), dann das Anwendungs-Backend.

Bearbeiten /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

Der :8080 Der Site-Block ist der wichtige Teil: Caddy lauscht jetzt auf einem internen HTTP-Port, anstatt mit SafeLine um 443 zu konkurrieren. Die bind 127.0.0.1 Zeile hält diesen Listener lokal auf dem VPS. Laden Sie Caddy mit sudo systemctl reload caddy neu und bestätigen Sie mit sudo ss -ltnp | grep -E ':(443|8080)' , dass Caddy an 8080 gebunden ist, nicht an 443.

Fügen Sie in SafeLine eine Anwendung hinzu, die mit aktiviertem SSL auf 443 lauscht, und setzen Sie dann den Upstream auf http://127.0.0.1:8080. Die X-Forwarded-For-Einstellung kann auf der Standardoption für die Netzwerkverbindung bleiben, da Caddy hinter SafeLine steht und nicht davor.

Wählen Sie einen Schutzmodus und überprüfen Sie, dass die WAF Angriffe blockiert

SafeLine verfügt über drei Schutzmodi, die entscheiden, was passiert, wenn die Engine eine Anfrage als bösartig einstuft. Der richtige Startmodus hängt von der Anwendung ab; der Prüfschritt ist in jedem Modus gleich.

Schutzmodi: Monitor, Balanced, Strict

Jede Anwendung in SafeLine hat ihre eigene Schutzmodus-Einstellung, konfigurierbar unter Applications, dann Ihre App, dann Protection Mode:

• Monitor. SafeLine protokolliert Anfragen, die es sonst blockieren würde, blockiert sie aber nicht. Dies ist der sicherste Ausgangspunkt für eine komplexe Produktivanwendung mit umfangreichen Eingabeformularen (ein Forum, ein Admin-Panel mit WYSIWYG-Feldern, eine API, die frei formulierte JSON-Payloads akzeptiert). Betreiben Sie Monitor einige Tage lang, überprüfen Sie die Seite Attack Events und stellen Sie sicher, dass es keine falsch-positiven Treffer gegen echte Nutzer gibt, bevor Sie zu Balanced wechseln.
• Balanced. Der Standardmodus. SafeLines vom Hersteller auf GitHub veröffentlichte Zahlen geben für den Modus Balanced 71.65% Erkennung, 99.45% Genauigkeit und eine Falsch-Positiv-Rate von 0.07% an. Für den Modus Strict werden 76.17% Erkennung, 99.38% Genauigkeit und eine Falsch-Positiv-Rate von 0.22% angegeben. Dies sind vom Hersteller gemeldete Ergebnisse und kein unabhängiger Benchmark, und die README weist den Datensatz nicht als WAF-Eval aus. Betrachten Sie sie als vergleichende Produktkennzahlen, nicht als garantierte Leistung im Produktivbetrieb.
• Strict. Ein aggressiveres Regelwerk mit strengeren Heuristiken und dem oben gezeigten Kompromiss zwischen Erkennung und Falsch-Positiven. Einen Versuch wert nach ein bis zwei Wochen sauberem Betrieb im Modus Balanced, sobald Sie Ihren Verkehr verstehen.

Empfehlung: Balanced für eine frische Bereitstellung ohne Live-Verkehr, der gestört werden könnte. Beginnen Sie bei einer bestehenden Produktivanwendung einige Tage lang mit Monitor, suchen Sie im Attack-Events-Protokoll nach Falsch-Positiven und wechseln Sie zu Balanced, sobald Sie etwaige Ausnahmen angepasst haben. Strict ist nach ein bis zwei Wochen mit Balanced einen Versuch wert, sobald Sie Ihren Verkehr verstehen.

Überprüfen Sie die WAF mit einem curl-SQLi-Test

Der letzte Schritt, bevor Sie die Installation als abgeschlossen betrachten, besteht darin, zu bestätigen, dass die WAF einen Angriff tatsächlich abfängt. Führen Sie von einem beliebigen Rechner außerhalb des VPS eine harmlose SQL-Injection-Testanfrage gegen Ihre geschützte Website aus:

curl -i "https://yourdomain.com/?id=1%20and%201=2%20union%20select%201"

Dies ist der von SafeLine veröffentlichte SQL-Injection-Testvektor. Erwarten Sie im Modus Balanced oder Strict einen 403-Status und eine SafeLine-Blockierungsantwort. Erwarten Sie im Modus Monitor, dass die Anfrage protokolliert, aber nicht blockiert wird. Die HTTP-Version und der genaue Antworttext können variieren, bestätigen Sie das Ergebnis daher mit einem passenden Eintrag unter Attack Events.

Öffnen Sie dann das Dashboard über die eingeschränkte Zugriffsmethode aus Schritt 4 und navigieren Sie zu Logs, dann Attack Events. Sie sollten einen neuen Eintrag mit dem passenden Zeitstempel, dem Angriffstyp SQL Injection, einer Quell-IP, die dem Rechner entspricht, von dem aus Sie curl ausgeführt haben, und der beanstandeten Query-Zeichenkette im Anfragedetail sehen. Klicken Sie auf das Ereignis, um die vollständige von SafeLine erfasste Anfrage und Antwort zu sehen.

Falls die curl-Anfrage 200 OK zurückgegeben hat, interpretieren Sie das Ergebnis zusammen mit dem Attack-Events-Protokoll:

• Ein passendes SQL-Injection-Ereignis bedeutet, dass sich die Anwendung wahrscheinlich im Modus Monitor befindet; Protokollieren ohne Blockieren ist zu erwarten.
• Falls es kein passendes Ereignis gibt, stellen Sie sicher, dass DNS auf den vorgesehenen VPS auflöst, überprüfen Sie die SafeLine-Listener- und Upstream-Konfiguration und gleichen Sie die Anfragezeit mit dem Zugriffsprotokoll von SafeLine ab.
• Bestätigen Sie außerdem, dass der Schutz aktiviert ist und dass keine IP-Whitelist, benutzerdefinierte Zulassungsregel oder Pfadausnahme die Testanfrage abdeckt.

Wichtigste Erkenntnis: Falls die curl-Testanfrage 403 mit der SafeLine-Abfangseite zurückgibt und unter Attack Events ein Eintrag mit dem Angriffstyp SQL Injection erscheint, fängt die WAF den Verkehr korrekt ab.

Was der kostenlose Tarif abdeckt und was einen kostenpflichtigen Tarif erfordert

Der kostenlose Personal-Tarif reicht aus, um die meisten Bereitstellungen auf einem einzelnen VPS zu schützen. Die kostenpflichtigen Tarife werden relevant, wenn Sie betriebliche Funktionen benötigen (Benachrichtigungen, Protokollexport, Geoblocking) oder die Grenze von 10 Anwendungen überschreiten.

Die Aufschlüsselung, entnommen aus der CyberServal-Preisseite:

• Personal, kostenlos. Bis zu 10 Anwendungen. Enthält die semantische Erkennungs-Engine (SQLi, XSS, Command Injection, Path Traversal, SSRF, XXE, CRLF), Ratenbegrenzung, Bot-CAPTCHA-Challenge, dynamische HTML/JS-Verschlüsselung gegen automatisierte Scraper, Web-ACL-Regeln und Zertifikatsverwaltung. Aktuelle CE-Releases umfassen ebenfalls die Free-Cert-Beantragung und -Erneuerung.
• Lite, $10/Monat oder $100/Jahr. Fügt Geoblocking, die Threat-Intelligence-IP-Datenbank, die Benachrichtigungsintegration für Discord und Telegram sowie den Export von Angriffsprotokollen hinzu und erhöht das Anwendungslimit auf 20.
• Pro, $100/Monat oder $1,000/Jahr. Fügt leistungsfähigere Angriffserkennung, dienstspezifische und globale Konfigurationen, benutzerdefinierte Abfangseiten, Upstream-Lastverteilung, Master-Slave-Knotensynchronisation und unbegrenzte Anwendungen hinzu. Siehe die aktuelle Preistabelle für Änderungen.
• Ultimate, individuelle Preisgestaltung. Maßgeschneiderte Unternehmenskonditionen mit persönlichem 1-zu-1-Support über alle Kanäle und individueller Funktionsentwicklung.

SafeLine verarbeitet und speichert Anwendungsdaten innerhalb seines lokalen Compose-Stacks. Allerdings erwähnen die aktuellen CE-Release-Notes Threat Intelligence Sharing, daher sollten Betreiber die UEP-, Datenschutz- und Freigabeeinstellungen der installierten Version prüfen und ausgehende Verbindungen beobachten, bevor sie die Bereitstellung als frei von ausgehendem Datenverkehr behandeln.

Wie es von hier aus weitergeht

Die Installation ist abgeschlossen und die WAF ist überprüft. Einige Folgeaufgaben tragen dazu bei, die Bereitstellung gesund zu halten.

• Setzen Sie für jede Produktivanwendung mit umfangreichen Nutzereingaben (ein Forum, ein Admin-Panel, eine frei formulierte API) den Schutzmodus auf Bildschirm für drei bis sieben Tage, überprüfen Sie die Seite Attack Events täglich und wechseln Sie zu Balanced, sobald Sie etwaige Falsch-Positive angepasst haben.
• Richten Sie im Lite-Tarif die Benachrichtigungsintegration für Discord oder Telegram ein, damit Angriffswarnungen Sie auch außerhalb des Dashboards erreichen.
• Planen Sie ein monatliches Wartungsfenster ein. Sichern Sie vor einem Upgrade die Daten und die Umgebungskonfiguration von SafeLine, lesen Sie die aktuellen Release-Notesund verwenden Sie das unterstützte Upgrade-Verfahren für Ihre installierte Version. Verlassen Sie sich nicht allein auf docker compose pull gefolgt von docker compose up -d, da sich die Compose-Definition oder die erforderlichen Umgebungsvariablen zwischen Releases ändern können. Cloudzy-Ein-Klick-Nutzer sollten von /opt/safeline ausgehen und den Anweisungen des Marketplace-Images folgen.
• Abonnieren Sie die SafeLine-Releases-Seite für Benachrichtigungen zu Sicherheitspatches und das Projekt-Repository für die Nachverfolgung von Problemen.

Falls Sie noch keinen VPS für diese Bereitstellung haben, ist SafeLine als Ein-Klick-Bereitstellung verfügbar in Cloudzy's Marketplace. Ein Tarif mit 4 GB RAM bietet den praktischen Spielraum, der in diesem Leitfaden empfohlen wird; prüfen Sie erneut die aktuelle Preistabelle auf Cloudzy zum Zeitpunkt der Veröffentlichung, da sich die Tarifspezifikationen ändern können. Das Ein-Klick-Image verwendet /opt/safeline und /opt/safeline/docker-compose.yml, sodass die Architektur- und Dashboard-Anweisungen gelten, die /data/safeline Befehle dieser Anleitung jedoch nicht identisch zutreffen.

Häufig gestellte Fragen

Ersetzt SafeLine WAF Nginx Proxy Manager, oder betreibe ich beide?

SafeLine kann Nginx Proxy Manager ersetzen, wenn es als einziger Reverse-Proxy bereitgestellt wird. Es muss NPM jedoch nicht ersetzen. Ein üblicher Aufbau behält NPM vorne für SSL und Routing und setzt SafeLine dahinter als dedizierte Sicherheitsebene. Beides funktioniert; die Wahl hängt davon ab, ob Sie ein Werkzeug für beide Aufgaben oder zwei Werkzeuge möchten, die jeweils eine Aufgabe gut erledigen.

Reicht der kostenlose Tarif für eine einzelne WordPress-Website oder ein kleines SaaS?

Ja, für den Schutz. Der kostenlose Personal-Tarif umfasst die semantische Erkennungs-Engine, Ratenbegrenzung, Bot-CAPTCHA-Challenge und dynamische HTML/JS-Verschlüsselung, die zentrale Abwehrmechanismen für eine einzelne Website sind. Die kostenpflichtigen Tarife fügen betriebliche Funktionen wie Geoblocking, den Export von Angriffsprotokollen, externe Benachrichtigungen, höhere Anwendungslimits, leistungsfähigere Erkennung und Lastverteilung hinzu. Ob ein kostenpflichtiger Tarif erforderlich ist, hängt von den benötigten Funktionen und der Anzahl der Anwendungen ab, nicht allein vom Verkehrsaufkommen.

Funktioniert SafeLine auf einem VPS mit 1 GB RAM?

SafeLines offizielles Minimum liegt bei 1 GB RAM. Das kann für Tests oder eine sehr geringe Last ausreichen, aber die Produktivkapazität hängt vom Verkehr, den aktivierten Funktionen und der Protokollaufbewahrung ab. Für eine kleine Produktivbereitstellung sind 2 vCPU und 4 GB RAM ein konservativer Ausgangspunkt; überwachen Sie die Speichernutzung und skalieren Sie anhand der gemessenen Last.

Warum erfordert ARM64 eine kostenpflichtige Lizenz?

SafeLines offizielle Bereitstellungsdokumentation gibt an, dass ARM-Bereitstellungen eine Pro-Lizenz erfordern und dass die Personal Edition auf ARM nicht unterstützt wird. Falls Sie die Personal Edition möchten, wählen Sie einen x86_64-VPS; falls Sie ARM benötigen, planen Sie eine Pro-Lizenz ein.

Was erhält Chaitin Tech von meiner SafeLine-Instanz?

Die genauen ausgehenden Daten können je nach Release und aktivierten Funktionen variieren. Aktuelle CE-Release-Notes erwähnen Threat Intelligence Sharing, während die installierte Version möglicherweise auch UEP oder andere Freigabeeinstellungen bereitstellt. Prüfen Sie diese Einstellungen und die Release-Notes für Ihre installierte Version und validieren Sie dann den ausgehenden Datenverkehr auf Netzwerkebene. Die lokalen Container von SafeLine verarbeiten Anwendungsdaten, aber diese Tatsache allein beweist nicht, dass das Ablehnen von UEP jede ausgehende Anfrage unterbindet.