Wazuh è oggi la piattaforma open source SIEM e XDR più adottata dalle organizzazioni che cercano una soluzione di monitoraggio della sicurezza senza costi di licenza. Con 1.900 ricerche mensili in Italia e una crescita del 26% anno su anno, il numero di team IT e SOC che la adottano continua ad accelerare. La versione 4.14.5, rilasciata il 23 aprile 2026, introduce miglioramenti significativi al rilevamento delle vulnerabilità e all’integrazione con le normative europee come NIS2 e GDPR.

Questa guida ti mostra come installare, configurare e ottimizzare Wazuh su Ubuntu 22.04/24.04 LTS in 12 step operativi, con esempi di codice pronti da usare, configurazioni FIM, regole personalizzate e un riferimento completo per il troubleshooting. Alla fine avrai un ambiente di monitoraggio funzionale, con agenti connessi e alert attivi.

Cosa è Wazuh: SIEM, XDR e Perché lo Scelgono le Aziende Europee

Wazuh è una piattaforma di sicurezza open source che unifica le capacità SIEM (Security Information and Event Management) e XDR (Extended Detection and Response) in un unico ecosistema senza costi di licenza. Nata come fork di OSSEC nel 2015, si è evoluta in una soluzione matura basata su OpenSearch per l’archiviazione e l’indicizzazione degli eventi di sicurezza.

Perché scelgono Wazuh le aziende europee nel 2026? Prima di tutto per la conformità normativa integrata: il motore di regole include mapping per PCI-DSS, HIPAA, GDPR e MITRE ATT&CK, tre standard centrali per le organizzazioni che operano nel mercato UE. In secondo luogo per l’architettura scalabile: si parte da una singola macchina virtuale per ambienti di test e si arriva a cluster multi-nodo per ambienti enterprise con migliaia di endpoint. Terzo, il modello open source garantisce trasparenza del codice, audit indipendenti e nessun lock-in con vendor proprietari.

SmarTech-IT, partner italiano di Wazuh, descrive la piattaforma come il principale strumento per “sicurezza, conformità e resilienza per le organizzazioni europee” nell’era post-NIS2. Il fatto che Wazuh abbia ricevuto il “Best Cloud Security Platform” award agli Hackernews Cybersecurity Stars Awards 2026 conferma il riconoscimento del settore.

Prerequisiti: Versioni, Hardware e Porte

Prima di iniziare l’installazione, verifica che il tuo ambiente soddisfi i requisiti minimi. Wazuh 4.14.5 supporta sistemi operativi a 64 bit con architettura x86_64/AMD64 o AARCH64/ARM64. Per Ubuntu, le versioni testate e supportate sono 16.04, 18.04, 20.04, 22.04 e 24.04 LTS.

ComponenteRAM MinimaCPU MinimaRAM RaccomandataCPU Raccomandata
Wazuh Manager2 GB2 core4 GB8 core
Wazuh Indexer4 GB2 core8 GB4 core
Wazuh Dashboard4 GB2 core8 GB4 core
Wazuh Agent256 MB1 core512 MB1 core
All-in-One (test)4 GB2 core8 GB4 core

Per il dimensionamento del disco, Wazuh usa un modello basato sugli Alert Per Second (APS). In un ambiente con 80 workstation, 10 server e 10 dispositivi di rete, lo storage necessario per 90 giorni di alert sul Wazuh server è circa 6 GB. Per ambienti più grandi, pianifica circa 0.2 GB per dispositivo di rete e proporzionalmente di più per server attivi.

Le porte di rete che devono essere aperte sul firewall:

PortaProtocolloComponenteUtilizzo
1514TCP/UDPManagerRicezione eventi dagli agenti
1515TCPManagerRegistrazione e enrollment agenti
55000TCPManagerAPI REST di Wazuh
9200TCPIndexerAPI HTTP di OpenSearch
9300TCPIndexerComunicazione cluster OpenSearch
443TCPDashboardInterfaccia web HTTPS

Software necessario prima dell’installazione: accesso root o sudo, connessione Internet stabile per scaricare i pacchetti, curl installato (apt-get install curl -y), e le porte sopra elencate aperte nel firewall. Se usi un cloud provider (AWS, Azure, GCP, Hetzner), configura i security group prima di procedere.

Architettura di Wazuh: I 4 Componenti Principali

Comprendere l’architettura di Wazuh è fondamentale per installarlo correttamente e per diagnosticare problemi in produzione. La piattaforma si divide in quattro componenti distinti che comunicano tra loro.

Il Wazuh Manager è il cuore del sistema. Riceve la telemetria dagli agenti, analizza i log, applica le regole di correlazione e invia alert. Gestisce anche le risposte attive automatizzate quando rileva minacce. È il processo che gira su /var/ossec/ e si controlla con systemctl.

Il Wazuh Indexer (basato su OpenSearch) archivia e indicizza tutti i dati di sicurezza. È il motore di ricerca che permette query veloci su milioni di eventi. In ambienti di produzione puoi configurarlo come cluster multi-nodo per alta disponibilità.

Il Wazuh Dashboard è l’interfaccia web che i SOC analyst usano quotidianamente. Visualizza alert, vulnerabilità, conformità, permette query avanzate sui log e supporta la creazione di dashboard personalizzate. Si accede via HTTPS sulla porta 443.

Il Wazuh Agent è il componente leggero installato sugli endpoint da monitorare. Raccoglie log di sistema, monitora l’integrità dei file, analizza i processi attivi, inventaria il software installato e rileva vulnerabilità. Supporta Linux, Windows, macOS, AIX, Solaris e altri sistemi operativi. Una volta installato, l’agente si connette al manager sulla porta 1514 per inviare eventi in tempo reale.

Step 1: Aggiornare il Sistema Ubuntu

Inizia sempre con un sistema aggiornato. Pacchetti obsoleti possono causare conflitti di dipendenze durante l’installazione di Wazuh e introducono rischi di sicurezza che il SIEM stesso dovrebbe rilevare.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install curl apt-transport-https gnupg -y

Dopo l’aggiornamento, verifica che il sistema abbia il nome host correttamente configurato. Wazuh usa il hostname per identificare il server nel cluster:

hostnamectl set-hostname wazuh-server
echo "127.0.1.1 wazuh-server" | sudo tee -a /etc/hosts

Pitfall #1: Non saltare il riavvio se il kernel è stato aggiornato. Un mismatch tra kernel in esecuzione e moduli kernel aggiornati può causare problemi con le funzionalità di auditing del sistema usate da Wazuh FIM.

Step 2: Scaricare e Lanciare l’Installation Assistant

Wazuh fornisce uno script di installazione assistita che automatizza il setup dell’intero stack (Manager, Indexer, Dashboard) su un singolo nodo. Questo è il metodo raccomandato per ambienti di test, lab e deployment SME.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

L’opzione -a lancia l’installazione all-in-one. Lo script installa automaticamente il Wazuh manager, l’indexer OpenSearch e il dashboard, configura i certificati SSL auto-firmati e genera le credenziali di accesso. L’installazione richiede circa 10-15 minuti su una macchina con connessione standard.

Al termine dell’installazione, lo script stampa le credenziali di accesso al dashboard direttamente nel terminale:

INFO: --- Summary ---
INFO: You can access the web interface https://<wazuh-dashboard-ip>
    User: admin
    Password: <password-generata>

INFO: Installation finished.

Importante: salva queste credenziali in un password manager prima di procedere. Se le perdi, puoi recuperarle con il comando sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt, ma solo se l’archivio generato dallo script è ancora presente.

Pitfall #2: Non eseguire l’installation assistant come utente non-root senza sudo. Lo script richiede permessi elevati per installare pacchetti di sistema e configurare i servizi systemd. Se lo esegui come utente normale senza sudo, fallirà silenziosamente su alcune operazioni.

Step 3: Verificare i Servizi e Accedere al Dashboard

Dopo l’installazione, verifica che tutti i servizi siano attivi e in esecuzione:

sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

# Output atteso per ogni servizio:
# ● wazuh-manager.service - Wazuh manager
#    Loaded: loaded (/usr/lib/systemd/system/wazuh-manager.service)
#    Active: active (running) since ...

Se un servizio non risulta attivo, controlla i log con journalctl -u wazuh-manager --since "10 minutes ago". Il problema più comune nelle prime installazioni è la mancanza di memoria RAM sufficiente per l’indexer OpenSearch.

Apri il browser e naviga su https://<IP-del-server>. Riceverai un avviso di sicurezza del browser perché Wazuh usa certificati auto-firmati: procedi comunque per gli ambienti di test. In produzione, configura un certificato valido da Let’s Encrypt o dalla tua CA aziendale.

Effettua il login con le credenziali stampate a terminale. La schermata principale mostra il dashboard di overview con il numero di agenti connessi (inizialmente zero), gli alert recenti e i moduli di sicurezza attivi.

Pitfall #3: Non ignorare l’avviso del browser in produzione. Un certificato auto-firmato in un ambiente produttivo espone il traffico di gestione a potenziali attacchi man-in-the-middle. Configura TLS con un certificato valido prima di connettere agenti di produzione.

Step 4: Installare il Wazuh Agent su Linux

Con il server operativo, puoi iniziare ad aggiungere agenti sugli endpoint da monitorare. Il processo di installazione dell’agente su Ubuntu/Debian avviene tramite il repository Wazuh.

Sul nodo endpoint (non sul server Wazuh), esegui:

# Aggiungi la chiave GPG e il repository Wazuh
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
chmod 644 /usr/share/keyrings/wazuh.gpg

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | sudo tee /etc/apt/sources.list.d/wazuh.list

# Installa il pacchetto agente
sudo apt-get update
sudo WAZUH_MANAGER="<IP-DEL-TUO-SERVER-WAZUH>" apt-get install wazuh-agent -y

La variabile d’ambiente WAZUH_MANAGER configurata durante l’installazione imposta automaticamente l’indirizzo del manager nel file di configurazione dell’agente. Avvia e abilita il servizio:

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

# Verifica lo stato
sudo systemctl status wazuh-agent

Installazione su Windows: per gli endpoint Windows, scarica il file MSI dal repository Wazuh (https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi) ed eseguilo con i parametri:

msiexec /i wazuh-agent-4.14.5-1.msi WAZUH_MANAGER="192.168.1.100" /q

Pitfall #4: Non dimenticare di disabilitare il repository Wazuh dopo l’installazione. La documentazione ufficiale raccomanda di eseguire sudo sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/wazuh.list && sudo apt-get update per evitare aggiornamenti automatici accidentali che potrebbero rompere la configurazione.

Step 5: Verificare la Connessione degli Agenti

Dopo aver installato uno o più agenti, torna sul server Wazuh per verificarne la connessione. Dal terminale del server:

# Lista tutti gli agenti connessi
sudo /var/ossec/bin/agent_control -lc

# Output di esempio:
# Wazuh agent_control. List of active agents:
#    ID: 001, Name: ubuntu-web-01, IP: 192.168.1.10, Active/Local

# Verifica lo stato di un agente specifico (ID 001)
sudo /var/ossec/bin/agent_control -i 001

Puoi anche verificare gli agenti dalla dashboard web: vai su Agents nel menu laterale. Ogni agente appare con il suo stato (Active, Disconnected, Never connected), l’OS, la versione del software e l’ultima attività registrata.

Se un agente appare come “Never connected”, controlla:

1. Il firewall dell’agente permette connessioni uscenti sulla porta 1514 verso il server Wazuh
2. Il firewall del server permette connessioni entranti sulla porta 1514
3. Il file /var/ossec/etc/ossec.conf dell’agente contiene l’IP corretto del manager
4. Il servizio wazuh-agent è in esecuzione sull’endpoint (systemctl status wazuh-agent)

Step 6: Configurare il File Integrity Monitoring (FIM)

Il File Integrity Monitoring (FIM) è una delle funzionalità più potenti di Wazuh. Monitora in tempo reale le modifiche a file e directory critiche del sistema, generando alert quando file vengono creati, modificati o eliminati. È essenziale per rilevare compromissioni di sistema, malware e modifiche non autorizzate.

La configurazione FIM si trova nel file /var/ossec/etc/ossec.conf sia sul manager (per la configurazione globale) che sull’agente. La sezione di riferimento è <syscheck>:

<syscheck>
  <disabled>no</disabled>

  <!-- Frequenza di scansione in secondi (default: 43200 = 12 ore) -->
  <frequency>7200</frequency>

  <!-- Scansione all'avvio del servizio -->
  <scan_on_start>yes</scan_on_start>

  <!-- Directory da monitorare in tempo reale -->
  <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">/bin</directories>
  <directories check_all="yes" realtime="yes">/sbin</directories>
  <directories check_all="yes" realtime="yes">/var/www</directories>

  <!-- File da ignorare (cambiano frequentemente, genererebbero falsi positivi) -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/mail/statistics</ignore>
  <ignore>/etc/random-seed</ignore>
  <ignore>/etc/adjtime</ignore>
  <ignore>/etc/resolv.conf</ignore>

  <!-- Genera alert per file eliminati -->
  <alert_new_files>yes</alert_new_files>
</syscheck>

Dopo aver modificato il file di configurazione, riavvia il manager per applicare le modifiche:

sudo systemctl restart wazuh-manager

# Forza una scansione FIM immediata su un agente specifico
sudo /var/ossec/bin/agent_control -r -u 001

Pitfall #5: Non abilitare il monitoraggio in tempo reale (realtime="yes") su directory molto attive come /tmp o /var/log. Genera un volume di alert talmente elevato da rendere impossibile il triaging. Usa la modalità real-time solo per directory critiche e limita le scansioni periodiche per directory a maggiore attività.

Step 7: Attivare il Rilevamento delle Vulnerabilità

Il modulo di Vulnerability Detection di Wazuh analizza i pacchetti software installati sugli endpoint e li confronta con le CVE pubblicate nei database di vulnerabilità. In un singolo dashboard puoi vedere quali endpoint hanno software vulnerabile e qual è la severity di ogni CVE.

Dalla dashboard, naviga su Threat Intelligence > Vulnerability Detection. Clicca sulla scheda Inventory per vedere tutti i pacchetti monitorati. Puoi filtrare per nome pacchetto: ad esempio, inserisci package.name con operatore is e valore openssl per trovare tutti gli endpoint con OpenSSL installato e verificare se sono sulla versione sicura.

Per abilitare o personalizzare la frequenza delle scansioni di vulnerabilità, modifica la sezione <vulnerability-detection> in /var/ossec/etc/ossec.conf sul manager:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Il parametro feed-update-interval controlla ogni quanto Wazuh aggiorna i feed CVE dai database pubblici (NVD, OVAL, etc.). Il valore di default è 60 minuti, un buon equilibrio tra freschezza dei dati e carico di rete.

Capire i Livelli di Severity nelle CVE

Wazuh classifica le vulnerabilità usando lo standard CVSS (Common Vulnerability Scoring System). Gli alert di vulnerabilità vengono categorizzati in quattro livelli: Critical (CVSS 9.0-10.0), High (7.0-8.9), Medium (4.0-6.9) e Low (0.1-3.9). Un filtro utile nella dashboard è ordinare per severity decrescente e applicare il filtro su agenti di produzione specifici, per triagare prima le vulnerabilità critiche sui sistemi esposti.

Step 8: Creare Regole Personalizzate

Wazuh include migliaia di regole predefinite per rilevare attività sospette su Linux, Windows, applicazioni web, database e servizi cloud. Puoi però aggiungere regole personalizzate per rispondere alle esigenze specifiche del tuo ambiente, senza modificare le regole di sistema che verrebbero sovrascritte da un aggiornamento.

Le regole personalizzate vanno inserite nel file /var/ossec/etc/rules/local_rules.xml. Gli ID delle regole custom devono essere superiori a 100000 per non collidere con quelle built-in:

<group name="local,syslog,">

  <!-- Alert livello 10 per tentativi SSH ripetuti da un IP non in whitelist -->
  <rule id="100100" level="10">
    <if_matched_sid>5720</if_matched_sid>
    <same_source_ip />
    <options>no_full_log</options>
    <description>Multipli tentativi SSH falliti dallo stesso IP</description>
    <group>authentication_failures,</group>
  </rule>

  <!-- Alert per accesso sudo da utente non privilegiato -->
  <rule id="100101" level="8">
    <if_sid>5402</if_sid>
    <description>Comando sudo eseguito da account non autorizzato</description>
    <group>sudo,</group>
  </rule>

  <!-- Alert per modifica al file /etc/passwd -->
  <rule id="100102" level="12">
    <if_sid>550</if_sid>
    <match>/etc/passwd</match>
    <description>File /etc/passwd modificato - possibile aggiunta account non autorizzato</description>
    <group>fim,pci_dss_11.5,gdpr_IV_35.7.d,</group>
  </rule>

</group>

I livelli delle regole vanno da 0 a 15. Livelli 7-9 indicano attività di sicurezza rilevanti, 10-12 attività ad alto rischio, 13-15 attività critiche. Dopo aver aggiunto regole, verifica la sintassi prima del riavvio:

sudo /var/ossec/bin/wazuh-logtest

# Testa una regola simulando un input di log
# Incolla un log di esempio e premi invio - Wazuh mostra quale regola si attiva

Pitfall #6: Non assegnare livelli troppo alti (12+) a regole che si attivano frequentemente. Wazuh può configurarsi per inviare notifiche email o attivare risposte automatiche sopra una certa soglia di livello. Regole molto aggressive con livelli alti creano alert fatigue e possono innescare risposte automatizzate non volute (come bloccare IP legittimi).

Step 9: Configurare le Risposte Attive

Le Active Response di Wazuh permettono di automatizzare le contromisure quando un alert viene triggerato. L’esempio classico è bloccare un IP che ha tentato un brute force SSH. La configurazione avviene in due sezioni di /var/ossec/etc/ossec.conf: la definizione del comando e la definizione della risposta.

<!-- Definizione del comando: usa iptables per bloccare un IP -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Risposta attiva: esegui il blocco quando la regola 5763 si attiva 3+ volte in 120 secondi -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>600</timeout>
</active-response>

Il parametro timeout indica per quanti secondi l’IP rimane bloccato (600 = 10 minuti). Dopo questo periodo, Wazuh rimuove automaticamente la regola iptables. Puoi anche impostare timeout a 0 per un blocco permanente, ma richiede intervento manuale per sbloccare.

Per vedere tutte le risposte attive eseguite, controlla il log:

sudo tail -f /var/ossec/logs/active-responses.log

Pitfall #7: Non attivare le active response senza testare prima in un ambiente non produttivo. Una regola configurata male può bloccare IP legittimi, incluso il tuo indirizzo di gestione. Prima di abilitare il blocco automatico, usa la modalità <location>defined-agent</location> su un singolo agente di test.

Step 10: Configurare gli Alert Email

Wazuh può inviare notifiche email per alert che superano una determinata soglia di livello. La configurazione SMTP va nella sezione <global> di /var/ossec/etc/ossec.conf:

<global>
  <email_notification>yes</email_notification>
  <smtp_server>smtp.tua-azienda.it</smtp_server>
  <email_from>[email protected]</email_from>
  <email_to>[email protected]</email_to>
  <email_maxperhour>12</email_maxperhour>
</global>

<alerts>
  <!-- Invia email solo per alert di livello 10 o superiore -->
  <email_alert_level>10</email_alert_level>
</alerts>

Il parametro email_maxperhour limita il numero di email inviate per ora, prevenendo spam in caso di attacchi intensivi. Per ambienti con molti agenti, considera l’integrazione con sistemi di ticketing (Jira, ServiceNow) o canali Slack/Teams tramite le integrazioni webhook disponibili nel menu Server Management > Settings della dashboard.

Step 11: Configurare la Conformità Normativa (GDPR, NIS2, PCI-DSS)

Wazuh è uno degli strumenti più usati dai team di compliance europei per dimostrare l’adeguamento alla Direttiva NIS2 e al GDPR. Il motore di regole include mapping espliciti verso i requisiti di questi standard, visibili nei tag delle regole (come gdpr_IV_35.7.d nell’esempio di custom rule sopra).

Dalla dashboard, il modulo Security Operations > IT Hygiene mostra lo stato di conformità per ogni endpoint. Le schede disponibili coprono: System, Software, Processes, Network, Identity, Services e un Dashboard overview. Ogni sezione mostra i dati raccolti dagli agenti e i deviazioni rispetto alle policy definite.

Per generare un report di conformità PCI-DSS:

1. Vai su Regulatory Compliance > PCI DSS
2. Filtra per il periodo di riferimento (es. ultimo trimestre)
3. Clicca su Generate Report
4. Il PDF generato include un riepilogo degli alert per ogni requisito PCI-DSS con il dettaglio degli agent coinvolti

StandardMapping WazuhSezione DashboardTipo di Alert
GDPR Art. 32gdpr_IV_32.2Regulatory ComplianceAccessi non autorizzati, FIM
GDPR Art. 35gdpr_IV_35.7.dRegulatory ComplianceModifiche a dati sensibili
PCI-DSS 10.2pci_dss_10.2.1Regulatory ComplianceLog accessi cardholder data
PCI-DSS 11.5pci_dss_11.5.1Regulatory ComplianceFile integrity (FIM)
HIPAA 164.312hipaa_164.312.bRegulatory ComplianceAudit log di sistema
MITRE ATT&CKattack.T1110MITRE ATT&CKBrute force, credential stuffing
NIS2 Art. 21Via policy SCAIT Hygiene / SCAHardening configurazione

Security Configuration Assessment (SCA)

Il modulo SCA (Security Configuration Assessment) di Wazuh esegue audit di hardening sugli endpoint, verificando le configurazioni di sistema rispetto a best practice CIS Benchmark, STIG e policy personalizzate. I risultati mostrano una percentuale di conformità per ogni agente, con i dettagli sui check falliti e le remediation raccomandate. Puoi accedere a questa sezione dalla dashboard tramite Security Operations > Configuration Assessment.

Step 12: Monitorare il Cloud e i Container

Wazuh non si limita agli endpoint fisici e virtuali. Supporta il monitoraggio di ambienti cloud (AWS, Azure, GCP) e container (Docker, Kubernetes), rendendolo una soluzione adatta agli ambienti ibridi e cloud-native sempre più diffusi nelle aziende europee.

Per il monitoraggio AWS, Wazuh si integra con CloudTrail, GuardDuty, Config e Inspector. Configura le credenziali AWS in /var/ossec/etc/ossec.conf:

<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>yes</skip_on_error>
  <bucket type="cloudtrail">
    <name>il-tuo-bucket-cloudtrail</name>
    <aws_profile>default</aws_profile>
    <regions>eu-west-1,eu-central-1</regions>
  </bucket>
</wodle>

Per Docker e Kubernetes, installa l’agente Wazuh sui nodi del cluster. Wazuh monitora automaticamente i container in esecuzione, gli eventi Docker (start, stop, inspect), i log delle applicazioni containerizzate e le modifiche al runtime dei container.

Wazuh integra anche il monitoraggio di Office 365 e GitHub, raccogliendo i log di auditing da questi servizi SaaS per rilevare accessi anomali, download massivi di dati e modifiche ai permessi.

Errori Comuni e Troubleshooting: 8 Problemi Frequenti

Queste sono le issue più segnalate dalla community Wazuh e i loro fix verificati:

1. Wazuh Indexer non si avvia (OutOfMemoryError)
Causa: memoria RAM insufficiente per OpenSearch (JVM). Fix: modifica /etc/wazuh-indexer/jvm.options e riduci i parametri -Xms e -Xmx a metà della RAM disponibile (es. su 4 GB: -Xms2g -Xmx2g). Riavvia con systemctl restart wazuh-indexer.

2. Gli agenti risultano “Disconnected” dopo pochi minuti
Causa: il firewall intermedio chiude le connessioni TCP idle sulla porta 1514. Fix: configura <tcp_keepalive>yes</tcp_keepalive> nella sezione <client> dell’ossec.conf dell’agente. Alternativa: usa UDP invece di TCP impostando protocol=udp.

3. Il dashboard mostra “No results” per tutti gli alert
Causa: l’indice OpenSearch non esiste o il Filebeat non sta inviando dati. Verifica con curl -k https://localhost:9200/_cat/indices che gli indici wazuh-alerts-* esistano. Controlla i log di Filebeat con journalctl -u filebeat -n 50.

4. Errore “ERROR: Could not open ‘/var/ossec/queue/ossec/queue'”
Causa: permessi errati sul socket OSSEC. Fix: sudo chown wazuh:wazuh /var/ossec/queue/ossec/queue && sudo chmod 770 /var/ossec/queue/ossec/queue, poi riavvia l’agente.

5. Il FIM non genera alert nonostante le modifiche ai file
Causa: la frequenza di scansione è troppo alta (scansione schedulata invece di realtime). Verifica che realtime="yes" sia impostato per le directory critiche. Controlla anche che il modulo syscheck non sia disabilitato (<disabled>no</disabled>).

6. Il Vulnerability Detection non mostra CVE
Causa: il feed NVD non è stato scaricato o non è aggiornato. Controlla con sudo /var/ossec/bin/wazuh-manager -t e verifica che il server abbia accesso a Internet. Il download iniziale dei feed CVE può richiedere 15-30 minuti.

7. Log “Trying to connect to server (X/Y)”
Causa: l’agente non riesce a raggiungere il manager. Verifica la connettività con nc -zv <IP-MANAGER> 1514 dall’endpoint. Se fallisce, il problema è nel firewall o nel routing di rete.

8. Alert duplicati per lo stesso evento
Causa: regole con if_matched_sid configurate in modo non corretto o agenti che inviano log da fonti multiple. Usa il flag <options>no_full_log</options> nelle regole di correlazione e controlla la configurazione del logcollector sull’agente per evitare la lettura duplicata degli stessi file di log.

Consigli Avanzati per Ambienti di Produzione

Una volta che il deployment base è operativo, questi sono i passi che distinguono un’installazione amatoriale da una configurazione pronta per la produzione.

Multi-node cluster per alta disponibilità: per ambienti con più di 100 agenti o requisiti di uptime del 99.9%, configura Wazuh in modalità cluster con almeno due nodi manager (un master e un worker). La configurazione del cluster avviene modificando la sezione <cluster> in ossec.conf su entrambi i nodi. L’indexer OpenSearch supporta la configurazione a tre nodi per la ridondanza dei dati.

Rotazione e retention dei log: per default Wazuh mantiene gli alert nell’indexer senza un limite di retention. In ambienti con molti agenti, questo può saturare il disco rapidamente. Configura una Index Lifecycle Policy (ILM) in OpenSearch per spostare gli indici vecchi su storage economico (cold tier) e cancellare quelli oltre 90 giorni.

Autenticazione LDAP/Active Directory: in ambienti aziendali, integra il Wazuh dashboard con LDAP o Active Directory per la gestione centralizzata degli accessi. La configurazione avviene nel file /etc/wazuh-dashboard/opensearch_dashboards.yml tramite il plugin OpenSearch Security.

Tune delle regole per ridurre i falsi positivi: nei primi giorni di funzionamento, il volume di alert può essere elevato. Usa il file /var/ossec/etc/rules/local_rules.xml per aggiungere regole che sopprimono i falsi positivi specifici del tuo ambiente (es. tool di backup che modificano file regolarmente, cron job che generano eventi di autenticazione).

Integrazione con SOAR e ticketing: Wazuh supporta l’integrazione con piattaforme SOAR tramite webhook. Configura l’integrazione con TheHive, Cortex, o direttamente con Jira Service Management per creare automaticamente ticket quando alert critici vengono rilevati. Questo riduce il tempo di risposta agli incidenti eliminando il passaggio manuale di triaging.

Wazuh vs Alternative: Quando Sceglierlo

Wazuh è la scelta ottimale per organizzazioni che cercano una piattaforma SIEM/XDR senza costi di licenza, con pieno controllo sui dati e la flessibilità di personalizzare le regole. Non è però la soluzione ideale per tutti i casi d’uso: richiede competenze interne per la gestione e la manutenzione, e il deployment iniziale può richiedere qualche giorno di lavoro per team senza esperienza.

Per un’analisi dettagliata del confronto con Splunk (incluso il costo di $69.000/anno per licenze enterprise), consulta il nostro articolo dedicato su Wazuh vs Splunk: SIEM Open Source Gratis vs $69.000/Anno.

In termini di compliance europea, Wazuh è particolarmente adatto per le organizzazioni che devono dimostrare conformità alla Direttiva NIS2, grazie ai mapping preconfigurati e ai report di conformità generabili direttamente dalla piattaforma.

Progetto Completo: Setup Wazuh per una PMI con 50 Endpoint

Ecco un piano di deployment realistico per una PMI con 50 endpoint (30 Windows, 15 Linux server, 5 macOS):

Infrastruttura consigliata: un server Wazuh dedicato con 8 GB RAM, 4 CPU core e 200 GB SSD (per 90 giorni di retention su 50 endpoint). Un server Ubuntu 22.04 LTS su cloud provider europeo (Hetzner, OVH, Aruba) costa circa 15-25 euro/mese.

Giorno 1: installazione Wazuh all-in-one, configurazione SSL, creazione account admin team. Test di accesso al dashboard.

Giorno 2-3: deployment agenti sui server Linux critici (web server, database server, jump host). Verifica della connessione e del flusso di alert base.

Giorno 4-5: deployment agenti su workstation Windows tramite GPO (Group Policy Object) per distribuzione automatizzata del pacchetto MSI. Configurazione FIM per le directory critiche applicazione.

Settimana 2: tune delle regole per eliminare falsi positivi, configurazione alert email per il team IT, attivazione del modulo Vulnerability Detection, generazione primo report di conformità.

Mese 2: configurazione active response per brute force, integrazione con Active Directory per autenticazione SSO, configurazione retention policy per gestione dello storage a lungo termine.

Copertura Correlata

Articoli Correlati

FAQ su Wazuh

Wazuh è davvero gratuito?

Sì. Wazuh è open source (licenza GPLv2) e gratuito senza limiti sul numero di agenti o sulle funzionalità. Non esistono versioni “enterprise” a pagamento con funzioni aggiuntive: tutto il codice è disponibile su GitHub. L’azienda dietro Wazuh offre supporto commerciale opzionale, ma non è necessario per l’utilizzo della piattaforma.

Quanti agenti può gestire Wazuh?

Un singolo nodo Wazuh con 4 GB RAM e 8 CPU core può gestire comodamente fino a 500 agenti attivi. Per scale maggiori, Wazuh supporta la configurazione cluster multi-nodo (un master e più worker) con bilanciamento del carico degli agenti. Deployment con decine di migliaia di agenti sono documentati nella community.

Wazuh può sostituire un antivirus?

No, Wazuh non è un sostituto dell’antivirus. È una piattaforma SIEM/XDR che completa la protezione endpoint fornendo visibilità, rilevamento basato su comportamenti, correlazione degli eventi e risposta agli incidenti. In una strategia di defense in depth, Wazuh e un antivirus sono complementari: l’antivirus blocca le minacce note in tempo reale, Wazuh rileva comportamenti anomali e minacce avanzate che l’antivirus non vede.

Wazuh funziona con endpoint Windows?

Sì, l’agente Wazuh supporta Windows Vista/Server 2008 e versioni successive, inclusi Windows 10, 11, Server 2016, 2019 e 2022. Su Windows, Wazuh raccoglie gli Event Log di sistema, i log di sicurezza, monitora il registry, rileva rootkit e integra il monitoraggio dei log di applicazioni come IIS, SQL Server e Active Directory.

Quanto tempo richiede l’installazione?

Il setup all-in-one su un server Ubuntu dedicato richiede circa 20-30 minuti con il Wazuh install assistant. L’aggiunta degli agenti richiede 5-10 minuti per endpoint. Per un deployment su 50 endpoint con deploy automatizzato via script, il tempo totale è tipicamente 4-8 ore lavorative incluso il testing iniziale.

Come si aggiorna Wazuh?

Wazuh raccomanda di disabilitare il repository apt dopo l’installazione per evitare aggiornamenti automatici. Gli aggiornamenti vanno pianificati seguendo le release note ufficiali. La procedura standard prevede: backup della configurazione, aggiornamento dell’indexer, poi del manager, poi della dashboard, infine degli agenti. La documentazione ufficiale include le migration guide per ogni versione maggiore.

Wazuh aiuta con la conformità NIS2?

Wazuh supporta direttamente la conformità NIS2 tramite: monitoraggio degli incidenti di sicurezza (requisito Art. 21), log retention e audit trail, valutazione della configurazione di sicurezza (SCA), vulnerability assessment continuo e report di conformità esportabili. Molte aziende italiane lo usano come componente del loro programma di conformità NIS2 in combinazione con politiche organizzative e formazione del personale.

Wazuh supporta le notifiche in tempo reale?

Sì. Wazuh può inviare notifiche in tempo reale via email, Slack, Microsoft Teams, PagerDuty e qualsiasi sistema che supporti webhook. La configurazione avviene tramite gli script di integrazione nella directory /var/ossec/integrations/ o tramite le integrazioni native disponibili nella dashboard. Per alert critici (livello 12+), i team SOC tipicamente configurano sia email che notifiche sul canale di sicurezza Slack.