Embed Size (px)
Citation preview
El presente documento de hacer un
humilde estudio sobre las soluciones
honeypot. Este documento se licencia
bajo GPLv3, usted puede copiarlo,
distribuirlo y modificarlo.
Trabajo de
Fin de
Master Seguridad en Sistemas
Operativos - HoneyPot.
Ana González y Pedro Berrocal
Licenciado bajo GPLv3 Página 1
Trabajo de Fin de Máster
Seguridad en Sistemas Operativos - HoneyPot.
Licenciado bajo GPLv3 Página 2
AGRADECIMIENTOS
A todas aquellas personas que dedican su vida al conocimiento
para hacer un mundo mejor compartiendólo.
Licenciado bajo GPLv3 Página 3
ÍNDICE
1. Capítulo 1. –Introducción- .................................................................................................... 5
1.1.1 ¿Qué es un honeypot? ......................................................................................................... 5
1.1.2 Honeypot, un poco de historia ......................................................................................... 6
1.1.3 Tipos de honeypots ......................................................................................................... 7
1.1.4 Honeynet .......................................................................................................................... 9
1.1.5 Elementos conceptuales de un honeypot ........................................................................ 9
1.2. Objetivos y justificación del trabajo de investigación ................................................. 10
1.2.1 Motivación........................................................................................................................... 10
1.2.2 Objetivos ............................................................................................................................. 10
1.3. Estructura del trabajo.................................................................................................. 11
2. Capítulo 2. - Estudio de sistemas operativos y fases de planificación y diseño ...................... 12
2.1 Estudio de honeypots según el sistema operativo ........................................................... 12
2.2. Sistema operativo linux .................................................................................................... 12
2.2.1 Vulnerabilidades en linux .................................................................................................... 12
2.2.2 Honeypots propuestos en linux .......................................................................................... 14
2.2.3 Honeywall ............................................................................................................................ 14
2.2.4 Honeydrive .......................................................................................................................... 22
2.3 Sistema operativo Windows ............................................................................................. 25
2.3.1 Tipos de ataques comunes en Windows ............................................................................. 25
2.3.2 Honeypots en Windows ...................................................................................................... 27
2.4 Fase de planificación y diseño .......................................................................................... 31
2.4.1 Planificación ........................................................................................................................ 31
2.4.2 Diseño .................................................................................................................................. 33
3. Capítulo 3. Metodología de instalación, configuración y testing de arquitectura. ............. 36
3.1 Instalación de las máquinas virtuales y configuración de la red. ................................ 36
3.2 Instalación y configuración de Debian .............................................................................. 37
3.3 Instalación honeydrive ...................................................................................................... 39
3.4 Configuración Honeydrive ................................................................................................. 40
3.4.1 Mwcrawler .......................................................................................................................... 40
3.4.2 Configuración de Dionaea ................................................................................................... 43
3.4.4 Configuración de Amun ....................................................................................................... 46
3.4.5 Configuración de Tiny Honeypot ......................................................................................... 48
3.4.6 Configuración de Wordpot .................................................................................................. 54
Licenciado bajo GPLv3 Página 4
3.4.7 Configuración de Glastopf ................................................................................................... 54
3.5 Instalación y Configuración WinhoneyD ........................................................................... 56
3.5.1 Instalación ........................................................................................................................... 56
3.5.2 Configuración: ..................................................................................................................... 56
4. Exposición de los sistemas .................................................................................................. 58
5. Análisis de datos .................................................................................................................. 59
6. Conclusiones............................................................................................................................ 60
X. BIBLIOGRAFÍA .................................................................................................................... 61
ANEXO ........................................................................................................................................ 62
Figura 1 Configuración de interfaces vboxnet en virtualbox: ................................................. 62
Figura 2 Configuración vboxnet0 ............................................................................................ 62
Figura 3 Configuración vboxnet1 ............................................................................................ 63
Figura 4 Características de la maquina virtual Debian ............................................................ 64
Figura 5 Instalación de Snort ................................................................................................... 65
Figura 6 Configuración del Snort 1 .......................................................................................... 65
Figura 7 Configuración de Snort 2 ........................................................................................... 66
Figura 8 Configuración de Snort 3 ........................................................................................... 66
Figura 9 Maltrive ..................................................................................................................... 67
Figura 10 Mastiff.db ................................................................................................................ 67
Figura 11 Interfaz gráfica de dionaea ...................................................................................... 68
Figura 12 Amun ....................................................................................................................... 69
Licenciado bajo GPLv3 Página 5
1. Capítulo 1. –Introducción-
La seguridad informática es un mundo cambiante y competitivo, donde diversos actores tratan
de encontrar nuevos bugs, formas de ataque y defensa, día a día, por diversas razones.
A medida que los ataques se vuelven más ingeniosos y variados con el paso del tiempo, las
medidas defensivas deben mantenerse a la altura.
Los investigadores cuentan con su ingenio y la tecnología, para diseñar sistemas de protección
que impidan o por lo menos palien la exposición a vulnerabilidades. Este Trabajo de fin de
Máster, TFM en adelante, habla de cómo adelantarse al gato y no sentirse ratón, de como
descubrir nuevos ataques, o por lo menos de una de las formas de hacerlo.
1.1.1 ¿Qué es un honeypot?
“Ser lo que soy, no es nada sin la Seguridad... Incluso para la locura se observa un método.” W.
Shakespeare.
Esta frase refleja claramente la partida de ajedrez que se juega a diario, y no sin intereses de
por medio, en el mundo de la seguridad IT actual.
Es un pequeño baile en apariencia caótico, donde atacantes, empresas de seguridad, y clientes
cumplen sus roles mientras las piezas del tablero se mantienen silenciosamente ajenas como
víctimas o verdugos.
Pero, ¿cómo observar el baile?, ¿cómo ver los próximos movimientos?, un honeypot puede ser
una buena respuesta, y ¿qué es un honeypot?
La traducción literal es “tarro de miel”, y ¿por qué un tarro de miel?, porque se trata de un
sistema que aparenta ser vulnerable, lo cual es atractivo para el atacante, cuando en realidad
su función principal es estudiar y recopilar información y patrones del atacante.
El diccionario Algesa lo define como:
En computación, un honeypot es una trampa para detectar, desviar o contrarrestar de alguna
manera, los intentos de uso no autorizado de los sistemas de información.
Generalmente un honeypot puede ser una computadora, datos o un sitio de red que parecen
ser parte de una red pero que en realidad están aislados, protegidos y monitorizados, y que
parecen contener información o recursos que serían valiosos para los posibles atacantes.
Un honeypot es una herramienta de seguridad informática utilizada para recoger información
sobre los atacantes y sus técnicas.
Licenciado bajo GPLv3 Página 6
Se puede crear un honeypot en un sistema entero, como será el caso del estudio a
continuación, o de pequeñas partes o servicios que lo compongan.
Los honeypots cumplen diversas funciones, por un lado crean un entorno que resulta atractivo
para el atacante y es expuesto intencionadamente para recibir estos ataques y por el otro sirve
para análisis de los mismos.
Estos ataques no siempre provienen de personas, no siempre hay alguien detrás atacando el
sistema, en muchas ocasiones son bots o maquinas programadas para tal propósito que
realizan ataques automatizados a varios sitios a la vez con una vulnerabilidad concreta.
También es importante señalar que poner un honeypot en nuestro sistema puede ser una
medida defensiva a tener en cuenta ya que desvía la atención del atacante, bot o humano, del
objetivo real, o lo entretiene.
Por otra parte nos permite capturar nuevos virus para su posterior estudio, conocer y
descubrir nuevas vulnerabilidades.
Más adelante en el desarrollo de este TFM veremos que hay formas de percibir que el sistema
o servicio atacado no es real, y también formas de hacer que sí lo parezca o enmascarar
nuestro honeypot.
Y ¿cómo surgió esta caja de Schrödinger?
1.1.2 Honeypot, un poco de historia
No hay mucha documentación al respecto y las fechas pueden no ser exactas ya que varían
según la fuente consultada, pero para hacernos una idea de como surgieron, en 1998, se
liberó la primera versión de herramientas para honeypot creada por Fred Cohen, llamada
Deception Toolkit .
Lance Spiztner, consultor y analista informático, construye en el año 2000, en su hogar una
red de seis equipos destinados a estudiar el comportamiento y los patrones tanto de ataques
como de atacantes.
De esta pequeña prueba nacerá lo que hoy en día se conoce como honeynet.
Su sistema se mantuvo en funcionamiento durante un casi un año, desde abril a febrero del
2000, recopilando resultados asombrosos, sus equipos llegaban a ser escaneados hasta
catorce veces en un día.
Varias empresas de seguridad comenzaron sus desarrollos en este campo, no ajenos al nuevo
marco de negocio que se les presentaba.
En la actualidad miles de desarrolladores trabajan a diario para crear nuevas soluciones,
herramientas y características para todos los tipos de honeypots existentes.
Licenciado bajo GPLv3 Página 7
1.1.3 Tipos de honeypots
Del mismo modo que no utilizamos una trampa de elefantes para cazar ratones, un honeypot
puede adaptarse a unos requerimientos específicos, adecuándose al objetivo del mismo, de
donde nacen diversos tipos de honeypots.
1.1.3.1 Clasificación
Los honeypots pueden se clasificados según su ambiente de implementación como: honeypots
para la producción o honeypots para la investigación y según su nivel de interacción como de
alta o baja interacción, también pueden ser máquinas físicas dedicadas a tal fin o máquinas
virtuales.
Según su ambiente de
implementación:
Honeypots de producción
Son implementados por empresas y
corporaciones tanto para proteger redes
cómo para estudiar patrones y por
supuesto por su gran función forense.
Suelen ser honeypots de alta interacción
ya que en un sistema con miles de
usuarios la recuperación del mismo en
caso de desastre puede llegar a afectar a la disponibilidad y esto es algo que difícilmente se
puede permitir ningún administrador y menos la compañía, hacer que un honeypot forme
parte del sistema ayuda a prever el tipo de ataques que se reciben y así poder pormenorizar
los incidentes críticos y establecer unas políticas de seguridad coherentes.
Se implementan en infraestructuras Tls y están sujetos a ataques constantes.
Honeypots de investigación
Son Honeypots implementados, normalmente en universidades y centros de estudio con la
finalidad de servir de recurso educativo.
Su objetivo primordial suele ser el de estudiar patrones de ataque, análisis de datos, gestión de
amenazas, en pocas palabras permiten a los estudiantes ver el panorama de la seguridad en
tiempo real, analizándolo y conociendo los pormenores del mismo.
Un ejemplo claro de este tipo de este tipo de honeypots es el proyecto honeynet, el cual es un
proyecto sin ánimo de lucro dedicado a la investigación y el desarrollo de herramientas Open
Source para la seguridad, el cual ya cuenta con su propia red social llamada hpfriends, donde
se permite el volcado de datos de las honeynet.
Según su ambiente de
implementación
•Honeypots de investigación
•Honeypots de producción
Según su nivel de interacción
•Honeypots de baja interacción
•Honeypots de alta interacción
Licenciado bajo GPLv3 Página 8
Según su nivel de interacción:
Honeypots de baja interacción
Como se dijo en al principio de esta introducción, un honeypot no tiene por que ser un sistema
completo, puede ser un servicio del mismo y a esto mismo nos referimos con honeypots de
baja interacción.
Los honeypots de baja interacción son aquellos que emulan servicios concretos sirviendo para
proteger estos servicios, un ejemplo de este tipo de honeypots es Kippo, cuya finalidad es
simular un servicio ssh.
Este tipo de honeypot también puede emular un sistema operativo completo. Al no tener
usuarios ni más procesos o demonios que los propios del sistema, resulta extremadamente
sencillo ver cualquier actividad sospechosa y el nivel de interacción del atacante queda
exclusivamente limitado al nivel de emulación del honeypot.
Por otro lado este tipo de honeypots son realmente muy fáciles de instalar y mantener. Sólo se
necesita una máquina virtual como puede ser VirtualBox, elegir el sistema operativo, montar el
servicio y establecer la estrategia de monitoreo. Al ser un único servicio la cantidad de logs a
analizar es mucho menor que en un honeypot de alta interacción.
Uno de los casos más llamativos y útiles de este tipo de honeypots son los utilizados para
plataformas web relativamente nuevas como puede ser Worpress. Este tipo de plataformas
están compuestas de una gran variedad de plugins y software de terceros que añaden más
piezas al rompecabezas de la seguridad en este tipo de sistemas.
Como desventaja de este tipo de honeypots he de señalar que en ocasiones la simulación del
servicio no es completamente fiel y el atacante puede darse cuenta de que está en un
honeypot.
Honeypots de alta interacción
Este tipo de honeypots son implementados en servidores reales y los servicios monitorizados
que contienen no son emulados, son sistemas reales implementados con servicios y
aplicaciones reales que se ejecutan de manera normal.
Las bases de datos, tablas de usuarios y documentos contenidos en estos servicios, si son
falsos, pero no existe ningún software de emulación que los contenga.
De este modo es posible capturar mayor información de los atacantes ya que estos se
encuentran atacando un sistema real. El atacante no tiene por que percibir la trampa en este
tipo de sistemas por lo que usará todo su arsenal, rootkits, exploits, código propio, zero-days,
lo que permite mayor cantidad de información capturada y quizás mayor fiabilidad de la
misma.
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
Licenciado bajo GPLv3 Página 9
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.
Este tipo de honeypots ha de ser cuidadosamente implementado para evitar que el atacante
pueda llegar a la red real y comprometer servidores reales no previstos en tal práctica, sobre
este punto hablaremos con más detenimiento en el segundo capítulo de este TFM.
1.1.4 Honeynet ¿Qué pasa cuando dos honeypots se encuentran en la red?, ¿cómo hacer si queremos tener
dos honeypots de alta interacción con diferentes sistemas operativos pero aunando logs?.
Una honeynet son dos o más honeypots interconectados, construyendo una red de honeypots,
donde se reciben los logs de todos los honeypots integrantes.
Es un tipo de arquitectura muy interesante ya que podemos unir nuestro honeypot con el de
otra red y ver el tráfico de ambos o tener diferentes honeypots unidos entre si, con diferentes
sistemas operativos en cada uno de ellos y estudiar los ataques los mismos tanto por separado
como en conjunto.
Si queremos ampliar la documentación a este respecto the honeynet project cuenta con un
whitepaper llamado Know your enemy donde se explica en detalle como crear una honeynet.
1.1.5 Elementos conceptuales de un honeypot
Conceptualmente un honeypot puede quedar representado por los siguientes elementos:
Sistema señuelo: Parece un sistema productivo de la organización, atractivo ya que contendrá
información sustancial como passwords, usuarios, bases de datos vulnerables, cuentas de
correo, tarjetas de crédito, convirtiéndose así en un target atractivo para el atacante
Mientras más atractivo, realista y complejo sea este componente, más posibilidades de éxito
tendrá el honeypot.
Firewall: en el modelo, el firewall provee logs de auditoría acerca de los intentos del intruso
por acceder al honeypot. El firewall se configura para registrar todos los paquetes yendo al
sistema señuelo, teniendo en consideración que ningún tráfico válido se dirigiría a ese host.
Se hace hincapié en este concepto: el sistema señuelo se creó exclusivamente para ser
atacado, con lo que, por definición, todo tráfico destinado a dicho sistema debe ser
considerado hostil y sujeto a mayor análisis.
Unidad de monitoreo: es un componente de evaluación de amenazas que supervisa las
actividades maliciosas o violaciones de políticas sobre la red y/o sistemas, produciendo
reportes que luego podrán ser consultados por el administrador del honeypot. Con medidas
como la revisión de las secuencias, las timestamps y los tipos de paquetes utilizados por el
intruso para acceder al honeypot, y también como la presión de teclas, accesos a los sistemas,
Licenciado bajo GPLv3 Página 10
archivos cambiados, etc., se busca identificar las herramientas y metodologías utilizadas por
los atacantes y sus intenciones.
Normalmente, en el marco de un honeypot, esta tarea es delegada a un IDS (Intrusion
Detection System).
Unidad de alertas: los honeypots deben ser capaces de generar y enviar avisos a través de
diferentes medios a su administrador para permitir la revisión de las actividades de los intrusos
mientras están ocurriendo.
Unidad de registro: este componente provee eficiencia en el almacenamiento tanto para los
logs del firewall como del honeypot en sí, y todo el tráfico que circula entre el firewall y el
honeypot.
1.2. Objetivos y justificación del trabajo de investigación
1.2.1 Motivación
La motivación fundamental de este proyecto es tener la oportunidad de montar un sistema tan
curioso, complejo y atractivo para llegar al estudio y compresión de cada una de sus partes con
todo lo que ello entraña.
La documentación existente sobre este tipo de proyectos es escasa y normalmente está
centrada en un solo sistema operativo.
1.2.2 Objetivos
El presente trabajo de técnico consiste en la creación o montaje de un HONEYPOT con el
objetivo final de realizar un estudio de cuáles son los principales ataques que se producen en
cada uno de los sistemas operativos caso de este trabajo.
Tal y como se indica en las premisas del este TFM, en todo momento se trabajará con
máquinas virtuales conectadas a internet directamente, y se utilizará una distribución de Linux
para una de las máquinas y una distribución de Windows para la otra máquina. Se analizará
más adelante que distribuciones se escogen y las causas de esta elección.
El principal objetivo de este trabajo técnico es el de obtener un análisis detallado de cómo se
ha de realizar la instalación y configuración de los sistemas operativos instalados así como los
distintos ataques sufridos en estos “equipos” y sistemas operativos.
A la luz de estos objetivos, el trabajo técnico se centrará en las siguientes metas:
En primer lugar, realizar un análisis del sistema operativo Linux que se va a instalar
y una recopilación de las herramientas para convertirlo en un HONEYPOT. Así
mismo realizar este análisis para seleccionar un sistema operativo Windows así
como algún tipo de servicio que tenga algún puerto activo y un estudio de
herramientas existentes para recoger los logs y posibles ataques detectados.
En segundo lugar, la instalación y configuración de un sistema operativo basado en
Linux y configurado con herramientas HONEYPOT. Por otro lado, realizar la
Licenciado bajo GPLv3 Página 11
instalación y configuración de un sistema operativo Windows con ciertos servicios
activos y con una herramienta de análisis y recogida de log escogida en el punto
anterior.
En tercer lugar, poner con acceso libre desde internet los servicios instalados los
sistemas operativos Linux y Windows durante un periodo de tiempo razonable.
En cuarto lugar, recoger los datos del punto anterior.
Y por último, realizar un análisis de los datos recogidos.
1.3. Estructura del trabajo
El primer capitulo de este trabajo se centra en poner en antecedentes al lector y dar
unas breves definiciones de en que consiste un honeypot. También cuenta con el índice,
los objetivos y la motivación que han llevado a su realización.
Puesto que todo trabajo técnico parte de una base teórica que lo justifica, en el segundo
capítulo se realizará un estudio sobre qué sistemas operativos se utilizarán así como que
herramientas se utilizarán para la captura de datos y que servicios estarán activos, así como
una estimación de los tiempos necesarios para la realización técnica de este trabajo.
En el tercer capítulo, pasaremos a describir la metodología seguida para la instalación,
configuración y puesta en explotación de los dos sistemas operativos.
El cuarto capítulo, está dedicado a exponer los sistemas operativos creados y
configurados a disposición del público y dejarlos expuestos durante un periodo de tiempo
establecido.
El quinto capítulo, analizar y presentar los datos recabados del anterior capítulo.
Por último, en el sexto capítulo expondremos las conclusiones extraídas de los datos
previamente analizados.
Licenciado bajo GPLv3 Página 12
2. Capítulo 2. - Estudio de sistemas operativos y fases de
planificación y diseño
2.1 Estudio de honeypots según el sistema operativo Ya que las vulnerabilidades varían según el sistema el sistema en este caso debe contemplar
sus posibles vulnerabilidades para enfocarse adecuadamente a la práctica propuesta, motivo
por el que expondremos cuales son las vulnerabilidades más frecuentes para cada uno de
ellos.
2.2. Sistema operativo linux
Se ha elegido Debian 7 estable, como sistema operativo para alojar ambos honeypots, o al
menos el honeypot basado en Windows (esto dependerá de la agilidad de la máquina con
ambos instalados), por su robustez, versatilidad, y por ser uno de los sistemas que antes saca
parches para cualquier cve que llega a conocerse.
Otro de los motivos para hacerlo de esta forma es el de intentar ofrecer todo en un único
producto en lugar de en partes separadas y proveer de una seguridad adicional al sistema
implementado.
En cuanto al resto de los sistemas, honeydrive, honeywall y honeynet se describen a
continuación junto con sus herramientas y componentes en detalle pero antes de entrar en
materia sería bueno dar un repaso sobre las vulnerabilidades presentes en linux.
2.2.1 Vulnerabilidades en linux
La lista de las 10 vulnerabilidades más comunes en linux según Sans son:
Software BIND
BIND es el software estándar de facto para actuar como servidor de nombres de dominio, un
servicio esencial para el correcto funcionamiento de la red, ya que se encarga de la conversión
de los nombres de dominio a sus correspondientes direcciones IP.
Determinadas versiones de BIND son vulnerables a ataques que pueden ser utilizados por un
atacante remoto para comprometer los sistemas vulnerables. Adicionalmente, una mala
configuración de BIND puede revelar información sensible sobre la configuración de la red.
Es importante verificar que los sistemas que ejecuten BIND utilicen la versión más reciente,
incluso si esto supone abandonar la versión distribuida por el fabricante del sistema operativo e
instalar la versión del ISC a partir de su código fuente.
Servidor Web
Prácticamente todos los sistemas Unix y Linux incluyen de forma nativa el servidor Apache. Una
configuración inadecuada del mismo así como la utilización de versiones antiguas pueden
provocar problemas de seguridad, con diversos niveles de efectos sobre el nivel de seguridad.
Licenciado bajo GPLv3 Página 13
Autenticación
Es habitual encontrar equipos Unix con deficiencias en sus mecanismos de autenticación. Esto
incluye la existencia de cuentas sin contraseña (o con contraseñas ampliamente conocidas o
fácilmente deducibles). Por otra parte es frecuente que diversos programas (o el propio sistema
operativo) cree nuevas cuentas de usuario con un débil mecanismo de autenticación.
Sistemas de control de versiones
El sistema de control de versiones más utilizado en entornos Unix es CVS. Si la configuración del
servidor CVS permite conexiones anónimas, determinadas versiones son susceptibles a ataques
de desbordamiento de búfer que pueden ser utilizados para ejecutar código arbitrario en el
servidor.
Servicio de transporte de correo
Los equipos Unix que actúan como servidores de correo pueden ser vulnerables, caso de utilizar
una versión antigua, a todo tipo de ataques. Fruto de estos ataques se puede conseguir el
control completo del sistema vulnerable, la utilización del servidor de correo como estación de
distribución de correo basura o robo de información sensible.
Protocolo SNMP
El protocolo SNMP se utiliza de una forma masiva para la gestión y configuración remota de
todo tipo de dispositivos conectados a la red: impresoras, routers, puntos de acceso,
ordenadores.
Dependiendo de la versión de SNMP utilizada, los mecanismos de autenticación son muy
débiles. Adicionalmente diversas implementaciones del protocolo son vulnerables a todo tipo
de ataques, que van desde la denegación de servicio, a la modificación no autorizada de la
configuración de los dispositivos o incluso de la consola donde se centraliza la gestión de la red.
Biblioteca OpenSSL
En los últimos meses se han detectado diversas vulnerabilidades en la biblioteca OpenSSL que
afectan a un gran número de productos que hacen uso de la misma: Apache, CUPS, Curl,
OpenLDAP, s-tunnel, Sendmail y muchos otros.
Es importante verificar que se está utilizando la versión más reciente de OpenSSL y todos los
productos que utilizan OpenSSL para el cifrado de la información utilicen esta versión más
moderna.
Mala configuración de los servicios de red
Los servicios NFS y NIS son los métodos más frecuentemente utilizados para la compartición de
recursos e información entre los equipos Unix de una red. Una mala configuración de los
mismos puede ser utilizada para la realización de diversos tipos de ataques, que van desde la
ejecución de código en los sistemas vulnerables a la realización de ataques de denegación de
servicio.
Licenciado bajo GPLv3 Página 14
Bases de datos
Las bases de datos son un elemento fundamental para la mayoría de las empresas.
Prácticamente cualquier aplicación empresarial está construida alrededor de una base de datos
donde se almacena información altamente sensible y vital para el funcionamiento del negocio.
Los problemas de configuración, una mala política de la política de control de acceso, errores
en las aplicaciones, errores de diseño o la complejidad intrínseca de muchos entornos puede ser
el origen de problemas de seguridad que afecten a la integridad, fiabilidad y/o disponibilidad
de los datos.
Núcleo del sistema operativo
El núcleo del sistema operativo realiza las funciones básicas como la interacción con el
hardware, la gestión de la memoria, la comunicación entre procesos y la asignación de tareas.
La existencia de vulnerabilidades en el núcleo puede provocar problemas de seguridad que
afecten a todos los componentes del sistema. Es muy importante la correcta configuración del
núcleo, para evitar o reducir el alcance de las posibles vulnerabilidades.
2.2.2 Honeypots propuestos en linux
En esta sección se barajarán alternativas para montar nuestro honeypots en linux, se probaran
y configuraran varias alternativas que permitan tomar una decisión razonada sobre cual es la
mejor opción de implementación.
2.2.3 Honeywall
Honeywall es un sistema operativo basado en Centos 5, también llamado de Honeynet
Gateway es un dispositivo con 3 interfaces de red: eth0, eth1, eth2.
La interface externa (eth0) del Honeywall se conecta con el sistema de producción, la interface
interna (eth1) se conecta con la Honeynet, ambas están a modo de puente (bridge)
transparente lo cual significa que no poseen una pila de IP, ni MAC asociadas, no realizan
encaminamiento, ni decrementan el TTL de los paquetes que las atraviesan.
La tercera interfaz (eth2) sí tiene una dirección de IP y es conectada a una red segura con fines
de administración y recolección de datos.
El comportamiento del Honeywall como dispositivo de Capa 2 (Bridge) transparente, dificulta
enormemente su detección por parte de los atacantes y permite la integración de la Honeynet
a la red de Producción e incluso compartir VLAN con otros sistemas dentro de la organización
en la que se esté implantando.
El software de implementación de honeynets Honeywall Roo v1.4 fue lanzado en Abril de
2009, siendo para esa época, su Sistema Operativo vigente junto con su paquete de
aplicaciones asociadas.
Licenciado bajo GPLv3 Página 15
El valor de honeywall reside en sus scripts de configuración que aúnan el compendio de
herramientas de las que está compuesto y pueden ser clasificadas como herramientas de
captura de datos, recopilación de datos y monitorización.
Herramientas de detección, captura y filtrado:
La captura de datos se ejecuta en tres capas, la capa firewall, la capa de red y la capa de los
sistemas.
Snort
Los dispositivos que forman parte de la captura de datos son: el firewall, el IDS y los
honeypots. El firewall/gateway captura y registra todo los paquetes que lo atraviesen en
cualquier sentido, pues toda actividad en la Honeynet es sospechosa. El Firewall está diseñado
no sólo para registrar actividades, también nos alertará de ciertos eventos configurados, como
el intento de conexión por Telnet, o hacia un puerto alto generalmente usado en puertas
traseras. Esta alerta puede ser enviada por email al administrador de la red.
El IDS captura y almacena todos los paquetes circulantes en la red. Reside en un 'puerto de
monitoreo', así que puede registrar toda la actividad de la red. Para esta tarea se usa Snort
(NIDS) en modo de full logging (recoge todos los paquetes IP) y tcpdump (recoge todo el
tráfico de red en formato binario). Se usan estas dos herramientas para evitar un punto único
de fallo, y para asegurar la integridad de los datos enviados a un servidor remoto de logs.
Otra de las tareas de este sistema IDS es alertarnos de la actividad sospechosa, comparando
los paquetes con una base de datos de marcas de ataques. En los Honeypots es necesario
recolectar actividades dentro de los sistemas. Los atacantes más experimentados acostumbran
a bloquear y borrar logs del sistema, por esto es necesario crear un repositorio externo de
dichos logs salvándolos de ser borrados o alterados por el atacante. Se usa una técnica para
que los sistemas repliquen sus los al servidor remoto. Entre los datos capturados del atacante,
hay unos especialmente que con las técnicas anteriores podríamos capturar pero no visualizar.
Si el atacante usa un medio seguro como SSH, SSL, IPsec, etc., para llevar a cabo sus métodos
de intromisión, esta actividad se almacenará encriptada en los registros.
Los datos deben ser registrados
Iptables
De sobra conocido este firewall de aplicación tiene como objetivo proveer cierta apariencia de
seguridad para la red ficticia.
Teniendo en cuenta esto, se espera que Iptables actúe como firewall en la interfaz bridge de la
red de Honeywall regulando los paquetes que ingresan y egresan la honeynet, siendo esto no
tanto para prevenir que los atacantes entren a la red falsa como sí apunta a hacerlos pensar
que están en una red productiva verdadera, surtiendo efecto la finalidad de la honeynet. El rol
de Iptables respecto de la interfaz de administración sería el de un firewall tradicional
permitiendo el acceso sólo a los usuarios y administradores de Honeywall. Esto se logra
Licenciado bajo GPLv3 Página 16
mediante la imposición de la restricción de las direcciones IP de hosts/redes específicos a los
cuales se les permite acceso a la interfaz de administración mediante reglas de permiso sólo a
cierto tipo de tráfico como lo es el del puerto UDP 53 (DNS), TCP 80 (HTTP) y TCP 443 (HTTPS).
Herramientas de recopilación de datos:
Sebek
Sebek es un herramienta cliente-servidor diseñada para capturar la actividad de los atacantes
en los Honeypots. Es un módulo de Kernel oculto capaz de capturar la actividad del atacante,
transmitiendo los datos usando UDP al servidor, en muchos casos el mismo Honeywall.
El cliente Sebek envía estos datos ocultándolos al atacante y el Servidor Sebek los recoge y
registra.
El sistema de alertas envía un correo electrónico al administrador de la Honeynet cada vez que
un evento muestre alguna intrusión en la misma.
Hflow2:
Es un software de recopilación y correlación de los datos obtenidos a partir de Snort, p0f,
Argus y Sebek, ensamblando dichos datos en un flujo unificado el que se almacena en una base
de datos particular. La base de datos Hflow2 funciona como método de acceso “fast path” a la
información recolectada para conseguir alto nivel de comprensión con cierto nivel de
degradación en el detalle. Funciona utilizando a las colecciones de datos de los demás
utilitarios (Argus, Snort, p0f y Sebek) como módulos que transmiten datos dentro del proceso
Hflowd. Las porciones de flujo que se distinga que pertenecen a un único flujo bidireccional de
datos de red son etiquetadas e insertadas en la base de datos. Hflow2 también actúa como el
controlador de los inicios para las dependencias entre los módulos, ayudando al
aseguramiento de que el proceso no genere errores debido a que alguno de los módulos no
esté disponible.
Herramientas de monitorización:
Walleye
Esta es una aplicación desarrollada por el mismo proyecto Honeynet Project, inicialmente
pensada para probar el método de acceso a datos “fast path” y sus capacidades de análisis. Se
considera como la herramienta primaria para configurar y monitorear el ambiente de
Honeywall. A través suyo se pueden definir la mayoría de los parámetros más importantes de
manera rápida y ayudando a los nuevos administradores para que sea comprensible a los
distintos niveles de capacidades técnicas.
Las excepciones, es decir, los parámetros que no se pueden configurar a través de Walleye y
que deben establecerse en cada utilitario o en el Sistema Operativo son:
Zona horaria.
Tripwire.
Licenciado bajo GPLv3 Página 17
Postfix.
También, Walleye es el medio a través del cual se examina la “fast path”. Dentro de la
aplicación, es posible analizar en detalle cada flujo de datos, permite filtrar por día y hora.
Además, es posible aislar más aún los flujos de datos IP destino y origen, y/o también por
números de puertos. De esta forma, Walleye permite ver la comunicación relevante entre 2
hosts sin distraer con otra información capturada que no sea de interés para el análisis que se
pretenda llevar adelante. Es importante tener en cuenta, además, que se puede acceder a los
logs “crudos” del firewall y Snort, habilitando al administrador a una revisión a nivel de
paquetes del flujo de datos.
Argus
Argus observa el flujo de datos pasando a través de la interfaz de red y los flujos dirigidos hacia
la placa de red desde, como máximo, 5 outputs. Su propósito es generar flujos de datos que
correlacionen tanto los paquetes de datos asociados como el total de tiempo de las
comunicaciones, sirviendo como método de auditoría de datos de red. En Honeywall, lo datos
son recolectados de una manera tradicional y ruteados a través del proceso Hflowd donde se
correlacionan, formatean y filtran con otra información coleccionada desde otro software (p0f
y Snort) y solamente una representación reducida de estos registros de actividad de sistemas
es almacenada en la base de datos Hflow.
p0f
Es una utilidad para realizar fingerprinting de sistemas operativos que es muy versátil y rápida.
Es útil para el monitoreo del tráfico que ingresa a la honeynet ya que puede ayudar a
identificar aquellas direcciones IP en las cuales el sistema operativo va cambiando y permite
mejorar la exactitud de los eventos de IDS. La información de p0f se correlaciona con Argus y
Snort para obtener una imagen más clara de los flujos de información conocidos y luego
escritos en la base de datos Hflow2.
2.2.3.4 Configuración de honeywall para pruebas de viabilidad
2.2.3.4.1 Instalación
Honeywall se descarga desde https://projects.honeynet.org/honeywall/raw-
attachment/wiki/WikiStart/roo-1.4.hw-20090425114542.iso una vez descargada creamos la
maquina virtual en VirtualBox con los valores por defecto y 3 interfaces de red.
La primera interfaz de red será la que irá conectada a nuestra DMZ por lo que la configuramos
en adaptador puente y le asignamos la ip estática 192.168.1.8 que previamente hemos
configurado en nuestro router.
La segunda interfaz de red será asignada a la red interna con la interfaz vboxnet0 que será
nuestro Gateway para el host Debian.
La tercera interfaz será asignada también a la red interna con la interfaz vboxnet1.
Licenciado bajo GPLv3 Página 18
Al iniciar la máquina virtual para HoneyWall, nos pedirá que seleccionemos una iso para su
arranque, seleccionamos roo-1.4.hw-20090425114542.iso, de modo que arrancará honeywall
mostrándonos la siguiente imagen:
Una vez presionamos enter inicia la instalación tal y como se muestra en la siguiente figura:
El proceso de instalación es rápido y automático, finalizada la instalación la máquina virtual se
reinicia apareciéndonos el promt para indicar que nos loguemos.
Esta distribución tiene la particularidad de que no permite el loguin como root, nos logamos
con el usuario roo contraseña honey y ejecutamos su – contraseña honey de nuevo para
acceder como root, momento en el que se inicia el script de configuración indicándonos que
honeywall no ha sido configurado aún.
Este script sólo aparece en primer inicio, posteriormente si se necesita se encuentra ubicado
en /dlg .
A partir de este momento podemos empezar con la configuración de honeywall.
Licenciado bajo GPLv3 Página 19
2.2.3.4.2 Configuración
Una vez aceptado el acuerdo de licencia entramos en las 5 fases de configuración, se omiten
algunos pasos del script de configuración inicial por no ser relevantes o resultar obvios.
En el initial setup vamos a seleccionar la opción 3, interview y entramos en la primera sección.
2.2.3.4.2.1 Fase 1
Esta primera sección de configuración trata del direccionamiento de red de nuestros
honeypots, en nuestro caso le indicamos las ips 192.168.3.2 y 192.168.3.3 como ips de
honeypot, le indicamos la ip de red y la ip de broadcast, de este modo acabamos con la
primera fase de configuración.
2.2.3.4.2.2 Fase 2
En esta sección se nos pide que configuremos un acceso ssh o una interfaz de gestión que sería
la que recibiese todos nuestros logs, en un principio pensamos en desechar esta opción ya que
disponemos de acceso físico a la máquina pero honeywall dispone de una interfaz web de
configuración a la que se accede a través de esta ip así que decidimos configúrasela como la
192.168.1.6 en la interfaz eth0.
En las siguientes opciones de configuración de esta fase nos permite modificar el nombre de
host, añadir un dominio y nos pide que le indiquemos cuales son los dns, que en nuestro caso
le ponemos los del router ya no hemos configurado ningún servidor dns para tal propósito.
La interfaz de administración se activará en el siguiente inicio, denegamos configurar ssh ya
que no lo necesitamos.
El siguiente paso será cambiar el password de root que en nuestro caso será el mismo para
todas las máquinas que configuremos a partir de este momento: 20honeyroot14! Como no
Licenciado bajo GPLv3 Página 20
hemos podido configurar el teclado todavía en esta máquina vamos a omitir el símbolo
quedando 20honeyroot14 de password.
También nos solicita que cambiemos el password para el usuario roo, siguiendo el mismo
patrón que para root será 20honeyuser14 para esta y todo el resto de las máquinas.
El siguiente punto de configuración de esta fase es indicar los puertos admitidos para la
interfaz de administración, por defecto sugiere el 443, nosotros le vamos a añadir el 80.
A continuación nos pregunta las ips a las que se le permitirá el acceso a esta interfaz, en
nuestro caso ponemos la del host 192.168.1.5 que es nuestra máquina física y nos asignamos
la ip con estática en el fichero /etc/network/interfaces, también debemos asegurarnos que el
dhcp de nuestro router no asigna esta ip a ningún otro host, por lo que se la configuramos en
el dhcp del router asociándola a nuestra mac.
Posteriormente nos pregunta si deseamos habilitar la interfaz de gestión para el análisis de
datos a lo que respondemos afirmativamente.
La siguiente pregunta es si deseamos restringir las comunicaciones salientes en el firewall a lo
que respondemos que si para limitar accesos indeseados.
Ahora nos pregunta que puertos deseamos permitir acceso, punto en el que hemos de tener
en cuenta los puertos que van a ir configurados ambos honeypots.
2.2.3.4.2.3 Fase 3
La primera pregunta que nos hace en esta fase es sobre la configuración del límite de
conexiones de salida. Esta configuración nos permite establecer el límite de las conexiones
salientes de modo que una vez alcanzado este punto el resto de conexiones será rechazado
impidiendo que el honeypot comprometido dañe a otros sistemas.
Podemos limitar por segundos, minutos horas o días, en nuestro caso vamos a limitar por
horas poniendo como limite 60 conexiones tcp a la hora y 60 udp, junto con 500 paquetes icm
permitidos a la hora para permitir escaneos.
Ahora nos da la opción de hacer configurar el Snort en modo inline, de esta forma podremos
re direccionar tráfico en línea según sucede el ataque a nuestra conveniencia.
Tras la configuración del snort nos indica que podemos crear dos ficheros, uno con una lista
negra donde se almacenarán las Ips que generen spam y otro con una lista blanca donde
posteriormente detallaremos las ips que bajo ningún concepto serán consideradas spam.
Habilitamos ambas y pasamos a la siguiente pregunta donde habilitamos una lista con las ips a
las que bajo ningún concepto podrán alcanzar nuestros honeypots en la ruta /etc/fencelist.txt.
Esta lista es bastante importante ya que ayudará a crear las reglas del firewall cuando la
habilitemos en el siguiente paso.
Licenciado bajo GPLv3 Página 21
Dejamos desactivado el Roach motel mode ya que hay bugs a este respecto y con esto
concluimos la fase 3.
2.2.3.4.2.4 Fase 4 Relativa a la configuración DNS
En esta fase nos preguntan si deseamos permitir el tráfico ilimitado de dns hacia nuestros
honeypots a lo que respondemos afirmativamente, momento en el que nos da la opción de
permitirlo a unos si y a otros no por medio de una lista o indiscriminadamente y con esto
finaliza esta sección.
2.2.3.4.2.5 Fase 5 Relativa a la gestión de alertas
Nos permite recibir las alertas por mail, pero no va a ser nuestro caso y entramos en la
configuración de Sebek, nuestro gestor de logs.
Le facilitamos la ip de la interfaz de administración para que envíe sus alertas y el número de
puerto y con esto finalizamos la fase 5 y el initial setup.
2.2.3.4.2.6 Configuración propia
Una vez reinicia vuelve a aparecernos el script de configuración con un nuevo menú pero en
este caso le damos a exit y vamos a hacer nuestras configuraciones manualmente.
Lo primero reconfiguramos el teclado para que esté en nuestro idioma: vim
/etc/sysconfig/keyboard
Necesitamos instalar el Virtual BoxGuest Adittions, pero tenemos dependencias incumplidas,
para lo que necesitamos actualizar los repositorios, el problema es que nuestra máquina no
tiene conexión con ninguna otra red, no llegamos ni al host, cuanto menos al router, punto en
el que modificamos las reglas de Iptables de forma permisiva, comprobamos que Selinux esté
inhabilitado y volvemos a probar. Seguimos sin tener conexión, configuramos manualmente
las interfaces eth0 y eth1, pero sigue sin permitirnos conectar ni con el router, tras mucha
lectura encontramos que no reconoce las interfaces virtuales, por lo que sin conexión con el
exterior por muy bonita que pudiese quedar nuestra topología con honeywall en medio no nos
queda otra opción que declinar su uso.
2.2.3.4.2.7 Deficiencias
No hay forma de conectar honeywall con el exterior, cabe la posibilidad que montando un
servidor dhcp propio y un servidor dns propio se pudiese.
2.2.3.4.2.8 Conclusiones
Sin la actualización del sistema, la instalación del vbox guest aditions y la conexión con otros
puntos de la red se hace inviable, pero queda pendiente para futuros estudios, instalada en
una máquina física con cable Ethernet.
Licenciado bajo GPLv3 Página 22
2.2.4 Honeydrive
Honeydrive es una distribución basada en Xubuntu para la implantación de honeypots y sus
herramientas se detallarán a continuación.
2.2.3.1 Herramientas para el manejo de amenazas MALWARE
Las herramientas de recolección y análisis de malware dentro de honeydrive son:
Mwcrawler
Mwcrawler es una herramienta para coleccionar malware. Su funcionamiento consiste en
conectarse a listas de urls que distribuyen malware y descargarlo para almacenarlo y
estudiarlo.
Thug
Esta herramienta se conecta a urls maliciosas simulando el comportamiento del navegador
web en el lado del cliente.
Dionaea
Dionaea ofrece servicios vulnerables, accesibles en la red, con el fin de obtener una copia del
malware que intente aprovecharse de los mismos.
Es capaz de emular los siguientes protocolos:
- SMB: Es el protocolo principal que implementa dionaea, debido a su larga trayectoria
de vulnerabilidades, y la fácil explotación de las mismas se convierte en un caramelo muy
dulce de nuestro honeypot.
- Http, Https: Establece tanto conexiones Http como Https y las cierra haciendo uso de
los datos obtenidos en estos puertos. Para Https se genera un certificado al inicio de la
aplicación
- Tftp: Dionea ofrece una implementación que permite la descarga de ficheros, aunque
no se tiene constancia de que este protocolo sea objetivo de ataques automatizados, si es
conocida la existencia de vulnerabilidades para este protocolo.
- Ftp: Dionaea ofrece un servidor básico de ftp en el puerto 21, que permite crear
carpetas y bajar y subir archivos. Al igual que tftp, no se tiene constancia de que algo
interesante ocurra con respecto a este servicio en lo que a ataques de malware automatizados
se refiere.
- SIP. Las características principales del modulo SIP son:
- Soporta las mayoría de las peticiones (OPTIONS, INVITE, ACK, CANCEL, BYE)
Licenciado bajo GPLv3 Página 23
- Soporte para sesiones SIP múltiples y streams RTP de audio
- Grabación de los datos RTP
- Agregar usuarios y contraseñas
- Guardar un registro a la base de datos SQL
- Mssql: Dionaea implementa el protocolo Tabular Data Stream, el cual es usado por
MSSQL server
Escucha en el puerto tcp/1433 y permite a los clientes logearse. Puede decodificar las
peticiones echas a la base de datos, pero como no hay base de datos, Dionaea no puede
contestar mySQL
Amun
Amun es un honeypot de baja interacción. Como dionaea, la finalidad última de Amun es
obtener una copia del malware que esta atacando nuestro honeypot. Amun emula una serie
de servicios vulnerables con el fin de que programas que andan sueltos por la red (malware)
realicen un ataque que tenga como objetivo nuestro sistema honeypot
Una vez lanzado el ataque, Amun crea la ilusión al malware de que el servicio ficticio es
vulnerable, de esta forma dicho malware mandara una copia de si mismo a nuestro honeypot,
copia que después podremos usar para analizarla con más detalle.
Una vez que Amun se ha descargado el malware, puede, al igual que Dionaea, guardarlo en el
disco local para lo cual usa el md5 del archivo como nombre, o enviarlo a los siguientes
servicios de análisis externos: anubis, cwsandbox o joebox. El resultado puede ser consultado
bien vía web o vía mail
2.2.3.2 Herramientas para el análisis de ataques no automatizados
En este caso la mayoría del software que usamos, guarda los payloads que son enviados al
sistema para su posterior análisis.
Dentro de esta categoría nos encontramos con:
Kippo
Kippo es un honeypot que emula un servicio ssh casi de forma perfecta. También tiene una
segunda funcionalidad interesante y es la forma que tiene de entregarnos sus estadísticas,
crea una página web con geo localización y un tipo de mapas muy visuales donde nos indica de
que partes del mundo se han recibido los ataques, cuales son las combinaciones de usuario
passwords más utilidades y los comandos utilizados en el servidor una vez conseguida la
penetración al mismo.
De fácil configuración es sin duda una herramienta muy útil para proteger el puerto 22 de
ataques sistemáticos aunque permite la configuración del puerto.
Licenciado bajo GPLv3 Página 24
Otro de los puntos a destacar es que cuenta con una herramienta que nos permite reproducir
los logs en la terminal como si de un video se tratase.
Tiny Honeypot (thp en lo que sigue).
Es un honeypot que hace uso de Iptables para hacer decisiones sobre como re direccionar el
tráfico TCP/IP entrante. El script Iptables de que es provisto por thp, que se encuentra en
/etc/iptables.rules, correrá en la mayoría de los entornos con las mínimas modificaciones.
Estas modificaciones crecerán si el host en el que estamos ejecutando thp esta actuando
como router.
Una de las cosas interesantes de thp es que permite a los servicios que tengamos en el
sistema, seguir ejecutándose sin que thp interfiera en su funcionamiento.
Wordpot
Wordpot es un honeypot que emula la aplicación web Worpress. Los vectores de ataque más
usuales en Worpress son sus plugins. Los plugins que Wordpot emula los podemos encontrar
en /opt/wordpot/wordpot.conf.
Está pensado para que sea extensible, es decir, para que podamos programar nuestros propios
falsos plugins.
Glastopf
Glastopf es un honeypot de aplicación web de baja interacción que puede emular cientos de
vulnerabilidades, con el fin de obtener datos de ataques que tienen como objetivo
aplicaciones web. Su principio de funcionamiento es simple: responde a los ataques con la
respuesta que el atacante esta esperando en su intento por explotar la aplicación web
Licenciado bajo GPLv3 Página 25
2.3 Sistema operativo Windows
2.3.1 Tipos de ataques comunes en Windows
Según Sans las 10 vulnerabilidades comunes en Windows son:
Existencia de servidores web y sus servicios asociados
Cuando se instala un servidor web en un equipo Windows, en su configuración por defecto, se
activan algunos servicios y/o configuraciones que son vulnerables a diversos tipos de ataques,
que van desde la denegación de servicio hasta el compromiso total del sistema.
Si la máquina debe actuar como servidor web, es preciso verificar que la versión del mismo está
actualizada, se ha fortalecido la configuración y se han desactivado los servicios innecesarios.
Es importante indicar que algunas versiones de Windows instalan, en su configuración por
defecto, el servidor web IIS.
Servicio Workstation
Existe una vulnerabilidad de desbordamiento de búfer en el servicio Workstation de Windows
2000 (SP2, SP3 y SP4) y Windows XP (hasta SP1) que puede ser utilizada por un usuario remoto
para forzar la ejecución de código en los sistemas vulnerables. Éste código se ejecutará en el
contexto de seguridad SYSTEM, lo que permite un acceso completo en el sistema
comprometido.
Servicios de acceso remoto de Windows
Todas las versiones de Windows incluyen mecanismos para permitir el acceso remoto tanto a
las unidades de disco y al registro así como para la ejecución remota de código. Estos servicios
han demostrado ser bastante frágiles y la existencia de numerosas vulnerabilidades ha sido
uno de los mecanismos preferidos por los gusanos y virus para propagarse. Es muy importante
verificar que se han aplicado las diversas actualizaciones publicadas para impedir la acciones
de los mismos.
Microsoft SQL Server
El gestor de base de datos de Microsoft ha sido, tradicionalmente, un producto con un nivel de
seguridad muy bajo.
Por un lado, existen un gran número de vulnerabilidades de seguridad, muchas de ellas críticas,
que pueden ser utilizadas para acceder y/o modificar a la información almacenada en las bases
de datos.
Pero además, la configuración por defecto de Microsoft SQL Server facilita que sea utilizado
como plataforma para la realización de ataques contra otros sistemas. Podemos recordar los
gusanos SQLSnake y Slammer que tuvieron un efecto perceptible en toda la red Internet.
Licenciado bajo GPLv3 Página 26
Autenticación de Windows
Es habitual encontrar equipos Windows con deficiencias en sus mecanismos de autenticación.
Esto incluye la existencia de cuentas sin contraseña (o con contraseñas ampliamente conocidas
o fácilmente deducibles). Por otra parte es frecuente que diversos programas (o el propio
sistema operativo) cree nuevas cuentas de usuario con un débil mecanismo de autenticación.
Por otra parte, a pesar de que Windows transmite las contraseñas cifradas por la red,
dependiendo del algoritmo utilizado es relativamente simple aplicar ataques de fuerza bruta
para descifrarlos en un plazo de tiempo muy corto. Es por tanto muy importante verificar que
se utilizado el algoritmo de autenticación NTLMv2.
Navegadores web
Los diversos navegadores habitualmente utilizados para acceder a la web pueden ser un
posible punto débil de las medidas de seguridad si no se han aplicado las últimas
actualizaciones.
Internet Explorer es, sin duda, el producto para el que se han publicado más actualizaciones y
que cuenta con algunos de los problemas de seguridad más críticos. No obstante debe
recordarse que otros navegadores como Opera, Mozilla, Firefox y Netscape también tienen sus
vulnerabilidades de seguridad.
Aplicaciones de compartición de archivos
Las aplicaciones P2P se han popularizado en los últimos años como un sistema para la
compartición de información entre los usuarios de Internet, hasta el punto de convertirse en
uno de los métodos preferidos para obtener todo tipo de archivos. De hecho, muchos usuarios
seguramente no entenderían la red actual sin la existencia de las aplicaciones P2P.
No obstante, algunas aplicaciones populares de compartición de archivos tienen serios
problemas de seguridad que pueden ser utilizados por un atacante para obtener el control del
ordenador del usuario.
Otro riesgos habituales, no estrictamente de seguridad pero si relacionado ya que atentan
contra nuestra privacidad, son los diversos programas espías incluidos en algunas de las
aplicaciones más populares de compartición de archivos. Otro problema habitual es la
compartición inadvertida de archivos que contienen información sensible.
Por último, en los últimos meses se ha popularizado la utilización de las redes P2P como un
nuevo mecanismo para la distribución de virus y gusanos.
Subsistema LSAS
El subsistema LSAS (Local Security Authority Subsystem) de Windows 2000, Windows Server
2003 y Windows XP es vulnerable a diversos ataques de desbordamiento de búfer que pueden
permitir a un atacante remoto obtener el control completo del sistema vulnerable. Esta
vulnerabilidad ha sido explotada por gusanos como el Sasser.
Licenciado bajo GPLv3 Página 27
Programa de correo
Diversas versiones de Windows incluyen de forma estándar el programa de correo Outlook
Express. Se trata de un producto que, si no se encuentra convenientemente actualizado, puede
fácilmente comprometer la seguridad del sistema.
Los principales problemas de seguridad asociados a Outlook Express son la introducción de
virus (sin que sea necesario ejecutar ningún programa) y el robo de información sensible.
Las versiones actuales de Outlook Express, configuradas de una forma adecuada, protegen al
usuario ante estos problemas de seguridad.
Sistemas de mensajería instantánea
La mensajería instantánea ha pasado de ser un sistema de comunicación utilizado básicamente
para contactar con amigos y familiares a ser una herramienta de comunicación habitualmente
utilizada en las empresas, especialmente entre aquellas que disponen de diversos centros de
trabajo.
Los diversos programas de mensajería instantánea pueden ser víctimas de ataques explotables
de forma remota y que pueden ser utilizados para obtener el control de los sistemas
vulnerables.
Es conveniente que el usuario de estos productos verifique que utiliza la versión actual, con las
últimas actualizaciones de seguridad.
2.3.2 Honeypots en Windows
Existen varias soluciones de honeypot para Windows, algunas comerciales como pueden ser
Specter, KFSensor, PatriotBox, algunos de ellos tienen versiones descargables en modo de
prueba para poder experimentar con ellos. Por otro lado existen soluciones gratuitas como
pueden ser HoneyBot o Valhala, omnívora que nos permiten montar honeypots en Windows
server.
Antes de elegir cual de ellos vamos a montar, los iremos probando de uno en uno y viendo sus
diferencias y aplicaciones para saber cual se ajusta a nuestras pretensiones.
Empezamos por Omnívora.
Omnívora
Omnívora es un honeypot de baja interacción diseñado para capturar malware.
Está provisto de vulnerabilidades específicas para los siguientes puertos:
Licenciado bajo GPLv3 Página 28
Se descarga desde su web oficial http://omnivora.sourceforge.net/ y su instalación es sencilla,
típica de cualquier programa en Windows, doble click al exe y se ejecuta el instalador que está
en alemán, sin posibilidad de elegir ningún otro idioma, sin embargo no pide nada especial por
lo que bastará con darle a siguiente y estará hecha la instalación.
Una vez finalizada nos aparece el archivo léeme con el siguiente texto:
Omnivora - Honeypot - Version 1.0
Installation:
Omnivora emulates serveral vulnerabilites of Windows services. To stop the original services
you can adjust your service settings or run the included script "svc2kxp.bat". If the script is run
in option 2 ("standard") it will make all necessary adjustments. If you need one of the emulated
services you'll have to disable the emulation of this vulnerability.
Notice: The vulnerability server won't start, if one selected port is blockedby another service.
Database: To enable database logging you have to install the MySQL ODBC driver.
I am using version 3.41.15.
2008 Philipp Trinius
Nuestro Windows Server en este momento está en una máquina virtual separada de la red
anteriormente descrita, partimos de una instalación limpia para pruebas antes de tomar la
decisión sobre que honeypot o conjunto de ellos implementaremos. No debería tener conflicto
de puertos, sin embargo cuando intentamos iniciar el servidor nos da un mensaje de error que
diciendo que los puertos están siendo utilizados:
Licenciado bajo GPLv3 Página 29
Siguiendo las recomendaciones del archivo léeme, nos vamos al directorio donde está
instalado omnívora e intentamos correr el script svc2kxp.bat para la configuración de los
puertos con el siguiente resultado:
Al parecer este honeypot no es compatible con Windows server, pero para estar seguros
probamos la instalación en Windows7 con similar resultado, al parecer este honeypot de baja
interacción sólo funciona en Windows xp, por lo que por prometedor que pareciese queda
abandonado de nuestro proyecto por problemas de incompatibilidad.
WinHoneyD
Honeyd es un honeypot de baja interacción que permite emular el finguerprint de otros
sistemas operativos y crear un enrutamiento interno emulando servicios en sistemas
fantasma.
Licenciado bajo GPLv3 Página 30
Para descargar la versión de Windows es necesario registrarse en
http://www2.netvigilance.com/ donde enviándonoslo al correo nos facilitan el siguiente link
de descarga para nuestro Honeyd
http://www2.netvigilance.com/winhoneyd/download/winhoneyd-1.1.1.zip
HoneyD nos permite configurar cualquier servicio emulado, con los script´s existentes o
facilitándonos la implementación de uno nuevo.
Trabaja en todo el rango de puertos TCP siendo capaz de emular sistemas y servicios en todas
las ip´s no usadas, contribuyendo al propósito del Honeypot en cuanto a "distraer" al atacante,
desde fuera parecerá una red con diversos sistemas lo que hará jugoso el ataque.
Otra de las funciones interesantes de Honeyd es que puede emular distintas
implementaciones de sistemas operativos a nivel de pila TCP/IP a la vez, es decir, que a una
petición FIN a un puerto, podemos hacer para un servicio emulado que responda, y para otro
servicio que no responda...
Permite emular más de 400 sistemas descritos en el fichero nmap.prints.
Debido a que no hemos encontrado ningún tipo de incompatibilidad y es un honeypot de baja
interacción pero interesante para la investigación será uno de los elegidos para nuestro
servidor Windows.
Kfsensor
KFSensor tiene un sentido claro de lo que se necesita para aparentar ser un host de Windows.
Al igual que Honeyd - WIN32 , KFSensor es un honeypot de baja interacción. A diferencia de
Honeyd - WIN32 , KFSensor viene con 77 puertos preconfigurados ( 58 puertos TCP y 19
puertos UDP) . La mayoría de los puertos se encuentran en ambientes típicos de Windows,
aunque KeyFocus ha lanzado en algunos puertos troyanos arbitrarias para atraer a los intrusos
de exploración para servidores vulnerables.
Es un tipo de honeypot casi Plug and Play ya que su instalación sólo se tiene que descargar el
software y ejecutar. Su interfaz es sencilla y contiene asistentes de ayuda que permiten guiar
al usuario para una buena configuración
KFSensor ofrece emulación simple servicio de IIS, FTP, Telnet y Exchange. Las conexiones a IIS
ofrecen una web EN CONSTRUCCION. Las conexiones al puerto 25 dan una respuesta de
intercambio de banners de texto realista, y la emulación de servicios acepta un número
limitado de comandos básicos de SMTP.
KeyFocus podría haber fácilmente hecho lo mismo por otros puertos de servidor de Exchange
comunes, como los puertos POP3 e IMAP, pero por alguna razón no lo hizo.
KFSensor hace mímica básica de Terminal Services para las conexiones RDP, de Symantec
pcAnywhere , Citrix MetaFrame, Virtual Network Computing (VNC ), Wingate, y más. Puede
usar los códigos de control y secuencias de comandos para personalizar cada puerto y el
Licenciado bajo GPLv3 Página 31
servicio de emulación. Durante las pruebas, el cliente remoto pcAnywhere pensó que estaba
conectado brevemente con el host directamente antes de cerrar la conexión.
KFSensor imita con precisión NetBIOS abiertos y puertos RPC de Windows, dando al honeypot
una respuesta realista de Windows
KFSensor destaca en casi todo lo que hace, pero tiene algunos puntos débiles:
KFSensor no es tan flexible o escalable como Honeyd - WIN32. Debido a que opera en la capa
de aplicación, no puede simular la pila IP y no contiene los ajustes para simular rutas de red,
las marcas de tiempo del sistema, problemas de latencia, etcétera, (aunque para ser justos, la
mayoría de los intrusos se pierda estas detalles). Además, KeyFocus no recomienda el apoyo a
más de 256 puertos por host, mientras que Honeyd - WIN32 puede soportar miles de puertos y
direcciones IP por host.
Al igual que otros honeypots de nivel de aplicación, KFSensor puede responder solamente a la
dirección IP asignada a su anfitrión. En comparación, Honeyd - WIN32 puede emular una
multitud de los ejércitos y las redes IP.
También es importante señalar que el precio de su licencia es de 990$ Dólares, aunque
permite una versión trial, que probaremos añadiéndole los servicios de iss aunque no se
detallará su configuración ya que es prácticamente inexistente y va acompañado de wizart que
hace de guía durante la misma.
2.4 Fase de planificación y diseño
2.4.1 Planificación
Esta etapa se deciden las fases de proyecto, al menos en rasgos generales, tal como se
muestra a continuación:
Figura 1 Análisis y diseño del proyecto
Análisis y diseño
Esta etapa tiene tres funciones principales:
- Estudiar el nivel de complejidad que debe tener nuestro honeypot.
- Decicdir que herramientas lo componen y sobre que sistemas
-Resolver la topologia para que se adapte a los puntos anteriores.
Implementación
En esta etapa se hará efectivo todo lo diseñado en el punto
anterior
Testing
Esta será la fase donde nos podremos a prueba antes de exponernos al
mundo real.
Plantearemos casos de uso de que corroboren
la arquitectura.
Puesta en producción
En este punto dejaremos expuesto el
sistema para que empiece a recibir ataques reales.
Licenciado bajo GPLv3 Página 32
Análisis
La etapa de análisis comprende:
El estudio de los sistemas operativos que van hospedar a nuestros honeypots.
El análisis de soluciones de honeypots para Windows y linux.
El estudio de las herramientas que componen cada una de estas soluciones.
Las pruebas relativas a una posible implementación de alguna de estas soluciones.
Este estudio ha sido realizado ya en este documento en los puntos del 2.1 al 2.4.
Diseño
La fase de diseño contempla:
El estudio de una topología de red optima para nuestras necesidades.
La elección y lógica de las herramientas a implementar en cada una de las soluciones
sobre cada uno de los sistemas.
Los servicios a emular en cada uno de los sistemas operativos elegidos.
Implementación
En esta fase se realizarán las configuraciones propias acorde al diseño y topologías
anteriormente elegidos. Este punto se desarrolla en el Capítulo 3 de este documento.
Testing
Una vez realizadas las configuraciones oportunas, pasaremos a la fase de pruebas para
comprobar que no se han cometido errores en la implementación y que todo funciona como
debiera.
Se probarán las herramientas implementadas y la lógica de los sistemas junto con el
funcionamiento de la red.
Exposición de los sistemas o puesta en producción
En este punto dejaremos expuesto el sistema para que empiece a recibir ataques.
Este punto se detalla en el capitulo 4 de este documento.
Recogida de datos
Una vez se hayan producido los ataques se pasará a la recogida de datos por medio de los logs
que genera cada una de las soluciones implementadas.
Análisis y estudio de los datos obtenidos.
Con todos los datos ya obtenidos realizaremos el análisis de los mismos.
Este punto se detalla en el capitulo 5 de este documento.
Licenciado bajo GPLv3 Página 33
Productos que acompañan a este TFM
Se adjunta una versión configurada que fue la puesta en producción de honeydrive
como maquina virtual independiente.
Se adjunta una versión de honeydrive mejorada con los scripts descritos sobre Mastiff
y maltrive creada después de la fase de puesta en producción.
Se adjunta matrioskahoney que contiene el honeypot de Windows, una versión de
honeydrive sin configurar tal que replica la configuración de diseño de la red,
honeydrive no se configuró en matrioskahoney por problemas de rendimiento,
matrioskahoney también contiene otro máquina virtual con otro honeypot que no se
describe en este documento por el mismo caso que honeydrive dentro de
matrioskahoney.
2.4.2 Diseño
Una vez decididos los sistemas a emplear es necesario pensar en cómo se van a implementar
para que resulte lo más seguro y eficaz posible.
Una buena planificación de la arquitectura conlleva tener en cuenta todos los factores que la
componen y es una herramienta crucial que servirá de guía para agilizar cualquier
implementación.
Esta fase ha resultado la más complicada, ya que a pesar de tener claros los sistemas que
vamos a utilizar para nuestros honeypots, Windows server 2008R2 y HoneyDrive, disponemos
de recursos limitados y la cuestión era pensar la forma adecuada de montar nuestro proyecto
sin que afectase al resto de la LAN.
2.4.2.1 Descripción
Para ponernos en antecedentes, nuestros recursos son los siguientes:
- Un ordenador de sobremesa: i5 intel 5550, 8gb de RAM, SO Debian Jessie 3.2.0-4-
amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
- Un router Netgear CG3100D
- Mucho VirtualBox
Nuestra Lan:
En nuestra red de área local hay otros seis equipos más dispositivos móviles que no pueden
verse afectados por nuestro proyecto, ni soportan modificaciones continuas en el router para
pruebas.
2.4.2.2 Resolución inicial y diseño de la topología
Tras mucha cabila se tomó la decisión de anidar máquinas virtuales quedando la estructura del
siguiente modo:
Licenciado bajo GPLv3 Página 34
Ordenador de sobremesa como host conectado directamente al router (por wifi):
- Virtualbox con interfaz vboxnet0
- Snort
- Arno Iptables
Maquina virtual 2 Debian Wheezy 64, en adelante MatrioskaHoney:
Esta máquina albergará Virtualbox y dentro nuestros dos honeypots, honeydrive y Windows
Server 2008 R2, de tal modo que visto esquemáticamente quedará así:
Figura 2 Esquematización de diseño.
Aprovecháremos la capacidad de Virtualbox para crear interfaces de red virtuales para separar
las redes, esto unido al linux kernel routing table e Iptables nos da la versatilidad necesaria
para nuestro diseño de red.
Host real S.O Debian Jessie
Honeypot Windows
Server 2008R2
HoneyPot Xubuntu
honeydrive
Maquina Virtual Debian 7.5
MatrioskaHoney
VirtualBox
Licenciado bajo GPLv3 Página 35
La topología lógica de red será la siguiente:
Figura 3 Topología de la red
2.4.2.3 Resolución Final
Aunque el diseño anterior nos parecía el adecuado, tras la fase de pruebas no resultó útil, por
lo que la solución final fue ir configurando la ip de la dmz 192.168.1.6 en el honeypot a
exponer, durante el documento se explicará la configuración de la fase de diseño, no la
efectiva finalmente.
Licenciado bajo GPLv3 Página 36
3. Capítulo 3. Metodología de instalación, configuración y
testing de arquitectura.
3.1 Instalación de las máquinas virtuales y configuración de la red.
La instalación de Virtualbox es tan sencilla como ejecutar el comando “aptitude install
virtulbox” con privilegios de root, si nos encontramos en una máquina Windows basta con
descargarse le ejecutable de la página oficial de VirtualBox e instalarlo, por lo que no
hablaremos sobre ese punto.
Una vez instalado es necesario crear nuestras máquinas virtuales y configurar las interfaces de
red adecuadamente para que se adapten a nuestra topología.
Las máquinas a instalar son una Debian 7, está última con el requerimiento especial de que
tendrá que disponer de suficiente capacidad de disco duro como para albergar en su interior la
máquina virtual de linux con Honeydrive y la de Windows con Honeyd las cuales instalaremos
posteriormente.
Antes de instalar las máquinas virtuales crearemos dos interfaces de red virtual que nos
permitirá mayor versatilidad con nuestra topología, (mostrado en la figura 1 del anexo).
La primera interfaz será la vboxnet0 a la que se le asignará el rango 192.168.2.1.
La segunda interfaz vboxnet1 se le asignará la red 192.168.10.1 y quedará como interfaz de
reserva para posibles ampliaciones. Tal como se muestran en las figuras del 2 y 3 del anexo.
Para hacer esto nos vamos a la siguiente ruta:
Archivo, Preferencias, Red y le damos a añadir interfaz configurando el direccionamiento
deseado.
Otra opción a reseñar es que cómo medida de seguridad se toma una instantánea del estado
de cada una de las máquinas recién configuradas para en el caso de que surja cualquier
inconveniente poder restaurarlas a su estado original sin mayor problema.
Una vez finalizada la parte de configuración de la red creamos nuestra máquina virtual a la que le asignamos las siguientes características: 3GB de Ram y el disco dejamos que se expanda automáticamente tal como se muestra en la figura 4.
Licenciado bajo GPLv3 Página 37
3.2 Instalación y configuración de Debian Una vez instalado nuestro hipervisor instalamos una imagen netinstall Debian Wheezy
descargada de la página oficial de Debian.
Durante la instalación:
Se configura LVM cifrado, la password es honeyroot14
Como entorno de escritorio se ha elegido Mate Desktop 1.8 por preferencias de usabilidad,
fiabilidad y eficiencia para lo cual se le añaden los repositorios de blackports.
Usuarios y contraseñas:
Nombre de la maquina: matrioska
Nombre de usuario: tarrito
Password de tarrito: 20honeyuser14
Password de root: 20honeyroot14
A partir de este punto cuando hagamos referencia a esta máquina la llamaremos
honeymatrioska.
Post instalación:
Paquetes adicionales:
- Terminator
- Virtualbox
- Snort
- Aide
- Lightdm
- Chromium
- VirtualBox Guest Additions (Se instala en todas las máquinas para permitir funciones
avanzadas por lo que no se volverá a nombrar.)
Creamos una carpeta compartida de forma temporal para pasarle las imágenes necesarias.
Configuración de la red:
Con todo ya instalado hemos de configurar la red para que se ajuste a nuestras necesidades y
no llevarnos sorpresas incómodas luego con las máquinas virtuales. Para ello abrimos el
fichero /etc/network/interfaces con nuestro editor favorito y lo configuramos como sigue:
Licenciado bajo GPLv3 Página 38
Comprobamos que la configuración se haya hecho efectiva reseteando previamente las
interfaces de red con /etc/init.d/networking reload:
Configuración de Snort:
Una vez finalizada la instalación se ejecuta con privilegios de superusuario dpkg-reconfigure
snort para entrar en la interfaz dialog que nos facilita su configuración.
Le indicamos las ips de honeymatrioska 192.168.1.6, 192.168.3.1, 192.168.3.2 sin activar el
modo promiscuo ni el envío de mails tal como se muestra en las figuras de la 5 a la 9.
Una vez configurado snort instalamos en virtualbox dentro de honeymatrioska y empezamos a
con nuestros honeys.
# The primary network interface in file /etc/network/interfaces
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.6
netmask 255.255.255.0
gateway 192.168.1.2
root@matrioska:~# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:d5:13:2e
inet addr:192.168.1.6 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fed5:132e/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500
Metric:1 RX packets:3951 errors:0 dropped:0 overruns:0 frame:0 TX packets:469 errors:0
dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:315970 (308.5 KiB) TX
bytes:30582 (29.8 KiB)
lo Link encap: Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0
frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
Licenciado bajo GPLv3 Página 39
3.3 Instalación honeydrive
Diseño elegido de honeydrive
Una vez descrito todo el software que compone Honeydrive, debemos escoger cómo será la
arquitectura elegida de nuestro honeypot ya que los servicios descritos anteriormente son
muy versátiles y dispone de múltiples configuraciones, algunos de ellos trabajando en los
mismos puertos con la configuración por defecto.
Nuestra pretensión no ha sido cubrir todos los servicios posibles si no aquellos que tienen un
atractivo especial en algunos casos para el atacante y en otros para nosotros como objeto de
la investigación, normalmente los honeypots suelen ser pasivos pero este se pretende activo y
con el conocimiento del atacante por lo que los servicios no tienen que ser coherentes con el
sistema operativo.
Lo primero es instalar nuestra imagen de honeydrive dentro del virtualbox de honeymatrioska
para lo cual sólo tenemos que darle doble click al fichero punto ova previamente descargado,
la única modificación que hacemos es aumentarle el número de procesadores a emular en la
primera pestaña de instalación para que funcione de forma más fluida.
Una vez instalada nuestra máquina virtual le cambiamos los passwords por defecto dejándolos
del mismo modo que en honeymatrioska.
Ahora pasaremos a las decisiones tomadas en la fase de diseño sobre los servicios que
correrán en esta máquina para proceder a su configuración.
Las decisiones tomadas son las siguientes:
Dionea se encargará de los protocolos smb, sip y de las bases de datos, su objetivo
será el analizar el malware y los ataques que en estos servicios se producen.
Tiny honeypot actuará como honeypot para los protocolos ftp, smtp cubriendo de
este modo servicios de correos y transferencia de archivos.
Wordpot estará montado en el puerto 80 emulando wordpress.
Glastopf será usado en el puerto 8080 para ver los ataques que reciben los servidores
web.
Amunt será configurado para emular la vulnerabilidad de Symantec Remote
Management Stack Buffer Overflow
Honeyd emulará un sistema FreeBSD, con dos routers cisco y un firewall checkpoint
Kippo cumpliendo con su función emulará un servicio ssh vulnerable.
Con esto en mente, hacemos unas configuraciones previas iniciales tales como:
Configurar la red
Actualizar el sistema
Cambiarle el del teclado
Y comenzamos a configurar nuestras herramientas.
Licenciado bajo GPLv3 Página 40
3.4 Configuración Honeydrive
Empezaremos por configurar las herramientas de detección de malware, aunque debido a la
naturaleza de este honeypot que se explicará en detalle en la parte de exposición nos parece
poco probable llegar a obtener ningún tipo de malware, queremos probar la eficiencia de las
herramientas anteriormente descritas.
3.4.1 Mwcrawler
Mwcrawler se inicia con /opt/mwcrawler/mwcrawler.py y es un script en python, cuando
fuimos a iniciarlo para comprobar su funcionamiento dio el siguiente error:
Comprobamos que dispusiese de la librería BeatifultSoup y revisamos la línea de código pero
no vimos el error y aunque seguramente sea obvio en este punto no andamos con mucho
tiempo para depurar código por lo que buscamos una alternativa y encontramos a maltrive,
creado por Kile Maxwell, un folk de mwcrawler que será implementado en la siguiente versión
de honeydrive.
3.4.1.1 Maltrieve, Características, instalación, configuración y puesta en
funcionamiento.
Maltrieve está licenciado con GPLv3 por lo que podemos leer su código fuente y puede ser
importado compartido y distribuido.
Para instalar maltrive todo lo que tenemos que hacer es irnos a su repositorio de github y
descargarnos los ficheros en la carpeta opt restando el nombre de los mismos.
Maltrive tiene un funcionamiento similar a mwcrawler, se descarga el malware directamente
de las fuentes provistas en una lista de urls que incorpora en su código, sigue siendo un script
en python pero con funcionalidades mejoradas como el soporte para Cuckoo Sandbox y
VxCarge.
honeydrive@honeydrive:~$ /opt/mwcrawler/mwcrawler.py
Malware Parser v0.4
- Error parsing http://minotauranalysis.com/malwarelist-urls.aspx
- Fetching from NovCon Minotaur
Traceback (most recent call last):
File "/opt/mwcrawler/mwcrawler.py", line 224, in <module>
minotaur(parse('http://minotauranalysis.com/malwarelist-urls.aspx'))
File "/opt/mwcrawler/mwcrawler.py", line 162, in minotaur
for row in soup('td'):
TypeError: 'NoneType' object is not callable
Licenciado bajo GPLv3 Página 41
Descarga el malware en el directorio /tmp/malware que ha de ser creado en el caso de que no
exista o modificar el código para que se descargue en otro directorio.
Comprobamos que se cumplen sus dependencias, BeatifulSoup, lxml y lo iniciamos llamándolo
con python, momento en el que se pone a trabajar. Se puede ver funcionando en la figura 9 .
Para gestionar de un modo más correcto los resultados de Maltrieve utilizaremos Mastiff para
lo cual clonamos su repositorio: git clone https://git.korelogic.com/mastiff.git en el directorio
/opt/
Mastiff es un framework que automatiza el proceso de extraer las características clave de un
fichero con diferentes tipos de formato de archivos, o explicado de otro modo los resultados
que nos da Maltrieve están codificados en md5 y son una larga lista de hashes donde es difícil
discernir que tipo de fichero es cada uno, Mastiff nos va a ayudar con esta tarea, por lo que
para dar una definición más exacta Mastiff es un framework analizador de malware.
3.4.1.2 Mastiff
Para hace funcionar a Mastiff al igual que con los otros scripts hemos de lanzar su fichero
mas.py pasándole como argumento el nombre del fichero con la ruta absoluta a analizar, pero
antes, como con cualquier otro software, lo primero es comprobar que se cumplen todas las
dependencias que este necesite para trabajar, Mastiff necesita de yapsy un gestor de plugins,
así que lo instalamos con pip, una vez instalado lo iniciamos y nos muestra la ayuda disponible
de la cual mostramos un fragmento porque tiene bastantes opciones:
Nosotros queremos que analice los ficheros contenidos en todo un directorio le hemos
añadido un pequeño script sacado de tekdefense:
root@honeydrive:/opt/mastiff# python mas.py
Usage: mas.py [options] FILE|DIRECTORY
Options:
-c CONFIG_FILE, --conf=CONFIG_FILE
Use an alternate config file. The default is
'./mastiff.conf'.
-h, --help Show the help message and exit.
-l PLUGIN_TYPE, --list=PLUGIN_TYPE
List all available plug-ins of the specified type and
exit. Type must be one of 'analysis' or 'cat'.
-o OVERRIDE, --option=OVERRIDE
Override a config file option. Configuration options
should be specified as 'Section.Key=Value' and should
be quoted if any whitespace is present. Multiple
overrides can be specified by using multiple '-o'
options.
-p PLUGIN_NAME, --plugin=PLUGIN_NAME
Only run the specified analysis plug-in. Name must be
quoted if it contains whitespace.
-q, --quiet Only log errors.
-t FTYPE, --type=FTYPE
Force file to be analyzed with plug-ins from the
specified category (e.g., EXE, PDF, etc.). Run with
Licenciado bajo GPLv3 Página 42
Que lanzamos invocándolo con: python autoRunMas.py en este punto nos da algún error ya
necesita la librería de pydeep para funcionar que a su vez tiene como dependencia ssdeep que
a su vez tiene como dependencia cython, instalamos cython con pip y para ssdeep y para el
resto creamos un sencillo script:
#!/bin/sh
cd /opt/
wget http://sourceforge.net/projects/ssdeep/files/ssdeep-2.10/ssdeep-2.10.tar.gz
tar -xvzf ssdeep-2.10.tar.gz
rm -f ssdeep-2.10.tar.gz
mv ssdeep-2.10 ssdeep
cd /opt/ssdeep/
./configure
make
make install
ldconfig
cd /opt/
git clone https://github.com/kbandla/pydeep.git pydeep
cd /opt/pydeep/
apt-get install python-dev
#!/usr/bin/python
import os
“””MASTIFF Autorun # @TekDefense # www.TekDefense.com Quick script to autorun samples from
maltrieve to MASTIFF
“””
malwarePath = '/tmp/malware/'
for r, d, f in os.walk(malwarePath):
for files in f:
malware = malwarePath + files
print malware
os.system ('mas.py' + ' ' + malware)
Licenciado bajo GPLv3 Página 43
python setup.py build
python setup.py install
Una vez todo en orden volvemos a lanzarlo y revisamos los resultados que se encuentran el
directorio /opt/Mastiff/work/log
Todo lo analizado se almacena en una base de datos llamada Mastiff.db para posteriormente
facilitar en análisis (figura 10), también es importante comentar que Mastiff permite la
integración con las apis de virus total entro otras, esto puede ser configurado en el fichero de
configuración de Mastiff.
3.4.2 Configuración de Dionaea
Características y detalles:
Dionaea Honeypot es el sucesor del conocido Nepenthes. El objetivo de dionaea es recolectar
piezas de malware. Ofrece servicios vulnerables a la red con el objetivo de conseguir una copia
del malware que explota las vulnerabilidades expuestas.
Los gusanos, por ejemplo, suelen usar APIs para acceder a los servicios antes de enviar su
payload, estos payloads pueden contener una url desde donde descargar una copia del
gusano. Esta interacción se da a través de protocolos implementados en python simulando
servicios reales.
Dionaea ofrece servicios como: smb, http, ftp, tftp, mssql, mysql, sip, … Utiliza python3 y
herramientas como scapy, libemu, libcurl, libpcap, libssl entre otras. Permite la subida de
ficheros vía web y ftp, y el acceso a las bases de datos señuelo a los atacantes como si de un
entorno real se tratara.
Toda la actividad se registra en ficheros de logs. Es posible limitar la información por niveles de
detalle (info, warn, crit, etc). Además, Dionaea usa un sistema de comunicación interna que se
registra en una base de datos sqlite.
El ejecutable dionaea estará por defecto en la ruta /opt/dionaea/bin/dionaea y cuenta con las
siguientes opciones en la ejecución:
# ./dionaea -h
Dionaea Version 0.1.0
-c, --config=FILE use FILE as configuration file
-D, --daemonize run as daemon
-g, --group=GROUP switch to GROUP after startup (use with -u)
-h, --help display help
Licenciado bajo GPLv3 Página 44
-H, --large-help display help with default values
-l, --log-levels=WHAT which levels to log, valid values all, debug, info, message, warning,
critical, error, combine using ',', exclude with - prefix
-L, --log-domains=WHAT which domains use * and ? wildcards, combine using ',', exclude
using -
-u, --user=USER switch to USER after startup
-p, --pid-file=FILE write pid to file
-r, --chroot=DIR chroot to DIR after startup, warning: chrooting causes problems with
logsql/sqlite
-V, --version show version
-w, --workingdir=DIR set the process' working dir to DIR
examples:
# dionaea -l all,-debug -L '*'
# dionaea -l all,-debug -L 'con*,py*'
# dionaea -u nobody -g nogroup -w /opt/dionaea -p /opt/dionaea/var/run/dionaea.pid
Podremos arrancarla con las siguientes opciones:
/opt/dionaea/bin/dionaea -D -u dionaea -g dionaea -w /opt/dionaea/ -p
/opt/dionaea/var/run/dionaea.pid
/opt/dionaea/bin/dionaea –D #Esta será la instrucción que utilicemos
La opción “-u usuario” crea un proceso hijo para el usuario indicado después del arranque
como medida de seguridad pero ha de existir previamente el usuario de dionaea. Si todo ha
ido bien veremos dos procesos dionaea al hacer un ps aux, el padre para el usuario root y otro
hijo para el usuario dionaea.
Se pueden consultar los logs para comprobar posibles errores en el arranque en
/opt/dionaea/var/log/, en los ficheros dionaea.log y dionaea-errors.log.
La actividad, muestras del malware, capturas de conexión y demás información se guarda en
/opt/dionaea/var/dionaea/:
binaries: en esta carpeta se alojarán las muestras de malware que recoja dionaea.
bistreams: información de cadenas de conexión.
wwwroot: ficheros subidos por los servicios http y ftp.
rtp: capturas de tráfico en formato pcap.
Licenciado bajo GPLv3 Página 45
logsql.sqlite: registro de actividad en base de datos sqlite.
sipaccounts: actividad con protocolo sip.
Configuración:
El fichero de configuración se encuentra en /opt/dionaea/etc/dionaea.conf. La configuración
es algo extensa aunque se entiende bastante bien ya que cuenta con muchos comentarios. Se
comentan las opciones más importantes:
Dentro de la categoría logging, al principio, podremos indicar el fichero de log (campo file) y el
nivel de detalle de los logs (en el campo levels), por ejemplo de la siguiente manera:
file = "log/dionaea.log"
levels = "warning,critical,error"
Indicar en qué interfaz trabajará dionaea en la categoría “listen”, en el campo “addrs”.
mode = "manual"
addrs = { eth0 = ["XX.XX.XX.XX"] }
Esto es importante ya que dionaea registrará toda la actividad en la interfaz indicada. Lo ideal
es contar con dos interfaces, una de gestión para acceder a la máquina para administrarla y
otra para que dionaea registre la actividad. Por seguridad, la de gestión debería de estar
accesible sólo a través de una red interna.
Si queremos conectar dionaea con virustotal tendremos que indicar la key de la api en la
configuración:
virustotal = {
apikey =
"7536e4c034490b91d3d2f07a6fa7d68c8b323c5881afa496e26de6887766553902" // grab it
from your virustotal account at My account > Inbox > Public API
file = "var/dionaea/vtcache.sqlite"
}
Como se ha comentado, es posible permitir a un atacante acceder a una base de datos a través
del servicio mySQL en nuestro caso la base de datos ficticia ya viene instalada con honeydrive.
Ahora vamos a preparar una interfaz gráfica que nos facilite la visualización de los datos que se
almacenan en la base de datos de una forma más amigable. Para ello tenemos el proyecto
DionaeaFR, un frontal web hecho en django bastante interesante.
Licenciado bajo GPLv3 Página 46
Y se ejecuta el servidor web:
python manage.py collectstatic
python manage.py runserver 0.0.0.0:8000
Se puede acceder a dionaeafr accediendo a http://YOUR_IP:8000 en el navegador.
Lanzamos el servicio y lo dejamos corriendo, en la figura 11 se muestra la interfaz gráfica de
dionea ya en funcionamiento.
3.4.4 Configuración de Amun
El archivo de configuración es /opt/amun/conf/amun.conf. El primer parámetro de
configuración, es la ip donde Amun estará escuchando por conexiones entrantes. En vez de
una ip, podemos darle una interface de red: ip: eth0
Otra parte importante de la configuración son los módulos de envió. Una vez que Amun se ha
descargado el malware, puede, al igual que Dionaea, guardarlo en el disco local para lo cual
usa el md5 del archivo como nombre, o enviarlo a los siguientes servicios de análisis externos:
anubis, cwsandbox o joebox. El resultado puede ser consultado bien vía web o vía mail,
también podremos analizarlo con Mastiff agregándolo a nuestra bd de malware.
La parte realmente interesante del archivo de configuración es donde declaramos los módulos
de vulnerabilidades que van a ser usador por Amun. Los podemos encontrar en
/opt/amun/vuln_modules/ y son modulos de python emulando vulnerabilidades conocidas.
vuln_modules:
vuln-mydoom,
vuln-axigen,
vuln-symantec,
vuln-veritas
A parte de definir que vulnerabilidades queremos exponer, Amun nos permite poder definir
en que puerto las queremos poner:
# CVE-2005-0582 - Axigen Mail Server
# http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0582
vuln-axigen: 110
# CVE-2006-1630 - Symantec Remote Management Stack Overflow
# http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1630
Licenciado bajo GPLv3 Página 47
vuln-symantec: 2967,2968,38292
# CVE-2004-0567 - Veritas Backup Exec Agent Stack Overflow
# http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0567
vuln-veritas: 6101
Otros parámetros de la configuración son, el usuario y grupo con el que será iniciado (no
puede escuchar por encima del puerto 1024 sin ser superusuario).
Para iniciar Amun procedemos de la siguiente forma:
$ sudo /opt/amun/amun_server.py
E esta ocasión mostraremos aquí una figura interesante, de la parte derecha de la figura nmap
escaneado nuestra ip y de la parte izquierda el servidor Amunt iniciado capturando las
acciones de namp:
Amun tienen varios módulos para gestionar logs. Los distintos módulos pueden ser
activados o desactivados comentándose en el archivo de configuración de Amun mencionado
arriba:
log_modules:
# log-surfnet,
log-syslog,
# log-mysql
Licenciado bajo GPLv3 Página 48
log-mysql - para mandar los logs a mysql. La configuración de este modulo (base datos,
usuario y pass) se encuentra en /opt/amun/conf/log-mysql.conf
log-syslog - este modulo manda toda la información de ataques entrantes al demonio local
de syslog
log-surfnet - permite la integración de Amun con SURFids
Los logs generados por syslog los podemos encontrar en /opt/amun/logs/.
En este directorio se encuentran tanto los logs del propio servidor Amun, como de las
interacciones que generan las amenazas contra Amun. Amun maneja las conexiones
proporcionándoles un módulo que se encarga de gestionar la interacción, al que llaman
ihandler. Como consecuencia del registro de actividades relacionadas con este modulo, se
generan logs que son almacenados en el archivo
/etc/opt/amun/logs/amun_request_handler.log.
Una fragmento de lo que podría contener el este archivo se muestra en la figura 12
3.4.5 Configuración de Tiny Honeypot
Tiny Honeypot (thp en lo que sigue) es un honeypot que hace uso de iptables para tomar las
decisiones sobre como re direccionar el tráfico TCP/IP entrante.
El script iptables de que es provisto por thp, que se encuentra en /etc/iptables.rules, correrá
en la mayoría de los entornos con las mínimas modificaciones. Estas modificaciones crecerán si
el host en el que estamos ejecutando thp esta actuando como router.
Se puede ver en la siguiente captura:
Licenciado bajo GPLv3 Página 49
CAPTURA THPOT IPTABLES TABLES
Una de las cosas interesantes de thp es que permite a los servicios que tengamos en el
sistema, seguir ejecutándose sin que thp interfiera en su funcionamiento. Estos servicios
deben ser establecidos en el script Iptables, agregándolos a la variable GOOD_SVCS. Por
defecto, el script Iptables redirigirá los demás puertos no especificados en esta variable. Los
puertos que deseemos usar para thp serán declarados en la variable HPOT_TCP_SVCS
Los puertos declarados en HPOT_TCP_SVCS serán redirigidos a HPOT_TCP_SVCS+40,000 y las
sesiones serán manejadas por los archivos de xinetd tal como se muestra a continuación:
Licenciado bajo GPLv3 Página 50
CAPTURA THPOT XINETD DIR
Estos archivos (/etc/xinet.d/*) contienen información sobre el puerto, el servidor
(/usr/sbin/thpot) y los argumentos del servidor. Este argumento define que script de perl será
el que maneje las peticiones y respuestas a ese servicio.
Licenciado bajo GPLv3 Página 51
CAPTURA THPOT XINETD SERVICES
Cualquier puerto que no tenga un servicio personalizado será redirigido al puerto 6635 por
defecto, establece una conexión y devuelve una Shell a la maquina remota
En el archivo de configuración (/etc/thpot/thp.conf) se definen lo parámetros típicos como son
la interface de red ($intf = "eth0";) y la dirección ($thpaddr = "127.0.0.1";) así como el dominio
o los directorios de operación básicos de thp ($thpdir = "/usr/share/thpot";) ($logdir =
"/var/log/thpot";) ($logfile = "$logdir/captures";) ($errfile = "$logdir/errors";).
La parte interesante de la configuración es la definición de las versiones de los cuatro tipos de
servicios que podemos emular con thp, mostramos aquí la configuración:
# ftp server version choices (edit them if you like)
my @fver;
$fver[1] = "FTP server (Version wu-2.6.0(1))";
$fver[2] = "FTP server (Version wu-2.6.1(2))";
$fver[3] = "FTP server (Version wu-2.6.1-16)";
Licenciado bajo GPLv3 Página 52
$fver[4] = "FTP server (BSDI Version 7.00LS)";
$fver[5] = "FTP server (PFTP 0.13)";
$fver[6] = "NcFTPd Server";
$fver[7] = "Microsoft FTP Service (Version 5.0)";
$fver[8] = "Microsoft FTP Service (Version 4.0)";
# the http vendor is emulated via selecting the appropriate directory of responses
#$httpdvend = "Microsoft-IIS";
$httpdvend = "Apache";
# http version is reported in headers, responses, etc. and SHOULD be a sensible
# match with the $httpdvend. If your server reports itself as IIS/1.3.9, that
# might raise an eyebrow.
#$httpdver = "5.0";
#$httpdver = "6.0";
$httpdver = "1.3.9";
#$httpdver = "1.3.19";
# sshd version to emulate:
my @sver;
$sver[1] = "SSH-1.5-1.2.26";
$sver[2] = "SSH-1.5-1.2.27";
$sver[3] = "SSH-2.0-OpenSSH_3.4p1";
$sshver = $sver[int(rand(@sver-1))+1];
Licenciado bajo GPLv3 Página 53
#smtp version to emulate
my @smver;
$smver[1] ="ESMTP Sendmail 8.12.2/8.12.2/SuSE Linux 0.6;";
$smver[2] ="ESMTP Exim 3.12 #1";
$smver[3] ="ESMTP Sendmail 8.9.3/8.9.3/Debian 8.9.3-21;";
$smver[4] ="ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2653.13)";
$smver[5] ="ESMTP Sendmail 8.11.6/8.11.6;";
$smtpver = $smver[int(rand(@smver-1)) + 1];
El resultado en cuanto a servicios accesibles desde el exterior quedaría de la siguiente forma,
según nmap:
CAPTURA NMAP THPOT
Licenciado bajo GPLv3 Página 54
3.4.6 Configuración de Wordpot
La configuración la podemos encontrar en el archivo /opt/wordpot/wordpot.conf. Los valores
más relevantes son la dirección y el puerto donde permanecerá a la escucha así como la lista
de plugins y temas, el título y poco más
# -----------------------
# Honeypot configuration
# -----------------------
HOST = '127.0.0.1' # Hostname
PORT = '80' # Port
THEME = 'twentyeleven' # Theme name in use
# -----------------------
# Wordpress configuration
# -----------------------
BLOGTITLE = 'Random Ramblings' # Title of the blog
VERSION = '2.8' # Version to mimick
AUTHORS = ['admin'] # Authors list
3.4.7 Configuración de Glastopf
El archivo de configuración puede ser encontrado en /opt/glastopf/glastopf.cfg. En nuestro
caso los campos que hemos modificado son la dirección del host donde estará escuchando y el
puerto para adaptarlo a nuestras necesidades particulares.
[webserver]
host = 0.0.0.0
port = 80
uid = nobody
Licenciado bajo GPLv3 Página 55
gid = nogroup
proxy_enabled = False
En este archivo también podemos especificar a donde queramos que vayan los logs.
#Generic logging for general monitoring
[logging]
consolelog_enabled = True
filelog_enabled = True
logfile = log/glastopf.log
Para ver los servicios que el sistema esta ofreciendo al exterior con esta configuración,
lanzamos nmap contra la IP de este, desde otra maquina:
CAPTURA NMAP TODO
Licenciado bajo GPLv3 Página 56
3.5 Instalación y Configuración WinhoneyD
3.5.1 Instalación
Una vez instalada nuestra máquina virtual de Windows server dentro de Honeymatrioska,
necesitamos instalar algunos paquetes para que todo valla bien con winHoneyD.
La password de administrator de Windows es 20adminroot14!
Volvemos a crear una carpeta compartida temporal, podríamos pasarle los archivos por la red
pero ya que virtualbox nos da esta facilidad la usaremos, siempre recordando desmontar
posteriormente estas unidades.
Buscamos las fuentes oficiales e instalamos:
- Nmap
- Cywin
- Chrome
- Winzip
- P7zip
- Wireshark
- Y las contribuciones de honeyd
Mantenemos todas las descargas en la carpeta de descargas que será donde guardaremos
todas nuestras cosas exceptuando honeyd que lo movemos a la carpeta raíz.
3.5.2 Configuración:
Para configurar winhoneyd es tan fácil o tan complicado como crear un template o plantilla
indicándole el sistema a emular, en que ip debe ser emulado y sus características pero antes
de entrar con la configuración de los templates debemos descomprimir dentro de la carpeta
scripts los scripts que nos hemos descargado de las contribuciones y los extraemos para que
queden disponibles.
Ahora crearemos nuestros templates para ello lo primero de todo es definir cómo va a ser la
red que simulará honeyd, cuantas y qué máquinas tendrá y que servicios ofrecerán estas
maquinas.
En nuestro caso vamos a crear un template sencillito que emula un Servidor Exchange 2003, la
plantilla de configuración será la siguiente:
Licenciado bajo GPLv3 Página 57
#Fichero C:\\WinHoney\honeyd.config
CREATE Exchange Server 2003
ANNOTATE "Microsoft Windows.NET Enterprise Server (build 3615 beta)"
SET Exchange Server 2003 PERSONALITY "Microsoft Windows.NET
Enterprise Server (build 3615 beta)"
BIND 10.0.0.1 Exchange Server 2003
#Set port behavior
SET DEFAULT Exchange Server 2003 TCP ACTION RESET
SET DEFAULT Exchange Server 2003 UDP ACTION RESET
ADD Exchange Server 2003 UDP PORT 135 BLOCK
ADD Exchange Server 2003 UDP PORT 137 BLOCK
ADD Exchange Server 2003 UDP PORT 138 BLOCK
ADD Exchange Server 2003 UDP PORT 389 BLOCK
ADD Exchange Server 2003 UDP PORT 445 BLOCK
ADD Exchange Server 2003 UDP PORT 500 OPEN
ADD Exchange Server 2003 UDP PORT 4500 OPEN
ADD Exchange Server 2003 TCP PORT 25 "sh C:\WinHoneyd\scripts\contrib\smtp.sh"
ADD Exchange Server 2003 TCP PORT 80 "perl.exe
C:\WinHoneyd\scripts\contrib\honeyd\scripts\win2k\iisemulator-0.95\iisemul8.pl"
ADD Exchange Server 2003 TCP PORT 88 OPEN
ADD Exchange Server 2003 TCP PORT 110 "sh
C:\WinHoneyd\scripts\contrib\honeyd\scripts\contrib\smtp.sh"
ADD Exchange Server 2003 TCP PORT 135 BLOCK
ADD Exchange Server 2003 TCP PORT 137 BLOCK
ADD Exchange Server 2003 TCP PORT 139 BLOCK
ADD Exchange Server 2003 TCP PORT 445 BLOCK
ADD Exchange Server 2003 TCP PORT 593 OPEN
ADD Exchange Server 2003 TCP PORT 1063 OPEN
Licenciado bajo GPLv3 Página 58
ADD Exchange Server 2003 TCP PORT 1071 OPEN
ADD Exchange Server 2003 TCP PORT 1073 OPEN
ADD Exchange Server 2003 TCP PORT 3389 OPEN
#Set template system variables
SET Exchange Server 2003 UPTIME 2248020
SET Exchange Server 2003 DROPRATE IN 0.005
SET Exchange Server 2003 UID 20208 GID 13876
Una vez creada nos iniciamos honeyd desde powershell con honeyd –f honeyd.config,
obviamente tenemos que encontrarnos en el directorio de honeyd.
A continuación una captura de pantalla con honeyd funcionado:
4. Capitulo 4. Exposición de los sistemas
Exposición pasiva:
Desde el momento de configuración de cada uno de los honeypots se han dejado expuestos de
forma alterna utilizando la interfaz de red que proveía nuestra dmz , viendo que los logs
recogidos de este modo eran lentos pasamos a otro tipo de exposición más activa y atractiva.
Licenciado bajo GPLv3 Página 59
Exposición activa:
En este punto facilitamos la ip pública de la wan a distintas listas de correo enfocadas a la
seguridad informática, indicando que era un honeypot y pidiendo que por favor lo atacasen
para este trabajo, la acogida fue tan alta que al segundo día tuvimos que enviar nuevos
correos diciendo que la prueba había finalizado.
5. Análisis de datos
Tras el periodo de exposición se recibieron más de 200 ataques en dos días, sin contar los
ataques de la exposición activa, pudimos observar que Windows recibe más ataques que linux
con diferencia una vez implementados los servicios de iis.
La calidad de los ataques ha sido muy variada, uno de los servicios más relevantes para ello fue
ftp por la simplicidad del usuario anonymous.
Durante la semana que el honeypot ha estado expuesto a la red se han recogido una serie de
datos en forma de logs (registros) cuyo análisis es el siguiente:
De los servicios o protocolos expuestos, los que han recibido más conexiones son
Microsoft SQL con 287 conexiones y Samba con 205 conexiones de donde se deduce
que son servicios a tener en cuenta a la hora de plantearse políticas de seguridad o
hardening de maquinas en producción.
Los países de origen de los ataques han sido:
1. China con 22 conexiones
2. Estados Unidos con 8 conexiones
3. Francia con 7 conexiones
4. Brasil con 3 conexiones
5. Colombia con 2 conexiones
6. Islandia con 2 conexiones
La dirección ip que más ataques ha generado a sido 234.27.79.32 y su procedencia es
Dallas (Estados Unidos).
La mayoría de los atacantes según muestran los logs registrados, se limitaron a hacer
scaneo de los servicios del honeypot sin intentar ningún tipo de intrusión posterior, o
en el caso de intentarla, resultó sin éxito, lo cual demuestra un perfil bajo o inexperto
en los mismos.
Licenciado bajo GPLv3 Página 60
A pesar de este perfil, ya que tenemos constancia de quela mayoría de los ataques provenían
de España, aunque los datos no lo reflejen, deducimos que en un 70% de las ocasiones según
los datos estaba siendo utilizado algún tipo de proxie o estaban conectados a través de la red
tor.
A parte de los ataques activos anteriormente reflejados no se ha recogido ninguna muestra de
malware proveniente de fuentes pasivas.
Para que esto sucediese habría sido necesario una exposición mas prolongada de las maquinas
que por motivos logísticos no ha resultado posible.
6. Conclusiones Después de todo lo expuesto y vivido durante la realización de este TFM si alguna conclusión
se ha llegado es que el mundo de los honeypots es apasionante desde cualquier prisma, poco
explorado y merecedor de toda atención.
No sólo nos permite defender nuestros sistemas y conocer a los atacantes si no que nos
provee de un conocimiento difícilmente alcanzable de otro modo.
Licenciado bajo GPLv3 Página 61
X. BIBLIOGRAFÍA
http://bruteforce.gr/honeydrive
http://www.alegsa.com.ar/Dic/honeypot.php
Honeynets como herramienta de prevención e investigación de ciberataques
http://www.somoslibres.org/modules.php?name=News&file=article&sid=307
http://www.tekdefense.com/news/tag/malware-analysis?currentPage=2
http://www.repson.org/
http://kinomakino.blogspot.com.es/
Licenciado bajo GPLv3 Página 62
ANEXO
Figura 1 Configuración de interfaces vboxnet en virtualbox:
Figura 2 Configuración vboxnet0
Licenciado bajo GPLv3 Página 63
Figura 3 Configuración vboxnet1
Volver al punto 3.1
Licenciado bajo GPLv3 Página 64
Figura 4 Características de la maquina virtual Debian
Figura 4 Características de la Maquina virtual Debian.
Volver al punto 3.1
Licenciado bajo GPLv3 Página 65
Figura 5 Instalación de Snort
Volver al punto 3.2
Figura 6 Configuración del Snort 1
Licenciado bajo GPLv3 Página 66
Figura 7 Configuración de Snort 2
Figura 8 Configuración de Snort 3
Volver al Punto 3.2
Licenciado bajo GPLv3 Página 67
Figura 9 Maltrive
Volver al punto 3.4.2
Figura 10 Mastiff.db
Volver al punto 3.4.1.2
Licenciado bajo GPLv3 Página 68
Figura 11 Interfaz gráfica de dionaea
Ir al punto 3.4.4
Licenciado bajo GPLv3 Página 69
Figura 12 Amun
![Peter Voigt: GPLv3 [24c3]](https://img.pdfslide.tips/doc/110x75/549ea532ac79592e768b4797/peter-voigt-gplv3-24c3.jpg)
