Firewalls en Capa 2 en entornos OT

En muchas ocasiones se habla que la primera medida técnica a implementar en lo que a seguridad en entornos industriales se refiere es definir los perímetros entre los entornos IT y OT. Para ello empleamos NGFW capaces no sólo de filtrar tanto por IPs y servicios sino realizar DPI (Deep Packet Inspection) a nivel de capa 7 además de otras funcionalidades como Antivirus, IDS/IPS, Anti DoS. Ya dentro del entorno OT, la recomendación es definir áreas, o zonas, más pequeñas y filtrar el tráfico entre ellas por medio de un segundo Firewall. El de «Segmentación».

Físico o virtual, en el supuesto de que un error humano o acción malintencionada se produjese en alguna de ellas, evitaríamos la propagación al resto provocando un daño mayor. Además, si el daño es menor, el tiempo que necesitaremos para recuperar el conjunto de equipos afectado será menor, como menor será su número.

En la siguiente imagen podemos ver una configuración en la dicha separación la hacemos por medio de la definición de Firewalls Lógicos dentro de uno físico del fabricante Fortinet.

El tamaño de estas áreas, zonas o celdas según sea la literatura de referencia, podrá albergar un número mayor o menor de equipos. Una de las opciones es definir una VLAN para cada una de ellas con un único dominio de broadcast y direccionamiento. Esto cubriría aspectos como protocolos industriales que operen en Capa 2 o tráfico multicast como LLDP. De esta manera podremos filtrar cualquier comunicación entre subredes, otras áreas, servidores en IDMZ (Industrial DMZ), estaciones de ingeniería, etc. Todo este tráfico pasaría por el Firewall de “Segmentación”.

Esto supone asumir que una acción malintencionada en la misma subred podría tener éxito ya que el control se efectúa cuando llega, al menos, en Capa 3. No en Capa 2. Pero, ¿qué ocurre si por alguna razón tenemos que llevar a cabo un filtrado a nivel de Capa 2 a un nivel más bajo y un número de equipos más reducido? Quizás una de las respuestas sea el cambio, o rediseño, del plan de direccionamiento de la/las área/s OT en cuestión y así escalar hasta el siguiente nivel. Sin embargo, esto no puede ser viable.

Mejor pongamos un ejemplo gráfico:

Como podemos observar en esta celda disponemos de un convertidor de fibra a cobre hacia un switch (Switch 1) donde se localizan un HMI y del que cuelga otro (Switch 2) al que se encuentran conectados otros controladores, componentes “Safety”, control de movimiento, etc. Si por alguna razón dicho HMI sufriera alguna infección o se quisiera llevar acabo alguna acción malintencionada, podría alcanzar el resto de equipamiento conectado. Vemos que todo se ubica en un mismo dominio de broadcast y con direccionamiento bajo 192.168.0.0/24.

El problema que se plantea es que el HMI sea un equipo con un sistema operativo sin actualizaciones o fuera de soporte. Bien porque la actualización de éstos pueda ser difícil, aunque no imposible, y por otro lado dado, el ciclo de vida elevado, genera más probabilidad de falta de actualizaciones, nuevos desarrollos, pero siguiendo 100% funcionales. Esto puede suponer un riesgo importante a los equipos ubicados en el otro switch de donde cuelgan autómatas, controladores y otros sistemas.

Sin embargo, no podemos olvidar que las intervenciones en entornos OT no sólo deben ser lo menos intrusivas posible sino, que no alteren la operación normal de las instalaciones. El despliegue de soluciones debe ser transparente y con un nivel de riesgo lo más cercano a cero. Como ya sabemos el riesgo igual a cero, no existe.

Cada cambio introduce un riesgo. Por mucho que lo preparemos, planifiquemos, involucremos a todas las personas que puedan responder ante alguna acción no prevista, siempre puede suceder algo que no esté contemplado. La falta de respuesta en tiempo y forma puede desembocar en la pérdida de disponibilidad. Por ello, cuanto menor sea la cantidad de acciones a realizar mejor. Hemos de guardar un equilibrio entre simplicidad y eficiencia.

Es por todo lo anterior que hemos de considerar el uso y funcionalidades a nivel de capa 2 que ofrecen los cortafuegos. Esto es, filtrar el tráfico entre dispositivos que se encuentren en la misma red y tratar de proteger de forma individualizada todos los elementos desplegados en ella sin requerir cambios adicionales. Esto nos permitirá mantener el direccionamiento intacto siendo la única pérdida de servicio, a priori, los segundos que empleemos en conectar el equipo en nuestra red. Obviamente esto introducirá un punto más de fallo, algo que deberemos asumir si lo que queremos es que otro elemento nos proporcione la seguridad que pretendemos.

Por tanto, cuanto más reduzcamos el riesgo sin intervenir en los equipos finales, indudablemente mejor. Claro está esto también dependerá de la criticidad del equipo, su funcionalidad, ciclo de vida, soporte, entre otros factores. Sin embargo, esto no debe ser algo que deba ser así siempre. Para alcanzar unos niveles lo más completos e integrales posibles hemos de aplicar aquellas que estén disponibles en PLCs, switches industriales, entre otros. Aquí os dejo aquellas que podremos encontrar en autómatas modelo S7-1200 del fabricante Siemens.

En el día de hoy he querido destacar la necesidad de uso de modos y funcionalidades a nivel de capa 2 para proteger los entornos industriales, evitando así cambios o interfiriendo en la operativa aunque esto sea tan sencillo como cambiar una dirección IP.

En sucesivas entradas abordaremos este tema y la manera de cubrir estas necesidades. Esto es uso de firewalls a nivel de capa 2, en lugar de 3, como es a lo que estamos más acostumbrados.

¡Nos vemos en la siguiente!

LLDP, pros y contras de la difusión de información en redes PROFINET

Aunque existen multitud de protocolos propietarios en redes OT, existen estándares que permiten la conexión entre productos de distintos fabricantes. Uno de ellos es PROFINET, evolución del extendido PROFIBUS. Según sea su implementación encontraremos distintas funciones PROFISAFE, PROFIENERGY, PROFINET-MRP, etc. Sin embargo, este protocolo no viene solo, sino que también hace uso de otros para su funcionamiento, entre ellos LLDP. Si, parece que no, pero sí.

Como hemos dicho en anteriores ocasiones, la evolución de las comunicaciones industriales tiende a basarse sobre tecnología Ethernet en detrimento, en muchos casos no en todos, de las comunicaciones serie. Esto va a traer consigo muchas ventajas, pero también algunos inconvenientes. Por ejemplo, será necesario el despliegue de distintas medidas que reduzcan el riesgo de que algo, o alguien, pueda atentar de manera voluntaria o involuntaria contra la disponibilidad de las instalaciones. Y es que, a mayor interconexión, mayor grado de exposición.

LLDP, Link Layer Discovery Protocol, es un protocolo empleado por dispositivos de red para anunciar información propia a otros equipos y dispositivos. Viene definido por el IEE 802.1AB. Su funcionamiento es muy similar al propietario de Cisco CDP, Cisco Discovery Protocol. Todos los dispositivos PROFINET lo soportan y es empleado para identificar, comprobar y mantener la topología de una red PROFINET, aparte de obtener información de diagnóstico si algo cambia. Otro de los usos es facilitar la puesta en marcha, tanto en un funcionamiento normal como en caso de fallo de algún equipo siendo necesario su sustitución. Las operaciones a este respecto se realizan de forma automática y sin necesidad de herramientas tipo software, lo cual simplifica y agiliza la forma en la que un equipo es reemplazado, minimizando la pérdida de disponibilidad.

Para ello los dispostivos PROFINET envían de forma cíclica esta información. Sin embargo  desde el punto de vista de la seguridad…

Haciendo un uso legítimo,  todo son facilidades. Sin embargo, cara a la realización de una auditoría o pentesting en entornos industriales que empleen PROFINET, LLDP se convierte en una fuente de información muy, muy buena.  Las tramas LLDP son enviadas a la dirección multicast 01:80:c200:00e. Los switches, por defecto, inundarán estas tramas por todos los puertos con lo que si conectamos nuestro Wireshark en alguna boca que encontremos libre… Seremos capaces de obtener toda esta información que se anuncia.

¿Ahora bien que pasa con equipos industriales? ¿Qué información podemos extraer? Veamos algunos ejemplos.

En la siguiente imagen podemos ver la que anuncia un switch SIEMENS. Allí podemos ver que estamos conectados al puerto 1, modelo X208, funciones MRP, IP de administración, etc.

En la siguiente captura veremos el tráfico referente a un autómata S7-300 a lque nos hemos conectado a una de sus interfaces disponibles en su CPU.

Como podemos ver aquí ya la información disponible es algo distinta, aunque se mantienen algunos campos como Chassis Subtype, Time to Live, etc. Sin embargo, algunos de los que no están por ejemplo el referente a MRP, protocolo utilizado en  switches para detectar bucles en topologías en anillo. Aprovecho para dejaros el link a una entrada que escribí hace un tiempo. Pincha aquí.

Como último ejemplo pondremos la trama esta vez de un módulo de comunicaciones CP del mismo PLC S7-300 que citaba anteriormente.

Sin duda la información que vemo en cuanto a cantidad y calidad es muy importante. Si vemos habla de CP 343, propia de estos PLCs, con lo que ya sabemos el modelo que se trata. Como información extra podríamos ver de qué modelo de Firmware 3.2.23.

A partir de aquí habría que investigar si existe alguna vulnerabilidad conocida. En este caso no afecta, pero si la versión hubiera sido algo inferior, desde luego que sí. Un ejemplo de ellas, las podemos encontrar aquí:

Vulnerabilidad en módulos de comunicaciones SIEMENS.

Múltiples vulnerabilidades en módulos SIMATIC CP 343-1/CP 443-1 y CPU SIMATIC S7-300/S7-400 de Siemens

Como podemos comprobar LLDP puede ser un gran aliado en tareas de mantenimiento, puesta a punto o reducción del tiempo en caso de avería ya que simplifica todas las tareas asociadas para restaurar la operatividad. Sin embargo, surge el problema de qué hacer al publicitarse tanta información que luego, pueda hacerse un mal uso de ella. Se me ocurren varios usos, pero mejor no dar ideas.

Sin duda, desde un punto de auditoría o pentesting, LLDP será un gran recurso para una fase inicial de “Information Gathering”, pero como digo, en malas manos…

El problema aquí es que el propio protocolo PROFINET necesita de LLDP por lo que su uso debe ser permitido ya que se requiere bien para el funcionamiento como para reducir el tiempo de indisponibilidad por fallo. Cisco en alguno de sus recomendaciones deshabilitar CDP o LLDP para los equipos finales. Obviamente éstos no lo necesitar para su funcionamiento, pero en Controladores sí.

Puesto que debemos convivir con él, una de la alternativa es el bloqueo de puertos, bien de forma física como lógica.

No quiero decir con esto que gracias a LLDP nuestras redes PROFINET van a estar en peligro (que también), sino que existen protocolos que para su uso requieren de la difusión de información que aunque no queramos publicarla, debemos de hacerlo para aprovecharnos de las ventajas que éstos ofrecen en el mantenimiento, operación y garantía de disponibilidad.

¡Un saludo, nos vemos en la siguiente!

Edorta