Archivo de la categoría: Infraestructura de red

Separación, segmentación, comunicaciones, seguridad perimetral y electrónica de red.

Control de Aplicación en entornos ICS/SCADA, Parte I

Posted on por
Anuncios

Hace poco más de dos meses hablaba de la necesidad de utilizar NGFW (Next Generation Firewall) para securizar nuestros entornos industriales. En ese ejemplo empleaba Modbus como protocolo y el uso de la funcionalidad IPS (Intrusion Protection System) para frenar posibles ataques. El artículo lo podéis encontrar a continuación:

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

Si bien los fabricantes están incorporando características de seguridad en sus productos, la presencia de equipos que no disponen de ellas es, y seguirá siendo, muy amplia. Esto es debido a que el ciclo de vida de los mismos es mayor si lo comparamos contra entornos IT tradicionales. Esto da pie a que exista equipamiento “antiguo”, totalmente funcional, pero con vulnerabilidades susceptibles de ser explotadas. Esto es comprensible ya que en el momento de su diseño, la seguridad no era una necesidad. Sí, la funcionalidad y robustez, algo que se mantiene en la actualidad. A veces es posible corregirlas mediante actualizaciones, pero no siempre es así ya que el hardware puede ser parcial o totalmente incompatible según el modelo en cuestión. Entonces, bien sea porque no es necesario su reemplazo o técnicamente posible su actualización, la securización pasa por elementos o medidas externas. Y como no, los NGFW son una de ellas.

Otras de las funcionalidades que poseen los NGFW es el denominado “Control de Aplicación”. Esta permite identificar el software que circula por la red, interpretar la información contenida en los paquetes mediante “Deep Packet Inspection” y a partir de aquí, permitir, bloquear, monitorizar o poner en cuarentena el mismo. Esto facilita reconocer herramientas en entornos donde, en principio, no debiera darse esas comunicaciones y por tanto alertarnos de que algo anormal está sucediendo o, aún peor, una actividad hostil.

Si bien resulta necesario frenar cualquier actividad no autorizada o perjudicial para nuestras infraestructuras, mejor aún es poder identificarlas o frenarlas antes de que se produzcan. Situándonos en el papel de un atacante, antes de llevar a cabo cualquier acción han de darse fases como reconocimiento, identificación de equipos, redes, servicios, vulnerabilidades, etc. debiendo emplear herramientas con las que, de forma activa o pasiva, poder obtener dicha información. Por tanto, si somos capaces de detectarlas, no sólo estaremos previniendo una actividad inusual sino además, que algo o alguien pueda estar dando los primeros pasos antes de llevar a cabo una acción mayor. Y como no, si esto se produce, identificar qué es lo que ha fallado o es necesario corregir.

Por poner un ejemplo, propongo el siguiente escenario:

Escribir una leyenda

En la red 192.168.0.0/24 tendremos un PLC (en este caso un Siemens S7-300 emulado con la aplicación Snap7) con IP 192.168.0.65 el cual es accesible desde una Workstation 192.168.0.100/24 destinada a labores propias del entorno. Por otro lado, tenemos una red 10.10.10.0/24 donde ubicamos una DMZ, y en ella, un servidor SCADA con IP 10.10.10.101/24. Por último, la Red de Oficinas bajo un direccionamiento 192.168.1.0/24, donde a priori no debiera haber ningún tipo de software de Control.

Como NGFWs he empleado un Fortinet FortiWifi 60D, el cual tiene instalada una versión FortiOS 5.4.2. Cabe recordar que en esta versión hay que habilitar las firmas “Industrial” ya que por defecto no vienen activadas.

En la siguiente imagen vemos una captura del Software Step7 de Siemens desde la Workstation que citaba anteriormente.

Para el “Firewall Separación IT-OT” de los entornos de Oficinas y de Control, hemos creado el siguiente perfil de “Application Control”. Aquí bloqueamos todo tipo de aplicaciones, no debe darse ninguna comunicación desde un lado a otro.

Sin embargo, ya dentro del entorno OT, en “Firewall Segmentación OT-OT”, sí que permiten las aplicaciones “Industrial” y “Network Services”. Esto es:

Si queremos ser más estrictos podríamos bloquear una categoría completa y permitir a su vez que aplicaciones incluidas dentro de ésta, se ejecuten. Esto es, monitorizar la actividad de estos dos últimos y sin embargo denegar una acción concreta. Esto se consigue mediante la opción “Application Overrides”, cuya configuración prevalecerá sobre la definida de un modo más global.  En la imagen siguiente podemos ver que aunque monitoricemos el tráfico, vamos a impedir especificamente la acción de Bloquear la CPU del PLC mediante el protocolo S7 de Siemens.

También podríamos hacer lo propio definiendo un filtro, “Filter Overrides”. Por ejemplo todas las comunicaciones “Cliente-Servidor” bloquearlas independientemente de qué categoría estén.

A partir de aquí será configurar las reglas en el Firewall según sean nuestros direccionamientos, interfaces y servicios de igual manera que lo sería en un Firewall tradicional. Es decir, podemos definir que desde un origen a un destino y bajo un mismo puerto sólo se puedan llevar a cabo tareas específicas de ese protocolo.

Hasta aquí una presentación de los que es y para qué se utiliza el “Control de Aplicaciones” dentro de un NGFW del fabricante Fortinet. En la próxima veremos algunos ejemplos y la funcionalidad de esta característica.

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

Un saludo.

Edorta.

MRP, Media Redundancy Protocol

Posted on por
Anuncios

Como avanzaba en la entrada “Redundancia en entornos ICS/SCADA” hoy comenzaremos a hablar de aquellos mecanismos que dotan a nuestras redes industriales de una resiliencia mayor. La tendencia de los protocolos empleados en este tipo de entornos es evolucionar hacia tecnología Ethernet en lugar de la tradicional serie. Sin embargo, su propia naturaleza, no permite la creación de bucles en la red ya que el tráfico “Broadcast” podría no sólo ralentizar las comunicaciones, sino bloquearlas. Ante la necesidad de entornos que requieren alta disponibilidad, hemos configurar protocolos que “rompan” esos bucles dejando un solo camino posible para la comunicación entre equipos. En caso de producirse un fallo, dicho protocolo será capaz de detectarlo y desencadenar las medidas necesarias para que todo el tráfico comience a ir por una vía alternativa. En entornos IT, el más conocido es Spanning Tree Protocol (STP) así como sus respectivas versiones RSTP, MSTP o PVSTP. Sin embargo, los tiempos que maneja para poder restaurar las comunicaciones son muy altos para los requerimientos de los sistemas de control y automatización, siendo necesario emplear otros que iremos viendo en esta y entradas sucesivas.

El primero de ellos es MRP (Media Redundancy Protocol). Este protocolo está descrito en el estándar IEC 62439-2, el cual es ampliamente utilizado en redes industriales para entornos de alta disponibilidad. MRP opera en Capa 2 y es específico para redes en anillo con hasta 50 equipos, garantizando un comportamiento determinístico en caso necesidad de cambio de un estado a otro. Para ello, define una serie de tiempos máximos para recuperar las comunicaciones según sea la configuración elegida. Éstos pueden ser 500 ms, 200 ms, 30 ms y 10 ms. Como hemos dicho estos son valores máximos, por lo que los tiempos reales oscilan entre la mitad y un cuarto de los mismos. Esto es, si configuramos nuestros equipos con un valor de 200 ms, el tiempo aproximado del cambio entre una ruta a otra de los paquetes podrá rondar entre 50 y 60 ms, aproximadamente.

Como vemos en la imagen anterior, MRP necesita que cada nodo disponga de dos enlaces en el anillo. Dentro de la topología, uno de ellos será elegido MRM (Media Redundancy Manager), el cual   monitoriza y controla,  reaccionando en caso de fallo. Esto lo consigue enviando tramas de control desde cada uno de los puertos, recibiéndolas en el otro extremo.  A pesar de que uno de ellos permanezca “Bloqueado”.

El resto de elementos del anillo reciben el nombre de MRC (Media Redundancy Client). Cada MRC retransmite las tramas de control enviadas por el MRM de un puerto a otro de tal manera que éste pueda detectar el fallo y activar el puerto en “Bloqueado”.

MRP define 3 tipos de tramas de control:

  1. Para monitorizar el estado de anillo. MRM envía regularmente tramas de prueba en ambos puertos que le conectan al anillo.
  2. Cuando el MRM detecta un fallo o recuperación de los enlaces, envía tramas de cambio de topología (“TopoChange”) en ambos puertos de lanillo.
  3. Cuando un MRC detecta un fallo o recuperación en un puerto, local envía tramas de cambio de enlace (“LinkChange”) al MRM. Éstas se consideran como un subtipo de otras denominadas “Linkdown y “Linkup”.

En un funcionamiento normal, “Anillo Cerrado”, el MRM bloqueará todo el tráfico a excepción de estas tramas, por lo que a efectos prácticos el anillo se comporta como si fuera un único enlace. Esto es, no existe ningún bucle.

Cuando el MRM deja de recibir dichas tramas en el otro extremo, interpreta que el enlace se ha roto en algún punto,  “Anillo Abierto”, por lo que ese puerto que estaba en “Bloqueado”, ahora comienza a enviar tramas de forma normal.

A esto hay que sumar que los MRC son capaces de informar de cambios de estado en alguno de los enlaces. Si esto se produjese, el MRC envía una trama de control al MRM informando de ello. Si éste la recibe antes de detectar que se ha producido un cambio en el anillo, toma la información contenida en ella para activar el enlace “Bloqueado” y así recuperar la conectividad en el menor tiempo posible. De ahí que, aunque se fijen tiempos máximos, siempre cabe la posibilidad de que el anillo pueda seguir enviando tráfico por debajo de estos umbrales.

Tanto el MRM como el MRC definen una serie de “estados” para sus puertos dentro de la topología.

  1. Disabled, los puertos descartan todas las tramas recibidas.
  1. Blocked, los puertos descartan todas las tramas excepto las tramas de control MRP y algunas otras de protocolos como LLDP.
  1. Forwarding, los puertos reenvían todas las tramas recibidas.
  1. Not Connected, el enlace está físicamente caído o desconectado.

En otro orden, en el caso concreto de PROFINET, MRP puede ser implementado sobre los dispositivos finales sin necesidad de equipos adicionales gracias a la definición de una aplicación concreta como es PROFINET/MRP.

Por último conviene citar las funcionalidades que cada fabricante otorga a sus productos dependiendo de modelos y licenciamiento. Algunos de ellos pueden ser; posibilidad de integración con software de gestión como Siemens Total Integrated Automation (TIA); definición de varios anillos MRP por una misma VLAN; interperabilidad con Spanning Tree Protocol; etc.

No debemos olvidar tampoco de las limitaciones y recomendaciones que cada uno hace a la hora de configurar los equipos. Por ejemplo, Cisco nos habla de que los puertos MRP no pueden ser configurados como puertos SPAN, Private VLAN o Tunnel y, si además la implementación es sobre Profinet, como Trunk; ser configurado en puertos Etherchannel; etc.

Lo dicho, hablar de resiliencia no es sólo hablar de la securización, es tener además la capacidad de recuperarse del elemento que provoca una determinada perturbación. Hoy en día con la cantidad de amenazas que acechan a los Sistemas de Control  Industrial resulta necesario no sólo desplegar medidas técnicas sino además definir arquitecturas que hagan frente a cambios o anomalías inesperadas. Los accidentes ocurren, una fibra óptica rota; un SFP, defectuoso; una configuración accidental de un puerto, o cualquier otra razón,  bien puede desencadenar una alteración en las comunicaciones y por tanto un impacto en el proceso. Esto no quita que debamos hablar de otros riesgos como el “Sabotaje”, “Inyección de tráfico”, “Intrusión”, y que obligen implementar otras medidas como el “Hardening de Sistemas”, “Monitorización”, “Control de Accesos”, entre otras paliando así estas amenazas.

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

Hasta pronto!

Redundancia en entornos ICS/SCADA

Posted on por
Anuncios

Como hemos hablado en anteriores ocasiones, y no nos cansaremos de repetirlo, la prioridad número uno en entornos industriales es garantizar la disponibilidad. Luego vendrá la integridad y la confidencialidad, pero lo primero es la disponibilidad. Para alcanzarlo, se ha de aplicar una estrategia de Defensa en Profundidad para reducir los riesgos de sufrir un incidente de seguridad y prevenir que algo, o alguien, atente total o parcialmente contra nuestras instalaciones. Dada la limitación y naturaleza de los equipos, así como las debilidades que ofrecen en lo que a materia de seguridad se refiere, muchos de ellos deben delegar en la infraestructura de red la seguridad que por sí mismos no pueden ofrecer. Para ello, ha de comenzarse por la separación de los entornos IT y OT; y más tarde en la segmentación de este último definiendo zonas más pequeñas con el fin de que si una se ve afectada, la amenaza no se propage al resto.

Sin embargo, esto no es lo único que debemos considerar. Si queremos que nuestra red sea resiliente, no sólo debe evitar,  y ser capaz,  de mitigar un ataque sino que debe ser tolerante a fallos, ya sean éstos intencionados o no.

Los enlaces redundantes suponen una medida para evitar puntos únicos de fallo que puedan dejar fuera de servicio toda una instalación. Duplicando las vías de comunicación conseguimos que, en caso de producirse uno, los sistemas comunicarán por caminos alternativos. Así podemos establecer dos posibles propósitos:

  1. Tolerancia a fallos

Aumento de las vías de comunicación que permitan reconducir el tráfico por alguna de las restantes.

  1. Balanceo de carga

Disponiendo de dos o más enlaces entre equipos podemos no sólo lograr el punto anterior sino también un envío alternativo de paquetes por canales distintos de tal manera que consigamos descongestionarlos en caso de saturación de alguno de ellos.

Aunque el punto uno en realidad también está incluido dentro del segundo, el uso de enlaces redundantes en entornos industriales esta usualmente dirigido a éste ya que es más importante garantizar la disponibilidad que el rendimiento. Esto último además se refuerza con que las necesidades de anchos de banda en entornos OT son más pequeñas que en IT.

La tendencia de las comunicaciones industriales es que se basen en tecnologías Ethernet y servicios TCP/IP dejando atrás, o reduciendo el uso,  protocolos basados en buses tipo RS-485 o serie. Sin embargo, el tráfico broadcast propio de la tecnología Ethernet no permite el uso de enlaces redundantes por lo que hemos de implementar protocolos que resuelvan este problema. El más extendido es Spanning Tree Protocol o algunas de sus versiones como RSTP, MSTP o PVSTP, el cual permite disponer de varias rutas físicas, pero bloqueando los puertos de los elementos de la red de tal manera que sólo exista una activa. El resto, permanece en “Standby” hasta que, como digo,  se produzca una caída de alguno de los enlaces que permanecen activos obligando a recalcular una segunda ruta que reestablezca las comunicaciones,  activando alguno de esos enlaces que permanecían en “Standby”. Hasta que esto ocurre transcurre un tiempo que puede ir de uno a varias decenas de segundos según sea el protocolo elegido.

Esto en entornos IT puede no suponer un problema, donde el retraso en décimas de segundo puede pasar inadvertido mientras se manda un correo o se accede a un fichero en una unidad de red. Aparte, claro está, que existan tecnologías más modernas que permitan la supresión de bucles en Capa 2 y por ende, estos protocolos. Pero insisto, aunque estén implementados, los tiempos pueden ser más amplios, algo que resulta inaceptable para entornos OT. Para hacernos una idea, en comunicaciones tipo RT (Real Time) o IRT (Isochronous Real Time) hablamos de latencias por debajo de 10 ms y 1 ms, respectivamente. Es por ello que las medidas de entornos IT no son aplicables, una vez más, a entornos de automatización, por lo que se han de aplicar otras. En resumen, el método para conmutar de un enlace a otro debe ser predecible para determinar el límite tolerable de latencia, y por tanto, conocer de antemano cómo puede afectar a las comunicaciones según sea su naturaleza. El objetivo debe ser que la convergencia sea tan rápida que resulte transparente para las aplicaciones en uso sin sobrepasar los límites tolerables.

Es por esto que en entornos OT no hablamos de Spanning Tree, ni como decía, ninguna de sus variantes. No tienen cabida. Han de emplearse otros. En las próximas entradas veremos estos protocolos y cómo, una vez más, disponer de una arquitectura de red nos proporcionará,  junto con las medidas de seguridad paralelas,  una resiliencia mayor para hacer frente al creciente número de amenazas y riesgos a los que se enfrentan nuestras infraestructuras.

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

Un saludo!