Un stack de servere bine întărit blochează mult zgomot, dar multe atacuri moderne trăiesc mai sus în stack. Payload-uri de SQL injection, path traversal, JSON malițios, credential stuffing automatizat și abuzuri de logică trec ușor de apărările de la nivelurile 3 și 4. Aici își face treaba un Web Application Firewall. În acest tutorial, echipa ENGINYRING te ghidează să implementezi un WAF de producție pe un VPS ENGINYRING folosind NGINX, ModSecurity v3 și OWASP Core Rule Set (CRS). La final vei avea un WAF în modul de detecție, un parcurs sigur pentru a activa blocarea, un playbook de testare și o procedură curată pentru a gestiona false positive fără să strici traficul legitim.

Cui îi este dedicat acest ghid

Tutorialul vizează administratori de sistem și dezvoltatori care găzduiesc aplicații web critice, API-uri și magazine eCommerce. Ar trebui să fii confortabil cu SSH, managementul pachetelor, elementele de bază NGINX și editarea fișierelor de configurare ca root. Abordarea este neutră față de vendor și funcționează impecabil pe VPS-urile ENGINYRING și pe majoritatea distribuțiilor Linux similare.

De ce ModSecurity v3 cu OWASP CRS

Motor matur, conector modern: ModSecurity v3 separă motorul (libmodsecurity) de conectorii pentru web server, oferind performanță mai bună și mentenanță mai ușoară.
OWASP Core Rule Set: Un set de reguli întreținut de comunitate, orientat pe tipuri reale de atac, care detectează și blochează cele mai frecvente atacuri out-of-the-box.
Portabil și auditabil: Reguli ușor de citit, tunabile per aplicație, cu metodologie de test transparentă.

Prerechizite

Un VPS ENGINYRING cu Debian sau Ubuntu LTS curent. Dacă nu ai încă, începe aici: ENGINYRING Virtual Servers.
NGINX deja instalat și servind site-ul sau API-ul tău.
Acces root sau sudo prin SSH.
Un domeniu care pointează la VPS (recomandat pentru TLS). Poți gestiona DNS prin ENGINYRING Domains.

Arhitectură, pe scurt

ModSecurity rulează ca modul în NGINX. Cererile ajung în NGINX, WAF-ul inspectează antetele, URL-ul, parametrii, cookie-urile și opțional corpul cererii. Motorul evaluează regulile pe faze și poate înregistra, bloca sau permite. Începem în modul doar detecție pentru a „învăța” traficul, apoi trecem cu grijă pe blocare după ce eliminăm zgomotul.

Partea 1: Instalarea ModSecurity v3 și a conectorului NGINX

Denumirile pachetelor variază în funcție de distribuție. Mai jos sunt pașii de referință pentru Debian/Ubuntu folosind pachete din distribuție. Dacă distribuția ta oferă un modul mai vechi, poți compila conectorul din sursă, dar cei mai mulți utilizatori preferă pachetele.

1. Actualizează și instalează dependențele

sudo apt update
sudo apt install -y nginx libmodsecurity3 modsecurity-crs

Pe unele distribuții, conectorul NGINX este pachetul libnginx-mod-security sau vine cu setul de module NGINX. Dacă modulul este separat, rulează și:

sudo apt install -y libnginx-mod-security

Dacă repository-ul tău nu oferă conectorul, consultă documentația distribuției pentru numele pachetului sau ia în calcul NGINX-ul oficial care include modulul dinamic ModSecurity. Ținta este să ai motorul (libmodsecurity) și conectorul NGINX instalate.

2. Verifică modulul

Listează modulele NGINX și confirmă prezența ModSecurity:

nginx -V 2&gt;&amp;1 | tr ' ' '\n' | grep -i modsecurity || true

Pe unele distro, conectorul se încarcă automat. Dacă nu, încarcă modulul dinamic în /etc/nginx/nginx.conf (la început, înainte de blocul http):

load_module modules/ngx_http_modsecurity_module.so;

Relansează NGINX ca să confirmi că pornește curat:

sudo nginx -t
sudo systemctl reload nginx

Partea 2: Configurație ModSecurity curată

Păstrăm toate fișierele WAF sub /etc/nginx/modsec pentru claritate și ușurință la versionare.

1. Creează directorul de configurare

sudo mkdir -p /etc/nginx/modsec
sudo chmod 750 /etc/nginx/modsec

2. Pornește de la configurația recomandată

Majoritatea distribuțiilor livrează un fișier exemplu. Pornim de la el și îl ajustăm.

sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Deschide-l și setează motorul pe detecție pentru faza inițială de învățare:

sudo nano /etc/nginx/modsec/modsecurity.conf

Găsește linia:

SecRuleEngine DetectionOnly

Asigură-te că ai următoarele opțiuni (adaugă dacă lipsesc):

# Log doar ce contează pentru triere
SecAuditEngine RelevantOnly
SecAuditLog /var/log/nginx/modsec_audit.log

# Inspectează corpul cererii până la limite rezonabile
SecRequestBodyAccess On
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyLimitAction Reject

# Gestionare protocol
SecResponseBodyAccess Off
SecDefaultAction "phase:1,log,pass"
SecDefaultAction "phase:2,log,pass"

3. Creează un include principal pentru reguli

Vom folosi un fișier principal care include opțiunile motorului, whitelist-urile locale și CRS:

sudo tee /etc/nginx/modsec/main.conf &gt; /dev/null &lt;&lt; 'EOF'
# Opțiuni de bază ModSecurity
Include /etc/nginx/modsec/modsecurity.conf

# Excepții locale și whitelist (înainte de CRS)
# Include /etc/nginx/modsec/whitelist.conf

# OWASP CRS: setup &amp; reguli
Include /etc/nginx/modsec/owasp-crs/crs-setup.conf
Include /etc/nginx/modsec/owasp-crs/rules/*.conf
EOF

Partea 3: Instalează OWASP Core Rule Set (CRS)

Dacă distribuția ta a instalat modsecurity-crs, ai deja CRS pe disc. Altfel, ia-l din repository-ul oficial.

Varianta A: din pachetul distribuției

Cale comună (ajustează dacă pachetul tău diferă):

sudo ln -s /usr/share/modsecurity-crs /etc/nginx/modsec/owasp-crs

Copiază fișierul de setup:

sudo cp /etc/nginx/modsec/owasp-crs/crs-setup.conf.example /etc/nginx/modsec/owasp-crs/crs-setup.conf

Varianta B: clonează din upstream

cd /etc/nginx/modsec
sudo git clone https://github.com/coreruleset/coreruleset.git owasp-crs
cd owasp-crs
sudo cp crs-setup.conf.example crs-setup.conf

În acest punct, /etc/nginx/modsec/main.conf face referire la fișierele CRS și le va încărca la pornirea NGINX.

Partea 4: Leagă WAF-ul de NGINX

Activăm ModSecurity la nivel de server. Poți activa și pe location ulterior. Editează blocul server și adaugă două directive:

Exemplu de bloc server

sudo nano /etc/nginx/sites-available/your-site.conf

server {
    listen 80;
    server_name your-domain.example;

    # Pornește WAF pentru acest server
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    # Configurația obișnuită NGINX
    root /var/www/your-site/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Exemplu PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    # Statice, antete cache, TLS etc.
}

Testează și încarcă:

sudo nginx -t
sudo systemctl reload nginx

Partea 5: Rulează WAF-ul în modul doar detecție

Lasă SecRuleEngine DetectionOnly cel puțin 48–72 de ore într-un site de producție. Asta colectează alerte fără a bloca utilizatorii. Revizuiește audit log-ul și error log-urile NGINX pentru a identifica regulile zgomotoase și tiparele specifice aplicației.

Localizează și urmărește log-urile

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/modsec_audit.log

Caută mesaje cu ID-uri de regulă, de forma id "942100". Pe acestea le vei folosi la tuning.

Partea 6: Treci în mod de blocare în siguranță

După ce ai revizuit alertele și ai redus false positive, poți comuta pe blocare. Editează /etc/nginx/modsec/modsecurity.conf:

SecRuleEngine On

Opțional, întărește acțiunile implicite:

SecDefaultAction "phase:1,log,deny,status:403"
SecDefaultAction "phase:2,log,deny,status:403"

Testează și încarcă:

sudo nginx -t
sudo systemctl reload nginx

Partea 7: Verifică dacă WAF-ul chiar funcționează

Trimite o cerere inofensivă dar „suspectă” și confirmă un 403 în modul de blocare sau o alertă în modul de detecție.

Testează un path traversal simplu

curl -i "https://your-domain.example/?file=../../etc/passwd"

Testează un pattern SQLi

curl -i "https://your-domain.example/search?q=' or '1'='1"

Ar trebui să primești HTTP 403 cu blocarea activă sau o alertă ModSecurity în log în modul de detecție. Testează mereu pe un endpoint nedistructiv sau pe o clonă de staging.

Partea 8: Gestionează false positive fără a strica funcționalitatea

False positive apar, mai ales la aplicații complexe, endpoint-uri legacy sau integrări webhook. Scopul este să restrângi excepția doar pe ruta sau parametrul afectat, nu să dezactivezi grupuri întregi de reguli.

1. Creează un fișier de whitelist

sudo nano /etc/nginx/modsec/whitelist.conf

Exemplu: un webhook de plată trimite JSON care declanșează regula CRS 942100. Restrânge excepția la acel endpoint și metodă.

# Doar pentru webhook-ul de plăți, elimină o singură regulă zgomotoasă
SecRule REQUEST_URI "@beginsWith /api/payments/webhook" \
    "id:1000001,phase:1,pass,log,ctl:ruleRemoveById=942100"

Decomentează include-ul whitelist în /etc/nginx/modsec/main.conf ca să se încarce înainte de CRS:

# Excepții locale și whitelist
Include /etc/nginx/modsec/whitelist.conf

Reîncarcă NGINX:

sudo nginx -t
sudo systemctl reload nginx

2. Restrânge și mai mult țintirea, dacă se poate

Vizează parametri specifici cu colecțiile REQUEST_FILENAME, ARGS_NAMES, REQUEST_HEADERS sau REQUEST_BODY.
Limitează pe metodă (ex. doar POST) cu chain și o condiție pe REQUEST_METHOD.
Preferă eliminarea unui singur ID de regulă în locul dezactivării unui întreg grup (de ex. 9xx).

Partea 9: Considerații de performanță și logging

Un WAF bine reglat adaugă un overhead minim. Următoarele bune practici țin CPU-ul și I/O-ul în frâu:

Păstrează audit logs pe RelevantOnly: Evită logarea completă a payload-urilor pentru răspunsuri 200 de rutină.
Rulează rotație de loguri: Configurează logrotate pentru /var/log/nginx/modsec_audit.log și error.log.
Scope pe body inspection: Mărește SecRequestBodyLimit doar dacă ai cu adevărat nevoie de upload-uri mari inspectate.
Dezactivează inspectarea răspunsului: Ține SecResponseBodyAccess Off dacă nu e cerut de reguli specifice.

Partea 10: Erori comune și remedieri

NGINX nu pornește: „unknown directive ‘modsecurity’”: Modulul conector nu este încărcat. Încarcă-l din nginx.conf sau instalează libnginx-mod-security.
403 pe cereri legitime imediat după activarea blocării: Revino la DetectionOnly, analizează logurile, adaugă o whitelist îngustă, apoi reactivează blocarea.
Nu apar alerte în loguri la test: Asigură-te că ai inclus main.conf și fișierele CRS și că ai modsecurity on; în blocul server.
CPU ridicat la upload-uri POST mari: Crește limitele cu prudență sau exclude endpoint-urile mari de la body inspection cu reguli țintite.
Include-uri duplicate, ordine greșită a regulilor: Încarcă whitelist înainte de CRS ca excepțiile să se aplice devreme.

Partea 11: Specific pentru API și JSON

API-urile trimit adesea corpuri JSON care pot părea suspecte regulilor generice. Două sfaturi:

Setează corect content type-ul. Majoritatea framework-urilor trimit Content-Type: application/json, lucru cu care CRS se descurcă mai bine decât cu corpuri URL-encoded.
Fă whitelist strict doar pentru endpoint-urile JSON necesare, pe bază de URI și ID de regulă unic.

Partea 12: Staging, rollback și controlul schimbărilor

Tratează schimbările WAF ca pe codul aplicației:

Folosește versionare pentru /etc/nginx/modsec, dacă se poate.
Testează whitelist-ul pe staging cu replay de trafic, dacă ai această opțiune.
Rulează în DetectionOnly, apoi activează blocarea într-o fereastră de trafic mic, cu on-call pregătit.
Documentează ID-urile de reguli eliminate și justificarea.

Checklist operațional

Baseline în DetectionOnly colectat minimum 48 de ore.
ID-urile de reguli zgomotoase identificate și, dacă e justificat, permise punctual.
Blocarea activată cu procedură clară de rollback.
Volumul de loguri verificat, rotație configurată.
Plan de update periodic pentru CRS, testat pe staging înainte de producție.

Cum ții regulile la zi

CRS este activ întreținut. Planifică un ciclu lunar sau trimestrial de update:

cd /etc/nginx/modsec/owasp-crs
sudo git pull
sudo nginx -t &amp;&amp; sudo systemctl reload nginx

Dacă folosești pachete din distribuție, actualizează prin managerul de pachete și citește changelog-urile pentru modificări de reguli.

Unde se potrivește ENGINYRING în stiva ta de securitate

Un WAF completează, nu înlocuiește, un cod de aplicație solid, patch management și controale de rețea. Platforma ENGINYRING îți oferă fundația fiabilă pentru un WAF eficient:

Rulează pe un VPS ENGINYRING cu CPU, RAM și stocare NVMe rapide.
Ține-ți endpoint-urile curate cu ENGINYRING Domains și management DNS.
Ai nevoie de panouri gestionate? Serviciile noastre de management servere cPanel și management servere DirectAdmin te pot ajuta să aplici conceptele WAF în medii administrate.
Infrastructuri de virtualizare complexe pot beneficia de management Proxmox cu load balancing „WAF-aware”.
Întrebări sau setup-uri personalizate? Contactează ENGINYRING pentru ghidaj dedicat.

Exemplu complet: layout minim, pregătit de producție

O structură compactă și ușor de întreținut pe care o poți adopta azi.

Structura fișierelor

/etc/nginx/modsec/
  modsecurity.conf          # opțiuni motor (DetectionOnly la început, On pentru blocare)
  main.conf                 # include motor, whitelist, CRS setup, regulile CRS
  whitelist.conf            # excepții înguste (editezi tu)
  owasp-crs/                # repository CRS sau pachet
    crs-setup.conf
    rules/*.conf

Fragment din blocul server

server {
    listen 443 ssl http2;
    server_name app.example.com;

    # Detaliile TLS omise pentru concizie

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    # Config aplicație ...
}

Exemplu de whitelist pentru un webhook JSON

# Elimină doar regula specifică pe o cale și metodă înguste
SecRule REQUEST_URI "@beginsWith /api/webhook" \
    "id:1000002,phase:1,pass,log,chain"
    SecRule REQUEST_METHOD "@streq POST" "t:none,ctl:ruleRemoveById=942100"

Pașii următori

Baseline: rulează DetectionOnly câteva zile, revizuiește alertele, documentează excepțiile necesare.
Activează blocarea într-o fereastră controlată, cu monitorizare pe dashboarduri și loguri.
Ține CRS la zi și revizuiește periodic whitelist-ul pentru a elimina excepțiile vechi.
Ia în calcul rate limiting în NGINX și detecție bot pe endpoint-urile sensibile.

Concluzie

Un WAF proactiv oprește atacurile din lumea reală înainte să ajungă în aplicația ta. Cu NGINX, ModSecurity v3 și OWASP CRS, poți implementa pe un VPS ENGINYRING un control eficient, auditabil și ușor de ajustat în mai puțin de o oră, apoi îl rafinezi în siguranță pe parcursul câtorva zile. Cheia este un rollout măsurat: observă în DetectionOnly, adaugă excepții punctuale, apoi treci pe blocare cu încredere. De aici, un ritm modest de mentenanță îți menține protecția actuală, iar utilizatorii rămân plăcut „neimpresionați” — adică fără întreruperi și incidente care… nu mai au loc.

Sursă și Atribuire

Aceast articol se bazează pe date originale ale ENGINYRING.COM. Pentru metodologia completă și pentru a asigura integritatea datelor, articolul original trebuie citat. Sursa canonică este disponibilă la: Cum se configurează un Web Application Firewall (WAF) puternic cu ModSecurity și NGINX pe VPS-ul tău.

Găzduire

Management & Branding

Digitalizare

Cum se configurează un Web Application Firewall (WAF) puternic cu ModSecurity și NGINX pe VPS-ul tău