Arquitectura de seguridad

Volver al Índice de Documentación Pandora FMS

El presente documento tiene como objetivo describir los elementos de seguridad de cada componente de Pandora FMS, para que el administrador los conozca y sepa cómo utilizarlos para implementar una arquitectura más segura, acorde a normativas como PCI/DSS, ISO 27001, ENS, LOPD o similares. Además de una descripción específica de los mecanismos de seguridad de cada elemento de Pandora FMS, se incide en los posibles riesgos y su manera de mitigarlos, utilizando las herramientas de que dispone Pandora FMS u otros mecanismos posibles.

Estos puntos aplican a normas internacionales como PCI/DSS, ISO 27001, Esquema de Seguridad Nacional, LOPD, entre otros. Pueden servirle para llevar a cabo una implementación segura de Pandora FMS en su entorno.

• Los componentes de Pandora FMS tienen documentados sus puertos de entrada y salida, por lo que es posible asegurar mediante cortafuegos (firewalls) todos los accesos hacia y desde sus componentes.
• Tráfico seguro mediante cifrado y certificados: Pandora FMS, a todos los niveles (operación de usuario, comunicación entre componentes), soporta cifrado SSL/TLS y certificados en ambos extremos.
• Sistema de doble autenticación de acceso: Se puede implantar un sistema de doble autenticación. El primero, a nivel de acceso (HTTP) integrado con cualquier sistema de token Opensource o comercial.
• Sistema de autenticación con terceros: A nivel de aplicación es gestionada por Pandora FMS, que se puede autenticar contra LDAP o Active Directory.
• SSO (Single Sign-On), con SAML.
• Políticas de seguridad en la gestión de usuarios: La gestión de usuarios está delimitada por políticas tanto a nivel de perfiles de usuario como a nivel de perfiles de visibilidad de operaciones, definido como el sistema de ACL Extendido de la versión Enterprise.
• Posibilidad de auditorías sobre las acciones de los elementos monitorizados: Pandora FMS, en su versión Enterprise, audita todas las acciones de los usuarios, incluyendo la información sobre los campos alterados o borrados. Además, incluye un sistema de validación por firma de estos registros.
• Cesión de datos de auditoría a gestores de logs externos: Los logs de auditoría están disponibles para su exportación mediante SQL y permiten integrarlos en una 3ª fuente para mayor seguridad, en tiempo cercano al real.
• Separación física de los componentes: Que ofrecen una interfaz al usuario y los contenedores de información (filesystem). Tanto los datos almacenados en BBDD como los filesystem que almacenan la información de configuración de monitorización pueden estar en máquinas físicas separadas, en distintas redes, protegidas a través de sistemas perimetrales.
• Política activa de contraseñas: Que permiten forzar una política estricta de gestión de contraseñas de acceso a los usuarios de la aplicación (consola).
• Cifrado de datos sensibles: El sistema permite guardar de manera cifrada y segura los datos más sensibles, tales como credenciales de acceso.

La arquitectura de Pandora FMS, de un modo muy simplificado, se puede resumir así:

• El servidor necesita permisos de root, pero puede ser instalado (con limitaciones) con permisos no root (solo en sistemas GNU/Linux).
• El servidor necesita acceso directo (lectura y escritura) a los ficheros de configuración remota de los agentes, que se propagan cuando los agentes contactan con el servidor, de manera periódica. Dichos ficheros están protegidos por el filesystem, con permisos estándar.
• El servidor como tal no escucha ningún puerto. Es el servidor de Tentacle quien escucha en un puerto, el servidor solo accede a los ficheros que este deja en disco.
• El servidor tiene su propio registro de eventos (log), muy detallado.
• El servidor se conecta con la base de datos (BBDD) principal mediante una conexión estándar MySQL/TCP.
• Parte del código es accesible (OpenSource) y el de la versión Enterprise se puede solicitar bajo condiciones específicas de contrato (solo para clientes).

Posibles vulnerabilidades y salvaguardas

• Acceso no autorizado a los archivos de configuración de los agentes. Solución:
  1. Implementar un contenedor asegurado externo para los archivos de configuración externos, vía NFS.
• Inyección de comandos en los agentes remotos a través de la manipulación de los ficheros de configuración almacenados en el contenedor de configuraciones. Solución:
  1. Deshabilitar configuración remota en los agentes especialmente sensibles después de la configuración y dejarlos funcionando sin poder alterar nada remotamente, para una seguridad absoluta.
  2. Monitorización remota -sin agentes- de los dispositivos más delicados.
• Vulnerable ante ataques de falseo de información, simulando agentes que no tenemos en el sistema o suplantando su identidad. Para evitarlo podemos utilizar varios mecanismos:
  1. Mecanismo de protección de contraseñas (que funciona por grupo).
  2. Limitando la autocreación de agentes, y crearlos de manera manual.
  3. Limitando la capacidad de autodetectar cambios en el agente y no tomar información nueva desde los XML a la ya existente.
• Captura maliciosa de la comunicación entre servidor y consola (captura de tráfico de red). Solución:
  1. Activar la comunicación TLS entre servidor y base de datos MySQl.

• Tentacle es un servicio oficial de Internet, documentado como tal por IANA. Esto significa que puede ser protegido fácilmente con cualquier herramienta de seguridad perimetral.

• No necesita root ni privilegios especiales.

• Tiene cuatro niveles de seguridad: Sin cifrado (por defecto), SSL/TLS Básico, SSL/TLS con certificado en ambos extremos, y SSL/TLS con certificado y validación de CA.

• Específicamente diseñado para no dar pistas a posibles intrusos en los mensajes de error y con períodos de expiración de tiempo (timeouts) específicos para desalentar ataques de fuerza bruta.

• Tiene un log de auditoría propio.

• El 100% del código es accesible (bajo licencia Opensource GPL2).

Posibles vulnerabilidades y salvaguardas

• Ataques al filesystem. Debe acceder al contenedor de configuraciones. Solución:
  1. Se protege de la misma manera que el servidor, mediante un sistema NFS externo asegurado.

• Ataques DoS por sobrecarga. Soluciones:
  1. Montar una solución de HA sobre el servicio TCP que ofrece para balanceo, o un clúster activo/activo. Vale cualquier solución hardware o software disponible al tratarse de un servicio TCP estándar.

• No necesita root, se instala con un usuario sin privilegios.

• Debe tener acceso al repositorio de configuraciones de agentes (filesystem).

• Escucha en puertos estándar HTTP o HTTPS.

• Registra todas las peticiones vía registro de peticiones HTTP.

• Ofrece una API pública vía HTTP/HTTPS, asegurada con credenciales y lista de direcciones IP permitidas de antemano.

• Existe una auditoría específica de aplicación, que registra la actividad de cada usuario sobre cada objeto del sistema.

• Se puede restringir el acceso de cada usuario a cualquier sección de la aplicación, y se pueden crear incluso administradores con permisos restringidos.

• La aplicación incorpora un sistema de doble autenticación.

• La aplicación incorpora un sistema de autenticación delegada (LDAP, AD).

• Se puede montar un sistema de solo lectura. Sin acceso a las configuraciones de dispositivos.

• La información confidencial (contraseñas) se puede guardar cifrada en la BBDD.

• La aplicación se conecta con la BBDD principal mediante una conexión estándar MySQL/TCP.

• Parte del código es accesible (OpenSource) y el de la versión Enterprise se puede solicitar bajo condiciones específicas de contrato (solo para clientes).

• Existe una implementación fuerte de políticas de seguridad respecto a las contraseñas (longitud, cambio forzado, histórico, tipo de caracteres validos, etc.).

Posibles vulnerabilidades y salvaguardas

• Ataques al filesystem. Debe acceder al contenedor de configuraciones. Solución:
  1. Se protege de la misma manera que el servidor, mediante un sistema NFS externo asegurado.

• Ataques de fuerza bruta o diccionario contra la autenticación de usuario. Soluciones:
  1. Implementar una política de contraseñas dura (punto 14).
  2. Implementar un mecanismo de doble autenticación (punto 8).

• Captura de tráfico (eavesdropping) del tráfico a la consola. Solución:
  1. Implementar SSL/TLS.

• Captura de tráfico (eavesdropping) del tráfico a la base de datos. Solución:
  1. Implementar SSL/TLS.

• Ataques de tipo SQL injection para obtener información confidencial de la BBDD de la aplicación. Solución:
  1. Implementar almacenamiento cifrado de datos.

• Mal uso (intencionado o no intencionado) por parte de los usuarios de la aplicación. Soluciones:
  1. Activar el log de auditoría y mostrarle a los usuarios que existe y su precisión.
  2. Activar el sistema de ACL extendido para restringir al máximo las funciones de cada usuario.
  3. Exportar el log de auditoría a un sistema externo de forma regular.

• Ejecución de código malicioso en herramientas locales de la consola, reemplazando ficheros binarios. Solución:
  1. Aseguramiento o fortalecimiento (hardening) del servidor que contiene la aplicación.

• Puede ejecutarse sin permisos de superusuario (con funcionalidades limitadas).
• La gestión remota del agente se puede desactivar (en local y en remoto), de manera que se puede minimizar el impacto de una intrusión en el sistema central.
• El agente no escucha puertos de red, es él el que se conecta al servidor de Pandora FMS.
• Existe un registro de cada ejecución.
• Los ficheros de configuración están protegidos por defecto, mediante permisos del filesystem. Solo un usuario con permisos de superadministrador puede modificarlos.
• El 100% del código es accesible (bajo licencia Opensource GPL2).

Posibles vulnerabilidades y salvaguardas

• Intrusión en el sistema central que permita distribuir ejecución de comandos maliciosos a los agentes. Soluciones:
  1. Limitar qué usuarios pueden realizar esas modificaciones de políticas o configuraciones (via ACL ordinario de la consola o ACL extendido).
  2. Activar el modo de solo lectura (readonly) de los agentes (no permiten modificaciones de su configuración remotamente), para aquellos sistemas especialmente sensibles.

• Debilidad en el filesystem que permita modificar ficheros. Solución:
  1. Correcta configuración de permisos.
• Ejecución de plugins o comandos maliciosos. Solución:
  1. Limitar qué usuarios pueden subir ejecutables (vía ACL ordinario de la consola o ACL extendido).
  2. Realizar una auditoría de plugins nuevos.

• Es un producto estándar (MySQL).

Posibles vulnerabilidades y salvaguardas

• Eavesdropping (captura de tráfico de red). Solución:
  1. Implementación de una conexión segura TLS. MySQL la soporta.

• Permisos incorrectos. Solución:
  1. Configuración correcta de permisos de acceso.

• Vulnerabilidades conocidas de MySQL. Es recomendable establecer un plan de actualización del servidor MySQL en el que podamos tener lo más actualizado posible el mismo, y de esta forma librarnos de las posibles vulnerabilidades que puedan tener versiones antiguas.

El fortalecimiento (hardening) o aseguramiento de sistemas es un punto clave en la estrategia de seguridad global de una compañía. Como fabricantes emitimos una serie de recomendaciones para realizar una instalación segura de todos los componentes de Pandora FMS, basados en una plataforma estándar RHEL7 o su equivalente Centos7. Estas mismas recomendaciones son válidas para cualquier otro sistema de monitorización basado en GNU/Linux.

Para acceder al sistema, se crearán usuarios nominativos de acceso, sin privilegios y con acceso restringido a las necesidades que tengan. Idealmente se debería integrar la autenticación de cada usuario con un sistema de autenticación doble, basado en token. Existen alternativas gratuitas y seguras como Google Authenticator®integrables en GNU/Linux, aunque fuera del alcance de esta guía. Considere seriamente su uso.

Si es necesario crear otros usuarios para aplicaciones, deben ser usuarios sin acceso remoto (para ello, desactivar su Shell o método equivalente)

En el caso de que ciertos usuarios tengan que tener permisos de administrador se utilizará el comando sudo.

Bastará con estar conectado a la red o configurar su sistema yum para que utilice un servidor proxy.

Este comando puede ocasionar potenciales problemas de cambio de librerías, configuraciones, etc. Es importante no saltarse la actualización del sistema, especialmente cuando vaya a poner el sistema en producción. Si está revisando un sistema de producción ya activo, quizás necesite actualizar solo aquellos componentes críticos, por ejemplo aquellos que tengan una vulnerabilidad, por ejemplo si quisiera actualizar solo mysql server, utilice el comando con el nombre del paquete que quiere actualizar.

yum update mysql-server

La actualización del sistema es un proceso que debería ser periódico. Mediante el inventariado de paquetes del sistema, puede consultar versiones vulnerables y ejecutar actualizaciones de emergencia.

Es necesario tener activo el log de seguridad /var/log/secure y monitorizar esos logs con la monitorización (que veremos más adelante).

Por defecto los CentOS vienen con esto activado. Si no es así, revisar el fichero /etc/rsyslog.conf o /etc/syslog.conf .

Recomendamos que se lleve los logs del sistema de auditoría y los recoja con un sistema externo de gestión de logs, Pandora FMS puede hacerlo fácilmente y le será útil para establecer alertas o revisarlos de manera centralizada en caso de necesidad.

El servidor SSH nos permite la conexión remota a nuestros sistemas GNU/Linux para la ejecución de comandos, por lo que se trata de un punto crítico y debe asegurarse prestando atención a los siguientes puntos (para ello edite el fichero /etc/ssh/sshd_config y posteriormente, reinicie el servicio).

• Modificar puerto por defecto (por ejemplo al 31122)

#Port22     ->     Port 31122

• Deshabilitar el inicio de sesión al superusuario root login

#PermitRootLogin yes        ->    PermitRootLogin no

• Deshabilitar el reenvío de puertos port forwarding

#AllowTcpForwarding yes        ->    AllowTcpForwarding no

• Deshabilitar tunneling

#PermitTunnel no        ->    PermitTunnel no

• Eliminar llaves SSH para acceso remoto de root. Asumimos que solo hay un usuario válido para acceso remoto (por ejemplo, artica). Su hubiere otros, también habría que comprobarlos. Para ello, miramos el contenido del fichero /home/artica/.ssh/authorized_keys y ver de qué máquinas somos. Borrarlo si creemos que no debería haber ninguno.

• Establecer un aviso de acceso remoto estándar que explique que el servidor es de acceso privado y que cualquier persona sin credenciales debe desconectar.

Banner /etc/issue.net

Puerto de escucha. Si el servidor MySQL tiene que dar servicio al exterior, simplemente controlaremos que las credenciales de root son seguras. Si el MySQL solo da servicio a un elemento interno, nos aseguramos de que solo escucha en localhost:

netstat -an | grep 3306 | grep LIST
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN

En este caso está escuchando para todo el mundo, debemos asegurarlo. Para ello, editaremos el fichero /etc/my.cnf y en la sección [mysqld] añadiremos la siguiente línea:

bind-address = 127.0.0.1

Y volveremos a verificar que está escuchando, pero ahora solo en localhost tras reiniciar el servicio:

netstat -an | grep 3306 | grep LIST
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN

Contraseña MySQL

Conectar a la consola de MySQL con un usuario con privilegios:

mysql -h host -u root -p

Verificar que la contraseña es segura y que nos ha pedido contraseña. De no ser así, la estableceremos con el comando:

mysqladmin password

Esta medida de seguridad es imprescindible para proteger nuestras bases de datos no solo ante ataques externos sino ante usos incorrectos por parte de usuarios internos.

Añadiremos la siguiente línea al fichero /etc/httpd/conf/httpd.conf para ocultar la versión del apache y del SO en las cabeceras de información del server.

ServerTokens Prod

Esta técnica, que puede ser muy exhaustiva, consiste simplemente en eliminar todo lo que no sea necesario en el sistema. Así evitamos posibles problemas en un futuro con aplicaciones mal configuradas que realmente no necesitemos. Para simplificar la aproximación a esta práctica, vamos a considerar únicamente aquellas aplicaciones que tienen un puerto abierto en la máquina, para ello, ejecutaremos el comando siguiente:

netstat -tulpn

Debe devolver un resultado por cada puerto en escucha, algo parecido a esto, pero no igual:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      996/master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      75171/httpd
tcp        0      0 0.0.0.0:31122           0.0.0.0:*               LISTEN      872/sshd
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      75097/mysqld
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      75171/httpd
tcp        0      0 0.0.0.0:6099            0.0.0.0:*               LISTEN      7721/Xvfb
tcp6       0      0 :::4444                 :::*                    LISTEN      7726/java
tcp6       0      0 :::34599                :::*                    LISTEN      7726/java
tcp6       0      0 :::6099                 :::*                    LISTEN      7721/Xvfb

Si hemos desactivado IPv6 no deberíamos ver líneas tcp6 a no ser que sean servicios que se arrancaran en modo ipv6 y que se hayan quedado sin reiniciar después de hacer un cambio en el sistema con sysctl.

Deberíamos investigar cada puerto y conocer la aplicación que hay detrás. En este caso, 443, 80 parece que son del servicio http, pero para ello y estar seguro analizaremos que procesos del sistema están usando cada puerto. Para ello usaremos el comando lsof, que habrá que instalar con yum porque no viene por defecto instalado.

Aquellos servicios que escuchan en localhost (127.0.0.1) son más seguros que los que escuchan a todas las direcciones IP (0.0.0.0) y algunos de ellos, si están escuchando en abierto, deberíamos intentar asegurarlos para que escuchen solo a localhost. En esta pantalla de ejemplo se ha hecho por ejemplo para el MySQL (3306).

Por ejemplo, vemos que el proceso principal de postfix, está ejecutándose. Como no necesitamos este servicio, lo desinstalamos del sistema:

yum remove postfix

Investigando el PID de cada uno de los procesos en duda (ver paso anterior) veremos el proceso que está en ese puerto:

ps aux | grep 7726 root 7726 0.1 8.5 3258724 248608 ? Sl Mar09 60:01 /usr/bin/java -jar /usr/lib/pwr/selenium-server-standalone-2.53.1.jar -host 185.247.117.28 -port 4444 -firefoxProfileTemplate /opt/firefox_profile root 79041 0.0 0.0 112716 960 pts/4 S+ 11:54 0:00 grep --color=auto 7726

Y si no estamos usando ese servicio, podemos eliminarlo.

Este proceso de “investigación” de procesos debe ser exhaustivo y repetitivo en el tiempo. Mediante el sistema de inventario de procesos de Pandora FMS, debemos verificar que no se inicien nuevos procesos a lo largo del tiempo. Un puerto en escucha en un servidor es algo muy significativo desde el punto de seguridad, sería como una ventana en la fachada del edificio. Puede que creamos que está cerrada y que es segura, pero una ventana, siempre será un posible punto de entrada para un intruso cualificado y motivado.

Se recomienda configurar la sincronización horaria del sistema:

yum install ntpdate
echo "ntpdate 0.us.pool.ntp.org"> /etc/cron.daily/ntp
chmod 755 /etc/cron.daily/ntp

El sistema debería tener un Agente Software Pandora FMS instalado y lanzado contra nuestro servidor. Para el sistema operativo MS Windows®, a partir de la versión 761, los ejecutables de instalación están firmados.

Se recomiendan los siguientes chequeos activos además de los chequeos estándar:

• Complemento (plugin) de seguridad activo.
• Inventario completo del sistema (especialmente usuarios y paquetes instalados).
• Recogida de logs del sistema y seguridad:

 module_plugin grep_log_module /var/log/messages Syslog \.\*
 module_plugin grep_log_module /var/log/secure Secure \.\*

Una vez instalado el Agente Software, habrá que definir manualmente al menos la siguiente información en la ficha de agente:

• Descripción.
• Dirección IP (si tiene varias, poner todas).
• Grupo.
• Departamento, responsable y ubicación física (custom fields).

El plugin oficial permite monitorizar de forma proactiva la seguridad en el agente, en cada ejecución, casi en tiempo real, ofreciendo algunos chequeos que pueden alertarnos de algunos sucesos relevantes de manera proactiva.

Este plugin está pensado para funcionar solamente en equipos GNU/Linux modernos. Está preparado para funcionar en 64 y 32 bits.

Contiene una compilación personalizada de John the ripper 1.8 + parches Contrib con binarios estáticos de 32 y 64. El concepto principal del plugin es ser monolítico, detectar lo que puede ser reforzado y tratar de resolver las diferencias entre distros sin preguntar nada al administrador, por lo que el despliegue podría ser el mismo para cualquier sistema, ignorando versiones, distro o arquitectura.

Este plugin comprobará:

• Comprobación de auditoría de contraseñas de usuario, usando el diccionario (proporcionado) con las 500 contraseñas más comunes. Esto no suele llevar más de unos segundos. Si tiene cientos de usuarios, probablemente necesite personalizar la ejecución del plugin para que se ejecute sólo cada 2-6 horas. Puede personalizar el diccionario de contraseñas simplemente añadiendo la contraseña típica de su organización en el archivo “basic_security/password-list”.
• Compruebe que SSH no se ejecute el puerto por defecto.
• Compruebe que el FTP no se ejecuta en el puerto por defecto.
• Compruebe que SSH no permita el acceso de root.
• Verifique si hay un MySQL corriendo sin la contraseña de root definida.
• Otros chequeos.

Volver al Índice de Documentación Pandora FMS