Introduzione: Perché Wazuh È Diventato lo Standard per la Sicurezza Linux
Se gestite server Linux in produzione, lo sapete già: il panorama delle minacce nel 2026 non perdona. Attacchi automatizzati, supply chain compromesse, tecniche di evasione sempre più raffinate — come il rootkit Curing basato su io_uring di cui abbiamo parlato in un precedente articolo — rendono praticamente obbligatorio avere un sistema di rilevamento intrusioni solido, ben configurato e costantemente aggiornato.
Ed è qui che entra in gioco Wazuh.
Nato nel 2015 come fork di OSSEC, Wazuh si è trasformato nel tempo in una piattaforma di sicurezza unificata che mette insieme SIEM (Security Information and Event Management), XDR (Extended Detection and Response), monitoraggio dell'integrità dei file, rilevamento delle vulnerabilità e risposta attiva agli incidenti. Con la versione 4.14.3, rilasciata l'11 febbraio 2026, offre funzionalità che fino a pochi anni fa richiedevano soluzioni enterprise proprietarie dal costo francamente proibitivo.
In questa guida vedremo come installare Wazuh su Linux partendo da zero, configurare il File Integrity Monitoring (FIM), impostare le risposte attive automatiche e creare regole personalizzate per il vostro ambiente. Il tutto con esempi pratici, comandi pronti all'uso e le best practice aggiornate al 2026.
Architettura di Wazuh: Capire i Componenti
Prima di mettere le mani sulla tastiera, vale la pena capire come Wazuh funziona sotto il cofano. La piattaforma è composta da quattro componenti principali che lavorano in sinergia.
Wazuh Server (Manager)
Il cuore del sistema. Il Wazuh Manager riceve i dati dagli agenti installati sugli endpoint, li analizza applicando il motore di correlazione e le regole di rilevamento, e genera gli alert. Tutta la logica di analisi, la decodifica dei log e l'esecuzione delle risposte attive avviene qui.
Wazuh Indexer
Basato su OpenSearch, il Wazuh Indexer archivia e indicizza tutti gli alert, gli eventi e i dati di sicurezza. Nella versione 4.14.3 utilizza OpenSearch 2.19.1 con Apache Lucene aggiornato, il che garantisce ricerche rapide anche su dataset piuttosto grandi.
Wazuh Dashboard
L'interfaccia web per visualizzazione e gestione. Permette di monitorare gli alert in tempo reale, gestire gli agenti, esplorare i dati di sicurezza, creare report di conformità e parecchio altro. Nella 4.14.3 è stata aggiunta anche la possibilità di rimuovere gli agenti direttamente dalla pagina Summary — una comodità non da poco.
Wazuh Agent
Il software leggero che va installato su ogni endpoint da monitorare. L'agente raccoglie log di sistema, monitora l'integrità dei file, esegue scansioni di vulnerabilità e trasmette tutto al Manager per l'analisi. Supporta Linux, Windows, macOS e diversi altri sistemi operativi.
┌─────────────────────────────────────────────────────┐
│ ARCHITETTURA WAZUH │
├─────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Agent 1 │ │ Agent 2 │ │ Agent N │ │
│ │ (Linux) │ │ (Windows) │ │ (Docker) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Wazuh Manager │ ◄─ Analisi, regole, │
│ │ (Server) │ correlazione │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Wazuh Indexer │ ◄─ Archiviazione e │
│ │ (OpenSearch) │ indicizzazione │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Wazuh Dashboard │ ◄─ Visualizzazione │
│ │ (Web UI) │ e gestione │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────┘Requisiti di Sistema e Prerequisiti
Prima di procedere con l'installazione, assicuratevi che il vostro server soddisfi i requisiti minimi. Wazuh non è esattamente leggero — il Wazuh Indexer in particolare ha un certo appetito in termini di risorse.
Requisiti Hardware Minimi (All-in-One)
- CPU: 4 core (consigliati 8 se avete più di 50 agenti)
- RAM: 8 GB minimo (16 GB per produzione, fidatevi)
- Storage: 50 GB SSD (la dimensione effettiva dipende dal volume dei log e dal periodo di retention)
- Sistema operativo: Ubuntu 22.04/24.04 LTS, Debian 12, RHEL 8/9, CentOS Stream 8/9, AlmaLinux 8/9
Requisiti di Rete
- Porta 1514/TCP: comunicazione agente-manager
- Porta 1515/TCP: registrazione degli agenti
- Porta 9200/TCP: API REST del Wazuh Indexer
- Porta 443/TCP: accesso al Dashboard web
- Porta 55000/TCP: API REST del Wazuh Manager
Preparazione del Server
Aggiornate il sistema e installate le dipendenze necessarie prima di partire:
# Aggiornamento del sistema (Ubuntu/Debian)
sudo apt update && sudo apt upgrade -y
# Installare le dipendenze
sudo apt install -y curl apt-transport-https software-properties-common gnupg2
# Configurare il nome host
sudo hostnamectl set-hostname wazuh-server
# Verificare che la data/ora sia sincronizzata (critico per la correlazione eventi)
timedatectl status
# Se necessario, abilitare la sincronizzazione NTP
sudo timedatectl set-ntp onInstallazione di Wazuh: Metodo Assistito (All-in-One)
Il metodo più rapido per avere un'istanza Wazuh funzionante è senza dubbio l'installazione assistita. Con un singolo script vengono installati e configurati tutti i componenti: Manager, Indexer e Dashboard.
Passo 1: Scaricare ed Eseguire lo Script di Installazione
# Scaricare lo script di installazione ufficiale Wazuh 4.14
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
# Eseguire l'installazione completa (All-in-One)
sudo bash ./wazuh-install.sh -aL'installazione richiede tra i 5 e i 15 minuti, a seconda delle prestazioni del server. Lo script si occupa di tutto:
- Installare e configurare il Wazuh Indexer (OpenSearch)
- Installare e configurare il Wazuh Manager
- Installare e configurare Filebeat per l'invio dei dati all'Indexer
- Installare e configurare il Wazuh Dashboard
- Generare certificati SSL/TLS per le comunicazioni sicure
- Creare le credenziali di accesso
Passo 2: Recuperare le Credenziali
Al termine dell'installazione, lo script mostra le credenziali generate automaticamente. Se le avete perse (capita più spesso di quanto si pensi), recuperatele con:
# Estrarre le password generate durante l'installazione
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txtPasso 3: Accedere al Dashboard
Aprite il browser e navigate su https://IP_DEL_VOSTRO_SERVER. Accettate il certificato autofirmato e inserite le credenziali dell'utente admin.
Importante: cambiate subito la password predefinita. Le credenziali di default sono letteralmente il primo bersaglio di qualsiasi attaccante che scopre un'istanza Wazuh esposta su internet.
# Cambiare la password dell'utente admin del Dashboard
# Usare lo script di gestione password fornito da Wazuh
sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh \
-u admin -p NuovaPasswordSicura2026!Installazione Manuale Passo-Passo (Per Ambienti di Produzione)
Per ambienti di produzione con requisiti specifici, l'installazione manuale vi dà un controllo molto maggiore. Vediamo il processo completo per Ubuntu 24.04 LTS.
Aggiungere il Repository Wazuh
# Importare la chiave GPG di 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
# Aggiungere il repository Wazuh
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
# Aggiornare la lista dei pacchetti
sudo apt updateInstallare il Wazuh Manager
# Installare il pacchetto del Manager
sudo apt install -y wazuh-manager
# Verificare lo stato del servizio
sudo systemctl status wazuh-manager
# Abilitare l'avvio automatico
sudo systemctl enable wazuh-managerInstallare e Configurare il Wazuh Indexer
# Installare il Wazuh Indexer
sudo apt install -y wazuh-indexer
# Il file di configurazione principale si trova in:
# /etc/wazuh-indexer/opensearch.yml
# Generare i certificati necessari
# (seguire la documentazione ufficiale per il processo completo
# di generazione certificati con lo strumento wazuh-certs-tool)
# Avviare e abilitare il servizio
sudo systemctl start wazuh-indexer
sudo systemctl enable wazuh-indexer
# Verificare che l'Indexer sia in esecuzione
curl -k -u admin:admin https://localhost:9200Installare Filebeat
# Installare Filebeat
sudo apt install -y filebeat
# Scaricare il modulo Wazuh per Filebeat
curl -so /etc/filebeat/wazuh-filebeat-module.tar.gz \
https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.4.tar.gz
# Estrarre il modulo nella directory corretta
sudo tar -xvzf /etc/filebeat/wazuh-filebeat-module.tar.gz -C /usr/share/filebeat/module/
# Configurare la connessione al Wazuh Indexer nel file filebeat.yml
# Avviare e abilitare Filebeat
sudo systemctl start filebeat
sudo systemctl enable filebeatRegistrazione degli Agenti Linux
Con il server operativo, è il momento di installare gli agenti sugli endpoint da monitorare. La buona notizia è che la registrazione automatica semplifica parecchio il processo.
Installare l'Agente su un Endpoint Linux
# Su Ubuntu/Debian - importare il repository e installare l'agente
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
sudo apt update && sudo apt install -y wazuh-agent
# Configurare l'indirizzo del Manager
sudo sed -i 's/MANAGER_IP/192.168.1.100/g' /var/ossec/etc/ossec.conf
# Avviare e abilitare l'agente
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
# Verificare la connessione al Manager
sudo /var/ossec/bin/wazuh-control statusRegistrazione tramite Variabili d'Ambiente
Per deployment automatizzati (Ansible, Terraform, script di provisioning), le variabili d'ambiente durante l'installazione sono la strada migliore:
# Installazione con registrazione automatica
WAZUH_MANAGER="192.168.1.100" \
WAZUH_AGENT_GROUP="linux-servers" \
WAZUH_AGENT_NAME="web-server-01" \
sudo apt install -y wazuh-agentVerificare lo Stato degli Agenti
Dal server Manager, potete controllare lo stato di tutti gli agenti registrati:
# Elencare tutti gli agenti registrati
sudo /var/ossec/bin/manage_agents -l
# Verificare lo stato con l'API REST
curl -k -u admin:admin https://localhost:55000/agents?pretty
# Controllare la connettività degli agenti
sudo /var/ossec/bin/agent_control -lcFile Integrity Monitoring (FIM): Configurazione Avanzata
Il monitoraggio dell'integrità dei file è onestamente una delle funzionalità più potenti di Wazuh. Il modulo FIM rileva la creazione, modifica e cancellazione di file nelle directory monitorate, generando alert quando qualcosa cambia rispetto alla baseline. E quando dico "qualcosa", intendo anche le modifiche più subdole ai permessi o ai metadati.
Configurazione Base del FIM
La configurazione FIM avviene nel blocco <syscheck> del file /var/ossec/etc/ossec.conf:
<syscheck>
<!-- Abilitare il modulo FIM -->
<disabled>no</disabled>
<!-- Frequenza di scansione in secondi (3600 = ogni ora) -->
<frequency>3600</frequency>
<!-- Eseguire una scansione all'avvio dell'agente -->
<scan_on_start>yes</scan_on_start>
<!-- Directory critiche del sistema con monitoraggio 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">/sbin</directories>
<directories check_all="yes" realtime="yes">/bin</directories>
<!-- File di configurazione web con report delle modifiche -->
<directories check_all="yes" realtime="yes" report_changes="yes">/var/www</directories>
<!-- Directory home degli utenti -->
<directories check_all="yes" realtime="yes">/home</directories>
<!-- File sensibili da monitorare individualmente -->
<directories check_all="yes" realtime="yes">/root/.ssh</directories>
<directories check_all="yes" realtime="yes" report_changes="yes">/etc/sudoers</directories>
<!-- Escludere directory rumorose -->
<ignore>/etc/mtab</ignore>
<ignore type="sregex">^/proc</ignore>
<ignore type="sregex">.log$|.swp$</ignore>
</syscheck>Modalità Who-Data con eBPF (Novità 2026)
A partire da Wazuh 4.12, il modulo FIM supporta eBPF su Linux per il monitoraggio who-data, superando finalmente le limitazioni del tradizionale Auditd. Questa modalità arricchisce gli alert con informazioni dettagliate su chi e quale processo ha effettuato la modifica — informazioni che fanno tutta la differenza durante un'indagine forense:
<!-- Configurazione FIM con who-data abilitato -->
<directories check_all="yes" whodata="yes">/etc/ssh</directories>
<directories check_all="yes" whodata="yes">/etc/pam.d</directories>
<directories check_all="yes" whodata="yes">/etc/cron.d</directories>
<directories check_all="yes" whodata="yes" report_changes="yes">/etc/sudoers.d</directories>Con who-data abilitato, ogni alert FIM includerà campi come audit.user.name, audit.process.name e audit.process.ppid, fornendo un contesto forense davvero prezioso.
Report delle Modifiche per File Critici
L'attributo report_changes è fondamentale per i file di configurazione sensibili. Quando abilitato, Wazuh salva una copia del file prima della modifica e mostra le differenze nell'alert:
<!-- Monitorare le modifiche esatte ai file di configurazione -->
<directories check_all="yes" realtime="yes" report_changes="yes">/etc/ssh/sshd_config</directories>
<directories check_all="yes" realtime="yes" report_changes="yes">/etc/nginx/nginx.conf</directories>
<directories check_all="yes" realtime="yes" report_changes="yes">/etc/apache2/apache2.conf</directories>Attenzione però: usate report_changes con cautela. Wazuh crea una copia di ogni file monitorato nella directory /var/ossec/queue/diff/, e questo può far lievitare lo storage su directory con molti file. L'ho imparato a mie spese su un server con migliaia di file di configurazione.
Active Response: Risposte Automatiche alle Minacce
L'Active Response è la funzionalità che trasforma Wazuh da sistema passivo (rileva e basta) a sistema attivo (rileva e reagisce). Quando un alert soddisfa determinati criteri, Wazuh può eseguire automaticamente script di mitigazione sugli endpoint.
Come Funziona l'Active Response
Il meccanismo si basa su tre elementi:
- Regola di trigger: un alert con un determinato ID, livello o gruppo di regole
- Comando: lo script o l'eseguibile da lanciare
- Configurazione Active Response: dove, quando e per quanto tempo eseguire il comando
Semplice, ma enormemente potente.
Esempio 1: Blocco Automatico di Attacchi Brute-Force SSH
Questo è probabilmente lo scenario più comune: bloccare automaticamente gli IP che tentano ripetuti accessi SSH falliti.
<!-- In /var/ossec/etc/ossec.conf sul Manager -->
<!-- Definizione del comando -->
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<!-- Configurazione Active Response per brute-force SSH -->
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5763</rules_id>
<timeout>600</timeout>
</active-response>Con questa configurazione, quando Wazuh rileva un tentativo di brute-force SSH (regola 5763), aggiunge automaticamente l'IP sorgente nelle regole iptables/nftables dell'endpoint, bloccandolo per 600 secondi (10 minuti). Niente male per poche righe di XML.
Esempio 2: Risposta Basata sul Livello di Severità
<!-- Bloccare la sorgente per qualsiasi alert di livello 10 o superiore -->
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location>
<level>10</level>
<timeout>900</timeout>
</active-response>
<!-- Disabilitare un account utente dopo tentativi di escalation -->
<command>
<name>disable-account</name>
<executable>disable-account</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<disabled>no</disabled>
<command>disable-account</command>
<location>local</location>
<rules_group>authentication_failure,</rules_group>
<timeout>3600</timeout>
</active-response>Script di Active Response Personalizzato
Per scenari specifici, potete creare i vostri script personalizzati. Ecco un esempio che invia una notifica via webhook quando viene rilevato un file sospetto:
#!/bin/bash
# /var/ossec/active-response/bin/notify-webhook.sh
# Script personalizzato di Active Response per notifiche webhook
LOCAL=$(dirname $0)
cd $LOCAL
cd ../
PWD=$(pwd)
WEBHOOK_URL="https://hooks.slack.com/services/XXXXX/XXXXX/XXXXX"
# Leggere l'input JSON da STDIN
read INPUT_JSON
# Estrarre informazioni rilevanti dall'alert
ALERT_LEVEL=$(echo $INPUT_JSON | python3 -c "import sys,json; print(json.load(sys.stdin).get('parameters',{}).get('alert',{}).get('rule',{}).get('level','N/A'))")
RULE_DESC=$(echo $INPUT_JSON | python3 -c "import sys,json; print(json.load(sys.stdin).get('parameters',{}).get('alert',{}).get('rule',{}).get('description','N/A'))")
AGENT_NAME=$(echo $INPUT_JSON | python3 -c "import sys,json; print(json.load(sys.stdin).get('parameters',{}).get('alert',{}).get('agent',{}).get('name','N/A'))")
# Inviare notifica via webhook
curl -s -X POST -H "Content-Type: application/json" \
-d "{\"text\":\"[Wazuh Alert] Livello: ${ALERT_LEVEL} | Agente: ${AGENT_NAME} | ${RULE_DESC}\"}" \
"$WEBHOOK_URL"
exit 0;Per attivare lo script personalizzato, configuratelo nel Manager:
# Impostare i permessi corretti sullo script
sudo chmod 750 /var/ossec/active-response/bin/notify-webhook.sh
sudo chown root:wazuh /var/ossec/active-response/bin/notify-webhook.sh
# Aggiungere la configurazione in ossec.conf
# <command>
# <name>notify-webhook</name>
# <executable>notify-webhook.sh</executable>
# <timeout_allowed>no</timeout_allowed>
# </command>
#
# <active-response>
# <disabled>no</disabled>
# <command>notify-webhook</command>
# <location>server</location>
# <level>12</level>
# </active-response>Regole Personalizzate: Adattare Wazuh al Vostro Ambiente
Le regole predefinite di Wazuh coprono un'ampia gamma di scenari, ma ogni ambiente ha le proprie particolarità. Ed è proprio qui che le regole personalizzate diventano indispensabili: permettono di creare rilevamenti su misura per le vostre applicazioni, i vostri workflow e le vostre policy di sicurezza.
Struttura delle Regole Wazuh
Le regole personalizzate vanno create nel file /var/ossec/etc/rules/local_rules.xml. Usate ID tra 100000 e 120000 per evitare conflitti con le regole di sistema:
<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,custom_rules,">
<!-- Rilevare tentativi di accesso root via SSH -->
<rule id="100001" level="12">
<if_sid>5716</if_sid>
<user>root</user>
<description>Tentativo di accesso SSH come root - violazione della policy.</description>
<group>authentication_failure,policy_violation,</group>
</rule>
<!-- Rilevare modifiche al file sudoers -->
<rule id="100002" level="14">
<if_sid>550</if_sid>
<match>/etc/sudoers</match>
<description>Modifica al file sudoers rilevata - possibile escalation di privilegi.</description>
<group>syscheck,privilege_escalation,</group>
</rule>
<!-- Rilevare l'installazione di nuovi pacchetti -->
<rule id="100003" level="7">
<if_sid>2902</if_sid>
<match>installed|upgraded</match>
<description>Nuovo pacchetto installato o aggiornato sul sistema.</description>
<group>package_management,change_management,</group>
</rule>
<!-- Rilevare comandi sospetti eseguiti come root -->
<rule id="100004" level="10">
<if_sid>5402</if_sid>
<match>wget|curl|nc |ncat |python.*-c|bash.*-i|chmod.*777</match>
<description>Comando potenzialmente pericoloso eseguito tramite sudo.</description>
<group>suspicious_command,audit,</group>
</rule>
<!-- Rilevare tentativi di accesso SSH da reti non autorizzate -->
<rule id="100005" level="13">
<if_sid>5715</if_sid>
<srcip>!192.168.1.0/24</srcip>
<description>Accesso SSH riuscito da IP esterno alla rete autorizzata.</description>
<group>authentication_success,policy_violation,</group>
</rule>
</group>Decoder Personalizzati per Log Applicativi
Se le vostre applicazioni generano log in formati particolari, potete creare decoder ad hoc. I decoder personalizzati vanno inseriti in /var/ossec/etc/decoders/local_decoder.xml:
<!-- /var/ossec/etc/decoders/local_decoder.xml -->
<!-- Decoder per log personalizzati di un'applicazione web -->
<decoder name="myapp">
<prematch>^MyApp:</prematch>
</decoder>
<decoder name="myapp-auth">
<parent>myapp</parent>
<regex>^MyApp: AUTH_FAILED user=(\S+) from=(\S+)</regex>
<order>user,srcip</order>
</decoder>
<!-- Regola corrispondente per il decoder -->
<!-- Da aggiungere in local_rules.xml -->
<!--
<rule id="100010" level="8">
<decoded_as>myapp-auth</decoded_as>
<description>Autenticazione fallita nell'applicazione MyApp.</description>
<group>myapp,authentication_failure,</group>
</rule>
-->Testare e Applicare le Regole
# Validare la sintassi delle regole personalizzate
sudo /var/ossec/bin/wazuh-logtest
# Nella console logtest, incollare una riga di log di esempio
# per verificare che venga correttamente decodificata e associata alla regola
# Dopo la validazione, riavviare il Manager per applicare
sudo systemctl restart wazuh-manager
# Verificare che non ci siano errori nei log
sudo tail -f /var/ossec/logs/ossec.log | grep -i errorRilevamento delle Vulnerabilità e Conformità
Wazuh include un modulo di Vulnerability Detection che analizza automaticamente i pacchetti installati sugli endpoint e li confronta con i database CVE aggiornati. È una di quelle funzionalità che, una volta attivata, vi chiederete come facevate prima senza. Nella versione 4.12 è stato aggiunto il supporto CTI (Cyber Threat Intelligence) con link diretti alle informazioni sulle CVE.
Abilitare il Vulnerability Detector
<!-- In /var/ossec/etc/ossec.conf sul Manager -->
<vulnerability-detector>
<enabled>yes</enabled>
<interval>5m</interval>
<min_full_scan_interval>6h</min_full_scan_interval>
<run_on_start>yes</run_on_start>
<!-- Feed NVD (National Vulnerability Database) -->
<provider name="nvd">
<enabled>yes</enabled>
<update_interval>1h</update_interval>
</provider>
<!-- Feed per distribuzioni Debian/Ubuntu -->
<provider name="canonical">
<enabled>yes</enabled>
<os>jammy</os>
<os>noble</os>
<update_interval>1h</update_interval>
</provider>
<!-- Feed per distribuzioni RHEL -->
<provider name="redhat">
<enabled>yes</enabled>
<os>9</os>
<update_interval>1h</update_interval>
</provider>
</vulnerability-detector>Security Configuration Assessment (SCA)
Il modulo SCA verifica automaticamente la configurazione degli endpoint rispetto ai CIS Benchmarks e altre policy di sicurezza. Wazuh 4.14.3 include una nuova policy SCA per Distribution Independent Linux, estendendo la copertura anche a distribuzioni meno comuni:
<!-- Verificare le policy SCA attive -->
<!-- In /var/ossec/etc/ossec.conf sull'agente -->
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
<skip_nfs>yes</skip_nfs>
</sca>Le policy SCA disponibili coprono i benchmark CIS per Ubuntu, Debian, RHEL, CentOS, SUSE e — novità della 4.14.3 — macOS 26 Tahoe. Trovate i risultati dell'assessment nella dashboard sotto Modules > Security Configuration Assessment.
Integrazione con Suricata per IDS di Rete
Wazuh eccelle nel rilevamento basato sull'host (HIDS), ma per una protezione davvero completa serve anche un'analisi del traffico di rete. L'integrazione con Suricata combina il meglio di entrambi i mondi, e la configurazione è più semplice di quanto potreste pensare.
Configurare Wazuh per Leggere i Log di Suricata
<!-- In /var/ossec/etc/ossec.conf sull'agente con Suricata installato -->
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>Wazuh include già i decoder e le regole per parsare i log JSON di Suricata. Una volta configurato, gli alert di rete appariranno nel dashboard insieme a quelli host-based, fornendovi una visione unificata della sicurezza. È proprio il tipo di integrazione che rende Wazuh così efficace come piattaforma centralizzata.
Hardening del Server Wazuh
Il server Wazuh stesso è un asset critico — e questo è un punto che spesso viene sottovalutato. Se un attaccante lo compromette, può disabilitare il monitoraggio su tutti gli endpoint in un colpo solo. Ecco le best practice per proteggerlo.
Sicurezza delle Comunicazioni
# Verificare che tutti i certificati TLS siano validi
sudo /var/ossec/bin/wazuh-authd -t
# Ruotare i certificati periodicamente
# I certificati si trovano in:
# /var/ossec/etc/sslmanager.cert
# /var/ossec/etc/sslmanager.key
# Limitare l'accesso all'API REST con firewall
# Solo IP autorizzati dovrebbero raggiungere la porta 55000
sudo nft add rule inet filter input tcp dport 55000 ip saddr != { 192.168.1.0/24 } dropProteggere le Credenziali
# Utilizzare il keystore di Wazuh per le credenziali sensibili
# invece di salvarle in chiaro nei file di configurazione
sudo /var/ossec/bin/wazuh-keystore -f indexer -k username -v admin
sudo /var/ossec/bin/wazuh-keystore -f indexer -k password -v PasswordSicura123!
# Limitare i permessi sul file di configurazione
sudo chmod 640 /var/ossec/etc/ossec.conf
sudo chown root:wazuh /var/ossec/etc/ossec.confBackup della Configurazione
# Script di backup giornaliero per la configurazione Wazuh
#!/bin/bash
BACKUP_DIR="/backup/wazuh/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"
# Backup delle configurazioni
cp -r /var/ossec/etc/ "$BACKUP_DIR/etc/"
cp -r /var/ossec/rules/ "$BACKUP_DIR/rules/"
cp -r /var/ossec/decoders/ "$BACKUP_DIR/decoders/"
# Backup del database degli agenti
cp /var/ossec/var/db/agents/ "$BACKUP_DIR/agents/" -r
# Comprimere il backup
tar -czf "$BACKUP_DIR.tar.gz" "$BACKUP_DIR"
rm -rf "$BACKUP_DIR"
# Mantenere solo gli ultimi 30 giorni di backup
find /backup/wazuh/ -name "*.tar.gz" -mtime +30 -deleteNovità di Wazuh 4.14.3 (Febbraio 2026)
La versione 4.14.3, rilasciata l'11 febbraio 2026, porta con sé diversi miglioramenti che vale la pena conoscere:
- Hardening del cluster: i percorsi di scrittura per il trasferimento file nel cluster sono ora ristretti, riducendo la superficie d'attacco
- Deserializzazione sicura: la decodifica nel cluster è stata rafforzata limitando i callable a moduli Wazuh, prevenendo attacchi di deserializzazione
- Prevenzione buffer overflow: aggiunti controlli sulle dimensioni delle query nel decoder SCA e nella generazione SQL di Syscollector
- Metadati agente migliorati: hostname e architettura vengono ora inclusi nei messaggi keep-alive di Windows
- Performance autenticazione: le coppie di chiavi generate vengono ora memorizzate in cache, con pulizia automatica quando i file chiave cambiano
- Nuova policy SCA per macOS 26 Tahoe
- Gestione agenti dal Dashboard: possibilità di rimuovere agenti direttamente dalla pagina Summary
Domande Frequenti (FAQ)
Qual è la differenza tra Wazuh e OSSEC?
Wazuh è nato come fork di OSSEC nel 2015 e da allora ha preso una direzione ben diversa. Le differenze principali? Wazuh include una dashboard web integrata, supporto per cloud e container, un motore di vulnerability detection, architettura distribuita e scalabile, integrazione nativa con OpenSearch e aggiornamenti regolari (la versione corrente è la 4.14.3). OSSEC resta una soluzione HIDS più leggera e semplice, ma il suo sviluppo si è praticamente fermato — l'ultimo rilascio stabile risale al 2021.
Quanti agenti può gestire un singolo server Wazuh?
Un'installazione all-in-one su un server con 16 GB di RAM e 8 core gestisce tranquillamente 100-200 agenti. Per deployment più grandi (500+ agenti), Wazuh supporta un'architettura distribuita multi-nodo con cluster di Manager e Indexer separati. Organizzazioni con migliaia di endpoint utilizzano architetture con bilanciamento del carico e nodi Indexer dedicati.
Wazuh è adatto alla conformità GDPR e PCI-DSS?
Assolutamente sì. Wazuh include moduli specifici per la conformità normativa. Il File Integrity Monitoring soddisfa il requisito PCI DSS 11.5, il Vulnerability Detection copre il requisito 6.1 e il modulo SCA verifica la conformità ai CIS Benchmarks. Per il GDPR, Wazuh fornisce monitoraggio dell'accesso ai dati personali (Articolo 32), logging e audit trail (Articolo 30) e rilevamento di violazioni dei dati (Articolo 33). I report di conformità si generano direttamente dalla dashboard.
Come integrare Wazuh con Suricata per un IDS completo?
L'integrazione è più semplice di quanto sembri. Installate Suricata sull'endpoint, configurate l'agente Wazuh per leggere i log JSON di Suricata (/var/log/suricata/eve.json) con formato json, e Wazuh utilizzerà i decoder e le regole già inclusi per parsare gli alert di rete. Il risultato è una piattaforma unificata che combina rilevamento host-based e network-based in un'unica dashboard.
Posso eseguire Wazuh in Docker per ambienti di test?
Certo che sì. Wazuh fornisce immagini Docker ufficiali e file docker-compose per deployment containerizzati. È perfetto per ambienti di sviluppo, laboratori di sicurezza e valutazioni preliminari. Il deployment Docker include Manager, Indexer e Dashboard in un unico stack che può essere operativo in pochi minuti. Per la produzione però vi consiglio l'installazione nativa: prestazioni e affidabilità sono su un altro livello.