Identificando tráfico con cortafuegos, Parte II

Hablábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de identificar los protocolos e instrucciones para limitar aquellas acciones que pueden realizar sobre Sistemas de Control Industrial. Para llevar a cabo esta acción, podemos emplear soluciones como Nozomi SCADAGuardian la cual, entre otras funciones, permite realizar Deep Packet Inspection (DPI) y extraer la información que necesitamos.

Sin embargo, los  mismos cortafuegos que nos ayudan a “Separar y Segmentar” podrán ayudarnos en esta tarea. En “Identificando tráfico con cortafuegos, Parte I” veíamos como podríamos hacerlo con equipamiento del fabricante Fortinet. En el día de hoy abordaremos la misma tarea, pero con aquellos del fabricante Palo Alto.

El mismo, dispone del equipo PA-220R para proteger este tipo de entornos teniendo la capacidad para realizar DPI sobre protocolos de esta índole. Además, es apto para instalaciones de entornos tales como subestaciones o plantas generadoras de energía ya que dispone de compatibilidad con estándares como IEC 61850-3 e IEEE 1613. Sus características físicas le permiten operar en rangos de temperatura y humedad de -40-70º C y 10-90%; respectivamente, pudiendo evitar daños físicos en entornos hostiles y polvo en suspensión ya que carece de piezas móviles para su refrigeración. Igualmente dispone de doble alimentación proporcionando así redundancia en lo que suministro eléctrico se refiere.

Dicho lo cual, veremos que las interfaces pueden ser configuradas de distintos modos, entre ellas el “TAP” con el que podremos monitorizar y analizar el tráfico que le llega.

Más tarde, definiremos una “Zona” en la cual incluir la interfaz que recibirá el tráfico que replicaremos desde el puerto espejo del switch o un dispositivo TAP. La denominaremos “Analisis_Trafico_ICS” y le asignaremos la interfaz “ethernet1/8”.

Luego, habrá que crear una política en la que deberemos indicar como origen y destino la Zona configurada en los puntos anteriores e indicar qué aplicaciones queremos detectar.  En nuestro caso seleccionaremos “Any” para poder hacerlo sobre todas aquellas que recojan las firmas que hayan sido desarrolladas hasta el momento.

Adicionalmente podremos habilitar otros controles para la detección de amenazas tales como antivirus, vulnerabilidades, filtrado URL, etc. Esto nos permitirá identificar la presencia de actividades o tráfico malicioso ya presente en nuestra red. Como se puede apreciar hemos creado un “Security Profile Group” con alguno de ellos.

Hecho esto, el siguiente paso será comenzar a procesar tráfico. De igual modo que hicimos en la entrada “Identificando tráfico con cortafuegos, Parte I”, reproduciremos tráfico con la herramienta TCPReplay previamente capturado a partir de distintas fuentes. En este nos hemos decantado por IEC 60870-5-104 y BACnet.

A partir de aquí, en la pestaña “Monitor” podremos ver los logs generados según distintos resultados de ese análisis. Por ejemplo, continuación se muestra el contenido relativo al tráfico en sí mismo, esto es, IPs de origen destino, puertos, Aplicación, etc.

Pero como hemos dicho, también nos interesa analizar en busca de amenazas como intentos de intrusión, malware, etc. Esta información la localizamos en el subapartado “Threat”. En este caso vemos cómo de entre las capturas reproducidas identificamos la presencia del archiconocido “Wannacry”, algunas anomalías relativas a Siemens S7 o DNP3.

Con la interoperabilidad entre entornos IT y OT, es imprescindible conocer las comunicaciones que se realizan hacia/desde los equipos. Un activo no sólo se compone de los datos de fabricante, modelo, instalación, etc. también han de incluirse sus comunicaciones dentro del modelo de gestión de activos. Un firewall y sus funcionalidades extras serán tan eficientes como estrictos seamos con su configuración y mantenimiento.

Pero, para conseguirlo, hemos hacer la tarea previa de identificarlas y estructurarlas y para ello los mismos cortafuegos también pueden ayudarnos.

Un saludo, ¡nos vemos en la siguiente!

 

Identificando tráfico con cortafuegos, Parte I

Comentábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de realizar un análisis del tráfico de red para identificar las comunicaciones existentes dentro de nuestro entorno OT. Con los activos y servicios localizados, podremos empezar a configurar las reglas necesarias en nuestros cortafuegos dentro de las acciones de “Separación y Segmentación” necesarias para limitar accesos o propagación de acciones que puedan afectar a la operatividad de nuestras instalaciones.

Sin embrago, debemos ir un paso más allá y conocer aquellos protocolos y comandos que permiten interactuar entre sistemas de control. Sin embargo, uno de los problemas más comunes es el alto grado de desconocimiento ya que, muy a menudo, nos enfrentamos a redes conmutadas o enrutadas donde todo comunica sin filtro alguno.

Esto cobra especial importancia, a nivel de célula de automatización, instalación o conjunto de equipos en planta; base de la actividad de las empresas. Sistemas superiores deben comunicar con controladores y éstos a su vez con elementos de periferia, como sensores, actuadores o cabeceras dentro de arquitecturas de periferia distribuida. Esto da lugar a en muchas ocasiones a que PLCs dispongan de dobles en laces de red. Por ejemplo, un módulo de comunicaciones para su integración “aguas arriba” con la red corporativa y otra “aguas abajo” de la propia CPU para entradas, salidas y módulos de conexión de dentro arquitecturas descentralizadas.

Como bien sabemos las latencias en este tipo de entornos son un aspecto crítico ya que las comunicaciones deben de hacer frente al carácter determinístico de éstas. Por tanto, debamos donde debamos identificar el tráfico no podemos introducir tiempos adicionales que puedan interferir en la operación.

Por tanto, surgen pues dos necesidades, documentar nuestras comunicaciones independientemente del segmento; y el despliegue de nuevos elementos de seguridad perimetral para separar y segmentar nuestras redes IT y OT.

Gracias a las funcionalidades de los productos de algunos fabricantes podremos apoyarnos en alguna de ellas para hacer esto último.

Por ejemplo, el fabricante Fortinet nos permite la configuración de alguna de las interfaces físicas en un modo denominado “One-arm-Sniffer”. Este modo, a diferencia de las habituales para permitir o denegar el flujo de comunicaciones, permitirá analizar mediante los motores IPS y Control de Aplicación el tráfico enviado desde un puerto espejo un dispositivo TAP. En caso de coincidencia con alguna de las firmas, se genera el correspondiente log y registro, descartándose el tráfico recibido.

De esta manera podremos utilizar nuestro equipo Fortinet Fortigate como un IDS o detectar qué tráfico a nivel de capa 7 que como hablamos en la entrada “Más que IPs y Puertos para proteger entornos industriales”. 

En primer lugar, deberemos configurar la interfaz en el modo anteriormente indicado, a partir de lo cual nos aparecerán las distintas opciones como los motores de filtrado contra los cuales queremos analizar el tráfico recibido. Como vemos en la imagen siguiente en nuestro caso hemos elegido la interfaz número 4.

Luego dentro de “Edit Sniffer Profile” podremos configurar cada uno de los motores y por tanto y ajustarlo en función de nuestras necesidades. En nuestro caso, puesto que planteamos el escenario de identificación de las comunicaciones y los protocolos industriales nos centraremos en éstos.

Para la presente entrada he empleado la herramienta TCPreplay para la reproducción de capturas PCAP.

De esta manera, el Firewall nos ha identificado no sólo un buen conjunto de ellos sino además los comandos que a través de ellos se envían. Como podemos ver en la imagen siguiente dentro de Modbus encontramos “Modbus_Function.Reserved.Code” y “Modbus_Read_Coils” entre otras como “S7.Protocol_CPU-Function.Read.SZL” o “DNP3_Response”.

Dependiendo de la arquitectura que tenga en nuestras instalaciones de planta las opciones podrán ser diversas, aparte de dónde radique el interés o necesidad por identificar ese tráfico. Es decir, podremos desplegar su uso a nivel de célula para conocer cómo un HMI, un PLC o periferia intercambian información; o bien, cómo desde servidores SCADA o MES envían o reciben consultas sobre equipos de planta para labores de control de producción, monitorización, telemetría entre otras.

En cualquiera de los casos, la idea es explotar otra funcionalidad de los cortafuegos que vayamos a desplegar y en la que nos podremos apoyar para la identificación de comunicaciones. Quizás no tengamos herramientas como “Nozomi SCADAGuardian” pero alternativas, las tenemos.

No obstante Fortinet no es el único. Próximamente presentaremos una funcionalidad similar, pero de otro fabricante.

¡Un saludo, nos vemos en la próxima!

Monitorización redes industriales, SCADAGuardian

Cuando abordamos un proyecto para la protección de un entorno de control y automatización, una de las primeras tareas es elaborar un inventario de todos los activos. No podemos tratar de reducir los riesgos de que algo o alguien, de una manera intencionada o no, pueda llevar a cabo una acción que afecte a la actividad de planta, instalaciones o infraestructuras; si saber lo que tenemos.

Es cierto que muchos equipos podrán serán comunes en distintos escenarios, pero dada la heterogeneidad de las actividades industriales cada entorno deberá ser abordado de forma particular. Es cierto que PLC´s, HMI´s y SIS serán un común denominador; no si de lo que hablamos es de atornilladoras, AGVs, sistemas de almacenamiento automático, sistemas de metrología, y un largo etcétera.

Esta tarea puede no ser compleja, pero sí tediosa. Al fin y al cabo, estamos recolectando información. El problema es cómo lo hacemos de una manera lo más sencilla y efectiva posible. Además, por experiencia, se parte con un alto grado de desconocimiento en particular para los profesionales que tienen que liderar proyectos de Ciberseguridad Industrial. Provenientes de entornos IT, donde aparte de desconocer las tecnologías, componentes y tecnologías, comienzan a relacionarse más estrechamente con personal con distintas culturas, puntos de vista, necesidades y sobre todo, prioridades. Hablo de personal de Ingeniería o Mantenimiento.

Por tanto, la base de cualquier proyecto es tener un inventario completo y consolidado que nos permita desarrollar medidas eficientes para proteger nuestros entornos.

Sin embargo, el éste no debe estar ceñido exclusivamente a información sobre tipos de equipos, fabricantes, modelos o versiones de firmware. Debemos conocer las comunicaciones que mantienen con otros sistemas o dispositivos. Esto es, orígenes y destinos, protocolos empleados, direcciones IP y sobre todo qué consignas o valores se envían a través de ellos. Podemos estar autorizando una determinada comunicación, pero ¿qué ocurre si aprovechando una falta de medidas de seguridad nativas somos capaces de cambiar un valor que está fuera de tolerancia?

Por esta y otras razones que iremos descubriendo en sucesivos artículos es que debemos contar con herramientas que nos ayuden a identificar los activos en nuestra organización, sus características y conocer cómo y de qué manera se comunican. A partir de aquí, ya comenzaremos a localizar vulnerabilidades, calcular impactos, priorizar medidas para minimizar riesgos, definir topologías de re red, crear matrices de comunicaciones para configurar reglas en firewalls, etc. etc. etc.

Una de estas ellas es el producto de la firma NOZOMI Networks, SCADAGuardian. Se trata de una herramienta especializada para entornos y tecnologías OT. En formato físico o virtual, entre sus características están

  • Monitorización en tiempo real
  • Identificación de activos de forma automática
  • Detección de comportamiento, amenazas y vulnerabilidades
  • Deep Packet Inspection de protocolos industriales
  • Fácil despliegue
  • Integración con otros sistemas
  • Creación de informes

El modo de operación es por medio bien de un puerto espejo en algunos de los switches de nuestra infraestructura o por medio de dispositivos TAP por lo que no resulta intrusiva ni añade latencias en las comunicaciones establecidas.

Por supuesto, todas estas medidas van acompañadas de una interfaz gráfica a través de la cual podamos visualizar, analizar y explotar toda la información recolectada de una manera intuitiva a través de los menús de navegación.

Adicionalmente se cuenta con una herramienta de gestión centralizada denominada “Central Management Console” con la que podremos desde un único espacio tener visibilidad de todos nuestros SCADAGuardian desplegados en nuestras instalaciones geográficamente o localmente dispersas.

No obstante, esta herramienta no tiene porqué ser empleada exclusivamente por clientes finales. Empresas que provean de servicios de SOC pueden encontrar en CMC una solución para proporcionar otros nuevos sobre entornos industriales como veremos más adelante.

Con todo ello a continuación se muestra una imagen de un despliegue tipo:

Ahora bien, hasta ahora nos hemos ceñido a la identificación de activos y características asociadas, para poder así elaborar un inventario acorde a nuestras necesidades. La herramienta nos permitirá exportar la información generada en formatos como Excel o CSV para un tratamiento posterior. Entre ellas estará la relativa a los equipos, sus enlaces y sesiones de comunicaciones pudiendo tener documentado los valores identificados dentro de cada protocolo.

Hasta ahora hemos hablado de esa primera fase de recolección de información para tener una visión de cómo y por quién está compuesta nuestra red OT. Sin embargo, las capacidades de esta herramienta van más allá pudiendo ser capaz de detectar vulnerabilidades con mayor o menor precisión según sea el caso.

Adicionalmente a SCADAGuardian, disponemos de SCADAGuardian Advanced. Como hemos dicho, la solución recolecta información de forma pasiva no interfiriendo en el tráfico legítimo. Esto proporciona a SCADAGuardian la capacidad de identificar vulnerabilidades por medio del citado análisis. Sin embargo, SCADAGuardian Advanced incorpora una funcionalidad que permite confirmar dichas vulnerabilidades por medio de consultas inteligentes sin interferir en el correcto funcionamiento.

A continuación, se establece una comparativa entre ambas:

Como bien sabemos existe un creciente aumento de vulnerabilidades y amenazas que afectan a sistemas de control y entornos industriales. En este sentido NOZOMI Networks cuenta con un servicio de suscripción denominado “OT Threat Feed” para recibir las últimas descubiertas y que nuestros SCADAGuardian o SCADAGuadian Advanced tengan la capacidad de detectarlas. Detrás de ello, se encuentra con un equipo de investigadores propio que trabajan continuamente para la mejora del producto siendo un ejemplo de ello las publicadas en fuentes como el ICS-CERT.

Con todo ello hemos de tener presente una funcionalidad clave en este tipo de soluciones y es la de notificar de alertas cada vez que tenga lugar un evento o anomalía. Para ello podremos personalizar y establecer canales para su notificación que van desde productos comerciales hasta mensajes de correo electrónico, Syslog o Traps de SNMP. SCADAGuardian establece 4 tipos de alertas principales en función del motor (funcionalidad) que la origine, “Protocol Validation”, “Learned Behavior”, “Built-in Checks” y “Custom Checks”.

En el momento del despliegue, SCADAGuardian necesita de un proceso de aprendizaje acerca del comportamiento de la red y de los elementos que la componen. En función de ese aprendizaje, la herramienta generará una nueva alerta por cada anomalía detectada. Más tarde, debreemos indicar si se trata de un incidente o si por el contrario se trata de un cambio o evento controlado. Por ejemplo, imaginemos una tarea de mantenimiento programado en la que conectamos un nuevo equipo que hasta la fecha no había sido conectado a la red.

Hasta aquí la entrada del día de hoy donde hemos hecho un repaso a la herramienta de monitorización líder del mercado no sólo por el crecimiento que NOZOMI Networks sino por sus capacidades de integración como es el caso de los equipos SIEMENS RUGGEDCOM APE proporcionando así una solución embebida en productos de terceros evitando así el despliegue de nuevo equipamiento.

Sin embargo no es la única. A continuación os dejo un video con la que se puede obtener con equipamiento de la firma Fortinet, dela que ya hemos hablado en otras entradas como su integración con switches.

Un saludo, nos vemos en la próxima!

Edorta

 

SIEMENS SCALANCE S615, firewall para protección de célula

La seguridad perimetral es, y seguirá siendo, el primero de los requisitos para proteger los entornos industriales. Si no somos capaces de establecer los límites y saber hasta dónde llegan los entornos IT y OT, poco podremos hacer a favor de su seguridad. Para ello la apuesta es el despliegue de NGFW y ejercer así un control hasta Capa 7 para Separar y Segmentar nuestras redes. Pero si lo que necesitamos, o queremos, es ir un paso más allá y bajar a nivel de célula, también podremos hacerlo empleando modelos más pequeños pero adaptados físicamente a situaciones ambientales más hostiles de temperatura, humedad, polvo o campos electromagnéticos. Tal es el caso de modelos como Fortinet Fortigate Rugged30D, 35D, 60D y 90D; CheckPoint 1200R o Palo Alto 220R

Sin embargo, puede haber escenarios en los que este grado de protección a bajo nivel no pueda o no tenga porqué alcanzarse.

Por un lado, hay que tener en cuenta un que las actualizaciones de las firmas Antivirus, Control de Aplicación, IDS/IPS, Filtrado Web hay que renovarlas asumiendo un coste mayor o menor dependiendo el número de equipos o el período de soporte contratado. Y por otro, que cada organización determinará el grado de riesgo asumible en función de su actividad. Por lo que podrá aceptar que no es aceptable tal inversión, dando por buena una protección hasta Capa 4 implementando en firewalls superiores los citados controles.

No nos podemos olvidar que cada proyecto lleva aparejado un consumo de recursos, tanto de tiempo, personal y dinero. Dicho de otra manera, ¿cuánto tiempo necesito? ¿Cuántos profesionales me hacen falta? Y … ¿Cuánto me va a costar? Y en este sentido, no solamente en el momento del despliegue sino en los años sucesivos.

Cada organización es única, con lo que arquitecturas, sistemas, procesos, riesgos, amenazas, vulnerabilidades entre otros factores deben ser tratados de forma individual.

Por tanto, por muy buenas y que sean las medidas, y las propuestas sean de máximos, puede haber muchos condicionantes que nos hagan reducir nuestras pretensiones y no ir a propuestas de máximos. Por tanto, deberemos buscar una vez más alternativas y aproximaciones distintas.

En este sentido los fabricantes de equipos industriales disponen de productos de networking para una u otra función. Tal es el caso del equipo SIEMENS Scalance S615

Se trata de un Router/Firewall de pequeño tamaño con el que podremos crear hasta un total de 128 reglas de filtrado en Capa 4 y con el que podremos apoyarnos para realizar un filtrado de las comunicaciones. Posee un diseño pequeño, para equipos individuales o un conjunto reducido de ellos, pudiéndose instalar como es lógico, sobre carril DIN para un montaje próximo al equipo final.

Permite ser alimentado por doble fuente de alimentación a 24VDC, mientras que sus 5 puertos RJ45 nos permiten conectar distintos equipos a nivel de célula un rango de operación de -40º a 70º C. La protección ambiental está situada en IP20.

Ya dentro de las funcionalidades de filtrado (de tipo “Stateful Inspection”) si bien no tendría mucho sentido hacerlo, podremos deshabilitar la funcionalidad de cortafuegos.

Luego dentro del mismo menú podremos definir Servicios IP, Protocolos a nivel de capa 3 e incluso establecer el tipo y código permitidos por ICMP.

La definición de servicios lo encontraremos en la pestaña “IP Service”, desde donde luego los encontraremos como veremos en las reglas a configurar.

Las reglas las configuraremos en la pestaña “IP Rules”. En cuanto a las acciones podremos elegir entre Permitir, denegar o denegar sin enviar ninguna notificación al emisor.

Adicionalmente a las IPs origen y destino, podremos definir las interfaces de entrada y salida para luego completarlas con los servicios.

Para cada una de ellas podremos indicar si queremos registrar algún tipo de log y su respectiva categorización en caso de “machee” con alguna de las reglas configuradas. En nosotros estará definir qué es más o menos importante.

Luego en otro de los menús podremos visualizarlos.

En este sentido conviene mencionar la posibilidad de enviarlos a un servidor Syslog para poderlos consolidad junto con los de otros equipos. Esto cobra especial importancia si contamos con un sistema de correlación SIEM con el que podremos detectar anomalías de forma conjunta y contextualizada.

Como podemos apreciar se trata de un cortafuegos con capacidades reducidas, y con limitaciones en comparación productos de fabricantes especializados. No obstante, puede ser un buen recurso como apoyo a otros con las funcionalidades y motores de análisis necesarios para garantizar unos niveles de protección acordes a las amenazas de hoy en día.

Tal es el caso de la protección PLCs, RTU´s como se puede apreciar en la imagen siguiente.

Hasta aquí la presentación de este equipo, que aunque sencillo, puede ayudarnos a mejorar los controles de acceso a equipos finales.

¡Nos vemos en la próxima!

Un saludo.

Sumando fuerzas, Switching y Firewalling para proteger maquinaria e instalaciones industriales

Dentro de cualquier estrategia de protección de entornos industriales no podemos pasar por alto la heterogeneidad de éstos. No podemos considerar de igual manera una actividad dedicada a la fabricación de vehículos, farmacéutica, alimentación o componentes electrónicos. Los tiempos de respuesta, los máximos asumibles de parada, estrategia de producción, pueden no ser para nada similares. Por tanto, la manera en la que debemos priorizar y desplegar las medidas que prevengan incidentes, debe ser distinta.

Pero independientemente del sector, los propietarios de los activos (esto es, las propias empresas) incorporan tecnología distinta de fabricantes, ingenierías, integradores o cualquier otra tercera parte debido al alto grado de especialización aparte de la complejidad o necesidades concretas de estos entornos. Claro está, que en muchos casos sea más operativo, económico o práctico externalizar estas tareas en lugar de desarrollar la solución y el conocimiento con medios internos.

Puesto que forman parte del proceso, se ha de acordar contratos de mantenimiento con el fin de garantizar un recurso en caso de ser necesario y recibir soporte a lo largo del ciclo de vida del producto, que como sabemos, dentro del mundo es OT es mayor que el tradicional IT. Esto es, respuesta ante una incidencia, actualizaciones, modificaciones o cualquier otra razón, de tal manera que el propietario de ese activo no pueda ver afectada su actividad por no saber resolver, atender o actuar sobre él.

Esto supone un problema para los citados integradores ya que una vez sus sistemas o maquinaria están en las instalaciones de sus clientes, dejan de tener, a priori, un control sobre el mismo. No tienen la garantía de que alguien pueda, en un momento dado, “conectarse” y llevar a cabo una acción que derive en un mal funcionamiento y generar un incidente con mayor o menor impacto. Por tanto, resulta necesario controlar los puntos de conexión a ese equipamiento en particular al de red como switches que permitan la comunicación entre equipos y componentes. Particularmente si hay consecuencias económicas…

En este sentido la conjunción de Switches y Firewalls del fabricante Fortinet pueden ayudarnos ya que dichos cortafuegos poseen la capacidad de controlar algunas funciones de los switches mediante un controlador embebido.

En este caso disponemos de un Fortigate Rugged 90D y un FortiSwitch Rugged 112D-PoE.

El Firewall será el que nos una a la red del cliente y evitará que un activo de la red de éste llegue a los componentes de la instalación o maquinaria en cuestión. La configuración podrá ser variada según la topología, esto es, que opere a nivel de capa 2 o 3. Será pues nuestra seguridad perimetral. El modo de acceso lo podemos establecer a través de un túnel VPN a partir de las opciones que nos permite el equipo. Obviamente, habilitaremos los distintos perfiles de seguridad como Antivirus, IDS/IPS, Control de Aplicación, etc.

Ya aguas abajo del Cortafuegos, el Switch permitirá la comunicación entre los equipos finales. Cómo configuremos ambos equipos dependerá del tipo de instalación, arquitectura, tipo de tráfico, conexionado, entre otras variables.

Para poder llevar a cabo esta administración, deberemos configurar una de las interfaces del Fortigate para la comunicación con el FortiSwitch empleando el protocolo FortiLink. En nuestro caso serán enlaces por medio de dos SFP de fibra en ambos extremos. Podréis encontrar más información en estos dos enlaces, enlace 1 y enlace 2.

Por defecto el switch operará en modo “Local Management”.

Si decidimos gestionarlo desde el Firewall deberemos tener presente que la se borrará cualquier configuración existente.

Hecho esto, se nos generarán dos interfaces, dependiendo de las características habilitadas.

Para poder agregar el switch deberemos ir al apartado “WIFI & Switch Controller” y comprobar que el switch se ha detectado y autorizarlo. Una vez hecho el mismo se reiniciará. Según el modelo del switch, por defecto se definirán algunas interfaces de “Auto-discovery”. Podréis encontrar más información aquí.

En el siguiente apartado podremos crear las interfaces de cada una de las VLAN que necesitemos. En mi caso he creado la VLAN100.

A continuación, podremos asignar a cada puerto la correspondiente VLAN y configurar algunos otros parámetros adicionales relativos a PoE, STP, Status, etc.

El último apartado será lo relacionado a las Políticas de Seguridad, algo que nos es objeto por ahora, todo se andará.

Cabe mencionar que aunque veamos que las características de parametrización son menores podremos abrir un CLI desde el apartado “Managed FortiSwitch”.

No obstante, si lo deseásemos también podríamos acceder a la interfaz web. Para ello deberemos de configurar una ruta estática que apunte a la interfaz creada para el enlace Fortilink.

A partir de ahí, podremos acceder a él, no sin antes ser avisados de que este equipo está siendo gestionado por un Fortigate.

Así pues, lo que he querido mostrar hoy es la posibilidad de administrar desde un Firewall algunos parámetros de un switch y con ello ejercer un control sobre los puertos de éste desde éste sin tener la necesidad de acceder a él. Por ejemplo, ante una tarea de mantenimiento, por defecto, dejaremos deshabilitados los puertos que no se utilicen y habilitar uno en caso de ser necesario. Pero si en contreto se trata de una tarea ejercida por un personal externo a la organización como puede ser la ingeniería que construyó la citada maquinaria podríamos, crear una VLAN concreta, asignarla aun puerto del switch y que todo el tráfico pase por el firewall hacia los equipos autorizados, teniendo registro y control de lo que se realice. Aparte, someterlo a filtrado de capa 7, generando los logs pertinentes y registrando evidencias de lo que suceda.

Además, hemos de recordar que los equipos FortiGate también disponen de un controlador Wi-Fi con lo que de forma análoga podremos administrar puntos de acceso tal y como se muestra en la imagen siguiente.

Esto lo podríamos acompañar como puede ser el software FortiClient tal y como lo hablaba tiempo atrás en la entrada “Controlando a nuestros Proveedores, Parte I” y “Controlando a nuestros Proveedores, Parte II”.

Desde luego este es el aspecto más básico ya que podremos explotar algunas funcionalidades más que por ahora no hemos contemplado.

Un saludo, hasta la próxima!

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