Muchas veces hemos visto el uso de Zabbix como una simple herramienta de monitoreo de activos de red e infraestructura de Tecnologías de la Información y Comunicación (TIC). Aunque este concepto no es incorrecto, es igualmente importante comprender que, con el avance de sus versiones, cada vez más funcionalidades han sido habilitadas para otros tipos de monitoreo, evolucionando hacia análisis avanzados de datos y visualizaciones impresionantes mediante nuevos y modernos widgets de la capa de frontend.
En este breve blog, exploraremos algunas funcionalidades existentes y poco conocidas de Zabbix, las cuales contribuyen al fortalecimiento de la disciplina de ciberseguridad en las organizaciones, un tema que se está volviendo cada vez más demandado y crítico en el entorno corporativo.
FIM – File Integrity Monitoring
Un concepto muy común entre las herramientas de seguridad de la información, específicamente en herramientas del tipo SIEM/XDR (Gestión de Eventos de Seguridad de la Información/Detección y Respuesta Extendida), es el FIM. El nombre es bastante sugestivo en cuanto a su utilidad; sin embargo, algunas herramientas presentan esta funcionalidad como una de sus características principales. Para quienes usan Zabbix, estas capacidades también están presentes, aunque no aparecen explícitamente con este mismo nombre.
Aquí trataremos el FIM como un concepto y no solo como una funcionalidad. Esto se debe a que buscamos alcanzar un resultado, y no simplemente contar con un menú que diga que estamos en conformidad al usar nuestra herramienta. De hecho, el resultado debe ser más importante que una simple “promoción”.
¿Qué esperar del FIM?
Imagina que en tus servidores existan algunos directorios y/o archivos tan importantes que no puedes dejar de monitorearlos en cuanto a cambios, inserciones o eliminación de datos. O incluso, archivos que tienen propietarios y propiedades que no pueden ser modificados, ya que, de lo contrario, los sistemas que dependen de ellos podrían perder la capacidad de leerlos y ejecutar sus funciones. Esto es, como mínimo, lo que esperamos del FIM como funcionalidad.
Para ilustrarlo un poco mejor, considera un servicio de base de datos como MariaDB:
# ls -lR /etc/mysql/
/etc/mysql/:
total 24
drwxr-xr-x 2 root root 4096 Jun 25 18:40 conf.d
-rwxr-xr-x 1 root root 1740 Nov 30 2023 debian-start
-rw——- 1 root root 544 Jun 25 18:43 debian.cnf
-rw-r–r– 1 root root 1126 Nov 30 2023 mariadb.cnf
drwxr-xr-x 2 root root 4096 Sep 30 16:36 mariadb.conf.d
lrwxrwxrwx 1 root root 24 Oct 20 2020 my.cnf -> /etc/alternatives/my.cnf
-rw-r–r– 1 root root 839 Oct 20 2020 my.cnf.fallback
/etc/mysql/conf.d:
total 8
-rw-r–r– 1 root root 8 Oct 20 2020 mysql.cnf
-rw-r–r– 1 root root 55 Oct 20 2020 mysqldump.cnf
/etc/mysql/mariadb.conf.d:
total 40
-rw-r–r– 1 root root 575 Nov 30 2023 50-client.cnf
-rw-r–r– 1 root root 231 Nov 30 2023 50-mysql-clients.cnf
-rw-r–r– 1 root root 927 Nov 30 2023 50-mysqld_safe.cnf
-rw-r–r– 1 root root 3795 Sep 30 16:36 50-server.cnf
-rw-r–r– 1 root root 570 Nov 30 2023 60-galera.cnf
-rw-r–r– 1 root root 76 Nov 8 2023 provider_bzip2.cnf
-rw-r–r– 1 root root 72 Nov 8 2023 provider_lz4.cnf
-rw-r–r– 1 root root 74 Nov 8 2023 provider_lzma.cnf
-rw-r–r– 1 root root 72 Nov 8 2023 provider_lzo.cnf
-rw-r–r– 1 root root 78 Nov 8 2023 provider_snappy.cnf
Todos los archivos, directorios y subdirectorios mencionados anteriormente ya están configurados, y el sistema, sea cual sea, está funcionando perfectamente. Sin embargo, si alguien decide repentinamente modificar una configuración en el archivo “/etc/mysql/mariadb.conf.d/50-server.cnf”, esto podría ser un desastre para el servicio… o tal vez no. Lo importante es contar con un monitoreo de este alcance y notificar a las personas interesadas para que puedan realizar un análisis adecuado.
Y aquí es donde Zabbix puede ayudar. Veamos cómo
Zabbix y funciones para FIM
Considera que el agente de Zabbix está instalado en el servidor que se va a monitorear:
vfs.dir.count[/etc/mysql]
Com esta chave, podemos contabilizar os objetos presentes dentro do diretório “/etc/mysql”. Posteriormente, podemos criar uma trigger a ser ativada se houver qualquer alteração relacionada ao número inicial da coleta, ou seja, alguém apagou ou inseriu um arquivo ou diretório neste local.
vfs.dir.size[/etc/mysql]
Con esta clave, podemos conocer el total utilizado en bytes por los directorios y archivos de configuración. De esta forma, en el futuro, podemos crear un trigger que se active cuando este tamaño sea modificado, indicando una posible eliminación o adición de algún archivo.
vfs.file.exists[/etc/mysql/mariadb.conf.d/50-server.cnf]
Entre varios archivos importantes, podemos tener un mayor interés en algunos archivos de configuración y podemos validar su existencia. De esta manera, podemos crear un trigger que se active cuando dicho archivo deje de existir. Esto claramente nos indicará que algo importante ha desaparecido.
En este caso, el valor «1» representa un «OK» para la existencia del archivo.
vfs.file.cksum[/etc/mysql/mariadb.conf.d/50-server.cnf,sha256]
Además de verificar la existencia del archivo de configuración considerado importante, también necesitamos ser notificados si algo en él es modificado. Esta clave se encarga de evaluar eso, generando un hash en formatos posibles (como SHA256), lo que permite que un trigger se active en caso de una modificación en el hash, indicando cambios en el contenido del archivo.
vfs.file.regmatch[/etc/mysql/mariadb.conf.d/50-server.cnf,^max_connections\s+=\s+(\d+)]
Puede que tengamos un parámetro específico de nuestro interés. Por ejemplo, el número máximo de conexiones permitidas a la base de datos. Monitorear esto es importante porque, si la configuración está en su valor predeterminado (default), puede significar que no se ha realizado un «tuning» en la base de datos o que alguien simplemente eliminó o comentó esta línea, haciendo que sea ignorada por el sistema. Por lo tanto, verificar si el parámetro existe y está configurado es fundamental.
En este caso, el número “1” representa que la expresión regular se encontró con éxito, es decir, la configuración o el parámetro que necesitamos que exista está presente.
vfs.file.regexp[/etc/mysql/mariadb.conf.d/50-server.cnf,^max_connections\s+=\s+(\d+),,,,\1]
Además de la existencia y la integridad del archivo, también es posible saber qué se ha modificado en él. La clave es especificar la configuración de interés mediante una expresión regular. Por ejemplo, considerando que el número máximo de conexiones permitidas por el sistema de base de datos es “x”, podríamos ser alertados mediante un trigger si cambia a “y” o “z” o a cualquier otro valor diferente de “x”. Esta configuración permite monitorear el parámetro de interés con precisión. Esta lógica puede aplicarse a cualquier otro parámetro que consideres importante y, por supuesto, también existe otra forma de automatizar este proceso. Sin embargo, no abordaremos esa automatización aquí.
En este caso, el parámetro que define el número máximo de conexiones no solo está presente, sino que también sabemos cuál es el número de conexiones configurado. De esta manera, tendremos un historial de la parametrización aplicada, en caso de que sea modificada en algún momento.
vfs.file.owner[/etc/mysql/mariadb.conf.d/50-server.cnf]
vfs.file.owner[/etc/mysql/mariadb.conf.d/50-server.cnf,group]
Las dos claves mencionadas anteriormente nos permiten saber quién es el propietario de un archivo y, en el caso de un sistema Linux, el grupo propietario. También podemos optar por conocer el nombre del usuario o su UID en el sistema. Por supuesto, se puede configurar un trigger que se active y nos alerte en caso de un cambio de propietario, indicando que alguien está «apoderándose» de un archivo importante en el sistema.
vfs.file.permissions[/etc/mysql/mariadb.conf.d/50-server.cnf]
La clave anterior nos permite conocer los permisos de un archivo: lectura, escritura, lectura y escritura, ejecución, o si hay un bit especial en la configuración de permisos. Por supuesto, se puede configurar un trigger que se active para alertarnos en caso de un cambio en los permisos del archivo.
vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf]
La clave anterior no existe de manera predeterminada. Fue creada a partir de un UserParameter, es decir, una personalización que permite verificar un comando específico que, en este caso, revisa los atributos de un archivo determinado. Considera el siguiente comando ejecutado directamente en el terminal de tu sistema:
# lsattr /etc/mysql/mariadb.conf.d/50-server.cnf
————–e——- /etc/mysql/mariadb.conf.d/50-server.cnf
Lo que nos interesa son los atributos:
————–e——-
Si alguien que invade el sistema altera el atributo de un archivo, por ejemplo, utilizando el comando:
# chattr +A /etc/mysql/mariadb.conf.d/50-server.cnf
# lsattr /etc/mysql/mariadb.conf.d/50-server.cnf
——-A——e——- /etc/mysql/mariadb.conf.d/50-server.cnf
Esto puede significar que alguien no quiere que el sistema registre cuándo se accedió a este archivo (consulta el manual del comando chattr). Además, cualquier otro atributo puede añadirse o eliminarse, lo que puede representar un riesgo para el sistema, ya que estos atributos pueden modificar cómo se acceden a los archivos o cómo se almacenan en el disco y posteriormente se leen. Por lo tanto, podemos crear un UserParameter de la siguiente manera:
# cd /etc/zabbix/zabbix_agent2.d/
# echo «UserParameter=vfs.file.attr[*],lsattr \$1 | cut -d\» \» -f1″ > attr.conf
# zabbix_agent2 -R userparameter_reload
Y finalmente, podemos probar la lectura de los atributos directamente desde el terminal:
# zabbix_agent2 -t vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf]
vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf][s|——-A——e——-]
También puedes experimentar esto desde el frontend.
Al crear el ítem, no olvides configurar el trigger que debe activarse en caso de que haya un cambio en el atributo de un archivo, sea cual sea.
Mantente atento al tiempo de acceso y modificación de los archivos
Para profundizar un poco más en el concepto de FIM, debemos preguntarnos si estamos monitoreando los accesos y modificaciones de un archivo con relación a sus horarios. De cierta forma, si hemos implementado todo lo propuesto anteriormente, la respuesta es sí.
De cualquier manera, existe una forma más sencilla de monitorear todo lo que hemos discutido. Se trata de la clave:
vfs.dir.get[/etc/mysql]
Al crear un ítem con esta clave, obtendremos de forma recursiva todos sus objetos, como subdirectorios y archivos. El formato de salida será un JSON, lo que nos permitirá crear reglas de tipo LLD (Low-level Discovery) para automatizar el FIM. A continuación, se muestra un pequeño fragmento de la salida del monitoreo:
{
«basename»: «mariadb.cnf»,
«pathname»: «/etc/mysql/mariadb.cnf»,
«dirname»: «/etc/mysql»,
«type»: «file»,
«user»: «root»,
«group»: «root»,
«permissions»: «0644»,
«uid»: 0,
«gid»: 0,
«size»: 1126,
«time»: {
«access»: «2024-11-30T23:01:01-0300»,
«modify»: «2023-11-30T01:42:37-0300»,
«change»: «2024-06-25T18:41:01-0300»
},
«timestamp»: {
«access»: 1733018461,
«modify»: 1701319357,
«change»: 1719351661
}
…
Considerando que la salida incluye todos los objetos del directorio principal, este sería el camino más sensato para configurar nuestro FIM. Sin embargo, es necesario crear la LLD y los prototipos. No abordaremos este tema en detalle en este artículo, pero este es el camino que te recomiendo seguir.
A continuación, un “blueprint” para una LLD destinada a la creación de monitorizaciones FIM de forma automatizada.
El “Master item”:
La “Dependent rule”:
Las «LLD Macros»:
Los «Item prototypes»:
A continuación, los componentes de un trigger prototype (he creado solo uno para simbolizar un tipo de alerta por modificación de archivo):
Name: Object: {#BASENAME} just changed
Event name: Object: {#BASENAME} just changed. Last hash: {ITEM.VALUE} The previous one: {?last(/MySQLDB/vfs.file.cksum[«{#PATHNAME}»,sha256],#2)} Object: {#BASENAME} just changed. Last hash: {ITEM.VALUE} The previous one: {?last(/MySQLDB/vfs.file.cksum[«{#PATHNAME}»,sha256],#2)}
Severity: Warning
Expression: last(/MySQLDB/vfs.file.cksum[«{#PATHNAME}»,sha256],#1)<>last(/MySQLDB/vfs.file.cksum[«{#PATHNAME}»,sha256],#2)
Y entonces, algunos resultados:
Conclusión sobre el FIM
La implementación de un sistema robusto de File Integrity Monitoring (FIM) es una de las mejores prácticas para garantizar la seguridad de la infraestructura de TI. Detectar cambios no autorizados en archivos críticos ayuda a prevenir ataques, identificar vulnerabilidades y garantizar la integridad y disponibilidad de los sistemas. Con Zabbix, contamos con una solución eficaz para implementar el FIM, que permite automatizar el proceso y visualizar en tiempo real las modificaciones. Este monitoreo no solo refuerza la protección contra intrusiones, sino que facilita la auditoría y el cumplimiento de normativas regulatorias.
Los principales beneficios de integrar el FIM con Zabbix incluyen:
- Detección temprana de cambios en archivos críticos, lo que permite respuestas rápidas.
- Mayor cumplimiento de las regulaciones de seguridad y políticas internas.
- Protección contra malware y ransomware, identificando modificaciones en archivos esenciales.
- Facilidad de auditoría con reportes automatizados y registros históricos de modificaciones.
- Mayor visibilidad y control sobre la integridad de los datos y sistemas en tiempo real.
- Eficiencia operativa mediante la automatización de alertas y reportes.
- Mejora de la seguridad proactiva, ayudando a prevenir ataques antes de que se vuelvan críticos.
Con el uso de Zabbix, las organizaciones pueden fortalecer su postura de seguridad y optimizar la gestión de riesgos, asegurando que cualquier cambio no autorizado sea detectado y corregido de manera rápida.