Prototipo de Firewall para redes Scada

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 LORENZ
FACULTAD DE MATEMATICA E INGENIERIA
INGENIERIA DE SISTEMAS
BOGOTA
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 Proyecto
GUSTAVO ADOLFO HERAZO PEREZ
Ingeniero de Sistemas
FUNDACION UNIVERSITARIA KONRAD LORENZ
FACULTAD DE INGENIERIA DE SISTEMAS
BOGOTA D.C.
2010
Nota De Aceptación
___________________________
___________________________
___________________________
___________________________
___________________________
Presidente Del Jurado
___________________________
Jurado
___________________________
Jurado
Bogotá, 09 de diciembre de 2010
i
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
ii
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.
iii
CONTENIDO
Pág.
LISTA DE TABLAS ............................................................................................... VI
LISTA DE FIGURAS ............................................................................................ VII
GLOSARIO .......................................................................................................... VIII
INTRODUCCION ..................................................................................................... 9
1 ASPECTOS DE LA INVESTIGACION ............................................................. 11
1.1 DESCRIPCIÓN DEL PROBLEMA ........................................................................... 11
1.2 JUSTIFICACION DEL PROYECTO DE INVESTIGACION ...................................... 11
1.3 DELIMITACION ...................................................................................................... 13
1.3.1 ESPACIAL. ................................................................................................................ 13
1.3.2 CRONOLÓGICA. ........................................................................................................ 14
1.3.3 CONCEPTUAL. .......................................................................................................... 17
1.4 OBJETIVOS............................................................................................................ 17
1.4.1 GENERAL ................................................................................................................. 17
1.4.2 ESPECÍFICOS............................................................................................................ 17
2 MARCO TEORICO .......................................................................................... 18
2.1 ANTECEDENTES ................................................................................................... 18
2.1.1 HISTÓRICOS ..........................................................................................................................18
2.1.1.1 ANTECEDENTES HISTÓRICOS SCADA ............................................................................18
2.1.1.2 ANTECEDENTES HISTÓRICOS FIREWALL ......................................................................18
2.1.2 INVESTIGATIVOS ...................................................................................................................21
2.2 BASES TEÓRICAS ................................................................................................. 24
2.2.1 DEFINICIÓN DE FIREWALL ....................................................................................................24
2.2.2 DEFINICIÓN DE SISTEMA SCADA. ......................................................................................25
2.2.3 DEFINICIÓN RED SCADA. ...................................................................................................25
2.3 TEORIAS GENERICAS BASADAS EN INGENIERIA. ............................................. 26
2.3.1 ARQUITECTURA DEL FIREWALL............................................................................................26
2.3.2 ARQUITECTURA SISTEMA SCADA ......................................................................................29
2.3.3 ARQUITECTURA MODBUS/TCP............................................................................................29
3 DISEÑO METODOLÓGICO ............................................................................. 30
3.1 TIPO DE INVESTIGACION ........................................................................................ 30
3.2 ANALISIS DE LA SITUACIÓN ACTUAL .................................................................. 30
3.3 DIAGNÓSTICO DE LA SITUACIÓN ACTUAL. ........................................................ 33
3.3.1 RED SCADA ............................................................................................................ 33
3.3.2 FIREWALL................................................................................................................. 34
3.3.3 MODELO PROPUESTO ............................................................................................... 35
3.3.3.1 INTEGRACIÓN RED SCADA Y FIREWALL ............................................................... 35
3.3.3.2 ANÁLISIS DEL DISEÑO DEL FIREWALL .................................................................... 35
3.3.3.2.1 DOCUMENTO DE ANÁLISIS................................................................................. 36
3.3.3.2.1.1 REQUERIMIENTOS FUNCIONALES.................................................................... 36
3.3.3.2.1.2 REQUERIMIENTOS NO FUNCIONALES .............................................................. 37
3.3.3.2.1.3 PLANTILLA SRS (SOFTWARE REQUIREMENTS SPECIFICATION) ........................ 37
iv
3.3.3.2.1.4 CASOS DE USO ............................................................................................. 39
3.3.4 MODELO DE INTEGRACIÓN ......................................................................................... 43
4 LISTA DE CHEQUEO PARA VERIFICACIÓN Y PRUEBAS .......................... 56
5 CONCLUSIONES Y RECOMENDACIONES ................................................... 64
6 REFERENCIAS BIBLIOGRÁFICAS ................................................................ 66
6.1 REFERENCIADA .................................................................................................... 66
6.1.1 LIBROS ELECTRÓNICOS O DOCUMENTOS W EB ..................................................................66
6.2 CONSULTADA ....................................................................................................... 67
6.2.1 PUBLICACIONES ESCRITAS ..................................................................................................67
6.2.2 LIBROS ..................................................................................................................................67
v
LISTA DE TABLAS
Pág.
Tabla 1. Grupos de Investigación en Colombia referentes a Firewall o SCADA .... 21
Tabla 2. Algunas investigaciones y Comunidades ................................................. 22
Tabla 3. Soluciones comerciales de Firewalll SCADA ........................................... 23
Tabla 4. Plataformas Firewall estándar disponibles con código abierto ................. 23
Tabla 5. Comparación de Plataformas de Firewall ................................................ 24
Tabla 6. Códigos de Función de los dispositivos de control .................................. 33
Tabla 7. Plantilla SRS para análisis de Netfilter ..................................................... 42
Tabla 8. Caso de Uso N°. 001 ............................................................................... 40
Tabla 9. Caso de Uso N°. 002 ............................................................................... 41
Tabla 10. Caso de Uso N°. 003 ............................................................................. 42
Tabla 11. Lista de Chequeo ................................................................................... 56
vi
LISTA DE FIGURAS
Pág.
Figura 1. Mercado de Sistemas SCADA en la Industria OIL & GAS .................... 112
Figura 2. Actividades y tiempos del proyecto de investigación ............................ 115
Figura 3. Diagrama Cronológico de Actividades .................................................. 116
Figura 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 ............................................................ 25
Figura 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.
vii
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 ...................................................... 60
Figura 36. Verificando la accesibilidad al firewall desde al consola ....................... 60
Figura 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
viii
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.
9
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.
10
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/
11
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
12
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
13
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 problema
a. Recopilar información.
b. Estudiar la factibilidad.
c. Consulta disponibilidad de
recursos de hardware y
software.
d. Informe
2. Análisis del sistema SCADA
a. Estudiar sistemas existentes.
b. Definir
herramientas
de
software 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
HMI
c. Herramientas software para
Prototipo Firewall.
d. Diseño de Alto Nivel.
e. Informe.
4. Simulación del sistema SCADA
a. Instalación PLC y/o RTU.
b. Instalación HMI.
c. Configuración y puesta a
punto.
d. Informe.
5. Instalación del Firewall
a. Instalación básica de Firewall.
14
0-1 semana
2-4 semana
5-7 semana
8-12 semana
13-15 semana
Actividad
Semana
b. Pruebas de Conectividad.
c. Definición e implementación de
políticas de seguridad.
d. Pruebas de Funcionalidad.
e. Informe.
6. Afinamiento
16-17 semana
a. Ajuste
de
Políticas
de
Seguridad.
b. Pruebas Finales.
Figura 2. Actividades y tiempos del proyecto de investigación
15
Figura 3. Diagrama Cronológico de Actividades.
16
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.
17
2
2.1
MARCO TEORICO
ANTECEDENTES
2.1.1 Históricos
2.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.
2.1.1.2 Antecedentes Históricos FIREWALL
[5] David Bailey, Edwin Wright. Practical SCADA for Industry. IDC Technologies. 2003. 288 p.
18
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_article0918
6a00800c85ae.html
[7]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article0918
6a00800c85ae.html
19
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.
[8]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_archive_article0918
6a00800c85ae.html
[9] http://www.internetfirewall.org/article/internet-firewall-basics/the-history-of-firewalls.html
20
2.1.2 Investigativos
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
GIAR
Grupo de Investigación en Automatización y Robótica
GIAM
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000004499
Grupo de Investigación en Aplicaciones Mecatrónicas
AIC
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000002805
Automatización, Instrumentación y Control
GRIDITS
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000003200
Grupo de Investigación
Grupo
de
Investigación en
Electrónica,
Telemática,
Arquitectura del
Computador
y
Temas afines
GRITAS
GIPIS
Ingeniería
de
Sistemas UPC
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000001185
Grupo de Investigación
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000001038
Grupo de Investigación en Tecnologías Aplicadas y
Sistemas de Información
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000001045
Grupo de Investigación
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000005897
Grupo de Investigación
http://201.234.78.173:8080/gruplac/jsp/visualiza/visuali
zagr.jsp?nro=00000000002707
21
Institución /
Procedencia
Universidad Central /
Bogotá - Colombia
Universidad
Santo
Tomás de Aquino /
Bucaramanga
Colombia
Pontificia Universidad
Bolivariana
/
Bucaramanga
–
Colombia
Universidad
de
Santander
/
Santander
–
Colombia
Universidad
del
Bosque / Bogotá Colombia
Universidad
Tecnológica
de
Bolívar / Cartagena
Colombia
Universidad
Cooperativa
de
Colombia / Bogotá Colombia
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
A Holistic SCADA
Security Standard for
the
Australian Context
Exploiting
SCADA
Systems
Autor
Christopher Beggs
Procedencia / Fuente
Autralia – Universidad Edith Cowan
http://ro.ecu.edu.au/cgi/viewcontent.cgi?arti
cle=1024&context=isw
Jeremy Brown
Cyber security for
SCADA and DCS
networks
NISCC
Good Practice Guide
on
Firewall Deployment
for
SCADA
and
Process
Control
Networks
Universidad de Louisville
Seoul
http://www.powerofcommunity.net/speaker.
html
Kentucky - Estados Unidos de America
http://louisville.edu/speed/research/centersand-labs/isrl/SCADA
Reino Unido
http://www.cpni.gov.uk/docs/re-2005022300157.pdf
National
Infrastructure
Security
Co-ordination
Centre (NISCC)
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=i
ndustrial%20defender&_kt=a2a5f259ae1a-430c-9f3224255702e194&gclid=CK3v1YiXtaUCFUt
J2godPhg5Zw
[10]http://www.industrialdefender.com/news/pr/pr2010.11.04_abb_and_industrial_defender_partne
rship.php
22
Fabricante
Nombre
Fuente:
Experion R310
http://hpsweb.honeywell.com/Cultures/en
US/Products/Systems/ExperionPKS/r300
/default.htm
Honeywell Modbus TCP
Firewall / Honeywell
OneWireless Firewal
http://www.tofinosecurity.com/buy/honey
well
Adaptative Security
Appliance
http://www.cisco.com/en/US/docs/switch
es/connectedgrid/cgs2520/software/relea
se/12_2_53_ex/configuration/guide/swm
odbus.html
Tabla 4. Plataformas Firewall estándar disponibles con código abierto
Proyecto
Fuente
http://www.smoothwall.org/
SmoothWall Express
Express Open Source Firewall Project
http://www.astaro.com/
Astaro Security Gateway
http://www.censornet.com/
CensorNet
http://www.sentryfirewall.com/
Sentry Firewall
http://m0n0.ch/wall/
m0n0wall
23
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.
Tabla 5. Comparación de Plataformas de Firewall
Funcionalidad o
Característica
Licencia
Hardware - Software
Plataforma de Gestión
Bloqueo de trafico que no
coincida con reglas
configuradas
Soporte de Filtrado de
Trafico Modbus/TCP
Interfaz Gráfica
Soporte de otros
protocolos industriales
Integración con otras
funcionalidades de
seguridad (IPS, AntiX,
VPN)
Firewall
Estándar
Comercial
Comercial
Hardware y/o
Software
SI
Firewall
SCADA
Comercial
Comercial
Hardware y/o
Software
SI
SI
SI
SI
NO
SI
SI
SI
SI
NO
NO
SI
NO
SI
NO
NO
Modbusfw
GPL
Software
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
2.2.1 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
24
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.
2.2.2 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.
2.2.3 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
Programables (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:
25
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.
2.3.1 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.
[11] http://www.isecauditors.com/es/iseclab9.html
26
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.
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
[12] http://sourceforge.net/projects/modbusfw/
27
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
28
2.3.2 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.
2.3.3 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.
[13] http://www.modbustools.com/
[14]http://www.infoplc.net/Documentacion/Docu_Comunicacion/EthernetIndustrial/infoPLC_net_Et
hernet_Industrial_ModbusTCP_IP.html
29
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] .
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 maestroesclavo), 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
[15] http://sites.google.com/site/ciefim/investigaci%C3%B3ndescriptiva
30
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.
Figura 10. Trama TCP Tradicional
[17]
.
[16]http://www.dte.upct.es/personal/manuel.jimenez/docencia/GD6_Comunic_Ind/pdfs/Tema%207.
pdf
[17] http://lakuiji.blogspot.com/
31
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.
[18] http://www.freemodbus.org/index.php?idx=92
[19] http://www.netfilter.org/
32
3.3
3.3.1
DIAGNÓSTICO DE LA SITUACIÓN ACTUAL.
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
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Estado
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] http://www.supvc.com/html/article/2010/0421/342.html
33
[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
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].
[21] http://downloads.vmware.com/d/info/desktop_downloads/vmware_player/3_0
34
3.3.3
Modelo Propuesto
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] http://l7-filter.sourceforge.net/PacketFlow.png
35
[22]
3.3.3.2.1
Documento de Análisis
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]
[23] http://plog.longwin.com.tw/news-unix/2007/01/03/netfilter_traversal_2007
36
3.3.3.2.1.2
Requerimientos no Funcionales
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
recomienda Red Hot Enterprise v5.)
Se requiere que el usuario tenga conocimientos básicos de Linux y del
funcionamiento 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
37
38
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.
39
Figura 14. Caso de uso Firewall SCADA
Tabla 8. Caso de Uso N°. 001
CU-001
Objetivos
asociados
Requisitos
asociados
Administración de Políticas
Operar las diferentes funciones permitidas para la
administración de las políticas o reglas de filtrado de
paquetes
Tener instalado el sistema operativo con el modulo de
firewall y kernel compatible adecuado (En este caso Trinux
2.4.26)
40
Descripción
Precondición
Secuencia
Normal
Postcondición
Excepciones
Frecuencia
esperada
Estabilidad
Comentarios
El sistema deberá permitir la administración adecuada de
las políticas de filtrado
Deben existir los requerimientos mínimos de Hardware. Y
contar con la imagen .iso de trinux
Paso
Acción
1
El Administrador crea una regla.
2
El Administrador elimina regla regla.
3
El Administrador edita una regla.
Al verificar en la el funcionamiento de las reglas con el
flujo de trafico se debe realizar el filtrado conforme las
reglas configuradas.
Paso
Acción
1
Si el firewall la imagen .iso de sistema
operativo trinux no inicia este caso de uso
termina.
Cada vez que se inicia la maquina del firewall
Media
En caso de algún fallo de la instalación, se recomienda
revisar la página http://modbusfw.sourceforge.net/
Tabla 9. Caso de Uso N°. 002
CU-002
Objetivos asociados
Requisitos asociados
Descripción
Precondición
Secuencia
Normal
Postcondición
Excepciones
Módulo de Routing
Realiza el enrutamiento del trafico que pasa por el
firewall.
Existencia del kernel de Linux v2.4.x.
El sistema deberá comportarse tal como se describe
en el siguiente caso de uso cuando el administrador
desee administrar las rutas del firewall.
Debe estar operativa la distribución Trinux.
Paso Acción
1
El Administrador verifica las rutas existentes.
2
El Administrador adiciona rutas en caso de
requerirse
3
El Administrador elimina rutas en caso de
requerirse
El firewall debe estar direccionando el tráfico
adecuadamente.
Paso Acción
41
1
Frecuencia esperada
Estabilidad
Comentarios
Si el módulo de enrutamiento no se
encuentra presento o no está activo este
caso de uso termina.
Cada vez que se requiera modificar alguna ruta.
Alta
En caso de algún fallo de la instalación, se
recomienda revisar la página
http://modbusfw.sourceforge.net/
Tabla 10. Caso de Uso N°. 003
CU-003
Objetivos asociados
Requisitos asociados
Descripción
Precondición
Secuencia
Normal
Postcondición
Excepciones
Frecuencia esperada
Estabilidad
Módulo Modbusfw
Filtrar tráfico mosbus/tcp.
Existencia del kernel de Linux v2.4.x. y del modulo
modbusfw.
El sistema deberá comportarse tal como se describe
en el siguiente caso de uso cuando el administrador
desee realizar filtrado de paquetes modbus/TCP.
Debe estar operativa la distribución Trinux, así como
instalado y operativo el modulo modbusfw.
Paso Acción
1
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.
Al entrar en Trinux se deben poder configurar las
reglas para Modbus/TCP usando los comandos
establecidos para ello.
Paso Acción
1
Si el Módolo modbusfw no se encuentra
activo esta caso de uso termina
1 vez (Una vez instalado y configurado el módulo no
hay necesidad de volver a cargarlo).
Alta
42
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.
b.
c.
d.
Windows_XP_A
Windows_XP_B
Linux Red Hat Enterprise 5
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
43
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/bash
clear
echo "**************************************************"
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
44
echo "Digite la máscara de la interface de entrada Firewall:";
read msin
echo "Digite la Ip de interface de salida Firewall:"; read ipout
echo "Digite la máscara de la interface de salida Firewall:"; read
msout
echo ""
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.sh
cat /proyecto/head.txt >> /proyecto/inicia.sh
echo "ifconfig eth0 $ipin netmask $msin up" >> /proyecto/inicia.sh
echo "ifconfig eth1 $ipout netmask $msout up" >>
/proyecto/inicia.sh
cat /proyecto/regla0.txt >> /proyecto/inicia.sh
clear
/proyecto/addreglas.sh
cat /proyecto/tail.txt >> /proyecto/inicia.sh
echo ""
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/bash
echo "**************************************************"
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 up
ifconfig 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
45
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -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 ACCEPT
iptables -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
ACCEPT
#iptables -A FORWARD -s 10.10.1.2 --sport 80 -d 10.10.2.2 -j
ACCEPT
# 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 ACCEPT
iptables -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 ACCEPT
echo ""
echo "Se ha configurado las tarjetas de Red Correctamente y se han
cargado las configuraciones iniciales ..."
echo ""
46
Archivo sddreglas.sh
#!/bin/bash
echo "Configuracion de la regla 1 del Firewall"
echo "Configuracion de servicio generales ej: RDP(3389)"
echo ""
echo "Digite la ip del equipo origen:" ; read iporg
echo "Digite la ip del equipo destino:" ; read ipdes
echo "Digite el puerto del servicio a permitir:" ; read puerto
echo "iptables -A FORWARD -s $iporg -p tcp --dport $puerto -d
$ipdes -j ACCEPT" >> /proyecto/inicia.sh
echo "iptables -A FORWARD -s $ipdes -p tcp --sport $puerto -d
$iporg -j ACCEPT" >> /proyecto/inicia.sh
echo ""
echo "Configuracion de function_code de ModBus"
echo "-- Configuracion Ambos sentidos:"
echo "Digite el funct_code para habilitar:"; read fcd1
echo "iptables -A FORWARD -p tcp -m modbus --funccode $fcd1 -allowtcp 1 -j ACCEPT" >> /proyecto/inicia.sh
echo ""
echo "-- Configuracion en un solo sentido:"
echo "Digite la ip del equipo origen:" ; read iporg1
echo "Digite la ip del equipo destino:" ; read ipdes1
echo "Digite el funct_code para habilitar:"; read fcd2
echo "iptables -A FORWARD -s $iporg1 -p tcp -m modbus --funccode
$fcd2 --allowtcp 1 -d $ipdes1 -j ACCEPT" >> /proyecto/inicia.sh
echo ""
echo "Se ha terminado de configurar las Reglas personalizadas"
echo ""
Archivo finconsola.sh
#!/usr/bin/bash
echo "**************************************************"
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 ACCEPT
iptables -D OUTPUT -d 192.168.0.2 -j ACCEPT
echo " Se ha cerrado conexion con la consola de configuracion"
echo ""
echo "VERIFICANDO ..."
iptables -L
47
Archivo reset.sh
#!/usr/bin/bash
echo "**************************************************"
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 -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
echo " Se Ha reseteado con exito"
echo ""
echo "VERIFICANDO ..."
iptables -L
Archivo head.txt
echo
echo
echo
echo
echo
echo
echo
"******************************************************"
"*
CONFIGURACION DEL FIREWALL
*"
"*
UNIVERSIDAD KONRAD LORENZ
*"
"*
PROYECTO DE GRADO: PROTOTIPO DE FIREWALL SCADA *"
"*
POR: JHONNY LOPEZ
*"
"******************************************************"
""
Archivo regla0.txt
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -s 192.168.0.2 -j ACCEPT
iptables -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
ACCEPT
#iptables -A FORWARD -s 10.10.1.2 --sport 80 -d 10.10.2.2 -j
ACCEPT
# Regla de funcode de modbus general
#iptables -A FORWARD -p tcp -m modbus --funccode 1 --allowtcp 1 -j
ACCEPT
Archivo tail.txt
48
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
49
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
50
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.
51
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
52
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.
53
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
54
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
55
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
1
2
3
4
5
6
7
8
9
10
11
Activity
Identify all connections to SCADA networks
Disconnect unnecessary connections to the SCADA network
Evaluate and strengthen the security of any remaining connections to the
SCADA network
Harden SCADA networks by removing or disabling unnecessary services
Do not rely on proprietary protocols to protect your system
Implement the security features provided by device and system vendors
Establish strong controls over any medium that is used as a backdoor into the
SCADA network
Implement internal and external intrusion detection systems and establish 24hour-a-day incident monitoring
Perform technical audits of SCADA devices and networks, and any other
connected networks, to identify security concerns
Conduct physical security surveys and assess all remote sites connected to the
SCADA network to evaluate their security
Establish SCADA “Red Teams” to identify and evaluate possible attack
scenarios
[25]http://www.controlscada.com/scada-security-checklist-freedownload&rurl=translate.google.com&usg=ALkJrhgiDhH1ZozY9THjoQ7u78W
56
Status
OK
OK
OK
OK
OK
N/A
OK
N/A
OK
N/A
N/A
12
13
14
15
16
17
18
19
20
21
Clearly define cyber security roles, responsibilities, and authorities for
managers, system administrators, and users
Document network architecture and identify systems that serve critical functions
or contain sensitive information that require additional levels of protection
Establish a rigorous, ongoing risk management process
Establish a network protection strategy based on the principle of defense-indepth
Clearly identify cyber security requirements
Establish effective configuration management processes
Conduct routine self-assessments
Establish system backups and disaster recovery plans
Senior organizational leadership should establish expectations for cyber
security performance and hold individuals accountable for their performance
Establish policies and conduct training to minimize the likelihood that
organizational personnel will inadvertently disclose sensitive information
regarding SCADA system design, operations, or security controls
N/A
OK
N/A
N/A
N/A
N/A
OK
OK
N/A
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.
57
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
58
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
59
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
60
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.
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
61
11. Establecer “Equipos Rojos” SCADA para identificar y evaluar posibles
escenarios de ataque
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
12. Definir claramente los roles de seguridad cibernética, responsabilidades y
autoridades para los gerentes, los administradores de sistemas y usuarios
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
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
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
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
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
17. Establecer una gestión eficaz de los procesos de configuración
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
18. Llevar a cabo la rutina de auto-evaluación
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
62
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
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
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,
No Aplica ya que no el proyecto obedece a la implementación de un
prototipo y no a un sistema en producción.
63
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
seguridad 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 empresariales, 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
comerciales y especializadas en redes de este tipo ya que estas son las que en la
actualidad se encuentran más desarrolladas y por tanto mitigan de mejor forma
las vulnerabilidades 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 ambiente 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
especializadas
64
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
65
6
6.1
REFERENCIAS BIBLIOGRÁFICAS
REFERENCIADA
6.1.1 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_arc
hive_article09186a00800c85ae.html
[7]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_arc
hive_article09186a00800c85ae.html
[8]http://www.cisco.com/web/about/ac123/ac147/ac174/ac200/about_cisco_ipj_arc
hive_article09186a00800c85ae.html
[9]
http://www.internetfirewall.org/article/internet-firewall-basics/the-history-offirewalls.html
[10]http://www.industrialdefender.com/news/pr/pr2010.11.04_abb_and_industrial_d
efender_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/i
nfoPLC_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/p
dfs/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-freedownload&rurl=translate.google.com&usg=ALkJrhgiDhH1ZozY9THjoQ7u78W
[26] http://www.cpni.gov.uk/ProtectingYourAssets/scada.aspx
66
6.2
CONSULTADA
6.2.1 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.
6.2.2 Libros
[5] David Bailey, Edwin Wright. Practical SCADA for Industry. IDC Technologies.
2003. 288 p.
67