Instalare și Configurare Wazuh pe Linux: Ghid Complet de Detectare a Intruziunilor

Verificarea conectivității agent-manager

# Pe manager — verifică agenții conectați
sudo /var/ossec/bin/agent_control -l

# Output exemplu:
# ID: 001, Name: web-server-01, IP: 10.0.0.21, Status: Active
# ID: 002, Name: db-server-01, IP: 10.0.0.22, Status: Active

# Pe agent — verifică log-urile de conectare
sudo tail -f /var/ossec/logs/ossec.log | grep -i "connected"

Dacă agentul nu se conectează, verifică trei lucruri: (1) porturile 1514 și 1515 sunt deschise pe manager, (2) adresa IP a managerului e corectă în /var/ossec/etc/ossec.conf pe agent, (3) nu există reguli firewall care blochează traficul. De cele mai multe ori, e una din primele două cauze.

Monitorizarea integrității fișierelor (FIM)

File Integrity Monitoring e probabil cea mai valoroasă capabilitate a lui Wazuh pentru administratorii Linux. Și sincer, e și cea mai ușor de înțeles.

Modulul FIM creează un baseline al fișierelor monitorizate (hash-uri criptografice, permisiuni, proprietar, timestamps) și alertează la orice modificare. Dacă un atacator modifică un binar de sistem, plantează un backdoor sau schimbă configurația SSH — FIM detectează asta.

Moduri de monitorizare

Wazuh FIM suportă trei moduri, fiecare cu compromisuri diferite:

• Scheduled (programat) — scanare periodică completă a directoarelor monitorizate. Interval implicit: 12 ore. Overhead minim, dar detectarea poate întârzia.
• Real-time — folosește inotify pe Linux pentru notificări instantanee la modificare. Ideal pentru fișiere critice care necesită detectare imediată.
• Who-data — extinde real-time cu informații despre cine a făcut modificarea (user, proces, PID). Folosește subsistemul auditd sau eBPF pe Linux. Impactul pe performanță e ușor mai mare, dar informațiile de atribuire sunt invaluabile în investigații.

Configurare FIM pe agent

Editează fișierul de configurare al agentului (/var/ossec/etc/ossec.conf) și ajustează secțiunea <syscheck>:

<ossec_config>
  <syscheck>
    <!-- Frecvența scanărilor programate (în secunde) -->
    <frequency>3600</frequency>

    <!-- Directoare critice monitorizate în real-time -->
    <directories check_all="yes" realtime="yes">/etc</directories>
    <directories check_all="yes" realtime="yes">/usr/bin</directories>
    <directories check_all="yes" realtime="yes">/usr/sbin</directories>
    <directories check_all="yes" realtime="yes">/sbin</directories>
    <directories check_all="yes" realtime="yes">/bin</directories>

    <!-- Fișiere sensibile cu who-data pentru atribuire completă -->
    <directories check_all="yes" whodata="yes" report_changes="yes">/etc/ssh</directories>
    <directories check_all="yes" whodata="yes" report_changes="yes">/etc/passwd</directories>
    <directories check_all="yes" whodata="yes" report_changes="yes">/etc/shadow</directories>
    <directories check_all="yes" whodata="yes" report_changes="yes">/etc/sudoers</directories>
    <directories check_all="yes" whodata="yes" report_changes="yes">/etc/crontab</directories>

    <!-- Directoare web (dacă ai un server web) -->
    <directories check_all="yes" realtime="yes" report_changes="yes">/var/www</directories>

    <!-- Excluderi pentru a reduce zgomotul -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>
    <ignore type="sregex">.log$|.swp$</ignore>

    <!-- Alertare la fișiere noi create -->
    <alert_new_files>yes</alert_new_files>

    <!-- Who-data cu eBPF (Ubuntu 22.04+) -->
    <whodata>
      <provider>ebpf</provider>
      <queue_size>50000</queue_size>
    </whodata>
  </syscheck>
</ossec_config>

Atributul check_all="yes" activează toate verificările disponibile simultan: hash-uri MD5, SHA-1 și SHA-256, dimensiune, proprietar, grup, permisiuni, timp de modificare și inode. Atributul report_changes="yes" salvează și conținutul exact al modificărilor (diff) — foarte util pentru fișiere text precum configurații.

Testarea FIM

# Creează o modificare de test pe agent
echo "# test fim" | sudo tee -a /etc/ssh/sshd_config

# Verifică alertele pe manager
sudo tail -f /var/ossec/logs/alerts/alerts.json | python3 -m json.tool

# Sau verifică în dashboard-ul web:
# Security Events > File Integrity Monitoring

# Curăță modificarea de test
sudo sed -i '/# test fim/d' /etc/ssh/sshd_config

În dashboard, alerta va arăta exact ce s-a modificat, cine a făcut modificarea (dacă who-data e activ), procesul responsabil și timestamp-ul precis.

Detectarea rootkit-urilor și verificarea proceselor

Modulul rootcheck al Wazuh rulează automat la fiecare 2 ore (implicit) și verifică:

• Prezența rootkit-urilor cunoscute (baze de date de semnături)
• Fișiere ascunse la nivel de kernel
• Porturi ascunse sau neobișnuite
• Procese suspecte
• Anomalii în răspunsurile apelurilor de sistem

<!-- Configurare rootcheck în /var/ossec/etc/ossec.conf pe agent -->
<rootcheck>
  <disabled>no</disabled>
  <frequency>7200</frequency>

  <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
  <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>

  <!-- Verifică procesele ascunse -->
  <check_unixaudit>yes</check_unixaudit>
  <check_files>yes</check_files>
  <check_trojans>yes</check_trojans>
  <check_dev>yes</check_dev>
  <check_sys>yes</check_sys>
  <check_pids>yes</check_pids>
  <check_ports>yes</check_ports>
  <check_if>yes</check_if>
</rootcheck>

Dacă rootcheck detectează ceva suspect, va genera o alertă de nivel înalt (7+) care apare imediat în dashboard. Alertele cu nivel 7 sau mai mare necesită investigare — nu le ignora.

Analiza log-urilor în timp real

Wazuh analizează automat log-urile de sistem și aplică reguli de detecție pentru a identifica activități suspecte. Vine preinstalat cu peste 4.000 de reguli care acoperă autentificări eșuate, escaladare de privilegii, erori de servicii, activitate web suspectă și multe altele.

Configurarea surselor de log

<!-- Adaugă surse de log suplimentare în /var/ossec/etc/ossec.conf pe agent -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/syslog</location>
</localfile>

<!-- Log-uri nginx -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/nginx/access.log</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/nginx/error.log</location>
</localfile>

<!-- Log-uri audit (pentru who-data FIM) -->
<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

Exemple de reguli de detecție

Wazuh vine cu reguli pentru scenarii comune. Iată câteva categorii critice pe care le detectează automat:

• Regula 5710 — Tentativă de login SSH cu parolă inexistentă
• Regula 5712 — Brute force SSH (multiple eșuate de la aceeași IP)
• Regula 5501 — Login ca root
• Regula 5402 — Utilizator adăugat la un grup privilegiat
• Regula 550 — Modificare integritate fișiere detectată
• Regula 510 — Rootkit posibil detectat

Reguli personalizate

Poți adăuga reguli personalizate pe manager în /var/ossec/etc/rules/local_rules.xml:

<group name="custom_rules,">

  <!-- Alertă la orice modificare a fișierului sudoers -->
  <rule id="100010" level="12">
    <if_sid>550</if_sid>
    <field name="file">/etc/sudoers</field>
    <description>Fișierul sudoers a fost modificat — verificare imediată necesară</description>
    <group>syscheck,pci_dss_10.5.5,</group>
  </rule>

  <!-- Alertă la crearea unui nou utilizator -->
  <rule id="100011" level="10">
    <if_sid>5902</if_sid>
    <description>Cont de utilizator nou creat pe sistem</description>
    <group>authentication,pci_dss_10.2.5,</group>
  </rule>

  <!-- Alertă la conexiuni SSH de la IP-uri neobișnuite -->
  <rule id="100012" level="10">
    <if_sid>5715</if_sid>
    <srcip negate="yes">10.0.0.0/8|192.168.0.0/16</srcip>
    <description>Login SSH reușit de la IP extern — posibil neautorizat</description>
    <group>authentication,</group>
  </rule>

</group>

După adăugarea regulilor, repornește Wazuh Manager:

sudo systemctl restart wazuh-manager

Răspunsul activ (Active Response)

Active Response e mecanismul prin care Wazuh nu doar detectează amenințări, ci și reacționează automat. Cel mai comun caz de utilizare: blocarea automată a IP-urilor care generează atacuri brute force pe SSH. Și e chiar satisfăcător să vezi cum funcționează în practică.

Configurare Active Response pe manager

Editează /var/ossec/etc/ossec.conf pe Wazuh Manager:

<ossec_config>
  <!-- Definește comanda de blocare -->
  <command>
    <name>firewall-drop</name>
    <executable>firewall-drop</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <!-- Răspuns activ: blochează IP la brute force SSH -->
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5712</rules_id>
    <timeout>1800</timeout>
    <!-- IP-ul va fi blocat pentru 30 minute (1800 secunde) -->
  </active-response>

  <!-- Răspuns activ: blochează IP la scanare de porturi -->
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5706</rules_id>
    <timeout>3600</timeout>
  </active-response>

  <!-- IP-uri excluse din blocarea automată (nu bloca administratorii!) -->
  <global>
    <white_list>10.0.0.0/8</white_list>
    <white_list>192.168.1.0/24</white_list>
  </global>
</ossec_config>

Atenție importantă: Configurează întotdeauna un whitelist cu IP-urile tale de administrare! Am văzut cazuri (și sincer, am pățit-o o dată) în care administratori s-au blocat singuri din sisteme pentru că și-au greșit parola SSH de câteva ori, iar Active Response le-a blocat IP-ul. Nu e o experiență plăcută, mai ales la 3 dimineața în timpul unui incident.

Testarea răspunsului activ

# De pe o mașină de test (NU de pe IP-ul tău de administrare!):
# Simulează tentative eșuate de login SSH
for i in $(seq 1 10); do
  ssh invalid_user@IP_SERVER_MONITORIZAT
done

# Pe server, verifică dacă IP-ul a fost blocat
sudo iptables -L -n | grep DROP
# sau cu nftables:
sudo nft list ruleset | grep "drop"

# Verifică log-urile active response
sudo tail -f /var/ossec/logs/active-responses.log

Integrarea FIM cu scanarea malware (YARA)

Acum vine o parte cu adevărat interesantă: integrarea Wazuh FIM cu YARA pentru scanarea automată a fișierelor noi sau modificate. Practic, când FIM detectează o modificare într-un director monitorizat, Wazuh poate rula automat o scanare YARA pe fișierul respectiv.

Instalarea YARA pe agentul Linux

# Debian/Ubuntu
sudo apt install -y yara

# RHEL/AlmaLinux
sudo dnf install -y yara

# Verifică instalarea
yara --version

Scriptul de răspuns activ YARA

Creează scriptul pe agent la /var/ossec/active-response/bin/yara.sh:

#!/bin/bash
# Script Active Response — scanare YARA la modificări FIM

LOCAL=$(dirname $0)
cd $LOCAL
cd ../

PWD=$(pwd)
LOG_FILE="${PWD}/../logs/active-responses.log"
YARA_PATH="/usr/bin/yara"
YARA_RULES="/var/ossec/etc/rules/yara_rules/malware_index.yar"

read INPUT_JSON
FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path)

if [[ ! $FILENAME ]]; then
  echo "$(date) — Eroare: Cale fișier lipsă" >> ${LOG_FILE}
  exit 1
fi

# Rulează scanarea YARA
YARA_OUTPUT=$("${YARA_PATH}" "${YARA_RULES}" "${FILENAME}" 2>/dev/null)

if [[ $YARA_OUTPUT ]]; then
  # Fișierul a fost identificat ca malware
  echo "$(date) — YARA MATCH: ${YARA_OUTPUT}" >> ${LOG_FILE}

  # Opțional: mută fișierul în carantină
  QUARANTINE_DIR="/var/ossec/quarantine"
  mkdir -p "${QUARANTINE_DIR}"
  mv "${FILENAME}" "${QUARANTINE_DIR}/"
  echo "$(date) — Fișier mutat în carantină: ${FILENAME}" >> ${LOG_FILE}
fi

exit 0

# Setează permisiunile corecte
sudo chmod 750 /var/ossec/active-response/bin/yara.sh
sudo chown root:wazuh /var/ossec/active-response/bin/yara.sh

Această integrare transformă Wazuh dintr-un simplu detector de modificări într-un sistem activ de prevenire a malware-ului. Fiecare fișier nou creat sau modificat în directoarele monitorizate va fi scanat automat cu regulile YARA — ceea ce e un upgrade serios față de monitorizarea pasivă.

Evaluarea vulnerabilităților integrată

Wazuh include un modul de evaluare a vulnerabilităților care scanează pachetele instalate pe fiecare agent și le compară cu baze de date CVE actualizate. Nu mai ai nevoie de instrumente separate precum Nessus sau OpenVAS pentru o vizibilitate de bază asupra vulnerabilităților.

Activarea modulului pe manager

<!-- În /var/ossec/etc/ossec.conf pe Wazuh Manager -->
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

După activare, verifică în dashboard la secțiunea Vulnerability Detection. Vei vedea o listă de CVE-uri care afectează pachetele instalate pe fiecare agent, grupate după severitate (Critical, High, Medium, Low).

# Verifică starea modulului de vulnerabilități
sudo /var/ossec/bin/wazuh-control info | grep vulnerability

# Listează vulnerabilitățile detectate prin API
curl -k -u admin:PAROLA_TA \
  "https://localhost:55000/vulnerability?pretty&limit=10&sort=-severity"

Notificări și integrare cu sisteme externe

Alertele Wazuh nu-s utile dacă nimeni nu le vede. Configurează notificări pentru a te asigura că echipa e informată în timp real.

Notificări email

<!-- În /var/ossec/etc/ossec.conf pe Wazuh Manager -->
<global>
  <email_notification>yes</email_notification>
  <smtp_server>smtp.exemplu.ro</smtp_server>
  <email_from>[email protected]</email_from>
  <email_to>[email protected]</email_to>
  <email_maxperhour>12</email_maxperhour>
</global>

<!-- Alertă email doar pentru niveluri 10+ (severitate ridicată) -->
<alerts>
  <email_alert_level>10</email_alert_level>
  <log_alert_level>3</log_alert_level>
</alerts>

Integrare cu Slack

<!-- Integrare Slack pentru alerte în timp real -->
<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Monitorizarea conformității (Compliance)

Wazuh mapează automat alertele pe standarde de conformitate. Asta înseamnă că, fără configurare suplimentară, ai deja o vizibilitate de bază asupra conformității cu:

• PCI DSS — Payment Card Industry Data Security Standard (cerința 10.5.5 pentru monitorizarea integrității fișierelor, cerința 11.4 pentru detecție intruziuni)
• HIPAA — Health Insurance Portability and Accountability Act
• GDPR — Articolul 32 privind securitatea procesării datelor personale
• NIST 800-53 — SI-7 (integritatea software-ului și informațiilor), AU-6 (revizuirea auditului)
• CIS Benchmarks — verificări automate ale configurării conform ghidurilor CIS

În dashboard-ul Wazuh, secțiunea Compliance afișează un scor global și detalii pe fiecare standard. Pentru audituri, poți genera rapoarte PDF direct din interfață — ceea ce face viața mult mai ușoară când vine vorba de auditori.

Bune practici operaționale

Instalarea Wazuh e doar începutul. Iată ce trebuie să faci pentru a-l menține eficient pe termen lung.

1. Ajustarea nivelurilor de alertare

Concentrează-te pe alertele de nivel 7+. Alertele de nivel 1-6 sunt informative și pot genera mult zgomot. Dacă primești prea multe alerte false pozitive, ajustează regulile — nu dezactiva modulele întregi. E tentant, dar o să regreți.

2. Sincronizarea timpului

Toate serverele (manager și agenți) trebuie să aibă timpul sincronizat prin NTP. Fără sincronizare, corelarea evenimentelor între agenți devine practic imposibilă.

# Verifică sincronizarea NTP
timedatectl status

# Dacă nu este sincronizat:
sudo systemctl enable systemd-timesyncd
sudo systemctl start systemd-timesyncd

3. Retenția datelor

Wazuh Indexer stochează alertele în indici OpenSearch. Configurează o politică de retenție pentru a preveni umplerea discului:

# Vizualizează dimensiunea indecșilor
curl -k -u admin:PAROLA_TA "https://localhost:9200/_cat/indices?v&s=store.size:desc"

# Șterge indecși mai vechi de 90 de zile (ajustează după necesități)
curl -k -u admin:PAROLA_TA -X DELETE \
  "https://localhost:9200/wazuh-alerts-4.x-2026.01.*"

4. Backup-ul configurării

# Script simplu de backup Wazuh
#!/bin/bash
BACKUP_DIR="/opt/wazuh-backup/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"

# Configurare manager
cp -r /var/ossec/etc/ "$BACKUP_DIR/etc/"
# Reguli personalizate
cp -r /var/ossec/etc/rules/local_rules.xml "$BACKUP_DIR/"
# Decodere personalizate
cp -r /var/ossec/etc/decoders/local_decoder.xml "$BACKUP_DIR/"
# Lista de agenți
cp /var/ossec/etc/client.keys "$BACKUP_DIR/"

echo "Backup completat: $BACKUP_DIR"

5. Actualizări regulate

Urmărește release notes Wazuh și aplică actualizările de securitate. Versiunea curentă, 4.14.4, a rezolvat probleme de securitate privind buffer underflow-uri și formate de timestamp inconsistente. Actualizează mai întâi managerul, apoi agenții — niciodată invers. Ordinea contează.

Întrebări frecvente

Ce resurse hardware necesită Wazuh pe un server Linux?

Pentru o instalare all-in-one cu până la 50 de agenți, ai nevoie de minim 4 nuclee CPU, 8 GB RAM și 50 GB spațiu pe disk SSD. Pentru implementări mai mari (100+ agenți), recomandarea e 8 nuclee, 16 GB RAM și arhitectură distribuită cu componente separate pe servere dedicate. Consumul de resurse al agentului pe endpoint-uri e minimal — sub 100 MB RAM și impact neglijabil pe CPU.

Pot folosi Wazuh împreună cu Fail2Ban pe același server?

Da, dar nu e necesar. Active Response din Wazuh oferă funcționalitate similară cu Fail2Ban — blocarea automată a IP-urilor care generează atacuri brute force. Dacă rulezi ambele, asigură-te că nu există conflicte în regulile de firewall. Recomandarea mea: folosește exclusiv Active Response din Wazuh și dezactivează Fail2Ban pe serverele unde ai agent Wazuh, ca să eviți duplicarea și conflictele.

Cât de repede detectează Wazuh o modificare neautorizată a unui fișier?

Depinde de modul de monitorizare configurat. În modul real-time sau who-data, detectarea e aproape instantanee (sub 1 secundă) deoarece folosește inotify sau eBPF din kernelul Linux. În modul scheduled (programat), detectarea are loc la următoarea scanare — intervalul implicit e de 12 ore, dar poți reduce la 1 oră sau chiar mai puțin pentru directoare critice.

Wazuh funcționează cu containere Docker și Kubernetes?

Da. Wazuh suportă monitorizarea containerelor Docker prin modulul dedicat docker-listener care detectează pornirea, oprirea și modificarea containerelor. Pentru Kubernetes, poți instala agentul Wazuh ca DaemonSet pe fiecare nod din cluster. Alertele includ metadata Kubernetes (pod name, namespace, labels) pentru context suplimentar. De asemenea, Wazuh poate fi instalat el însuși ca stack containerizat folosind Docker Compose sau Helm charts oficiale.

Cum integrez Wazuh într-un pipeline DevSecOps existent?

Wazuh oferă un RESTful API complet pe portul 55000 care permite integrarea cu orice sistem de automatizare. Poți interoga alerte, gestiona agenți și configura reguli programatic. Cele mai comune integrări: Slack/Teams pentru notificări, Jira/ServiceNow pentru crearea automată de tickete la alerte de severitate ridicată, și pipeline-uri CI/CD care verifică starea de vulnerabilitate a serverelor înainte de deployment.