Esta sección contiene las mejores prácticas que deben observarse 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.
El principio de privilegio mínimo debe utilizarse en todo momento para Zabbix. Este principio significa que las cuentas de usuario (en la interfaz de Zabbix) o el usuario del proceso (para servidor/proxy o agente de Zabbix) tiene solo aquellos privilegios que son esenciales para realizar las funciones previstas. En otras palabras, las cuentas de usuario en todo momento deben ejecutarse con la menor cantidad de privilegios posible.
Dar permisos adicionales al usuario 'zabbix' le permite acceder a archivos de configuración y ejecutar operaciones que pueden comprometer la seguridad general de la infraestructura.
Al implementar el principio de privilegios mínimos para las cuentas de usuario, los tipos de usuario de la interfaz Zabbix deben tenerse en cuenta. Es importante entender que mientras un tipo de usuario "Administrador" tiene menos privilegios que el tipo de usuario "Super Admin", tiene permisos administrativos que permiten gestionar la configuración y ejecutar scripts personalizados.
Cierta información está disponible incluso para usuarios sin privilegios. Por ejemplo, mientras que Alertas → Scripts no está disponible para los que no son superadministradores, los scripts están disponibles para su recuperación utilizando la API de Zabbix. Se debe limitar los permisos de los scripts y no agregar información confidencial (como credenciales de acceso, etc.) para evitar la exposición de la información sensible disponible en los scripts globales.
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:
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.
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.
En sistemas basados en RHEL, instale el paquete mod_ssl
:
Cree un directorio para claves SSL:
Cree el 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
Complete las indicaciones adecuadamente. La línea más importante es la que solicita el Nombre común
. Debe ingresar el nombre de dominio que desea asociar con su servidor. En su lugar, puede ingresar la dirección IP pública si no tiene un nombre de dominio.
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (por ejemplo, su nombre o el nombre de equipo de su servidor) []:ejemplo.com
Email Address []:
Edite el archivo de 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:
En sistemas basados en RHEL, agregue un equipo virtual a la configuración de Apache (/etc/httpd/conf/httpd.conf
) y establezca una redirección permanente para la raíz del documento a la URL SSL de Zabbix. Tenga en cuenta que example.com debe reemplazarse con el nombre real del servidor.
# Agregar líneas:
<Host virtual *:*>
ServerName example.com
Redirect permanent / https://example.com
</VirtualHost>
Reinicie el servicio Apache para aplicar los cambios:
Para proteger la interfaz de Zabbix contra ataques de degradación de protocolo, recomendamos habilitar la política HSTS en el servidor web.
Para habilitar la política HSTS para su interfaz Zabbix en la configuración de Apache, siga estos pasos:
1. Localice el archivo de configuración de su host virtual:
/etc/httpd/conf/httpd.conf
en sistemas basados en RHEL/etc/apache2/sites-available/000-default.conf
en Debian/Ubuntu2. Agregue la siguiente directiva al archivo de configuración de su host virtual:
3. Reinicie el servicio Apache para aplicar los cambios:
# En sistemas basados en RHEL:
systemctl restart httpd.service
# En Debian/Ubuntu
systemctl restart apache2.service
Para proteger la interfaz de Zabbix contra Cross Site Scripting (XSS), inyección de datos y ataques similares, recomendamos habilitar la Política de seguridad de contenido en el servidor web. Para hacerlo, configure el servidor web para que devuelva el encabezado HTTP.
La siguiente configuración del encabezado CSP es solo para la instalación predeterminada de la interfaz de Zabbix y para los casos en los que todo el contenido se origina en el dominio del sitio (excluidos los subdominios). Es posible que se requiera una configuración de encabezado CSP diferente si, por ejemplo, está configurando el widget URL para mostrar contenido de los subdominios del sitio o dominios externos, cambiando de OpenStreetMap a otro motor de mapas, o agregando CSS o widgets externos.
Para habilitar CSP para su interfaz Zabbix en la configuración de Apache, siga estos pasos:
1. Localice el archivo de configuración de su host virtual:
/etc/httpd/conf/httpd.conf
en sistemas basados en RHEL/etc/apache2/sites-available/000-default.conf
en Debian/Ubuntu2. Agregue la siguiente directiva al archivo de configuración de su host virtual:
<Host virtual *:*>
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. Reinicie el servicio Apache para aplicar los cambios:
# En sistemas basados en RHEL:
systemctl restart httpd.service
# En Debian/Ubuntu
systemctl restart apache2.service
Se recomienda desactivar todas las firmas del servidor web como parte del proceso de endurecimiento del servidor web. El servidor web está exponiendo la firma del software por defecto:
La firma se puede deshabilitar agregando dos líneas al archivo de configuración de Apache (usado como un ejemplo):
La firma PHP (encabezado HTTP X-Powered-By) se puede desactivar cambiando el archivo de configuración php.ini (la firma está deshabilitada de forma predeterminada):
Es necesario reiniciar el servidor web para que se apliquen los cambios en el archivo de configuración.
Se puede lograr un nivel de seguridad adicional utilizando mod_security (paquete libapache2-mod-security2) con Apache. mod_security permite eliminar la firma del servidor en lugar de solo eliminar la versión de la firma del servidor. La firma se puede modificar a cualquier valor cambiando "SecServerSignature" a cualquier valor deseado después de la instalación de mod_security.
Consulte la documentación de su servidor web para encontrar ayuda sobre cómo eliminar/cambiar firmas de software.
Se recomienda desactivar las páginas de error predeterminadas para evitar la exposición de información. El servidor web utiliza páginas de error integradas de forma predeterminada:
Las páginas de error predeterminadas deben reemplazarse o eliminarse como parte del proceso de endurecimiento del servidor web. La directiva "ErrorDocument" se puede utilizar para definir una página/texto de error personalizado para el servidor web Apache (usado como ejemplo).
Consulte la documentación de su servidor web para encontrar ayuda sobre cómo reemplazar/eliminar páginas de error predeterminadas.
Se recomienda eliminar la página de prueba del servidor web para evitar la exposición de la información. De forma predeterminada, el webroot del servidor web contiene una página de prueba llamada index.html (se utiliza Apache2 en Ubuntu como ejemplo):
La página de prueba debe eliminarse o dejar de estar disponible como parte del el proceso de endurecimiento del servidor web.
De forma predeterminada, Zabbix está configurado con el encabezado HTTP X-Frame-Options establecido en SAMEORIGIN
. Esto significa que el contenido solo se puede cargar en un marco que tiene el mismo origen que la propia página.
Los elementos de la interfaz de Zabbix que extraen contenido de URLs externas (es decir, la URL del widget del tablero), muestra el contenido recuperado en una "sandbox" con todas las restricciones de la "sandbox" activadas.
Estas configuraciones mejoran la seguridad de la interfaz de Zabbix y brindan protección contra ataques XSS y de clickjacking. Los superadministradores pueden modificar los parámetros usar sandboxing de iframe y usar encabezado HTTP X-Frame-Options según sea necesario. Sopese cuidadosamente los riesgos y beneficios antes de cambiar la configuración predeterminada. No se recomienda desactivar por completo el sandboxing o el encabezado HTTP X-Frame-Options.
El agente de Windows Zabbix compilado con OpenSSL intentará alcanzar el archivo de configuración SSL en c:\openssl-64bit. El directorio "openssl-64bit" en el disco C: puede ser creados por usuarios sin privilegios.
Entonces, para reforzar la seguridad, es necesario crear este directorio. manualmente y revocar el acceso de escritura de usuarios que no sean administradores.
Tenga en cuenta que los nombres de los directorios serán diferentes en sistemas de 32 bits y versiones de 64 bits de Windows.
Para aumentar la complejidad de los ataques de fuerza bruta a 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á habilitado en la política de contraseñas.
Por ejemplo, en NGINX el acceso a archivos se puede limitar usando la directiva location
:
En Apache, usando el archivo .htaccess
: