WAF

SafeLine WAF: un firewall open-source serios pentru aplicatiile tale web

Daca ai stat vreodata noaptea la 3 dimineata cu un grafic de erori 5xx in fata in timp ce un botnet bate la fiecare formular de login pe care il ai, deja stii de ce conteaza un Web Application Firewall. Intrebarea sincera este pe care sa-l pui in fata stack-ului tau fara sa platesti Cloudflare Enterprise si fara sa te lupti weekend-uri intregi cu reguli ModSecurity.

SafeLine , WAF-ul open-source mentinut de Chaitin Tech , aduna in tacere momentum exact pe acea nisa. La versiunea v9.3.4 (lansata pe 17 aprilie 2026) are peste 21.000 de stele pe GitHub, ruleaza in peste 180.000 de instalari si este licentiat sub GPL-3.0. Il testam de cateva saptamani pe un VPS in datacenterul nostru din Bucuresti. Acest articol e raportul de teren.

Ce este, mai exact, SafeLine

Ca arhitectura, SafeLine e un reverse proxy cu motor de detectie in fata originii tale. Traficul intra in SafeLine pe porturile 80/443, e inspectat, si fie e lasat sa treaca spre aplicatia upstream, fie e provocat, limitat sau blocat. Reverse proxy-ul e construit pe un fork hardenizat de Tengine (Tengine fiind derivatul nginx al Alibaba), cu logica de detectie implementata ca module native in C++ si Lua. Planul de management e un serviciu in Go cu PostgreSQL in spate.

Daca suna mult ca nginx + ModSecurity, comparatia e corecta pe hartie si nedreapta in practica. Partea interesanta e ce se intampla intre momentul in care soseste cererea si apelul catre upstream.

De ce motorul de detectie e diferit

Majoritatea WAF-urilor open-source pe care le-ai atins, ModSecurity cu OWASP Core Rule Set fiind exemplul canonic, sunt fundamental motoare regex. Cauta tipare in cerere si decid. Compromisul e bine cunoscut: stransi regulile si incepi sa blochezi useri legitimi, le slabesti si atacurile trec. Oricine a pus paranoid mode pe ModSecurity in fata unui WordPress stie taxa pe fals-pozitive.

SafeLine merge pe alt drum. Parseaza cererea ca structura sintactica (gramatica SQL pentru parametrii care arata a query, AST de JavaScript pentru continut script, parser shell pentru tipare de comanda) si apoi evalueaza daca rezultatul parsat are forma semantica de atac. Un query cu ghilimele nu e automat suspect; un query a carui forma parsata ar schimba fluxul de executie SQL este. Echipa Chaitin publica numere de benchmark in jur de 99,4% acuratete in modul balance, in zona ofertelor comerciale.

Tot ar trebui sa verifici pe traficul tau, toate benchmark-urile WAF au un puternic iz de “testat pe setul de date pe care l-am construit noi”, dar in practica rata de fals-pozitive pe workload-urile noastre de test a fost substantial mai mica decat ModSecurity cu CRS la paranoia level 2. Asta singur schimba povestea operationala: un WAF pe care nu trebuie sa-l whitelist-ezi constant e un WAF care ramane pornit.

Ce primesti din cutie

Editia community (despre care vorbim, editia Pro e anuntata dar nu general disponibila la momentul scrierii) vine cu:

Detectie de atacuri web pentru categoriile canonice OWASP: SQL injection, XSS, command si code injection, XXE, SSRF, path traversal, tipare de deserializare.
Rate limiting per IP, per cale, per sesiune, cu ferestre si comportament de burst configurabile.
Anti-bot challenge, un proof-of-work JavaScript pe care browserele legitime il rezolva transparent si pe care scraperele headless se impotmolesc.
Authentication challenge, o poarta separata pe care o poti pune in fata panourilor de admin (gandeste-te: un pas tip captcha inainte sa ajunga cererea la /wp-admin/).
Criptare dinamica HTML/JS, care altereaza identificatorii client-side la fiecare cerere astfel incat scraperele si tool-urile de credential stuffing sa nu poata tinti usor campurile din formulare.
Geo blocking pe tara, util pentru site-urile fara business in afara unei regiuni.
Dashboard de logging si analiza, care e chiar util (mai jos despre asta).

Ce nu face: nu e un CDN. Nu cache-uieste asseturi statice, nu-ti da POP-uri in jurul lumii, nu te apara de DDoS volumetric L3/L4 la marginea retelei. SafeLine e firewall pe layer 7. Daca primesti 100 Gbit de UDP reflection, ai nevoie de mitigare la nivel de retea in amonte, genul celei pe care o rulam la AS57050 cu setup-ul nostru de RTBH si sFlow , inainte ca traficul sa-ti ajunga la VPS.

Instalare SafeLine pe un VPS

Asta e partea unde majoritatea proiectelor “open source WAF” te fac sa regreti decizia. SafeLine, sincer, nu. Comanda one-liner oficiala face ce trebuie pe o cutie curata de Debian sau Ubuntu.

Resurse minime rezonabile: 2 vCPU, 4 GB RAM, 10 GB liberi pe disc. Scriptul avertizeaza sub 5 GB liberi. E nevoie de instructiuni CPU SSSE3 (orice procesor x86 facut in ultimii 15 ani le are, dar daca rulezi pe ceva exotic, verifica /proc/cpuinfo). Sunt suportate atat x86_64 cat si arm64.

Pe un server proaspat:

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

Scriptul va:

Instala Docker si plugin-ul Compose daca lipsesc.
Pune un stack docker-compose la /data/safeline/.
Alege o subretea privata neutilizata (incearca, in ordine, 172.22.222.0/24, 169.254.222.0/24, 192.168.222.0/24).
Genera o parola Postgres random de 32 de caractere.
Trage si porni patru containere: safeline-pg, safeline-mgt, safeline-detector, safeline-tengine.

Dupa ce termina, UI-ul de management e la https://<ip-server>:9443/ cu un certificat self-signed. Ca sa iei credentialele initiale de admin:

docker exec safeline-mgt resetadmin

Comanda asta tipareste un user si o parola de unica folosinta pentru primul login. Schimba parola imediat dupa ce intri. Cat esti acolo, restrictioneaza portul 9443 cu o regula de firewall, planul de management nu trebuie expus pe internet:

ufw allow from IP_BIROU_TAU to any port 9443
ufw deny 9443

Daca rulezi asta pe un VPS DreamServer , aceeasi regula trebuie pusa si in firewall-ul de retea al providerului, nu te baza doar pe regulile la nivel de host pentru interfete de management.

Cum pui un site real in spate

Adaugarea unui site protejat e simpla, dar modelul mental dureaza un minut sa se aseze. SafeLine devine endpoint-ul public; aplicatia ta reala devine un upstream intern cu care vorbeste doar SafeLine.

In UI-ul de management, Sites > Add site:

Domeniu: example.com (si orice alias-uri pe care le servesti).
Port: 80 pentru HTTP simplu, 443 pentru HTTPS, ambele daca vrei sa faca SafeLine redirectul.
Upstream: IP-ul si portul originii tale, de exemplu 10.0.0.5:8080. Daca originea sta pe aceeasi cutie, foloseste gateway-ul bridge-ului docker (de obicei 172.17.0.1 sau cea aleasa de script) si portul pe care asculta aplicatia ta.
Certificat TLS: lipeste certificat si cheie, sau urca unul emis de Let’s Encrypt. SafeLine nu emite acum certificate automat, vii cu al tau.

Salveaza, apoi indica recordurile A/AAAA ale domeniului spre hostul SafeLine. In cateva secunde site-ul apare la Detection logs si poti urmari traficul live trecand prin el.

Primul lucru de verificat e ca SafeLine e chiar inline. Trimite o cerere intentionat proasta:

curl -k "https://example.com/?id=1' OR '1'='1"

Ar trebui sa primesti o pagina de blocare SafeLine (HTML in body, HTTP 403 default) si o intrare corespunzatoare in log-ul de detectie. Daca cererea ajunge la aplicatie, DNS-ul sau configul de upstream e gresit, repara aia inainte sa te bazezi pe orice altceva.

Tipare de configurare care merita stiute

Cateva tipare pe care le-am gasit chiar utile, dincolo de default-uri.

Whitelist pentru health check-uri

Daca sistemul tau de monitoring loveste /health dintr-un IP cunoscut, nu lasa SafeLine sa scoreze cererile alea. Adauga o regula Allow in capul lantului de policy care matcheaza IP sursa si cale, cu actiunea “skip detection”. Scopul nu e sa salvezi CPU, e sa-ti pastrezi log-urile de detectie curate de trafic in care ai incredere.

Rate limit inainte de block

Cand pornesti rate limiting pe un endpoint de login, prefera challenge in loc de block la primul prag. Un bot care intra intr-un challenge moare in tacere; un om care si-a gresit parola de trei ori la rand trece. Pastreaza actiunea de block pentru al doilea prag (sa zicem, 30 de cereri pe 5 minute de la un singur IP).

Contraintuitiv, dar util: porneste challenge-ul JS pe tot site-ul pentru cai de valoare mica (homepage-ul, blogul) pe un procent mic de trafic. Botii care pica challenge-ul acolo sunt aceiasi care ulterior ti-ar incerca formularul de login. Inveti multe despre ce te loveste inainte ca vreun endpoint sensibil sa vada traficul.

Authentication challenge pentru caile de admin

Pentru orice match cu /admin*, /wp-admin*, /phpmyadmin*, adauga un strat de authentication challenge. SafeLine implementeaza asta ca o poarta in plus care cere rezolvarea unui challenge tip CAPTCHA inainte ca cererea sa ajunga la aplicatia ta. Nu inlocuieste autentificarea aplicatiei, doar opreste tool-urile automate sa mai bata vreodata la usa.

Citeste log-urile

Dashboard-ul la Statistics > Detection logs arata fiecare cerere blocata cu motivul parsat: ce motor a declansat (SQLi semantic, XSS regex, anti-bot), corpul cererii, scorul. Petrece o ora trecand prin el a doua zi dupa ce pornesti SafeLine. Vei descoperi ca cea mai mare parte din “traficul ciudat” arata la fel: o mana de toolkit-uri de mass-scanning lovind aceleasi cai de admin WordPress si aceleasi URL-uri .env expuse.

Unde SafeLine nu e raspunsul potrivit

Merita sa fim onesti despre limite.

Nu e CDN. Fara cache, fara POP-uri la margine. Daca povestea ta de performanta depinde de proximitatea la edge, tot ai nevoie de un CDN in fata (sau pe langa) SafeLine.
Nu pentru cai sub-milisecunda. Fiecare cerere trece prin detectie. Overhead-ul median in testele noastre a fost 1 pana la 3 ms pe cache cald, ok pentru aproape orice aplicatie web, dar daca rulezi un API HFT, nu e tool-ul tau.
Nu toate feature-urile Pro sunt deschise. Cateva dintre feature-urile mai sofisticate de protectie dinamica si clustering-ul multi-nod sunt clar destinate viitoarei editii Pro. Editia community e generoasa, dar daca protejezi o flota de zeci de site-uri cu cerinte HA, planuieste in consecinta.
Self-hosting nu e gratis. Mai rulezi un serviciu stateful care are nevoie de backup-uri, OS patching, si Postgres babysitting ocazional. Daca echipa ta nu vrea asta, un WAF gestionat va fi mai ieftin in ore de operator.

Alternative pe care le-am luat in calcul

Pentru completitudine: ne-am uitat si la BunkerWeb (bazat pe nginx, foarte abordabil, detectie semantica mai slaba), Coraza (reimplementare nativa in Go a ModSecurity, excelent daca vrei sa incorporezi logica de WAF direct intr-un service mesh), si OWASP CRS pe nginx clasic cu ngx_security_module (testat in lupta, infinit reglabil, fals-pozitivele devin hobby-ul tau).

SafeLine s-a dovedit cea mai curata potrivire pentru “vreau un WAF real in fata unei flote mici de site-uri self-hosted fara sa devin specialist in WAF-uri”. Ponderile tale pot fi diferite.

Deci, sa-l rulezi?

Daca host-uiesti aplicatii web in PHP, Node, Python sau Go pe un VPS sau server dedicat si tot vrei “sa faci ceva in privinta header-elor de securitate si a traficului de boti”, SafeLine merita o duminica dupa-amiaza. Instalarea e chiar rapida, detectia merge fara sa te lupti cu ea, si dashboard-ul iti spune ceva adevarat despre traficul tau.

Daca il rulezi in productie, pune-l pe un server cu o poveste reala de backup (Proxmox Backup, snapshot-uri, alegerea ta) si trateaza planul de management ca infrastructura critica. Containerele de detectie pot fi reconstruite intr-un minut; configuratia din Postgres e ce ti-ar lipsi cu adevarat.

Noi rulam SafeLine in fata catorva servicii interne si il recomandam clientilor care intreaba. Daca vrei sa-l incerci pe infrastructura pe care nu trebuie sa o construiesti tu intai, planurile noastre VPS incep la dimensiuni mici cat sa faca experimentul ieftin, iar serviciul de administrare server acopera instalarea si tuning-ul daca preferi sa sari peste curba de invatare.

Oricum ai alege, sa testezi SafeLine e o seara mai bine petrecuta decat citind inca un listicle “top 10 WAF”. Codul e pe GitHub, instalarea e o singura comanda, si vei sti intr-o ora daca isi castiga un loc in stack-ul tau.