UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

Transcripción

1 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja Escuela de Ciencias de la Computación Modalidad Clásica TEMA: ANÁLISIS DEL TRÁFICO MALICIOSO DE LOS SERVICIOS EXTERNOS DE LA UTPL TESIS PREVIA A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN Autor: César Augusto Montalván Celi Director: Msc. María Paula Espinoza Loja - Ecuador 2010

2 Msc. María Paula Espinoza DOCENTE INVESTIGADOR DE LA ESCUELA DE CIENCIAS DE LA COMPUTACIÓN DE LA UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA CERTIFICA: Que una vez concluido el trabajo de investigación con el tema ANÁLISIS DEL TRÁFICO MALICIOSO DE LOS SERVICIOS EXTERNOS DE LA UTPL previa la obtención del título de Ingeniero en Sistemas Informáticos y Computación, realizado por el señor César Augusto Montalván Celi egresado de la Escuela de Ciencias de la Computación; haber dirigido, supervisado y asesorado en forma detenida cada uno de los aspectos de la tesis de pregrado. Además, en mi calidad de DIRECTOR DE TESIS y al encontrar que se han cumplido con todos los requisitos investigativos, autorizo su presentación y sustentación ante el tribunal que se designe para el efecto. Atentamente, Ing. María Paula Espinoza DIRECTOR DE TESIS

3 CESIÓN DE DERECHO Yo, César Augusto Montalván Celi, declaro conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja, que en 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. César A. Montalván Celi

4 AUTORÍA Las ideas, opiniones, conclusiones, recomendaciones y más contenidos expuestos en el presente informe de tesis son de absoluta responsabilidad del autor. César A. Montalván C.

5 DEDICATORIA A mis padres Gladys y Samuel por creer en mí, por brindarme su cariño y apoyo incondicional, y a mis hermanos Nora, Henrry, Eduardo y Leonardo que son mi impulso para seguir adelante. César A.

6 AGRADECIMIENTOS Mis más sinceros agradecimientos a todas las personas que me apoyaron, y de una u otra manera han contribuido a la culminación de este proyecto de fin de carrera, y de manera especial a la Msc. María Paula Espinoza, Directora de Tesis, que con su conocimiento, empeño y motivación, fue la tutora y guía durante el desarrollo del presente trabajo de investigación. Gracias

7 Índice General Índice de figuras 2 Índice de cuadros 3 I Introducción 4 II Objetivos 6 III Estructura de la tesis 7 1. Análisis de la situación actual tanto a nivel de honeynet como servicio de la UTPL Estudio del Esquema actual de la Honeynet Revisión del estado del arte Revisión de la Arquitectura Revisión del Software y Hardware utilizado Resultados obtenidos Identificación de los servicios críticos externos de la UTPL Inventario de servicios y evaluación de su criticidad Revisión de características: plataformas, versiones, aplicaciones, tráfico Revisión de problemas de seguridad relacionados Implementación de los servicios críticos externos en la honeynet Estudio de Honeynets virtuales Clasificación Virtualización y Herramientas de Virtualización Análisis del Hardware disponible Equipos virtuales a implementar Análisis de red de la Honeynet Esquema de red Configuración de red Esquema de red honeynet en VMware Configuración del equipo anfitrión Honeywall Requisitos del sistema Instalación de Honeywall CD roo-1.4.hw Configurando el Honeywall Interface GUI Walleye Sebek Instalación y configuración de Sebek Parámetros y/o variables Sebek a configurar Implementación de servicios Problemas de implementación Instalación de Sebek Instalación de las mismas versiones de las aplicaciones Pruebas Recolección de datos Subsistemas de una Honeynet de Generación III Control de Datos Captura de Datos Análisis de datos

8 3.2. Análisis de servicios, aplicaciones y vulnerabilidades de los servidores Exploración de servicios y aplicaciones con nmap y nessus Herramientas utilizadas para el análisis Wireshark y Geolocalización de direcciones IP remotas Análisis con NetworkMiner Análisis, interpretación y presentación de resultados Reportes mensuales Reportes mes de Agosto Reportes mes de Septiembre Análisis de los reportes mensuales Actividad en lo+s servidores Servidor DNS Servidor WEB Servidor EVA Servidor WSUTPL Actividades registradas Alertas Snort Ataques de diccionario al puerto ssh (port 22) Actividades maliciosas/sospechosas Incidentes registrados Ataque DOS a la red de la UTPL Patrones de comportamiento Discusión Conclusiones Recomendaciones Trabajos Futuros Referencias Anexos

9 Estudio del tráfico malicioso en los servicios críticos externos de la UTPL César A. Montalván C. * 10 de noviembre de 2010 * camontalvanx@utpl.edu.ec 1

10 Índice de figuras 1. Clasificación de honeynets por su Nivel de Interacción.[3] Ubicación de la honeynet en la red[7] Red actual de la UTPL[7] Honeynet virtual autocontenida.[17] Honeynet virtual hìbrida.[17] Esquema de red de la honeynet virtual Esquema de red y configuración de la honeynet virtual Puente de red entre Conexion de Area Local y VMnet Honeywall - Main Menú Diagrama de recolección y fusión de datos.[22] Interfaz GUI Walleye Interfaz GUI Walleye - cambio de contraseña Interfaz GUI Walleye Interface Walleye en funcionamiento Sebek, arquitectura cliente-servidor[23] Problema con Sebek, volcado de memoria Problema con Sebek,./parameters.sh Problema con Sebek, install failed Subsistemas del Honeywall.[25] Geolocalización de direcciones IP remotas NetworkMiner como herramienta de análisis Total paquetes mes de Agosto Total paquetes mes de Agosto Total puertos probados en el mes de Agosto Direcciones IP atacantes - Agosto Total paquetes mes de Septiembre Total paquetes mes de Septiembre Total puertos probados en el mes de Septiembre Direcciones IP atacantes - Septiembre Ataque de diccionario al puerto 22 ssh Ataque de diccionario al puerto 22 ssh analizado con Wireshark Ataque de diccionario al puerto 22 ssh registrado en la interface GUI Walleye Instalación de un backdoor Puerto que han sido abierto en el Honeypot comprometido Connection Limiting - Control de Datos Connection Limiting - Prueba de conexión Fence List - Control de Datos Fence List - Prueba de conexión

11 Índice de cuadros 1. Generaciones Honeynets.[5] Características de los servidores externos Características de la máquina anfitrión Características de los servidores externos sbk install.sh, variables Sebek a configurar Aplicaciones soportadas que han sido instaladas Servicios, puertos y aplicaciones instaladas en el Servidor DNS Servicios, puertos y aplicaciones instaladas en el Servidor Web Servicios, puertos y aplicaciones instaladas en el Servidor EVA Servicios, puertos y aplicaciones instaladas en el Servidor WSUT- PL Puertos escaneados/probados. Agosto IPs atacantes - Agosto Puertos escaneados/probados. Septiembre IPs atacantes - Septiembre Alertas ICMP generadas por Snort Alertas a otros protocolos generadas por Snort

12 Parte I Introducción Actualmente, la seguridad en los sistemas informáticos se ve cada vez más afectada y puesta en peligro por el desarrollo y avance de nuevas tecnologías, convirtiendola a la seguridad informática en un área elemental e importante en la protección de una infraestructura computacional. Los riesgos van en aumento y cada vez los métodos, herramientas, técnicas, etc. que son utilizados, son más sofisticados. Como medida para contrarrestar y tratar de minimizar estos riesgos, son empleados métodos de seguridad tradicionales, como lo son: la utilización de Firewalls, Listas de Control de Acceso (ACLs), Sistemas de Detección de Intrusos (IDS), Redes Virtuales Privadas (VPN), antivirus, etc. los cuales sirven de protección a la organización contra los atacantes,como dispositivos de detección y bloqueo de ataques de red, y como medidas reactivas, es decir, que la respuesta al incidente se la da una vez que el incidente ya se ha presentado, pero en temas de seguridad y protección a la información casi nada es suficiente. Conjuntamente con el desarrollo de las nuevas tecnologías, también van surgiendo herramientas en cuanto a protección contra atacantes de red se refiere, en procura de mantener la seguridad y la alta disponibilidad de los sistemas informáticos. Es así que surgen las Honeynets, como herramientas que pretenden mejorar la seguridad y se transforman en una estratégia para resguardar la información. Se trata de mecanismos, que nos permiten capturar y aprender de las actividades de red que se registran, con ello la formación de patrones y perfiles de los intrusos de la red. Cada ataque, intrusión o incidente representa una forma de obtener y alcanzar el conocimiento para poder de alguna manera entender el comportamiento de un atacante y estar preparados para recibir estos ataques la siguiente vez, esta vez ya de una forma proactiva, lo cual puede ayudar en sobre medida. Ya que un honeypot, se trata de un recurso de red a ser comprometido por ser voluntariamente vulnerable, y que está a vista de los atacantes, es el punto central de una Honeynet por la capacidad de recolección de información importante acerca de los intrusos, con la cual se pueden determinar tipos de ataques, métodos y también poder observar y conocer las propias vulnerabilidades y los riesgos a los que se encuentra expuestos los sistemas en producción, con esto, el administrador o administradores estar prevenidos y puedan tomar las medidas necesarias del caso, para evitar situaciones indeseables. En el presente trabajo, se pretende continuar con el desarrollo, investigación y explotación de estas tecnologías en una de sus formas, las Honeynets Virtuales, las cuales mantienen el mismo concepto de las Honeynets clásicas, pero sus ventajas podrían ser significantes al momento de utilizarlas. Asi mismo, en base a esta estructura, se busca capturar y monitorear el tráfico que se genera hacia los servidores externos de la UTPL, mediante la 4

13 simulación de estos entornos, con el fín de buscar actividades y comportamientos maliciosos para que puedan ser evitadas en un entorno real en un futuro. Así también, el estudio realizado permitirá generar nuevos campos de investigación en seguridad informática en la UTPL y el desarrollo del Grupo de Seguridad - UTPL. 5

14 Parte II Objetivos Objetivo General Establecer el nivel de exposición y seguridad de los servicios externos de la UTPL y determinar patrones de comportamiento anómalos y/o dañinos. Objetivos Específicos Estudio de los servicios externos de la UTPL y su nivel de criticidad a fín de ser implementados en la Honeynet para su posterior análisis. Implementación de un prototipo de Honeynet Virtual como fuente de información de las actividades de red hacia los servidores. Buscar explotar las Honeynets como herramientas innovadoras de seguridad proactiva. Tener en la Honeynet Virtual una herramienta para la generación de reportes y estadísticas de los datos recolectados. Buscar generar información y conocimiento en base a los resultados obtenidos. Análisis del tráfico de red malicioso de los servicios críticos externos de la UTPL. Informar, alertar y comunicar datos, hechos o incidentes importantes recolectados a los administradores para que se puedan tomar las medidas necesarias. 6

15 Parte III Estructura de la tesis La tesis está estructurada de la siguiente manera: Una introducción general sobre lo que es el proyecto, el trabajo realizado, los objetivos trazados y lo que se pretende conseguir a la culminación del mismo. En el capitulo 1, titulado: Análisis de la situación actual tanto a nivel de honeynet como servicio de la UTPL, se trata acerca de la revisión del estado de arte, conceptos, definiciones, funcionamiento, arquitecturas, etc., acerca de las tecnologías Honeynet. Se contempla el análisis de los servicios externos de la UTPL, para la evaluación de su nivel de criticidad. También se ha realizado un análisis sobre la tesis previa: ESTUDIO DE TRÁFICO DE ATAQUES A LA RED DE LA UTPL MEDIANTE UN PROTOTIPO DE HONEYPOT, los resultados obtenidos de la misma, para en base a estos, poder desarrollar el proyecto. En el capitulo 2, titulado: Implementación de los servicios críticos externos en la honeynet, se trata primeramente acerca del estudio de las técnologias de virtualización, sus definiciones, su utilización en Honeynets y la clasificación de Honeynets virtuales, luego el hardware disponible para poder montar la Honeynet virtual Auto-contenida, es decir dentro de un solo equipo, seleccionada por cuestiones de recursos hardware y espacio, y la configuración necesaria, en cuanto a tema de red se refiere; conceptos, requerimientos, beneficios. Luego se procede con las instalaciones de todos los elementos de la Honeynet Virtual, máquinas virtuales, switchs virtuales, puentes, hardware virtual, etc. Seguidamente, la implementación de los servicios críticos seleccionados en el capitulo 1, en cada una de las máquinas virtuales, así tambien como la implementación y puesta en marcha del equipo Honeywall. Finalmente se concluye este capítulo con la fase de pruebas, para comprobar la funcionalidad de todos los componentes de la Honeynet virtual. El capitulo 3, titulado: Recolección de datos, es el capitulo que trata acerca del Control, Captura y Análisis de datos, en sí, aborda temas de configuración y funcionamiento de la Honeynet Virtual, las herramientas que lo componen y el método utilizado para la recolección de la información. En el capitulo 4, titulado: Análisis, interpretación y presentación de resultados, se realiza una revisión de herramientas que se utilizan para el análisis de los datos, a su vez, tambien se hace una reconocimiento de las aplicaciones y los servicios instalados, para verificar los puertos que se podrían ver afectados por cada servidor. Finalmente, se hace una presentación de reportes con las actividades registradas de la Honeynet, análisis del tráfico generado, puertos utilizados/probados, direcciones IP de las cuales han intentado acceder, actividades por cada uno de los protocolos implementados, recogimiento de alertas de Snort, descubrimientos de hallazgos, entre otras cosas. 7

16 CAPITULO I ANÁLISIS DE LA SITUACIÓN AC- TUAL TANTO A NIVEL DE HONEYNET COMO SERVICIO DE LA UTPL 8

17 1. Análisis de la situación actual tanto a nivel de honeynet como servicio de la UTPL 1.1. Estudio del Esquema actual de la Honeynet Revisión del estado del arte Generalmente en las organizaciones, la protección de la información es uno de los principales aspectos que se toman en cuenta al momento de montar sus sistemas computacionales; para realizar este trabajo son empleados Firewalls, IDS (Sistemas de Detección de Intrusos), así también mecanismos de encriptación como medidas defensivas para mantener y garantizar la seguridad de la información, es decir; las medidas de reacción y recuperación se toman luego de que fallos o ataques o algún incidente en algún equipo han sido detectados. De esta manera, el enemigo tendrá siempre la iniciativa y la victima estará a sus expensas. Honeynet es una estructura que intenta cambiar este esquema. Se trata de una red trampa la cual tiene la misión de recolectar toda la información sobre las amenazas que se presentan en la red, información que es utilizada con fines investigativos y de aprendizaje. Esta estructura crea una red altamente controlada, que puede inspeccionar y supervisar toda la actividad que ocurre dentro de él.[1] Además, proporcionan un terreno fértil para los temas de investigación incluyen: las bases de datos, agentes distribuidos, análisis de datos, tecnología de agentes, los fundamentos de la red y temas avanzados.[2] El trabajo realizado en esta primera parte tiene como objetivo la recolección de información acerca de la estructura honeynet implementada en la red de la UTPL. Se ha verificado principalmente conceptos y definiciones acerca de estas arquitecturas, así como la información acerca de los servicios y servidores para el estudio de su nivel de criticidad en la red a fin de ser implementado en la honeynet y poder estudiar las vulnerabilidades y riesgos a los que están expuestos en un ambiente de producción. Se ha revisado la situación actual de la honeynet y su ubicación dentro de la red de la Universidad, ventajas, desventajas e inconvenientes, además del estudio de los resultados obtenidos por la honeynet a partir de su implementación desde el mes de Febrero del 2009 en la red de la UTPL. Tipos de Honeypots Los honeypots 1 se clasifican de la siguiente manera:[3] Por su función o uso ˆ Honeypots de Producción Detectar nuevos tipos de ataques y herramientas de hacking. 1 Recurso de red a ser atacado o comprometido. Lance Spitzner, Honeypots: Tracking Hackers,

18 ˆ Obtener mayor conocimiento de los atacantes (objetivos, actividades, etc.) y tendencias. Desarrollar nuevas signatures de IDS s. Honeypots de Investigación Distraer al atacante del objetivo real (ganar tiempo para proteger el ambiente de producción). Recolectar suficiente evidencia contra un atacante (controvertido). Por su grado de interacción ˆ ˆ ˆ Bajo Nivel de Interacción Minimizan el riesgo considerablemente. La información obtenida es muy limitada. Fáciles de instalar y mantener. No hay un sistema operativo sobre el cual el atacante pueda interactuar. Típicamente sólo proveen servicios falsos o emulados. Medio Nivel de Interacción Brinda mayor interacción pero sin llegar a proveer un sistema operativo sobre el cual interactuar. Los demonios que emulan los servicios son más sofisticados y brindan mayores posibilidades de interacción. El atacante obtiene una mejor ilusión de un sistema operativo real y mayores posibilidades de interactuar y escanear el sistema. El desarrollo/implementación es más complejo y consume más tiempo. Alto Nivel de Interacción Cuentan con un sistema operativo real. Presentan un mayor nivel de riesgo y complejidad. Son objetivos más atractivos a ser atacados. Se obtiene mayor y mejor información de los atacantes. Requiere de mucho tiempo para instalar y mantener. En la siguiente figura se muestra un cuadro comparativo entre los honeypots clasificados por su nivel de interacción: 10

19 Figura 1: Clasificación de honeynets por su Nivel de Interacción.[3] Arquitectura de una Honeynet Con el tiempo las honeynets han evolucionado y han surgido diferentes generaciones: GenI, GenII y Gen III. GenI (para la primera generación) explica como el Honeynet Project implementó por primera vez estos requisitos, desde 1999 al Basto y simple a la vez, fue muy efectivo en su tarea, capturando la mayoría de los ataques que se produjeron en Internet; gusanos, script kiddies, sondeos automáticos, etc. En el 2002 el Honeynet Project empezó a desarrollar nuevas herramientas y técnicas, llamadas GenII (en referencia a la segunda generación). Estas técnicas, siguiendo sus mismos requisitos, han ampliado enormemente sus capacidades. Las tecnologías de GenII dan a las organizaciones la habilidad de capturar las actividades de agresores más avanzados.[4] Una tercera Generación de Honeynets nace en el 2003, la cual se caracteriza por hacer la integración del análisis de datos en un mismo dispositivo Honeywall, con lo cual se hace más sencilla la utilización y mantenimiento de una Honeynet. En la siguiente figura se pueden evidenciar las diferencias entre estas Generaciones de Honeynets: Cuadro 1: Generaciones Honeynets.[5] 11

20 El uso de honeynets tiene grandes ventajas, pueden ayudar a mejorar la seguridad de la red, con la información recolectada se pueden armar perfiles y el modus operandi de los atacantes, las herramientas empleadas para realizar ataques, los procedimientos empleados, descubrir, entender mejor y protegerse de las amenazas a la que está expuesta, entre otras cosas; su desventaja es que una configuración errónea puede traer muchas consecuencias negativas, convirtiéndose en un riesgo potencial para la red, otro problema es que muchos recursos, son difíciles de construir y complejas de mantener.[6] Del estudio y trabajo realizado en base a la tesis[7] se pueden destacar los siguientes puntos a considerar: Revisión de la Arquitectura Una honeynet es un conjunto de honeypots con una arquitectura clienteservidor, en la cual los honeypots (clientes) son agentes expuestos a ataques y amenazas los que enviaran la información recogida a un servidor centralizado. La honeynet implementada actualmente consta de tres equipos en total: dos equipos que actúan como honeypots y un equipo central que hace las funciones de servidor central. Los honeypots al ser empleados como señuelos, deberán presentar ciertas fallas, bugs, y/o vulnerabilidades configuradas a propósito. Por ello también es importante que la ubicación de los mismos deba hacerse donde la red de producción no esté expuesta, puesto que podrían ser comprometidos y ser utilizados en su contra. En base al análisis elaborado previamente en[7], la honeynet se ha ubicado fuera de la red de producción ya que en ésta se ubican servicios sensibles y muy susceptibles a ataques. Con esta ubicación se elimina el riesgo de seguridad y las posibilidades que estos equipos sean comprometidos. El esquema es el que se presenta en la siguiente figura: Figura 2: Ubicación de la honeynet en la red[7]. 12

21 Revisión del Software y Hardware utilizado Para poder implementar una red trampa o honeynet se hace uso mayormente del Honeywall CDROM[8]. Se trata de un CD de arranque que contiene todas las herramientas necesarias para crear y utilizar una honeynet gateway (pasarela de red trampa) de segunda generación. El CDROM está basado en una versión reducida de Linux y está diseñado para ser utilizado como aplicación: contiene sólo las herramientas necesarias para gestionar el Honeywall. Un entorno de configuración (customization) permite a los usuarios avanzados añadir acracterísticas al CDROM que hace posible que las herramientas del mismo puedan ser utilizadas fuera de la red trampa.[9] A continuación se describen las herramientas que emplea honeywall para el control captura y análisis de tráfico en la Honeynet. - Captura de datos: Snort.- NIDS que lanza alarmas de ataques conocidos que son detectados por sus sensores. Snort Inline.- NIPS que previene ataques detectados por snort, está basado 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 fingerprinting).- Recoge información sobre el sistema operativo de un host. 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. - Captura de tráfico de red: 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 13

22 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 Resultados obtenidos Diseño e implementación de una honeynet en la red de la UTPL. Para poder establecer la ubicación adecuada de la honeynet en la red de la UTPL se ha hecho un análisis tanto del esquema de red, equipos y configuraciones de la red. La ubicación de los honeypots se la puede determinar en base a los requerimientos que tenga la organización y puede ser ubicados en distintas partes de la red, estas pueden ser: 1. Honeypots antes del firewall. 2. Honeypots después del firewall. 3. Honeypots en la zona desmilitarizada. Dependiendo de la ubicación de los honeypots, el nivel de riesgo aumenta, pero la cantidad de información que se logra recolectar también aumenta, cada ubicación presenta sus ventajas y sus desventajas. Ubicación de la Honeynet en la red de la UTPL. En la siguiente figura, se puede observar cual es el esquema de la red UTPL donde se ha implementado la honeynet. 14

23 Figura 3: Red actual de la UTPL[7]. Actualmente se tiene implementada la honeynet con un equipo que es el encargado de ser el Servidor centralizado y dos equipos honeypots, uno con plataforma Linux y el otro con plataforma Windows, que serán los encargados de ser señuelos y de enviar la información al servidor central. En el honeypot Windows, se ha seleccionado Windows XP como sistema operativo, aquí se tienen levantados servicios como IIS (Internet Information Services), HTTP, FTP, SMTP, servicios que convierten al ordenador en un servidor de Internet en el cual se pueden publicar páginas web. Además de esto, se ha procedido tambien a configurar un entorno virtual de aprendizaje EVA, en la plataforma Moodle-1.9.2, con la finalidad de simular un servicio real de la UTPL. En el servidor Linux, se ha tomado como sistema operativo base la distribución CentOS 5.2, aquí se tienen levantados servicios como HTTP, FTP, SSH(Secure Shell), Servidor Mail y servicios de bases de datos Identificación de los servicios críticos externos de lautpl. Toda organización de TI cuenta con servicios algunos más críticos que otros, ciertos servicios que no pueden dejar de funcionar bajo ninguna circunstancia. Por ello, los administradores tienen en las honeynet un recurso de ayuda para analizar la forma de proteger esos servicios críticos. La captura y análisis de datos que ofrece la honeynet proporciona información de mucho interés para los 15

24 administradores estos servicios críticos. Actualmente, la honeynet implementada en la red de la UTPL, aunque está en funcionamiento, no está simulando sistemas en producción y por tal no hay un seguimiento ni monitoreo a servicios críticos, en este caso servicios externos, y tampoco se ha realizado la evaluación para implementar los servicios en la misma. Por ello, se hace indispensable esa evaluación de los servicios externos para su posterior implementación en la honeynet, de manera que se pueda obtener la información referente a los riesgos a los que están expuestos estos servicios Inventario de servicios y evaluación de su criticidad. La finalidad de esta fase es de obtener información detallada sobre los servicios que están implementados en los servidores de la red de la UTPL, a fin de reconocer y seleccionar aquellos que sean de mayor criticidad para su posterior implementación y evaluación del tráfico de red que se genera. Para este fin y para poder evaluar valorar el nivel de criticidad se han tomado en consideración los siguientes puntos: 1. Inventario de todos los servidores de la red de la UTPL. Se ha procedido a recolectar toda información acerca de los servicios que están en producción y los que están en prueba, así también como plataformas usadas, versiones, servicios levantados, direcciones IP, internas como externas, administradores, etc. [Ver Anexo 1] 2. Estudio realizado en la tesis Plan de Continuidad de Negocios, PCN[10]. En este análisis se menciona que el servicio de internet es el que contiene los servicios críticos en sí, los más necesarios para la realización del presente proyecto. Por ello la tesis PCN menciona textualmente lo siguiente: Los servicios de internet como mail, DNS, Web Hosting y Proxy involucran las tareas de administrar las cuentas de correo de todos los usuarios de la Universidad, asignación de nombres de dominios internos de las aplicaciones, brinda dominios virtuales a clientes externos, permite el acceso a internet. Desde este punto de vista, presentamos a continuación los servicios de internet críticos para este proyecto y que se mencionan en PCN: Servicios Internet: - Web (gdr1.utpl.edu.ec). - DNS Externo (gdr2.utpl.edu.ec). - Entorno Virtual de Aprendizaje (eva.utpl.edu.ec). antes conocido como SGAMC(Sistema de Gestión Académica Modalidad Clásica) y SGA-MAD (Sistema de Gestión Académica de la Modalidad Abierta y a Distancia). - Servicios en línea, Estudiantes Docentes. (wsutpl.utpl.edu.ec). 16

25 3. Valorización de la información con los administradores y líderes de grupo. Para validar la información recolectada se ha procedido a realizar una encuesta [Ver Anexos 2] con los administradores de los servicios críticos para obtener una información aun más detallada de los servicios externos implementados. A más de ello, se ha procedido a verificar el nivel de criticidad de los servicios externos con una escuesta aplicada a los líderes de cada uno de los departamentos en los que se administran los servicios, para corroborar con ellos el nivel de importancia que tienen cada uno de ellos. Luego de aplicar las respectivas encuestas, el resultado que se ha podido obtener es que, los servicios críticos externos evaluados son evidentemente primordiales para el desarrollo normal de las actividades diarias de la UTPL, aumentando su nivel de importancia el número de usuarios y el impacto que significaría que estos servicios estén fuera de funcionamiento (indisponibilidad). 4. Evaluación de los servicios críticos en base a la información dada en el estudio de herramientas de monitoreo de la UTPL. El nivel de criticidad, de los servicios candidatos, también ha sido evaluado usando como métrica los datos que genera las herramientas tales como Netflow, Cacti, las cuales se encuentran montadas en el sistema de monitoreo de la UTPL (NOC), en cuanto al tráfico de red de entrada y salida registrado por los servidores y la determinación de si un servicio es identificado como interno o externo y cuál es el flujo de transmisión de datos.[ver Anexos 3]. De éste análisis se puede decir que efectivamente los servidores externos evaluados son críticos en base al flujo de tráfico que registran cada uno de ellos, si efectuamos un monitoreo diario de estos servidores externos, siempre, o casi siempre, se puede observar al servidor web (gdr1.utpl.edu.ec) en el primer lugar del rank de servidores con más tráfico de entrada y de salida, seguido del EVA (eva.utpl.edu.ec) que generalmente ocupa el segundo puesto. Un poco abajo del listado que se muestra con netflow se puede observar el servidor wsutpl.edu.ec, que al igual a diario muestra un flujo de red considerable. Lo mismo que pasa con el servidor DNS, que en cambio se monitorea con Cacti, tambien presenta una gran actividad y tráfico de red externo. Es necesario mencionar que tanto el servidor DNS, Web y el Eva, son servidores sumamente críticos, tanto a nivel externo e interno, por lo que se procederá a virtualizar estos servicios interna y externamente, esta información fué validada con los respectivos administradores y corroborada con los resultados que se muestran en las herramientas de monitoreo de la UTPL, NOC. 17

26 Revisión de características: plataformas, versiones, aplicaciones, tráfico. Luego del análisis de los servicios críticos se ha procedido a recoger información relevante acerca de estos, estos se muestran en la siguiente tabla. Cuadro 2: Características de los servidores externos Revisión de problemas de seguridad relacionados El hecho de conectar una red a un ambiente externo, como lo podría ser el internet, deja abierta la posibilidad de que los equipos de la red estén expuestos a amenazas como ataques, robo de información, mal funcionamiento, entre otras cosas. Conforme han evolucionado las tecnologías empleadas en red, así también como los servicios prestados, tales como , web, dns, etc., de igual forma los problemas de seguridad han ido surgiendo. Hoy en día es difícil mantener un equipo totalmente protegido, puesto que las aplicaciones, programas, software empleado muchas de las veces presenta fallas o errores, también conocidos como 18

27 bugs, los cuales pueden ser aprovechados por atacantes para comprometer los sistemas. Protocolo DNS El protocolo DNS y los programas que lo implementan se han visto envueltos desde siempre con múltiples problemas de seguridad. Por varios métodos distintos[11]: Atacando al servidor a través de un desbordamiento de búfer, inyectar código o accediendo al servidor para modificar las zonas. Aunque esto es ya menos común, BIND el programa casi estándar de facto en servidores DNS, sufrió de muchas vulnerabilidades de este tipo. Envenenamiento de la caché de los servidores. Un atacante puede montar su propio servidor DNS y mentir a un servidor DNS legítimo que le pregunta por registros que no tiene (los servidores DNS se preguntan constantemente entre sí para actualizar sus datos y redireccionar correctamente todos los dominios a las mismas direcciones). Falsificación del ID. Este método consiste en hacerse pasar por la respuesta legítima de un servidor DNS. El cliente que ha hecho una pregunta recibe directamente una respuesta falsa de un atacante. Estos dos últimos métodos han sido muy populares también en los últimos años, con numerosas técnicas que permitían llevar a cabo el ataque. Bien por fuerza bruta (bombardeando con peticiones) bien por fallos de implementación del protocolo. Vulnerabilidades en el Servidores DNS de BIND[12]: CA-AL : Vulnerabilidad en BIND 9.3.x PROBLEMA: Una vulnerabilidad fue identifica en el software de DNS BIND que de se explotada podría utilizarse para generar ataques de envenenamiento de cache en el mencionado software.el problema reside en un error de validación de datos de entrada en el protocolo DNSSEC cuando se reciben consultas recursivas. Para que el exploit sea efectivo se requiere que el servidor de nombres tenga la recursión permitida y que exija validación DNSSEC para sus clientes. Servidores de nombre solo autoritativos no están afectados. VERSIONES AFECTADAS: Las versiones afectadas son: BIND 9.0.x, BIND 9.1.x, 19

28 BIND 9.2.x, BIND 9.3.x, BIND hasta BIND P3, BIND 9.5.0, BIND 9.5.1, BIND 9.5.2, BIND y BIND P1. SOLUCIÓN: Actualizar a las versiones: P4, P1, o P2. dirección, VALORACIÓN DEL IMPACTO: ALTO. De la siguente Problemas de seguridad con Apache[13]: Vulnerabilidad en Apache Tomcat (CVE ) Tipo: No Disponible/Otro tipo + Salto de directorio + Secuencias de comandos en sitios cruzados - XSS Gravedad: Media Fecha de publicación: 28/01/2010 Última modificación: 26/02/2010 Descripción: Vulnerabilidad de salto de directorio en Apache Tomcat desde v5.5.0 hasta v y desde v6.0.0 hasta v permite a atacantes remotos borrar ficheros del directorio de trabajo a través de secuencias de salto de directorio en un nombre de fichero WAR, como se demuestra en..war nombre de fichero. Vector de acceso: A través de red. Problema de seguridad con Joomla[14]: Vulnerabilidad en JE Event Calendars (com jeeventcalendar) para Joomla! (CVE ) Tipo: No Disponible/Otro tipo + Salto de directorio + Inyección SQL + Errores numéricos + Permisos, privilegios y/o control de acceso. Gravedad: Alta Fecha de publicación: 02/03/2010 Última modificación: 03/03/2010 Descripción: 20

29 Vulnerabilidad de inyección SQL en el componente JE Event Calendars (com jeeventcalendar) v1.0 para Joomla! permite a atacantes remotos ejecutar comandos SQL arbitrarios a través del parámetro event id en una acción event a index.php. Vector de acceso: A través de red Complejidad de Acceso: Baja Autenticación: No requerida para explotarla. Tipo de impacto : Afecta parcialmente a la integridad del sistema + Afecta parcialmente a la confidencialidad del sistema + Afecta parcialmente a la disponibiliad del sistema Productos y versiones vulnerables: harmistechnology - com jeeventcalendar Problemas de seguridad con Wordpress[15]: Vulnerabilidad en wp-adminpress-this.php en WordPress (CVE ) Tipo: No Disponible/Otro tipo + Secuencias de comandos en sitios cruzados - XSS + Error de búfer Gravedad: Baja Fecha de publicación: 17/11/2009 Última modificación: 17/12/2009. Descripción: Vulnerabilidad de ejecución de secuencias de comandos en sitios cruzados (XSS) en wp-admin/press-this.php en WordPress anteriores a v2.8.6 permite a usuarios remotos autenticados inyectar secuencias de comandos web o HTML a través del parámetro s (también conocido como variable selección). Vector de acceso: A través de red. Tipo de impacto : Afecta parcialmente a la integridad del sistema. Los problemas de seguridad referentes a servicios se enfocan principalmente a la explotación de vulnerabilidades que estos pueden presentar. Por ello lo aconsejable sería mantener los equipos actualizados, trabajar con versiones estables y probadas, reajustar los sistemas conforme se liberen los parches de seguridad, seguridad en puertos al tener levantados solo los indispensables, actualización de firmas, etc. 21

30 CAPITULO II IMPLEMENTACIÓN DE LOS SERVICIOS CRÍTICOS EXTER- NOS EN LA HONEYNET 22

31 2. Implementación de los servicios críticos externos en la honeynet. Las honeynets se han convertido en los últimos años en una herramienta de seguridad altamente empleada y útil, dentro de los entornos computacionales de las organizaciones, demostrando su gran valor en la recolección de información significativa de los comportamientos de los agentes externos e internos que tiene toda organización. Por ello, se ha ideado también el concepto de honeynets virtuales como una forma de seguir explotando esta herramienta, en busca de nuevos patrones de comportamiento y de una manera u otra buscar la forma de entender mejor las amenazas a las que se encuentra expuesto para poder protegerse de las mismas. Otro de los motivos por los que surgen las honeynets virtuales es el gran consumo de recursos que representa el uso de honeynets tradicionales o clásicas, al hacer uso de varios equipos o sistemas y de mecanismos de protección, el espacio físico y los requerimientos para su implementación. En esta segunda fase del proyecto se tratará sobre la fase de implementación de los servicios críticos externos que se definieron en la fase anterior en una honeynet virtual. Por ello, en una primera parte se hace un recuento de conceptos acerca de las honeynets virtuales, su clasificación, ventajas, desventajas, herramientas existentes para virtualización. También un recuento del hardware con el que se cuenta para implementar la honeynet virtual. La revisión del esquema de red que se ha de utilizar y la configuración adecuada del software para simular la red. Para finalmente poder instalar y configurar los equipos virtuales con sus aplicaciones y servicios correspondientes Estudio de Honeynets virtuales. Una honeynet virtual se basa en el mismo concepto de una honeynet clásica, es una forma diferente de implementar un sistema completo honeynet dentro de un solo equipo físico a través de herramientas de virtualización, las cuales permiten simular los componentes de un sistema para su posterior análisis. El uso de este tipo de mecanismo de seguridad, presenta sus ventajas y desventajas[16]: VENTAJAS Ahorro de hardware: Se necesita de una sola máquina física. Se puede tener la ejecución de varios sistemas operativos dentro de un solo ordenador. Información centralizada: Se pueden administrar todos los componentes del sistema o honeynet en un solo equipo físico. Movilidad: Todo el sistema virtualizado puede ser movilizado sin problema alguno de un lado a otro, se puede implementar por ejemplo, dentro de un equipo portátil y poder ser movilizado con facilidad. 23

32 Escalabilidad: Dependiendo de las características del equipo anfitrión, se puede implementar y aumentar máquinas virtuales dependiendo de la necesidad. Aislamiento: Una caída o falla general del sistema de una máquina virtual no afecta al resto de máquinas virtuales. Espacio físico: Dependiendo del tamaño y la cantidad de componentes de la honeynet, se tiene un ahorro del espacio físico al únicamente emplear un solo equipo. DESVENTAJAS Un único punto de fallo: De llegar a fallar el hardware del equipo anfitrión todo el sistema honeynet dejará de funcionar. Equipo anfitrión de características potentes: Dependiendo también del tamaño de la honeynet se requerirá mayor tamaño en memoria y mejores características de procesamiento. Software Limitado, ya que todo tiene que ejecutarse en una máquina, esto limita al software que se pueda usar en el anfitrión. Las técnicas de fingerprinting (obtención del tipo y versión del sistema operativo mediante el envío de paquetes IP específicamente construidos) podrían revelar la naturaleza real de nuestro sistema operativo base. Incluso aunque en principio esta técnica no funcionara, si el atacante toma el control de una de los Honeypots probablemente pudiera averiguar que se encuentra en un sistema simulado, lo que falsearía su comportamiento Clasificación. Las honeynets virtuales se clasifican en dos tipos[17]: 1. Honeynets Auto-contenidas Una honeynet virtual autocontenida engloba a una honeynet en un solo equipo. La red entera está virtualmente contenida en un único y físico sistema. Una red Honeynet típicamente consiste de un cortafuegos para Control de Datos y Captura de Datos, y los honeypots dentro de la Honeynet. Un esquema de esta clase de honeynet sería la que muestra la figura que aparece a continuación: 24

33 Figura 4: Honeynet virtual autocontenida.[17] 2. Honeynets Híbridas 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, es decir, los sensores de IDS y el almacenamiento de registros, están en un sistema separado y aislado, para reducir el riesgo de compromiso. Sin embargo, todos los honeypots son ejecutados en una única máquina. Un esquema de esta clase de honeynet sería la que muestra la figura que aparece a continuación: Figura 5: Honeynet virtual hìbrida.[17] 25

34 Virtualización y Herramientas de Virtualización. Virtualización En informática, virtualización es ún término que se refiere a la abstracción de los recursos de una computadora, llamada Hypervisor, que crea una capa de abstracción entre el hardware de la máquina física (host, anfitrión) y el sistema operativo de la máquina virtual (guest, máquina virtual), siendo un medio para crear una versión virtual de un dispositivo o recurso como un servidor, un dispositivo de almacenamiento, una red, etc.[18] Herramientas de virtualización Actualmente existen muchas soluciones para virtualizar sistemas, unas mejores que otras dependiendo del uso que se le vaya a dar. Tanto en el mundo organizacional como con usuarios normales la virtualización va ganando terreno gracias al aporte de numerosas ventajas, asi como el ahorro de costes en hardware, mantenimiento, etc. Entre estas soluciones, herramientas licenciadas y de código abierto, las más utilizadas son[19]: Sun: VirtualBox (gratis), VirtualBox OSE (libre). VMware: Workstation (de pago), Server (gratis), Player (gratis). QEMU (libre). Micorsoft: Virtual PC, Virtual Server.... VMWare Workstation VMMare Workstation es un software de virtualización que puede correr en tanto en plataformas Windows como en plataformas Linux. Este software permite a los usuarios simular múltiples computadoras virtuales. Se trata de un sistema de virtualización por software. Un sistema virtual por software es un programa que simula un sistema físico (un ordenador, un hardware) con unas características de hardware determinadas. Cuando se ejecuta el programa (simulador), proporciona un ambiente de ejecución similar a todos los efectos a un ordenador físico (excepto en el puro acceso físico al hardware simulado), con CPU (puede ser más de una), BIOS, tarjeta gráfica, memoria RAM, tarjeta de red, sistema de sonido, conexión USB, disco duro (pueden ser más de uno), etc. Un virtualizador por software permite ejecutar (simular) varios ordenadores (sistemas operativos) dentro de un mismo hardware de manera simultánea, permitiendo así el mayor aprovechamiento de recursos. No obstante, y al ser una 26

35 capa intermedia entre el sistema físico y el sistema operativo que funciona en el hardware emulado, la velocidad de ejecución de este último es menor, pero en la mayoría de los casos suficiente para usarse en entornos de producción[20]. VMware toma ventaja de entre las otras soluciones de virtualización, por la garantía que da el tiempo que lleva en el mercado y la cantidad de usuarios a su haber, además de ser una herramienta muy flexible al momento de gestionar redes de sistemas, que es lo que se requiere para implementar una honeynet. Para el diseño y creación de redes complejas, VMWare es una excelente elección por las opciones y características que hacen de esta herramienta muy flexible, intuible y útil Análisis del Hardware disponible. Como se hacía mención anteriormente, para poder implementar una honeynet virtual es necesario un equipo robusto, de buenas características, para que pueda soportar las máquinas virtuales que han de formar la honeynet y que puedan correr simultaneamente. El equipo que se ha de emplear es de las siguientes características: Cuadro 3: Características de la máquina anfitrión Dispositivo(s) Procesador Memoria RAM Disco duro (HD) Tarjeta(s) de red Sistema Operativo Características Intel(R) Core(TM) 2 Duo CPU 2.93 GHz 6 Gb 250 Gb Ethernet (IP pública) Windows 2008 Server - 64 bits Equipos virtuales a implementar. Para poder crear una honeynet virtual utilizando VMWare como herramienta de virtualización, el equipo presentado anteriormente deberá dar soporte a las máquinas virtuales que conformarán la honeynet. La honeynet a implementar consta de 4 equipos honeypots con sus respectivos Sistemas Operativos y sus respectivos servicios y/o aplicaciones, un equipo será el honeywall, con su sistema operativo basado en Centos y una interfaz más para la administración remota del Honeywall. A continuación se muestra un cuadro en el que constan estos equipos: 27

36 Cuadro 5: Características de los servidores externos Análisis de red de la Honeynet. Para poder crear una honeynet virtual utilizando VMWare como herramienta de virtualización, es necesario primeramente diseñar la red que se quiere implementar, con los equipos y recursos que han de utilizarse para su respectivo funcionamiento Esquema de red El esquema de red para la honeynet, es el que se muestra en la siguiente figura: Figura 6: Esquema de red de la honeynet virtual 28

37 Configuración de red El equipo Honeywall tendrá 3 interfaces o tarjetas de red, configuradas dos en modos Bridge y una configurada en modo Host-only. ˆ ˆ ˆ A través de la interfaz configurada en modo Host-only el honeywall se comunicará con los honeypots. Una interfaz configurada en modo Bridge para la comunicación con el host anfitrión. Una tercera interfaz, también configurada en modo bridge, será la interfaz para la administración del Honeywall. VMWare tiene algunas opciones para configurar los adaptadores de red, cada uno tiene su propósito de ser, estos se mencionan a continuación[21]: Bridge La VM configurada con esta opción usa una dirección IP desde la red física y tiene acceso completo a los recursos de red. Significa que puede acceder a Internet, al servidor DHCP de la LAN, a los archivos compartidos entre otras cosas. Es como tener un computador separado en la propia red, que también tiene acceso completo desde cualquier host en la LAN real. NAT Esta opción permite acceder a algunos recursos basados en TCP/IP en el anfitrión (tal como conexión a Internet) sin requerir una dirección IP de la LAN real. En lugar de esto la VM usa una dirección IP la cual pertenece a la red virtual VMnet8. Esta VM no puede ser accedida desde cualquier equipo localizado en la red LAN (a excepción del propio equipo). Host-Only Habilitando esta opción, una VM que está conectada a nuestro equipo real es invisible a otros dispositivos en la LAN. Es decir se crea una red aislada a la de la LAN real. Custom Usando esta opción se puede configurar y diseñar redes complejas. Para esta opción se puede tener siete redes virtuales: VMnet2, VMnet3, VMnet4, VMnet5, VMnet6, VMnet7 and VMnet9. Cabe recalcar que estas redes son también redes host-only y las VMs las cuales pertenecen a cada una de ellas son accesibles desde el hostanfitrión si el adaptador virtual correspondiente se habilita en el hostanfitrión Esquema de red honeynet en VMware El esquema de red para la honeynet, y su respectiva configuración en el VMware, es el que se muestra en la siguiente figura: 29

38 Figura 7: Esquema de red y configuración de la honeynet virtual Configuración del equipo anfitrión Para poder implementar la infraestructura mencionada en los puntos anteriores, es necesario también configurar adecuadamente el equipo anfitrión de modo que nos permita el envío y recepción del tráfico de red. Cada uno de los equipos virtualizados tendrá que tener tráfico de entrada y salida, de manera que puedan ser visualizados desde la red exterior, con el objetivo que queden expuestos a ataques y riesgos que ésto significa. Para lograr esto, es necesario configurar las conexiones partícipes de red a manera de puente, de modo que los honeypots puedan tener la misma configuración de la Conexión que tiene acceso a la internet. Puente de red Un Puente de Red es una funcionalidad de Windows a través de la cual se pueden conectar dos o mas segmentos de red. En este caso, se hace un puente 30

39 entre la Conexión de Área Local, que es la que tiene acceso al internet, con el Adaptador virtual de red VMware (VMware Network Adapter VMnet1), que es la interface virtual a la que se conectan los honeypots. Esquema La figura siguiente muestra el esquema de un Puente de red, entre Conexión de área local 2 y VMware Network Adapter VMnet1: Figura 8: Puente de red entre Conexion de Area Local y VMnet1 Configuración Para configurar un puente de Red en el equipo anfitrión, bajo Windows Server 2008, procedemos de la siguiente manera: 1. Ir a Panel de Control. 2. Ir a Centro de Redes y recursos compartidos. 3. Ir a Administrar conexiones de red. 4. Localizar los Adaptadores de red los cuales serán parte del puente, en este caso: Adaptador de Área Local y VMware Network Adapter VMnet1, seleccionarlos a ambos manteniendo pulsada la tecla Control. 5. Dar click derecho y escoger la opción Puente de red. 31

40 2.4. Honeywall Para este proyecto se hará uso del CD Honeywall 1.4, que esta disponible en la web del proyecto honeynet ( Se crea una nueva maquina virtual y se la arranca desde un CD-Live Honeywall 1.4, en la máquina que estará designada para ser de Honeywall Requisitos del sistema Según [8], por motivos de seguridad, el CDROM Honeywall utiliza un sistema operativo Linux minimizado. Por lo tanto, este es el hardware y los requisitos: Al menos 256MB de memoria (Más siempre es mejor, pero menos de 960M - no soporta highmem) Unidad cd CDROM Disco duro IDE para registro. (Recomendado AL MENOS 30 GB) Pentium III o superior. 2 tarjetas de red (una 3ª para gestión de red) Unidad de disquetera (opcional). Puede ser utilizada para grabar o cargar nuevos ficheros de configuración Instalación de Honeywall CD roo-1.4.hw Para una información detallada sobre la instalación, configuración y adminstración de Honeywall, se puede remitirnos a los manuales que se presentan en el [Anexo 4] Configurando Honeywall Una vez que el software se ha instalado correctamente en el sistema, el siguiente paso es la configuración del Honeywall para el correcto funcionamiento de los parámetros y/o variables de la Honeynet. En teoría esto debería hacerse automáticamente la primera vez que se ingresa, pero casi nunca se logra configurar correctamente la Honeynet solo a la primera vez. Es por ello que se puede acceder a la configuración a través de la ejecución del script: /dlg/dialogmenu.sh, el cual nos presenta el Menú principal, para poder chequear el estado del Honeywall: 32

41 Figura 9: Honeywall - Main Menú EL Dialog Menu, es la interface clásica para administrar y configurar el Honeywall CDROM. Aunque hoy en día ya no se la considera como el método principal para el mantenimiento del Honeywall, debido a que la interface Walleye se la considera como mejor opción, presenta sub-menús con opciones para la administración del Honeywall Interface GUI Walleye Walleye es la interface web para la administración del Honeywall. El Honeywall ejecuta un servidor web al cual se puede acceder remotamente a travez de una conexión segura SSL a la interface de red de administración. Esta GUI, permite al usuario configurar y mantener el sistema de una forma sencilla. Además, cuenta con un menú de expansión por lo que se facilita el acceso para poder visualizar toda la información. Esta Interface Gráfica de Usuario, actualmente tiene soporte ya sea para Internet Explorer, Firefox, Google Chrome, etc. La interface GUI Walleye está diseñada para facilitar la comprensión de la secuencia de una intrusión, a través de la presentación de una vista compuesta de datos. Es decir, que la vista de datos que se presenta es una composición de cada una de las fuentes de datos. Para lograr esto, la interface GUI Walleye utiliza un modelo relacional para generar vistas compuestas de los eventos de las fuentes de datos, tal como lo son: p0f, Argus, Snort, Sebek, haciendo una fusión de todas estas fuentes en una base de datos llamada hflow, de la cual se obtienen los datos: 33

42 Figura 10: Diagrama de recolección y fusión de datos.[22] Para poder visualizar esta interfaz, iniciamos un navegador desde el equipo que servirá de administración y ubicamos en el url la dirección IP de administración del honeywall, utilizando ssl, Figura 11: Interfaz GUI Walleye Para poder ingresar, el username y password por defecto son: Username: roo Password: honey 34

43 Figura 12: Interfaz GUI Walleye - cambio de contraseña El username y password son solo para la primera vez que se ingresa al Walleye, de ahi se deben modificar: Figura 13: Interfaz GUI Walleye Una vez registrados se puede realizar la administración del Honeywall remotamente. En la interface GUI Walleye se realiza el monitoreo y análisis, podemos ver gráficamente las conexiones entrantes y salientes, información detallada de los protocolos utilizados y en especial se puede visualizar el tráfico Sebek capturado, además que tiene la funcionalidad para poder filtrar nuestras capturas de modo que sea ágil el análisis. De esta interface tambien podemos descargar los pcaps, para poder realizar 35

44 el respectivo análisis de modo off-line con cualquier herramienta de análisis de táfico, como por ejemplo: Wireshark. A continuación se presenta una captura de la interface Walleye en funcionamiento: Figura 14: Interface Walleye en funcionamiento 2.6. Sebek Sebek es una herramienta para la captura de datos, diseñada para capturar las actividades de los atacantes en un honeypot, sin que éste lo sepa. Este consta de dos componentes. El primero es un cliente que corre en los honeypots, su propósito es capturar todas las actividades (pulsaciones del teclado, subidas de archivos, passwords, incluso en entornos encriptados) y encubiertamente envía los datos al servidor. El segundo componente es el servidor, el cual los datos de los honeypots[23]. El servidor, normalmente corre en un gateway Honeywall, pero puede correr también independientemente. 36

45 Figura 15: Sebek, arquitectura cliente-servidor[23] Instalación y configuración de Sebek. Esta herramienta de seguridad se puede ejecutar en plataformas Linux y Windows, y se lo puede descargar desde la web desde la siguiente ubicación: La instalación y configuración de Sebek, tanto en sistemas Linux, como en sistemas Windows se muestra en los [Anexos 5] Parámetros y/o variables Sebek a configurar. Para una configuración adecuada de Sebek, es necesario editar el archivo de configuración: sbk install.sh, el cual contiene los parámetros o variables para Sebek. Se debe configurar las variables con el fín de personalizar la captura en el honeypot (equipo trampa) y también hacer más dificil la detección de Sebek: 37

46 Cuadro 6: sbk install.sh, variables Sebek a configurar. Parámetro FILTER INTERFACE DESTINATION IP DESTINATION MAC SOURCE PORT DESTINATION PORT MAGIC VAL KEYSTROKE ONLY SOCKET TRACKING WRITE TRACKING TESTING MODULE NAME Descripción Archivo que contiene el filtro de colección. Identifica la interface desde la que registrará Sebek Estable la IP destino para los paquetes Sebek Establece la dirección MAC destino para los paquetes Sebek Define el puerto UDP origen para Sebek Define el puerto UDP destino para Sebek Define el valor mágico en los registros Sebek Controla si se recolecta solamente pulsaciones de teclado Controla si solo se recolecta información en conexiones de red Característica experimental. Deshabilitada por recomendación Se usa para hacer el módulo oculto Usado para controlar el nombre del módulo La configuración utilizada del archivo sbk install.sh de Sebek, para plataformas Linux, se muestra en el [Anexo 6] Implementación de servicios. Una vez que ya se tiene montada la honeynet virtual, con todos los componentes (honeywall, honeypots, equipo de administración) y que han sido configurados adecuadamente el honeywall y Sebek en los honeypots, procedemos a la instalación de los respectivos servicios en cada uno de los honeypots, con el objetivo de poder analizar el tráfico que se genera. Los servicios a ser implementados se los puede observar todos y cada uno de ellos en el Cuadro 2: Características de los servidores externos de la primera fase, son los servicios y/o aplicaciones que se analizaron en la fase anterior. Ver [Anexos 7] 2.8. Problemas de implementación Instalación de Sebek Instalación de Sebek en Windows 2003 Server Para la implementación del servidor wsutpl, se necesita virtualizar un servidor con Windows 2003 Server - Enterprise Edition, como su Sistema Operativo. Luego de realizar la instalación de dicho Sistema Operativo, y de implementar las aplicaciones y servicios, el siguiente paso es la instalación de la herramienta Sebek, para la captura de las actividades de los atacantes, es aquí donde surge el inconveniente: 38

47 Se ha procedido a instalar Sebek para Windows, probando con diferentes versiones, y esto es lo que sucede: Escenario 1 Sistema Operativo: Windows 2003 Server Edición: Enterprise Service Pack: 2 Versiones instalada de Sebek: ˆ ˆ ˆ sebek-win Sebek-Win Sebek-Win Resultado Al utilizar estas versiones de Sebek bajo plataformas Windows 2003 Server, el servidor presenta funcionamiento defectuoso, y se muestra un volcado de memoria, el pantallazo azul, al momento de reiniciar el servidor: Figura 16: Problema con Sebek, volcado de memoria Escenario 2 Sistema Operativo: Windows 2003 Server Edición: Enterprise 39

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

49 ˆ ˆ ˆ ˆ sebek-lin c.tar sebek-linux tar sebek-linux c.tar sebek-linux b.tar Resultado: Al descomprimir y realizar pruebas con todos y cada uno de estas versiones de Sebek para Linux, y luego de modificar adecuadamente el archivo sbk install.sh; cuando se ejecuta el instalador, se muestra el siguiente mensaje de error, el cual no permite realizar la instalación de Sebek: Figura 17: Problema con Sebek,./parameters.sh Escenario 2 Sistema Operativo: Linux Distribución: CentOS 5.0 Server Kernel: el5 Versiones Sebek instaladas: ˆ sebek disable raw socket replacement-lin b-bin.tar Resultado: Del mismo modo, después de desempaquetar el instalador y editar adecuadamente el archivo sbk install.sh, al momento de lanzar el instalador, también se nos muestra una falla al momento de la instalación: Figura 18: Problema con Sebek, install failed 41

50 Solución: Se ha procedido a instalar la Herramienta Sebek en una distribución Linux que le dé el soporte a tal herramienta, en este caso se ha instalado en Ubuntu 7.10 Server en todos los servidores que utilizan Linux como Sistema Operativo. Notas: Cabe mencionar, que para tratar de solventar estos inconvenientes, también se solicitó ayuda a similares proyectos que se realizan en diferentes paises, tales como en Brazil, México, España, pero tampoco se logró tener una respuesta para poder solucionar este inconveniente Instalación de las mismas versiones de las aplicaciones Como consecuencia de los problemas en la implementación de Sebek, citados anteriormente, hay problemas de compatibilidad con las versiones de las aplicaciones reales con las que soportan los Sistemas Operativos instalados. En la tabla siguiente se puede observar cuales han sido las aplicaciones instaladas en los sistemas operativos instalados: Cuadro 8: Aplicaciones soportadas que han sido instaladas. 42

51 2.9. Pruebas Como última parte de esta segunda fase, se hace necesario realizar algunas pruebas para testear el correcto funcionamiento de la honeynet, con la finalidad de que verificar si realmente se está capturando el tráfico de red y si se tiene una correcta actividad de cada uno de los componentes de la honeynet. Para ello se procederá a realizar los siguientes pasos: Verificar conectividad de componentes (honeypots). ˆ ˆ Se ha verificado esto, mediante respuestas echo replies al comando ping. Existe conectividad de todos los honeypots entre sí. Comprobar conectividad desde y hacia la internet a través del protocolo IP. ˆ ˆ ˆ Se ha verificado esto, mediante respuestas echo replies al comando ping. Ping exitoso hacia algunos sitios web, como desde todos los honeypots. Ping exitoso desde equipos de red externa hacia los honeypots. Comprobar si los servicios y/o aplicaciones estén instalados y configurados correctamente en los honeypots. ˆ ˆ ˆ ˆ Servidor DNS Se ha verificado esto, mediante el comando nslookup. Existen resolución exitosa de nombres de dominio, tanto normal como inversa. Aplicaciones instaladas y funcionando correctamente Servidor WEB Aplicaciones instaladas y funcionando correctamente. Se puede visualizar el servidor web, a través de navegadores de la red externa. Webmin, instalado y ejecutandose. Servidor EVA Aplicaciones instaladas y funcionando correctamente. Moodle en funcionamiento y accesible a través de navegadores desde la red externa. Servidor WSUTPL Aplicaciones instaladas y funcionando correctamente. 43

52 IIS instalado y accesible a través de navegadores desde la red externa. Verificar si realmente se están enviando alertas por . ˆ Efectivamante se están receptando correos electrónicos a través del puerto 25 smtp. Verificar si Sebek realmente está recolectando la actividad de los sistemas. ˆ Se ha verificado esto, mediante el comando sbk extract del honeywall Se hace un ping desde cada uno de los honeypots, y efectivamente se está capturando tráfico Sebek. Otra forma de verificar esto es a través de la interface GUI Walleye, donde los paquetes capturados aparecen etiquetados (flag) como Sebeked. Comprobar el ingreso exitoso a la interface GUI Walleye. ˆ Una vez que se ha ejecutado el Honeywall, abrir desde un navegador la administración, en la dirección: y verificar si hay como ingresar al sistema correctamente ingresando usuario y contraseña. Comprobar si la interfaz Walleye está funcionando y recolectando datos correctamente. ˆ Existe tráfico ya capturado que muestra la información que se está recolectando y mostrando a través de la interface GUI. Verificar que todas las herramientas del Honeywall sean inicializadas. ˆ En el arranque del sistema verificar la inicialización de servicios del Honeywall. (Walleye, Snort, Sebek, Pof, Swatch, Argus) 44

53 CAPITULO III RECOLECCIÓN DE DATOS 45

54 3. Recolección de datos Una vez que se ha logrado configurar e implementar la red honeynet con los honeypots en la herramienta de virtualización (VMWare), el siguiente paso a seguir es el Control, la Captura y el Análisis de Datos Subsistemas de una Honeynet de Generación III. La Arquitectura Honeynet de Generación III, tiene sus origenes a inicios del años Es una evolución de sus generaciones antecesoras, pero esta generación presenta mejoras en las versiones de la herramientas utilizadas, con la finalidad de optimizar el análisis de los datos recogidos. En base a la experiencia de las versiones o generaciones anteriores, y con el objetivo de disminuir la dificultad en el análisis de los datos, las Honeynets de Generación III presenta los siguientes subsistemas: Figura 19: Subsistemas del Honeywall.[25] Control de Datos El objetivo del Control de Datos es verificar qué es lo que el atacante puede hacer en la entrada y salida de la Honeynet. Generalmente, lo que se realiza es permitir cualquier tráfico en la entrada al sistema Honeynet, pero lo que se hace es limitar el tráfico de salida. Para esto se hace uso de IPTables, que es un cortafuegos OpenSource que viene incluido con Linux. Se trata de un firewall o cortafuegos altamente flexible, que incluye la habilidad de limitar conexiones entrantes y salientes, traducción de direcciones de red (NAT), registro, entre otras características. Hay que configurar IPTables para que actúe como filtro en nuestro HostOS (máquina física), contando los paquetes de salida. Una vez que se haya alcanzado el límite de conexiones de salida, cualquier intento posterior deberá ser bloqueado, con esto se puede prevenir que algún honeypot comprometido pueda afectar a otros 46

55 sistemas dentro de la red. La configuración e implementación de dichas características se podría tratar de una tarea extremadamente compleja. Sin embargo, el Honeynet Project ha desarrollado un script IPTables llamado rc.firewall para facilitar este trabajo. En algunas ocasiones es necesario modificar algunas de las variables del script para que se adapten a la Honeynet, y luego ejecutarlo. Lo primero, es necesario saber que se está trabajando con una Honeynet de Gen III, en la que el Honeywall gateway trabaja en modo puente de nivel dos ( layer two bridging mode ), el cual es el método más comunmente utilizado. Cuando el gateway actúa como puente, no hay enrutamiento o decrementos de paquetes TTL ( time to live ), lo cual permite que actúe como un dispositivo de filtro invisible, haciéndola más difícil de detectar ante atacantes. Para poder configurar el script rc.firewall adecuadamente, hay dos áreas críticas que configurar, los parámetros de red y los de conexión. Como en modo puente (bridge) no hay enrutamiento, ni asuntos de Traducción de Direcciones de Red (NAT). Simplemente se convierte el HostOS(máquina física) en un puente, y los GuestOS(máquinas virtuales) interactúan directamente con otras redes. Para los parámetros de conexión, hay que configurar cuántas conexiones de salida serán permitidas. Para realizar estas operaciones se debe configurar de la siguiente manera: Primero, se debe establecer las direcciones IP públicas de los sistemas operativos invitados (máquinas virtuales). Esas son las IP que los hackers atacarán, las IP válidas de nuestros honeypots. Dependiendo de la cantidad de honeypots, se necesita enumerar las direcciones IP de los honeypots. Segundo, se necesita identificar el nombre de las interfaces internas para el HostOS. Por defecto, esta es la interface eth1, y la interface externa que por defecto es la eth2. Tercero, se debe considerar probar las capacidades de Snort-Inline para rechazar ( drop ) ataques salientes conocidos. Los paquetes de salida autorizados para pasar a través del cortafuegos son luego enviados a Snortinline. Snort-inline es un sistema de prevención de intrusiones basado en el detector de intrusiones Snort. Este es capaz de tomar acciones contra el tráfico saliente que tenga ataques conocidos. Snort-inline puede ser configurado en el Honeywall para utilizar tres conjuntos diferentes de reglas por defecto que pueden descartar (drop), deshabilitar (disable), o rechazar (reject) ataques conocidos. Tanto el rc.firewall como el Snort-inline pueden generar registros detallados que pueden ser utilizados para analisis y alertas.[26] Esas son las mínimas variables que se debe considerar, puede haber otras dependiendo de la configuración del sistema. Hay opciones adicionales que se pueden actualizar, como administración remota, limitar las conexiones que puede iniciar el cortafuegos, y dar a los honeypots acceso DNS sin restricciones. También, por 47

56 defecto, el script limita a cada honeypot las siguientes conexiones de salida por hora: 9 conexiones TCP, 20 conexiones UDP, 50 conexiones ICMP, y 10 otras IP, esta es la configuración que viene por defecto.[26]. Cabe mecionar, que para el proyecto se está usando las configuraciones por defecto y que tanto para conexiones TCP y UDP, ya están configurados los puertos de escuchan que utilizan los servidores y sus aplicaciones en el Honeywall. Herramientas para el Control de Datos: Bridge de capa 2 (Honeywall) Iptables (limitación de paquetes y/o tráfico de red) Snort Inline (manipulación de paquetes de red) Captura de Datos Otro de los requisitos fundamentales es la captura de toda la actividad del atacante minimizando las posibilidades de que éste se percate de ello. La actividad en la red trampa es registrada por varias herramientas diferentes. Primero, el firewall o cortafuegos registra todas las conexiones entrantes y salientes en /var/log/messages. Segundo, por defecto un proceso de Snort captura toda la actividad de red y todos los contenidos de los paquetes vistos por la interfaz de red interna (por defecto eth1). Esto incluye toda la actividad de Sebek, la cual es enviada mediante paquetes UDP. Tercero, una instancia adicional de Snort escucha en la interfaz interna y genera alertas IDS en modo full y fast. Toda la actividad de Snort y Snort-inline es registrada en /var/log/snort/$day, donde $DAY es el valor numérico del día. Donde se ha estandarizado YEARMONTHDAY, por ejemplo los datos capturados el 06 de agosto de 2010 deberían estar en /var/log/snort/ La única cosa que necesita configurarse a mano son las opciones de registro de Sebek. A qué puerto e IP tienen los clientes Sebek que enviar sus registros, y si se desea que todos los paquetes de Sebek sean registrados por el cortafuegos (Sebek puede ser bastante ruidoso, llenando sus registros de cortafuegos). Cuando el Honeywall haya capturado la actividad de Sebek en los ficheros pcap de Snort, se pueden extraer manualmente los paquetes de Sebek desde la interface GUI. Otra de las características es la habilidad para generar alertas automáticas cuando el sistema trampa ha sido comprometido. Las alertas están implementadas actualmente utilizando correos electrónicos sin cifrar (en texto en claro). Swatch, el Simple WATCHer, es el encargado de monitorizar /var/log/messages 48

57 en busca de actividad entrante y saliente. Si se detecta cualquier conexión saliente, se genera una alerta y envía un correo electrónico. Las direcciones de correo a las que son enviadas las alertas pueden ser configuradas a través del GUI. Las alertas de correo sirven para notificar a los administradores de la red trampa sobre los posibles equipos comprometidos. Ya que el Honeywall está configurado para trabajar en modo puente (bridge) de nivel dos (por defecto) entonces es necesario tener una tercera interface de gestión para poder enviar las alertas. Cuando se envían alertas por correo electrónico a través de la interface de gestión, se configura el cortafuegos para permitir la salida de TCP/25 desde esa interface[26]. Herramientas para la Captura de Datos: Iptables (logs de iptables) Snort (alertas IDS) pof (identificación pasiva de SO) Sebek (captura avanzada de datos) Tcpdump (captura de tráfico de red) Análisis de datos A través de la Generación III de las Honeynets se ha logrado mejorar el análisis de los datos, con respecto a las arquitecturas anteriores. En sí, la manera más sencilla de realizar el análisis y examinar el tráfico de red y los datos recolectados en la Honeynet es la búsqueda de conexiones por fecha, tiempo, direcciones IP y/o puertos que se muestran en la interface GUI Walleye, estos resultados pueden ser devueltos como un archvivo PCAP o en Walleye flow view, para mediante la utilización de herramientas de análisis de tráfico de red como por ejemplo Wireshark proceder al examinar los datos recolectados. Herramientas para el Análisis de Datos: MySQL (base de datos Honeynet para la recolección) Argus + Hflow (recolección de datos, flujo de tráfico y relaciones) Swatch (logs de firewall y alertas IDS) Walleye (interface gráfica de usuario) 49

58 3.2. Análisis de servicios, aplicaciones y vulnerabilidades de los servidores. En primer lugar, antes de la captura y análisis de los datos, es necesario verificar que las aplicaciones que se han configurado en los servidores se encuentren disponibles y ejecutandose en los equipos. Para esto, hacemos uso de herramientas de escaneo de puertos abiertos y vulnerabilidades, como los son nmap y nessus Exploración de servicios y aplicaciones con nmap y nessus. Luego de realizar un escaneo con las herramientas nmap y nessus de los servidores montados, los resultados acerca de los servicios y puertos abiertos, que arrojan las herramientas son los siguientes por cada servidor: Servidor DNS Servicios/aplicaciones instaladas: Cuadro 9: Servicios, puertos y aplicaciones instaladas en el Servidor DNS. PORT STATE SERVICE VERSIÓN 0/icmp open general 22/tcp open ssh OpenSSH 4.6p1 Debian 5build1 (protocol 2.0) 53/udp open domain 53/tcp open domain 953/tcp open rndc Servidor WEB Servicios/aplicaciones instaladas: Cuadro 10: Servicios, puertos y aplicaciones instaladas en el Servidor Web. PORT STATE SERVICE VERSIÓN 0/icmp open general 80/tcp open http Apache httpd 2.2.4((Ubuntu)PHP/ ubuntu6) 3306/tcp open mysql MYSQL 10000/tcp open http Webmin httpd Servidor EVA Servicios/aplicaciones instaladas: 50

59 Cuadro 11: Servicios, puertos y aplicaciones instaladas en el Servidor EVA. PORT STATE SERVICE VERSIÓN 0/icmp open general 80/tcp open http Apache httpd ((Ubuntu) PHP/ ubuntu6) 8009/tcp open ajp13? Apache JServ Protocol AJP Connector 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 Servidor WSUTPL Servicios/aplicaciones instaladas: Cuadro 12: Servicios, puertos y aplicaciones instaladas en el Servidor WSUTPL. PORT STATE SERVICE VERSIÓN 0/icmp open general 25/tcp open smtp Microsoft ESMTP /tcp open http Microsoft IIS webserver /tcp open msrpc Microsoft Windows RPC 137/udp open netbios-ns 139/tcp open netbios-ssn 443/tcp open https? 445/tcp open microsoft-ds? 1027/tcp open msrpc Microsoft Windows RPC 1241/tcp open ssl/unknown 3.3. Herramientas utilizadas para el análisis Wireshark y Geolocalización de direcciones IP remotas. La geolocalización de direcciones IP remotas es una de las formas de verificar las conexiones que se han dado y la ubicación geográfica de las direcciones IPs remotas que han intentado realizar conexiones hacia los honeypots. Mediante las múltiples funcionalidades que presenta la herramienta de análisis de tráfico Wireshark se puede realizar este análisis. Con esto podemos observar la gran cantidad de conexiones remotas que existen hacia los honeypots de todas partes del mundo: 51

60 Figura 20: Geolocalización de direcciones IP remotas Fecha: Jueves 26 de Agosto. Pcap tomado de entre las 03:18am a las 4:18am Análisis con NetworkMiner. NetworkMiner es una herramienta Open Source para Analisis Forense de red, Network Forensic Analysis Tool (NFAT). Esta herramienta, incluye un sniffer o capturador de paquetes de red, puede detectar Sistemas Operativos, sesiones, hostnames, puertos abiertos etc. Con NetworkMiner también se puede analizar archivos PCAP, para un análisis off-line. El Website es: 52

61 Figura 21: NetworkMiner como herramienta de análisis Mediante esta herramienta, podemos realizar el análisis forense de los archivos pcaps que se analice. Se presenta gráficamente a detalle la información de los equipos que han intentado acceder a los honeypots, los puertos origen y destino que se han utilizado, protocolos, sesiones, etc. 53

62 Capitulo 4 ANÁLISIS, INTERPRETACIÓN Y PRESENTACIÓN DE RE- SULTADOS 54

63 4. Análisis, interpretación y presentación de resultados Luego de haber implementado la Honeynet en la red de la UTPL, se ha comprobado el correcto funcionamiento de la misma y los instrumentos de recolección de datos están puestos en marcha, se procede a realizar el tratamiento correspondiente para el análisis y la interpretación de los datos por cuanto la información que se arroje nos ayudará a poder sacar las conclusiones a las cuales se pretende llegar con el presente proyecto. En esta fase del proyecto se ha procedido a utilizar las herramientas necesarias para recolectar la información importante que se suscita en los servidores externos implementados, un análisis de los mismos a través de reportes y estadísticas que nos muestran el comportamiento y el tráfico que se genera hacia los servidores. El análisis de direcciones IPs, puertos afectados, protocolos que han sido utilizados, reflejados en los reportes, nos darán una idea o una visión de cuales son los servicios más atrayentes para los atacantes Reportes mensuales Reportes mes de Agosto Total de paquetes: ICMP: TCP: UDP: Figura 22: Total paquetes mes de Agosto Conexiones totales a los Puertos por Protocolo En la figura siguiente se puede observar los puertos por protocolo los cuales han 55

64 sido utilizados por los atacantes: Figura 23: Total paquetes mes de Agosto Servicios y puertos escaneados/probados por los atacantes. En la siguiente figura se muestran los los puertos que han sido probados por los atacantes. Figura 24: Total puertos probados en el mes de Agosto. 56

65 Cuadro 13: Puertos escaneados/probados. Agosto Puerto Frec. Descrip. Puerto Frec. Descrip. tcp/ ssh tcp/ Simantec Antiv tcp/ http tcp/ HTTP Squid icmp/ echo reply tcp/ Apache Tomcat udp/ sip tcp/25 86 smtp tcp/ microsoft-ds tcp/23 67 telnet tcp/ netbios-ssn udp/ Norton Antiv tcp/ ms-sql-server tcp/ WBT tcp/ vnc tcp/ radmin tcp/ SOCKS proxy tcp/ iclpv-sas Direcciones IP atacantes Durante el mes de Agosto hubo una gran cantidad de direcciones IP atacantes, en la figura siguiente se muestra un top 30 de las mismas: Figura 25: Direcciones IP atacantes - Agosto. 57

66 Cuadro 14: IPs atacantes - Agosto. Dir. IP Frec. País Dir. IP Frec. Cód. país hk kr ec hk cn us br cn co sf br il ec sg cn bg br cn kr us cn ec cn us uk us cn ar cn cn Reportes mes de Septiembre Total de paquetes: ICMP: TCP: UDP: Figura 26: Total paquetes mes de Septiembre 58

67 Conexiones totales a los Puertos por Protocolo. En la figura siguiente se puede observar los puertos por protocolo los cuales han sido utilizados por los atacantes: Figura 27: Total paquetes mes de Septiembre Servicios y puertos escaneados/probados por los atacantes. En la siguiente figura se muestran los los puertos que han sido probados/utilizados por los atacantes. Figura 28: Total puertos probados en el mes de Septiembre. 59

68 Cuadro 15: Puertos escaneados/probados. Septiembre Puerto Frec. Descrip. Puerto Frec. Descrip. tcp/ ssh tcp/ Simantec Antiv tcp/ http tcp/ HTTP Squid icmp/ echo reply tcp/ Apache Tomcat udp/ sip tcp/ smtp tcp/ microsoft-ds tcp/ telnet tcp/ netbios-ssn udp/ Norton Antiv tcp/ ms-sql-server tcp/ WBT tcp/ vnc tcp/ radmin tcp/ SOCKS proxy tcp/ domain Direcciones IP atacantes A continuación se presenta un top 30 de los equipos atacantes, en la siguiente captura: Figura 29: Direcciones IP atacantes - Septiembre. 60

69 Cuadro 16: IPs atacantes - Septiembre. IP Frec. País IP Frec. Cód. país br cn ec cn co cl pl br uk co br br fr cn cn ec cn co cn br cl uk us ug mx br ar fr cn co Análisis de los Reportes mensuales El tráfico de red que se genera a diario en servidores públicos o externos de una organización es de gran cantidad, debido a que están expuestos y pueden ser vistos de la internet, el total de conexiones, incluyendo los protocolos TCP, UDP e ICMP, reflejan la actividad y las conexiones que se establecen desde todas partes del mundo y la gran cantidad de direcciones IPs atacantes, al igual de los resultados obtenidos por la Honeynet clásica implementada en la UTPL. Los reportes estadísticos de la Honeynet Virtual en los meses de Agosto y Septiembre, contrastan en gran medida con los resultados recogidos por otros proyectos Honeynet alrededor del mundo, tal es el caso de la Honeynet implantada en la Massey University de Nueva Zelanda en el proyecto Building and Deploying a GenIII Virtual Honeynet 2009[27], en el caso de los puertos afectados por los atacantes, puesto que en los resultados obtenidos de un mes de recolección de tráfico, las observaciones muestran que de un total de puertos y servicios probados, estaban dirigidos al protocolo SSH, seguido por el protocolo tcp 80 de HTTP. Al igual que en la Honeynet implantada en la Escuela Politécnica del Litoral (ESPOL)[28], los resultados indican que el protocolo que genera más tráfico de red es el protocolo SSH, seguido del protocolo HTTP. Esto significa que existe mucha relación entre los resultados arrojados por las Honeynets virtuales implementadas y que han instalados tales aplicaciones, siendo el protocolo ssh a través del puerto tcp/22 el que más intentos de ataques registra, ya sea por hackers, black hat, script kiddies, crackers, etc., desde todas partes del mundo y presenta el mayor tráfico debido a la ejecución de scripts y/o herramientas automatizadas en la red, en busca de este puerto abierto y 61

70 poder lanzar el ataque común de diccionario o fuerza bruta para lograr acceder y apoderarse del equipo, por ello no se puede decir que en su totalidad las conexiones registradas se tratan de ataques o conexiones plenamente dirigidos. Con esto no se quiere decir que la seguridad sea deficiente en la UTPL, pero tampoco no se puede asegurar que ésta sea segura en su totalidad, ni tampoco que este puerto especificamente y los otros sean fáciles o difíciles de hackear, puesto que en cuestiones de seguridad y protección de la información siempre existe cierto grado de incertidumbre. Por estos motivos se deben tomar las medidas necesarias de seguridad para proteger este puerto, que como muestran los resultados es el blanco favorito de los atacantes de la red y lo que hace que cualquier equipo sea atractivo a los atacantes de cualquier parte del mundo Actividad en los servidores Servidor DNS El servidor DNS, ha sido el que más intentos y conexiones presenta, por tanto es el equipo que genera la mayor cantidad de tráfico de red ha generado, puesto que en este servidor se ha instalado el SSH. Protocolo SSH El puerto tcp 22, para SSH (Secure SHell), que es el protocolo que facilita las comunicaciones seguras entre dos sistemas utilizando una arquitectura clienteservidor el cual permite al usuario la conexión remota hacia un host y que utiliza encriptación en sus sesiones, con su especificación completa detallada en el RFC 4251, es el protocolo con el mayor número de conexiones registradas desde todas partes del mundo. Durante el mes de Agosto, las conexiones hacia este protocolo representaron el 88 % del total de conexiones hacia los puertos utilizados, teniendo en total intentos de conexiones. Para el mes de Septiembre, las conexiones hacia este mismo puerto, con una cantidad de 78705, representaron el 86 % de las conexiones totales hacia los puertos. Protocolo DNS EL Domain Name System/Service o Sistema de Nombres de Dominio, es el sistema el cual tiene la función principal de traducir (resolver) nombres inteligibles para los humanos en identificadores binarios asociados con los equipos conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos mundialmente. Se trata de una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como 62

71 base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los usos más comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio. El tráfico al servicio DNS es generado por las peticiones (request) que son enviadas, y se envían peticiones que requieren una búsqueda de DNS. El servidor DNS que recibe la petición, buscan en primer lugar si dispone de la respuesta en la memoria caché. Si es así, proporciona la respuesta; en caso contrario, inicia la búsqueda de manera recursiva. Una vez encontrada la respuesta, el servidor DNS guarda el resultado en su memoria caché para futuros usos y devuelve el resultado. Este servicio, con su aplicación principal (bind), que funcionan en el puerto tcp/udp 53, presentan una cantidad baja de conexiones hacia este servicio, siendo en un total de 13 conexiones en el mes de Agosto y de 549 conexiones en el mes de Septiembre, lo cual representa un 1 % del todal de conexiones en ese mes Servidor WEB Protocolo HTTP El puerto tcp 80, para HTTP (HyperText Transfer Protocol), es un protocolo cliente-servidor, el cual articula los intercambios de información entre los clientes Web y los servidores HTTP. La especificación completa de este protocolo se recoge en el RFC Con un total de 3958 conexiones en el mes de Agosto, que representan el 7 % del total de conexiones, se ubica como el segundo protocolo más utilizado por los atacantes hacia los servicios implementados. En el mes de Septiembre se registró un total de 5531 conexiones hacia el puerto 80, lo cual representa el 6 % del total, es así mismo en este mes el segundo de los protocolos utilizados por los atacantes. MYSQL Mysql es la base de datos generalmente empleada con las aplicaciones de servicio Web, el puerto de escucha por defecto es el 3306, puerto en el cual casi no han existido conexiones durante los meses de Agosto y Septiembre, teniendo una cantidad total de 30 conexiones registradas hacia este puerto Servidor EVA Protocolo HTTP Los puertos y aplicaciones de este servidor son casi iguales a las utilizadas en el Servidor Weben cuanto se refiere a conexiones en el puerto 80 y en el puerto 3306 del MySql, a diferencia que en este servidor se ha abierto tambien el puerto 8080 para los servicios de Apache-Tomcat. 63

72 En cuanto al puerto tcp 8080 abierto para Apache-Tomcat, los cantidad de registros de conexiones hacia este puerto son sumamente bajos, sumando un total de 124 conexiones en los meses de Agosto y Septiembre, representando una cantidad sumamente reducida Servidor WSUTPL En cuanto al WSUTPL, este implementa servidor IIS con las configuraciones por defecto, emplea al igual que el servidor Web el puerto tcp 80 para implementar sus servicios. Todos los servicios que por defecto se cargan de entornos Windows, no han sido modificados para que sean explotados por los atacantes: Puerto 135 (TCP) - para el Servicio de Remote Procedure Call (RPC). Puerto 137 (UDP) - para el Servicio de nombres de NetBIOS. Puerto 138 (UDP) - para Netlogon y Browsing de NetBIOS. Puerto 139 (TCP) - para la sesión (NET USE) de NetBIOS. Todos estos servicios y puertos han registrado tráfico en la Honeynet, pero en menor cantidad. De los puertos que se han abierto en este servidor, se puede registrar mayor cantidad de actividad en el puerto tcp 445 que es utilizado por el protocolo SMB (Server Message Block) para entre otras cosas el compartimiento de archivos en Sistemas Operativos Windows. Las conexiones hacia este puerto son en total de 131 en el mes de Agosto y de 253 en el mes de Septiembre, qie se tratan de cantidades considerablemente bajas Actividades registradas Alertas Snort. Snort es un IDS o Sistema de detección de intrusiones basado en red (NIDS) en tiempo real. Esta herramienta implementa un motor de detección de ataques y barrido de puertos que permite registrar, alertar y responder ante cualquier anomalía previamente definida como patrones que corresponden a ataques, barridos, intentos aprovechar alguna vulnerabilidad, análisis de protocolos, entre otras cosas. Los resultados de Snort y las alertas generadas, demuestran al protocolo ICMP como el protocolo más afectado, con mayor cantidad de intentos de acceso, debido a los rastreos que son realizados por los atancantes con herramientas automatizadas en busca de posibles equipos víctmas vulnerables para poder aprovecharse de estas. Como en la Honeynet clásica implementada en la UTPL, desarrollada en la tesis elaborada anteriormente, las alertas que genera Snort son casi las mismas, con esto se puede observar que las actividades de red apuntan o hacen match a las mismas reglas del Snort. A continuación se muestra un listado de las alertas ICMP más comunes generadas por Snort: 64

73 Cuadro 17: Alertas ICMP generadas por Snort. Alertas comunes en otros protocolos generadas por Snort: Cuadro 18: Alertas a otros protocolos generadas por Snort. Alerta ID Snort NETBIOS SMB-DS IPC$unicode share access 2465 WEB-CGI awstats access 3463 (portscan) TCP Portsweep SQL Worm propagation attemtp OUTBOUND 2003 (portscan) TCP Portscan WEB-GCI calendar access 882 SNMP AgentX/tcp request 1421 SNMP trap tcp 1420 SNMP request tcp 480 Así mismo, se tratan de casi las mismas alertas generadas por la Honeynet implantada en la Escuela Politécnica del Litoral (ESPOL), que en los [Anexos 8] se muestran a detalle estas alertas registradas por Snort, en base a la información de su página oficial[29] Ataques de diccionario al puerto ssh (port 22) La actividad hacía los servidores (honeypots) virtualizados, quedá registrada en los logs del sistema. A continuación se muestra uno de los intentos de intrusión a uno de los servidores, utilizando la técnica de diccionario al protocolo ssh. Como se puede observar, este tipo de ataques son muy ruidosos, por lo que su actividad queda registrada y los administradores pueden darse cuenta de ello con facilidad revisando los logs del sistema. El siguiente es un intento de acceso a través del protocolo ssh, desde un equipo de Brazil: 65

74 Figura 30: Ataque de diccionario al puerto 22 ssh A continuacio n se muestra el tra fico de red capturado con la herramienta Wireshark: Figura 31: Ataque de diccionario al puerto 22 ssh analizado con Wireshark Asi mismo, gracias a la interface GUI Walleye, todo e sta actividad queda 66

75 registrada para su posterior análisis: Figura 32: Ataque de diccionario al puerto 22 ssh registrado en la interface GUI Walleye Actividades maliciosas/sospechosas A continuación se hace referencia a algunas de las actividades maliciosas/sospechosas que se han dado en los honeypots, algunos hallazgos, ataques, herramientas, métodos, etc. Instalación de backdoors En unos de los Honeypots, se ha verificado la instalación de un programa backdoor, puerta trasera. Se trata de un Malware conocido como GodMessage. A continuación algunos detalles de este malware: Número de puerto: 7777 Protocolo utilizado: tcp/udp Tipo de servicio : cbt Figura 33: Instalación de un backdoor 67

76 Este malware abre una puerta trasera en un equipo comprometido para poderse loguear luego nuevamente. Abre una puerta trasera y escucha en los puertos ports 6868/tcp and 7777/tcp para la ejecución de comandos. Instalación de remoteware-cl RemoteShut Port Number: 3000 RemoteWare Client Protocol Used : tcp/udp Service Type : remoteware-cl Se trata de un malware conocido como Hallazgos y Actividades ocurridas A continuación se muestra un listado de algunas de las actividades que se han registrado durante los dos meses, en el Honeywall, que se pueden observar a través del análisis de los pcaps en la herramienta Wireshark: Principalmente, ataques SSH de fuerza bruta sobre el puerto TCP/22. Symantec Antivirus desbordamiento en el puerto TCP/2967. La actividad de varios gusanos en los puertos UDP/137, TCP/139 y TCP/445. Windows RPC desbordamiento de búfer en el puerto TCP/135. Windows Messenger spam en los puertos UDP/1026, UDP/1027 y UDP/1028. MSSQL desbordamiento de búfer en UDP/1434 puerto. Instalación de Malware, que utiliza conexiones IRC al puerto tcp Esta información y algunas de las actividades listadas, se corroboran con la información de los reportes generados en el Annual Status Report del The Pakistan Honeynet Project. Sitio oficial: Incidentes registrados Ataque DOS a la red de la UTPL Incidente El día Domingo 3 de Octubre, aproximadamente a las 18:30 de la tarde, se informa a los administradores de la red de la UTPL acerca de la ejecución de un ataque de red, de una de sus IPs. La causa de este incidente fué el comprometimiento de un equipo (honeypot) virtual, mediante el cual se generan ataques que inundan (flood) y colapsan la red de la UTPL, reflejada en el abundante tráfico mostrado en la herramienta de análisis de tráfico Netflow. 68

77 El incidente se produjo por el acceso al Honeypot(Linux) mediante el protocolo SSH, instalado y dispuesto con las configuraciones por defecto, se efectuó con éxito un ataque de fuerza bruta para encontrar la contraseña, que por motivos de investigación, era vulnerable voluntariamente. Hallazgos sobre el incidente A continuación se reporta algunos hallazgos sobre el incidente de seguridad. Alguna de las actividades y comprobaciones que se han realizado son la siguientes: Borrado de logs e inhabilitación de comandos. Se comprueba el borrado de los logs del sistema, a través del borrado del directorio: /var/log/wtmp, que es donde se aloja toda la información de accesos, login, etc., también se puede verificar la inhabilitación de ciertos comandos, como las herramientas de red (net-tools)y aplicaciones de encendido y apagado del sistema, tales como netstat, last, lastb, w, who, shutdown, reboot, etc. Puertos abiertos/utilizados. Se ha verificado los puertos que se han dejado abierto en el sistema, se observa el puertos 31337/tcp de servicio Elite abierto, por la instalación de aplicaciones maliciosas: Figura 34: Puerto que han sido abierto en el Honeypot comprometido. Aplicaciones instaladas. Las aplicaciones que han sido instaladas por el intruso son las siguientes: floobot.tar.gz Se trata de una aplicación, diseñada para inundar (flooding) programas-chat, este programa ataca canales de IRC con una carga masiva de datos insignificantes que generan tráfico para inundar y colapsar el canal. psybnc-linux.tgz Esta aplicación se trata de un bot IRC que tiene el propósito de controlar la máquina. El motivo de controlar la máquina comprometida mediante un bot IRC es poder utilizar la máquina sin conectarse directamente a ella, dejando de esta forma menos huellas; así como poder controlar todas las máquinas comprometidas simultáneamente desde un único canal IRC, e incluso con la capacidad de mantener la sesión abierta sin la necesidad de estar conectado. 69

78 Ya que se tiene el equipo comprometido, el destino de este servidor ha sido usado para enviar spam, además que pudo haber servido de plataforma para atacar a otras máquinas, usarlos como proxy, etc. Como medida para evitar que esto vuelva a suceder se deberá configurar un servidor SSH de forma segura. Acciones realizadas En primer lugar, al momento de detectar el incidente, los administradores de la red UTPL, inhabilitaron el punto del switch al que se conectaba el honeypot, seguidamente se puso fuera de producción la Honeynet temporalmente, hasta tomar las medidas necesarias, a más de sacar copias de la imagen de la máquina virtual a fín de ser analizada posteriormente. Pruebas de los Controles de Datos del Honeywall CONNECTION LIMITING Connection limiting es uno de los métodos de control de datos. Las conexiones salientes son contadas, y cuando ha alcanzado un cierto límite, se rechaza cualquier conexión saliente. Las configuraciones por defecto son las siguientes: Figura 35: Connection Limiting - Control de Datos. Prueba: Una de las formas para probar el funcionamiento de este Control de Datos del Honeywall, es mediante la realización de un ping extendido desde un honeypot. Las configuraciones por defecto de las conexiones salientes permitidas muestran un total de 50 como límite para las conexiones ICMP, esto quiere decir, que al momento de realizar el ping extendido, este se deberá bloquear al llegar 50 que es el límite. 70

79 Figura 36: Connection Limiting - Prueba de conexión. Esto no sucede así, por lo que a pesar de llegar al límite, las conexiones ICMP salientes no se bloquean y continúan, fallando así este control. VARIABLES FENCE LIST Otro de los controles de Datos del Honeywall es el uso de Fence List, es similar a una lista Negra/Blanca, la cual permite filtrar el tráfico a sistemas específicos o redes. Sin embargo, Fence List, no filtra conexiones entrantes a los Honeypots. En lugar de esto, Fence List, específica a que sistemas los Honeypots no pueden iniciar una conexión, esto es una medida de prevención de seguridad, usualmente para proteger sistemas críticos. A continuación se muestra el contenido del archivo fencelist.txt, en el cual se ha incluido la dirección IP del servidor web de la UTPL ( ), y se ha procedido a realizar un ping para comprobar si existe o no la conectividad: Figura 37: Fence List - Control de Datos. Resultado: Se ha podido realizar el ping satisfactoriamente hacia el servidor web de la UTPL, esto quiere decir que este control de Datos también no funcionó. 71

80 Figura 38: Fence List - Prueba de conexión. Conclusión sobre el incidente Con las observaciones realizadas se deduce que se hizo uso del protocolo SSH por medio de técnica de fuerza bruta o ataque de diccionario que se venía realizando anteriormente con bastante frecuencia para poder apoderarse de la máquina. Los Controlos de Datos del Honeywall fallaron, al permitir las conexiones salientes desde el Honeypot afectado y no fueron bloquedas permitiendo la realización exitosa del ataque. No se puede deducir a que sistemas o redes fueron afectados por el ataque lanzado debido a que se los log del sistema fueron borrados. No todas las configuraciones que utiliza el protocolo SSH real implementado en el servidor DNS real de la UTPL fueron utilizadas, por ejemplo, la instalación de la misma versión de ssh, por motivos de compatibilidad. Cabe señalar que el equipo que recolecta los paquetes de red Pcap ese fín de semana, es decir, los días Sábado 2 y Domingo 3 de Octubre, colapso debido a la gran cantidad de tráfico que se ha generado y existe el riesgo de que no se hayan recolectado paquetes de el día del ataque, puesto que fue en día Domingo y no se sacó el respectivo pcap, por ello es de suma importancia, la asignación del espacio de disco necesario e ir verificando constantemente que el espacio no se esté agotando, así mismo establecer políticas para descargas de pcaps diarias con el objetivo de mantener la información recolectada para el análisis posterior Patrones/comportamientos de ataques. En base a la información obtenida, al incidente y las actividades, podemos determinar que las acciones que toman los atacantes es la que comunmente siguen los hackers, es decir, los pasos y fases que involucran la anatomía de un ataque informático, descrito en[30]: 1. Reconocimiento (Reconnaissance): Es la fase donde se buscan las posibles vícitmas y se obtiene la información necesaria antes de lanzar algun ataque. El tráfico de red generado demuestra esto, en las conexiones que se dan a través de los mensajes icmp, que son respuesta a mensajes ping que son lanzados para reconocer los equipos que están levantados o en producción. 72

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

82 DISCUSIÓN, CONCLUSIONES, RECOMENDACIONES Y TRA- BAJOS FUTUROS 74

83 DISCUSIÓN En base al trabajo elaborado en este proyecto de fin de carrera, se ha podido obtener como resultados la experiencia alcanzada en el desarrollo de las tecnologías Honeynet y el aprendizaje obtenido ha sido muy importante para el desarrollo intelectual y académico en temas de seguridad informática, redes y telecomunicaciones, análisis de datos, etc. A pesar de que las tecnologías Honeynet abarcan una amplia gama de temas y los conocimientos son sumamente extensos forman un interesante campo en temas de seguridad y protección de la información de la cual se puede extraer mucha información y generar conocimiento acerca de los riesgos a los que están expuestos los sistemas computacionales. Para el desarrollo del proyecto, se abarcaron temas de mucho interés e importancia como lo son el trabajar con nuevas e innovativas herramientas de seguridad, el desarrollo de temas de virtualización, diseño de redes, implementación de servicios y servidores, trabajo con plataformas Linux y Windows, el análisis de tráfico, uso de herramientas de red, estudio de vulnerabilidades, análisis forense, entre otros, los cuales permitieron darle forma y poder culminar el proyecto. Como en cualquier proyecto, existieron facilidades e inconvenientes en el desarrollo del mismo. En cuanto a las facilidades prestadas por los administradores de los servidores, de los cuales se obtuvo la información para evaluar la criticidad de los servicios externos a implementar en los Honeypots de la Honeynet, así tambien a los administradores de red, que facilitaron y agilitaron el trabajo en cuanto a asignación de recursos necesarios para implementar la estructura Honeynet Virtual. También los inconvenientes que se dieron a lo largo del desarrollo del proyecto, como el trabajo realizado en un equipo de pruebas, y la demora en la entrega del equipo propio, hicieron también que el trabajo se retrase un poco. Problemas propios del proyecto como lo fue la instalación de la herramienta de captura de tráfico: Sebek, debido a su reducido soporte y poca asistencia por parte de proyectos honeynets de varias partes del mundo. Por ello se vió obligado el cambio de plataformas, por aquellas que den soporte a la herramienta Sebek, como lo es Ubuntu 7.10 Server para Linux y Windows XP Profesional para plataformas Windows. Los resultados que arroja la implementación de esta Honeynet Virtual, son un aporte para la investigación y el desarrollo de la seguridad dentro de la UT- PL, sus resultados contrastan en gran medida con los resultados de la Honeynet clásica implementada en la UTPL y de la ESPOL y de otros proyectos similares alrededor del mundo, tal como el proyecto Honeynet de la Massey University de Nueva Zelanda, Honeynet.br de Brasil, el proyecto Honeynet de la UNAM de Mexico, Honeynet.pk de Pakistan, donde concluyen que el puerto más afectado es el puerto tcp/22 y las direcciones origen atacantes son de países principalmente de Asia y Europa. Gracias a la recolección de los datos se puede tener una idea más clara del nivel de exposición de los servicios externos de la UTPL, y sus servicios en la web. 75

84 A pesar de que el tiempo de recolección de datos fue corto, se puede decir que fue el suficiente para poder capturar y analizar el tráfico de red y las actividades maliciosas para su posterior análisis, sin embargo, para poder armar un perfil o un patrón de comportamiento con mayor grado de precisión sería conveniente el análisis de datos recolectados en un periodo mucho más largo de tiempo. Ahora, lo que se pretende es abrir nuevos campos en la investigación acerca de las Honeynets como herramienta de seguridad informáticas y explotarla para obtener el mayor conocimiento que puede brindar, también aperturar nuevos temas de investigación para trabajos futuros dentro de la UTPL. 76

85 CONCLUSIONES Conclusiones inherentes a la Honeynet: Debido a que los Honeypots implementados y ubicados en la red externa actúan como sensores, la cantidad de tráfico de red que se genera en estos es sumamente elevada, con un estimado diario de paquetes entrantes por paquetes de salida, éste tráfico que es capturado por la Honeynet Virtual ocupa gran cantidad de espacio diariamente en el Honeywall. La gran cantidad de tráfico de red recolectado, y la total de paquetes registrados a diariamente, nos indica la accesibilidad y la acogida de la Honeynet en la internet, asi como el nivel de exposición de los servicios críticos externos implementados en la misma, a través de escaneos automatizados, ejecución de scritps, herramientas de rastreo y descubrimiento, etc. El tráfico que se ha capturado, muestra que el puerto 22 de ssh, con una cantidad total de conexiones en los dos meses de recolección de datos, y que representa aproximadamente 87 % de la conexiones totales en ese lapso de tiempo, es el blanco favorito de atacantes, hackers, black hat, script kiddies, crackers, etc., por simplicidad o porque quizás este sea el ataque más difundido y fácil de ejecutar por cualquier internauta y que no requiere de amplios conocimientos, sin embargo, esto no significa que los otros puertos y protocolos estén libres de ataques. Según los resultados, el puerto tcp 80 de HTTP, se convierte en el segundo puerto favorito de los atacantes, para aprovecharse de los sitios web mal configurados o vulnerabilidades que pudieran tener los mismos, con el objetivo maliciosos de robar o alterar información importante, a través de ataques phishing (suplantación de identidad), o por el simple hecho de dejar fuera de funcionamiento un sitio web ya sea por ego o por medir sus conocimientos y habilidades. Los resultados obtenidos nos muestran el siguiente TOP 3 de protocolos afectados, donde la mayor cantidad de tráfico que se ha generado es hacia el puerto tcp 22 de ssh con un 87 % del total del conexiones, seguidamente el puerto tcp 80 de http, el cual representa un 7 % del total de conexiones y seguidos de estos, el protocolo icmp con mensajes de respuesta hacia peticiones icmp (type 0 Echo reply) con un 4 % del total de conexiones. Esto se debe a que en la internet existen equipos automatizados que realizan barridos de direcciones y puertos para poder identificar y explotar las vulnerabilidades de los equipos y por ello se generan estas alertas a estos protocolos. Los datos recolectados en el periodo de dos meses aproximadamente, el tráfico generado y los resultados que arroja la implementación de esta 77

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

87 cuales son: 1. Reconocimiento, 2. Escaneo, 3. Ganar el acceso, 4. Mantener el acceso, 5. Cubrir huellas; a través de técnicas y uso de herramientas, por ello depende en gran medida de los conocimientos del atacante y de su habilidad y experiencia para que el ataque sea o no exitoso. Las conexiones y el tráfico que se ha capturado en los resultados, nos indican de que con el solo hecho de implementar y hacer uso de servicios y protocolos de red, los servidores de la UTPL son monitoreados, observados y visitados desde cualquier parte del planeta, especialmente al hacer uso de servicios tradicionales y habituales, como HTTP y SSH que los hacen atractivos al resto del mundo. A través de los resultados obtenidos, no se quiere decir que el nivel de la seguridad sea deficiente en la UTPL, pero tampoco no se puede asegurar que éste sea segura en su totalidad, ni tampoco que el puerto tcp/22 de ssh especificamente y los otros sean fáciles o difíciles de hackear, puesto que en cuestiones de seguridad y protección de la información siempre existe cierto grado de incertidumbre. Pese a que se logró capturar y analizar el tráfico de red y las actividades maliciosas hacia los servidores implementados, el corto lapso de tiempo de recolección de datos dificultó armar un perfil o patrón de comportamiento con mayor precisión y exactitud. 79

88 RECOMENDACIONES La arquitectura de la Honeynet a implementar se debe escoger en base a los recursos que se tenga disponibles y la que mejor se adapte a los requerimientos del proyecto, tomando en cuenta también aspectos importantes como la ubicación en la red, la seguridad, los riesgos, etc. El equipo anfitrión (host), debe ser un equipo robusto capaz de dar soporte a una red de honeypots, asi también como al Honeywall, siendo éste, el elemento que más recursos consumen en cuanto a espacio en disco se refiere, por cuanto, el espacio de disco que fue asignado para el proyecto fue de 160 Gb aproximadamente, el cual saturó en el lapso de dos meses. Es importante que los administradores de servidores que implementan aplicaciones como SSH, controlen el límite de las conexiones a estos puertos que son permitidas y su configuración correcta, para evitar posibles ataques. Revisar el estado de todos los elementos de la Honeynet Virtual, en especial el correcto funcionamiento del Honeywall, ya que este se puede saturar con facilidad debido a la gran cantidad de conexiones que se registran. Si el espacio en disco que se le ha asignado al equipo Honeywall se completa, a pesar de que la Interface Walleye esté aun en funcionamiento, ya no se registrarán los pcaps correctamente. Se debe buscar seguir promoviendo y explotando las tecnologías Honeynets con la finalidad de servir de apoyo y ayuda a las organizaciones para conocer los riesgos y los peligros a los que están expuestos en la internet, ésto se da a través de la captura y análisis del tráfico que ha capturado la Honeynet. Para el análisis y la interpretación de los resultados, se requiere de vastos conocimientos y habilidades en temas de redes, protocolos, configuraciones, servidores, sistemas operativos, etc., para poder definir, interpretar e identificar correctamente cuando se trate de un comportamiento anómalo y poder sacar las conclusiones correctas y adecuadas del tráfico capturado. Las Honeynets como herramientas nuevas, cubren un amplio campo dentro de la seguridad informática, y sería recomendable el estudio y análisis de los componentes del Honeywall Roo como una nueva plataforma o sistema operativo, su forma de operar, sus versiones, su funcionamiento, sus ventajas, desventajas, las limitaciones, etc., como una manera de buscar sacar el máximo provecho a esta herramienta. Utilizar varias herramientas para el análisis del tráfico de manera que se pueda permitir el entendimiento del comportamiento y poder sacar las conclusiones correctas en base a los resultados que estas arrojen. 80

89 Para una mayor comprensión de los incidentes, intentos de ataques, comprometimientos, etc., es necesario dedicar gran la mayor cantidad de tiempo posible para analizar los datos recogidos por la Honeynet, puesto que la información que se recoge es abundante. Puesto que se ha comprobado el riesgo de utilizar esta técnología, debido a los Controles de Datos, se sugiere el ensayo de la implementación de Honeynets Híbridas, que ha diferencia de la Honeynet auto-contenida, el uso de dispositivos reales puede ayudar al mejoramiento del Control de Datos y poder mitigar los riesgos. Los resultados de la Honeynet auto-contenida nos muestran que se trata de una herramienta de ayuda para el mejoramiento de la seguridad, a pesar de los riesgos encontrados, puede servir de apoyo al tratarse de una herramienta de seguridad, como un sniffer a gran escala, y que serviría para el análisis del tráfico de red que puede capturar. Mantener contacto con los administradores de la red, alertar y dar avisos oportunos sobre posibles comportamientos anómalos en la red a fín de evitar posibles daños, pasando la información obtenida a través de informes para su posterior manejo. Es recomendable una administración global centralizada, esto se puede lograr a través de la utilización de la virtualización, puesto que todos sus componentes y elementos se encuentran incorporados en un solo equipo anfitrión. No olvidar documentar hechos o incidentes que se hayan producido y reportarlos a las personas responsables o encargadas. Se debe tener un respaldo de seguridad de toda la información, sacarle copias de las imágenes de la máquinas virtuales, con el fín de poder restablecer la Honeynet en caso de caídas. Establecer como política, el obtener y descargar los pcaps diariamente con los registros del tráfico de red, esto con la finalidad de tener esta información de apoyo para análisis forense. Uno de los principales componentes de una Honeynet, la interface web Walleye, no es una interface al ciento por ciento eficaz, puesto que presenta frecuentemente caídas y funcionamiento irregular, es por ello que no se puede depender solamente de esta interface para visualizar gráficamente lo que está ocurriendo con el tráfico en la red. Si bien, se logró obtener resultados de las actividades de red de los servicios críticos externos de la UTPL, para poder armar un perfil o un patrón de comportamiento malicioso con mayor precisión, es recomendable la recolección de datos de un periodo mucho más prolongado de tiempo y un seguimiento más a detalle y a profundidad de los datos recolectados. 81

90 TRABAJOS FUTUROS La culminación del presente proyecto abarca una gran cantidad de temas, aspectos y conceptos de seguridad de redes, que serían conceptos relativamente nuevos que están en evolución permanente. Una de las maneras de buscar el desarrollo y mejoramiento de los resultados de las tecnologías Honeynet es la investigación de las Honeynets distribuidas, las cuales se tratan de infraestructuras abiertas de redes trampa, que permite la colaboración entre administradores de red y analistas de datos, esto permite, a los proyectos honeynet trabajar conjuntamente y aprender acerca de los ataques globales al tiempo que se garantiza la integridad de los datos. Si bien el proyecto The Honeynet Project ha construido herramientas comunes para la recopilación de datos IDS y análisis, no se proporciona un paquete completo y un plan de colaboración. Como parte de este desarrollo de Honeynets Virtuales, ya existe el proyecto: The Distributed Honeynets Project, que es el proyecto de investigación relativamente nuevo. El proyecto de Honeynets distribuidas se estableció como ayuda a los administradores de red aplicar un enfoque coordinado del sistema de detección de intrusos mediante el uso de software de código abierto con el beneficio de análisis de datos de colaboración y el intercambio de alertas de red. 82

91 Referencias [1] The honeynet Project, Know Your Enemy: Honeynets (en línea), Disponible en: [2] Conoce a tu enemigo: Redes trampa en universidades, Disponible en: [3] GSI-FING (2007) Título: Honeypots (parte I) [4] Conoce a tu enemigo: Honeynets (en línea), Disponible en: [5] Traap Jorge, Titulo: ICIHONEY: Diseño e Implementación de una Red Trampa en el Instituto de Informática de la Universidad Austral de Chile [6] The honeynet Project, Conoce a tu enemigo: Definiendo honeynets virtuales (en línea), Disponible en: [7] Montalván Henry, Titulo: Estudio de tráfico de ataques a la red de la UTPL mediante la implementación de un prototipo de Honeypot [8] The honeynet project, Honeywall CDROM (en línea), Disponible en: [9] Conoce a tu enemigo: Honeywall CDROM (en línea) Disponible en: [10] Romero L. Mayra, Titulo: PCN: Plan de continuidad de negocio, 2002 [11] Seguridad Informática, Masiva actualización coordinada de servidores DNS: Grave vulnerabilidad en la implementación del protocolo que sustenta Internet (en línea) Disponible en: [12] CSIRT, Gestión de Incidentes de Seguridad Informática y Telecomunicaciones, (en línea) Disponible en: [13] Inteco CERT, Título: Vulnerabilidad en Apache Tomcat (CVE ). (en línea) Disponible en: [14] Inteco CERT, Título: Vulnerabilidad en JE Event Calendars (com jeeventcalendar) para Joomla! (CVE ) (en línea) Disponible en: [15] Inteco CERT, (en línea) Disponible en: [16] Wikipedia, Titulo: Virtualización, (en línea) Disponible en: 83

92 [17] Federación de enseñanza de CC.OO. de Andalucia, Titulo: Temas para la Educación, (en línea), Disponible en: [18] Lugo Yuli, Titulo: Mantenimiento de equipos de cómputo, (en línea) Disponible en: DE-REDES [19] Slice of Linux, Titulo: Qué es la virtualización?, (en línea), Disponible en: %C2 %BFque-es-lavirtualizacion/ [20] Wikipedia: VMware, (en línea) Disponible en: [21] Carbonwind, Titulo: VMware Server Networking Options, (en línea) Disponible en: [22] Balas Edward, Viecco Camilo, (2005) Titulo: Towards a Third Generation Data Capture Architecture for Honeynets [23] The Honeynet project, Titulo: Sebek, (en línea), Disponible en: [24] Prado Javier, Jones Heather, Título: Building a Heterogeneous Honeynet [25] Siles Raúl, Titulo: Honeynets, Conoce a tu enemigo [26] The Honeynet project, Titulo: Conoce a tu enemigo: Aprender con VMware, (en línea) Disponible en: [27] Massey University, Título: Building and Deploying a GenIII Virtual Honeynet, Disponible en: [28] Aviles Jorge, Pazmiño Mayra, Título: CAPTURA Y ANÁLISIS DE LOS ATAQUES INFORMÁTICOS QUE SUFREN LAS REDES DE DATOS DE LA ESPOL, IMPLANTANDO UNA HONEYNET CON MIRAS A MEJORAR LA SEGURIDAD INFORMÁTICA EN REDES DE DATOS DEL ECUADOR, Disponible en [29] Snort, (en línea) Disponible en: [30] Monroy Lopez Daniel, Título: ANÁLISIS INICIAL DE LA ANATOMÍA DE UN ATAQUE A UN SISTEMA INFORMÁTICO México D.F

93 ANEXO 1 Inventario de los servidores críticos externos de la red de la UTPL. ID Servidor Administrador DIR IP DIR PUBLICA Dependencia Descripción Sistema Operativo Entorno 7 BDVIRTUAL Rodrigo Patricio Lopez X.X X.X Unidad de Virtualización Servidor de Base de Datos del EVA_x000D_ Base de datos de EVA externos_x000d_ Base de Datos de Dspace_x000D_ Base de datos de Wordpress y Joomla_x000D_ Mysql_x000D_ PostgreSql Producción Rodrigo Patricio Unidad de 20 EVA Lopez X.X X.X Virtualización Servidor Web de EVA Centos Producción GDR1.UTPL.E Gestión del 22 DU.EC Ramiro Ramírez X.X X.X Conocimiento Web Centos 4.4 Producción GDR1BACK.UT Diana Alexandra Gestión del 23 PL.EDU.EC Torres Guarnizo X.X X.X Conocimiento Web respaldos Centos 5 Producción 24 GDR2 Ruperto Alexander López Lapo X.X Grupo de Telecomunicaciones DNS extreno Centos Producción INTRANETCIT INTRANET CITTES MODULO DE PROYECTOS Y REPOSITORIOS DE Windows 34 TES Ana Lucia Abad X.X X.X Dir. G CITTES DATOS 2003 Server Producción 38 MX1 Ruperto Alexander López Lapo X.X X.X Grupo de Telecomunicaciones Servidor Antispam Slackware 12 Producción 39 MX2 Ruperto Alexander López Lapo X.X X.X Grupo de Telecomunicaciones Servidor Antispam Slackware 12 Producción Juan Carlos Grupo de Desarrollo Servidor de Backup del cajanuma. Actualmente es utilizado 44 PALTAS Morocho X.X X.X de Software para entorno de pruebas con la base de datos Oracle Solaris Pruebas Unidad de Video SErvidor de Aplicaciones. Encuesta, Agenda, Pedido de Videos Windows 49 PRODUCCION Rodrigo Barba X.X Conferencias en Linea. Meeting 2003 Server Producción 52 SIGSERVER Víctor González X.X X.X Sistemas de Información Servidor Wed de Sistemas de información Geográfica, con servicio de servidor de mapas y base de datos espaciales, Windows 2003 Server Producción

94 55 SUNBLADE2 Juan Carlos Morocho X.X X.X 61 VIDEOCONTV Rodrigo Barba X.X 65 VPN Julia Pineda X.X X.X Ruperto Alexander 66 WEBMAIL López Lapo X.X X.X 67 WSUTPL Viviana Montaño X.X X.X Geográfica Grupo de Desarrollo Estación de trabajo utilizada como servidor. Base de datos para de Software las Academias Solaris Producción Unidad de Video Transmisión de TV por internet. Unidad de videoconferencias Conferencias UTPL Win XP Producción Grupo de Telecomunicaciones Servidor de VPN y Netflow Ubuntu Producción Grupo de Telecomunicaciones Frontal del servidor Mail Centos Producción Grupo de Desarrollo Servidor Internet. Servicios en línea: centros, docentes, Windows de Software matrícula en línea 2003 Server Producción

95 ANEXO 2 En los siguientes se muestran las encuestas realizadas a los Administradores de los Servidores Críticos Externos y las encuestas realizadas a los Líderes de cada Grupo en los que se administran dichos servidores. PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a Líderes de Grupo. El objetivo de la presente encuesta es la recolección de información relevante y actualizada acerca de los servidores/servicios para el análisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: DNS Externo - Qué servicio ofrece? Servidor de Nombres de Dominio. - El servidor se encuentra en producción: SI( x ) NO( ) - A que dependencia pertenece: UPSI GTE - Como cataloga el nivel de criticidad del servicio/servidor Alto( x ) Medio( ) Bajo( ) - Número de usuarios del servicio: Toda la red UTPL. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( x ) Medio ( ) Leve( ) Por qué? Si este servicio falla no se tendría acceso a ciertos dominios en la red, las direcciones de cierto dominio se podrían reconocer como no validas y con ello no se podrán realizar las actividades diarias, provocando pérdidas y molestias en los usuarios. - Interactúa con otros sistemas? SI( x ) NO( ) - Cuáles? o Web o Webmail

96 Hardware/Equipo: Procesador Memoria RAM Pentium IV 3GHz 1 Gb Software: Servicio: Red: Sistema Operativo/Plataforma Linux Distribución Centos Versión 5.4 Kernel Aplicación Bind Versión Parches / actualización P1.el5_4.1 Puertos abiertos 53 UDP/TCP - dns 22 TCP - ssh Otras aplicaciones instaladas Servidor ssh Nombre del servidor Dirección IP4 externa/pública Dirección IP6 externa/pública Ubicación en la red gdr2.utpl.edu.ec X.X 2800:.X.:X.X:.X.X:.X/XX Red externa, junto al router de borde Seguridad - Parches/actualizaciones instaladas para dicho servicio o sistema operativo El servidor y las aplicaciones se encuentran actualizados con las últimas versiones y parches de seguridad. Flujo de datos: No se tiene un flujo exacto de tráfico de red, puesto que este equipo no se está monitoreando aún en el NOC-UTPL, pero se tiene previsto su monitoreo lo más pronto con la herramienta Argus. Información Adicional: Administrador: Ing. Alexander Lopez Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

97 PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a Líderes de Grupo. Luego de realizar un análisis acerca de los servicios críticos externos de la UTPL, se ha recolectado cierta información por parte del administrador, que necesita ser corroborada por ud(s), como líder del grupo en el que se encuentra o se administra el servidor en producción, para verificar si estos servicios externos son realmente críticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera más objetiva: SERVIDOR: Servidor DNS Externo gdr2.utpl.edu.ec - Cómo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Alto ( X ) Medio ( ) Bajo ( ) Por qué? Porque es el registro de los nombres de Dominio de la UTPL. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( ) - Cuál cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable ( ) Moderada ( ) Esporádica (X ) Nunca ( ) - Qué pasaría si el servicio deja de funcionar (indisponibilidad) y cómo cree que afectaría a las actividades de la Universidad? Desde el exterior no se podrán resolver los nombres de Dominio de la UTPL Internamente existen los DNS s internos.

98 - Considera Ud. que el servidor DNS Externo (gdr2.utpl.edu.ec), es un servicio muy crítico e imprescindible para la Universidad? SI ( X ) NO ( ) - Considera Ud. algún otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI ( X ) NO ( ) Cuáles? 1. Acceso a Internet (Servicios) 2. Frontal Web de acceso al correo electrónico Por qué? 1. Todas las actividades hacia el exterior se paralizarían. 2. Si el frontal está fuera de servicio nadie pudiera acceder al correo mediante el navegador. - Información adicional Gracias por su colaboración Ing. Carlos Córdova Líder del Grupo de Telecomunicaciones Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

99 PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a Administradores. El objetivo de la presente encuesta es la recolección de información relevante y actualizada acerca de los servidores/servicios para el análisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: Servidor WEB (GDR1) - El servidor se encuentra en producción: SI( X ) NO( ) - Qué servicio(s) ofrece? Servicio Web de la UTPL. - A que dependencia pertenece: Gestión del Conocimiento - Interactúa con otros sistemas? SI( X ) NO( ) - Cuáles? o Servidor Oracle. - Número de usuarios del servicio: Mayor a mil. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( ) - Qué pasa si el servicio deja de funcionar (indisponibilidad) y cómo cree que afectaría a las actividades de la Universidad? No se podría acceder al servicio Web que ofrece la UTPL para estudiantes presenciales y de la modalidad a distancia, así también como docentes y administrativos. Hardware/Equipo: Procesador Memoria RAM IBM 1.6 GHz 10 Gb Software:

100 Sistema Operativo Linux Distribución Centos Versión 4 Kernel 2.6 Parches/actualización Servicio: Aplicación principal Apache Versión 2.6 Otras aplicaciones instaladas - MySQL 5 (Versión) - PHP Cliente Oracle Wordpress - Webmin - Sendmail - Squirrelmail - Joomla - Drupal Puertos abiertos 80 http Parches/actualización Red: Nombre del servidor Dirección IP4 externa/pública Dirección IP6 externa/pública Ubicación en la red gdr1.utpl.edu.ec X.X 2800:XX:XX:XX:XX:XX:XX:XX Información Adicional: Tiempos críticos en tiempos de matriculas. Administrador: Ing. Ramiro Ramirez Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

101 PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a Líderes de Grupo. Luego de realizar un análisis acerca de los servicios críticos externos de la UTPL, se ha recolectado cierta información que se necesita ser corroborada por ud(s), como líder del grupo en el que se encuentra o se administra el servidor en producción, para verificar si estos servicios externos son realmente críticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera más objetiva: SERVIDOR: WEB gdr1.utpl.edu.ec - Cómo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Por qué? Alto ( X ) Medio ( ) Bajo ( ) Es el acceso a la información, la presencia de la UTPL EN LA Web, además de ser la puerta de acceso a otros servicios. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( ) - Cuál cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable ( ) Moderada ( ) Esporádica (X ) Nunca ( ) - Qué pasaría si el servicio deja de funcionar (indisponibilidad) y cómo cree que afectaría a las actividades de la Universidad? Se perdería el acceso a otros servicios como EVA, SGA. Los estudiantes, docentes y administrativos no podrían utilizar las herramientas web disponibles. - Considera Ud. que el servidor Web (gdr1.utpl.edu.ec) externo, es un servicio muy crítico e imprescindible para la Universidad? SI (X ) NO ( )

102 - Considera Ud. algún otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI () NO (X ) Cuáles? Por qué? - Información adicional Gracias por su colaboración Ing. Germania Rodríguez Líder del grupo de Gestión del Conocimiento. Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

103 PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a los Administradores. El objetivo de la presente encuesta es la recolección de información relevante y actualizada acerca de los servidores/servicios para el análisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: Servidor EVA Entorno Virtual de Aprendizaje - El servidor se encuentra en producción: SI( X ) NO( ) - Qué servicio(s) ofrece? Servicio Web del EVA, Repositorio de Aprendizaje DSPACE. - A que dependencia pertenece: Unidad de Virtualización y Video Conferencia. - Interactúa con otros sistemas? SI( X ) NO( ) - Cuáles? o Sistema Académico SGA. - Número de usuarios del servicio: 67000, entre activos y no activos. - Como cataloga el nivel de criticidad del servicio/servidor? Por qué? Alto ( X ) Medio ( ) Bajo ( ) Por las actividades, tareas, evaluaciones, mensajes que se translimiten mediante este medio a los estudiantes de cada una de las materias. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( X ) Medio ( ) Leve ( ) - Qué pasa si el servicio deja de funcionar (indisponibilidad) y cómo cree que afectaría a las actividades de la Universidad? Es imprescindible este servicio, puesto que es también la puerta de entrada a otros servicios.

104 Hardware/Equipo: Procesador Memoria RAM Dual Core 1.3 GHz 8 Gb Software: Sistema Operativo Linux Distribución Centos Versión 5.2 Kernel Parches/actualización Servicio: Aplicación principal Apache Versión 2.6 Otras aplicaciones instaladas Tomcat (Versión) Puertos abiertos Parches/actualización 80 - http tomcat Red: Nombre del servidor Dirección IP4 externa/pública Dirección IP6 externa/pública Ubicación en la red eva.utpl.edu.ec X.X Red externa, junto al router de borde Información Adicional: Los tiempos en los que el servicio es aún más crítico es en tiempo de matriculas, subida y consulta de notas, envío de trabajos, llegando en algunas veces a saturarse el servidor. Se tiene 650 conexiones concurrentes al servidor. Administrador: Ing. Rodrigo López Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

105 PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a Líderes de Grupo. Luego de realizar un análisis acerca de los servicios críticos externos de la UTPL, se ha recolectado cierta información que se necesita ser corroborada por ud(s), como líder del grupo en el que se encuentra o se administra el servidor en producción, para verificar si estos servicios externos son realmente críticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera más objetiva: SERVIDOR: Entorno Virtual de Aprendizaje - EVA eva.utpl.edu.ec - Cómo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Alto (X) Medio ( ) Bajo ( ) Por qué? Hay 500 usuarios concurrentes que usan los servicios de la UTPL. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( ) Medio (X ) Leve ( ) - Cuál cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable ( ) Moderada (X ) Esporádica ( ) Nunca ( ) - Qué pasaría si el servicio deja de funcionar (indisponibilidad) y cómo cree que afectaría a las actividades de la Universidad? Los estudiantes no tendrían acceso a servicios y el call center se congestionaría. - Considera Ud. que el servidor Eva (eva.utpl.edu.ec) externo, es un servicio muy crítico e imprescindible para la Universidad? SI (X ) NO ( )

106 - Considera Ud. algún otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI (X ) NO ( ) Cuáles? Correo electrónico Por qué? Es uno de los medios de comunicación de la UTPL. - Información adicional Gracias por su colaboración Ing. Juan Carlos Torres Líder de la Unidad de Video Conferencia y Virtualización Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

107 PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a Administradores. El objetivo de la presente encuesta es la recolección de información relevante y actualizada acerca de los servidores/servicios para el análisis de su nivel de importancia y criticidad dentro de la UTPL. Solicitamos su ayuda respondiendo a las siguientes preguntas: SERVIDOR: Servidor WSUTPL - El servidor se encuentra en producción: SI( X ) NO( ) - Qué servicio(s) ofrece? Servicios de notas y consultas de saldos. - A que dependencia pertenece: Grupo de Desarrollo de Software - Interactúa con otros sistemas? SI( X ) NO( ) - Cuáles? o Sistema Académico SGA. - Número de usuarios del servicio: Docentes, administrativos y alumnos de la modalidad clásica y abierta de la UTPL. - Como cataloga el nivel de criticidad del servicio/servidor? Por qué? Alto ( X ) Medio ( ) Bajo ( ) Por las actividades, tareas, evaluaciones, notas, saldos, no podrían ser vistos ni por alumnos ni docentes, afectando esto principalmente a la Modalidad Abierta de la UTPL. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave ( ) Medio ( X ) Leve ( ) - Qué pasa si el servicio deja de funcionar (indisponibilidad) y cómo cree que afectaría a las actividades de la Universidad? Los servicios como Consulta de Notas, de saldos, no se podrían visualizar.

108 Hardware/Equipo: Procesador Memoria RAM Intel(R) Xeon(R) CPU 51103GHZ 3.25 GB Software: Sistema Operativo Distribución Versión/Edición Kernel Parches/actualización Windows Windows 2003 Server Enterprise Servicio: Aplicación principal IIS Versión 6 Otras aplicaciones instaladas (Versión) Puertos abiertos 80 - http Parches/actualización Red: Nombre del servidor Dirección IP4 externa/pública Dirección IP6 externa/pública Ubicación en la red wsutpl.utpl.edu.ec X.X Red externa Información Adicional: Administrador: Ing. Viviana Montaño Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

109 PROYECTO DE FIN DE CARRERA Estudio de tráfico malicioso en los servicios críticos externos de la UTPL Entrevista a Líderes de Grupo. Luego de realizar un análisis acerca de los servicios críticos externos de la UTPL, se ha recolectado cierta información que se necesita ser corroborada por ud(s), como líder del grupo en el que se encuentra o se administra el servidor en producción, para verificar si estos servicios externos son realmente críticos para el departamento y para la UTPL. Por tal motivo, solicitamos su ayuda respondiendo a las siguientes preguntas de la manera más objetiva: SERVIDOR: Servidor Internet. Servicios en línea: centros, docentes, matrícula en línea. wsutpl.utpl.edu.ec - Cómo cataloga el nivel de criticidad del servicio/servidor para la Universidad? Por qué? Alto (X ) Medio ( ) Bajo ( ) El servicio de matriculación de estudiantes de la Modalidad Clásica y Abierta dependen de este servidor. - Nivel de Importancia/Impacto si el servidor/servicio falla: Grave (X ) Medio ( ) Leve ( ) - Cuál cree Ud. que sea la probabilidad de que el servicio/servidor falle? Muy probable ( ) Probable (X ) Moderada ( ) Esporádica ( ) Nunca ( ) - Qué pasaría si el servicio deja de funcionar (indisponibilidad) y cómo cree que afectaría a las actividades de la Universidad? No se podrían realizar procesos de matriculación, afectaría de manera grave a la operatividad de la UTPL.

110 - Considera Ud. que el servidor wsutpl.utpl.edu.ec externo, es un servicio muy crítico e imprescindible para la Universidad? SI (X ) NO ( ) - Considera Ud. algún otro servicio/servidor externo, de su departamento como importante y relevante para la Universidad? SI (X ) NO ( ) Cuáles? Todos los servidores de acceso al Sistema Académico y sus relacionados, ya sea de manera interna o externa. Por qué? La operatividad diaria de procesos académicos y financieros relacionados no podrán realizarse. - Información adicional Gracias por su colaboración Ing. Diego Plascencia Líder del Grupo de Desarrollo de Software Tesista: César A. Montalván C. camontalvanx@utpl.edu.ec

111 ANEXO 3 A continuación se muestran capturas del tráfico que se registra con las herramientas del Sistema de Monitoreo de la UTPL NOC, Cacti y Netflow, en cuanto se refiere al tráfico de entrada y salida que se genera en los servidores de las red UTPL. La siguiente figura muestra una captura con la herramienta de monitoreo Cacti, donde se registra la actividad de red del servidor DNS Externo. Servidor DNS Externo Dirección IP: 200.X.X.X Tráfico de red del servidor DNS. Como se puede observar, el tráfico semanal empieza desde el 18 de Marzo que es donde se ha empezado a monitorear el servidor. El tráfico de red promedio registrado desde el 28 de Marzo es de 2,93k de salida y de 1,74k de entrada. Para poder analizar el comportamiento del tráfico de red se ha utilizado el Netflow haciendo uso de la interfaz WAN que es donde se registra la actividad de los servidores externos. Según las respuestas de las encuestas realizadas a los administradores de los servicios, los tiempos de sobrecargo o de saturación son generalmente se da en tiempos de matriculas, que es donde los servidores presentan mayor tráfico.

112 Las siguientes capturas son tomadas de una semana, desde el 12 al 18 de Marzo con Netflow de los servidores críticos. Servidor Web Dirección IP: 200.X.X.X Como se puede observar en la figura, el tráfico que se ha generado en una semana es de 8.8 GB ubicando a este servidor entre los que generan más tráfico de red. Servidor EVA Dirección IP: 200.X.X.X

113 Servidor WSUTPL Dirección IP: 200.X.X.X

114 Actividad diaria de los servidores, registrada por Netflow: Día: Lunes, 5 de Abril del Hora: de 15:05 a 16:05 Día: Martes, 6 de Abril del Hora: de 14:07 a 15:07

115 ANEXO 4 Instalación y configuración de Honeywall roo-1.4.hw-2009 Una vez descargado Honeywall roo-1.4.hw-2009 de la web, procedemos a quemarlo en un CD bootable. Arrancamos la máquina virtual, y el instalador del Honeywall iniciará el proceso de Instalación: 1. Pantalla de inicio 2. Copia e instalación de archivos al sistema 3. Proceso de Instalación de ROO versión 1.4

116 Luego de esperar algunos minutos al proceso de instalación, se finaliza procedemos a retirar el CD y presionamos ENTER. 4. Una vez que se han realizado estos primeros pasos, tendremos que logearnos en el sistema. Para ello, se tienen dos cuentas de usuario que son las siguientes: Usuarios: roo y root Password: honey (este password es el que viene por defecto) Luego de esto, una vez logueados, ingresamos al directorio /dlg y ejecutamos la aplicación dialogmenu.sh, lo cual nos desplegará una ventana para configurar el honeywall. 5. Seleccionar la opción 4 del menú principal, Honeywall Configuration : 6. Seleccionar la opción 3 en la siguiente ventana:

117 7. Ingresar la dirección IP de los honeypots. 8. Ingresar la dirección de red que ha de utilizar la Honeynet. 9. Ingresar la dirección Broadcast de la Honeynet

118 10. Configuración de la Interfaz remota para administración. 11. Para la interfaz de Administración generalmente se hace uso de la interfaz de red eth2: 12. Ingresar la dirección IP del equipo que hará las funciones de Administración:

119 13. Activación de la Interfaz de Administración 14. Configuración de SSH 15. Permitir el acceso remoto

120 16. Cambio de password de usuario, de los que viene por defecto en la instalación. a. Cambio de password para el usuario root b. Ingreso del nuevo password c. Confirmación del password ingresado: 17. Ingrese una lista de puertos TCP permitidos para la interfaz de administración, por defecto está incluido SSH

121 18. Habilitar la interfaz Walleye, Aceptar 19. Confirmar restricciones del firewall

122 20. Ingresar lista de puertos TCP de salida 21. Ingresar lista de puertos UDP de salida 22. Conexiones permitidas, se especifica por escala de tiempo:

123 23. Límite de conexiones TCP:20, UDP: 20, ICMP: 50, OTROS PROTOCOLOS: Habilitar la opción snort_inline 25. Elegir el filtrado de listas negras y blancas

124 26. Elegir la opción no para habilitar el filtrado seguro durante la captura de paquetes. 27. Configuración de Fencelist 28. Habilitar Fencelist

125 29. 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ón no. 30. Configuración de DNS, habilitar los accesos ilimitados de los Honeypots al servidor(es) DNS. 31. Habilitar la restricción de accesos ilimitados de los Honeypots hacia servidores DNS externos.

126 32. Ingrese los Honeypots que accederán a servidores DNS externos. 33. Habilitar la restricción del servidor DNS a ser utilizado para accesos ilimitados 34. Ingrese la dirección IP del servidor DNS

127 35. Configuración de alertas por 36. Ingrese la dirección de correo electrónico donde se deben enviar las alertas 37. Configuración de las variables Sebek

128 38. Ingrese la dirección IP de destino de los paquetes Sebek, por defecto Ingrese el puerto UDP de destino de los paquetes Sebek, por defecto Del menú de opciones de registro, elegir el literal 4

129 ANEXO 5 Instalación y configuración de Sebek Instalación de Sebek en Sistemas Windows Una vez descargado para Windows, Sebek-Win , de la web, procedemos a su instalación y configuración en el respectivo honeypot. Procedemos con los siguientes pasos: 1. Ejecución de archivo setup.exe, dar click en Next. 2. Ubicación de la carpeta en la que se instalará Sebek, dar click en Install.

130 3. Instalación de los archivos. Dar click en Aceptar 4. Finalización de la Instalación. Dar click en Finish.

131 5. Configuración de Sebek, esto lo hacemos mediante el asistente de configuración Sebek. Ejecutamos el archivo Configuration Wizard.exe: 6. Ubicación del driver Sebek, la ubicación por defecto es la siguiente ruta: c:\windows\system32\drivers\sebek.sy. Dar click en Siguiente:

132 7. Configuración de la Dirección IP, Direccion MAC y puerto destino. Luego dar click en siguiente 8. Valor mágico, elegir el valor randomico. Dar click en Siguiente.

133 9. Escoger la interface de red con la que se ha de comunicar con el Servidor Sebek. Escoger y dar click en Siguiente 10. Escoger el nombre del programa de configuración, el nombre por defecto es Configuratio. Dar click en Siguiente.

134 11. Verificación de la configuración de Sebek. Dar click en Finalizar. DESINSTALACIÓN DE SEBEK. Debido a que el instalador no se registra en el sistema se deberá desinstalar manualmente. Los siguientes pasos son necesarios para eliminar Sebek de un PC: 1. Inicie el equipo con el CD de instalación del sistema operativo. 2. Seleccione la consola de recuperación pulsando "R". 3. Si está ejecutando XP puede ignorar este paso. Si está ejecutando en Windows 2000, después presione C para abrir la consola de recuperación. 4. Seleccione la instalación de Windows que desea modificar. 5. Proporcionar la contraseña de administrador. 6. Una vez ya en el símbolo del sistema, ir a C:\WINDOWS\System32\drivers y escriba 'delete Sebek" sin las comillas. 7. Una vez que el comando se completa reiniciar la máquina escribiendo Exit. 8. Elimine Sebek situado en la clave del Registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sebek 9. Y finalmente quite el programa de configuración si está en la máquina.

135 ANEXO 6 Instalación Sebek-Cliente en Linux Distribución: Ubuntu 7.10 Server Para la instalación de Sebek-Cliente en los Honeypots, se procede de la siguiente manera: Instalación de paquetes requeridos: Nota: Es necesario tener a mano el disco de Instalación de Ubuntu 7.10 Server, por lo que para poder realizar las instalaciones, el sistema requerirá de este disco. #sudo apt-get install subversión # sudo apt-get install make linux-headers-server # sudo apt-get install gcc linux-headers-server # sudo apt-get install autoconf linux-headers-server # sudo apt-get install libc6-dev linux-headers-server # sudo apt-get install patch linux-headers-server También instalar el paquete automake EN SU VERSIÓN 1.4 # sudo apt-get install automake1.4 Una vez instalados todos los paquetes requeridos, procedemos a descargarnos el clientesebek, de la página oficial del proyecto Sebek: Descargamos el: sebek_disable_raw_socket_replacement-lin b-bin.tar.gz Luego, descomprimirlo en el sistema en cualquier directorio, con el comando: # tar zxvf sebek_disable_raw_socket_replacement-lin b-bin.tar.gz Ingresamos en el Nuevo directorio que se creó: # cd sebek-lin b-bin Editar el archivo de configuración sbk_install.sh, con los parámetros necesarios: # sudo nano sbk_install.sh Principalmente, dentro de este archivo, modificamos la directiva DESTINATION_PORT, que por defecto viene en blanco y le ponemos el puerto de escucha de Sebek: 1101

136 Finalmente ejecutamos el instalador con el comando sh: # sudo sh sbk_install.sh Y si todo está bien, la instalación deberá mostrar un mensaje de exitosa (successfully). Con este procedimiento se concluye la instalación del cliente sebek en los equipos honeypots.

137 ANEXO 7 Instalación y configuración de servicios/aplicaciones en los servidores virtuales de la Honeynet. No. Tipo Servidor Software Vers soft. Puerto Función Tráfico 1 Honeypot gdr1.utpl.edu.ec Centos 4.4 Web Externo Apache MySQL cliente Oracle PHP Wordpress Joomla Webmin Sendmail Squirrelmail Drupal 2 Honeypot gdr2.utpl.edu.ec Centos 5 DNS Externo Bind 9,3 53 Ssh Honeypot eva.utpl.edu.ec Centos 5.2 Apache Servidor Web de Eva Externo Tomcat Honeypot wsutpl.edu.ec Windows 2003 Server IIS 6 80 Servicios en Línea Estudiantes docentes Externo Con. remotas 3389 Act. directory 389

138 No. Procesador Disco Duro Memoria Servidor Ram Software Vers soft. Función 1 gdr1.utpl.edu.ec IBM 1.6 GHz 2 Discos 70 GB 10 GB Centos 4.4 Web Apache 2.6 MySQL 5 cliente Oracle PHP Wordpress Joomla Webmin Sendmail Squirrelmail Drupal 2 gdr2.utpl.edu.ec Pentium IV 3GHz 36 GB 1 GB Centos 5 DNS Bind 9,3 Ssh 5 3 eva.utpl.edu.ec Dual Core 1.3 GHz 75 GB 8 GB Centos 5.2 Apache 2.6 Servidor Web de Eva Tomcat 4 wsutpl.edu.ec Intel(R) Xeon(R) CPU GHZ 70 GB 3.25 GB Windows 2003 Server Enterprise Edition IIS 6 Servicios en Línea Estudiantes docentes

139 ANEXO 7 Instalación de aplicaciones en los Honeypots Servidor DNS BIND es el servidor de nombres de dominio más popular en Internet, que trabaja en todas las plataformas informáticas principales y se caracteriza por su flexibilidad y seguridad. Domain Name Service (DNS) es el servicio que resuelve los nombres de dominio asociados a una dirección IP para direccionar las peticiones a un servidor en específico. Se utiliza cuando un nodo (o host) en Internet contacta a otro mediante el nombre de domino de la máquina y no por su dirección IP. Instalación de bind Para la instalación utilizamos el siguiente comando: # sudo apt-get install bind9 Luego de la instalación los archivos de configuración se ubican en el directorio: /etc/bind Configuración de bind Para poder configurar bind editamos named.conf.local y añadimos la zona utpl.org.ec, haciendo referencia a su fichero de configuración: zone "utpl.org.ec" { type master; file "/etc/bind/db.utpl"; }; Cada vez que se cambia la configuración de BIND9, debemos reiniciar el demonio: # sudo /etc/init.d/bind9 restart Creamos el fichero de configuración db.utpl a partir de db.local : # cp db.local db.utpl Editamos db.utpl, reemplazamos la palabra localhost por utpl.org.ec, cambiamos la IP por la que queramos asignar al dominio y añadimos al final del fichero todos los A, MX y CNAME que queramos, quedando: ;

140 ; BIND data file for local loopback interface ; $TTL Utpl.org.ec IN SOA utpl.org.ec. root.localhost. ( 1 ; Serial ; Refresh ; Retry ; Expire ) ; Negative Cache TTL ; IN NS gdr2.utpl.org.ec. IN A gdr2 IN A gdr1 IN A www IN CNAME gdr1 eva IN A wsutpl IN A En el caso de que nuestra máquina utilice el servidor de DNS que hemos configurado, debemos editar /etc/resolv.conf y dejamos únicamente la línea: nameserver Si se va a configurar en otros servidores, hay que poner la dirección IP del DNS que se ha configurado en lugar del que es el localhost. Resolución Inversa Si se desea realizar la traducción inversa, es decir, que se quiera traducir de nombre de dominio a dirección IP, se realiza la siguiente configuración: Editamos el archivo /etc/bind/named.conf.local, y le añadimos las siguientes líneas: zone "192.in-addr.arpa" { type master; file "/etc/bind/db.172"; }; Creamos el archivo de configuración /etc/bind/db.200 a partir del /etc/bind/db.127: # cd /etc/bind/ # cp db.127 db.200 Editamos /etc/bind/db.192, substituimos localhost por utpl.org.ec y cambiamos la última línea: ; ; BIND reverse data file for local loopback interface ; $TTL IN SOA utpl.org.ec. root.utpl.org.ec. ( 1 ; Serial ; Refresh ; Retry

141 ; Expire ) ; Negative Cache TTL IN NS utpl.org.ec IN PTR gdr2.utplinux.org IN PTR gdr1.utplinux.org IN PTR eva.utpl.org IN PTR wsutpl.utplinux.org. A continuación modificamos el fichero /etc/bind/named.conf.options. En este fichero especificaremos aquellos servidores DNS de Internet que resolverán los nombres de dominio que nuestro servidor DNS local no pueda resolver. Será necesario especificarlos para que los ordenadores de nuestra red salgan a Internet. options { directory /var/cache/bind ; forwarders { ; }; }; Enrutamiento en host anfitrión La red interna o intranet donde se encuentran los servidores utiliza un direccionamiento NAT, por lo que para salir hacia otras redes externas se deberá usar como gateway o pasarela el host anfitrión, es decir que todos los paquetes que le lleguen al anfitrión pero que este no sea el objetivo serán redireccionados por la interfaz que se conecta a la red que se necesita acceder, por lo que se habilita el IP Forward, de la siguiente manera: # echo "1" > /proc/sys/net/ipv4/ip_forward # iptables -A FORWARD -j ACCEPT En cada servidor interno se agrega la ruta de salida: # route add -net netmask gateway IP_gtw Pruebas Ahora, para poder comprobar el funcionamiento del bind, se puede hacer uso del comando host, de la siguiente manera: ó

142 Otra forma con las que se dispone para hacer consultas sobre un servidor DNS es dig (domain information groper). Se utiliza para detectar problemas de configuración en el servidor DNS. Su sintaxis es la siguiente: donde: # dig <@servidor> [opciones] [nombre] es el nombre o la dirección IP del servidor a consultar. nombre es el nombre de dominio donde se hace la consulta tipo es el tipo de registro por el que se consulta (ANY, NS, SOA ). Si no se indica, se asume A Con esto se verifica que la traducción de direcciones y nombres de dominio se está realizando correctamente.

143 Instalación Servidor Web Apache El servidor HTTP Apache es un servidor web HTTP 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, procedemos: #sudo apt-get install apache2 SERVIDOR WEB Luego de haber realizado este paso, comprobamos que efectivamente se ha instalado apache en nuestro sistema; desde otro equipo abrimos un navegador y en la url ubicamos la dirección de nuestro servidor local. Es decir, poner la dirección IP de la máquina en la que se instaló apache: Si se da click en el enlace que se muestra apache2-default, y si todo está normal, nos aparecerá una pantalla como la que se muestra a continuación: 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: - sudo /etc/init.d/apache2 restart ó con el comando: - sudo apache2ctl restart

144 Motor de Base de Datos Mysql y PHP Para dotar a Apache de la funcionalidad de manejar páginas php se debe instalar el paquete php5. # sudo aptitude install php5 Para verificar la correcta instalación y funcionamiento de php, creamos un fichero y lo editamos: sudo gedit /var/www/test.php en el fichero le colocas lo siguiente <?php phpinfo();?> Guardamos los cambio y reseteamos el apache server: sudo /etc/init.d/apache2 restart y abres tu navegador y escribimos: Se nos tendrá que presentar una pantalla así: Instalación de algunos paquetes necesarios: # sudo apt-get install mysql5-server # sudo apt-get install libapache2-mod-auth-mysql

145 # sudo 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. # sudo apt-get install phpmyadmin Para poder ser uso de esta herramienta, vamos en otra máquina y en la url ponemos: damos Enter y nos saldrá la ventana para el respectivo logueo: - En caso de que no funcione de esta manera, lo que se puede hacer es, descargarse el phpmyadmin y descomprimirlo en la carpeta de páginas web y asi mismo, ingresar a travez del navegador.

146 Instalación de Webmin WebMin es una aplicación web que nos ayuda a poder configurar graficamente los servicios de nuestro servidor. Para su instalación se requieren seguir el siguiente procedimiento: - Instalamos los siguientes paquetes: # sudo apt-get install build-essential # sudo apt-get install perl libnet-ssleay-perl openssl libauthenpam-perl libpam-runtime libio-pty-perl libmd5-perl - Luego instalamos el paquete webmin # sudo dpkg -i webmin_1.370_all.deb - Luego de esto termina el proceso de instalación. Para acceder a nuestra aplicacion usamos un navegador e ingresamos a la dirección: esto nos muestra una pantalla de login, y podemos ingresar a administrar nuestro servidor. Instalación de Joomla En primer lugar, para poder realizar la instalación de Joomla en nuestro servidor Web, debemos crear una base de datos para Joomla. Esto se puede realizar mediante la utilidad phpmyadmin: Luego de haber creado nuestra base de datos, descargamos el instalador de Joomla y lo desempaquetamos en nuestra carpeta de pagina web de apache. Una vez desempaquetado el instalador, nos ubicamos en el navegador, y colocamos la dirección IP, para proceder con la instalación:

147 - Seleccionamos el idioma a utilizar y ahora, se realiza una comprobación previa, antes de la instalación: - Aceptamos la licencia GNU/GPL: - Ingresamos los datos de configuración de la base de datos:

148 - Ahora, se procede con la instalación: - En el caso de haber existido alguno error en la configuración, se puede arreglar esto, copiando el texto que se muestra en la siguiente pantalla, copiarlo en un archivo de nombre configuration.php y pegarlo en la carpeta raiz de joomla: - Una vez realizado esto, ya podemos ingresar a la administración del nuevo sitio web en joomla:

149 Instalación y configuración del servidor Web Apache El servidor HTTP Apache es un servidor web HTTP 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, procedemos: #sudo apt-get install apache2 SERVIDOR EVA Luego de haber realizado este paso, comprobamos que efectivamente se ha instalado apache en nuestro sistema; desde otro equipo abrimos un navegador y en la url ubicamos la dirección de nuestro servidor local. Es decir, poner la dirección IP de la máquina en la que se instaló apache: Si se da click en el enlace que se muestra apache2-default, y si todo está normal, nos aparecerá una pantalla como la que se muestra a continuación: 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: # sudo /etc/init.d/apache2 restart ó con el comando: # sudo apache2ctl restart

150 Instalación de Moodle Requerimientos: - Servidor Web: Apache - Base de datos: Mysql - Lenguaje: PHP En primer lugar vamos a la página principal del moodle: una vez que se ha escogido la versión adecuado, respecto al S.O. que se tiene, en este caso Linux, descargamos el instalador: Luego de esto, desempaquetamos el archivo descargado en el directorio adecuado, donde se alojan las páginas web. # tar zxvf modle tgz Luego de desempaquetar, se nos crea un directorio con el nombre moodle, en este caso renombramos este directorio y le ponemos por nombre eva. # mv moodle/ eva Luego nos ubicamos en el navegador, y ponemos en la url: Damos Enter y con esto empieza la instalación: 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.

151 Ahora, se configura los datos de la conexión con la base de datos Mysql: Ahora, se comprueban los componentes del servidor:

152 Configuración del Idioma, damos click en Descargar el paquete de idioma Español Internacional (es) : En el caso que no se pueda descargar tal paquete de idioma, hay que descargarlo de descomprimirlo y copiarlo en el directorio /home/moodledata/lang : El siguiente paso es la configuración del archivo principal: config.php:

153 Configuraciones de la cuenta del Administrador. Es necesario crear la contraseña: Con esto se ha finalizado la instalación y configuración de Moodle: Aquí una captura de la pantalla principal:

154 Servidor WSUTPL Instalación y configuración de IIS Primero, nos dirigimos al Panel de Control y Seleccionamos la pestaña Agregar o quitar programas. - En la siguiente ventana damos click en la opción Agregar o quitar componentes de Windows : - De la lista que se nos presenta seleccionamos Servicios de Internet Information Service (IIS), y damos click en siguiente, es necesario tener el CD de Instalación de Windows para poder realizar la instalación: - Con esto finaliza la instalación de Internet Information Service (IIS), damos click en Finalizar

155 Configuración de Internet Information Service (IIS) - Para poder configurar y administrar IIS, ingresamos a Administración de Equipos, esto es, haciendo click derecho sobre Mi Pc y click izquierdo en la pestaña Administrar : - Ahora se nos presentará la siguiente pantalla, desde donde podremos configurar y administrar nuestro servidor Web y sus respectivas páginas que se alojaran: - Una vez ubicados en esta ventana, nos ubicamos en Servicios y Aplicaciones, damos click en el desplegable, luego click en Servicios de Internet Information Service y se nos mostrarán los servicios que se pueden configurar, en este caso Servicios Web, FTP y SMTP: - Lo que por ahora nos interesa son los sitios Web del Servidor Web, por tal motivo, damos click en Sitios Web y luego click derecho en Sitio Web predeterminado y

156 seleccionamos Propiedades. Se nos presentará la siguiente pantalla, donde están todas las opciones para la configuración de los sitios Web que ha de utilizarse: - Para poder verificar si el servidor Web se instaló y se está ejecutando correctamente, nos ubicamos en el navegador y en la URL ponemos localhost, con ello se debe presentar la siguiente pantalla: - Lo cual significa que el Servidor Web está activo, pero que aún no se encuentra alojando ninguna página Web predeterminada. Cabe mencionar, que para agregar documentos al sitio Web, hay que guardarlos en el directorio: C:\Inetpub\wwwroot\