Wazuh – Vulnerability detection
Grazie all’integrazione dei feed di vulnerabilità delle maggiori distribuzioni Linux (Canonical/Ubuntu, Debian, RedHat/CentOS e NVD – National Vulnerability Database), Wazuh è in grado di rilevare vulnerabilità nelle applicazioni installate negli agenti utilizzando il modulo Vulnerability Detection. Wazuh è anche in grado di riconoscere le vulnerabilità di Windows (indicizzate come CVE) rilevando gli hotfix installati.
Il motore di Wazuh crea un database di vulnerabilità locale utilizzando i CVE pubblici; successivamente confronta le informazioni ricevute dagli agent circa i SO e i le applicazioni installate e le confronta con i dati in proprio possesso, presentando all’utente le vulnerabilità di cui i sistemi sono affetti.
Il primo passo per abilitare la ricerca di vulnerabilità, è quella di aprire il file di configurazione di Wazuh-Agent ( /var/ossec/etc/ossec.conf ) e abilitare il modulo syscollector (abilitato di default):
<wodle name="syscollector"> <disabled>no</disabled> <interval>1h</interval> ==> Tempo tra scansioni di sistema <scan_on_start>yes</scan_on_start> <hardware>yes</hardware> ==> Abilita la scansione dell'HW <os>yes</os> ==> Abilita la scansio del SO <network>yes</network> ==> Abilita la scansione del network <packages>yes</packages> ==> Abilita le scansioni delle applicazioni <ports all="no">yes</ports> ==> Abilita la scansione delle porte (ALL=no ==> solo le porte in LISTENING) <processes>yes</processes> ==> Abilita la scansion dei processi </wodle>
Se si desidera eseguire la scansione delle vulnerabilità negli agenti Windows, è necessario aggiungere anche le os e hotfixes:
<wodle name="syscollector"> <disabled>no</disabled> <interval>1h</interval> <packages>yes</packages> <os>yes</os> <hotfixes>yes</hotfixes> </wodle>
Sul server di Wazuh, abilitiamo il modulo di gestione delle vulnerabilità; apriamo il file di configurazione di Wazuh-Manager ( /var/ossec/etc/ossec.conf ) e lo abilitiamo per Debian, RedHat (CentOS) e NVD:
<vulnerability-detector> <enabled>yes</enabled> <interval>5m</interval> ==> Tempo tra scansioni di vulnerabilità <ignore_time>6h</ignore_time> ==> Tempo durante il quale le vulnerabilità che sono già state trovate verranno ignorate. <run_on_start>yes</run_on_start> <provider name="canonical"> <enabled>no</enabled> <os>trusty</os> <os>xenial</os> <os>bionic</os> <update_interval>1h</update_interval> </provider> <provider name="debian"> <enabled>yes</enabled> <os>wheezy</os> <os>stretch</os> <os>jessie</os> <os>buster</os> <update_interval>1h</update_interval> </provider> <provider name="redhat"> <enabled>yes</enabled> <update_from_year>2010</update_from_year> <update_interval>1h</update_interval> </provider> <provider name="nvd"> <enabled>yes</enabled> <update_from_year>2010</update_from_year> <update_interval>1h</update_interval> </provider> </vulnerability-detector>
Riavviamo wazuh-manager ramite systemd:
# systemctl restarty wazuh-manager
Una volta che gli agent hanno effettuato le collect dei dati necessari e li hanno trasmessi al manager, il manager può rilevare la presenza di vulnerabilità note. Tale informazioni potranno essere analizzate tramite Kibana nell’app di Wazuh:
Applichiamo un filtro per vedere solo le vulnerabilità critiche rilevate da Wazuh:
In questo caso, Wazuh ha rilevato che ci sono 3 sistemi con livelli critici di vulnerabilità; la vulnerabilità è la stessa per tutti i sistemi (CVE-2019-11043); accedendo alla pagina indicata, possiamo avere maggiori informazioni circa la vulnerabilità segnalata:
In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it is possible to cause FPM module to write past allocated buffers into the space reserved for FCGI protocol data, thus opening the possibility of remote code execution.
A questo punto possiamo prendere le contromisure necessarie per mitigare la vulnerabilità (ad esempio come indicato nella pagina CVE) o eliminarla completamente (effettuando un upgrade di PHP ad esempio).
Di seguito vedremo alcuni esempi pratici su come scovare ed eventualmente correggere/reagire ad eventi “tipici” nei nostri network (attacchi di tipo brute-force, cambiamenti sui file-systems in aree sensibili, ….)