Parches y Virtual Patching

Anuncios

A estas alturas todos tenemos claro que una de las medidas a aplicar dentro de nuestras políticas de seguridad es tener actualizados los sistemas y equipos de red. Esto lo podemos conseguir instalando parches para sistemas operativos, actualización de aplicaciones y versiones de firmware. Esto creo, que a nadie nos pilla por sorpresa.

Quizás uno de los puntos más críticos de las opciones planteadas es aplicar los últimos parches emitidos por el fabricante o los desarrolladores. La instalación de los mismos no debería provocar que nada dejase de funcionar, sin embargo este riesgo no es cero y puede suceder.

En entornos industriales, se emplean PCs para la interacción, configuración y gobierno de la maquinaria, robots y demás sistemas de control y automatización. Como he hablado en otras ocasiones aquí la premisa es la disponibilidad de las instalaciones, y por tanto, las posibles causas que puedan provocar una interrupción del servicio deben quedar reducidas al máximo. Para ello es necesario, o al menos conveniente, tener un entorno de laboratorio para el testeo de parches, ver su comportamiento y una vez comprobada la ausencia de anomalías, proceder a su despliegue siempre de forma progresiva.

Así pues se nos plantean 3 posibles casuísticas:

Hasta ahora hemos contemplado que el parcheo se puede llevar a cabo, sin embargo esto no siempre es así. Imaginemos que adquirimos un equipamiento a un proveedor. Éste garantizará su funcionamiento en esas condiciones, no en cambio, si sobre ella se realiza algún tipo de instalación de parches o software adicional. Seguramente será posible la contratación de un soporte de mantenimiento pero a cambio, posiblemente, de una muy considerable cantidad económica. Así pues el escenario, muy probablemente, será no parchear. Con lo que ello conlleva, claro.

Como segundo caso, debemos recordar que una de las características de los equipos industriales es su ciclo de vida prolongado. Éste es muy superior a los dispositivos IT convencionales, sin embargo no dejan de pertenecer a este ámbito por muy PCs industriales que sean. Llevan en sus entrañas Windows 2000, XP, 7, etc. Eso por no citar a NT que aún los sigo viendo. Estas versiones hasta XP, están fuera de soporte, aunque su uso sigue y seguirá vigente por varios años más. Y en estos casos, ¿cómo parcheamos si no tenemos soporte?

Finalmente podría darse que bien por su criticidad o por su delicadeza, no nos atrevamos a “meter mano” a este equipo que lleva sin tocarse 3, 4, 5 o más años. No nos podemos arriesgar a que surja algún inconveniente y no sepamos resolverlo. Y claro, ¿qué hacemos entonces? ¿Asumimos los riesgos? ¿O no?

En cualquier caso, la no actualización de nuestros equipos conlleva un riesgo. Quedan expuestos a una mayor probabilidad que un ataque, intrusión o actividad de malware, tenga éxito. Los entornos industriales, hasta hace relativamente poco, eran redes que permanecían aisladas del resto y su acceso era muy limitado. Con la integración en redes Ethernet, funcionalidades basadas en TCP/IP y la aparición del IIoT, esta exposición está siendo mayor y por tanto a los riesgos han aumentado.

Claro y ¿qué hacer entonces? Buena pregunta.

Pues bien, una de las opciones viene de la mano del Parcheo Virtual o Virtual Patching.

¿Qué esto de Virtual Patching? Podríamos definirlo como la política de seguridad destinada a prevenir la explotación de una vulnerabilidad mediante el análisis del tráfico, sometiéndolo a distintas capas de seguridad con el fin de evitar que código malicioso alcance la aplicación o sistema vulnerable. Esto es, el “ataque” se bloquea antes de que llegue al objetivo. Dichas capas vienen dadas por motores Cortafuegos, Antivirus, IDS/IPS, Control de Aplicaciones y Filtrado de Tráfico Web.

Como viene siendo habitual no voy a referirme a los entornos IT, sino a los industriales. Ya en la entrada anterior “Convertidores de medios” hablaba de la necesidad de utilizar dispositivos diseñados y pensados para ese fin, y la de hoy no es para menos.

Un ejemplo lo encontramos en el Fortinet Fortigate Rugged 60D, cuyas especificaciones las podéis encontrar aqui. Y su Quick Start Guide aqui. 

Este equipo es lo que podemos denominar UTM (Unified Threat Management) pero orientado a entornos industriales.

Como podemos ver, ya con su aspecto, las diferencias con los dispositivos tradicionales IT son bastante evidentes, el diseño ruguerizado lo delata. Otra de ellas es la implementación de protocolos industriales como Modbus, Profinet, OPC, DNP3, etc. Luego sobre ellos podemos aplicar las firmas de Control de Aplicación e IPS.

Por otra parte tendremos la posibilidad de instalación sobre carriles DIN, un modo de instalación de equipos industriales en armarios destinados a tal fin. Igual modo la alimentación eléctrica, por medio de borneros pudiendo emplear además la fuente de alimentación convencional que trae consigo.

En adición a lo anterior, podremos ver que la temperatura operacional va de -20 a 70 º C. ¿os imagináis las temperaturas más bajas y altas en un entorno IT convencional? Ufff qué frío y que calor…

Para su configuración inicial, nos descargaremos el software Fortiexplorer. Luego con el cable USB que viene de serie, conectaremos nuestro PC con el dispositivo.

Allí podremos acceder al Dashboard donde asignaremos algunos parámetros básicos y visualización de cierta información.

Luego dentro del apartado “Config -> Features”, definiremos aquellas características que queramos activar.

A destacar su modo de funcionamiento denominado “Transparente”. Es modo convierte al dispostivo como un Firewall pero a nivel de Capa 2. No es necesario realizar ningún cambio en el direccionamiento IP del equipo a proteger. Sólo bastaría asignar una IP de gestión del mismo rango que éste.

En “Security Profiles” definiremos los perfiles de configuración para los motores Antivirus, Filtrado Web, Control de Aplicación e IPS, en base a firmas y reglas.

En cada uno de ellos podremos definir si en caso de detectar comportamientos coincidentes con cada motor, entre “Block” y “Monitor”. Esto es, tomar una medida y bloquearla; o bien dejarla pasar, monitorizarla, registrando el evento como un log. Para ello deberemos indicar el servidor dónde enviar los datos. Fortinet tiene las herramientas propietarias FotiManager para una administración centralizada de dispositivos y FortiAnalyzer, para el análisis del tráfico y logs.

El dispositivo tiene otras muchos parámetros y funcionalidades a las que podríamos dedicar horas y horas. No obstante en el futuro, espero poder subir alguna más. Todo depende del tiempo disponible.

Por ahora ya hemos terminado con esta, y como siempre, os pido que dejéis vuestra opinión a modo de comentario de lo que os ha parecido, tanto si os ha resultado, o no, interesante, o cualquier otro crítica constructiva.

Lo dicho, muchas gracias, nos vemos en la siguiente!!

 

Convertidores de medios

Anuncios

Cuando hablamos de redes seguramente uno de los temas que primero nos viene a la cabeza es la electrónica de red. Pensamos en switches, routers, firewalls, etc. y en toda su gama de fabricantes, modelos y características. Dentro del mundo industrial uno de los factores más determinantes, es la latencia que introducen estos equipos dentro de las comunicaciones. En entornos IT ésta puede ser asumible dentro de unos valores razonables, a excepción de tecnologías en tiempo real como la trasmisión de Voz sobre IP o Vídeo sobre IP.

Sin embargo en las comunicaciones industriales esto no es aceptable. Éstas a la vez que rápidas deben ser precisas. A esta característica se le denomina “determinismo”, esto es, la capacidad de determinar cuánto es el tiempo que tardará la comunicación en transferir los eventos generados y que éstos sean atendidos. Se establecen tres categorías:

  • IRT, Tiempo Real Isócrono. Comunicaciones a muy alta velocidad. Jitter admisible de 0.25 a 1ms.
  • RT, Tiempo Real. Comunicaciones a alta velocidad. Jitter admisible 10 ms
  • TCP/IP, Comunicaciones estándar. Jitter admisible 100 ms

En cualquier caso, tanto en comunicaciones tradicionales, como industriales, se precisa de un medio de transmisión, tanto cableado como inalámbrico. En este último no hay mucha opción, es el aire sí o sí, pero dentro de los cableados tendremos varias opciones.

Dentro de las redes IT lo más normal es encontrarnos con cableado de par trenzado tipo UTP. Dependiendo del uso, y la antigüedad de la instalación, podremos toparnos con distintas categorías. Por ejemplo, para conectar un PC o una impresora con uno de Categoría 5 o 5e, nos valdría pero si lo que queremos es conectar un servidor, indudablemente deberemos irnos a uno de Categoría 6. Lo ideal sería disponer de al menos de Categoría 5e o incluso 6 ya que cubriríamos tanto velocidades de 100 Mbps como 1 Gbps, pero como digo esto no siempre es así.

Sin embargo en entornos industriales, OT, el cableado UTP es desplazado en muchas ocasiones por fibra óptica ya que ésta posee mejores características.

Una de ellas es la distancia. Con el cableado UTP estamos limitados a 100 metros mientras que con fibra óptica podremos aumentar a varios cientos o incluso kilómetros. No digo que vayamos a hacer tiradas excesivamente largas pero si las instalaciones son grandes es muy fácil superar estos 100 metros.

Otros de los beneficios es su inmunidad frente a radiaciones electromagnéticas. Dependiendo de la actividad, en entornos industriales es probable la existencia de este tipo de interferencias generadas por la maquinaria, componentes, proximidad de líneas eléctricas, etc. y que, en el caso, de cableado UTP puede afectar a las señales que viajan en ellos. Es cierto que el par de cobre tiene su versión “apantallada” que suele ser más costoso y difícil de manipular. Aparte, ese apantallamiento puede darnos más de un dolor de cabeza ya que si los conectores o conexiones no están bien hechos, podría no derivar las interferencias e inducirlas a los pares de par trenzado. Más información aqui.

Otro beneficio, es que la fibra óptica es sustancialmente más ligera y ocupa menos espacio por canaletas y bandejas por donde haya que hacer las tiradas.

Si bien tanto la fibra y cobre soportan anchos de banda comúnmente utilizados como,  100 Mbps y 1 Gbps; la fibra posee un mejor comportamiento a frente a tasas de transferencia mayores.

Sin embargo no todo son ventajas. Por ejemplo, son más delicadas que el cobre. Si los radios de curvatura se superan, el núcleo de nylon o fibra de vidrio puede romperse o deteriorarse y el haz de luz dispersarse. Por otro lado, un punto crítico también son los conectores. Éstos deben realizarse con una mayor precisión ya que cualquier mínima desviación en la alineación de los núcleos puede provocar pérdidas en la señal al igual que cualquier impureza como polvo o suciedad. Así pues resulta se escrupuloso con la limpieza empleando alcohol isopropílico para tal fin. Sobre cómo hacerlo pincha aqui.

Sin embargo no todos los equipos finales poseen conexiones de fibra, o por otra razón conviene hacerlo en cobre. ¿Qué hacer en estos casos? Instalar un convertidor medios. A veces, y según instalaciones, la instalación de un switch para la interconexión de varios equipos también nos puede hacer esta función.

Sin embargo conviene recalcar que aunque los haya convencionales, es decir, para entornos de oficina, si el uso va a ser industrial deberemos utilizar los diseñados a este respecto.

Más allá que puedan ser montados sobre carril DIN y que el armario nos quede bien ordenado, poseen características mejoradas para ello.

Una es la temperatura de operación. Si comparamos por ejemplo uno de la firma Microsens de uso genérico como este:

Vemos que su temperatura de operación oscila:

Sin embargo si lo comparamos con uno de diseño específico industrial, como este:

Aquí los valores son los siguientes:

Otra característica es su valor IP, que en el caso del industrial es de IP 30. En el primero de los convertidores no consta.

Otras de las diferencias es la manera de que se alimentan. En los industriales dispondremos de un bornero para conectarlo a las líneas de alimentación del armario eléctrico en lugar de un conector tradicional. Aunque también podremos conectarle una fuente de alimentación como veréis más adelante.

En cualquiera de los casos lo que se pretende demostrar aquí es que aunque disponemos de dispositivos que aunque no sean específicos para entornos industriales, nos pueden valer para tal propósito, no están preparados para las condiciones que existen en éstos. Esto es, rango de temperaturas, consumo eléctrico, protección contra polvo, estanqueidad, etc.

A continuación dejo algunos enlaces con más productos similares de otros fabricantes.

Siemens 01

Siemens 02

Microsens

Allied Telesis

Phoenix Contact

Belden

Korenix

Sobre este último, os dejo algunas fotos del modelo Jetcon 1301.

Y como siempre digo, si te ha parecido interesante, lo has encontrado de tu interés o quieres dejar una crítica constructiva, te agradezco dejes tu comentario.

Nos vemos en la siguiente!

Protegiendo STP, Parte II

Anuncios

Seguimos con STP. En esta ocasión vamos a ver algunos comandos sobre STP que nos van permitir evitar posibles ataques a este protocolo y que vimos en la “Parte I”.La primera de ella es proteger el switch que va a ejercer como “Root Bridge”. Esto es, si le llegase una BPDU con indicando que existe otro switch con una prioridad menor (bien porque se conecta uno o porque se generan mediante un software como Yersinia) no la considere, lo descarte. Se aplica sobre la interfaz que lo une a otros switches. En nuestro ejemplo se aplicaría sobre la Fa 1/0 en el “SW-CORE-01”.

SW-CORE-01(config-if)# spanning-tree guard root 

Otra de las configuraciones a realizar es activar la opción “BPDU Guard”. Este parámetro configurado en los puertos de los switches de acceso provocará que el puerto se deshabilite al recibir una BPDU. A diferencia del anterior, este comando habría que ejecutarlo en los switches de acceso, sonde se conectan los equipos finales ya que en caso de añadir un switch legítimo podrían no detectarse los bucles en la red y por tanto STP no ser efectivo

SW-OFICINAS-01(config-if) # spanning-tree bpduguard enable 

Igualmente, podríamos conseguir que el switch no envíe BPDUs sobre puertos donde tengamos un equipo final, ya que estamos seguros de que no es necesario enviar información de STP. ¿Para qué mandar información que no es necesaria?

SW-OFICINAS-01(config-if) # spanning-tree bpdufilter enable 

STP nos ofrece otras muchas configuraciones también de utilidad. Quizás no tanto con la seguirdad pero só con la funcionalidad. Por ejemplo, podríamos ser capaces de que un switch sea el “Root Bridge” y otro sea un “Backup” de éste. En el nuestro esto sería:

SW-CORE-01(config) # spannig-tree vlan 10 root primary

SW-CORE-02(config) # spannig-tree vlan 10 root secondary

¿Qué quiere decir esto? Para VLAN 10, el switch “SW-CORE-01” el será el root bridge. Si éste cae, el “SW-CORE-02” será el “Root Bridge”. ¿Cómo se consigue esto? Ambos switches modificarán sus prioridades para que el “SW-CORE-01” sea el primario y el “SW-CORE-02” el “Backup” en un funcionamiento normal.

Existen más comandos que permiten modificar y optimizar los valores que STP tiene por defecto, pero no entraremos en ellos ya no es el objetivo de esta entrada. Por ahora lo dejamos así.

Un saludo, seguiremos informando…