Sådan udruller du SafeLine WAF på en Linux VPS

Webapplikationer med internetadgang bliver rutinemæssigt afsøgt for SQL-injektion, misbrug af loginoplysninger og kendte sårbarhedsmønstre. SafeLine er en GPL-3.0 selvhostet WAF der kører som en Docker Compose-stak og filtrerer HTTP/S-trafik, før tilladte forespørgsler videresendes til origin. Dens gratis Personal-plan understøtter op til 10 applikationer.

Denne vejledning dækker installationen og tre områder, der kræver særlig opmærksomhed: beslutningen om reverse-proxy-arkitektur, Docker-netværkskonfigurationen når SafeLine sidder bag en eksisterende proxy som Nginx Proxy Manager, og en verifikationskommando, du kan køre efter installationen for at bekræfte, at WAF'en rent faktisk opfanger angreb.

Den korte version

• Installer SafeLine på en Linux VPS med Docker Compose. Brug én-linjes-installationsprogrammet, eller tag den manuelle Docker Compose-vej for at inspicere Compose-definitionen og miljøkonfigurationen, før du starter stakken.
• Beslut dig for reverse-proxy-arkitekturen, før du installerer: SafeLine som eneste proxy, SafeLine bag en eksisterende Nginx Proxy Manager, eller SafeLine der deler serveren med Caddy. Hver model kræver forskellige porttildelinger og X-Forwarded-For-indstillinger.
• Efter installationen verificerer du WAF'en ved at sende en curl SQL-injektionstest mod den beskyttede URL. I Balanced- eller Strict-tilstand bekræfter et 403-svar plus en matchende post i Attack Events, at blokering finder sted. I Monitor-tilstand bekræfter den matchende hændelse registreringen, selvom svaret kan forblive vellykket.
• Det gratis Personal-niveau dækker op til 10 applikationer og den centrale registreringsmotor. Geo-blokering, eksport af angrebslog og eksterne notifikationer kræver Lite-niveauet; kraftigere angrebsdetektion og belastningsfordeling kræver Pro.

Før du går i gang: Forudsætninger og hvad denne vejledning dækker

Denne vejledning antager, at du har en Linux VPS, du kan tilgå via SSH med root- eller sudo-adgang, og at Docker er installeret. Du ender med en fungerende SafeLine-instans, der beskytter mindst ét websted, og en verifikationskommando, du kan køre igen når som helst.

Du skal bruge:

• En Linux VPS. Kommandoerne nedenfor antager et Debian- eller Ubuntu-lignende system med systemd; verificer pakke- og tjenestenavne på andre distributioner.
• Mindst 1 vCPU, 1 GB RAM og 5 GB disk ifølge de officielle udrulningskrav. For praktisk produktionsmargin anbefaler denne guide 2 vCPU, 4 GB RAM og 20 GB disk.
• Docker 20.10.14 eller nyere og Docker Compose 2.0 eller nyere.
• En x86_64 CPU med SSSE3-understøttelse; verificer det med lscpu | grep ssse3 i stedet for at antage, at instruktionen er til stede.
• Et domæne eller subdomæne med DNS, der peger på VPS'ens offentlige IP, hvis du planlægger at eksponere den beskyttede applikation over offentlig HTTPS.
• Porte, der passer til den valgte topologi. Model A og C giver normalt SafeLine port 80 og 443, mens model B lader disse porte tilhøre Nginx Proxy Manager og tildeler SafeLine en anden lytter som f.eks. 10080.
• Root- eller sudo-adgang.

I VPS-udbyderens firewall eller sikkerhedsgruppe skal du kun eksponere de offentlige porte, den valgte topologi kræver. Begræns SSH og TCP 9443 til betroede administrationskilder. I model B skal du holde TCP 10080 lukket for offentlig IPv4 og IPv6 og holde backend-porte som f.eks. 8080 private i enhver topologi. Direkte adgang til 10080 ville omgå NPM og ugyldiggøre X-Forwarded-For-tillidsgrænsen.

Bemærk: For manuel ARM64-udrulning skal du sætte ARCH_SUFFIX=-arm. SafeLines officielle udrulningsdokumentation angiver, at ARM kræver en Pro-licens, og at Personal Edition ikke understøttes på ARM. Brug en x86_64 VPS til Personal Edition.

Verificer Docker, før du starter:

docker --version
docker compose version

Begge kommandoer bør returnere installerede versioner. Fortsæt kun, hvis Docker er version 20.10.14 eller nyere, og Docker Compose er version 2.0.0 eller nyere; ellers skal du opgradere, før du installerer SafeLine.

Vælg din reverse-proxy-arkitektur først

En ny VPS lader SafeLine eje port 80 og 443 fuldt ud. En VPS, der allerede kører Nginx Proxy Manager, Caddy eller applikationens egen Nginx, gør ikke, og arkitekturbeslutningen er forskellen mellem en gnidningsfri installation og en portkonflikt ved første opstart. Få dette rigtigt fra starten, og resten af udrulningen er mekanisk.

De tre modeller:

• Model A, SafeLine som eneste reverse proxy. SafeLine ejer port 80 og 443 og håndterer TLS for den beskyttede applikation. Aktuelle CE-udgivelser inkluderer et Free Cert-arbejdsforløb, mens manuel certifikatoverførsel fortsat er tilgængelig; verificer de præcise certifikatmuligheder i den installerede udgivelse. Backend'en kører på en ikke-offentlig port, og SafeLine ruter til den.
• Model B, SafeLine bag Nginx Proxy Manager (NPM). NPM beholder port 80 og 443 og håndterer SSL. SafeLine lytter på port 10080 (kun HTTP, da NPM allerede har termineret TLS). NPM videresender til SafeLine; SafeLine videresender til backend'en. Dette er en almindelig opsætning, når NPM allerede er udrullet.
• Model C, SafeLine sammen med Caddy. Caddys automatiske HTTPS konkurrerer med SafeLine om port 443. En brugbar løsning giver SafeLine port 80 og 443 og flytter Caddy til en ikke-offentlig intern HTTP-port som f.eks. 8080 til springet fra SafeLine til Caddy til applikationen.

Vigtigste pointe: Model A er enklest for en ny VPS; model B er det rette valg, når NPM allerede kører; model C kræver en bevidst omfordeling af Caddys port.

Installer SafeLine på din VPS

Selve installationen er den nemme del. SafeLine leveres med to installationsveje: et automatiseret installationsprogram, der henter et fjernscript fra waf.chaitin.com, og en manuel Docker Compose-vej, der lader dig inspicere alt, før det kører. Vælg den, der passer til din sikkerhedspolitik.

Trin 1: Bekræft, at Docker er klar

Kontroller Docker-versionen igen, og at Docker-dæmonen kører:

docker --version
docker compose version
sudo systemctl status docker

Det forventede output inkluderer active (running) for Docker-dæmonen. Hvis den ikke kører, starter du den med sudo systemctl start docker og aktiverer den ved opstart med sudo systemctl enable docker.

Trin 2: Kør SafeLine-installationsprogrammet

Der er to underveje. Vælg én.

Trin 2a, automatiseret installation. Kør installationsprogrammet med root-rettigheder:

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

Scriptet spørger, hvor SafeLine-datamappen skal placeres, henter Docker-imagene og starter stakken. Efter installationen kører du sudo docker exec safeline-mgt resetadmin for at hente eller nulstille administrator-loginoplysningerne, som beskrevet i den officielle udrulningsguide. Opbevar de resulterende loginoplysninger sikkert.

Bemærk: Denne kommando downloader og udfører et fjern-shellscript fra waf.chaitin.com som root. Den officielle one-liner inkluderer curl -k, som deaktiverer verifikation af TLS-certifikater. Gennemgå det downloadede script før udførelse, eller brug trin 2b, hvis den risiko er uacceptabel. SafeLine er også tilgængelig som en ét-kliks Cloudzy-udrulning, men det image bruger /opt/safeline, /opt/safeline/.env, og /opt/safeline/docker-compose.yml. Brug ikke denne guides /data/safeline -stier uændret på Cloudzy-imaget.

Trin 2b, manuel Docker Compose-installation. Download og inspicer den officielle Compose-fil, og start derefter stakken:

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

Efter docker compose up -d er fuldført, viser du de kørende containere for at bekræfte:

sudo docker compose ps

Du bør se containere for safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi og safeline-chaos. Hvis en container viser Exited, så se trin 3 for de to mest almindelige årsager.

Trin 3: Løs almindelige installationsfejl

To fejl opstår ofte nok til, at de fortjener deres eget trin.

Subnet-overlap. Hvis installationen fejler med Pool overlaps with other one on this address space, er SafeLines standard-subnet i konflikt med et eksisterende Docker-netværk. Som dokumenteret i en SafeLine-fejlfindingsgennemgang til installation, kan du løse dette ved at redigere /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-fejl. Hvis safeline-tengine går ned med nginx: [emerg] invalid IPv6 address in resolver, skal du først inspicere resolver-filen og fastslå, hvem der administrerer den:

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

Rediger ikke /etc/resolv.conf direkte, hvis den genereres af systemd-resolved, NetworkManager eller VPS-udbyderen. Ret den fejlformaterede nameserver-værdi i den administrerende tjenestes konfiguration, regenerer resolver-filen, og genstart derefter Tengine:

sudo docker restart safeline-tengine

Trin 4: Tilgå dashboardet

SafeLines administrationsdashboard lytter på TCP 9443 over HTTPS. Lad ikke denne administrative port stå åben for hele internettet. Begræns den til en betroet kildeadresse eller VPN, eller blokér offentlig adgang og brug en SSH-tunnel:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Åbn https://localhost:9443 gennem tunnelen. En advarsel om selvsigneret certifikat er forventet ved første adgang; verificer, at SSH-forbindelsen nåede den tilsigtede server, før du fortsætter.

Hvis du har mistet de oprindelige loginoplysninger, kan du nulstille admin-adgangskoden fra værten:

sudo docker exec safeline-mgt resetadmin

Kommandoen udskriver administrator-loginoplysninger, du kan bruge til at logge ind igen.

Konfigurer SafeLine til din arkitektur

SafeLine kører nu, men den beskytter endnu ikke noget. Dashboardets Applications-side er, hvor du fortæller SafeLine, hvilke websteder der skal beskyttes, og hvor renset trafik skal videresendes. Konfigurationen varierer afhængigt af den arkitektur, du valgte tidligere, så hver model får sin egen underafdeling. Gennemgå kun den, der matcher din opsætning.

Model A: SafeLine som eneste reverse proxy

For model A lytter SafeLine direkte på port 80 og 443 og videresender renset trafik til din backend-applikation på en ikke-offentlig port. I dashboardet:

1. Gå til Applications, derefter Add Application.
2. Sæt lytteporten til 443 og aktiver SSL. Brug det certifikatarbejdsforløb, der er tilgængeligt i din installerede SafeLine-udgivelse. Aktuelle CE-udgivelser inkluderer Free Cert-ansøgning og fornyelseshåndtering, mens manuel certifikatoverførsel fortsat er tilgængelig.
3. Sæt upstream til http://127.0.0.1:8080. Hvis backend'en kører i Docker, skal du kun publicere dens port på loopback, for eksempel "127.0.0.1:8080:8080" i tjenestens ports-sektion. Undgå en hårdkodet container-IP som f.eks. 172.17.0.5 fordi den kan ændre sig, når containeren genskabes.
4. Gem applikationen. SafeLine begynder straks at lytte på 443 og videresende renset trafik til backend'en.
5. Bekræft, at dit domænes DNS A-record peger på VPS'ens offentlige IP, og at port 80 og 443 er tilgængelige udefra.

Hvis port 443 allerede var bundet af en anden proces, vil SafeLines container ikke kunne binde, og dashboardet vil vise en fejl på den applikation. Stop den konfliktende proces, eller vælg en anden port, før du tilføjer applikationen.

Model B: SafeLine bag Nginx Proxy Manager

Model B lader NPM fortsætte med det, den allerede gør (eje 80 og 443, håndtere Let's Encrypt) og indsætter SafeLine som et dedikeret sikkerhedslag bag den. Trafikforløbet er: klient, derefter NPM (port 443, TLS-terminering), derefter SafeLine (port 10080, HTTP), derefter backend-applikationen.

Inde i SafeLine-dashboardet:

1. Applications, derefter Add Application. Sæt lytteporten til 10080, og lad SSL være slået fra (NPM har allerede termineret TLS).
2. Sæt upstream til applikationens interne adresse, som beskrevet i model A.
3. Gem applikationen.

I Nginx Proxy Manager:

1. Hosts, derefter Proxy Hosts, derefter Add Proxy Host.
2. Details-fanen: angiv domænenavnet, skema http, og videresend til port 10080. Hvis NPM kører direkte på værten, skal du bruge 127.0.0.1 som forward-værtsnavn. Hvis NPM kører i Docker på Linux, 127.0.0.1 peger på NPM-containeren i stedet for VPS-værten. Tilføj Dockers host-gateway-mapping til NPM Compose-tjenesten, og brug derefter host.docker.internal som forward-værtsnavn:

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

Fra NPM Compose-mappen kører du sudo docker compose up -d så containeren genskabes med den nye host-mapping.

3. SSL-fanen: anmod om et Let's Encrypt-certifikat, gennemtving SSL, og aktiver HTTP/2.
4. Lad NPM's Advanced-fane være tom for X-Forwarded-For. I den aktuelle NPM-skabelonindsættes Advanced-indhold på server-niveau og tilsidesætter ikke de genererede location-niveau-headers under NGINX's arveregler. Den genererede location sender:

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

Det andet direktiv tilføjer den adresse, NPM observerer, som den yderste højre værdi i headeren.

5. Gem Proxy Host'en.

Tilbage i SafeLine skal du kun konfigurere udtræk af kilde-IP, efter du har bekræftet den effektive header-kæde. SafeLine 9.3.1 introducerede fleksibelt XFF-udtræk med valg af retning og indeks.

1. Settings, derefter Advanced, derefter Real IP from Header. Sæt headernavnet til X-Forwarded-For.
2. Brug brugerdefineret udtræk fra slutningen af headeren, og vælg den yderste højre adresse, der er tilføjet af NPM. Nøjagtige indeksetiketter varierer efter version, så verificer resultatet i Logs, derefter Access. Hvis den installerede udgivelse er ældre end 9.3.1, skal du opdatere den, før du følger denne topologi.
3. Hvis Cloudflare eller et andet CDN sidder foran NPM, skal du først konfigurere NPM til kun at stole på den udbyders publicerede proxy-intervaller, så den adresse, NPM tilføjer, er troværdig. Vælg ikke en fast position, før du har inspiceret og testet den faktiske header-kæde.
4. Gem og genindlæs applikationen.

Test konfigurationen fra en maskine uden for VPS'en:

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

SafeLine-adgangsloggen bør vise din rigtige offentlige adresse, ikke 1.2.3.4 eller NPM's bro-adresse.

Forhindr brugere i at omgå SafeLine ved at holde backend-lytteren privat. For en Docker Compose-backend skal du kun publicere porten på loopback:

ports:
  - "127.0.0.1:8080:8080"

For en tjeneste, der kører direkte på værten, skal du konfigurere den til at lytte på 127.0.0.1:8080 i stedet for 0.0.0.0:8080. Verificer begge interne porte fra en maskine uden for VPS'en:

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

TCP-forbindelserne bør blive afvist eller timeoute. En HTTP-fejl eller "Empty reply from server" betyder stadig, at porten er offentligt tilgængelig og skal sikres. Hvis loopback-binding er umulig, skal du oprette firewall-regler skræddersyet til den faktiske grænseflade, Docker-netværk og destinationscontainer i stedet for at anvende en generisk DOCKER-USER-regel.

Model C: SafeLine med Caddy

For model C tager SafeLine port 80 og 443; Caddy flyttes til en ikke-offentlig intern HTTP-port. Trafikforløbet er: klient, derefter SafeLine (443, TLS), derefter Caddy (8080, intern HTTP), derefter applikationens backend.

Rediger /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

Den :8080 site-blokken er den vigtige del: Caddy lytter nu på en intern HTTP-port i stedet for at konkurrere med SafeLine om 443. Linjen bind 127.0.0.1 holder den lytter lokal på VPS'en. Genindlæs Caddy med sudo systemctl reload caddy og bekræft med sudo ss -ltnp | grep -E ':(443|8080)' at Caddy er bundet til 8080, ikke 443.

I SafeLine tilføjer du en applikation, der lytter på 443 med SSL aktiveret, og sætter derefter upstream til http://127.0.0.1:8080. X-Forwarded-For-indstillingen kan forblive på standardindstillingen for netværksforbindelse, fordi Caddy er bag SafeLine, ikke foran den.

Vælg en beskyttelsestilstand og verificer, at WAF'en blokerer angreb

SafeLine har tre beskyttelsestilstande, der afgør, hvad der sker, når motoren markerer en forespørgsel som ondsindet. Den rette starttilstand afhænger af applikationen; verifikationstrinnet er det samme i enhver tilstand.

Beskyttelsestilstande: Monitor, Balanced, Strict

Hver applikation i SafeLine har sin egen indstilling for beskyttelsestilstand, som kan konfigureres under Applications, derefter din app, derefter Protection Mode:

• Monitor. SafeLine logger forespørgsler, den ellers ville blokere, men blokerer dem ikke. Dette er det sikreste udgangspunkt for en kompleks produktionsapplikation med rige indtastningsformularer (et forum, et administrationspanel med WYSIWYG-felter, en API der accepterer JSON-payloads i fri form). Kør Monitor i nogle dage, gennemgå Attack Events-siden, og bekræft, at der ikke er nogen falske positiver mod rigtige brugere, før du opgraderer til Balanced.
• Balanced. Standardtilstanden. SafeLines leverandørpublicerede GitHub-tal rapporterer 71.65% detektion, 99.45% nøjagtighed og en falsk-positiv-rate på 0.07% for Balanced-tilstand. Strict-tilstand rapporteres til 76.17% detektion, 99.38% nøjagtighed og en falsk-positiv-rate på 0.22%. Dette er leverandørrapporterede resultater snarere end et uafhængigt benchmark, og README'en identificerer ikke datasættet som WAF-Eval. Betragt dem som sammenlignende produkttal, ikke garanteret produktionsydelse.
• Strict. Et mere aggressivt regelsæt med strengere heuristik og den detektion-versus-falsk-positiv-afvejning, der er vist ovenfor. Værd at prøve efter en uge eller to med ren Balanced-drift, når du forstår din trafik.

Anbefaling: Balanced til en ny udrulning uden live-trafik at forstyrre. Til en eksisterende produktionsapplikation starter du i Monitor i nogle dage, leder efter falske positiver i Attack Events-loggen og opgraderer til Balanced, når du har finjusteret eventuelle undtagelser. Strict er værd at prøve efter en uge eller to med Balanced, når du forstår din trafik.

Verificer WAF'en med en curl SQLi-test

Det sidste trin, før installationen kan betragtes som færdig, er at bekræfte, at WAF'en rent faktisk opfanger et angreb. Kør en harmløs SQL-injektionstest mod dit beskyttede websted fra en hvilken som helst maskine uden for VPS'en:

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

Dette er SafeLines publicerede SQL-injektionstestvektor. I Balanced- eller Strict-tilstand forvent en 403-status og et SafeLine-blokeringssvar. I Monitor-tilstand forvent, at forespørgslen logges uden blokering. HTTP-versionen og den nøjagtige svartekst kan variere, så bekræft resultatet med en matchende post i Attack Events.

Åbn derefter dashboardet via den begrænsede adgangsmetode fra trin 4 og naviger til Logs, derefter Attack Events. Du bør se en ny post med det matchende tidsstempel, angrebstypen SQL Injection, kilde-IP der matcher den maskine, du kørte curl fra, og den fejlagtige forespørgselsstreng i forespørgselsdetaljen. Klik ind på hændelsen for at se hele forespørgslen og svaret, som SafeLine har opfanget.

Hvis curl-forespørgslen returnerede 200 OK, skal du fortolke resultatet sammen med Attack Events-loggen:

• En matchende SQL Injection-hændelse betyder, at applikationen sandsynligvis er i Monitor-tilstand; logning uden blokering er forventet.
• Hvis der ikke er nogen matchende hændelse, skal du bekræfte, at DNS resolver til den tilsigtede VPS, verificere SafeLine-lytteren og upstream-konfigurationen og korrelere forespørgselstidspunktet med SafeLines adgangslog.
• Bekræft også, at beskyttelse er aktiveret, og at ingen IP-whitelist, brugerdefineret tilladelsesregel eller sti-undtagelse dækker testforespørgslen.

Vigtigste pointe: Hvis curl-testen returnerer 403 med SafeLine-opfangningssiden, og en post vises i Attack Events med angrebstypen SQL Injection, opfanger WAF'en trafikken korrekt.

Hvad det gratis niveau dækker, og hvad der kræver en betalt plan

Det gratis Personal-niveau er nok til at beskytte de fleste enkelt-VPS-udrulninger. De betalte niveauer begynder at have betydning, når du har brug for driftsfunktioner (notifikationer, logeksport, geo-blokering) eller vokser ud over grænsen på 10 applikationer.

Opdelingen, hentet fra CyberServals prisside:

• Personal, gratis. Op til 10 applikationer. Inkluderer den semantiske registreringsmotor (SQLi, XSS, kommandoinjektion, path traversal, SSRF, XXE, CRLF), rate limiting, bot-CAPTCHA-udfordring, dynamisk HTML/JS-kryptering mod automatiserede scrapere, web-ACL-regler og certifikathåndtering. Aktuelle CE-udgivelser inkluderer også Free Cert-ansøgning og fornyelseshåndtering.
• Lite, $10/måned eller $100/år. Tilføjer geo-blokering, IP-databasen for trusselsefterretning, notifikationsintegration med Discord og Telegram, eksport af angrebslog og hæver applikationsgrænsen til 20.
• Pro, $100/måned eller $1,000/år. Tilføjer kraftigere angrebsdetektion, konfigurationer pr. tjeneste og globalt, brugerdefinerede opfangningssider, upstream-belastningsfordeling, master-slave-node-synkronisering og ubegrænsede applikationer. Se den aktuelle pristabel for ændringer.
• Ultimate, tilpasset prissætning. Skræddersyede enterprise-vilkår med 1-til-1-support på tværs af kanaler og udvikling af tilpassede funktioner.

SafeLine behandler og gemmer applikationsdata inden for sin lokale Compose-stak. Dog de aktuelle CE-udgivelsesnoter nævner Threat Intelligence Sharing, så operatører bør gennemgå den installerede versions UEP-, privatlivs- og delingskontroller og observere udgående forbindelser, før de behandler udrulningen som zero-egress.

Hvad du gør herfra

Installationen er fuldført, og WAF'en er verificeret. Nogle få opfølgningsopgaver vil hjælpe med at holde udrulningen sund.

• For enhver produktionsapplikation med rig brugerinput (et forum, et administrationspanel, en API i fri form) skal du sætte beskyttelsestilstanden til Skærm i tre til syv dage, gennemgå Attack Events-siden dagligt, og opgrader til Balanced, når du har finjusteret eventuelle falske positiver.
• På Lite-niveauet skal du opsætte notifikationsintegrationen med Discord eller Telegram, så angrebsadvarsler når dig uden for dashboardet.
• Planlæg et månedligt vedligeholdelsesvindue. Før du opgraderer, skal du sikkerhedskopiere SafeLines data og miljøkonfiguration, læse de aktuelle udgivelsesnoter, og bruge den understøttede opgraderingsprocedure for din installerede version. Stol ikke kun på docker compose pull efterfulgt af docker compose up -d, fordi Compose-definitionen eller de påkrævede miljøvariabler kan ændre sig mellem udgivelser. Cloudzy ét-kliks-brugere bør arbejde ud fra /opt/safeline og følge marketplace-imagets instruktioner.
• Abonnér på SafeLine-udgivelsessiden for notifikationer om sikkerhedsrettelser og på projektets repository for problemsporing.

Hvis du endnu ikke har en VPS til denne udrulning, er SafeLine tilgængelig som en ét-kliks-udrulning i Cloudzy's marketplace. En plan med 4 GB RAM giver den praktiske plads, der anbefales i denne guide; tjek igen den aktuelle pristabel på Cloudzy ved udgivelsen, fordi planspecifikationer kan ændre sig. One-click-imaget bruger /opt/safeline og /opt/safeline/docker-compose.yml, så arkitektur- og dashboardinstruktionerne gælder, men denne guides /data/safeline kommandoer gælder ikke identisk.

Ofte stillede spørgsmål

Erstatter SafeLine WAF Nginx Proxy Manager, eller kører jeg begge?

SafeLine kan erstatte Nginx Proxy Manager, når den udrulles som eneste reverse proxy. Den behøver dog ikke at erstatte NPM. En almindelig opsætning holder NPM foran til SSL og routing og lægger SafeLine bag den som et dedikeret sikkerhedslag. Begge virker; valget afhænger af, om du vil have ét værktøj, der udfører begge opgaver, eller to værktøjer, der hver udfører én opgave godt.

Er det gratis niveau nok til et enkelt WordPress-websted eller en lille SaaS?

Ja, hvad angår beskyttelse. Det gratis Personal-niveau inkluderer den semantiske registreringsmotor, rate limiting, bot-CAPTCHA-udfordring og dynamisk HTML/JS-kryptering, som er kerneforsvar for et enkelt websted. De betalte niveauer tilføjer driftsfunktioner som geo-blokering, eksport af angrebslog, eksterne notifikationer, højere applikationsgrænser, kraftigere detektion og belastningsfordeling. Om et betalt niveau er nødvendigt, afhænger af de påkrævede funktioner og antallet af applikationer, ikke trafikmængden alene.

Virker SafeLine på en VPS med 1 GB RAM?

SafeLines officielle minimum er 1 GB RAM. Det kan være nok til test eller en meget let arbejdsbelastning, men produktionskapacitet afhænger af trafik, aktiverede funktioner og logopbevaring. Til en lille produktionsudrulning er 2 vCPU og 4 GB RAM et konservativt udgangspunkt; overvåg hukommelsesforbruget og skaler ud fra målt belastning.

Hvorfor kræver ARM64 en betalt licens?

SafeLines officielle udrulningsdokumentation angiver, at ARM-udrulninger kræver en Pro-licens, og at Personal Edition ikke understøttes på ARM. Hvis du vil have Personal Edition, skal du vælge en x86_64 VPS; hvis du har brug for ARM, skal du planlægge en Pro-licens.

Hvad modtager Chaitin Tech fra min SafeLine-instans?

De nøjagtige udgående data kan variere efter udgivelse og aktiverede funktioner. Aktuelle CE-udgivelsesnoter nævner Threat Intelligence Sharing, mens den installerede version også kan eksponere UEP eller andre delingskontroller. Gennemgå disse indstillinger og udgivelsesnoterne for din installerede version, og valider derefter egress på netværksniveau. SafeLines lokale containere håndterer applikationsdata, men den kendsgerning alene beviser ikke, at det stopper enhver udgående forespørgsel at afvise UEP.