Escrito por Daniel Olivares
Introducción
Continuando nuestra serie de artículos para mejorar la seguridad de nuestras PYMES y Hogar, hoy presentamos la quinta parte: “Securizando tu red: Instalación certificado e instalación de agentes”. Si no has visto los artículos anteriores acá está la lista completa:
- Securitizando tu red: Instalando servidores de Wazuh (Parte 4)
- Securitizando tu red: Sysmon y AuditD (Parte 3)
- Securitizando tu red: SQUID (Parte 2)
- Securitizando tu red: Pi-Hole (Parte 1)
Si has seguido nuestros artículos anteriores, la red debería verse de la siguiente manera:

Donde tendremos instalado:
- El cluster de Wazuh (Indexer, Server y Dashboard)
- Un servidor PiHole (DNS)
- Un servidor SQUID (Proxy)
- Una máquina Windows con SYSMON instalado
- Una máquina Linux con AuditD instalado
El acceso hacia el Dashboard de Wazuh es utilizando la IP, con certificado SSL autofirmado, pero no reconocido como válido (candado rojo) y lo más importante:
¡Ningún equipo está enviando LOG hacía Wazuh!
Por lo que en este articulo nos enfocaremos en:
- Creación de registro DNS para facilitar el acceso hacía el servidor Wazuh
- Creación de una Autoridad Certificadora (CA) y un certificado auto-firmado valido para ser utilizado en el servidor Wazuh
- Instalación de agente Wazuh en equipos Windows y Linux para el envío de logs básicos.
Actualmente tenemos que el ingreso al Dashboard de Wazuh se realiza utilizando la IP del servidor en la URL de acceso, sumado al hecho de que el certificado SSL es autofirmado y no válido para los navegadores. Estas son dos situaciones que buscamos evitar y que son fácilmente solucionables con los equipos que contamos.
Aprovecharemos que tenemos un servidor DNS, donde crearemos el FQDN de acceso al Dashboard Wazuh. Luego crearemos nuestra propia Autoridad Certificadora (CA), para generar el certificado SSL del Dashboard y firmarlo con la CA para que sea válido.
Haciendo esto mejoraremos:
- Autenticación del servidor: Los certificados SSL válidos, incluyen información sobre la identidad del sitio web y su propiedad. Esto permite a los usuarios asegurar que se están conectando al sitio web correcto y no un sitio web falso o comprometido.
- Protección contra ataques de intermediarios: Al usar certificados SSL valido, aumenta la posibilidad de detectar ataques de intermediarios, como el ataque “Man-in-the-Middle“.
- Mejora de la confianza del usuario: Los certificados SSL válidos muestran un candado o un icono de “HTTPS” en el navegador web, lo que indica que la conexión es segura. Esto ayuda a aumentar la confianza de los usuarios en el sitio web.
Para realizar la configuración del registro DNS, debemos agregar un registro A en tú servidor DNS. En este caso utilizaremos PiHole como servidor DNS y agregaremos el registro tipo A wazuh-lab.aconetwork.cl apuntando a la IP 20.20.20.12 (Wazuh Dashboard).
Creación del registro DNS
Para esto iniciamos sesión en el portal de administración web y nos dirigimos a “Local DNS à DNS Records”

Y luego agregamos el registro como se muestra en la siguiente imagen:

Ahora podremos ingresar utilizando el registro FQDN, pero seguiremos viendo un mensaje de advertencia debido a el certificado SSL no está firmado.

Para solucionar esto, crearemos nuestra propia autoridad certificadora (CA) y la utilizaremos para firmar el certificado que utilizaremos en el portal de Wazuh.
Creación de Autoridad Certificadora (CA)
Nos conectaremos al servidor “Wazuh Dashboard” por SSH y utilizaremos openssl para la creación de los certificados.
En caso de no tener instalado openssl en nuestro servidor, utilizaremos el siguiente comando:
Ubuntusudo apt install openssl |
Centossudo yum install openssl |
Para verificar la versión instalada podemos utilizar el siguiente comando:
openssl version
Luego crearemos la llave de nuestra CA con el siguiente comando:
openssl genrsa -aes256 -out aconetwork-lab-CA.key 2048

Durante la generación de la llave, nos pedirá que ingresemos una contraseña. ¡GUARDALA! Está será requerida al momento de usar utilizando nuestra CA en el futuro.
La siguiente tabla detalla los aspectos más importantes del comando:
| Campo | Descripción |
|---|---|
| openssl | Comando para utilizar la biblioteca openssl |
| genrsa | Subcomando que le indica a openssl que debe crear una clave privada RSA |
| -aes256 | La clave privada que utilizaremos para proteger el uso de la CA será encriptada por AES256. |
| -out | Es flag permite especificar el nombre del archivo de salida. |
| 2048 | Se especifica la longitud de la clave RSA en bits. En este caso utilizaremos 2048, pero puedes utilizar 1024 (no recomendado) o 4096 por ejemplo. |
Ahora crearemos el certificado CRT que nos servirá como certificado asociado a nuestra CA:
openssl req -x509 -new -nodes -key aconetwork-lab-CA.key -sha256 -days 1825 -out aconetwork-lab-CA.crt

Durante la creación del certificado deberemos ingresar la contraseña que utilizamos para crear la llave y luego deberemos completar algunos campos. La siguiente tabla detalla los aspectos más importantes del comando:
| Campo | Descripción |
|---|---|
| openssl | Comando para utilizar la biblioteca openssl |
| req | Subcomando que permite procesar solicitudes de firmado (CSR) para generar nuevos certificados |
| -x509 | Esta opción indica que generaremos un certificado auto firmado por nuestra CA |
| -new | Esta opción indica que se generará un nuevo certificado en vez de renovar uno. |
| -nodes | Esta opción indica que no se debe encriptar la clave privada. |
| -key | Permite especificar cual será el archivo llave que utilizaremos para firmar el certificado. |
| -sha256 | Especificar el algoritmo de hash que utilizaremos para firmar el certificado. |
| -days | Número de días que será válida nuestra CA, en nuestro comando utilizamos 1825 días, que equivaldría a 5 años aproximadamente. |
| -out | Es flag permite especificar el nombre del archivo de salida. |

También se solicitará que agreguemos la información del certificado durante la creación, si bien son opciones y pueden quedar en blanco, es recomendable llenarnos correctamente. La siguiente tabla detalla los aspectos más importantes del comando:
| Campo | Descripción |
|---|---|
| Código de País | Código de país en formato ISO 3166 en formato de dos letras, para chile es CL. En caso de querer utilizar otro país en el siguiente enlace puedes encontrar los códigos por país. List of country codes |
| Nombre del estado o provincia | El nombre de la provincia o estado del certificado, en este caso será “Santiago |
| Nombre de la localidad o ciudad | Nombre de la ciudad del certificado, en este caso también será “Santiago” |
| Nombre de la organización | El nombre de la organización que está creando el certificado, en este caso “Aconetwork” |
| Nombre de la unidad organizativa | Nombre de la unidad organizativa del certificado, en este caso “TI”. |
| Nombre común | Nombre común del certificado, en este caso será aconetwork.cl. |
| Dirección de correo electrónico | Correo electrónico del responsable del certificado. |
Creación del certificado propio
Una vez creada nuestra CA, podremos continuar con el certificado que instalaremos en el servidor “Wazuh Dashboard”.

Para este ejemplo utilizaremos el dominio aconetwork.cl, pero puedes utilizar el que tú definas.
Para esto utilizaremos los siguientes comandos para crear la llave.
openssl genrsa -out wazuh-lab.key 2048
A diferencia de cuando creamos nuestra CA, esta vez no utilizaremos el flag -AES256 por lo cual no se nos solicitará una contraseña para la creación. La siguiente tabla detalla los aspectos más importantes del comando:
| Campo | Descripción |
|---|---|
| openssl | Comando para utilizar la biblioteca openssl |
| genrsa | Subcomando que le indica a openssl que debe crear una clave privada RSA |
| -out | Es flag permite especificar el nombre del archivo de salida. |
| 2048 | Se especifica la longitud de la clave RSA en bits. En este caso utilizaremos 2048, pero puedes utilizar 1024 (no recomendado) o 4096 por ejemplo. |
Continuaremos creando el archivo de solicitud de firma de certificado (CSR) con el siguiente comando:
openssl req -new -sha256 \
-key wazuh-lab.key \
-subj "/C=CL/ST=Santiago/O=Aconetwork SPA/OU=Aconetwork/CN=aconetwork.cl" \
-reqexts SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:wazuh-lab.aconetwork.cl")) \
-out wazuh-lab.csr

La siguiente tabla detalla los aspectos más importantes del comando:
| Campo | Descripción |
|---|---|
| openssl | Comando para utilizar la biblioteca openssl |
| req | Subcomando que permite procesar solicitudes de firmado (CSR) para generar nuevos certificados |
| -x509 | Esta opción indica que generaremos un certificado auto firmado por nuestra CA |
| -new | Esta opción indica que se generará un nuevo certificado en vez de renovar uno. |
| -sha256 | Especificar el algoritmo de hash que utilizaremos para firmar el certificado. |
| -key | Permite especificar cual será el archivo llave que utilizaremos para firmar el certificado. |
| -subj | Aquí definiremos la información del certificado como: País: C Estado: ST Organización: O Unidad Organizativa: SPA/OU Nombre Común: CN |
| -reqexts | Esta opción indica que se incluirán extensiones en la CSR. En este caso, se agregarán extensiones para soportar Subject Alternative Name (SAN). |
| -config | Esta opción especifica el archivo de configuración OpenSSL que se utilizará para generar la CSR, incluyendo extensiones para SAN. En este caso crearemos el certificado utilizando solo un registro SAN, pero en caso de querer agregar más registros para utilizar solo un certificado podemos hacerlo de la siguiente manera: (printf “\n[SAN]\nsubjectAltName=DNS:aconetwork.cl,DNS:subdomain1.aconetwork.cl,DNS:subdomain2.aconetwork.cl”) También se puede generar un certificado wildcard. Este validará cualquier subdominio que utilicemos. (printf “\n[SAN]\nsubjectAltName=DNS:*.aconetwork.cl “) |
| -out | Es flag permite especificar el nombre del archivo de salida. |
Ahora solo nos quedaría el último paso el cual sería la firma de nuestro certificado. Para esto utilizaremos el siguiente comando:
openssl x509 -req -extfile <(printf "subjectAltName=DNS:wazuh-lab.aconetwork.cl") -days 1024 -in wazuh-lab.csr -CA aconetwork-lab-CA.crt -CAkey aconetwork-lab-CA.key -CAcreateserial -out wazuh-lab.crt -sha256

Durante la firma del certificado deberemos ingresar la contraseña que utilizamos durante la creación de la CA con la que firmaremos nuestra solicitud. La siguiente tabla detalla los aspectos más importantes del comando:
| Campo | Descripción |
|---|---|
| openssl | Comando para utilizar la biblioteca openssl |
| x509 | Subcomando de OpenSSL utilizado para manejar certificados X.509 |
| -req | Flag que permite procesar solicitudes de firmado (CSR) para generar nuevos certificados |
| -extfile | Especifica el archivo que contiene las extensiones que se agregarán al certificado. En caso de querer agregar más registros para utilizar solo un certificado podemos hacerlo de la siguiente manera: <(printf “subjectAltName= DNS:aconetwork.cl,DNS:subdomain1.aconetwork.cl,DNS:subdomain2.aconetwork.cl”) También se puede generar un certificado wildcard. Este validará cualquier subdominio que utilicemos. <(printf “subjectAltName= DNS:*.aconetwork.cl”) |
| -days | Número de días que será válido el certificado, en nuestro comando utilizamos 1024 días, que equivaldría a 3 años aproximadamente. |
| -in | Especifica el archivo de entrada que contiene la solicitud de certificado que se va a firmar. |
| -CA | Especifica el archivo de la CA que se utilizará para firmar la solicitud de certificado |
| -CAkey | Especifica la clave privada de la CA que se utilizará para firmar la solicitud de certificado. |
| -CAcreateserial | Indica que se debe crear un nuevo número de serie para el certificado. |
| -out | Es flag permite especificar el nombre del archivo de salida. |
| -sha256 | Especifica el algoritmo de hash que utilizaremos para firmar el certificado. |
Una vez creado el certificado que utilizaremos para el portal del servidor “Wazuh Dashboard”, verificaremos su información con el siguiente comando:
openssl x509 -in wazuh-lab.crt -noout -text

La siguiente tabla detalla los aspectos más importantes del comando:
| Campo | Descripción |
|---|---|
| openssl | Comando para utilizar la biblioteca openssl |
| x509 | Subcomando de OpenSSL utilizado para manejar certificados X.509 |
| -req | Flag que permite procesar solicitudes de firmado (CSR) para generar nuevos certificados |
| -in | Especifica el archivo de entrada que contiene la solicitud de certificado que se va a firmar. |
| -noout | Indica que la salida no debe incluir ninguna información adicional aparte del texto del certificado. Si no se utiliza esta opción, también se mostrarán otros detalles del certificado, como las fechas de validez y las extensiones. |
| -text | Indica que se debe mostrar el texto del certificado en un formato legible por humanos. |
Para no tener que escribir la información del certificado en cada paso (CN, ST, OU, etc), te dejo el link de un script para la creación de certificados CertificateCrafter.
Actualización de certificado SSL
Ahora tendremos que actualizar la configuración del servicio opensearch-dashboard con la ubicación de nuestros certificados. El archivo de configuración se encuentra en la ruta ““”/etc/wazuh-dashboard/opensearch_dashboards.yml”.
Pero antes deberemos convertir los archivos .crt y .key a .pem. Esto lo haremos con los siguientes comandos:
openssl x509 -in wazuh-lab.crt -outform PEM -out wazuh-lab_crt.pem
openssl rsa -in wazuh-lab.key -outform PEM -out wazuh-lab_key.pem
La siguiente tabla detalla los aspectos más importantes de los comandos:
| Campo | Descripción |
|---|---|
| openssl | Comando para utilizar la biblioteca openssl |
| x509 | Subcomando de OpenSSL utilizado para manejar certificados X.509 |
| rsa | Subcomando de OpenSSL utilizado para manipular claves RSA. |
| -in | Especifica el archivo de entrada que contiene la solicitud de certificado que se va a firmar. |
| -outform | Especifica el formato de salida deseado para la clave privada. “PEM” es un formato comúnmente utilizado para claves y certificados en OpenSSL y otros sistemas. “PEM” significa “Privacy Enhanced Mail” y es un formato de codificación de datos ASCII. |
| -out | Es flag permite especificar el nombre del archivo de salida. |
Luego copiaremos ambos certificados a la ruta “/etc/wazuh-dashboard/certs/”, para esto utilice el siguiente comando:
cp wazuh-lab_* /etc/wazuh-dashboard/certs/
Ahora modificaremos el owner y permisos de ambos certificados con los siguientes comandos:
chown -R wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/ wazuh-lab_*
chmod -R 500 /etc/wazuh-dashboard/certs/wazuh-lab_*
Ahora si modificaremos las directivas “server.ssl.key” y “server.ssl.certificate”, para que apunten a nuestros archivos .PEM:

Una vez actualizado, debemos guardar el archivo y reiniciar el servicio utilizando el siguiente comando:
systemctl restart wazuh-dashboard
Instalar certificado raíz en equipos finales
En este punto el Dashboard de Wazuh tiene instalado el certificado SSL firmado por nuestra CA para que pueda ser validado. Pero ninguno de nuestros equipos conoce la CA con la que debe validar el certificado de nuestro servidor. Para esto será necesario instalemos el certificado raíz en cada equipo que vaya a tener acceso al Dashboard Wazuh.
Instalar CA en Windows (Chrome/Edge)

Este paso se debe realizar solo si la CA que se utilizó para firmar el certificado no ha sido instalada. Si ese fuera el caso, este punto puede ser omitido.
Para que el certificado pueda ser validado por Chrome y Edge tenemos que instalarlo como un certificado raíz en nuestro sistema operativo Windows. Para Firefox tenemos una configuración un poco más adelante.
Para instalar la CA en nuestro Windows, lo primero que tenemos que hacer es descargarla a nuestro equipo. Esto podrás realizarlo mediante Filezilla o WinSCP, pero para este ejemplo utilizaremos el comando SCP desde la terminal debido a que viene incluido en el sistema operativo desde Windows 10.
scp [email protected]:/home/dolivares/aconetwork-lab-CA.crt C:\Users\\Escritorio\

Una vez descargada la CA en nuestro equipo, el daremos doble click y luego seleccionaremos “Instalar certificado”

A continuación, deberemos indicar la ubicación del llavero donde se guardará la CA. Para este caso seleccionaremos “Equipo local” y luego “siguiente”.

Luego definiremos el almacén donde se guardará la CA. Para esto seleccionamos “Colocar todos los certificados en el siguiente almacén” y seleccionamos “Entidades de certificación raíz de confianza”, continuamos haciendo clic en “Siguiente”.

Confirmamos la importación haciendo clic en “Finalizar”.

Reiniciamos el navegador y entramos nuevamente al portal de Wazuh. Ahora veremos que la conexión por FQDN tiene un certificado válido.

Ref: Configuring SSL certificates directly on the Wazuh dashboard
Instalando CA en Linux

Este paso se debe realizar solo si la CA que se utilizó para firmar el certificado no ha sido instalada. Si ese fuera el caso, este punto puede ser omitido.
Para instalar nuestra CA en un sistema Linux, lo primero que debemos hacer es copuar el archivo .crt al equipo.

Luego nos aseguraremos de tener instalado la utilidad “ca-certificates”:

En caso de no tenerlo instalado, puede realizarlo ejecutando los siguientes comandos:
Ubuntusudo apt install ca-certificates |
Centossudo yum install ca-certificates |
Continuaremos copiando el certificado de la CA en ruta “/usr/local/share/ca-certificates”:

Y finalizaremos actualizando el listado de CA instaladas con el comando “sudo update-ca-certificates”:

Con esto habremos concluido la instalación de la CA en el almacén local de certificados del sistema, lo cual nos permitirá conectarnos al sitio sin tener el mensaje o se tenga que utilizar algún flag para no validar el certificado.

Instalando CA en Firefox (Windows o Linux)
Lamentablemente esta opción no aplica para Mozilla Firefox, debido a que el utiliza su propio almacen de certificados.
Para poder importar la CA en Firefox y que este reconozca los certificados que se firmen, debemos ir a “Ajustes -> Privacidad y Seguridad -> Certificados” y luego hacer clic en “Ver Certificados”.

Luego nos dirigimos a la pestaña “Autoridades” y seleccionamos “Importar”:

Buscaremos el certificado y lo seleccionaremos para importarlo, cuando hagamos esto, se solicitará que confirmemos los permisos con los que será importada la CA. Debemos hacer clic en “Confiar en esta CA para identificar sitios web” y luego “Aceptar”.

Si todo esto se realizó correctamente deberíamos ser capaces de ver nuestra CA en el listado de Firefox.

Y ahora sí, cuando ingresemos al portal de nuestro Wazuh veremos que el certificado ahora es válido:

Instalación del Agente de Wazuh
Lo siguiente que realizaremos será la instalación del agente de Wazuh para el envío de logs al servidor.

Antes de continuar con la instalación del primer agente es recomendable que valides que el servidor tenga los puertos de red necesarios abiertos.
Para esto puedes revisar la sección “Firewall” del artículo Instalando servidores de Wazuh (Parte 4) o puedes revisar directamente la documentación oficial de Wazuh en el siguiente link Architecture – Wazuh
Instalación del agente en Linux
Comenzaremos con la instalación del agente para Linux de Wazuh. Para esto iniciaremos sesión en el portal web de Wazuh y nos dirigiremos a parte superior del sitio y haremos clic en “Wazuh” y luego en “Agents”.

Si es el primer agente que agregamos nos mostrará inmediatamente el menú de despliegue, en caso contrario mostrará el listado de Endpoint configurados.
En este escenario vamos a instalar el agente en un servidor Ubuntu 22 x64, por lo cual seleccionaremos como paquete de instalación “Linux DEB amd64”

Luego deberemos indicar la dirección del servidor, aquí puedes ingresar una dirección IP o un FQDN. Para este ejemplo indicaremos la IP del servidor con rol “Wazuh Server”.


Si queremos definir un valor preestablecido para el servidor, debemos ir a “Wazuh -> Settings -> Configuration -> Enrollment DNS”. Ahí podrás definir una IP o FQDN base.
Luego podremos opcionalmente predefinir un HOSTNAME al agente o asignarlo a un grupo. Para este caso ambos quedarán en blanco. Esto significa que el HOSTAME del equipo será el mismo que del Endpoint y el equipo será agregado al grupo “Default”.

Finalmente, el menú de despliegue nos indicará el comando que debemos ejecutar en el Endpoint para instalar el agente. Si la contraseña de autenticación del agente fue configurada, está aparecerá automáticamente en el comando.

Ejecutamos el comando que genera el menú de despliegue con permisos de administrador:

Ahora, para validar la correcta instalación del agente podemos revisar los siguientes puntos:
- Dirección del servidor Wazuh
Debemos revisar la sección address del archivo “/var/ossec/etc/ossec.conf”.

Si la dirección del servidor Wazuh se aplicó correctamente aparecerá la IP/FQDN que definimos durante el despliegue.
- Clave de autenticación
Debemos revisar la sección address del archivo “/var/ossec/etc/authd.pass”.

Si se configuro correctamente, aparecerá la clave que definimos en el servidor con rol “Wazuh Server”.
Y como último paso de despliegue nos indicará los comandos que debemos ejecutar para iniciar el agente.

Una vez iniciamos el agente, este se registrará automáticamente en el servidor con rol “Wazuh Server” y aparecerá en el menú de Agentes.


En caso de que el agente no se reporte con en la consola puedes:
- Revisar que la dirección del servidor Wazuh sea la correcta.
- Revisar que la clave de autenticación del agente este correctamente configurada.
- Revisar que el servidor tenga los puertos de red necesarios abiertos.
Para esto puedes revisar la sección “Firewall” del artículo Instalando servidores de Wazuh (Parte 4) o puedes revisar directamente la documentación oficial de Wazuh en el siguiente link Architecture – Wazuh
Instalación del agente en Windows
Ahora abordaremos como realizar la instalación del agente Wazuh. Para esto iniciaremos sesión en el portal web de Wazuh y nos dirigiremos a parte superior del sitio y haremos clic en “Wazuh” y luego en “Agents”

Si es el primer agente que agregamos nos mostrará inmediatamente el menú de despliegue, en caso contrario mostrará el listado de Endpoint configurados.
En este escenario vamos a instalar el agente en una estación de trabajo con Windows 10, por lo cual seleccionaremos como paquete de instalación “MSI 32/64 bits”.

Luego deberemos indicar la dirección del servidor, aquí puedes ingresar una dirección IP o un FQDN. Para este ejemplo indicaremos la IP del servidor con rol “Wazuh Server”:


Si queremos definir un valor preestablecido para el servidor, debemos ir a “Wazuh -> Settings -> Configuration -> Enrollment DNS”. Ahí podrás definir una IP o FQDN base.
Luego podremos opcionalmente predefinir un HOSTNAME al agente o asignarlo a un grupo. Para este caso ambos quedarán en blanco. Esto significa que el HOSTAME del equipo será el mismo que del Endpoint y el equipo será agregado al grupo “Default”.

Finalmente, el menú de despliegue nos indicará el comando que debemos ejecutar en el Endpoint para instalar el agente. Si la contraseña de autenticación del agente fue configurada, está aparecerá automáticamente en el comando:

Ejecutamos el comando anterior dentro de una consola Powershell con permisos de administrador:

Ahora, para validar la correcta instalación del agente podemos revisar los siguientes puntos:
- Dirección del servidor Wazuh
Debemos revisar la sección address del archivo “C:\Program Files (x86)\ossec-agent\ossec.conf”

Si la dirección del servidor Wazuh se aplicó correctamente aparecerá la IP/FQDN que definimos durante el despliegue.
- Clave de autenticación
Debemos revisar la sección address del archivo “C:\Program Files (x86)\ossec-agent\authd.pass”.

Si se configuro correctamente, aparecerá la clave que definimos en el servidor con rol “Wazuh Server”.
Como último paso de despliegue nos indicará los comandos que debemos ejecutar para iniciar el agente:


Una vez iniciamos el agente, este se registrará automáticamente en el servidor con rol “Wazuh Server” y aparecerá en el menú de Agentes.


En caso de que el agente no se reporte con en la consola puedes:
- Revisar que la dirección del servidor Wazuh sea la correcta.
- Revisar que la clave de autenticación del agente este correctamente configurada.
- Revisar que el servidor tenga los puertos de red necesarios abiertos.
Para esto puedes revisar la sección “Firewall” del artículo Instalando servidores de Wazuh (Parte 4) o puedes revisar directamente la documentación oficial de Wazuh en el siguiente link Architecture – Wazuh
Utilización básica
Con esto habremos terminado la configuración inicial del cluster Wazuh y tendremos equipos enviando eventos a nuestro servidor.
Con la configuración estándar del agente ya podremos ver los eventos básicos de Windows como por ejemplo los inicios de sesión. Si utilizamos la aplicación “Discovery” podremos identificar los logs que estan llegando:

Si utilizamos la siguiente query vamos a poder visualizar los inicios y términos de sesión de los equipos Windows que estén enviando logs.
data.win.system.eventID:(4624 or 4634)


Y si queremos ver los inicios de sesión vía SSH en los equipos Linux podemos utilizar la siguiente query:
location:"/var/log/auth.log" and predecoder.program_name:"sshd"


Conclusión
Con esto tenemos una primera mirada de como poder integrar correctamente dos equipos a nuestro monitoreo con Wazuh, y que además tengamos asegurada la conexión SSL con el Wazuh Dashboard. Este es el primer paso para poder tener monitoreada nuestra red y saber quienes se están conectando a los equipos, centralizando los logs en 1 solo servidor, el “Wazuh Server”.
Ahora debemos mejorar y ampliar los eventos que se registran en nuestros sistemas y comenzaremos abordarlo en el próximo articulo el envío de logs específicos para los servidores DNS y Proxy, explicando como crear el decodificador (en caso de no existir) y como armar las primeras de reglas de detección personalizadas.
Muchas gracias por leer hasta acá, y los esperamos en el siguiente.

Excelente todo, estoy atento al proximo contenido, muchas gracias!
Me gustaMe gusta