Archivo de la etiqueta: control de aplicación

Controlando nuestros Proveedores, Parte II.

Posted on por

Hola de nuevo. Siguiendo con la entrada anterior “Controlando nuestros Proveedores, Parte I” en el día de hoy vamos a ver la manera en cómo trabaja el binomio FortiGate + FortiClient.

Si bien la protección es en tiempo real, al hacer un análisis antivirus vemos la forma en la que detecta malware según la base de firmas del fabricante. Para ver su funcionamiento he dejado en el escritorio un fichero de EICAR.

No obstante, para que no fuese un típico ejemplo, también tenía una carpeta con el software incluido en el repositorio Pengowin y que desde aquí, dicho sea de paso, recomiendo dicho proyecto.

Viendo los logs:

en total fueron 55 detecciones:

Para terminar la desinfección es posible que se solicite un reinicio del sistema.

Como se puede ver, también en el escritorio tenía el simulador del protocolo S7 de SIEMENS, Snap7 del que hablaba en la entrada “Snap7 suite de PLCs y comunicaciones Siemens”. Al ejecutar el cliente para hacer una lectura del supuesto PLC, esto es “clientdemo.exe”, como el protocolo “ICMP” y “S7 Protocol” no están permitidos vemos su bloqueo, al igual que otros relacionados con el sistema operativo.

Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.

También disponemos de un “Filtro Web”, funcionalidad que no he utilizado pero también útil si necesitamos tener acceso a una interfaz Web. ¡Ojo! Hablo de equipos locales, no accesos a Internet.

Como decía en el post anterior es compatible con los “Security Profiles” configurables en cada una de las reglas del Firewall, con lo que a nivel de red también podríamos ejercer un control adicional. Configurar los perfiles de qué se puede ejecutar, o no, en un PC puede llegar a ser complejo y laborioso en función de cada proveedor. Con lo que llegado el momento, podríamos llegar a ser más permisivos en este sentido en cuanto a consentir toda la categoría “Industrial” o “Servicios de RED” y denegar “Botnet”, “Game”, “P2P”, etc. y luego apoyarnos en reglas y “Security Profiles” como indicaba en las entradas:

También destacar la visibilidad que podemos tener desde el Fortigate a la hora de monitorizar los FortiClients conectados y de si cumplen, o no, con las políticas establecidas. Para ello deberemos ir a “Monitor – FortiClient Monitor”.

Ya por último comentar que en este caso hemos hecho uso de un Firewall Fortigate para la gestión de los endpoint. Sin embargo, Fortinet dispone de un producto específico para la gestión de este software denominada FortiClientEMS (Enterprise Management Server) con lo que podremos realizar un control centralizado y una gestión más pormenorizada de todos ellos.  Aquí os dejo un video presentación y enlaces con información al respecto.

Integración de Fortigate y FortiClientEMS.

Como hemos visto nuestros proveedores pueden ser no sólo un punto de entrada sino también el origen de un problema mucho mayor. Los habrá que sean estrictos con el uso de sus equipos sin embargo, esto no es razón para pensar que nada malo pueda suceder. Los entornos industriales no son para nada similares a los de Oficina o IT tradicionales. Los ciclos de vida son mayores con lo que la posibilidad de encontrarnos con Sistemas Operativos y Hardware viejo u obsoleto, es bastante común. Con ello, falta de soporte del fabricante y vulnerabilidades incapaces de corregir, y aun existiendo parches, según actividad de la compañía, desarrollos de software propios, o cierre, hacen que muchas veces sea inviable. A esto hay que sumar la existencia de empresas proveedoras de servicios que necesitan conectarse a nuestras instalaciones para llevar a cabo las tareas para las cuales han sido contratadas, y que no hace posible desplegar su software sobre otro equipo de la organización en el que sí tenemos control y conocimiento de su estado.

Con esta entrega hemos visto cómo con los NGFW FortiGate y endpoint FortiClient podemos llevar a cabo un control y permitir qué equipos de terceros puedan conectarse a nuestra red. De esta manera reducimos los riesgos  de que algo, o alguien, pueda comprometer la disponibilidad de nuestras instalaciones. No pretende ser un manual, ni mucho menos, sino una visión sobre de qué manera podemos ejercer dicho control y supervisión.

Obviamente existen en el mercado otros fabricantes, con otras soluciones que de igual manera puedan satisfacer nuestras necesidades, pero resulta interesante ver esta en concreto por su integración junto con el hardware de red. Como hemos visto, desde hace relativamente poco tiempo, los fabricantes de equipos de control y automatización tipo SIEMENS, Phoenix Contact, entre otros, incluyen ya características relacionadas con la Ciberseguridad, cosa con los equipos más antiguos o bien, o no disponen o son débiles. Por tanto, delegar en la electrónica de red y seguridad perimetral aspectos de la seguridad sigue siendo un hecho que durará por mucho tiempo ya que la renovación de PLCs, Robots, o cualquier otro por motivos puramente de seguridad, no es una razón de peso o prioridad.

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

Edorta

 

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

Posted on por

Hoy vamos a continuar con lo que adelantábamos en la entrada “Control de Aplicación en entornos ICS/SCADA, Parte I” poniendo algunos ejemplos sobre cómo esta funcionalidad en los NGFW puede ayudar a detectar, o prevenir, cierto tipo de actividades.

En ella proponía el siguiente entorno:

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/24 accesible desde una Workstation, 192.168.0.100/24, destinada a labores propias del entorno. Por otro lado, la red 10.10.10.0/24 donde existe 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 NGFW 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 “Firewall de Segmentación OT-OT” hemos creado el siguiente perfil “Control de Aplicación” para las comunicaciones entre el servidor SCADA  y la red de Control. Como se puede ver, se bloquearán todas las aplicaciones incluidas dentro de la categoría ”Industrial”. Sin embargo, se hará uso de “Application Overrides” para permitir sólo aquellos protocolos y operaciones propias de nuestras instalaciones. Dicho sea de paso, han tenido que ser identificadas con anterioridad. No obstante, y aunque no es necesario indicarlo explícitamente, se impedirá la parada de PLC, algo reservado sólo a nivel local, no por red.

Fortinet define varios controles sobre el tráfico. Estos son Allow, Monitor, Block y Quarantine. Para conocer las diferencias os dejo el enlace en la página Web del fabricante, pincha aquí.

Ahora bien, en “Firewall  Separación IT-OT”, no habrá excepciones de ningún tipo, absolutamente todo se bloquea. Se entiende que no debe existir ningún software que necesite acceder a la red de control y mucho menos que realice operaciones de lectura o escritura sobre variables, bloques de memoria, funciones, etc.

Respecto a las reglas de Firewall, para este laboratorio he sido bastante “laxo”. Puesto que la intención es destacar el uso de esta funcionalidad, he permitido las comunicaciones entre todas las redes y puertos, siendo el “Control de Aplicación” el único que autoriza o deniega el paso de paquetes. Como todos sabemos, no debiera ser así en un entorno real.

Como hemos dicho anteriormente una de las tareas que no pueden llevarse a cabo desde el servidor es ejecutar la orden de paro de los PLCs. Si lo haríamos, esto sería lo que ocurriría.

Como vemos se genera un log donde se refleja la aplicación identificada y la acción tomada.

Pero siguiendo con el esquema, veremos ahora lo que sucede si alguien desde el entorno de oficinas quisiera obtener alguna información. Los ejemplos siguientes se han hecho con una distribución Kali Linux y aplicaciones Plcscan y script S7-info para Nmap. 

El ambas, el resultado sería el siguiente, siendo el de Plcscan el realizado a las 19:23:34 mientas que Nmap a las 19:25:12 en adelante.

Así pues, el resultado por parte del supuesto atacante quedaría:

Como vemos los escaneos no arrojan ninguna información.  En cambio, si aplicásemos el mismo sensor de “Application Control” para las comunicaciones entre el servidor SCADA y el PLC el resultado sería bien distinto:

Como podemos ver, aquí sí se muestra información ya que las las operaciones que realizan ambas aplicaciones concuerdan con los protocolos y operaciones permitidas, al igual que el servidor SCADA. De esta manera, se podrían extraer datos sobre los equipos para luego seguir con fases más avanzadas o dirigir, somo es lógico, el ataque sobre el fabricante en cuestión.

El “Control de Aplicaciones” puede ser de gran utilidad, sino necesario. Obviamente su configuración y parametrización requiere de una labor que puede resultar costosa en tiempo ya que hay que definir claramente el tráfico que atraviesa por nuestra red. No sólo en lo que se refiere a IPs y puertos, sino también a aquellas aplicaciones que generan el tráfico de Operación, Control y Monitorización. No obstante, no debiera ser la única. Para ser más completos, además habría de acompañarlo de otras como IPS y Antivirus, funcionalidades que ya disponemos. Algo que también resultaría interesante según entornos y necesidades es la consolidación de logs en servidores, tanto para su almacenamiento (Syslog Server) como correlación (SIEM).

Ya por último un factor que no podemos olvidar es que todas estas medidas pueden introducir una latencia en las comunicaciones debido a la carga computacional que requiere el análisis en tiempo real. Según fabricantes, dispositivos y modelos puede variar con lo que dependiendo de nuestra arquitectura, comunicaciones (TCP/IP, RT o IRT), sistemas, etc. es algo que debemos tener presente en cualquiera de los casos.

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

Edorta.

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

Posted on por

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.