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

Presentación Check Point 1200R Rugged Appliance

Una de las características que presentan los entornos industriales, o aquellos donde estén presentes los sistemas de control y automatización, es lo hostil que puede ser el medio en cuanto polvo, humedad, temperatura, se refiere. Con la necesidad de tomar medidas en materia de ciberseguridad, los equipos deben de poseen una serie de características, aparte de las funcionales, que cumplan con estos requisitos de robustez, tolerancia a fallos, entre otras. Conscientes de esta situación, los fabricantes de soluciones de seguridad perimetral y redes han sacado al mercado productos para cubrir esta necesidad con más o menos gama dependiendo del fabricante. Hoy hablaremos del equipo 1200R del fabricante CheckPoint.

Como podemos comprobar posee un diseño rugerizado soportando un rango de temperatura entre -40 y 75 ºC con un índice de humedad sin condensación entre 20 y 90%. Al igual que otros, no posee un ventilador para su refrigeración, importante para aquellos espacios con gran cantidad de polvo en el ambiente. Pose un total de 6 puertos para comunicar equipos; 4 LAN, 1 WAN y 1 DMZ, pudiendo los dos últimos ser utilizados a través de módulos SFP como fibra óptica. También un puerto serie para comunicación por consola.

Tendremos la opción de alimentarlo bien por un bornero en la parte frontal o con una fuente tradicional a un enchufe a 220V por la zona posterior. Importante tener en cuenta que la que se suministra opera entre 0-40ºC lo cual supone una diferencia notable con respecto al del propio equipo.

En la zona posterior nos encontraremos con un slot para introducir una tarjeta SD-HC y ser utilizada como almacén de logs. El fabricante ofrece una de 32GB de capacidad con lo que, al menos, hasta esta cantidad estaremos cubiertos.

Cara a la instalación, tendremos la opción de colocar un soporte para carril DIN y montarlo en aquellos espacios que así lo requieran.

Sin embargo, conviene prestar atención si nuestra opción sea la de alimentarlo con la fuente de alimentación a 220 V ya que el espacio entre equipo y armario puede no ser el suficiente para el que ocupa el conector.

El equipo trae consigo la posibilidad de ser administrado tanto de forma centralizada a través de una consola de administración, o local vía web. En mi caso he elegido esta opción, para su puesta en marcha inicial. Para ello habrá que conectarse a l puerto LAN 1 e introducir la IP que viene por defecto, 192.168.1.1. Luego seguiremos el asistente para su configuración inicial.

 

 

Luego deberemos de llevar a cabo la actualización sistema y los servicios que trae consigo el propio equipo. Aquí al hacerlo a la versión de Firmware R77.20.75 como podemos apreciar la apariencia cambia.

Hasta aquí la presentación de este equipo que al igual que otros puede ser empleado para técnicas de Virtual Patching, protección de conjunto de equipos, o acceso remoto seguro. En futuras entradas veremos más del funcionamiento y cómo podremos proteger tanto nuestro entornos industriales como nuestras infraestructuras críticas.

Un abrazo!

Edorta

TAP Devices, Siemens TAP 104

Few months ago, I wrote about how port mirroring is an allied to capture and analyze network traffic. You can access to the article clicking here. There are a lot of reasons to use it, such as identify communications, troubleshooting tasks, use of IDS/IPS systems, and so on. But port mirroring is not the only one, we can use TAP devices. However, as I said several times, we must use specialized equipment for these environments, in particular industrial ones. Today I will talk about Siemens TAP 104.

Siemens TAP 104 is a hardware device that can be installed between two devices to gather a copy of data traffic on Ethernet based networks. Once the collected frames are stored, we can visualize them with a network analyzer tool to identify the information that we are looking for. The TAP device does not affect to the communication that pass through it.

Siemens TAP 104

It has four RJ-45 ports. Two to connect the segments that we want to monitor and two more to connect the systems to collect the frames. It operates in a fault-free mode even when the power is off.

One use case can be as the picture below shows. For example, we can be interested to identify issues between the HMI and the S7-1500 PLC. The traffic will be gathered by Grassmarlin tool that can be downloaded from here. I wrote about it more than a year and half. You can find the article clicking here.

Siemens TAP 104

Following the concept of the previous picture, this time, I have replicated this scenario in small testbed. In the picture below you can identify different devices, such as Fortinet Fortigate Rugged 90D, Fortinet Fortiswitch 112D-PoE, Siemens PLC S7-1200, Siemens HMI, Siemens TAP 104 and a laptop. As you can see, the TAP is just in the middle of the Fortigate switch and the PLC. Each communication from and to them, is replicated to the first RJ-45 port, where the laptop is connected and running Wireshark packet analyzer.

Testbed Lab

Testbed Lab

Once the traffic is gathered, we can open it with an analyzrer. Below we can see the information available from LLDP protocol as system description, IP management address, and so on.

LLDP Wireshark

But if we are looking for information, we can see the values of sending and receiving from and to the devices.  In the picture below you can see the field “Function: GetMultiVariables”

S7 Communication Wireshark

And then displaying the field “Response Set-ValueList”  we can see the values 84 and 16, the same that appears in the HMI.

S7 Communication Wireshark

Today, with Siemens TAP 104, we see other way to gather network traffic to identify possible issues in our industrial communications where it is mandatory not to introduce additional latencies that may affect them. In general, it is very common to do it using Port Mirroring configurations, but as we have seen, there are others. Either Port Mirroring or TAP devices, we can find them a helpful resource for different use cases such as troubleshooting, anomalies, security problems and much more. Always with specialized equipment.

That is all for now, see you next time!

Edorta

Specialised products, FortiSwitch Rugged 112-D PoE

As I said several times, the industrial communications trend to Ethernet Technology for the advantages that it provides. However, this is not similar to affirm that everything will can communicate by frames or packets. There are many scenarios where serial protocols are being used because is not possible to update to Ethernet. For example, migrate to it requires to change cabling, reconfigure devices, deploy new networking equipment, programming changes, and many other measures. But if we can, we must deploy networking devices according to these harsh environments. Today, I will show one that can be used for its capabilities, Fortinet FortiSwitch Ruuged 112D-PoE.

It has 8 GE RJ-45 ports and 4 more GE SFP slots. It can be necessary for those situations when you need to connect devices by optical fiber. It is widespread used because permits more than 100 meters, or less, and does not affect electromagnetic interferences in comparison with unshielded twisted pair Ethernet cabling. It supports fiber single mode, multimode and long haul single mode with LC connector

FortiSwitch Rugged 112D-PoE

This switch can be used to connect PLCs, HMIs, or other device that communicates by industrial based Ethernet Protocols such as PROFINET, Ethernet/IP, Modbus/TCP, and so on. It has redundant power input terminals in the range from 44 to 57V DC to give service for PoE ports if needed.

FortiSwitch Rugged 112D-PoE

There are not any fans to cool itself to prevent damages. It is so important for those dusty places where can affect the operation stopping them if it is excessive. The switch can work in a temperature range from -40 to 75º C (-40 – 167º F) and can be mounted in DIN rail or wall depending your rack or facility. Related to the atmosphere, it tolerates up to 5-95% of non-condensing humidity.

FortiSwitch Rugged 112D-PoE

As you know, the lifecycle of industrial components and systems are higher in comparison with IT world. In this way, Fortinet affirm this switch has a mean time between failures (MTBF) more than 25 years. For this, it is capable to work in OT scenarios.

When you connect to its web interface you can see the dashboard where you can identify different information.

FortiSwitch Rugged 112D-PoE Menu

As you can see on the left, you will find a menu from where you can configure different features. For example, authenticate user to a LDAP server, port mirror ports, syslog server, and so on.

FortiSwitch Rugged 112D-PoE Authenticatio

FortiSwitch Rugged 112D-PoE Port Mirror

FortiSwitch Rugged 112D-PoE Logs

It operates at Layer 2 but you can get more Layer 3 capabilities if you connect it to a Fortinet Fortigate unit. Furthermore, you can manage your Fortiswitch from Fortigate console by FortiLink protocol. You will not find all the features, but you can configure VLAN interfaces, switch on and switch off ports, enable or disable PoE, and others.

FortiSwitch Rugged 112D-PoE and Fortigate Rugged 90D

Even though Ethernet technology give us a lot of improvements not always we will be able to implement them in own facilities in particular when they are working for 24 hours a day, 7 days a week, 365 days a year. It requires a very big effort in time, knowledge and obviously, budget .

Depending the activity, availability, probably, we will only get time on Christmas, Easter Week or summer Holidays, to do everything we need. In addition to that, be sure that you meet with others employees such as maintenance technicians that they have to do tasks relative to keep on good state of operation of our infrastructures. And as you know, they have more priority.

In spite of this, either it is possible to update or deploy a new facility we need to know which are the devices available that meet the requirements that we need. In the same way, industrial and automation control system vendors have been working to deploy new products for Cybersecurity purposes; the Cybersecurity product manufactures have developed industrial networking equipment. One of them, is Fortinet FortiSwitch Rugged 112D-PoE that I have shown. All features can be found by clicking here.

Other choice to find the best solution for our needs.

See you next time!

Regards

Edorta

BACnet, fundamentos de un protocolo para la gestión de edificios

A menudo nos centramos en materia de Ciberseguridad haciendo referencia a aquellos equipos y sistemas que intervienen en los procesos productivos o entornos de control y automatización. Sin embargo, las fábricas no sólo son PLCs, HMIs, Workstations, sensores u actuadores. Dependiendo de la actividad y el tamaño, cuentan con otros elementos que también contribuyen a que se garantice la disponibilidad de la que tanto hemos hablado. Me refiero a sistemas de refrigeración, extinción de fuegos, climatización, montacargas, etc. los cuales pueden ser gestionados por medio del protocolo BACnet.

Habitualmente los vemos referenciados en los denominados “Edificios Inteligentes”, sin embargo, su uso ni es exclusivo de ellos ni es algo relativamente nuevo. La gestión de edificios viene dada por las siglas BMS, Building Management System debiéndose distinguir, entre edificios de viviendas o edificios industriales. En general, los sistemas BMS integran un conjunto de subsistemas encargados de los sistemas de control de iluminación, antincendios, alarmas, elevadores, ventilación, temperatura, etc. Si bien muchos de ellos son comunes a ambos entornos no podemos decir que son similares ya que las aplicaciones y alcance son distintos.

Ahora bien, al igual que PLCs, HMIs, y demás dispositivos, estos sistemas han de comunicarse entre sí para su propio funcionamiento y gestión. En este sentido, uno de los protocolos empleados es BACnet, Buiding Automation Control Network. Desarrollado en 1987, ha sido un ANSI e ISO estándar desde 1995 y 2003, respectivamente. Aunque su mantenimiento es continuo, el propósito de BACnet es proporcionar interoperabilidad entre sistemas y dispositivos en aplicaciones de control y automatización de edificios, mediante un protocolo de comunicaciones estándar.

Al igual que muchos otros, cada dispositivo BACNet es una combinación de hardware y software, encontrándolo como norma general en forma de controlador, pasarela o interfaz de usuario. Cada uno de ellos dispone de un identificador o número de instancia único que lo identifica y diferencia de los existentes en la red aparte de otros con información relativa a las entradas y salidas que  monitoriza y controla.

Dentro de BACnet podemos encontrar 3 conceptos claramente diferenciados, Objetos, Propiedades y Servicios.

Toda la información contenida dentro de un dispositivo BACnet es ordenada como objetos, el cual le convierte en un protocolo orientado justamente a esto mismo, a objetos. Cada Objeto” representa un componente del propio dispositivo o un conjunto de información que puede ser solicitada por otro a través de medios como Ethernet, IP, RS-485, etc.

El protocolo define un total de 54 tipos de objetos para los usos más comunes cubriendo así la mayoría de las necesidades. Sin embargo, da la posibilidad de crear otros nuevos para no interferir sobre aquellos usos más concretos o aplicaciones propietarias.

La imagen muestra la arquitectura e interoperabilidad entre los distintos elementos que definen el funcionamiento del protocolo para la gestión y automatización de edificios BACnet.

Arquitectura e inteoperabilidad en BACnet

 

Cada objeto tiene un identificador de 32 bits el cual contiene un código para el tipo de objeto y el número de instancia de dicho objeto.

Con independencia del propósito o función, cada “Objeto” posee un conjunto de “Propiedades”. Cada una de ellas contendrá dos partes, un identificador y un valor. El identificador son números que la definen de forma única en el ámbito del tipo de objeto; y el valor, la magnitud del mismo. Luego, dicha información podrá ser tanto de lectura como de y escritura.

Si unificamos ambos conceptos, podemos decir que cada “Objeto” incluyen “Propiedades” que determinan sus capacidades, operación e información asociada.

Como hemos dicho anteriormente los dispositivos interactúan entre sí para su operación. Cuando un equipo se comunica con otro para llevar a cabo una determinada acción, lo hace a través de los denominados “Servicios”. Los servicios son agrupados en 5 categorías según su funcionalidad:

  1. Object access (lectura, escritura, creación, borrado)
  2. Device management (descubrimiento, sincronización horaria, inicialización, copia de respaldo y restauración)
  3. Alarm and event (alarmas y cambios de estado)
  4. File transfer (Tendencia de datos y cambio de programa)
  5. Virtual terminal (interfaz hombre-máquina por medio de menús o similar)

Cada dispositivo envía las peticiones empleando mensajes convenientemente estructurados tanto en la pregunta como en la respuesta. Los mensajes son codificados en un stream numérico definiendo las funciones que deben llevarse a cabo.

Para que dichos mensajes puedan enviarse y recibirse, se establecen varios medios de transporte, los cuales se citan a continuación:

  1. BACnet/IP
  2. BACnet ISO 802-3 (Ethernet)
  3. BACnet MS/TP (Master-Slave/Token Passing)
  4. BACnet over ARCNET
  5. BACnet Point-to-Point (EIA-232 and Telephone)
  6. BACnet over LonTalk Foreign Frames
  7. BACnet over ZigBee

Cada uno de ellos son una combinación de capas Físicas y Enlace de Datos. Sin embargo, el mensaje BACnet es independiente del medio empleado pudiendo existir a su vez pasarelas referenciadas como “Routers” que puedan combinar cada uno de los medios. No obstante, serán los dos primeros los que reclaman más nuestra atención ya que proporcionan integración con redes tradicionales.

BACnet/IP proporciona conectividad a nivel de capa 3 pudiendo ser los equipos accesibles desde distintas redes IP. Cuando este medio es empleado con múltiples subredes, es necesario el uso de una funcionalidad especial denominada BBMD, Broadcast (Management Devices), equipo empleado para administrar los mensajes broadcast entre subredes. Éste recoge dichos mensajes y los redistribuye a otro BBMD ubicado en otra red mediante mensajes unicast.

Mientras que, BACnet ISO 802.3, similar al anterior, pero limitando las comunicaciones a nivel de capa 2.

Ahora bien, teniendo en cuenta los conceptos acerca de dispositivos, objetos propiedades, servicios y la forma en la que transmitir los mensajes, BACnet proporciona capacidades funcionales las cuales son denominadas como “Interoperability Areas”.  Existen un total de 5:

  1. Data Sharing, intercambio de información entre dispositivos. Lo mensajes pueden ser priorizados en función de su propiedad, además de ser de lectura o lectura/escritura.
  2. Trending, visualización de los valores recogidos y graficados para determinar tendencias.
  3. Scheduling, programación de tareas a ejecutar en momentos o intervalos concretos.
  4. Alarm & Event Management, intercambio de información relativo a alarmas o eventos.
  5. Device & Network Management, permite el descubrimiento de dispositivos, objetos dentro de ellos, establecimiento y reconexión en caso de caída de comunicación, sincronización horaria y reinicio.

Estas áreas están definidas dentro de BACnet como BIBB, “BACnet Interoperability Blocks”.

Puesto que BACnet es un estándar, los distintos fabricantes de equipos deben garantizar que sus productos soportan ciertos requisitos para poder operar unos con otros. Para ello, deben cumplir con lo definido en lo que se denomina “Protocol and Implementation and Conformance Statement”, PICS; una ficha técnica con distinta información y entre ella, los distintos BIBB soportados para que puedan ser comparados y garantizar su funcionamiento.

Es importarte resaltar que los mensajes pueden ser dotados de una “Prioridad” dependiendo el tipo de mensaje y la información que transporta. Se definen un total de 16, siendo las dos primeras relativas a cuestiones de “Safety”, “Manual Life-Safety” y “Automatic Life-Safety”.

Hasta aquí la presentación de los conceptos básicos de BACnet. Un protocolo con unas características específicas para entornos concretos. Como decía, es importante remarcar que su uso puede no estar necesariamente asociado a edificios de viviendas sino también a entornos industriales. Éstos también disponen de sistemas de refrigeración, sensores de humos, montacargas, etc. dependiendo, claro está, del tamaño y la actividad. Podrán almacenar productos químicos que deban ser almacenados bajo unas condiciones de temperatura determinada; entornos donde la calidad del aire deba ser única debiendo accionarse los sistemas de ventilación bajo unas circunstancias concretas; controlar la iluminación de un pabellón en distintas franjas horarias, entre otras muchas. ¿Alguien se imagina los efectos que pudiera tener si algo o alguien, pudiese alterar a las dos de la madrugada la iluminación de parte o toda una nave de producción y los operarios no pudiesen trabajar? Y peor aún, cómo o porqué se genera esa situación si no se puede acotar la causa que lo origina. No estamos hablando de un hecho con unas consecuencias graves, pero sí con impacto sobre la actividad de la propia empresa.

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

Firewalls Virtuales, por qué no en redes industriales?

Como hemos hablado en otras ocasiones la primera medida técnica para securizar las redes industriales es separar nuestros entornos de Oficinas y de Control mediante un NGFW. Con ello, conseguimos independizarlos y ceñir a cada uno de ellos el tráfico necesario. Luego, ya dentro del segundo es necesario segmentarlo en áreas funcionales más pequeñas de tal modo que si se produjese algún incidente, intencionado o no, no se propague al resto evitando así un daño mayor. Todo esto y más lo comentaba en un artículo de abril de 2016. Os dejo el enlace, pinchar aquí.

En él citaba que las mismas podrían ser física o lógica, utilizándose enlaces dedicados o configuraciones en la electrónica de red como pueden ser las tan conocidas VLAN. Sin embargo, el uso de tecnología “virtual” no es exclusivo de los switches o servidores. También la podemos emplear en Firewalls. Sí, los mismos que nos separan y segmentan dichos entornos.

En mi caso voy a tomar como ejemplo el uso que hace de esta tecnología el fabricante Fortinet.

Fortinet lo denomina como “VDOMs”, Virtual Domains. Con ella podremos crear dos o más Firewalls “lógicos” dentro de uno físico siendo cada uno de ellos totalmente independiente uno del otro. Tendrán sus propias reglas de filtrado, sus propios perfiles de seguridad, sus propios administradores, etc.

Tal es así que, aparte de los que se configuren, se creará otro de forma automática denominado “root”. Cuando todos los VDOMs son deshabilitados en cualquier unidad FortiGate, hay un VDOM que sigue activo, el “root”. Esto es así ya que debe existir un VDOM de administración entre otros aspectos, para la gestión de tráfico. Por ejemplo, cuando habilitamos la funcionalidad de VDOM toda la configuración se conserva en el VDOM “root”. A partir de ahí iremos creando otros en consecuencia. Todas las configuraciones que sean necesarias fuera de los VDOM, se realizan desde el apartado “Global”. Hablamos de las que afectan a la unidad Fortigate como dispositivo físico, esto es, la asignación de interfaces, Alta Disponibilidad, mantenimiento, etc.

Aquí os dejo un video donde se muestra tanto el concepto como una configuración básica:

Como es evidente, cada unidad FortiGate tiene recursos hardware limitados como CPU, memoria y almacenamiento. Cuando no empleamos VDOMs, este límite no supone un problema ya que todas las sesiones, usuarios y otros procesos comparten todos los recursos de forma equitativa. Sin embargo, cuando hacemos uso de ellos, podremos asignar a cada VDOM distinta cantidad, mínima y máxima, según sea necesario. Por defecto, cada VDOM no tendrá límites, con lo que un solo VDOM podría en un momento dado emplear todos los recursos en detrimento de otros VDOM.

Por ello es conveniente definir límites a este respecto. Veamos porqué.

Si bien la electrónica ha mejorado, cada vez que instalamos un equipo de seguridad perimetral introducimos una latencia, que puede aumentar tanto en cuanto se habilitan más características con el fin de mejorar la seguridad en las comunicaciones. Me refiero a servicios antivirus, IDS/IPS, Control de Aplicación, VPNs, etc. Las comunicaciones industriales no requieren unos anchos de banda como las que puede haber en entornos IT, sin embargo, las latencias experimentadas pueden ser inasumibles. Cuando hablamos en comunicaciones en tiempo real como voz o video sobre IP, podemos aceptar tiempos de hasta 150 ms. Sin embargo, en comunicaciones industriales tipo RT (Real Time) podemos hablar de hasta 10 ms o incluso en IRT (Isochronous Real Time) entre 0.25 y 1 ms. A la hora de instalar dispositivos de seguridad perimetral físicos como virtualizados, debemos tener esto presente. Más aún, en el caso de estos últimos donde compartimos recursos hardware. Si no realizamos un correcto dimensionamiento o asignación, podríamos enfrentarnos a que un Firewall virtual del entorno IT donde los anchos de banda sean mayores y exista una mayor cantidad de tráfico, requiera  recursos hardware y penalice al virtualizado en el entorno OT, donde si bien la cantidad de tráfico es menor, las latencias asumibles son mucho menores o críticas.

Como decía dentro de la Ciberseguridad Industrial, nuestro primer paso será la separación de entornos y la segmentación del de Control. Esta tecnología puede sernos de gran utilidad ya  que además de lo anterior es compatible con entornos de Alta Disponibilidad. Dos nodos físicos pueden albergar VDOMs, de tal manera que, si un Firewall cae, el otro podrá dar servicio en los VDOMs alojados en el contrario.

En la imagen que se muestra a continuación se puede ver cómo a partir de un equipo físico se han definido 3 VDOMs. Uno denominado “VDOM IT” donde tendremos nuestro Firewall Virtual encargado del filtrado de las comunicaciones entre todos los segmentos del entorno de “Oficinas”. El puerto “WAN 1”, red de servidores y del 1 al 3, subredes de clientes. Luego, el “VDOM OT”, y de forma homónima, “WAN 2”, servidores SCADA, Historians, etc. y del 4 al 6 los equipos finales como PLCs, Robots, SIS, etc. Finalmente, el “VDOM Root” el que emplearemos para la administración del equipo.

Al igual que ocurre con los Firewalls físicos podremos necesitar permitir cierto tráfico de un entorno a otro. Puesto que los Firewalls virtuales son independientes, es necesario establecer los denominados “VDOM Links”, que no son otra cosa que interfaces virtuales que comunican VDOMs. Cada “VDOM Link” posee su propio direccionamiento punto a punto, debiendo cada extremo ser asociado a uno de los VDOMs. Estas interfaces virtuales son más rápidas que las físicas, aunque dependerá tanto de la CPU como de la carga que ésta tenga fruto de las funcionalidades, perfiles, sesiones, funciones criptográficas, análisis de tráfico, etc.

En la siguiente guía podréis encontrar más información al respecto.

La idea mostrada aquí es que, si necesitamos aislar y segmentar ambos entornos, no tenemos por qué hacerlo necesariamente con equipos físicos como muestran muchos modelos y recomendaciones. No tiene por qué ser así. De igual manera que lo hacemos de forma lógica en switches con la definición de VLANs, lo podemos hacer con los Firewall, si éstos lo soportan; obviamente. Haciendo uso de esta capacidad podremos no sólo cumplir con nuestras necesidades y estrategias sino también, optimizar recursos hardware, reducir el número de equipos físicos, minimizar el espacio en nuestras instalaciones, escalabilidad, etc. Tal vez requiera de una planificación mayor, no sólo en cuanto a configuración en sí sino la administración futura.

Nuevamente las tecnologías nos ofrecen alternativas y soluciones más apropiadas, sólo tenemos que ver cuál se ajusta mejor a las necesidades de nuestros clientes para reducir los riesgos y garantizar la disponibilidad de las instalaciones. Eso si, previo estudio y planificación.

Un saludo, nos vemos en la próxima.

Edorta