En el laboratorio de hoy verificar el modulo de detector de vulnerabilidades, añadir mas clientes y configuralo para clientes no soportados pero si compatibles.
El mapa del laboratorio es el siguiente:
+----------+ +--------+ +----------+
| | | | | |<--> Lan 10.0.0.1/28
| | | | | Firewall |
| Internet |<---> | Router |<---Wan--->| OPNsense |<--> DMZINT 10.0.0.17/28
| | | | | |
| | | | | |<--> DMZEXT 10.0.0.33/28
+----------+ +--------+ +----------+
IP | Hostname | S.O. | Zona |
---|---|---|---|
10.0.0.2 | db1000-01 | Debian 10 Desktop | Lan |
10.0.0.3 | w1000-01 | Winodws 10 | Lan |
10.0.0.6 | ub200400-01 | Ubuntu 20.04 Server | Lan |
10.0.0.22 | w201900-01 | Windows 2019 Server | DMZINT |
Revisando los hosts ya vemos que se aplican los escaneos, si nos fijamos en ub200400-01 podemos observar lo siguiente:
Nos conectamos al host y realizamos una actualización del sistema y al pasar el siguiente escaneo cambian los valores:
Como se puede observar se solucionan alguno de los problemas detectados. Ahora que ya sabemos que funciona la siguiente es por quien corresponda revisar los problemas de seguridad y ver como solucionarlos.
Una de las cosas que me parecen muy interesantes es que se pueden realizar búsquedas por un CVE determinado y ver cuando se resolvió para realizar un seguimiento del estado. Vamos a ver un ejemplo, utilizamos como filtro data.vulnerability.cve:CVE-2022-28693 esto nos muestra en la tabla por el timestamp como fue evolucionando según los escaneod en el tiempo de resolución:
Ahora vamos a realizar la misma operativa con un entorno Microsoft en nuestro hosts w201900-01 y tenemos lo siguiente:
Actualizamos nuestro sistema Windows y como no nos solicitara reiniciar. Al revisar de nuevo el nuestro Wazuh esta todo limpio como la patena.
Tengo desplegado un hosts en la DMZEXT llamado rk86000-01 que tiene instalado Rocky Linux como servidor en su version 8.6 vamos a instalar el cliente en una versión anterior para catalizar desde el servidor de Wazuh.. Luego lo añadiremos al grupo Linux y veremos que ajusta las configuraciones automáticamente.
Pues ya lo tenemos desplegado pero observar la versión del agente:
Como lo desplegamos con otra versión aquí se ve perfectamente. Esta en versión 4,2,7. Pues bien vamos a actualizar desde nuestro servidor Wazuh. Nos conectamos como ssh y como root ejecutamos:
#cd /var/ossec/bin
#./agent_control -l
#./agent_upgrade -a 005
Como podemos observar tarda un poco la actualizar y al finalizar nos indica de que versión a que versión pasa el agente.
Pues ya lo tenemos:
Bueno ahora lo añadimos al grupo Linux para que también se ejecute el modulo de detección de vulnerabilidades:
#./agent_groups -a -i 005 -g Linux
Do you want to add the group 'Linux' to the agent '005'? [y/N]: y
Group 'Linux' added to agent '005'.
Como podemos observar el agente ya esta en el grupo correspondiente:
Con lo cual damos por echo que al ser un sistema Linux basado en RedHat al ir al hosts dentro de vulnerabilidades tendríamos que ver su estado. Pues bien no es así. Vale reiniciamos en agente desde la consola en remoto:
#./agent_control -R -u 005
Wazuh agent_control: Restarting agent: 005
Seguimos sin datos:
Pues bien vamos a solucionar este problema, tenemos los siguientes datos:
#sqlite3 /var/ossec/queue/db/global.db "SELECT OS_NAME, OS_MAJOR FROM AGENT WHERE ID = 5;"
Rocky Linux|8
Ya con los datos anteriores editamos el fichero ossec.conf y buscamos la seccion donde se configura el modulo de detección de vulnerabilidades, mas concretamente la sección de RedHat y lo configuramos de la siguiente manera:
<!-- RedHat OS vulnerabilities -->
<provider name="redhat">
<enabled>yes</enabled>
<os>5</os>
<os>6</os>
<os>7</os>
<os>8</os>
<os allow="Rocky Linux-8">8</os>
<update_interval>1h</update_interval>
</provider>
Reiniciamos el servicio del manager:
systemctl restart wazuh-manager
Ya lo tenemos listo y funcionado, primer escaneo realizado. Ahora a trabajar.
Otro laboratorio mas. Continuara.