SafeLine WAF implementeren op een Linux VPS

Webapplicaties die aan het internet zijn blootgesteld, worden routinematig afgetast op SQL-injectie, misbruik van inloggegevens en bekende kwetsbaarheidspatronen. SafeLine is een zelfgehoste WAF onder GPL-3.0 die draait als een Docker Compose-stack en HTTP/S-verkeer filtert voordat toegestane verzoeken naar de origin worden doorgestuurd. Het gratis Personal-abonnement ondersteunt tot 10 applicaties.

Deze tutorial behandelt de installatie en drie aandachtsgebieden die bijzondere zorg vereisen: de keuze voor de reverse-proxyarchitectuur, de Docker-netwerkconfiguratie wanneer SafeLine achter een bestaande proxy zoals Nginx Proxy Manager staat, en een verificatiecommando dat je na installatie kunt uitvoeren om te bevestigen dat de WAF daadwerkelijk aanvallen onderschept.

De korte versie

• Installeer SafeLine op een Linux VPS met Docker Compose. Gebruik het installatieprogramma met een enkele regel, of kies de handmatige Docker Compose-route om de Compose-definitie en omgevingsconfiguratie te inspecteren voordat je de stack start.
• Bepaal de reverse-proxyarchitectuur voordat je installeert: SafeLine als enige proxy, SafeLine achter een bestaande Nginx Proxy Manager, of SafeLine die de server deelt met Caddy. Elke vorm vereist andere poorttoewijzingen en X-Forwarded-For-instellingen.
• Verifieer na installatie de WAF door met curl een SQL-injectietest naar de beschermde URL te sturen. In de modus Balanced of Strict bevestigt een 403-respons plus een overeenkomend item bij Attack Events dat er wordt geblokkeerd. In de Monitor-modus bevestigt het overeenkomende item de detectie, ook al blijft de respons mogelijk geslaagd.
• De gratis Personal-laag dekt tot 10 applicaties en de kern-detectie-engine. Geoblokkering, export van aanvalslogboeken en externe meldingen vereisen de Lite-laag; krachtigere aanvalsdetectie en load balancing vereisen Pro.

Voordat je begint: vereisten en wat deze tutorial behandelt

Deze tutorial gaat ervan uit dat je een Linux VPS hebt waarop je met root- of sudo-toegang via SSH kunt inloggen en dat Docker is geïnstalleerd. Je eindigt met een werkende SafeLine-instantie die ten minste één site beschermt en een verificatiecommando dat je op elk moment opnieuw kunt uitvoeren.

Je hebt nodig:

• Een Linux VPS. De onderstaande commando's gaan uit van een Debian- of Ubuntu-achtig systeem met systemd; verifieer de namen van pakketten en services op andere distributies.
• Minimaal 1 vCPU, 1 GB RAM en 5 GB schijfruimte volgens de officiële implementatievereisten. Voor praktische speelruimte in productie raadt deze handleiding 2 vCPU, 4 GB RAM en 20 GB schijfruimte aan.
• Docker 20.10.14 of nieuwer en Docker Compose 2.0 of nieuwer.
• Een x86_64-CPU met SSSE3-ondersteuning; verifieer dit met lscpu | grep ssse3 in plaats van aan te nemen dat de instructie aanwezig is.
• Een domein of subdomein met DNS dat naar het publieke IP van de VPS verwijst als je de beschermde applicatie via publieke HTTPS wilt aanbieden.
• Poorten die passen bij de gekozen topologie. Vorm A en C geven SafeLine normaal gesproken poort 80 en 443, terwijl Vorm B die poorten bij Nginx Proxy Manager laat en SafeLine een andere listener toewijst, zoals 10080.
• Root- of sudo-toegang.

Stel bij de firewall of security group van de VPS-provider alleen de publieke poorten open die de gekozen topologie nodig heeft. Beperk SSH en TCP 9443 tot vertrouwde administratiebronnen. Houd in Vorm B TCP 10080 gesloten voor publieke IPv4 en IPv6, en houd backendpoorten zoals 8080 in elke topologie privé. Directe toegang tot 10080 zou NPM omzeilen en de X-Forwarded-For-vertrouwensgrens ongeldig maken.

Opmerking: Voor handmatige ARM64-implementatie stel je ARCH_SUFFIX=-arm. SafeLine's officiële implementatiedocumentatie vermeldt dat ARM een Pro-licentie vereist en dat de Personal Edition niet wordt ondersteund op ARM. Gebruik een x86_64-VPS voor de Personal Edition.

Verifieer Docker voordat je begint:

docker --version
docker compose version

Beide commando's moeten geïnstalleerde versies teruggeven. Ga alleen verder als Docker versie 20.10.14 of nieuwer is en Docker Compose versie 2.0.0 of nieuwer; upgrade anders voordat je SafeLine installeert.

Kies eerst je reverse-proxyarchitectuur

Op een verse VPS kan SafeLine poort 80 en 443 volledig in bezit nemen. Een VPS waarop al Nginx Proxy Manager, Caddy of de eigen Nginx van de applicatie draait, kan dat niet, en de keuze voor de architectuur is het verschil tussen een soepele installatie en een poortconflict bij de eerste boot. Doe dit aan het begin één keer goed en de rest van de implementatie is mechanisch.

De drie vormen:

• Vorm A, SafeLine als enige reverse proxy. SafeLine bezit poort 80 en 443 en beheert TLS voor de beschermde applicatie. Huidige CE-releases bevatten een Free Cert-workflow, terwijl handmatige certificaatupload beschikbaar blijft; verifieer de precieze certificaatopties in de geïnstalleerde release. De backend draait op een niet-publieke poort en SafeLine routeert ernaartoe.
• Vorm B, SafeLine achter Nginx Proxy Manager (NPM). NPM behoudt poort 80 en 443 en verzorgt SSL. SafeLine luistert op poort 10080 (alleen HTTP, aangezien NPM TLS al heeft afgehandeld). NPM stuurt door naar SafeLine; SafeLine stuurt door naar de backend. Dit is een veelvoorkomende opzet wanneer NPM al is geïmplementeerd.
• Vorm C, SafeLine naast Caddy. De automatische HTTPS van Caddy concurreert met SafeLine om poort 443. Een werkbare opzet geeft SafeLine poort 80 en 443 en verplaatst Caddy naar een niet-publieke interne HTTP-poort zoals 8080 voor de hop van SafeLine naar Caddy naar applicatie.

Kernpunt: Vorm A is het eenvoudigst voor een verse VPS; Vorm B is de juiste keuze wanneer NPM al draait; Vorm C vereist een bewuste herindeling van de Caddy-poort.

Installeer SafeLine op je VPS

De installatie zelf is het makkelijke deel. SafeLine biedt twee installatieroutes: een geautomatiseerd installatieprogramma dat een extern script van waf.chaitin.com ophaalt, en een handmatige Docker Compose-route waarmee je alles kunt inspecteren voordat het draait. Kies de route die past bij je beveiligingsbeleid.

Stap 1: bevestig dat Docker klaar is

Controleer opnieuw de Docker-versie en of de Docker-daemon draait:

docker --version
docker compose version
sudo systemctl status docker

De verwachte uitvoer bevat active (running) voor de Docker-daemon. Als deze niet draait, start hem dan met sudo systemctl start docker en schakel hem in bij het opstarten met sudo systemctl enable docker.

Stap 2: voer het SafeLine-installatieprogramma uit

Er zijn twee subroutes. Kies er een.

Stap 2a, geautomatiseerde installatie. Voer het installatieprogramma uit met root-rechten:

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

Het script vraagt waar de SafeLine-datamap moet komen, haalt de Docker-images op en start de stack. Voer na de installatie sudo docker exec safeline-mgt resetadmin uit om de beheerdersgegevens op te halen of te resetten, zoals beschreven in de officiële implementatiehandleiding. Bewaar de resulterende inloggegevens veilig.

Opmerking: Dit commando downloadt en voert als root een extern shellscript van waf.chaitin.com uit. De officiële one-liner bevat curl -k, waarmee TLS-certificaatverificatie wordt uitgeschakeld. Bekijk het gedownloade script voordat je het uitvoert, of gebruik Stap 2b als dat risico onaanvaardbaar is. SafeLine is ook beschikbaar als een one-click Cloudzy-implementatie, maar die image gebruikt /opt/safeline, /opt/safeline/.env, en /opt/safeline/docker-compose.yml. Gebruik de /data/safeline paden uit deze handleiding niet ongewijzigd op de Cloudzy-image.

Stap 2b, handmatige Docker Compose-installatie. Download en inspecteer het officiële Compose-bestand en start vervolgens de 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

Na docker compose up -d klaar is, geef dan de draaiende containers weer om te bevestigen:

sudo docker compose ps

Je zou containers moeten zien voor safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi en safeline-chaos. Als een container Exitedtoont, raadpleeg dan Stap 3 voor de twee meest voorkomende oorzaken.

Stap 3: los veelvoorkomende installatiefouten op

Twee fouten komen vaak genoeg voor om een eigen stap te verdienen.

Subnetoverlap. Als de installatie mislukt met Pool overlaps with other one on this address space, dan conflicteert het standaard SafeLine-subnet met een bestaand Docker-netwerk. Zoals gedocumenteerd in een stapsgewijze probleemoplossing voor SafeLine-installatie, los je dit op door /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-resolverfout. Als safeline-tengine crasht met nginx: [emerg] invalid IPv6 address in resolver, inspecteer dan eerst het resolverbestand en bepaal wie het beheert:

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

Bewerk /etc/resolv.conf niet rechtstreeks als het wordt gegenereerd door systemd-resolved, NetworkManager of de VPS-provider. Corrigeer de onjuiste nameserver-waarde in de configuratie van de beherende service, genereer het resolverbestand opnieuw en herstart vervolgens Tengine:

sudo docker restart safeline-tengine

Stap 4: open het dashboard

Het beheerdashboard van SafeLine luistert op TCP 9443 via HTTPS. Laat deze administratieve poort niet openstaan voor het hele internet. Beperk hem tot een vertrouwd bronadres of VPN, of blokkeer publieke toegang en gebruik een SSH-tunnel:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Open https://localhost:9443 via de tunnel. Een waarschuwing over een zelfondertekend certificaat is bij de eerste toegang te verwachten; controleer of de SSH-verbinding de beoogde server heeft bereikt voordat je verdergaat.

Als je de oorspronkelijke inloggegevens kwijt bent, reset dan het beheerderswachtwoord vanaf de host:

sudo docker exec safeline-mgt resetadmin

Het commando toont beheerdersgegevens waarmee je opnieuw kunt inloggen.

Configureer SafeLine voor je architectuur

SafeLine draait nu, maar beschermt nog niets. Op de pagina Applications van het dashboard vertel je SafeLine welke sites het moet beschermen en waarheen het gefilterd verkeer moet doorsturen. De configuratie verschilt afhankelijk van de architectuur die je eerder hebt gekozen, dus elke vorm krijgt een eigen subsectie. Werk alleen de vorm door die bij je opzet past.

Vorm A: SafeLine als enige reverse proxy

Bij Vorm A luistert SafeLine rechtstreeks op poort 80 en 443 en stuurt gefilterd verkeer door naar je backendapplicatie op een niet-publieke poort. In het dashboard:

1. Ga naar Applications, daarna Add Application.
2. Stel de luisterpoort in op 443 en schakel SSL in. Gebruik de certificaatworkflow die beschikbaar is in je geïnstalleerde SafeLine-release. Huidige CE-releases bevatten Free Cert-aanvraag en -verlenging, terwijl handmatige certificaatupload beschikbaar blijft.
3. Stel de upstream in op http://127.0.0.1:8080. Als de backend in Docker draait, publiceer de poort dan alleen op loopback, bijvoorbeeld "127.0.0.1:8080:8080" in de ports-sectie van de service. Vermijd een hardcoded container-IP zoals 172.17.0.5 omdat dit kan veranderen wanneer de container opnieuw wordt aangemaakt.
4. Sla de applicatie op. SafeLine begint direct te luisteren op 443 en gefilterd verkeer naar de backend door te sturen.
5. Bevestig dat het DNS A-record van je domein naar het publieke IP van de VPS verwijst en dat poort 80 en 443 van buitenaf bereikbaar zijn.

Als poort 443 al door een ander proces in gebruik was, kan de container van SafeLine zich niet binden en toont het dashboard een fout bij die applicatie. Stop het conflicterende proces, of kies een andere poort, voordat je de applicatie toevoegt.

Vorm B: SafeLine achter Nginx Proxy Manager

Vorm B laat NPM doen wat het al doet (poort 80 en 443 bezitten, Let's Encrypt afhandelen) en plaatst SafeLine erachter als een toegewijde beveiligingslaag. De verkeersstroom is: client, dan NPM (poort 443, TLS-terminatie), dan SafeLine (poort 10080, HTTP), dan de backendapplicatie.

In het SafeLine-dashboard:

1. Applications, daarna Add Application. Stel de luisterpoort in op 10080 en laat SSL uit (NPM heeft TLS al afgehandeld).
2. Stel de upstream in op het interne adres van de applicatie, zoals beschreven in Vorm A.
3. Sla de applicatie op.

In Nginx Proxy Manager:

1. Hosts, dan Proxy Hosts, dan Add Proxy Host.
2. Tabblad Details: stel de domeinnaam in, schema http, en forward-poort 10080. Als NPM rechtstreeks op de host draait, gebruik je 127.0.0.1 als forward-hostnaam. Als NPM in Docker op Linux draait, 127.0.0.1 verwijst naar de NPM-container in plaats van de VPS-host. Voeg Docker's host-gateway-mapping toe aan de NPM Compose-service en gebruik vervolgens host.docker.internal als forward-hostnaam:

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

Voer vanuit de NPM Compose-map sudo docker compose up -d uit zodat de container opnieuw wordt aangemaakt met de nieuwe host-mapping.

3. Tabblad SSL: vraag een Let's Encrypt-certificaat aan, forceer SSL en schakel HTTP/2 in.
4. Laat het tabblad Advanced van NPM leeg voor X-Forwarded-For. In de huidige NPM-templatewordt Advanced-inhoud op serverniveau ingevoegd en overschrijft deze de gegenereerde headers op location-niveau niet volgens de overervingsregels van NGINX. De gegenereerde location stuurt:

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

De tweede directive voegt het door NPM waargenomen adres als meest rechtse waarde aan de header toe.

5. Sla de Proxy Host op.

Terug in SafeLine configureer je de extractie van het bron-IP pas nadat je de effectieve headerketen hebt bevestigd. SafeLine 9.3.1 introduceerde flexibele XFF-extractie met keuze van richting en index.

1. Settings, dan Advanced, dan Real IP from Header. Stel de headernaam in op X-Forwarded-For.
2. Gebruik aangepaste extractie vanaf het einde van de header en selecteer het meest rechtse adres dat door NPM is toegevoegd. Exacte indexlabels verschillen per versie, dus verifieer het resultaat in Logs, daarna Access. Als de geïnstalleerde release ouder is dan 9.3.1, werk deze dan bij voordat je deze topologie volgt.
3. Als Cloudflare of een andere CDN vóór NPM staat, configureer NPM dan eerst zo dat het alleen de gepubliceerde proxyranges van die provider vertrouwt, zodat het door NPM toegevoegde adres betrouwbaar is. Selecteer geen vaste positie voordat je de daadwerkelijke headerketen hebt geïnspecteerd en getest.
4. Sla de applicatie op en laad deze opnieuw.

Test de configuratie vanaf een machine buiten de VPS:

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

Het SafeLine-toegangslogboek zou je echte publieke adres moeten tonen, niet 1.2.3.4 of het bridge-adres van NPM.

Voorkom dat gebruikers SafeLine omzeilen door de backend-listener privé te houden. Publiceer bij een Docker Compose-backend de poort alleen op loopback:

ports:
  - "127.0.0.1:8080:8080"

Configureer een service die rechtstreeks op de host draait zo dat deze luistert op 127.0.0.1:8080 in plaats van 0.0.0.0:8080. Verifieer beide interne poorten vanaf een machine buiten de VPS:

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

De TCP-verbindingen zouden geweigerd moeten worden of een time-out moeten geven. Een HTTP-fout of "Empty reply from server" betekent nog steeds dat de poort publiek bereikbaar is en beveiligd moet worden. Als binden op loopback onmogelijk is, maak dan firewallregels op maat voor de daadwerkelijke interface, het Docker-netwerk en de doelcontainer in plaats van een generieke DOCKER-USER-regel toe te passen.

Vorm C: SafeLine met Caddy

Bij Vorm C neemt SafeLine poort 80 en 443; Caddy verhuist naar een niet-publieke interne HTTP-poort. De verkeersstroom is: client, dan SafeLine (443, TLS), dan Caddy (8080, interne HTTP), dan de applicatiebackend.

Bewerken /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

De :8080 site-blok is het belangrijke deel: Caddy luistert nu op een interne HTTP-poort in plaats van met SafeLine om 443 te concurreren. De bind 127.0.0.1 regel houdt die listener lokaal op de VPS. Herlaad Caddy met sudo systemctl reload caddy en bevestig met sudo ss -ltnp | grep -E ':(443|8080)' dat Caddy gebonden is aan 8080, niet aan 443.

Voeg in SafeLine een applicatie toe die luistert op 443 met SSL ingeschakeld, en stel de upstream in op http://127.0.0.1:8080. De X-Forwarded-For-instelling kan op de standaard netwerkverbindingsoptie blijven staan omdat Caddy achter SafeLine staat, niet ervoor.

Kies een beschermingsmodus en verifieer dat de WAF aanvallen blokkeert

SafeLine heeft drie beschermingsmodi die bepalen wat er gebeurt wanneer de engine een verzoek als kwaadaardig markeert. De juiste startmodus hangt af van de applicatie; de verificatiestap is in elke modus hetzelfde.

Beschermingsmodi: Monitor, Balanced, Strict

Elke applicatie in SafeLine heeft een eigen instelling voor de beschermingsmodus, configureerbaar onder Applications, dan je app, dan Protection Mode:

• Monitor. SafeLine logt verzoeken die het anders zou blokkeren, maar blokkeert ze niet. Dit is het veiligste startpunt voor een complexe productieapplicatie met uitgebreide invoerformulieren (een forum, een adminpaneel met WYSIWYG-velden, een API die vrije JSON-payloads accepteert). Draai Monitor een paar dagen, bekijk de pagina Attack Events en bevestig dat er geen valse positieven bij echte gebruikers zijn voordat je naar Balanced promoveert.
• Balanced. De standaardmodus. De door de leverancier gepubliceerde GitHub-cijfers van SafeLine rapporteren 71.65% detectie, 99.45% nauwkeurigheid en een percentage valse positieven van 0.07% voor de Balanced-modus. Voor de Strict-modus wordt 76.17% detectie, 99.38% nauwkeurigheid en een percentage valse positieven van 0.22% gerapporteerd. Dit zijn door de leverancier gerapporteerde resultaten en geen onafhankelijke benchmark, en de README identificeert de dataset niet als WAF-Eval. Beschouw ze als vergelijkende productcijfers, niet als gegarandeerde productieprestaties.
• Strict. Een agressievere set regels met strengere heuristiek en de hierboven getoonde afweging tussen detectie en valse positieven. De moeite waard om te proberen na een week of twee van schone Balanced-werking, zodra je je verkeer begrijpt.

Aanbeveling: Balanced voor een verse implementatie zonder live verkeer dat verstoord kan worden. Begin bij een bestaande productieapplicatie een paar dagen met Monitor, let op valse positieven in het Attack Events-logboek en promoveer naar Balanced zodra je eventuele uitzonderingen hebt afgesteld. Strict is het proberen waard na een week of twee Balanced, zodra je je verkeer begrijpt.

Verifieer de WAF met een curl-SQLi-test

De laatste stap voordat je de installatie als voltooid beschouwt, is bevestigen dat de WAF daadwerkelijk een aanval onderschept. Voer een ongevaarlijke SQL-injectietest uit tegen je beschermde site vanaf een willekeurige machine buiten de VPS:

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

Dit is de door SafeLine gepubliceerde SQL-injectietestvector. Verwacht in de modus Balanced of Strict een 403-status en een SafeLine-blokkeerrespons. Verwacht in de Monitor-modus dat het verzoek wordt gelogd zonder te worden geblokkeerd. De HTTP-versie en de exacte responstekst kunnen variëren, dus bevestig het resultaat met een overeenkomend item bij Attack Events.

Open vervolgens het dashboard via de beperkte toegangsmethode uit Stap 4 en navigeer naar Logs, daarna Attack Events. Je zou een nieuw item moeten zien met de overeenkomende tijdstempel, aanvalstype SQL Injection, een bron-IP dat overeenkomt met de machine waarvandaan je curl uitvoerde, en de aanstootgevende querystring in de verzoekdetails. Klik op het item voor het volledige verzoek en de respons die SafeLine heeft vastgelegd.

Als het curl-verzoek 200 OK retourneerde, interpreteer het resultaat dan samen met het Attack Events-logboek:

• Een overeenkomend SQL Injection-item betekent dat de applicatie waarschijnlijk in de Monitor-modus staat; loggen zonder blokkeren is te verwachten.
• Als er geen overeenkomend item is, bevestig dan dat DNS naar de beoogde VPS resolvet, verifieer de SafeLine-listener en de upstreamconfiguratie, en correleer de verzoektijd met het toegangslogboek van SafeLine.
• Bevestig ook dat de bescherming is ingeschakeld en dat geen IP-whitelist, aangepaste toestaanregel of paduitzondering het testverzoek dekt.

Kernpunt: Als de curl-test 403 retourneert met de SafeLine-onderscheppingspagina en er een item verschijnt bij Attack Events met aanvalstype SQL Injection, dan onderschept de WAF het verkeer correct.

Wat de gratis laag dekt en waarvoor je een betaald abonnement nodig hebt

De gratis Personal-laag is genoeg om de meeste single-VPS-implementaties te beschermen. De betaalde lagen worden pas relevant wanneer je operationele functies nodig hebt (meldingen, logexport, geoblokkering) of de limiet van 10 applicaties overstijgt.

De uitsplitsing, afkomstig van de CyberServal-prijzenpagina:

• Personal, gratis. Tot 10 applicaties. Bevat de semantische detectie-engine (SQLi, XSS, command injection, path traversal, SSRF, XXE, CRLF), rate limiting, bot-CAPTCHA-uitdaging, dynamische HTML/JS-versleuteling tegen geautomatiseerde scrapers, web-ACL-regels en certificaatbeheer. Huidige CE-releases bevatten ook Free Cert-aanvraag en -verlenging.
• Lite, $10/maand of $100/jaar. Voegt geoblokkering, de threat-intelligence-IP-database, meldingsintegratie voor Discord en Telegram en export van aanvalslogboeken toe, en verhoogt de applicatielimiet naar 20.
• Pro, $100/maand of $1,000/jaar. Voegt krachtigere aanvalsdetectie, configuraties per service en globaal, aangepaste onderscheppingspagina's, upstream load balancing, master-slave-nodesynchronisatie en onbeperkte applicaties toe. Zie de huidige prijstabel voor wijzigingen.
• Ultimate, prijs op maat. Op maat gemaakte enterprisevoorwaarden met 1-op-1-ondersteuning via meerdere kanalen en ontwikkeling van functies op maat.

SafeLine verwerkt en bewaart applicatiegegevens binnen zijn lokale Compose-stack. Echter, de huidige CE-release notes vermelden Threat Intelligence Sharing, dus operators zouden de UEP-, privacy- en deelinstellingen van de geïnstalleerde versie moeten bekijken en de uitgaande verbindingen moeten observeren voordat ze de implementatie als zero-egress beschouwen.

Hoe nu verder

De installatie is voltooid en de WAF is geverifieerd. Een paar vervolgtaken helpen de implementatie gezond te houden.

• Stel voor elke productieapplicatie met uitgebreide gebruikersinvoer (een forum, een adminpaneel, een vrije API) de beschermingsmodus in op Beeldscherm gedurende drie tot zeven dagen, bekijk de pagina Attack Events dagelijks en promoveer naar Balanced zodra je eventuele valse positieven hebt afgesteld.
• Stel op de Lite-laag de meldingsintegratie voor Discord of Telegram in zodat aanvalsmeldingen je ook buiten het dashboard bereiken.
• Plan een maandelijks onderhoudsvenster. Maak vóór het upgraden een back-up van de gegevens en omgevingsconfiguratie van SafeLine, lees de huidige release notesen gebruik de ondersteunde upgradeprocedure voor je geïnstalleerde versie. Vertrouw niet uitsluitend op docker compose pull gevolgd door docker compose up -d, omdat de Compose-definitie of vereiste omgevingsvariabelen tussen releases kunnen veranderen. Cloudzy one-click-gebruikers zouden moeten werken vanuit /opt/safeline en de instructies van de marketplace-image moeten volgen.
• Abonneer je op de SafeLine-releasepagina voor meldingen over beveiligingspatches en op de projectrepository voor het volgen van issues.

Als je nog geen VPS hebt voor deze implementatie, is SafeLine beschikbaar als one-click-implementatie in Cloudzy's marketplace. Een abonnement met 4 GB RAM biedt de praktische speelruimte die in deze gids wordt aanbevolen; controleer opnieuw de huidige prijstabel op Cloudzy op het moment van publicatie, omdat plan-specificaties kunnen veranderen. De één-klik-image gebruikt /opt/safeline en /opt/safeline/docker-compose.yml, dus de architectuur- en dashboardinstructies zijn van toepassing, maar de /data/safeline commando's uit deze handleiding zijn niet identiek van toepassing.

Veelgestelde vragen

Vervangt SafeLine WAF Nginx Proxy Manager, of draai ik beide?

SafeLine kan Nginx Proxy Manager vervangen wanneer het als enige reverse proxy wordt ingezet. Het hoeft NPM echter niet te vervangen. Een veelvoorkomende opzet houdt NPM ervoor voor SSL en routering en plaatst SafeLine erachter als een toegewijde beveiligingslaag. Beide werken; de keuze hangt af van de vraag of je één tool beide taken wilt laten doen of twee tools die elk één taak goed doen.

Is de gratis laag genoeg voor één WordPress-site of kleine SaaS?

Ja, voor bescherming. De gratis Personal-laag bevat de semantische detectie-engine, rate limiting, bot-CAPTCHA-uitdaging en dynamische HTML/JS-versleuteling, die kernafweer vormen voor één site. De betaalde lagen voegen operationele functies toe zoals geoblokkering, export van aanvalslogboeken, externe meldingen, hogere applicatielimieten, krachtigere detectie en load balancing. Of een betaalde laag nodig is, hangt af van de vereiste functies en het aantal applicaties, niet van het verkeersvolume alleen.

Werkt SafeLine op een VPS met 1 GB RAM?

SafeLine's officiële minimum is 1 GB RAM. Dat kan genoeg zijn voor testen of een zeer lichte werklast, maar de productiecapaciteit hangt af van het verkeer, de ingeschakelde functies en de logbewaring. Voor een kleine productie-implementatie is 2 vCPU en 4 GB RAM een conservatief startpunt; monitor het geheugengebruik en schaal op basis van de gemeten belasting.

Waarom vereist ARM64 een betaalde licentie?

SafeLine's officiële implementatiedocumentatie vermeldt dat ARM-implementaties een Pro-licentie vereisen en dat de Personal Edition niet wordt ondersteund op ARM. Als je de Personal Edition wilt, kies dan een x86_64-VPS; als je ARM nodig hebt, houd dan rekening met een Pro-licentie.

Wat ontvangt Chaitin Tech van mijn SafeLine-instantie?

De precieze uitgaande gegevens kunnen per release en ingeschakelde functies verschillen. De huidige CE-release notes vermelden Threat Intelligence Sharing, terwijl de geïnstalleerde versie mogelijk ook UEP of andere deelinstellingen blootlegt. Bekijk die instellingen en de release notes voor je geïnstalleerde versie en valideer vervolgens de uitgaande verbindingen op netwerkniveau. De lokale containers van SafeLine verwerken applicatiegegevens, maar dat feit alleen bewijst niet dat het weigeren van UEP elk uitgaand verzoek stopt.