Wazuh, XDR si SIEM open source pentru cine chiar are nevoie de detectie centralizata

Ai cateva servere, poate un VPS sau doua aplicatii critice, si cand ceva pare in neregula deschizi jurnalele si dai grep dupa un IP suspect sau un mesaj de eroare care revine prea des. Functioneaza atata vreme cat esti singurul care se uita si numarul de masini se numara pe degete. Apoi infrastructura creste: mai multe servere, poate un client care cere un audit de securitate sau o cerinta de conformitate (PCI DSS, GDPR, HIPAA) care iti pretinde dovezi ca monitorizezi integritatea fisierelor, ca detectezi intruziuni si ca pastrezi jurnale analizate central, nu doar niste fisiere text imprastiate pe fiecare masina in parte. In punctul acela, grep-ul manual nu mai e o strategie de securitate, e doar noroc care inca nu s-a terminat.

Wazuh (repo pe github.com/wazuh/wazuh , site oficial wazuh.com ) e instrumentul construit exact pentru acest salt: o platforma open source, licentiata GPLv2, care combina XDR (Extended Detection and Response) cu SIEM (Security Information and Event Management) intr-un singur stack. Pentru organizatiile care au nevoie de analiza centralizata a jurnalelor si de monitorizare a integritatii fisierelor pe o flota de servere, Wazuh e una dintre cele mai solide optiuni open source disponibile azi, nu pentru ca ar fi singura varianta, ci pentru ca acopera realist tot ciclul: colectare de telemetrie, detectie, corelare cu framework-uri de referinta, alertare si raportare de conformitate.

Ce este, mai exact, Wazuh

Pe scurt, Wazuh functioneaza cu agenti usori instalati pe endpoint-uri si servere, care colecteaza telemetrie (jurnale de sistem si aplicatie, apeluri de sistem, modificari de fisiere, inventar software) si o trimit catre un server central. Acolo, datele sunt decodate, comparate cu un set de reguli si transformate in alerte cu sens, nu doar randuri brute de text. In jurul acestui nucleu exista un indexer, construit pe OpenSearch, care stocheaza si indexeaza tot volumul de date, si un dashboard web, pe stack-ul OpenSearch Dashboards, de unde cauti, vizualizezi si configurezi alertarea.

De ce conteaza centralizarea, nu doar citirea jurnalelor pe fiecare masina

Cand ai un singur server, citirea manuala a jurnalelor e o solutie perfect rezonabila. Problema apare la scara: un atacator care se misca lateral printr-o retea lasa urme fragmentate pe mai multe masini, urme care, luate separat, par banale, dar care capata sens doar cand sunt puse cap la cap pe o singura axa de timp. Rotatia jurnalelor sterge dovezi inainte sa apuci sa le vezi, iar un auditor care cere dovada ca monitorizezi integritatea unui fisier de configurare nu se multumeste cu “da, ma uit din cand in cand”. Centralizarea telemetriei de securitate iti da un singur set de reguli aplicat uniform, o singura cronologie de evenimente si un singur loc unde apar alertele, indiferent pe care din cele 20 sau 200 de masini s-a intamplat ceva.

De la OSSEC la un stack XDR/SIEM complet

Wazuh are radacini in linia OSSEC, un instrument mai vechi, axat aproape exclusiv pe analiza de jurnale si detectie de intruziuni bazata pe reguli, rulat ca un binar relativ simplu langa un agent. Nevoile reale de securitate ale unei organizatii nu se opresc insa la “alerta-ma cand apare un cuvant suspect intr-un jurnal”: ai nevoie si de corelare cu vulnerabilitati cunoscute, de rapoarte de conformitate, de un tablou de bord cautabil pentru echipa de securitate si de o modalitate de a pune fiecare detectie in contextul unei tactici sau tehnici cunoscute de atac. Din aceasta nevoie s-a nascut stack-ul de azi: Wazuh a crescut de la un motor de detectie bazat pe jurnale la o platforma completa XDR/SIEM, cu propriul indexer si propriul dashboard.

Ce primesti din cutie

Instalarea de baza a Wazuh nu e un singur feature, e un pachet de capabilitati care acopera, luate impreuna, majoritatea cerintelor unui program de securitate operationala:

• Agenti pentru endpoint-uri si servere: procese usoare instalate pe fiecare masina monitorizata, care colecteaza jurnale, evenimente de sistem si informatii de inventar.
• File Integrity Monitoring (FIM): urmarirea modificarilor de continut, permisiuni, proprietar si atribute pentru fisierele si directoarele pe care le declari importante.
• Motor de analiza a jurnalelor: decodoare si reguli care transforma text brut din jurnale in evenimente clasificate si alerte cu prioritate.
• Detectie de intruziuni si rootkit-uri: cautare de fisiere ascunse, procese camuflate, listeneri de retea neinregistrati si inconsistente in raspunsurile apelurilor de sistem.
• Detectie de vulnerabilitati: inventarul software colectat de agenti e comparat cu baze de date actualizate de CVE-uri, ca sa afli ce pachete instalate au vulnerabilitati cunoscute.
• Evaluare de configuratie si conformitate: scanari periodice care compara setarile de sistem cu ghiduri de hardening, cu maparile catre standarde precum PCI DSS, GDPR sau HIPAA.
• Mapare pe MITRE ATT&CK: fiecare detectie relevanta poate fi legata de o tactica sau tehnica cunoscuta de atac, ceea ce iti da context imediat, nu doar un titlu de alerta.
• Indexer si dashboard: OpenSearch pentru stocare si cautare, plus o interfata web pentru vizualizare si configurarea alertarii.

Nu toate organizatiile au nevoie de tot ce e pe lista, dar valoarea reala vine din faptul ca aceste piese functioneaza impreuna, nu ca instrumente separate pe care trebuie sa le lipesti manual.

Instalare Wazuh pe un VPS

Wazuh nu e un binar unic pe care il pornesti si gata. E un stack cu mai multe componente (server, indexer, dashboard) plus agenti separati pe fiecare masina monitorizata. Cel mai practic mod de a-l ridica pe un VPS e printr-un docker compose, care porneste cele trei servicii centrale intr-o retea izolata:

git clone https://github.com/wazuh/wazuh-docker.git -b v4.9.0
cd wazuh-docker/single-node

# genereaza certificatele interne pentru comunicarea dintre componente
docker compose -f generate-indexer-certs.yml run --rm generator

# porneste stack-ul: wazuh-manager, wazuh-indexer, wazuh-dashboard
docker compose up -d

# verifica ca toate containerele sunt sanatoase
docker compose ps

Aceasta ridica serverul central, indexer-ul si dashboard-ul pe acelasi VPS. Agentul se instaleaza separat, pe fiecare masina de monitorizat (inclusiv, daca vrei, pe VPS-ul serverului), si se configureaza sa raporteze catre IP-ul serverului Wazuh.

Odata ce stack-ul e sus, mai ai de deschis porturile corecte in firewall. Dashboard-ul e servit HTTPS, iar serverul asculta pe porturi separate pentru agenti:

# acces la dashboard-ul web (HTTPS)
sudo ufw allow 443/tcp

# inregistrarea agentilor noi
sudo ufw allow 1515/tcp

# comunicarea curenta agent -> server
sudo ufw allow 1514/tcp

# API-ul serverului Wazuh (optional, pentru automatizari)
sudo ufw allow 55000/tcp

Pentru ca vorbim de un stack cu mai multe servicii, dimensionarea VPS-ului conteaza mult mai mult decat la un utilitar simplu de linia de comanda: indexer-ul, fiind construit pe OpenSearch, vrea memorie reala, iar CPU-ul si spatiul de disc cresc direct proportional cu numarul de agenti si volumul de jurnale ingerate. Un VPS subdimensionat pentru cateva zeci de agenti devine rapid punctul in care dashboard-ul incepe sa raspunda greu si indexarea ramane in urma.

Tipare de configurare care merita stiute

Tunarea FIM ca sa urmaresti caile potrivite, nu tot sistemul de fisiere

Tentatia initiala e sa pui File Integrity Monitoring sa urmareasca tot: /etc, /usr/bin, /var/www, poate chiar /home intreg. Rezultatul e un volum de alerte in care semnalul real (o modificare neasteptata intr-un fisier de configurare critic) se pierde in zgomotul normal (un deploy care rescrie zilnic zeci de fisiere). Merita sa pornesti restrans: cai de configuratie de sistem, binare critice, fisiere de autentificare, si sa extinzi lista treptat, pe masura ce intelegi ce e normal in mediul tau.

Alegerea si scrierea decodoarelor si regulilor pentru sursele tale reale de jurnale

Wazuh vine cu un set generos de decodoare si reguli pentru software comun (nginx, sshd, sisteme de baza), dar orice aplicatie interna sau stack mai neobisnuit are nevoie de decodoare proprii ca sa transforme jurnalele in evenimente utile. Timpul investit aici e cel care face diferenta intre un SIEM care iti spune ceva concret si unul care doar arhiveaza text pe care nimeni nu-l citeste.

Foloseste maparile de conformitate ca punct de plecare, nu ca certificare

Maparile catre PCI DSS, GDPR sau HIPAA sunt utile ca lista de verificare initiala si ca dovada pentru auditori ca ai un proces de monitorizare activ, dar nu inlocuiesc un audit de conformitate propriu-zis, facut de cineva calificat. Trateaza-le ca un punct de start solid, nu ca o cutie bifata definitiv.

Dimensioneaza indexer-ul pentru volumul tau real de jurnale si perioada de retentie

OpenSearch, motorul din spatele indexer-ului, e componenta care simte cel mai tare cresterea numarului de agenti si a volumului de jurnale. Retentia pe care o alegi (cate zile sau luni pastrezi datele indexate) inmultita cu evenimentele pe zi iti da direct necesarul de disc, iar cautarile pe un volum mare de date nesegmentat corect devin lente. Gandeste-te la retentie si sharding din prima zi, nu dupa ce indexer-ul incepe sa gafaie.

Unde Wazuh nu e raspunsul potrivit

Onest, Wazuh e overkill pentru un singur VPS mic sau cateva proiecte personale. Un stack cu server, indexer si dashboard, fiecare cu propriile cerinte de memorie si CPU, e mult mai greu decat un utilitar unic care sta linistit in fundal. Daca tot ce ai e o masina si vrei doar sa stii cand cineva incearca brute-force pe SSH, exista instrumente mult mai usoare pentru exact acea nevoie.

Valoarea reala a Wazuh apare abia cand ai destule masini si destul volum de jurnale cat sa justifice o platforma centralizata, si o nevoie concreta de securitate sau conformitate care cere dovezi, nu doar “ma uit din cand in cand la loguri”. In plus, un SIEM nu se administreaza singur: are nevoie de tunare continua si de cineva care sa se uite efectiv la alerte, altfel devine exact genul de zgomot pe care il instalezi ca sa-l ignori. Un Wazuh instalat si uitat e mai rau decat niciun Wazuh, pentru ca da o falsa senzatie de siguranta.

Alternative pe care le-am luat in calcul

Wazuh nu e singura optiune, iar alegerea depinde mult de scara si de nevoia reala:

• CrowdSec : un IPS bazat pe comportament, mult mai usor decat Wazuh, potrivit pentru infrastructuri mai mici unde vrei detectie si blocare automata de atacuri comune (brute-force, scanari) fara un stack intreg de analiza si indexare.
• Elastic Stack / Elastic Security : o abordare de tip DIY SIEM, in care construiesti singur piesele (ingestie, indexare, reguli, vizualizare) folosind componentele Elastic. Flexibilitate mai mare, dar si mai multa munca de integrare.
• Graylog : o alternativa mai usoara, orientata pe managementul jurnalelor mai degraba decat pe un pachet complet de securitate cu FIM, detectie de vulnerabilitati si mapari de conformitate incluse din start.

Daca nevoia reala e blocarea automata a atacurilor comune pe cateva servere, CrowdSec e probabil suficient. Daca ai deja o cerinta de conformitate si o flota serioasa de servere, Wazuh iti da mai mult din cutie.

Deci, sa-l rulezi?

Wazuh e instrumentul potrivit atunci cand ai deja o infrastructura reala de monitorizat, o cerinta concreta de securitate sau conformitate, si resursa (umana si de server) sa il tii tunat si urmarit efectiv. Nu e instrumentul potrivit pentru un VPS de hobby sau un proiect personal cu doua masini, acolo greutatea stack-ului nu se justifica.

Daca esti in tabara in care Wazuh chiar are sens, primul pas practic e un VPS dimensionat corect pentru indexer si server, nu resturi de resurse ramase de la alte servicii. Iar pentru ca vorbim de un stack care cere tunare continua, nu doar o instalare initiala, administrarea profesionala a serverelor e adesea o investitie care merita facuta din prima zi, in loc sa descoperi la mijlocul unui incident real ca nimeni nu s-a uitat la dashboard de trei luni.