Saltos entre redes IT y OT. Parte II
Después del último post donde hablamos sobre la respuesta temprana de detección de amenazas en entornos industriales y donde se daban recomendaciones para crear una red con más seguridad a la hora de acceder a entornos OT, volvemos con esta segunda parte.
En este post os vamos a explicar cómo desplegar esos artefactos simulando a nuestros dispositivos industriales llamados Honeypots, para aquellos que no revisaron el primer post y no conozcan esta definición damos un breve resumen:
Son sistemas que simulan a los reales donde se exponen libremente en nuestra red para que los atacantes accedan primero a estos sistemas, a los que posteriormente mandaran sus ataques para que tengamos el foco de atención puestas en ellos y hagamos una detección temprana de amenazas.
La información que se da a continuación aparece en la guía de Incibe de como desplegar un HoneyPot industrial y que podemos descargar en el siguiente enlace:
Dentro nos explican que existen varios tipos de HoneyPots y podemos seguir en el siguiente esquema:
En nuestro caso se va a desplegar virtualmente y además es con fines de investigación, donde hemos optado por crear un servidor con ciertos servicios críticos.
Vamos a mostrar los dos “más comunes”, uno de despliegue y configuración más manual como es Honeyd el cual podemos levantar todos aquellos servicios que consideremos oportunos y asemejen más a nuestros sistemas reales. Es decir, un atacante siempre va a buscar aquellos sistemas que cree que vamos a disponer en nuestra red. Es por ello, que vamos a crear réplicas de los mismos.
Si seguimos la guía de Incibe para este tipo de HoneyPots se nos detalla cómo podemos construir uno específico y que en próximos posts detallaremos con más detenimiento ya que estamos investigando en una manera automática de generar este tipo de honeypot más customizados.
Por otro lado, hemos usado para la parte práctica, otro honeypot que ya viene preparado y es más fácil de desplegar, además también tiene una buena documentación para usar. En este los servicios vienen predefinidos y simula a sistema ICS/Scada más frecuentes que sufren ataques.
En este caso, se puede desplegar fácilmente desde un contenedor de Docker, y que vamos a encontrar una guía muy detallada de las diferentes maneras de desplegarlo en el siguiente enlace:
https://conpot.readthedocs.io/en/latest/installation/quick_install.html
Si hacemos una búsqueda de puertos de estos hosts podemos encontrar que tenemos todos estos servicios habilitados y que podemos acceder a ellos.
Una vez se tienen estos sistemas levantados como comentamos en el anterior post, se tienen sistemas de registro (IDS/IPS), sondas que generan logs y también nuestros honeypots van a generar logs de lo que se accede para que luego tengamos que procesarlo para la detección de amenazas.
Por eso, debemos conocer lo que nos está guardando este tipo de sistemas de registros, y dentro de los honeypots, como son los logs que se están generando.
En el caso de honeyd, nuestro honeypot de diseño propio o custom nos da el siguiente fichero de registros la siguiente información:
- Fecha, hora, minuto y segundo en el que se ha producido la petición.
- Protocolo del paquete registrado.
- Tipo de conexión: “E” si es un cierre, “S” si es un inicio de conexión y “-“ si no pertenece a ninguna conexión.
- IP y puerto origen.
- IP y puerto destino.
- En algunos paquetes TCP que no forman parte de una conexión, Honeyd incluye el tamaño del paquete y los flags TCP.
- En ocasiones, existe una última columna con el sistema operativo de la máquina origen, obtenido mediante fingerprinting pasivo.
Para Conpot, como hemos visto anteriormente, en la consola se muestran todos los registros de acceso a los distintos servicios, donde se puede ver la hora y lo recibido por el protocolo al que hemos llamado:
Si volvemos de nuevo al esquema que enseñamos en el primer Post tenemos otro elemento importante que es el conducto por el que vamos a pasar de los entornos IT a los entornos OT, creo que debemos tener especial atención a este elemento ya que obligamos a pasar por este sistema para hacer un salto entre zonas IT y OT.
Esto nos permite aislar completamente las dos redes a través de un punto de acceso común, donde además es recomendable que tenga un 2FA para evitar posibles ataques de fuerza bruta o password spray. Existen numerosas herramientas para realizar esta máquina de salto o pasarela y en el caso que queramos herramientas open source podemos usar OpenVPN. Aunque también existen herramientas de pago como Citrix o Thinlinc que nos permite crear este portal de salto.
Si queremos usar OpenVPN con 2Fa, ya integra en su servidor un servicio conectado a Google Authenticator, una herramienta de uso seguro y sencillo para el usuario o si tenemos nuestro correo corporativo integrado con Gsuite.
Como recomendación final debemos evitar todos aquellos saltos entre zonas y que no pasen por este tipo de conducto ya que vamos a evitar siempre una posible mala gestión de accesos y por lo consiguiente vulnerabilidades de acceso.
Espero que os guste este post y seguiremos añadiendo más información a este campo tan interesante.
¡¡Hasta pronto!!
