{"id":243,"date":"2026-06-19T14:00:00","date_gmt":"2026-06-19T14:00:00","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/19\/wazuh-tutorial-installazione-siem\/"},"modified":"2026-06-19T14:00:00","modified_gmt":"2026-06-19T14:00:00","slug":"wazuh-tutorial-installazione-siem","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/19\/wazuh-tutorial-installazione-siem\/","title":{"rendered":"Wazuh: Installazione e Configurazione SIEM\/XDR in 12 Step [2026]"},"content":{"rendered":"\n

Wazuh \u00e8 oggi la piattaforma open source SIEM e XDR<\/strong> pi\u00f9 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<\/strong>, rilasciata il 23 aprile 2026, introduce miglioramenti significativi al rilevamento delle vulnerabilit\u00e0 e all’integrazione con le normative europee come NIS2<\/strong> e GDPR<\/strong>.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Cosa \u00e8 Wazuh: SIEM, XDR e Perch\u00e9 lo Scelgono le Aziende Europee<\/h2>\n\n\n\n

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

Perch\u00e9 scelgono Wazuh le aziende europee nel 2026? Prima di tutto per la conformit\u00e0 normativa integrata<\/strong>: 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<\/strong>: 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<\/strong> garantisce trasparenza del codice, audit indipendenti e nessun lock-in con vendor proprietari.<\/p>\n\n\n\n

SmarTech-IT, partner italiano di Wazuh, descrive la piattaforma come il principale strumento per “sicurezza, conformit\u00e0 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.<\/p>\n\n\n\n

Prerequisiti: Versioni, Hardware e Porte<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Componente<\/th>RAM Minima<\/th>CPU Minima<\/th>RAM Raccomandata<\/th>CPU Raccomandata<\/th><\/tr><\/thead>
Wazuh Manager<\/td>2 GB<\/td>2 core<\/td>4 GB<\/td>8 core<\/td><\/tr>
Wazuh Indexer<\/td>4 GB<\/td>2 core<\/td>8 GB<\/td>4 core<\/td><\/tr>
Wazuh Dashboard<\/td>4 GB<\/td>2 core<\/td>8 GB<\/td>4 core<\/td><\/tr>
Wazuh Agent<\/td>256 MB<\/td>1 core<\/td>512 MB<\/td>1 core<\/td><\/tr>
All-in-One (test)<\/td>4 GB<\/td>2 core<\/td>8 GB<\/td>4 core<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

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

Le porte di rete che devono essere aperte sul firewall:<\/p>\n\n\n\n

Porta<\/th>Protocollo<\/th>Componente<\/th>Utilizzo<\/th><\/tr><\/thead>
1514<\/td>TCP\/UDP<\/td>Manager<\/td>Ricezione eventi dagli agenti<\/td><\/tr>
1515<\/td>TCP<\/td>Manager<\/td>Registrazione e enrollment agenti<\/td><\/tr>
55000<\/td>TCP<\/td>Manager<\/td>API REST di Wazuh<\/td><\/tr>
9200<\/td>TCP<\/td>Indexer<\/td>API HTTP di OpenSearch<\/td><\/tr>
9300<\/td>TCP<\/td>Indexer<\/td>Comunicazione cluster OpenSearch<\/td><\/tr>
443<\/td>TCP<\/td>Dashboard<\/td>Interfaccia web HTTPS<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

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

Architettura di Wazuh: I 4 Componenti Principali<\/h2>\n\n\n\n

Comprendere l’architettura di Wazuh \u00e8 fondamentale per installarlo correttamente e per diagnosticare problemi in produzione. La piattaforma si divide in quattro componenti distinti che comunicano tra loro.<\/p>\n\n\n\n

Il Wazuh Manager<\/strong> \u00e8 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. \u00c8 il processo che gira su \/var\/ossec\/<\/code> e si controlla con systemctl<\/code>.<\/p>\n\n\n\n

Il Wazuh Indexer<\/strong> (basato su OpenSearch) archivia e indicizza tutti i dati di sicurezza. \u00c8 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\u00e0.<\/p>\n\n\n\n

Il Wazuh Dashboard<\/strong> \u00e8 l’interfaccia web che i SOC analyst usano quotidianamente. Visualizza alert, vulnerabilit\u00e0, conformit\u00e0, permette query avanzate sui log e supporta la creazione di dashboard personalizzate. Si accede via HTTPS sulla porta 443.<\/p>\n\n\n\n

Il Wazuh Agent<\/strong> \u00e8 il componente leggero installato sugli endpoint da monitorare. Raccoglie log di sistema, monitora l’integrit\u00e0 dei file, analizza i processi attivi, inventaria il software installato e rileva vulnerabilit\u00e0. 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.<\/p>\n\n\n\n

Step 1: Aggiornare il Sistema Ubuntu<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

sudo apt-get update && sudo apt-get upgrade -y\nsudo apt-get install curl apt-transport-https gnupg -y<\/code><\/pre>\n\n\n\n
Dopo l’aggiornamento, verifica che il sistema abbia il nome host correttamente configurato. Wazuh usa il hostname per identificare il server nel cluster:<\/p>\n\n\n\n
hostnamectl set-hostname wazuh-server\necho \"127.0.1.1 wazuh-server\" | sudo tee -a \/etc\/hosts<\/code><\/pre>\n\n\n\n
Pitfall #1:<\/strong> Non saltare il riavvio se il kernel \u00e8 stato aggiornato. Un mismatch tra kernel in esecuzione e moduli kernel aggiornati pu\u00f2 causare problemi con le funzionalit\u00e0 di auditing del sistema usate da Wazuh FIM.<\/p>\n\n\n\n
Step 2: Scaricare e Lanciare l’Installation Assistant<\/h2>\n\n\n\n
Wazuh fornisce uno script di installazione assistita che automatizza il setup dell’intero stack (Manager, Indexer, Dashboard) su un singolo nodo. Questo \u00e8 il metodo raccomandato per ambienti di test, lab e deployment SME.<\/p>\n\n\n\n
curl -sO https:\/\/packages.wazuh.com\/4.14\/wazuh-install.sh\nsudo bash .\/wazuh-install.sh -a<\/code><\/pre>\n\n\n\n
L’opzione -a<\/code> 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.<\/p>\n\n\n\n
Al termine dell’installazione, lo script stampa le credenziali di accesso al dashboard direttamente nel terminale:<\/p>\n\n\n\n
INFO: --- Summary ---\nINFO: You can access the web interface https:\/\/<wazuh-dashboard-ip>\n    User: admin\n    Password: <password-generata>\n\nINFO: Installation finished.<\/code><\/pre>\n\n\n\n
Importante:<\/strong> 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<\/code>, ma solo se l’archivio generato dallo script \u00e8 ancora presente.<\/p>\n\n\n\n
Pitfall #2:<\/strong> Non eseguire l’installation assistant come utente non-root senza sudo<\/code>. Lo script richiede permessi elevati per installare pacchetti di sistema e configurare i servizi systemd. Se lo esegui come utente normale senza sudo, fallir\u00e0 silenziosamente su alcune operazioni.<\/p>\n\n\n\n
Step 3: Verificare i Servizi e Accedere al Dashboard<\/h2>\n\n\n\n
Dopo l’installazione, verifica che tutti i servizi siano attivi e in esecuzione:<\/p>\n\n\n\n
sudo systemctl status wazuh-manager\nsudo systemctl status wazuh-indexer\nsudo systemctl status wazuh-dashboard\n\n# Output atteso per ogni servizio:\n# \u25cf wazuh-manager.service - Wazuh manager\n#    Loaded: loaded (\/usr\/lib\/systemd\/system\/wazuh-manager.service)\n#    Active: active (running) since ...<\/code><\/pre>\n\n\n\n
Se un servizio non risulta attivo, controlla i log con journalctl -u wazuh-manager --since \"10 minutes ago\"<\/code>. Il problema pi\u00f9 comune nelle prime installazioni \u00e8 la mancanza di memoria RAM sufficiente per l’indexer OpenSearch.<\/p>\n\n\n\n
Apri il browser e naviga su https:\/\/<IP-del-server><\/code>. Riceverai un avviso di sicurezza del browser perch\u00e9 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Pitfall #3:<\/strong> 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.<\/p>\n\n\n\n
Step 4: Installare il Wazuh Agent su Linux<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Sul nodo endpoint<\/strong> (non sul server Wazuh), esegui:<\/p>\n\n\n\n
# Aggiungi la chiave GPG e il repository Wazuh\ncurl -s https:\/\/packages.wazuh.com\/key\/GPG-KEY-WAZUH | gpg --no-default-keyring \\\n  --keyring gnupg-ring:\/usr\/share\/keyrings\/wazuh.gpg --import\nchmod 644 \/usr\/share\/keyrings\/wazuh.gpg\n\necho \"deb [signed-by=\/usr\/share\/keyrings\/wazuh.gpg] https:\/\/packages.wazuh.com\/4.x\/apt\/ stable main\" \\\n  | sudo tee \/etc\/apt\/sources.list.d\/wazuh.list\n\n# Installa il pacchetto agente\nsudo apt-get update\nsudo WAZUH_MANAGER=\"<IP-DEL-TUO-SERVER-WAZUH>\" apt-get install wazuh-agent -y<\/code><\/pre>\n\n\n\n
La variabile d’ambiente WAZUH_MANAGER<\/code> configurata durante l’installazione imposta automaticamente l’indirizzo del manager nel file di configurazione dell’agente. Avvia e abilita il servizio:<\/p>\n\n\n\n
sudo systemctl daemon-reload\nsudo systemctl enable wazuh-agent\nsudo systemctl start wazuh-agent\n\n# Verifica lo stato\nsudo systemctl status wazuh-agent<\/code><\/pre>\n\n\n\n
Installazione su Windows:<\/strong> 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<\/code>) ed eseguilo con i parametri:<\/p>\n\n\n\n
msiexec \/i wazuh-agent-4.14.5-1.msi WAZUH_MANAGER=\"192.168.1.100\" \/q<\/code><\/pre>\n\n\n\n
Pitfall #4:<\/strong> 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<\/code> per evitare aggiornamenti automatici accidentali che potrebbero rompere la configurazione.<\/p>\n\n\n\n
Step 5: Verificare la Connessione degli Agenti<\/h2>\n\n\n\n
Dopo aver installato uno o pi\u00f9 agenti, torna sul server Wazuh per verificarne la connessione. Dal terminale del server:<\/p>\n\n\n\n
# Lista tutti gli agenti connessi\nsudo \/var\/ossec\/bin\/agent_control -lc\n\n# Output di esempio:\n# Wazuh agent_control. List of active agents:\n#    ID: 001, Name: ubuntu-web-01, IP: 192.168.1.10, Active\/Local\n\n# Verifica lo stato di un agente specifico (ID 001)\nsudo \/var\/ossec\/bin\/agent_control -i 001<\/code><\/pre>\n\n\n\n
Puoi anche verificare gli agenti dalla dashboard web: vai su Agents<\/strong> nel menu laterale. Ogni agente appare con il suo stato (Active, Disconnected, Never connected), l’OS, la versione del software e l’ultima attivit\u00e0 registrata.<\/p>\n\n\n\n
Se un agente appare come “Never connected”, controlla:<\/p>\n\n\n\n
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<\/code> dell’agente contiene l’IP corretto del manager
4. Il servizio wazuh-agent \u00e8 in esecuzione sull’endpoint (systemctl status wazuh-agent<\/code>)<\/p>\n\n\n\n
Step 6: Configurare il File Integrity Monitoring (FIM)<\/h2>\n\n\n\n
Il File Integrity Monitoring (FIM) \u00e8 una delle funzionalit\u00e0 pi\u00f9 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. \u00c8 essenziale per rilevare compromissioni di sistema, malware e modifiche non autorizzate.<\/p>\n\n\n\n
La configurazione FIM si trova nel file \/var\/ossec\/etc\/ossec.conf<\/code> sia sul manager (per la configurazione globale) che sull’agente. La sezione di riferimento \u00e8 <syscheck><\/code>:<\/p>\n\n\n\n
<syscheck>\n  <disabled>no<\/disabled>\n\n  <!-- Frequenza di scansione in secondi (default: 43200 = 12 ore) -->\n  <frequency>7200<\/frequency>\n\n  <!-- Scansione all'avvio del servizio -->\n  <scan_on_start>yes<\/scan_on_start>\n\n  <!-- Directory da monitorare in tempo reale -->\n  <directories check_all=\"yes\" realtime=\"yes\">\/etc<\/directories>\n  <directories check_all=\"yes\" realtime=\"yes\">\/usr\/bin<\/directories>\n  <directories check_all=\"yes\" realtime=\"yes\">\/usr\/sbin<\/directories>\n  <directories check_all=\"yes\" realtime=\"yes\">\/bin<\/directories>\n  <directories check_all=\"yes\" realtime=\"yes\">\/sbin<\/directories>\n  <directories check_all=\"yes\" realtime=\"yes\">\/var\/www<\/directories>\n\n  <!-- File da ignorare (cambiano frequentemente, genererebbero falsi positivi) -->\n  <ignore>\/etc\/mtab<\/ignore>\n  <ignore>\/etc\/hosts.deny<\/ignore>\n  <ignore>\/etc\/mail\/statistics<\/ignore>\n  <ignore>\/etc\/random-seed<\/ignore>\n  <ignore>\/etc\/adjtime<\/ignore>\n  <ignore>\/etc\/resolv.conf<\/ignore>\n\n  <!-- Genera alert per file eliminati -->\n  <alert_new_files>yes<\/alert_new_files>\n<\/syscheck><\/code><\/pre>\n\n\n\n
Dopo aver modificato il file di configurazione, riavvia il manager per applicare le modifiche:<\/p>\n\n\n\n
sudo systemctl restart wazuh-manager\n\n# Forza una scansione FIM immediata su un agente specifico\nsudo \/var\/ossec\/bin\/agent_control -r -u 001<\/code><\/pre>\n\n\n\n
Pitfall #5:<\/strong> Non abilitare il monitoraggio in tempo reale (realtime=\"yes\"<\/code>) su directory molto attive come \/tmp<\/code> o \/var\/log<\/code>. Genera un volume di alert talmente elevato da rendere impossibile il triaging. Usa la modalit\u00e0 real-time solo per directory critiche e limita le scansioni periodiche per directory a maggiore attivit\u00e0.<\/p>\n\n\n\n
Step 7: Attivare il Rilevamento delle Vulnerabilit\u00e0<\/h2>\n\n\n\n
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\u00e0. In un singolo dashboard puoi vedere quali endpoint hanno software vulnerabile e qual \u00e8 la severity di ogni CVE.<\/p>\n\n\n\n
Dalla dashboard, naviga su Threat Intelligence > Vulnerability Detection<\/strong>. Clicca sulla scheda Inventory<\/strong> per vedere tutti i pacchetti monitorati. Puoi filtrare per nome pacchetto: ad esempio, inserisci package.name<\/code> con operatore is<\/code> e valore openssl<\/code> per trovare tutti gli endpoint con OpenSSL installato e verificare se sono sulla versione sicura.<\/p>\n\n\n\n
Per abilitare o personalizzare la frequenza delle scansioni di vulnerabilit\u00e0, modifica la sezione <vulnerability-detection><\/code> in \/var\/ossec\/etc\/ossec.conf<\/code> sul manager:<\/p>\n\n\n\n
<vulnerability-detection>\n  <enabled>yes<\/enabled>\n  <index-status>yes<\/index-status>\n  <feed-update-interval>60m<\/feed-update-interval>\n<\/vulnerability-detection><\/code><\/pre>\n\n\n\n
Il parametro feed-update-interval<\/code> controlla ogni quanto Wazuh aggiorna i feed CVE dai database pubblici (NVD, OVAL, etc.). Il valore di default \u00e8 60 minuti, un buon equilibrio tra freschezza dei dati e carico di rete.<\/p>\n\n\n\n
Capire i Livelli di Severity nelle CVE<\/h3>\n\n\n\n
Wazuh classifica le vulnerabilit\u00e0 usando lo standard CVSS (Common Vulnerability Scoring System). Gli alert di vulnerabilit\u00e0 vengono categorizzati in quattro livelli: Critical<\/strong> (CVSS 9.0-10.0), High<\/strong> (7.0-8.9), Medium<\/strong> (4.0-6.9) e Low<\/strong> (0.1-3.9). Un filtro utile nella dashboard \u00e8 ordinare per severity decrescente e applicare il filtro su agenti di produzione specifici, per triagare prima le vulnerabilit\u00e0 critiche sui sistemi esposti.<\/p>\n\n\n\n
Step 8: Creare Regole Personalizzate<\/h2>\n\n\n\n
Wazuh include migliaia di regole predefinite per rilevare attivit\u00e0 sospette su Linux, Windows, applicazioni web, database e servizi cloud. Puoi per\u00f2 aggiungere regole personalizzate per rispondere alle esigenze specifiche del tuo ambiente, senza modificare le regole di sistema che verrebbero sovrascritte da un aggiornamento.<\/p>\n\n\n\n
Le regole personalizzate vanno inserite nel file \/var\/ossec\/etc\/rules\/local_rules.xml<\/code>. Gli ID delle regole custom devono essere superiori a 100000 per non collidere con quelle built-in:<\/p>\n\n\n\n
<group name=\"local,syslog,\">\n\n  <!-- Alert livello 10 per tentativi SSH ripetuti da un IP non in whitelist -->\n  <rule id=\"100100\" level=\"10\">\n    <if_matched_sid>5720<\/if_matched_sid>\n    <same_source_ip \/>\n    <options>no_full_log<\/options>\n    <description>Multipli tentativi SSH falliti dallo stesso IP<\/description>\n    <group>authentication_failures,<\/group>\n  <\/rule>\n\n  <!-- Alert per accesso sudo da utente non privilegiato -->\n  <rule id=\"100101\" level=\"8\">\n    <if_sid>5402<\/if_sid>\n    <description>Comando sudo eseguito da account non autorizzato<\/description>\n    <group>sudo,<\/group>\n  <\/rule>\n\n  <!-- Alert per modifica al file \/etc\/passwd -->\n  <rule id=\"100102\" level=\"12\">\n    <if_sid>550<\/if_sid>\n    <match>\/etc\/passwd<\/match>\n    <description>File \/etc\/passwd modificato - possibile aggiunta account non autorizzato<\/description>\n    <group>fim,pci_dss_11.5,gdpr_IV_35.7.d,<\/group>\n  <\/rule>\n\n<\/group><\/code><\/pre>\n\n\n\n
I livelli delle regole vanno da 0 a 15. Livelli 7-9 indicano attivit\u00e0 di sicurezza rilevanti, 10-12 attivit\u00e0 ad alto rischio, 13-15 attivit\u00e0 critiche. Dopo aver aggiunto regole, verifica la sintassi prima del riavvio:<\/p>\n\n\n\n
sudo \/var\/ossec\/bin\/wazuh-logtest\n\n# Testa una regola simulando un input di log\n# Incolla un log di esempio e premi invio - Wazuh mostra quale regola si attiva<\/code><\/pre>\n\n\n\n
Pitfall #6:<\/strong> Non assegnare livelli troppo alti (12+) a regole che si attivano frequentemente. Wazuh pu\u00f2 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).<\/p>\n\n\n\n
Step 9: Configurare le Risposte Attive<\/h2>\n\n\n\n
Le Active Response di Wazuh permettono di automatizzare le contromisure quando un alert viene triggerato. L’esempio classico \u00e8 bloccare un IP che ha tentato un brute force SSH. La configurazione avviene in due sezioni di \/var\/ossec\/etc\/ossec.conf<\/code>: la definizione del comando e la definizione della risposta.<\/p>\n\n\n\n
<!-- Definizione del comando: usa iptables per bloccare un IP -->\n<command>\n  <name>firewall-drop<\/name>\n  <executable>firewall-drop<\/executable>\n  <timeout_allowed>yes<\/timeout_allowed>\n<\/command>\n\n<!-- Risposta attiva: esegui il blocco quando la regola 5763 si attiva 3+ volte in 120 secondi -->\n<active-response>\n  <command>firewall-drop<\/command>\n  <location>local<\/location>\n  <rules_id>5763<\/rules_id>\n  <timeout>600<\/timeout>\n<\/active-response><\/code><\/pre>\n\n\n\n
Il parametro timeout<\/code> indica per quanti secondi l’IP rimane bloccato (600 = 10 minuti). Dopo questo periodo, Wazuh rimuove automaticamente la regola iptables. Puoi anche impostare timeout<\/code> a 0 per un blocco permanente, ma richiede intervento manuale per sbloccare.<\/p>\n\n\n\n
Per vedere tutte le risposte attive eseguite, controlla il log:<\/p>\n\n\n\n
sudo tail -f \/var\/ossec\/logs\/active-responses.log<\/code><\/pre>\n\n\n\n
Pitfall #7:<\/strong> Non attivare le active response senza testare prima in un ambiente non produttivo. Una regola configurata male pu\u00f2 bloccare IP legittimi, incluso il tuo indirizzo di gestione. Prima di abilitare il blocco automatico, usa la modalit\u00e0 <location>defined-agent<\/location><\/code> su un singolo agente di test.<\/p>\n\n\n\n
Step 10: Configurare gli Alert Email<\/h2>\n\n\n\n
Wazuh pu\u00f2 inviare notifiche email per alert che superano una determinata soglia di livello. La configurazione SMTP va nella sezione <global><\/code> di \/var\/ossec\/etc\/ossec.conf<\/code>:<\/p>\n\n\n\n
<global>\n  <email_notification>yes<\/email_notification>\n  <smtp_server>smtp.tua-azienda.it<\/smtp_server>\n  <email_from>wazuh@tua-azienda.it<\/email_from>\n  <email_to>soc-team@tua-azienda.it<\/email_to>\n  <email_maxperhour>12<\/email_maxperhour>\n<\/global>\n\n<alerts>\n  <!-- Invia email solo per alert di livello 10 o superiore -->\n  <email_alert_level>10<\/email_alert_level>\n<\/alerts><\/code><\/pre>\n\n\n\n
Il parametro email_maxperhour<\/code> 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<\/strong> della dashboard.<\/p>\n\n\n\n
Step 11: Configurare la Conformit\u00e0 Normativa (GDPR, NIS2, PCI-DSS)<\/h2>\n\n\n\n
Wazuh \u00e8 uno degli strumenti pi\u00f9 usati dai team di compliance europei per dimostrare l’adeguamento alla Direttiva NIS2<\/strong> e al GDPR<\/strong>. Il motore di regole include mapping espliciti verso i requisiti di questi standard, visibili nei tag delle regole (come gdpr_IV_35.7.d<\/code> nell’esempio di custom rule sopra).<\/p>\n\n\n\n
Dalla dashboard, il modulo Security Operations > IT Hygiene<\/strong> mostra lo stato di conformit\u00e0 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.<\/p>\n\n\n\n
Per generare un report di conformit\u00e0 PCI-DSS:<\/p>\n\n\n\n
1. Vai su Regulatory Compliance > PCI DSS<\/strong>
2. Filtra per il periodo di riferimento (es. ultimo trimestre)
3. Clicca su Generate Report<\/strong>
4. Il PDF generato include un riepilogo degli alert per ogni requisito PCI-DSS con il dettaglio degli agent coinvolti<\/p>\n\n\n\n
Standard<\/th>Mapping Wazuh<\/th>Sezione Dashboard<\/th>Tipo di Alert<\/th><\/tr><\/thead>
GDPR Art. 32<\/td>gdpr_IV_32.2<\/td>Regulatory Compliance<\/td>Accessi non autorizzati, FIM<\/td><\/tr>
GDPR Art. 35<\/td>gdpr_IV_35.7.d<\/td>Regulatory Compliance<\/td>Modifiche a dati sensibili<\/td><\/tr>
PCI-DSS 10.2<\/td>pci_dss_10.2.1<\/td>Regulatory Compliance<\/td>Log accessi cardholder data<\/td><\/tr>
PCI-DSS 11.5<\/td>pci_dss_11.5.1<\/td>Regulatory Compliance<\/td>File integrity (FIM)<\/td><\/tr>
HIPAA 164.312<\/td>hipaa_164.312.b<\/td>Regulatory Compliance<\/td>Audit log di sistema<\/td><\/tr>
MITRE ATT&CK<\/td>attack.T1110<\/td>MITRE ATT&CK<\/td>Brute force, credential stuffing<\/td><\/tr>
NIS2 Art. 21<\/td>Via policy SCA<\/td>IT Hygiene \/ SCA<\/td>Hardening configurazione<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Security Configuration Assessment (SCA)<\/h3>\n\n\n\n
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\u00e0 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<\/strong>.<\/p>\n\n\n\n
Step 12: Monitorare il Cloud e i Container<\/h2>\n\n\n\n
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\u00f9 diffusi nelle aziende europee.<\/p>\n\n\n\n
Per il monitoraggio AWS<\/strong>, Wazuh si integra con CloudTrail, GuardDuty, Config e Inspector. Configura le credenziali AWS in \/var\/ossec\/etc\/ossec.conf<\/code>:<\/p>\n\n\n\n
<wodle name=\"aws-s3\">\n  <disabled>no<\/disabled>\n  <interval>10m<\/interval>\n  <run_on_start>yes<\/run_on_start>\n  <skip_on_error>yes<\/skip_on_error>\n  <bucket type=\"cloudtrail\">\n    <name>il-tuo-bucket-cloudtrail<\/name>\n    <aws_profile>default<\/aws_profile>\n    <regions>eu-west-1,eu-central-1<\/regions>\n  <\/bucket>\n<\/wodle><\/code><\/pre>\n\n\n\n
Per Docker e Kubernetes<\/strong>, 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.<\/p>\n\n\n\n
Wazuh integra anche il monitoraggio di Office 365 e GitHub<\/strong>, raccogliendo i log di auditing da questi servizi SaaS per rilevare accessi anomali, download massivi di dati e modifiche ai permessi.<\/p>\n\n\n\n
Errori Comuni e Troubleshooting: 8 Problemi Frequenti<\/h2>\n\n\n\n
Queste sono le issue pi\u00f9 segnalate dalla community Wazuh e i loro fix verificati:<\/p>\n\n\n\n
1. Wazuh Indexer non si avvia (OutOfMemoryError)<\/strong>
Causa: memoria RAM insufficiente per OpenSearch (JVM). Fix: modifica \/etc\/wazuh-indexer\/jvm.options<\/code> e riduci i parametri -Xms<\/code> e -Xmx<\/code> a met\u00e0 della RAM disponibile (es. su 4 GB: -Xms2g -Xmx2g<\/code>). Riavvia con systemctl restart wazuh-indexer<\/code>.<\/p>\n\n\n\n
2. Gli agenti risultano “Disconnected” dopo pochi minuti<\/strong>
Causa: il firewall intermedio chiude le connessioni TCP idle sulla porta 1514. Fix: configura <tcp_keepalive>yes<\/tcp_keepalive><\/code> nella sezione <client><\/code> dell’ossec.conf dell’agente. Alternativa: usa UDP invece di TCP impostando protocol=udp<\/code>.<\/p>\n\n\n\n
3. Il dashboard mostra “No results” per tutti gli alert<\/strong>
Causa: l’indice OpenSearch non esiste o il Filebeat non sta inviando dati. Verifica con curl -k https:\/\/localhost:9200\/_cat\/indices<\/code> che gli indici wazuh-alerts-*<\/code> esistano. Controlla i log di Filebeat con journalctl -u filebeat -n 50<\/code>.<\/p>\n\n\n\n
4. Errore “ERROR: Could not open ‘\/var\/ossec\/queue\/ossec\/queue'”<\/strong>
Causa: permessi errati sul socket OSSEC. Fix: sudo chown wazuh:wazuh \/var\/ossec\/queue\/ossec\/queue && sudo chmod 770 \/var\/ossec\/queue\/ossec\/queue<\/code>, poi riavvia l’agente.<\/p>\n\n\n\n
5. Il FIM non genera alert nonostante le modifiche ai file<\/strong>
Causa: la frequenza di scansione \u00e8 troppo alta (scansione schedulata invece di realtime). Verifica che realtime=\"yes\"<\/code> sia impostato per le directory critiche. Controlla anche che il modulo syscheck<\/code> non sia disabilitato (<disabled>no<\/disabled><\/code>).<\/p>\n\n\n\n
6. Il Vulnerability Detection non mostra CVE<\/strong>
Causa: il feed NVD non \u00e8 stato scaricato o non \u00e8 aggiornato. Controlla con sudo \/var\/ossec\/bin\/wazuh-manager -t<\/code> e verifica che il server abbia accesso a Internet. Il download iniziale dei feed CVE pu\u00f2 richiedere 15-30 minuti.<\/p>\n\n\n\n
7. Log “Trying to connect to server (X\/Y)”<\/strong>
Causa: l’agente non riesce a raggiungere il manager. Verifica la connettivit\u00e0 con nc -zv <IP-MANAGER> 1514<\/code> dall’endpoint. Se fallisce, il problema \u00e8 nel firewall o nel routing di rete.<\/p>\n\n\n\n
8. Alert duplicati per lo stesso evento<\/strong>
Causa: regole con if_matched_sid<\/code> configurate in modo non corretto o agenti che inviano log da fonti multiple. Usa il flag <options>no_full_log<\/options><\/code> nelle regole di correlazione e controlla la configurazione del logcollector<\/code> sull’agente per evitare la lettura duplicata degli stessi file di log.<\/p>\n\n\n\n
Consigli Avanzati per Ambienti di Produzione<\/h2>\n\n\n\n
Una volta che il deployment base \u00e8 operativo, questi sono i passi che distinguono un’installazione amatoriale da una configurazione pronta per la produzione.<\/p>\n\n\n\n
Multi-node cluster per alta disponibilit\u00e0:<\/strong> per ambienti con pi\u00f9 di 100 agenti o requisiti di uptime del 99.9%, configura Wazuh in modalit\u00e0 cluster con almeno due nodi manager (un master e un worker). La configurazione del cluster avviene modificando la sezione <cluster><\/code> in ossec.conf su entrambi i nodi. L’indexer OpenSearch supporta la configurazione a tre nodi per la ridondanza dei dati.<\/p>\n\n\n\n
Rotazione e retention dei log:<\/strong> per default Wazuh mantiene gli alert nell’indexer senza un limite di retention. In ambienti con molti agenti, questo pu\u00f2 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.<\/p>\n\n\n\n
Autenticazione LDAP\/Active Directory:<\/strong> 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<\/code> tramite il plugin OpenSearch Security.<\/p>\n\n\n\n
Tune delle regole per ridurre i falsi positivi:<\/strong> nei primi giorni di funzionamento, il volume di alert pu\u00f2 essere elevato. Usa il file \/var\/ossec\/etc\/rules\/local_rules.xml<\/code> 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).<\/p>\n\n\n\n
Integrazione con SOAR e ticketing:<\/strong> 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.<\/p>\n\n\n\n
Wazuh vs Alternative: Quando Sceglierlo<\/h2>\n\n\n\n
Wazuh \u00e8 la scelta ottimale per organizzazioni che cercano una piattaforma SIEM\/XDR senza costi di licenza, con pieno controllo sui dati e la flessibilit\u00e0 di personalizzare le regole. Non \u00e8 per\u00f2 la soluzione ideale per tutti i casi d’uso: richiede competenze interne per la gestione e la manutenzione, e il deployment iniziale pu\u00f2 richiedere qualche giorno di lavoro per team senza esperienza.<\/p>\n\n\n\n
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<\/a>.<\/p>\n\n\n\n
In termini di compliance europea, Wazuh \u00e8 particolarmente adatto per le organizzazioni che devono dimostrare conformit\u00e0 alla Direttiva NIS2<\/a>, grazie ai mapping preconfigurati e ai report di conformit\u00e0 generabili direttamente dalla piattaforma.<\/p>\n\n\n\n
Progetto Completo: Setup Wazuh per una PMI con 50 Endpoint<\/h2>\n\n\n\n
Ecco un piano di deployment realistico per una PMI con 50 endpoint (30 Windows, 15 Linux server, 5 macOS):<\/p>\n\n\n\n
Infrastruttura consigliata:<\/strong> 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.<\/p>\n\n\n\n
Giorno 1:<\/strong> installazione Wazuh all-in-one, configurazione SSL, creazione account admin team. Test di accesso al dashboard.<\/p>\n\n\n\n
Giorno 2-3:<\/strong> deployment agenti sui server Linux critici (web server, database server, jump host). Verifica della connessione e del flusso di alert base.<\/p>\n\n\n\n
Giorno 4-5:<\/strong> deployment agenti su workstation Windows tramite GPO (Group Policy Object) per distribuzione automatizzata del pacchetto MSI. Configurazione FIM per le directory critiche applicazione.<\/p>\n\n\n\n
Settimana 2:<\/strong> tune delle regole per eliminare falsi positivi, configurazione alert email per il team IT, attivazione del modulo Vulnerability Detection, generazione primo report di conformit\u00e0.<\/p>\n\n\n\n
Mese 2:<\/strong> configurazione active response per brute force, integrazione con Active Directory per autenticazione SSO, configurazione retention policy per gestione dello storage a lungo termine.<\/p>\n\n\n\n
Copertura Correlata<\/h2>\n\n\n\n
Articoli Correlati<\/h3>\n\n\n\n