Buenas prácticas de seguridad en Zabbix: Criptografía, macros secretas y permisos

Zabbix concentra información extremadamente sensible: credenciales de acceso a bases de datos, routers, hipervisores y aplicaciones; métricas que revelan el comportamiento interno de tu infraestructura; y la capacidad de ejecutar comandos remotos sobre servidores en producción. Un Zabbix mal configurado no es solo un riesgo de monitoreo: es una puerta de entrada hacia el resto de tu entorno.

En esta guía repasamos cómo reforzar la seguridad de Zabbix trabajando tres pilares que se complementan entre sí: la criptografía de las comunicaciones, las macros secretas para proteger credenciales y la gestión avanzada de permisos. Los ejemplos están basados en Zabbix 7.0 LTS, pero aplican igual a 6.0 LTS y a las versiones estándar más recientes.

Por qué la seguridad es crítica en Zabbix

El argumento central es simple: Zabbix toca todo lo que monitorea. La configuración guarda las credenciales que usa para acceder a otros sistemas, los datos recolectados pueden contener información confidencial y, en muchos despliegues, el agente está habilitado para ejecutar comandos en los hosts de producción.

Las vulnerabilidades más frecuentes en entornos mal configurados suelen repetirse:

• Tráfico en texto plano. Por defecto, las conexiones entre el servidor, los proxies y los agentes no van cifradas. Cualquier sniffer en la red puede leer las métricas e, incluso, datos sensibles que viajen en ellas.
• Credenciales visibles. Las macros de usuario tradicionales pueden ser leídas por administradores con acceso al host a través de la pestaña Inherited and host macros, exponiendo contraseñas de bases de datos, APIs o dispositivos.
• Permisos demasiado amplios. Es común encontrar usuarios con rol de administrador “porque era más fácil”, o accesos de lectura/escritura sobre grupos de hosts que no les corresponden.
• Claves de agente sin restringir. Si no se limitan claves peligrosas como run, un usuario con acceso suficiente puede ejecutar comandos arbitrarios en los servidores monitoreados.
• Versiones sin soporte. Ejecutar una versión que ya alcanzó su End of Life implica quedarse sin parches de seguridad.

La buena noticia es que Zabbix incluye, de forma nativa, todas las herramientas necesarias para cerrar estas brechas. Veámoslas una por una.

Criptografía en Zabbix

Zabbix admite comunicaciones cifradas con TLS (Transport Layer Security) v1.2 y v1.3 entre todos sus componentes: servidor, proxy, agente, web service, y las utilidades zabbix_sender y zabbix_get. También permite cifrar la conexión entre el frontend / servidor y la base de datos.

Un detalle importante de diseño: cada demonio de Zabbix usa un único puerto tanto para conexiones cifradas como sin cifrar. Es decir, agregar cifrado no obliga a abrir nuevos puertos en el firewall, lo que facilita una migración gradual.

El cifrado se apoya en una librería criptográfica (OpenSSL, GnuTLS o mbedTLS) y ofrece dos métodos: clave precompartida (PSK) y certificados.

Configuración de conexiones seguras (TLS/SSL)

Dos parámetros controlan el comportamiento del cifrado en cada componente:

• TLSConnect: define cómo se realizan las conexiones salientes (unencrypted, psk o cert). Se usa, por ejemplo, en el agente para los checks activos y en el proxy activo hacia el servidor.
• TLSAccept: define qué conexiones entrantes se aceptan. Admite varios valores separados por coma, útil durante una migración (por ejemplo unencrypted,psk).

Cifrado con PSK (clave precompartida)

La opción más rápida de implementar. Consiste en dos valores: una identidad y una clave.

Importante: La identidad PSK viaja sin cifrar por la red. Nunca pongas información sensible en ella. Úsala solo como un nombre descriptivo, por ejemplo PSK-Agente-001.

La clave es una cadena hexadecimal de entre 32 y 512 dígitos (de 128 a 2048 bits). Se genera con OpenSSL y el archivo debe quedar legible únicamente por el usuario zabbix:

# Generar la clave PSK (256 bits) y guardarla en un archivo

openssl rand -hex 32 > /etc/zabbix/zabbix_agentd.psk

# Restringir el acceso al archivo

chown zabbix:zabbix /etc/zabbix/zabbix_agentd.psk

chmod 600 /etc/zabbix/zabbix_agentd.psk

En el archivo de configuración del agente (zabbix_agentd.conf o zabbix_agent2.conf):

TLSConnect=psk

TLSAccept=psk

TLSPSKFile=/etc/zabbix/zabbix_agentd.psk

TLSPSKIdentity=PSK-Agente-001

Tras reiniciar el agente, configura el mismo par identidad/clave en el frontend, en Data collection → Hosts → [host] → Encryption. Puedes validar la conexión cifrada con zabbix_get:

zabbix_get -s 127.0.0.1 -k "system.cpu.load[all,avg1]" \

--tls-connect=psk \

--tls-psk-identity="PSK-Agente-001" \

--tls-psk-file=/etc/zabbix/zabbix_agentd.psk

Cifrado con certificados

Más robusto y escalable para entornos grandes, porque permite gestionar la confianza de forma centralizada y revocar credenciales. Algunos puntos clave:

• Zabbix no admite certificados autofirmados: necesitas una Autoridad Certificadora (CA). Se recomienda usar CAs intermedias para firmar los certificados de cliente y servidor.
• Puedes restringir el emisor (issuer) y el sujeto (subject) del certificado remoto, de modo que no baste con poseer cualquier certificado firmado por la CA.

Configuración de ejemplo en el agente:

TLSConnect=cert

TLSAccept=cert

TLSCAFile=/etc/zabbix/certs/ca.crt

TLSCertFile=/etc/zabbix/certs/agent.crt

TLSKeyFile=/etc/zabbix/certs/agent.key

# Opcional, pero muy recomendado en entornos corporativos:

TLSServerCertIssuer=CN=CA Interna Monitoreo

TLSServerCertSubject=CN=zabbix-server

PSK vs. certificados: ¿cuál elegir?

Para una estrategia de migración con downtime mínimo, configura primero TLSAccept=unencrypted,cert (o psk), valida que la conexión cifrada funciona y, recién entonces, endurece a TLSAccept=cert para rechazar todo el tráfico sin cifrar.

Cifrado de datos: frontend y base de datos

Además del tráfico entre componentes, conviene proteger otras dos superficies:

• Frontend (interfaz web): sírvela siempre sobre HTTPS, configurando TLS en el servidor web (Nginx o Apache). Las credenciales de los usuarios y los tokens de sesión nunca deberían viajar en claro.
• Base de datos: cifra la conexión entre el servidor / frontend y la base de datos. Esto es especialmente relevante porque las macros de tipo “Secret text” se almacenan en la base de datos: si un atacante obtiene un backup, podría leerlas.

Macros secretas

Las macros de usuario en Zabbix ({$MACRO}) son ideales para parametrizar plantillas y evitar repetir credenciales. El problema es que, en su forma tradicional, su valor es visible para cualquier administrador con acceso al host: basta abrir la pestaña Inherited and host macros para ver contraseñas en texto plano. Incluso algunas macros globales, accesibles por defecto solo para Super admins, terminan apareciendo en esa pestaña a nivel de host.

Para resolverlo, desde Zabbix 5.0 existen las macros secretas, que ocultan el valor de modo que nunca se muestre a quien no debe verlo.

Qué son y cómo se usan las macros en Zabbix

Zabbix ofrece dos modalidades para proteger valores sensibles en macros de usuario:

Para crear una macro secreta, en el formulario de macros haz clic en el botón al final del campo Value y selecciona Secret text o Vault secret.

Conviene tener presentes algunas limitaciones de las macros secretas:

• No funcionan en URLs ni en campos como el proxy HTTP de un escenario web: se resuelven como ****** y la operación falla.
• No pueden usarse en expresiones de trigger.
• No se utilizan en los formularios de prueba (test) ni se clonan junto con la macro del host o de la plantilla.
• Una vez guardado el valor de una macro Secret text, ya no se puede visualizar. Para cambiarlo hay que pasar el cursor sobre el campo y usar Set new value (el valor anterior se borra).
• Cuidado: aunque el valor está oculto en la interfaz, puede revelarse indirectamente si se usa en un ítem que lo imprima (por ejemplo, un echo en un script externo), porque el servidor sí conoce el valor real. Por eso las macros secretas se combinan con la restricción de claves peligrosas.

Ejemplos prácticos para proteger credenciales

Caso 1 — Secret text. Crea una macro de host o de plantilla {$DB_PASSWORD}, selecciona el tipo Secret text e introduce la contraseña. A partir de ese momento la usas con normalidad en tus ítems (por ejemplo, en un ítem de monitoreo de base de datos) y nadie podrá leer su valor desde el frontend. Recuerda cifrar la conexión a la base de datos, ya que el valor sigue residiendo en ella.

Caso 2 — Vault secret con HashiCorp Vault. El valor real vive en Vault y Zabbix solo guarda una referencia. Primero se crea el secreto en Vault:

# Habilitar el motor de secretos kv-v2 (si no está habilitado)

vault secrets enable -path=secret/ kv-v2

# Guardar la credencial

vault kv put secret/zabbix/database username=zabbix password=<contraseña>

# Verificar

vault kv get secret/zabbix/database

Luego se configura el servidor (zabbix_server.conf) para autenticarse contra Vault:

Vault=HashiCorp

VaultToken=hvs.XXXXXXXXXXXXXXXXXXXXXXXX

VaultURL=https://127.0.0.1:8200

VaultDBPath=secret/zabbix/database

Finalmente, en la macro de usuario seleccionas el tipo Vault secret y como valor indicas la referencia en formato ruta:clave, por ejemplo:

secret/zabbix:password

El servidor (y el proxy, si está configurado para ello) recupera el valor desde Vault en cada refresco de la configuración y lo mantiene en la caché. Algunas buenas prácticas con Vault:

• Usa tokens de solo lectura y, preferentemente, periodic service tokens renovables, para un servicio de larga ejecución como Zabbix.
• Emplea tokens distintos para cada proxy.
• Habilita el cifrado entre servidor y proxy; de lo contrario Zabbix registra una advertencia al resolver macros de Vault.
• Puedes monitorear con el propio Zabbix la fecha de expiración del token para anticiparte a su vencimiento.

Gestión avanzada de permisos

El principio que rige todo el modelo de permisos de Zabbix es claro: los permisos se basan en grupos, no en usuarios individuales. Aunque un solo usuario necesite acceso a un solo host, ese acceso se concede agregándolo a un grupo de usuarios y otorgando a ese grupo permisos sobre el grupo de hosts que contiene el host.

Tipos de usuario y roles

Hay que distinguir dos conceptos que trabajan juntos:

Tipos de usuario (definen el alcance general):

• User: acceso limitado a secciones del menú y sin acceso a ningún recurso por defecto. Todo permiso sobre grupos de hosts o plantillas debe asignarse explícitamente.
• Admin: acceso incompleto al menú y sin acceso a grupos de hosts por defecto; los permisos se otorgan explícitamente.
• Super admin: acceso a todas las secciones y lectura/escritura sobre todos los grupos de hosts y plantillas. Sus permisos no pueden revocarse denegando grupos específicos.

Roles de usuario (desde Zabbix 5.2): cuatro roles preconfigurados (User, Admin, Super admin y Guest) que afinan a qué secciones de la interfaz, módulos y métodos de la API tiene acceso cada usuario. Puedes crear roles personalizados y desmarcar permisos concretos para ajustarlos a cada función. El rol Super admin por defecto no se puede modificar ni eliminar, porque siempre debe existir al menos un Super admin con privilegios ilimitados.

Cómo se calculan los permisos sobre los datos

Los permisos sobre los datos se asignan a los grupos de usuarios desde las pestañas Host permissions y Template permissions, con cuatro niveles: Read-write, Read, Deny y None (este último “resetea” y quita el grupo de la lista).

El nivel efectivo depende de la combinación entre el tipo de usuario y el permiso sobre el grupo de hosts:

Dos reglas de precedencia que conviene memorizar cuando un usuario pertenece a varios grupos:

1. Read-write tiene prioridad sobre Read. Si un grupo le da lectura y otro lectura/escritura sobre el mismo grupo de hosts, prevalece lectura/escritura.
2. Deny es lo más estricto. Si un host pertenece a algún grupo denegado para el usuario, el acceso se bloquea aunque otro grupo le otorgue lectura/escritura.

Zabbix también soporta grupos de hosts anidados mediante la barra diagonal en el nombre (por ejemplo, Europa/España/Madrid), lo que facilita modelar jerarquías y aplicar (o denegar) permisos por rama. Y, mediante el filtro por etiquetas (Problem tag filter), puedes separar el acceso a un grupo de hosts de la capacidad de ver sus problemas: por ejemplo, permitir que un equipo vea únicamente los problemas etiquetados como service: database.

Buenas prácticas para entornos corporativos

• Privilegio mínimo. Asigna a cada grupo solo el acceso que necesita. Evita el rol Super admin salvo para un puñado de administradores.
• Roles por función, no por persona. Crea roles personalizados (por ejemplo, “Operador NOC”, “Ingeniero de red”, “Solo lectura auditoría”) y asigna usuarios a ellos.
• Modela grupos de hosts según tu organización (por equipo, ubicación, criticidad) y aprovecha el anidamiento para gestionarlos en bloque.
• Usa Deny con criterio. Recuerda que prevalece sobre cualquier otro permiso; es ideal para excluir un subgrupo sensible dentro de una rama a la que, por lo demás, se da acceso.
• Restringe la cuenta guest. Está deshabilitada por defecto; mantenla así salvo que tengas una necesidad explícita.
• Limita las claves del agente. Con AllowKey y DenyKey en la configuración del agente puedes bloquear claves peligrosas (como run) y reducir el riesgo de ejecución de comandos no deseada.

Seguridad en Zabbix es una estrategia de defensa en capas

La seguridad en Zabbix no depende de una única función, sino de la combinación de diferentes capas de protección que trabajan en conjunto. Para proteger el entorno, es fundamental cifrar las comunicaciones entre el servidor, los proxies y los agentes mediante TLS, así como servir el frontend a través de HTTPS y proteger las conexiones a la base de datos. Las credenciales sensibles deben almacenarse de forma segura, utilizando macros secretas o Vault en lugar de contraseñas en texto plano.

También es importante proteger los archivos que contienen claves PSK y certificados mediante permisos adecuados, aplicar el principio de mínimo privilegio mediante roles y permisos sobre grupos de hosts, y restringir o deshabilitar la cuenta Guest. En los agentes, las claves potencialmente peligrosas deben limitarse mediante AllowKey y DenyKey, mientras que el parámetro Server debe restringirse a las IP de los servidores o proxies autorizados. Por último, mantener Zabbix en una versión con soporte y revisar periódicamente el audit log son prácticas esenciales para mantener un entorno seguro y preparado para infraestructuras críticas.

¿Quieres llevar la seguridad de tu entorno Zabbix al siguiente nivel?

Cada infraestructura tiene sus propios desafíos de seguridad. Si quieres evaluar la configuración de tu entorno, aplicar las mejores prácticas o descubrir cómo Zabbix puede ayudarte a construir una infraestructura de monitoreo más segura, habla con nuestro equipo de expertos.

Contacta con el equipo de Zabbix y descubre cómo podemos ayudarte.

Lucas Frade

Prev Post