Bueno, aquí seguimos com el tema del Virtual Patching. Antes de seguir los dejo los enlaces de las 3 entradas anteriores para estar al tanto del tema que nos concierne.
Siguiendo con la última entrada, si no contásemos con el dispositivo Fortigate, un atacante podría haber localizado nuestra vulnerabilidad y lanzar un “exploit” para poder aprovecharse de ella. Esto puede llevarse a cabo con el framework “Metaesploit” destinado a ese fin y con la ayuda de la GUI “Armitage” para un entorno más amigable.
Arrancaríamos la aplicación “Armitage” desde nuestra distribución Kali y seguiríamos los siguientes pasos:
Dar de alta al equipo con su dirección IP que ya la conoceríamos de los pasos anteriores:
Se realiza un escaneo para detectar puertos abiertos y posterior detección del Sistema Operativo:
Ahora se trata de localizar posibles ataques en función de los resultados obtenidos con anterioridad.
A partir de ahí se localiza la vulnerabilidad descubierta con el escáner “Nessus”.
La ejecutamos y comprometemos el objetivo.
Y una vez hecho esto, ya tendríamos nuestro equipo bajo control. Como vemos en la figura siguiente el icono del XP ha cambiado tornándose de color rojo y unos rayos.
Con el equipo comprometido, podríamos hacernos con el control del Windows XP mediante un visor VNC aún sin tenerlo instalado. El exploit genera un proceso en nuestro equipo Kali, al cual nos conectamos ejecutando el comando:
#vncviewer 127.0.0.1:[identificador]
Esto resulta especialmente grave ya que la tener acceso a la interfaz gráfica podríamos realizar alguna serie de cambios y modificaciones sobre las aplicaciones que estarían corriendo en esos instantes.
También, si lo deseásemos, podríamos hacernos con una consola remota tal y como aparece en la parte inferior y otras muchas acciones:
Sin embargo, si configurásemos el motor IDS/IPS para que bloquee en lugar de monitorizar. Esto es:
Y lanzamos de nuevo el ataque veríamos que éste no tiene éxito:
Y los logs generados indicarían el bloqueo:
Así pues queda claro la importancia de no sólo parchear nuestros equipos, sino además en el supuesto de que por distintas razones no podríamos llevarlo a cabo, la obligación de tener que tomar las medidas necesarias.
En entornos industriales podemos ver el esta situación de una forma más habitual que en entornos IT tradicionales ya que por un lado los ciclos de vida de los PCs industriales son mayores y por otro, dada la criticidad de las instalaciones gobernadas por éstos muchas veces no sea aconsejable instalar algún tipo de software tipo “Endpoint” que los bastione con funcionalidades Host IPS, Antivirus y Firewall.
Espero que el ejemplo haya sido de utilidad para tomar conciencia de esta situación y de las medidas que debemos tomar para securizar nuestros equipos.
Así pues nos vemos en la siguiente entrada, no sin antes invitaros a dejar vuestros comentarios. Desde ya muchas gracias.
Siguiendo con el tema de Virtual Patching ahora toca ver cómo funciona y los beneficios que puede aportarnos.
Para ello he creado un entorno con dos PCs interconectados por medio de un Fortinet Fortigate Rugged 60D configurándolo con motores Antivirus, IDS/IPS y Control de Aplicación. La parte de firewall la he dejado con un “permit any any any” (IP origen, destino y puerto, respectivamente) Hay que recordar que cada una de ellos lo podemos configurar en dos modos, “Monitor” o “Block”. Con el primero, en caso de que se detecte algún patrón que puda quedar recogido dentro de las reglas y firmas, no se tomará ninguna acción, sólo se registrará el evento y se dejará pasar. En cambio con “Block”, valga la redundancia se bloqueará y la amenaza será paralizada.
Luego, estas características han de aplicarse, o no, a las reglas de Firewall en él configuradas.
En cada uno de estos PCs he virtualizado un total de 3 máquinas.
Una con Kali Linux desde la cual simularemos la actividad de un atacante. Lanzaremos un escaneo de puertos con Nmap, escáner de vulnerabilidades con Nessus, intento de intrusión con Metaesploit y Armitage y por último copiar en un recurso de red el fichero EICAR.
Otra con un Windows XP vulnerable, el objetivo. Se ha elegido este ya que posee vulnerabilidades que para un ejemplo pueden ser fácilmente explotables. Aparte porque su uso en entornos industriales y o vida prolongada es aún bastante común.
Por último un Fortinet FotiManager con funciones FortiAnalyzer desde donde gestionaremos el equipo Fortigate Rugged 60D. Lo he querido utilizar ya que con un despliegue de varios equipos resulta aconsejable no sólo por la gestión centralizada sino porque nos permite almacenar los logs, analizar tráfico, sacar informes, ver registros, etc.
Todo queda resumido de la siguiente manera:
En la imagen siguiente se muestra cómo el equipo Fortigate bloquea un total de 9965 amenazas catalogadas en un total de 1993 incidentes, provenientes de la IP XX.XX.XX.15 de la máquina Kali Linux. Esto es debido a que la aplicación Nmap envía sucesivamente paquetes para que en función de las respuestas obtenidas se pueda determinar si un equipo está activo, o no, puertos abiertos; versiones de aplicaciones, servicios; etc.
Para conocer un poco más recomiendo la siguiente lectura, pincha aquí.
En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.
En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:
Como se puede apreciar éstas han sido bloqueadas no pudiéndose obtener datos sobre el equipo objetivo, el XP. Esto mitigaría la etapa inicial de recolección de información que un atacante llevaría a cabo y poder, a partir de ahí, realizar otro tipo de acciones sobre nuestros sistemas.
Obviamente habría que configurar las reglas del firewall del modo más restrictivo posible y sobre el tráfico que dejamos pasar aplicar el análisis de los motores Antivirus, IPS y Control de Aplicación. Sin embargo para este ejemplo se ha querido dejar así para ver el comportamiento de la aplicación Nmap y qué es lo que sucede si no empleamos un cortafuego. Pero como como digo, siempre, siempre, siempre, ha de restringirse el tráfico sólo al estrictamente permitido por medio de estos firewalls.
Esto es todo por hoy, pero os debo las siguientes entradas sobre escáner de Vulnerabilidades, Metaesploit y EICAR Test File.
No s vemos en la próxima, y como siempre digo, se agradece cualquier comentario al respecto.
A estas alturas todos tenemos claro que una de las medidas a aplicar dentro de nuestras políticas de seguridad es tener actualizados los sistemas y equipos de red. Esto lo podemos conseguir instalando parches para sistemas operativos, actualización de aplicaciones y versiones de firmware. Esto creo, que a nadie nos pilla por sorpresa.
Quizás uno de los puntos más críticos de las opciones planteadas es aplicar los últimos parches emitidos por el fabricante o los desarrolladores. La instalación de los mismos no debería provocar que nada dejase de funcionar, sin embargo este riesgo no es cero y puede suceder.
En entornos industriales, se emplean PCs para la interacción, configuración y gobierno de la maquinaria, robots y demás sistemas de control y automatización. Como he hablado en otras ocasiones aquí la premisa es la disponibilidad de las instalaciones, y por tanto, las posibles causas que puedan provocar una interrupción del servicio deben quedar reducidas al máximo. Para ello es necesario, o al menos conveniente, tener un entorno de laboratorio para el testeo de parches, ver su comportamiento y una vez comprobada la ausencia de anomalías, proceder a su despliegue siempre de forma progresiva.
Así pues se nos plantean 3 posibles casuísticas:
Hasta ahora hemos contemplado que el parcheo se puede llevar a cabo, sin embargo esto no siempre es así. Imaginemos que adquirimos un equipamiento a un proveedor. Éste garantizará su funcionamiento en esas condiciones, no en cambio, si sobre ella se realiza algún tipo de instalación de parches o software adicional. Seguramente será posible la contratación de un soporte de mantenimiento pero a cambio, posiblemente, de una muy considerable cantidad económica. Así pues el escenario, muy probablemente, será no parchear. Con lo que ello conlleva, claro.
Como segundo caso, debemos recordar que una de las características de los equipos industriales es su ciclo de vida prolongado. Éste es muy superior a los dispositivos IT convencionales, sin embargo no dejan de pertenecer a este ámbito por muy PCs industriales que sean. Llevan en sus entrañas Windows 2000, XP, 7, etc. Eso por no citar a NT que aún los sigo viendo. Estas versiones hasta XP, están fuera de soporte, aunque su uso sigue y seguirá vigente por varios años más. Y en estos casos, ¿cómo parcheamos si no tenemos soporte?
Finalmente podría darse que bien por su criticidad o por su delicadeza, no nos atrevamos a “meter mano” a este equipo que lleva sin tocarse 3, 4, 5 o más años. No nos podemos arriesgar a que surja algún inconveniente y no sepamos resolverlo. Y claro, ¿qué hacemos entonces? ¿Asumimos los riesgos? ¿O no?
En cualquier caso, la no actualización de nuestros equipos conlleva un riesgo. Quedan expuestos a una mayor probabilidad que un ataque, intrusión o actividad de malware, tenga éxito. Los entornos industriales, hasta hace relativamente poco, eran redes que permanecían aisladas del resto y su acceso era muy limitado. Con la integración en redes Ethernet, funcionalidades basadas en TCP/IP y la aparición del IIoT, esta exposición está siendo mayor y por tanto a los riesgos han aumentado.
Claro y ¿qué hacer entonces? Buena pregunta.
Pues bien, una de las opciones viene de la mano del Parcheo Virtual o Virtual Patching.
¿Qué esto de Virtual Patching? Podríamos definirlo como la política de seguridad destinada a prevenir la explotación de una vulnerabilidad mediante el análisis del tráfico, sometiéndolo a distintas capas de seguridad con el fin de evitar que código malicioso alcance la aplicación o sistema vulnerable. Esto es, el “ataque” se bloquea antes de que llegue al objetivo. Dichas capas vienen dadas por motores Cortafuegos, Antivirus, IDS/IPS, Control de Aplicaciones y Filtrado de Tráfico Web.
Como viene siendo habitual no voy a referirme a los entornos IT, sino a los industriales. Ya en la entrada anterior “Convertidores de medios” hablaba de la necesidad de utilizar dispositivos diseñados y pensados para ese fin, y la de hoy no es para menos.
Un ejemplo lo encontramos en el Fortinet Fortigate Rugged 60D, cuyas especificaciones las podéis encontrar aqui. Y su Quick Start Guide aqui.
Este equipo es lo que podemos denominar UTM (Unified Threat Management) pero orientado a entornos industriales.
Como podemos ver, ya con su aspecto, las diferencias con los dispositivos tradicionales IT son bastante evidentes, el diseño ruguerizado lo delata. Otra de ellas es la implementación de protocolos industriales como Modbus, Profinet, OPC, DNP3, etc. Luego sobre ellos podemos aplicar las firmas de Control de Aplicación e IPS.
Por otra parte tendremos la posibilidad de instalación sobre carriles DIN, un modo de instalación de equipos industriales en armarios destinados a tal fin. Igual modo la alimentación eléctrica, por medio de borneros pudiendo emplear además la fuente de alimentación convencional que trae consigo.
En adición a lo anterior, podremos ver que la temperatura operacional va de -20 a 70 º C. ¿os imagináis las temperaturas más bajas y altas en un entorno IT convencional? Ufff qué frío y que calor…
Para su configuración inicial, nos descargaremos el software Fortiexplorer. Luego con el cable USB que viene de serie, conectaremos nuestro PC con el dispositivo.
Allí podremos acceder al Dashboard donde asignaremos algunos parámetros básicos y visualización de cierta información.
Luego dentro del apartado “Config -> Features”, definiremos aquellas características que queramos activar.
A destacar su modo de funcionamiento denominado “Transparente”. Es modo convierte al dispostivo como un Firewall pero a nivel de Capa 2. No es necesario realizar ningún cambio en el direccionamiento IP del equipo a proteger. Sólo bastaría asignar una IP de gestión del mismo rango que éste.
En “Security Profiles” definiremos los perfiles de configuración para los motores Antivirus, Filtrado Web, Control de Aplicación e IPS, en base a firmas y reglas.
En cada uno de ellos podremos definir si en caso de detectar comportamientos coincidentes con cada motor, entre “Block” y “Monitor”. Esto es, tomar una medida y bloquearla; o bien dejarla pasar, monitorizarla, registrando el evento como un log. Para ello deberemos indicar el servidor dónde enviar los datos. Fortinet tiene las herramientas propietarias FotiManager para una administración centralizada de dispositivos y FortiAnalyzer, para el análisis del tráfico y logs.
El dispositivo tiene otras muchos parámetros y funcionalidades a las que podríamos dedicar horas y horas. No obstante en el futuro, espero poder subir alguna más. Todo depende del tiempo disponible.
Por ahora ya hemos terminado con esta, y como siempre, os pido que dejéis vuestra opinión a modo de comentario de lo que os ha parecido, tanto si os ha resultado, o no, interesante, o cualquier otro crítica constructiva.
Lo dicho, muchas gracias, nos vemos en la siguiente!!
