“DoS Policy” más allá del filtrado tradicional

Como hemos comentado en otras ocasiones la separación y segmentación de los entornos IT y OT es la primera medida técnica que debemos tomar. Es necesario definir los perímetros y qué comunicaciones deben permitirse entre uno y otro lado. Para conseguirlo, empleamos Cortafuegos aunque con características adicionales que han dado lugar a los conocidos NGFW. Sin embargo, también podemos contar con otras adicionales, en este caso, para evitar denegaciones de servicio, DoS.

La primera acción que debemos hacer es identificar el tráfico. Definir qué comunicaciones existen en nuestro entorno de control y automatización. Luego, permitirlas en función del criterio que más se ajuste ya sea por IPs, interfaces, servicios, subredes, aplicaciones, protocolos o cualquier otro. Sin embargo, una vez hecho esto y teniendo que claro “qué si y qué no”, también es importante identificar posibles anomalías dentro del mismo pudiendo afectar al funcionamiento del, o los equipos, destino.

Una de las acciones con las que podríamos afectar a las comunicaciones de este ámbito es introduciendo tráfico adicional. Sea este Broadcast, Multicast o Unicast los efectos podrán ser unos u otros ya que dependerá si la electrónica de red lo replica por todos los puertos o sólo por aquél que está dirigido al destinatario.

Si nos referimos a los equipos de control, sabemos que éstos tienen un ciclo de vida mayor con lo que es muy común encontrarnos con equipos antiguos con una capacidad para gestionar comunicaciones mucho más limitada que los equipos actuales. Ante un exceso de tráfico, aunque esté dirigido a un puerto de destino permitido, éstos podrían dejar de responder perdiendo así visibilidad y control.

Hay que tener presente que una denegación de servicio puede no venir exclusivamente de medidas claramente intencionadas. También puede hacerse por un error o mala parametrización de sistemas. Un caso lo podríamos encontrar en los escáneres de vulnerabilidades. Si no los configuramos correctamente y no los ejecutamos acorde a los equipos finales podríamos llegar a comprobar vulnerabilidades de sistemas operativos Windows, Linux, etc. sobre autómatas o controladores que, lógicamente, no los empleen o podrían no hacerlo. Aparte de que los resultados no tendrían sentido, podría desembocar en posibles bloqueos en módulos de comunicaciones, tiempos de respuesta tardíos, entre otros.

Para emular una situación de esta índole he elaborado una Prueba de Concepto empleando el simulador Snap7 y equipos virtuales. No obstante, la prueba fue realizada sobre dos autómatas Siemens S7-400 y S7-300 y los resultados fueron la pérdida de visibilidad desde el servidor que los gestionaba. Los equipos no eran capaces de manipular tanto tráfico. Por supuesto, en un entorno de laboratorio.

La misma sigue el siguiente esquema:

Desde un equipo con una distribución Kali Linux realizamos una inundación de tráfico por medio de la herramienta hping3, efectuando peticiones TCP SYN contra el puerto TCP 102, que es el empleado por el fabricante Siemens. Dicho equipo tendrá una IP 192.168.100.20, mientras que el PLC virtualizado 192.168.20.10.

root@kali:~# hping3 –flood -p 102 -S 192.168.20.10

Antes de realizar dicha operación podremos comprobar que el consumo de CPU como de memoria es bajo dada la ausencia de sesiones.

Sin embargo, una vez comenzado el envío de paquetes el consumo de recursos va en aumento:

Si en ese momento decidiésemos conectarnos a dicho PLC simulando un servidor, HMI, etc. veríamos que no sería posible y cómo la propia herramienta muestra un mensaje en la parte inferior de la captura “ISO: An error occurred during…”

En este sentido fabricantes como Fortinet introducen una funcionalidad denominada “IPv4 DoS Policy” que nos va a permitir atajar que, algo o alguien, de una manera intencionada, o no, pueda generar un exceso de tráfico que desemboque en una pérdida de visibilidad o control sobre equipos finales.

En la imagen siguiente podemos ver los distintos parámetros que podemos definir y parametrizar según sea nuestra necesidad.

 

Deberemos indicar la interfaz de entrada por dónde esperaremos el tráfico en cuestión, ya sea física o lógica; direcciones IP de origen y destino y servicios. A continuación, hemos de identificar las características a nivel de capa 3 y/o 4 que queremos habilitar y los respectivos umbrales de cada uno de ellos. Este es un trabajo que hemos realizar con cautela ya que nos obliga a tener una estimación acerca de los valores tolerables y qué se escapa de un normal comportamiento. No tenemos porqué habilitar todas las opciones, sino aquellas que consideremos que nos pueden ser de utilidad o tengan sentido dependiendo de la ubicación y exposición del cortafuegos. Finalmente, una de las opciones que sí resulta conveniente habilitar es la opción de registro ya que nos va a permitir disponer de información al respecto, como se puede ver en la imagen siguiente.

Cuando hablamos de cortafuegos, generalmente nos viene a la mente la opción de permitir o denegar tráfico y sobre él aplicarle controles adicionales como Antivirus, IDS/IPS, entre otros. Es cierto, ese su principal cometido. Sin embargo, podemos encontrar funcionalidades que, sin penalizar el rendimiento, pueda ayudar a identificar anomalías de aquél que estamos dejando pasar.

La primera tarea es decidir qué debemos autorizar y qué no. Esto nos va obligar a conocer qué comunicaciones establecen nuestros equipos de control y sistemas asociados. A menudo partiremos de un desconocimiento total ya que nos enfrentaremos a entornos conmutados o enrutados donde no se ha documentado dicha información y obviamente no existen elementos de seguridad perimetral. Si queremos filtrarlas deberemos identificarlas, y entender el por qué deben producirse, o no. No todo lo que veamos debe ser permitido. Probablemente ni tan siquiera los propios usuarios de las instalaciones lo sepan. Es una labor que puede complicarse según sean los escenarios, pero que en cualquier caso, ha de realizarse.

Un buen recurso pueden ser los “Puerto Espejo” o dispositivos como el Siemens TAP  104, que nos ayudarán a replicar tráfico de red y que pueda ser colectado y analizado a posteriori.

Hasta aquí la entrada de hoy.

¡Un saludo nos vemos en la próxima!

¿Por qué es necesario NGFW en entornos ICS/SCADA?

Como he hablado en otras ocasiones el primer paso para securizar un entorno de control y automatización es separarlo del de IT mediante un dispositivo de seguridad perimetral. Luego, ya dentro del propio entorno OT, es necesario segmentar la misma en áreas más pequeñas con el fin de que si se produce un anomalía o incidente, éste no se propague al resto y ponga en peligro la disponibilidad total, o parcial, de las instalaciones.

separacion_01

El dispositivo estrella para este tipo de tareas es el firewall. Los cortafuegos tradicionales (L2, L3, L4) han quedado ineficaces ante el creciente y diversificado aumento de amenazas, vulnerabilidades y vectores de ataque. Surgen entonces los NGFW (Next Generation Firewall) que además de las características típicas incorporan otras como motores Antivirus, IDS/IPS, Control de Aplicación, Filtrado Web y DPI (Deep Packet Inspection).

A continuación, indico algunos enlaces de artículos relacionados a este respecto.

  1. Defensa en Profundidad, breve repaso.
  2. Defensa en profundidad OT
  3. Separar y Segmentar, primeros pasos para reducir riesgos…
  4. Virtual Patching en funcionamiento (Parte I)
  5. Virtual Patching en funcionamiento (Parte II)
  6. Virtual Patching en funcionamiento (Parte III)

En la entrada de hoy vamos a ver la necesidad de este tipo de dispositivos NGFW en detrimento de los tradicionales. Para ello me voy a basar en el software utilizado en la entrada “Simulador de protocolo ModBus”, creado el siguiente entorno.

arquitectura

La idea es representar dos supuestos entornos; uno IT (de Oficinas) y uno OT (de automatización). En este último he simulado un equipo cliente ModBus el cual será el “objetivo” de las acciones a realizar. Por otro lado, en parte de IT/OT, situaré el posible “atacante” (Kali Linux) junto con un equipo legítimo (Maestro Modbus). He decidido especificar IT/OT para cubrir dos supuestos. Cuando me refiero a “IT”, represento el concepto de “Separación” y con “OT” el de “Segmentación”. De esta manera cubrimos las posibles acciones llevadas a cabo desde la propia red de Control como desde otra ajena a éstas como puede ser la de “Oficinas” o Internet si consideramos equipos accesibles remotamente. En cualquiera de los casos, ambos están separados por un equipo Fortinet FortiWifi60D con una versión de FortiOS 5.2.8. Habrá que piense que esta versión ya tiene un tiempo y que las hay más nuevas. Tiene razón, pero hay una explicación. Las actualizaciones en equipos industriales, se producen en intervalos de tiempo superiores si lo comparamos contra entornos IT con lo que es muy común encontrarse no con las últimas. Además de esto, no debemos olvidar el uso de equipamiento acorde a la actividad que vamos a realizar. Lo correcto sería emplear, por ejemplo uno de la serie Fortinet Fortigate Rugged.

Así pues, el esclavo queda configurado como sigue:

esclavo_01

Por otro lado, el firewall permite el tráfico según la siguiente regla.

config_forti_01

Como se puede apreciar sólo se deja pasar el protocolo “ModBus” (TCP-502), entre la red 172.30.123.0/24 y el destino “Esclavo_MODBUS” (172.20.123.200). Lo suyo sería dejar pasar sólo aquellos equipos que lo necesiten. Aparte de ser un entorno de laboratorio, en la vida real, es probable que alguien se pueda configurar manualmente la IP de un equipo legítimo, la infección de uno de ellos o las conexiones vengan de redes configuradas con DHCP con lo que se abra a todo su rango. No es descabellado. Lo dicho, cobra especial importancia la correcta configuración de las reglas del firewall.

Según lo anterior el resultado de una conexión legítima al esclavo sería la siguiente:log_forti_01Y el Master recogería estos resultados:

master_01

Considerando las características de ModBus que no posee ninguna medida de seguridad nativa, un atacante podría con alguna herramienta poder leer o escribir datos. Para este caso he utilizado mbtget, la cual podéis encontrar aquí.

Así pues leeremos los siguientes registros:

kali_01O escribir, por ejemplo, “12345” en la primera entrada.

kali_02

Y… oh sorpresa! el usuario legítimo lo vería….

master_02

Con ello vemos que los Firewall tradicionales no son del todo efectivos para este tipo de entornos y protocolos. Vamos a proceder a configurar el “Perfil de Seguridad”, término que emplea Fortinet para definir las características de seguridad adicionales y que son definidos en cada una de las reglas. Estos perfiles pueden ser ajustados según necesidades. En el siguiente ejemplo optamos por activar en “Modo Monitor” de la característica “IPS” con lo que operaría como un IDS (Intrusion Detection System) en lugar de un IPS (Intrusion Prevention System) :

config_forti_02

Aún podríamos llevar a cabo una escritura con el valor “55555” en el esclavo desde el equipo atacante, ya que sólo detectaríamos tal acción:

kali_03

Generaríamos el siguiente log en el Firewall.

kali_07

Y también, hacer una lectura:

kali_04

Como vemos en los logs del Firewall, en la columna “Action” vemos como figura “detected”. El tráfico se ha detectado pero no se ha cortado.

log_forti_04

Sin embargo, si cambiamos el perfil IPS y esta vez lo reconfiguramos como “Block”

ips_02

config_forti_03

El atacante se encontrará que no podrá llevar a cabo la escritura. Por ejemplo modificando el primer campo con el valor “8888”. Se produce un “timeout”.

kali_05

Y el correspondiente log en el Firewall:

log_forti_05

Aquí ya vemos cómo en la columna “Action” ya consta como “Dropped”.

Idem con la lectura:

kali_06

log_forti_06

Mientras tanto el cliente legítimo sigue funcionando con total normalidad.

master_03

En el día de hoy hemos comprobado la funcionalidad IDS/IPS para este equipo del fabricante Fortinet, sin embargo, no es la única que debemos aplicar. Hay que apoyarse en otras como Antivirus, Control de Aplicación y filtrado Web. Esto debe mantenerse bajo cualquier circunstancia, también cuando estos firewalls se empleen para establecer VPN y acceder a éstos de forma remota.

Adicionalmente, conviene que los logs generados, se consoliden en un servidor para poder ser almacenados y analizados bien para llevar a cabo una monitorización del estado de la seguridad por medio de un SIEM, como para realizar labores de forénsica en caso de ser necesario. Fortinet cuenta con algunos productos específicos como FortiAnalyzer o FortiManager, que aunque sea este último una herramienta de gestión incorpora algunas funcionalidades de gestión de logs. Este tipo de soluciones deben de contemplarse desde el inicio de los proyectos. Hemos de tener una visión más allá del despliegue inicial ya que todo lo que instalemos luego hay que administrarlo por lo que a la hora de elegir tal o cual producto, esto también ha de considerarse.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Virtual Patching en funcionamiento (Parte III)

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.

1.- Parches y Virtual Patching

2.- Virtual Patching en funcionamiento (ParteI)

3.- Virtual Patching en funcionamiento (Parte II)

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:

Metaesploit 01

Se realiza un escaneo para detectar puertos abiertos y posterior detección del Sistema Operativo:

Metaesploit 02

Ahora se trata de localizar posibles ataques en función de los resultados obtenidos con anterioridad.

Metaesploit 03

A partir de ahí se localiza la vulnerabilidad descubierta con el escáner “Nessus”.

Metaesploit 04

La ejecutamos y comprometemos el objetivo.

Metaesploit 05

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.

Metaesploit 06

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]

Metaesploit 07

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:

Metaesploit 08

Sin embargo, si configurásemos el motor IDS/IPS para que bloquee en lugar de monitorizar. Esto es:

Metaesploit 09

Y lanzamos de nuevo el ataque veríamos que éste no tiene éxito:

Metaesploit 10

Metaesploit 11

Y los logs generados indicarían el bloqueo:

Metaesploit 12

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.

Un saludo!!

Virtual Patching en funcionamiento (Parte II)

Siguiendo la entrada anterior Virtual Patching en funcionamiento (Parte I) vamos a seguir viendo los efectos del Virtual Patching pero en el caso frente a un escáner de vulnerabilidades.

Lo que vamos a hacer es lanzar uno desde una máquina virtual con Kali Linux hacia un Windows XP vulnerable. ¿Por qué un XP? Porque este sistema operativo está aún muy presente en muchos equipos en entornos industriales y debido al largo ciclo de vida de las estaciones o instalaciones que gobiernan, siguen funcionando a pleno rendimiento. Sin embargo, como sabemos ya no hay soporte y muchos de ellos no están parcheados, lo cual les convierte en un objetivo muy apetecible a malware y usuarios malintencionados. Ni qué hablar de Windows 2000 que también los he visto… Buenos, el esquema era el siguiente:

Esquema 01

Como decía, en el post anterior trataba los resultados tras hacer un escaneo con Nmap. Ahora toca pasar a la siguiente etapa dentro de una supuesta intrusión, o auditoría. Encontrar vulnerabilidades para ser explotadas. Para ello se utiliza un escáner que en nuestro será “Nessus”, pudiendo encontrarse otros como OpenVAS y Nexpose.

Kali Linux no lo trae por defecto, así que lo hemos descargado de la página del producto, obtenido el código correspondiente, instalado y actualizado los plugins. Luego creamos el proyecto y definimos los perfiles que queremos utilizar. En mi caso he dejado sólo los relacionados con plataformas Windows para que sea algo más rápido. No obstante os dejo otro de mis post donde hablaba de la metodología del Pentesting. Lo podéis encontrar aquí.

Nessus 01

Por otro lado la configuración de reglas en el Fortinet Fortigate Rugged 60D quedaría como sigue:

Nessus 02

Como se puede ver se permite todo el tráfico entre las interfaces “Wan1” y “Wan2”, pero se someterá a los motores Antivirus, Control de Aplicación e IDS/IPS. Lo sé, lo sé, habría que restringir el tráfico sólo al imprescindible pero para la prueba lo dejaré así. En la vida real, ni se os ocurra hacer esto. En el caso de este último, el IDS, se ha configurado para que bloquee “Block” todo aquél tráfico que coincida con alguna de las reglas en él definidas.

Tras lanzar el escáner vemos que el resultado es el siguiente. El Fortigate ha bloqueado los paquetes desde el escáner:Nessus 03

Si a continuación hacemos un reporte de las vulnerabilidades encontradas vemos que sólo se han encontrado un total de 8 de nivel informativo.

Nessus 04

Así pues el supuesto atacante apenas podría haber obtenido información del objetivo, con lo que tendría más complicado a la hora de lanzar un exploit concreto cara a aprovechar una vulnerabilidad. Aunque no se aprecie en la imagen, los datos ofrecidos no son relevantes cara a este fin, la intrusión. En cambio, si deshabilitamos dicha protección, esto es:

Nessus 05

Y lanzamos de nuevo el escáner, el resultado sería bien distinto:

Nessus 06

Aquí veremos que sí se obtienen datos sobre el equipo con Windows XP y por tanto sería exitoso el ataque como el que se podría llevar a cabo en el punto siguiente. Entre ellas hay un total de 3 vulnerabilidades “Critical”, 2 “Medium”, y 20 “Info” destacando entre ellas la que figura a continuación.

34477 (1) – MS08-067: Microsoft Windows Server Service Crafted RPC Request Handling Remote 

Code Execution (958644) (uncredentialed check) 

Synopsis

Arbitrary code can be executed on the remote host due to a flaw in the ‘Server’ service.

Description

The remote host is vulnerable to a buffer overrun in the ‘Server’

service that may allow an attacker to execute arbitrary code on the remote host with the ‘System’ privileges.

See Also

http://technet.microsoft.com/en-us/security/bulletin/ms08-067

Solution

Microsoft has released a set of patches for Windows 2000, XP, 2003, Vista and 2008.

Risk Factor

Critical

CVSS Base Score

10.0 (CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C)

CVSS Temporal Score

8.7 (CVSS2#E:H/RL:OF/RC:C)

STIG SeverityI

References 

BID 31874

CVE CVE-2008-4250

XREF OSVDB:49243

XREF MSFT:MS08-067

XREF IAVA:2008-A-0081

XREF CWE:94

Exploitable with

CANVAS (true)Core Impact (true)Metasploit (true)

Plugin Information:

Publication date: 2008/10/23, Modification date: 2015/06/18

Hosts

XX.XX.XX.17 (tcp/445)

Queda bastante claro la funcionalidad de estos motores. A pesar de no restringir el tráfico mediante reglas de firewall tradicionales y dejar pasar todo, algo que obviamente NO DEBE HACERSE BAJO NINGÚN CONCEPTO, nos proporcionan un grado de protección evidente.

En este ejemplo lo hemos hecho sobre un Windows XP vulnerable, pero esto también podríamos emplearlo como elemento de seguridad perimetral sobre Sistemas de Control y Automatización Industrial u otros dispositivos con capacidades limitadas para la implementación de medidas de seguridad. Su protección en este caso radicaría en el Fortigate Rugged 60.

Así hemos terminado por hoy. En la próxima entrada veremos cómo comprometer el Windows XP mediante Metaesploit gracias a la vulnerabilidad anterior.

Como en otras ocasiones os animo a que dejéis vuestro comentario, tanto si es positivo como si no lo es. Todo sirve para mejorar.

Lo dicho, un saludo, nos vemos en la próxima!!

Virtual Patching en funcionamiento (Parte I)

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:

 

Esquema 01

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

Imagen 01

En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.

Imagen 02

En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:

Imagen 03

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.

Muchas gracias!

Parches y Virtual Patching

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 aquiForti

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.

Imagen 01

Imagen 02

Imagen 03

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.

Imagen 04

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.

Imagen 05

Imagen 06

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.

Imagen 07

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!!