Escuela Politécnica del Ejército - · PDF fileHONEYPOTS Seguridades...

Escuela Politécnica del Ejército Maestría de Gerencia de Sistemas VIII

Lic. Julio Ardita

CYBSEC S.A.

Autor: Pablo Andrés Mora T.

SEGURIDAD INFORMÁTICA HONEYPOTS

HONEYPOTS Seguridades Informáticas

2

Contenido Introducción ............................................................................................................................3

1. Honeypots.........................................................................................................................5

2. Clasificación de los Honeypots.....................................................................................7

3.1. Honeypots según su Ambiente de Implementación ........................................7

3.1.1. Honeypots para la Producción......................................................................7

3.1.2. Honeypots para la Investigación ..................................................................7

3.2. Honeypots según su Nivel de Interacción...........................................................8

3.2.1. Honeypots de Baja Interacción.....................................................................8

3.2.2. Honeypots de Alta Interacción .....................................................................9

3. Ubicación .........................................................................................................................9

4. WiFi Honeypots.............................................................................................................. 12

5. Honeynets ...................................................................................................................... 13

Ejemplo 1: Honeynet Control de datos GenI .............................................................. 16

Ejemplo2: Emulación de servidor de FTP...................................................................... 16

Ejemplo3: Predicción y alerta trampa ......................................................................... 17

6. Ventajas y Desventajas de Honeypots..................................................................... 18

7. Diseño de la trampa.................................................................................................... 19

8. Análisis de un caso real ............................................................................................... 23

9. Creación de un Honeypot Básico............................................................................. 31

Sistema Operativo Windows: ..................................................................................... 31

Conclusiones......................................................................................................................... 33

Bibliografía ............................................................................................................................ 33


3

Introducción Los ataques a servidores conectados a Internet siguen aumentando cada año. La complejidad de los métodos empleados por los atacantes ha ido creciendo paralelamente, al igual que las herramientas que emplean para disimular sus acciones en los equipos una vez que han conseguido acceso al sistema.

Hasta hace algún tiempo los sistemas atacados no solían contener información confidencial, por lo que los administradores procedían a la reinstalación y actualización de estos equipos atacados, para así borrar los binarios y puertas traseras instaladas por los atacantes, continuando posteriormente con la actividad normal del sistema.

En la mayoría de las situaciones, las únicas medidas que se solían adoptar con respecto a los atacantes consistían en la notificación del ataque a los administradores de los equipos origen del ataque, si se llegaba a averiguar, y el envío de un aviso interno a los usuarios del equipo, para que procedieran a cambiar sus claves de acceso.

Sin embargo, con este incremento del número de equipos atacados, es cada vez más frecuente el tener que analizar las acciones realizadas por los atacantes en los equipos, por un lado para averiguar el alcance del mismo y, llegado el momento, poder tomar las medidas oportunas para denunciar el ataque a las autoridades competentes y por otro, para llevar a cabo la actualización parcial del equipo, ya que muchas veces no es posible dejar sin servicio a los usuarios para proceder a una instalación completa.

El número de incidentes reportados cada año sigue en aumento, como se puede ver en las estadísticas. Aunque el código de los programas de ataque, o exploit, últimamente no suele aparecer de forma directa en listas de correo y servidores www, es evidente que hay muchos foros de discusión y servidores en Internet donde se pueden obtener estas herramientas ya compiladas, lo que hace que el número de ataques siga creciendo.

Muchas veces se observa que los atacantes no suelen tener conocimientos extensos sobre el funcionamiento general del sistema al que han conseguido acceder: no saben cómo compilar los programas, ni dónde se encuentra la configuración del sistema de logs del equipo, e intentan ejecutar programas pertenecientes a otros sistemas operativos. La mayoría de ellos se limitan a utilizar una serie de programas “precocinados” para borrar los rastros dejados e instalar una serie de binarios precompilados para atacar después otros servidores.


4

Las dificultades de acceso a los programas que emplean los atacantes impiden muchas veces que los administradores puedan evaluar si un determinado problema de seguridad afecta directamente a los equipos de la institución, teniendo que esperar bien a que los fabricantes del sistema operativo o aplicación distribuyan la versión actualizada del programa o a filtrar determinados servicios al exterior.

Los sistemas de detección de intrusos son una de las herramientas que más ha evolucionado en los últimos años, habiéndose convertido en uno de los principales mecanismos empleados por los administradores de redes para detectar cuándo se produce un ataque, aunque muchas veces no son suficientes para evitar que estos se produzcan.

La dificultad para analizar los binarios instalados en los equipos por los atacantes complica muchas veces la solución de estos ataques. Los administradores deben intentar eliminar todas las puertas traseras que se hayan podido dejar para entrar con facilidad en el equipo, al igual que los programas de recolección de claves que circulan en claro por la red (sniffer) y las herramientas de ataque a otros equipos.

En los últimos años se ha empezado a utilizar equipos trampa o honeypots como un mecanismo de seguridad en la red; estos sistemas suelen ser equipos vulnerables monitorizados en la organización, que sirven para detectar cuándo se ha producido una intrusión y analizar en profundidad las acciones realizadas por los atacantes.

Estos sistemas simulan hacia el exterior equipos vulnerables que al ser atacados permiten a los administradores observar las acciones realizadas por los atacantes, pudiendo de esta forma analizarlas.

Este análisis permitirá, por un lado verificar el uso de los procedimientos de análisis de ataques o análisis forense, y por otro, capturar los nuevos patrones de ataque empleados por los atacantes. De este modo se podrán configurar los sistemas de detección de intrusos con estas nuevas reglas para detectar, a su vez, otros nuevos ataques.

Estas máquinas trampa proporcionan muchas veces a los administradores los programas de ataque empleados por los atacantes, que pueden servir para evaluar la seguridad interna de la organización, siempre y cuando se tomen las medidas oportunas.


5

1. Honeypots Los Honeypots son una tecnología nueva con enorme potencial para la comunidad informática. Los primeros conceptos fueron introducidos por primera vez por varios íconos en la seguridad informática, especialmente aquellos definidos por Cliff Stoll y Bill Cheswick. Desde entonces, han estado en una continua evolución, desarrollándose de manera acelerada y convirtiéndose en una poderosa herramienta de seguridad hoy en día.

Un Honeypot es un sistema diseñado para analizar cómo los hackers emplean sus armas para intentar entrar en un sistema (analizan las vulnerabilidades) y alterar, copiar o destruir sus datos o la totalidad de éstos (por ejemplo borrando el disco duro del servidor). Por medio del aprendizaje de sus herramientas y métodos se puede, entonces, proteger mejor los sistemas. Pueden constar de diferentes aplicaciones, una de ellas sirve para capturar al intruso o aprender cómo actúan sin que ellos sepan que están siendo vigilados.

Los Honeypots son en su forma más básica son servidores de información falsos, posicionados estratégicamente en una red de prueba, los cuales son alimentados con información falsa que es disfrazada como archivos de naturaleza confidencial. A su vez, estos servidores son configurados inicialmente de manera que sea difícil mas no imposible el hecho de ser penetrados por un atacante informático, exponiéndolos de manera deliberada y haciéndolos altamente atractivos para un “hacker” en busca de un blanco. Por último, el servidor es habilitado con herramientas de monitoreo y rastreo de información, de manera que cada paso y rastro de actividad de un “hacker” pueda ser registrado en una bitácora que indique esos movimientos de manera detallada.

Las funciones principales de un Honeypot son:

• Desviar la atención del atacante de la red real del sistema, de manera que no se comprometan los recursos principales de información.

• Capturar nuevos virus o gusanos para su estudio posterior.

• Formar perfiles de atacantes y sus métodos de ataque preferidos, de manera similar a la usada por una corporación policiaca para construir el archivo de un criminal basado en su modus operandi.

• Conocer nuevas vulnerabilidades y riesgos de los distintos sistemas operativos, entornos y programas las cuales aún no se encuentren debidamente documentadas.


6

En un contexto más avanzado, un conjunto de Honeypots forma una Honeynet, proporcionando así una herramienta que abarca un conjunto extendido de posibles amenazas y proporciona al administrador de sistemas mayor información para su estudio. Inclusive, hace más fascinante el ataque para intruso debido a que se incrementan las posibilidades, blancos y métodos de ataque.

Los Honeypots pueden ayudar a prevenir ataques en varias formas:

Defensa contra ataques automatizados: Estos ataques son basados en herramientas que aleatoriamente rastrean redes enteras buscando sistemas vulnerables. Si un sistema vulnerable es encontrado, estas herramientas automatizadas atacaran y tomaran el sistema (con gusanos que se replican en la víctima). Uno de las métodos para proteger de tales ataques es bajando la velocidad de su rastreo para después detenerlos. Llamados “Sticky Honeypots”, estas soluciones monitorean el espacio IP no utilizado. Cuando los sistemas son analizados, estos Honeypots interactúan con él y disminuyen la velocidad del ataque. Esto se logra utilizando una variedad de trucos TCP, como poniendo el “Window Size” a cero o poniendo al atacante en un estado de espera continúa. Esto es excelente para disminuir la velocidad o para prevenir la diseminación de gusanos que han penetrado en la red interna.

Protección contra intrusos humanos: Este concepto se conoce como engaño o disuasión. La idea de esta contramedida es confundir al atacante y hacerle perder tiempo y recursos mientras interactúa con el Honeypot. Mientras ese proceso se lleva a cabo, se puede detectar la actividad del atacante y se tiene tiempo para reaccionar y detener el ataque.

Métodos de Detección Precisa: Tradicionalmente, la detección ha sido una tarea extremadamente difícil de llevar a cabo. Las tecnologías como los Sistemas de Detección de Intrusos y sistemas de logueo han sido deficientes por diversas razones: Generan información en cantidades excesivas, grandes porcentajes de falsos positivos (o falsas alarmas), no cuentan con la habilidad de detectar nuevos ataques y/o de trabajar en forma encriptada o en entornos IPv6. Los Honeypots son excelentes en el ramo de la detección, solventando muchos de los problemas de la detección clásica: Reducen los falsos positivos, capturan pequeñas cantidades de datos de gran importancia como ataques desconocidos y nuevos métodos de explotación de vulnerabilidades (zero-days) y trabajan en forma encriptada o en entornos Ipv6.

Labor Ciber-Forense: Una vez que un administrador de red se da cuenta que uno(s) de sus servidores fueron comprometidos ilegalmente, es necesario proceder inmediatamente a realizar un análisis forense en el sistema comprometido para realizar un control de daños causados por el atacante. Sin


7

embargo, hay dos problemas que afectan a la respuesta al incidente: Frecuentemente, los sistemas comprometidos no pueden ser desconectados de la red para ser analizados y la cantidad de información que se genera es considerablemente extensa, de manera que es muy difícil determinar lo que hizo el atacante dentro del sistema. Los Honeypots ayudar a solventar ambos problemas, ya que son excelentes herramientas de análisis de incidencias que pueden rápida y fácilmente ser sacados de la red para un análisis forense completo, sin causar impacto en las operaciones empresariales diarias. La única actividad que guardan los Honeypots son las relacionadas con el atacante, ya que no son utilizadas por ningún otro usuario, excepto los atacantes. La importancia de los Honeypots, es la rápida entrega de la información, analizada en profundidad previamente, para responder rápida y eficientemente a un incidente.

2. Clasificación de los Honeypots Los Honeypots se pueden clasificar de acuerdo a dos criterios: Según su Ambiente de Implementación y según su Nivel de Interacción. Estos criterios de clasificación hacen fácil entender su operación y utilización al momento de planear la implementación de uno de ellos dentro de una red de datos o infraestructura de TIs.

3.1. Honeypots según su Ambiente de Implementación Bajo esta categoría podemos definir dos tipos de Honeypots: Para la Producción y para la Investigación.

3.1.1. Honeypots para la Producción Son aquellos que se utilizan para proteger a las organizaciones en ambientes reales de operación. Se implementan de manera colateral a las redes de datos o infraestructuras de TIs y están sujetas a ataques constantes las 24 horas del día, 7 días a la semana (24/7). Se les concede cada vez más importancia debido a las herramientas de detección que pueden brindar y por la forma cómo pueden complementar la protección en la red y en los hosts.

3.1.2. Honeypots para la Investigación Estos Honeypots no son implementados con la finalidad de proteger redes, sino que constituyen recursos educativos de naturaleza demostrativa y de investigación cuyo objetivo se centra en estudiar patrones de ataque y amenazas de todo tipo. Gran parte de la atención actual se centra en los Honeypots para la investigación, que se utilizan para recolectar información sobre las acciones de los intrusos.


8

El proyecto Honeynet, por ejemplo, es una organización para la investigación sobre seguridad voluntaria, sin ánimo de lucro que utiliza los Honeypots para recolectar información sobre las amenazas del ciberespacio. Honeypots según su Nivel de Interacción Dentro de este criterio de clasificación, el término “Nivel de Interacción” define el rango de posibilidades de ataque que un Honeypot le permite tener un potencial atacante. Estas categorías nos ayudan a entender no solo el tipo de Honeypot con el que se está trabajando, sino también ayudan a definir la gama de opciones en cuanto a las vulnerabilidades que se desea que un atacante explote. Estas son las características de mayor importancia al momento de empezar a construir el perfil de un atacante.

3.2. Honeypots según su Nivel de Interacción

3.2.1. Honeypots de Baja Interacción Normalmente, éstos Honeypots trabajan únicamente emulando servicios y sistemas operativos. La actividad del atacante se encuentra limitada al nivel de emulación del Honeypot. La ventaja de un Honeypot de Baja Interacción radica principalmente en su simplicidad, ya que estos tienden a ser fáciles de utilizar y mantener con un riesgo mínimo. Por ejemplo, un servicio FTP emulado, escuchando en el puerto 21, probablemente estará emulando un login FTP o probablemente suportará algunos comandos FTP adicionales, pero no representa un blanco de importancia crítica ya que probablemente no está ligado a un servidor FTP que contenga información sensible.

Por lo general, el proceso de implementación de un Honeypot de Baja Interacción consiste en instalar un software de emulación de sistema operativo (ej. VMWare Workstation o Server), elegir el sistema operativo y el servicio a emular, establecer una estrategia de monitoreo y dejar que el programa opere por si solo de manera normal. Este proceso, de naturaleza similar al “plug and play”, hace que la utilización de este tipo de Honeypot sea extremadamente sencilla. Los servicios emulados mitigan el riesgo de penetración, conteniendo la actividad del intruso que nunca tiene acceso al sistema operativo real donde puede atacar o dañar otros sistemas.

La principal desventaja de los Honeypots de Baja Interacción radica en que registran únicamente información limitada, ya que están diseñados para capturar actividad predeterminada. Debido a que los servicios emulados solo pueden llegar hasta un cierto límite operacional, ésa característica limita la gama de opciones que se pueden anunciar hacia el potencial intruso. De igual manera, es relativamente sencillo para un atacante el detectar un Honeypot de Baja Interacción, ya que un intruso hábil puede detectar qué tan buena es la emulación con el debido tiempo.


9

Ejemplos de Honeypots de Baja Interacción son: Specter, Honeyd, y KFSensor.

3.2.2. Honeypots de Alta Interacción Este tipo de Honeypots constituyen una solución compleja, ya que implica la utilización de sistemas operativos y aplicaciones reales montados en hardware real sin la utilización de software de emulación e involucrando aplicaciones reales que se ejecutan de manera normal, muchas veces en directa relación a servicios como bases de datos y directorios de archivos compartidos. Por ejemplo:

Si se desea implementar un Honeypot sobre un servidor Linux que ejecute un servidor FTP, se tendrá que construir un verdadero sistema Linux y montar un verdadero servidor FTP.

Las ventajas de dicha solución son dos: Por un lado, se tiene la posibilidad de capturar grandes cantidades de información referentes al modus operandi de los atacantes debido a que los intrusos se encuentran interactuando frente a un sistema real. De esta manera, se está en posibilidad de estudiar la extensión completa de sus actividades: cualquier cosa desde nuevos rootkits, zero-days, hasta sesiones internacionales de IRC. Por otro lado, los Honeypots de Alta Interacción no asumen nada acerca del posible comportamiento que tendrá el atacante, proveyendo un entorno abierto que captura todas las actividades realizadas y que ofrece una amplia gama de servicios, aplicaciones y depósitos de información que pueden servir como blanco potencial para aquellos servicios que específicamente deseamos comprometer. Esto permite a las soluciones de alta interacción conocer comportamientos no esperados.

Sin embargo, esta última capacidad también incrementa el riesgo de que los atacantes puedan utilizar estos sistemas operativos reales para lanzar ataques a sistemas internos que no forman parte de los Honeypots, convirtiendo una carnada en un arma. En consecuencia, se requiere la implementación de una tecnología adicional que prevenga al atacante el dañar otros sistemas que no son Honeypots o que prive al sistema comprometido de sus capacidades de convertirse en una plataforma de lanzamiento de ataques. Hoy por hoy, el mejor ejemplo de un Honeypot de alta interacción está representado en las Honeynets.

3. Ubicación La ubicación de los Honeypots es esencial para maximizar su efectividad, ya que debido a su carácter intrínsecamente pasivo; una ubicación de difícil acceso eliminará gran parte de su atractivo para potenciales atacantes. Por otro lado, si su ubicación es demasiado artificial u obvia cualquier experimentado atacante la descubrirá y evitará todo contacto.


10

Se debe tener en cuenta que los Honeypots se debe integrar con el resto del sistema que se tiene implementado por ejemplo: servidores WWW, servidores de ficheros, DNS. De manera de asegurar que no interfiera con las otras medidas de seguridad que puedan ya existir en la red como Firewalls, IDS.

Los Honeypots pueden servir tanto para la detección de atacantes internos como externos, se debe tener siempre en cuenta la posibilidad de establecer Honeypots internos para la detección de atacantes o sistemas comprometidos en la red, por ejemplo sistemas infectados con gusanos o virus.

Los Honeypots pueden ubicarse:

Antes del firewall (Front of firewall): Esta localización permitirá evitar el incremento del riesgo inherente a la instalación del Honeypot. Como este se encuentra fuera de la zona protegida por el firewall, puede ser atacado sin ningún tipo de peligro para el resto de la red como se puede observar en la figura:

INTERNET

LAN

Firewall

Honeypot

Esta configuración evitara las alarmas de otros sistemas de seguridad de la red (IDS) al recibir ataques en el Honeypot. Sin embargo, existe el peligro de generar mucho tráfico debido precisamente a la facilidad que ofrece el Honeypot para ser atacado.

Cualquier atacante externo será lo primero que encuentra y esto generará un gran consumo de ancho de banda y espacio en los ficheros de log. Por otro lado, esta ubicación evita la detección de atacantes internos.


11

Detrás del firewall (Behind the firewall): En esta posición, el Honeypot queda afectado por las reglas de filtrado del firewall. Por un lado se tiene que modificar las reglas para permitir algún tipo de acceso al Honeypot por posibles atacantes externos, y por el otro lado, al introducir un elemento potencialmente peligroso dentro de la red se puede permitir a un atacante que gane acceso al Honeypot y a la red.

INTERNET

LAN

Firewall

Honeypot

La ubicación tras el firewall permite la detección de atacantes internos así como firewalls mal configurados, máquinas infectadas por gusanos o virus e incluso atacantes externos.

Sin embargo las contrapartidas más destacables son la gran cantidad de alertas de seguridad que generarán otros sistemas de seguridad de la red (Firewalls, IDS). Al recibir ataques el Honeypot se ve la necesidad de asegurar el resto de nuestra red contra el Honeypot mediante el uso de firewalls extras o sistemas de bloqueo de acceso, ya que si un atacante logra comprometer el sistema tendrá vía libre en su ataque a toda la red.

Hay varias circunstancias que obligan a este tipo de arquitectura, como por ejemplo la detección de atacantes internos o la imposibilidad de utilizar una dirección IP externa para el Honeypot.

En la zona desmilitarizada: La ubicación en la zona desmilitarizada permite por un lado juntar en el mismo segmento a los servidores de producción con el Honeypot y por el otro controlar el peligro que añade su uso, ya que tiene un firewall que lo aísla de resto de la red local.


12

Servidores Publicos

INTERNET

LANFirewall

Honeypot

Esta arquitectura nos permite tener la posibilidad de detectar ataques externos e internos con una simple reconfiguración del sistema de firewall puesto que se encuentra en la zona de acceso público.

Además se elimina las alarmas de los sistemas internos de seguridad y el peligro que supone para la red al no estar en contacto directo con esta.

La detección de atacantes internos se ve algo debilitada, puesto que al no compartir el mismo segmento de red que la LAN, un atacante local no accederá al Honeypot. Sin embargo, desde la red local si es posible acceder al Honeypot, con lo que un atacante interno que intente atacar a los servidores públicos u otros sistemas externos por ejemplo un gusano, muy probablemente acabe siendo detectado.

4. WiFi Honeypots Las redes de comunicaciones se han ido expandiéndose lentamente por centros militares, universitarios y centros de investigación hasta el estallido de Internet. A partir de este momento la obsesión por estar conectados ha llevado a la instalación de millones de metros de cables que cubren todo tipo de edificios y superficies.

Sin embargo, la dependencia de Internet continúa alimentando el deseo de estar conectados en cualquier sitio y a cualquier hora. Bares, librerías e incluso campus universitarios están iniciando un nuevo paso en las comunicaciones, las redes inalámbricas (wireless networks).

Obviamente, no se puede descartar el papel de catalizador que la gran expansión de los teléfonos móviles ha tenido en el desarrollo de estas redes sin


13

hilos. Actualmente ya existen varios estándares de IEEE que regulan estas comunicaciones como el 802.11b y el 802.11g.

Como ocurre con cualquier red de comunicaciones, los accesos no autorizados o los ataques perpetrados por hackers están a la orden del día. Sin embargo, el peligro de este tipo de redes se dispara debido a tres factores diferenciales:

• Los estándares y especificaciones para este tipo de redes son nuevos y poco probados. Como siempre que se realiza una cosa por primera vez, la existencia de indefiniciones, malas interpretaciones o fallos de conceptos es bastante probable. Estos aspectos difusos son los más utilizados por los atacantes para obtener acceso a este tipo de redes.

• Cualquiera usuario con un simple portátil o incluso con un PDA puede intentar acceder de forma fraudulenta a nuestra red inalámbrica. A diferencia de otros tipos de redes, no se necesita estar físicamente conectado o estar confinado en un área concreta. Los ataques pueden venir de cualquier sitio.

• La mayor ventaja de las redes sin hilos es la movilidad que proporcionan. Este aspecto también puede jugar en contra, ya que el atacante puede ir cambiando de ubicación mientras realiza su ataque.

La utilización de Honeypots en las redes inalámbricas es una de las últimas aplicaciones que se están probando con éxito en Estados Unidos. Actualmente el programa WISE (Wireless Information Security Experiment) lidera la investigación en este campo.

5. Honeynets Se puede definir una Honeynet como un tipo concreto de Honeypot. Específicamente es un Honeypot altamente interactivo diseñado para la investigación y la obtención de información sobre atacantes. Una Honeynet es una arquitectura, no un producto concreto o un software determinado.

El nuevo enfoque consiste no en falsear datos o engañar a un posible atacante (como suelen hacer algunos Honeypot) sino que el objetivo principal es recoger información real de cómo actúan los atacantes en un entorno de verdad.

Para conseguir este entorno real con sistemas reales, no con simples emulaciones de servicios y altamente interactivo, se dispone una configuración de red típica con todos los elementos.


14

INTERNET

Firewall

LOG Honeypot

Windows NT Solaris 7 Linux 2.2x Windows 98

Firewall

SISTEMA REAL

HONEYNET

Esta red ha sido diseñada para ser comprometida, por lo que debe estar separada de forma segura y controlada de la de producción. Por otro lado, como el objetivo es el de hacer creer al atacante que está ante una red real, se debe añadir los distintos elementos que conforman una arquitectura normal en cualquier red distintas máquinas, distintos sistemas operativos.

Una Honeynet presenta dos requerimientos básicos para ser realmente útil y que permita la extracción de información valiosa:

Control del flujo de datos (Data control): Siempre que se interactúa con un atacante, el peligro aumenta exponencialmente. El objetivo de la Honeynet es el de ser comprometida y atacada, se debe mantener siempre un control del flujo de datos para evitar que el atacante la utilice contra terceros o contra la red.

Si bien es cierto que cuanta más interacción permitamos con el exterior más datos reales podremos obtener del atacante, se debe evaluar los riesgos que conlleva. Análogamente, una Honeynet que no permita ningún tipo de actividad con el exterior dejará de ser atractiva para un atacante y perderá toda su utilidad. Como siempre, la búsqueda de un equilibrio nos debe guiar en este aspecto.

Captura de datos (Data capture): La captura de todos los movimientos y acciones que realice el atacante en nuestra Honeynet nos revelará sus técnicas y motivaciones. Si bien es esencial que el nivel de vigilancia y captura sea alto, si este es excesivo o detectado por el atacante dejará de ser efectivo.

Obviamente, la captura de datos debe hacerse sigilosamente y sin despertar ningún tipo de sospecha, por lo que debe planificarse cuidadosamente.


15

El lugar dónde se almacena esta información debería encontrarse fuera de la Honeynet, ya que si realmente compromete un sistema puede encontrarla o incluso peor, falsearla o borrarla. Esto eliminaría cualquier utilidad a la Honeynet.

Tradicionalmente, la mayoría de los sistemas de seguridad han sido siempre de carácter defensivo. IDS, Firewalls y demás soluciones se basan en la defensa de los sistemas, y cuando un ataque o vulnerabilidad es detectado se debe arreglar el problema tan rápido como sea posible.

Estas aproximaciones siempre van siempre un paso por detrás de los atacantes, ya que la reacción depende directamente de los ataques sufridos y detectados. Si no se recibe ningún ataque o no se descubre alguna vulnerabilidad, los sistemas de defensa permanecerán iguales. No hay mejora intrínseca o pro actividad propia de los sistemas de ningún tipo.

Las Honeynets miran de cambiar esta actitud mediante el estudio de los ataques y atacantes. Obtener nuevos patrones de comportamiento y nuevos métodos de ataque con el objetivo de prevenirlos en los sistemas reales.

Sin Honeynets, cada vez que se produzca un ataque nuevo y exitoso a un sistema real existente, este dejará de dar servicio y se verá comprometido. Con las Honeynets, un ataque exitoso o nuevo no tiene porqué afectar a ningún sistema real.

Además perderá el factor sorpresa, ya que se habrá obtenido datos precisos de su ataque en el estudio de los logs, cosa que permitirán contrarrestarlo de una manera más eficiente.

Al igual que los Honeypots, la cantidad y calidad de información producida es muy importante, ya que cualquier actividad existente es sospechosa.


16

Ejemplo 1: Honeynet Control de datos GenI

Este es un ejemplo de una política de cortafuegos que implementa el control de datos utilizando un corta fuegos. Checkpoint Firewall. La regla que se marca es la que controla el tráfico saliente ésta es la regla que limita el riesgo. El origen es la red Honeynet, el destino es cualquier red (Internet) salvo la red de Producción. Cuando una conexión se establece, el corta fuegos ejecuta la alerta definida por el usuario, que cuenta los números de conexiones, y los bloquea cuando supera un límite de 10 conexiones.

Ejemplo2: Emulación de servidor de FTP Aquí se puede ver el código de un tarro de miel de baja interacción (Honeyd) que emula un servidor de FTP. Basándose en la entrada del ataque, existe una salida predefinida.


17

Ejemplo3: Predicción y alerta trampa Este es un modelo estadístico, basado en firmas IDS, muestra el concepto de alerta temprana.


18

6. Ventajas y Desventajas de Honeypots Las principales características y ventajas que nos ofrecen los sistemas basados en Honeypots son:

• Generan un volumen pequeño de datos, que al contrario de los sistemas clásicos de seguridad (Firewalls, IDS…), generan cientos de megas de ficheros de logs con todo tipo de información no necesaria, que para el caso de los Honeypots estos generan muy pocos datos y de altísimo valor.

• Los Honeypots son ordenadores que ningún usuario o sistema normal debe acceder a ellos. Permitiendo de esta forma, relevar cualquier acceso, atacante o una configuración errónea de un sistema, sin existir falsos positivos.

• Se necesita recursos mínimos, ya que a diferencia de otros sistemas de seguridad, las necesidades de un Honeypot son mínimas. No consume ni ancho de banda ni memoria o CPU extra. No necesita complejas arquitecturas o varios ordenadores centralizados, cualquier ordenador conectado a la red puede realizar este trabajo.

• Este tipo de sistemas sirven tanto para posibles atacantes internos como externos. De esta forma, se evita poner a las máquinas nombres como “honeypot” o “attack-me”; muchas veces ni tan siquiera están dadas de altas en los DNS. Su objetivo es pasar desapercibidas en una red como una máquina más.

Como todo sistema tiene también unas contrapartidas o desventajas asociadas. En el caso de los Honeypots los principales inconvenientes son:

• Son elementos totalmente pasivos. De esta forma, si no reciben ningún ataque no sirven de nada.

• Son fuentes potenciales de riesgo para nuestra red. Debido a la atracción que ejercen sobre posibles atacantes, si no calibramos perfectamente el alcance del Honeypot y lo convertimos en un entorno controlado y cerrado, puede ser utilizado como fuente de ataques a otras redes o incluso a la nuestra propia.

• Consumen una dirección IP como mínimo. De todas formas, este inconveniente es mínimo, ya que lo ideal es asignar direcciones IP del rango de direcciones libres.


19

Del análisis de todas las características principales de los Honeypots y aplicando el desglose del concepto de seguridad en prevención, detección y reacción, obtenemos el siguiente análisis:

1. Los Honeypots tienen un limitado carácter preventivo. No evitarán o disuadirán a ningún posible atacante.

2. Tienen un alto grado de detección. Si bien son elementos pasivos, los atacantes rara vez se centran en una simple máquina, sino que buscan por toda la red posibles víctimas, lo que hace que antes o después se encuentre con el Honeypot.

3. La reacción es otro de los valores que añade el uso de Honeypots. En los de Honeypots de producción se puede de forma automática generar los comandos necesarios para evitar el acceso del atacante al resto del sistema. En los de investigación, además nos permiten a posteriori la ejecución de técnicas forenses (computer forense) para examinar el comportamiento del atacante y descubrir sus comportamientos.

7. Diseño de la trampa El Honeypots está formado por un conjunto de equipos vulnerables; las máquinas trampa propiamente dichas y un equipo de control que monitoriza al resto de los equipos. Este sistema permitirá el tráfico entre la red de equipos trampa y el exterior, bloqueando los equipos cuando se detecta un ataque, de forma que no se puedan emplear estos, a su vez, para realizar nuevos ataques.

En los equipos trampa se pueden instalar los diversos sistemas operativos usados en la institución con la configuración de servicios que se deseé monitorizar (servidor WWW, FTP, etc.). Dado que estos equipos trampa no necesitan tener un rendimiento alto, se pueden emplear sistemas antiguos que hayan sido retirados del servicio, aunque es conveniente que pueden ejecutar versiones actuales de los sistemas operativos.

Para proceder al análisis de los datos dejados por el atacante en el equipo, no conviene que los sistemas tengan una capacidad de almacenamiento muy elevada. Por ejemplo un equipo Pentium 133 con un disco duro de 1,6 ó 2Gb y 32 Megas de memoria RAM se puede emplear para la instalación de diversos sistemas operativos Unix/Linux sobre plataforma Intel; mientras que un antiguo Sparc puede servir para la instalación de un Solaris 2.7.

Estos equipos trampa tendrán direccionamiento propio de la red de la organización y estarán conectados entre sí a un hub que permita al atacante, en


20

un momento dado, capturar el tráfico falso entre equipos externos y las máquinas trampa de manera que el atacante pueda ser dirigido a otros equipos trampa.

El equipo de control funciona en modo puente Ethernet, actuando de forma transparente a nivel IP, pudiendo, de esta manera, conectar las máquinas trampa a la red, manteniéndolas aisladas del resto de los equipos de la organización y sin tener que implementar una subred donde incluirlas. Este equipo de control deberá tener, a su vez, una dirección IP para poder gestionarlo.

Para poder monitorizar los ataques, el equipo de control capturará todo el tráfico con origen y/o destino a la red de máquinas trampa, de forma que se pueda tener un registro de las conexiones que realiza el atacante a ellas.

Este registro de tráfico sirve, entre otras cosas, para poder detectar nuevos ataques y vulnerabilidades ya que se puede comparar el tráfico generado por el uso del ataque o exploit con los realizados por otros ataques similares; y detectar así cuando aparecen nuevos ataques o variaciones de otros ya existentes.

Red de la Organización10.0.1.0/24 10.0.1.10

Router de acceso10.0.1.10

10.0.1.120Servidor

Equipo de control

Red trampa

Maquinas trampa

10.0.1.20

10.0.1.19

10.0.0.5

EJEMPLO DE RED TRAMPA


21

En la figura se observa la configuración del Honeypots propuesto. Como se puede observar, el equipo trampa divide en dos la red de la institución, separando los equipos trampa del resto de equipos de la organización. Esta separación a nivel físico impide que los equipos trampa puedan capturar el tráfico a nivel IP que circule por el resto de la red, con independencia del tipo de entorno (conmutado o compartido) en el que se encuentre la red de máquinas trampa.

El tráfico entre los equipos de usuarios del servidor no se detectaría en ninguna de las máquinas trampa, solamente aquél destinado a toda la red de broadcast Ethernet llegaría a estos equipos.

Así pues, cuando desde el exterior se realizase un escaneo contra la red 10.0.1.0/24 todos los equipos, normales y trampa, responderían a las conexiones y, llegado el momento, el atacante podría entrar en una de las máquinas trampa, por ejemplo la 10.0.1.80, e instalar un sniffer en ella para intentar capturar las claves de acceso; sin embargo, solamente obtendría la información generada por las máquinas trampa; proporcionada mediante scripts para simular tráfico y no la generada por los equipos de usuario (10.0.1.5 y 10.0.1.10).

Para evitar que una vez que el atacante haya accedido a los equipos pueda atacar a otros sistemas, es conveniente limitar en el router de acceso la cantidad de conexiones salientes que se pueden realizar desde estos equipos. No se debe filtrar completamente ya que, de lo contrario, es muy posible que algunos programas, como los clientes y servidores de FTP, no funcionen correctamente.

Para el equipo de control se puede emplear un sistema Linux con la característica de puente Ethernet activada. Esta característica está presente en las últimas versiones de los núcleos 2.4.x, donde también hay una opción que permite el filtrado a nivel de dirección Ethernet de los equipos del tiempo, que se puede emplear para bloquear el tráfico de los equipos atacados sin tener que aplicar filtros en los router de acceso de la organización.

CONFIG_BRIDGE=m Activa el empleo de las funciones de puente Ethernet en el núcleo del equipo

CONFIG_BRIDGE_NF Indica que se van a poder emplear las facilidades de filtro de paquetes (netfilter) para las trampas Ethernet que circulen por el puente

CONFIG_NETFILTER Activa el sistema de IPtables para el filtrado de paquetes IP y trampas en el núcleo del quipo

CONFIG_IP_NF_IPTABLES Activa el sistema de IPtables para el filtrado de las tramas

CONFIG_IP_NF_MATCH_MAC Permite filtrar en función de la dirección Ethernet (MAC) de las trampas, para impedir por ejemplo que


22

desde los equipos trampa se pueda acceder a determinados equipos de la red

CONFIG_IP_NF_FILTER Activación de los filtros Tabla: Opciones de configuración del núcleo de Linux

En la tabla se muestran las opciones más importantes que hay que activar para que el equipo pueda funcionar como puente Ethernet y filtrar las conexiones. En general se pueden activar todas las funcionalidades que aparecen dentro del menú de configuración de los filtros (IP Netfilter configuration) de los núcleos.

Además de la compilación del núcleo, hay que instalar en el equipo las utilidades de gestión de puentes (bridge-utils) que permiten la configuración y gestión de los puentes Ethernet.

La captura del tráfico generado con origen/destino en/a los equipos trampa se puede realizar directamente con el programa tcpdump, separando el tráfico en ficheros distintos y clasificándolo según la dirección IP del equipo origen/destino. Periódicamente se deben realizar rotaciones de estos logs, para evitar tener ficheros de captura demasiado grandes.

Las opciones que se han empleado con el programa tcpdump para capturar el tráfico aparecen comentadas en la tabla.


23

Tcpdump –n –nn –s 1500 –w trampa‐ 10.0.1.80 –I br0 host 10.0.1.80 ‐n No consultar en el servidor de DNS el nomb asociado a las direccions IP ‐nn No consultat en el fichero /etc/services el nombre de los puertos

involucrados en cada conexión ‐s 1500 Número máximo de bytes a almacenar de cada paquete, este valordebe

ser igual o mayor que la MTU de los interfaces Ethernet (1.500 normalmente)

‐w fichero Almacenar la información directamente en un fichero ‐I br0 Emplear el interface del puente, en este el br0 Host equipo Capturar sólo el tráfico con destino a este equipo a nivel IP

Tabla: Opciones de captura para TCPDUMP

Además, en el equipo de control se lanzará el software de detección de intrusiones snort, que avisará cuando se haya producido un ataque contra las máquinas trampa.

Estos programas de detección de intrusos funcionan leyendo todo el tráfico que llega al equipo y comparando cada paquete IP con una base de datos de reglas que especifican un determinado ataque.

Estas reglas detectan patrones de ataques conocidos, por lo que deben actualizarse periódicamente con los patrones de nuevos ataques que van surgiendo.

8. Análisis de un caso real Desde un punto de vista práctico, una vez que se ha detectado o se sospecha que la integridad del sistema ha podido ser vulnerada por algún tipo de intrusión, es conveniente hacer una copia de la información que hay en el sistema. Dependiendo de la situación, puede ser conveniente incluso hacer una copia de los procesos que se están ejecutando en ese momento en el equipo, del espacio de intercambio (swap), de las conexiones activas, etc.

Para realizar una copia de las particiones del sistema de ficheros, en los equipos Unix, se puede usar el comando dd. Las copias obtenidas pueden volcarse en una partición libre del propio equipo o a un fichero (cosa poco recomendable, ya que el contenido del sistema atacado debería modificarse lo menos posible), sin embargo es preferible enviar los contenidos a otro equipo empleando, por ejemplo, el programa Netcat (nc).


24

El siguiente ejemplo muestra cómo se podría realizar esta copia, transfiriendo el contenido de la partición sda4 del equipo víctima al equipo de control.

En el equipo víctima se ejecutaría:

y en el equipo remoto se recibiría el fichero:

También se pueden enganchar los discos a un equipo y realizar la copia a bajo nivel, empleando discos duros de iguales características (mismo modelo) y haciendo la copia mediante dd.

En sistemas operativos como Windows NT, que no disponen de un procedimiento de backup a bajo nivel, se puede utilizar el procedimiento empleado para sistemas Unix: arrancar el equipo desde un disco de rescate o instalación de Linux/Unix (menos recomendable por aquello de modificar datos del sistema) y proceder a realizar la copia de los dispositivos a bajo nivel.

En cualquier caso, es conveniente realizar estas copias a bajo nivel para poder restaurar los datos en caso de que ocurra algún problema al analizar los ficheros, además esto permitirá el análisis de los archivos buscando las fechas de modificación de los mismos.

Todo este proceso (es decir, los pasos dados para la copia de los datos del sistema) debería quedar registrado y documentado en algún sitio de forma automática. En estos casos, comandos como script pueden resultar muy útiles.

Una vez que se ha realizado la copia y la migración de los datos al equipo remoto donde se va a efectuar al análisis, se debe proceder a la recopilación de datos relacionados con el tipo de sistema y su entorno: versión del sistema operativo, particiones utilizadas, fecha en la que se detectó el ataque, fecha en la que se desconectó de la red el equipo y cualquier otra modificación que pudiese tener relevancia para el análisis.

Posteriormente, se procederá a montar las imágenes de las particiones para comenzar el análisis de las mismas en el equipo remoto. Para esto se puede usar el mecanismo de loop-back disponile en Linux, que permite el montaje de los ficheros imagen de la partición en el equipo Unix, pudiendo así acceder a archivos de estos sistemas de ficheros.


25

Una vez montadas las particiones, se utilizará fundamentalmente el paquete TCT para realizar el análisis. El primer paso será la obtención de los tiempos de Modificación/Acceso/Cambio (tiempos MAC) de todos los ficheros del sistema. Es fundamental capturar estos tiempos antes de emprender cualquier acción sobre los ficheros del equipo atacado que pueda modificar su valor. La secuencia de accesos a los ficheros permitirá crear una línea temporal que muestre los acontecimientos ocurridos en el sistema.

Mediante las herramientas ils e ils2mac1 se podrán obtener los tiempos MAC de los nodos-i borrados de las particiones. El fichero resultante será combinado, a su vez, con el fichero obtenido tras la ejecución de grave- robber2 sobre el sistema de ficheros anterior, para, de esta forma, tener los tiempos MAC tanto de los nodos-i borrados como de los nodos-i activos. La secuencia de comandos usada para hacer esto podría ser la que se detalla a continuación:

Al final de este proceso se obtiene un listado completo (contenido en el fichero ’fichero.txt’) de los tiempos MAC de todos los ficheros del sistema (incluidos los borrados) que hayan modificado alguno de sus tiempos MAC desde ’fecha’.

La siguiente acción a realizar, una vez obtenidos los tiempos MAC, es comprobar todos los programas y ficheros de configuración instalados en el equipo.

En muchas intrusiones, lo primero que hace el atacante es modificar los programas y herramientas del sistema para ocultar su acceso; además, suelen modificar los ficheros de configuración para crear nuevos usuarios, permitir accesos desde determinadas máquinas, etc., de forma que puedan acceder al equipo más cómodamente con posterioridad.


26

Por todo lo comentado anteriormente, es conveniente que no se empleen los programas instalados en el propio equipo, sino versiones que se tengan compiladas estáticamente siempre que se tenga que realizar el análisis sobre el mismo equipo atacado y no se pueda usar otro sistema para realizarlo. El motivo de utilizar ficheros compilados estáticamente se debe a que no emplean llamadas a librerías del sistema susceptibles de ser modificadas por los atacantes. Por esa misma razón no es conveniente que se emplee el sistema operativo de la máquina atacada, ya que puede ser modificado mediante módulos para ocultar los procesos y ficheros del atacante. Sin embargo, aunque se usen programas compilados estáticamente, esto no evita que la información mostrada pueda ser errónea, ya que existen rootkits que pueden modificar, mediante módulos, el propio núcleo del sistema operativo. Un ejemplo sería Adore.

Si no se dispone de una base de datos de integridad en un dispositivo externo para poder comprobar la integridad de los ficheros (ayudándose de herramientas como, por ejemplo, Tripwire), se pueden usar técnicas como comparar los ficheros binarios existentes en el sistema con los de la instalación original (cuando no estén empaquetados) o con los que hay en otro equipo con la misma versión y parches del sistema operativo, empleando comandos como cmp.

La mayoría de los sistemas operativos disponen de un sistema de verificación de paquetes instalados.

La base de datos se mantiene en el propio equipo (por lo que el atacante puede modificarla) pero de todas maneras puede emplearse muchas veces para comprobar qué ficheros se han modificado.

Aunque es habitual que algunos ficheros cambien de permisos o de contenido, por ejemplo al añadir usuarios al fichero de password, después de realizar algunas instalaciones que producen cambios en los formatos, etc.; no suele ser habitual que comandos como /bin/ls sean modificados, lo que puede indicar que se trata de una versión troyanizada.

Para comprobar la consistencia de los paquetes instalados en el sistema atacado, buscando especialmente errores de chequeo de md5, se puede usar la utilidad rpm (o su equivalente si existe en el sistema operativo atacado) con las opciones adecuadas, como por ejemplo:


27

La aparición de modificaciones en ficheros como: netstat, ifconfig, ps, top, ls, top, tcpd..., se sugeriría la posibilidad de que se haya instalado un rootkit en el sistema.

Un método para saber si los ficheros modificados son versiones troyanizadas de los originales es examinar los ficheros sospechosos buscando cadenas que delaten esta posibilidad. Normalmente, la información que se obtiene de este estudio suelen ser rutas de directorios y ficheros que no deberían aparecer en el sistema, por ejemplo:

El fichero ‘‘‘/dev/xdta” resulta ser un fichero de configuración que contiene un listado con todos los procesos que no mostraría el comando ps (aunque se estuvieran ejecutando), para no delatar la presencia de intrusos en el equipo.

Sin embargo, este sistema no siempre da buenos resultados ya que en los ataques más recientes se están empezando a utilizar ficheros que se ejecutan comprimidos por lo que no es posible visualizar las cadenas de texto que


28

contienen y otras técnicas de ofuscación que impiden obtener información útil empleando el método anterior.

Una vez analizadas las cadenas de los programas supuestamente modificados, se debe intentar recuperar el contenido de los ficheros borrados (el número de nodo-i que tenía asociado cada archivo antes de ser borrado se puede obtener del fichero de tiempos MAC generado anteriormente).

Para recuperar el contenido de estos ficheros se puede usar el comando icat, incluido en el TCT. Este programa devuelve toda la información que encuentra sobre el nodo-i que se le pasa como parámetro realizando la búsqueda en la imagen de la partición indicada.

Anteriormente se han obtenido, mediante el comando ils, los nodos-i actualmente vacíos que hubiesen contenido información en el periodo en el que se produjo el incidente. Para obtener una copia de estos ficheros se puede emplear el comando icat, en lugar de realizar una búsqueda mediante un editor.

Al realizar este proceso, la siguiente tarea será averiguar el tipo de cada fichero para abrirlo con el programa adecuado (el comando file, o sus análogos en cada sistema operativo, pueden facilitar esta tarea).

Posteriormente, se deberá analizar el contenido de cada uno de estos ficheros. Así, por ejemplo, los ficheros de texto pueden contener trozos de logs borrados deliberadamente por el intruso, los ficheros ejecutables pueden corresponder a programas utilizados por el atacante, los ficheros comprimidos pueden ser paquetes instalados.


29

En este punto, si fuese necesario, se procedería al desensamblado de los ficheros ejecutables para determinar cómo mayor exactitud su funcionalidad.

Recogida y analizada esta información básica (que puede dar una idea muy aproximada de lo que ha pasado en el sistema), se procederá al estudio del fichero de tiempos MAC que se generó anteriormente. Este análisis tratará de establecer una línea temporal que muestre la secuencia de acontecimientos ocurrida en el sistema.

A continuación se observa un extracto de los datos que genera el programa mactime, y una pequeña reseña de la información que se puede obtener de estos (la salida ha sido ligeramente modificada para ajustarla a la página).

Como ejemplo se muestra la información que aparece cuando se modifica el fichero ps. A continuación podemos observar la creación del fichero de configuración (dev/xmx) que se había detectado anteriormente.


30

En primer lugar, se puede observar que por la proximidad de las fechas en las que se modifican los ficheros es muy posible que se trate de la ejecución de un script, ya que se crean varios ficheros en el mismo instante de tiempo en el análisis completo de este ataque se puede verificar esta hipótesis, recuperando el script empleado entre los ficheros borrados por el atacante.

En la primera entrada de tiempos se accede a varios ficheros del sistema para obtener información del equipo. El fichero “raiz-hda4-dead-2404” es el fichero comprimido de la instalación que es borrado posteriormente por el atacante.

Por último se puede observar la creación y modificación de diversos ficheros en los directorios del sistema, que reemplazan a los binarios originales del equipo. Mediante la recuperación del script lanzado por el atacante, se puede comprobar que algunos de estos ficheros eran las versiones reales de los demonios del sistema, como “/usr/bin/ct”, versión original del programa crontab.

Los ficheros instalados por el atacante en el directorio “/dev” contenían la configuración de los binarios del rootkit, indicando qué procesos y conexiones se debían ocultar a los administradores.

En la última fase del análisis en realidad, no tiene por qué ser la última, puede ser incluso la primera o ir intercalándose, procediéndose a examinar el flujo de tráfico capturado por un IDS. El objetivo es establecer y corroborar todos los datos hallados en el sistema.

En general, los pasos a seguir suelen dividirse en:

1. Análisis de los flujos de datos para agruparlos según las distintas conexiones capturadas. En estos casos conviene la utilización de algún tipo de script que facilite y automatice esta labor, puesto que la cantidad de información con la que se puede llegar a trabajar (del orden de varios gigabytes) hace inviable un tratamiento manual.

2. Almacenamiento de la información de cada conexión en un fichero donde sea fácilmente identificable: origen y destino de la conexión, fecha y hora de comienzo y finalización, puerto utilizado y tamaño de la misma.

3. Establecer, en su caso, si existe algún tipo de desfase horario entre el sistema de control (IDS, Firewall) y el equipo analizado. Esto es fundamental para poder comparar los datos de las conexiones almacenadas con la información que ha quedado registrada en el equipo atacado.

4. Estudio de las conexiones y búsqueda de datos que faciliten la identificación del atacante. El orden seguido al examinar las conexiones


31

puede disminuir el tiempo que es necesario emplear, por eso conviene empezar por las que parezcan más prometedoras.

Una vez analizada y clasificada toda la información almacenada en el IDS se pudo determinar que el ataque se produjo aprovechando una vulnerabilidad del proceso rpc.statd. Posteriormente, el atacante realizó una conexión ftp desde el propio equipo para bajarse los programas necesarios para completar la intrusión.

Un análisis más en profundidad de las conexiones permitió obtener un listado de las actividades desarrolladas por el atacante: desde la conexión a un servidor para descargarse el archivo con los ficheros troyanizados, hasta la instalación de los mismos.

9. Creación de un Honeypot Básico

Sistema Operativo Windows: Paso 1:

Se deberá bajar el entorno Perl (ActivePerl 5.8.6) para Windows

http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl allí encontrará varios formatos, se recomienda bajar el .zip

http://downloads.activestate.com/ActivePerl/Windows/5.8/ActivePerl-5.8.6.811-MSWin32-x86-122208.zip , una vez descargado se deberá ejecutar en línea de comando installer.bat, allí se presentará una serie de opciones que se puede dejar por defecto.

Paso 2:

Se debe añadir el directorio Perl al PATH. Entre en Mi PC. Con el botón derecho entre en opciones avanzadas, variables de entorno y se debe agregar lo siguiente:

c:>path=%path%;c:perl (o donde haya instalado el Perl).

Paso 3:

Se descargará el entorno Python (ActivePython 2.4.0)

http://www.activestate.com/Products/Download/Download.plex?id=Activepython

Una vez instalado el SO (sistema operativo) estará en la disponibilidad de ejecutar ficheros .py.


32

Es imprescindible equipar una máquina diseñada para ser atacada, con un sistema de seguridad; en caso contrario podría volverse en nuestra contra.

Paso 4:

Se debe bajar el script (free) desde:

http://www.megamultimedia.com/arroba/arroba78/descargas/intrusos.zip de nombre windog, es la mínima expresión de un Honeypot. Además de configurable es sencillo de instalar y su código es bastante entendible. Solo basta tener ciertos conocimientos de programación.

Una vez descomprimido se encontrará 2 ficheros perl (sendmail.pl y telnet.pl) como también un readme del autor del script. Sí el entorno Perl está corriendo solo se tendrá que pulsar dos veces sobre cualquiera de los ficheros nombrados anteriormente y aparecerá una consola indicando que el script está corriendo.

NOTA: Se debe estar atento que no exista ningún servicio corriendo en los puertos que se indican en el script (23 si se ejecuta el telnel.pl o el 25 si se ejecuta el sendmail.pl).

Paso 5:

Se debe comprobar que está funcionando el script, para luego pulsar sobre telnet.pl dos veces. Por medio de la consola se realizará un telnet

telnet localhost

Aparecerá algo similar a esto:

Unix(r) System V release 4.0

(Brooder) Login:

Se introduzca el login y contraseña de acceso al sistema. El mensaje que muestra por consola puede ser modificado a gusto. Todos los intentos de login y contraseña quedarán reflejados en la ventana en la que se levantó el script y nunca serán validados porque no está programado de esa forma; además de que no hay servicio alguno que validar. Si se deja corriendo esto por un tiempo con vista a Internet se observará cómo alguien intentará entrar por ese servicio ficticio.

Para modificar el banner que sale al principio indicando que el visitante acaba de conectarse a un sistema Unix, se debe abrir el fichero telnet.pl y modificar la línea:


33

$banner ="nrnrUnix (r) System V Release 4.0 (brooder) nr";

Para el fichero sendmail es exactamente igual.

Sí se usa el fichero sendmail.pl, al hacer conexión vía telnet, reconocerá el comando HELO y responderá con un saludo y la dirección IP del visitante que acaba de conectarse.

Los script son tan sencillos que se puede hasta cambiar el puerto. Si se desea trabaja con el puerto 23 sólo debe cambiar el valor de la variable $port, ejemplo: $port = 22;

Hay que recordar que la verdadera potencia de los servidores trampa consiste en saber atacar al Script Kiddie donde más les duele. Hay que tener presente que se deberá combinar diferentes herramientas de análisis y monitorización para sacar un verdadero provecho de un HoneyPot.

Conclusiones • La instalación honeypots aislados de la red en producción permite analizar

los métodos empleados por los atacantes para acceder a los equipos sin comprometer la seguridad de la organización.

• Los honeypots permiten recuperar y analizar diversos programas instalados y empleados por los atacantes, permitiendo determinar los fines que llevaron a la intrusión, detectando además los equipos desde donde se llevaban a cabo los ataques preliminares, así como obtener, para su posterior análisis, otros programas utilizados por el atacante.

• El análisis del tráfico de red complementa perfectamente la información obtenida directamente de los honeypots, pudiéndose relacionar de forma inmediata la actividad en la red, como por ejemplo los escaneos desde determinados equipos, con los ataques realizados con éxito contra los equipos trampa.

• La documentación generada sobre las actuaciones realizadas en los equipos víctima es de utilidad directa en situaciones reales en las que un equipo ha sido atacado, sirviendo de guía en los pasos a seguir para realizar un análisis del ataque.

Bibliografía • Honeynet Project, http://www.honeynet.org


34

• Honeynet Project México, http://www.honeynet.org.mx

• Honeynet Project, Know your Enemy: Honeynets,

http://www.honeynet.org/papers/honeynet/index.html

• Philippine Honeynet Project, Honeynets Learning, 2006

http://www.philippinehoneynet.org/docs/honeynetlearning.pdf

• Honeypots: Definitions and Values, http://www.spitzner.net/honeypots.html

• HoneyNet Español, http://his.sourceforge.net/trad/honeynet/

• Zonavirus, http://www.zonavirus.com/Detalle_Articulo.asp?Articulo=108

• Symantec, http://www.symantec.com/region/mx/enterprisesecurity/content/framework/LAM_2371.html

• Datafull, http://www.datafull.com/datahack/informe.php?id=255

• Forzis, http://www.forzis.com

• Tracking-Hackers, http://www.tracking-hackers.com

Escuela Politécnica del Ejército - · PDF fileHONEYPOTS Seguridades...

Documents

Transcript of Escuela Politécnica del Ejército - · PDF fileHONEYPOTS Seguridades...