Hogyan telepítsd a SafeLine WAF-ot egy Linux VPS-re

Az internetről elérhető webalkalmazásokat rendszeresen tesztelik SQL injection, hitelesítőadat-visszaélés és ismert sebezhetőségi minták után kutatva. A SafeLine egy GPL-3.0 licencű, saját üzemeltetésű WAF , amely Docker Compose stackként fut, és szűri a HTTP/S forgalmat, mielőtt az engedélyezett kéréseket továbbítaná az eredeti kiszolgálóhoz. Az ingyenes Personal csomag legfeljebb 10 alkalmazást támogat.

Ez az útmutató a telepítést és három, különös figyelmet igénylő területet tárgyal: a reverse proxy architektúrával kapcsolatos döntést, a Docker hálózat beállítását, amikor a SafeLine egy meglévő proxy, például az Nginx Proxy Manager mögött helyezkedik el, valamint egy ellenőrző parancsot, amelyet a telepítés után futtatva megerősítheted, hogy a WAF valóban elfogja a támadásokat.

A rövid verzió

• Telepítsd a SafeLine-t egy Linux VPS-re Docker Compose segítségével. Használd az egysoros telepítőt, vagy válaszd a manuális Docker Compose utat, hogy a stack indítása előtt átnézhesd a Compose definíciót és a környezeti konfigurációt.
• A telepítés előtt döntsd el a reverse proxy architektúrát: a SafeLine az egyetlen proxy, a SafeLine egy meglévő Nginx Proxy Manager mögött, vagy a SafeLine a Caddyvel osztozik ugyanazon a gépen. Mindegyik változat eltérő portkiosztást és X-Forwarded-For beállításokat igényel.
• A telepítés után ellenőrizd a WAF-ot úgy, hogy egy curl SQL injection próbát küldesz a védett URL-re. Balanced vagy Strict módban egy 403-as válasz és egy hozzá tartozó Attack Events bejegyzés megerősíti a blokkolást. Monitor módban az egyező esemény akkor is megerősíti az észlelést, ha a válasz sikeres marad.
• Az ingyenes Personal szint legfeljebb 10 alkalmazást és az alap észlelő motort fedi le. A geoblokkoláshoz, a támadási naplók exportálásához és a külső értesítésekhez a Lite szint szükséges; az erősebb támadásészleléshez és a terheléselosztáshoz pedig a Pro.

Mielőtt belekezdesz: előfeltételek és az útmutató tartalma

Ez az útmutató feltételezi, hogy van egy Linux VPS-ed, amelyre SSH-n keresztül root vagy sudo hozzáféréssel be tudsz jelentkezni, és hogy a Docker telepítve van. A végére egy működő SafeLine példányod lesz, amely legalább egy webhelyet véd, valamint egy ellenőrző parancsod, amelyet bármikor újra lefuttathatsz.

Amire szükséged van:

• Egy Linux VPS. Az alábbi parancsok egy systemd-t használó, Debian vagy Ubuntu jellegű rendszert feltételeznek; más disztribúciókon ellenőrizd a csomag- és szolgáltatásneveket.
• Legalább 1 vCPU, 1 GB RAM és 5 GB lemez a hivatalos telepítési követelmények szerint. A gyakorlati éles üzemi tartalék érdekében ez az útmutató 2 vCPU-t, 4 GB RAM-ot és 20 GB lemezt javasol.
• Docker 20.10.14 vagy újabb, valamint Docker Compose 2.0 vagy újabb.
• Egy x86_64 CPU SSSE3 támogatással; ezt ellenőrizd a következővel: lscpu | grep ssse3 ahelyett, hogy feltételeznéd, hogy az utasítás elérhető.
• Egy domain vagy aldomain, amelynek DNS-e a VPS nyilvános IP-jére mutat, ha a védett alkalmazást nyilvános HTTPS-en keresztül tervezed elérhetővé tenni.
• A választott topológiának megfelelő portok. Az A és C változat általában a 80-as és 443-as portokat adja a SafeLine-nak, míg a B változat ezeket a portokat az Nginx Proxy Managernél hagyja, és a SafeLine-nak egy másik figyelőt, például a 10080-ast rendeli.
• Root vagy sudo hozzáférés.

A VPS-szolgáltató tűzfalánál vagy biztonsági csoportjánál csak azokat a nyilvános portokat tedd elérhetővé, amelyekre a választott topológiának szüksége van. Korlátozd az SSH-t és a TCP 9443-at megbízható adminisztrációs forrásokra. A B változatban tartsd zárva a TCP 10080-at a nyilvános IPv4 és IPv6 felé, és minden topológiában tartsd priváton a backend portokat, például a 8080-at. A 10080 közvetlen elérése megkerülné az NPM-et, és érvénytelenné tenné az X-Forwarded-For megbízhatósági határt.

Megjegyzés: Manuális ARM64 telepítéshez állítsd be a következőt: ARCH_SUFFIX=-arm. A SafeLine hivatalos telepítési dokumentációja kimondja, hogy az ARM Pro licencet igényel, és hogy a Personal Edition nem támogatott ARM-on. A Personal Editionhöz használj x86_64 VPS-t.

Indítás előtt ellenőrizd a Dockert:

docker --version
docker compose version

Mindkét parancsnak a telepített verziókat kell visszaadnia. Csak akkor folytasd, ha a Docker verziója 20.10.14 vagy újabb, a Docker Compose verziója pedig 2.0.0 vagy újabb; ellenkező esetben a SafeLine telepítése előtt frissíts.

Először válaszd ki a reverse proxy architektúrát

Egy friss VPS-en a SafeLine teljesen birtokolhatja a 80-as és 443-as portokat. Egy olyan VPS, amelyen már fut az Nginx Proxy Manager, a Caddy vagy az alkalmazás saját Nginxe, ezt nem teszi lehetővé, és az architektúrával kapcsolatos döntés dönti el, hogy a telepítés zökkenőmentes lesz, vagy az első indításnál portütközésbe futsz. Ha ezt az elején egyszer jól megcsinálod, a telepítés többi része már gépies.

A három változat:

• A változat: a SafeLine az egyetlen reverse proxy. A SafeLine birtokolja a 80-as és 443-as portokat, és kezeli a védett alkalmazás TLS-ét. A jelenlegi CE kiadások tartalmaznak egy Free Cert munkafolyamatot, miközben a manuális tanúsítványfeltöltés továbbra is elérhető; a pontos tanúsítványbeállításokat ellenőrizd a telepített kiadásban. A backend egy nem nyilvános porton fut, és a SafeLine oda irányítja a forgalmat.
• B változat: a SafeLine az Nginx Proxy Manager (NPM) mögött. Az NPM megtartja a 80-as és 443-as portokat, és kezeli az SSL-t. A SafeLine a 10080-as porton figyel (csak HTTP, mivel az NPM már lezárta a TLS-t). Az NPM a SafeLine-ba, a SafeLine pedig a backendbe továbbít. Ez gyakori elrendezés, amikor az NPM már telepítve van.
• C változat: a SafeLine a Caddy mellett. A Caddy automatikus HTTPS-e versenyez a SafeLine-nal a 443-as portért. Egy működőképes elrendezésben a SafeLine kapja a 80-as és 443-as portokat, a Caddy pedig egy nem nyilvános, belső HTTP portra, például a 8080-asra kerül a SafeLine–Caddy–alkalmazás útvonalhoz.

Fő tanulság: Az A változat a legegyszerűbb egy friss VPS-hez; a B változat a helyes választás, amikor az NPM már fut; a C változat a Caddy portjának szándékos újrakiosztását igényli.

Telepítsd a SafeLine-t a VPS-edre

Maga a telepítés a könnyebbik rész. A SafeLine két telepítési utat kínál: egy automatizált telepítőt, amely egy távoli szkriptet tölt le a waf.chaitin.com-ról, és egy manuális Docker Compose utat, amely lehetővé teszi, hogy futtatás előtt mindent átnézz. Válaszd azt, amelyik megfelel a biztonsági irányelveidnek.

1. lépés: Győződj meg róla, hogy a Docker készen áll

Ellenőrizd újra a Docker verzióját, és hogy a Docker démon fut-e:

docker --version
docker compose version
sudo systemctl status docker

A várt kimenet tartalmazza a következőt: active (running) a Docker démonhoz. Ha nem fut, indítsd el a következővel: sudo systemctl start docker és engedélyezd az indításkori futtatását a következővel: sudo systemctl enable docker.

2. lépés: Futtasd a SafeLine telepítőt

Két alútvonal van. Válassz egyet.

2a. lépés: automatizált telepítés. Futtasd a telepítőt root jogosultsággal:

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

A szkript megkérdezi, hova helyezze a SafeLine adatkönyvtárát, letölti a Docker image-eket, és elindítja a stacket. A telepítés után futtasd a következőt: sudo docker exec safeline-mgt resetadmin az adminisztrátori hitelesítő adatok lekéréséhez vagy visszaállításához, ahogy azt a hivatalos telepítési útmutató leírja. A kapott hitelesítő adatokat tárold biztonságosan.

Megjegyzés: Ez a parancs egy távoli shell szkriptet tölt le és futtat root jogosultsággal a waf.chaitin.com-ról. A hivatalos egysoros tartalmazza a következőt: curl -k, amely letiltja a TLS tanúsítvány-ellenőrzést. Futtatás előtt nézd át a letöltött szkriptet, vagy használd a 2b. lépést, ha ez a kockázat elfogadhatatlan. A SafeLine egykattintásos Cloudzy telepítésként is elérhető, de az az image a következőt használja: /opt/safeline, /opt/safeline/.env, és /opt/safeline/docker-compose.yml. Ne használd ennek az útmutatónak a /data/safeline útvonalait változatlanul a Cloudzy image-en.

2b. lépés: manuális Docker Compose telepítés. Töltsd le és vizsgáld át a hivatalos Compose fájlt, majd indítsd el a stacket:

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

után docker compose up -d befejeződik, listázd a futó konténereket a megerősítéshez:

sudo docker compose ps

A következő konténereket kell látnod: safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi és safeline-chaos. Ha bármelyik konténer a következő állapotot mutatja: Exited, nézd meg a 3. lépést a két leggyakoribb okért.

3. lépés: Gyakori telepítési hibák megoldása

Két hiba elég gyakran előfordul ahhoz, hogy megérdemeljen egy saját lépést.

Alhálózat-átfedés. Ha a telepítés a következő hibával áll le: Pool overlaps with other one on this address space, akkor a SafeLine alapértelmezett alhálózata ütközik egy meglévő Docker hálózattal. Ahogy azt egy SafeLine telepítési hibaelhárítási útmutató dokumentálja, ezt a következő szerkesztésével javítsd: /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 feloldó hiba. Ha a safeline-tengine a következő hibával összeomlik: nginx: [emerg] invalid IPv6 address in resolver, először vizsgáld meg a feloldó fájlt, és állapítsd meg, ki kezeli:

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

Ne szerkeszd a következőt: /etc/resolv.conf közvetlenül, ha azt a systemd-resolved, a NetworkManager vagy a VPS-szolgáltató generálja. Javítsd a hibás nameserver értéket a kezelő szolgáltatás konfigurációjában, generáld újra a feloldó fájlt, majd indítsd újra a Tengine-t:

sudo docker restart safeline-tengine

4. lépés: A vezérlőpult elérése

A SafeLine felügyeleti vezérlőpultja a TCP 9443-as porton figyel HTTPS-en keresztül. Ne hagyd ezt az adminisztratív portot nyitva az egész internet felé. Korlátozd egy megbízható forráscímre vagy VPN-re, vagy tiltsd le a nyilvános hozzáférést, és használj SSH-alagutat:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Nyitás https://localhost:9443 az alagúton keresztül. Az első elérésnél egy önaláírt tanúsítványra vonatkozó figyelmeztetés várható; a folytatás előtt győződj meg róla, hogy az SSH-kapcsolat a kívánt kiszolgálót érte el.

Ha elvesztetted a kezdeti hitelesítő adatokat, állítsd vissza az admin jelszót a hosztról:

sudo docker exec safeline-mgt resetadmin

A parancs kiírja azokat az adminisztrátori hitelesítő adatokat, amelyekkel újra bejelentkezhetsz.

Állítsd be a SafeLine-t az architektúrádhoz

A SafeLine most már fut, de még nem véd semmit. A vezérlőpult Applications oldalán adhatod meg a SafeLine-nak, hogy mely webhelyeket védje, és hova továbbítsa a megtisztított forgalmat. A konfiguráció attól függően eltér, hogy korábban melyik architektúrát választottad, ezért minden változat saját alfejezetet kap. Csak azzal foglalkozz, amelyik a te beállításodhoz illik.

A változat: a SafeLine mint az egyetlen reverse proxy

Az A változatnál a SafeLine közvetlenül a 80-as és 443-as portokon figyel, és a megtisztított forgalmat egy nem nyilvános porton továbbítja a backend alkalmazásodhoz. A vezérlőpulton:

1. Navigáljon a következőhöz: Applications, majd Add Application.
2. Állítsd a figyelő portot 443-ra, és engedélyezd az SSL-t. Használd a telepített SafeLine kiadásodban elérhető tanúsítvány-munkafolyamatot. A jelenlegi CE kiadások tartalmazzák a Free Cert igénylést és a megújítás kezelését, miközben a manuális tanúsítványfeltöltés továbbra is elérhető.
3. Állítsd az upstreamet a következőre: http://127.0.0.1:8080. Ha a backend Dockerben fut, csak loopbacken tedd elérhetővé a portját, például "127.0.0.1:8080:8080" a szolgáltatás ports szakaszában. Kerüld a beégetett konténer IP-t, például a következőt: 172.17.0.5 mivel az megváltozhat, amikor a konténert újra létrehozzák.
4. Mentsd az alkalmazást. A SafeLine azonnal elkezd figyelni a 443-as porton, és a megtisztított forgalmat a backendbe továbbítja.
5. Győződj meg róla, hogy a domained DNS A rekordja a VPS nyilvános IP-jére mutat, és hogy a 80-as és 443-as portok kívülről elérhetők.

Ha a 443-as portot már egy másik folyamat lefoglalta, a SafeLine konténere nem tudja lefoglalni, és a vezérlőpult hibát fog jelezni az adott alkalmazásnál. Az alkalmazás hozzáadása előtt állítsd le az ütköző folyamatot, vagy válassz másik portot.

B változat: a SafeLine az Nginx Proxy Manager mögött

A B változatban az NPM azt csinálja tovább, amit eddig is (birtokolja a 80-as és 443-as portokat, kezeli a Let's Encryptet), a SafeLine pedig mögötte egy dedikált biztonsági rétegként illeszkedik be. A forgalom útja: kliens, majd NPM (443-as port, TLS-lezárás), majd SafeLine (10080-as port, HTTP), majd a backend alkalmazás.

A SafeLine vezérlőpulton:

1. Applications, majd Add Application. Állítsd a figyelő portot 10080-ra, és hagyd kikapcsolva az SSL-t (az NPM már lezárta a TLS-t).
2. Állítsd az upstreamet az alkalmazás belső címére, ahogy az A változatnál leírtuk.
3. Mentsd az alkalmazást.

Az Nginx Proxy Managerben:

1. Hosts, majd Proxy Hosts, majd Add Proxy Host.
2. Details fül: állítsd be a domainnevet, a sémát http, és a továbbítási portot 10080-ra. Ha az NPM közvetlenül a hoszton fut, használd a következőt: 127.0.0.1 továbbítási hosztnévként. Ha az NPM Dockerben fut Linuxon, 127.0.0.1 az NPM konténerre mutat, nem a VPS hosztjára. Add hozzá a Docker host-gateway leképezését az NPM Compose szolgáltatáshoz, majd használd a következőt: host.docker.internal továbbítási hosztnévként:

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

Az NPM Compose könyvtárból futtasd a következőt: sudo docker compose up -d hogy a konténer újra létrejöjjön az új hosztleképezéssel.

3. SSL fül: igényelj egy Let's Encrypt tanúsítványt, kényszerítsd az SSL-t, és engedélyezd a HTTP/2-t.
4. Hagyd üresen az NPM Advanced fülét az X-Forwarded-For tekintetében. A jelenlegi NPM sablonban az Advanced tartalom szerver hatókörben szúródik be, és nem írja felül a location szintű, generált fejléceket a NGINX öröklési szabályai. A generált location a következőt küldi:

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

A második direktíva az NPM által megfigyelt címet fűzi hozzá a fejléc legjobb szélső értékeként.

5. Mentsd a Proxy Hostot.

A SafeLine-ba visszatérve csak a tényleges fejléclánc megerősítése után állítsd be a forrás-IP kinyerését. SafeLine 9.3.1 rugalmas XFF-kinyerést vezetett be iránnyal és indexválasztással.

1. Settings, majd Advanced, majd Real IP from Header. Állítsd a fejléc nevét a következőre: X-Forwarded-For.
2. Használj egyéni kinyerést a fejléc végéről, és válaszd ki az NPM által hozzáadott, legjobb szélső címet. A pontos indexcímkék verziónként eltérnek, ezért az eredményt ellenőrizd a Logs, majd Access alatt. Ha a telepített kiadás régebbi, mint a 9.3.1, frissítsd, mielőtt ezt a topológiát követnéd.
3. Ha a Cloudflare vagy egy másik CDN az NPM előtt helyezkedik el, először állítsd be az NPM-et úgy, hogy csak az adott szolgáltató közzétett proxytartományaiban bízzon meg, hogy az NPM által hozzáfűzött cím megbízható legyen. Ne válassz fix pozíciót addig, amíg meg nem vizsgáltad és le nem tesztelted a tényleges fejlécláncot.
4. Mentsd és töltsd újra az alkalmazást.

Teszteld a konfigurációt egy VPS-en kívüli gépről:

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

A SafeLine hozzáférési naplójának a valódi nyilvános címedet kell mutatnia, nem a következőt: 1.2.3.4 vagy az NPM bridge címét.

Akadályozd meg, hogy a felhasználók megkerüljék a SafeLine-t azzal, hogy a backend figyelőt priváton tartod. Egy Docker Compose backend esetén csak loopbacken tedd elérhetővé a portot:

ports:
  - "127.0.0.1:8080:8080"

Egy közvetlenül a hoszton futó szolgáltatásnál állítsd be úgy, hogy a következőn figyeljen: 127.0.0.1:8080 a következő helyett: 0.0.0.0:8080. Ellenőrizd mindkét belső portot egy VPS-en kívüli gépről:

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

A TCP-kapcsolatokat el kell utasítani, vagy le kell járniuk. Egy HTTP hiba vagy az „Empty reply from server" üzenet még mindig azt jelenti, hogy a port nyilvánosan elérhető, és biztonságossá kell tenni. Ha a loopback kötés nem lehetséges, hozz létre a tényleges interfészre, a Docker hálózatra és a cél konténerre szabott tűzfalszabályokat, ahelyett, hogy egy általános DOCKER-USER szabályt alkalmaznál.

C változat: a SafeLine a Caddyvel

A C változatnál a SafeLine veszi át a 80-as és 443-as portokat; a Caddy egy nem nyilvános, belső HTTP portra kerül. A forgalom útja: kliens, majd SafeLine (443, TLS), majd Caddy (8080, belső HTTP), majd az alkalmazás backendje.

Szerkesztés /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

A :8080 site blokk a fontos rész: a Caddy most egy belső HTTP porton figyel ahelyett, hogy a 443-ért versenyezne a SafeLine-nal. A bind 127.0.0.1 sor a figyelőt a VPS-en belül tartja. Töltsd újra a Caddyt a következővel: sudo systemctl reload caddy és erősítsd meg a következővel: sudo ss -ltnp | grep -E ':(443|8080)' hogy a Caddy a 8080-ashoz van kötve, nem a 443-ashoz.

A SafeLine-ban adj hozzá egy alkalmazást, amely a 443-as porton figyel engedélyezett SSL-lel, majd állítsd az upstreamet a következőre: http://127.0.0.1:8080. Az X-Forwarded-For beállítás maradhat az alapértelmezett hálózati kapcsolat opción, mivel a Caddy a SafeLine mögött van, nem előtte.

Válassz védelmi módot, és ellenőrizd, hogy a WAF blokkolja-e a támadásokat

A SafeLine három védelmi móddal rendelkezik, amelyek eldöntik, mi történik, amikor a motor egy kérést rosszindulatúnak jelöl. A megfelelő kezdő mód az alkalmazástól függ; az ellenőrzési lépés bármely módban ugyanaz.

Védelmi módok: Monitor, Balanced, Strict

A SafeLine minden alkalmazása saját védelmi mód beállítást hordoz, amely a következő alatt konfigurálható: Applications, majd az alkalmazásod, majd Protection Mode:

• Monitor. A SafeLine naplózza azokat a kéréseket, amelyeket egyébként blokkolna, de nem blokkolja őket. Ez a legbiztonságosabb kiindulópont egy összetett éles alkalmazáshoz, amely gazdag beviteli űrlapokkal rendelkezik (egy fórum, egy WYSIWYG mezőket tartalmazó adminfelület, egy szabad formátumú JSON-adatokat elfogadó API). Futtasd a Monitort néhány napig, tekintsd át az Attack Events oldalt, és győződj meg róla, hogy nincsenek téves riasztások valós felhasználókkal szemben, mielőtt Balancedre váltanál.
• Balanced. Az alapértelmezett mód. A SafeLine gyártó által közzétett GitHub-adatai 71.65% észlelést, 99.45% pontosságot és 0.07% téves riasztási arányt jelentenek a Balanced módhoz. A Strict módnál 76.17% észlelés, 99.38% pontosság és 0.22% téves riasztási arány szerepel. Ezek gyártó által közölt eredmények, nem független benchmark, és a README nem azonosítja az adatkészletet WAF-Eval-ként. Kezeld ezeket összehasonlító termékadatokként, nem garantált éles teljesítményként.
• Strict. Egy agresszívebb szabálykészlet szigorúbb heurisztikákkal és a fent bemutatott észlelés–téves riasztás közötti kompromisszummal. Érdemes kipróbálni egy-két hét tiszta Balanced működés után, amikor már ismered a forgalmadat.

Ajánlás: Balanced egy friss telepítéshez, ahol nincs zavarható éles forgalom. Egy meglévő éles alkalmazásnál kezdj Monitor módban néhány napig, keress téves riasztásokat az Attack Events naplóban, majd válts Balancedre, miután beállítottad a kivételeket. A Strict egy-két hét Balanced után érdemes kipróbálni, amikor már ismered a forgalmadat.

Ellenőrizd a WAF-ot egy curl SQLi teszttel

Az utolsó lépés, mielőtt a telepítést befejezettnek tekintenéd, annak megerősítése, hogy a WAF valóban elfog egy támadást. Futtass egy ártalmatlan SQL injection próbát a védett webhelyed ellen bármely VPS-en kívüli gépről:

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

Ez a SafeLine által közzétett SQL injection tesztvektor. Balanced vagy Strict módban egy 403-as státuszra és egy SafeLine blokkoló válaszra számíts. Monitor módban arra számíts, hogy a kérés naplózódik blokkolás nélkül. A HTTP verzió és a pontos választörzs eltérhet, ezért az eredményt egy egyező Attack Events bejegyzéssel erősítsd meg.

Ezután nyisd meg a vezérlőpultot a 4. lépésben ismertetett korlátozott hozzáférési módszerrel, és lépj a Logs, majd Attack Events menüpontra. Egy új bejegyzést kell látnod az egyező időbélyeggel, SQL Injection támadástípussal, a curl futtatásához használt géppel egyező forrás-IP-vel, valamint a kérés részleteiben a kifogásolt lekérdezési sztringgel. Kattints az eseményre a SafeLine által rögzített teljes kérés és válasz megtekintéséhez.

Ha a curl kérés 200 OK választ adott, az eredményt az Attack Events naplóval együtt értelmezd:

• Egy egyező SQL Injection esemény azt jelenti, hogy az alkalmazás valószínűleg Monitor módban van; a blokkolás nélküli naplózás elvárt viselkedés.
• Ha nincs egyező esemény, győződj meg róla, hogy a DNS a kívánt VPS-re oldódik fel, ellenőrizd a SafeLine figyelő és upstream konfigurációját, és vesd össze a kérés idejét a SafeLine hozzáférési naplójával.
• Győződj meg arról is, hogy a védelem engedélyezve van, és hogy semmilyen IP-fehérlista, egyéni engedélyezési szabály vagy útvonalkivétel nem vonatkozik a tesztkérésre.

Fő tanulság: Ha a curl próba 403-at ad a SafeLine elfogási oldalával, és egy bejegyzés jelenik meg az Attack Events alatt SQL Injection támadástípussal, akkor a WAF helyesen fogja el a forgalmat.

Mit fed le az ingyenes szint, és mihez kell fizetős csomag

Az ingyenes Personal szint elegendő a legtöbb egy-VPS-es telepítés védelméhez. A fizetős szintek akkor kezdenek számítani, amikor működési funkciókra van szükséged (értesítések, naplóexport, geoblokkolás), vagy kinövöd a 10 alkalmazásos korlátot.

A részletezés, amelynek forrása a CyberServal árazási oldala:

• Personal, ingyenes. Legfeljebb 10 alkalmazás. Tartalmazza a szemantikus észlelő motort (SQLi, XSS, parancsinjektálás, path traversal, SSRF, XXE, CRLF), a sebességkorlátozást, a bot CAPTCHA kihívást, az automatizált scraperek elleni dinamikus HTML/JS titkosítást, a web ACL szabályokat és a tanúsítványkezelést. A jelenlegi CE kiadások szintén tartalmazzák a Free Cert igénylést és a megújítás kezelését.
• Lite, $10/hó vagy $100/év. Hozzáadja a geoblokkolást, a fenyegetettségi hírszerzés IP-adatbázisát, a Discord és Telegram értesítési integrációt, a támadási naplók exportálását, és 20-ra emeli az alkalmazáskorlátot.
• Pro, $100/hó vagy $1,000/év. Hozzáadja az erősebb támadásészlelést, a szolgáltatásonkénti és globális konfigurációkat, az egyéni elfogási oldalakat, az upstream terheléselosztást, a master-slave node szinkronizálást és a korlátlan alkalmazásokat. Lásd a aktuális árazási táblázatot a változásokért.
• Ultimate, egyedi árazás. Testreszabott vállalati feltételek, csatornákon átívelő 1-az-1-ben támogatással és egyedi funkciófejlesztéssel.

A SafeLine az alkalmazásadatokat a helyi Compose stackjében dolgozza fel és tárolja. Azonban a jelenlegi CE kiadási megjegyzések megemlítik a Threat Intelligence Sharinget, ezért az üzemeltetőknek át kell nézniük a telepített verzió UEP-, adatvédelmi és megosztási beállításait, és meg kell figyelniük a kimenő kapcsolatokat, mielőtt a telepítést zero-egressként kezelnék.

Merre tovább innen

A telepítés kész, és a WAF ellenőrizve van. Néhány utólagos feladat segít abban, hogy a telepítés egészséges maradjon.

• Bármely gazdag felhasználói bevitelt tartalmazó éles alkalmazásnál (egy fórum, egy adminfelület, egy szabad formátumú API) állítsd a védelmi módot a következőre: Monitor három-hét napig, naponta tekintsd át az Attack Events oldalt, és válts Balancedre, miután beállítottad a téves riasztásokat.
• A Lite szinten állítsd be a Discord vagy Telegram értesítési integrációt, hogy a támadási riasztások a vezérlőpulton kívül is elérjenek téged.
• Ütemezz be egy havi karbantartási ablakot. Frissítés előtt készíts biztonsági mentést a SafeLine adatairól és környezeti konfigurációjáról, olvasd el a aktuális kiadási megjegyzéseket, és használd a telepített verziódhoz támogatott frissítési eljárást. Ne támaszkodj kizárólag a következőre: docker compose pull majd ezt követően docker compose up -d, mivel a Compose definíció vagy a szükséges környezeti változók kiadásonként változhatnak. A Cloudzy egykattintásos felhasználóknak a következőből kell dolgozniuk: /opt/safeline és követniük kell a marketplace image utasításait.
• Iratkozz fel a SafeLine kiadások oldalára a biztonsági javítási értesítésekért, és a projekt repozitóriumára a hibakövetéshez.

Ha még nincs VPS-ed ehhez a telepítéshez, a SafeLine egykattintásos telepítésként elérhető a A Cloudzy piactere. A 4 GB RAM-mal rendelkező csomag biztosítja az útmutatóban ajánlott gyakorlati tartalékot; ellenőrizze újra aktuális árazási táblázatot a Cloudzy oldalán a közzététel idején, mert a csomagspecifikációk változhatnak. Az egykattintásos lemezkép a következőt használja: /opt/safeline és /opt/safeline/docker-compose.yml, így az architektúrával és a vezérlőpulttal kapcsolatos utasítások érvényesek, de ennek az útmutatónak a /data/safeline parancsai nem alkalmazhatók azonos módon.

Gyakran ismételt kérdések

A SafeLine WAF felváltja az Nginx Proxy Managert, vagy mindkettőt futtatom?

A SafeLine felválthatja az Nginx Proxy Managert, ha az egyetlen reverse proxyként telepíted. Azonban nem szükséges felváltania az NPM-et. Egy gyakori elrendezésben az NPM marad elöl az SSL-hez és az útválasztáshoz, a SafeLine pedig mögötte egy dedikált biztonsági rétegként helyezkedik el. Mindkettő működik; a választás attól függ, hogy egy eszközt szeretnél mindkét feladatra, vagy két eszközt, amelyek egyenként egy-egy feladatot látnak el jól.

Elég az ingyenes szint egyetlen WordPress-webhelyhez vagy egy kis SaaS-hez?

Igen, a védelemhez igen. Az ingyenes Personal szint tartalmazza a szemantikus észlelő motort, a sebességkorlátozást, a bot CAPTCHA kihívást és a dinamikus HTML/JS titkosítást, amelyek egyetlen webhely alapvető védelmét jelentik. A fizetős szintek olyan működési funkciókat adnak hozzá, mint a geoblokkolás, a támadási naplók exportálása, a külső értesítések, a magasabb alkalmazáskorlátok, az erősebb észlelés és a terheléselosztás. Az, hogy szükséges-e fizetős szint, a kívánt funkcióktól és az alkalmazások számától függ, nem pusztán a forgalom mennyiségétől.

Működik a SafeLine egy 1 GB RAM-os VPS-en?

A SafeLine hivatalos minimuma 1 GB RAM. Ez elegendő lehet teszteléshez vagy nagyon könnyű terheléshez, de az éles kapacitás a forgalomtól, az engedélyezett funkcióktól és a naplómegőrzéstől függ. Egy kis éles telepítéshez 2 vCPU és 4 GB RAM egy óvatos kiindulópont; figyeld a memóriahasználatot, és a mért terhelés alapján skálázz.

Miért igényel az ARM64 fizetős licencet?

A SafeLine hivatalos telepítési dokumentációja kimondja, hogy az ARM telepítések Pro licencet igényelnek, és hogy a Personal Edition nem támogatott ARM-on. Ha a Personal Editiont szeretnéd, válassz x86_64 VPS-t; ha ARM-ra van szükséged, számolj egy Pro licenccel.

Mit kap a Chaitin Tech a SafeLine példányomtól?

A pontos kimenő adatok kiadásonként és az engedélyezett funkcióktól függően eltérhetnek. A jelenlegi CE kiadási megjegyzések megemlítik a Threat Intelligence Sharinget, míg a telepített verzió UEP-t vagy más megosztási beállításokat is elérhetővé tehet. Nézd át ezeket a beállításokat és a telepített verziód kiadási megjegyzéseit, majd ellenőrizd a kimenő forgalmat hálózati szinten. A SafeLine helyi konténerei kezelik az alkalmazásadatokat, de ez a tény önmagában nem bizonyítja, hogy az UEP visszautasítása minden kimenő kérést leállít.