Prototipo de Firewall para redes Scada - … · Web viewLas maquinas virtuales Linux, cumplirán...

DISEÑO DE UN PROTOTIPO QUE PERMITA EVALUAR LA VIABILIDAD DE UN FIREWALL EN REDES SCADA

JONNY ALEXANDER LÓPEZ SANDOVAL

FUNDACIÓN UNIVERSITARIA KONRAD LORENZFACULTAD DE MATEMATICA E INGENIERIA

INGENIERIA DE SISTEMASBOGOTA

2010

DISEÑO DE UN PROTOTIPO QUE PERMITA EVALUAR LA VIABILIDAD DE UN FIREWALL EN REDES SCADA

JONNY ALEXANDER LÓPEZ SANDOVAL

Trabajo de grado para optar por el Título de Ingeniero de Sistemas

Director del ProyectoGUSTAVO ADOLFO HERAZO PEREZ

Ingeniero de Sistemas

FUNDACION UNIVERSITARIA KONRAD LORENZFACULTAD DE INGENIERIA DE SISTEMAS

BOGOTA D.C.2010

2

Nota De Aceptación

___________________________

___________________________

___________________________

___________________________

___________________________Presidente Del Jurado

___________________________Jurado

___________________________Jurado

Bogotá, 09 de diciembre de 2010

Dedico este trabajo a todas aquellas personas que de una u otra manera han estado a mi lado en cada una de las etapas de este proceso, sin embargo quiero hacer una dedicación especial a mi madre que con su temple, constancia y disciplina, es un ejemplo permanente no sólo para mí como hijo suyo, sino para todos y cada uno de los integrantes de mi familia. Todos, siempre dispuestos a brindarme su apoyo incondicional.

Jonny Alexander López Sandoval

AGRADECIMIENTOS

El agradecimiento más importante se lo debo a Dios por bendecirme de tantas formas diferentes, permitiéndome pagar mis estudios de educación superior con el fruto de mi trabajo, bendiciéndome con una familia y una compañera excepcional y finalmente contando con aquellos amigos que siempre me alentaron a seguir adelante a pesar de los tropiezos que tiene estudiar y trabajar simultáneamente.

El proyecto de grado que presento a continuación ha sido construido con el imprescindible apoyo y supervisión de mi director de proyecto, el Ingeniero Gustavo Adolfo Herazo; a quien por supuesto le debo gratitud por orientarme y contribuir en mi formación profesional.

Finalmente, en último lugar pero no menos importante, extiendo un fuerte agradecimiento a todo el personal docente, académico, administrativo y operativo de la Fundación Universitaria Konrad Lorenz, por su continua colaboración, por su amor por la academia y por acogerme en la institución en este tiempo.

CONTENIDO

Pág.

LISTA DE TABLAS................................................................................................VILISTA DE FIGURAS.............................................................................................VIIGLOSARIO...........................................................................................................VIIIINTRODUCCION.....................................................................................................91 ASPECTOS DE LA INVESTIGACION.............................................................111.1 DESCRIPCIÓN DEL PROBLEMA.............................................................................111.2 JUSTIFICACION DEL PROYECTO DE INVESTIGACION.......................................111.3 DELIMITACION..........................................................................................................131.3.1 ESPACIAL.....................................................................................................................131.3.2 CRONOLÓGICA.............................................................................................................141.3.3 CONCEPTUAL...............................................................................................................171.4 OBJETIVOS...............................................................................................................171.4.1 GENERAL.....................................................................................................................171.4.2 ESPECÍFICOS...............................................................................................................172 MARCO TEORICO...........................................................................................182.1 ANTECEDENTES......................................................................................................182.1.1 HISTÓRICOS...........................................................................................................................182.1.1.1 ANTECEDENTES HISTÓRICOS SCADA.............................................................................182.1.1.2 ANTECEDENTES HISTÓRICOS FIREWALL.......................................................................182.1.2 INVESTIGATIVOS....................................................................................................................212.2 BASES TEÓRICAS....................................................................................................242.2.1 DEFINICIÓN DE FIREWALL.....................................................................................................242.2.2 DEFINICIÓN DE SISTEMA SCADA........................................................................................252.2.3 DEFINICIÓN RED SCADA.....................................................................................................252.3 TEORIAS GENERICAS BASADAS EN INGENIERIA...............................................262.3.1 ARQUITECTURA DEL FIREWALL.............................................................................................262.3.2 ARQUITECTURA SISTEMA SCADA.......................................................................................292.3.3 ARQUITECTURA MODBUS/TCP............................................................................................293 DISEÑO METODOLÓGICO.............................................................................303.1 TIPO DE INVESTIGACION...........................................................................................303.2 ANALISIS DE LA SITUACIÓN ACTUAL....................................................................303.3 DIAGNÓSTICO DE LA SITUACIÓN ACTUAL...........................................................333.3.1 RED SCADA...............................................................................................................333.3.2 FIREWALL....................................................................................................................343.3.3 MODELO PROPUESTO...................................................................................................353.3.3.1 INTEGRACIÓN RED SCADA Y FIREWALL.................................................................353.3.3.2 ANÁLISIS DEL DISEÑO DEL FIREWALL......................................................................353.3.3.2.1 DOCUMENTO DE ANÁLISIS....................................................................................363.3.3.2.1.1 REQUERIMIENTOS FUNCIONALES.......................................................................363.3.3.2.1.2 REQUERIMIENTOS NO FUNCIONALES.................................................................373.3.3.2.1.3 PLANTILLA SRS (SOFTWARE REQUIREMENTS SPECIFICATION)...........................37

3.3.3.2.1.4 CASOS DE USO................................................................................................393.3.4 MODELO DE INTEGRACIÓN............................................................................................434 LISTA DE CHEQUEO PARA VERIFICACIÓN Y PRUEBAS...........................565 CONCLUSIONES Y RECOMENDACIONES...................................................646 REFERENCIAS BIBLIOGRÁFICAS................................................................666.1 REFERENCIADA.......................................................................................................666.1.1 LIBROS ELECTRÓNICOS O DOCUMENTOS WEB..................................................................666.2 CONSULTADA...........................................................................................................676.2.1 PUBLICACIONES ESCRITAS...................................................................................................676.2.2 LIBROS...................................................................................................................................67

LISTA DE TABLAS

Pág.

Tabla 1. Grupos de Investigación en Colombia referentes a Firewall o SCADA....21Tabla 2. Algunas investigaciones y Comunidades.................................................22Tabla 3. Soluciones comerciales de Firewalll SCADA...........................................23Tabla 4. Plataformas Firewall estándar disponibles con código abierto.................23Tabla 5. Comparación de Plataformas de Firewall.................................................24Tabla 6. Códigos de Función de los dispositivos de control...................................33Tabla 7. Plantilla SRS para análisis de Netfilter.....................................................42Tabla 8. Caso de Uso N°. 001................................................................................40Tabla 9. Caso de Uso N°. 002................................................................................41Tabla 10. Caso de Uso N°. 003..............................................................................42Tabla 11. Lista de Chequeo...................................................................................56

LISTA DE FIGURAS

Pág.

Figura 1. Mercado de Sistemas SCADA en la Industria OIL & GAS....................112Figura 2. Actividades y tiempos del proyecto de investigación............................115Figura 3. Diagrama Cronológico de Actividades..................................................116Figura 4. Sistemas de Telemetría...........................1¡Error! Marcador no definido.Figura 5. Arquitectura del SEAL.............................1¡Error! Marcador no definido.Figura 6. Arquitectura de Sistema SCADA.............................................................25Figura 7. Topología Lógica Prototipo Firewall SCADA............¡Error! Marcador no definido.Figura 8. Topología Física Prototipo Firewall SCADA.............¡Error! Marcador no definido.Figura 9. Encapsulamiento de Modbus en TCP.......¡Error! Marcador no definido.Figura 10. Trama TCP Tradicional............................¡Error! Marcador no definido.Figura 11. Trama Modbus/TCP................................¡Error! Marcador no definido.Figura 12. Flujo de los Paquetes en Netfilter............¡Error! Marcador no definido.Figura 13. Flujo de los Paquetes en Netfilte.............¡Error! Marcador no definido.Figura 14. Caso de uso Firewall SCADA..................¡Error! Marcador no definido.Figura 15. Maquinas Virtuales..................................¡Error! Marcador no definido.Figura 16. Iniciando Maquinas Virtuales...................¡Error! Marcador no definido.Figura 17. Archivos Requeridos................................¡Error! Marcador no definido.Figura 18. Iniciando Maquinas Virtuales...................¡Error! Marcador no definido.Figura 19. Configuración de interface eth0...............¡Error! Marcador no definido.Figura 20. Ejecutando setup.sh................................¡Error! Marcador no definido.Figura 21. Estableciendo direcciones IP para interfaces del Firewall............¡Error! Marcador no definido.Figura 22. Habilitando Escritorio remoto desde A hacia B......¡Error! Marcador no definido.Figura 23. Permitiendo func_code=2 en ambos sentidos........¡Error! Marcador no definido.Figura 24. Finalizando configuración inicial..............¡Error! Marcador no definido.Figura 25. Configurando interface eth2 en el Firewall.............¡Error! Marcador no definido.Figura 26. Verificando conectividad con Red Hat y copiando inicia.sh..........¡Error! Marcador no definido.Figura 27. Finalizando copia de Archivos.................¡Error! Marcador no definido.Figura 28. Cargando configuración inicial al Firewall..............¡Error! Marcador no definido.Figura 29. Cargando configuración inicial al Firewall¡Error! Marcador no definido.

Figura 30. Identificando Conexiones de acuerdo con la topología propuesta¡Error! Marcador no definido.Figura 31. Identificando Conexiones de acuerdo con la configuración de las interfaces..................................................................¡Error! Marcador no definido.Figura 32. Ejecutando inicia.sh.................................¡Error! Marcador no definido.Figura 33. Probando Protocolo RDP de B hacia A...¡Error! Marcador no definido.Figura 34. Probando Protocolo ICMP en ambos sentidos.......¡Error! Marcador no definido.Figura 35. Ejecutando el archivo finconsola.sh......................................................60Figura 36. Verificando la accesibilidad al firewall desde al consola.......................60Figura 37. Envío de Func Coce = 2 transmitido y otros rechazados......................61

GLOSARIO

FIREWALL (Cortafuegos): Software, hardware o una combinación de ambas, usado en redes de computadores para controlar (permitiendo a negando) el acceso a la red

GPL (General Public License): Licencia encaminada a proteger la distribución, modificación y uso del software libre

KERNEL: Núcleo de un sistema operativo

NETFILTER Framework embebido en el kernel de Linux que permite interceptar y filtrar el tráfico que llega o sale del sistema operativo a través de sus interfaces

PLC (Controlador Lógico Programable): dispositivo diseñado para programar y controlar procesos, por lo general de producción industriales.

RTU (Remote Terminal Unit): Microprocesador que controla un dispositivo capaces de alterar o modificar el estado del mismo

SCADA (Supervisory Control And Data Acquisition): Software diseñado para controlar y automatizar entornos de control de producción industrial.

TCP/IP (Transmission Control Protocol/Internet Protocol): Conjunto de protocolos que permiten intercomunicar diferentes puertos y servicios en una red de datos.

TRINUX Mini distribución de Linux que permite habilitar un firewall portable en memoria RAM

INTRODUCCION

La globalización de las comunicaciones y la necesidad de controlar de manera automática la mayor cantidad de procesos industriales de las organizaciones de una manera centralizada, han conducido a las empresas a converger en la red TCP/IP una gran variedad de servicios de voz, video y datos sobre la misma infraestructura; sin embargo un segmento especifico de compañías han adicionado a esa misma red, otros servicios especializados que permiten automatizar y controlar procesos industriales de producción como lo son las redes SCADA.

Anteriormente, estos sistemas de automatización y control pertenecían a redes de aplicaciones específicas, completamente aisladas de las redes de datos convencionales; de allí que la seguridad en términos de integridad, confiabilidad y disponibilidad de estos sistemas estaba comprometida en porcentajes muy bajos, casi imperceptibles para la compañía que las poseía.

Hoy por hoy, con redes de datos integrales, equipos de comunicaciones, protocolos, servicios y aplicaciones comunes para los diferentes objetivos del negoció, se hace necesario contemplar sistemas de seguridad que garanticen integridad, confiabilidad y la disponibilidad de todos y cada uno de los servicios que convergen en la infraestructura de red. Por lo anterior, se desarrolla este proyecto de grado que pretende diseñar un prototipo usando software libre que permita evaluar la viabilidad de un firewall en redes SCADA, siendo estos sistemas los más frecuentes en el sector real para aplicaciones de automatización y control.

Este documento se compone de cinco capítulos. El primer capítulo contiene los aspectos referentes al tema de Investigación, sus objetivos, alcance, delimitación, y justificación.

El Segundo cubre la fundamentación teórica acerca de los dos grandes tópicos tratados de una forma en el transcurso del desarrollo del proyecto, también describe los componentes metodológicos y los recursos necesarios para realizar este proyecto.

El Diseño Metodológico, el análisis de la situación actual y la solución propuesta junto con la implementación del prototipo se contemplan el capítulo tres.

El cuarto capítulo cubre lo relacionado con la lista que chequeo y pruebas, y finalmente el capitulo cinco corresponde a las conclusiones finales y recomendaciones.

1 ASPECTOS DE LA INVESTIGACION

1.1 DESCRIPCIÓN DEL PROBLEMA

En sus orígenes, los sistemas SCADA se concibieron como sistemas cerrados con sistemas operativos y protocolos propietarios en arquitecturas aisladas de la infraestructura de comunicaciones de la organización que los usa; hoy en día, estos sistemas se han modernizado; corren sobre sistemas operativos abiertos, usan protocolos estándar como TCP/IP e interactúan con otras aplicaciones como bases de datos, correo electrónico y aplicaciones web[1].

Por lo anterior, y en gran parte debido a la evolución de las tecnologías de información y comunicación, se han detectado múltiples vulnerabilidades que amenazan a los sistemas SCADA. La razón principal por la que dichos sistemas se han visto afectados cada día más, se debe principalmente a la adopción de sistemas de propósito general a nivel de aplicaciones, sistemas operativos y protocolos que cargan con su propio legado de vulnerabilidades.

1.2 JUSTIFICACION DEL PROYECTO DE INVESTIGACION

La globalización de la tecnología, el rápido avance de la cobertura y conocimiento tecnológico en la población de nuestro país, hace necesaria la investigación e implementación de sistemas de seguridad informática en los diferentes escenarios productivos de la industria, de manera tal que cada vez es más importante integrar a las redes SCADA, componentes de seguridad perimetral que permitan mantener a salvo la infraestructura de comunicaciones y datos, que en muchos casos son críticos para la operación de las compañías que las implementan.

Por lo anterior, se han identificado dos razones principales que fundamentan el desarrollo del proyecto en cuestión.

1.2.1 Justificación técnica

El estudio de un prototipo de Firewall usando software libre para las redes SCADA es de gran importancia, ya que este un muy bien inicio en la mitigación de las vulnerabilidades de las actuales redes industriales de automatización y control. Lo anterior dado que muy pocas compañías que actualmente usan infraestructura de

[1] http://thertux.wordpress.com/2008/12/25/sistemas-scada-y-seguridad/

http://thertux.wordpress.com/2008/12/25/sistemas-scada-y-seguridad/

este tipo desconocen la necesidad de asegurar su infraestructura o lo que es peor, ignoran la existencia de componentes de seguridad como los firewalls para asegurar estos sistemas.

Este proyecto de investigación permitirá documentar la implementación de un prototipo de Firewall para redes SCADA haciendo uso de herramientas de software libre, permitiendo de esta manera a aquellas compañías que poseen redes industriales implementadas con estos sistemas de control, conocer los detalles técnicos e integrar diversos servicios a su propia infraestructura de comunicaciones de manera segura.

1.2.2 Justificación económica

Las organizaciones implementan sistemas SCADA en la actualidad para optimizar el proceso industrial de producción automatizándolo, generalmente dicho proceso es el objeto central del negocio de estas organizaciones, motivo por el cual la seguridad y la confiabilidad en este tipo de redes se convierte en un tema sensible.

El diseño del prototipo propuesto le permitirá a la fundación universitaria Konrad Lorenz, implementar, auditar y trabajar de la mano con compañías que estén interesadas en mejorar la seguridad perimetral de las redes de los sistemas SCADA, resultando en un beneficio mutuo, tanto económico como investigativo, teniendo en cuenta que el mercado para este tipo de soluciones apunta a compañías generalmente del sector industrial, más específicamente en el sector de los hidrocarburos, vertical en la que este tipo de soluciones es el objeto del negocio y representan una importancia prioritaria a la hora de invertir.

Figura 1. Mercado de Sistemas SCADA en la Industria OIL & GAS

La figura anterior[2] muestra claramente el potencial de los sistemas SCADA en la industria Oil & Gas, claramente se puede evidenciar que el mercado ha venido creciendo en esta dirección y además predice que este comportamiento se mantendrá creciendo de manera mesurada pero constante en los dos próximos años.

1.2.3 Justificación Metodológica

Se encuentra una importante justificación metodológica debido a la evidente carencia de normatividad para la regulación de la seguridad de las redes industriales, especialmente aquellas que gestionan infraestructuras e instalaciones críticas de nuestro país. En este sentido, este documento hará referencia a publicaciones y guías de mejores prácticas para redes SCADA como la publicada por el Centro Nacional de Coordinación de seguridad de infraestructura, NISCC [3]

(por sus siglas en inglés) perteneciente al Centro para la Protección de la Infraestructura Nacional (CPNI Centre for the Protection of National Infrastructure) del gobierno del Reino Unido; este se alinea perfectamente con las políticas, controles y análisis de seguridad descritos en la norma ISO 27001. De la misma manera, se hará referencia a otros documentos como el publicado por el departamento de Energía de los Estados Unidos, denominado: "21 Steps to Improve Cyber Security of SCADA Networks" [4], lo anterior con el fin de brindar un marco referencial para la investigación realizada de manera tal que pueda ser útil exponiendo lineamientos a tener el cuenta al momento de implementar estrategias de seguridad en redes industriales.

1.3 DELIMITACION

1.3.1 Espacial.

El Proyecto de Investigación así como el control y seguimiento correspondiente se llevará a cabo en la FUNDACION UNIVERSITARIA KONRAD LORENZ, ubicada en la Cra 9 Bis No. 62-43 de la ciudad de Bogotá.

La Fundación Universitaria Konrad Lorenz, fundada el 4 de noviembre de 1.981, como entidad de educación superior privada, de utilidad común y sin ánimo de lucro, con autonomía académico-administrativa y patrimonio independiente, está dedicada a la enseñanza, difusión y generación del conocimiento científico y cultural.

[2] http://www.technolead.com/news/index.php?ID=101&SubID=204[3] http://www.cpni.gov.uk/docs/re-20050223-00157.pdf[4] http://www.oe.netl.doe.gov/docs/prepare/21stepsbooklet.pdf

Es preciso notar que en la fase final del proyecto se pretende diseñar un prototipo de firewall, esta actividad se llevará a cabo en las mismas instalaciones de la universidad a manera de prototipo de laboratorio y tendrá fines netamente investigativos y académicos.

1.3.2 Cronológica.

Para la realización del presente proyecto se contará con un tiempo de estimado de 4 meses, debido a que el semestre finaliza en noviembre y es el tiempo estimado según la universidad para el desarrollo de esta propuesta. Este tiempo se distribuirá de la siguiente manera:

Actividad Semana

1. Definición del problemaa. Recopilar información.b. Estudiar la factibilidad.c. Consulta disponibilidad de re-

cursos de hardware y software.d. Informe

2. Análisis del sistema SCADAa. Estudiar sistemas existentes.b. Definir herramientas de softwa-

re a usar.c. Informe

3. Diseño de topología a. Herramientas de Simulación

PLC’s y/o RTU’s.b. Herramientas de Simulación

HMIc. Herramientas software para

Prototipo Firewall.d. Diseño de Alto Nivel.e. Informe.

4. Simulación del sistema SCADAa. Instalación PLC y/o RTU.b. Instalación HMI.c. Configuración y puesta a pun-

to.d. Informe.

5. Instalación del Firewalla. Instalación básica de Firewall.b. Pruebas de Conectividad.

0-1 semana

2-4 semana

5-7 semana

8-12 semana

13-15 semana

Actividad Semana

c. Definición e implementación de políticas de seguridad.

d. Pruebas de Funcionalidad.e. Informe.

6. Afinamientoa. Ajuste de Políticas de Seguri-

dad.b. Pruebas Finales.

16-17 semana

Figura 2. Actividades y tiempos del proyecto de investigación

Figura 3. Diagrama Cronológico de Actividades.

1.3.3 Conceptual.

Este proyecto de grado pretende desarrollar una investigación especifica acerca de las posibilidades de implementar un firewall en una red SCADA, no se orienta al análisis ni al desarrollo como tal del sistema SCADA, sus componentes ni a la construcción como tal del firewall, tampoco se tratarán aspectos relacionados con desarrollo; el propósito de la investigación es implementar un prototipo de firewall libre que permita filtrar el trafico no deseado en una red SCADA con el fin de proteger estos sistemas industriales. Tampoco es objeto de este proyecto implementar redes de comunicaciones con mejores prácticas, direccionamiento y otros aspectos que aunque serán parte funcional del prototipo, no son objeto de estudio en esta ocasión.

1.4 OBJETIVOS

1.4.1 General

Implementar un prototipo de firewall usando software libre que permita asegurar el perímetro de una red SCADA simulada.

1.4.2 Específicos.

1. Realizar el levantamiento de información necesaria para la realización del proyecto.

2. Elaborar un estado del arte que involucre las herramientas existentes para simular el tráfico típico de una red SCADA.

3. Estructurar una Topología de Red de acuerdo con la arquitectura del sistema SCADA y la infraestructura de red a implementar

4. Implementar el prototipo y realizar las pruebas básicas de conectividad.5. Definir e implementar las políticas de seguridad para el firewall.6. Realizar las pruebas de funcionalidad del firewall realizando diversos

ataques a la red.7. Elaborar un artículo de investigación.

2 MARCO TEORICO

2.1 ANTECEDENTES

1.1.1 Históricos

1.1.1.1 Antecedentes Históricos SCADA

En sus inicios, alrededor de la década del sesenta, los sistemas “SCADA” se limitaron simplemente a ser sistemas de telemetría que solo permitían obtener información de manera remota por medio de paneles que mostraban el estado de los diferentes sensores del sistema de control y siempre requerían la intervención del operador lo cual eliminaba las posibilidades de automatizar procesos y controlarlos de la misma manera. La siguiente figura ilustra los primeros sistemas de telemetría[5]

Figura 4. Sistemas de Telemetría

Con la evolución de los sistemas de comunicación y la aparición de las computadoras, los sistemas SCADA actuales son mucho más completos y tienen la capacidad de realizar remotamente tareas más complejas de manera local o remota en tiempo real. Por lo anterior, son diversos los fabricantes de este tipo de sistemas y su uso es ampliamente conocido en las diferentes verticales de la industria mundial.

1.1.1.2 Antecedentes Históricos FIREWALL

[5] David Bailey, Edwin Wright. Practical SCADA for Industry. IDC Technologies. 2003. 288 p.

El término firewall es propio del sector de la construcción, y hace referencia a un muro sin ventanas que aísla una zona de la construcción de otra con el fin de evitar en caso de incendio que el fuego se propague fácilmente de un lugar a otro[6].

Con el auge de las telecomunicaciones, la aparición de internet y el crecimiento de la industria de los computadores, también nacieron los virus informáticos (los gusanos fueron los primeros en aparecer) y los usuarios más especializados cuyos conocimientos y curiosidad les invitaban a navegar y a acceder a redes privadas sin ninguna restricción. Por esta razón surgen los surgen los primeros Firewalls; en sus primeras versiones, gracias a Cisco Systems, alrededor de 1985, se denominaron Firewalls de filtrado de paquetes y se integraron a las versiones de software (IOS) del sistema operativo de sus enrutadores; estos equipos pretendían separar la red en redes LAN más pequeñas para que los problemas de estas nos se propagaran afectando toda la red[7].

Tres años más tarde Jeff Mogul de Digital Equipment Corporation (DEC) escribe el primer paper acerca de la tecnología de Firewall, sin embargo durante los años comprendidos entre 1980 y 1990 Dave Presetto y Howard Trickey de AT&T desarrollaron la segunda generación de Firewalls denominados “circuit level firewalls”. En el transcurso del siguiente año se describe la segunda generación de Firewalls llamada firewalls de capa de aplicación o proxy firewalls, documento cortesía de Bill Cheswick, Marcus Ranum, and Gene Spafford y contituyeron la tercera generación de Firewalls. En ese mismo año (1991), DEC lanza al mercado su primera versión comercial de Firewall, fue denominado SEAL (Secure External Access Link) y se fundamento en el trabajo de Marcus Ranum. Este Firewall estaba compuesto por un sistema externo llamado Gatekeeper, un gateway de filtrado llamando Gate y un “Mailhub” interno como se muestra en la siguiente figura:

[6]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article09186a00800c85ae.html[7]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article09186a00800c85ae.html

Figura 5. Arquitectura del SEAL [8]

En los años siguientes, otras entidades como Trusted Information Systems (TIS), y la Universidad del Sur de California desarrollaron sus propias versiones de firewall de cuarta generación denominada “packet filter firewall system”, dentro de esta generación encontramos el Firewall Toolkit (FWTK) y los “Visas”. Estos últimos se constituyeron en la base comercial del Firewall-1 que ya integraba una interfaz de usuario mucho más amigable con una consola gráfica, capacidades de gestión, y fácil instalación y administración; este producto fue lanzado al mercado en en 1994 y pertenece a la empresa israelí de software Checkpoint [9].

Más tarde en 1996, Global Internet Software Group en cabeza de Scott Wiegel comienza a trabajar en los Firewalls de quinta generación llamados Firewalls de arquitectura “Kernel Proxy” y es allí cuando Cisco Systems lanza al mercado su Cisco Centri Firewall construido bajo esta arquitectura. Lo anterior abre paso finalmente a la denominada “Next Generation Firewalls” cuya arquitectura incluye muchas más capacidades como la integración de sistemas de prevención de intrusos y la posibilidad de hacer control de contenido; estas funcionalidades y la agrupación de las mismas en un solo equipo dependen básicamente de las capacidades de hardware y software provistas por los diferentes fabricantes en la actualidad.

1.1.2 Investigativos

[8]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article09186a00800c85ae.html[9] http://www.internetfirewall.org/article/internet-firewall-basics/the-history-of-firewalls.html

En la actualidad existe una gran cantidad de grupos de investigación referentes a los dos temas principales que trata este documento, en este sentido a continuación listamos algunos de los grupos de cuyo objeto de investigación son los Firewalls o los sistemas SCADA según con el sistema de información GrupLAC de Colciencias en Colombia

Tabla 1. Grupos de Investigación en Colombia referentes a Firewall o SCADA

Nombre Descripción y Fuente Institución / Procedencia

GIAR Grupo de Investigación en Automatización y Robótica

http://201.234.78.173:8080/gruplac/jsp/visualiza/visualizagr.jsp?nro=00000000004499

Universidad Central / Bogotá - Colombia

GIAM Grupo de Investigación en Aplicaciones Mecatrónicas


Universidad Santo Tomás de Aquino / Bucaramanga - Colombia

AIC Automatización, Instrumentación y Control


Pontificia Universidad Bolivariana / Bucaramanga – Colombia

GRIDITS Grupo de Investigación


Universidad de Santander / Santander – Colombia

Grupo de Investigación en Electrónica, Telemática, Arquitectura del Computador y Temas afines

Grupo de Investigación


Universidad del Bosque / Bogotá - Colombia

GRITAS Grupo de Investigación en Tecnologías Aplicadas y Sistemas de Información


Universidad Tecnológica de Bolívar / Cartagena Colombia

GIPIS Grupo de Investigación


Universidad Cooperativa de Colombia / Bogotá - Colombia

Ingeniería de Sistemas UPC

Grupo de Investigación


Corporación Universidad Piloto de Colombia / Bogotá - Colombia

Sin embargo como se pudo observar anteriormente, no existen en la actualidad grupos de investigación dedicados a estudiar la seguridad basada en los firewall,

específicamente para sistemas SCADA aunque a nivel internacional si es posible encontrar grupos, comunidades e instituciones de diferente índole trabajando en este sentido como lo podemos ver en la siguiente tabla que muestra algunos casos representativos:

Tabla 2. Algunas investigaciones y Comunidades

Nombre Autor Procedencia / FuenteA Holistic SCADA Security Standard for theAustralian Context

Christopher Beggs Autralia – Universidad Edith Cowanhttp://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1024&context=isw

Exploiting SCADA Systems

Jeremy Brown Seoulhttp://www.powerofcommunity.net/speaker.html

Cyber security for SCADA and DCS networks

Universidad de Louisville Kentucky - Estados Unidos de Americahttp://louisville.edu/speed/research/centers-and-labs/isrl/SCADA

NISCCGood Practice GuideonFirewall Deploymentfor SCADA and Process Control Networks

National Infrastructure Security Co-ordination Centre (NISCC)

http://www.cpni.gov.uk/docs/re-20050223-00157.pdf

Reino Unido http://www.cpni.gov.uk/docs/re-20050223-00157.pdf

De otra parte, en contraste con lo anterior, es posible encontrar múltiples fabricantes de firewall o soluciones de software libre que están en capacidad de entregarle soluciones SCADA seguras[10] a aquellas industrias que desean implementarlas; como una muestra de ello encontramos los siguientes fabricantes y soluciones:

Tabla 3. Soluciones comerciales de Firewalll SCADA

Fabricante Nombre Fuente:

Compliance Manager

http://www.industrialdefender.com/?_kk=industrial

%20defender&_kt=a2a5f259-ae1a-430c-9f32-

24255702e194&gclid=CK3v1YiXtaUCFUtJ2godPhg5Zw

Experion R310 http://hpsweb.honeywell.com/Cultures/en-US/Products/Systems/ExperionPKS/

r300/default.htm

[10]http://www.industrialdefender.com/news/pr/pr2010.11.04_abb_and_industrial_defender_partnership.php

http://www.industrialdefender.com/

Fabricante Nombre Fuente:Honeywell Modbus TCP

Firewall / Honeywell OneWireless Firewal

http://www.tofinosecurity.com/buy/honeywell

Adaptative Security Appliance

http://www.cisco.com/en/US/docs/switches/connectedgrid/cgs2520/

software/release/12_2_53_ex/configuration/guide/swmodbus.html

Tabla 4. Plataformas Firewall estándar disponibles con código abierto

Proyecto Fuente

SmoothWall ExpressExpress Open Source Firewall Project

http://www.smoothwall.org/

Astaro Security Gateway

http://www.astaro.com/

CensorNet

http://www.censornet.com/

Sentry Firewall

http://www.sentryfirewall.com/

m0n0wall

http://m0n0.ch/wall/

A continuación se muestra en la Tabla 5 una comparación de las diferentes plataformas de Firewall disponibles con algunas de las funcionalidades que cada una soporta.

http://www.SentryFirewall.com/

http://m0n0.ch/wall/

Tabla 5. Comparación de Plataformas de Firewall

Funcionalidad o Característica

Firewall Estándar Comercial

Firewall SCADA

ComercialModbusfw

Licencia Comercial Comercial GPL

Hardware - Software Hardware y/o Software

Hardware y/o Software Software

Plataforma de Gestión SI SI NOBloqueo de trafico que no coincida con reglas configuradas

SI SI SI

Soporte de Filtrado de Trafico Modbus/TCP NO SI SI

Interfaz Gráfica SI SI NOSoporte de otros protocolos industriales NO SI NO

Integración con otras funcionalidades de seguridad (IPS, AntiX, VPN)

SI NO NO

Como se puede observar en la tabla anterior, de acuerdo con las funcionalidades soportadas, en el caso de implementar una red SCADA, la recomendación está orientada a implementar una plataforma de firewall comercial convirtiéndose en la mejor opción para proteger redes industriales de este tipo.

2.2 BASES TEÓRICAS

1.1.3 Definición de Firewall

Un firewall es un sistema diseñado para detener accesos no autorizados en la red, puede implementarse en hardware, en software o una combinación de los dos anteriores. Estos sistemas son usados para proteger redes privadas de violaciones de seguridad efectuadas por usuarios, aplicaciones o tráfico no deseado proveniente de redes externas. A través del firewall pasa todo el tráfico que entra o sale de la red y mediante criterios o políticas definidas por el administrador examina cada uno de los paquetes y bloquea aquellos que no son conformes con dichas políticas.

De acuerdo con lo anterior y dado que este tipo de herramientas se ubican en el borde de la red, los firewall están catalogados como equipos de seguridad perimetral.

1.1.4 Definición de Sistema SCADA.

Las siglas SCADA corresponden al acrónimo de Supervisory Control And Data Acquisition que en términos generales hacen referencia a un sistema compuesto por una serie de componentes de software y hardware que supervisan y controlan a distancia la operación dinámica de maquinas de producción, proporcionando toda esta información en una pantalla de computador e integrando datos de control de calidad y estadísticas de producción entre otros. Los sistemas SCADA se caracterizan por ser sistemas de control centralizado; a diferencia de los sistemas DCS cuya arquitectura es distribuida, los sistemas SCADA están en capacidad de realizar acciones de control en forma automática. En este tipo de arquitectura, la labor del operador es principalmente de supervisión.

1.1.5 Definición Red SCADA.

Un sistema SCADA consta de varios componentes dentro de los cuales encontramos:

a. Varias Unidades de Terminal Remota (RTU) ó Controladores Lógicos Pro-gramables (PLC)

b. Estación Maestra (Servidor con HMI y Bases de Datos)c. Infraestructura de Comunicaciones.

En la siguiente gráfica (Figura 1) se puede observar la arquitectura típica de un sistema SCADA:

Figura 6. Arquitectura de Sistema SCADA[11]

De acuerdo a lo anterior, definimos que la Red SCADA es la infraestructura que permite intercomunicar a los diferentes componentes del sistema SCADA haciendo uso de múltiples equipos de comunicación, protocolos y tecnologías.

2.3 TEORIAS GENERICAS BASADAS EN INGENIERIA.

1.1.6 Arquitectura del Firewall

Para el desarrollo de este proyecto, se ha elegido un firewall de código abierto, específicamente desarrollado para redes SCADA, esta aplicación se encuentra en los diferentes sitios web de las comunidades de desarrollo como SourceForge.net.

Como la mayoría de las aplicaciones de las aplicaciones de licencia pública o GPL (por sus siglas en inglés), corre sobre el kernel de Linux versión 2.4.26 y está disponible en una mini distribución booteable de Gentoo Linux versión 3.3.2-r5 que puede ser ejecutada desde memoria RAM en sistemas de muy bajos requerimientos con un excelente desempeño. Se trata del módulo modbusfw que fue desarrollado por Kat Pothamsetty y Matthew Franz como una extensión del Netfilter, firewall tradicional que se encuentra embebido en la mayoría de los Kernel de Linux actuales.

El Modbusfw es un desarrollo básico pero útil al momento de controlar el tráfico de paquetes de datos en protocolo Modbus/TCP ya que permite filtrar por código de función en la misma sintaxis y estructura de las bien conocidas IpTables de Netfilter.

Para este caso particular, se ha decidido trabajar sobre la imagen ISO disponible en SourceForge.net [12] dado que la implementación sobre otra distribución de Linux no fue posible por tratarse de un kernel de Linux del año 2004 que no es compatible con ninguna de las versiones actuales de manera tal que para la implementación del prototipo se planteó topología lógica que se muestra en la Figura 7.

[11] http://www.isecauditors.com/es/iseclab9.html[12] http://sourceforge.net/projects/modbusfw/

Figura 7. Topología Lógica Prototipo Firewall SCADA

Con el fin de optimizar recursos y hacer lo más portable posible la implementación del prototipo, se realizó un diseño de bajo nivel en el cual se usa una sóla una maquina física con sistema operativo Windows XP que hospeda dos maquinas virtuales corriendo Windows XP para simular el trafico entre dos entes de un sistema SCADA (HMI – PLC/RTU) y dos máquinas virtuales adicionales con la mini distribución de Linux llamada Trinux y otra con Red Hat Linux. Las maquinas virtuales Linux, cumplirán con el rol de firewall SCADA y consola de administración respectivamente.

Fue necesario contar con una consola de administración del Firewall ya que Trinux no cuenta con las herramientas suficientes para la adecuada edición de los scripts que se crearon para el aprovisionamiento de las políticas del firewall ya que al ser una imagen booteable que se ejecuta desde la memoria RAM del equipo, no es posible almacenar de manera permanente las políticas a configurar. A continuación se presenta la topología física que se implementara para el prototipo de firewall:

Figura 8. Topología Física Prototipo Firewall SCADA

1.1.7 Arquitectura Sistema SCADA

En lo que al sistema SCADA respecta, la implementación del prototipo pretende simular el trafico generado y recibido por cada uno de los entes que conforman un sistema de automatización y control tradicional, es así como de acuerdo con la topología lógica mostrada en la Figura 8, se ha configurado un generador de tráfico modbus/tcp sobre una maquina virtual con sistema operativo Windows XP pretendiendo emular a través de un software denominado “Simply Modbus TCP 7.0” un PLC o una RTU corriendo dicho protocolo; adicionalmente, también se hace necesaria la inclusión de una aplicación que cumpla el rol de una HMI de manera tal que se instaló en otra máquina virtual con Windows XP la aplicación mod_RSsim que escucha por el puerto 502 el tráfico Modbus/tcp dándonos una indicación grafica de ello y simulando la consola de control de un sistema SCADA.

Es preciso aclarar que las aplicaciones utilizadas para generar y escuchar el tráfico Modbus/TCP no son GPL, se han descargado de la web [13] con sus funcionalidades completas, con autorización de uso por 30 días en calidad de “Demo License”. Lo anterior dado que este trabajo no posee el alcance de implementar una red SCADA con hardware y software de licencia pública y que tampoco fue posible encontrar un conjunto de aplicaciones de software libre que permitieran realizar la simulación de los componentes de un sistema de automatización y control usando el protocolo modbus encapsulado en TCP.

1.1.8 Arquitectura Modbus/TCP

El protocolo Modbus/tcp corresponde a una variación del protocolo Modbus, este protocolo se emplea en la capa de transporte del protocolo estándar TCP/IP [14] y se originó con el fin de poder transmitir este tráfico sobre internet de forma que fuera posible controlar uno o varios dispositivos (PLC o RTU) geográficamente distribuidos a través de la red mundial. Por esta razón, el protocolo Modbus/TCP es hoy por hoy un estándar abierto soportado de facto en la industria de los fabricantes de PLCs y RTUs por su fácil implementación y bajo costo permitiendo intercambiar información entre estos dispositivos brindando una adecuada escalabilidad ampliando las posibilidades de integración sin depender de protocolos propietarios ni fabricantes específicos.

3 DISEÑO METODOLÓGICO

3.1 TIPO DE INVESTIGACION

El presente Proyecto de Investigación es de tipo descriptivo pues pretende exponer los diferentes elementos, procedimientos y características que se deberán tener en cuenta para la implementación de un prototipo de firewall orientado a las redes de sistemas SCADA. La investigación no se detiene a comprobar hipótesis ni a hacer predicciones al respecto[15] .

[13] http://www.modbustools.com/[14]http://www.infoplc.net/Documentacion/Docu_Comunicacion/EthernetIndustrial/infoPLC_net_Ethernet_Industrial_ModbusTCP_IP.html[15] http://sites.google.com/site/ciefim/investigaci%C3%B3ndescriptiva

De esta manera, en este documento se detalla el procedimiento para implementar el firewall, se propone una arquitectura en un ambiente controlado y se realizan pruebas de funcionalidad con el fin de describir las diferentes funcionalidades que se pueden implementar.

3.2 ANALISIS DE LA SITUACIÓN ACTUAL

Con el fin de recrear el tráfico Modbus/TCP generado por un sistema SCADA tradicional, es necesario definir los elementos que deberán permitir emitir tráfico como mínimo, entre un PLC y una HMI. Actualmente, la universidad Konrad Lorenz no cuenta con un laboratorio que permita recrear las condiciones reales de un sistema SCADA ni su correspondiente red de transporte de datos, de manera tal que se hace partir de cero para logar implementar el prototipo y realizar las pruebas de funcionalidad pertinentes.

Los componentes de una red SCADA que usa Modbus/TCP establecen inicialmente una conexión a nivel de la capa de aplicación y posteriormente ese enlace puede transportar múltiples transacciones independientes. El protocolo Modbus es asíncrono, se define como un protocolo cliente-servidor (o maestro-esclavo), de capa de aplicación y no orientado a conexión; el protocolo Modbus/TCP sencillamente encapsula la trama Modbus en un segmento TCP, de manera tal que TCP brinda un servicio orientado a conexión fiable para que toda petición, espere una repuesta. Modbus/TCP establece una conexión inicial, y esta a su vez puede llevar múltiples transacciones de manera independiente.

En la Figura 9 se ilustra la trama Modbus encapsulada en TCP

Figura 9. Encapsulamiento de Modbus en TCP [16].

Con el objetivo de evidenciar claramente las diferencia entre las tramas de un paquete Modbus/TCP y uno convencional (http por ejemplo), a continuación podemos observar con el uso de analizadores de tráfico la características de cada uno de ellos.

[16]http://www.dte.upct.es/personal/manuel.jimenez/docencia/GD6_Comunic_Ind/pdfs/Tema%207.pdf

Figura 10. Trama TCP Tradicional [17].

[17] http://lakuiji.blogspot.com/

Figura 11. Trama Modbus/TCP [18].

Por otro lado, en lo que respecta al Firewall, el modbusfw es sólo una extensión para el Netfilter, éste último es el firewall de facto de Linux y se encuentra en las versiones de kernel 2.4.x y 2.6.x; permite habilitar las funcionalidades de filtrado de paquetes y NAT en dicho sistema operativo mediante el uso de la definición de una serie de reglas regidas por una estructura general de tablas [19]. Netfilter filtra básicamente inspeccionando los encabezados de cada paquete que llega a las interfaces de red y con base a las tablas de reglas configuradas decide que debe hacer con él. Por otra parte, cuando se habilitan reglas de NAT, es posible, dependiendo éstas, modificar o no el paquete cambiando el origen o el destino del mismo. Lo anterior es posible configurarlo para la mayoría de protocolos y puertos que transitan en la red, sin embargo a este funcional firewall en software es necesario adicionarle el módulo “modbusfw” si se requiere inspeccionar los paquetes de tráfico Modbus/TCP. Este módulo se usa apoyándose en las mismas palabras reservadas y funcionalidades de las iptables de Netfilter de manera tal que la implementación para un usuario que haya tenido contacto estas tablas es natural.

3.3 DIAGNÓSTICO DE LA SITUACIÓN ACTUAL.

[18] http://www.freemodbus.org/index.php?idx=92[19] http://www.netfilter.org/

3.3.1 Red SCADA

Para la simulación del tráfico en la red SCADA se evaluaron dos alternativas viables; inicialmente se pensó en buscar e implementar un conjunto de aplicaciones que se comunicaran entre sí de manera tal que permitieran la simulación de un PLC o una RTU que le enviara información a una HMI que graficara o mostrara el estado de un sistema de control, sin embargo no fue posible encontrar dichas aplicaciones disponibles en la web o las que se encontraban no establecían comunicación alguna entre ellas y no era posible mostrar el flujo del tráfico para evaluar la funcionalidad del firewall. Es así como la alternativa seleccionada fue ubicar dos aplicaciones que establecieran conectividad desde un extremo de red permitiendo generar por demanda las funciones de código que emiten los dispositivos PLC o RTU y paralelamente, el otro extremo una vez establecida la conexión mostrara la recepción exitosa de dichos códigos de función (func_code). Los códigos de función mencionados, representan los estados del dispositivo de control y en el protocolo Modbus/TCP son enviados y recibidos por el puerto TCP 502.

La Tabla 5. muestra los estados que representan los códigos de función del dispositivo de control en el protocolo Modbus.

Func_Code Estado010203040506070809101112131415161718192021222324

Read Coil Status Read Input Status Read Holding Registers Read Input Registers Force Single Coil Preset Single Register Read Exception Status Diagnostics Program 484 Poll 484 Fetch Communication Event Counter Fetch Communication Event Log Program Controller Poll Controller Force Multiple Coils Preset Multiple Registers Report Slave ID Program 884/M84 Reset Comm. Link Read General Reference Write General Reference Mask Write 4X Register Read/Write 4X Registers Read FIFO Queue

Tabla 6. Códigos de Función de los dispositivos de control [20]

Las aplicaciones que se utilizaron para similar el tráfico mencionado, aunque no son open source, permiten una instalación en modo de demostración y aún así habilitan todas sus funcionalidades pero por un periodo de 30 días y con [20] http://www.supvc.com/html/article/2010/0421/342.html

limitaciones como el tiempo que se pueden usar una vez ejecutadas, lo cual se constituye en una desventaja pero que para fines académicos no tiene implicaciones negativas.

De la misma manera, los programas mencionados con anterioridad ofrecen una funcionalidad importante al generar el trafico en el protocolo Modbus/TCP y además de ello permiten modificar el func_code a decisión del usuario en cada paquete enviado, funcionalidad cuya utilidad es importante en la implementación y prueba posterior del prototipo.

3.3.2 Firewall

El prototipo de Firewall, corresponde a la implementación de una serie de políticas creadas en la estructura general de tablas para filtrado de paquetes de Netfilter (iptables), para ello se investigó acerca de una distribución de Linux que permitiera habilitar el modulo de extensión “modbusfw” o que ya lo tuviera embebido, con el fin de poder filtrar paquetes en el protocolo Modbus/TCP. De esta manera, se definió que la distribución de Linux a usar es una distribución llamada Trinux, es lite, booteable y corre en casi cualquier configuración de hardware esto lo hace increíblemente portable lo cual representa una importante ventaja para el usuario ya que desde su arranque no tiene servicios habilitados (como Telnet, RDP, DHCP) por tanto mejora los niveles de seguridad sin la intervención del usuario. Desafortunadamente con la portabilidad y escaso soporte de comandos y servicios también se detectó una desventaja importante, en el sentido en que no es posible guardar las configuraciones realizadas una vez se reinicia o se apaga el equipo, lo anterior se debe que esta distribución se ejecuta desde memoria RAM.

Por lo anteriormente expuesto, el prototipo debió integrar una consola de administración que permitiera generar y almacenar scripts de configuración con el fin de que la implementación, cambios y adiciones en el Firewall pudieran ser fácilmente realizados por cualquiera que leyera este documento.

De la misma manera, todo el escenario de pruebas, se realizo en un solo equipo físico, todos los sistemas operativos y software para generar trafico que fueron usados en el proyecto se encuentran en maquinas virtuales, esto permite que se replique rápidamente todo el ambiente de pruebas en cualquier equipo que tenga instalado el software VMware Player cuya distribución es gratuita[21].

3.3.3 Modelo Propuesto

[21] http://downloads.vmware.com/d/info/desktop_downloads/vmware_player/3_0

3.3.3.1 Integración Red SCADA y Firewall

El modelo de prototipo propuesto para la integración de la red SCADA y el Firewall pretende implementar en un ambiente de pruebas, mediante la instalación de múltiples máquina virtuales en Windows y Linux, los componentes necesarios para la puesta en funcionamiento del Firewall así como también para la administración del mismo y la instalación del diferentes simuladores en software para generar tráfico Modbus/TCP. Una vez realizado el montaje, se procederá a realizar la pruebas de conectividad pertinentes para verificar el estado de las conexiones y el tránsito del tráfico a través del Firewall.

Por último se habilitarán las políticas requeridas para filtrar el tráfico deseado y se realizarán pruebas de operatividad. Para lo anterior se construirán algunos scripts sencillos que permitan guardar la configuración del firewall y así poder darle una mejor aplicabilidad y portabilidad al prototipo.

A continuación se relacionan los requerimientos funcionales y no funcionales dados para la Integración e implementación del prototipo de firewall.

3.3.3.2 Análisis del Diseño del Firewall

A continuación se presenta la siguiente gráfica que permite ver el flujo del tráfico a través de las capas de conexión y de red del modelo OSI.

Figura 12. Flujo de los Paquetes en Netfilter[22]

3.3.3.2.1 Documento de Análisis

[22] http://l7-filter.sourceforge.net/PacketFlow.png

En este apartado se presentaran los tópicos referentes al análisis del Firewall propuesto para la implementación del prototipo. Cubre en primer lugar los requerimientos funcionales y no funcionales seguidos de la documentación de los mismos usando una plantilla SRS para su adecuado análisis, y por último los casos de uso con su correspondiente documentación.

3.3.3.2.1.1 Requerimientos Funcionales

A continuación se enumeran los requerimientos funcionales para el análisis del prototipo de firewall:

a. Aplicar regla a paquetes que ingresan al firewall b. Aplicar regla a paquetes que salen del firewall c. Aplicar regla a paquetes de trafico que atraviesan el firewall

La siguiente gráfica muestra el flujo de los paquetes y el comportamiento del módulo de Netfilter para el filtrado del los paquetes.

Figura 13. Flujo de los Paquetes en Netfilter[23]

3.3.3.2.1.2 Requerimientos no Funcionales

[23] http://plog.longwin.com.tw/news-unix/2007/01/03/netfilter_traversal_2007

A continuación se enumeran los requerimientos no funcionales para la implementación del prototipo de firewall para redes SCADA:

Software VMware Player Maquina con arquitectura Intel con mínimo: Windows XP, Tarjeta de Red,

2GB de memoria RAM, disco duro de 80GB, unidad DVD/R y procesador de 2.0 Ghz

Instaladores Windows XP imagen ISO de la distribución lite Trinux basada en Gentoo Linux Previamente debe estar instalado y configurado Windows XP en el equipo

Host. 2 Maquinas virtuales de Windows XP, instaladas y operativas en el equipo

host. 1 Maquina virtual de cualquier distribución Linux con cliente SSH (Se reco-

mienda Red Hot Enterprise v5.) Se requiere que el usuario tenga conocimientos básicos de Linux y del fun-

cionamiento de iptables. Se debe mantener copia actualizada de todos los scripts y configuraciones

de iptables realizadas.

3.3.3.2.1.3 Plantilla SRS (Software Requirements Specification)

Con el fin de documentar de una manera adecuada los casos de uso encontrados en el proceso de reingeniería de software, a continuación se presenta la plantilla SRS que se usó para el correspondiente análisis de Netfilter, ya que este es el sistema implementado en el prototipo y que hospeda el modulo de firewall para SCADA “modbusfw”.

Tabla 7. Plantilla SRS para análisis de Netfilter

3.3.3.2.1.4 Casos de Uso

Debido a que el presente proyecto de investigación no tiene el alcance de desarrollar o complementar el desarrollo del los módulos a implementar, a continuación se representan gráficamente los casos de uso que aplican al modulo de firewall de Linux y además se realiza la documentación correspondiente para cada uno de ellos.

Figura 14. Caso de uso Firewall SCADA

Tabla 8. Caso de Uso N°. 001

CU-001 Administración de Políticas Objetivos asociados

Operar las diferentes funciones permitidas para la administración de las políticas o reglas de filtrado de paquetes

Requisitos asociados

Tener instalado el sistema operativo con el modulo de firewall y kernel compatible adecuado (En este caso Trinux 2.4.26)

Descripción El sistema deberá permitir la administración adecuada de las políticas de filtrado

Precondición Deben existir los requerimientos mínimos de Hardware. Y contar con la imagen .iso de trinux

SecuenciaNormal

Paso Acción1 El Administrador crea una regla.2 El Administrador elimina regla regla.3 El Administrador edita una regla.

Postcondición Al verificar en la el funcionamiento de las reglas con el flujo de trafico se debe realizar el filtrado conforme las reglas configuradas.

Excepciones Paso Acción1 Si el firewall la imagen .iso de sistema

operativo trinux no inicia este caso de uso termina.

Frecuencia esperada

Cada vez que se inicia la maquina del firewall

Estabilidad MediaComentarios En caso de algún fallo de la instalación, se recomienda

revisar la página http://modbusfw.sourceforge.net/


CU-002 Módulo de Routing

Objetivos asociados Realiza el enrutamiento del trafico que pasa por el firewall.

Requisitos asociados Existencia del kernel de Linux v2.4.x.

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el administrador desee administrar las rutas del firewall.

Precondición Debe estar operativa la distribución Trinux. SecuenciaNormal

Paso Acción1 El Administrador verifica las rutas existentes.2 El Administrador adiciona rutas en caso de

requerirse3 El Administrador elimina rutas en caso de

requerirsePostcondición El firewall debe estar direccionando el tráfico

adecuadamente.Excepciones Paso Acción

1 Si el módulo de enrutamiento no se encuentra presento o no está activo este caso de uso termina.

Frecuencia esperada Cada vez que se requiera modificar alguna ruta.Estabilidad Alta

Comentarios En caso de algún fallo de la instalación, se recomienda revisar la página http://modbusfw.sourceforge.net/


CU-003 Módulo Modbusfw

Objetivos asociados Filtrar tráfico mosbus/tcp.Requisitos asociados Existencia del kernel de Linux v2.4.x. y del modulo

modbusfw.Descripción El sistema deberá comportarse tal como se describe

en el siguiente caso de uso cuando el administrador desee realizar filtrado de paquetes modbus/TCP.

Precondición Debe estar operativa la distribución Trinux, así como instalado y operativo el modulo modbusfw.

SecuenciaNormal

Paso Acción1 El Administrador verifica que se encuentre

módulo instalado y operativo.2 El Administrador configura una regla para

filtrar tráfico Modbus/TCP.3 El Administrador verifica la operación del la

regla creada.Postcondición Al entrar en Trinux se deben poder configurar las

reglas para Modbus/TCP usando los comandos establecidos para ello.

Excepciones Paso Acción1 Si el Módolo modbusfw no se encuentra

activo esta caso de uso terminaFrecuencia esperada 1 vez (Una vez instalado y configurado el módulo no

hay necesidad de volver a cargarlo).Estabilidad Alta

Comentarios En caso de algún fallo de la instalación, se recomienda revisar la página http://modbusfw.sourceforge.net/

3.3.4 Modelo de integración

A continuación se relacionan paso a paso las diferentes actividades y procesos necesarios para implementar el prototipo del firewall SCADA:

Instalar las siguientes maquinas virtuales usando WMware Player:

a. Windows_XP_Ab. Windows_XP_Bc. Linux Red Hat Enterprise 5d. Cargar la imagen de Trinux y Nombrarla como “Firewall”

Las Maquinas virtuales deberán quedar como se muestra en la Figura 12:

Figura 15. Maquinas Virtuales

Inicie todas las maquinas virtuales

Figura 16. Iniciando Maquinas Virtuales

Ingrese a la Máquina virtual de Red Hat (Para este caso Usr: root Pwr: 1)

En la consola de Red Hat cree una carpeta (para nuestro caso la carpeta se llamará “proyecto”) con los siguientes archivos:

Figura 17. Archivos Requeridos

En el editor de texto de la consola Rad Hat agregue el siguiente contenido por cada uno de los archivos:

Archivo setup.sh

#!/bin/bashclearecho "**************************************************"echo "* SETUP FIREWALL *"echo "* UNIVERSIDAD KONRAD LORENZ *"echo "* PROYECTO DE GRADO: PROTOTIPO FIREWALL SCADA*"echo "* POR: JHONNY LOPEZ *"echo "**************************************************"echo ""echo "Digite la Ip de interface de entrada Firewall:" ; read ipin

echo "Digite la máscara de la interface de entrada Firewall:"; read msinecho "Digite la Ip de interface de salida Firewall:"; read ipoutecho "Digite la máscara de la interface de salida Firewall:"; read msoutecho ""echo "Se configurado la interface de entrada Firewall:"echo "IP es $ipin mascara $msin"echo "Se configurado la interface de salida Firewall:"echo "IP es $ipout mascara $msout"echo ""echo "#!/usr/bin/bash" > /proyecto/inicia.shcat /proyecto/head.txt >> /proyecto/inicia.shecho "ifconfig eth0 $ipin netmask $msin up" >> /proyecto/inicia.shecho "ifconfig eth1 $ipout netmask $msout up" >> /proyecto/inici-a.shcat /proyecto/regla0.txt >> /proyecto/inicia.shclear/proyecto/addreglas.shcat /proyecto/tail.txt >> /proyecto/inicia.shecho ""echo "Se ha creado correctamente el archivo inicia.sh ..."echo "Por Favor copiar el archivo inicia.sh al firewall ..."echo ""

chmod 777 /proyecto/inicia.sh

Archivo inicia.sh

Este archivo es generado automáticamente por el script setup.sh, no es necesario crearlo; se referencia con el fin de ver el resultado de las configuraciones que serán cargadas en el firewall además de explicar brevemente las configuraciones y comandos implementados en el prototipo.

#!/usr/bin/bashecho "**************************************************"echo "* CONFIGURACION DEL FIREWALL *"echo "* UNIVERSIDAD KONRAD LORENZ *"echo "* PROYECTO DE GRADO: PROTOTIPO FIREWALL SCADA*"echo "* POR: JHONNY LOPEZ *"echo "**************************************************"echo ""# Configuración de direcciones IP de las interfaces de red eth0 y eth1 de# salida y entrada correspondientemente.ifconfig eth0 10.10.1.1 netmask 255.255.255.0 upifconfig eth1 10.10.2.1 netmask 255.255.255.0 up# Configuración de políticas generales (-P) todo el tráfico que entre, salga y# atraviese el firewall será descartado

iptables -P INPUT DROPiptables -P FORWARD DROPiptables -P OUTPUT DROP# Ahora se agrega una regal (-A) de manera que se acepte el tráfico que entre y# salga de la dirección IP 192.168.0.2, que para nuestro caso será la consola de# administración.iptables -A INPUT -s 192.168.0.2 -j ACCEPTiptables -A OUTPUT -d 192.168.0.2 -j ACCEPT# Reglas auxiliares de referencia para permitir trafico de servicios particulares# (http), se deben crear mínimo dos por cada servicio una para entrada y la # otra para salida (comentariadas no se ejecutarán)#iptables -A FORWARD -s 10.10.2.2 -d 10.10.1.2 --dport 80 -j AC-CEPT#iptables -A FORWARD -s 10.10.1.2 --sport 80 -d 10.10.2.2 -j AC-CEPT# Regla de funcode de modbus general, donde 1 es el código de función del# paquete modbus/tcp, -m modbus es el modulo para filtrado de trafico modbus,# –p tcp es la instrucción que se trata de trafico del protocolo tcp y –j ACCEPT es# la instrucción para aceptar el paquete que haga match con las demás # características enunciadas#iptables -A FORWARD -p tcp -m modbus --funccode 1 --allowtcp 1 -j ACCEPT# reglas para dejar transitar el tráfico TCP en el Puerto 3389 que corresponde a# RDP para permitir el Servicio de escritorio remoto aceptándolo desde el origen# con IP 10.10.2.2 y 10.10.1.2 iptables -A FORWARD -s 10.10.2.2 -p tcp --dport 3389 -d 10.10.1.2 -j ACCEPTiptables -A FORWARD -s 10.10.1.2 -p tcp --sport 3389 -d 10.10.2.2 -j ACCEPT# Regla para dejar transitar los paquetes modbus/tcp con func_code 6 en su trama# aceptándolo.iptables -A FORWARD -p tcp -m modbus --funccode 6 --allowtcp 1 -j ACCEPT# Regla para dejar transitar los paquetes modbus/tcp con func_code 9 en su # trama, aceptándolo desde el origen con IP 10.10.2.2 hacia el destino con IP# 10.10.1.2.iptables -A FORWARD -s 10.10.2.2 -p tcp -m modbus --funccode 9 --allowtcp 1 -d 10.10.1.2 -j ACCEPTecho ""echo "Se ha configurado las tarjetas de Red Correctamente y se han cargado las configuraciones iniciales ..."echo ""

Archivo sddreglas.sh

#!/bin/bashecho "Configuracion de la regla 1 del Firewall"echo "Configuracion de servicio generales ej: RDP(3389)"echo ""echo "Digite la ip del equipo origen:" ; read iporgecho "Digite la ip del equipo destino:" ; read ipdesecho "Digite el puerto del servicio a permitir:" ; read puertoecho "iptables -A FORWARD -s $iporg -p tcp --dport $puerto -d $ipdes -j ACCEPT" >> /proyecto/inicia.shecho "iptables -A FORWARD -s $ipdes -p tcp --sport $puerto -d $iporg -j ACCEPT" >> /proyecto/inicia.shecho ""echo "Configuracion de function_code de ModBus"echo "-- Configuracion Ambos sentidos:"echo "Digite el funct_code para habilitar:"; read fcd1echo "iptables -A FORWARD -p tcp -m modbus --funccode $fcd1 --allowtcp 1 -j ACCEPT" >> /proyecto/inicia.shecho ""echo "-- Configuracion en un solo sentido:"echo "Digite la ip del equipo origen:" ; read iporg1echo "Digite la ip del equipo destino:" ; read ipdes1echo "Digite el funct_code para habilitar:"; read fcd2echo "iptables -A FORWARD -s $iporg1 -p tcp -m modbus --funccode $fcd2 --allowtcp 1 -d $ipdes1 -j ACCEPT" >> /proyecto/inicia.shecho ""echo "Se ha terminado de configurar las Reglas personalizadas"

echo ""

Archivo finconsola.sh

#!/usr/bin/bashecho "**************************************************"echo "* CERRAR CONSOLA DEL FIREWALL *"echo "* UNIVERSIDAD KONRAD LORENZ *"echo "* PROYECTO DE GRADO: PROTOTIPO FIREWALL SCADA*"echo "* POR: JHONNY LOPEZ *"echo "**************************************************"echo ""echo " Cerrando Acceso de Consola Espere Por Favor . . . "iptables -D INPUT -s 192.168.0.2 -j ACCEPTiptables -D OUTPUT -d 192.168.0.2 -j ACCEPTecho " Se ha cerrado conexion con la consola de configuracion"echo ""echo "VERIFICANDO ..."iptables -L

Archivo reset.sh

#!/usr/bin/bashecho "**************************************************"echo "* RESET DEL FIREWALL *"echo "* UNIVERSIDAD KONRAD LORENZ *"echo "* PROYECTO DE GRADO: PROTOTIPO FIREWALL SCADA*"echo "* POR: JHONNY LOPEZ *"echo "**************************************************"echo ""echo " Espere Por Favor . . . "iptables -Fiptables -P INPUT ACCEPTiptables -P FORWARD ACCEPTiptables -P OUTPUT ACCEPTecho " Se Ha reseteado con exito"echo ""echo "VERIFICANDO ..."iptables -L

Archivo head.txt

echo "******************************************************"echo "* CONFIGURACION DEL FIREWALL *"echo "* UNIVERSIDAD KONRAD LORENZ *"echo "* PROYECTO DE GRADO: PROTOTIPO DE FIREWALL SCADA *"echo "* POR: JHONNY LOPEZ *"echo "******************************************************"echo ""

Archivo regla0.txt

iptables -P INPUT DROPiptables -P FORWARD DROPiptables -P OUTPUT DROPiptables -A INPUT -s 192.168.0.2 -j ACCEPTiptables -A OUTPUT -d 192.168.0.2 -j ACCEPT# Reglas auxiliares de adicion (se deben crear minimo dos por cada servicio)#iptables -A FORWARD -s 10.10.2.2 -d 10.10.1.2 --dport 80 -j AC-CEPT#iptables -A FORWARD -s 10.10.1.2 --sport 80 -d 10.10.2.2 -j AC-CEPT# Regla de funcode de modbus general#iptables -A FORWARD -p tcp -m modbus --funccode 1 --allowtcp 1 -j ACCEPT

Archivo tail.txt

echo ""echo "Se ha configurado las tarjetas de Red Correctamente ..."echo ""

Configure las tarjetas de Red del los equipos Windows_XP_A y Windows_XP_B con direcciones de segmentos de red diferentes, para este particular el ejemplo tomará como base el direccionamiento establecido en la Figura 7 donde se propone que el quipo A de esncuentre en al segmento de red Interno y el equipo B se encuentre en el segmento de red externo:

Figura 18. Iniciando Maquinas Virtuales

Desde la consola de Red Hat configure la interface eth0 y verifique:

Figura 19. Configuración de interface eth0

Desde la consola de Red Hat ingrese al directorio que contienen los archivos (/proyecto) y ejecute el archivo setup.sh para iniciar el asistente de configuración de los parámetros iniciales del firewall.

Figura 20. Ejecutando setup.sh

Ingrese correctamente los parámetros solicitados para configurar las direcciones IP del las interfaces interna y externa según su configuración; para éste caso se seguirá el direccionamiento propuesto en la Figura 7.

Figura 21. Estableciendo direcciones IP para interfaces del Firewall

Luego el script le solicitará la configuración de una regla para habilitar un servicio de red, para este ejemplo se habilitará el puerto 3389 correspondiente a RDP para permitir el escritorio remoto de Windows de manera tal que permitiremos el paso de este tipo de tráfico desde la red red externa al PC llamado Windows_XP_A desde el equipo Windows_XP_B

Figura 22. Habilitando Escritorio remoto desde A hacia B

Continuando con la configuración el script le solicitará ahora el func_code de modbus/TCP que desea que pase a través del firewall en ambos sentidos; a manera de ejemplo vamos a permitir el func_code=2:

Figura 23. Permitiendo func_code=2 en ambos sentidos

Finalmente el script le permitirá configurar el paso de un func_code que para efectos de este ejemplo será = 3 con el fin de permitir el trafico Modbus/TCP en un solo sentido de manera que solicitara la IP de equipo origen que para este caso será la del equipo A, el equipo destino que será el B y por último el func_code.

Figura 24. Finalizando configuración inicial

Para contextualizar al lector, se recuerda que según la Tabla 5, los códigos de función 2 y 3 corresponden a las funciones “Read Input Status” y “Read Holding Registers” respectivamente.

A continuación, ingrese a la máquina donde está ejecutando la distribución Trinux, esta máquina virtual debe tener tres tarjetas de red virtuales instaladas de manera tal que debe configurara la interface eth2, que será la que establezca la comunicación con la consola de administración (Red Hat) y cuyo direccionamiento sigue el propuesto el a Figura 7.

Figura 25. Configurando interface eth2 en el Firewall

Verifique conectividad entre las dos maquinas virtuales y acceda a la consola Red Hat usando SSH y copie los archivos inicia.sh, reset.sh y finconsola.sh

Figura 26. Verificando conectividad con Red Hat y copiando inicia.sh

Realice este mismo procedimiento para los otros dos archivos.

Figura 27. Finalizando copia de Archivos

Continuando en el firewall, ejecute el archivo inicia.sh para cargar la configuraciones establecidas en la consola Red Hat al principio de este procedimiento.

Figura 28. Cargando configuración inicial al Firewall

Por último, si desea cerrar la puerta trasera que constituye la consola, ejecute el archivo finconsola.sh

Si su deseo es eliminar todas las reglas del firewall ejecute reset.sh

Figura 29. Cargando configuración inicial al Firewall

Si desea modificar alguna de las regla configuradas, puede usar el comando iptables directamente en la consola del firewall, sin embargo, la recomendación es editar desde la consola, el script setup.sh o el script inicia.sh generado por él de manera tal que pueda ser almacenado en la consola y sea posible recuperar las reglas del firewall en caso de reinicio del mismo.

Dado que no es del alcance de este proyecto de investigación cubrir el funcionamiento y configuración de reglas de filtrado usando iptables, se hace referencia a un compilado de manuales que pueden ayudar en caso de que el

lector quiera profundizar en el uso de iptables[24]. Sin embargo, para la implementación de reglas de este prototipo, las configuraciones son almacenadas en el archivo inicia.sh que se carga al Firewall, dicho script de configuración se explica en detalle al inicio de este mismo numeral.

[24] http://lucas.hispalinux.es/htmls/manuales.html

4 LISTA DE CHEQUEO PARA VERIFICACIÓN Y PRUEBAS

Actualmente no existe un protocolo de pruebas establecido para un firewall de una red SCADA, sin embargo dentro de la investigación realizada se encontró una lista de chequeo general para aseguramiento de redes SCADA[20] que establece algunas pautas que pueden ser verificadas en la implementación realizada.

Es preciso aclarar que algunos de los ítems estipulados en la lista de chequeo no hacen referencia específicamente al firewall por tanto no podrán ser incluidos en las pruebas que se ejecutarán para el prototipo implementado.

La Tabla 7 muestra la lista de chequeo que se seguirá para la realización de las pruebas.

Tabla 11. Lista de Chequeo [25].

SCADA Security Checklist Company: Konrad Lorenz University Date: Nov - 2010 No Activity Status

1 Identify all connections to SCADA networks OK2 Disconnect unnecessary connections to the SCADA network OK

3 Evaluate and strengthen the security of any remaining connections to the SCADA network OK

4 Harden SCADA networks by removing or disabling unnecessary services OK5 Do not rely on proprietary protocols to protect your system OK6 Implement the security features provided by device and system vendors N/A

7 Establish strong controls over any medium that is used as a backdoor into the SCADA network OK

8 Implement internal and external intrusion detection systems and establish 24-hour-a-day incident monitoring N/A

9 Perform technical audits of SCADA devices and networks, and any other con-nected networks, to identify security concerns OK

10 Conduct physical security surveys and assess all remote sites connected to the SCADA network to evaluate their security N/A

11 Establish SCADA “Red Teams” to identify and evaluate possible attack scenar-ios N/A

12 Clearly define cyber security roles, responsibilities, and authorities for man-agers, system administrators, and users N/A

[25]http://www.controlscada.com/scada-security-checklist-free-download&rurl=translate.google.com&usg=ALkJrhgiDhH1ZozY9THjoQ7u78W

13 Document network architecture and identify systems that serve critical functions or contain sensitive information that require additional levels of protection OK

14 Establish a rigorous, ongoing risk management process N/A

15 Establish a network protection strategy based on the principle of defense-in-depth N/A

16 Clearly identify cyber security requirements N/A17 Establish effective configuration management processes N/A18 Conduct routine self-assessments OK19 Establish system backups and disaster recovery plans OK

20 Senior organizational leadership should establish expectations for cyber secu-rity performance and hold individuals accountable for their performance N/A

21Establish policies and conduct training to minimize the likelihood that organiza-tional personnel will inadvertently disclose sensitive information regarding SCADA system design, operations, or security controls

N/A

A continuación se realizarán las posibles pruebas de acuerdo con la lista de chequeo presentada anteriormente.

1. Identificando las conexiones de la red SCADA

Se verifican las conexiones configuradas versus las establecidas en el diseño de alto nivel.

Figura 30. Identificando Conexiones de acuerdo con la topología propuesta.

Figura 31. Identificando Conexiones de acuerdo con la configuración de las interfaces.

2. Desconectando conexiones innecesarias en la red SCADA:

Se ejecuta el archivo inicia.sh que elimina todo acceso innecesario.

Figura 32. Ejecutando inicia.sh

3. Evaluando y reforzando los enlaces restantes en la red SCADA:

La seguridad de las conexiones se mejora con la ejecución del archivo inicia.sh ya que sólo deja disponibles los puertos y conexiones deseadas.

Para probar que el protocolo RDP en el puerto 3389 se encuentra habilitado

Figura 33. Probando Protocolo RDP de B hacia A

Probando el estado de otros servicios (ICMP) desde A hacia B y viceversa

Figura 34. Probando Protocolo ICMP en ambos sentidos

4. Fortaleciendo SCADA removiendo o deshabilitando servicios innecesarios

Se comprobó en el punto anterior a nivel de firewall

5. No confíe en protocolos propietarios para proteger sus sistema:

Se está utilizando protocolo Modbus/TCP que es un protocolo abierto además de que se está utilizando el firewall de uso libre por tanto se cumple este ítem a nivel de firewall

6. Implemente la funcionalidades de seguridad provistas por el dispositivo y el fabricante del sistema

Este ítem no aplica es este caso ya que no se están implementando dispositivos reales.

7. Establecer controles estrictos sobre cualquier medio que se utilice como una puerta trasera en la red

Para el cumplimento de este ítem se debe correr el archivo finconsola.sh con el fin de eliminar las conexiones de puerta trasera que constituye la misma.

Figura 35. Ejecutando el archivo finconsola.sh

Figura 36. Verificando la accesibilidad al firewall desde al consola

8. Implementar sistemas de detección de intrusos internos y externos de y establecer un seguimiento de incidentes las 24 horas del día.

No Aplica ya que no el proyecto obedece a la implementación de un prototipo y no a un sistema en producción.

9. Realizar auditorías técnicas de los dispositivos de SCADA y redes, y cualquier red conectada otros, para identificar problemas de seguridad

Aunque el prototipo implementado no obedece a un sistema en producción, en este caso se realizarán las pruebas con los generadores de tráfico comprobando el estado de las reglas de filtrado configuradas.

Para evaluar la seguridad en estas conexiones es necesario descargar e instalar los programas Simply Modbus TCP, mod_RSsim, Modbus Poll e instalarlos en las dos máquinas virtuales configuradas con Windows XP (se recomienda hacer una prueba de conectividad antes de habilitar las reglas del firewall.

Figura 37. Envío de Func Coce = 2 transmitido y otros rechazados

10.Realizar estudios de seguridad física y evaluar todos los sitios remotos conectados a la red SCADA para evaluar su seguridad.


11.Establecer “Equipos Rojos” SCADA para identificar y evaluar posibles escenarios de ataque


12.Definir claramente los roles de seguridad cibernética, responsabilidades y autoridades para los gerentes, los administradores de sistemas y usuarios


13.Documente la arquitectura de red e identifique los sistemas que cumplen funciones críticas o que contengan información sensible que requiere niveles adicionales de protección

Solo es posible documentar la arquitectura propuesta para el prototipo ya que el proyecto no obedece a un sistema en producción real.

14.Establecer un proceso riguroso y permanente de gestión de riesgos


15.Establecer una estrategia de protección de la red basado en el principio de defensa en profundidad

No Aplica ya que no el proyecto obedece a la implementación de un prototipo y no a un sistema en producción con una arquitectura completa real.

16. Identificar claramente los requisitos de seguridad cibernética


17.Establecer una gestión eficaz de los procesos de configuración


18.Llevar a cabo la rutina de auto-evaluación


19.Establezca un sistema de copias de seguridad y planes de recuperación de desastres

No Aplica ya que no el proyecto obedece a la implementación de un prototipo y no a un sistema en producción. Sin embargo se han establecido copias de seguridad de las maquinas virtuales y los scripts configurados

20.La dirección de la organización debe establecer mayores expectativas de rendimiento de la seguridad cibernética y responsabilizar a los individuos respectivos de su desempeño


21.Establecer políticas y actividades de entrenamiento para reducir al mínimo la probabilidad de que personal de la organización sin darse cuenta divulgue información sobre el diseño, operaciones o controles de seguridad del sistema SCADA,


5 CONCLUSIONES Y RECOMENDACIONES

A finalizar la implementación del prototipo de firewall para redes SCADA se puede afirmar que hoy por hoy, es de vital importancia implementar sistemas de seguri-dad perimetral en las redes modernas y con mayor razón, aquellas que controlan instalaciones o infraestructuras criticas para las naciones, lo anterior ya que en pro de la convergencia, portabilidad e integrabilidad de dispositivos y aplicaciones em-presariales, se requiere adoptar el uso de protocolos abiertos como TCP/IP que permitan la comunicación simultánea y remota de entre todos ellos.

Por lo anterior se puede concluir que sobre un protocolo abierto como TCP/IP es viable integrar a la infraestructura de las redes de control, sistemas de seguridad perimetral, esto dado que no sólo es posible usar herramientas de software libre con las limitaciones expuestas durante el desarrollo de este proyecto, sino que ya es posible encontrar en al mercado múltiples plataformas de seguridad, orientadas a las redes de automatización y control que soportan protocolos abiertos como Modbus/TCP y muchos otros más para diferentes aplicaciones industriales.

En este caso, la recomendación es implementar plataformas de firewall comercia-les y especializadas en redes de este tipo ya que estas son las que en la actuali -dad se encuentran más desarrolladas y por tanto mitigan de mejor forma las vul -nerabilidades actuales al evolucionar con el paso del tiempo.

Aunque la implementación del prototipo se llevó a cavo con éxito, son escasos las comunidades de desarrollo que trabajan en este sentido, de la misma manera son limitadas también las posibilidades de filtrado para este tipo de tráfico dejando sólo la posibilidad de realizar filtrado por el código de función de los paquetes Modbus/TCP.

Se recomienda como alcance de otro proyecto evaluar las diferentes posibilidades de desarrollo del módulo modbusfw, ya que en la implementación sólo fue posible usar como argumento de filtrado el código de función en el paquete de Modbus/TCP, lo anterior dado que no se ha habilitado ni probado este módulo en un am-biente diferente del de laboratorio; no se encontró registro de ello. De otra parte, las herramientas disponibles para realizar pruebas de trafico con el protocolo Modbus/TCP son restringidas a fabricantes y comunidades especializa-das

Se puede observar que en Colombia no existe normatividad para la regulación de los mecanismos de control de los sistemas de automatización de las instalaciones e infraestructura critica, así como tampoco existe para el sector público.

Finalmente, es importante notar que aunque en nuestro país no existen leyes que regulen la seguridad en sistemas SCADA, si es posible encontrar una serie de documentos de este tipo pertenecientes al Centro para la Protección de la Infraestructura Nacional, del gobierno del Reino Unido. Allí se encuentran varios documentos que cubren la mayoría, si no todos los frentes en cuanto a seguridad para redes SCADA respecta. Se trata de una serie de guías de mejores prácticas disponibles al público vía web[26].

[26] http://www.cpni.gov.uk/ProtectingYourAssets/scada.aspx

http://www.cpni.gov.uk/ProtectingYourAssets/scada.aspx

6 REFERENCIAS BIBLIOGRÁFICAS

6.1 REFERENCIADA

1.1.9 Libros Electrónicos o Documentos Web

[1] http://thertux.wordpress.com/2008/12/25/sistemas-scada-y-seguridad/ [2] http://www.technolead.com/news/index.php?ID=101&SubID=204[3] http://www.cpni.gov.uk/docs/re-20050223-00157.pdf[4] http://www.oe.netl.doe.gov/docs/prepare/21stepsbooklet.pdf[6]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article09186a00800c85ae.html[7]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article09186a00800c85ae.html[8]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article09186a00800c85ae.html[9] http://www.internetfirewall.org/article/internet-firewall-basics/the-history-of-firewalls.html[10]http://www.industrialdefender.com/news/pr/pr2010.11.04_abb_and_industrial_defender_partnership.php[11] http://www.isecauditors.com/es/iseclab9.html[12] http://sourceforge.net/projects/modbusfw/[13] http://www.modbustools.com/[14]http://www.infoplc.net/Documentacion/Docu_Comunicacion/EthernetIndustrial/infoPLC_net_Ethernet_Industrial_ModbusTCP_IP.html[15] http://sites.google.com/site/ciefim/investigaci%C3%B3ndescriptiva[16]http://www.dte.upct.es/personal/manuel.jimenez/docencia/GD6_Comunic_Ind/pdfs/Tema%207.pdf[17] http://lakuiji.blogspot.com/[18] http://www.freemodbus.org/index.php?idx=92[19] http://www.netfilter.org/[20] http://www.supvc.com/html/article/2010/0421/342.html[21] http://downloads.vmware.com/d/info/desktop_downloads/vmware_player/3_0[22] http://l7-filter.sourceforge.net/PacketFlow.png[23] http://plog.longwin.com.tw/news-unix/2007/01/03/netfilter_traversal_2007[24] http://lucas.hispalinux.es/htmls/manuales.html[25]http://www.controlscada.com/scada-security-checklist-free-download&rurl=translate.google.com&usg=ALkJrhgiDhH1ZozY9THjoQ7u78W[26] http://www.cpni.gov.uk/ProtectingYourAssets/scada.aspx

6.2 CONSULTADA

1.1.10 Publicaciones Escritas

INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACIÓN, Documentación. Presentación de tesis, trabajos de grado y otros trabajos de investigación. NTC 1486 sexta actualización. Bogotá, ICONTEC, 2008. 126p.

1.1.11 Libros

[5] David Bailey, Edwin Wright. Practical SCADA for Industry. IDC Technologies. 2003. 288 p.

Prototipo de Firewall para redes Scada - … · Web viewLas maquinas virtuales Linux, cumplirán...

Documents

Transcript of Prototipo de Firewall para redes Scada - … · Web viewLas maquinas virtuales Linux, cumplirán...