UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA MODALIDAD CLASICA ESCUELA DE CIENCIAS DE LA COMPUTACIÓN

Transcripción

1 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La universidad católica de Loja MODALIDAD CLASICA ESCUELA DE CIENCIAS DE LA COMPUTACIÓN Tema: Estudio de tráfico malicioso en los servicios críticos internos de la UTPL Memoria de tesis previa a la obtención del título de Ingeniero en Sistemas Informáticos y Computación. Autor: Santiago Fernando Ludeña Ramírez Director: Msc. María Paula Espinoza Vélez LOJA ECUADOR 2012

2 CERTIFICACIÓN Ingeniera María Paula Espinoza Vélez. DIRECTOR DE TESIS CERTIFICA: Que el presente trabajo de investigación, previo a la obtención del titulo de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, ha sido dirigido, supervisado y revisado en todas sus partes, por lo mismo, cumple con los requisitos legales exigidos por la Universidad Técnica Particular de Loja, quedando autorizada su presentación. Loja, Octubre de 2010 Ing. María Paula Espinoza Vélez DIRECTOR DE TESIS ii

3 AUTORÍA El presente proyecto de tesis previo a la obtención del Título de Ingeniero en Sistemas Informáticos y Computación; sus conceptos, análisis, conclusiones y recomendaciones emitidas, es de absoluta responsabilidad del autor. Se debe indicar además que la información de otros autores empleada en este trabajo está debidamente especificada en fuentes de referencia y apartados bibliográficos. Santiago Fernando Ludeña Ramírez. iii

4 CESIÓN DE DERECHOS Yo, Ludeña Ramírez Santiago Fernando, declaro ser autor del presente trabajo y eximo a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales. Adicionalmente declaro conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja que su parte pertinente textualmente dice. Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través o con el apoyo financiero académico o institucional (operativo) de la Universidad. Santiago Fernando Ludeña Ramírez iv

5 AGRADECIMIENTO Mis sinceros agradecimientos para aquellas personas que me brindaron la ayuda necesaria para llevar a cabo el presente proyecto. Agradecimientos especiales a la Ing. María Paula Espinoza por su gran aporte directriz y a mi familia, pilar fundamental. v

6 DEDICATORIA Ofrezco la siguiente investigación al ser supremo que me acompañó en todo momento y a mi familia. vi

7 vii

8 ÍNDICEGENERAL ÍNDICE GENERAL... 1 Índice de Figuras... 3 Índice de Tablas... 7 OBJETIVOS... 9 RESUMEN... Error! Marcador no definido. Fase 1.1 Estudio del Esquema actual de la Honeynet Honeynet: Definiciones Revisión del estado del arte de la honeynet UTPL Revisión de la plataforma Revisión del software Honeynet virtuales Resultados obtenidos Fase 1.2 Identificación de servicios internos de la UTPL Problemática Inventario de servicios y evaluación de la criticidad Definición de servicios críticos de acuerdo al tráfico Consideraciones finales entre los servicios escogidos Revisión de problemas de seguridad relacionados Resultados obtenidos: Servidores escogidos Fase 2.1 Preparacion de equipos Elección de herramienta virtualizadora Análisis de Herramientas existentes Honeynet virtual a utilizar Pruebas de implementación Conclusiones extraídas a partir de las pruebas Riesgos encontrados Fase 2.2 Implementación de servicios Instalación de ROO Honeywall CDROM Implementación del servidor web Reglas de firewall [Ver anexo I] Implementación del servidor dns Configuraciones generales Reglas de firewall [Ver Anexo I]... 41

9 2.2.3 Implementación del servidor eva Configuraciones generales Instalación de Moodle [Ver Anexo H] Reglas de firewall [Ver anexo I] Implementación del servidor baan Implementación Reglas de firewall Ver Anexo I Fase 3.1 Control de datos en la honeynet Medidas de contención y control de conexiones Prueba de control de conexiones Fase 3.2 Captura de datos Fase 4.1 Análisis de tráfico Introducción Herramientas de análisis Análisis de datos obtenidos desde la honeynet Direcciones IP origen Alertas Conclusiones Conclusiones a partir del análisis de tráfico Recomendaciones Proyectos futuros ANEXOS BIBLIOGRAFÍA

10 Índice de Figuras Fig Sebek esquema de captura Fig Esquema de la red de la UTPL Fig Esquema de red de la honeynet UTPL Fig Honeynet auto-contenida Fig Honeynet Virtual Híbrida Fig Esquema de honeynet a implementar Fig Ubicación de la honeynet virtual en la red de la UTPL Fig Riesgos del host anfitrión Figura Petición http (wget) a honeypots Eva y Web desde la vlan Figura Intentos de conexión de acceso remoto usando el protocolo ssh a todos los honeypots Figura Peticiones ping realizadas desde la vlan 82 a todos los honeypots. 48 Figura Archivo.pcap con tráfico capturado desde los honeypots Fig Alerta de conexión usando protocolo SMB Fig Alerta de conexiones http con el servidor WEB Fig Alertas conocidas Fig D1. Se muestra el tráfico normal cuando subitamente pasa de 1.89KB/s hasta alcanzar los 7.86MB/s Fig D2. El ancho de banda se mantiene en un promedio de 4.8 MB/s Fig D3. La cantidad de tráfico de salida aumentó a un promedio de 3.39 MB/s Fig D4. Muestra la cantidad de tráfico de salida y el protocolo q más cantidad de peticiones respuestas registra Fig D5. Esta es una captura del analizador de tráfico con interfáz gráfica Etherape, la cual muestra que en la red existen solo dos direcciones en funcionamiento y la línea da un indicio del tráfico que están transfiriendo Fig D6. Traza de tráfico desde el origen hacia el destino Fig D7. Traza de tráfico desde el origen hacia el destino, causado por configuración errónea Fig F1 Instalación de openssl Fig F2. Instalación de librería libauthen-pam-perl Fig F3. Instalación con comando dpkg de librería libpan-runtime Fig F4. Instalación con comando dpkg de librería libio-pty-perl Fig F5. Instalación con comando dpkg de librería libmd5-perl Fig F6. Instalación con comando dpkg de webmin

11 Fig F7. Instalación con comando dpkg de webmin Fig F8. Pantalla de autenticación de webmin Fig F9. Características generales del equipo mostradas por webmin Fig F10. Servidores que pueden ser administrados por medio de webmin Fig H1. Versión de descarga desde el sitio oficial de moodle Fig H2. Inicio de instalación de moodle Fig H3. El instalador de moodle comprueba la compatibilidad con php Fig H4. Confirmar las direcciones de instalación Fig H5. Ingresar los parámetros de instalación de MySQL Fig H6. Parametros de configuración ingresados Fig H7. Comprobaciones del servidor Fig H8. Nos pedirá descargar el paquete de idioma que nos convenga Fig H9. Este error se produce al intentar descargar el paquete de idioma, al no haber conexión Fig H10. Se muestra el fichero de configuración php Fig H11. Se escoge el idioma que se utilizará Fig H12. Comprobación de ajustes Fig H13. Moodle instalado y listo para configurarlo Fig H14. Configuraciones de administración Fig H15. Se configura el nombre del sitio y descripciones del mismo Fig H15. Características generales del equipo mostradas por webmin Fig H16. Confirmación de configuraciones Fig H17. Sitio donde se ha instalado apache Fig H18. Prueba de que el servidor trabaja Fig H19. Comprobación de funcionamiento de php Fig H20. Pantalla de autenticación de phpmyadmin Fig H21. Pantalla desde donde se pueden gestionar bases de datos MySQL Fig I1. Firewall iptables en funcionamiento Fig I2. Peticiones de resolución de nombres al servidor DNS de la honeynet con el firewall en funcionamiento Fig I3. Peticion de ping a dirección externa, aunque luego se deshabilita la salida a internet en todos los honeypots Fig I4. Resolución de nombre del servidor DNS FIG K1. Reiniciar bind Fig K2. Consulta del dominio de la honeynet

12 Fig L1. Pantalla de inicio de instalación de honeywall Fig L2. Progreso de instalación - Formateo Fig L3. Progreso de instalación Transferencia de archivos Fig L4. Inicio de instalación Fig L5. Accediendo al sistema Fig L6. Menu principal: Configuración Honeywall Fig L7. Configuración inicial Fig L8. Método de configuración inicial Fig L9. Mensaje de inicio de configuración inicial Fig L10. Ingreso de direcciones IP Fig L11. Ingreso de la red Fig L12. Ingreso de la dirección de broadcast Fig L13. Configuración de interfaz de administración Fig L14. Ingreso del nombre de la interfaz Fig 15. Confirmación de interfaz Fig L16. Ingreso de dirección IP, interfaz de administración Fig L17. Ingreso de mascara de red, interfaz de administración Fig L18. Ingreso de Gateway, interfaz de administración Fig L19. Ingreso del hostname, interfaz de administración Fig L20. Ingreso de IP(s) del servidor DNS, interfaz de administración Fig L21. Confirmación de interface, interfaz de administración Fig L22. Confirmación para la configuración de SSH Fig L23. Confirmación para permiso remoto Fig L24. Confirmación de cambio de password Fig L25. Ingreso de nuevo password Fig L26. Confirme el password ingresado Fig L27. Confirmación de password cambiado Fig L28. Ingreso de puertos TCP Fig L29. Ingreso de rango de direcciones IP Fig L30. Confirmación para habilitar interfaz web Fig L31. Confirmación para restricciones de firewall Fig L32. Ingreso de puertos permitidos TCP para salida Fig L33. Ingreso de puertos permitidos UDP para salida Fig L34. Confirmación de finalizar la 2da sección

13 Fig L35. Especificación del límite de conexiones Fig L36. Especificación del límite de conexiones: TCP Fig L37. Especificación del límite de conexiones: UDP Fig L38. Especificación del límite de conexiones: ICMP Fig L39. Especificación del límite de conexiones para otros protocolos Fig L40. Confirmación para habilitar snort_inline Fig L41. Archivo Blacklist Fig L42. Archivo Whitelist Fig L43. Filtrado listas (Black- White) Fig L44. Filtrado seguro Fig L45. Fencelist Fig L46. Filtrado Fencelist Fig L47. Modo Roach Motel Fig L48. Finalización de la 3ra sección de configuraciones Fig L49. Acceso a DNS ilimitados de los Honeypots Fig L50. Acceso DNS ilimitados. Honeypot Servidores Fig L51. Honeypots que pueden acceder a servidores DNS Fig L52. Restringir servidor DNS Fig L53. Ingreso de dirección del servidor DNS Fig L54. Configuración de alertas por Fig L55. Ingreso de dirección de correo Fig L56. Inicio de configuración de Sebek Fig L57. Dirección IP destino Fig L58. Puerto UDP de Sebek, Fig L59. Opciones de registro del paquete Sebek Fig L60. Pantalla de finalización del proceso

14 Índice de Tablas Tabla Extractos de tráfico promedio de los servidores Tabla Consideraciones de importancia y criticidad de los servidores Tabla Características generales del equipo real Tabla Características de administración e importancia Tabla Servicios utilizados por el servidor real Tabla Características generales del equipo real Tabla Características de hardware Tabla Servicios utilizados por el servidor real Tabla Características generales del equipo real Tabla Características de administración e importancia Tabla Servicios utilizados por el servidor real Tabla Características generales del equipo real Tabla Características de administración e importancia Tabla Servicios utilizados por el servidor real Tabla Equipo utilizado para las pruebas previas de la honeynet Tabla Equipo que se utiliza para la implementación de la honeynet Tabla Características implementadas a cada máquina virtual Tabla Riesgos sobre el host anfitrión Tabla Vlans utilizadas para capturar tráfico Tabla Pruebas a honeypot DNS desde vlans habilitadas y no habilitadas.. 46 Tabla Pruebas a honeypot WEB desde vlans habilitadas y no habilitadas. 46 Tabla Pruebas a honeypot EVA desde vlans habilitadas y no habilitadas.. 47 Tabla Pruebas a honeypot BAAN desde vlans habilitadas y no habilitadas.47 Tabla Descripción de herramientas de recolección y análisis de tráfico Tabla Direcciones desde donde se detectaron alertas Tabla A1. Servidores de la UTPL

15 RESUMEN Las honeynets se han convertido en nuevo paradigma en el estudio de los ciberataques, estos se presentan con alta frecuencia siendo cada vez más nocivos y complejos. Su accionar normalmente está motivado por la parte económica. En el presente proyecto se implementó una Honeynet auto-contenida, para lograr esto fue necesario hacer estudio previo de los servicios implementados con los que cuenta la universidad, luego correlacionar datos, obtener los servicios que mayor criticidad en el ambiente interno. Posterior a esto fue necesario realizar una evaluación en cuanto al hardware que soporta los servicios de la universidad que posibilite implementar los sistemas virtualizados además de soportar la carga de trabajo que se planificó. La recolección de datos es la parte fundamental de la honeynet, pues sobre estos datos se hace el análisis para que a partir de estos se pueden encontrar patrones de ataques, conexiones normales entre equipos pero no lógicas, falsos ataques o simples conexiones. La honeynet implementada propone un nuevo método para detectar intrusos y sus acciones, permite observar la conducta normal en la red. 8

16 OBJETIVOS GENERAL Implementar un mecanismo donde se simulen parte de los servicios internos críticos de la UTPL en un solo equipo, para que sean vulnerados evitando que los ataques se propaguen por el resto de la red interna, con el fin de obtener la metodología usada y aprender de los atacantes. ESPECIFICOS Administrar Honeynet virtual auto-contenida. Recolectar y analizar información colectada por los señuelos. Extraer metodologías de ataques Implementar y administrar métodos de contención como Reglas de firewall. Dosificar y optimizar recursos en un solo equipo para implementar la honeynet. Extraer y analizar imágenes de configuración de cada sistema señuelo. 9

17 PRIMER COMPONENTE ANÁLISIS DE LA SITUACIÓN INICIAL 10

18 PRIMER COMPONENTE: Análisis de la situación actual Fase 1.1 Estudio del Esquema actual de la Honeynet Honeynet: Definiciones Inmiscuidos en la inmensa masa de usuarios de internet existen usuarios con intenciones arteras contra la privacidad y respeto por la propiedad física e intelectual ajena, para ser más exactos, hago referencia a los hackers destructivos, conocidos técnicamente como crackers, sujetos difíciles de identificar que intentan y mayoritariamente consiguen romper las seguridades de empresas privadas, instituciones comerciales, financieras, académicas, etc. Con el ánimo de hacer daño aunque la razón principal de su existencia es actualmente la lucrativa. Ingentes métodos, técnicas, procedimientos se han incorporado hacia el sector productivo con el objetivo primordial de proteger los datos de las empresas, sean estas de cualquier índole. A estas estrategias de protección se suma un nuevo método, que inicialmente tiene un objetivo meramente académico, no siendo una estrategia necesariamente para las organizaciones preocupadas en proteger su seguridad, las honeynets. Una honeynet es una red ideada para aprender del atacante, conocida informalmente como una red trampa, que bien puede ser una réplica de la red de una organización emulando sus servicios o también una red que implemente otros servicios dentro de la empresa. El objetivo primordial de los administradores de una honeynet es capturar tráfico, para por medio de éste aprender las técnicas de ataque utilizadas. El administrador de una honeynet debe poseer la habilidad necesaria para esconder y proteger la red, el atacante no debe caer en cuenta que sus acciones están siendo monitoreadas, teniendo en cuenta que estos tienen técnicas para reconocer si están en una red en producción o una honeynet. Aún menos el administrador no puede permitir que la red sirva de relay, es decir que desde la red se ataque a otra en producción dentro o fuera de la organización Revisión del estado del arte de la honeynet UTPL La honeynet UTPL nació como un proyecto de tesis, se implementó y actualmente está siendo administrada por el grupo de seguridad en el Departamento de 11

19 Telecomunicaciones de la universidad. Desde su implementación extrae reportes periódicos del tráfico capturado por los sensores ubicados en los honeypots. La honeynet se encuentra ubicada fuera del espacio de direcciones de producción de la universidad, esta consideración se tomó muy en cuenta debido a que en la red de producción están ubicados servicios de TI que pueden ser susceptibles a ataques, teniendo en cuenta que una Honeynet puede ser usada como atacante de tal manera que no se pueden exponer los servicios a este posible riesgo. En la honeynet se utilizan algunas herramientas como Walleye, Sebek, Snort entre las principales, de las cuales Sebek se utiliza para realizar la captura de tráfico, la figura 1 posterior muestra la estructura de la comunicación de Sebek para la transmisión de los datos capturados desde un Honeypot hacia el servidor que almacena los datos. Fig Sebek esquema de captura Esta estructura se utiliza en la mayoría de las honeynets que usan Sebek, este realiza la captura de datos en el honeypot y luego los transmite de forma segura e invisible al atacante hacia el servidor para su posterior análisis. Mientras que Walleye es una interfaz gráfica que presenta de ordenadamente la información previamente extraída con Sebek Revisión de la plataforma La actual red trampa es de generación II, como se mencionó anteriormente esta se encuentra ubicada fuera de la red de producción de la universidad, con un direccionamiento de subred para 8 hosts, gráficamente se puede observar la ubicación inicial de la honeynet tomada de 2. 1 Montalván Henry, Estudio de tráfico de ataques a la red de la UTPL mediante la implementación de un prototipo de Honeypot 2 Montalván Henry, Estudio de tráfico de ataques a la red de la UTPL mediante la implementación de un prototipo de Honeypot 12

20 Fig Esquema de la red de la UTPL Fig Esquema de red de la honeynet UTPL Mención aparte para destacar las técnicas de engaño utilizadas en la Honeynet para despistar a los atacantes, es decir para que estos crean que realmente están atacando a un recurso importante, entre estos destacan, honeyd el software de virtualización que permite diseñar una Honeynet y Symantec Decoy Server (Man Trap)[2]. Una configuración errónea en una Honeynet puede tener implicaciones severas sobre los equipos de la red de producción si la red está operando junto a una. La Honeynet puede ser comprometida y usada como relay[3], un señuelo del verdadero atacante. El administrador debe acometer correctamente las 13

21 configuraciones que eviten la salida de tráfico maligno desde la red trampa hacia alguna red en producción, servidor ajeno externo, etc. Esta medida se logra con las reglas de firewall, también implementadas en la Honeynet UTPL, junto a otras medidas como un NIDS 3. Tomando en cuenta las ventajas y desventajas de la honeynet [4], en la honeynet que se ha integrado en la red, se ha utilizado algunos métodos que permiten asegurar un alto rendimiento [4], de acuerdo a la fuente citada, los honeypots sobretodo deben ser mantenidos de acuerdo a una lista de pasos, ésta lista de pasos ayuda al administrador a reponer los equipos en cuanto estos lo necesiten ya sea porque el equipo se ha visto comprometido demasiado, está siendo utilizado como relay o bien necesita realizarse un backup de datos, manejando para esto imágenes de las configuraciones y de los datos totales en los honeypots Revisión del software Actualmente se utilizan para la administración y mantenimiento herramientas que vienen incluídas en la distribución Honeywall, tales como las iptables de firewall, snort, proxy ARP, snort_inline, etc. Snort.- NIDS que lanza alarmas de ataques conocidos que son detectados por sus sensores. Snort_Inline.- NIPS 5 que previene ataques detectados por snort, está basado en snort y puede ser configurado para realizar alguna acción específica sobre los paquetes atacantes. Iptables.- Reglas de firewall 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 fingerprinting9).- Recoge información sobre el sistema operativo de un host. 3 NIDS: Network Intrusion Detection System (Sistema de detección de instrusiones) 4 Honeypot: Sistema señuelo utilizado para capturar tráfico en una honeynet. 5 NIPS: Network Intrusion Prevention System. 14

22 Sebek.- Aplicación cliente servidor que captura los datos ingresados por los atacantes, es decir captura todas las manipulaciones y modificaciones de los atacantes sobre los datos del honeypot. Capaz de registrar conexiones seguras levantadas desde y hacia el equipo. Se ubica muy cerca del núcleo, por tal motivo pasa desapercibido por los atacantes. El objetivo primordial como se ha explicado es recolectar los datos modificados y creados sin que la aplicación sea descubierta. Hflow.- 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 tráfico, permite ver información de los archivos exportados por sebek (.cap). Provisto de herramientas gráficas para determinar el flujo de datos, incluyendo una potente base de datos de filtros que puede ser usada para realizar análisis detallados sobre algún servicio en particular. Walleye.- Herramienta gráfica de administración de la Honeynet, permitiendo al administrador solicitar información a los honeypots. Permite ver los datos recolectados por sebek. Honeysnap.- Presenta análisis resumidos de los archivos exportados por sebek Honeynet virtuales Virtualizar sistemas permite el ahorro de tiempo, recursos y por ende dinero, una honeynet de este tipono son un nuevo concepto, de hecho toman el concepto actual de Honeynet y las implementan de una forma diferente. Esta implementación tiene sus únicas ventajas y desventajas comparadas con las Honeynets tradicionales. Las ventajas son coste reducido y más fácil manejo, ya que todo está; combinado en un único sistema [14]. Es decir no existen grandes diferencias entre una honeynet normal y una virtualizada en cuanto a la instalación e implementación. En protección y resultados es otro ámbito, mientras que en una honeynet normal se puede utilizar cualquier tipo de sistema operativo, en las virtualizadas se limita mucho al hardware y al programa virtualizador que se use, además un atacante puede 15

23 usarla para pasar por alto los mecanismos de control y captura de datos tomando el dominio de la honeynet virtual. Honeynet Virtual Auto-Contenida Una Honeynet Virtual Auto-Contenida es una red entera Honeynet condensada en un sólo computador. La red entera está virtualmente contenida en un único y físico sistema. Una red Honeynet típicamente consiste de un cortafuego para Control de Datos y Captura de Datos, y los honeypots dentro de la Honeynet. Fig Honeynet auto-contenida [14] Algunas ventas de este tipo de Honeynet(s) virtual(es) son: Movible, las Honeynets Virtuales pueden ser situadas en un portátil y llevadas a donde quiera. Plug and Play, Puedes coger una máquina y simplemente conectarla en cualquier red y estará preparada para coger a los blackhats. Esto hace que la implantación sea más fácil, ya que físicamente está implantando y conectando un sólo sistema. Barata en dinero y en espacio, sólo se necesita un computador, así que reduce gastos de hardware. Ocupa poco espacio y solo necesita una regleta y un puerto. Hay algunas desventajas: Único punto de fallo. Si algo va mal con el hardware, la honeynet entera se quedaría sin funcionar. 16

24 Computador de Alta Calidad, aunque las Honeynets Auto-Contenidas sólo requieren un computador, tendrá que ser un sistema potente. Dependiendo de la configuración, puede necesitar bastante memoria y procesador. Seguridad, ya que todo puede estar compartiendo el mismo hardware, hay peligro de que un atacante acceda a otras partes del sistema. Mucho depende del software virtual. Software Limitado, ya que todo tiene que ejecutarse en una máquina, estás limitado al software que se puede usar. Honeynet Virtual Híbrida Una Honeynet Híbrida es una combinación de la clásica Honeynet y del software virtual. Captura de Datos, como por ejemplo cortafuegos, y Control de Datos, como por ejemplo sensores IDS y almacenamiento de logs, están en un sistema separado y aislado. Este aislamiento reduce el riesgo de compromiso. Sin embargo, todas las honeynets son virtualmente ejecutadas en una única máquina. Las ventajas de esta configuración son: Fig Honeynet Virtual Híbrida [14] Segura: Como se vió en las Honeynets Auto-Contenidas, existe el peligro de que que el atacante acceda a otras partes de la honeynet (como el 17

25 cortafuegos). Con las Honeynets Híbridas, el único peligro sería que el atacante accediera a otras honeypots. Flexible: Puedes usar una gran cantidad de software y hardware para el Control de Datos y la Captura de Datos de la red Híbrida. Algunas desventajas son: No movible, ya que la red honeynet consistirá en más de una máquina, es más difícil moverla. Cara en tiempo y en espacio, tendrá que pasarse más electricidad, espacio y posiblemente dinero puesto que habrá más de un computador en la red Resultados obtenidos Si bien la Honeynet UTPL captura tráfico malicioso valioso que sirve de aprendizaje, no cubre los servicios que actualmente la universidad brinda a sus usuarios, no tiene un servidor web, proxy, mail, dns con las mismas configuraciones y características que las utilizadas, aún más crítico es que tampoco monta servicios propios de la universidad, como el sistema financiero, ni el sistema de gestión académica por lo que es necesario montar estos servicios para que los administradores de los servidores obtengan información del riesgo que corren sus servicios al estar expuestos en la red de producción. Ahora a pesar de que la Honeynet emula débilmente algunos servicios, la información que se extrae de esta es valiosa para la investigación presente, a continuación detallo las herramientas que a priori y primordialmente serán ubicadas en la red virtual: Honeywall Walleye Sebek Wireshark TCPDump 18

26 Fase 1.2 Identificación de servicios internos de la UTPL Problemática Como se menciona al final de la sección anterior, la actual honeynet implementada no emula servicios que la universidad tenga funcionando, tiene en producción 2 honeypots de los cuales captura su tráfico, permite obtener datos de la metodología utilizada por los atacantes y definir los ataques utilizados, pero concretamente no proporciona información de ataques a servicios específicos usados por la universidad. No se pretende dar una solución efectiva contra algún método de ataque específico, pero si se habla de una medida que puede ayudar a prevenir distintos ataques, en principio, porque la red virtual se usará para obtener información de la estructura de los ataques, conocer nuevas vulnerabilidades, aunque distinto de la honeynet actual, en este proyecto se implementaronalgunos servicios que utiliza la universidad, con las mismas configuraciones, con el ánimo de identificar las vulnerabilidades que por muchas razones se pasan por alto y que de esta manera brinde información al administrador de cómo puede proteger aún más a su equipo. La universidad cuenta con una variedad abultada de servicios, para esto posteriormente se hará una evaluación para escoger los servicios de mayor criticidad en la red de producción interna tomando en cuenta variables como tráfico entrante, promedio, impacto si algún riesgo potencial sucede, etc Inventario de servicios y evaluación de la criticidad Esta fase del proyecto comprende también el análisis de la importancia de los servicios en la red de la universidad, como primer paso de esta fase, se ha realizado una investigación en base a la información encontrada en el proyecto PCN [6]. Aunque en el PCN se menciona un SGA-MAD (Sistema de Gestión Académica de la Modalidad Abierta y a Distancia) y SGAMC (Sistema de Gestión Académica de la Modalidad Clásica), estos dos sistemas fueron reemplazados por el Entorno Virtual de Aprendizaje EVA, el cuál será implementado en esta fase inicial de análisis de servicios. 19

27 El servicio de internet es el que contiene los servicios críticos en sí, los más necesarios para nuestro proyecto, PCN menciona: 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, asignación de nombres de dominios internos de las aplicaciones, brinda dominios virtuales a clientes externos, permite el acceso a internet. Por lo que estos servicios debería ser implementados, en principio, puesto que en las posteriores secciones se evaluará la criticidad de cada servicio, su importancia, cantidad de usuarios, servicios, etc. Para la elección de los servicios se seguirá un proceso de filtrado, con las siguientes fases: 1. Encuestas.- Con el carácter de extraer información de los servidores se aplicó a todos los administradores, se puede considerar como el primer filtro, de estas encuestas se tomaron en cuenta la cantidad de usuarios que gestiona cada servidor, la importancia, la criticidad, los servicios que utiliza, además si interaccionan con otros servicios de la red. 2. Definición de los servicios críticos de acuerdo al tráfico: Se realiza el segundo filtro, aquí se extraen estadísticas del tráfico promedio y máximo tanto de entrada como tráfico de salida, esta muestra de datos se extrae en dos intervalos de una semana cada uno. 3. De acuerdo a los dos puntos anteriores se realiza una evaluación conjunta con el director de tesis para confirmar o descartar servidores. 4. Consideraciones finales.- Se pide información detallada a cada administrador de los servidores que han llegado hasta esta sección [Ver Anexo A]. 5. A los servidores escogidos se extrae los problemas de seguridad que aparecen en los datos proporcionados por los propios administradores, además, se realiza una búsqueda online de las vulnerabilidades conocidas sobre el sistema operativo y sobre los servicios implementados en cada servidor. 20

28 1.2.3 Definición de servicios críticos de acuerdo al tráfico Luego de recabar información de cada servicio y de acuerdo a los datos resultantes de las encuestas sometidas, los servidores, fueron sometidos a una evaluación de tráfico, con la intención de conocer con más detalle si deberían o no ser parte de la red interna que se implementa, para esto, se tomó dos muestras de tráfico en un intervalo de una semana para cada muestra, con lo cual se obtuvo: Tabla Extractos de tráfico promedio de los servidores 6. Servidor Muestra In Average eth0 Out In Max Out Max Average WEB Del 29/03 a 02/ k 2.05M 3.29M 34.75M Del 05/04 a 09/04 DNS Del 22/03 a 26/03 Del 29/03 a 02/04 Proxy Del 29/03 a 02/04 Del 22/03 a 26/03 proxy eth1 Del 29/03 a 02/04 Del 22/03 a 26/ k 6.73 M M M 35 k k k k k k k k K 6.43 M M M 1.30 M M M M 8.52 M K M M M 1.02 M M M De estas estadísticas se puede concluir que el servidor DNS no encajaría, por tráfico, en el nivel de los otros servidores, ciertamente registra muy poco tráfico, pero en caso de fallar este servicio toda la universidad perdería el acceso a internet además del caos que se produciría en la red interna por la interacción entre servicios, puesto que muchos utilizan los nombres de los equipos en lugar de su dirección IP. El servidor proxy tiene 2 interfaces Ethernet funcionando, obviamente es necesaria la presencia de ambas, pero la presencia del servidor no se justifica como crítica, ciertamente es un servicio de criticidad media, pero, ante su falta la universidad aún podría salir al internet con la configuración adecuada. 6 Extraído del Network Operation Center de la UTPL: 21

29 1.2.4 Consideraciones finales entre los servicios escogidos Tabla Consideraciones de importancia y criticidad de los servidores Consideraciones Baan PROXY DNS EVA Número usuarios * 1500* 67000* Criticidad** Alta Media Media Baja Importancia** Alta Media Media Alta Interracción con otros sistemas Si No No Si Fecha de ultima actualización Dic-10 Mar-10 Mar-10 Ene-10 Última vez que parchó Mar-10 Lleva registro de incidentes No Si si no Da un promedio aproximado de incidentes no No < 10 no Considera que el equipo es el adecuado si No si no Usa un firewall ** no Si si no *Valor aproximado **Según el administrador Revisión de problemas de seguridad relacionados De los problemas identificados en las encuestas [Ver Anexo C]sometidas a los administradores, se deslindan los siguientes: o Algunos administradores no colocan los parches adecuados para sus distribuciones ni sus servicios. o Se llevan registros de los ataques a los servicios, pero, no tienen un número aproximado de ataques conocidos o en algunos casos los ataques son mínimos. o La mayoría de los administradores cree que su equipo ya no brinda las prestaciones necesarias para satisfacer las necesidades de los usuarios. De los servicios que se proporcionan todos tienen vulnerabilidades [Ver anexo B] las cuales se encuentran parchadas con las actualizaciones últimas realizadas sobre los servicios, aunque es posible que existan aún más vulnerabilidades, existen sitios como Milworm 7 que anexan código fuente de las vulnerabilidades encontradas

30 1.2.6 Resultados obtenidos: Servidores escogidos Luego del proceso realizado se llega al escogimiento de estos 4 servidores, de los cuales se obtuvo información detallada gracias al aporte de cada administrador: 1. Baan Datos generales Tabla Características generales del equipo real N Procesadores 2 Procesador Powerpc P5 Memoria 17 GB Disco duro 300 GB* Raid - S.O. AIX Versión 5.3 Kernel Mantenimiento 8 Firewall No Detalles de administración Tabla Características de administración e importancia Nombre Uloja DIR IP - Ubicación Interna Dependencia SIT - D. Financiero Ing. Franco Responsable Guachizaca Estado Producción Criticidad Alta Importancia Alta Usuarios 62 Interacción Syllabus Servicios Tabla Servicios utilizados por el servidor real Servicio Puerto Versión Baan ERP c Oracle G 23

31 2. WEB Datos generales Tabla Características generales del equipo real Nombre gdr1 DIR IP - Ubicación Interna Dependencia Gestión del conocimiento Responsable Ing. Ramiro Ramírez Estado Producción Criticidad Alto Importancia Alto Usuarios Aprox Interacción Servidor EVA SGA Mail Servidor Oracle Detalles de hardware Tabla Características de hardware N Procesadores 2 Procesador Intel Xeon a 1.6 Ghz Memoria 10 GB Disco duro 300 GB Raid - S.O. CentOS Versión 4.4 Kernel Firewall Si Servicios Tabla Servicios utilizados por el servidor real Servicio Puerto Versión Apache CMAP 8080, 4447, 4999, SSH FTP 21 - Webmin

32 3. Servidor EVA(Entorno virtual de Aprendizaje) Datos generales Tabla Características generales del equipo real Nombre Eva DIR IP - Ubicación Interna Dependencia Virtualización Responsable Ing. Rodrigo López Estado Producción Criticidad Alta Importancia Media Usuarios Aprox Interacción Si Mail LDAP Detalles de Hardware y S.O. Tabla Características de administración e importancia N Procesadores 1 Dual Core Procesador Intel Xeon 1.6 Ghz Memoria 8 GB Disco duro 70 GB Raid - S.O. CentOS Versión 5.3 Kernel Firewall No Servicios Tabla Servicios utilizados por el servidor real Servicio Puerto Versión Apache 80 - Tomcat

33 DNS Interno Datos generales Tabla Características generales del equipo real Nombre gdr5 DIR IP - Ubicación Interna Dependencia UPSI GTE Responsable Ing. Alexander López Estado Producción Criticidad Media Importancia Media Usuarios Aprox Interacción No Detalles de hardware y S.O. Tabla Características de administración e importancia N Procesadores 1 Procesador Pentium III 1.2 Ghz Memoria 1 GB Disco duro 80 GB Raid 1 S.O. CentOS Versión 5 Kernel Firewall Si Servicios Tabla Servicios utilizados por el servidor real Servicio Puerto Versión Named SSH

34 SEGUNDO COMPONENTE IMPLEMENTACIÓN DE LOS SERVICIOS CRÍTICOS EN LA HONEYNET VIRTUAL 27

35 Fase 2.1Preparación de equipos Elección de herramienta virtualizadora. Esta subfase comprende el análisis de las herramientas existentes para virtualización, comparación entre aplicaciones, los beneficios y desventajas que proporcionan, además se contrastará al final cuál de ellas se ajusta a los requerimientos necesarios para montar la honeynet y los honeypots correspondientes. Entre los requisitos que deben cumplir se encuentran: Enmarcarse dentro de las posibilidades del hardware que se utilizará. El consumo de recursos debe ser bajo. Que soporte los S.O. a utilizar. Que permita manejar los modos Host-only. Nat y bridge principalmente. Que permita suspender los S.O. En lo posible que sea una herramienta libre Análisis de Herramientas existentes VMWWARE[7] Vmwarees un producto para realizar virtualización de sistemas operativos, en principio se creó como software privado, pero gracias al advenimiento de la cultura open source, EMC Corporation creó versiones libres para instalarse en la mayoría de plataformas basadas en unix.el software creado por esta empresa mantiene, entre los más conocidos, los productos Vmware, y las versiones libres Vmware Server y Vmware Player, las siglas VM provienen de la unión de las palabras anglosajonas Virtual Machine. Vmware es un simulador de sistemas operativos, un simulador permite una ambiente de ejecución con características similares a uno real, emulando sus características principales, tales como CPU, BIOS, tarjeta gráfica, RAM, Adaptador de sonido, puertos seriales, Disco Duro, etc. Aunque un simulador no puede 28

36 emular la velocidad real de un equipo físico con un sistema anfitrión, se acerca mucho y permite usarle en ambientes de producción. Vmware permite ejecutar instrucciones directamente en el procesador, a diferencia de algunos de sus rivales, además es uno de los productos de virtualización más utilizados. Vmware tiene algunos competidores como Virtual PC (para Windows XP), Xen (paravirtualization 8 ), Virtual Box, entre las más conocidas. Vmware Player Es un producto gratuito que permite correr máquinas virtuales creadas con productos de VMware. Las máquinas virtuales se pueden crear con productos más avanzados como VMware Workstation, o con el propio VMware Player desde su versión 3.0 (las versiones anteriores no incluyen dicha funcionalidad). Vmware Server Esta versión, a diferencia de la anterior, tiene un mejor manejo y administración de recursos; también corre dentro de un sistema operativo (host), está pensada para responder a una demanda mayor que el Workstation. Otra diferencia entre VMware Server y Workstation es que se pueden ejecutar de manera concurrente más máquinas virtuales soportando servidores con hasta 32 procesadores y/o 64 GB de memoria, ofreciendo funcionalidad de administración remota, soporta una API avanzada y funcionalidad de scripting y se puede ejecutar en modo headless. Vmware ESXi Es una versión completa del producto ESX, pero con varias limitaciones, entre ellas: no permite instalar controladores (drivers) para hardware adicional, no permite utilizar las funciones avanzadas de movimiento de maquinas virtuales encendidas de un equipo físico a otro, ni hacerlo con el almacenamiento. Vmware ESX Server Esta versión es un sistema complejo de virtualización, pues corre como 8 Paravirtualización: Virtualización de hardware, teóricamente actúan directamente sobre el hardware. 29

37 sistema operativo dedicado al manejo y administración de máquinas virtuales dado que no necesita un sistema operativo host sobre el cual sea necesario instalarlo. Pensado para la centralización y virtualización de servidores, esta versión no es compatible con una gran lista de hardware doméstico. Es realmente útil, ya que solamente ocupa 10 Mb de Ram y 55 de Disco Duro, aproximadamente. Para su administración, hay que instalar un software en una máquina remota, que se conecta por entorno web. XEN[8] Producto de Paravirtualización, desarrollada por la universidad de Cambridge, a diferencia de vmware que hace una virtualización, xen se mezcla con el sistema operativo anfitrión dando mejores resultados aunque con un nivel mayor de dificultad y un aumento en el consumo de recursos. Los sistemas operativos pueden ser modificados explícitamente para correr Xen. Esto permite a Xen alcanzar virtualización de alto rendimiento sin un soporte especial de hardware. Es software de licencia libre lo que posibilita su mayor uso en distribuciones linux, aunque no alcanza el rendimiento de Vmware ESX Server [9] que es software privativo, está muy cerca en términos de rendimiento. Xen puede ser instalado en los siguientes sistemas Mandriva Ubuntu Suse Xen demo CD Fedora Core NetBSD Fedora Oracle VM Red Hat Enterprise Linux Centos, entre los más Xenophilia conocidos. Debian VIRTUAL BOX[10] Software de virtualización creado originalmente por Innotex GmbH, aunque, actualmente es desarrollado por Oracle Corp. De características similares a vmware player, soporta sistemas operativos GNU/LINUX, MAC OSX, OS/2 Warp, Microsoft Windows, Open Solaris/Solaris. Nación como un producto con licencia 30

38 de software propietario aunque a inicios del 2007 se publicó la versión Virtual Box OSE, bajo la licencia GPL2, aunque carece de algunas funcionalidades en comparación con rivales como Wmware o Virtual PC, provee la ejecución de maquinas virtuales de forma remota a través del protocolo RDP (Remote Desktop Control). Entre las características principales se pueden mencionar: El que permite el uso de carpetas compartidas entre las máquinas virtuales Las últimas versiones ya incluyen ya brindan soporte necesario para que una máquina virtual pueda integrar puertos USB Las configuraciones de virtualbox se guardan en archivos con formato xml, lo que permite que esas configuraciones puedan transferirse a otras máquinas. Control de escritorio remoto, una máquina virtual puede actuar como un servidor RDP, lo que permite que se pueda correr la máquina virtual de forma remota. Esta es una evaluación comparativa realizada por el sitio alemán heise [15], entre Vmware y Virtualbox, teniendo los siguientes resultados: make: -- Máquina real: 64 minutos -- VirtualBox: 107 minutos -- VMware: 101 minutos En el resultado superior, se escogió un sistema operativo se implementó en ambos productos y se calculó el tiempo que cada uno demoró en comparación con una máquina real al momento de hacer una compilación de kernel. grep: -- Máquina real: 7 minutos -- VirtualBox: 20 minutos -- VMware: 18 minutos En este segundo resultado se realizo un grep con un listado de más de 100MB. 31

39 Razones para escoger Virtualbox OSE. Aunque este producto no ofrece un rendimiento igual o mejor que Vmware, se acerca mucho, entre las ventajas que puedo nombrar están: Aunque es software propietario, existen versiones libres para linux. Consume menos recursos en el equipo anfitrión asignado. Incluye las características más comunes entre las herramientas de virtualización existentes. Facilidad de mantenimiento de las máquinas virtuales. Crea un solo archivo por cada máquina virtual. Comparte carpetas entre máquinas virtuales. Soporte de dispositivos USB Administración de máquinas virtuales de forma remota. Archivo de configuración único de fácil transporte. Tabla Cuadro comparativo entre las herramientas virtualizadoras Características VMWare Virtual Box UML XEN Licencia Privado Privado Libre Libre Consumo Medio Alto Bajo Medio Usabilidad Simple Simple Complejo Medio Facilidad Simple Simple Complejo Medio Paravirtualización No Si ** No Si Movilidad Si Si No Si Soporte Si Si Libre * Libre * *Soporte brindado por comunidad de software libre. **Incorpora función PAE/NX 2.1.2Honeynet virtual a utilizar Se usará una honeynet Virtual auto-contenida, ya que presenta algunas ventajas sobre una Híbrida, ventajas tales como: el uso de un solo equipo para el proceso de virtualización, mayor facilidad de mantenimiento, etc. Debido a que los honeypots que se administrarán y dado que no se puede permitir poner en riesgo el control total de la honeynet por un atacante, tomando en cuenta las limitaciones en términos de captura y protección, a continuación el esquema de la honeynet virtual: 32

40 Fig Esquema de honeynet a implementar Fig Ubicación de la honeynet virtual en la red de la UTPL 33

41 2.1.3 Pruebas de implementación Equipo de prueba Tabla Equipo utilizado para las pruebas previas de la honeynet Procesador Intel Pentium 4 RAM 1 GB DISCO DURO 80 GB S.O. Anfitrión Ubuntu 8.04 Maquina virtual Virtualbox Sistemas virtualizados DNS - Centos RAM - 8 GB HD - GUI Inhabilitada WEB - Centos RAM - 8 GB HD - GUI Inhabilitada Honeywall Equipo utilizado como anfitrión Tabla Equipo que se utiliza para la implementación de la honeynet Procesador Intel Core 2 Duo RAM 4 GB * DISCO DURO 320 GB S.O. Windows Server Anfitrión 2008 Enterprise *El equipo trae inicialmente 2 GB, se adquirieron 2 GB aparte Conclusiones extraídas a partir de las pruebas Sistemas a instalar en host anfitrión* Las pruebas de implementación me sirvieron para identificar la configuración virtual óptima para los servidores escogidos como críticos, además mencionar que se utilizará una honeynet virtual híbrida por todas las prestaciones que presenta en comparación a una Auto-Contenida. Con las pruebas se llegó a la conclusión de que cada servidor virtual debe tener las siguientes especificaciones de acuerdo a las características del host anfitrión. Tabla Características implementadas a cada máquina virtual. SERVIDOR S.O. RAM (GB) HD (GB) DNS CentOS 5 ** WEB CentOS 4.4 ** EVA CentOS 5.3 ** BAAN AIX** Honeywall Honeywall *Son datos aproximados teniendo en cuenta los datos de las pruebas ** Se reemplazo por Ubuntu Server Gutsy Gibon por la limitación de la instalación de sebek. 34

42 2.1.5 Riesgos encontrados Riesgos en el Host Anfitrión Falta de espacio en HD MV Comprometida Falta 3 de RAM RIESGO 2 Configuración erronea Fig Riesgos del host anfitrión. Tabla Riesgos sobre el host anfitrión PROBABILIDAD IMPACTO CONSECUENCIA ACCIONES Falta de espacio en HD 2 3 Falta de RAM 2 3 La máquina virtual podría colapsar Volcado de memoria: Colapso de MV. - Respaldos periódicos Configuración erronea 2 2 MV Comprometida 3 2 Descripción de riesgos: Captura erronea, comprometer MV, Perdida de tiempo, etc. Atacante se apodera de maquina virtual y realiza cambios Configurar de acuerdo a las necesidades Revisión de Logs Falta espacio en HD Si se adicionan la capacidad de discos de cada sistema, se tendría problemas considerando que el equipo pedido trae 320 GB, los cuales serán repartidos entre las 5 maquinas virtuales y el host anfitrión. Aunque por la naturaleza del proyecto, de emular los sistemas, no 35

43 necesariamente se implementarán con la misma capacidad, pero si se asignará una cantidad adecuada para cada sistema Acción preventiva: Para aplacar este riesgo es posible contar con un disco duro externo de la misma capacidad, en el cual se irá respaldando la información capturada por cada honeypot. Probabilidad: Clasificado como de importancia media, debido al uso de un disco externo la probabilidad disminuye. Impacto: Alto, si el riesgo se hace realidad, el efecto es la caída del honeypot. Falta de Memoria principal RAM Un riesgo de mucha importancia. Aunque son 5 maquinas virtuales no todas consumen la misma cantidad de memoria principal, las pruebas arrojan que el servidor DNS podría trabajar con 256 de RAM tranquilamente, mientras que con la máquina de prueba el servidor WEB con 281 trabaja bien. La preocupación aparece con el servidor BAAN que es el de más alto consumo en memoria principal, aunque como se verá luego al final el riesgo se minimiza. Acción preventiva: La placa base del anfitrión soporta hasta 4 GB, así que se elevará hasta esa cantidad la memoria principal. Probabilidad: Es muy posible que ocurra este problema. Impacto: Alto, la ocurrencia de este riesgo podría denegar el servicio del honeypot. Configuración errónea[ver ANEXO F] Este riesgo tiene más ocurrencia por un error humano antes que un problema tecnológico. Tendría efectos operativos que dificultarían la captura normal desde los honeypots, además que importaría a los administradores perdidas en términos de tiempo. Acción preventiva: Llevar a cabo una configuración de acuerdo a una metodología que cubra todos los aspectos importantes para una perfecta configuración Probabilidad: Media, es probable que ocurra, pero si se sigue la metodología, este riesgo se minimiza. 36

44 Impacto: Medio, aunque funcionaría el honeypot es probable que no esté cumpliendo la labor para la que fue pensado. MV Comprometida Es un riesgo común y de mucha importancia, un atacante podría tomar acciones sobre el honeypot para hacer daño sobre el mismo o para utilizarlo como relay o atacante falso, aunque los honeypots virtuales limitan el accionar de cualquier atacante. Acción preventiva: Antes que acciones preventivas, se debe configurar muy bien las aplicaciones de captura, en este caso Sebek, para tener la información exacta de cómo fue comprometida la máquina. Además se puede evitar que el honeypot sea utilizado como relay prohibiendo la salida de tráfico desde el honeypot. Probabilidad: Alta, es decir el honeypot está expuesto para ser comprometido, el tema es evitar que sea usado para atacar. Impacto: Alto, si es comprometido y las configuraciones también son erróneas, es probable que el honeypot sea utilizado como un atacante falso. 37

45 Fase 2.2 Implementación de servicios Instalación de ROO Honeywall CDROM [Anexo L] El propósito de este manual es dar a conocer al Administrador del Proyecto Honeynet, las características técnicas de instalación y configuración del Honeywall CDROM Roo-1.4.hw Se espera que el manual sirva de apoyo para modificar valores y parámetros de las variables existentes cuando sea necesario Implementación del servidor web El servidor web de la UTPL cuenta con los servicios de apache y webmin, los cuales alojan la página principal de la universidad, para lo cual se instaló y configuró el servidor WEB con las siguientes características: Instalación y configuración 1. Creación de máquina virtual a. Características principales i. 2 procesadores ii. 698 MB memoria RAM iii de Disco Duro iv. Habilitada la función PAE/NX 9 v. Eth0 en modo host only. 2. Instalación de Ubuntu server 7.10 Gutsy gibbon a. Nombre de la máquina: mpkstroff b. Usuario: mpkstroff c. Nombre de la cuenta: mpkstroff d. Contraseña: D###c Configuraciones previas del S.O. 9 Función PAE/NX: Necesaria para que el SO virtualizado pueda gestionar archivos mayores a 4GB. 38

46 a. Modificación de los archivos motd y motd.tail b. Instalación de openssh-server y openssh-client 4. Instalación de servidor web apache [Ver anexo E] 5. Instalación de webmin [Ver anexo F] 6. Pruebas [Ver anexo G] 7. Instalación de sebek Reglas de firewall[ver anexo I] El servidor web de la UTPL si utiliza un firewall, aunque la aplicación cmaps no pudo ser instalada se abrió el puerto, además se permitió el acceso a los servicios web, ssh, ftp, se permite la comunicación con el servidor EVA además con el Webmin para la administración del servidor y finalmente se cerraron los puertos que no son utilizados. 39

47 2.2.2 Implementación del servidor dns Configuraciones generales Estas configuraciones se realizan desde el proceso de instalación del servidor hasta antes de la implementación de los servicios. El servidor DNS tiene las siguientes configuraciones: Nombre de la cuenta: Saramago Usuario de la cuenta: Saramago Contraseña: Se sigue el estándar de Una letra mayúscula, números y símbolos. Dirección IP: <>.220 Durante el proceso de instalación de Gutsy Gibbon no se incluye ningún servidor de los que vienen incluidos en la distribución Se modifican los archivos motd, motd.tail, issue en, en el que se ubicó un mensaje en el cual se advierte que todas las acciones están siendo almacenadas. root@tesis-desktop:# nano /etc/motd root@tesis-desktop:# nano /etc/motd.tail root@tesis-desktop:# nano /etc/issue El servidor DNS real utiliza bind con la versión en CentOS 5, aunque estas configuraciones variaron en función de la limitación de sebek, paquete que tiene implementación actualmente para ubuntu 7.10, lo que impide usar la versión antes mencionada de CentOS. Se decidió implementar bind en esas condiciones, siguiendo este procedimiento: 1. Se configuran las características de la máquina virtual 1. Memoria principal 294 MB 2. Disco Duro 32 GB 2. Se instaló ubuntu server 7.10 Gutsy Gibbon 3. Se instala por defecto openssh-server y openssh-client. 4. Se descarga el archivo bind_ _i386.deb. 40

48 *El archivo está en formato RPM 10, así que se usa el programa alien 11 para transformarlo en.deb y pueda ser instalable en ubuntu. [Ver anexo J] 5. Se instala bind9 6. Configurar DNS como Master [Ver anexo K] 1. Modificar archivo named.conf.local 2. Activar forwarders en named.conf.options 3. Crear zonas utpl.com y la inversa. 4. Reiniciar servicio 5. Probar servicio 7. Documentación Reglas de firewall[ver Anexo I] El servidor DNS tiene el firewall IPTABLES implementado, este servidor solamente permite el acceso a servicios de administración vía SSH y al servicio DNS, por lo que las reglas de firewall se configuraron acorde a estos parámetros, aunque también se habilitó el intercambio de paquetes entre el servidor utilizado para forward y se cerraron los puertos bien conocidos que no son utilizados en este servidor. 10 RPM: Red-Hat Package Manager, software empaquetado para sistemas basados en Red Hat Linux y formato de paquete de partida del Linux Estándar Base. 11 Alien: Programa convertidor entre los diferentes formatos de las distribuciones basadas en Linux. 41

49 2.2.3 Implementación del servidor eva Configuraciones generales Estas configuraciones se realizan desde el proceso de instalación del servidor hasta antes de la implementación de los servicios. El servidor EVA tiene las siguientes configuraciones Nombre de la cuenta: gunter Usuario de la cuenta: gunter Contraseña: Se sigue el estándar de Una letra mayúscula, números y simbolos. Dirección IP: <>.223 Durante el proceso de instalación de Gutsy Gibbon se incluyó la instalación de Openssh 12 que más adelante se necesitará, se utilizó este paso para ahorrar el paso de la instalación posterior. Se modifican los archivos motd, motd.tail, issue en, en el que se ubicó un mensaje en el cual se advierte que todas las acciones están siendo almacenadas. root@tesis-desktop:# nano /etc/motd root@tesis-desktop:# nano /etc/motd.tail root@tesis-desktop:# nano /etc/issue Instalación de Moodle 1.9.9[Ver Anexo H] Requerimientos: - Servidor Web: Apache - Base de datos: Mysql - Lenguaje: PHP Reglas de firewall[ver anexo I] El Entorno Virtual de Aprendizaje utiliza los servicios de Apache y Tomcat, el primero no tuvo ningún reparo al ser instalado, mientras que el segundo no está instalado por problemas de dependencia con el Ubuntu Server, de todas formas 12 Versión libre del protocolo de acceso remoto seguro SSH. 42

50 se abrió el puerto, se habilitaron los puertos 80 y 8080 además de permitir el envío y recepción de paquetes dns y cerrar los puertos que no son utilizados en el servidor Implementación del servidor baan Implementación El servidor BAAN no tiene implementado un firewall, aunque las aplicaciones Oracle 10 G Enterprise y Baan ERP 5.0c levantan los puertos 1521 y 512 respectivamente. Debido a que no se pudo instalar ninguno de los 2 servicios en la máquina virtual usada, debido a la limitación de sebek y al ser los dos servicios de licencia privada, se levanta el firewall IPTABLES para abrir los puertos antes mencionados, se permite también el intercambio de paquetes con el servidor DNS y se cerraron los puertos conocidos que no son utilizados por el servidor: Reglas de firewallver Anexo I En el caso de este servidor solamente se ubicaron las reglas de firewall para tratar de indicar que se está utilizando los servicios de Oracle 10 G y el Baan ERP, aunque sin embargo no estén instalados, el resto de puertos estánhabilitados. 43

51 TERCER COMPONENTE RECOLECCIÓN DE DATOS 44

52 Fase 3.1 Control de datos en la honeynet Medidas de contención y control de conexiones En esta fase se explica con mayor detalle las acciones tomadas para que dentro de lo posible un blackhat 13 no tome el control de la honeynet, uno de los cuatro requerimientos principales mencionados en [12]. En resumen indica que se debe tomar medidas de contención ante un atacante sin obstruir la captura del tráfico deseado, además de evitar que este caiga en cuenta que está en una red trampa y continúe con su accionar sobre los servicios que se implementen. La honeynet virtual ubicada en la red interna de la UTPL utiliza la vlan 28. Esta red virtual fue agregada para ubicar a los estudiantes de gestión productiva y no presentó ninguna limitación para el proyecto. Sin embargo era necesario limitar el acceso de la vlan a redes de alta criticidad como, vlans de servidores, de telefonía, centros asociados, cámaras de seguridad, VoIP, etc. Fue necesario obtener tráfico de relevancia para el proyecto desde vlans como redes inalámbricas, salas, GP, laboratorios, etc. Las redes inalámbricas libres que proporciona la universidad son de especial agrado para el presente proyecto, puesto que cualquier máquina puede conectarse y ser utilizada para infectar con malware o en casos extremos para atacar algún servicio o equipo de la red, aunque se dé en muy pocos casos. Vlans utilizadas para capturar tráfico: Tabla Vlans utilizadas para capturar tráfico Vlan Denominación Vlan Denominación 3 Cittes 19 Docentes 6 Octog 25 Inalámbrica 7 Abierta 28 GP 11 Salas 30 ADM-INT 12 Salas 31 Desarrolladores 17 Valle-tec 33 Ap-Biblioteca 18 Cittes-b 88 Lab-Ingles Criterios para escoger vlans La razón principal de haber escogido las vlans anteriores se basa en su tráfico, que resulta útil para el presente proyecto, vlans donde es más probable que se infecte un equipo y este propague el malware, donde es posible que un equipo 13 Hacker nocivo, también denominado Cracker. 45

53 pueda ser utilizado para atacar algún equipo interno con o sin consentimiento de quien maneje el equipo atacante. Aunque la universidad implementa una severa política de permisos, se logró obtener los permisos para que la honeynet pueda acaparar tráfico proveniente de estas vlans sin ninguna restricción, cualquier equipo desde las vlans mencionadas tiene opción de ingresar a cualquier honeypot y por cualquier puerto. En los 4 honeypots se utilizó iptables, con las siguientes reglas: Se permite el tráfico de entrada y salida hacia los puertos que utilizan los servicios implementados. Se denegó tráfico de entrada y salida para el resto de servicios, en el caso de los servidores EVA y BAAN, solo se permite tráfico de entrada y salida a puertos menores a 1024, el resto se denegó. Se denegó todo tráfico de salida hacia internet. Además se obtuvieron los permisos necesarios en los equipos de enrutamiento de la universidad, para que el tráfico que proviene de internet no acceda a los honeypots, como también se denegó el tráfico de salida que tenga como destino la internet Prueba de control de conexiones Se realizó pruebas desde las vlans asignadas y desde algunas no asignadas para comprobar el funcionamiento de los permisos: Tabla Pruebas a honeypot DNS desde vlans habilitadas y no habilitadas. DNS vlan29 vlan25 vlan33 vlan71 vlan82 Tipo de prueba Ping Ping ssh ssh ping Configuración Habilitado Habilitado Solo vlan 28 Solo vlan 28 Habilitado Resultado Si Si Sin acceso Sin acceso Si Tabla Pruebas a honeypot WEB desde vlans habilitadas y no habilitadas. WEB vlan29 vlan33 vlan33 vlan25 vlan28 vlan82 Tipo de prueba ping wget ssh wget ssh ping Configuración Habilitado Habilitado Solo vlan 28 Habilitado Habilitado Habilitado Resultado Si Si Sin acceso Si Si Si 46

54 Tabla Pruebas a honeypot EVA desde vlans habilitadas y no habilitadas. EVA vlan29 vlan33 vlan33 vlan25 vlan28 vlan82 Tipo de prueba Ping wget ssh wget ssh Ping Configuración Habilitado Habilitado Solo vlan 28 Habilitado Habilitado Habilitado Resultado Si Si Sin acceso Si Si Si Petición http a servidores EVA y WEB Figura Petición http (wget) a honeypots Eva y Web desde la vlan 25. Tabla Pruebas a honeypot BAAN desde vlans habilitadas y no habilitadas. BAAN vlan29 vlan25 vlan33 vlan71 vlan28 Tipo de prueba ping Ssh ssh ssh ssh Configuración Habilitado Solo vlan 28 Solo vlan 28 Solo vlan 28 Habilitado Resultado Si Sin acceso Sin acceso Sin acceso Si Prueba de conexión de acceso remoto usando el protocolo SSH Figura Intentos de conexión de acceso remoto usando el protocolo ssh a todos los honeypots. Todas las conexiones ssh desde fuera de la vlan de los honeypots están denegadas, es posible administrarlos remotamente solo a los que tienen habilitado el uso del ese protocolo y desde la vlan donde se encuentran los honeypots, al resto se ha denegado el acceso. 47

55 Peticiones ping desde vlan 82 Figura Peticiones ping realizadas desde la vlan 82 a todos los honeypots. Fase 3.2 Captura de datos Esta subfase comprende el monitoreo y captura de tráfico en los honeypots, que luego será utilizado para el análisis y entrenamiento posterior de las técnicas utilizadas para atacar. Como se menciona en [12] La captura de datos comprende monitorizar y registrar toda la actividad dentro de una honeynet. Son estos datos capturados los que se analizarán posteriormente para aprender las herramientas, tácticas y motivos de los atacantes. El desafío es capturar el mayor tráfico posible sin ser detectados, para lo cual los mecanismos implementados previamente aseguran que los honeypots (Capture Mechanisms[12]) no fueron detectados como dispositivos de escucha y captura sino como simples equipos que brindan servicios. Uno de esos mecanismos es la desactivación de Roach Motel en la honeynet, con el que se deniega todo tráfico de salida [13] desde los honeypots. Es nuestro objetivo tratar de minimizar la habilidad del atacante para evitar que se dé cuenta de los mecanismos de captura utilizados en la honeynet. Para eso es necesario hacer pocos cambios en la honeynet, además no se permite que los datos capturados reposen en los honeypots, porque un atacante bien 48

56 podría borrarlos o modificarlos y así posteriormente se tendría un análisis erróneo sobre estos, por lo cual cada honeypot se configura para enviar el tráfico capturado a la honeynet. Otro de los desafíos está en tomar en cuenta que el atacante utiliza métodos de encriptación en su actividad, métodos como SSH, IPSec, SSL, etc. Armada la honeynet, ubicados los honeypots en la vlan se empezó a capturar y se obtuvo un archivo.pcap 14 de aproximadamente 100 MB, con datos capturados en 1 día. Análisis de tráfico capturado usando Wireshark: Figura Archivo.pcap con tráfico capturado desde los honeypots. Proceso de captura El proceso de captura duró alrededor de 3 semanas en promedio por vlan y el proceso es el siguiente. 1. Se identifica la vlan a monitorizar. 2. Se configuran los honeypots para escuchar tráfico en la vlan escogida. 3. Los datos capturados por honeywall son descargados. 4. Se revisa el tráfico con la herramienta wireshark. 5. Se filtran los datos clasificando las alertas. 14 PCAP: Packet Capture. 49

57 CUARTO COMPONENTE ANÁLISIS DE DATOS 50

58 Fase 4.1 Análisis de tráfico Introducción Esta última fase del proyecto comprende el análisis del tráfico capturado por la honeynet, con este análisis se tratará de encontrar las fuentes de ataque en la red interna, la naturaleza del ataque. La honeynet empezó a capturar tráfico desde mediados de Agosto del 2010, en un inicio se ubicó en la vlan 28, posteriormente pasó a vlan 7, para posteriormente a la ubicación actual que data en la vlan 33. Las razones de los cambios están explicadas en la sección Herramientas de análisis Se utilizaron herramientas útiles que aportan características importantes para lograr un análisis de provecho, las cuales se nombran en la siguiente tabla y que además ya se mencionaron en el primer componente de este proyecto. Tabla Descripción de herramientas de recolección y análisis de tráfico. Herramienta Walleye Wireshark Características Presenta información del tráfico de red Permite solicitar información sobre Honeypots individuales Presenta una visión general de las actividades del atacante Exporta tráfico de red en formato pcap Permite modificar algunas configuraciones del Honeywall Analiza la información capturada de paquetes en formato pcap Analiza protocolos Examina datos de una red en tiempo real Presenta el flujo reconstruido de una sesión de TCP Proporciona gráficas estadísticas del tráfico Análisis de datos obtenidos desde la honeynet La honeynet virtual está activa desde mediados de agosto del 2010, los datos capturados durante este mes y medio muestran aspectos a tener en cuenta dentro de la red interna. Se registraron cantidades normales de tráfico hacia los honeypots, aproximadamente unas 100 alarmas diarias, de las cuales en promedio 10, de estas son alarmas reales, que indican un comportamiento anormal en el flujo de tráfico.del resto de alarmas aproximadamente un 60% de estas, son conexiones 51

59 hacia el servidor DNS, aunque son accesos al servicio, no representan mayor peligro, también se registraron en vlan 7 y 28 conexiones a los servicios web de los servidores WEB y EVA, aproximadamente un 10% de las conexiones. Además de algún intento de conexión al puerto 22, en un promedio del 5% del total de las alarmas. Cabe destacar que entre estos dos servidores se encontraron restos de conexiones de chat Windows Messenger Direcciones IP origen Alertas Alerta SMB Tabla Direcciones desde donde se detectaron alertas. Direcciones Protocolo Conexiones diarias http 200 aprox Dns 110 apro sshv2 58 aprox netbios 52 aprox netbios 42 aprox netbios 38 aprox netbios 22 aprox sshv2 22 aprox netbios 17 aprox Una de las alertas persistentes se dio con el protocolo SMB 15 con el que algunas direcciones de la vlan 7 intentaban iniciar sesión con el servidor WEB usando el usuario: anonymous, la siguiente figura muestra un intento de conexión: Fig Alerta de conexión usando protocolo SMB 15 SMB: Server Message Block, protocol utilizado por Microsoft windows para accede a los recursos compartidos en la red. 52

60 Alerta http Luego de realizar el cambio de vlan de la 28 a la 7, se produjo un aumento en el tráfico desde y hacia el gdr4 ( ), estas conexiones muestran cortas transferencias de tráfico no http y también peticiones de retransmisión TCP, en estos intentos se muestra que el origen es un servidor de microsoft: SN1MSG mixer.edge.messenger.live.com, la siguiente figura muestra una captura del tráfico mencionado: Fig Alerta de conexiones http con el servidor WEB. Alertas conocidas Algunas de las alarmas reportadas por la honeynet, se producen por conexiones con los servidores internos de la universidad. Una de las alarmas más insistentes se produce con el servidor DNS interno, siendo hasta ahí una conexión normal, aunque no se determina exactamente que produce que el servidor dns ubicado en la honeynet se conecte con su inmediato superior, aunque en algunas conexiones se muestra la petición de los servidores root: e.root-servers.net, es una conexión totalmente normal, pues hace la petición hacia un servidor raíz. Fig Alertas conocidas. 53

61 4.1.6 Resultados Los honeypots Web y Eva registraron intentos de conexión en algunos puertos como el 1068, 1074, 1066, entre otros, puertos que no están habilitados, con puerto origen el Estas conexiones contienen información de chat, correo electrónico, Id del usuario, la conversación entre los participantes del chat, estado del usuario, etc.el puerto 1863 es usado por el protocolo msnp (Microsoft Notification Protocol) de Microsoft, por medio del cual se envía información entre el cliente y el servidor de mensajería, actualmente existe la versión 18 [20] del protocolo. Esta conexión no representa peligro alguno, dado que las conexiones encontradas son retransmisiones de paquetes perdidos, ya que los comandos que se incluyen en el paquete capturado son asíncronos, del tipo, FLN, NLN, QNG, etc. Estos son retransmitidos por el servidor [21], ahora, no es normal, que esos paquetes lleguen a los honeypots, si no se usa ninguna tipo de mensajería instantánea, pero, los comandos asíncronos usados en msnp indican que son enviados sin tener previamente una petición del cliente y en los honeypots solamente se tienen este tipo de paquetes. Ahora, en principio se pensó que estas conexiones podrían haber sido generadas por el troyano 16 Bifrose.E [22] o alguna de sus variantes. Este malware se propaga vía Internet Explorer a través del puerto 1863, usa el mencionado puerto para dejar una puerta trasera abierta y permitir a un atacante ejecutar determinados comandos de forma remota. Se descartó su presencia ya que apareció solo en sistemas elaborados por Microsoft, y además como se mencionó previamente es una conexión normal. Otra de las conexiones que se analizaron fueron las conexiones que realizaba el honeypot DNS al servidor en producción de la universidad, como ya se explico previamente estas obedecían a tráfico normal ya que el honeypot DNS está configurado como servidor maestro. 16 Tipo de malware que permite abrir puertas traseras en los equipos. 54

62 Fase 4.2 Conclusiones Conclusiones generales La política de permisos implementada por la universidad es altamente efectiva, el tráfico que se genera en una vlan específica no llega a otras vlans salvo que existan los permisos. Se probó realizando escaneos de host y luego ataques de penetración a victimas de otras vlans pero en la mayoría de los casos la política de permisos dificultaba estas pruebas, además se registró todo en la honeynet y en los sensores de la universidad. Existen vlans donde los usuarios pueden conectar sus dispositivos sin problemas, las vlans asignadas para el internet inalámbrico son un claro ejemplo. En estos casos se puede propagar malware entre los equipos de la misma vlan, la política de permisos evita que se propague a otras vlans. Se realizaron pruebas y es posible realizar ataques entre los equipos de la misma vlan, como escaneos, ataques de penetración y explotamiento de vulnerabilidades, etc. El firewall implementado en cada honeypot resultó útil en este ambiente, así que podría tener el mismo efecto en cada servidor real contra ataques producidos solamente en la red interna, tomando en cuenta que la calidad técnica de las implementaciones reales es mayor y mucho más compleja, ya que algunos servidores reciben tráfico externo a parte del interno. No se debe colocar la honeynet en zona de servidores, así su uso sea interno, existe siempre la posibilidad de que un atacante penetre la red y tome el control, en ese caso, el peligro sobre los servicios críticos de la organización es inevitablemente alto y potencialmente nocivo ya que la honeynet virtual tiene mayor posibilidad de ser detectada por un atacante diestro. Es imperante definir correctamente las medidas de control a implementar en la honeynet, probar que estas funcionen, a fin de evitar que algún atacante tome el control sobre la honeynet. Si alguno de los equipos virtualizados llega a ser utilizado para atacar es muy probable 55

63 que un atacante muy hábil pueda tomar control de otros equipos en la vlan. Un ejemplo claro fue el problema que tuvo la honeynet virtual externa, las medidas de control de la honeynet fallaron, uno de sus honeypots fue vulnerado y posteriormente utilizado para crear problemas en los enlaces de la universidad. En esta investigación se presentó el problema de sobrecarga de tráfico desde los honeypots hacia la red ocasionado por una configuración errónea [Ver Anexo D]. Se debe tener claro que interfaz será de salida y que interfaz será de entrada, ambas interfaces deben estar activas y registrando tráfico. La implementación de la honeynet interna no fue del todo efectiva, debido a la poca cantidad de tráfico maligno registrado, la carencia de ataques en la red interna, la política de permisos y la poca flexibilidad de este tipo de honeynets, lo cuál dificultó la obtención de patrones específicos de comportamiento y de ataque. 56

64 4.2.2 Recomendaciones Sería útil ir rotando la honeynet por las distintas vlans del campus, exceptuando las vlans de servicios críticos, es decir ubicar la honeynet en un segmento temporalmente, hacer las respectivas copias de las configuraciones y analizar la información recolectada, terminado el tiempo asignado en ese segmento, moverla a otro y realizar el mismo proceso. Es muy probable que algunos equipos finales en alguna vlan específica estén infectados con malware y estén intentando propagarlo, la política de permisos puede evitar que el malware se propague a otros segmentos, pero evitar que infecte a otros equipos de la misma vlan sería una tarea tanto ardua como tediosa. La honeynet ayudaría a identificar el tráfico malicioso, aunque trabajaría simplemente como un IDS y la universidad ya cuenta con un sistema de detección implementado, por lo que pierde sentido el trabajo de la honeynet virtual. Considerar la posibilidad de implementar una honeynet híbrida 17, en el actual proyecto se dio un problema con el switch virtual, su configuración fué compleja y necesitó de constantes pruebas y mantenimiento. Como se detalla en [14], este tipo de honeynet permite usar más de 1 dispositivo además de aportar mayor seguridad y flexibilidad. Con esta opción se podría implementar otros servicios críticos, con mayor capacidad y recursos. Implementar una honeynet, de cualquier tipo, ubicando los honeypots en vlans diferentes. Sería óptimo realizar un estudio de factibilidad para analizar si es plausible realizar este esquema en la red de la universidad. En caso de que se pueda implementar, se podría capturar directamente tráfico de varias vlans en lugar de una sola, como se propone en este proyecto, con lo que se evitaría la rotación de la honeynet. 17 Combinación de Honeynet clásica y del software devirtual 57

65 4.2.3 Proyectos futuros Live CD La instalación de la honeynet actual se realiza en un solo equipo virtualizando los honeypots, la instalación de cada uno de estos, más que compleja es una tarea tediosa, se consume tiempo además de recursos. Es posible pensar en una idea propuesta por nuestra directora, la de crear un Live CD de la honeynet, por medio del cual se puedan instalar los honeypots con los servicios directamente además del módulo de sebek acortando tiempos de implementación. Wireless Honeynet Hasta ahora se han probado algunos tipos de honeynets, pero hasta ahora se ha enfocado hacia tecnologías wireless, existen pocos trabajos sobre este tipo de tecnología como el propuesto por The Spanish Honeynet Project [23].En la universidad existen diversas vlans que proporcionan acceso con esta tecnología, algunos de los equipos finales podría estar infectados con algún tipo de malware y este a su vez intentando propagarse, aquí cabe la posibilidad de usar una wireless honeynet para obtener toda esa información, aunque hay poca información al respecto. Honeytokens Un honeytoken es un tipo de honeypot según Lance Spitner [24], aunque este tipo trata de simular un componente y no un ordenador entero [25], entiéndase como componente a un , un documento, una cuenta de usuario, etc. Es decir recursos que no sean específicamente sistemas o servicios, pero que atraigan la atención de un atacante, Royer menciona por ejemplo el uso del honeytoken archivo, el cual puede ser algún documento que aparente tener información valiosa o que a ojos del atacante resulte atractivo, usando métodos como ponerle un nombre sugerente como: contraseñas.doc o un archivo pdf en un servidor web. Es decir es un tema que se acerca levemente a la ingeniería social y que puede ser utilizado como herramienta para obtener datos de los atacantes. Existen algunos trabajos en este tema, uno de estos propone 58

66 detectar por medio de un modulo honeytoken la actividad maliciosa que pudiese existir en una DMBS de Oracle 9i [26]. 59

67 ANEXOS 60

68 ANEXOS ANEXO A: Información de los servidores Los siguientes datos fueron proporcionados por los administradores, de este reporte se desprende la siguiente información: Tabla A1. Servidores de la UTPL 18 ID Server Servidor Administrador 1 ASTERISK Daniela Calva 2 ASTERISK-BACKUP Daniela Calva 3 ASUTPL Viviana Montaño 4 BASE RECURSOS HUMANOS Ruth Reátegui 5 BD-DESKTOP Rodrigo Patricio Lopez 6 BDDGDS Viviana Montaño 7 BDVIRTUAL Rodrigo Patricio Lopez 8 CA Julia Pineda 9 CAJANUMA Juan Carlos Morocho 10 CAJANUMA ANTIGUO Juan Carlos Morocho 11 CALSERVER Viviana Montaño 12 CATAMAYO Viviana Montaño 13 CESERVER Jorge Cordero Z. 14 CIPRE Ruperto Alexander López Lapo 15 DEVCRM Viviana Montaño 16 DEVSERVER Viviana Montaño 17 DEVSERVER.OLD Viviana Montaño 18 DIGITSERVER Viviana Montaño 19 EUCALIPTO Ruperto Alexander López Lapo 20 EVA Rodrigo Patricio Lopez 21 F-SECURE Janeth Alba 22 GDR1.UTPL.EDU.EC Ramiro Ramírez 23 GDR1BACK.UTPL.EDU.EC Diana Alexandra Torres Guarnizo 24 GDR2 Ruperto Alexander López Lapo 25 GDR3 Ruperto Alexander López Lapo 26 GDR3A Ruperto Alexander López Lapo 27 GDR3B Ruperto Alexander López Lapo 28 GDR4 Ruperto Alexander López Lapo 29 GDR4A Ruperto Alexander López Lapo 30 GDR5 Ruperto Alexander López Lapo 31 GDR7 Ruperto Alexander López Lapo 32 HOSPITAL UTPL Jenny Maria Cuenca 33 INGLES José Manuel Ochoa 34 INTRANETCITTES Ana Lucia Abad 35 IVR Carina Jaramillo 36 LEXIS E IMPRESIONES Janeth Alba 37 MONITOREO Carlos Aguilar M. 38 MX1 Ruperto Alexander López Lapo 39 MX2 Ruperto Alexander López Lapo 40 NOCAT Daniela Calva 18 Investigado a Mayo del

69 41 NODO1SGA Viviana Montaño 42 NTS01 Danilo Jaramillo H 43 OSSIM Julia Pineda 44 PALTAS Juan Carlos Morocho 45 PANECILLO Juan Carlos Morocho 46 PDCSERVER Viviana Montaño 47 PODCASTSERVER.UTPL.EDU.EC Greyson Alberca 48 PRESENTATION SERVER Rodrigo Barba 49 PRODUCCION Rodrigo Barba 50 REPO Ruperto Alexander López Lapo 51 SERVERHOSPITAL Jenny Maria Cuenca 52 SIGSERVER Víctor González 53 SOLCA Viviana Montaño 54 SUNBLADE1 Juan Carlos Morocho 55 SUNBLADE2 Juan Carlos Morocho 56 TIVOLI Janeth Alba 57 TSTSERVER Viviana Montaño 58 TSTVLEE Daniel Irene 59 ULOJA Juan Pablo Ureña Torres 60 VC GRABADOR Rodrigo Barba 61 VIDEOCONTV Rodrigo Barba 62 VIEWER Julia Pineda 63 VILLONACO Juan Carlos Morocho 64 VLEE Daniel Irene 65 VPN Julia Pineda 66 WEBMAIL Ruperto Alexander López Lapo 67 WSUTPL Viviana Montaño 68 CasaLojana Viviana Montaño 62

70 ANEXO B: Vulnerabilidades Acorde al sistema operativo, utilizado en cada servidor y a las aplicaciones montadas se han encontrado entre los más comunes los siguientes problemas: Vulnerabilidades en Oracle 10G En este sitio web [16] se encontrarán algunos exploits que se pueden utilizar para vulnerar el gestor de base de datos de Oracle, además información de los parches, los exploits están actualizados hasta julio del Vulnerabilidad de envenenamiento de cache en Bind Vulnerabilidad publicada en el 2007[17], afecta a las versiones 9.0 aunque no son vulnerables las versiones: BIND P1, BIND P1, BIND P1 or BIND 9.5.0a6 Vulnerabilidad producida por el incorrecto uso del comando de recarga rndc Esta es una vulnerabilidad reinsertada en bind, apareció originalmente como un bug en Red Hat 4[18], aunque fue resuelta volvió aparecer en las versiones de Centos 5, afectando también a la versión 4[19]. Vulnerabilidad por direcciones bien conocidas en openssh Es una vulnerabilidad que afecta a la versión libre del protocolo seguro, apareció en una versión de la distribución Red Hat Enterprise 4, aunque es de baja severidad [27]. Otras vulnerabilidades conocidas Vulnerabilidad en bind 9.3: DoS Vulnerabilidad en bind 9.3: Desbordamiento de Buffer, DoS Vulnerabilidad en OpenLdap 9.3: DoS Vulnerabilidad en Apache 2: DoS Vulnerabilidad en Apache 2: XSS Vale aclarar que las vulnerabilidades antes enunciadas no son todas las conocidas, pero si las más comunes encontradas para las versiones específicas del software utilizado en los servidores a implementar, esta información a sido extraída de variadas fuentes, aunque se puede obtener detalles técnicos más explicados en Milw0rm 19 una base de datos de exploits que permite descargar incluso el código fuente que produce estos bugs. 19 Milw0rm: Base de datos de vulnerabilidades (Descontinuada). Exploit-db es su sucesora. 63

71 ANEXO C: Encuesta PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos internos de la UTPL El presente documento tiene como objetivo recabar información necesaria para la realización de este proyecto de tesis, sírvase usted responder las siguientes cuestiones con la mayor precisión posible. SERVIDOR Nombre: Dirección IPv4 Privada: Dirección IPv6: Ubicación en la red de producción: El servidor se encuentra en producción: SI( ) NO( ) A que dependencia pertenece: Como cataloga el nivel de criticidad del servidor Alto( ) Medio( ) Bajo( ) Nivel de Importancia si el servidor/servicio falla: Alto( ) Medio( ) Bajo( ) Número total aproximado de usuarios del servidor: Interactúa con otros sistemas? SI( ) NO( ) Cuáles? Equipo: - N de procesadores: - - Tipo Procesador: - - Memoria (GB): - - Disco (GB): Según su criterio, Son estas características las apropiadas para los servicios que proporciona el servidor? SI ( ) NO ( ) Por que? 64

72 Sistema operativo: o o o Distribución: Versión: Kernel: Fecha de la útima actualización: Tiene algún firewall activado: Servicio: - Indique los servicios que se encuentran implementados en el servidor, la versión y los puertos utilizados por cada servicio: o Última vez que parchó/actualizo: - Lleva un registro de los ataques conocidos a su servidor? SI () NO () Si la respuesta anterior fue negativa, describa la razón: o Promedio de ataques (semanales): < 10 < 100 < 500 > 500 < 1000 No tiene idea Administrador 65

73 ANEXO D: Configuración errónea de honeywall INUNDACIÓN DE PAQUETES La inundación de paquetes DHCP Request es provocado por el Honeywall, cuando este se levanta comienza a enviar una gran cantidad de estos paquetes dirigidos al gdr4.utpl.edu.ec y el gateway de la vlan asignada empieza también a incrementar su tráfico de salida con dirección al host anfitrión, esta inundación de paquetes provoca que la red empiece a colapsar, llegando incluso a los 8MB/s de datos transmitidos por la interfaz eth0, ocupando al servidor proxy con las peticiones dhcp. Este problema se presentó cuando las dos interfaces utilizadas para la captura estaban en modo bridge y también cuando se intercambiaban las interfaces. Fig D1. Se muestra el tráfico normal cuando subitamente pasa de 1.89KB/s hasta alcanzar los 7.86MB/s 66

74 Fig D2. El ancho de banda se mantiene en un promedio de 4.8 MB/s Fig D3. La cantidad de tráfico de salida aumentó a un promedio de 3.39 MB/s. Aunque como se podrá notar en las gráficas, el tráfico de salida disminuye paulatinamente hasta llegar a un promedio en el cual se mantiene estable, el efecto que tiene esta inundación es que las otras máquinas conectadas a la vlan empiezan a tener problemas de conexión perdiendola parcial o totalmente. 67

75 Fig D4. Muestra la cantidad de tráfico de salida y el protocolo q más cantidad de peticiones Muestras extraídas con Etherape respuestas registra. Fig D5. Esta es una captura del analizador de tráfico con interfáz gráfica Etherape, la cual muestra que en la red existen solo dos direcciones en funcionamiento y la línea da un indicio del tráfico que están transfiriendo. Fig D6. Traza de tráfico desde el origen hacia el destino. 68

76 Fig D7. Traza de tráfico desde el origen hacia el destino, causado por configuración errónea. 69

77 ANEXOE Instalación de apache2 Se usará la versión que viene incluída en Gutsy Gibbon, con los siguientes comandos: root://aptitude search apache2 root://apt-get install apache2 Este comando realizará la instalación y configuración defecto automática de apache2 y las librerías necesarias. ANEXO F: Instalación de Webmin Herramienta utilizada para administrar servidores, permite configurar archivos de configuración, usuarios, cuotas de espacio, servicios, apagado del equipo, además, permite modificar y controlar muchas servicios como apache, php, mysql, dns, samba, dhcp, etc. Escrito en PERL 20 se comunica por defecto por el puerto además de poder configurar para ser administrado via SSL. En el servidor se obtuvo la versión web1.3.7, se instalan previamente las librerías necesarias, como perl, libnet-ssleay-perl, openssl, libauthen-pam-perl, libpamruntime, libio-pty-perl y libmd5-perl. Se descarga las librerías y se instala de la siguiente forma: root://apt-get install perl /Si es que no está instalado root://dpkg -i libnet-ssleay-perl_1.30-1_i386.deb root://dpkg -i openssl-0.9.6m-3.i386.deb Fig F1 Instalación de openssl root://dpkg -i libauthen-pam-perl_0.16-1_i386.deb 20 PERL, disponible en consultado a 15 de Julio del

78 Fig F2. Instalación de librería libauthen-pam-perl root://dpkg -i libpam-runtime_ ubuntu6_all.deb Fig F3. Instalación con comando dpkg de librería libpan-runtime root://dpkg -i libio-pty-perl_1.07-1_i386.deb Fig F4. Instalación con comando dpkg de librería libio-pty-perl root://dpkg -i libmd5-perl_2.03-1_all.deb Fig F5. Instalación con comando dpkg de librería libmd5-perl Ahora que ya se instalaron las librerías necesarias, se procede a instalar Webmin 21, primero se descarga el archivo desde sourceforge, luego se procede a la instalación: root://dpkg -i webmin_1.370_all.deb 21 Webmin installer, disponible en cosultado a 13 de Julio del

79 Fig F6. Instalación con comando dpkg de webmin Fig F7. Instalación con comando dpkg de webmin La figura última superior nos indica que ahora ya se puede conectar a webmin, a través del puerto como usuario root con la contraseña del usuario mencionado. Pruebas de webmin En un navegador se ingresa al servicio ubicando en la barra de navegación la dirección ip del servidor y el puerto en el que se ha configurado webmin: Fig F8. Pantalla de autenticación de webmin Se ingresa el usuario root y la contraseña del mismo para acceder al sitio de administración de los servicios: Fig F9. Características generales del equipo mostradas por webmin 72

80 Fig F10. Servidores que pueden ser administrados por medio de webmin 73

81 ANEXO H: Instalación de moodle En primer lugar se accede a la página principal del moodle 22 una vez que se ha escogido la versión adecuada, respecto al S.O. que se tiene, en este caso Linux, y se descarga el instalador. Fig H1. Versión de descarga desde el sitio oficial de moodle Luego de esto, se desempaqueta el archivo descargado en el directorio adecuado, donde se alojan las páginas web. Luego se accede desde el navegador, y se ubica la url: Se aplica Enter y con esto empieza la instalación: Fig H2. Inicio de instalación de moodle Fig H3. El instalador de moodle comprueba la compatibilidad con php. En la siguiente pantalla se muestra la Dirección Web, el Directorio Moodle y el Directorio de Datos, en caso de no existir dicho directorio, hay que crear tal directorio en el Servidor

82 Fig H4. Confirmar las direcciones de instalación Ahora, se configura los datos de la conexión con la base de datos Mysql: Fig H5. Ingresar los parámetros de instalación de MySQL Fig H6. Parametros de configuración ingresados 75

83 Ahora, se comprueban los componentes del servidor: Fig H7. Comprobaciones del servidor Configuración del Idioma, click en Descargar el paquete de idioma Español Internacional (es) : Fig H8. Nos pedirá descargar el paquete de idioma que nos convenga En el caso que no se pueda descargar tal paquete de idioma, hay que 23 descargarlo, descomprimirlo y copiarlo en el directorio /home/moodledata/lang : Fig H9. Este error se produce al intentar descargar el paquete de idioma, al no haber conexión

84 El siguiente paso es la configuración del archivo principal: config.php: Se selecciona el Idioma: Fig H10. Se muestra el fichero de configuración php Fig H11. Se escoge el idioma que se utilizará Fig H12. Comprobación de ajustes. 77

85 Fig H13. Moodle instalado y listo para configurarlo Configuraciones de la cuenta del Administrador. Es necesario cambiar el password: Fig H14. Configuraciones de administración. Ahora, se configura el nombre que llevará el sitio: Fig H15. Se configura el nombre del sitio y descripciones del mismo. Luego de todo el proceso, se muestra una captura de la pantalla principal: 78

86 Fig H15. Características generales del equipo mostradas por webmin Fig H16. Confirmación de configuraciones. Servidor Web Apache El servidor HTTP Apache es un servidor webhttp de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 Para poder instalar hacer funcionar el servidor, es necesario instalar el apache2, para ello, mediante una consola, se procede: root@tesis-desktop:/etc/bind# apt-get install apache2 Luego de haber realizado este paso, se comprueba que efectivamente se ha instalado apache en nuestro sistema; desde otro equipo se abre un navegador y en la url se ubica la dirección de nuestro servidor local. Es decir, poner la dirección IP de la máquina en la que se instaló apache: 79

87 Fig H17. Sitio donde se ha instalado apache2. 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 continuación: Fig H18. Prueba de que el servidor trabaja. 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 configuración default que se encuentra en la siguiente ruta: /etc/apache2/sites-available Cada vez que se realice alguna modificación o cambio es necesario reiniciar apache con cualquiera de las siguientes maneras: - root@tesis-desktop:/etc/bind# /etc/init.d/apache2 restart ó con el comando: - root@tesis-desktop:/etc/bind# apache2ctl restart Motor de Base de Datos Mysql y PHP Para dotar a Apache de la funcionalidad de manejar páginas php se debe instalar el paquetephp5. root@tesis-desktop:/etc/bind# aptitude install php5 Para verificar la correcta instalación y funcionamiento de php, se crea un fichero y lo edita: 80

88 nano /var/www/test.php en el fichero le colocas lo siguiente <?php phpinfo();?> Reiniciar apache restart Se prueba el funcionamiento ubicando en el navegador la siguiente dirección: Se presenta una pantalla así: Fig H19. Comprobación de funcionamiento de php Instalación de algunos paquetes necesarios: apt-get install mysql5-server apt-get install libapache2-mod-auth-mysql apt-get install mysql5-mysql Instalación de phpmyadmin phpmyadmin es una herramienta libre escrita en PHP con la intención de manejar la administración de MySQL a través de páginas web, utilizando Internet con interfaz gráfica muy útil para gestionar las bases de datos. root@tesis-desktop:/etc/bind# apt-get install phpmyadmin 81

89 Para poder ser uso de esta herramienta, desde otra máquina se ubica la url se obtendrá la ventana para el respectivo logueo: Fig H20. Pantalla de autenticación de phpmyadmin Fig H21. Pantalla desde donde se pueden gestionar bases de datos MySQL. 82

90 ANEXO I: Definición de reglas de firewall DEFINICIÓN DE REGLAS DE FIREWALL Se creará un script donde se ubicaran las reglas de acuerdo a las especificaciones de cada servidor, ese script contendrá todas las reglas que sean utiles, ese script será ejecutado cada vez q sea necesario. Configuración de protocolo de administración remota ssh Se deshabilitó el logueo del usuario root vía ssh en todos los servidores que tienen el servicio levantado, además se permitirá la administración remota solo en los servidores que realmente utilicen el servicio. Servidor DNS El servidor DNS tiene el firewall IPTABLES implementado, este servidor solamente permite el acceso a servicios de administración vía SSH y al servicio DNS, por lo que las reglas de firewall se configuraron acorde a estos parámetros, aunque también se habilitó el intercambio de paquetes entre el servidor utilizado para forward y se cerraron los puertos bien conocidos que no son utilizados en este servidor: #!/bin/bash iptables -F INPUT iptables -F OUTPUT # Trà fico loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #Permitir conexion con servidor dns iptables -A INPUT -p tcp -s /24 --dport 53 -j ACCEPT iptables -A INPUT -p udp -s /24 --dport 53 -j ACCEPT iptables -A OUTPUT -p tcp --sport 53 -d /24 --dport 1024: -j ACCEPT iptables -A OUTPUT -p udp --sport 53 -d /24 --dport 1024: -j ACCEPT #Permitir las salidas de forward iptables -A OUTPUT -p tcp -d dport 53 -j ACCEPT iptables -A OUTPUT -p udp -d dport 53 -j ACCEPT iptables -A INPUT -p tcp -s dport 53 -j ACCEPT iptables -A INPUT -p tcp -s dport 53 -j ACCEPT #Permitit ssh iptables -A INPUT -p tcp -s /24 --dport 22 -j DROP iptables -A OUTPUT -p tcp --sport 22 -d /24 -j DROP iptables -A INPUT -p tcp -s /16 --dport 22 -j REJECT iptables -A OUTPUT -p tcp --sport 22 -d /16 -j REJECT #Cerrar los rangos de puertos bien conocidos 83

91 iptables -A INPUT -s 0/0 -p tcp --dport 1:1024 -j DROP iptables -A INPUT -s 0/0 -p udp --dport 1:1024 -j DROP iptables -A OUTPUT -p tcp -d 0/0 -j DROP iptables -A INPUT -p tcp -s 0/0 -j DROP iptables -A OUTPUT -p udp -d 0/0 -j DROP iptables -A INPUT -p udp -s 0/0 -j DROP 84

92 Servidor BAAN El servidor BAAN no tiene implementado un firewall, aunque las aplicaciones Oracle 10 G Enterprise y Baan ERP 5.0c levantan los puertos 1521 y 512 respectivamente. Debido a que no se pudo instalar ninguno de los 2 servicios en la máquina virtual usada, debido a la limitación de sebek y al ser los dos servicios de licencia privada, se levanta el firewall IPTABLES para abrir los puertos antes mencionados, se permite también el intercambio de paquetes con el servidor DNS y se cerraron los puertos conocidos que no son utilizados por el servidor: #!/bin/bash iptables -F INPUT iptables -F OUTPUT # Trà fico loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #Permitir conexion con servidor dns iptables -A INPUT -p tcp -s sport 53 -j ACCEPT iptables -A INPUT -p udp -s sport 53 -j ACCEPT iptables -A OUTPUT -p tcp -d dport 53 -j ACCEPT iptables -A OUTPUT -p udp -d dport 53 -j ACCEPT #Permitir conexiones a puertos 512 y 1521 iptables -A INPUT -p tcp -s dport 512 -j ACCEPT iptables -A INPUT -p tcp -s dport j ACCEPT iptables -A OUTPUT -p tcp --sport 512 -d j ACCEPT iptables -A OUTPUT -p tcp --sport d j ACCEPT #Permitir ssh iptables -A INPUT -p tcp -s /16 --dport 22 -j DROP iptables -A OUTPUT -p tcp --sport 22 -d /16 -j DROP #iptables -A INPUT -p TCP -s /24 --dport 22 -j DROP #iptables -A OUTPUT -p TCP --sport 22 -d /24 -j DROP #Cerrar los rangos de puertos bien conocidos iptables -A INPUT -s 0/0 -p tcp --dport 1:1024 -j ACCEPT iptables -A INPUT -s 0/0 -p udp --dport 1:1024 -j ACCEPT #1101 iptables -A OUTPUT -p udp --sport d 0/0 -j ACCEPT iptables -A INPUT -p udp --dport j DROP #Denegar todo trã fico hacia internet iptables -A INPUT -p tcp -s 0/0 -j DROP iptables -A OUTPUT -p tcp -d 0/0 -j DROP iptables -A INPUT -p udp -s 0/0 -j DROP iptables -A OUTPUT -p udp -d 0/0 -j DROP 85

93 Servidor EVA El Entorno Virtual de Aprendizaje utiliza los servicios de Apache y Tomcat, el primero no tuvo ningún reparo al ser instalado, mientras que el segundo no está instalado por problemas de dependencia con el Ubuntu Server, de todas formas se abrió el puerto, se habilitaron los puertos 80 y 8080 además de permitir el envío y recepción de paquetes dns y cerrar los puertos que no son utilizados en el servidor: #!/bin/bash iptables -F INPUT iptables -F OUTPUT # Trà fico loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #Permitir conexiones con el dns iptables -A INPUT -p tcp -s sport 53 -j ACCEPT iptables -A INPUT -p udp -s sport 53 -j ACCEPT iptables -A OUTPUT -p tcp -d dport 53 -j ACCEPT iptables -A OUTPUT -p udp -d dport 53 -j ACCEPT #Permitir acceso a puertos 80 y 8080 iptables -A INPUT -p tcp -s /24 --dport 80 -j ACCEPT iptables -A INPUT -p tcp -s /24 --dport j ACCEPT iptables -A OUTPUT -p tcp --sport 80 -d /24 -j ACCEPT iptables -A OUTPUT -p tcp --sport d /24 -j ACCEPT #Permitir conexion con el servidor web iptables -A INPUT -p tcp -s dport 80 -j ACCEPT iptables -A OUTPUT -p tcp -d dport 80 -j ACCEPT #Permitir ssh #iptables -A INPUT -p tcp -s /24 --dport 22 -j ACCEPT #iptables -A OUTPUT -p tcp --sport 22 -d /24 -j ACCEPT iptables -A INPUT -p tcp -s /16 --dport 22 -j REJECT iptables -A OUTPUT -p tcp --sport 22 -d /16 -j REJECT #Cerrar los rangos de puertos bien conocidos iptables -A INPUT -s 0/0 -p tcp --dport 1:1024 -j ACCEPT iptables -A INPUT -s 0/0 -p udp --dport 1:1024 -j ACCEPT iptables -A OUTPUT -p tcp -d 0/0 -j DROP iptables -A INPUT -p tcp -s 0/0 -j DROP iptables -A OUTPUT -p udp -d 0/0 -j DROP iptables -A INPUT -p udp -s 0/0 -j DROP 86

94 Servidor WEB El servidor web de la utpl si utiliza un firewall, aunque la aplicación cmaps no pudo ser instalada se abrió el puerto, además se permitió el acceso a los servicios web, ssh, ftp, se permite la comunicación con el servidor EVA además con el Webmin para la administración del servidor y finalmente se cerraron los puertos que no son utilizados: #!/bin/bash iptables -F INPUT iptables -F OUTPUT #Permitir conexion con servidor dns iptables -A INPUT -p tcp -s sport 53 -j ACCEPT iptables -A INPUT -p udp -s sport 53 -j ACCEPT iptables -A OUTPUT -p tcp -d dport 53 -j ACCEPT iptables -A OUTPUT -p udp -d dport 53 -j ACCEPT #Permitir conexiã³n entrantes a puerto 80 iptables -A INPUT -p tcp -s /16 --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --sport 80 -d /16 -j ACCEPT #Permitir conexiã³n entrantes a puerto 22 iptables -A INPUT -p TCP -s /24 --dport 22 -j ACCEPT iptables -A OUTPUT -p TCP --sport 22 -d /24 -j ACCEPT iptables -A INPUT -p tcp -s /16 --dport 22 -j REJECT iptables -A OUTPUT -p tcp --sport 22 -d /16 -j REJECT #Permitir conexion con servidor EVA iptables -A INPUT -p tcp -s dport 80 -j ACCEPT iptables -A OUTPUT -p tcp -d dport 80 -j ACCEPT #Permitir ftp iptables -A INPUT -p tcp -s /24 --dport 21 -j ACCEPT iptables -A OUTPUT -p tcp --sport 21 -d /24 -j ACCEPT #Permitir administraciã³n con WEBMIN iptables -A INPUT -p tcp -s /24 --dport j ACCEPT iptables -A OUTPUT -p tcp --sport d /24 -j ACCEPT #Se abren los puertos de CMAP iptables -A INPUT -s /16 -p tcp --dport j ACCEPT iptables -A INPUT -s /16 -p tcp --dport j ACCEPT iptables -A INPUT -s /16 -p tcp --dport j ACCEPT iptables -A INPUT -s /16 -p tcp --dport j ACCEPT iptables -A OUTPUT -p tcp --sport d /16 -j ACCEPT iptables -A OUTPUT -p tcp --sport d /16 -j ACCEPT iptables -A OUTPUT -p tcp --sport d /16 -j ACCEPT iptables -A OUTPUT -p tcp --sport d /16 -j ACCEPT #1101 iptables -A OUTPUT -p udp --sport d 0/0 --dport j ACCEPT 87

95 #Cerrar los rangos de puertos bien conocidos iptables -A INPUT -s 0/0 -p tcp --dport 1:1024 -j DROP iptables -A INPUT -s 0/0 -p udp --dport 1:1024 -j DROP iptables -A OUTPUT -p tcp -d 0/0 -j REJECT iptables -A INPUT -p tcp -s 0/0 -j REJECT iptables -A OUTPUT -p udp -d 0/0 -j REJECT iptables -A INPUT -p udp -s 0/0 -j DROP iptables -A OUTPUT -p icmp -d! /16 -j DROP PRUEBAS Ahora ya con los servidores con las iptables instaladas se procede a probar si efectivamente estas funcionan correctamente, es decir que se realiza el envío y recepción de tráfico normalmente, así que se realizaron las siguientes pruebas: (1) Probar que las reglas se están utilizando (1) Listar las reglas de firewall con iptables -L (2) Desde uno de los servidores pedir la resolución de nombres de todos los servidores (1) Pedir la resolución de eva, www, baan y dns del dominio utpl.ed.ec (3) Hacer una prueba de conexión a dirección externas (1) Hacer ping a Google y a la UNL. Captura de pantalla de las reglas de firewall aplicadas al servidor Baan. Fig I1. Firewall iptables en funcionamiento. 88

96 Se realizó una prueba entre el servidor dns y el servidor eva, este último intenta pedir los nombre de el resto de los servidores y el suyo utilizando el comando host <nombrehost>, esta petición Fig I2. Peticiones de resolución de nombres al servidor DNS de la honeynet con el firewall en funcionamiento. Esta captura muestra al servidor WEB intentando hacer ping a la dirección teniendo un resultado efectivo. Fig I3. Peticion de ping a dirección externa, aunque luego se deshabilita la salida a internet en todos los honeypots Captura en la que se muestran 3 servidores con las reglas de firewall ya implementadas, el servidor DNS, el servidor EVA y el servidor WEB, estos dos últimos intentan hacer ping a una dirección externa usando el nombre del dominio. Este resultado muestra que las reglas de firewall implementadas en el servidor DNS para conectarse con su servidor de más alto nivel o forwarder se han configurado correctamente. 89

97 Fig I4. Resolución de nombre del servidor DNS ANEXO J Instalación de BIND9 y librerias necesarias Se descarga el archivo bind i386.rpm y se transforma con alien a un formato.deb para poder instalar: root@tesis-desktop:# alien -d bind i386.rpm Lo cual produce un archivo denominado bind_ _i386.deb el cual si puede ser inslado, para tal efecto se hace lo siguiente: root@tesis-desktop:# dpkg -i bind_ i386.deb Instalando Bind-utils, bind-libs y openssl librerias necesarias para el funcionamiento de BIND9 root@tesis-desktop:# dpkg -i bind-utils_ _i386.deb root@tesis-desktop:# dpkg -i bind-libs_ _i386.deb root@tesis-desktop:# dpkg -i openssl_0.9.6m-4_i386.deb 90

98 ANEXO K Configuración de BIND9 Ahora se procede a configurar el archivo named.conf.local donde se nombra las 'zonas' o dominios que se van a administrar: root@tesis-desktop:/etc/bind# nano named.conf.local // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; zone "utpl.com" { type master; file "/etc/bind/utpl.com.b"; }; zone " in-addr.arpa"{ type master; file "/etc/bind/192.rev"; }; Ahora se crea la carpeta 'zones' que es donde se ubicaran todos los dominios, además se crean los dominios especificados en name.conf.local: root@tesis-desktop:/etc/bind# mkdir zones root@tesis-desktop:/etc/bind# cd zones/ root@tesis-desktop:/etc/bind/zones# nano utpl.com utpl.com ; ; BIND data file for utpl IN SOA utpl.com. root.utpl.com. ( 1 ; Serial ; Refresh ; Retry ; Expire ) ; Default TTL IN NS dns.utpl.com IN MX 10 dns.utpl.com www IN A dns IN A eva IN A

99 baan IN A rev ; ; BIND reverse data file for utpl IN SOA utpl.com. root.utpl.com. ( 1 ; Serial ; Refresh ; Retry ; Expire ) ; Default TTL IN NS dns.utpl.com. 101 IN PTR IN PTR dns.utpl.com 103 IN PTR eva.utpl.com 104 IN PTR baan.utpl.com El siguiente paso consiste en configurar el archivo resolv.conf en el que se indicará el dominio de búsqueda y el nombre del servidor: root@tesis-desktop:/etc/bind# nano /etc/resolv.conf search utpl.com nameserver Este servicio está configurado como servidor DNS maestro, igual que el servicio real, así que en el archivo named.conf.options se configura el servidor de nivel superior a donde se consultará por direcciones desconocidas. root@tesis-desktop:/etc/bind# nano named.conf.options options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you might need to uncomment the query-source // directive below. Previous versions of BIND always asked // questions using port 53, but BIND 8.1 and later use an unprivileged // port by default. // query-source address * port 53; // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. 92

100 forwarders { ; }; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; Se reinicia el servicio: root@tesis-desktop:/etc/bind# /etc/init.d/bind9 restart FIG K1. Reiniciar bind Ahora se realiza la prueba del funcionamiento del servidor: root@tesis-desktop:/etc/bind# dig utpl.com Fig K2. Consulta del dominio de la honeynet. Instalaciónde ssh El servidor también utiliza para su administración remota SSH, aunque en la máquina virtual se utiliza openssh, así que se procede a su instalación: root@tesis-desktop:/etc/bind# apt-get install openssh-server openssh-client 93

101 ANEXO L 1. INSTALACIÓN DEL HONEYWALL. 1.1 Cambiar la secuencia de arranque del computador para que inicie con el CD. 1.2 Inserte el CD del Honeywall. 1.3 Presione Enter. Fig L1. Pantalla de inicio de instalación de honeywall 1.4 Seguidamente se inicia con el formateo y copiado de archivos necesarios. Fig L2. Progreso de instalación - Formateo 94

102 Fig L3. Progreso de instalación Transferencia de archivos. 1.5 Inicio del proceso de instalación. Fig L4. Inicio de instalación. 1.6 Luego de finalizar la instalación retire el CD y presione Enter. 2. ACCESO AL SISTEMA. Para ingresar a la administración como usuario, root, obligadamente se debe iniciar antes como usuario roo, la contraseña para estos usuarios es honey por defecto. Fig L5. Accediendo al sistema 95

103 3. CONFIGURACIÓN DE LAS VARIABLES. 3.1 Iniciar la configuración ingresando al directorio dlg y ejecutando la aplicación./dialogmenu.sh. 3.2 En el menú principal, seleccionar la opción 4: Honeywall Configuration, para iniciar las configuraciones. Fig L6. Menu principal: Configuración Honeywall. Fig L7. Configuración inicial. 3.3 En el método de configuración inicial se tienen tres opciones: FLOPPY: El Honeywall permite cargar configuraciones existentes almacenadas en un disquete. DEFAULTS: Se cargan las configuraciones por defecto. INTERVIEW: Elegir si se va a configurar por primera vez. 96

104 Fig L8. Método de configuración inicial. 3.4 Se recomienda leer el documento Know your enemy: Honeynets. Fig L9. Mensaje de inicio de configuración inicial 3.5 Ingrese las direcciones IP s de todos los Honeypots, separadas por un espacio. Fig L10. Ingreso de direcciones IP. 97

105 3.6 Ingrese la Red que se va a utilizar en la Honeynet. Fig L11. Ingreso de la red. 3.7 Ingrese la dirección de Broadcast correspondiente a la red de la Honeynet. Fig L12. Ingreso de la dirección de broadcast 3.8 Configuración de la interfaz de administración remota. Fig L13. Configuración de interfaz de administración. 98

106 3.9 Ingresar el nombre de la interfaz, por defecto se elige la eth2. Fig L14. Ingreso del nombre de la interfaz. Fig 15. Confirmación de interfaz Ingrese la dirección IP para la interfaz de administración, esta dirección se utiliza para conectarse remotamente y tener acceso a la interfaz web que servirá para monitorear la activad de la Honeynet. Fig L16. Ingreso de dirección IP, interfaz de administración. 99

107 3.11 Ingrese la máscara de red para la interfaz de administración. Fig L17. Ingreso de mascara de red, interfaz de administración 3.12 Ingrese la dirección Gateway para la interfaz de administración. Fig L18. Ingreso de Gateway, interfaz de administración Elija un nombre para su sistema. Fig L19. Ingreso del hostname, interfaz de administración. 100

108 3.14 Ingrese la dirección del servidor DNS; si posee más de una dirección debe escribirlos separados por un espacio. Fig L20. Ingreso de IP(s) del servidor DNS, interfaz de administración Confirme la activación de la interface de administración. Fig L21. Confirmación de interface, interfaz de administración. 4. CONFIGURACIÓN SSH. 4.1 Confirme el mensaje de que desea configurar SSH. Fig L22. Confirmación para la configuración de SSH. 101

109 Fig L23. Confirmación para permiso remoto. 5. CAMBIAR EL PASSWORD DE LOS USUARIOS. 5.1 Es necesario cambiar las contraseñas que trae por defecto el sistema Honeywall, el administrador debe elegir una contraseña más segura. Fig L24. Confirmación de cambio de password. Fig L25. Ingreso de nuevo password. 102

110 Fig L26. Confirme el password ingresado. Fig L27. Confirmación de password cambiado. 5.2 Ingrese una lista de puertos TCP permitidos para la interfaz de administración, por defecto está incluido SSH. Fig L28. Ingreso de puertos TCP. 103

111 5.3 Ingrese el rango de direcciones IP que pueden tener acceso a la administración. Fig L29. Ingreso de rango de direcciones IP. 5.4 Elija yes para habilitar la interfaz web de administración. Fig L30. Confirmación para habilitar interfaz web. 5.5 Confirme las restricciones al firewall. Fig L31. Confirmación para restricciones de firewall. 104

112 5.6 Ingrese la lista de puertos TCP necesarios de salida. Fig L32. Ingreso de puertos permitidos TCP para salida. 5.7 Ingrese la lista de puertos UDP necesarios de salida. Fig L33. Ingreso de puertos permitidos UDP para salida. 5.8 Ha finalizado la 2da sección de la configuración del sistema Honeywall. Fig L34. Confirmación de finalizar la 2da sección. 105

113 6. CONFIGURACIÓN DEL LÍMITE DE CONEXIONES PERMITIDAS. 6.1 Se especifica el límite de conexiones por unidad de tiempo (segundo, minuto, hora, día y mes) y también por protocolos. Fig L35. Especificación del límite de conexiones. Fig L36. Especificación del límite de conexiones: TCP. Fig L37. Especificación del límite de conexiones: UDP. 106

114 Fig L38. Especificación del límite de conexiones: ICMP Fig L39. Especificación del límite de conexiones para otros protocolos. 6.2 Elija yes para habilitar la aplicación snort_inline. Fig L40. Confirmación para habilitar snort_inline. 107

115 6.3 Indicar el archivo que contiene la lista negra blacklist (direcciones IPs que generan Spam). Elija OK y presione Enter. Fig L41. Archivo Blacklist 6.4 Indicar el archivo que contiene las direcciones IPs, fijadas por el usuario, que no deben ser detectadas ni consideradas como Spam. Elija OK y presione Enter. Fig L42. Archivo Whitelist. 6.5 Habilitar el filtrado para las listas (Black White). Elija yes y presione Enter. Fig L43. Filtrado listas (Black - White) 6.6 Elegir la opción no para habilitar el filtrado seguro durante la captura de paquetes. 108

116 Fig L44. Filtrado seguro. 7. CONFIGURACIÓN DE FENCELIST. 7.1 FENCELIST: La finalidad de este fichero es para configurar IPTABLES para registrar y bloquear tráfico de salida hacia otros equipos o redes. Indique la ruta del directorio donde se encuentra el fichero y elija OK. Fig L45. Fencelist 7.2 Es necesario habilitar el filtradofencelist, elija Yes. Fig L46. Filtrado Fencelist 7.3 ROACH MOTEL:A través de este modo, un atacante podría detectar fácilmente el Honeywall y atacarlo posteriormente, es por ello que esta opción debe ser deshabilitada. Elija la opciónno. 109

117 Fig L47.Modo Roach Motel. 7.4 Confirme el mensaje de haber finalizado la 3ra sección de la configuración del sistema Honeywall. Fig L48. Finalización de la 3ra sección de configuraciones. 8. CONFIGURACIÓN DE DNS. 8.1 Habilitar los accesos ilimitados de los Honeypots al servidor DNS. Fig L49. Acceso a DNS ilimitados de los Honeypots. 110

118 8.2 Habilitar la restricción de accesos ilimitados de los Honeypots hacia servidores DNS externos. Fig L50. Acceso DNS ilimitados. Honeypot Servidores. 8.3 Ingrese los Honeypots que accederán a servidores DNS externos. Fig L51. Honeypots que pueden acceder a servidores DNS. 8.4 Habilitar la restricción del servidor DNS a ser utilizado para accesos ilimitados. Fig L52. Restringir servidor DNS. 111

119 8.5 Ingrese la dirección IP del servidor DNS. Fig L53. Ingreso de dirección del servidor DNS. 9. CONFIGURACIÓN DE ALERTAS. 9.1 Habilite la entrega de alertas por . Fig L54. Configuración de alertas por Ingrese la dirección de correo electrónico donde se deben enviar las alertas. Fig L55. Ingreso de dirección de correo. 112

120 10. CONFIGURACIÓN DE LAS VARIABLES DE SEBEK Elija yes para iniciar la configuración de las variables de Sebek. Fig L56. Inicio de configuración de Sebek Ingrese la dirección IP de destino de los paquetes Sebek, por defecto Fig L57. Dirección IP destino Ingrese el puerto UDP de destino de los paquetes Sebek, por defecto Fig L58. Puerto UDP de Sebek,

121 10.4 Del menú de opciones de registro, elegir el literal 4. Fig L59. Opciones de registro del paquete Sebek El proceso de instalación y configuración ha terminado. Fig L60. Pantalla de finalización del proceso. 114