Monitorización de puertos con Pandora FMS

Todas las tareas de Pandora FMS descansan –o tienen que ver- con la monitorización de puertos

El antiguo Imperio Romano gustaba de llamar a lo que ahora es el Mar Mediterráneo como Mare Nostrum (Nostrum Mare), colocando a la que ahora es la ciudad portuaria de Barcelona como punto de entrada a Hispania (hoy Península Ibérica) desde la ciudad de Miseno, ubicada en el sur de lo que ahora es Italia. Para los romanos la monitorización de puertos era crucial, y para nosotros ahora también. ¿Cómo? Se preguntarán ustedes. ¡Veamos!

Modelo de trirreme romana
https://commons.wikimedia.org/wiki/File:Trireme_1.jpg

Sí, en la vida real cada puerto marítimo es la entrada a la mayoría de los países del mundo, ya que el marítimo es decenas de veces más barato que el transporte terrestre… aunque mucho más lento que el transporte aéreo. Los romanos y ahora los Estados modernos saben por experiencia de miles de años que la monitorización de puertos es de suma importancia.

En los ordenadores también existen puertos físicos: es donde conectamos cada teclado, monitor, etc. Así existen infinidad de ellos, tales como puertos seriales (9 ó 25 pines o agujas conectoras), USB, para vídeo, como HDMI o el viejo VGA. En este artículo iremos un paso más allá: los puertos virtuales, una abstracción (o mejor dicho, 65.535 abstracciones, ese es el número de puertos abarcados en 16 bits) que hacen los sistemas operativos en la capa de aplicaciones, para entregar a cada programa sus datos o información necesarios. Pero será luego que retomemos este punto.

Así entonces las cosas, en el mundo de la informática la monitorización de puertos tampoco es cualquier cuestión baladí:

• Empresas como @StatusCakeTeam (Twitter) realizan diariamente más de 380 millones de comprobaciones de sitios web, por supuesto contactando con los puertos respectivos de cada protocolo (HTTP/HTTPS, TCP, SSH, DNS, SMTP, PING, PUSH).
• En países como Reino Unido, Alemania y Finlandia se toman muy en serio la exploración de puertos, al punto de que hay leyes al respecto. Obviamente esto no se aplica a la monitorización, incluso si es realizada por terceros que hemos contratado para esa tarea, ya que son labores consensuadas.

Como la monitorización de la seguridad está entre los retos inmediatos de Pandora FMS (PFMS), doy aquí un panorama general de la monitorización de puertos, teniendo eso presente.

Dispositivos y monitorización de puertos

Pandora FMS es un software para monitorizar las redes informáticas y su infraestructura. Puede monitorizar el rendimiento y estado de los equipos de red, infraestructura virtual, sistemas operativos y diferentes tipos de aplicaciones y sistemas sensibles a la seguridad, como bases de datos, cortafuegos y servidores web.

Pandora FMS tiene un capítulo totalmente dedicado a las tareas de descubrimiento (Discovery) e incluye una herramienta de exploración de red llamada NetScan.

En resumen, esto ofrece la funcionalidad de poder llevar cuenta de un inventario de dispositivos y servicios ofrecidos por cada uno de ellos (concentradores, aplicaciones, módem, etc.) Allí está todo bien explicado a profundidad sobre cómo funciona la exploración de red; sin embargo, aquí formulo la pregunta retórica sobre cómo puede esa herramienta determinar qué dispositivos están conectados o no.

Para ello debemos repasar un poco de teoría, poca, pero la necesaria. No pretendemos superar a un licenciado en computación y/o a algún académico titulado, simplemente debemos ser prácticos.

En las décadas de 1970 y 1980 se unificaron criterios para la creación del Modelo de referencia para interconexión de sistemas abiertos (Open Systems Interconnection o, simplemente, Modelo OSI). Como fue derivado de un modelo propuesto por la Organización Internacional de Normas (International Standards Organization o ISO, fundada en 1946 por más de 70 países) también se le denomina Modelo ISO/OSI.

En dicho modelo se describen siete (mi número favorito) de las capas que fundamentan los conceptos necesarios para una red ideal, amplia y abierta:

• Capa física.
• Capa de enlace de datos.
• Capa de red.
• Capa de transporte.
• Capa de sesión.
• Capa de presentación.
• Capa de aplicación.

OSI model
https://commons.wikimedia.org/wiki/File:Osi-model-jb.svg

Yo como programador siempre me ubico en la séptima capa y me puedo olvidar de manera cómoda de las capas inferiores, aunque debido a mi experiencia de muchos años esto no siempre fue así. Para la monitorización de puertos debemos «bajar» hasta la capa número 4, la capa de transporte, donde se ubican dos protocolos asociados a los puertos. Este par son el Protocolo de Control de Transporte (Transport Control Protocol o TCP) y el Protocolo de Datagrama (paquete de datos o mensaje de red) de Usuario (User Datagram Protocol o UDP).

Para probar la conectividad de nuevo bajaremos, esta vez un solo escalón, a la capa de red donde están el Protocolo de Internet (Internet Protocol o IP) y su par de aliados, el ICMP e IGMP. No sigo detallando nombre por nombre para evitaros aburrimiento; a todo esto se le llama conjunto de protocolos TCP/IP o llanamente TCP/IP.

Es en esta tercera capa donde podremos hacer uso del famoso ping, en mi opinión la piedra angular de la monitorización. Allí no vale puerto alguno y es excelente para determinar si algún dispositivo está conectado a una red. En muy contadas ocasiones los administradores de red lo desactivan o simplemente suprimen que responda petición alguna, así que yo lo doy por hecho cierto y ubicuo.

Nmap

Nmap (imagino que abreviatura en inglés de Network Mapper o Mapeador de red) fue creado y publicado por Gordon Lyon en 1997. Pronto fue modificado, portado y mejorado, llegando hasta nuestros días como programa campeón, no solo para solventar «problemas» como la desactivación del ping que comenté, sino también para explorar redes completas en rangos de puertos, haciendo gala de toda la especificación de opciones de TCP/IP, algo movida, por cierto.

Pandora FMS utiliza por ejemplo Nmap para comprobar la comunicación y servicios por línea de comandos en la Configuración de Consola; Nmap también tiene una interfaz gráfica llamada nmapfe. Existen cantidad de programas que también usan Nmap

Zenmap utilizando Nmap 4.5
https://commons.wikimedia.org/wiki/File:Zenmap_2.png

Ping, Nmap, Curl y muchas otras herramientas de red fueron confirmadas por el equipo de Pandora FMS como imprescindibles. En dicho artículo ofrecemos un breve resumen de cada una de ellas, si queréis explorar un poquito más -de manera técnica- en la monitorización de puertos.

Monitorización remota

Como su nombre indica, haremos comprobaciones de manera externa con un componente de Pandora FMS llamado Servidor de Red (Network Server). Aunque tiene encomendados muchos trabajos y tareas, la monitorización de puertos está dentro de la Monitorización TCP, uno de sus tres bloques básicos de labores.

Si quieres ver cómo crear un módulo TCP en Pandora FMS puedes echar un vistazo a este vídeo:

El primer trabajo es determinar si un puerto en un anfitrión remoto está abierto, y en base a ello emitir órdenes y/o alertas. Recordad que os comenté acerca de ping, y para ello existe la Monitorización ICMP (aunque no viene a cuento, os adelanto que el tercer bloque es lo que engloba la Monitorización SNMP en el Servidor de Red PFMS).

Y como dicen en los «infomerciales», ¡esperen, aún hay más!: en una suerte de remedo al Gato de Schrödinger, para estar totalmente seguros de que el puerto está abierto o no, Pandora FMS permite además recibir una respuesta específica por el puerto solicitado («OK», «200» o alguna otra respuesta estándar de alguna aplicación común). Incluso pueden ser varios los envíos y sus respectivas respuestas hasta lograr dar con la condición o estado que busca ser monitorizado.

Recordad siempre la seguridad: debido a la naturaleza de estos protocolos dichas comunicaciones no están cifradas.

Versión Enterprise: «Satellite Server»

Pandora FMS, en su edición empresarial, es utilizada por muchos líderes de la industria; por ejemplo la Empresa Municipal de Transportes de Madrid (EMT), el Ministerio de Telecomunicaciones y de la Sociedad de la Información de la República del Ecuador y el Governo Povo do Acre, estado de Brasil con 22 municipios y 700 mil habitantes.

Como ya os dije, la monitorización remota es ejecutada por el Servidor de Red PFMS, el cual presenta características particulares. El Satellite Server, a su vez, hace uso del lenguaje Perl y necesita (además de fping y Nmap, instalados aparte) a wmic y braa (incluidos al descargar el fichero binario) para poder equiparar en funciones al Servidor de Red PFMS.

Teniendo todo esto presente, y sin entrar a profundidad, podremos hacer la monitorización de puertos en redes donde, por razones de seguridad y/o brechas tecnológicas, no podamos acceder de manera directa por medio de nuestro Servidor PFMS (a los dispositivos a los que les realizaremos la monitorización de puertos).

Sí, ya se estarán preguntando cómo el Satellite Server es capaz de guardar en la base de datos las métricas recogidas: dicho servidor debe tener salida a Internet y desde allí al Servidor PFMS por medio de su propio protocolo denominado Tentacle.

Es utilizado para ello el puerto número 41121 (asignado oficialmente por la IANA) y este es el único número de puerto que, a mi juicio, no vale la pena monitorizar: nos daremos cuenta muy rápidamente por la Consola PFMS si hemos dejado de recibir conexiones de nuestros Satellite Servers.

¿Qué motiva que los dispositivos a monitorizar estén «aislados» o no estén al alcance del Servidor de Red PFMS? Revisemos.

Cortafuegos y detectores de intrusos

Muro de fuego, red de redes (Seth Kenlon, CC BY-SA 4.0)

Ya por último toco el temido tema de los cortafuegos. Así como nos protegen, también nos hacen la vida imposible cuando están correctamente configurados. ¿A qué me refiero?

Un cortafuegos (basado en software o en hardware) puede tener infinitas configuraciones, pero el modelo que más me gusta es el que bloquea todo lo que entra desde Internet excepto lo expresamente permitido. Y es allí donde comienza nuestro gran trabajo, agregar lo que necesitemos como los famosos puertos 80 y 443 para el tráfico web, los más comunes para los servidores web (pero siempre debemos tener en cuenta los distintos tipos de servidores que existen).

Pero la cosa va más allá, el cortafuegos también debe cerciorarse de que los paquetes que entran corresponden a una salida desde nuestra red local; vamos, que fue que lo solicitamos nosotros (¿recuerdan el Satellite Server PFMS?). Menudo trabajo.

Visto así, las tareas de los cortafuegos son exigentes y debido a eso se han diseñado y creado artefactos expresamente para ello; son basados en hardware y PFMS tiene varios complementos para monitorizarlos, generalmente por SNMP.

Yo agrego, además, que un cortafuegos debe tener una lista de direcciones IP permitidas para ser redireccionadas a servidores específicos, como es nuestro caso si estamos con la labor de monitorización de puertos (desde fuera de la empresa). Si la solicitud es recibida de cualquier otra dirección IP a un puerto que está fuera de la lista de permitidos, la enviaremos a nuestro servidor «pote de miel» (honeypot), tecnología acorde para la tarea de visitantes desconocidos y no deseados. Para mantener actualizada la lista de direcciones IP permitidas deberemos tener un tercer servidor en Internet que acredite nuestra identidad ante el cortafuegos.

Ahora bien, esto último está enfocado a las peticiones TCP, que son orientadas a la conexión (volvemos a la teoría) pero las peticiones UDP no trabajan de esa manera. Allí es que podremos tener una falsificación de direcciones IP para que seamos victimarios forzados de otro servidor web ajeno a nosotros. Afortunadamente el kernel de Linux retrasa a propósito dichas peticiones a un límite de un mil por segundo, así que atacar más de 60 mil puertos les va a llevar algo de tiempo. Eso nos lleva a lo siguiente, a los detectores de intrusos.

Esta tecnología, aunque lleva tiempo entre nosotros, poco he visto su uso. Que no quito que la podamos integrar en nuestros honeypots, pero recomiendo que trabajen aparte; si es una solución basada en hardware, pues mejor. La idea es llevar cuenta de los paquetes que se mueven en la red de área local: allí Pandora FMS puede efectuar una monitorización de puertos de manera pasiva.

• También podremos usar la técnica de las embarcaciones marítimas: compartimientos estancos (pero igual no os confiéis, recordad que el famoso barco Titanic nunca llegó a Nueva York, a pesar de contar con esta novedosa tecnología para la época). Es decir, después del muro de fuego principal, crear subredes aisladas con cortafuegos adicionales, repitiendo las recomendaciones anteriores.
• Cada servidor de trabajo a ser monitorizado debe tener también su cortafuegos local, ejecutado por el sistema operativo (y a riesgo de ser fastidioso «repitiendo las recomendaciones anteriores»). ¿Qué tiene que ver esto con la monitorización de puertos? Que si ya tenemos en inventario una máquina que lleva una base de datos MySQL (normalmente el puerto 3306) y verificamos que está abierto y operativo, comprobamos adicionalmente que no haya ningún otro abierto. Así son las tareas de monitorización, redundantes en sumo grado. Dichos cortafuegos locales tienen una característica adicional: el permitir solo a programas específicos el abrir y usar sus puertos por defecto (mirad también la monitorización de logs para estar al tanto de los cambios).
• Algunos administradores de red utilizan técnicas de ofuscación, como cambiar los puertos predefinidos (yo he visto servidores web usando el puerto 28081 en ventanas emergentes, que aunque a esta fecha no está asignado a nadie por la IANA, pero deberían utilizar los puertos por encima de 49152, los puertos dinámicos personalizados). Esto solamente refuerza mi afirmación: la monitorización es una ciencia… y un arte.
• En el caso de orquestadores de máquinas virtuales (Docker con Kubernetes, el caso más famoso) la monitorización de puertos recaerá en la monitorización virtual, ya que será más efectivo utilizar las instrucciones API, ¡esto sin perjuicio de todo lo explicado!

Antes de despedirnos, recuerda que Pandora FMS es un software de monitorización flexible, capaz de monitorizar dispositivos, infraestructuras, aplicaciones, servicios y procesos de negocio.

¿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 una DEMO GRATUITA de 30 días de Pandora FMS Enterprise. Consíguela 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í.