UNIVERSIDAD TCNICA PARTICULAR DE LOJA

La Universidad Catlica de Loja

Escuela de Ciencias de la Computacin

Modalidad Clsica

TEMA:

ANLISIS DEL TRFICO MALICIOSO DE LOS SERVICIOS EXTERNOS DE LA UTPL

TESIS PREVIA A LA OBTENCIN DEL TTULO DE INGENIERO EN SISTEMAS INFORMTICOS Y COMPUTACIN

Autor: Csar Augusto Montalvn Celi

Director: Msc. Mara Paula Espinoza

Loja - Ecuador 2010

Msc. Mara Paula Espinoza DOCENTE INVESTIGADOR DE LA ESCUELA DE CIENCIAS DE LA COMPUTACIN DE LA UNIVERSIDAD TCNICA PARTICULAR DE LOJA

CERTIFICA:

Que una vez concluido el trabajo de investigacin con el tema ANLISIS DEL TRFICO MALICIOSO DE LOS SERVICIOS EXTERNOS DE LA UTPL previa la obtencin del ttulo de Ingeniero en Sistemas Informticos y Computacin, realizado por el seor Csar Augusto Montalvn Celi egresado de la Escuela de Ciencias de la Computacin; haber dirigido, supervisado y asesorado en forma detenida cada uno de los aspectos de la tesis de pregrado. Adems, en mi calidad de DIRECTOR DE TESIS y al encontrar que se han cumplido con todos los requisitos investigativos, autorizo su presentacin y sustentacin ante el tribunal que se designe para el efecto.

Atentamente,

--------------------Ing. Mara Paula Espinoza DIRECTOR DE TESIS

CESIN DE DERECHO

Yo, Csar Augusto Montalvn Celi, declaro conocer y aceptar la disposicin del Art. 67 del Estatuto Orgnico de la Universidad Tcnica Particular de Loja, que en su parte pertinente textualmente dice: Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos cientficos o tcnicos y tesis de grado que se realicen a travs o con el apoyo financiero, acadmico o institucional (operativo) de la Universidad.

_____________________ Csar A. Montalvn Celi

AUTORA

Las ideas, opiniones, conclusiones, recomendaciones y ms contenidos expuestos en el presente informe de tesis son de absoluta responsabilidad del autor.

_____________________ Csar A. Montalvn C.

DEDICATORIA

A mis padres Gladys y Samuel por creer en m, por brindarme su cario y apoyo incondicional, y a mis hermanos Nora, Henrry, Eduardo y Leonardo que son mi impulso para seguir adelante.

Csar A.

AGRADECIMIENTOS

Mis ms sinceros agradecimientos a todas las personas que me apoyaron, y de una u otra manera han contribuido a la culminacin de este proyecto de fin de carrera, y de manera especial a la Msc. Mara Paula Espinoza, Directora de Tesis, que con su conocimiento, empeo y motivacin, fue la tutora y gua durante el desarrollo del presente trabajo de investigacin.

Gracias

ndice General
ndice de figuras ndice de cuadros 2 3

I Introduccin II Objetivos III Estructura de la tesis

4 6 7

1. Anlisis de la situacin actual tanto a nivel de honeynet como servicio de la UTPL 9 1.1. Estudio del Esquema actual de la Honeynet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 1.1.1. Revisin del estado del arte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1.2. Revisin de la Arquitectura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.1.3. Revisin del Software y Hardware utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1.4. Resultados obtenidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2. Identificacin de los servicios crticos externos de la UTPL. . . . . . . . . . . . . . . . . . . . 15 1.2.1. Inventario de servicios y evaluacin de su criticidad. . . . . . . . . . . . . . . . . . . . . . . . .16 1.2.2. Revisin de caractersticas: plataformas, versiones, aplicaciones, trfico. . . . . . . 18 1.2.3. Revisin de problemas de seguridad relacionados. . . . . . . . . . . . . . . . . . . . . . . . . 18 2. Implementacin de los servicios crticos externos en la honeynet. 23 2.1. Estudio de Honeynets virtuales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.1. Clasificacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.1.2. Virtualizacin y Herramientas de Virtualizacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2. Anlisis del Hardware disponible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.1. Equipos virtuales a implementar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 2.3. Anlisis de red de la Honeynet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 2.3.1. Esquema de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 2.3.2. Configuracin de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.3. Esquema de red honeynet en VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.4. Configuracin del equipo anfitrin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.4. Honeywall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.1. Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.2. Instalacin de Honeywall CD roo-1.4.hw-20090425114538. . . . . . . . . . . . . . . . . . . 32 2.4.3. Configurando el Honeywall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 2.5. Interface GUI Walleye . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.6. Sebek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 2.6.1. Instalacin y configuracin de Sebek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.6.2. Parmetros y/o variables Sebek a configurar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.7. Implementacin de servicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 2.8. Problemas de implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 2.8.1. Instalacin de Sebek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 2.8.2. Instalacin de las mismas versiones de las aplicaciones. . . . . . . . . . . . . . . . . . . . . 42 2.9. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3. Recoleccin de datos 47 3.1. Subsistemas de una Honeynet de Generacin III. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.1.1. Control de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 3.1.2. Captura de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1.3. Anlisis de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

3.2. Anlisis de servicios, aplicaciones y vulnerabilidades de los servidores. . . . . . . . . . . 51 3.2.1. Exploracin de servicios y aplicaciones con nmap y nessus. . . . . . . . . . . . . . . . . . .51 3.3. Herramientas utilizadas para el anlisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.1. Wireshark y Geolocalizacin de direcciones IP remotas. . . . . . . . . . . . . . . . . . . . . . 52 3.3.2. Anlisis con NetworkMiner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4. Anlisis, interpretacin y presentacin de resultados. 56 4.1. Reportes mensuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 4.1.1. Reportes mes de Agosto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 4.1.2. Reportes mes de Septiembre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 4.1.3. Anlisis de los reportes mensuales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 4.2. Actividad en lo+s servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.1. Servidor DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.2. Servidor WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 4.2.3. Servidor EVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.4. Servidor WSUTPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.3. Actividades registradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 4.3.1. Alertas Snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 4.3.2. Ataques de diccionario al puerto ssh (port 22) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.3.3. Actividades maliciosas/sospechosas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4. Incidentes registrados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.4.1. Ataque DOS a la red de la UTPL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.5. Patrones de comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Discusin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Conclusiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .77 Recomendaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Trabajos Futuros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Referencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 83 Anexos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 85

Estudio del trco malicioso en los a servicios cr ticos externos de la UTPL

Csar A. Montalvn C.* e a 10 de noviembre de 2010

* [email protected]

 Indice de guras
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. Clasicacin de honeynets por su Nivel de Interaccin.[3] . . . . o o Ubicacin de la honeynet en la red[7]. . . . . . . . . . . . . . . . o Red actual de la UTPL[7]. . . . . . . . . . . . . . . . . . . . . . . Honeynet virtual autocontenida.[17] . . . . . . . . . . . . . . . . Honeynet virtual h` brida.[17] . . . . . . . . . . . . . . . . . . . . Esquema de red de la honeynet virtual . . . . . . . . . . . . . . . Esquema de red y conguracin de la honeynet virtual . . . . . . o Puente de red entre Conexion de Area Local y VMnet1 . . . . . Honeywall - Main Men . . . . . . . . . . . . . . . . . . . . . . . u Diagrama de recoleccin y fusin de datos.[22] . . . . . . . . . . . o o Interfaz GUI Walleye . . . . . . . . . . . . . . . . . . . . . . . . . Interfaz GUI Walleye - cambio de contrasea . . . . . . . . . . . n Interfaz GUI Walleye . . . . . . . . . . . . . . . . . . . . . . . . . Interface Walleye en funcionamiento . . . . . . . . . . . . . . . . Sebek, arquitectura cliente-servidor[23] . . . . . . . . . . . . . . . Problema con Sebek, volcado de memoria . . . . . . . . . . . . . Problema con Sebek, ./parameters.sh . . . . . . . . . . . . . . . . Problema con Sebek, install failed . . . . . . . . . . . . . . . . . Subsistemas del Honeywall.[25] . . . . . . . . . . . . . . . . . . . Geolocalizacin de direcciones IP remotas . . . . . . . . . . . . . o NetworkMiner como herramienta de anlisis . . . . . . . . . . . . a Total paquetes mes de Agosto . . . . . . . . . . . . . . . . . . . . Total paquetes mes de Agosto . . . . . . . . . . . . . . . . . . . . Total puertos probados en el mes de Agosto. . . . . . . . . . . . . Direcciones IP atacantes - Agosto. . . . . . . . . . . . . . . . . . Total paquetes mes de Septiembre . . . . . . . . . . . . . . . . . Total paquetes mes de Septiembre . . . . . . . . . . . . . . . . . Total puertos probados en el mes de Septiembre. . . . . . . . . . Direcciones IP atacantes - Septiembre. . . . . . . . . . . . . . . . Ataque de diccionario al puerto 22 ssh . . . . . . . . . . . . . . . Ataque de diccionario al puerto 22 ssh analizado con Wireshark . Ataque de diccionario al puerto 22 ssh registrado en la interface GUI Walleye . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instalacin de un backdoor . . . . . . . . . . . . . . . . . . . . . o Puerto que han sido abierto en el Honeypot comprometido. . . . Connection Limiting - Control de Datos. . . . . . . . . . . . . . . Connection Limiting - Prueba de conexin. . . . . . . . . . . . . o Fence List - Control de Datos. . . . . . . . . . . . . . . . . . . . . Fence List - Prueba de conexin. . . . . . . . . . . . . . . . . . . o 11 12 15 25 25 28 30 31 33 34 34 35 35 36 37 39 41 41 46 52 53 55 56 56 57 58 59 59 60 66 66 67 67 69 70 71 71 72

 Indice de cuadros
1. 2. 3. 5. 6. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Generaciones Honeynets.[5] . . . . . . . . . . . . . . . . . . . . . Caracter sticas de los servidores externos. . . . . . . . . . . . . . Caracter sticas de la mquina antrin . . . . . . . . . . . . . . . a o Caracter sticas de los servidores externos. . . . . . . . . . . . . . sbk install.sh, variables Sebek a congurar. . . . . . . . . . . . . Aplicaciones soportadas que han sido instaladas. . . . . . . . . . Servicios, puertos y aplicaciones instaladas en el Servidor DNS. . Servicios, puertos y aplicaciones instaladas en el Servidor Web. . Servicios, puertos y aplicaciones instaladas en el Servidor EVA. . Servicios, puertos y aplicaciones instaladas en el Servidor WSUTPL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Puertos escaneados/probados. Agosto . . . . . . . . . . . . . . . IPs atacantes - Agosto. . . . . . . . . . . . . . . . . . . . . . . . . Puertos escaneados/probados. Septiembre . . . . . . . . . . . . . IPs atacantes - Septiembre. . . . . . . . . . . . . . . . . . . . . . Alertas ICMP generadas por Snort. . . . . . . . . . . . . . . . . . Alertas a otros protocolos generadas por Snort. . . . . . . . . . . 11 18 27 28 38 42 50 50 51 51 57 58 60 61 65 65

Parte I

Introduccin o
Actualmente, la seguridad en los sistemas informticos se ve cada vez ms a a afectada y puesta en peligro por el desarrollo y avance de nuevas tecnolog as, convirtiendola a la seguridad informtica en un rea elemental e importante en a a la proteccin de una infraestructura computacional. Los riesgos van en aumento o y cada vez los mtodos, herramientas, tcnicas, etc. que son utilizados, son ms e e a sosticados. Como medida para contrarrestar y tratar de minimizar estos riesgos, son empleados mtodos de seguridad tradicionales, como lo son: la utilizacin de e o Firewalls, Listas de Control de Acceso (ACLs), Sistemas de Deteccin de Intruo sos (IDS), Redes Virtuales Privadas (VPN), antivirus, etc. los cuales sirven de proteccin a la organizacin contra los atacantes,como dispositivos de deteccin o o o y bloqueo de ataques de red, y como medidas reactivas, es decir, que la respuesta al incidente se la da una vez que el incidente ya se ha presentado, pero en temas de seguridad y proteccin a la informacin casi nada es suciente. o o Conjuntamente con el desarrollo de las nuevas tecnolog as, tambin van e surgiendo herramientas en cuanto a proteccin contra atacantes de red se reo ere, en procura de mantener la seguridad y la alta disponibilidad de los sistemas informticos. a Es as que surgen las Honeynets, como herramientas que pretenden mejorar la seguridad y se transforman en una estratgia para resguardar la informacin. e o Se trata de mecanismos, que nos permiten capturar y aprender de las actividades de red que se registran, con ello la formacin de patrones y perles de los intrusos o de la red. Cada ataque, intrusin o incidente representa una forma de obtener y alcano zar el conocimiento para poder de alguna manera entender el comportamiento de un atacante y estar preparados para recibir estos ataques la siguiente vez, esta vez ya de una forma proactiva, lo cual puede ayudar en sobre medida. Ya que un honeypot, se trata de un recurso de red a ser comprometido por ser voluntariamente vulnerable, y que est a vista de los atacantes, es el punto a central de una Honeynet por la capacidad de recoleccin de informacin imporo o tante acerca de los intrusos, con la cual se pueden determinar tipos de ataques, mtodos y tambin poder observar y conocer las propias vulnerabilidades y los e e riesgos a los que se encuentra expuestos los sistemas en produccin, con esto, el o administrador o administradores estar prevenidos y puedan tomar las medidas necesarias del caso, para evitar situaciones indeseables. En el presente trabajo, se pretende continuar con el desarrollo, investigacin o y explotacin de estas tecnolog en una de sus formas, las Honeynets Virtuales, o as las cuales mantienen el mismo concepto de las Honeynets clsicas, pero sus a ventajas podr ser signicantes al momento de utilizarlas. an Asi mismo, en base a esta estructura, se busca capturar y monitorear el trco que se genera hacia los servidores externos de la UTPL, mediante la a

simulacin de estos entornos, con el f de buscar actividades y comportamientos o n maliciosos para que puedan ser evitadas en un entorno real en un futuro. As tambin , el estudio realizado permitir generar nuevos campos de in e a vestigacin en seguridad informtica en la UTPL y el desarrollo del Grupo de o a Seguridad - UTPL.

Parte II

Objetivos
Objetivo General Establecer el nivel de exposicin y seguridad de los servicios externos de la o UTPL y determinar patrones de comportamiento anmalos y/o dainos. o n Objetivos Espec cos Estudio de los servicios externos de la UTPL y su nivel de criticidad a f n de ser implementados en la Honeynet para su posterior anlisis. a Implementacin de un prototipo de Honeynet Virtual como fuente de ino formacin de las actividades de red hacia los servidores. o Buscar explotar las Honeynets como herramientas innovadoras de seguridad proactiva. Tener en la Honeynet Virtual una herramienta para la generacin de reo portes y estad sticas de los datos recolectados. Buscar generar informacin y conocimiento en base a los resultados obtenidos. o Anlisis del trco de red malicioso de los servicios cr a a ticos externos de la UTPL. Informar, alertar y comunicar datos, hechos o incidentes importantes recolectados a los administradores para que se puedan tomar las medidas necesarias.

Parte III

Estructura de la tesis
La tesis est estructurada de la siguiente manera: a Una introduccin general sobre lo que es el proyecto, el trabajo realizado, los o objetivos trazados y lo que se pretende conseguir a la culminacin del mismo. o En el capitulo 1, titulado: Anlisis de la situacin actual tanto a nivel de a o honeynet como servicio de la UTPL, se trata acerca de la revisin del estado o de arte, conceptos, deniciones, funcionamiento, arquitecturas, etc., acerca de las tecnolog Honeynet. Se contempla el anlisis de los servicios externos de as a la UTPL, para la evaluacin de su nivel de criticidad. Tambin se ha realizado o e un anlisis sobre la tesis previa: ESTUDIO DE TRAFICO DE ATAQUES A a LA RED DE LA UTPL MEDIANTE UN PROTOTIPO DE HONEYPOT, los resultados obtenidos de la misma, para en base a estos, poder desarrollar el proyecto. En el capitulo 2, titulado: Implementacin de los servicios cr o ticos externos en la honeynet, se trata primeramente acerca del estudio de las tcnologias de e virtualizacin, sus deniciones, su utilizacin en Honeynets y la clasicacin de o o o Honeynets virtuales, luego el hardware disponible para poder montar la Honeynet virtual Auto-contenida, es decir dentro de un solo equipo, seleccionada por cuestiones de recursos hardware y espacio, y la conguracin necesaria, en o cuanto a tema de red se reere; conceptos, requerimientos, benecios. Luego se procede con las instalaciones de todos los elementos de la Honeynet Virtual, mquinas virtuales, switchs virtuales, puentes, hardware virtual, etc. Seguidaa mente, la implementacin de los servicios cr o ticos seleccionados en el capitulo 1, en cada una de las mquinas virtuales, as tambien como la implementacin y a o puesta en marcha del equipo Honeywall. Finalmente se concluye este cap tulo con la fase de pruebas, para comprobar la funcionalidad de todos los componentes de la Honeynet virtual. El capitulo 3, titulado: Recoleccin de datos, es el capitulo que trata acerca o del Control, Captura y Anlisis de datos, en s aborda temas de conguracin a , o y funcionamiento de la Honeynet Virtual, las herramientas que lo componen y el mtodo utilizado para la recoleccin de la informacin. e o o En el capitulo 4, titulado: Anlisis, interpretacin y presentacin de resula o o tados, se realiza una revisin de herramientas que se utilizan para el anlisis de o a los datos, a su vez, tambien se hace una reconocimiento de las aplicaciones y los servicios instalados, para vericar los puertos que se podr ver afectados por an cada servidor. Finalmente, se hace una presentacin de reportes con las actividades rego istradas de la Honeynet, anlisis del trco generado, puertos utilizados/probados, a a direcciones IP de las cuales han intentado acceder, actividades por cada uno de los protocolos implementados, recogimiento de alertas de Snort, descubrimientos de hallazgos, entre otras cosas.

CAPITULO I
ANALISIS DE LA SITUACION ACTUAL TANTO A NIVEL DE HONEYNET COMO SERVICIO DE LA UTPL

1.
1.1.
1.1.1.

Anlisis de la situacin actual tanto a nivel a o de honeynet como servicio de la UTPL

Estudio del Esquema actual de la Honeynet
Revisin del estado del arte o

Generalmente en las organizaciones, la proteccin de la informacin es uno o o de los principales aspectos que se toman en cuenta al momento de montar sus sistemas computacionales; para realizar este trabajo son empleados Firewalls, IDS (Sistemas de Deteccin de Intrusos), as tambin mecanismos de encriptacin o e o como medidas defensivas para mantener y garantizar la seguridad de la informacin, es decir; las medidas de reaccin y recuperacin se toman luego de o o o que fallos o ataques o algn incidente en algn equipo han sido detectados. De u u esta manera, el enemigo tendr siempre la iniciativa y la victima estar a sus a a expensas. Honeynet es una estructura que intenta cambiar este esquema. Se trata de una red trampa la cual tiene la misin de recolectar toda la informacin o o sobre las amenazas que se presentan en la red, informacin que es utilizada con o nes investigativos y de aprendizaje. Esta estructura crea una red altamente controlada, que puede inspeccionar y supervisar toda la actividad que ocurre dentro de l.[1] e Adems, proporcionan un terreno frtil para los temas de investigacin ina e o cluyen: las bases de datos, agentes distribuidos, anlisis de datos, tecnolog de a a agentes, los fundamentos de la red y temas avanzados.[2] El trabajo realizado en esta primera parte tiene como objetivo la recoleccin o de informacin acerca de la estructura honeynet implementada en la red de o la UTPL. Se ha vericado principalmente conceptos y deniciones acerca de estas arquitecturas, as como la informacin acerca de los servicios y servidores o para el estudio de su nivel de criticidad en la red a n de ser implementado en la honeynet y poder estudiar las vulnerabilidades y riesgos a los que estn a expuestos en un ambiente de produccin. o Se ha revisado la situacin actual de la honeynet y su ubicacin dentro de la o o red de la Universidad, ventajas, desventajas e inconvenientes, adems del estua dio de los resultados obtenidos por la honeynet a partir de su implementacin o desde el mes de Febrero del 2009 en la red de la UTPL. Tipos de Honeypots Los honeypots1 se clasican de la siguiente manera:[3] Por su funcin o uso o
Honeypots de Produccin o

Detectar nuevos tipos de ataques y herramientas de hacking.

1 Recurso

de red a ser atacado o comprometido. Lance Spitzner, Honeypots: Tracking Hack-

ers, 2003.

 Obtener mayor conocimiento de los atacantes (objetivos, actividades, etc.) y tendencias. Desarrollar nuevas signatures de IDSs.
Honeypots de Investigacin o

Distraer al atacante del objetivo real (ganar tiempo para proteger el ambiente de produccin). o Recolectar suciente evidencia contra un atacante (controvertido). Por su grado de interaccin o
Bajo Nivel de Interaccin o

Minimizan el riesgo considerablemente. La informacin obtenida es muy limitada. o Fciles de instalar y mantener. a No hay un sistema operativo sobre el cual el atacante pueda interactuar. T picamente slo proveen servicios falsos o emulados. o
Medio Nivel de Interaccin o

Brinda mayor interaccin pero sin llegar a proveer un sistema o operativo sobre el cual interactuar. Los demonios que emulan los servicios son ms sosticados y a brindan mayores posibilidades de interaccin. o El atacante obtiene una mejor ilusin de un sistema operativo o real y mayores posibilidades de interactuar y escanear el sistema. El desarrollo/implementacin es ms complejo y consume ms o a a tiempo.
Alto Nivel de Interaccin o

Cuentan con un sistema operativo real. Presentan un mayor nivel de riesgo y complejidad. Son objetivos ms atractivos a ser atacados. a Se obtiene mayor y mejor informacin de los atacantes. o Requiere de mucho tiempo para instalar y mantener.

En la siguiente gura se muestra un cuadro comparativo entre los honeypots clasicados por su nivel de interaccin: o

10

Figura 1: Clasicacin de honeynets por su Nivel de Interaccin.[3] o o Arquitectura de una Honeynet Con el tiempo las honeynets han evolucionado y han surgido diferentes generaciones: GenI, GenII y Gen III. GenI (para la primera generacin) explica como el Honeynet Project impleo ment por primera vez estos requisitos, desde 1999 al 2001. Basto y simple a la o vez, fue muy efectivo en su tarea, capturando la mayor de los ataques que se a produjeron en Internet; gusanos, script kiddies, sondeos automticos, etc. En el a 2002 el Honeynet Project empez a desarrollar nuevas herramientas y tcnicas, o e llamadas GenII (en referencia a la segunda generacin). o Estas tcnicas, siguiendo sus mismos requisitos, han ampliado enormemente e sus capacidades. Las tecnolog de GenII dan a las organizaciones la habilidad as de capturar las actividades de agresores ms avanzados.[4] a Una tercera Generacin de Honeynets nace en el 2003, la cual se caracteriza o por hacer la integracin del anlisis de datos en un mismo dispositivo Honeywall, o a con lo cual se hace ms sencilla la utilizacin y mantenimiento de una Honeynet. a o En la siguiente gura se pueden evidenciar las diferencias entre estas Generaciones de Honeynets: Cuadro 1: Generaciones Honeynets.[5]

11

El uso de honeynets tiene grandes ventajas, pueden ayudar a mejorar la seguridad de la red, con la informacin recolectada se pueden armar perles y o el modus operandi de los atacantes, las herramientas empleadas para realizar ataques, los procedimientos empleados, descubrir, entender mejor y protegerse de las amenazas a la que est expuesta, entre otras cosas; su desventaja es que a una conguracin errnea puede traer muchas consecuencias negativas, cono o virtindose en un riesgo potencial para la red, otro problema es que muchos e recursos, son dif ciles de construir y complejas de mantener.[6] Del estudio y trabajo realizado en base a la tesis[7] se pueden destacar los siguientes puntos a considerar: 1.1.2. Revisin de la Arquitectura o

Una honeynet es un conjunto de honeypots con una arquitectura clienteservidor, en la cual los honeypots (clientes) son agentes expuestos a ataques y amenazas los que enviaran la informacin recogida a un servidor centralizado. o La honeynet implementada actualmente consta de tres equipos en total: dos equipos que actan como honeypots y un equipo central que hace las funciones u de servidor central. Los honeypots al ser empleados como seuelos, debern presentar ciertas n a fallas, bugs, y/o vulnerabilidades conguradas a propsito. Por ello tambin es o e importante que la ubicacin de los mismos deba hacerse donde la red de proo duccin no est expuesta, puesto que podr ser comprometidos y ser utilizados o e an en su contra. En base al anlisis elaborado previamente en[7], la honeynet se ha ubicado fuera a de la red de produccin ya que en sta se ubican servicios sensibles y muy suso e ceptibles a ataques. Con esta ubicacin se elimina el riesgo de seguridad y las o posibilidades que estos equipos sean comprometidos. El esquema es el que se presenta en la siguiente gura:

Figura 2: Ubicacin de la honeynet en la red[7]. o

12

1.1.3.

Revisin del Software y Hardware utilizado o

Para poder implementar una red trampa o honeynet se hace uso mayormente del Honeywall CDROM[8]. Se trata de un CD de arranque que contiene todas las herramientas necesarias para crear y utilizar una honeynet gateway (pasarela de red trampa) de segunda generacin. El CDROM est basado en una versin reducida de Linux o a o y est diseado para ser utilizado como aplicacin: contiene slo las herramiena n o o tas necesarias para gestionar el Honeywall. Un entorno de conguracin (cuso tomization) permite a los usuarios avanzados aadir acracter n sticas al CDROM que hace posible que las herramientas del mismo puedan ser utilizadas fuera de la red trampa.[9] A continuacin se describen las herramientas que emplea honeywall para el o control captura y anlisis de trco en la Honeynet. a a - Captura de datos: Snort.- NIDS que lanza alarmas de ataques conocidos que son detectados por sus sensores. Snort Inline.- NIPS que previene ataques detectados por snort, est basado a en snort y puede ser congurado para realizar alguna accin espec o ca sobre los paquetes atacantes. Iptables.- Reglas de rewall que permiten regular las conexiones de entrada y/o salida. Proxy ARP.- Permite dar acceso a internet a los honeypots ubicados en la red trampa. P0F (Passive OS ngerprinting).- Recoge informacin sobre el sistema o operativo de un host. Sebek.- Aplicacin cliente servidor que captura los datos ingresados por o los atacantes, es decir captura todas las manipulaciones y modicaciones de los atacantes sobre los datos del honeypot. Capaz de registrar conexiones seguras levantadas desde y hacia el equipo. Se ubica muy cerca del ncleo, por tal motivo pasa desapercibido por los atacantes. El objeu tivo primordial como se ha explicado es recolectar los datos modicados y creados sin que la aplicacin sea descubierta. o - Captura de trco de red: a How.- Recolecta los datos proporcionados por el IDS Snort, Argus, POF y los datos sebek. Todos estos datos son almacenados en una base de datos del mismo nombre, elaborando un modelo relacional complejo. Wireshak.- Potente analizador de trco, permite ver informacin de los a o archivos exportados por sebek (.cap). Provisto de herramientas grcas a 13

para determinar el ujo de datos, incluyendo una potente base de datos de ltros que puede ser usada para realizar anlisis detallados sobre algn a u servicio en particular. Walleye.- Herramienta grca de administracin de la Honeynet, permia o tiendo al administrador solicitar informacin a los honeypots. Permite ver o los datos recolectados por sebek. Honeysnap.- Presenta anlisis resumidos de los archivos exportados por a sebek. 1.1.4. Resultados obtenidos

Diseo e implementacin de una honeynet en la red de la UTPL. n o Para poder establecer la ubicacin adecuada de la honeynet en la red de la o UTPL se ha hecho un anlisis tanto del esquema de red, equipos y conguraa ciones de la red. La ubicacin de los honeypots se la puede determinar en base a los requero imientos que tenga la organizacin y puede ser ubicados en distintas partes de o la red, estas pueden ser: 1. Honeypots antes del rewall. 2. Honeypots despus del rewall. e 3. Honeypots en la zona desmilitarizada. Dependiendo de la ubicacin de los honeypots, el nivel de riesgo aumenta, pero o la cantidad de informacin que se logra recolectar tambin aumenta, cada ubio e cacin presenta sus ventajas y sus desventajas. o Ubicacin de la Honeynet en la red de la UTPL. o En la siguiente gura, se puede observar cual es el esquema de la red UTPL donde se ha implementado la honeynet.

14

Figura 3: Red actual de la UTPL[7]. Actualmente se tiene implementada la honeynet con un equipo que es el encargado de ser el Servidor centralizado y dos equipos honeypots, uno con plataforma Linux y el otro con plataforma Windows, que sern los encargados a de ser seuelos y de enviar la informacin al servidor central. n o En el honeypot Windows, se ha seleccionado Windows XP como sistema operativo, aqu se tienen levantados servicios como IIS (Internet Information Services), HTTP, FTP, SMTP, servicios que convierten al ordenador en un servidor de Internet en el cual se pueden publicar pginas web. Adems de esto, a a se ha procedido tambien a congurar un entorno virtual de aprendizaje EVA, en la plataforma Moodle-1.9.2, con la nalidad de simular un servicio real de la UTPL. En el servidor Linux, se ha tomado como sistema operativo base la distribucin CentOS 5.2, aqu se tienen levantados servicios como HTTP, FTP, o SSH(Secure Shell), Servidor Mail y servicios de bases de datos.

1.2.

Identicacin de los servicios cr o ticos externos de laUTPL.

Toda organizacin de TI cuenta con servicios algunos ms cr o a ticos que otros, ciertos servicios que no pueden dejar de funcionar bajo ninguna circunstancia. Por ello, los administradores tienen en las honeynet un recurso de ayuda para analizar la forma de proteger esos servicios cr ticos. La captura y anlisis de a datos que ofrece la honeynet proporciona informacin de mucho inters para los o e

15

administradores estos servicios cr ticos. Actualmente, la honeynet implementada en la red de la UTPL, aunque est en funcionamiento, no est simulando sistemas en produccin y por tal a a o no hay un seguimiento ni monitoreo a servicios cr ticos, en este caso servicios externos, y tampoco se ha realizado la evaluacin para implementar los servio cios en la misma. Por ello, se hace indispensable esa evaluacin de los servicios o externos para su posterior implementacin en la honeynet, de manera que se o pueda obtener la informacin referente a los riesgos a los que estn expuestos o a estos servicios. 1.2.1. Inventario de servicios y evaluacin de su criticidad. o

La nalidad de esta fase es de obtener informacin detallada sobre los sero vicios que estn implementados en los servidores de la red de la UTPL, a n de a reconocer y seleccionar aquellos que sean de mayor criticidad para su posterior implementacin y evaluacin del trco de red que se genera. o o a Para este n y para poder evaluar valorar el nivel de criticidad se han tomado en consideracin los siguientes puntos: o 1. Inventario de todos los servidores de la red de la UTPL. Se ha procedido a recolectar toda informacin acerca de los servicios que o estn en produccin y los que estn en prueba, as tambin como platafora o a e mas usadas, versiones, servicios levantados, direcciones IP, internas como externas, administradores, etc. [Ver Anexo 1] 2. Estudio realizado en la tesis Plan de Continuidad de Negocios, PCN[10]. En este anlisis se menciona que el servicio de internet es el que contiene a los servicios cr ticos en s los ms necesarios para la realizacin del pre, a o sente proyecto. Por ello la tesis PCN menciona textualmente lo siguiente: Los servicios de internet como mail, DNS, Web Hosting y Proxy involucran las tareas de administrar las cuentas de correo de todos los usuarios de la Universidad, asignacin de nombres de dominios internos de las aplio caciones, brinda dominios virtuales a clientes externos, permite el acceso a internet. Desde este punto de vista, presentamos a continuacin los servicios de o internet cr ticos para este proyecto y que se mencionan en PCN: Servicios Internet: - Web (gdr1.utpl.edu.ec). - DNS Externo (gdr2.utpl.edu.ec). - Entorno Virtual de Aprendizaje (eva.utpl.edu.ec). antes conocido como SGAMC(Sistema de Gestin Acadmica Modalidad Clsica) y SGA-MAD o e a (Sistema de Gestin Acadmica de la Modalidad Abierta y a Distancia). o e - Servicios en l nea, Estudiantes Docentes. (wsutpl.utpl.edu.ec). 16

3. Valorizacin de la informacin con los administradores y l o o deres de grupo. Para validar la informacin recolectada se ha procedido a realizar una o encuesta [Ver Anexos 2] con los administradores de los servicios cr ticos para obtener una informacin aun ms detallada de los servicios externos o a implementados. A ms de ello, se ha procedido a vericar el nivel de criticidad de los a servicios externos con una escuesta aplicada a los l deres de cada uno de los departamentos en los que se administran los servicios, para corroborar con ellos el nivel de importancia que tienen cada uno de ellos. Luego de aplicar las respectivas encuestas, el resultado que se ha podido obtener es que, los servicios cr ticos externos evaluados son evidentemente primordiales para el desarrollo normal de las actividades diarias de la UTPL, aumentando su nivel de importancia el nmero de usuarios y el u impacto que signicar que estos servicios estn fuera de funcionamiento a e (indisponibilidad). 4. Evaluacin de los servicios cr o ticos en base a la informacin dada o en el estudio de herramientas de monitoreo de la UTPL. El nivel de criticidad, de los servicios candidatos, tambin ha sido evale uado usando como mtrica los datos que genera las herramientas tales e como Netow, Cacti, las cuales se encuentran montadas en el sistema de monitoreo de la UTPL (NOC), en cuanto al trco de red de entrada y a salida registrado por los servidores y la determinacin de si un servicio es o identicado como interno o externo y cul es el ujo de transmisin de a o datos.[Ver Anexos 3]. De ste anlisis se puede decir que efectivamente los servidores externos e a evaluados son cr ticos en base al ujo de trco que registran cada uno de a ellos, si efectuamos un monitoreo diario de estos servidores externos, siempre, o casi siempre, se puede observar al servidor web (gdr1.utpl.edu.ec) en el primer lugar del rank de servidores con ms trco de entrada y a a de salida, seguido del EVA (eva.utpl.edu.ec) que generalmente ocupa el segundo puesto. Un poco abajo del listado que se muestra con netow se puede observar el servidor wsutpl.edu.ec, que al igual a diario muestra un ujo de red considerable. Lo mismo que pasa con el servidor DNS, que en cambio se monitorea con Cacti, tambien presenta una gran actividad y trco de red externo. a Es necesario mencionar que tanto el servidor DNS, Web y el Eva, son servidores sumamente cr ticos, tanto a nivel externo e interno, por lo que se proceder a a virtualizar estos servicios interna y externamente, esta informacin fu validada o e con los respectivos administradores y corroborada con los resultados que se muestran en las herramientas de monitoreo de la UTPL, NOC.

17

1.2.2.

Revisin de caracter o sticas: plataformas, versiones, aplicaciones, trco. a

Luego del anlisis de los servicios cr a ticos se ha procedido a recoger informacin relevante acerca de estos, estos se muestran en la siguiente tabla. o Cuadro 2: Caracter sticas de los servidores externos.

1.2.3.

Revisin de problemas de seguridad relacionados o

El hecho de conectar una red a un ambiente externo, como lo podr ser el a internet, deja abierta la posibilidad de que los equipos de la red estn expuestos e a amenazas como ataques, robo de informacin, mal funcionamiento, entre otras o cosas. Conforme han evolucionado las tecnolog empleadas en red, as tambin as e como los servicios prestados, tales como e-mail, web, dns, etc., de igual forma los problemas de seguridad han ido surgiendo. Hoy en d es dif mantener un a cil equipo totalmente protegido, puesto que las aplicaciones, programas, software empleado muchas de las veces presenta fallas o errores, tambin conocidos como e 18

bugs, los cuales pueden ser aprovechados por atacantes para comprometer los sistemas. Protocolo DNS El protocolo DNS y los programas que lo implementan se han visto envueltos desde siempre con mltiples problemas de seguridad. Por varios mtodos u e distintos[11]: Atacando al servidor a travs de un desbordamiento de bfer, inyectar e u cdigo o accediendo al servidor para modicar las zonas. Aunque esto es o ya menos comn, BIND el programa casi estndar de facto en servidores u a DNS, sufri de muchas vulnerabilidades de este tipo. o Envenenamiento de la cach de los servidores. Un atacante puede mone tar su propio servidor DNS y mentir a un servidor DNS leg timo que le pregunta por registros que no tiene (los servidores DNS se preguntan constantemente entre s para actualizar sus datos y redireccionar correc tamente todos los dominios a las mismas direcciones). Falsicacin del ID. Este mtodo consiste en hacerse pasar por la respuesta o e leg tima de un servidor DNS. El cliente que ha hecho una pregunta recibe directamente una respuesta falsa de un atacante. Estos dos ultimos mtodos han sido muy populares tambin en los ultimos aos, e e n con numerosas tcnicas que permit llevar a cabo el ataque. Bien por fuerza e an bruta (bombardeando con peticiones) bien por fallos de implementacin del proo tocolo. Vulnerabilidades en el Servidores DNS de BIND[12]: CA-AL-17-1109: Vulnerabilidad en BIND 9.3.x PROBLEMA: Una vulnerabilidad fue identica en el software de DNS BIND que de se explotada podr utilizarse para generar ataques de envenenamiento de cache a en el mencionado software.El problema reside en un error de validacin de datos o de entrada en el protocolo DNSSEC cuando se reciben consultas recursivas. Para que el exploit sea efectivo se requiere que el servidor de nombres tenga la recursin permitida y que exija validacin DNSSEC para sus clientes. Servidores o o de nombre solo autoritativos no estn afectados. a VERSIONES AFECTADAS: Las versiones afectadas son: BIND 9.0.x, BIND 9.1.x, 19

BIND 9.2.x, BIND 9.3.x, BIND 9.4.0 hasta BIND 9.4.3-P3, BIND 9.5.0, BIND 9.5.1, BIND 9.5.2, BIND 9.6.0 y BIND 9.6.1-P1. SOLUCION: Actualizar a las versiones: 9.4.3-P4, 9.5.2-P1, o 9.6.1-P2. De la siguente direccin, https://www.isc.org/downloadables/11. o VALORACION DEL IMPACTO: ALTO. Problemas de seguridad con Apache[13]: Vulnerabilidad en Apache Tomcat (CVE-2009-2902) Tipo: No Disponible/Otro tipo + Salto de directorio + Secuencias de comandos en sitios cruzados - XSS Gravedad: Media Fecha de publicacin: 28/01/2010 Ultima modicacin: 26/02/2010 o o Descripcin: o Vulnerabilidad de salto de directorio en Apache Tomcat desde v5.5.0 hasta v5.5.28 y desde v6.0.0 hasta v6.0.20 permite a atacantes remotos borrar cheros del directorio de trabajo a travs de secuencias de salto de directorio en un e nombre de chero WAR, como se demuestra en ..war nombre de chero. Vector de acceso: A travs de red. e Problema de seguridad con Joomla[14]: Vulnerabilidad en JE Event Calendars (com jeeventcalendar) para Joomla! (CVE2010-0795) Tipo: No Disponible/Otro tipo + Salto de directorio + Inyeccin SQL + o Errores numricos + Permisos, privilegios y/o control de acceso. e Gravedad: Alta Fecha de publicacin: 02/03/2010 Ultima modicacin: 03/03/2010 o o Descripcin: o

20

Vulnerabilidad de inyeccin SQL en el componente JE Event Calendars o (com jeeventcalendar) v1.0 para Joomla! permite a atacantes remotos ejecuo tar comandos SQL arbitrarios a travs del parmetro event id en una accin e a event a index.php. Vector de acceso: A travs de red e Complejidad de Acceso: Baja Autenticacin: No requerida para explotarla. o Tipo de impacto : Afecta parcialmente a la integridad del sistema + Afecta parcialmente a la condencialidad del sistema + Afecta parcialmente a la disponibiliad del sistema Productos y versiones vulnerables: harmistechnology - com jeeventcalendar - 3.1 Problemas de seguridad con Wordpress[15]: Vulnerabilidad en wp-adminpress-this.php en WordPress (CVE-2009-3891) Tipo: No Disponible/Otro tipo + Secuencias de comandos en sitios cruzados - XSS + Error de bfer u Gravedad: Baja Fecha de publicacin: 17/11/2009 Ultima modicacin: 17/12/2009. o o Descripcin: o Vulnerabilidad de ejecucin de secuencias de comandos en sitios cruzados o (XSS) en wp-admin/press-this.php en WordPress anteriores a v2.8.6 permite a usuarios remotos autenticados inyectar secuencias de comandos web o HTML a travs del parmetro s (tambin conocido como variable seleccin). e a e o Vector de acceso: A travs de red. e Tipo de impacto : Afecta parcialmente a la integridad del sistema. Los problemas de seguridad referentes a servicios se enfocan principalmente a la explotacin de vulnerabilidades que estos pueden presentar. Por ello lo acono sejable ser mantener los equipos actualizados, trabajar con versiones estables a y probadas, reajustar los sistemas conforme se liberen los parches de seguridad, seguridad en puertos al tener levantados solo los indispensables, actualizacin o de rmas, etc.

21

CAPITULO II IMPLEMENTACION DE LOS SERVICIOS CR ITICOS EXTERNOS EN LA HONEYNET

22

2.

Implementacin de los servicios cr o ticos externos en la honeynet.

Las honeynets se han convertido en los ultimos aos en una herramienta de n seguridad altamente empleada y util, dentro de los entornos computacionales de las organizaciones, demostrando su gran valor en la recoleccin de informacin o o signicativa de los comportamientos de los agentes externos e internos que tiene toda organizacin. Por ello, se ha ideado tambin el concepto de honeynets o e virtuales como una forma de seguir explotando esta herramienta, en busca de nuevos patrones de comportamiento y de una manera u otra buscar la forma de entender mejor las amenazas a las que se encuentra expuesto para poder protegerse de las mismas. Otro de los motivos por los que surgen las honeynets virtuales es el gran consumo de recursos que representa el uso de honeynets tradicionales o clsicas, a al hacer uso de varios equipos o sistemas y de mecanismos de proteccin, el o espacio f sico y los requerimientos para su implementacin. o En esta segunda fase del proyecto se tratar sobre la fase de implementacin a o de los servicios cr ticos externos que se denieron en la fase anterior en una honeynet virtual. Por ello, en una primera parte se hace un recuento de conceptos acerca de las honeynets virtuales, su clasicacin, ventajas, desventajas, o herramientas existentes para virtualizacin. Tambin un recuento del hardware o e con el que se cuenta para implementar la honeynet virtual. La revisin del eso quema de red que se ha de utilizar y la conguracin adecuada del software para o simular la red. Para nalmente poder instalar y congurar los equipos virtuales con sus aplicaciones y servicios correspondientes.

2.1.

Estudio de Honeynets virtuales.

Una honeynet virtual se basa en el mismo concepto de una honeynet clsica, a es una forma diferente de implementar un sistema completo honeynet dentro de un solo equipo f sico a travs de herramientas de virtualizacin, las cuales e o permiten simular los componentes de un sistema para su posterior anlisis. a El uso de este tipo de mecanismo de seguridad, presenta sus ventajas y desventajas[16]: VENTAJAS Ahorro de hardware: Se necesita de una sola mquina f a sica. Se puede tener la ejecucin de varios sistemas operativos dentro de un solo ordeo nador. Informacin centralizada: Se pueden administrar todos los componentes o del sistema o honeynet en un solo equipo f sico. Movilidad: Todo el sistema virtualizado puede ser movilizado sin problema alguno de un lado a otro, se puede implementar por ejemplo, dentro de un equipo porttil y poder ser movilizado con facilidad. a 23

Escalabilidad: Dependiendo de las caracter sticas del equipo antrin, o se puede implementar y aumentar mquinas virtuales dependiendo de la a necesidad. Aislamiento: Una ca o falla general del sistema de una mquina virtual da a no afecta al resto de mquinas virtuales. a Espacio f sico: Dependiendo del tamao y la cantidad de componentes de n la honeynet, se tiene un ahorro del espacio f sico al unicamente emplear un solo equipo. DESVENTAJAS Un unico punto de fallo: De llegar a fallar el hardware del equipo antrin o todo el sistema honeynet dejar de funcionar. a Equipo antrin de caracter o sticas potentes: Dependiendo tambin del e tamao de la honeynet se requerir mayor tamao en memoria y mejores n a n caracter sticas de procesamiento. Software Limitado, ya que todo tiene que ejecutarse en una mquina, esto a limita al software que se pueda usar en el antrin. o Las tcnicas de ngerprinting (obtencin del tipo y versin del sistema e o o operativo mediante el env de paquetes IP espec o camente construidos) podr revelar la naturaleza real de nuestro sistema operativo base. an Incluso aunque en principio esta tcnica no funcionara, si el atacante toma e el control de una de los Honeypots probablemente pudiera averiguar que se encuentra en un sistema simulado, lo que falsear su comportamiento. a 2.1.1. Clasicacin. o

Las honeynets virtuales se clasican en dos tipos[17]: 1. Honeynets Auto-contenidas Una honeynet virtual autocontenida engloba a una honeynet en un solo equipo. La red entera est virtualmente contenida en un unico y f a sico sistema. Una red Honeynet t picamente consiste de un cortafuegos para Control de Datos y Captura de Datos, y los honeypots dentro de la Honeynet. Un esquema de esta clase de honeynet ser la que muestra la gura que a aparece a continuacin: o

24

Figura 4: Honeynet virtual autocontenida.[17]

2. Honeynets H bridas Una Honeynet H brida es una combinacin de la clsica Honeynet y del o a software virtual. Captura de Datos, como por ejemplo cortafuegos, y Control de Datos, es decir, los sensores de IDS y el almacenamiento de registros, estn en un sistema separado y aislado, para reducir el riesgo a de compromiso. Sin embargo, todos los honeypots son ejecutados en una unica mquina. a Un esquema de esta clase de honeynet ser la que muestra la gura que a aparece a continuacin: o

Figura 5: Honeynet virtual h` brida.[17]

25

2.1.2.

Virtualizacin y Herramientas de Virtualizacin. o o

Virtualizacin o En informtica, virtualizacin es un trmino que se reere a la abstraccin a o e o de los recursos de una computadora, llamada Hypervisor, que crea una capa de abstraccin entre el hardware de la mquina f o a sica (host, antrin) y el sistema o operativo de la mquina virtual (guest, mquina virtual), siendo un medio para a a crear una versin virtual de un dispositivo o recurso como un servidor, un diso positivo de almacenamiento, una red, etc.[18] Herramientas de virtualizacin o Actualmente existen muchas soluciones para virtualizar sistemas, unas mejores que otras dependiendo del uso que se le vaya a dar. Tanto en el mundo organizacional como con usuarios normales la virtualizacin va ganando terreno gracias o al aporte de numerosas ventajas, asi como el ahorro de costes en hardware, mantenimiento, etc. Entre estas soluciones, herramientas licenciadas y de cdigo abierto, las ms o a utilizadas son[19]: Sun: VirtualBox (gratis), VirtualBox OSE (libre). VMware: Workstation (de pago), Server (gratis), Player (gratis). QEMU (libre). Micorsoft: Virtual PC, Virtual Server. ... VMWare Workstation VMMare Workstation es un software de virtualizacin que puede correr en o tanto en plataformas Windows como en plataformas Linux. Este software permite a los usuarios simular mltiples computadoras virtuales. u Se trata de un sistema de virtualizacin por software. Un sistema virtual por o software es un programa que simula un sistema f sico (un ordenador, un hardware) con unas caracter sticas de hardware determinadas. Cuando se ejecuta el programa (simulador), proporciona un ambiente de ejecucin similar a todos o los efectos a un ordenador f sico (excepto en el puro acceso f sico al hardware simulado), con CPU (puede ser ms de una), BIOS, tarjeta grca, memoria a a RAM, tarjeta de red, sistema de sonido, conexin USB, disco duro (pueden ser o ms de uno), etc. a Un virtualizador por software permite ejecutar (simular) varios ordenadores (sistemas operativos) dentro de un mismo hardware de manera simultnea, pera mitiendo as el mayor aprovechamiento de recursos. No obstante, y al ser una 26

capa intermedia entre el sistema f sico y el sistema operativo que funciona en el hardware emulado, la velocidad de ejecucin de este ultimo es menor, pero en o la mayor de los casos suciente para usarse en entornos de produccin[20]. a o VMware toma ventaja de entre las otras soluciones de virtualizacin, por la o garant que da el tiempo que lleva en el mercado y la cantidad de usuarios a a su haber, adems de ser una herramienta muy exible al momento de gestionar a redes de sistemas, que es lo que se requiere para implementar una honeynet. Para el diseo y creacin de redes complejas, VMWare es una excelente n o eleccin por las opciones y caracter o sticas que hacen de esta herramienta muy exible, intuible y util.

2.2.

Anlisis del Hardware disponible. a

Como se hac mencin anteriormente, para poder implementar una hona o eynet virtual es necesario un equipo robusto, de buenas caracter sticas, para que pueda soportar las mquinas virtuales que han de formar la honeynet y que a puedan correr simultaneamente. El equipo que se ha de emplear es de las siguientes caracter sticas: Cuadro 3: Caracter sticas de la mquina antrin a o Dispositivo(s) Procesador Memoria RAM Disco duro (HD) Tarjeta(s) de red Sistema Operativo Caracter sticas Intel(R) Core(TM) 2 Duo CPU 2.93 GHz 6 Gb 250 Gb Ethernet (IP pblica) u Windows 2008 Server - 64 bits

2.2.1.

Equipos virtuales a implementar.

Para poder crear una honeynet virtual utilizando VMWare como herramienta de virtualizacin, el equipo presentado anteriormente deber dar soporte a o a las mquinas virtuales que conformarn la honeynet. a a La honeynet a implementar consta de 4 equipos honeypots con sus respectivos Sistemas Operativos y sus respectivos servicios y/o aplicaciones, un equipo ser el honeywall, con su sistema operativo basado en Centos y una interfaz ms a a para la administracin remota del Honeywall. o A continuacin se muestra un cuadro en el que constan estos equipos: o

27

Cuadro 5: Caracter sticas de los servidores externos.

2.3.

Anlisis de red de la Honeynet. a

Para poder crear una honeynet virtual utilizando VMWare como herramienta de virtualizacin, es necesario primeramente disear la red que se quiere imo n plementar, con los equipos y recursos que han de utilizarse para su respectivo funcionamiento. 2.3.1. Esquema de red

El esquema de red para la honeynet, es el que se muestra en la siguiente gura:

Figura 6: Esquema de red de la honeynet virtual

28

2.3.2.

Conguracin de red o

El equipo Honeywall tendr 3 interfaces o tarjetas de red, conguradas a dos en modos Bridge y una congurada en modo Host-only.
A travs de la interfaz congurada en modo Host-only el honeywall e se comunicar con los honeypots. a Una interfaz congurada en modo Bridge para la comunicacin con o el host antrin. o Una tercera interfaz, tambin congurada en modo bridge, ser la e a interfaz para la administracin del Honeywall. o

VMWare tiene algunas opciones para congurar los adaptadores de red, cada uno tiene su propsito de ser, estos se mencionan a continuacin[21]: o o Bridge La VM congurada con esta opcin usa una direccin IP desde o o la red f sica y tiene acceso completo a los recursos de red. Signica que puede acceder a Internet, al servidor DHCP de la LAN, a los archivos compartidos entre otras cosas. Es como tener un computador separado en la propia red, que tambin tiene acceso completo desde e cualquier host en la LAN real. NAT Esta opcin permite acceder a algunos recursos basados en TCP/IP o en el antrin (tal como conexin a Internet) sin requerir una direco o cin IP de la LAN real. En lugar de esto la VM usa una direccin IP o o la cual pertenece a la red virtual VMnet8. Esta VM no puede ser accedida desde cualquier equipo localizado en la red LAN (a excepcin o del propio equipo). Host-Only Habilitando esta opcin, una VM que est conectada a nueo a stro equipo real es invisible a otros dispositivos en la LAN. Es decir se crea una red aislada a la de la LAN real. Custom Usando esta opcin se puede congurar y disear redes compleo n jas. Para esta opcin se puede tener siete redes virtuales: VMnet2, o VMnet3, VMnet4, VMnet5, VMnet6, VMnet7 and VMnet9. Cabe recalcar que estas redes son tambin redes host-only y las VMs las e cuales pertenecen a cada una de ellas son accesibles desde el hostantrin si el adaptador virtual correspondiente se habilita en el hosto antrin. o 2.3.3. Esquema de red honeynet en VMware

El esquema de red para la honeynet, y su respectiva conguracin en el o VMware, es el que se muestra en la siguiente gura:

29

Figura 7: Esquema de red y conguracin de la honeynet virtual o 2.3.4. Conguracin del equipo antrin o o

Para poder implementar la infraestructura mencionada en los puntos anteriores, es necesario tambin congurar adecuadamente el equipo antrin de e o modo que nos permita el env y recepcin del trco de red. o o a Cada uno de los equipos virtualizados tendr que tener trco de entrada a a y salida, de manera que puedan ser visualizados desde la red exterior, con el objetivo que queden expuestos a ataques y riesgos que sto signica. e Para lograr esto, es necesario congurar las conexiones part cipes de red a manera de puente, de modo que los honeypots puedan tener la misma conguracin de la Conexin que tiene acceso a la internet. o o Puente de red Un Puente de Red es una funcionalidad de Windows a travs de la cual se e pueden conectar dos o mas segmentos de red. En este caso, se hace un puente

30

 entre la Conexin de Area Local, que es la que tiene acceso al internet, con el o Adaptador virtual de red VMware (VMware Network Adapter VMnet1), que es la interface virtual a la que se conectan los honeypots. Esquema La gura siguiente muestra el esquema de un Puente de red, entre Conexin o de rea local 2 y VMware Network Adapter VMnet1: a

Figura 8: Puente de red entre Conexion de Area Local y VMnet1 Conguracin o Para congurar un puente de Red en el equipo antrin, bajo Windows Server o 2008, procedemos de la siguiente manera: 1. Ir a Panel de Control. 2. Ir a Centro de Redes y recursos compartidos. 3. Ir a Administrar conexiones de red. 4. Localizar los Adaptadores de red los cuales sern parte del puente, en este a caso: Adaptador de Area Local y VMware Network Adapter VMnet1, seleccionarlos a ambos manteniendo pulsada la tecla Control. 5. Dar click derecho y escoger la opcin Puente de red. o 31

2.4.

Honeywall

Para este proyecto se har uso del CD Honeywall 1.4, que esta disponible en a la web del proyecto honeynet (www.honeynet.org). Se crea una nueva maquina virtual y se la arranca desde un CD-Live Honeywall 1.4, en la mquina que a estar designada para ser de Honeywall. a 2.4.1. Requisitos del sistema

Segn [8], por motivos de seguridad, el CDROM Honeywall utiliza un sistema u operativo Linux minimizado. Por lo tanto, este es el hardware y los requisitos: Al menos 256MB de memoria (Ms siempre es mejor, pero menos de 960M a - no soporta highmem) Unidad cd CDROM Disco duro IDE para registro. (Recomendado AL MENOS 30 GB) Pentium III o superior. 2 tarjetas de red (una 3 para gestin de red) o Unidad de disquetera (opcional). Puede ser utilizada para grabar o cargar nuevos cheros de conguracin. o 2.4.2. Instalacin de Honeywall CD roo-1.4.hw-20090425114538 o

Para una informacin detallada sobre la instalacin, conguracin y admino o o stracin de Honeywall, se puede remitirnos a los manuales que se presentan en o el [Anexo 4]. 2.4.3. Congurando Honeywall

Una vez que el software se ha instalado correctamente en el sistema, el siguiente paso es la conguracin del Honeywall para el correcto funcionamiento de o los parmetros y/o variables de la Honeynet. En teor esto deber hacerse aua a a tomticamente la primera vez que se ingresa, pero casi nunca se logra congurar a correctamente la Honeynet solo a la primera vez. Es por ello que se puede acceder a la conguracin a travs de la ejecucin o e o del script: /dlg/dialogmenu.sh, el cual nos presenta el Men principal, para u poder chequear el estado del Honeywall:

32

Figura 9: Honeywall - Main Men u EL Dialog Menu, es la interface clsica para administrar y congurar el a Honeywall CDROM. Aunque hoy en d ya no se la considera como el mtodo a e principal para el mantenimiento del Honeywall, debido a que la interface Walleye se la considera como mejor opcin, presenta sub-mens con opciones para la o u administracin del Honeywall. o

2.5.

Interface GUI Walleye

Walleye es la interface web para la administracin del Honeywall. El Honeyo wall ejecuta un servidor web al cual se puede acceder remotamente a travez de una conexin segura SSL a la interface de red de administracin. Esta GUI, pero o mite al usuario congurar y mantener el sistema de una forma sencilla. Adems, a cuenta con un men de expansin por lo que se facilita el acceso para poder u o visualizar toda la informacin. o Esta Interface Grca de Usuario, actualmente tiene soporte ya sea para a Internet Explorer, Firefox, Google Chrome, etc. La interface GUI Walleye est diseada para facilitar la comprensin de la a n o secuencia de una intrusin, a travs de la presentacin de una vista compuesta o e o de datos. Es decir, que la vista de datos que se presenta es una composicin o de cada una de las fuentes de datos. Para lograr esto, la interface GUI Walleye utiliza un modelo relacional para generar vistas compuestas de los eventos de las fuentes de datos, tal como lo son: p0f, Argus, Snort, Sebek, haciendo una fusin de todas estas fuentes en una base de datos llamada how, de la cual se o obtienen los datos:

33

Figura 10: Diagrama de recoleccin y fusin de datos.[22] o o

Para poder visualizar esta interfaz, iniciamos un navegador desde el equipo que servir de administracin y ubicamos en el url la direccin IP de adminisa o o tracin del honeywall, utilizando ssl, https:<ip-administracin> o o

Figura 11: Interfaz GUI Walleye Para poder ingresar, el username y password por defecto son: Username: roo Password: honey

34

Figura 12: Interfaz GUI Walleye - cambio de contrasea n El username y password son solo para la primera vez que se ingresa al Walleye, de ahi se deben modicar: Figura 13: Interfaz GUI Walleye

Una vez registrados se puede realizar la administracin del Honeywall remoo tamente. En la interface GUI Walleye se realiza el monitoreo y anlisis, podemos ver a grcamente las conexiones entrantes y salientes, informacin detallada de los a o protocolos utilizados y en especial se puede visualizar el trco Sebek capturado, a adems que tiene la funcionalidad para poder ltrar nuestras capturas de modo a que sea gil el anlisis. a a De esta interface tambien podemos descargar los pcaps, para poder realizar

35

el respectivo anlisis de modo o-line con cualquier herramienta de anlisis a a de tco, como por ejemplo: Wireshark. a A continuacin se presenta una captura de la interface Walleye en funo cionamiento: Figura 14: Interface Walleye en funcionamiento

2.6.

Sebek

Sebek es una herramienta para la captura de datos, diseada para capturar n las actividades de los atacantes en un honeypot, sin que ste lo sepa. e Este consta de dos componentes. El primero es un cliente que corre en los honeypots, su propsito es capturar todas las actividades (pulsaciones del teclao do, subidas de archivos, passwords, incluso en entornos encriptados) y encubiertamente env los datos al servidor. El segundo componente es el servidor, el a cual los datos de los honeypots[23]. El servidor, normalmente corre en un gateway Honeywall, pero puede correr tambin independientemente. e

36

Figura 15: Sebek, arquitectura cliente-servidor[23] 2.6.1. Instalacin y conguracin de Sebek. o o

Esta herramienta de seguridad se puede ejecutar en plataformas Linux y Windows, y se lo puede descargar desde la web desde la siguiente ubicacin: o https://projects.honeynet.org/sebek/. La instalacin y conguracin de Sebek, o o tanto en sistemas Linux, como en sistemas Windows se muestra en los [Anexos 5]. 2.6.2. Parmetros y/o variables Sebek a congurar. a

Para una conguracin adecuada de Sebek, es necesario editar el archivo de o conguracin: sbk install.sh, el cual contiene los parmetros o variables para o a Sebek. Se debe congurar las variables con el f de personalizar la captura en n el honeypot (equipo trampa) y tambin hacer ms dicil la deteccin de Sebek: e a o

37

Cuadro 6: sbk install.sh, variables Sebek a congurar. Parmetro a FILTER INTERFACE DESTINATION IP DESTINATION MAC SOURCE PORT DESTINATION PORT MAGIC VAL KEYSTROKE ONLY SOCKET TRACKING WRITE TRACKING TESTING MODULE NAME Descripcin o Archivo que contiene el ltro de coleccin. o Identica la interface desde la que registrar Sebek a Estable la IP destino para los paquetes Sebek Establece la direccin MAC destino para los paquetes Sebek o Dene el puerto UDP origen para Sebek Dene el puerto UDP destino para Sebek Dene el valor mgico en los registros Sebek a Controla si se recolecta solamente pulsaciones de teclado Controla si solo se recolecta informacin en conexiones de red o Caracter stica experimental. Deshabilitada por recomendacin o Se usa para hacer el mdulo oculto o Usado para controlar el nombre del mdulo o

La conguracin utilizada del archivo sbk install.sh de Sebek, para plataforo mas Linux, se muestra en el [Anexo 6].

2.7.

Implementacin de servicios. o

Una vez que ya se tiene montada la honeynet virtual, con todos los componentes (honeywall, honeypots, equipo de administracin) y que han sido cono gurados adecuadamente el honeywall y Sebek en los honeypots, procedemos a la instalacin de los respectivos servicios en cada uno de los honeypots, con el o objetivo de poder analizar el trco que se genera. a Los servicios a ser implementados se los puede observar todos y cada uno de ellos en el Cuadro 2: Caracter sticas de los servidores externos de la primera fase, son los servicios y/o aplicaciones que se analizaron en la fase anterior. Ver [Anexos 7]

2.8.
2.8.1.

Problemas de implementacin o
Instalacin de Sebek o

Instalacin de Sebek en Windows 2003 Server o Para la implementacin del servidor wsutpl, se necesita virtualizar un servio dor con Windows 2003 Server - Enterprise Edition, como su Sistema Operativo. Luego de realizar la instalacin de dicho Sistema Operativo, y de implemeno tar las aplicaciones y servicios, el siguiente paso es la instalacin de la herramieno ta Sebek, para la captura de las actividades de los atacantes, es aqu donde surge el inconveniente:

38

Se ha procedido a instalar Sebek para Windows, probando con diferentes versiones, y esto es lo que sucede: Escenario 1 Sistema Operativo: Windows 2003 Server Edicin: Enterprise o Service Pack: 2 Versiones instalada de Sebek:
sebek-win32-2.1.5 Sebek-Win32-3.0.3 Sebek-Win32-3.0.4

Resultado Al utilizar estas versiones de Sebek bajo plataformas Windows 2003 Server, el servidor presenta funcionamiento defectuoso, y se muestra un volcado de memoria, el pantallazo azul, al momento de reiniciar el servidor: Figura 16: Problema con Sebek, volcado de memoria

Escenario 2 Sistema Operativo: Windows 2003 Server Edicin: Enterprise o

39

Service Pack: 2 Versin instalada de Sebek: o

Sebek-Win32-3.0.5

Resultado: Al utilizar esta versin de Sebek, ya no se presenta el error de volcado de o memoria, y la instalacin es exitosa, el problema es que no se registran y no o se env paquetes Sebek desde el honeypot al servidor o Honeywall. an Esto se lo puede comprobar en el Honeywall, mediante la utilidad sbk extract. Es decir, al ejecutar el comando: ./sbk extract -i eth0 -p 1101 Donde: -i eth0, es la interface por la que se esta registrando la actividad de red, -p 1101, es el puerto al que se env los paquetes Sebek. an Mediante la ejecucin de este comando, se pueden visualizar las actividades o realizadas en los honeypots, ya que se envian paquetes Sebek del honeypot al Honeywall. Solucin: o Se ha procedido a instalar la Herramienta Sebek en una versin Windows o de Sistema Operativo que le d el soporte a tal herramienta, en este caso se ha e instalado en Windows XP Profesional. El estudio realizado en [24], corrobora este inconveniente en su trabajo de investigacin realizado: Building a Heterogeneous Honeynet, 2005. o Instalacin de Sebek en CentOS o Tanto los servidores eva, web asi como el dns, utlizan distribuiciones Linux, en este caso CentOS, por lo que tambin hay que virtualizar tales servidores en e la honeynet. De igual forma, una vez instaladas las distribuciones CentOS en los servidores y las diferentes aplicaciones, tenemos que instalar la herramienta Sebek. Escenario 1 Sistema Operativo: Linux Distribucin: CentOS 5.0 Server o Kernel: 2.6.18-8.el5 Versiones Sebek instaladas:

40

 sebek-lin26-3.1.3c.tar sebek-linux-3.0.3.tar sebek-linux24-3.2.0c.tar sebek-linux26-3.2.0b.tar

Resultado: Al descomprimir y realizar pruebas con todos y cada uno de estas versiones de Sebek para Linux, y luego de modicar adecuadamente el archivo sbk install.sh; cuando se ejecuta el instalador, se muestra el siguiente mensaje de error, el cual no permite realizar la instalacin de Sebek: o

Figura 17: Problema con Sebek, ./parameters.sh Escenario 2 Sistema Operativo: Linux Distribucin: CentOS 5.0 Server o Kernel: 2.6.18-8.el5 Versiones Sebek instaladas:
sebek disable raw socket replacement-lin26-3.2.0b-bin.tar

Resultado: Del mismo modo, despus de desempaquetar el instalador y editar adecuadae mente el archivo sbk install.sh, al momento de lanzar el instalador, tambin e se nos muestra una falla al momento de la instalacin: o

Figura 18: Problema con Sebek, install failed

41

Solucin: o Se ha procedido a instalar la Herramienta Sebek en una distribucin Linux o que le d el soporte a tal herramienta, en este caso se ha instalado en Ubuntu e 7.10 Server en todos los servidores que utilizan Linux como Sistema Operativo. Notas: Cabe mencionar, que para tratar de solventar estos inconvenientes, tambin e se solicit ayuda a similares proyectos que se realizan en diferentes paises, tales o como en Brazil, Mxico, Espaa, pero tampoco se logr tener una respuesta e n o para poder solucionar este inconveniente.

2.8.2.

Instalacin de las mismas versiones de las aplicaciones o

Como consecuencia de los problemas en la implementacin de Sebek, citao dos anteriormente, hay problemas de compatibilidad con las versiones de las aplicaciones reales con las que soportan los Sistemas Operativos instalados. En la tabla siguiente se puede observar cuales han sido las aplicaciones instaladas en los sistemas operativos instalados: Cuadro 8: Aplicaciones soportadas que han sido instaladas.

42

2.9.

Pruebas

Como ultima parte de esta segunda fase, se hace necesario realizar algunas pruebas para testear el correcto funcionamiento de la honeynet, con la nalidad de que vericar si realmente se est capturando el trco de red y si se tiene a a una correcta actividad de cada uno de los componentes de la honeynet. Para ello se proceder a realizar los siguientes pasos: a Vericar conectividad de componentes (honeypots).
Se ha vericado esto, mediante respuestas echo replies al comando ping . Existe conectividad de todos los honeypots entre s .

Comprobar conectividad desde y hacia la internet a travs del protocolo e IP.

Se ha vericado esto, mediante respuestas echo replies al comando ping . Ping exitoso hacia algunos sitios web, como www.google.com, desde todos los honeypots. Ping exitoso desde equipos de red externa hacia los honeypots.

Comprobar si los servicios y/o aplicaciones estn instalados y congurados e correctamente en los honeypots.
Servidor DNS

Se ha vericado esto, mediante el comando nslookup. Existen resolucin exitosa de nombres de dominio, tanto normal o como inversa. Aplicaciones instaladas y funcionando correctamente
Servidor WEB

Aplicaciones instaladas y funcionando correctamente. Se puede visualizar el servidor web, a travs de navegadores de e la red externa. Webmin, instalado y ejecutandose.
Servidor EVA

Aplicaciones instaladas y funcionando correctamente. Moodle en funcionamiento y accesible a travs de navegadores e desde la red externa.
Servidor WSUTPL

Aplicaciones instaladas y funcionando correctamente.

43

 IIS instalado y accesible a travs de navegadores desde la red e externa. Vericar si realmente se estn enviando alertas por e-mail. a
Efectivamante se estn receptando correos electrnicos a travs del a o e puerto 25 smtp.

Vericar si Sebek realmente est recolectando la actividad de los sistemas. a

Se ha vericado esto, mediante el comando sbk extract del honeywall

Se hace un ping desde cada uno de los honeypots, y efectivamente se est capturando trco Sebek. a a Otra forma de vericar esto es a travs de la interface GUI Walle eye, donde los paquetes capturados aparecen etiquetados (ag) como Sebeked. Comprobar el ingreso exitoso a la interface GUI Walleye.
Una vez que se ha ejecutado el Honeywall, abrir desde un navegador la administracin, en la direccin: https://<ip-administracin>/walleye.pl:443, o o o y vericar si hay como ingresar al sistema correctamente ingresando usuario y contrasea. n

Comprobar si la interfaz Walleye est funcionando y recolectando datos a correctamente.

Existe trco ya capturado que muestra la informacin que se est recolectana o a do y mostrando a travs de la interface GUI. e

Vericar que todas las herramientas del Honeywall sean inicializadas.

En el arranque del sistema vericar la inicializacin de servicios del o Honeywall. (Walleye, Snort, Sebek, Pof, Swatch, Argus)

44

CAPITULO III RECOLECCION DE DATOS

45

3.

Recoleccin de datos o

Una vez que se ha logrado congurar e implementar la red honeynet con los honeypots en la herramienta de virtualizacin (VMWare), el siguiente paso a o seguir es el Control, la Captura y el Anlisis de Datos. a

3.1.

Subsistemas de una Honeynet de Generacin III. o

La Arquitectura Honeynet de Generacin III, tiene sus origenes a inicios o del aos 2005. Es una evolucin de sus generaciones antecesoras, pero esta genn o eracin presenta mejoras en las versiones de la herramientas utilizadas, con la o nalidad de optimizar el anlisis de los datos recogidos. a En base a la experiencia de las versiones o generaciones anteriores, y con el objetivo de disminuir la dicultad en el anlisis de los datos, las Honeynets de a Generacin III presenta los siguientes subsistemas: o

Figura 19: Subsistemas del Honeywall.[25] 3.1.1. Control de Datos

El objetivo del Control de Datos es vericar qu es lo que el atacante puede e hacer en la entrada y salida de la Honeynet. Generalmente, lo que se realiza es permitir cualquier trco en la entrada al sistema Honeynet, pero lo que se hace a es limitar el trco de salida. a Para esto se hace uso de IPTables, que es un cortafuegos OpenSource que viene incluido con Linux. Se trata de un rewall o cortafuegos altamente exible, que incluye la habilidad de limitar conexiones entrantes y salientes, traduccin o de direcciones de red (NAT), registro, entre otras caracter sticas. Hay que congurar IPTables para que acte como ltro en nuestro HostOS (mquina f u a sica), contando los paquetes de salida. Una vez que se haya alcanzado el l mite de conexiones de salida, cualquier intento posterior deber ser bloqueado, con esa to se puede prevenir que algn honeypot comprometido pueda afectar a otros u

46

sistemas dentro de la red. La conguracin e implementacin de dichas caracter o o sticas se podr tratar a de una tarea extremadamente compleja. Sin embargo, el Honeynet Project ha desarrollado un script IPTables llamado rc.rewall para facilitar este trabajo. En algunas ocasiones es necesario modicar algunas de las variables del script para que se adapten a la Honeynet, y luego ejecutarlo. Lo primero, es necesario saber que se est trabajando con una Honeynet de a Gen III, en la que el Honeywall gateway trabaja en modo puente de nivel dos (layer two bridging mode), el cual es el mtodo ms comunmente utilizado. e a Cuando el gateway acta como puente, no hay enrutamiento o decrementos de u paquetes TTL (time to live), lo cual permite que acte como un dispositivo u de ltro invisible, hacindola ms dif de detectar ante atacantes. e a cil Para poder congurar el script rc.rewall adecuadamente, hay dos reas a cr ticas que congurar, los parmetros de red y los de conexin. Como en modo a o puente (bridge) no hay enrutamiento, ni asuntos de Traduccin de Direcciones de o Red (NAT). Simplemente se convierte el HostOS(mquina f a sica) en un puente, y los GuestOS(mquinas virtuales) interactan directamente con otras redes. a u Para los parmetros de conexin, hay que congurar cuntas conexiones de a o a salida sern permitidas. a Para realizar estas operaciones se debe congurar de la siguiente manera: Primero, se debe establecer las direcciones IP pblicas de los sistemas u operativos invitados (mquinas virtuales). Esas son las IP que los hacka ers atacarn, las IP vlidas de nuestros honeypots. Dependiendo de la a a cantidad de honeypots, se necesita enumerar las direcciones IP de los honeypots. Segundo, se necesita identicar el nombre de las interfaces internas para el HostOS. Por defecto, esta es la interface eth1, y la interface externa que por defecto es la eth2. Tercero, se debe considerar probar las capacidades de Snort-Inline para rechazar (drop) ataques salientes conocidos. Los paquetes de salida autorizados para pasar a travs del cortafuegos son luego enviados a Snorte inline. Snort-inline es un sistema de prevencin de intrusiones basado en o el detector de intrusiones Snort. Este es capaz de tomar acciones contra el trco saliente que tenga ataques conocidos. Snort-inline puede ser cona gurado en el Honeywall para utilizar tres conjuntos diferentes de reglas por defecto que pueden descartar (drop), deshabilitar (disable), o rechazar (reject) ataques conocidos. Tanto el rc.rewall como el Snort-inline pueden generar registros detallados que pueden ser utilizados para analisis y alertas.[26] Esas son las m nimas variables que se debe considerar, puede haber otras dependiendo de la conguracin del sistema. Hay opciones adicionales que se pueden o actualizar, como administracin remota, limitar las conexiones que puede iniciar o el cortafuegos, y dar a los honeypots acceso DNS sin restricciones. Tambin, por e 47

defecto, el script limita a cada honeypot las siguientes conexiones de salida por hora: 9 conexiones TCP, 20 conexiones UDP, 50 conexiones ICMP, y 10 otras IP, esta es la conguracin que viene por defecto.[26]. o Cabe mecionar, que para el proyecto se est usando las conguraciones por a defecto y que tanto para conexiones TCP y UDP, ya estn congurados los a puertos de escuchan que utilizan los servidores y sus aplicaciones en el Honeywall.

Herramientas para el Control de Datos: Bridge de capa 2 (Honeywall) Iptables (limitacin de paquetes y/o trco de red) o a Snort Inline (manipulacin de paquetes de red) o 3.1.2. Captura de Datos

Otro de los requisitos fundamentales es la captura de toda la actividad del atacante minimizando las posibilidades de que ste se percate de ello. La activie dad en la red trampa es registrada por varias herramientas diferentes. Primero, el rewall o cortafuegos registra todas las conexiones entrantes y salientes en /var/log/messages. Segundo, por defecto un proceso de Snort captura toda la actividad de red y todos los contenidos de los paquetes vistos por la interfaz de red interna (por defecto eth1). Esto incluye toda la actividad de Sebek, la cual es enviada mediante paquetes UDP. Tercero, una instancia adicional de Snort escucha en la interfaz interna y genera alertas IDS en modo full y fast. Toda la actividad de Snort y Snort-inline es registrada en /var/log/snort/$DAY, donde $DAY es el valor numrico del d Donde se ha estandarizado YEARMONTHDAY, e a. por ejemplo los datos capturados el 06 de agosto de 2010 deber estar an en /var/log/snort/20100806. La unica cosa que necesita congurarse a mano son las opciones de registro de Sebek. A qu puerto e IP tienen los clientes Sebek que enviar sus registros, y si se e desea que todos los paquetes de Sebek sean registrados por el cortafuegos (Sebek puede ser bastante ruidoso, llenando sus registros de cortafuegos). Cuando el Honeywall haya capturado la actividad de Sebek en los cheros pcap de Snort, se pueden extraer manualmente los paquetes de Sebek desde la interface GUI. Otra de las caracter sticas es la habilidad para generar alertas automticas a cuando el sistema trampa ha sido comprometido. Las alertas estn implemena tadas actualmente utilizando correos electrnicos sin cifrar (en texto en claro). o Swatch, el Simple WATCHer, es el encargado de monitorizar /var/log/messages 48

en busca de actividad entrante y saliente. Si se detecta cualquier conexin o saliente, se genera una alerta y env un correo electrnico. Las direcciones a o de correo a las que son enviadas las alertas pueden ser conguradas a travs e del GUI. Las alertas de correo sirven para noticar a los administradores de la red trampa sobre los posibles equipos comprometidos. Ya que el Honeywall est congurado para trabajar en modo puente (bridge) de nivel dos (por dea fecto) entonces es necesario tener una tercera interface de gestin para poder o enviar las alertas. Cuando se env alertas por correo electrnico a travs de an o e la interface de gestin, se congura el cortafuegos para permitir la salida de o TCP/25 desde esa interface[26]. Herramientas para la Captura de Datos: Iptables (logs de iptables) Snort (alertas IDS) pOf (identicacin pasiva de SO) o Sebek (captura avanzada de datos) Tcpdump (captura de trco de red) a 3.1.3. Anlisis de datos a

A travs de la Generacin III de las Honeynets se ha logrado mejorar el e o anlisis de los datos, con respecto a las arquitecturas anteriores. En s la manera a , ms sencilla de realizar el anlisis y examinar el trco de red y los datos a a a recolectados en la Honeynet es la bsqueda de conexiones por fecha, tiempo, u direcciones IP y/o puertos que se muestran en la interface GUI Walleye, estos resultados pueden ser devueltos como un archvivo PCAP o en Walleye ow view, para mediante la utilizacin de herramientas de anlisis de trco de red o a a como por ejemplo Wireshark proceder al examinar los datos recolectados. Herramientas para el Anlisis de Datos: a MySQL (base de datos Honeynet para la recoleccin) o Argus + How (recoleccin de datos, ujo de trco y relaciones) o a Swatch (logs de rewall y alertas IDS) Walleye (interface grca de usuario) a

49

3.2.

Anlisis de servicios, aplicaciones y vulnerabilidades a de los servidores.

En primer lugar, antes de la captura y anlisis de los datos, es necesario a vericar que las aplicaciones que se han congurado en los servidores se encuentren disponibles y ejecutandose en los equipos. Para esto, hacemos uso de herramientas de escaneo de puertos abiertos y vulnerabilidades, como los son nmap y nessus. 3.2.1. Exploracin de servicios y aplicaciones con nmap y nessus. o

Luego de realizar un escaneo con las herramientas nmap y nessus de los servidores montados, los resultados acerca de los servicios y puertos abiertos, que arrojan las herramientas son los siguientes por cada servidor: Servidor DNS Servicios/aplicaciones instaladas: Cuadro 9: Servicios, puertos y aplicaciones instaladas en el Servidor DNS. PORT STATE SERVICE VERSION 0/icmp open general 22/tcp open ssh OpenSSH 4.6p1 Debian 5build1 (protocol 2.0) 53/udp open domain 53/tcp open domain 953/tcp open rndc Servidor WEB Servicios/aplicaciones instaladas: Cuadro 10: Servicios, puertos y aplicaciones instaladas en el Servidor Web. PORT STATE SERVICE VERSION 0/icmp open general 80/tcp open http Apache httpd 2.2.4((Ubuntu)PHP/5.2.3-1ubuntu6) 3306/tcp open mysql MYSQL 10000/tcp open http Webmin httpd Servidor EVA Servicios/aplicaciones instaladas:

50

Cuadro 11: Servicios, puertos y aplicaciones instaladas en el Servidor EVA. PORT STATE SERVICE VERSION 0/icmp open general 80/tcp open http Apache httpd 2.2.4 ((Ubuntu) PHP/5.2.3-1ubuntu6) 8009/tcp open ajp13? Apache JServ Protocol AJP Connector 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 Servidor WSUTPL Servicios/aplicaciones instaladas: Cuadro 12: Servicios, puertos y aplicaciones instaladas en el Servidor WSUTPL. PORT STATE SERVICE VERSION 0/icmp open general 25/tcp open smtp Microsoft ESMTP 6.0.2600.2180 80/tcp open http Microsoft IIS webserver 5.1 135/tcp open msrpc Microsoft Windows RPC 137/udp open netbios-ns 139/tcp open netbios-ssn 443/tcp open https? 445/tcp open microsoft-ds? 1027/tcp open msrpc Microsoft Windows RPC 1241/tcp open ssl/unknown

3.3.
3.3.1.

Herramientas utilizadas para el anlisis. a

Wireshark y Geolocalizacin de direcciones IP remotas. o

La geolocalizacin de direcciones IP remotas es una de las formas de vericar o las conexiones que se han dado y la ubicacin geogrca de las direcciones IPs o a remotas que han intentado realizar conexiones hacia los honeypots. Mediante las mltiples funcionalidades que presenta la herramienta de anliu a sis de trco Wireshark se puede realizar este anlisis. Con esto podemos oba a servar la gran cantidad de conexiones remotas que existen hacia los honeypots de todas partes del mundo:

51

Figura 20: Geolocalizacin de direcciones IP remotas o Fecha: Jueves 26 de Agosto. Pcap tomado de entre las 03:18am a las 4:18am 3.3.2. Anlisis con NetworkMiner. a

NetworkMiner es una herramienta Open Source para Analisis Forense de red, Network Forensic Analysis Tool (NFAT). Esta herramienta, incluye un snier o capturador de paquetes de red, puede detectar Sistemas Operativos, sesiones, hostnames, puertos abiertos etc. Con NetworkMiner tambin se puede analizar archivos PCAP, para un anlie a sis o-line. El Website es: http://networkminer.sourceforge.net

52

Figura 21: NetworkMiner como herramienta de anlisis a Mediante esta herramienta, podemos realizar el anlisis forense de los archivos a pcaps que se analice. Se presenta grcamente a detalle la informacin de los a o equipos que han intentado acceder a los honeypots, los puertos origen y destino que se han utilizado, protocolos, sesiones, etc.

53

Capitulo 4
ANALISIS, INTERPRETACION Y PRESENTACION DE RESULTADOS

54

4.

Anlisis, interpretacin y presentacin de rea o o sultados

Luego de haber implementado la Honeynet en la red de la UTPL, se ha comprobado el correcto funcionamiento de la misma y los instrumentos de recoleccin de datos estn puestos en marcha, se procede a realizar el tratamiento o a correspondiente para el anlisis y la interpretacin de los datos por cuanto la a o informacin que se arroje nos ayudar a poder sacar las conclusiones a las cuales o a se pretende llegar con el presente proyecto. En esta fase del proyecto se ha procedido a utilizar las herramientas necesarias para recolectar la informacin importante que se suscita en los servidores o externos implementados, un anlisis de los mismos a travs de reportes y esa e tad sticas que nos muestran el comportamiento y el trco que se genera hacia a los servidores. El anlisis de direcciones IPs, puertos afectados, protocolos que a han sido utilizados, reejados en los reportes, nos darn una idea o una visin a o de cuales son los servicios ms atrayentes para los atacantes. a

4.1.
4.1.1.

Reportes mensuales
Reportes mes de Agosto

Total de paquetes: 4560398 ICMP: 249809 TCP: 1254980 UDP: 3055609

Figura 22: Total paquetes mes de Agosto Conexiones totales a los Puertos por Protocolo En la gura siguiente se puede observar los puertos por protocolo los cuales han 55

sido utilizados por los atacantes:

Figura 23: Total paquetes mes de Agosto Servicios y puertos escaneados/probados por los atacantes. En la siguiente gura se muestran los los puertos que han sido probados por los atacantes.

Figura 24: Total puertos probados en el mes de Agosto.

56

Puerto tcp/22 tcp/80 icmp/0 udp/5060 tcp/445 tcp/139 tcp/1433 tcp/5900 tcp/1080

Cuadro 13: Puertos escaneados/probados. Agosto Frec. Descrip. Puerto Frec. Descrip. 46979 ssh tcp/2967 69 Simantec Antiv 3958 http tcp/3128 16 HTTP Squid 1134 echo reply tcp/8080 4 Apache Tomcat 213 sip tcp/25 86 smtp 131 microsoft-ds tcp/23 67 telnet 130 netbios-ssn udp/38293 47 Norton Antiv 102 ms-sql-server tcp/3389 20 WBT 93 vnc tcp/4899 55 radmin 4 SOCKS proxy tcp/1391 24 iclpv-sas

Direcciones IP atacantes Durante el mes de Agosto hubo una gran cantidad de direcciones IP atacantes, en la gura siguiente se muestra un top 30 de las mismas:

Figura 25: Direcciones IP atacantes - Agosto.

57

Dir. IP 113.59.254.6 200.0.29.35 121.207.246.76 189.11.11.130 200.24.102.242 200.19.191.194 190.214.121.0 58.221.206.189 200.144.189.73 116.45.181.64 61.128.122.13 58.221.206.189 92.242.121.254 121.15.226.230 219.143.225.34 4.1.2.

Cuadro 14: IPs atacantes - Agosto. Frec. Pa s Dir. IP Frec. 11817 hk 119.201.19.40 643 3371 ec 118.142.15.30 632 3125 cn 173.15.29.61 601 2978 br 201.238.198.110 593 2964 co 196.30.124.220 589 2644 br 212.150.123.120 555 2488 ec 27.0.8.8 465 2171 cn 217.18.252.117 408 1850 br 222.178.119.145 389 1779 kr 174.34.141.50 377 1121 cn 190.152.182.163 367 928 cn 184.82.62.156 327 881 uk 24.10.133.83 309 817 cn 200.80.237.214 285 755 cn 219.141.174.148 279

Cd. pa o s kr hk us cn sf il sg bg cn us ec us us ar cn

Reportes mes de Septiembre

Total de paquetes: 23499675 ICMP: 30724 TCP: 9989416 UDP: 13479535

Figura 26: Total paquetes mes de Septiembre

58

Conexiones totales a los Puertos por Protocolo. En la gura siguiente se puede observar los puertos por protocolo los cuales han sido utilizados por los atacantes:

Figura 27: Total paquetes mes de Septiembre Servicios y puertos escaneados/probados por los atacantes. En la siguiente gura se muestran los los puertos que han sido probados/utilizados por los atacantes.

Figura 28: Total puertos probados en el mes de Septiembre.

59

Puerto tcp/22 tcp/80 icmp/0 udp/5060 tcp/445 tcp/139 tcp/1433 tcp/5900 tcp/1080

Cuadro 15: Puertos escaneados/probados. Septiembre Frec. Descrip. Puerto Frec. Descrip. 78705 ssh tcp/2967 111 Simantec Antiv 5531 http tcp/3128 25 HTTP Squid 3699 echo reply tcp/8080 120 Apache Tomcat 920 sip tcp/25 141 smtp 253 microsoft-ds tcp/23 436 telnet 187 netbios-ssn udp/38293 222 Norton Antiv 368 ms-sql-server tcp/3389 96 WBT 279 vnc tcp/4899 133 radmin 12 SOCKS proxy tcp/53 549 domain

Direcciones IP atacantes A continuacin se presenta un top 30 de los equipos atacantes, en la siguiente o captura:

Figura 29: Direcciones IP atacantes - Septiembre.

60

IP 200.19.174.126 190.214.65.167 200.31.76.22 82.160.28.50 195.216.205.34 200.129.22.80 85.10.136.18 123.127.147.251 125.211.200.32 221.12.147.74 200.29.166.15 69.74.102.38 200.34.99.2 200.43.192.201 202.105.182.205 4.1.3.

Cuadro 16: IPs atacantes - Septiembre. Frec. Pa s IP Frec. 7346 br 121.207.246.76 1591 5247 ec 112.65.158.86 1508 5098 co 200.55.198.67 1120 4907 pl 200.175.44.248 1014 4379 uk 200.73.2.18 943 4151 br 200.208.160.114 936 3697 fr 120.195.108.22 727 3488 cn 200.0.29.35 702 2840 cn 190.145.115.130 678 2760 cn 200.248.115.130 629 2512 cl 213.186.127.167 593 2420 us 212.88.103.150 518 1911 mx 187.45.202.24 496 1869 ar 88.191.77.100 411 1840 cn 200.21.228.168 339

Cd. pa o s cn cn cl br co br cn ec co br uk ug br fr co

Anlisis de los Reportes mensuales a

El trco de red que se genera a diario en servidores pblicos o externos de a u una organizacin es de gran cantidad, debido a que estn expuestos y pueden ser o a vistos de la internet, el total de conexiones, incluyendo los protocolos TCP, UDP e ICMP, reejan la actividad y las conexiones que se establecen desde todas partes del mundo y la gran cantidad de direcciones IPs atacantes, al igual de los resultados obtenidos por la Honeynet clsica implementada en la UTPL. a Los reportes estad sticos de la Honeynet Virtual en los meses de Agosto y Septiembre, contrastan en gran medida con los resultados recogidos por otros proyectos Honeynet alrededor del mundo, tal es el caso de la Honeynet implantada en la Massey University de Nueva Zelanda en el proyecto Building and Deploying a GenIII Virtual Honeynet 2009[27], en el caso de los puertos afectados por los atacantes, puesto que en los resultados obtenidos de un mes de recoleccin de trco, las observaciones muestran que de un total de 29643 o a puertos y servicios probados, 29048 estaban dirigidos al protocolo SSH, seguido por el protocolo tcp 80 de HTTP. Al igual que en la Honeynet implantada en la Escuela Politcnica del Litoral e (ESPOL)[28], los resultados indican que el protocolo que genera ms trco de a a red es el protocolo SSH, seguido del protocolo HTTP. Esto signica que existe mucha relacin entre los resultados arrojados por o las Honeynets virtuales implementadas y que han instalados tales aplicaciones, siendo el protocolo ssh a travs del puerto tcp/22 el que ms intentos de ataques e a registra, ya sea por hackers, black hat, script kiddies, crackers, etc., desde todas partes del mundo y presenta el mayor trco debido a la ejecucin de scripts a o y/o herramientas automatizadas en la red, en busca de este puerto abierto y

61

poder lanzar el ataque comn de diccionario o fuerza bruta para lograr acceder u y apoderarse del equipo, por ello no se puede decir que en su totalidad las conexiones registradas se tratan de ataques o conexiones plenamente dirigidos. Con esto no se quiere decir que la seguridad sea deciente en la UTPL, pero tampoco no se puede asegurar que sta sea segura en su totalidad, ni tampoco e que este puerto especicamente y los otros sean fciles o dif a ciles de hackear, puesto que en cuestiones de seguridad y proteccin de la informacin siempre o o existe cierto grado de incertidumbre. Por estos motivos se deben tomar las medidas necesarias de seguridad para proteger este puerto, que como muestran los resultados es el blanco favorito de los atacantes de la red y lo que hace que cualquier equipo sea atractivo a los atacantes de cualquier parte del mundo.

4.2.
4.2.1.

Actividad en los servidores

Servidor DNS

El servidor DNS, ha sido el que ms intentos y conexiones presenta, por a tanto es el equipo que genera la mayor cantidad de trco de red ha generado, a puesto que en este servidor se ha instalado el SSH.

Protocolo SSH El puerto tcp 22, para SSH (Secure SHell), que es el protocolo que facilita las comunicaciones seguras entre dos sistemas utilizando una arquitectura clienteservidor el cual permite al usuario la conexin remota hacia un host y que utiliza o encriptacin en sus sesiones, con su especicacin completa detallada en el RFC o o 4251, es el protocolo con el mayor nmero de conexiones registradas desde todas u partes del mundo. Durante el mes de Agosto, las conexiones hacia este protocolo representaron el 88 % del total de conexiones hacia los puertos utilizados, teniendo en total 46979 intentos de conexiones. Para el mes de Septiembre, las conexiones hacia este mismo puerto, con una cantidad de 78705, representaron el 86 % de las conexiones totales hacia los puertos.

Protocolo DNS EL Domain Name System/Service o Sistema de Nombres de Dominio, es el sistema el cual tiene la funcin principal de traducir (resolver) nombres intelo igibles para los humanos en identicadores binarios asociados con los equipos conectados a la red, esto con el propsito de poder localizar y direccionar estos o equipos mundialmente. Se trata de una base de datos distribuida y jerrquica que almacena infora macin asociada a nombres de dominio en redes como Internet. Aunque como o

62

base de datos el DNS es capaz de asociar diferentes tipos de informacin a cao da nombre, los usos ms comunes son la asignacin de nombres de dominio a a o direcciones IP y la localizacin de los servidores de correo electrnico de cada o o dominio. El trco al servicio DNS es generado por las peticiones (request) que son a enviadas, y se env peticiones que requieren una bsqueda de DNS. El servidor an u DNS que recibe la peticin, buscan en primer lugar si dispone de la respuesta en o la memoria cach. Si es as proporciona la respuesta; en caso contrario, inicia e , la bsqueda de manera recursiva. Una vez encontrada la respuesta, el servidor u DNS guarda el resultado en su memoria cach para futuros usos y devuelve el e resultado. Este servicio, con su aplicacin principal (bind), que funcionan en el puero to tcp/udp 53, presentan una cantidad baja de conexiones hacia este servicio, siendo en un total de 13 conexiones en el mes de Agosto y de 549 conexiones en el mes de Septiembre, lo cual representa un 1 % del todal de conexiones en ese mes. 4.2.2. Servidor WEB

Protocolo HTTP El puerto tcp 80, para HTTP (HyperText Transfer Protocol), es un protocolo cliente-servidor, el cual articula los intercambios de informacin entre los clientes o Web y los servidores HTTP. La especicacin completa de este protocolo se o recoge en el RFC 1945. Con un total de 3958 conexiones en el mes de Agosto, que representan el 7 % del total de conexiones, se ubica como el segundo protocolo ms utilizado por a los atacantes hacia los servicios implementados. En el mes de Septiembre se registr un total de 5531 conexiones hacia el o puerto 80, lo cual representa el 6 % del total, es as mismo en este mes el segun do de los protocolos utilizados por los atacantes.

MYSQL Mysql es la base de datos generalmente empleada con las aplicaciones de servicio Web, el puerto de escucha por defecto es el 3306, puerto en el cual casi no han existido conexiones durante los meses de Agosto y Septiembre, teniendo una cantidad total de 30 conexiones registradas hacia este puerto. 4.2.3. Servidor EVA

Protocolo HTTP Los puertos y aplicaciones de este servidor son casi iguales a las utilizadas en el Servidor Weben cuanto se reere a conexiones en el puerto 80 y en el puerto 3306 del MySql, a diferencia que en este servidor se ha abierto tambien el puerto 8080 para los servicios de Apache-Tomcat.

63

En cuanto al puerto tcp 8080 abierto para Apache-Tomcat, los cantidad de registros de conexiones hacia este puerto son sumamente bajos, sumando un total de 124 conexiones en los meses de Agosto y Septiembre, representando una cantidad sumamente reducida. 4.2.4. Servidor WSUTPL

En cuanto al WSUTPL, este implementa servidor IIS con las conguraciones por defecto, emplea al igual que el servidor Web el puerto tcp 80 para implementar sus servicios. Todos los servicios que por defecto se cargan de entornos Windows, no han sido modicados para que sean explotados por los atacantes: Puerto 135 (TCP) - para el Servicio de Remote Procedure Call (RPC). Puerto 137 (UDP) - para el Servicio de nombres de NetBIOS. Puerto 138 (UDP) - para Netlogon y Browsing de NetBIOS. Puerto 139 (TCP) - para la sesin (NET USE) de NetBIOS. o Todos estos servicios y puertos han registrado trco en la Honeynet, pero a en menor cantidad. De los puertos que se han abierto en este servidor, se puede registrar mayor cantidad de actividad en el puerto tcp 445 que es utilizado por el protocolo SMB (Server Message Block) para entre otras cosas el compartimiento de archivos en Sistemas Operativos Windows. Las conexiones hacia este puerto son en total de 131 en el mes de Agosto y de 253 en el mes de Septiembre, qie se tratan de cantidades considerablemente bajas.

4.3.
4.3.1.

Actividades registradas
Alertas Snort.

Snort es un IDS o Sistema de deteccin de intrusiones basado en red (NIDS) o en tiempo real. Esta herramienta implementa un motor de deteccin de ataques o y barrido de puertos que permite registrar, alertar y responder ante cualquier anomal previamente denida como patrones que corresponden a ataques, bara ridos, intentos aprovechar alguna vulnerabilidad, anlisis de protocolos, entre a otras cosas. Los resultados de Snort y las alertas generadas, demuestran al protocolo ICMP como el protocolo ms afectado, con mayor cantidad de intentos de acceso, a debido a los rastreos que son realizados por los atancantes con herramientas automatizadas en busca de posibles equipos v ctmas vulnerables para poder aprovecharse de estas. Como en la Honeynet clsica implementada en la UTPL, desarrollada en la a tesis elaborada anteriormente, las alertas que genera Snort son casi las mismas, con esto se puede observar que las actividades de red apuntan o hacen match a las mismas reglas del Snort. A continuacin se muestra un listado de las alertas ICMP ms comunes o a generadas por Snort: 64

Cuadro 17: Alertas ICMP generadas por Snort.

Alertas comunes en otros protocolos generadas por Snort: Cuadro 18: Alertas a otros protocolos generadas por Snort. Alerta ID Snort NETBIOS SMB-DS IPC$unicode share access 2465 WEB-CGI awstats access 3463 (portscan) TCP Portsweep 122-3 SQL Worm propagation attemtp OUTBOUND 2003 (portscan) TCP Portscan 122-1 WEB-GCI calendar access 882 SNMP AgentX/tcp request 1421 SNMP trap tcp 1420 SNMP request tcp 480 As mismo, se tratan de casi las mismas alertas generadas por la Honeynet implantada en la Escuela Politcnica del Litoral (ESPOL), que en los [Anexos 8] e se muestran a detalle estas alertas registradas por Snort, en base a la informacin o de su pgina ocial[29]. a 4.3.2. Ataques de diccionario al puerto ssh (port 22)

La actividad hac los servidores (honeypots) virtualizados, qued registrada a a en los logs del sistema. A continuacin se muestra uno de los intentos de intrusin o o a uno de los servidores, utilizando la tcnica de diccionario al protocolo ssh. e Como se puede observar, este tipo de ataques son muy ruidosos, por lo que su actividad queda registrada y los administradores pueden darse cuenta de ello con facilidad revisando los logs del sistema. El siguiente es un intento de acceso a travs del protocolo ssh, desde un e equipo de Brazil:

65

Figura 30: Ataque de diccionario al puerto 22 ssh A continuacin se muestra el trco de red capturado con la herramienta o a Wireshark:

Figura 31: Ataque de diccionario al puerto 22 ssh analizado con Wireshark Asi mismo, gracias a la interface GUI Walleye, todo sta actividad queda e 66

registrada para su posterior anlisis: a

Figura 32: Ataque de diccionario al puerto 22 ssh registrado en la interface GUI Walleye 4.3.3. Actividades maliciosas/sospechosas

A continuacin se hace referencia a algunas de las actividades maliciosas/sospechosas o que se han dado en los honeypots, algunos hallazgos, ataques, herramientas, mtodos, etc. e Instalacin de backdoors o En unos de los Honeypots, se ha vericado la instalacin de un programa backo door, puerta trasera. Se trata de un Malware conocido como GodMessage. A continuacin algunos detalles de este malware: Nmero de puerto: 7777 o u Protocolo utilizado: tcp/udp Tipo de servicio : cbt

Figura 33: Instalacin de un backdoor o

67

Este malware abre una puerta trasera en un equipo comprometido para poderse loguear luego nuevamente. Abre una puerta trasera y escucha en los puertos ports 6868/tcp and 7777/tcp para la ejecucin de comandos. o Instalacin de remoteware-cl o RemoteShut Port Number: 3000 RemoteWare Client Protocol Used : tcp/udp Service Type : remoteware-cl Se trata de un malware conocido como

Hallazgos y Actividades ocurridas A continuacin se muestra un listado de algunas de las actividades que se han o registrado durante los dos meses, en el Honeywall, que se pueden observar a travs del anlisis de los pcaps en la herramienta Wireshark: e a Principalmente, ataques SSH de fuerza bruta sobre el puerto TCP/22. Symantec Antivirus desbordamiento en el puerto TCP/2967. La actividad de varios gusanos en los puertos UDP/137, TCP/139 y TCP/445. Windows RPC desbordamiento de bfer en el puerto TCP/135. u Windows Messenger spam en los puertos UDP/1026, UDP/1027 y UDP/1028. MSSQL desbordamiento de bfer en UDP/1434 puerto. u Instalacin de Malware, que utiliza conexiones IRC al puerto tcp 6667. o Esta informacin y algunas de las actividades listadas, se corroboran con la o informacin de los reportes generados en el Annual Status Report - 2007 del o The Pakistan Honeynet Project. Sitio ocial: http://www.honeynet.pk

4.4.
4.4.1.

Incidentes registrados
Ataque DOS a la red de la UTPL

Incidente El d Domingo 3 de Octubre, aproximadamente a las 18:30 de la tarde, se a informa a los administradores de la red de la UTPL acerca de la ejecucin de o un ataque de red, de una de sus IPs. La causa de este incidente fu el comprometimiento de un equipo (honeypot) e virtual, mediante el cual se generan ataques que inundan (ood) y colapsan la red de la UTPL, reejada en el abundante trco mostrado en la herramienta a de anlisis de trco Netow. a a

68

El incidente se produjo por el acceso al Honeypot(Linux) mediante el protocolo SSH, instalado y dispuesto con las conguraciones por defecto, se efectu con xito un ataque de fuerza bruta para encontrar la contrasea, que por o e n motivos de investigacin, era vulnerable voluntariamente. o Hallazgos sobre el incidente A continuacin se reporta algunos hallazgos sobre el incidente de seguridad. Alo guna de las actividades y comprobaciones que se han realizado son la siguientes: Borrado de logs e inhabilitacin de comandos. o Se comprueba el borrado de los logs del sistema, a travs del borrado del e directorio: /var/log/wtmp, que es donde se aloja toda la informacin de o accesos, login, etc., tambin se puede vericar la inhabilitacin de ciere o tos comandos, como las herramientas de red (net-tools)y aplicaciones de encendido y apagado del sistema, tales como netstat, last, lastb, w, who, shutdown, reboot, etc. Puertos abiertos/utilizados. Se ha vericado los puertos que se han dejado abierto en el sistema, se observa el puertos 31337/tcp de servicio Elite abierto, por la instalacin o de aplicaciones maliciosas:

Figura 34: Puerto que han sido abierto en el Honeypot comprometido. Aplicaciones instaladas. Las aplicaciones que han sido instaladas por el intruso son las siguientes: oobot.tar.gz Se trata de una aplicacin, diseada para inundar (oodo n ing) programas-chat, este programa ataca canales de IRC con una carga masiva de datos insignicantes que generan trco para inuna dar y colapsar el canal. psybnc-linux.tgz Esta aplicacin se trata de un bot IRC que tiene el o propsito de controlar la mquina. El motivo de controlar la mquina o a a comprometida mediante un bot IRC es poder utilizar la mquina sin a conectarse directamente a ella, dejando de esta forma menos huellas; as como poder controlar todas las mquinas comprometidas si a multneamente desde un unico canal IRC, e incluso con la capacidad a de mantener la sesin abierta sin la necesidad de estar conectado. o 69

Ya que se tiene el equipo comprometido, el destino de este servidor ha sido usado para enviar spam, adems que pudo haber servido de plataforma para atacar a a otras mquinas, usarlos como proxy, etc. a Como medida para evitar que esto vuelva a suceder se deber congurar un a servidor SSH de forma segura. Acciones realizadas En primer lugar, al momento de detectar el incidente, los administradores de la red UTPL, inhabilitaron el punto del switch al que se conectaba el honeypot, seguidamente se puso fuera de produccin la Honeynet temporalmente, hasta o tomar las medidas necesarias, a ms de sacar copias de la imagen de la mquina a a virtual a f de ser analizada posteriormente. n Pruebas de los Controles de Datos del Honeywall CONNECTION LIMITING Connection limiting es uno de los mtodos de control de datos. Las conexe iones salientes son contadas, y cuando ha alcanzado un cierto l mite, se rechaza cualquier conexin saliente. Las conguraciones por defecto son las siguientes: o

Figura 35: Connection Limiting - Control de Datos. Prueba: Una de las formas para probar el funcionamiento de este Control de Datos del Honeywall, es mediante la realizacin de un ping extendido desde un o honeypot. Las conguraciones por defecto de las conexiones salientes permitidas muestran un total de 50 como l mite para las conexiones ICMP, esto quiere decir, que al momento de realizar el ping extendido, este se deber bloquear al llegar a 50 que es el l mite.

70

Figura 36: Connection Limiting - Prueba de conexin. o Esto no sucede as por lo que a pesar de llegar al l , mite, las conexiones ICMP salientes no se bloquean y continan, fallando as este control. u VARIABLES FENCE LIST Otro de los controles de Datos del Honeywall es el uso de Fence List, es similar a una lista Negra/Blanca, la cual permite ltrar el trco a sistemas espec a cos o redes. Sin embargo, Fence List, no ltra conexiones entrantes a los Honeypots. En lugar de esto, Fence List, espec ca a que sistemas los Honeypots no pueden iniciar una conexin, esto es una medida de prevencin de seguridad, o o usualmente para proteger sistemas cr ticos. A continuacin se muestra el contenido del archivo fencelist.txt, en el cual o se ha incluido la direccin IP del servidor web de la UTPL (172.16.80.14), y se o ha procedido a realizar un ping para comprobar si existe o no la conectividad:

Figura 37: Fence List - Control de Datos. Resultado: Se ha podido realizar el ping satisfactoriamente hacia el servidor web de la UTPL, esto quiere decir que este control de Datos tambin no funcion. e o

71

Figura 38: Fence List - Prueba de conexin. o Conclusin sobre el incidente o Con las observaciones realizadas se deduce que se hizo uso del protocolo SSH por medio de tcnica de fuerza bruta o ataque de diccionario que se ven ree a alizando anteriormente con bastante frecuencia para poder apoderarse de la mquina. Los Controlos de Datos del Honeywall fallaron, al permitir las conexa iones salientes desde el Honeypot afectado y no fueron bloquedas permitiendo la realizacin exitosa del ataque. o No se puede deducir a que sistemas o redes fueron afectados por el ataque lanzado debido a que se los log del sistema fueron borrados. No todas las conguraciones que utiliza el protocolo SSH real implementado en el servidor DNS real de la UTPL fueron utilizadas, por ejemplo, la instalacin de la misma o versin de ssh, por motivos de compatibilidad. o Cabe sealar que el equipo que recolecta los paquetes de red Pcap ese f de n n semana, es decir, los d Sbado 2 y Domingo 3 de Octubre, colapso debido a as a la gran cantidad de trco que se ha generado y existe el riesgo de que no se a hayan recolectado paquetes de el d del ataque, puesto que fue en d Domingo a a y no se sac el respectivo pcap, por ello es de suma importancia, la asignacin o o del espacio de disco necesario e ir vericando constantemente que el espacio no se est agotando, as mismo establecer pol e ticas para descargas de pcaps diarias con el objetivo de mantener la informacin recolectada para el anlisis posterior. o a

4.5.

Patrones/comportamientos de ataques.

En base a la informacin obtenida, al incidente y las actividades, podemos o determinar que las acciones que toman los atacantes es la que comunmente siguen los hackers, es decir, los pasos y fases que involucran la anatom de un a ataque informtico, descrito en[30]: a 1. Reconocimiento (Reconnaissance): Es la fase donde se buscan las posibles v citmas y se obtiene la informacin necesaria antes de lanzar algun o ataque. El trco de red generado demuestra esto, en las conexiones que a se dan a travs de los mensajes icmp, que son respuesta a mensajes ping e que son lanzados para reconocer los equipos que estn levantados o en a produccin. o 72

2. Escaneo (Scanning): Esta fase es la fase previa al lanzamiento o ejecucin o de un ataque. En esta parte se utiliza toda la informacin que se obtuvo en o la anterior fase y lo que se hace es identicar las vulnerabilidades, puertos abiertos, aplicaciones instaladas con sus versiones. Gracias a la interface Walleye y a las alertas de Snort, se puede identicar estas actividades y el uso de herramientas como nmap, utilizada para este n. 3. Ganar Acceso (Gaining Access): Esta es la fase donde ya se ejecuta un ataque propiamente y es la fase de penetracin al sistema, gracias a la o explotacin de las vulnerabilidades, y fallas encontradas en la fase anterior. o En el caso del incidente sucitado especicamente, el atacante obtuvo el acceso a travs de la tcnica de ataque de diccionario o de fuerza bruta, e e donde se obtuvo la clave para ingresar al sistema v ssh. a 4. Mantener el Acceso (Maintaining Access): Una vez ingresado en el sistema el atacante hace uso de sus recursos y recursos del sistema y usa el sistema afectado como plataforma de lanzamiento de ataques para escanear y explotar a otros sistemas que quiere atacar, este fue el caso y se hizo un ataque de ooding (inundacin) para hacer colapsar la red. En esta fase o tambien se ha podido constatar la instalacin de troyanos y backdoors que o abren puertos para que el atacante se pueda conectar posteriormente. 5. Cubrir las huellas (Covering Tracks): En esta fase es donde el atacante trata de destruir toda la evidencia de sus actividades con el f de seguir n manteniendo el acceso al sistema comprometido ya que si borra sus huellas los administradores de redes no tendrn pistas claras del atacante y el a Hacker podr seguir penetrando el sistema cuando quiera y ademas evita a ser detectado. Las herramientas y tcnicas que usa para esto son caballos e de Troya, Steganography, Tunneling, Rootkits y la alteracin y borrado de o los log les (Archivos donde se almacenan todos los eventos ocurridos en un sistema informtico y permite obtener informacin detallada sobre a o los registros de los usuarios). El comportamiento de los atacantes de la red sigue un perl o un patrn, el o cual se basa en los puntos mencionados anteriormente, se cumplen las 5 fases solamente en el caso de un ataque informtico haya sido exitoso, y depende en a gran medida de los conocimientos del atacantes y de su habilidad y experiencia.

73

 DISCUSION, CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS

74

 DISCUSION En base al trabajo elaborado en este proyecto de n de carrera, se ha podido obtener como resultados la experiencia alcanzada en el desarrollo de las tecnolog Honeynet y el aprendizaje obtenido ha sido muy importante para el as desarrollo intelectual y acadmico en temas de seguridad informtica, redes y e a telecomunicaciones, anlisis de datos, etc. a A pesar de que las tecnolog Honeynet abarcan una amplia gama de temas as y los conocimientos son sumamente extensos forman un interesante campo en temas de seguridad y proteccin de la informacin de la cual se puede extraer o o mucha informacin y generar conocimiento acerca de los riesgos a los que estn o a expuestos los sistemas computacionales. Para el desarrollo del proyecto, se abarcaron temas de mucho inters e impore tancia como lo son el trabajar con nuevas e innovativas herramientas de seguridad, el desarrollo de temas de virtualizacin, diseo de redes, implementacin de o n o servicios y servidores, trabajo con plataformas Linux y Windows, el anlisis de a trco, uso de herramientas de red, estudio de vulnerabilidades, anlisis forense, a a entre otros, los cuales permitieron darle forma y poder culminar el proyecto. Como en cualquier proyecto, existieron facilidades e inconvenientes en el desarrollo del mismo. En cuanto a las facilidades prestadas por los administradores de los servidores, de los cuales se obtuvo la informacin para evaluar la criticio dad de los servicios externos a implementar en los Honeypots de la Honeynet, as tambien a los administradores de red, que facilitaron y agilitaron el trabajo en cuanto a asignacin de recursos necesarios para implementar la estructura o Honeynet Virtual. Tambin los inconvenientes que se dieron a lo largo del desarrollo del proyece to, como el trabajo realizado en un equipo de pruebas, y la demora en la entrega del equipo propio, hicieron tambin que el trabajo se retrase un poco. Problee mas propios del proyecto como lo fue la instalacin de la herramienta de captura o de trco: Sebek, debido a su reducido soporte y poca asistencia por parte de a proyectos honeynets de varias partes del mundo. Por ello se vi obligado el camo bio de plataformas, por aquellas que den soporte a la herramienta Sebek, como lo es Ubuntu 7.10 Server para Linux y Windows XP Profesional para plataformas Windows. Los resultados que arroja la implementacin de esta Honeynet Virtual, son o un aporte para la investigacin y el desarrollo de la seguridad dentro de la UTo PL, sus resultados contrastan en gran medida con los resultados de la Honeynet clsica implementada en la UTPL y de la ESPOL y de otros proyectos similares a alrededor del mundo, tal como el proyecto Honeynet de la Massey University de Nueva Zelanda, Honeynet.br de Brasil, el proyecto Honeynet de la UNAM de Mexico, Honeynet.pk de Pakistan, donde concluyen que el puerto ms afectado a es el puerto tcp/22 y las direcciones origen atacantes son de pa ses principalmente de Asia y Europa. Gracias a la recoleccin de los datos se puede tener una idea ms clara del o a nivel de exposicin de los servicios externos de la UTPL, y sus servicios en la o web. 75

A pesar de que el tiempo de recoleccin de datos fue corto, se puede decir que o fue el suciente para poder capturar y analizar el trco de red y las actividades a maliciosas para su posterior anlisis, sin embargo, para poder armar un perl o a un patrn de comportamiento con mayor grado de precisin ser conveniente o o a el anlisis de datos recolectados en un periodo mucho ms largo de tiempo. a a Ahora, lo que se pretende es abrir nuevos campos en la investigacin acerca o de las Honeynets como herramienta de seguridad informticas y explotarla para a obtener el mayor conocimiento que puede brindar, tambin aperturar nuevos e temas de investigacin para trabajos futuros dentro de la UTPL. o

76

CONCLUSIONES Conclusiones inherentes a la Honeynet: Debido a que los Honeypots implementados y ubicados en la red externa actan como sensores, la cantidad de trco de red que se genera en estos es u a sumamente elevada, con un estimado diario de 125025 paquetes entrantes por 36844 paquetes de salida, ste trco que es capturado por la Honeynet e a Virtual ocupa gran cantidad de espacio diariamente en el Honeywall. La gran cantidad de trco de red recolectado, y la total de paquetes a registrados a diariamente, nos indica la accesibilidad y la acogida de la Honeynet en la internet, asi como el nivel de exposicin de los servicios o cr ticos externos implementados en la misma, a travs de escaneos autome atizados, ejecucin de scritps, herramientas de rastreo y descubrimiento, o etc. El trco que se ha capturado, muestra que el puerto 22 de ssh, con una a cantidad total de 125684 conexiones en los dos meses de recoleccin de o datos, y que representa aproximadamente 87 % de la conexiones totales en ese lapso de tiempo, es el blanco favorito de atacantes, hackers, black hat, script kiddies, crackers, etc., por simplicidad o porque quizs este sea a el ataque ms difundido y fcil de ejecutar por cualquier internauta y que a a no requiere de amplios conocimientos, sin embargo, esto no signica que los otros puertos y protocolos estn libres de ataques. e Segn los resultados, el puerto tcp 80 de HTTP, se convierte en el segundo u puerto favorito de los atacantes, para aprovecharse de los sitios web mal congurados o vulnerabilidades que pudieran tener los mismos, con el objetivo maliciosos de robar o alterar informacin importante, a travs o e de ataques phishing (suplantacin de identidad), o por el simple hecho de o dejar fuera de funcionamiento un sitio web ya sea por ego o por medir sus conocimientos y habilidades. Los resultados obtenidos nos muestran el siguiente TOP 3 de protocolos afectados, donde la mayor cantidad de trco que se ha generado es hacia a el puerto tcp 22 de ssh con un 87 % del total del conexiones, seguidamente el puerto tcp 80 de http, el cual representa un 7 % del total de conexiones y seguidos de estos, el protocolo icmp con mensajes de respuesta hacia peticiones icmp (type 0 Echo reply) con un 4 % del total de conexiones. Esto se debe a que en la internet existen equipos automatizados que realizan barridos de direcciones y puertos para poder identicar y explotar las vulnerabilidades de los equipos y por ello se generan estas alertas a estos protocolos. Los datos recolectados en el periodo de dos meses aproximadamente, el trco generado y los resultados que arroja la implementacin de esta a o 77

Honeynet Virtual, contrastan en gran medida con los resultados de la Honeynet clsica implementada en la UTPL[7], desarrollada anteriormente y a de la Honeynet de la ESPOL y de otros proyectos similares alrededor del mundo, tal como el proyecto Honeynet de la Massey University de Nueva Zelanda, Honeynet.br de Brasil, el proyecto Honeynet de la UNAM de Mexico, Honeynet.pk de Pakistan, en los cuales se evidencia el comportamiento de los atacantes de la internet as como los protocolos y puertos que se utilizan y se concluye que el puerto ms afectado es el puerto a tcp/22 y las direcciones origen atacantes son de pa principalmente de ses Asia y Europa, con lo que se puede validar los resultados obtenidos en este proyecto. Los Controles de Datos implementados por el Honeywall, tal como la opcin Connection Limiting o limitacin de conexiones salientes y el o o Fence List para evitar que desde un Honeypot se hagan conexiones hacia un sistema o una red espec ca, no son efectivos en su totalidad, al menos en una Honeynet Virtual, esto se ha visto reejado en las pruebas efectuadas y en los hechos de seguridad suscitados. Por esto, se deben establecer tambin otros mecanismos de control como rewalls e iptables en e cada uno de los honyepots. A pesar de que se ha realizado pruebas en diferentes entornos y plataformas y con las diferentes versiones de la herramienta, la aplicacin Sebek o de captura de trco de red y pulsaciones de teclado, unicamente se ha a podido instalar en Ubuntu 7.10 Server, en plataformas Linux, y en Windows XP Profesional, en plataformas Windows. Conclusiones inherentes al proyecto: La seguridad es un punto cr tico en el momento de implementar una honeynet virtual, se debe tomar las medidas necesarias y probarlas antes de poner en ejecucin la honeynet, como por ejemplo, los controles de datos o que se establecen en el Honeywall, con el objetivo de poder evitar situaciones indeseables y que puedan poner en riesgo la seguridad de la red de produccin. o Gracias a las ventajas que representa el uso de la virtualizacin se puede o reducir notablemente el espacio f sico y los recursos hardware necesarios y sus costes asociados, para poder implementar y simular una red de servidores, adems de la facilidad de incorporar nuevos recursos para los a servidores virtualizados. En base a la informacin obtenida, al incidente y las actividades rego istradas por la Honeynet, se puede determinar que las acciones que toman los atacantes es la que comunmente siguen todos los hackers, es decir, los pasos y fases que involucran la anatom de un ataque informtico, los a a 78

cuales son: 1. Reconocimiento, 2. Escaneo, 3. Ganar el acceso, 4. Mantener el acceso, 5. Cubrir huellas; a travs de tcnicas y uso de herramientas, e e por ello depende en gran medida de los conocimientos del atacante y de su habilidad y experiencia para que el ataque sea o no exitoso. Las conexiones y el trco que se ha capturado en los resultados, nos a indican de que con el solo hecho de implementar y hacer uso de servicios y protocolos de red, los servidores de la UTPL son monitoreados, observados y visitados desde cualquier parte del planeta, especialmente al hacer uso de servicios tradicionales y habituales, como HTTP y SSH que los hacen atractivos al resto del mundo. A travs de los resultados obtenidos, no se quiere decir que el nivel de la e seguridad sea deciente en la UTPL, pero tampoco no se puede asegurar que ste sea segura en su totalidad, ni tampoco que el puerto tcp/22 de ssh e especicamente y los otros sean fciles o dif a ciles de hackear, puesto que en cuestiones de seguridad y proteccin de la informacin siempre existe o o cierto grado de incertidumbre. Pese a que se logr capturar y analizar el trco de red y las actividades o a maliciosas hacia los servidores implementados, el corto lapso de tiempo de recoleccin de datos dicult armar un perl o patrn de comportamiento o o o con mayor precisin y exactitud. o

79

RECOMENDACIONES La arquitectura de la Honeynet a implementar se debe escoger en base a los recursos que se tenga disponibles y la que mejor se adapte a los requerimientos del proyecto, tomando en cuenta tambin aspectos importantes e como la ubicacin en la red, la seguridad, los riesgos, etc. o El equipo antrin (host), debe ser un equipo robusto capaz de dar soo porte a una red de honeypots, asi tambin como al Honeywall, siendo ste, e e el elemento que ms recursos consumen en cuanto a espacio en disco se a reere, por cuanto, el espacio de disco que fue asignado para el proyecto fue de 160 Gb aproximadamente, el cual satur en el lapso de dos meses. o Es importante que los administradores de servidores que implementan aplicaciones como SSH, controlen el l mite de las conexiones a estos puertos que son permitidas y su conguracin correcta, para evitar posibles o ataques. Revisar el estado de todos los elementos de la Honeynet Virtual, en especial el correcto funcionamiento del Honeywall, ya que este se puede saturar con facilidad debido a la gran cantidad de conexiones que se registran. Si el espacio en disco que se le ha asignado al equipo Honeywall se completa, a pesar de que la Interface Walleye est aun en funcionamiento, ya no se e registrarn los pcaps correctamente. a Se debe buscar seguir promoviendo y explotando las tecnolog Honeynets as con la nalidad de servir de apoyo y ayuda a las organizaciones para conocer los riesgos y los peligros a los que estn expuestos en la internet, a sto se da a travs de la captura y anlisis del trco que ha capturado la e e a a Honeynet. Para el anlisis y la interpretacin de los resultados, se requiere de vasa o tos conocimientos y habilidades en temas de redes, protocolos, conguraciones, servidores, sistemas operativos, etc., para poder denir, interpretar e identicar correctamente cuando se trate de un comportamiento anmalo o y poder sacar las conclusiones correctas y adecuadas del trco capturado. a Las Honeynets como herramientas nuevas, cubren un amplio campo dentro de la seguridad informtica, y ser recomendable el estudio y anlisis a a a de los componentes del Honeywall Roo como una nueva plataforma o sistema operativo, su forma de operar, sus versiones, su funcionamiento, sus ventajas, desventajas, las limitaciones, etc., como una manera de buscar sacar el mximo provecho a esta herramienta. a Utilizar varias herramientas para el anlisis del trco de manera que se a a pueda permitir el entendimiento del comportamiento y poder sacar las conclusiones correctas en base a los resultados que estas arrojen.

80

Para una mayor comprensin de los incidentes, intentos de ataques, como prometimientos, etc., es necesario dedicar gran la mayor cantidad de tiempo posible para analizar los datos recogidos por la Honeynet, puesto que la informacin que se recoge es abundante. o Puesto que se ha comprobado el riesgo de utilizar esta tcnolog debido e a, a los Controles de Datos, se sugiere el ensayo de la implementacin de o Honeynets H bridas, que ha diferencia de la Honeynet auto-contenida, el uso de dispositivos reales puede ayudar al mejoramiento del Control de Datos y poder mitigar los riesgos. Los resultados de la Honeynet auto-contenida nos muestran que se trata de una herramienta de ayuda para el mejoramiento de la seguridad, a pesar de los riesgos encontrados, puede servir de apoyo al tratarse de una herramienta de seguridad, como un snier a gran escala, y que servir a para el anlisis del trco de red que puede capturar. a a Mantener contacto con los administradores de la red, alertar y dar avisos oportunos sobre posibles comportamientos anmalos en la red a f de evio n tar posibles daos, pasando la informacin obtenida a travs de informes n o e para su posterior manejo. Es recomendable una administracin global centralizada, esto se puede o lograr a travs de la utilizacin de la virtualizacin, puesto que todos sus e o o componentes y elementos se encuentran incorporados en un solo equipo antrin. o No olvidar documentar hechos o incidentes que se hayan producido y reportarlos a las personas responsables o encargadas. Se debe tener un respaldo de seguridad de toda la informacin, sacaro le copias de las imgenes de la mquinas virtuales, con el f de poder a a n restablecer la Honeynet en caso de ca das. Establecer como pol tica, el obtener y descargar los pcaps diariamente con los registros del trco de red, esto con la nalidad de tener esta a informacin de apoyo para anlisis forense. o a Uno de los principales componentes de una Honeynet, la interface web Walleye, no es una interface al ciento por ciento ecaz, puesto que presenta frecuentemente ca das y funcionamiento irregular, es por ello que no se puede depender solamente de esta interface para visualizar grcamente a lo que est ocurriendo con el trco en la red. a a Si bien, se logr obtener resultados de las actividades de red de los servicios o cr ticos externos de la UTPL, para poder armar un perl o un patrn o de comportamiento malicioso con mayor precisin, es recomendable la o recoleccin de datos de un periodo mucho ms prolongado de tiempo y un o a seguimiento ms a detalle y a profundidad de los datos recolectados. a 81

TRABAJOS FUTUROS La culminacin del presente proyecto abarca una gran cantidad de temas, o aspectos y conceptos de seguridad de redes, que ser conceptos relativamente an nuevos que estn en evolucin permanente. a o Una de las maneras de buscar el desarrollo y mejoramiento de los resultados de las tecnolog Honeynet es la investigacin de las Honeynets distribuidas, as o las cuales se tratan de infraestructuras abiertas de redes trampa, que permite la colaboracin entre administradores de red y analistas de datos, esto permite, a o los proyectos honeynet trabajar conjuntamente y aprender acerca de los ataques globales al tiempo que se garantiza la integridad de los datos. Si bien el proyecto The Honeynet Project ha construido herramientas comunes para la recopilacin o de datos IDS y anlisis, no se proporciona un paquete completo y un plan de a colaboracin. o Como parte de este desarrollo de Honeynets Virtuales, ya existe el proyecto: The Distributed Honeynets Project, que es el proyecto de investigacin relatio vamente nuevo. El proyecto de Honeynets distribuidas se estableci como ayuda a los ado ministradores de red aplicar un enfoque coordinado del sistema de deteccin o de intrusos mediante el uso de software de cdigo abierto con el benecio de o anlisis de datos de colaboracin y el intercambio de alertas de red. a o

82

Referencias
[1] The honeynet Project, Know Your Enemy: Honeynets (en l nea), Disponible en: http://old.honeynet.org/papers/honeynet/ [2] Conoce a tu enemigo: Redes trampa en universidades, Disponible en: http://his.sourceforge.net/honeynet/papers/edu/ [3] GSI-FING (2007) T tulo: Honeypots (parte I) [4] Conoce a tu enemigo: Honeynets (en l nea), http://his.sourceforge.net/honeynet/papers/honeynet/ Disponible en:

[5] Traap Jorge, Titulo: ICIHONEY: Diseo e Implementacin de una Red n o Trampa en el Instituto de Informtica de la Universidad Austral de Chile a [6] The honeynet Project, Conoce a Deniendo honeynets virtuales (en l nea), http://his.sourceforge.net/honeynet/papers/virtual/ tu enemigo: Disponible en:

[7] Montalvn Henry, Titulo: Estudio de trco de ataques a la red de la a a UTPL mediante la implementacin de un prototipo de Honeypot. 2010 o [8] The honeynet project, Honeywall CDROM (en l nea), Disponible en: http://his.sourceforge.net/honeynet/tools/cdrom/ [9] Conoce a tu enemigo: Honeywall CDROM (en l nea) Disponible en: http://his.sourceforge.net/honeynet/papers/cdrom/ [10] Romero L. Mayra, Titulo: PCN: Plan de continuidad de negocio, 2002 [11] Seguridad Informtica, Masiva actualizacin coordinada de servidores a o DNS: Grave vulnerabilidad en la implementacin del protocolo que suso tenta Internet (en l nea) Disponible en: http://bit.ly/cXrZF5 [12] CSIRT, Gestin de Incidentes de Seguridad Informtica y Teleo a comunicaciones, (en l nea) Disponible en: http://www.csirtantel.com.uy/principal/CA-AL-17-1109 [13] Inteco CERT, T tulo: Vulnerabilidad en Apache Tomcat (CVE-20092902). (en l nea) Disponible en: http://bit.ly/aIeOuD [14] Inteco CERT, T tulo: Vulnerabilidad en JE Event Calendars (com jeeventcalendar) para Joomla! (CVE-2010-0795) (en l nea) Disponible en: http://bit.ly/bbEcC7 [15] Inteco CERT, (en l nea) Disponible en: http://bit.ly/cUEVPw [16] Wikipedia, Titulo: Virtualizacin, (en l o nea) http://es.wikipedia.org/wiki/Virtualizaci%C3%B3n Disponible en:

83

[17] Federacin de enseanza de CC.OO. de Andalucia, Tituo n lo: Temas para la Educacin, (en l o nea), Disponible en: http://www.fe.ccoo.es/andalucia/docu/p5sd6337.pdf [18] Lugo Yuli, Titulo: Mantenimiento de equipos de cmputo, (en l o nea) Disponible en: http://www.scribd.com/doc/19007058/CONFERENCIADE-REDES [19] Slice of Linux, Titulo: Qu es la virtualizacin?, (en l e o nea), Disponible en: http://sliceoinux.com/2009/06/11/ %C2 %BFque-es-lavirtualizacion/ [20] Wikipedia: VMware, (en http://es.wikipedia.org/wiki/VMware l nea) Disponible en:

[21] Carbonwind, Titulo: VMware Server Networking Options, (en l nea) Disponible en: http://bit.ly/9PPL9b [22] Balas Edward, Viecco Camilo, (2005) Titulo: Towards a Third Generation Data Capture Architecture for Honeynets [23] The Honeynet project, Titulo: Sebek, (en l nea), Disponible en: https://projects.honeynet.org/sebek/ [24] Prado Javier, Jones Heather, T tulo: Building a Heterogeneous Honeynet 2005. [25] Siles Ral, Titulo: Honeynets, Conoce a tu enemigo u [26] The Honeynet project, Titulo: Conoce go: Aprender con VMware, (en l nea) http://his.sourceforge.net/honeynet/papers/vmware/ a tu enemiDisponible en:

[27] Massey University, T tulo: Building and Deploying a GenIII Virtual Honeynet, Disponible en: http://seat.massey.ac.nz/projects/honeynet/honeynet.htm [28] Aviles Jorge, Pazmio Mayra, T n tulo: CAPTURA Y ANALISIS DE LOS ATAQUES INFORMATICOS QUE SUFREN LAS REDES DE DATOS DE LA ESPOL, IMPLANTANDO UNA HONEYNET CON MIRAS A MEJORAR LA SEGURIDAD INFORMATICA EN REDES DE DATOS DEL ECUADOR, Disponible en http://bit.ly/auFDeS [29] Snort, (en l nea) Disponible en: https://www.snort.org [30] Monroy Lopez Daniel, T tulo: ANALISIS INICIAL DE LA ANATOM IA DE UN ATAQUE A UN SISTEMA INFORMATICO Mxico D.F. 2009. e

84

ANEXO 1
Inventario de los servidores crticos externos de la red de la UTPL.

ID

Servidor

Administrador

DIR IP

DIR PUBLICA

Dependencia

Descripcin Servidor de Base de Datos del EVA_x000D_ Base de datos de EVA externos_x000D_ Base de Datos de Dspace_x000D_ Base de datos de Wordpress y Joomla_x000D_ Mysql_x000D_ PostgreSql Servidor Web de EVA Web Web respaldos DNS extreno INTRANET CITTES MODULO DE PROYECTOS Y REPOSITORIOS DE DATOS Servidor Antispam Servidor Antispam Servidor de Backup del cajanuma. Actualmente es utilizado para entorno de pruebas con la base de datos Oracle 9.0.2.0.8 SErvidor de Aplicaciones. Encuesta, Agenda, Pedido de Videos en Linea. Meeting Servidor Wed de Sistemas de informacin Geogrfica, con servicio de servidor de mapas y base de datos espaciales,

Sistema Operativo

Entorno

7 20

BDVIRTUAL

EVA GDR1.UTPL.E 22 DU.EC GDR1BACK.UT 23 PL.EDU.EC 24 34 38 39 44 GDR2 INTRANETCIT TES MX1 MX2 PALTAS

Rodrigo Patricio Lopez Rodrigo Patricio Lopez Ramiro Ramrez Diana Alexandra Torres Guarnizo Ruperto Alexander Lpez Lapo Ana Lucia Abad Ruperto Alexander Lpez Lapo Ruperto Alexander Lpez Lapo Juan Carlos Morocho Rodrigo Barba Vctor Gonzlez

172.16.X.X 172.16.X.X 172.16.X.X 172.16.X.X

200.0.X.X 200.0.X.X 200.0.X.X 200.0.X.X 200.0.X.X

Unidad de Virtualizacin Unidad de Virtualizacin Gestin del Conocimiento Gestin del Conocimiento Grupo de Telecomunicaciones Dir. G CITTES Grupo de Telecomunicaciones Grupo de Telecomunicaciones Grupo de Desarrollo de Software Unidad de Video Conferencias Sistemas de Informacin

Produccin Centos Centos 4.4 Centos 5 Centos Windows 2003 Server Slackware 12 Slackware 12 Solaris Windows 2003 Server Windows 2003 Server Produccin Produccin Produccin Produccin Produccin Produccin Produccin Pruebas Produccin Produccin

172.16.X.X 172.16.X.X 172.16.X.X 172.16.X.X

200.0.X.X 200.0.X.X 200.0.X.X 200.0.X.X 200.0.X.X

49 PRODUCCION 52 SIGSERVER

172.16.X.X

200.0.X.X

Geogrfica 55 61 65 66 67 SUNBLADE2 VIDEOCONTV VPN WEBMAIL WSUTPL Juan Carlos Morocho Rodrigo Barba Julia Pineda Ruperto Alexander Lpez Lapo Viviana Montao 172.16.X.X 172.16.X.X 172.16.X.X 172.16.X.X 200.0.X.X 200.0.X.X 200.0.X.X 200.0.X.X 200.0.X.X Grupo de Desarrollo de Software Unidad de Video Conferencias Grupo de Telecomunicaciones Grupo de Telecomunicaciones Grupo de Desarrollo de Software Estacin de trabajo utilizada como servidor. Base de datos para las Academias Transmisin de TV por internet. Unidad de videoconferencias UTPL Servidor de VPN y Netflow Frontal del servidor Mail Servidor Internet. Servicios en lnea: centros, docentes, matrcula en lnea Solaris Win XP Ubuntu Centos Windows 2003 Server Produccin Produccin Produccin Produccin Produccin

ANEXO 2
En los siguientes se muestran las encuestas realizadas a los Administradores de los Servidores Crticos Externos y las encuestas realizadas a los Lderes de cada Grupo en los que se administran dichos servidores.

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a Lderes de Grupo.

El objetivo de la presente encuesta es la recoleccin de informacin relevante y actualizada acerca de los servidores/servicios para el anlisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: DNS Externo Qu servicio ofrece? Servidor de Nombres de Dominio. El servidor se encuentra en produccin: SI( x ) A que dependencia pertenece: UPSI GTE Como cataloga el nivel de criticidad del servicio/servidor Alto( x ) Medio( ) Bajo( ) Nmero de usuarios del servicio: Toda la red UTPL. Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( x ) Medio ( ) Leve( ) Por qu? Si este servicio falla no se tendra acceso a ciertos dominios en la red, las direcciones de cierto dominio se podran reconocer como no validas y con ello no se podrn realizar las actividades diarias, provocando prdidas y molestias en los usuarios. Interacta con otros sistemas? Cules? o Web o Webmail SI( x ) NO( ) NO( )

Hardware/Equipo:

Procesador Memoria RAM

Software:

Pentium IV 3GHz 1 Gb

Sistema Operativo/Plataforma Distribucin Versin Kernel

Servicio:

Linux Centos 5.4 2.6.18

Aplicacin Versin Parches / actualizacin Puertos abiertos Otras aplicaciones instaladas

Red:

Bind 9.3.6 P1.el5_4.1 53 UDP/TCP - dns 22 TCP - ssh Servidor ssh

Nombre del servidor Direccin IP4 externa/pblica Direccin IP6 externa/pblica Ubicacin en la red
Seguridad -

gdr2.utpl.edu.ec 200.0.X.X 2800: .X. :X.X:.X.X:.X/XX Red externa, junto al router de borde

Parches/actualizaciones instaladas para dicho servicio o sistema operativo El servidor y las aplicaciones se encuentran actualizados con las ltimas versiones y parches de seguridad.

Flujo de datos: No se tiene un flujo exacto de trfico de red, puesto que este equipo no se est monitoreando an en el NOC-UTPL, pero se tiene previsto su monitoreo lo ms pronto con la herramienta Argus. Informacin Adicional: Administrador: Ing. Alexander Lopez

Tesista: Csar A. Montalvn C. [email protected]

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a Lderes de Grupo.

Luego de realizar un anlisis acerca de los servicios crticos externos de la UTPL, se ha recolectado cierta informacin por parte del administrador, que necesita ser corroborada por ud(s), como lder del grupo en el que se encuentra o se administra el servidor en produccin, para verificar si estos servicios externos son realmente crticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera ms objetiva:

SERVIDOR:

Servidor DNS Externo gdr2.utpl.edu.ec

Cmo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Alto ( X ) Medio ( ) Bajo ( )

Por qu? Porque es el registro de los nombres de Dominio de la UTPL.

Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( )

Cul cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable ( ) Moderada ( ) Espordica (X ) Nunca ( )

Qu pasara si el servicio deja de funcionar (indisponibilidad) y cmo cree que afectara a las actividades de la Universidad? Desde el exterior no se podrn resolver los nombres de Dominio de la UTPL Internamente existen los DNSs internos.

Considera Ud. que el servidor DNS Externo (gdr2.utpl.edu.ec), es un servicio muy crtico e imprescindible para la Universidad? SI ( X ) NO ( ) Considera Ud. algn otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI ( X ) NO ( ) Cules? 1. Acceso a Internet (Servicios) 2. Frontal Web de acceso al correo electrnico Por qu? 1. Todas las actividades hacia el exterior se paralizaran. 2. Si el frontal est fuera de servicio nadie pudiera acceder al correo mediante el navegador. Informacin adicional

Gracias por su colaboracin

Ing. Carlos Crdova Lder del Grupo de Telecomunicaciones

Tesista: Csar A. Montalvn C. [email protected]

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a Administradores.

El objetivo de la presente encuesta es la recoleccin de informacin relevante y actualizada acerca de los servidores/servicios para el anlisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: Servidor WEB (GDR1) El servidor se encuentra en produccin: Qu servicio(s) ofrece? Servicio Web de la UTPL. A que dependencia pertenece: Gestin del Conocimiento Interacta con otros sistemas? Cules? o Servidor Oracle. SI( X ) NO( ) SI( X ) NO( )

Nmero de usuarios del servicio: Mayor a mil.

Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( )

Qu pasa si el servicio deja de funcionar (indisponibilidad) y cmo cree que afectara a las actividades de la Universidad? No se podra acceder al servicio Web que ofrece la UTPL para estudiantes presenciales y de la modalidad a distancia, as tambin como docentes y administrativos.

Hardware/Equipo:

Procesador Memoria RAM

Software:

IBM 1.6 GHz 10 Gb

Sistema Operativo Distribucin Versin Kernel Parches/actualizacin

Linux Centos 4 2.6

Servicio:

Aplicacin principal Versin Otras aplicaciones instaladas (Versin)

Puertos abiertos

Apache 2.6 - MySQL 5 - PHP 5.2.9 - Cliente Oracle 11.1.0 - Wordpress - Webmin - Sendmail - Squirrelmail - Joomla - Drupal 80 http 3306 1521

Parches/actualizacin
Red:

Nombre del servidor Direccin IP4 externa/pblica Direccin IP6 externa/pblica Ubicacin en la red
Informacin Adicional: Tiempos crticos en tiempos de matriculas.

gdr1.utpl.edu.ec 200.0.X.X 2800:XX:XX:XX:XX:XX:XX:XX

Administrador: Ing. Ramiro Ramirez

Tesista: Csar A. Montalvn C. [email protected]

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a Lderes de Grupo.

Luego de realizar un anlisis acerca de los servicios crticos externos de la UTPL, se ha recolectado cierta informacin que se necesita ser corroborada por ud(s), como lder del grupo en el que se encuentra o se administra el servidor en produccin, para verificar si estos servicios externos son realmente crticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera ms objetiva:

SERVIDOR: WEB gdr1.utpl.edu.ec

Cmo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Alto ( X ) Medio ( ) Bajo ( )

Por qu? Es el acceso a la informacin, la presencia de la UTPL EN LA Web, adems de ser la puerta de acceso a otros servicios.

Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( )

Cul cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable ( ) Moderada ( ) Espordica (X ) Nunca ( )

Qu pasara si el servicio deja de funcionar (indisponibilidad) y cmo cree que afectara a las actividades de la Universidad? Se perdera el acceso a otros servicios como EVA, SGA. Los estudiantes, docentes y administrativos no podran utilizar las herramientas web disponibles.

Considera Ud. que el servidor Web (gdr1.utpl.edu.ec) externo, es un servicio muy crtico e imprescindible para la Universidad? SI (X ) NO ( )

Considera Ud. algn otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI () NO (X ) Cules? Por qu? Informacin adicional

Gracias por su colaboracin

Ing. Germania Rodrguez Lder del grupo de Gestin del Conocimiento.

Tesista: Csar A. Montalvn C. [email protected]

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a los Administradores.

El objetivo de la presente encuesta es la recoleccin de informacin relevante y actualizada acerca de los servidores/servicios para el anlisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: Servidor EVA Entorno Virtual de Aprendizaje El servidor se encuentra en produccin: Qu servicio(s) ofrece? Servicio Web del EVA, Repositorio de Aprendizaje DSPACE. A que dependencia pertenece: Unidad de Virtualizacin y Video Conferencia. Interacta con otros sistemas? Cules? o Sistema Acadmico SGA. SI( X ) NO( ) SI( X ) NO( )

Nmero de usuarios del servicio: 67000, entre activos y no activos.

Como cataloga el nivel de criticidad del servicio/servidor? Alto ( X ) Medio ( ) Bajo ( )

Por qu? Por las actividades, tareas, evaluaciones, mensajes que se translimiten mediante este medio a los estudiantes de cada una de las materias. Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( )

Qu pasa si el servicio deja de funcionar (indisponibilidad) y cmo cree que afectara a las actividades de la Universidad? Es imprescindible este servicio, puesto que es tambin la puerta de entrada a otros servicios.

Hardware/Equipo:

Procesador Memoria RAM

Software:

Dual Core 1.3 GHz 8 Gb

Sistema Operativo Distribucin Versin Kernel Parches/actualizacin

Servicio:

Linux Centos 5.2 2.6.18

Aplicacin principal Versin Otras aplicaciones instaladas (Versin) Puertos abiertos Parches/actualizacin
Red:

Apache 2.6 Tomcat

80 - http 8080 - tomcat

Nombre del servidor Direccin IP4 externa/pblica Direccin IP6 externa/pblica Ubicacin en la red
Informacin Adicional:

eva.utpl.edu.ec 200.0.X.X Red externa, junto al router de borde

Los tiempos en los que el servicio es an ms crtico es en tiempo de matriculas, subida y consulta de notas, envo de trabajos, llegando en algunas veces a saturarse el servidor. Se tiene 650 conexiones concurrentes al servidor.

Administrador: Ing. Rodrigo Lpez

Tesista: Csar A. Montalvn C. [email protected]

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a Lderes de Grupo.

Luego de realizar un anlisis acerca de los servicios crticos externos de la UTPL, se ha recolectado cierta informacin que se necesita ser corroborada por ud(s), como lder del grupo en el que se encuentra o se administra el servidor en produccin, para verificar si estos servicios externos son realmente crticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera ms objetiva:

SERVIDOR: Entorno Virtual de Aprendizaje - EVA eva.utpl.edu.ec

Cmo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Alto (X ) Medio ( ) Bajo ( )

Por qu? Hay 500 usuarios concurrentes que usan los servicios de la UTPL.

Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( ) Medio (X ) Leve ( )

Cul cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable ( ) Moderada (X ) Espordica ( ) Nunca ( )

Qu pasara si el servicio deja de funcionar (indisponibilidad) y cmo cree que afectara a las actividades de la Universidad? Los estudiantes no tendran acceso a servicios y el call center se congestionara.

Considera Ud. que el servidor Eva (eva.utpl.edu.ec) externo, es un servicio muy crtico e imprescindible para la Universidad? SI (X ) NO ( )

Considera Ud. algn otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI (X ) NO ( ) Cules? Correo electrnico Por qu? Es uno de los medios de comunicacin de la UTPL.

Informacin adicional

Gracias por su colaboracin

Ing. Juan Carlos Torres Lder de la Unidad de Video Conferencia y Virtualizacin

Tesista: Csar A. Montalvn C. [email protected]

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a Administradores.

El objetivo de la presente encuesta es la recoleccin de informacin relevante y actualizada acerca de los servidores/servicios para el anlisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: Servidor WSUTPL El servidor se encuentra en produccin: Qu servicio(s) ofrece? Servicios de notas y consultas de saldos. A que dependencia pertenece: Grupo de Desarrollo de Software Interacta con otros sistemas? Cules? o Sistema Acadmico SGA. SI( X ) NO( ) SI( X ) NO( )

Nmero de usuarios del servicio: Docentes, administrativos y alumnos de la modalidad clsica y abierta de la UTPL.

Como cataloga el nivel de criticidad del servicio/servidor? Alto ( X ) Medio ( ) Bajo ( )

Por qu? Por las actividades, tareas, evaluaciones, notas, saldos, no podran ser vistos ni por alumnos ni docentes, afectando esto principalmente a la Modalidad Abierta de la UTPL. Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( ) Medio ( X ) Leve ( )

Qu pasa si el servicio deja de funcionar (indisponibilidad) y cmo cree que afectara a las actividades de la Universidad? Los servicios como Consulta de Notas, de saldos, no se podran visualizar.

Hardware/Equipo:

Procesador Memoria RAM

Software:

Intel(R) Xeon(R) CPU 5110 3GHZ 3.25 GB

Sistema Operativo Distribucin Versin/Edicin Kernel Parches/actualizacin

Windows Windows 2003 Server Enterprise

Servicio:

Aplicacin principal Versin Otras aplicaciones instaladas (Versin) Puertos abiertos Parches/actualizacin
Red:

IIS 6

80 - http

Nombre del servidor Direccin IP4 externa/pblica Direccin IP6 externa/pblica Ubicacin en la red

wsutpl.utpl.edu.ec 200.0.X.X Red externa

Informacin Adicional:

Administrador: Ing. Viviana Montao

Tesista: Csar A. Montalvn C. [email protected]

PROYECTO DE FIN DE CARRERA Estudio de trfico malicioso en los servicios crticos externos de la UTPL

Entrevista a Lderes de Grupo.

Luego de realizar un anlisis acerca de los servicios crticos externos de la UTPL, se ha recolectado cierta informacin que se necesita ser corroborada por ud(s), como lder del grupo en el que se encuentra o se administra el servidor en produccin, para verificar si estos servicios externos son realmente crticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera ms objetiva:

SERVIDOR:

Servidor Internet. Servicios en lnea: centros, docentes, matrcula en lnea. wsutpl.utpl.edu.ec

Cmo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Alto (X ) Medio ( ) Bajo ( )

Por qu? El servicio de matriculacin de estudiantes de la Modalidad Clsica y Abierta dependen de este servidor.

Nivel de Importancia/Impacto si el servidor/servicio falla: Grave (X ) Medio ( ) Leve ( )

Cul cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable (X ) Moderada ( ) Espordica ( ) Nunca ( )

Qu pasara si el servicio deja de funcionar (indisponibilidad) y cmo cree que afectara a las actividades de la Universidad? No se podran realizar procesos de matriculacin, afectara de manera grave a la operatividad de la UTPL.

Considera Ud. que el servidor wsutpl.utpl.edu.ec externo, es un servicio muy crtico e imprescindible para la Universidad? SI (X ) NO ( ) Considera Ud. algn otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI (X ) NO ( ) Cules? Todos los servidores de acceso al Sistema Acadmico y sus relacionados, ya sea de manera interna o externa. Por qu? La operatividad diaria de procesos acadmicos y financieros relacionados no podrn realizarse.

Informacin adicional

Gracias por su colaboracin

Ing. Diego Plascencia Lder del Grupo de Desarrollo de Software

Tesista: Csar A. Montalvn C. [email protected]

ANEXO 3
A continuacin se muestran capturas del trfico que se registra con las herramientas del Sistema de Monitoreo de la UTPL NOC, Cacti y Netflow, en cuanto se refiere al trfico de entrada y salida que se genera en los servidores de las red UTPL. La siguiente figura muestra una captura con la herramienta de monitoreo Cacti, donde se registra la actividad de red del servidor DNS Externo.

Servidor DNS Externo Direccin IP: 200.X.X.X Trfico de red del servidor DNS.

Como se puede observar, el trfico semanal empieza desde el 18 de Marzo que es donde se ha empezado a monitorear el servidor. El trfico de red promedio registrado desde el 28 de Marzo es de 2,93k de salida y de 1,74k de entrada.

Para poder analizar el comportamiento del trfico de red se ha utilizado el Netflow haciendo uso de la interfaz WAN que es donde se registra la actividad de los servidores externos. Segn las respuestas de las encuestas realizadas a los administradores de los servicios, los tiempos de sobrecargo o de saturacin son generalmente se da en tiempos de matriculas, que es donde los servidores presentan mayor trfico.

Las siguientes capturas son tomadas de una semana, desde el 12 al 18 de Marzo con Netflow de los servidores crticos.

Servidor Web Direccin IP: 200.X.X.X

Como se puede observar en la figura, el trfico que se ha generado en una semana es de 8.8 GB ubicando a este servidor entre los que generan ms trfico de red.

Servidor EVA Direccin IP: 200.X.X.X

Servidor WSUTPL Direccin IP: 200.X.X.X

Actividad diaria de los servidores, registrada por Netflow:

Da: Lunes, 5 de Abril del 2010. Hora: de 15:05 a 16:05

Da: Martes, 6 de Abril del 2010. Hora: de 14:07 a 15:07

ANEXO 4

Instalacin y configuracin de Honeywall roo-1.4.hw-2009 Una vez descargado Honeywall roo-1.4.hw-2009 de la web, procedemos a quemarlo en un CD bootable. Arrancamos la mquina virtual, y el instalador del Honeywall iniciar el proceso de Instalacin: 1. Pantalla de inicio

2. Copia e instalacin de archivos al sistema

3. Proceso de Instalacin de ROO versin 1.4

Luego de esperar algunos minutos al proceso de instalacin, se finaliza procedemos a retirar el CD y presionamos ENTER.

4. Una vez que se han realizado estos primeros pasos, tendremos que logearnos en el sistema. Para ello, se tienen dos cuentas de usuario que son las siguientes: Usuarios: roo y root Password: honey (este password es el que viene por defecto) Luego de esto, una vez logueados, ingresamos al directorio /dlg y ejecutamos la aplicacin dialogmenu.sh, lo cual nos desplegar una ventana para configurar el honeywall.

5. Seleccionar la opcin 4 del men principal, Honeywall Configuration:

6. Seleccionar la opcin 3 en la siguiente ventana:

7. Ingresar la direccin IP de los honeypots.

8. Ingresar la direccin de red que ha de utilizar la Honeynet.

9. Ingresar la direccin Broadcast de la Honeynet

10. Configuracin de la Interfaz remota para administracin.

11. Para la interfaz de Administracin generalmente se hace uso de la interfaz de red eth2:

12. Ingresar la direccin IP del equipo que har las funciones de Administracin:

13. Activacin de la Interfaz de Administracin

14. Configuracin de SSH

15. Permitir el acceso remoto

16. Cambio de password de usuario, de los que viene por defecto en la instalacin. a. Cambio de password para el usuario root

b. Ingreso del nuevo password

c. Confirmacin del password ingresado:

17. Ingrese una lista de puertos TCP permitidos para la interfaz de administracin, por
defecto est incluido SSH

18. Habilitar la interfaz Walleye, Aceptar

19. Confirmar restricciones del firewall

20. Ingresar lista de puertos TCP de salida

21. Ingresar lista de puertos UDP de salida

22. Conexiones permitidas, se especifica por escala de tiempo:

23. Lmite de conexiones TCP:20, UDP: 20, ICMP: 50, OTROS PROTOCOLOS: 10

24. Habilitar la opcin snort_inline

25. Elegir el filtrado de listas negras y blancas

26. Elegir la opcin no para habilitar el filtrado seguro durante la captura de paquetes.

27. Configuracin de Fencelist

28. Habilitar Fencelist

29. ROACH MOTEL: A travs de este modo, un atacante podra detectar fcilmente el
Honeywall y atacarlo posteriormente, es por ello que esta opcin debe ser deshabilitada. Elija la opcin no.

30. Configuracin de DNS, habilitar los accesos ilimitados de los Honeypots al servidor(es) DNS.

31. Habilitar la restriccin de accesos ilimitados de los Honeypots hacia servidores DNS
externos.

32. Ingrese los Honeypots que accedern a servidores DNS externos.

33. Habilitar la restriccin del servidor DNS a ser utilizado para accesos ilimitados

34. Ingrese la direccin IP del servidor DNS

35. Configuracin de alertas por e-mail

36. Ingrese la direccin de correo electrnico donde se deben enviar las alertas

37. Configuracin de las variables Sebek

38. Ingrese la direccin IP de destino de los paquetes Sebek, por defecto 0.0.0.0

39. Ingrese el puerto UDP de destino de los paquetes Sebek, por defecto 1101

40. Del men de opciones de registro, elegir el literal 4

ANEXO 5
Instalacin y configuracin de Sebek Instalacin de Sebek en Sistemas Windows Una vez descargado para Windows, Sebek-Win32-3.0.5, de la web, procedemos a su instalacin y configuracin en el respectivo honeypot. Procedemos con los siguientes pasos: 1. Ejecucin de archivo setup.exe, dar click en Next.

2. Ubicacin de la carpeta en la que se instalar Sebek, dar click en Install.

3. Instalacin de los archivos. Dar click en Aceptar

4. Finalizacin de la Instalacin. Dar click en Finish.

5. Configuracin de Sebek, esto lo hacemos mediante el asistente de configuracin Sebek. Ejecutamos el archivo Configuration Wizard.exe:

6. Ubicacin del driver Sebek, la ubicacin por defecto es la siguiente ruta:

c:\WINDOWS\system32\drivers\SEBEK.SY. Dar click en Siguiente:

7. Configuracin de la Direccin IP, Direccion MAC y puerto destino. Luego dar click en siguiente

8. Valor mgico, elegir el valor randomico. Dar click en Siguiente.

9. Escoger la interface de red con la que se ha de comunicar con el Servidor Sebek. Escoger y dar click en Siguiente

10. Escoger el nombre del programa de configuracin, el nombre por defecto es Configuratio. Dar click en Siguiente.

11. Verificacin de la configuracin de Sebek. Dar click en Finalizar.

DESINSTALACIN DE SEBEK.
Debido a que el instalador no se registra en el sistema se deber desinstalar manualmente. Los siguientes pasos son necesarios para eliminar Sebek de un PC: 1. 2. 3. Inicie el equipo con el CD de instalacin del sistema operativo. Seleccione la consola de recuperacin pulsando "R". Si est ejecutando XP puede ignorar este paso. Si est ejecutando en Windows 2000, despus presione C para abrir la consola de recuperacin. Seleccione la instalacin de Windows que desea modificar. Proporcionar la contrasea de administrador. Una vez ya en el smbolo del sistema, ir a C:\WINDOWS\System32\drivers y escriba 'delete Sebek" sin las comillas. Una vez que el comando se completa reiniciar la mquina escribiendo Exit. Elimine Sebek situado en la clave del Registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sebek 9. Y finalmente quite el programa de configuracin si est en la mquina.

4. 5. 6.

7. 8.

ANEXO 6
Instalacin Sebek-Cliente en Linux

Distribucin:

Ubuntu 7.10 Server

Para la instalacin de Sebek-Cliente en los Honeypots, se procede de la siguiente manera: Instalacin de paquetes requeridos: Nota: Es necesario tener a mano el disco de Instalacin de Ubuntu 7.10 Server, por lo que para poder realizar las instalaciones, el sistema requerir de este disco. #sudo apt-get install subversin # sudo apt-get install make linux-headers-server # sudo apt-get install gcc linux-headers-server # sudo apt-get install autoconf linux-headers-server # sudo apt-get install libc6-dev linux-headers-server # sudo apt-get install patch linux-headers-server

Tambin instalar el paquete automake EN SU VERSIN 1.4 # sudo apt-get install automake1.4 Una vez instalados todos los paquetes requeridos, procedemos a descargarnos el clientesebek, de la pgina oficial del proyecto Sebek: https://projects.honeynet.org/sebek/ Descargamos el: sebek_disable_raw_socket_replacement-lin26-3.2.0b-bin.tar.gz Luego, descomprimirlo en el sistema en cualquier directorio, con el comando: # tar zxvf sebek_disable_raw_socket_replacement-lin26-3.2.0b-bin.tar.gz Ingresamos en el Nuevo directorio que se cre: # cd sebek-lin26-3.2.0b-bin Editar el archivo de configuracin sbk_install.sh, con los parmetros necesarios: # sudo nano sbk_install.sh Principalmente, dentro de este archivo, modificamos la directiva DESTINATION_PORT, que por defecto viene en blanco y le ponemos el puerto de escucha de Sebek: 1101

Finalmente ejecutamos el instalador con el comando sh: # sudo sh sbk_install.sh

Y si todo est bien, la instalacin deber mostrar un mensaje de exitosa (successfully). Con este procedimiento se concluye la instalacin del cliente sebek en los equipos honeypots.

ANEXO 7 Instalacin y configuracin de servicios/aplicaciones en los servidores virtuales de la Honeynet.

No. 1

Tipo Honeypot

Servidor gdr1.utpl.edu.ec

Software Centos Apache MySQL cliente Oracle PHP Wordpress Joomla Webmin Sendmail Squirrelmail Drupal

Vers soft. 4.4 2.6 5 11.1.0 5.2.9

Puerto

Funcin Web

Trfico Externo

80 3306 1521

10000

Honeypot

gdr2.utpl.edu.ec

Centos Bind Ssh

5 9,3 5 5.2 2.6 80 8080 53 22

DNS

Externo

Honeypot

eva.utpl.edu.ec

Centos Apache Tomcat

Servidor Web de Eva

Externo

Honeypot wsutpl.edu.ec Windows 2003 Server IIS Con. remotas Act. directory 6 80 3389 389

Servicios en Lnea Estudiantes docentes

Externo

No. 1

Servidor gdr1.utpl.edu.ec

Procesador IBM 1.6 GHz

Disco Duro 2 Discos 70 GB

Memoria Ram 10 GB

Software Centos Apache MySQL cliente Oracle PHP Wordpress Joomla Webmin Sendmail Squirrelmail Drupal

Vers soft. 4.4 2.6 5 11.1.0 5.2.9

Funcin Web

gdr2.utpl.edu.ec

Pentium IV 3GHz

36 GB

1 GB

Centos Bind Ssh

5 9,3 5 5.2 2.6

DNS

eva.utpl.edu.ec

Dual Core 1.3 GHz

75 GB

8 GB

Centos Apache Tomcat

Servidor Web de Eva

4 wsutpl.edu.ec

Intel(R) Xeon(R) CPU 5110 3GHZ

70 GB

3.25 GB Windows 2003 Server IIS Enterprise Edition 6

Servicios en Lnea Estudiantes docentes

ANEXO 7
Instalacin de aplicaciones en los Honeypots

Servidor DNS
BIND es el servidor de nombres de dominio ms popular en Internet, que trabaja en todas las plataformas informticas principales y se caracteriza por su flexibilidad y seguridad. Domain Name Service (DNS) es el servicio que resuelve los nombres de dominio asociados a una direccin IP para direccionar las peticiones a un servidor en especfico. Se utiliza cuando un nodo (o host) en Internet contacta a otro mediante el nombre de domino de la mquina y no por su direccin IP. Instalacin de bind Para la instalacin utilizamos el siguiente comando:
# sudo apt-get install bind9

Luego de la instalacin los archivos de configuracin se ubican en el directorio: /etc/bind Configuracin de bind Para poder configurar bind editamos named.conf.local y aadimos la zona utpl.org.ec, haciendo referencia a su fichero de configuracin:
zone "utpl.org.ec" { type master; file "/etc/bind/db.utpl"; };

Cada vez que se cambia la configuracin de BIND9, debemos reiniciar el demonio:

# sudo /etc/init.d/bind9 restart

Creamos el fichero de configuracin db.utpl a partir de db.local:

# cp db.local db.utpl

Editamos db.utpl, reemplazamos la palabra localhost por utpl.org.ec, cambiamos la IP 127.0.0.1 por la que queramos asignar al dominio y aadimos al final del fichero todos los A, MX y CNAME que queramos, quedando:
;

; BIND data file for local loopback interface ; $TTL 604800 Utpl.org.ec IN SOA utpl.org.ec. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; IN NS gdr2.utpl.org.ec. IN A 200.0.28.251 gdr2 IN A 200.0.28.251 gdr1 IN A 200.0.28.252 www IN CNAME gdr1 eva IN A 200.0.28.253 wsutpl IN A 200.0.28.254

En el caso de que nuestra mquina utilice el servidor de DNS que hemos configurado, debemos editar /etc/resolv.conf y dejamos nicamente la lnea:
nameserver 127.0.0.1

Si se va a configurar en otros servidores, hay que poner la direccin IP del DNS que se ha configurado en lugar del 127.0.0.1 que es el localhost.

Resolucin Inversa Si se desea realizar la traduccin inversa, es decir, que se quiera traducir de nombre de dominio a direccin IP, se realiza la siguiente configuracin: Editamos el archivo /etc/bind/named.conf.local, y le aadimos las siguientes lneas:
zone "192.in-addr.arpa" { type master; file "/etc/bind/db.172"; };

Creamos el archivo de configuracin /etc/bind/db.200 a partir del /etc/bind/db.127:

# cd /etc/bind/ # cp db.127 db.200

Editamos /etc/bind/db.192, substituimos localhost por utpl.org.ec y cambiamos la ltima lnea:

; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA utpl.org.ec. root.utpl.org.ec. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry

2419200 604800 ) ; @ IN NS 251.28.0 252.28.0 253.28.0 254.28.0 utpl.org.ec. IN IN IN IN

; Expire ; Negative Cache TTL

PTR PTR PTR PTR

gdr2.utplinux.org. gdr1.utplinux.org. eva.utpl.org. wsutpl.utplinux.org.

A continuacin modificamos el fichero /etc/bind/named.conf.options. En este fichero especificaremos aquellos servidores DNS de Internet que resolvern los nombres de dominio que nuestro servidor DNS local no pueda resolver. Ser necesario especificarlos para que los ordenadores de nuestra red salgan a Internet.
options { directory /var/cache/bind; forwarders { 200.0.31.155; }; };

Enrutamiento en host anfitrin La red interna o intranet donde se encuentran los servidores utiliza un direccionamiento NAT, por lo que para salir hacia otras redes externas se deber usar como gateway o pasarela el host anfitrin, es decir que todos los paquetes que le lleguen al anfitrin pero que este no sea el objetivo sern redireccionados por la interfaz que se conecta a la red que se necesita acceder, por lo que se habilita el IP Forward, de la siguiente manera:
# echo "1" > /proc/sys/net/ipv4/ip_forward # iptables -A FORWARD -j ACCEPT

En cada servidor interno se agrega la ruta de salida:

# route add -net 0.0.0.0 netmask 0.0.0.0 gateway IP_gtw

Pruebas Ahora, para poder comprobar el funcionamiento del bind, se puede hacer uso del comando host, de la siguiente manera:

Otra forma con las que se dispone para hacer consultas sobre un servidor DNS es dig (domain information groper). Se utiliza para detectar problemas de configuracin en el servidor DNS. Su sintaxis es la siguiente:
# dig <@servidor> [opciones] [nombre] [tipo]

donde:

@servidor es el nombre o la direccin IP del servidor a consultar. nombre es el nombre de dominio donde se hace la consulta tipo es el tipo de registro por el que se consulta (ANY, NS, SOA). Si no se indica, se asume A

Con esto se verifica que la traduccin de direcciones y nombres de dominio se est realizando correctamente.

SERVIDOR WEB
Instalacin Servidor Web Apache El servidor HTTP Apache es un servidor web HTTP de cdigo abierto para plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo Windows HTTP/1.1 Para poder instalar hacer funcionar el servidor, es necesario instalar el apache2, para ello, mediante una consola, procedemos:
#sudo apt-get install apache2 get

Luego de haber realizado este paso, comprobamos que efectivamente se ha instalado apache en nuestro sistema; desde otro equipo abrimos un navegador y en la url ubicamos la direccin de nuestro servidor local. Es decir, poner la direccin IP de la mquina en la que se instal apache:

, Si se da click en el enlace que se muestra apache2-default, y si todo est normal, nos aparecer una pantalla como la que se muestra a continuacin:

El directorio hacia donde apunta el servidor Web Apache por defecto es a /var/www/apache2-default. Esto se puede cambiar y se puede configurar editando el archivo se de configuracin default que se encuentra en la siguiente ruta: /etc/apache2/sites-available Cada vez que se realice alguna modificacin o cambio es necesario reiniciar apache con cualquiera de las siguientes maneras:
sudo /etc/init.d/apache2 restart

con el comando:
sudo apache2ctl restart

Motor de Base de Datos Mysql y PHP

Para dotar a Apache de la funcionalidad de manejar pginas php se debe instalar el paquete php5.
# sudo aptitude install php5

Para verificar la correcta instalacin y funcionamiento de php, creamos un fichero y lo editamos:

sudo gedit /var/www/test.php

en el fichero le colocas lo siguiente

<?php phpinfo(); ?>

Guardamos los cambio y reseteamos el apache server:

sudo /etc/init.d/apache2 restart

y abres tu navegador y escribimos: http://[DireccinIP]/test.php Se nos tendr que presentar una pantalla as:

Instalacin de algunos paquetes necesarios:

# sudo apt-get install mysql5-server # sudo apt-get install libapache2-mod-auth-mysql

# sudo apt-get install mysql5-mysql

Instalacin de phpMyadmin phpMyAdmin es una herramienta libre escrita en PHP con la intencin de manejar la administracin de MySQL a travs de pginas web, utilizando Internet con interfaz grfica muy til para gestionar las bases de datos.
# sudo apt-get install phpmyadmin

Para poder ser uso de esta herramienta, vamos en otra mquina y en la url ponemos: http://DirIP/phpmyadmin, damos Enter y nos saldr la ventana para el respectivo logueo:

- En caso de que no funcione de esta manera, lo que se puede hacer es, descargarse el phpMyAdmin y descomprimirlo en la carpeta de pginas web y asi mismo, ingresar a travez del navegador.

Instalacin de Webmin WebMin es una aplicacin web que nos ayuda a poder configurar graficamente los servicios de nuestro servidor. Para su instalacin se requieren seguir el siguiente procedimiento: - Instalamos los siguientes paquetes:

# sudo apt-get install build-essential # sudo apt-get install perl libnet-ssleay-perl openssl libauthenpam-perl libpam-runtime libio-pty-perl libmd5-perl
- Luego instalamos el paquete webmin
# sudo dpkg -i webmin_1.370_all.deb

- Luego de esto termina el proceso de instalacin. Para acceder a nuestra aplicacion usamos
un navegador e ingresamos a la direccin:
https://your-server-ip:10000/

esto nos muestra una pantalla de login, y podemos ingresar a administrar nuestro servidor.

Instalacin de Joomla En primer lugar, para poder realizar la instalacin de Joomla en nuestro servidor Web, debemos crear una base de datos para Joomla. Esto se puede realizar mediante la utilidad phpMyAdmin:

Luego de haber creado nuestra base de datos, descargamos el instalador de Joomla y lo desempaquetamos en nuestra carpeta de pagina web de apache. Una vez desempaquetado el instalador, nos ubicamos en el navegador, y colocamos la direccin IP, para proceder con la instalacin:

- Seleccionamos el idioma a utilizar y ahora, se realiza una comprobacin previa, antes de la instalacin:

- Aceptamos la licencia GNU/GPL:

- Ingresamos los datos de configuracin de la base de datos:

- Ahora, se procede con la instalacin:

- En el caso de haber existido alguno error en la configuracin, se puede arreglar esto, copiando el texto que se muestra en la siguiente pantalla, copiarlo en un archivo de nombre configuration.php y pegarlo en la carpeta raiz de joomla:

- Una vez realizado esto, ya podemos ingresar a la administracin del nuevo sitio web en joomla:

SERVIDOR EVA
Instalacin y configuracin del servidor Web Apache El servidor HTTP Apache es un servidor web HTTP de cdigo abierto para plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows Macintosh y otras, que implementa el protocolo Windows, HTTP/1.1 Para poder instalar hacer funcionar el servidor, es necesario instalar el apache2, para ello, funcionar mediante una consola, procedemos:
#sudo apt-get install apache2 get

Luego de haber realizado este paso, comprobamos que efectivamente se ha instalado apache en nuestro sistema; desde otro equipo abrimos un navegador y en la url ubicamos la direccin abrimos de nuestro servidor local. Es decir, poner la direccin IP de la mquina en la que se instal apache:

Si se da click en el enlace que se muestra apache2-default, y si todo est normal, nos , aparecer una pantalla como la que se muestra a continuacin:

El directorio hacia donde apunta el servidor Web Apache por defecto es a /var/www/apache2-default. Esto se puede cambiar y se puede configurar editando el archivo de configuracin default que se encuentra en la siguiente ruta: /etc/apache2/sitesencuent -available Cada vez que se realice alguna modificacin o cambio es necesario reiniciar apache con cualquiera de las siguientes maneras:
# sudo /etc/init.d/apache2 restart

con el comando:
# sudo apache2ctl restart

Instalacin de Moodle 1.9.9 Requerimientos: Servidor Web: Apache Base de datos: Mysql Lenguaje: PHP

En primer lugar vamos a la pgina principal del moodle: http://moodle.org , una vez que se ha escogido la versin adecuado, respecto al S.O. que se tiene, en este caso Linux, descargamos el instalador:

Luego de esto, desempaquetamos el archivo descargado en el directorio adecuado, donde se alojan las pginas web.
# tar zxvf modle-1.9.9.tgz 1.9.9.tgz

Luego de desempaquetar, se nos crea un directorio con el nombre moodle, en este caso renombramos este directorio y le ponemos por nombre eva eva.
# mv moodle/ eva

Luego nos ubicamos en el navegador, y ponemos en la url: http://[ipserver]/eva Damos Enter y con esto empieza la instalacin:

En la siguiente pantalla se muestra la Direccin Web, el Directorio Moodle y el Directorio de Datos, en caso de no existir dicho directorio, hay que crear tal directorio en el Servidor. crear

Ahora, se configura los datos de la conexin con la base de datos Mysql:

Ahora, se comprueban los componentes del servidor:

Configuracin del Idioma, damos click en Descargar el paquete de idioma Espaol Internacional (es):

En el caso que no se pueda descargar tal paquete de idioma, hay que descargarlo de http://download.moodle.org/lang16/es_utf8.zip, descomprimirlo y copiarlo en el directorio /home/moodledata/lang:

El siguiente paso es la configuracin del archivo principal: config.php:

Configuraciones de la cuenta del Administrador. Es necesario crear la contrasea:

Con esto se ha finalizado la instalacin y configuracin de Moodle: Aqu una captura de la pantalla principal:

Servidor WSUTPL

Instalacin y configuracin de IIS 5.1 Primero, nos dirigimos al Panel de Control y Seleccionamos la pestaa Agregar o quitar programas. En la siguiente ventana damos click en la opcin Agregar o quitar componentes de Windows:

De la lista que se nos presenta seleccionamos Servicios de Internet Information Service (IIS), y damos click en siguiente, es necesario tener el CD de Instalacin de Windows para poder realizar la instalacin:

Con esto finaliza la instalacin de Internet Information Service (IIS), damos click en Finalizar

Configuracin de Internet Information Service (IIS) Para poder configurar y administrar IIS, ingresamos a Administracin de Equipos, esto es, haciendo click derecho sobre Mi Pc y click izquierdo en la pestaa Administrar:

Ahora se nos presentar la siguiente pantalla, desde donde podremos configurar y administrar nuestro servidor Web y sus respectivas pginas que se alojaran:

Una vez ubicados en esta ventana, nos ubicamos en Servicios y Aplicaciones, damos click en el desplegable, luego click en Servicios de Internet Information Service y se nos mostrarn los servicios que se pueden configurar, en este caso Servicios Web, FTP y SMTP:

Lo que por ahora nos interesa son los sitios Web del Servidor Web, por tal motivo, damos click en Sitios Web y luego click derecho en Sitio Web predeterminado y

seleccionamos Propiedades. Se nos presentar la siguiente pantalla, donde estn todas las opciones para la configuracin de los sitios Web que ha de utilizarse:

Para poder verificar si el servidor Web se instal y se est ejecutando correctamente, nos ubicamos en el navegador y en la URL ponemos localhost, con ello se debe presentar la siguiente pantalla:

Lo cual significa que el Servidor Web est activo, pero que an no se encuentra alojando ninguna pgina Web predeterminada. Cabe mencionar, que para agregar documentos al sitio Web, hay que guardarlos en el directorio: C:\Inetpub\wwwroot\

ANEXOS 8
Alertas generadas por Snort
ICMP PING CyberKit 2.2 Windows, Snort ID:483

ICMP PING NMAP, Snort ID:384

NETBIOS SMB-DS IPC$ unicode share access, Snort ID:2465

WEB-CGI awstats access, Snort ID:3463

ICMP PING, Snort ID:384

ICMP Echo Reply, Snort ID:408

ICMP Destination Unreachable Port Unreachable, Snort ID:402

(portscan) TCP Portsweep, Snort ID:122-3

SQL Worm propagation attempt OUTBOUND, Snort ID:2003

(portscan) TCP Portscan, Snort ID:122-1

WEB-CGI calendar access, Snort ID:882

BAD-TRAFFIC tcp port 0 traffic, Snort ID:524

ICMP Destination Unreachable Communication with Destination Host is Administratively Prohibited, Snort ID:486

SNMP AgentX/tcp request, Snort ID:1421

SNMP trap tcp, Snort ID:1420

SNMP request tcp, Snort ID:1418

WEB-PHP Setup.php access, Snort ID:2281

SQL version overflow attempt, Snort ID:2050

WEB-IIS view source via translate header, Snort ID:1042

WEB-MISC backup access, Snort ID:1213

(http inspect) IIS UNICODE CODEPOINT ENCODING WriteAndX little endian overflow attempt, Snort ID:119-7

(http inspect) OVERSIZE CHUNK ENCODING, Snort ID:119-16

DELETED NETBIOS SMB-DS srvsvc NetrPethCanonizalize WriteAndX little endian overflow attempt, Snort ID:7298

BAD TRAFFIC IP Proto 53 55 77 103, Snort ID:2186 2187 2188 2189

NETBIOS SMB-DS repeated logon failure, Snort ID:2924