Pandora: Documentation es: Arquitectura de seguridad

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Arquitectura de seguridad


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.

Seguridad1.PNG


2 Implementación de seguridad (general)


Estos puntos aplican a normas internacionales como PCI/DSS, ISO 27001, Esquema de Seguridad Nacional, LOPD, etc. Pueden servirle para guiar 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 securizar mediante 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.


3 Seguridad por componentes de la arquitectura


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

Seguridad2.PNG


3.1 Servidor


  • El servidor necesita permisos de root, pero puede ser instalado (con limitaciones) con permisos no root (solo en sistemas 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 log, muy detallado.
  • El servidor 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).


Posibles vulnerabilidades y salvaguardas

  • Acceso no autorizado a los archivos de configuración de los agentes. Solución:
  1. Implementar un contenedor securizado 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 password (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.

3.2 Tentacle


  • 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 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 securizado.
  • Ataques DoS por sobrecarga. Soluciones:
  1. Montar una solución de HA sobre el servicio TCP que ofrece para balanceo, o un cluster activo/activo. Vale cualquier solución hardware o software disponible al tratarse de un servicio TCP estándar.

3.3 Consola


  • 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, securizada con credenciales.
  • 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 securizado.
  • 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. Securización (hardening) del servidor que contiene la aplicación.

3.4 Agentes


  • 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 “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.
  2. Ejecución de plugins o comandos maliciosos. Solución:
  3. Limitar qué usuarios pueden subir ejecutables (vía ACL ordinario de la consola o ACL extendido).
  4. Realizar una auditoría de plugins nuevos.


3.5 Base de datos


  • 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.