2 Mejores prácticas para la configuración segura de Zabbix

Visión general

Esta sección contiene las mejores prácticas que deben ser observadas para configurar Zabbix de forma segura.

Las prácticas aquí contenidas no son necesarias para el funcionamiento de Zabbix. Se recomiendan para una mejor seguridad del sistema.

Control de acceso

Principio del menor privilegio

El principio de mínimo privilegio debe ser utilizado en todo momento para Zabbix. Este principio significa que las cuentas de usuario (en el frontend de Zabbix) o proceso de usuario (para el servidor/proxy o agente de Zabbix) tienen sólo aquellos privilegios que son esenciales para realizar las funciones previstas. En otras palabras, las cuentas de usuario cuentas de usuario en todo momento deben ejecutarse con el menor número de privilegios posible.

Al implementar el principio de mínimo privilegio para las cuentas de usuario, Zabbix frontend user types debe tenerse en cuenta. Es importante entender que mientras un usuario "Admin" tiene menos privilegios que el tipo de usuario "Super Admin", tiene permisos administrativos que permiten gestionar la configuración y ejecutar scripts personalizados.

Usuario seguro para el agente Zabbix

En la configuración por defecto, el servidor Zabbix y los procesos del agente Zabbix comparten un usuario 'zabbix'. Si desea asegurarse de que el agente no puede acceder a detalles sensibles en la configuración del servidor (por ejemplo, información de inicio de sesión de la base de datos base de datos), el agente debe ejecutarse como un usuario diferente:

1. • Cree un usuario seguro
2. • Especifique este usuario en el fichero [configuration

• archivo](/manual/apéndice/config/zabbix_agentd) (parámetro 'User')

3. • Reinicie el agente con privilegios de administrador. Los privilegios serán

• se le quitarán al usuario especificado.

codificación UTF-8

UTF-8 es la única codificación soportada por Zabbix. Se sabe que funciona sin ningún fallo de seguridad. Los usuarios deben ser conscientes de que hay problemas de seguridad si se utilizan algunas de las otras codificaciones.

Rutas del instalador de Windows

Al utilizar instaladores de Windows, se recomienda utilizar las rutas predeterminadas proporcionadas por el instalador, ya que el uso de rutas personalizadas sin los permisos adecuados podría comprometer la seguridad de la instalación.

Consejos de seguridad de Zabbix y base de datos CVE

Ver Zabbix Security Advisories and CVE database.

Configuración de SSL para el frontend de Zabbix

En RHEL/Centos, instale el paquete mod_ssl:

· yum install mod_ssl

Cree un directorio para las claves SSL:

· mkdir -p /etc/httpd/ssl/private · chmod 700 /etc/httpd/ssl/private

Crear certificado SSL:

· openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/private/apache-selfsigned.key -out /etc/httpd/ssl/apache-selfsigned.crt

Rellene las indicaciones de forma adecuada. La línea más importante es la que que solicita el nombre común. Necesita introducir el nombre de dominio que quieres que se asocie a tu servidor. Puede introducir la dirección IP pública si no tiene un dominio. Utilizaremos ejemplo.com en este artículo.

· Nombre del país (código de 2 letras) [XX]: · Nombre del Estado o Provincia (nombre completo) []: · Nombre de la localidad (por ejemplo, ciudad) [Ciudad por defecto]: · Nombre de la organización (p. ej., empresa) [Empresa por defecto]: · Nombre de la unidad organizativa (por ejemplo, sección) []: · Nombre común (por ejemplo, su nombre o el nombre de host de su servidor) []:ejemplo.com · Dirección de correo electrónico []:

Editar la configuración de Apache SSL:

· /etc/httpd/conf.d/ssl.conf

· DocumentRoot "/usr/share/zabbix" · ServerName example.com:443 · SSLCertificateFile /etc/httpd/ssl/apache-selfsigned.crt · SSLCertificateKeyFile /etc/httpd/ssl/private/apache-selfsigned.key

Reinicie el servicio Apache para aplicar los cambios:

· systemctl restart httpd.service

Refuerzo del servidor web

Habilitar Zabbix en el directorio raíz de la URL

Añadir un host virtual a la configuración de Apache y establecer una redirección permanente para la raíz del documento a la URL de Zabbix SSL. No olvide reemplazar ejemplo.com por el nombre real del servidor.

· /etc/httpd/conf/httpd.conf

· #Añadir líneas#

· <VirtualHost :> · ServerName example.com · Redirección permanente / https://example.com · <VirtualHost>

Reinicie el servicio Apache para aplicar los cambios:

· systemctl restart httpd.service

Habilitación de HTTP Strict Transport Security (HSTS) en el servidor web

Para proteger el frontend de Zabbix contra ataques de bajada de protocolo, nosotros recomendamos habilitar HSTS política en el servidor web.

Por ejemplo, para habilitar la política HSTS para su frontend Zabbix en Apache configuración:

· /etc/httpd/conf/httpd.conf

añada la siguiente directiva a la configuración de su host virtual:

· <Host virtual *:443> · Header set Strict-Transport-Security "max-age=31536000" · <VirtualHost>

Reinicie el servicio Apache para aplicar los cambios:

· systemctl restart httpd.service

Enabling Content Security Policy (CSP) on the web server

To protect Zabbix frontend against Cross Site Scripting (XSS), data injection, and similar attacks, we recommend enabling Content Security Policy on the web server. To do so, configure the web server to return the HTTP header.

To enable CSP for your Zabbix frontend in Apache configuration, follow these steps:

1. Locate your virtual host's configuration file:

• /etc/httpd/conf/httpd.conf on RHEL-based systems
• /etc/apache2/sites-available/000-default.conf on Debian/Ubuntu

2. Add the following directive to your virtual host's configuration file:

<VirtualHost *:*>
           Header set Content-Security-Policy: "default-src 'self' *.openstreetmap.org; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self' data: *.openstreetmap.org; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self';"
       </VirtualHost>

3. Restart the Apache service to apply the changes:

# On RHEL-based systems:
       systemctl restart httpd.service
       
       # On Debian/Ubuntu
       systemctl restart apache2.service

Desactivar la exposición de la información del servidor web

Se recomienda deshabilitar todas las firmas del servidor web como parte del proceso de endurecimiento del servidor web. El servidor web expone el software firma por defecto:

La firma puede desactivarse añadiendo dos líneas al archivo de configuración de Apache (utilizado como ejemplo) archivo de configuración:

· ServerSignature Off · ServerTokens Prod

La firma de PHP (cabecera HTTP X-Powered-By) puede ser desactivada cambiando el archivo de configuración de archivo de configuración php.ini (la firma está desactivada por defecto):

· expose_php = Off

Es necesario reiniciar el servidor web para que los cambios en el archivo de configuración se apliquen.

Se puede conseguir un nivel de seguridad adicional utilizando el mod_security (paquete libapache2-mod-security2) con Apache. mod_security permite eliminar la firma del servidor en lugar de sólo eliminar la versión del servidor. La firma puede ser alterada a cualquier valor cambiando "SecServerSignature" a cualquier valor deseado después de instalar mod_security.

Por favor, consulte la documentación de su servidor web para encontrar ayuda sobre cómo eliminar/cambiar las firmas de software.

Desactivar las páginas de error del servidor web por defecto

Se recomienda deshabilitar las páginas de error por defecto para evitar la exposición de la información exposición. El servidor web utiliza páginas de error incorporadas por defecto:

Las páginas de error por defecto deben ser reemplazadas/eliminadas como parte del proceso de endurecimiento. La directiva "ErrorDocument" puede utilizarse para definir una página/texto de error personalizado para el servidor web Apache (utilizado como ejemplo).

Por favor, consulte la documentación de su servidor web para encontrar ayuda sobre cómo reemplazar/eliminar las páginas de error por defecto.

Eliminación de la página de prueba del servidor web

Se recomienda eliminar la página de prueba del servidor web para evitar la exposición de la información. Por defecto, el servidor webroot contiene una página de prueba de prueba llamada index.html (Apache2 en Ubuntu se utiliza como ejemplo):

La página de prueba debe ser eliminada o no debe estar disponible como parte del proceso de endurecimiento del servidor web.

Configuración de Zabbix

Por defecto, Zabbix está configurado con la cabecera X-Frame-Options HTTP de respuesta HTTP a SAMEORIGIN, lo que significa que el contenido sólo puede ser cargado en un marco que tenga el mismo origen que la propia página.

Los elementos del frontend de Zabbix que extraen contenido de URLs externas (concretamente, la URL dashboard widget) mostrar el contenido recuperado en una sandbox con todas las restricciones del sandboxing activadas.

Estos ajustes mejoran la seguridad del frontend de Zabbix y proporcionan protección contra ataques XSS y clickjacking. Los superadministradores pueden modificar iframe sandboxing y X-Frame-Options HTTP response header según sea necesario. Por favor, sopese cuidadosamente los riesgos y beneficios antes de cambiar la configuración por defecto. No se recomienda desactivar por completo el sandboxing o X-Frame-Options por completo no es recomendable.

Agente Zabbix Windows con OpenSSL

El agente de Zabbix para Windows compilado con OpenSSL intentará llegar al archivo de configuración de SSL en c:\enssl-64bit. El directorio "openssl-64bit" en el disco C: puede ser creado por usuarios sin privilegios.

Así que para reforzar la seguridad, es necesario crear este directorio manualmente y revocar el acceso de escritura de los usuarios sin privilegios.

Tenga en cuenta que los nombres de los directorios serán diferentes en las versiones de 32 y 64 bits de Windows.

Cryptography

Ocultar el archivo con la lista de contraseñas comunes

Para aumentar la complejidad de los ataques de fuerza bruta a las contraseñas, se sugiere limitar el acceso al archivo ui/data/top_passwords.txt modificando la configuración del servidor web. Este archivo contiene una lista de las contraseñas más comunes y específicas del contexto, y se utiliza para evitar que los usuarios establezcan dichas contraseñas si el parámetro *Evitar contraseñas fáciles de adivinar está activado en la política de contraseñas policy.

Por ejemplo, en NGINX el acceso a los archivos puede limitarse utilizando la directiva location

· location = /data/top_passwords.txt {​​​​​​​ · deny all; · return 404; · }​​​​​​​

En Apache - utilizando el archivo .htacess:

· <Files "top_passwords.txt"> · · Order Allow,Deny · Deny from all · </Files>