Honeypot para simular redes SCADA.
viernes, octubre 22, 2010 | Author: Aldo JB Madueño
Es muy difícil recrear un honeypot de una red SCADA dado la variedad de despliegues de redes industriales y la falta de una arquitectura estándar. Otro de los factores que dificultan simular estas redes, es que utilizan muchos protocolos de red diferentes y topologías muy complejas. En SCADA HoneyNet Project podemos encontrar complementos para el honeypot Honeyd que nos permiten simular una variedad de redes industriales tales como arquitecturas de SCADA, de DCS, y de PLC. 

Con Honeyd es posible simular varios dispositivos industriales basados en IP en un mismo anfitrión como por ejemplo: un servidor de Modbus/TCP en el puerto 502 y EtherNet/IP en los puertos 44818/2222. Y de esta forma recoger datos sobre los ataques que se producen a dichos dispositivos.

Para completar este honeypot necesitamos simular conexiones serie debido a que muchos dispositivos industriales utilizan RS-232/485, es posible, utilizando el modulo programado en python llamado pySerial. De esta forma presentamos un interfaz de protocolo a un atacante que se conecte por el puerto serie.

Este honeypot no solo nos puede servir de estudio de ataques que puede sufrir una red industrial, aplicando las cualidades de Honeyd nos permite utilizarlo como técnica de camuflaje ante ataques de Fingerprinting. Ya que entre las opciones de Honeyd es posible configurar que solo responda a un rango de IP determinado o que responda en una franja horaria concreta.



SCADA Honeynet Project: Creación de Honeypots para redes industriales

Objetivos

El objetivo a corto plazo del proyecto es determinar la viabilidad de la construcción de un marco basado en software para simular una variedad de redes industriales tales como SCADA, DCS, PLC y arquitecturas. Tenemos la intención de documentar los requisitos y la prueba de liberación de código de tipo conceptual (en forma de honeyd secuencias de comandos) para que un único servidor Linux puede simular múltiples dispositivos industriales y redes de topologías complejas. Dada la variedad de implementaciones y la falta de la norma, definida por las arquitecturas y de las redes industriales, este proyecto propone crear los bloques de construcción para que los usuarios pueden simular sus redes propias redes - no hacer suposiciones acerca de lo que el "mundo real" SCADA / DCS / PLC aspecto. Suponiendo que el despliegue de "SCADA redes trampa" nunca alcanzar una masa crítica, el objetivo a más largo plazo del proyecto es recopilar información sobre los patrones de ataque general y explota específicos que podrían ser utilizados para escribir la firma con fines comerciales y de código abierto productos IDS.

Introducción

Todavía hay poca información acerca de las vulnerabilidades SCADA y ataques, a pesar de la creciente conciencia de los problemas de seguridad en las redes industriales. Como es el caso de la seguridad informática, los propietarios-operadores son a menudo reacios a liberar o incidente de datos ataque. Sin embargo, a diferencia de los productos y protocolos, hay no el tipo de repositorios públicos de los avisos de los proveedores y las vulnerabilidades en los dispositivos industriales. Aunque algunas investigaciones vulnerabilidad está siendo llevado a cabo en este ámbito, muy poco se ha lanzado públicamente y no "las herramientas de seguridad SCADA" (sea lo que podría significar) han sido liberados al público.Para hacer frente a estas limitaciones, este objetivo de este proyecto es proporcionar herramientas y para simular una variedad de redes industriales y los dispositivos. Vemos varios usos para este proyecto:
  • Construir una red trampa para los atacantes, para recopilar datos sobre las tendencias atacante y herramientas
  • Proporcionar un protocolo industrial simuladores de secuencias de comandos para probar un live implementación del protocolo real
  • medidas de investigación, tales como el endurecimiento de dispositivos, pila de ofuscación, la reducción de información de la aplicación y eficacia de los controles de acceso a la red

Requisitos de características de

Basado en nuestro conocimiento de las aplicaciones de red industrial, productos y protocolos, se identificaron los siguientes requisitos:

Simulación de dispositivos individuales

Para simular los dispositivos individuales, las siguientes funciones es necesario:
  • nivel de pila: Para simular la pila TCP / IP de un dispositivo basado en dispositivo Ethernet a un atacante para niños de tipo script que está escaneando la red con herramientas de detección de sistema operativo como Nmap y Xprobe.
  • nivel de Protocolo: Para la simulación de protocolos industriales para los atacantes calificados que cuenten con las herramientas que los protocolos de interrogar y quieren hacer algo significativo con el protocolo de características
  • Nivel de aplicación: Para la simulación de diferentes aplicaciones en un dispositivo de SCADA, tales como servidores web y aplicaciones de gestión tales como SNMP y Telnet.
  • nivel de hardware: Muchos de los dispositivos SCADA utilizar interfaces en serie, como módems y RS232 para la comunicación de protocolo de SCADA y con fines de gestión. Un atacante que, o bien "se registra en" un dispositivo de SCADA o tiene acceso a la red de serie, es necesario presentar con un dispositivo de serie y / o un protocolo de comunicación sobre un dispositivo de serie.

Simulación de redes

Tenemos que simular los puntos de entrada diferentes para que cuando un atacante se encuentra con un dispositivo perimetral, que se presentará la misma red que una verdadera red SCADA en ese punto de la red de entrada particular, 
Varios puntos de acceso de red que tenemos que simular incluyen:
  1. Un router directamente conectado a Internet: sistema de redes de control son por lo general no directamente conne una red de control se encuentra dentro de una red corporativa. Suponiendo que la red corporativa como en Internet, tenemos que simular el punto de entrada de un router que separa la red de control y la red corporativa. Los dispositivos que normalmente se conectan a los routers como sería switches Ethernet industriales o de dispositivos industriales con una pila IP, tales como algunos IP activado PLC y puntos de acceso inalámbricos.
  2. de serie del dispositivo directo: Algunos de los dispositivos industriales tiene un módem que puede ser directamente de marcado en la red pública. Tenemos que simular un "servidor de módem" que puede tomar conexiones y se comporta como un dispositivo industrial o está conectado a un dispositivo industrial.
  3. Un dispositivo habilitado para Ethernet industrial directamente conectado a Internet: Este escenario debe ser la misma que la simulación de la pila, los protocolos y aplicaciones en el dispositivo y la conexión a Internet que
  4. Una serie de puerta de enlace Ethernet está conectado directamente a Internet: Ethernet de serie una puerta de enlace es un puente entre la red IP y la interfaz en serie. El lado IP del dispositivo estaría conectado a la red, ya sea un interruptor industrial o un router para que otros industriales dispositivos IP están conectados. El equipo de serie del dispositivo estaría conectado a un dispositivo serial o una red de serie.
  5. Inalámbrica: Wireless es uno de los puntos de entrada en una red industrial. La mayoría de los dispositivos inalámbricos para uso industrial, propiedad de protocolos inalámbricos y algunos de ellos el uso estándar 802.1b. Normalmente la interfaz de serie del dispositivo que se conecta a un puente inalámbrico.
  6. Acceso remoto de escritorio y HMI: La máquina de Interfaces Humanos y el software que se comunica con dispositivos industriales que generalmente se ejecuta en una máquina Windows. Los administradores que desean tener acceso remoto a estos dispositivos normalmente sería un visor de escritorio remoto, como VNC o PC en cualquier lugar. Un atacante normalmente se encuentra a través de un escaneo de puertos "después de que él se mete en la red de control y podría llegar a ella mediante un cliente VNC. Simulación de esto probablemente necesitaría un encargo del protocolo VNC simulación.
  7. Servidor de acceso remoto (RAS): Otro posible punto de entrada en una red de control es marcar en la red a través de PPP y el uso de la contraseña PPP para autenticarse en un servidor de acceso de red y luego acceder directamente al dispositivo industrial.

Captura de las herramientas atacante y las pistas

Nuestra necesidad de capturar secuencias de comandos de las herramientas atacante y las pistas. Que debe incluir registro de pulsaciones y las instalaciones para captar las herramientas y los binarios que podría ser hasta de carga, si el ataque. Nuestros guiones también tienen que capturar el tráfico de red.

Examen de las tecnologías existentes y relavency


Honeyd

Honeyd cuenta con instalaciones para la simulación fácil de pilas TCP / IP y aplicaciones. 
Honeynet se Nmap y firmas Xprobe a través de los archivos de configuración de paquetes y envía las respuestas a las exploraciones correspondientes a las firmas. Los usuarios pueden configurar los perfiles, asignación de direcciones IP que Honeyd debe responder a un perfil de dispositivo correspondiente. Cuando los atacantes Nmap o Xprobe escanear la dirección IP que Honeyd está cuidando, le será devuelto con paquetes que coincidan con el perfil del dispositivo correspondiente.Por lo tanto el uso Honeyd, sería posible simular simultáneamente múltiples pilas de base industrial dispositivos IP, siempre que la herramientas de análisis correspondiente (Nmap o Xprobe) tiene el conocimiento de la firma. A partir de ahora, no hay firmas de dispositivos industriales en la base de datos de Nmap. 
Honeyd permite al usuario escuchar en un puerto y ejecutar un script en ese puerto en particular cuando alguien se conecta a ese puerto. A partir de ahora, hay muchos guiones han contribuido al proyecto, que puede simular las páginas web, servidores de telnet WSFTP y servidores de Cisco.
Usando esta característica en Honeyd, es posible escribir secuencias de comandos que simula diferentes protocolos de Ethernet Industrial.Por ejemplo, sería posible simular una Modbus / servidor TCP en el puerto 502 y EtherNet / IP en los puertos 44818/2222.

simulación de interfaz de serie

Muchos dispositivos de red para uso industrial RS-232/485 para la comunicación. Normalmente, el puerto serie de un PC sería directamente (o indirectamente, a través de una puerta de enlace Ethernet de serie) conectado al puerto serie del dispositivo. Habría un software que se ejecuta en el PC, que envía comandos al dispositivo a través de la interfaz en serie. Según algunas versiones hay cientos de protocolos de serie en uso en las redes de SCADA. Algunos de los protocolos más comunes son MODBUS y DNP.Tenemos que simular los protocolos a través del puerto serie, con el fin de presentar una interfaz de protocolo de un atacante que se conecta al puerto serie. Muchos lenguajes de apoyo a la programación de interfaz de serie incluyendo Python y Java. Hemos sido capaces de lograr una comunicación serie a través de un módulo de código abierto de programación Python serie (pyserial.sf.net).

Simulación de 802,11

El controlador HostAP (http://hostap.epitest.fi/), las respuestas para los paquetes de gestión 802.1b y convierte un adaptador de cliente de un punto de acceso. El conductor puede ser utilizado para simular un punto de acceso que está dentro de un sistema de automatización o de una red SCADA

La captura de herramientas de ataque y la captura de la pista de los atacantes

Aunque no forma parte de Honeyd, hay un montón de capturadores de teclado disponibles. Necesitamos un mecanismo para el seguimiento del atacante en la interfaz web del dispositivo. No sabemos de ninguna herramienta que puede proporcionar esa funcionalidad, sin embargo hemos explorado algunas posibilidades que el applet de Java (que se ejecutan en los atacantes "navegador web") es capaz de com

Retos


Implementación y pruebas

Un sitio ideal para la implementación de una secuencia de comandos sería un primer plano de subred a una verdadera Industrial / red SCADA o un número de teléfono perteneciente a un SCADA / planta de automatización.

SCADA Honeynet 
PLC Conceptos de simulación, diseño, e implementación

antecedentes

Controladores Lógicos Programables (PLC) son comunes en algunas aplicaciones industriales (especialmente de manufactura discreta) y tienen cada vez más interfaces de red que soporte Ethernet y TCP / IP, así como interfaces de comunicación más tradicionales, tales como Modbus, DeviceNet, ContrlNet, Foundation Fieldbus, etcComo es el caso con cualquier dispositivo de red, proveedores de diferentes aplicar sus propias conchas de telnet y soporte varios comandos FTP, dependiendo de sus necesidades de aplicación. El módulo de comunicación Ethernet del PLC normalmente se ejecuta un sistema operativo integrado que incluye el protocolo de red estándar, así como las implementaciones de protocolos de red industriales, tales como Modbus / TCP o EtherNet / IP. Por ejemplo, telnet y servidores FTP son comunes y tienen información de identificación que se puede utilizar para determinar el proveedor y la versión del software. Incluso en el lado protocolo industrial, vimos que no todos los PLCs de apoyo todos los comandos de un protocolo industrial dado, por lo que las implementaciones pueden ser las huellas digitales. Dependiendo del tipo (y capacidades) del dispositivo puede haber ligeras diferencias en el protocolo.
Todas estas características hacen posible que los atacantes para identificar versiones específicas y vendedores de dispositivos y nos permite ser capaces de simular los dispositivos también.

La aplicación del Enfoque

Seguimos el siguiente enfoque al simular un PLC:
  • Poner en práctica las características genéricas para que los usuarios pueden fácilmente cambiar, agregar nuevas características y re-presentar a

  • La puesta en práctica característica debe ser para que el código servirá como ejemplo para que los usuarios que cambian de acuerdo a sus propias necesidades.

  • Una vez que los usuarios envíen el código suficiente para implementaciones más, visualizamos a su puesta en plantillas de modo que un motor genérico puede configurar la carga de acuerdo a una configuración definida

  • Componentes necesarios

    Los siguientes son los componentes de la red en un PLC que deben ser simulados:
  • La pila TCP / IP del PLC

  • La simulación de la Modbus / TCP implementación del servidor.

  • La simulación del servidor FTP, que se encuentra en algunos PLCs.

  • La simulación del servidor telnetd, que se pueden encontrar en algunos PLCs.

  • La simulación del servidor HTTP de gestión, que cada vez más común en el PLC y otros dispositivos de red industrial.

  • Tenga en cuenta que las secuencias de comandos anteriores se pueden utilizar junto con independiente y la necesidad de permisos de la raíz o honeyd porque tienen que obligarse a los puertos previleged por debajo de 1024.

    Simulación de la pila TCP / IP del módulo de comunicación PLC

    Para que Honeyd para simular la pila TCP / IP de un PLC, añadiendo el protocolo TCP / IP de la firma del dispositivo a la honeyd denmap.prints archivo sería suficiente. Pero en oder para el atacante a sentir que la pila es un autómata de pila, la firma tiene que estar en la base de datos de la herramienta de análisis que se está utilizando. Aunque hemos probado que al poner la firma en nmap-os-huellas digitales de archivo (que es la base de datos de huellas dactilares de Nmap), no sabemos de ningún escáner que tiene la firma de cualquier PLC en el momento de escribir este documento.

    Simulación de la Modbus / TCP servidor

    El PLC puede tener múltiples implementaciones del protocolo industrial que va a escuchar en sus puertos correspondientes para los paquetes de los clientes correspondientes.Decidimos simular el Modbus / TCP como servidor de una prueba de concepto ya que el protocolo es muy sencillo. ModbusSrvr.py comienza con escuchar () método, que une el puerto 502 y espera a que las conexiones de cliente. Una vez que un cliente se conecta a ella, se inicia un hilo de servir al cliente y sigue escuchando en el puerto para conexiones de cliente adicional. El subproceso llama a la ProcessData () método que extrae la parte superior Modbus los datos de cabecera y llama al método SendResponse () para enviar la respuesta correcta.
    En el protocolo MODBUS, la respuesta depende del código de la función de la consulta. Puesto que no somos los expertos del protocolo y no necesariamente esperar a los usuarios y desarrolladores de red trampa SCADA para ser expertos en protocolos industriales, seguimos y recomendar el enfoque de crudo de observar y analizar los paquetes de comunicación entre algunos clientes y el PLC. Con base en la observación y el análisis se optó por aplicar las "respuestas de arriba" y para enviar un "código de error" para el resto de las consultas. Las siguientes son las observaciones:
    • Hay dos tipos de consultas utiliza en gran medida, la escribe y lee, y el objetivo puede ser bobinas o de los registros.
    • Para las respuestas a las solicitudes de lectura, la respuesta sería la de devolver los datos, lo que equivale al número de bits se pide en la solicitud de lectura. Si su lectura a varios objetivos, a continuación, por lo general dan múltiples cabeceras modbus.
    • Para las respuestas a las solicitudes de escritura, le dará el bit / byte / palabra c uente de los datos por escrito
    Implementamos las respuestas a read_coil (código de función 1), escribir múltiples registros (código de función 16), diagnóstico (código de función 8 y la respuesta de excepción con el código 1 (código de función desconocida). Damos la bienvenida a los usuarios para estudiar y analizar las respuestas de otros y ponerlas en práctica. La secuencia de comandos se puede encontrar en plc / modbusSrvr.py archivo. También incluimos nuestro archivo de prueba, modbusScanner.py, para enviar paquetes Modbus para la aplicación modbussrvr.py. Los usuarios de forma manual debe ir en modbusScanner.py y puede que editar los valores de las diferentes cabeceras de modbus.

    Simulación del servidor FTP

    honeyd ha depósito FTP basados en la simulación, la escritura, decidimos volver a escribir en él, ya que Python es un lenguaje y más fácil para los que queremos agregar más funcionalidad a la misma. El Implementamos los siguientes comandos:
  • El usuario de mando, cuando el usuario da un nombre de usuario

  • La contraseña de mando, cuando el usuario da la contraseña

  • La lista de comandos, cuando el usuario da un comando ls

  • El sist de comandos, lo que da al usuario información sobre el sistema

  • El puerto de transferencia de datos para varios comandos

  • Cuenta con varios puntos donde se escribe la información en el archivo de registro y el usuario tiene que cambiar a la habitación que sus propias necesidades con sólo invocar el método writelog y pasándole la cadena a escribir. El methos writelog abre "/ var / log / scadahoneynet.log" y añade información para de forma predeterminada. El usuario debe cambiar las respuestas dadas como variables dadas en la parte superior (como ListCommandResponse CommandResponse Syst el archivo que las suites de sus necesidades . La secuencia de comandos se puede encontrar en plc / VxWorks-ftpd.py

    Simulación del servidor Telnet

    Decidimos escribir un guión telnetd específica porque la mayoría de los PLCs de ejecución de sistemas integrados y la cáscara tiene un conjunto único de comandos. Implementamos ayuda y ls y comandos cwd y el usuario obtiene la lista de comandos cuando él sólo golpea a cambio. La secuencia de comandos se pueden encontrar en plc / VxWorks-telnetd.py

    Simulación del servidor Web

    Con frecuencia, el usuario se conecta al servidor web del dispositivo y un applet de Java se descarga en el cliente y se ejecuta dentro del navegador web. En algunos casos, el applet que hacer la conexión de vuelta al PLC a través de protocolos como Modbus / TCP y FTP para la recopilación de datos. El concepto de un applet de seguimiento de la información de la descarga es nuevo en el mundo Honeynet, los llamamos "Miel Applet ". El problema con los applets es que no se les permite comunicarse con todos los hosts de otros entonces el host que sirve el applet (http://java.sun.com/sfaq/). Así que asegúrese de que tiene la variable hosIP como el suyo el nombre de host tof exacta. Dado que cada PLC tiene sus propias interfaces de usuario, una vez más nuestro diseño y los objetivos de la aplicación son suficientes para escribir una prueba de concepto genérico que afecta a la mayoría de las características de los applets de PLC. Se utilizó clases Java Swing para dibujar el applet y se usa Java de SUN 1.4.2 para el desarrollo.
  • El botón, y cuentan con el seguimiento de clics botón

  • El campo de texto, y disponen además de un seguimiento y eliminación de texto

  • Para conectar de nuevo a un host en el puerto 502 y dar información de nuevo. el usuario puede ejecutar netcat como oyente TCP para recuperar los datos desde el applet.

  • El connectBack () se conectará de nuevo a la IP estática descritos en el código, codificado en la variable, de acogida. Llamamos a conectarse de nuevo cuando el botón se pulsa CA o cuando la prueba se cambia en TransmittButton con fines de demostración

  • El uso de las discusiones y vuelva a pintar con los números de cambio en los campos de texto

  • La secuencia de comandos se puede encontrar en plc / StatusApplet.java Tiene que ser debatido si el applet puede ser sustituido por un script PHP y lo mucho que un atacante conocer si se tratara de un script PHP

     pySerial escrito en python de simulación de RS-232/485




    This entry was posted on viernes, octubre 22, 2010 and is filed under . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.