La arquitectura de seguridad en la monitorización

Introducción

Haz un ejercicio, pregúntale a cinco técnicos en IT -de cualquier perfil- qué significa SNMP. Si acaso es posible que tengas confianza con ellos para que lo primero que hagan no sea ir a Wikipedia para dárselas de listo. Con suerte, quizás te digan lo que me decían a mí cuando trabajaba en redes.

“Security is Not My Problem”

Teniendo en cuenta que el protocolo SNMP es una de las bases de monitorización, y un sistema que lleva más de treinta años en uso, esta respuesta, “Security is Not My Problem”, resume bastante bien la situación de la monitorización en el panorama actual: desconocimiento, desidia y falta de interés por la seguridad en la monitorización.

Por cierto, de SNMP hablamos en otro artículo de nuestro blog y ya adelanto que significa Simple Network Management Protocol y que viene de 1987.

Teniendo en cuenta que la monitorización es la “llave del reino”, ya que permite acceder a todos los sistemas e incluso acceder muchas veces con credenciales de administración, ¿no deberíamos tomarnos un poco más en serio la seguridad cuando hablamos de ella?

Las recientes vulnerabilidades en sistemas de monitorización de sobrada reputación como Solarwinds o Centreon hacen cada vez más urgente la necesidad de tomar en serio la seguridad en la implantación de sistemas de monitorización, ya que estos tienen una integración muy fuerte con los sistemas.

En muchos casos, los problemas de seguridad no tratan tanto de que un software sea mucho más seguro que otro, sino de una deficiente configuración y/o arquitectura. Hay que tener en cuenta que un sistema de monitorización es complejo, extenso, y por lo general, está muy adaptado a cada organización. Hoy ha sido Solarwinds, mañana puede ser Pandora FMS o Nagios.

Ninguna aplicación es segura al 100%, ni ninguna red corporativa está asegurada frente a intrusiones, sea cual sea el tipo. Esto es un hecho cada vez más evidente y lo único que se puede hacer respecto a ello es conocer los riesgos y asumir cuales podemos asumir, cuáles no, y trabajar en estos últimos.

Arquitectura segura de monitorización

Es fundamental tener en la cabeza en todo momento que un sistema de monitorización contiene información clave para un posible intruso. Si la monitorización cae en manos equivocadas tu sistema estará comprometido. Por eso es tan importante dedicar un tiempo a la arquitectura de tu sistema de monitorización, sea cual sea.

Realiza un primer análisis, recogiendo los requisitos y el alcance de tu estrategia de monitorización:

• Identificar qué sistemas vas a monitorizar y catalogar sus niveles de seguridad.
• Identificar qué perfiles van a tener acceso al sistema de monitorización.
• Identificar cómo obtendrá información de dichos sistemas, si es a través de sondas/agentes o por datos remotos.
• Identificar quienes son los responsables de los sistemas que va a monitorizar.

La arquitectura de un sistema poseerá, sea cual sea el software escogido, los siguientes elementos y tendrá que tener en cuenta su topología de red, sus recursos y la forma de protegerlos debidamente:

1. Interfaz de visualización de la información (consola web, aplicación pesada).
2. Almacenamiento de datos (generalmente una base de datos relacional).
3. Recolectores de información (servidores intermedios, pollers, colectores, etc).
4. Agentes (opcional).
5. Sistema de notificación (alertas, avisos, etc).

Securización del sistema de monitorización

Por muy correcta que sea la implementación de un sistema, su arquitectura y su diseño en conjunto, si uno de los elementos que lo componen es vulnerado, los daños causados a éste por un ataque malicioso comprometen a toda la estructura. Por ello en seguridad existe un dicho, “La seguridad es una cadena y su seguridad real depende siempre de su eslabón más débil”.

Esta lista de conceptos de seguridad aplicados a la arquitectura de un sistema de monitorización se puede resumir como las funcionalidades que debe tener un producto de monitorización para asegurar la máxima seguridad en una implantación:

• Tráfico cifrado entre todos sus componentes.
• Alta disponibilidad de todos sus componentes.
• Backup integrado.
• Doble autenticación de acceso.
• Sistema de autenticación delegado (LDAP, AD, SAML, Kerberos, etc).
• ACL y perfilado de usuarios.
• Auditoría interna.
• Política de contraseñas.
• Cifrado de datos sensibles.
• Contenedores de credenciales.
• Monitorización de zonas restringidas / acceso indirecto.
• Instalación sin superusuario.
• Arquitectura segura agente/servidor (pasiva).
• Sistema de actualización distribuido y centralizado.
• Soporte 24×7.
• Política clara de gestión de vulnerabilidades por parte del fabricante.

Securización básica de la infraestructura de monitorización

La consola de gestión, servidores de monitorización y otros elementos jamás deberían estar en una red pública accesible. La consola debería estar siempre protegida en una red interna, protegida por firewalls y a ser posible, en una red independiente de otros sistemas de gestión.

Los sistemas operativos que alberguen la infraestructura de monitorización no deben usarse para otros propósitos: por ejemplo, reutilizar la base de datos para otras aplicaciones, ni los sistemas operativos base para ejecutar otras aplicaciones.

Tráfico seguro y cifrado

Deberías asegurarte de que tu sistema soporta cifrado SSL/TLS y certificados en ambos extremos a todos los niveles: operación de usuario, comunicación entre componentes, envío de datos desde el agente a los servidores.

Si vas a emplear agentes en ubicaciones poco seguras, es más que recomendable que fuerces a todos los agentes externos a emplear una autenticación basada en certificados en ambos extremos, para eludir recibir información de fuentes no autorizadas y para evitar que la información recogida por los agentes no viaje en claro.

Por otro lado es muy importante que actives el cifrado en tu servidor web para proveer una consola de administración cifrada y evitar que cualquier atacante pueda ver credenciales de acceso, password de sistemas remotos o información confidencial.

Alta Disponibilidad total.

Para todos los elementos: base de datos, servidores, agentes y consola.

Backup integrado.

La propia herramienta debería facilitar al máximo esto, ya que a menudo las configuraciones y los datos están muy distribuidos y es complejo realizar una copia de seguridad coherente.

Política clara de gestión de vulnerabilidades por el fabricante

Todos los días decenas de auditores independientes prueban las fortalezas y debilidades de todo tipo de aplicaciones comerciales. Buscan hacerse un hueco en el sector publicando un fallo desconocido que eleve su reputación. Muchos clientes, como parte de sus procesos internos de gestión de la seguridad, ejecutan auditorías externas e internas de seguridad que tienen como objeto su infraestructura IT.

Sea como sea, todos los productos tienen fallos de seguridad, la cuestión es: ¿cómo se gestionan esos fallos? La transparencia, diligencia y comunicación son esenciales para evitar que los clientes tengan problemas derivados de las vulnerabilidades del software que utilizan. Es fundamental que haya una política clara al respecto, de manera que se conozcan qué vulnerabilidades públicas se han reportado, cuándo se han corregido y que si se detecta una nueva, se sepan los pasos a seguir para notificación, mitigación y distribución al cliente final.

Sistema de doble autenticación

Pandora FMS dispone de un sistema -opcional- basado en google authenticator que permite forzar su uso a todos los usuarios por política de seguridad. Esto hará mucho más seguro el acceso de usuarios a la consola de administración, impidiendo que por una escalada de privilegios se pueda acceder como administrador al sistema, que es como mucho, el mayor riesgo que se puede correr.

Sistema de autenticación delegado

Complementario al anterior, puede delegar la autenticación de la consola de administración para autenticar contra LDAP, Active Directory o SAML. Te permitirá una gestión centralizada de accesos, y en combinación con el sistema de doble autenticación harás muchísimo más seguro su acceso.

ACL y perfilado de usuarios

Identifica y asigna diferentes usuarios, a personas concretas. No utilices usuarios genéricos, asigna sólo los permisos necesarios y no utilices “superadministradores”. Son buenas prácticas no solo para herramientas de monitorización sino para cualquier implantación de software empresarial con acceso a información sensible.

Hoy día cualquier herramienta profesional para definir un perfil de acceso a cada usuario lo hará de manera que ningún usuario tenga “control absoluto”, sino que solo tenga los accesos mínimos exigidos a sus funciones.

Sistema de auditoría interna

Se debe disponer de un sistema que registre todas las acciones de los usuarios, incluyendo la información sobre los campos alterados o borrados. Dicho sistema debe poder exportarse al exterior para que ni siquiera el usuario administrador pueda alterar dichos registros.

Política de contraseñas

Un elemento básico que nos permita forzar una política estricta de gestión de contraseñas de acceso a los usuarios de la aplicación: tamaño mínimo de contraseñas, tipo de password, reutilización de las mismas, forzado de cambio cada x tiempo, etc.

Cifrado de datos sensibles.

El sistema debe permitir guardar de manera cifrada y segura los datos más sensibles, tales como credenciales de acceso, campos personalizados de los elementos de monitorización, etc. Aunque el propio sistema contenga la “semilla” de cifrado, siempre será mucho más difícil el acceso a dicha información por parte de un posible atacante.

Contenedores de credenciales.

O un sistema equivalente para poder delegar el uso de credenciales por parte del administrador a otros usuarios que emplean dichas credenciales para monitorizar elementos sin ver las passwords contenidas en el contenedor.

Monitorización de zonas restringidas

En dichos sistemas, se recogerá información de manera remota por parte de un servidor satélite y se dispondrá para ser recogida desde el sistema central (en Pandora FMS a través de un componente específico llamado Sync server). De esta manera se pueden recoger datos de una red sin acceso al exterior, ideal para entornos muy restrictivos donde se reduce drásticamente el impacto en caso de que un atacante se haga con el sistema.

Sistema de bloqueo de gestión remota de agentes

Para entornos críticos de seguridad, donde el agente no pueda ser gestionado remotamente una vez que está configurado. Esto es especialmente crítico en la monitorización, ya que si un sistema es vulnerado y se accede a su administración, por la propia esencia del sistema, este tendrá acceso a todos los sistemas desde donde recibe información. En aquellos sistemas críticos habrá que desactivar la capacidad de gestión remota, aunque eso haga más incómoda la administración. Lo mismo se aplica a actualizaciones automáticas en el agente.

Diseño de arquitectura segura de comunicación con agentes

A veces conocido como comunicación pasiva. De esta manera, los agentes no escucharán un puerto ni tendrán acceso remoto desde la consola. Son ellos, quienes conectarán con el sistema central para pedir instrucciones.

Instalación sin root

Pandora FMS puede ser instalado en entornos con paths personalizados sin ejecutarse con root. En algunos entornos bancarios es un requisito que cumplimos.

Sistema de notificación y reportes (alertas, avisos, etc)

Un sistema de monitorización sólo es útil si muestra información veraz en el momento que se necesita. La recepción de una alerta o el informe semanal es la culminación de todo el trabajo previo y para eso deberá tener en cuenta algunos puntos “obvios” pero que se suelen pasar de largo. Proteje esos sistemas, allí donde estén.

Actualizaciones periódicas

Todos los fabricantes distribuyen ya actualizaciones periódicas, que incluyen tanto correcciones de bugs como de problemas de seguridad. En nuestro caso, publicamos actualizaciones aproximadamente cada cinco semanas. Es fundamental actualizar los sistemas tan pronto como sea posible, pues cuando se comunica una vulnerabilidad, los responsables de producto piden a los investigadores de seguridad externos que han reportado el bug, que no publiquen nada acerca de la vulnerabilidad hasta haber publicado un parche. Una vez publicado el parche, el investigador publicará la información con mayor o menor detalle, hecho que puede servir para explotar y atacar aquellas versiones de software no actualizadas.

Pandora FMS dispone de una política pública de comunicación de vulnerabilidades así como un catálogo público de vulnerabilidades conocidas y reportadas. Nuestra política es de máxima transparencia y comunicación total con investigadores de seguridad, siempre para paliar el impacto de cualquier problema de seguridad y poder proteger a nuestros clientes como prioridad máxima.

Soporte 24×7

En nuestro soporte, el técnico que atiende el teléfono tiene detrás a todo el equipo. Si existe una incidencia de seguridad y un parche de seguridad tiene que ser publicado en cuestión de horas. No sólo disponemos de la tecnología para propagar a todos nuestros clientes el parche, sino al equipo para desarrollarlo en tiempo récord.

Securización del sistema base

El hardening o securización 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:

Checklist de hardening para sistema base de monitorización:

 

• Credenciales de acceso al sistema.
• Gestión de acceso de superusuario.
• Auditoría de acceso al sistema.
• Securización SSH.
• Securización servidor web.
• Securización servidor BBDD.
• Minimización de servicios.
• Monitorización local.

Credenciales de acceso

Para acceder al sistema, se crearán usuarios nominativos de acceso, sin privilegios y con acceso restringido a las necesidades que tengan. De forma ideal 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 fácilmente integrables en 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, es necesario desactivar su Shell o algún método equivalente)

Acceso de superusuario vía sudo

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

Auditoría de acceso al sistema base

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í, bastará con revisar el fichero /etc/rsyslog.conf o /etc/syslog.conf

Recomendamos que te lleves los logs del sistema de auditoría y los recojas 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.

Securización servidor SSH

El servidor SSH nos permite la conexión remota a nuestros sistemas Linux para la ejecución de comandos, por lo que se trata de un punto crítico y debe securizarse prestando atención a los siguientes puntos:

• Modificar puerto por defecto.
• Deshabilitar root login.
• Deshabilitar port forwarding.
• Deshabilitar tunneling.
• Eliminar llaves SSH para acceso remoto de root.
• Investigar qué orígenes hay de llaves para acceso remoto. Para ello, miramos el contenido del fichero /home/xxxx/.ssh/authorized_keys y vemos de qué máquinas son. Borrarlos si creemos que no debería haber ninguno.
• Establecer un banner de acceso remoto estándar que explique con claridad que el servidor es de acceso privado y que cualquier persona sin credenciales debe desconectar.

Securización servidor MySQL

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.

Securización del servidor web.

Modificaremos la configuración para ocultar la versión del apache y del SO en las cabeceras de información del server.

Si utilizas SSL desactiva los métodos inseguros. Recomendamos el uso de TLS 1.3 únicamente.

Minimización de servicios en el sistema

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 necesitamos y que puedan ser vulnerables en un futuro.

Monitorización local

Todos los sistemas internos de monitorización deberían estar monitorizados al máximo nivel, especialmente los registros de información. En nuestro caso siempre se recomiendan los siguientes chequeos activos además de los chequeos estándar:

• Plugin de seguridad activo.
• Inventario completo del sistema (especialmente usuarios y paquetes instalados).
• Logs de sistema y seguridad del servidor.

¿Quieres conocer mejor qué es lo que Pandora FMS puede ofrecerte? Descúbrelo entrando aquí.

Si tienes que monitorizar más de 100 dispositivos también puedes disfrutar de un TRIAL GRATUITO de 30 días de Pandora FMS Enterprise. Instalación en Cloud u On-Premise, ¡¡tú eliges!! Consíguelo aquí.

Por último, recuerda que si cuentas con un número reducido de dispositivos para monitorizar puedes utilizar la versión OpenSource de Pandora FMS. Encuentra más información aquí.

No dudes en enviar tus consultas. ¡El equipazo que se encuentra detrás de Pandora FMS estará encantado de atenderte!

Y si quieres seguir el ritmo de todas nuestras novedades y te va el rollo IT, release y, por supuesto, monitorización, te esperamos en este nuestro blog y en nuestras distintas redes sociales, desde Linkedin a Twitter pasando por el inolvidable Facebook. Hasta canal de Youtube tenemos, y con mejores narradores que El Rubius y AuronPlay.