UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO

FACULTAD DE INGENIERÍA

Análisis de Malware con

Cuckoo SandBox

TESIS
Que para obtener el título de
Ingeniero en Computación

PRESENTA
Alejandro Bárcenas Godínez

DIRECTOR DE TESIS
Ing. Aldo Jiménez Arteaga

Ciudad Universitaria, Cd. Mx., Octubre 2016

Dedicado a la memoria de mi padre, quién me
proporcionó su apoyo y amor de manera
incondicional y me impulsó a seguir adelante
y a nunca rendirme.
 Reconocimientos

Agradezco a Dios por haberme dado la sabidurı́a, fuerza y paciencia para poder
concluir mis estudios de ingenierı́a en computación.

Agradezco a mis padres, quiénes han forjado lo mejor de ellos en mı́, a través de su
incondicional amor y apoyo en todo momento y me han impulsado a seguir adelante
para nunca desistir a pesar de lo difı́cil de las adversidades. Los AMO.

A mi cousin Julio, quién me apoyó a lo largo de mi trayectoria universitaria y ha

compartido conmigo sus conocimientos para poder ser mejor persona, estudiante y pro-
fesionista.

A mi amigo Humberto, por sus valiosos consejos de vida y su apoyo en los primeros
semestres de la licenciatura.

A mi amigo José Alberto, por aportar ideas durante la realización de esta tesis,
compartir conmigo un poco de su conocimiento, ser mi sensei, y por brindarme su apo-
yo para poder seguir desarrollándome como un profesionista altamente competitivo.

Agradezco a Vane, por haberme permitido ser parte de tu vida y ser una excelente
compañera y amiga durante la carrera.

A mi director de tesis Ing. Aldo Jiménez Arteaga, por haber dedicado su tiempo
para la realización y culminación de esta tesis.

A la honorable Facultad de Ingenierı́a de la Universidad Nacional Autónoma de

México, por la excelente formación académica que se imparte en sus aulas.

A la Escuela Nacional Preparatoria 5, por la educación de calidad recibida y las

gratas experiencias que vivı́ durante mı́ estancia en ella.

México, Pumas, Universidad!

iii
 Resumen

El malware es definido como un software malicioso que tiene como propósito in-
filtrarse en las computadoras y servidores de diferentes organizaciones alrededor del
mundo. Este tipo de software altera y modifica programas y/o archivos, y en algunos
casos puede permitir que los equipos infectados sean controlados remotamente por pi-
ratas informáticos para obtener ventajas y beneficios de esta situación.

Hoy en dı́a, el software malicioso, tiene su mayor auge desde su creación. Este puede
llegar a ser tan sofisticado, que puede ocasionar daño en el mundo fı́sico; tal y como es
el caso de Stuxnet, un malware espı́a que reprograma sistemas industriales, afectando
a instalaciones crı́ticas como centrales nucleares.

Actualmente, en la Secretarı́a de Salud de la Ciudad de México (SEDESA) se de-

tectó que algunos equipos de cómputo que componen su infraestructura informática, se
encuentran infectados con software malicioso, poniendo en peligro la información que
reside en ellos, atentando contra su confidencialidad, integridad y disponibilidad.

Por la situación descrita anteriormente, se propuso el desarrollo de este proyecto,

el cual tiene como objetivo identificar, desde un sistema centralizado, los equipos que
potencialmente pudieran estar infectados, alertando al administrador de red para que
tome las medidas necesarias con el fin de contener y evitar la propagación hacia otros
activos de información de dicha Secretarı́a.

Se decidió implementar una SandBox para el análisis automatizado de malware;

debido a que estos entornos son seguros para la realización de pruebas en ambientes
aislados, evitando la propagación de los archivos maliciosos ejecutados en ésta. Se optó
por implementar especı́ficamente Cuckoo SandBox, ya que de manera automática, rea-
liza un análisis sobre una muestra, ya sea un archivo o una URL, arrojando información
relevante acerca del comportamiento durante el análisis. Los resultados del análisis de
la muestra son consultados a través de cualquier navegador web moderno.

Por otra parte, se empleó Ubuntu 12.04 Precise Pangolin como Sistema Operativo
de la SandBox y del sistema centralizado encargado de detectar, a través de la red de

v
datos interna de la Secretarı́a de Salud, los equipos con comportamientos anómalos.
Además de tener la ventaja de ser open source, Ubuntu se caracteriza por su robustez,
estabilidad y rapidez para realizar las tareas que son ejecutadas en él. Este Sistema
Operativo al ser un Linux, cuenta con el apoyo y soporte de miles de programadores a
nivel mundial.
 Índice general

Índice de figuras XI

Índice de tablas XV

1. Conceptos Generales 1
1.1. Redes de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2. Importancia de las redes de datos en la actualidad . . . . . . . . 1
1.1.3. Dispositivos de red . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4. Topologı́as de red . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.4.1. Topologı́as fı́sicas . . . . . . . . . . . . . . . . . . . . . 5
1.1.4.2. Topologı́as lógicas . . . . . . . . . . . . . . . . . . . . . 10
1.1.5. Tipos de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.5.1. MAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.5.2. WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.5.3. Redes inalámbricas . . . . . . . . . . . . . . . . . . . . 12
1.1.6. Protocolos de red . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.6.1. Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.6.2. Protocolo TCP/IP . . . . . . . . . . . . . . . . . . . . . 18
1.2. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.1. Tipos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.2. Servicios de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.3. Amenaza y vulnerabilidad . . . . . . . . . . . . . . . . . . . . . . 28
1.2.4. Análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.2.5. Trazabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.2.6. Sistemas de Detección de Intrusos . . . . . . . . . . . . . . . . . 31
1.2.7. SandBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2. Implementación del Sistema de Detección de Intrusos y Cuckoo Sand-

Box 39
2.1. Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox 39
2.1.1. Instalación del Sistema de Detección de Intrusos (IDS) . . . . . . 41
2.1.2. Instalación de Snort . . . . . . . . . . . . . . . . . . . . . . . . . 45

vii
ÍNDICE GENERAL

2.1.3. Configuración de Snort . . . . . . . . . . . . . . . . . . . . . . . 47

2.1.4. Instalación de Barnyard . . . . . . . . . . . . . . . . . . . . . . . 50
2.1.5. Configuración de MySQL . . . . . . . . . . . . . . . . . . . . . . 51
2.1.6. Configuración del servidor apache . . . . . . . . . . . . . . . . . 52
2.1.7. Instalación de B.A.S.E. . . . . . . . . . . . . . . . . . . . . . . . 53
2.1.8. Configuración de B.A.S.E. . . . . . . . . . . . . . . . . . . . . . . 54
2.1.9. Instalación y actualización de reglas en Snort . . . . . . . . . . . 57
2.2. Instalación de Cuckoo SandBox . . . . . . . . . . . . . . . . . . . . . . . 62
2.2.1. Instalación de paquetes . . . . . . . . . . . . . . . . . . . . . . . 62
2.2.2. Configuración de la Base de Datos . . . . . . . . . . . . . . . . . 66
2.2.3. Instalación de VirtualBox . . . . . . . . . . . . . . . . . . . . . . 66
2.2.4. Instalación y preparación de la máquina huésped . . . . . . . . . 67
2.2.5. Instalación de la SandBox Cuckoo . . . . . . . . . . . . . . . . . 73
2.2.6. Archivos de configuración . . . . . . . . . . . . . . . . . . . . . . 74
2.3. Puesta en producción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.3.1. Requerimientos de hardware y software . . . . . . . . . . . . . . 75
2.3.2. Configuración de port mirroring . . . . . . . . . . . . . . . . . . 76
2.3.3. Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.3.4. Topologı́a de red . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.3.5. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3. Recolección de Evidencia 81
3.1. Funcionamiento de un IDS . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.1.1. Métodos para la recolección de datos . . . . . . . . . . . . . . . . 81
3.1.2. Recolección de información e intentos de intrusión . . . . . . . . 82
3.1.3. Respuesta de un IDS ante un intento de ataque . . . . . . . . . . 83
3.1.4. Motor de detección . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.1.5. Módulos de salida . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.2. Estructura de las reglas de Snort . . . . . . . . . . . . . . . . . . . . . . 86
3.2.1. Encabezado de la regla . . . . . . . . . . . . . . . . . . . . . . . . 86
3.2.2. Opciones de la regla . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.3. Eventos generados (Alertas) . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.3.1. Contenido de las reglas disparadas . . . . . . . . . . . . . . . . . 98
3.3.2. Contenido y análisis del payload de los paquetes capturados . . . 113
3.3.3. Análisis en Cuckoo SandBox . . . . . . . . . . . . . . . . . . . . 128

4. Automatización del proceso de análisis de un evento 151

4.1. Estructura y módulos del programa de automatización . . . . . . . . . . 152
4.1.1. Módulo de análisis de archivos descargados del IDS Snort . . . . 153
4.1.2. Módulo para eliminar los incidentes de la Base de Datos del IDS
Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
4.1.3. Módulo para comprobar que Cuckoo SandBox está en ejecución . 156
4.1.4. Módulo para enviar una muestra para su análisis con Cuckoo
SandBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

viii
 ÍNDICE GENERAL

4.1.5. Módulo para analizar el repositorio de reportes de malware gene-

rados por Cuckoo SandBox . . . . . . . . . . . . . . . . . . . . . 160
4.1.6. Módulo para habilitar el servicio web de Cuckoo SandBox . . . . 161
4.2. Sistema de Consulta de Malware . . . . . . . . . . . . . . . . . . . . . . 163

5. Conclusiones 173

Glosario 177

Bibliografı́a 183

A. Archivos de configuración de Cuckoo SandBox 185

B. Código fuente para la automatización del análisis de una muestra con

Cuckoo SandBox y Administración de eventos del IDS Snort. 201

C. Código fuente del Sistema de Consulta de Malware. 235

ix
 Índice de figuras

1.1. Las redes de datos minimizan las fronteras geográficas. Fuente: Netacad
CISCO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Switch Cisco Serie 2600X de 48 puertos (Administrable). Fuente: cisco.com. 3
1.3. Hub de cuatro puertos Netgear EN104TP. Fuente: netgear.com. . . . . . 4
1.4. Access Point Linksys WAP54G. Fuente: linksys.com. . . . . . . . . . . . 4
1.5. Router Cisco Serie 1900. Fuente: cisco.com. . . . . . . . . . . . . . . . . 5
1.6. Firewall Fortinet Fortigate – 100D. Fuente: fortinet.com. . . . . . . . . . 5
1.7. Topologı́a tipo Malla. Fuente: wikipedia.com. . . . . . . . . . . . . . . . 6
1.8. Topologı́a tipo Estrella. Fuente: wikipedia.com. . . . . . . . . . . . . . . 6
1.9. Topologı́a tipo Árbol. Fuente: wikipedia.com. . . . . . . . . . . . . . . . 7
1.10. Topologı́a tipo Bus. Fuente: wikipedia.com. . . . . . . . . . . . . . . . . 8
1.11. Topologı́a tipo Anillo. Fuente: wikipedia.com. . . . . . . . . . . . . . . . 9
1.12. Topologı́a tipo Hı́brida (Estrella-Bus-Estrella). Fuente: google.com. . . . 9
1.13. Red LAN. Fuente: Netacad CISCO. . . . . . . . . . . . . . . . . . . . . 11
1.14. Red MAN. Fuente: Netacad CISCO. . . . . . . . . . . . . . . . . . . . . 11
1.15. Red WAN. Fuente: Netacad CISCO. . . . . . . . . . . . . . . . . . . . . 12
1.16. Tecnologı́as de las redes inalámbricas. Fuente: ccm.net. . . . . . . . . . . 13
1.17. Modelo OSI. Fuente: Netacad CISCO. . . . . . . . . . . . . . . . . . . . 15
1.18. Modelo TCP/IP. Fuente: Netacad CISCO. . . . . . . . . . . . . . . . . . 18
1.19. Red usando 3 NIDS implementados en segmentos de red estratégicos.
Fuente: Snort IDS and IPS Toolkit, 2007. . . . . . . . . . . . . . . . . . 32
1.20. Red usando HIDS en servidores y computadoras especı́ficas. Fuente:
Snort IDS and IPS Toolkit, 2007. . . . . . . . . . . . . . . . . . . . . . . 33
1.21. Red monitoreada por 4 sensores y una estación de administración cen-
tralizada. Fuente: Snort IDS and IPS Toolkit, 2007. . . . . . . . . . . . 34
1.22. Imagotipo del IDS Snort. Fuente: snort.org. . . . . . . . . . . . . . . . . 35
1.23. Imagotipo de Cuckoo SandBox. Fuente: cuckoosandbox.org. . . . . . . . 38

2.1. Diagrama de bloques instalación y configuración IDS Snort. Fuente: Ela-

boración propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2. Diagrama de bloques instalación y configuración Cuckoo SandBox. Fuen-
te: Elaboración propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

xi
ÍNDICE DE FIGURAS

2.3. Configuración de contraseña para el usuario root de MySQL. Fuente:

Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4. Ejecución de Snort en modo consola. Fuente: Captura propia. . . . . . . 50
2.5. Tablas que contiene la base de datos snort. Fuente: Captura propia. . . 52
2.6. Pantalla de inicio de configuración de B.A.S.E. Fuente: Captura propia. 54
2.7. Selección del idioma del usuario y la ruta de adodb. Fuente: Captura
propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.8. Configuración de parámetros para realizar la conexión con la base de
datos snort. Fuente: Captura propia. . . . . . . . . . . . . . . . . . . . . 55
2.9. Definición de los parámetros de autenticación del sistema B.A.S.E. Fuen-
te: Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.10. Creación de las tablas de B.A.S.E. en la Base de Datos snort. Fuente:
Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.11. Acceso a B.A.S.E. Fuente: Captura propia. . . . . . . . . . . . . . . . . 57
2.12. Login en la página de Snort. Fuente: snort.org. . . . . . . . . . . . . . . 59
2.13. Oinkcode proporcionado en la página de Snort. Fuente: snort.org. . . . . 60
2.14. Actualización completa del kit de reglas de Snort con PulledPork. Fuente:
Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.15. Configuración de alertas en el sistema huésped. Fuente: Captura propia. 69
2.16. El agente Python escucha por el puerto 8000. Fuente: Captura propia. . 71
2.17. Creación de la interfaz virtual vboxnet0 en VirtualBox. Fuente: Captura
propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.18. Ejecución de Cuckoo SandBox. Fuente: Captura propia. . . . . . . . . . 73
2.19. Configuración del port mirroring. Fuente: Captura propia. . . . . . . . . 76
2.20. Arquitectura de red de la instalación del IDS Snort. Fuente: Elaboración
propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.21. Arquitectura de red de Cuckoo SandBox. Fuente: docs.cuckoosandbox.org/
elaboración propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.1. Matriz enlazada. Fuente: Optimización de Sistemas de Detección de In-

trusos en Red, 2009. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.2. Alertas emitidas por el IDS Snort. Fuente: Captura propia. . . . . . . . 95
3.3. Alerta de Snort 1:28806:2. Fuente: Captura propia. . . . . . . . . . . . . 95
3.4. Alerta de Snort 1:30211:1. Fuente: Captura propia. . . . . . . . . . . . . 96
3.5. Alerta de Snort 1:28039:4. Fuente: Captura propia. . . . . . . . . . . . . 96
3.6. Alerta de Snort 1:31683:1. Fuente: Captura propia. . . . . . . . . . . . . 96
3.7. Alerta de Snort 1:28801:2. Fuente: Captura propia. . . . . . . . . . . . . 96
3.8. Alerta de Snort 1:28423:1. Fuente: Captura propia. . . . . . . . . . . . . 96
3.9. Alerta de Snort 1:27919:3. Fuente: Captura propia. . . . . . . . . . . . . 97
3.10. Alerta de Snort 1:32125:1. Fuente: Captura propia. . . . . . . . . . . . . 97
3.11. Alerta de Snort 1:31527:1. Fuente: Captura propia. . . . . . . . . . . . . 97
3.12. Paquete de la firma 28806. Fuente: Captura propia. . . . . . . . . . . . . 113
3.13. Paquete de la firma 30211. Fuente: Captura propia. . . . . . . . . . . . . 116
3.14. Paquete de la firma 28039. Fuente: Captura propia. . . . . . . . . . . . . 117

xii
 ÍNDICE DE FIGURAS

3.15. Paquete de la firma 31683. Fuente: Captura propia. . . . . . . . . . . . . 119

3.16. Figura 3.16: Paquete de la firma 28801. Fuente: Captura propia. . . . . 120
3.17. Paquete de la firma 28423. Fuente: Captura propia. . . . . . . . . . . . . 123
3.18. Paquete de la firma 27919. Fuente: Captura propia. . . . . . . . . . . . . 124
3.19. Paquete de la firma 32125. Fuente: Captura propia. . . . . . . . . . . . . 125
3.20. Paquete de la firma 31527. Fuente: Captura propia. . . . . . . . . . . . . 126
3.21. Análisis con Cuckoo SandBox del evento 28806. Fuente: Captura propia. 130
3.22. Análisis con Cuckoo SandBox del evento 28039. Fuente: Captura propia. 134
3.23. Análisis con Cuckoo SandBox del evento 31683. Fuente: Captura propia. 139
3.24. Análisis con Cuckoo SandBox del evento 28801. Fuente: Captura propia. 143
3.25. Análisis con Cuckoo SandBox del evento 27919. Fuente: Captura propia. 146
3.26. Análisis con Cuckoo SandBox del evento 32125. Fuente: Captura propia. 150

4.1. Módulos principales. Fuente: Captura propia. . . . . . . . . . . . . . . . 153

4.2. Análisis de archivo con extensión .bin o .pcap. Fuente: Captura propia. . 153
4.3. Descarga de archivo desde un archivo .bin y .pcap. Fuente: Captura propia.154
4.4. Mensaje para la eliminación de eventos de las tablas de la Base de Datos
de Snort. Fuente: Captura propia. . . . . . . . . . . . . . . . . . . . . . 155
4.5. Borrado de información de las tablas de la Base de Datos Snort. Fuente:
Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
4.6. Cuckoo SandBox ejecutándose correctamente. Fuente: Captura propia. . 157
4.7. Notificación de que Cuckoo SandBox no está actualmente en ejecución.
Fuente: Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.8. Activación de Cuckoo SandBox. Fuente: Captura propia. . . . . . . . . . 158
4.9. Nombre de la muestra a analizar. Fuente: Captura propia. . . . . . . . . 159
4.10. Análisis de un archivo ejecutable. Fuente: Captura propia. . . . . . . . . 159
4.11. Proceso de análisis del repositorio de reportes de Cuckoo SandBox. Fuen-
te: Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4.12. Servicio web de Cuckoo SandBox en ejecución. Fuente: Captura propia. 162
4.13. Notificación de que el servicio web de Cuckoo SandBox no está actual-
mente en ejecución. Fuente: Captura propia. . . . . . . . . . . . . . . . . 162
4.14. Servicio web de Cuckoo ejecutándose. Fuente: Captura propia. . . . . . 163
4.15. Contenido de la tabla usuario. Fuente: Captura propia. . . . . . . . . . . 164
4.16. Página de autenticación del sistema de consulta de malware. Fuente:
Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.17. Mensaje de fallo de autenticación. Fuente: Captura propia. . . . . . . . 166
4.18. Mensaje de error de lectura del archivo Información Muestras.txt. Fuen-
te: Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
4.19. Despliegue de información en el sistema de consulta de malware. Fuente:
Captura propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.20. Menú de la página web. Fuente: Captura propia. . . . . . . . . . . . . . 169
4.21. Envı́o de correo con el reporte de la muestra analizada. Fuente: Captura
propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.22. Dirección de e-mail no válida. Fuente: Captura propia. . . . . . . . . . . 170

xiii
ÍNDICE DE FIGURAS

4.23. Envı́o exitoso de correo electrónico. Fuente: Captura propia. . . . . . . . 170

4.24. Correo electrónico con el reporte de la muestra recibido. Fuente: Captura
propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

xiv
 Índice de tablas

3.1. Opciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.2. Opciones payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.3. Opciones non-payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.4. Opciones post-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

xv
 Capı́tulo 1

Conceptos Generales

1.1. Redes de Datos

1.1.1. Definición
Una red de datos se define como un grupo de dispositivos, medios y servicios que
trabajan en forma conjunta mediante reglas establecidas, para que exista un proceso de
comunicación entre los diferentes dispositivos, con la finalidad de compartir información
y recursos.

1.1.2. Importancia de las redes de datos en la actualidad

Uno de los elementos esenciales en la existencia del ser humano y que es tan impor-
tante como el respirar o comer, es la necesidad de poder interactuar y comunicarnos
con los nuestros.

La forma en que nos comunicamos ha seguido un proceso evolutivo, el cual pasó

de una comunicación individual y presencial, a una forma de comunicación de mane-
ra remota; en la que básicamente podemos comunicarnos sin importar la ubicación
geográfica en la que nos encontremos.

Al igual que ha pasado con otros avances tecnológicos, la evolución de las tecnologı́as
de la comunicación permitió que la naturaleza con la que interactuábamos socialmente
cambiara y se adoptara a una escala global. Como ejemplo de esta evolución tecnológi-
ca, fue la creación e interconexión de redes de datos sólidas.

Las redes de datos en la actualidad son un elemento importante para poder lle-
var a cabo esta comunicación distante, ya que además de poder interactuar con otras
personas, podemos compartir contenido multimedia, lo que implica flujos de video, tex-
to y gráficos. Algunos ejemplos de las herramientas de comunicación más populares

1
1. CONCEPTOS GENERALES

comprenden la mensajerı́a instantánea, los blogs, las wikis, los podcasts, radio online,
herramientas de colaboración, video en demanda, entre otros.

Además de poder establecer una comunicación remota entre uno o varios individuos,
otro uso tradicional de las redes de datos es la compartición de recursos, lo cual significa
que la información, servidores, programas y medios de almacenamiento se encuentren
disponibles para todos aquellos equipos de cómputo que estén conectados a una red de
datos, sin importar la ubicación fı́sica del recurso y el usuario.

Las redes de datos también facilitan la manera en que aprendemos hoy en dı́a. Los
recursos multimedia de e-learning, a diferencia del método tradicional, no se limita a
dos fuentes de conocimiento: el libro de texto y el instructor. Estos recursos pueden
contener videos, voz y datos interactivos; que pueden ser consultados en cualquier mo-
mento sin importar la localización del educando. Es por ello que actualmente el acceso
a una educación de calidad, ya no se limita a vivir cerca del lugar en donde se imparte
la instrucción.

Las redes de datos han tenido un impacto positivo en nuestra sociedad. En el mun-
do actual, estamos conectados como nunca antes y sı́ alguien tiene una idea, puede
compartirla con otras personas para materializarla y hacerla realidad. Las noticias y
nuevos descubrimientos fluyen como nunca antes y en cuestión de segundos se dan a
conocer por todo el mundo. La figura 1.1 ilustra este concepto.

Figura 1.1: Las redes de datos minimizan las fronteras geográficas. Fuente: Netacad
CISCO.

2
 1.1 Redes de Datos

1.1.3. Dispositivos de red

Los dispositivos de red se definen como un conjunto de hardware que proporciona
conectividad, para garantizar que los datos fluyan a través de la red. Estos dispositivos
pueden interconectar varias redes para formar una internetwork. Según su función se
clasifican como acceso a la red (switches, hubs y puntos de acceso inalámbrico), inter-
networking (routers) y seguridad (firewalls).

Switch
El switch es utilizado para conectar varios dispositivos a través de la misma red de
un edificio u oficina. Éste actúa como controlador y permite a los diferentes equipos
comunicarse entre sı́ y compartir información.

Existen dos tipos de switches: los no administrables y los administrables. Los pri-
meros no necesitan una configuración adicional y funcionan inmediatamente una vez
se les instale dentro de la red, mientras que los switches administrables, pueden ser
supervisados de manera local o remota para establecer una configuración, para poderlo
adaptar a las necesidades de la organización. En la figura 1.2 se muestra un switch
administrable.

Figura 1.2: Switch Cisco Serie 2600X de 48 puertos (Administrable). Fuente: cisco.com.

Hub
Los hubs son dispositivos que trabajan en la capa 1 (capa fı́sica) del modelo OSI y
en la capa de acceso al medio en el modelo TCP/IP. Estos dispositivos concentran las
conexiones, es decir que el grupo de nodos que se encuentren conectados a éste, la red
los tratará como una sola unidad.

Estos dispositivos no pueden dirigir los datos para quién van destinados, por lo
que los datos son enviados a todos los puertos, para que todos los dispositivos puedan
recibirlos. Actualmente se encuentran de salida del mercado y de la implementación de
las redes de datos actuales. La figura 1.3 muestra un hub de cuatro puertos.

3
1. CONCEPTOS GENERALES

Figura 1.3: Hub de cuatro puertos Netgear EN104TP. Fuente: netgear.com.

Puntos de acceso inalámbrico

Un punto de acceso inalámbrico es un dispositivo que permite extender la conec-
tividad de una red hacia dispositivos móviles de cómputo inalámbricamente (laptops,
tabletas, celulares, etc).

Los AP, generalmente, se encuentran conectados de manera alámbrica a otros equi-

pos de comunicación y permiten transmitir datos entre los dispositivos conectados a la
red cableada y los dispositivos móviles. En la figura 1.4 se muestra un Access Point.

Figura 1.4: Access Point Linksys WAP54G. Fuente: linksys.com.

4
 1.1 Redes de Datos

Router
Un router es un dispositivo que tiene como principal función establecer la conexión
de muchas redes. Estos dispositivos analizan los datos que van a ser enviados o recibidos
para poder seleccionar la mejor ruta de desplazamiento de la información, para su
transmisión eficaz. La figura 1.5 muestra un router.

Figura 1.5: Router Cisco Serie 1900. Fuente: cisco.com.

Firewall
Estos dispositivos especializados cumplen una función importante en la seguridad
de la red al examinar y filtrar la información recibida, según su dirección de origen y
destino, protegiendo la red de posibles ataques. En la figura 1.6 se muestra un firewall.

Figura 1.6: Firewall Fortinet Fortigate – 100D. Fuente: fortinet.com.

1.1.4. Topologı́as de red

Una topologı́a de red se define como la conexión entre un conjunto de nodos, ası́
como la forma en que se encuentran conectados éstos; para que pueda existir una cadena
de comunicación y pueda existir el proceso de transmisión de información.

1.1.4.1. Topologı́as fı́sicas

Cuando se habla de la manera en que están configurados los nodos y la forma en que
intercambian datos entre ellos mediante conexiones fı́sicas, se dice que es una topologı́a
fı́sica de red. A continuación se explicarán las diferentes topologı́as fı́sicas de red que
existen.

5
1. CONCEPTOS GENERALES

Malla
La topologı́a de malla presenta la caracterı́stica de que cada nodo se encuentra
conectado a todos los demás nodos que conforman la red. Al tener un enlace punto
a punto y dedicado con los demás nodos que conforman la red, permite llevar los
mensajes por diferentes caminos; eliminado la desventaja de los medios de transmisión
compartidos, lo que evita que la comunicación y transmisión se vea afectada. Lo mismo
pasa sı́ uno de los nodos llegase a fallar. Comparada con las demás topologı́as fı́sicas
de red, esta topologı́a tiene la desventaja de requerir una mayor cantidad de cable,
haciendo que el costo de implementación sea alto. La figura 1.7 describe esta topologı́a.

Figura 1.7: Topologı́a tipo Malla. Fuente: wikipedia.com.

Estrella
En la topologı́a de estrella, los nodos de una red se conectan a un nodo central, en
la que el nodo central puede ser un hub o un switch. Una ventaja de esta topologı́a
es permitir que todos los nodos se comuniquen de manera conveniente. Si un nodo o
el cable se dañan, no interrumpe el desempeño de la red. La implementación de esta
topologı́a es sencilla. La desventaja de esta topologı́a es que sı́ el nodo central falla,
toda la red quedarı́a sin comunicación. La figura 1.8 ilustra una topologı́a de red tipo
estrella.

Figura 1.8: Topologı́a tipo Estrella. Fuente: wikipedia.com.

6
 1.1 Redes de Datos

Árbol
En una topologı́a tipo árbol, los nodos se encuentran distribuidos mediante una confi-
guración jerárquica, en la que el medio de transmisión es un cable ramificado. Pueden
existir una o varias ramificaciones de cable que se conectan a un punto inicial llamado
raı́z o cabecera. A su vez, éstas pueden contener más ramificaciones, lo cual da lugar
a una topologı́a más compleja. Para poder implementar este tipo de topologı́a, los dis-
positivos de red que se emplean son concentradores o switches.

Como principal desventaja de esta topologı́a, es sı́ alguno de los dispositivos de red
llegase a fallar, dejarı́a sin transmitir información hacia esa ramificación y todas las
demás que se extienden debajo de ésta.

Esta topologı́a tiene la ventaja de presentar una estructura con un orden jerárquico,
lo cual proporciona facilidad para la resolución de problemas en caso de fallas. En la
figura 1.9 se muestra una topologı́a de red tipo árbol.

Figura 1.9: Topologı́a tipo Árbol. Fuente: wikipedia.com.

Bus
En una topologı́a tipo bus, todos los nodos se conectan directamente a un canal
único digital, llamado bus o backbone, en una configuración multipunto. Básicamente
cualquier nodo puede transmitir datos hacia otro nodo, propagándose por todo el me-
dio. Esta topologı́a, presenta tres principales desventajas. La primer desventaja es que
al momento de transmitir información desde un nodo origen hacia un nodo destino,
todos los nodos conectados al bus reciben dicha transmisión.

La segunda desventaja es sı́ dos nodos deciden transmitir al mismo tiempo, las
señales que son enviadas por el medio colisionarán y serán erróneas. También se debe
considerar el hecho de que un nodo esté continuamente transmitiendo información a
través del medio.

7
1. CONCEPTOS GENERALES

Finalmente, sı́ falla el backbone, todos los nodos dejarán de transmitir y toda la
red dejará de funcionar.

Para corregir estos problemas, los nodos envı́an información en pequeñas porciones
de datos llamadas tramas. Cada una de estas tramas contiene el identificador del nodo
de destino, para que ası́ únicamente el nodo para quién está dirigida, reciba dicha trama
y los demás nodos la ignoren. Al reducir el tamaño total de la información a transmitir
en tramas, permite que por el mismo bus se intercalen estas tramas. A esto se le llama
multiplexación.

Debido a que la arquitectura de esta topologı́a es simple, las ventajas de ésta es

una facilidad en la implementación y puesta en funcionamiento. En la figura 1.10 se
muestra dicha topologı́a.

Figura 1.10: Topologı́a tipo Bus. Fuente: wikipedia.com.

Anillo
Esta topologı́a se caracteriza por la forma de bucle cerrado que forman todos los
nodos que se encuentren en ella. Los enlaces en esta topologı́a son unidireccionales, lo
que significa que el sentido de la transmisión puede realizarse en el sentido de las agujas
del reloj o en el sentido contrario. La principal desventaja de esta topologı́a es que sı́
un nodo llega a fallar, se rompe el anillo y la red se queda sin comunicación.

Existe una segunda versión de esta topologı́a: anillo doble, la cual es similar a la
topologı́a de anillo, con la diferencia de que existe un segundo enlace redundante. En la
topologı́a de anillo doble, un anillo es utilizado como enlace principal, mientras que el
otro se emplea de reserva. En otros casos, la configuración de esta topologı́a es utilizada
para que la transmisión de la información sea en ambas direcciones. La ventaja de esta
variante es una mayor tolerancia a fallos, lo cual garantiza una mayor disponibilidad
de la red. La figura 1.11 muestra una topologı́a de red en anillo.

8
 1.1 Redes de Datos

Figura 1.11: Topologı́a tipo Anillo. Fuente: wikipedia.com.

Hı́bridas
Una topologı́a hı́brida es una combinación de las topologı́as descritas anteriormente.
Un ejemplo de esta topologı́a puede ser una compuesta por las siguientes: estrella-árbol,
bus-estrella, etc. La implementación de ésta dependerá de las necesidades de cada una
de las organizaciones. Esta topologı́a permite cubrir el aumento en el número de nodos o
dispositivos, debido a los componentes que la pueden conformar. Generalmente su costo
es muy elevado, mientras que la administración es compleja. La figura 1.12 describe esta
topologı́a de red.

Figura 1.12: Topologı́a tipo Hı́brida (Estrella-Bus-Estrella). Fuente: google.com.

9
1. CONCEPTOS GENERALES

1.1.4.2. Topologı́as lógicas

Cuando se habla de la manera en que un nodo transmite una trama hacia al siguien-
te nodo, se trata de una topologı́a lógica de red. Esta configuración emplea conexiones
virtuales, independientemente de la distribución fı́sica y son los protocolos de la capa de
enlace de datos que establecen estas conexiones virtuales. Las topologı́as más comunes
son la broadcast y transmisión de tokens.

Broadcast
También conocida como bus, en esta topologı́a cada host transmite sus datos hacia
los demás host que están conectados en la red. No hay un orden, por lo que el acceso
se otorga hacia el primer host que transmita sus datos al medio.

Tokens
En esta topologı́a se controla el acceso a la red de los host mediante un token
electrónico, el cual es transmitido secuencialmente a cada uno de ellos. Cuando un host
recibe el token, significa que tiene la oportunidad de transmitir datos a través de la
red. Sı́ dicho host no tiene ninguna información para enviar, transmite el token hacia
el siguiente host, repitiéndose el proceso nuevamente. Los ejemplos más populares de
la transmisión de tokens son Token Ring y la Interfaz de Datos Distribuida por Fibra
(FDDI). En el caso de esta última, el token circula entre los equipos a velocidades muy
altas.

1.1.5. Tipos de red

El tamaño e infraestructura de una red de datos varı́a en gran medida al número de
usuarios que necesiten conectarse, el área geográfica cubierta y los diferentes servicios
que se encuentren disponibles a través de ella. De acuerdo a lo anterior éstas se pueden
clasificar como redes LAN, MAN y WAN.

Una red LAN o también llamada Red de Área Local, cubre un área geográfica única,
proporcionando conectividad a estaciones de trabajo en una organización como puede
ser una empresa, una biblioteca o una escuela de tamaño mediano. La extensión es
limitada, ya que la conectividad entre una estación de trabajo y otra es de 100 metros.
Dicha red es administrada por una única organización. La velocidad de transmisión en
la que operan son de 10 Mbps, 100 Mbps y 1 Gbps. La figura 1.13 ilustra una red LAN.

10
 1.1 Redes de Datos

Figura 1.13: Red LAN. Fuente: Netacad CISCO.

1.1.5.1. MAN

Una red MAN o Red de Área Metropolitana recibe su nombre debido a que propor-
ciona cobertura a un área geográfica extensa como por ejemplo una ciudad. Los medios
de transmisión empleados en este tipo de redes pueden ser una combinación de fibra
óptica y par trenzado. Las velocidades de transmisión a las que opera este tipo de redes
sobre par trenzado son 10 Mbps, 20 Mbps, 45 Mbps y 75 Mbps; mientras que en fibra
óptica las velocidades son de 100 Mbps, 1 Gbps y 10 Gbps. La figura 1.14 describe este
tipo de red.

Figura 1.14: Red MAN. Fuente: Netacad CISCO.

11
1. CONCEPTOS GENERALES

1.1.5.2. WAN

Una red WAN o Red de Área Amplia permite interconectar varias redes LAN y
MAN que se encuentran en distintas ubicaciones. La cobertura geográfica de este tipo de
redes ofrece distancias desde los 100 Km hasta los 1000 Km; lo cual permite comunicar
varios paı́ses e incluso hasta continentes enteros. Estas redes las utilizan organizaciones
particulares y por los ISP para proporcionar servicios a sus clientes. La figura 1.15
ilustra una red WAN.

Figura 1.15: Red WAN. Fuente: Netacad CISCO.

1.1.5.3. Redes inalámbricas

Las redes inalámbricas proporcionan conectividad y comunicación sin el uso de una
conexión fı́sica, a dispositivos portátiles de cómputo, tales como laptops, tabletas, celu-
lares, televisores, entre otros dispositivos electrónicos. Este tipo de redes en particular,
proporciona conectividad a usuarios que se desplazan dentro de un área geográfica en
particular.

La conexión se establece a través de ondas electromagnéticas. De la misma manera

en que las redes cableadas se clasifican de acuerdo al área geográfica que cubren, las
redes inalámbricas se clasifican de la siguiente manera:

Wireless Personal Area Network (WPAN)

Las redes de área personal inalámbricas, tiene un alcance entre 1 a 10 metros. El uso
de estas redes es para conectar dispositivos periféricos como impresoras, smartphones,
ratones inalámbricos, sistemas de audio e inclusive conectar dos computadoras cercanas;
sin emplear una conexión cableada. El estándar de red en una WPAN es el IEEE
802.15, que comúnmente es llamado Bluetooth. Ofrece una velocidad de hasta 55 Mbps
(estándar IEEE 802.15.3 - 2003).

12
 1.1 Redes de Datos

Wireless Local Area Network (WLAN)

Las redes de área local inalámbricas, ofrecen una cobertura al equivalente de una
LAN en una compañı́a; y representan una opción para aquellas organizaciones en las
que el cableado no es una solución. El estándar de una LAN inalámbrica es el IEEE
802.11, comúnmente llamada Wi-Fi. Éste estándar ofrece una velocidad máxima de 600
Mbps en varios cientos de metros (estándar IEEE 802.11n).

Wireless Metropolitan Area Network (WMAN)

Las redes de área metropolitana inalámbricas, utilizan tecnologı́as basadas en el
estándar IEEE 802.16, conocidas comúnmente como WiMAX (Worldwide Interopera-
bility for Microwave Access). WiMAX es similar a Wi-Fi, pero ofrece una mayor co-
bertura y ancho de banda. Esta tecnologı́a emplea una topologı́a punto a multipunto,
para proporcionar acceso a servicios de banda ancha inalámbrica. La cobertura puede
ser de hasta 50 km.

Wireless Wide Area Network (WWAN)

Las redes de área extendida inalámbricas emplean tecnologı́as de red celular como
LTE, WiMAX, UMTS, CDMA2000, GSM, entre otras; para la transmisión de datos.
Estas tecnologı́as son ofrecidas a nivel regional, nacional e incluso a nivel mundial, las
cuales son proporcionadas por un proveedor de servicios inalámbricos.

A continuación, en la figura 1.16 se ilustran las diferentes tecnologı́as de redes

inalámbricas.

Figura 1.16: Tecnologı́as de las redes inalámbricas. Fuente: ccm.net.

13
1. CONCEPTOS GENERALES

1.1.6. Protocolos de red

Para que pueda existir una adecuada conectividad y se pueda llevar a cabo un pro-
ceso de comunicación exitoso entre los diferentes tipos de dispositivos que conforman
la red, es necesario que existan reglas predeterminadas denominadas protocolos. Éstos
se interrelacionan unos con otros y se encuentran implementados tanto en el software
como en el hardware.

Los protocolos se encuentran organizados en una jerarquı́a de capas, en el cual cada

capa interactúa con la capa superior o inferior, por lo que sı́ los datos se van a trans-
mitir; cada una de las capas tienen la tarea de agregar una cabecera. Éstos, más la
cabecera pasarán a la capa inferior hasta que los datos sean transmitidos por el medio
fı́sico. Sı́ los datos son recibidos, llegan por el medio fı́sico por la capa inferior y subirán
por la pila de capas, en la que cada una de éstas leerán las cabeceras correspondientes y
al mismo tiempo realizará el proceso de desencapsulación de los datos, transmitiéndolos
a la capa superior hasta llegar a la capa de destino. Es por ello que cada uno de los
servicios de una capa de nivel superior, depende de la funcionalidad y servicios esta-
blecidos en las capas de niveles inferiores.

Actualmente el modelo de referencia más conocido es el OSI, el cual se emplea como

referencia para los protocolos de red como el TCP/IP. Tanto el modelo OSI como el
TCP/IP son los principales modelos empleados para el funcionamiento de una red.
También los diseñadores de protocolos de red, pueden desarrollar sus propios modelos.

1.1.6.1. Modelo OSI

El llamado modelo OSI fue desarrollado por la ISO, la cual es la Organización de
Estándares Internacionales, en el año de 1980. Este modelo propone una pila de 7 capas
para la correcta comunicación en una red de datos y describe la interacción de cada
capa con las que se encuentran por encima y debajo de éstas. A continuación se descri-
birán cada una de las 7 capas empezando por la capa superior.

En la figura 1.17 se ilustra la pila de capas del modelo OSI.

14
 1.1 Redes de Datos

Figura 1.17: Modelo OSI. Fuente: Netacad CISCO.

Capa de Aplicación
La capa 7 del modelo OSI, ofrece a las aplicaciones la manera de acceder a los
servicios de las capas inferiores. También establece varios protocolos que son utilizados
frecuentemente por los usuarios finales, para el intercambio de datos.

Capa de Presentación
La capa de presentación también es denominada capa 6 del modelo OSI. Dicha capa
se encarga de la sintaxis y la semántica de la información transmitida, de tal manera
que aunque distintos equipos tengan diferentes representaciones internas de caracteres,
la información sea recibida y transmitida de manera legible. Ası́ mismo, esta capa se
encarga de comprimir y descomprimir la información, ası́ como su cifrado y descifrado
de los mismos.

Capa de Sesión
La capa 5 del modelo OSI, permite que ambos extremos de la comunicación esta-
blezcan una sesión, manteniendo y controlando el enlace establecido entre dos máquinas
diferentes. Esta capa da seguimiento sobre quién puede transmitir, impide que ambos
extremos traten de hacer una acción crı́tica al mismo tiempo y permite reanudar una
sesión establecida en caso de una interrupción.

Capa de Transporte
La capa de transporte o capa 4 del modelo OSI, divide los datos recibidos de las
capas superiores en unidades más pequeñas denominados segmentos sı́ es a través del
protocolo TCP, o datagramas en el caso del protocolo UDP. Éstos son transmitidos a
la capa de red y se asegura de que todas estas unidades lleguen correctamente al otro

15
1. CONCEPTOS GENERALES

extremo de la comunicación.

Capa de Red
La capa 3 del modelo OSI determina el camino a seguir de un paquete desde su
origen hasta su destino, a pesar de que ambos no estén conectados directamente. A
esta acción se le denomina enrutamiento y puede basarse en tablas definidas por un
administrador de red (enrutamiento estático) o cuando los dispositivos de red llamados
routers intercambian información de las tablas de rutas (enrutamiento dinámico). Los
protocolos de enrutamiento más empleados son los siguientes:

Routing Information Protocol (RIP)

Es un protocolo de ruteo classful de gateway interior que emplea como métrica el
conteo de saltos. Este protocolo determina cuál es la mejor ruta desde un origen hacia
un destino mediante el empleo del algoritmo vector-distancia. Realiza el intercambio
de información de su tabla de ruteo a través del protocolo UDP por el puerto 520.

Actualmente existen dos variantes del protocolo RIP original: RIPv2 y RIPng. El
primero es una mejora del protocolo RIP ya que es un protocolo classless, lo que quiere
decir que soporta VLSM y el segundo soporta IPv6.

Open Shortest Path First (OSPF)

OSPF es un protocolo de ruteo classless de estado-enlace desarrollado como re-
emplazo del protocolo RIP. Probablemente es el protocolo de gateway interior más
empleado en redes de gran escala. La métrica de este protocolo denominada costo, se
basa principalmente en el ancho de banda.

Emplea el algoritmo Dijkstra para determinar la mejor ruta entre un origen y des-
tino de un sistema autónomo. Las ventajas de este protocolo es una rápida convergencia
y una escalabilidad mucho mayor de implementaciones de grandes redes de datos, a di-
ferencia de RIP.

Interior Gateway Routing Protocol (IGRP)

IGRP es un protocolo classful de gateway interior, desarrollado por Cisco Systems
en respuesta a las limitaciones del protocolo RIP. Dicho protocolo emplea el algoritmo
vector-distancia y a veces también considera el algoritmo estado-enlace, el cual determi-
na la mejor ruta entre un origen y destino considerando el ancho de banda, el retardo,
confiabilidad y carga del enlace. Actualmente este protocolo no es soportado por el
sistema operativo de los dispositivos Cisco.

Enhanced Interior Gateway Routing Protocol (EIGRP)

Este protocolo de ruteo por vector-distancia avanzado, es una versión mejorada de
IGRP. EIGRP es un protocolo classless de gateway interior. Utiliza el algoritmo DUAL
(Difussing Update Algorithm), el cual garantiza una excepcional y rápida convergencia

16
 1.1 Redes de Datos

de red. DUAL implementa caracterı́sticas que no se encuentran en los protocolos de

enrutamiento por vector-distancia, como es el envı́o de actualizaciones periódicas.

Capa de Enlace de Datos

La capa de enlace de datos es denominada también capa 2. Esta capa prepara los
paquetes recibidos de las capas superiores para ser transmitidos, además de controlar
el acceso a los medios fı́sicos. Los paquetes dejan de llamarse ası́ y se convierten en
tramas. La trama de la capa de enlace de datos incluye lo siguiente:

Encabezado: Está ubicado al inicio de la trama, y contiene información del inicio

de la trama, direcciones de origen y destino de la trama ası́ como control de flujo.

Datos: El paquete de la capa de red.

Cola o tráiler: Es información de control al final de la trama para la detección de

errores e indicación del fin de la trama.

A su vez la capa de enlace de datos se subdivide en dos capas: control de enlace

lógico (LLC) y control de acceso al medio (MAC).

Control de enlace lógico

El control de enlace lógico (LLC) coloca información en la trama para identificar el
protocolo de la capa de red que está usando la trama. Esto permite que diferentes proto-
colos de la Capa 3 utilicen la misma interfaz de red y los mismos medios de transmisión.

Control de acceso al medio

El control de acceso al medio (MAC) proporciona información acerca del medio de
transmisión que se emplea en la comunicación, ası́ como la delimitación de datos de
acuerdo con los requisitos de señalización fı́sica del medio.

Capa Fı́sica
La capa 1 ó capa fı́sica del modelo OSI, se encarga de transmitir en un ambiente
fı́sico las cadenas de bits, que van desde un origen hasta un destino, de acuerdo a las
caracterı́sticas mecánicas, fı́sicas, eléctricas y funcionales del medio. Se consideran dos
tipos de medios para la transmisión de datos: medios guiados y no guiados. Los medios
guiados hacen uso del cable como por ejemplo cable coaxial, par trenzado y fibra óptica.
Los medios no guiados o sin cable comprenden microondas, satélites, ondas de radio,
etc.

17
1. CONCEPTOS GENERALES

1.1.6.2. Protocolo TCP/IP

TCP/IP es el modelo que se usó en la red experimental ARPANET, el cual hace

posible la comunicación entre diferentes computadoras que utilizan diferente sistema
operativo sobre una red LAN o en una red WAN. La familia de protocolos TCP/IP
tiene una amplia suite de protocolos que actualmente son estándares de Internet.

Este modelo de protocolo consta de 4 capas como se muestra en la figura 1.18:

Figura 1.18: Modelo TCP/IP. Fuente: Netacad CISCO.

Capa de Aplicación
Al igual que la capa de aplicación es la capa superior en el modelo OSI, también
lo es en el modelo TCP/IP. Ésta sirve de enlace entre los usuarios, las aplicaciones
que son utilizadas para establecer una comunicación y la red subyacente en la cual son
transmitidos los mensajes.

Un protocolo de la capa de aplicación es el HTTP (Hypertext Transfer Protocol),

el cual permite la transferencia de información en la World Wide Web. Básicamente
cuando un navegador web desea una página web, emplea este protocolo para hacer una
solicitud al servidor del recurso solicitado. Otros protocolos de la capa de aplicación son
el POP (Post Office Protocol) y SMTP (Simple Mail Transfer Protocol) para el correo
electrónico o el DNS (Domain Name System) para la resolución de nombres de dominio.

18
 1.1 Redes de Datos

Capa de Transporte
En la capa de transporte se encuentran las reglas o procedimientos que permiten
garantizar una transmisión segura entre un origen y destino, sin importar la naturaleza
de las aplicaciones que intercambian datos. Por otra parte, los protocolos más recono-
cidos para el transporte de datos se explican a continuación:

El protocolo TCP (Transmission Control Protocol) es orientado a la conexión lo

que asegura que los datos que son transmitidos sean recibidos por el otro lado de la
comunicación sin errores y en el mismo orden en el que fueron enviados, todo gracias
a la negociación en tres pasos conocido como Three-way handshake. Dicha negociación
consiste en que el destino envı́a un ACK (acuse de recibo) por cada paquete recibido al
origen, y sı́ algún paquete está dañado o malformado se solicita al origen que se envı́e
nuevamente ese paquete.

El protocolo UDP (User Datagram Protocol) permite el envı́o de datagramas sin

que exista una conexión previa ni acuse de recibido, por lo que no se garantiza la entrega
de todos los paquetes al destino. Tampoco cuenta con control de flujo, por lo que los pa-
quetes pueden llegar al destino en diferente orden al que fueron enviados desde el origen.

Capa de Internet
Al igual que la capa de Red del modelo OSI, esta capa se encarga de recibir y
transferir paquetes por el mejor camino a través de la red, para que puedan llegar a
su destino. Es probable que los paquetes hayan sido recibidos en distinto orden al que
fueron enviados, lo cual las capas superiores se encargarán de ordenar.

El Protocolo IP (Internet Protocol) se incluye en esta capa. Se encuentra imple-

mentado tanto en los equipos finales (PC’s, servidores, tablets, celulares, etc) como en
los equipos intermediarios (routers). Dicho protocolo:

Establece las convenciones de direcciones IP, ya que introduce las direcciones IPv4
y direcciones IPv6.

Establece la ruta que debe seguir un paquete con base a la dirección IP del
destinatario.

Agrega un encabezado IP a los paquetes, adicional a la información de los proto-

colos TCP o UDP. El encabezado contiene las direcciones IP tanto de origen como
de destino, la longitud del datagrama y el número de secuencia del datagrama.

Fragmenta un paquete si es demasiado grande para su transmisión a través del

medio de red. El protocolo IP del destinatario reconstruye los fragmentos, para
formar el paquete original.

Capa de Acceso a la Red

Dicha capa se encarga del intercambio de datos entre el receptor y la red a la cual

19
1. CONCEPTOS GENERALES

se está conectando el emisor. También especifica las caracterı́sticas del hardware de red
que se utilizará para la red y las caracterı́sticas fı́sicas del medio de comunicaciones,
para que los datos puedan ser transmitidos.

20
 1.2 Seguridad

1.2. Seguridad
El concepto de seguridad es una caracterı́stica de cualquier sistema ya sea informáti-
co o no, en el cual se busca protegerlo de sufrir algún peligro o daño, permitiendo ga-
rantizar su adecuada y normal operación.

Dentro del concepto de seguridad, existen dos definiciones fundamentales y que

aunque pueden ser parecidos, en realidad no lo son: seguridad de la información y
seguridad informática.

1.2.1. Tipos de seguridad

Seguridad de la Información
Considerando desde el enfoque de los sistemas computacionales, la información se
define como: “conjunto fundamental de datos organizados y procesados, los cuales son
intercambiados por un individuo y un sistema informático, cambiando el estado de co-
nocimiento de quién recibe estos datos”.

Partiendo de la definición anterior, el concepto de seguridad de la información se

define como: “las acciones y mecanismos que son aplicados, a fin de prevenir cualquier
acción que ponga en un estado endeble la información, garantizando su integridad, con-
fidencialidad y disponibilidad”.

Seguridad Informática
La seguridad informática tiene sus orı́genes por allá en tiempos de la Segunda Gue-
rra Mundial, cuando a los primeros mainframes desarrollados para hacer cálculos, se les
protegı́a la confidencialidad e integridad de su información mediante candados, chapas,
ası́ como reconocimiento facial del personal autorizado que podı́a acceder. Conforme fue
aumentando la necesidad de salvaguardar la información que contenı́an, se emplearon
métodos más complejos y tecnológicamente más sofisticados.

La seguridad informática se define como “la necesidad de proteger al hardware, soft-

ware y la ubicación fı́sica de los sistemas informáticos de amenazas, a fin de garantizar
la confidencialidad, integridad y disponibilidad de la información que reside en dichos
sistemas”.

Las técnicas de intrusión que son empleadas dı́a a dı́a, para comprometer a los sis-
temas actuales han sido más agresivas, lo que ocasiona un mayor impacto para quién
las recibe. Un ejemplo de esto, es el gusano Stuxnet. Stuxnet se propagaba a través
de sistemas de control industrial, para reprogramar estos sistemas y que los atacantes
pudieran tomar control de éstos, sin que los operadores pudieran percatarse de las ac-
tividades ilı́citas que eran realizadas.

21
1. CONCEPTOS GENERALES

Fue la primera amenaza que permitió pasar de un daño virtual a un daño fı́sico, de-
bido a que estaba programado para hacer dos ataques. El primero estaba dirigido a las
instalaciones de enriquecimiento de uranio en Irán, en el cual era capaz de manipular
la velocidad de las partes mecánicas del proceso de enriquecimiento, lo que ocasionarı́a
que se agrietara el rotor principal, destruyendo el centrifugado, mientras que el segundo
ataque contenido en Stuxnet, pretendı́a atacar la central eléctrica de Bushehr de Irán,
en el cual destruirı́a las turbinas exteriores de la planta, imposibilitando el abasteci-
miento de energı́a eléctrica a ese paı́s.

Es por ello que el presente proyecto tiene como objetivo la implementación de una
SandBox, en la cual se analizarán los archivos que fueron detectados como maliciosos
con ayuda de un IDS, el cual proporcionará dichas muestras.

Antes de poder proporcionar seguridad de la información, se debe contestar las si-

guientes interrogantes: ¿Qué queremos proteger? ¿Para qué se quiere proteger? ¿De qué
o quiénes nos queremos proteger? ¿Cómo nos podemos proteger?, para tener un pano-
rama mucho más amplio, y ası́ saber cuáles son las necesidades de seguridad en una
organización, ası́ como los recursos que se deberán emplear para poderla proporcionar.

Seguridad de la red
La seguridad de la red se puede definir como la protección de los equipos y dispositi-
vos de red que almacenan y transmiten información dentro y fuera de una organización.

En la actualidad, establecer medidas de seguridad en la red es un control básico,

debido a que la infraestructura de red de la mayorı́a de las organizaciones, tiene puntos
de contacto con la red pública. La red de una organización, al interactuar con las redes
públicas, permite aumentar el número de intrusiones a los sistemas de información de
la organización, ya que además tienen que lidiar con los ataques informáticos que se
generan dentro de ésta.

En un ataque informático externo, el atacante busca la manera de poder infiltrarse

en la red de una organización, a través de una debilidad o falla de seguridad. Por otro
lado, en un ataque informático interno, el usuario malicioso no se preocupa sobre cómo
acceder a la red de una organización porque ya se encuentra en ella, por lo cual le facilita
realizar acciones que atente contra los sistemas y a la información que logre tener acceso.

Los ataques informáticos externos comprenden casi tres cuartas partes de los ata-
ques totales en una organización, mientras que los ataques internos representan el por-
centaje restante. Sin embargo, los ataques internos son los que tienen un mayor impacto
negativo en los intereses de una organización, comparado con los ataques externos.

22
 1.2 Seguridad

Seguridad fı́sica
La seguridad fı́sica se refiere a la implementación de barreras fı́sicas y mecanismos
de control (diseño, implementación y mantenimiento) que permitan proteger de amena-
zas, los recursos fı́sicos de una organización, los cuales interactúan con la información en
todos sus estados (transmisión, almacenamiento o procesamiento). La seguridad fı́sica
analiza como principales amenazas las catástrofes naturales y artificiales, ası́ como las
amenazas humanas.

Una catástrofe natural y artificial es la amenaza que tiene una menor probabilidad
de que pueda ocurrir, aunque dependiendo de la ubicación geográfica que se tome como
referencia, puede aumentar la probabilidad de ocurrencia. El hecho de que este tipo de
amenazas sean las menos probables de ocurrir, no implica que no se tomen medidas
básicas, ya que sı́ no se hicieran, tendrı́an un impacto negativo mucho mayor para la
organización en cuestión.

Como ejemplo de una amenaza humana, se puede mencionar la interrupción del

suministro eléctrico, un acceso no autorizado o no monitoreado, el uso de dispositivos
electrónicos no autorizados, derrame accidental de lı́quido sobre los equipos de cómpu-
to, entre otros.

De acuerdo a la norma ISO 27002:2013, el dominio de seguridad fı́sica y ambiental

establece una serie de objetivos de control y actividades de control para la implemen-
tación de seguridad fı́sica en una organización, los cuales se describen a continuación:

Áreas seguras
Los activos que procesen información crı́tica o confidencial deben ser ubicados en
áreas seguras, protegidos por los perı́metros de seguridad definidos, con las adecuadas
barreras de seguridad y controles apropiados. Este objetivo de control previene un ac-
ceso fı́sico no autorizado, daño e interferencia en las instalaciones y en la información
de la organización y establece los siguientes controles:

Perı́metro de seguridad fı́sico. Los perı́metros de seguridad fı́sico deben ser definidos
y usados para proteger áreas que contengan información crı́tica o sensible, ası́ como las
instalaciones de procesamiento de información.

Controles de acceso fı́sico. Las áreas seguras deben ser protegidas por controles de
entrada apropiados para asegurar que sólo personal autorizado cuenta con permiso de
acceso.

Seguridad de oficinas, pisos e instalaciones. Se debe diseñar y aplicar un sistema

de seguridad fı́sica para oficinas, pisos e instalaciones de la organización.

Protección contra las amenazas externas y ambientales. Control en el que se analiza

23
1. CONCEPTOS GENERALES

la manera de cómo prevenir daño por fuego, inundación, terremoto, explosión, distur-
bios civiles y otros desastres naturales o que pueden ser provocados por el hombre.

Trabajo en áreas seguras. Como área segura se define el lugar fı́sico en el que se
encuentra la información crı́tica de una organización. Se deben establecer pautas para
permitir el trabajo en un área segura.

Áreas de entrega y carga. Los puntos de entrega y carga de una organización deben
ser identificados y separados de los activos de información, a fin de evitar accesos no
autorizados a la organización.

Seguridad de los equipos

Los equipos deben ser protegidos contra amenazas fı́sicas y ambientales, para pre-
venir pérdida, daño, robo o compromiso de los activos, ası́ como interrupciones en las
operaciones de la organización. Este objetivo de control proporciona las siguientes ac-
tividades:

Ubicación y protección del equipamiento. Los equipos deben ser ubicados y prote-
gidos para reducir los riesgos de amenazas ambientales y peligros, ası́ como de accesos
no autorizados.

Instalaciones de suministros. El equipo debe ser protegido de fallas de suministro

eléctrico y otras interrupciones causadas por fallas en la instalación de suministros.

Seguridad del cableado. Tiene como objetivo proteger contra la intercepción, inter-
ferencia o posibles daños al cableado eléctrico y de telecomunicaciones, que transportan
información y/o apoyan a los servicios de información.

Mantenimiento del equipo. Se le debe proporcionar un adecuado mantenimiento al

equipo de una organización, para garantizar la continua disponibilidad e integridad de
la información con la que interactúan.

Eliminación de los activos. Tiene como objetivo prevenir la eliminación de los acti-
vos por lo que éstos, la información y el software no deben ser retirados de su sitio sin
previa autorización.

Seguridad de los equipos y activos fuera de las instalaciones. Se deben aplicar con-
troles de seguridad a los activos que se encuentran fuera de la organización, pero que
contienen información de la misma, tomando en cuenta el riesgo que representa que
ésta pueda ser expuesta.

Seguridad en la reutilización o eliminación del equipo. Establece que todos los equi-
pos y activos que contienen medios de almacenamiento, deben ser verificados para

24
 1.2 Seguridad

asegurar y garantizar que ninguna información sensible y software licenciado ha sido

eliminado o sobrescrito de manera segura antes de su eliminación o reutilización.

Equipo de usuario desatendido. Los usuarios se deben asegurar que los equipos que
no son supervisados, cuentan con la protección apropiada.

Polı́tica de escritorio limpio y bloqueo de pantalla. El personal de la organización

debe adoptar una polı́tica, en la cual se establezcan controles para que los lugares de
trabajo se encuentren despejados de cualquier tipo de documentación en papel, ası́
como de cualquier medio de almacenamiento extraı́ble.

1.2.2. Servicios de Seguridad

Un servicio de seguridad se define como la acción que coadyuva a proteger el flujo
de información entre los diferentes sistemas de información de una organización, em-
pleando modelos, métodos o mecanismos, evitando un ataque informático.

Confidencialidad
La confidencialidad se define como la protección de la divulgación o exposición de
la información a usuarios o sistemas no autorizados. Cuando ocurre lo contrario se dice
que la confidencialidad es incumplida. Para garantizar la confidencialidad de la infor-
mación se establecen mecanismos como clasificación de la información, cifrado de la
información, entre otros.

En la actualidad, muchas organizaciones esperan que la información interna crı́ti-

ca que manejan y la que intercambian con otras se mantenga confidencial, debido al
valor de mercado de la mayorı́a de éstas; por lo que confı́an que la información de la
organización se mantenga a salvo de individuos no autorizados para su conocimiento,
pudiendo tener un impacto negativo en los intereses financieros de éstas.

Algunos ejemplos que atentan contra la confidencialidad de la información son el

malware, intentos de intrusión, ingenierı́a social, redes sin el nivel de seguridad adecua-
do y sistemas pobremente administrados.

Integridad
El servicio de integridad permite asegurar que la información no sufra una modi-
ficación o alteración en el contenido de ésta, sin una debida autorización. Ası́ mismo,
durante la transmisión de información también debe existir integridad, por lo cual en la
secuencia de datos que son enviados por un emisor deben ser recibidos tal cual fueron
enviados por un receptor.

La integridad de la información es amenazada cuando la información es expuesta a

un daño, como puede ser la destrucción o la corrupción de datos.

25
1. CONCEPTOS GENERALES

Existen mecanismos para validar la integridad de un archivo, el cual es llamado

valor hash. Este elemento es un indicador que permite saber sı́ un archivo ha sufrido
alguna modificación desde su origen, hasta el momento en que se encuentra en el destino.

Disponibilidad
La disponibilidad permite a los usuarios o sistemas autorizados acceder a la in-
formación sin ninguna interferencia u obstrucción. Sı́ una información es requerida o
solicitada y ésta no es desplegada en un corto lapso de tiempo, se considera que no hay
disponibilidad de la misma.

Los ataques que atentan contra la disponibilidad de información son conocidos como
denegación de servicio (DoS), los cuales consisten en enviar un gran número de cone-
xiones o grandes solicitudes de información hacia un sistema objetivo, por lo que llega
a sobrecargarse y no responde a solicitudes legı́timas de información. También existe
una variante del ataque DoS llamado denegación de servicio distribuido (DDoS), en el
cual un conjunto de conexiones o peticiones se coordinan desde diferentes ubicaciones
y son enviadas al mismo tiempo hacia un objetivo.

Autenticación
El servicio de autenticación consiste en validar y comprobar la identidad de una
entidad quién dice ser, mediante alguno de los siguientes tres métodos de autenticación:

¿Qué sabes?: Tiene como objetivo, validar y comprobar algo que únicamente de-
be saber un individuo o un sistema autorizado, comparándolo con la información que
cuenta en la base de datos al sistema que se desea acceder. Este método hace uso
de contraseñas, NIPs, códigos secretos, etc. Sin embargo, este método no es considera-
do como fuerte y no es adecuado para sistemas que requieren un alto nivel de seguridad.

¿Qué tienes?: Consiste en emplear llaves para el desbloqueo de una barrera fı́sica
o virtual, para poder tener acceso al espacio o sistema deseado. Un ejemplo de des-
bloqueo de una barrera fı́sica, es el uso de una llave que permite abrir un candado o
puertas. Por otro lado, el uso de un token o una tarjeta magnética permite desbloquear
una barrera virtual y por lo tanto, permite tener acceso al sistema o recurso solicitado.
El riesgo de este método, es que las llaves se pueden perder, dañar o ser robadas.

¿Qué eres?: Este método se refiere a la autenticación biométrica, en la cual usa

las caracterı́sticas del ser humano, como son las huellas digitales, la voz o la retina de
los ojos; las cuales sirven para identificar a un individuo de otro. La desventaja de este
método es que requiere de una previa instalación, configuración y mantenimiento.

Cuando son empleados adecuadamente y en conjunto los métodos descritos ante-

riormente, éstos contribuyen a una adecuada robustez en la forma de autenticación.

26
 1.2 Seguridad

Control de Acceso
El control de acceso es un método que determina cómo un individuo o sistema es
admitido para interactuar con la información. Los controles de acceso son dependientes
del servicio de autenticación, ya que en primera instancia se tiene que determinar si al
individuo o sistema se le otorga permiso al recurso solicitado. Este servicio cuenta con
tres modelos principales de control de acceso lógico, los cuales se explican a continua-
ción:

Control de Acceso Discrecional (DAC): Es el modelo de control de acceso

más ampliamente usado. En este, el dueño de la información impone un conjunto de
restricciones sobre los individuos que deseen tener acceso a la información que él posee,
mediante lo que ellos pueden hacer: leer, escribir, borrar, renombrar, mover, etc.

Control de Acceso Obligatorio (MAC): Se emplean esquemas de niveles de

clasificación de información (por ejemplo pública, restringido, confidencial, secreta y
ultra secreta), para tomar una decisión de acuerdo a un conjunto de polı́ticas de se-
guridad de la información y por los dueños de la información, las restricciones en los
controles de acceso.

Control de Acceso Basado en Roles (RBAC): Los permisos y derechos hacia

los recursos de la información se establecen de acuerdo a los roles o perfiles, en lugar de
usuarios individuales. Este modelo permite una administración más flexible, ası́ como
el cumplimiento de los controles de acceso en organizaciones con un gran número de
usuarios.

No repudio
El no repudio es un servicio de seguridad que actúa tanto en el emisor como en el
receptor de la información, en el cual tanto el emisor como el receptor no pueden refutar
que la información ha sido transmitida. Los tipos de no repudio que a continuación se
mencionan, se encuentran definidos en el estándar internacional ISO 14516 “Guı́a para
el uso y administración de proveedores de servicio de confianza electrónicos”, en el que
pueden ser demostrados a una tercera entidad:
Aprobación: Ofrece pruebas de quién es responsable de la aprobación del conte-
nido del mensaje.
Envı́o: Ofrece pruebas de quién fue el que envió el mensaje.
Origen: Ofrece pruebas del origen del mensaje. Es una combinación de aprobación
y envı́o.
Sumisión: Ofrece pruebas de que un agente de entrega ha aceptado el mensaje
para su transmisión.
Transporte: Ofrece pruebas de cualquier intento de negar que los datos no se
transmitieron.

27
1. CONCEPTOS GENERALES

Recepción: Ofrece pruebas de cualquier intento de negar por parte del receptor
que la información no fue recibida, con lo cual se brinda protección al emisor.

Conocimiento: Proporciona pruebas de que el receptor conoce el contenido del

mensaje transmitido.

Entrega: Proporciona pruebas de que el receptor recibió el mensaje y también

conoce el contenido del mensaje. Es una combinación de recepción y conocimiento.

1.2.3. Amenaza y vulnerabilidad

Vulnerabilidad
Vulnerabilidad, en el ámbito de seguridad informática, se define como una debilidad
en el diseño o implementación de algún sistema informático, que puede ser utilizado por
un atacante, violando la seguridad del mismo, para ocasionar algún daño sı́ el ataque
es intencionado. Existen vulnerabilidades que son muy reconocidas en los sistemas in-
formáticos, para los cuales se cuenta con la solución, ya sea una actualización de versión
o un parche de seguridad. Las vulnerabilidades que más afectan son las 0-day, ya que
no existe una solución conocida, pero sı́ se conoce la forma de explotarla.

Amenaza
Una amenaza es todo elemento, acción o evento capaz de atentar contra la seguri-
dad de la información, causando una alteración total y/o parcial a la información de la
organización, generando un impacto negativo de tipo material, económico, informativo
o prestigio de esta. Las amenazas se clasifican en dos grupos:

Amenazas intencionales: Son aquellas que deliberadamente pueden ocasionar

un daño hacia una organización (robo de información, divulgación de información, pro-
pagación de malware, suplantación de identidad, entre otros).

Amenazas no intencionales: Las amenazas no intencionales, se originan debido

a la falta de medidas, omisión o incumplimiento de acciones, que ponen en riesgo el
desempeño de los activos de información, impactando de manera negativa en la organi-
zación. Como ejemplo de amenazas no intencionales, se tienen los fenómenos naturales,
caı́das en los medios de comunicación, discontinuidad en el suministro eléctrico, entre
otros.

1.2.4. Análisis de riesgos

El análisis de riesgos es un proceso en el cual se logran identificar las amenazas y
vulnerabilidades a las que se encuentran expuestos los activos de alguna organización,
la probabilidad de ocurrencia y además se estima el impacto que supondrı́a en caso de
que se llegaran a concretar. Una vez que es obtenida esta información, se establecen

28
 1.2 Seguridad

polı́ticas o procedimientos para combatirlos.

Es importante mencionar, que ningún sistema o infraestructura se encuentra com-

pletamente seguro, por lo que un riesgo puede ser mitigado, aceptado o transferido.

Los siguientes conceptos proporcionan un panorama general en la comprensión del

análisis de riesgos:

Activo: Un activo es aquello que tiene un valor para una organización, que com-
pone el proceso de comunicación y que por ende necesita de protección; para que no
atenten contra su confidencialidad, integridad y disponibilidad. Éstos pueden ser hard-
ware, software, información personal, medios de almacenamiento, servidores, bases de
datos, infraestructura.

Riesgo: Un riesgo es una probabilidad de que ocurra un evento y se presente algún

daño o pérdida para los activos de la organización. Básicamente es la posibilidad de
que se concrete una amenaza.

Riesgo residual: Cuando las vulnerabilidades han sido controladas en la medida

de lo posible, aún sigue existiendo un riesgo que no ha sido completamente eliminado,
transferido o previsto. Este resto es lo que se conoce como riesgo residual.

El manejo del riesgo residual debe ser juzgado de acuerdo a la zona de confort de la
organización, ya que el objetivo de la seguridad de la información no es llevar el riesgo
residual a cero, sino manejarlo de acuerdo a los intereses de la organización.

Aceptación: La estrategia de aceptar un riesgo es la decisión que ha tomado una

organización, en la que no hay nada por hacer para proteger una vulnerabilidad y se
acepta el resultado de su explotación. Generalmente esta decisión se toma basada en
una conclusión, en la que el costo de proteger un activo no justifica los gastos de seguri-
dad. Por otro lado, se encuentran los legacy-systems, los cuales son sistemas anticuados,
pero se continúan empleando por los usuarios; y no es posible aplicar actualizaciones o
parches de seguridad de una manera sencilla; por lo que también se decide emplear la
estrategia de aceptación.

Transferencia: Esta estrategia, transfiere el riesgo a otros activos, procesos u

otras organizaciones. Esto se puede lograr cuando son reconsiderados cómo se ofrecen
los servicios, revisando los modelos de despliegue del Cloud Computing, el outsourcing
a otras organizaciones, adquiriendo seguros o implementando contratos de servicios con
proveedores.

Mitigación: La estrategia de mitigación de un riesgo, intenta reducir o eliminar

el impacto para una organización, causado por la explotación de una vulnerabilidad a

29
1. CONCEPTOS GENERALES

través de un proceso de planeación y preparación.

Análisis del riesgo: Permite establecer una clasificación o puntuación de un riesgo

para los activos de información. Es aquı́ en donde se evalúa que determinados eventos
no deseados pueden ocurrir, ası́ como el impacto de las consecuencias en caso de que
sucedieran.

Administración de riesgos: Este proceso es usado para identificar, controlar y

minimizar el impacto de eventos inciertos, por lo cual la principal función de la admi-
nistración de riesgos es reducir los mismos, hasta que alcancen un nivel aceptable para
la organización.

Impacto: El impacto establece que tan malo puede ser para una organización que
se concrete la actividad de una amenaza. El impacto se categoriza como se muestra a
continuación:

Cumplimiento: Que la amenaza afecte con el cumplimiento de requerimientos

normativos establecidos en la organización.
Operativo: Que la amenaza pueda afectar la operación de los sistemas de infor-
mación en su confidencialidad, integridad y/o disponibilidad.
Imagen: Que la amenaza afecte la imagen de la organización ante sus clientes,
de tal manera que estos decidan no usar los servicios que ofrece la organización
afectada.
Financiero: Que la amenaza impacte de manera negativa en la salud financiera o
flujo financiero de la organización.

1.2.5. Trazabilidad
En muchas ocasiones, cuando las organizaciones tienen un incidente informático,
éstas quieren obtener respuestas como: ¿Cuándo ocurrió? ¿Quién lo hizo? ¿Por qué lo
hizo? La trazabilidad permite realizar un seguimiento de las acciones realizadas en el
tiempo, entre un origen y destino, por lo que se puede avanzar hacia una investigación
que permitan responder las preguntas planteadas anteriormente.

La manera en que se puede establecer trazabilidad es mediante evidencias. Estas

evidencias son los registros de actividades, también llamados logs.

Logs
La seguridad no sólo radica en la implementación de controles y medidas de pre-
vención, sino también en controles de identificación, en el caso de que un sistema haya
sido comprometido por un intruso.

30
 1.2 Seguridad

Las aplicaciones y sistemas registran eventos y acciones de un determinado perio-

do de tiempo, en un conjunto de archivos llamados logs. Generalmente las actividades
que más se almacenan en este conjunto de archivos, es el registro de los accesos ha-
cia algún sistema, aunque también permiten registrar información sobre quién, qué,
cuándo, dónde y por qué de determinado evento.

Para que los logs puedan considerarse confiables, su integridad debe ser asegurada
de una manera razonable; por lo que sı́ alguien puede escribir y/o borrar eventos de
los logs, se puede decir que no son lo suficientemente confiables como mecanismo de
identificación de actividades anómalas y maliciosas.

Como recomendaciones de las mejores prácticas, los logs deben ser protegidos contra
la manipulación, accesos no autorizados, deben ser cifrados y revisados periódicamente
en busca de identificar alguna actividad sospechosa.

1.2.6. Sistemas de Detección de Intrusos

Para poder entender el concepto de un Sistema de Detección de Intrusos, primero
se debe tener presente la definición de intrusión, la cual se define como el acto de entrar
en algún lugar sin invitación, autorización, derecho o bienvenida.

Un Sistema de Detección de Intrusos es una tecnologı́a que funciona de la misma

manera en que lo hace una alarma antirrobo; el cual se configura para monitorear ac-
tividades sospechosas o accesos no autorizados en un host o a una red. Según la forma
en que reaccionan se les puede clasificar de la siguiente manera:

NIDS
Un Sistema de Detección de Intrusos basado en Red, monitorea el tráfico de toda
una red. Normalmente, la tarjeta de red de una computadora funciona en modo no
promiscuo, lo que significa que en este modo de operación, sólo los paquetes que van
destinados para la dirección MAC de la tarjeta de red del host se analizarán. Sin em-
bargo, para el adecuado y correcto funcionamiento del NIDS, su tarjeta de red debe
operar en modo promiscuo, para que pueda capturar y analizar los paquetes que no
van dirigidos a su dirección MAC.

Ası́, en este modo, el NIDS puede vigilar sigilosamente todas las comunicaciones
del segmento de red. El modo promiscuo es necesario para protección de la red. En la
figura 1.19 se observa la implantación de 3 NIDS en segmentos estratégicos de red, lo
que permite monitorear el tráfico de red para todos los dispositivos de los segmentos.

31
1. CONCEPTOS GENERALES

Figura 1.19: Red usando 3 NIDS implementados en segmentos de red estratégicos.

Fuente: Snort IDS and IPS Toolkit, 2007.

HIDS
Un Sistema de Detección de Intrusos basado en Host, a diferencia del NIDS; sólo
protege el equipo de cómputo en el que reside y su tarjeta de red no opera en modo
promiscuo. Una ventaja del HIDS, a diferencia del NIDS, es que el conjunto de reglas
que son empleadas, se pueden adaptar de acuerdo a las necesidades especı́ficas de la
organización. La reducción en el número de las reglas permite mejorar el desempeño y
reducir una sobrecarga del procesador.

En la figura 1.20 se ilustra la implantación de diferentes Sistemas de Detección de

Intrusos basados en Host, en el segmento de servidores, ası́ como en los equipos finales.

32
 1.2 Seguridad

Figura 1.20: Red usando HIDS en servidores y computadoras especı́ficas. Fuente: Snort
IDS and IPS Toolkit, 2007.

DIDS

En un Sistema de Detección de Intrusos Distribuido, son colocados sensores de de-

tección y reportan a una estación de administración centralizada, en una arquitectura
administración/sondeo. Los logs de ataques son continuamente enviados a la estación
centralizada y pueden ser almacenados en una base de datos central. Otra ventaja,
es que la actualización de reglas para la detección de ataques o tráfico malicioso son
descargadas desde el equipo de administración centralizado, para posteriormente ser
enviadas a los sensores.

En la figura 1.21, se ilustra la implantación de un DIDS.

33
1. CONCEPTOS GENERALES

Figura 1.21: Red monitoreada por 4 sensores y una estación de administración

centralizada. Fuente: Snort IDS and IPS Toolkit, 2007.

IPS
La prevención de intrusos es el siguiente paso en la evolución de la detección de in-
trusos. Un Sistema de Prevención de Intrusos, a diferencia de los tres sistemas descritos
anteriormente, que son pasivos, éstos son reactivos.

Básicamente el concepto de prevención de intrusos es tomar la información reunida

durante la detección de intrusiones y actuar en consecuencia a través de un proceso
automatizado. Mientras un IDS está diseñado para hacer conciencia de ataques po-
tenciales, el IPS tiene un mayor alcance ya que trabaja activamente para prevenir las
intrusiones.

Un IPS actúa de manera similar a un Firewall, pero ofrece muchas ventajas. Puede
ser configurado como un IDS, para responder a los ataques de acuerdo a la última
versión de firmas de reglas vigentes. Por otro lado, actúa más inteligentemente que un

34
 1.2 Seguridad

Firewall, ya que no sólo bloquea la comunicación de una dirección IP especı́fica o un

puerto en especı́fico, sino que tiene la habilidad de rechazar los paquetes que contienen
un ataque y permitir el tráfico normal.

IDS Snort
Snort es un sistema de detección y prevención de intrusos multiplataforma de código
abierto, el cual observa el tráfico de una red privada y detecta anomalı́as, el cual puede
dar indicios sobre algún tipo de comportamiento inusual causado por software malicioso
en la intranet. Para ello, emplea una serie de reglas, que contienen patrones, expresiones
regulares y coincidencias de malware conocido. La figura 1.22 muestra el imagotipo de
Snort.

Figura 1.22: Imagotipo del IDS Snort. Fuente: snort.org.

1.2.7. SandBox
Una SandBox es un mecanismo de seguridad separada de un ambiente de pro-
ducción, para aislar la ejecución de programas que generalmente están infectados o
contienen código malicioso, ejecución de código no probado, usuarios y sitios web que
no son de confianza.

Una SandBox provee un conjunto de recursos controlados para que las pruebas se
ejecuten en los sistemas invitados, como espacio reservado en disco y memoria, acceso
a la red o la habilidad para que puedan inspeccionar el sistema en el que se están eje-
cutando.

Las implementaciones actuales de una SandBox incluyen las siguientes caracterı́sti-

cas:

Restricciones del acceso a la red.

Emulación de una computadora a través de una máquina virtual.

35
1. CONCEPTOS GENERALES

Reglas de ejecución que permite a los administradores tener control total sobre
los procesos que se inician o se están ejecutando.

Cuckoo SandBox
Cuckoo es un sistema de análisis de malware automatizado de código abierto. Se
emplea para ejecutar y analizar archivos, para después obtener resultados completos
del análisis que describen las acciones que realizó el software malicioso, mientras son
ejecutadas en un ambiente seguro y aislado. La siguiente información es la que arroja
el análisis automatizado de Cuckoo SandBox.

Rastros de las llamadas realizadas por todos los procesos generados por el pro-
grama malicioso.

Los archivos que son creados, eliminados y descargados por el malware durante
su ejecución.

Volcados de memoria de los procesos del malware.

Rastros del tráfico de red en formato PCAP.

Capturas de pantallas tomadas durante la ejecución del malware.

Volcados de memoria completos de las máquinas.

Cuckoo SandBox está diseñado para ser usado como una aplicación independiente,
ası́ como para ser integrado en grandes frameworks, gracias a su diseño modular. Puede
ser usado para analizar:

Archivos ejecutables de Windows

Archivos DLL

Documentos PDF

Documentos de Microsoft Office

URLs y archivos HTML

Scripts de PHP

Archivos CPL

Scripts de Visual Basic

Archivos ZIP

Archivos JAR de Java

Scripts de Python

36
 1.2 Seguridad

Cuckoo SandBox comenzó como un proyecto de Google Summer of Code en 2010,

dentro del Proyecto Honeynet. Fue diseñado y desarrollado por Claudio Guarnieri,
quién es el desarrollador principal y coordina todos los esfuerzos de los desarrolladores
y contribuyentes.

Después del trabajo inicial durante verano de 2010, la primera versión beta se
publicó el 5 de febrero de 2011, cuando Cuckoo fue anunciado públicamente y fue dis-
tribuido por primera vez.

En marzo de 2011 Cuckoo fue seleccionado de nuevo como un proyecto apoyado

durante el Google Summer of Code de 2011 con el Proyecto Honeynet, durante el cual
se unió Darı́o Fernández y amplió su funcionamiento.

El 2 de noviembre de 2011 se hace el lanzamiento de la primera versión estable de

Cuckoo, la versión 0.2.

En diciembre de 2011 se liberó Cuckoo v0.3 y a principios de febrero de 2012 surge

la versión 0.3.2.

A finales de enero de 2012 Malwr.com es abierto, la cual es una instancia libre y

pública que corre sobre Cuckoo Sandbox, provista de una interfaz a través de la cual los
usuarios pueden enviar sus archivos para ser analizados y obtener resultados de vuelta.

En marzo de 2012 Cuckoo Sandbox gana la primera ronda en el Magnificent7 orga-

nizado por Rapid7.

El 24 de julio de 2012 la versión 0.4 de Cuckoo Sandbox es liberada.

El 20 de diciembre de 2012 la versión 0.5 “To The End Of The World” se libera.

El 15 de abril de 2013 la versión 0.6 es lanzada, poco tiempo después de haber sido
lanzada la segunda versión de Malwr.com.

El 9 de enero de 2014 la versión 1.0 de Cuckoo es liberada.

En marzo de 2014 nace la fundación Cuckoo, como una organización sin fines de
lucro, dedicada al crecimiento de Cuckoo Sandbox y a proyectos e iniciativas que exis-
tan a su alrededor.

El 7 de abril de 2014 la versión 1.1 de Cuckoo Sandbox es liberada. El 7 de octubre

de este mismo año, la versión 1.1.1 de Cuckoo SandBox es publicada y liberada.

El 5 de marzo de 2015 se publica la versión 1.2 de Cuckoo SandBox.

37
1. CONCEPTOS GENERALES

Durante el verano de 2015 Cuckoo SandBox comenzó el desarrollo de análisis de

malware de Mac OS X como un proyecto de Google Summer of Code como parte del
Proyecto Honeynet.

El 21 de enero de 2016, se libera la versión 2.0 RC1, la cual hasta el momento es la

última versión estable de Cuckoo SandBox.

La figura 1.23 ilustra el imagotipo de Cuckoo SandBox.

Figura 1.23: Imagotipo de Cuckoo SandBox. Fuente: cuckoosandbox.org.

38
 Capı́tulo 2

Implementación del Sistema de

Detección de Intrusos y Cuckoo SandBox

2.1. Instalación del Sistema de Detección de Intrusos (IDS)

y Cuckoo SandBox
La instalación de un IDS, permite a un administrador de red detectar accesos no
autorizados y anomalı́as en el tráfico de la infraestructura de red y activos de una or-
ganización.

Una vez que se detectan estas anomalı́as, el Sistema de Detección Intrusos genera
alertas que informan al administrador de la red de dicho comportamiento inusual. Para
la realización de esta tesis, el tráfico de red que disparó esas alertas, fue capturado y
guardado en un registro (log), para su análisis.

Adicionalmente la SandBox Cuckoo analizó de forma automática, las muestras de

malware recabadas a partir del tráfico de red.

A continuación se establece el diagrama de bloques para el proceso de instalación

y configuración tanto del IDS Snort como de Cuckoo SandBox. Como se aprecia a
continuación en la figura 2.1, el diagrama de bloques para la instalación y configuración
del IDS Snort consta de 10 bloques, en el cual cada uno de ellos especifica el proceso de
instalación, ası́ como la configuración de paquetes y software complementario, para el
óptimo funcionamiento del IDS Snort en la intranet. Esto se explica en la sección 2.1.1.

39
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Figura 2.1: Diagrama de bloques instalación y configuración IDS Snort. Fuente:

Elaboración propia.

Por otro lado, en la figura 2.2, se detalla el diagrama de bloques para indicar la
configuración que se realizó para la instalación de Cuckoo SandBox. Se compone bási-
camente por 5 procesos, los cuales son necesarios seguir, para que pueda realizarse de
manera eficaz y segura el análisis de muestras maliciosas que hayan sido detectadas por
el Sistema de Detección de Intrusos.

El proceso de instalación tanto del software complementario, ası́ como de la propia

SandBox puede consultarse a partir de la sección 2.2.1.

40
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Figura 2.2: Diagrama de bloques instalación y configuración Cuckoo SandBox. Fuente:

Elaboración propia.

2.1.1. Instalación del Sistema de Detección de Intrusos (IDS)

El Sistema de Detección de Intrusos se instaló en un Sistema Operativo Linux, con-
cretamente sobre Ubuntu versión 12.04 Precise Pangolin. La función principal de este
Sistema de Detección de Intrusos es analizar los logs y capturas de datos que fueron
generados por las alertas emitidas por dicho sistema.

Para realizar la instalación, primero se agregó una clave GPG. Para ello, se contó
con los privilegios de administrador y se creó un directorio para concentrar los archivos
descargados con la herramienta wget:

41
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

# mkdir / u s r / I n s t a l a c i o n S n o r t C u c k o o
# cd / u s r / I n s t a l a c i o n S n o r t C u c k o o
# w g e t h t t p : / /www . d o t d e b . o r g / d o t d e b . gpg

Se agregó la clave GPG con el siguiente comando:

# c a t d o t d e b . gpg | apt−k e y add −

Snort depende de algunos paquetes adicionales para su correcta instalación, confi-

guración y funcionamiento. Los paquetes que se instalaron fueron:

apache2 libpcre3 libssl-dev

libapache2-mod- libpcre3-dev gcc-4.4

php5
autoconf g++
libwww-perl
libcrypt-ssleay-perl automake
mysql-server
libmysqlclient-dev gcc
mysql-common php5-gd make
mysql-client php-pear flex
php5-mysql libphp-adodb bison
libnet1 php5-cli apache2-doc

libnet1-dev libtool ca-certificates

Para la descarga e instalación de los paquetes necesarios se empleó el gestor de

paquetes apt y la herramienta wget.
# apt−g e t u p d a t e && apt−g e t i n s t a l l apache2 l i b a p a c h e 2 −mod−php5 libwww−
p e r l mysql−s e r v e r mysql−common mysql−c l i e n t php5−mysql l i b n e t 1 l i b n e t 1
−dev l i b p c r e 3 l i b p c r e 3 −dev a u t o c o n f l i b c r y p t −s s l e a y −p e r l
l i b m y s q l c l i e n t −dev php5−gd php−p e a r l i b p h p −adodb php5− c l i libtool
l i b s s l −dev gcc −4.4 g++ automake g c c make f l e x b i s o n apache2−doc ca−
certificates

Durante el proceso de instalación de MySQL se ingresó un password para el usuario

root, como se muestra a continuación en la figura 2.3:

42
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Figura 2.3: Configuración de contraseña para el usuario root de MySQL. Fuente:

Captura propia.

Cabe mencionar, si ya se dispone de un servidor Apache configurado con MySQL

y PHP, los paquetes correspondientes a dicho software pueden ser omitidos.

Adicionalmente, se instalaron otros paquetes de manera manual que no se encuen-

tran en los repositorios de Ubuntu. Concretamente daq, libpcap y libdnet.

A continuación se descargó el paquete libpcap en el directorio creado anteriormente.

La versión de libpcap que se descargó fue la 1.6.1 :
# cd / u s r / I n s t a l a c i o n S n o r t C u c k o o
# wget h t t p : / /www . tcpdump . o r g / r e l e a s e / l i b p c a p − 1 . 6 . 1 . t a r . g z

Terminada la descarga del archivo, se descomprime y desempaqueta. Hecho lo an-

terior, se cambió la ubicación del directorio actual al directorio libpcap-1.6.1.
# t a r −z x v f l i b p c a p − 1 . 6 . 1 . t a r . g z
# cd l i b p c a p −1.6.1

Dentro del directorio libpcap-1.6.1 se ejecutó el siguiente comando:

# . / c o n f i g u r e −−p r e f i x =/u s r −−e n a b l e −s h a r e d

El argumento –prefix=/usr indica que los archivos de registro (logs) y los directorios
de bases de datos se ubicaron en /usr y no en el directorio /usr/local/var. El segundo
argumento, –enable-shared, generó una biblioteca compartida.

Posteriormente se compiló e instaló el paquete en nuestro sistema.

43
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

# make
# make i n s t a l l

El siguiente paquete que se instaló fue daq. De la misma forma que libpcap, se
descargó el archivo dentro del directorio creado para este fin.
# cd / u s r / I n s t a l a c i o n S n o r t C u c k o o
# w g e t h t t p s : / /www . s n o r t . o r g / downloads / s n o r t / daq − 2 . 0 . 2 . t a r . g z

Se descomprimió y desempaquetó el archivo daq-2.0.2.tar.gz. Realizado lo anterior,

se cambió la ubicación al directorio creado (daq-2.0.2).
# t a r −z x v f daq − 2 . 0 . 2 . t a r . g z
# cd daq −2.0.2

Se ejecutó el siguiente comando.

# ./ configure

Este comando comprueba las caracterı́sticas del sistema que afectan a la compi-
lación y a la vez, configuró la compilación según estos valores para crear el archivo
makefile.

Se compiló e instaló el paquete en nuestro sistema.

# make
# make i n s t a l l

Por otro lado, se actualizó el directorio de librerı́as compartidas de la siguiente

manera:
# echo >> / e t c / l d . so . c o n f / u s r / l i b
# echo >> / e t c / l d . so . c o n f / u s r / l o c a l / l i b && l d c o n f i g

Por último, se instaló el paquete libdnet. La descarga del archivo comprimido se

realizó en el directorio InstalacionSnortCuckoo.
# cd / u s r / I n s t a l a c i o n S n o r t C u c k o o
# w g e t h t t p : / / l i b d n e t . g o o g l e c o d e . com/ f i l e s / l i b d n e t −1.12. t g z

44
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Éste se descomprimió, desempaquetó y se cambió la ubicación al directorio libdnet-

1.12.
# t a r −z x v f l i b d n e t −1.12. t g z
# cd l i b d n e t −1.12

Una vez dentro del directorio libdnet-1.12, se ejecutó el siguiente comando:

# . / c o n f i g u r e −−p r e f i x =/u s r −−e n a b l e −s h a r e d

Se compiló e instaló el paquete.

# make
# make i n s t a l l

A continuación, se instaló la herramienta TCPTrace. TCPTrace es una herramienta

escrita por Shawn Ostermann, la cual permite realizar un análisis más preciso de los
paquetes generados por Snort con formato tcpdump. Entre la información que podemos
obtener con TCPTrace, se encuentran: bytes, segmentos enviados y recibidos, tiempos
de vida, retransmisiones, entre otros. Puede realizar gráficos para su posterior análisis.

Esta herramienta se instaló para habilitar la automatización del proceso de análisis

de una muestra.

Se agregó el siguiente repositorio en el archivo sources.list, el cual se encuentra en

/etc/apt:
deb h t t p : / / us . a r c h i v e . ubuntu . com/ ubuntu p r e c i s e main u n i v e r s e

Los repositorios se actualizaron y mediante el gestor de paquetes apt, se instaló

TCPTrace.
# apt−g e t u p d a t e
# apt−g e t i n s t a l l t c p t r a c e

2.1.2. Instalación de Snort

Posterior a la instalación de los paquetes descritos anteriormente, se realizó la insta-
lación de Snort en su versión 2.9.6.2, siguiendo los pasos que se explican a continuación:

Se descargó el archivo snort-2.9.6.2.tar.gz y el archivo de configuración de Snort,

en el directorio creado anteriormente:

45
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

# cd / u s r / I n s t a l a c i o n S n o r t C u c k o o
# w g e t h t t p : / / l a b s . s n o r t . o r g / s n o r t /2962/ s n o r t . c o n f
# w g e t h t t p : / /www . s n o r t . o r g / downloads / s n o r t / s n o r t − 2 . 9 . 6 . 2 . t a r . g z

Hecho el proceso anterior, se descomprimió el archivo snort-2.9.6.2.tar.gz y se cam-

bió la ubicación al directorio snort-2.9.6.2 como se muestra a continuación:
# t a r −z x v f s n o r t − 2 . 9 . 6 . 2 . t a r . g z
# cd s n o r t − 2 . 9 . 6 . 2

Una vez dentro del directorio, se comprobaron las caracterı́sticas del sistema, previas
a la compilación:
# . / c o n f i g u r e −−e n a b l e −s o u r c e f i r e

Hecho lo anterior, se compiló e instaló Snort en su versión 2.9.6.2.

# make
# make i n s t a l l

A continuación se configuró el servicio para que pueda ser ejecutado fácilmente,

para esto se emplearon los siguientes comandos desde consola.

El primer paso que se realizó, fue crear los siguientes directorios y archivos.
# mkdir / e t c / s n o r t / e t c / s n o r t / r u l e s / v a r / l o g / s n o r t / v a r / l o g / b a r n y a r d 2 / u s r
/ l oc a l / l i b / snort dynamicrules

# touch / etc / snort / r u l e s / w h i t e l i s t . r u l e s / etc / snort / r u l e s / b l a c k l i s t .

rules

Se agregó un nuevo grupo llamado snort y un usuario llamado snort. Este usuario
se agregó al grupo homónimo.
# groupadd s n o r t
# u s e r a d d −g s n o r t s n o r t

Se modificó el usuario y el grupo propietarios (snort, para ambos casos) de los

directorios /var/log/snort y /var/log/barnyard2.

46
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

# chown s n o r t : s n o r t / v a r / l o g / s n o r t / v a r / l o g / b a r n y a r d 2

Una vez realizado el proceso anterior, los archivos con extensión .conf, .config y
.map se copiaron al directorio /etc/snort, ası́ como el archivo snort.conf, mediante los
siguientes comandos.

# cp / u s r / I n s t a l a c i o n S n o r t C u c k o o / s n o r t − 2 . 9 . 6 . 2 / e t c / ∗ . c o n f ∗ / e t c / s n o r t
# cp / u s r / I n s t a l a c i o n S n o r t C u c k o o / s n o r t − 2 . 9 . 6 . 2 / e t c / ∗ . map∗ / e t c / s n o r t
# cp / u s r / I n s t a l a c i o n S n o r t C u c k o o / s n o r t . c o n f / e t c / s n o r t

2.1.3. Configuración de Snort

Para la configuración de Snort, es necesario realizar algunos cambios en el archivo
snort.conf.

A continuación se editaron las variables de configuración de Snort. En la lı́nea 45 se

ingresó el segmento de red que deseamos que Snort esté observando el tráfico. Para este
caso, la red de análisis emplea un segmento 172.16.0.0/12. En la lı́nea 48, se declaró
como red externa, todas las direcciones IP que no se encuentren en el segmento de
monitoreo. Las variables se establecieron de la siguiente manera:

L i n e a 4 5 : i p v a r HOME NET 1 7 2 . 1 6 . 0 . 0 / 1 2
L i n e a 4 8 : i p v a r EXTERNAL NET !$HOME NET

Hecho lo anterior, se modificó la lı́nea 104. En esta lı́nea se especificó el directorio

donde se encuentran ubicados los archivos de las reglas que Snort empleó, para emitir
alertas. Además, se establece la ruta de las reglas de objetos compartidos (lı́nea 105),
el set de reglas del preprocesador (lı́nea 106), ası́ como las reglas de lista blanca y negra
(lı́neas 109 y 110 respectivamente).

L i n e a 1 0 4 : var RULE PATH . / r u l e s

L i n e a 1 0 5 : var SO RULE PATH . / s o r u l e s
L i n e a 1 0 6 : var PREPROC RULE PATH . / p r e p r o c r u l e s
L i n e a 1 0 9 : var WHITE LIST PATH . / r u l e s
L i n e a 1 1 0 : var BLACK LIST PATH . / r u l e s

De la lı́nea 261 a la 265, se omitieron todas las entradas correspondientes a las

variables preprocessor normalize *.

47
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

En la lı́nea 293 después de “decompress depth 65535” se agregó la siguiente expre-

sión:

L i n e a 2 9 3 : max gzip mem 104857600

En la lı́nea 517 se declaró el nombre con el que se almacenaron los logs de Snort, ası́
como el tamaño máximo de cada uno de estos archivos. En este caso, se estableció en
128 Mb. El argumento output unified2, se refiere un formato binario optimizado, para
que las alertas puedan ser insertadas de forma eficiente y rápida en los logs.

L i n e a 5 1 7 : output u n i f i e d 2 : f i l e n a m e s n o r t . l o g , l i m i t 128

En la lı́nea 528 se editó el módulo log tcpdump, que registra los paquetes generados
por las alertas de Snort a un archivo con formato tcpdump. Esto es de suma impor-
tancia, debido a que los archivos con formato tcpdump se emplearon para realizar un
análisis automatizado post-proceso con el tráfico capturado, que se explica en el capı́tulo
4.

L i n e a 5 2 8 : output log tcpdump : / var / l o g / log tcpdump /tcpdump . l o g

Se creó el directorio log tcpdump en el directorio /var/log. Adicionalmente, se mo-

dificó el usuario y el grupo propietarios del directorio.

# mkdir / v a r / l o g / l o g t c p d u m p
# chown −R s n o r t : s n o r t / v a r / l o g / l o g t c p d u m p

A partir de la lı́nea 543 se incluyen los ficheros de reglas para Snort. Para este caso,
en concreto, se comentaron todos los conjuntos de reglas que no sean de utilidad para
la realización de este proyecto. Las reglas que se incluyeron fueron las siguientes:

48
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

i n c l u d e $RULE PATH/ l o c a l . r u l e s
i n c l u d e $RULE PATH/ b l a c k l i s t . r u l e s
i n c l u d e $RULE PATH/ dos . r u l e s
i n c l u d e $RULE PATH/ e x p l o i t −k i t . r u l e s
i n c l u d e $RULE PATH/ i n d i c a t o r −compromise . r u l e s
i n c l u d e $RULE PATH/ i n d i c a t o r −o b f u s c a t i o n . r u l e s
i n c l u d e $RULE PATH/ i n d i c a t o r −s c a n . r u l e s
i n c l u d e $RULE PATH/ i n d i c a t o r −s h e l l c o d e . r u l e s
i n c l u d e $RULE PATH/ malware−backdoor . r u l e s
i n c l u d e $RULE PATH/ malware−cnc . r u l e s
i n c l u d e $RULE PATH/ malware−o t h e r . r u l e s
i n c l u d e $RULE PATH/ malware−t o o l s . r u l e s
i n c l u d e $RULE PATH/ n e t b i o s . r u l e s
i n c l u d e $RULE PATH/ os−windows . r u l e s
i n c l u d e $RULE PATH/ s e r v e r −apache . r u l e s

Para verificar el correcto funcionamiento del IDS Snort, fue necesario crear una regla
de prueba. Para esta verificación, se creó un archivo llamado local.rules de la siguiente
manera:
# cd / e t c / s n o r t / r u l e s
# touch l o c a l . r u l e s

En este fichero se puede escribir un conjunto de reglas que no se encuentren en los

repositorios de las reglas de Snort y que sean realizadas para la captura de tráfico en
especı́fico. Para comprobar el correcto funcionamiento del IDS se agregó la siguiente
alerta:
a l e r t icmp any any −> $HOME NET any ( msg : ” Prueba ICMP” ; s i d : 1 0 0 0 0 0 0 1 ; r e v
:1;)

Se ejecutó Snort en modo consola, y se comprobó que funcionara correctamente.

Para ello se realiza un ping desde otro equipo hacia el IDS:
# s n o r t −A c o n s o l e −q −u s n o r t −g s n o r t −c / e t c / s n o r t / s n o r t . c o n f −i e t h 1

Lo anterior generó el despliegue de una alerta en tiempo real en consola; como se

puede apreciar en la figura 2.4:

49
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Figura 2.4: Ejecución de Snort en modo consola. Fuente: Captura propia.

Nota: Para terminar con el proceso de Snort, basta con presionar ctrl + c.

2.1.4. Instalación de Barnyard

Para instalar Barnyard, se descargó el archivo master.tar.gz en el directorio Insta-
lacionSnortCuckoo.
# w g e t h t t p s : / / g i t h u b . com/ f i r n s y / b a r n y a r d 2 / a r c h i v e / master . t a r . g z

Se descomprimió el archivo y se ingresó al directorio creado:

# t a r −z x v f master . t a r . g z
# cd barnyard2−master

Fueron actualizados los scripts de configuración:

# a u t o r e c o n f − f v i −I . /m4

Se verificaron las caracterı́sticas del sistema antes de compilar e instalar.

# . / c o n f i g u r e −−w it h −mysql −−w it h −mysql−l i b r a r i e s =/u s r / l i b / i386 −l i n u x −gnu

Finalmente se compiló e instaló barnyard en el sistema.

# make
# make i n s t a l l

Se movió el archivo barnyard2.conf al directorio /etc/snort.

# mv / u s r / l o c a l / e t c / b a r n y a r d 2 . c o n f / e t c / s n o r t

50
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Se editó el archivo barnyard2.conf para el correcto funcionamiento de Barnyard.

La l i n e a 227 f u e s u s t i t u i d a :
output a l e r t f a s t : s t d o u t

por :
output a l e r t f a s t

Adicionalmente, al final del archivo, se declaró la siguiente lı́nea. Esta instrucción

permite almacenar los eventos generados por Snort en una base de datos, en este caso
en MySQL:

output d a t a b a s e : l o g , mysql , u s e r=s n o r t password=<Password u s u a r i o s n o r t >

dbname=s n o r t h o s t=l o c a l h o s t

2.1.5. Configuración de MySQL

En esta sección se explica el proceso de configuración de la base de datos que usa
Snort, para registrar las alertas, y que la aplicación B.A.S.E. utiliza para aprovechar
un mayor rendimiento de Snort.

Se ingresó a MySQL con la contraseña del usuario root que se configuró anterior-
mente:

# mysql −u r o o t −p
Enter password : <Password u s u a r i o r o o t de MySQL>

Una vez que se ingresó como usuario root al manejador de bases de datos MySQL,
se creó la base de datos snort. También se debió establecer una contraseña para el
usuario snort en MySQL. Por otro lado, fueron proporcionados privilegios sobre la base
de datos para el usuario snort creado en Linux.

mysql> create d a t a b a s e s n o r t ;
mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on s n o r t . ∗ t o
snort@localhost ;
mysql> SET PASSWORD FOR s n o r t @ l o c a l h o s t=PASSWORD( ’ password u s u a r i o s n o r t ’ )
;

Una vez que se configuró la base de datos, se crearon las tablas, mediante las

51
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

cuales, Snort administra las alertas. Para la creación de dichas tablas se usó el esquema
existente en Barnyard2. El nombre de la base de datos es “snort”.

mysql> s o u r c e / u s r / I n s t a l a c i o n S n o r t C u c k o o / barnyard2−master / schemas /

create mysql

Se comprobó la creación de las tablas. Para ello, se ingresó a MySQL como usuario
root seleccionando la base de datos snort y se realizó un despliegue de las tablas que
contiene dicha base de datos.

mysql> u s e s n o r t ;
mysql> show t a b l e s ;

En la figura 2.5 se pueden observar las tablas que contiene la base de datos snort.

Figura 2.5: Tablas que contiene la base de datos snort. Fuente: Captura propia.

2.1.6. Configuración del servidor apache

En esta sección se explicará cómo configurar el servidor Apache con PHP, para la
visualización de las alertas vı́a web.

Para ello, en el archivo /etc/php5/apache2/php.ini se editaron los siguientes paráme-

tros:

52
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Se modificó la variable error reporting (lı́nea 521) con el siguiente valor: error reporting
= E ALL & E NOTICE.

Se copió el archivo default-ssl en el directorio sites-enabled. Y se activó el módulo

ssl.

# cp / e t c / apache2 / s i t e s −a v a i l a b l e / d e f a u l t −s s l / e t c / apache2 / s i t e s −e n a b l e d
# a2enmod s s l

Adicionalmente, se realizaron algunas configuraciones e instalaron algunos paquetes

mediante el framework Pear. Esto garantiza el correcto despliegue de datos numéricos,
gráficos y datos en la aplicación B.A.S.E. Se reinició el servidor apache para activar la
nueva configuración.

# p e a r c o n f i g −s e t p r e f e r r e d s t a t e a l p h a
# p e a r ch a nn e l −u p d a t e p e a r . php . n e t
# p e a r i n s t a l l − a l l d e p s I m a g e C o l o r 2 Image Canvas Image Graph
# / e t c / i n i t . d/ apache2 r e s t a r t

2.1.7. Instalación de B.A.S.E.

En este apartado se explicará cómo instalar B.A.S.E. versión 1.4.5, para que fun-
cione en conjunto con Snort. Recordar que antes de descargar cada archivo, se usó el
directorio creado para tener una instalación óptima y limpia.

Se descargó el archivo base-1.4.5.tar.gz de la siguiente url.

# wget h t t p : / / s o u r c e f o r g e . n e t / p r o j e c t s / s e c u r e i d e a s / f i l e s /BASE/ base −1.4.5/

base − 1 . 4 . 5 . t a r . g z

Como se hizo con los archivos anteriores, se descomprimió y desempaquetó.

# t a r −z x v f base − 1 . 4 . 5 . t a r . g z

Finalmente se copió el directorio base-1.4.5 a /var/www. Una vez que se copió el ar-
chivo, se asignaron permisos de lectura, escritura y ejecución. Se modificó el nombre
del directorio base-1.4.5 a base. Realizados los pasos anteriores, se concluyó con la
instalación de B.A.S.E.

53
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

# cp −r base −1.4.5 / v a r /www

# chmod 777 / v a r /www/ base −1.4.5
# cd / v a r /www
# mv base −1.4.5 b a s e

2.1.8. Configuración de B.A.S.E.

A continuación, se explicará la configuración de B.A.S.E.

Se modificó el archivo default, ubicado en /etc/apache2/sites-available. La modifi-

cación se realizó para que cuando se desee ejecutar B.A.S.E., únicamente se escriba la
dirección IP del servidor. Para ello, en la lı́nea 4 del archivo anterior, se modificó la
siguiente lı́nea: DocumentRoot /var/www/base.

Se guardaron los cambios del archivo y se reinició nuevamente el servidor Apache.

B.A.S.E. se configuró desde un navegador web. En el navegador web se ingresó

la dirección IP de nuestro servidor. Al ingresar mostró la siguiente pantalla, como se
observa en la figura 2.6. Lo importante de esta primera pantalla, es la opción Config
Writeable, ya que debe aparecer Yes. Si aparece No, se deberán de asignar los permisos
correspondientes al directorio base ubicado en /var/www.

Figura 2.6: Pantalla de inicio de configuración de B.A.S.E. Fuente: Captura propia.

En la siguiente ventana, se eligió el idioma y la ruta de adodb, como se muestra en

la figura 2.7.

54
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Figura 2.7: Selección del idioma del usuario y la ruta de adodb. Fuente: Captura propia.

A continuación, como se observa en la figura 2.8, se realizaron las configuraciones

para la conexión con la base de datos MySQL.

Figura 2.8: Configuración de parámetros para realizar la conexión con la base de datos
snort. Fuente: Captura propia.

Se generó una cuenta de administrador para B.A.S.E. Es importante seleccionar

la casilla que se encuentra arriba del formulario, para que cada vez que se ingrese a
B.A.S.E. solicite credenciales de autenticación. La figura 2.9 ilustra este proceso.

55
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Figura 2.9: Definición de los parámetros de autenticación del sistema B.A.S.E. Fuente:
Captura propia.

Como se muestra en la figura 2.10, se agregaron tablas a la base de datos de Snort,

para extender el soporte y las funcionalidades de Snort junto a B.A.S.E. Se dio clic en
Create BASE AG.

Figura 2.10: Creación de las tablas de B.A.S.E. en la Base de Datos snort. Fuente:
Captura propia.

Posteriormente, un mensaje confirma que se crearon correctamente las tablas. Al

dar clic en continuar con el paso 5 se debe realizar el proceso de autenticación para
ingresar a la aplicación. Una vez finalizados los pasos anteriores se encuentra B.A.S.E.
configurado y listo para su ejecución con todas las dependencias necesarias. Ver figura
2.11.

56
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Figura 2.11: Acceso a B.A.S.E. Fuente: Captura propia.

2.1.9. Instalación y actualización de reglas en Snort

En esta sección se expondrán los diferentes conjuntos de reglas que se emplearon
para garantizar el correcto desempeño de Snort, una vez puesto en producción.

El primer conjunto de reglas que podremos agregar son las reglas locales. Las reglas
locales, son las reglas creadas por el usuario, inicialmente para verificar el correcto
funcionamiento de Snort, y posteriormente para encontrar patrones en especı́fico que el
usuario desee capturar. Estas reglas se deben colocar en el archivo local.rules, ubicado
en /etc/snort/rules. Algunos ejemplos de reglas son:

a l e r t icmp any any −> $HOME\ NET any ( msg : ” Prueba ICMP” ; s i d : 1 0 0 0 0 0 1 ; r e v
:1)
a l e r t t c p any any −> $HOME\ NET 22 ( msg : ” Conexion SSH por e l p u e r t o 22 ” ;
c l a s s t y p e : s u s p i c i o u s −login ; s i d : 1 0 0 0 0 0 8 ; )
a l e r t t c p any any −> $HOME\ NET 23 ( msg : ” Conexion TELNET por e l p u e r t o 23 ”
; sid :1000503;)

Otra manera de maximizar la funcionalidad de Snort, fue descargar las reglas crea-
das por la comunidad de Snort. Este conjunto contiene alrededor de 20000 reglas de
diferentes categorı́as.

Para poder descargar dichas reglas, se ingresó al siguiente enlace

https://www.snort.org/downloads en el cual tenemos dos opciones de descarga de re-
glas. En la primera opción deberemos de registrarnos en el sistema de Snort, además
de pagar una suscripción por $29.99 dólares al mes. La ventaja de esta opción es tener
acceso inmediato a las actualizaciones más recientes de las reglas de Snort.

Para los que no opten por la opción anterior, existe una segunda alternativa en la

57
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

cual, simplemente debemos de registrar un correo válido en la plataforma de Snort.

La desventaja de este conjunto de reglas, es el desfase de un mes respecto a las que
publican mensualmente y qué tienen un costo. En este caso, se empleó el kit de reglas
de la versión 2.9.

A continuación se descargó el kit de reglas de Snort versión 2.9. Para poder realizar
la descarga, se debe contar con un previo registro. Recordar que una vez que se realizó
la descarga del kit de reglas, se ubicaron en el directorio creado anteriormente, para
almacenar todas las descargas que hayamos realizado.

Una vez descargado el archivo, se obtuvo el fichero snortrules-snapshot-2962, como

se muestra a continuación:

# t a r −z x v f s n o r t r u l e s −s n a p s h o t −2962. t a r . g z

Se copió el contenido de los siguientes directorios: preproc rules, rules y so rules a

la ubicación donde se crearon dichos directorios, cuando se instaló Snort.

# cp p r e p r o c r u l e s /∗ / e t c / s n o r t / p r e p r o c r u l e s /
# cp r u l e s /∗ / e t c / s n o r t / r u l e s /
# cp s o r u l e s /∗ / e t c / s n o r t / s o r u l e s /

Se cambió el usuario y grupo propietario a dichos directorios.

# chown −R s n o r t : s n o r t / e t c / s n o r t

Es importante mantener el kit de reglas actualizado, ya que con cierta frecuencia

aparece nuevo software malicioso, que son más sofisticados y qué por ende son desco-
nocidos para el Sistema de Detección de Intrusos.

Para mantener actualizado el conjunto de reglas de Snort, se empleó la herramienta

PulledPork. PulledPork es un script escrito en Perl, el cual realizará las actualizaciones
con el mı́nimo esfuerzo. Se instalaron los siguientes paquetes y se descargó la última
versión de PulledPork en el directorio InstalacionSnortCuckoo.

# apt−g e t i n s t a l l l i b c r y p t −s s l e a y −p e r l l i b l w p −u s e r a g e n t −determined −p e r l −y
# w g e t h t t p s : / / p u l l e d p o r k . g o o g l e c o d e . com/ f i l e s / p u l l e d p o r k − 0 . 7 . 0 . t a r . g z

Se descomprimió y desempaquetó el archivo pulledpork-0.7.0.tar.gz. Se cambió el

nombre del directorio creado (pulledpork-0.7.0) a PulledPork, para mayor facilidad de
uso.

58
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

# t a r −z x v f p u l l e d p o r k − 0 . 7 . 0 . t a r . g z
# mv p u l l e d p o r k −0.7.0 p u l l e d p o r k

Antes de proseguir fue necesario conseguir un código Oinkcode, que fungió como
llave privada, para realizar la actualización de las reglas. Se inició sesión con el usuario
qué se creó para descargar el kit de reglas. Posteriormente, se dió clic sobre el nombre
de usuario de Snort, como se muestra en la figura 2.12.

Figura 2.12: Login en la página de Snort. Fuente: snort.org.

A continuación, el usuario se debe dirigir a su perfil. En la sección Oinkcode, se

busca el código. La figura 2.13 muestra este proceso:

59
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Figura 2.13: Oinkcode proporcionado en la página de Snort. Fuente: snort.org.

Realizado el proceso anterior, se modificó el archivo de configuración de PulledPork

(/usr/src/pulledpork/etc/pulledpork.conf ) y en la lı́nea 19 se escribe la URL de donde
son descargadas las reglas incluyendo el Oinkcode. Adicionalmente las lı́neas 21, 24 y
26 se comentaron.

r u l e u r l=h t t p s : / /www. s n o r t . o r g / r u l e s /| < v e r s i o n r e g l a s . t a r . gz >|<o i n k c o d e >

Las lı́nea 72, 87, 90, 117, 131 se editaron de la siguiente manera respectivamente:

r u l e path=/ e t c / s n o r t / r u l e s / s n o r t . r u l e s
l o c a l r u l e s =/ e t c / s n o r t / r u l e s / l o c a l . r u l e s
s i d m s g=/ e t c / s n o r t / s i d −msg . map
c o n f i g p a t h =/ e t c / s n o r t / s n o r t . c o n f
d i s t r o=Ubuntu −12.04

Se guardaron los cambios realizados en el archivo y se creó el archivo snort.rules.

# touch / etc / snort / r u l e s / snort . r u l e s

Se cambiaron los permisos al archive pulledpork.pl.

# chmod 755 / u s r / I n s t a l a c i o n S n o r t C u c k o o / p u l l e d p o r k / p u l l e d p o r k . p l

60
 2.1 Instalación del Sistema de Detección de Intrusos (IDS) y Cuckoo SandBox

Finalmente, para actualizar el kit de reglas de Snort se ejecutó el siguiente co-

mando que se puede observar en la figura 2.14, indicando la ubicación del archivo de
configuración de PulledPork.

Figura 2.14: Actualización completa del kit de reglas de Snort con PulledPork. Fuente:
Captura propia.

61
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

2.2. Instalación de Cuckoo SandBox

La SandBox Cuckoo permitió realizar análisis de malware de manera eficiente. Esto
se logró gracias al informe que se generó después de realizar un análisis en un entorno
aislado y seguro. Las muestras de malware que obtuvo la SandBox, fueron capturadas
por el IDS, al generarse una alerta. Este proceso de automatización se explica en el
capı́tulo 4 de esta tesis.

2.2.1. Instalación de paquetes

En esta sección se explicará la instalación de los paquetes necesarios para el correcto
funcionamiento de la SandBox.

Primero, se garantizó que el sistema tuviera instalado Python. En caso de no contar

con Python se debe instalar. Para ello se emplea el gestor de paquetes apt.

# apt−g e t i n s t a l l p y t h o n

Cuckoo requiere de los paquetes SQLAlchemy y Python BSON. Para la instalación

del paquete sqlalchemy se realizó de la siguiente manera:

# apt−g e t i n s t a l l python−s q l a l c h e m y

Para instalar el paquete python-bson, se realizó con el gestor de paquetes apt de

Linux.

# apt−g e t i n s t a l l python−bson

A continuación se instalaron diversos paquetes Python, ası́ como el paquete build-

essential. Dicho paquete contiene las herramientas necesarias para crear, compilar e
instalar programas.

# apt−g e t i n s t a l l python−p i p python−dev b u i l d −e s s e n t i a l

# apt−g e t i n s t a l l python−d p k t python−j i n j a 2 python−magic python−pymongo
python−g r i d f s python− l i b v i r t python−b o t t l e python−p e f i l e python−
chardet

También, se realizó la instalación de paqueterı́as que son opcionales y que por ende,
no son estrictamente requeridas, pero se aconseja instalarlas.

62
 2.2 Instalación de Cuckoo SandBox

Se instaló el paquete Django, para el uso de la interfaz web. Se realizó con la

herramienta pip, la cual sirve para instalar y administrar paquetes Python:

# p i p i n s t a l l Django ==1.7.1

A continuación, se instaló el paquete Ssdeep. Dicho paquete permite saber que tan
similares son dos o más archivos, mediante la técnica de fuzzy hashing. Se descomprimió
con la herramienta tar :

# wget h t t p : / / s o u r c e f o r g e . n e t / p r o j e c t s / s s d e e p / f i l e s / s s d e e p −2.10/ s s d e e p
−2.10. t a r . g z
# t a r −z x v f s s d e e p −2.10. t a r . g z

Se cambió al directorio creado, se comprobaron las caracterı́sticas del sistema y se

compiló e instaló:

# cd s s d e e p −2.10
# ./ configure
# make
# make c h e c k
# make i n s t a l l

Pydeep es el siguiente paquete que se instaló. El paquete Ssdeep debe estar instalado
para poder usar Pydeep.

Se cambió la ubicación al directorio InstalacionSnortCuckoo, y desde ahı́ se realizó

la descarga. Se descomprimió con la herramienta unzip y se cambió al directorio creado.
Se compiló e instaló el paquete con Python.

# wget h t t p s : / / g i t h u b . com/ k b a n d l a / pydeep / a r c h i v e / master . z i p

# u n z i p master . z i p
# cd pydeep−master
# p y t h o n s e t u p . py b u i l d
# p y t h o n s e t u p . py i n s t a l l

Para la instalación de Yara se requieren los siguientes paquetes: libpcre3 y libpcre3-

dev.

# apt−g e t i n s t a l l l i b p c r e 3 l i b p c r e 3 −dev

63
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Posterior a la instalación de los paquetes mencionados anteriormente, se descargó e

instaló el paquete Yara, la cual es una herramienta que sirve para identificar y clasificar
muestras de malware. El archivo Yara se descomprimió y se cambió al directorio yara-
3.1.0 para comprobar las caracterı́sticas del sistema para su compilación e instalación.
# w g e t h t t p s : / / g i t h u b . com/ p l u s v i c / yara / a r c h i v e / v3 . 1 . 0 . t a r . g z
# t a r −z x v f v3 . 1 . 0 . t a r . g z
# cd yara −3.1.0
# . / b o o t s t r a p . sh
# ./ configure
# make
# make c h e c k
# make i n s t a l l

Para construir e instalar el paquete yara-python se realiza mediante el siguiente

proceso:
# cd / u s r / I n s t a l a c i o n S n o r t C u c k o o / yara −3.1.0/ yara−p y t h o n
# p y t h o n s e t u p . py b u i l d
# p y t h o n s e t u p . py i n s t a l l

También se realizó la instalación de Distorm. Se descargó de la siguiente manera:

# w g e t f t p : / / f t p . cn . d e b i a n . o r g / g e n t o o / d i s t f i l e s / d i s t o r m 3 − 1 . 0 . z i p
# u n z i p d i s t o r m 3 − 1 . 0. z i p && cd d i s t o r m 3 −1.0
# cd d i s t o r m 3 −1.0

Se compiló e instaló con Python.

# p y t h o n s e t u p . py b u i l d
# p y t h o n s e t u p . py i n s t a l l

Otro paquete que se instaló fue Pycrypto. Se descargó con la herramienta wget. Se
procedió a descomprimirlo y se cambió al directorio pycrypto-2.6.1.
# w g e t h t t p : / / f t p . d l i t z . n e t / pub / d l i t z / c r y p t o / p y c r y p t o / p y c r y p t o − 2 . 6 . 1 . t a r .
gz
# t a r −x v z f p y c r y p t o − 2 . 6 . 1 . t a r . g z
# cd p y c r y p t o −2.6.1/

64
 2.2 Instalación de Cuckoo SandBox

De la misma forma en qué se compiló e instaló Distorm, se realizó con Pycrypto.

# p y t h o n s e t u p . py b u i l d
# p y t h o n s e t u p . py i n s t a l l

El siguiente paquete que se instaló fue volatility. Se descargó el archivo comprimido

de volatility y se desempaquetó y descomprimió. Hecho lo anterior, se compiló e instaló
con Python.

# wget h t t p s : / / v o l a t i l i t y . g o o g l e c o d e . com/ f i l e s / v o l a t i l i t y − 2 . 3 . 1 . t a r . g z
# tar x v z f v o l a t i l i t y −2.3.1. tar . gz
# cd v o l a t i l i t y −2.3.1
# p y t h o n s e t u p . py b u i l d
# p y t h o n s e t u p . py i n s t a l l

Finalmente, se instaló TCPdump, el cual es un analizador de paquetes que circulan

a través de una red. Dicha herramienta requiere de privilegios de administrador. Pero
cómo no es recomendable ejecutar Cuckoo como administrador, es necesario especificar
en los binarios de Linux dicho requerimiento. Para ello se descargó la librerı́a libcap2-
bin, la cual proporciona la herramienta setcap, requerida para aplicar privilegios de
administrador a Cuckoo.

# apt−g e t i n s t a l l tcpdump
# apt−g e t i n s t a l l l i b c a p 2 −b i n

Se configuraron las capacidades del sistema:

# s e t c a p c a p n e t r a w , c a p n e t a d m i n=e i p / u s r / s b i n / tcpdump

Finalmente se verificaron los resultados con el siguiente comando:

# g e t c a p / u s r / s b i n / tcpdump

El resultado del comando anterior mostró lo siguiente, lo cual establece que ha

surtido efecto el cambio realizado anteriormente:

/ u s r / s b i n /tcpdump = c ap n et a dm in , c a p n e t r a w+e i p

65
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

2.2.2. Configuración de la Base de Datos

En esta sección se explicará la configuración de la Base de Datos para que se pue-
dan almacenar los análisis que vaya generando la SandBox, y que posteriormente se
utilizaron para estudiar el comportamiento de dichas muestras.

El paquete python-mysqldb se instaló, el cual se define como una interfaz que permite
trabajar con bases de datos MySQL desde Python. A continuación, se ingresó a MySQL
como usuario root.

# apt−g e t i n s t a l l python−m y s q l d b −y
# mysql −u r o o t −p

Posteriormente se creó la base de datos cuckoo y se proporcionaron todos los privile-

gios sobre la base de datos cuckoo para el usuario Snort y se recargaron todas las tablas
manualmente. La conexión a la base de datos se establece en el archivo de configuración
cuckoo.conf, que se encuentra en el apéndice A.

mysql> c r e a t e d a t a b a s e cuckoo ;
mysql> g r a n t a l l p r i v i l e g e s on cuckoo . ∗ t o s n o r t @ l o c a l h o s t i d e n t i f i e d by ’
cuckoo ’ ;
mysql> f l u s h p r i v i l e g e s ;
mysql> q u i t ;

2.2.3. Instalación de VirtualBox

Una vez que se contó con todas las librerı́as anteriores en el servidor, se instaló
VirtualBox. En VirtualBox se creó el sistema invitado, en dónde se ejecutó malware de
manera segura. Se descargó VirtualBox versión 4.3.14 desde el siguiente enlace, en el
directorio creado para el concentrado de todos los archivos descargados:

# w g e t h t t p : / / download . v i r t u a l b o x . o r g / v i r t u a l b o x / 4 . 3 . 2 0 / v i r t u a l b o x −4.3 4
.3.20 −96996˜ Ubuntu ˜ p r e c i s e i 3 8 6 . deb

A continuación se empleó la herramienta dpkg, la cual permite instalar, compilar o

eliminar un paquete Debian. En este caso se utilizó la instalación de VirtualBox.

# dpkg −i v i r t u a l b o x −4.3 4 .3.20 −96996˜ Ubuntu ˜ p r e c i s e i 3 8 6 . deb

Sı́ al momento de realizar la instalación, es mostrado un mensaje diciendo que Vir-

66
 2.2 Instalación de Cuckoo SandBox

tualBox depende de paquetes adicionales, se puede solucionar el problema ejecutando

el siguiente comando:

# apt−g e t −f i n s t a l l

Después de ejecutar el comando anterior, automáticamente se instalaron los paque-

tes que hacı́an falta para poder realizar la instalación de VirtualBox. Nuevamente se
ejecutó la herramienta dpkg y esta vez se instaló VirtualBox correctamente.

2.2.4. Instalación y preparación de la máquina huésped

A continuación se explicará la correcta instalación y configuración del sistema
huésped, el cual realizó el análisis de las muestras de malware. Es importante con-
tar con un disco imagen de Windows XP Service Pack 3 de 32 bits.

Inicialmente se ejecuta VirtualBox. Una vez inicializado, se creó una nueva máquina
virtual. Se le asignó el nombre de ‘cuckoo1’. El Tipo: ‘Microsoft Windows’ y la versión
‘Windows XP (32 bits)’. Seleccionada la versión del sistema operativo, ası́ como sus
caracterı́sticas, se continuó con la siguiente ventana de configuración.

En esta ventana, se estableció el tamaño de la memoria RAM, que fue de 1024 MB,
ya que es la cantidad sugerida en la documentación oficial de Cuckoo. Prosiguiendo con
la configuración de la máquina huésped, se creó un disco duro virtual. En la siguiente
ventana, se determinó un tamaño fijo para el archivo del disco duro virtual, ya que éste
fue creado con su máximo tamaño y no permite expandir su tamaño.

En la siguiente ventana, se eligió el nombre del archivo del disco duro virtual. Nue-
vamente ingresamos ‘cuckoo1’. En la parte de abajo se indicó el tamaño del disco duro
virtual, el cual se fijó en 10 GB, debido a que es el tamaño que recomienda la guı́a de
instalación de VirtualBox.

Nota: El proceso de la creación del disco duro virtual dependerá de las caracterı́sti-
cas de la máquina anfitrión.

Una vez que se encendió por primera vez la máquina huésped, se especificó la ruta
en donde se encuentra la imagen de nuestro sistema operativo. Una vez seleccionado el
archivo .iso, se continuó con una instalación tı́pica de un sistema Windows XP.

Finalizado el proceso de instalación de la máquina huésped, se realizaron algunas

adecuaciones en la máquina virtual, para que pudiera realizar el análisis de malware
con el mejor desempeño posible.

67
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Inicialmente, se ajustó el rendimiento de la máquina virtual huésped. Para ello, se

ubicaron las ‘Propiedades de mi PC’ y se eligió la pestaña de ‘Opciones Avanzadas’. Se
seleccionó la sección qué se llama ‘Rendimiento’ y se accedió sobre el botón que dice
‘Configuración’.

Se desplegó una nueva ventana con las opciones de rendimiento qué se requirieron
configurar. En este caso, se adaptó el rendimiento de efectos visuales, seleccionando la
opción ‘Ajustar para obtener el mejor rendimiento’.

Posteriormente se realizó la configuración de alertas en el Centro de Seguridad de

Windows XP. Para acceder al centro de Seguridad en Windows XP, se pulsó la tecla de
Inicio de Windows e ingresar al Panel de Control. Una vez dentro del Panel de Control,
se dio clic sobre “Centro de Seguridad” y a continuación se abrió la ventana del Centro
de Seguridad.

Ahı́, del lado derecho, se ubicó la sección “Recursos” y se seleccionó al quinto y

última opción de configuración “Cambiar la forma en que el Centro de seguridad me
alerta”. Esta acción hizo que se desplegara una nueva ventana, en la cual se desmarca-
ron las tres casillas de verificación, las cuales corresponden al Firewall, actualizaciones
automáticas y protección antivirus. La ventana de configuración de alertas puede ob-
servarse a continuación en la figura 2.15.

68
 2.2 Instalación de Cuckoo SandBox

Figura 2.15: Configuración de alertas en el sistema huésped. Fuente: Captura propia.

Posteriormente los servicios de actualizaciones automáticas y el Firewall de Win-

dows fueron deshabilitados. Se abrió una ventana de Ejecutar (tecla Windows + R) y
se escribió services.msc la cual mostró todos los servicios locales.

En el servicio “Actualizaciones automáticas”, se dio clic derecho sobre dicho servicio

y se seleccionó ‘propiedades’. Desplegó una ventana nueva y en la pestaña ‘General’, se
detuvo el servicio. En el apartado “Tipo de inicio”, se seleccionó Deshabilitado. Se hizo
exactamente lo mismo con el servicio de “Firewall de Windows/Conexión compartida
a Internet (ICS)”.

La siguiente configuración que se realizó, fue deshabilitar el protector de pantalla

y no seleccionar ningún fondo de pantalla. Esto se realizó dando clic derecho sobre
cualquier parte de la pantalla, seleccionando la pestaña de pantalla. Las configuracio-
nes anteriores se realizaron en las pestañas de “Protector de Pantalla” y “Escritorio”
respectivamente.

A continuación Python tuvo que ser instalado, debido a que es un requerimiento

69
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

estricto para el sistema huésped Cuckoo, para que pueda ejecutarse adecuadamen-
te el análisis de muestras de malware. Python se descargó desde su sitio web oficial
https://www.python.org/downloads/. Se recomienda la versión 2.7 de Python. Adicio-
nalmente se instaló la librerı́a Python Image, la cual es usada para obtener capturas
de pantallas, mientras se realiza un análisis de malware. También se instaló software
adicional, para que las muestras pudieran tener interacción con aplicaciones. Para ello
se obtuvo Adobe Reader v6.0, Java 1.5.0.12, Office 2003 y Mozilla Firefox 1.0 desde el
siguiente enlace: http://www.oldapps.com/.

El siguiente software que se instaló, fue un agente (Agent.py), que se ejecuta dentro
del huésped; el cual es el responsable de la comunicación y transferencia de datos con el
sistema anfitrión (Ubuntu 12.04). Dicho agente se encuentra en la ruta /opt/cuckoo/a-
gent. Una vez que se encontró, se copió en C:\Python27.

Cuando se ejecutó el agente en Windows con la extensión .py, abrió una ventana
de Python. Para evitar que dicha ventana sea mostrada y el agente se ejecute en back-
ground, basta con cambiar la extensión del archivo Agent.py por Agent.pyw.

El siguiente paso fue añadir un nuevo valor alfanumérico en el Editor del Registro.
Para ingresar al Editor del Registro de Windows, nuevamente se debe presionar la
combinación de teclas Windows + R y escribir la palabra regedit. Para agregar el nuevo
valor alfanumérico, debe realizarse en la siguiente ruta:

HKEY LOCAL MACHINE\ S o f t w a r e \ M i c r o s o f t \Windows\ C u r r e n t V e r s i o n \Run

Ubicada la carpeta ‘Run’, se dio clic derecho y desplegó un pequeño menú; don-
de se seleccionó un ‘Nuevo Valor Alfanumérico’. Una vez que se creó, se modificó su
nombre, y se llamó ‘Agent’. Del lado derecho, donde se encuentran todos los valores
alfanuméricos de la carpeta ‘Run’, se modificó el valor que se creó. La información
del valor será: “C:\Python27\agent.pyw”. Este valor se debe agregar, para cuando es
encendido el sistema huésped, automáticamente el agente de Python se ejecute, el cual
abre el puerto 8000.

Se ejecutó el agente de Python y se verificó que el puerto 8000 esté a la escucha por
cualquier dirección IP. Este proceso se ilustra a continuación, en la figura 2.16.

70
 2.2 Instalación de Cuckoo SandBox

Figura 2.16: El agente Python escucha por el puerto 8000. Fuente: Captura propia.

Una vez que se comprobó el estado del puerto, se realizó una captura instantánea al
sistema invitado. Esta acción se realizó por lı́nea de comandos desde el sistema anfitrión
ejecutando los siguientes comandos:

# VBoxManage s n a p s h o t ” cuckoo1 ” t a k e ” cuckoo ” −−pause

# VBoxManage c o n t r o l v m ” cuckoo1 ” p o w e r o f f
# VBoxManage s n a p s h o t ” cuckoo1 ” r e s t o r e c u r r e n t

Terminado el proceso anterior, se configuró una interfaz virtual, la cual comunica al

sistema anfitrión con el sistema invitado, permitiendo enviar las muestras de malware
recolectadas para su análisis.

Cuando se terminó de guardar la captura instantánea del equipo, en la pestaña

Archivo de VirtualBox se seleccionó la opción ‘Preferencias’. Se desplegó una nueva
ventana y se seleccionó la opción ‘Red’. Se seleccionó la pestaña “Redes solo-anfitrión”,
como se muestra en la figura 2.17, y del lado derecho y se seleccionó el ı́cono verde. La
función de este ı́cono verde es crear la interfaz virtual ‘vboxnet0’.

71
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Figura 2.17: Creación de la interfaz virtual vboxnet0 en VirtualBox. Fuente: Captura

propia.

Finalmente se configuró una dirección IP y una máscara de red al sistema invitado.

La dirección IP es ‘192.168.56.1’ y la máscara ‘255.255.255.0’.

Ahora en el sistema anfitrión, se modificó el firewall de Linux y se habilitó el acceso

a internet para la máquina huésped, utilizando las siguientes reglas de iptables:

# i p t a b l e s −A FORWARD −o e t h 1 −i v b o x n e t 0 −s 1 9 2 . 1 6 8 . 5 6 . 0 / 2 4 −m c o n n t r a c k
−− c t s t a t e NEW −j ACCEPT
# i p t a b l e s −A FORWARD −m c o n n t r a c k −− c t s t a t e ESTABLISHED,RELATED −j ACCEPT
# i p t a b l e s −A POSTROUTING −t n a t −j MASQUERADE
# s y s c t l −w n e t . i p v 4 . i p f o r w a r d =1

72
 2.2 Instalación de Cuckoo SandBox

2.2.5. Instalación de la SandBox Cuckoo

Para la correcta instalación de Cuckoo, se empleó la herramienta wget. El archivo
cuckoo 1.1.tar.gz se descargó en el directorio opt.

# cd / o p t
# wget h t t p : / / downloads . c u c k o o s a n d b o x . o r g / 1 . 1 / c u c k o o 1 . 1 . t a r . g z

Una vez que se descargó Cuckoo, el archivo fue desempaquetado y descomprimido.

Esto generó un directorio llamado Cuckoo.

Para activar la Sandbox y validar su correcto funcionamiento se siguió la ruta

/opt/cuckoo. Desde ahı́ se activó la SandBox Cuckoo. Este proceso de activación de
Cuckoo SandBox fue automatizado y se explica en el capı́tulo 4 de este tema.

# t a r −z x v f c u c k o o 1 . 1 . t a r . g z
# cd / o p t / cuckoo
# p y t h o n cuckoo . py

Al ejecutar Cuckoo estará a la espera de que se envı́en muestras de malware para

su análisis, como se muestra en la figura 2.18.

Figura 2.18: Ejecución de Cuckoo SandBox. Fuente: Captura propia.

Para poder enviar muestras de malware a Cuckoo de manera manual, se realiza de

la siguiente manera:

73
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

# cd / o p t / cuckoo / u t i l s
# p y t h o n s u b m i t . py r u t a m u e s t r a s m a l w a r e

2.2.6. Archivos de configuración

En este apartado se explica la función de cada uno de los archivos de configuración
de Cuckoo que se empleó en este proyecto. Para consultar el contenido de los archivos
de configuración, referirse al apéndice A.

auxiliary.conf
Este archivo se debe editar si se desea activar o desactivar el uso de un analizador
de paquetes (sniffer) externo, en este caso tcpdump.

cuckoo.conf
En este archivo se elige sı́ cada vez que inicia Cuckoo compruebe que se tenga la
última versión instalada. Si se desea hacer esto, Cuckoo se conectará a una locación re-
mota y verificará que la última versión que estemos ejecutando es la versión más actual.
También en este archivo se configura la conexión con la base de datos, y se define la
dirección IP y el puerto que Cuckoo va a emplear para devolver los resultados obtenidos.

memory.conf
En este archivo de configuración se activa o desactiva el uso de volatility, la cual es
una herramienta que nos ayudará a realizar análisis forense sobre volcados de memoria.

processing.conf
En este archivo se configura la disponibilidad de los módulos de procesamiento. Es-
tos módulos se encuentran en modules/processing. Se define como se asimilan los datos
en bruto obtenidos durante el análisis.

reporting.conf
Este archivo de configuración habilita o deshabilita la generación automatizada de
reportes. Genera un reporte con formato jsondump y un reporte con formato html por
cada muestra de malware analizada.

virtualbox.conf
En este archivo de configuración se especifica la forma en que se ejecuta VirtualBox
y la forma en que interactuará con Cuckoo, ya que puede ser por lı́nea de comandos
o con interfaz gráfica de usuario. En este proyecto se configuró el modo de interfaz
gráfica.

74
 2.3 Puesta en producción

2.3. Puesta en producción

En este apartado se explicarán los requerimientos de software y hardware necesarios
para su funcionamiento, el proceso de instalación y puesta en producción del Sistema
de Detección de Intrusos y la SandBox Cuckoo, ası́ como la manera en que trabajan
ambos sistemas.

2.3.1. Requerimientos de hardware y software

Se debe contar con el software y hardware necesario, para llevar a cabo la imple-
mentación del IDS y la SandBox, ası́ como tener en cuenta la ubicación dentro de la
red en la que fueron instalados dichos servicios.

El hardware necesario para la implementación del sistema es el siguiente:

Un servidor o PC. Debe contar con al menos 4 GB en memoria RAM, ya que

dentro de ella se ejecutan diversos procesos y servicios. El tener una cantidad
óptima de memoria RAM, garantiza que no se produzcan cuellos de botella al
momento de realizar las capturas de tráfico, generar alertas y analizar muestras
de malware. Adicionalmente se recomienda tener un espacio de almacenamiento
por lo menos de 500 GB, para poder almacenar el tráfico capturado, las mues-
tras de malware obtenidas a partir de éste y los resultados del análisis de malware.

Además, la PC debe de contar con dos tarjetas de red, ya que una interfaz se
emplea para la captura de tráfico, y otra para la administración remota.

Los requerimientos de software necesarios que se necesitan son los siguientes:

Linux Ubuntu (a partir de la versión 12.04). Este sistema operativo es la base

en donde se implementaron los servicios del IDS y SandBox. Las ventajas que
posee este sistema operativo es la gran estabilidad y el software que se necesita
es gratuito. Otra ventaja de usar Ubuntu, es que cuenta con un firewall, el cual
se puede modificar mediante el uso de iptables.

Este proyecto se basa en el IDS Snort, el cual es el sistema principal para poder
realizar la captura del tráfico de red y su posterior análisis.

La SandBox Cuckoo es el sistema que se encarga de realizar el análisis de las mues-

tras obtenidas, a partir del tráfico capturado por el IDS.

75
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

2.3.2. Configuración de port mirroring

La configuración de un port mirroring o puerto espejo fue necesario para la realiza-
ción de esta tesis, debido a que el IDS Snort requiere monitorear el tráfico de toda una
red, en busca de tráfico que pueda ser catalogado como malicioso.

Para ello en la configuración del switch core de dicha Secretarı́a, se estableció al

puerto 20 como el puerto de destino del tráfico proveniente de las VLAN Medicos, Me-
dicos2 y Gobierno; las cuales pertenecen al puerto 23 del switch, que es el enlace troncal.

En la figura 2.19 se aprecia el proceso de configuración del port mirroring en el

switch core, ası́ como el estatus de la configuración del puerto espejo y el proceso de
guardado de la configuración actual.

Figura 2.19: Configuración del port mirroring. Fuente: Captura propia.

2.3.3. Beneficios
Con la implementación de un IDS en la red, se detecta en tiempo real, principal-
mente tráfico sospechoso, peticiones de resolución de nombres de dominio malicioso y
ataques de denegación de servicios. Esto genera alertas, las cuales mantienen al ad-
ministrador de red informado, para que tome las medidas necesarias, a fin de mitigar
posibles fallas en los servicios y en la red.

Debido a que el IDS Snort, almacena las alertas generadas en una base de datos
dedicada, se puede realizar un análisis posterior con mayor detalle, acerca del compor-
tamiento del tráfico que generó dicho alerta.

76
 2.3 Puesta en producción

Al implementar la SandBox Cuckoo con un Sistema de Detección de Intrusos, el

beneficio de tener un IDS aumenta exponencialmente; ya que al mismo tiempo que
el IDS genera alertas, se puede analizar el comportamiento en un ambiente aislado y
controlado, y poder saber en cuestión de unos pocos minutos sı́ se trató de un falso
positivo o realmente es una potencial amenaza.

Ası́ mismo, una vez que termina el análisis en la SandBox, se genera un reporte,
en el cual se muestra diversa información acerca del comportamiento del malware. Un
apartado importante en el reporte, es que se conecta a la base de datos de Virus Total,
y muestra cuántos motores antivirus detectaron la muestra como maliciosa.

2.3.4. Topologı́a de red

La instalación del Sistema de Detección de Intrusos, garantiza conocer, capturar y
analizar el tráfico de datos que circulan en una red en especı́fico. Su ubicación dentro
de la red, debe ser la idónea, ya que debe de estar implementado estratégicamente, a
fin de que pueda capturar todo el tráfico que circula en los segmentos de red que serán
monitoreados.

Una vez que el Sistema de Detección de Intrusos se encuentra en producción, se ob-

tienen las capturas de tráfico necesarios, para poder analizar cuál es el comportamiento
del tráfico de red.

El Sistema de Detección de Intrusos, cuando se encuentra en producción, no mani-

pula o procesa la información que viaja por la red, simplemente la captura.

La ubicación del IDS se realizó en la Zona Desmilitarizada (DMZ) de la red, ya que

es ahı́ donde se encuentran diversos servidores de filtrado de contenido, resguardados
por un firewall. Esta ubicación tiene la ventaja de poder reunir en único puerto espejo,
el tráfico de los servidores de producción junto al IDS, y poder detectar todo el tráfico
de la institución, ya que el puerto reflejado, es la única puerta de salida de todo ese
tráfico. Esta arquitectura tiene la ventaja, además de detectar anomalı́as en el tráfico
de la red interna, detectar patrones anómalos en el tráfico entrante.

En la figura 2.20 se muestra la arquitectura de red empleada para la instalación del

IDS. El IDS, además de contar con una interfaz que captura el tráfico del puerto espejo
del switch de core, cuenta con otra interfaz, mediante la cual se puede tener acceso a
él para su administración; ya que la otra interfaz se encuentra en modo pasivo y no
cuenta con una dirección IP establecida.

77
2. IMPLEMENTACIÓN DEL SISTEMA DE DETECCIÓN DE INTRUSOS Y
CUCKOO SANDBOX

Figura 2.20: Arquitectura de red de la instalación del IDS Snort. Fuente: Elaboración
propia.

2.3.5. Funcionamiento
En el sistema anfitrión, por cada alerta emitida, el Sistema de Detección de Intru-
sos genera un archivo que se almacena en /var/log/log tcpdump/. Éstos se almacenan
con el nombre de tcpdump.log.identificador, en donde el identificador, es determinado
por la fecha y hora con el que se crearon. Es importante mencionar que estos eventos
que se encuentran registrados en los archivos mencionados anteriormente, también son
almacenados en la base de datos snort.

Una vez que se obtuvieron suficientes alertas, el programa para la automatización

del proceso de análisis de un evento (referirse al capı́tulo 4 de esta tesis) analizó los
datos de tráfico referentes al tráfico HTTP, para poder obtener las direcciones URL

78
 2.3 Puesta en producción

que fueron solicitadas y proceder a descargar, en caso de existir la petición de descarga

de un archivo. Éstas son las muestras de malware. En caso de que no se haya realizado
una petición para descargar algún archivo, también la URL puede ser analizada con
Cuckoo SandBox.

La SandBox Cuckoo se encarga de la ejecución y análisis de las muestras. Funciona

con el hypervisor VirtualBox. Cada muestra, se envı́a a una máquina virtual (invitada)
en un ambiente aislado y controlado, a fin de evitar la propagación de la muestra.

Cuckoo está compuesto por el equipo anfitrión, en donde también se encuentra el

IDS, y un par de sistemas invitados, para realizar el análisis.

El sistema anfitrión ejecuta el componente principal de la SandBox, el cual es ini-

ciar el análisis, capturar tráfico y la generación de reportes. Los sistemas invitados,
son entornos aislados, donde se envı́an las muestras de malware, para posteriormente
ser ejecutadas y analizadas. El comportamiento de la muestra, es enviado al sistema
anfitrión para la generación del reporte.

En la figura 2.21 se muestra la arquitectura de red que fue empleada, para la reali-
zación de esta tesis.

Figura 2.21: Arquitectura de red de Cuckoo SandBox. Fuente: docs.cuckoosandbox.org/

elaboración propia.

79
 Capı́tulo 3

Recolección de Evidencia

En este capı́tulo se explicará el funcionamiento de un Sistema de Detección de In-

trusos y la arquitectura de las reglas de Snort, las cuales sin ellas, no podrı́an generar
alertas y notificar al administrador de red de probables comportamientos anómalos y/o
sospechosos en el tráfico de red.

También, este capı́tulo explica la evidencia capturada con ayuda del IDS Snort, y
los reportes generados por Cuckoo SandBox a partir de esta evidencia.

3.1. Funcionamiento de un IDS

3.1.1. Métodos para la recolección de datos

Para poder comprender el funcionamiento de la suite de reglas de Snort, es necesario
saber cómo funciona un IDS.

La primera parte que se debe entender, es que un IDS simplemente está observando
el tráfico de una red. En general existen 3 tipos de IDS, lo cual determinará el tipo de
datos que ingresarán a él:

Información especı́fica de aplicaciones, como el correcto flujo de datos de éstas.

Información especı́fica de hosts, como contenido de logs y permisos del sistema

de archivos.

Información especı́fica de red, como el contenido de paquetes en la red.

Un IDS no tiene un método eficaz para la recolección de información, cada uno

cuenta con sus propias ventajas y desventajas; y cada método empleado es adecuado
para diferentes tareas.

81
3. RECOLECCIÓN DE EVIDENCIA

Sniffeo de paquetes
Cualquier tipo de IDS que observa el tráfico de una red, realiza un sniffeo de paque-
tes. El sniffeo de paquetes es un método clásico para realizar la detección de intrusos, e
inclusive existen técnicas de evasión de IDS; por ejemplo los ataques de fragmentación,
en los cuales un atacante cambia la manera en que los paquetes están fragmentados y
en consecuencia al reensamblarlos, quedan fragmentos vacı́os o superpuestos.

Análisis de logs
Muchos IDS extraen datos de los logs del sistema y alertan sı́ se observan compor-
tamientos anómalos. Las implementaciones originales de IDS emplearon este método
para recolectar datos. Dicho método permite obtener las huellas que un atacante dejó
en los registros del sistema.

Monitoreo de llamada al sistema

Los HIDS se autoajustan como un residente en el kernel del sistema operativo, y
está observando (o en algunos casos interceptando), llamadas potencialmente maliciosas
al sistema. Sı́ el HIDS determina que la llamada al sistema puede ser potencialmente
maliciosa, como solicitar cambiar de un usuario de menor privilegios a uno de mayor
privilegios, genera una alerta.

En el caso de algunos HIDS, como el Linux Intrusion Detection System (LIDS), no

permite realizar la llamada al sistema.

Monitoreo del sistema de archivos

Otro método empleados por los HIDS es observar los atributos y tamaños de los
ficheros del sistema de archivos. Sı́ el kernel del sistema operativo espontáneamente mo-
difica estos valores y ningún administrador realizó dicho cambio, es probable que hayan
sido troyanizados. Observando estas alertas, ayuda a los administradores a determinar
una posible actividad maliciosa.

3.1.2. Recolección de información e intentos de intrusión

Cualquier Sistema de Detección de Intrusos va a recolectar una gran cantidad de
datos, debido al constante flujo de información en la red, ası́ como una pequeña canti-
dad de ruido eléctrico. Para tener la mayor eficacia, es necesario contar con algoritmos
para determinar cuál de todo ese tráfico vale la pena alertar a los administradores.

Existen dos tácticas básicas para obtener los mejores resultados. Para ello, el tráfico
se puede ajustar a una polı́tica de seguridad determinada, dictada por las necesidades
particulares de una organización o de la misma red. Mientras algunos administradores
eligen permitir sólo el tráfico que ellos saben que es bueno, otros optan por bloquear el
tráfico que ellos saben que es malo. Para realizar la mejor decisión para la organización,
se debe tener en cuenta el tipo de tráfico que probablemente se observe, la cantidad de

82
 3.1 Funcionamiento de un IDS

personal que tiene que hacer frente a las alertas, ası́ como el nivel de paranoia generado
por las alertas.

La estrategia de permitir el tráfico bueno, implicará enfrentarse a una gran cantidad

de falsos positivos y a un gran volumen de alertas generadas. En cambio, la estrategia
de alertar cuando se sospeche de tráfico malicioso, significa que el volumen de alertas
generadas será menor. Esto se debe, a que las reglas pueden ser muy especı́ficas sobre
la definición de algún comportamiento anómalo. Este método es más preciso, ya que
cuando una alerta permanece activa por un largo tiempo, significa que una actividad
maliciosa puede estar ocurriendo.

La elección de la estrategia es un análisis de beneficio/costo, ası́ como considerar el

tiempo y los recursos que están dispuestos a dedicarse al correcto funcionamiento de
un IDS, con la eficacia de controlar el máximo número de ataques posibles.

3.1.3. Respuesta de un IDS ante un intento de ataque

Algunos sistemas son capaces de lanzar contraataques a las intrusiones detectadas,
aunque las mejores prácticas indican que la identificación automatizada y el rastreo de
llamadas al sistema, son los mecanismos más importantes.

Existen diferentes enfoques de las acciones a tomar por parte del IDS, cuando se
detecta un intento de intrusión.

Respuesta pasiva
Como ya se mencionó, los IDS observan el tráfico de la red, y éstos se configuran
para enviar y/o mostrar alertas a un administrador y/o almacenarlas en un archivo.
Estas alertas pueden ser de diversas maneras, como por ejemplo, notificaciones por
medio de e-mail, páginas o mensajes de texto para el administrador, incluso llamadas
telefónicas automatizadas.

Generalmente, estos tipos de IDS se configuran con una interfaz de administración

independiente de la interfaz que monitorea la red. La interfaz que está escuchando no
tiene configurada ni siquiera una dirección IP, ya que es una interfaz pasiva y discreta,
configurada para no responder; evitando revelar su presencia.

Respuesta activa
Los IPSs y los IDSs con capacidad de respuesta activa, se comportan como un IDS
de respuesta pasiva en cuanto a la detección. Sin embargo, cuando detectan un intento
de ataque, se pueden configurar para tomar medidas proactivas en contra de éstos, en
lugar de simplemente alertar al administrador y esperar a que él tome medidas. Ellos
pueden ser colocados, de tal manera que el tráfico atraviesa las interfaces, descartando
el tráfico que ven como malicioso, para que sólo el tráfico confiable pueda ser enviado al

83
3. RECOLECCIÓN DE EVIDENCIA

destinatario (modo inline). Este enfoque ofrece prevención y protección, debido a que
el sensor puede detener un ataque antes de que alcance a su objetivo, que es algo que
los IDSs de respuesta pasiva no pueden realizar.

Otro tipo de respuesta, es que ellos pueden enviar mensajes inalcanzables de Inter-
net Control Message Protocol (ICMP) al origen, en un esfuerzo de convencimiento de
que el sistema objetivo es inalcanzable.

La ventaja de la respuesta activa es que no tiene que estar un administrador de

sistema viendo el flujo de información en tiempo real. Lo peligroso, son las consecuencias
que una mala configuración puede provocar.

3.1.4. Motor de detección

El motor de detección de Snort, es el componente principal del IDS, el cual es un
grupo de herramientas de detección y prevención de amenazas, que trabajan conjunta-
mente para reensamblar tráfico, evitar evasiones y amenazas, entre otros. En un NIDS,
es el encargado de tomar datos de los paquetes capturados, comparándolos con el con-
junto de reglas que han sido configuradas.

Snort, a diferencia de otros IDS, genera sólo una alerta por cada paquete que generó
un evento. Esto se debe a que la primera regla que coincide con el payload del paquete,
es la única que generará la alerta.

El motor de detección de Snort primero determina el conjunto de reglas estable-

cidas, para ası́ poder realizar la comparación entre las reglas y los paquetes. Éstas se
almacenan en memoria dentro de las estructuras RTN (Rule Tree Node) y OTN (Op-
tions Tree Node), formando una matriz enlazada como se observa en la figura 3.1. En
los RTNs se almacena la información de las cabeceras de las reglas, mientras que en los
OTNs se almacenan las opciones de la regla.

84
 3.1 Funcionamiento de un IDS

Figura 3.1: Matriz enlazada. Fuente: Optimización de Sistemas de Detección de Intrusos

en Red, 2009.

Una vez que se ha generado una alerta, el paquete es clasificado de acuerdo al proto-
colo (TCP, UDP, ICMP, IP), para encontrar caracterı́sticas propias de cada protocolo.
Según el tipo de protocolo, se selecciona un árbol RTN y se inicia con un recorrido
de los diferentes nodos RTN, verificando las opciones de los encabezados de las reglas
hasta encontrar una coincidencia. Una vez que se seleccionó un árbol RTN, se inicia el
recorrido de los nodos OTN, en donde están almacenadas las opciones de las reglas.

Finalmente, se determina sı́ un nodo OTN coincide con la información de los datos
del paquete, comparando las opciones de esa regla contra el paquete.

3.1.5. Módulos de salida

Estos módulos son ejecutados cuando el sistema de alertas se activa, tomando la
salida para almacenarla en diferentes formatos. A continuación se detalla cada módulo
de Snort.

alert syslog: Este módulo permite enviar las alertas al syslog.

alert fast: Muestra información de manera rápida de los principales campos de la
alerta. Estos son: tiempo, mensajes de la alerta, clasificación, prioridad y sockets
de origen y destino.
alert full: Además de los campos anteriores, el módulo alert full muestra infor-
mación completa de las cabeceras de los paquetes capturados.
alert unixsock: Crea un socket para el envı́o de reportes de alertas.

85
3. RECOLECCIÓN DE EVIDENCIA

log tcpdump: Almacena los paquetes en un archivo con formato tcpdump.

csv: Permite escribir alertas en un formato más fácil de importar a una base de
datos.

unified 2: Este módulo permite registrar los datos en formato binario básico.
Almacena paquetes y alertas para su posterior análisis.

log null: Permite que se generen alertas para cierto tráfico, pero sin que se
capturen los paquetes.

Database: Snort permite el registro de alertas en una base de datos. Estas pueden
ser: MySQL, Oracle, PostgreSQL y unixODBC.

3.2. Estructura de las reglas de Snort

Snort emplea un lenguaje de descripción de reglas ligero y simple, que es flexible y
muy potente. Las reglas de Snort están divididas en dos secciones lógicas: encabezado
de la regla y las opciones de la regla. El encabezado de la regla contiene la acción de la
regla, protocolo, un operador, ip o red de origen y destino, ası́ como los puertos de origen
y destino. Las opciones de la regla contienen mensajes de alerta e información de en qué
parte del paquete se debe inspeccionar para determinar sı́ la regla debe entrar en acción.

Aquı́ se encuentra la forma general de una regla de Snort:

a c c i ón p r o t o c o l o i p / r e d o r i g e n p u e r t o o r i g e n d i r e c c i ó n o p e r a d o r i p /
red destino puerto destino ( opciones )

3.2.1. Encabezado de la regla

El encabezado de la regla contiene la información del origen y destino de la comu-
nicación.

Acciones de la regla
La acción de la regla le indica a Snort como debe actuar cuando encuentra un
paquete que equivale a los criterios de la regla. Las acciones por defecto disponibles
en Snort son cinco: alert, log, pass, activate y dynamic. Adicionalmente, sı́ el IDS se
configura en modo inline, existen tres opciones que son: drop, reject y sdrop.

alert: Snort genera una alerta, usando el método de alerta seleccionado, para
posteriormente capturar el paquete.

log: captura el paquete.

86
 3.2 Estructura de las reglas de Snort

pass: el paquete es ignorado.

activate: se genera una alerta y una regla dinámica es invocada.

dynamic: se activa por una regla de activación.

drop: es empleado en el modo inline; el paquete es bloqueado y capturado.

reject: es empleado en el modo inline; el paquete es bloqueado y capturado.

Se envı́a un reset TCP sı́ el protocolo es TCP o un mensaje ICMP de puerto
inalcanzable sı́ el protocolo es UDP.

sdrop: es empleado en el modo inline; el paquete es bloqueado y no se guarda

ningún registro de él.

Protocolos
Permite establecer el protocolo de comunicación, el cual Snort analiza por compor-
tamientos sospechosos: TCP, UDP, ICMP e IP.

Direcciones IP
Permite establecer el origen y destino de la comunicación a nivel de capa 3 del
modelo OSI. Este campo se puede indicar de las siguientes formas:

Indicando la IP de un host (p.e. 10.123.32.45).

Indicando la dirección de un segmento de red (p.e. 10.123.32.0/24).

Indicando un conjunto de direcciones de red, empleando corchetes (p.e. [10.123.32.44,

10.123.32.54, 10.123.32.60]).

Empleando el uso de variables. Las variables por defecto en Snort es $EXTER-

NAL NET (red externa), $HOME NET (red local) y ANY (cualquier red). Sı́ es
necesario, también se pueden definir nuevas variables en el fichero /etc/snort/s-
nort.conf. El formato es el siguiente:
var NET a 10.123.32.0/24 // red especı́fica
var NET b !10.123.32.0/24 // diferente a una red especı́fica
var NET c [10.123.32.0/24, 10.123.33.0/24] // conjunto de redes

Número de puertos
Permite establecer el origen y destino de la comunicación. Este campo se puede
especificar de las siguientes formas:

Indicando un rango de puertos (p.e. alert udp any any -> $HOME NET 1:1024).

Indicando un puerto en especı́fico (p.e. log tcp any any -> 192.168.1.0/24 80).

Indicando un rango de puertos menores o iguales a un puerto en especı́fico (p.e.

log tcp $EXTERNAL NET any -> $HOME NET :6000).

87
3. RECOLECCIÓN DE EVIDENCIA

Indicando un rango de puertos mayores o iguales a un puerto en especı́fico (p.e.

alert tcp any any -> 10.0.0.0/8 500:).

Indicando la captura de todos los puertos menores a 2004 excepto el 1945 (p.e.
log tcp any any -> $HOME NET !1945:2004).

Dirección del operador

La dirección del operador indica el sentido de la comunicación que la regla debe apli-
car. El operador -> indica que las direcciones IP y puertos de la izquierda son el host de
origen del flujo de información, mientras que las direcciones IP y puertos de la derecha
son el destino. El operador bidireccional <> indica a Snort que debe considerar las
direcciones IP y puertos tanto de origen como de destino. Este operador es útil para el
análisis de ambos lados de una comunicación, como por ejemplo sesiones telnet o POP3.

La siguiente regla analiza el tráfico que se origina de un servidor Telnet en la red

172.16.0.0/12, que contiene la palabra confidential:

a l e r t t c p 1 7 2 . 1 6 . 0 . 0 / 1 2 23 −> any any ( c o n t e n t : ” c o n f i d e n t i a l ” ; msg : ”

Detected c o n f i d e n t i a l ” ; )

La regla anterior puede adaptarse para analizar el tráfico saliente o entrante de

cualquier servidor Telnet en la red:

a l e r t t c p 1 7 2 . 1 6 . 0 . 0 / 1 2 23 <> any any ( c o n t e n t : ” c o n f i d e n t i a l ” ; msg : ”

Detected c o n f i d e n t i a l ” ; )

Reglas activadoras/dinámicas
La combinación de reglas activadoras/dinámicas proporcionan al IDS un mejor
desempeño. Se puede contar con una regla que active a otra cuando la primera lle-
ve a cabo una acción para un número determinado de paquetes. La regla activadora
se desempeña sólo como una regla de alerta, a menos de que contenga un campo de
opción requerido: activates. En cambio, las reglas dinámicas actúan sólo como regla de
registro, y tienen un campo de opción diferente: activated by.

En el siguiente ejemplo se le indica al IDS que debe alertar, cuando detecte un

desbordamiento de búfer IMAP y capture los siguientes 50 paquetes con cabeceras para
el puerto 143. Ası́ mismo, el origen de dichos paquetes tiene que ser una red distinta a la
local, mientras que el destino tiene que ser la red local. Sı́ el desbordamiento de búfer
fue exitoso, existe una gran posibilidad de que los datos útiles se encuentren dentro
de los siguientes 50 paquetes, por lo que esos paquetes son valiosos para su posterior
análisis.

88
 3.2 Estructura de las reglas de Snort

a c t i v a t e t c p !$HOME NET any −> $HOME NET 143 ( f l a g s :PA; c o n t e n t : ” |

E8C0FFFFFF | / b i n ” ; a c t i v a t e : 1 ; msg ” Desbordamiento de b u f e r IMAP ! ” ; )

dynamic t c p !$HOME NET any −> $HOME NET 143 ( a c t i v a t e d b y : 1 ; count : 5 0 ; )

3.2.2. Opciones de la regla

En las opciones de las reglas de Snort, se establecen los mensajes; con los cuales
se muestran las alertas, un identificador de regla, las decisiones que elige la regla, los
valores de los campos que contiene el paquete para que se cumpla la condición del
encabezado, entre otros. Todas las opciones de la regla se deben separar una de otra
usando un punto y coma (;). Las palabras clave de las opciones de la regla, deben ir
separadas de sus argumentos con dos puntos (:).

Existen 4 categorı́as para las opciones de la regla:

general: Estas opciones proporcionan información sobre la regla, pero no tienen

ningún efecto durante la detección.

payload: Estas opciones buscan datos de carga útil dentro del paquete.

non-payload: Estas opciones buscan datos de carga no útil.

post-detection: Estas opciones son disparadores de reglas especı́ficas, que ocurren

después de que una regla se ha ejecutado.

89
3. RECOLECCIÓN DE EVIDENCIA

Opciones generales
En la tabla 3.1 se muestran las opciones generales de las reglas de Snort:

Nombre Descripción
msg Esta opción muestra una breve descripción cuando una regla es
activada.
reference Permite incluir referencias a las reglas de sistemas de identificación
externos.
gid Identifica la parte de Snort que genera un evento, cuando una regla
en particular se activa.
sid El sid (Snort ID) se emplea para identificar fácilmente cada regla
de Snort. Los rangos de sid son los siguientes:

≤ 999 999 Reservado para las reglas oficiales de Snort.org y el

conjuto de reglas VRT.
1, 000,000 - 1, 999,999 Reservado para las reglas locales.
2, 000,000 - 2, 999,999 Reservado para el repositorio de Bleeding
Edge Threats.
≥ 3, 000,000 Reservado para futuro uso.
rev La opción rev, indica la versión y/o revisión de la regla. La opción
rev en combinación con sid, sólo identifica una regla de Snort;
relacionando el ID de la regla individual con el número de revisión
de la regla.
classtype Se usa para clasificar una regla e identifica el tipo de ataque que
contiene el paquete.
priority Se emplea para asignar un nivel de gravedad a las reglas.
metadata Permite insertar información adicional acerca de la regla.

Tabla 3.1: Opciones generales

90
 3.2 Estructura de las reglas de Snort

Opciones payload
En la tabla 3.2 se muestran las opciones payload de las reglas de Snort:

Nombre Descripción
content Permite indicarle a Snort la búsqueda de contenido especı́fico en el
campo de datos del paquete. Sı́ los datos del paquete concuerdan
exactamente con los ingresados en la regla, el resto de las opciones
de la regla se ejecutan.
protected Permite buscar contenido en un paquete, sin revelear el contenido
content en la regla.
hash Especı́fica el algoritmo hash que se ocupa cuando se observa una
regla de contenido protegido. Acepta MD5, SHA256 y SHA512.
nocase Permite buscar contenido sin distinguir entre mayúsculas y
minúsculas.
rawbytes Permite observar los datos del paquete en crudo, ignorando cual-
quier decodificación que haya sido realizado por los preprocesado-
res.
depth Especı́fica un rango de ”n”bytes de un paquete, en los cuales Snort
debe inspeccionar el patrón.
offset Se indica a Snort donde debe empezar a inspeccionar el patrón en
un paquete.
distance Se indica a Snort la cantidad de bytes que debe ignorar, antes de
empezar a inspeccionar el patrón en un paquete.
within Establece que Snort debe inspeccionar el patrón a partir de
”n”bytes desde la última coincidencia.
uricontent Se establece una búsqueda de contenido en las peticiones (URI)
que se realizan a los servidores HTTP.
urilen Indica la mı́nima y máxima longitud; ası́ como el rango de tamaño
de la URI para que coincida.
isdataat Comprueba que la carga útil tiene datos en una ubicación especı́fi-
ca.
pcre Permite usar reglas escritas en perl que son compatibles con ex-
presiones regulares.
byte test Analiza un campo de un byte contra un valor especı́fico.
byte jump Se le indica a una regla leer la longitud de una porción de datos.
ftpbounce Detecta ataques de FTP Bounce.
asn1 Decodifica un paquete o una porción de un paquete y comprueba
sı́ existen codificaciones maliciosas.

Tabla 3.2: Opciones payload

91
3. RECOLECCIÓN DE EVIDENCIA

Opciones non-payload
En la tabla 3.3 se muestran las opciones non-payload de las reglas de Snort:

Nombre Descripción
fragoffset Permite comparar el desplazamiento del fragmento IP contra un
valor decimal.
ttl Es usado para verificar el valor time-to-live de un paquete IP. Se
emplea para detectar intentos de trazar la ruta. El rango de valores
que emplea es de 0 a 255.
tos Verifica el valor del campo ToS (Type of Service) en el encabeza-
do IP, el cual indica una serie de parámetros sobre la calidad de
servicio durante el recorrido por una red.
id Se emplea para comprobar el valor del campo id del datagrama.
Este se emplea en caso de que el datagrama sea fragmentado.
Herramientas como scanners y exploits, emplean este campo para
diversos propósitos.
ipopts Esta opción se emplea para verificar el campo opción de la cabe-
cera del datagrama IP.
fragbits Es usado para verificar sı́ los bits reservados y de fragmentación
se encuentran establecidos en el encabezado IP.
dsize Permite establecer el tamaño del payload. Se emplea para verificar
tamaños anómalos de paquetes, que puedan causar desbordamien-
to de búfer.
flags Se usa para comprobar sı́ los bits especı́ficos de las banderas TCP
están activos.
Los bits que verifica son:

F -FIN
S -SYN
R -RST
P -PSH
A -ACK
U -URG
C -CWR
E –ECE

0 -Ninguna bandera TCP establecida.

flow Es empleada para determinar la dirección del flujo del tráfico.
flowbits Esta opción es usada para seguir los estados de las sesiones del
protocolo de transporte, junto con la opción flow.
seq Permite verificar por un número de secuencia TCP.
Continúa en la siguiente página

92
 3.2 Estructura de las reglas de Snort

Tabla 3.3 – Continuación de la página previa

Nombre Descripción
ack Verifica el valor ACK de un paquete TCP.
window Verifica el tamaño de una ventana TCP especı́fica.
itype Identifica el tipo de mensaje ICMP.
icode Identifica el valor del código ICMP.
icmp id Obtiene el identificador ICMP.
icpm seq Permite identificar una determinada secuencia de paquetes ICMP.
rpc Se emplea para identificar aplicaciones Rich Client Platform
(RPC), tales como Eclipse, NetBeans, Visual Studio, etc.
ip proto Obtiene el protocolo del encabezado IP.
sameip Realiza una comparación entre las direcciones IP de origen y des-
tino; y determina sı́ las IP de origen y destino son las mismas.
stream Permite a una regla activar o desactivar el reensamblado del flujo
reassemble TCP, en el tráfico que coincidió con las reglas.
stream size Permite a una regla capturar tráfico, de acuerdo a la coincidencia
del número de bytes observados.

Tabla 3.3: Opciones non-payload

93
3. RECOLECCIÓN DE EVIDENCIA

Opciones post-detection
En la tabla 3.4 se muestran las opciones post-detection de las reglas de Snort:

Nombre Descripción
logto Se le indica a Snort que guarde el paquete que activó esa alerta.
session Permite extraer datos de usuario de sesiones TCP, por ejemplo
telnet, ftp, entre otros.
resp Permite a Snort terminar conexiones de protocolo basadas en las
reglas que se activan. Por ejemplo, puede enviar un paquete es-
pecı́fico TCP o ICMP.
react Permite una respuesta activa, que permite el envı́o a una página
web u otro servicio al cliente, para después terminar la conexión.
tag Registra un número en especı́fico de paquetes después de que una
alerta se ha activado.
activates Permite especificar a una regla que agregue otra, cuando un evento
especı́fico de red ocurrió.
activated Permite activar dinámicamente una regla, cuando una alerta en
by especı́fico se activó.
count Especifica el número de paquetes que debe dejar pasar la regla,
antes de que ésta se active. Debe ser empleada con la opción
”activated by”.
replace Es una opción especial para el modo inline de Snort. Se reempla-
zará el contenido coincidente por una cadena de la misma longitud.
detection Establece un rango, en el que debe ser excedido por un host de
filter origen o destino, antes de que la regla pueda generar una alerta.

Tabla 3.4: Opciones post-detection

94
 3.3 Eventos generados (Alertas)

3.3. Eventos generados (Alertas)

En el periodo que se dejó funcionando el Sistema de Detección de Intrusos, se
generaron las siguientes alertas, mostradas en la figura 3.2.

Figura 3.2: Alertas emitidas por el IDS Snort. Fuente: Captura propia.

Para la realización de este proyecto solo se toman en cuenta las alertas que indican
un comportamiento anómalo por los equipos finales de los usuarios. Estas se indican
con la clasificación trojan-activity, omitiendo las demás alertas que se generaron.

El primer evento que se generó es el que contiene la firma “Snort Alert [1:28806:2]”,
el cual generó 177 eventos. Esto se observa en la figura 3.3.

Figura 3.3: Alerta de Snort 1:28806:2. Fuente: Captura propia.

La siguiente alerta generada contiene la firma “Snort Alert [1:30211:1]” generando

un total de 3120 eventos. Esta alerta se observa a continuación en la figura 3.4.

95
3. RECOLECCIÓN DE EVIDENCIA

Figura 3.4: Alerta de Snort 1:30211:1. Fuente: Captura propia.

El siguiente evento generado contiene la firma “Snort Alert [1: 28039:4]”. Esta alerta
tuvo una ocurrencia de 81 eventos, tal y como se muestra en la figura 3.5.

Figura 3.5: Alerta de Snort 1:28039:4. Fuente: Captura propia.

El evento que contiene la firma “Snort Alert [1:31683:1]”, generó un total de 45

alertas. La figura 3.6 muestra este evento.

Figura 3.6: Alerta de Snort 1:31683:1. Fuente: Captura propia.

El evento generado con la firma “Snort Alert [1:28801:2]”, tuvo un total de 547
alertas. Esto se observa en la figura 3.7.

Figura 3.7: Alerta de Snort 1:28801:2. Fuente: Captura propia.

La alerta con la firma “Snort Alert [1:28423:1]”, disparó 77 alertas. Los detalles de
este evento se observan en la figura 3.8.

Figura 3.8: Alerta de Snort 1:28423:1. Fuente: Captura propia.

El evento con la firma “Snort Alert [1:27919:3], generó un total de 90 alertas, como
se aprecia a continuación en la figura 3.9.

96
 3.3 Eventos generados (Alertas)

Figura 3.9: Alerta de Snort 1:27919:3. Fuente: Captura propia.

En la figura 3.10 se muestra el evento con la firma “Snort Alert [1:32125:1]”, la cual
disparó 2 alertas.

Figura 3.10: Alerta de Snort 1:32125:1. Fuente: Captura propia.

Finalmente, el evento con la firma “Snort Alert [1:31527:1]”, tuvo una ocurrencia
de 4 eventos, como se muestra en la figura 3.11.

Figura 3.11: Alerta de Snort 1:31527:1. Fuente: Captura propia.

Cabe recordar que estos eventos, se generaron gracias a la ayuda de las reglas que
se descargaron de la página oficial de Snort. El conjunto de reglas que se empleó fue el
que proporciona la comunidad de Snort de manera gratuita.

97
3. RECOLECCIÓN DE EVIDENCIA

3.3.1. Contenido de las reglas disparadas

A continuación se explicarán cada una de las reglas que generaron los eventos an-
teriormente descritos.

Snort Alert [1:28806:2]

La regla que generó el evento “Snort Alert [1:28806:2]”, se encuentra ubicada en el
fichero /etc/snort/rules/local.rules. El contenido de la regla es el siguiente:

a l e r t t c p $HOME NET any −> $EXTERNAL NET $HTTP PORTS ( msg : ”INDICATOR−
COMPROMISE p o t e n t i a l malware download − s i n g l e d i g i t . exe f i l e
download ” ; f l o w : t o s e r v e r , e s t a b l i s h e d ; u r i l e n : 6 ; c o n t e n t : ” . exe ” ;
f a s t p a t t e r n : o n l y ; p c r e : ” / \ / [ a−z0 − 9 ] \ . exe$ / Ui ” ; metadata : i m p a c t f l a g
red , p o l i c y s e c u r i t y −i p s drop , r u l e s e t community , s e r v i c e h t t p ;
r e f e r e n c e : u r l , u r l q u e r y . n e t / s e a r c h . php?q= %5C %2F %5Ba−zA−Z %5D%5C. %5BEe %5D
%5BXx %5D%5BEe %5D%24&type=r e g e x p&s t a r t =2013−09−07&end=2013−12−06&max
=400; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 2 8 8 0 6 ; r e v : 2 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
TCP. El origen de la comunicación es cualquier host que pertenezca a la red
172.16.0.0/12 y el puerto de origen puede ser cualquiera.

El destino de la comunicación es cualquier dirección IP que no se encuentre en la

red local, y los puerto de destino pueden ser cualquiera de los que a continuación
se mencionan: 36, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 311, 383, 555, 591,
593, 631, 801, 808, 818, 901, 972, 1158, 1220, 1414, 1533, 1741, 1830, 1942, 2231,
2301, 2381, 2809, 2980, 3029, 3037, 3057, 3128, 3443, 3702, 4000, 4343, 4848,
5000, 5117, 5250, 5600, 6080, 6173, 6988, 7000, 7001, 7071, 7144, 7145, 7510,
7770, 7777, 7778, 7779, 8000, 8008, 8014, 8028, 8080, 8081, 8082, 8085, 8088,
8090, 8118, 8123, 8180, 8181, 8222, 8243, 8280, 8300, 8333, 8344, 8500, 8509,
8800, 8888, 8899, 8983, 9000, 9060, 9080, 9090, 9091, 9111, 9290, 9443, 9999,
10000, 11371, 12601, 13014, 15489, 29991, 33300, 34412, 34443, 34444, 41080,
44449, 50000, 50002, 51423, 53331, 55252, 55555, 56712. Esta lista de puertos se
encuentra en el fichero snort.conf. En este fichero a la variable HTTP PORTS se le
pueden agregar o eliminar puertos, según sean las necesidades de la organización.
En este caso, se empleó la configuración de puertos HTTP por defecto de Snort.

Opciones de la regla:
El argumento de la opción msg (INDICATOR-COMPROMISE potential malwa-
re download - single digit .exe file download), va a mostrar dicho mensaje que

98
 3.3 Eventos generados (Alertas)

identifica el por qué esa alerta fue disparada.

Los argumentos de la opción flow (to server, established), indican que se apli-
que la regla solo a un sentido de la comunicación y que sean peticiones hacia
un servidor. El argumento established indica que deben existir conexiones TCP
establecidas.

El argumento urilen (6), establece la longitud de 6 bytes de las URI’s que com-
parará Snort.

El argumento de la opción content (.exe), establece que Snort busque la palabra

.exe en el payload del paquete, el cual es la extensión de un archivo ejecutable.

El argumento de la opción fast pattern (only), establece que debe usar el conte-
nido “.exe” por el Fast Pattern Matcher, para que no se evalúe como la opción
“content” de la regla.

El argumento de la opción pcre (/\/[a-z0-9]\.exe$/Ui), sirva para indicar el uso

de una expresión regular. Dicha expresión regular establece que el valor a buscar
en el payload del paquete debe de contener cualquier palabra que empiece con “/”
formado por una letra minúscula o un número, seguido de la extensión .exe. Los
siguientes son delimitadores que indican que debe distinguir entre mayúsculas y
minúsculas.

Los argumentos de la opción metadata (impact flag red, policy security-ips drop,
ruleset community y service http) establecen información adicional acerca de la
regla, sin que afecte los patrones de búsqueda. Los primeros dos argumentos se
emplean en el modo inline de Snort. El tercer argumento proporciona información
acerca de que esta regla pertenece al grupo de reglas de la comunidad de Snort.
El cuarto argumento identifica a la regla como un servicio HTTP.

El argumento de la opción reference (url), establece una referencia externa, de

sistemas de identificación externos.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (28806), establece el identificador único para esta

regla en especı́fico. El identificador de esta regla es el 28806.

99
3. RECOLECCIÓN DE EVIDENCIA

El argumento de la opción rev (2), indica que es la versión 2 de dicha regla.

Snort Alert [1:30211:1]

La regla que generó al evento “Snort Alert [1:30211:1]” se ubica en el fichero
/etc/snort/rules/malware-cnc.rules. El contenido de la regla es el siguiente:

a l e r t t c p $EXTERNAL NET $HTTP PORTS −> $HOME NET any ( msg : ”MALWARE−CNC Win
. Trojan . ZeusVM embedded image c o n f i g f i l e download ” ; f l o w : t o c l i e n t ,
e s t a b l i s h e d ; f l o w b i t s : i s s e t , f i l e . j p e g ; f i l e d a t a ; c o n t e n t : ” | FF FE 3F
10 00 0 0 | ” ; f a s t p a t t e r n : o n l y ; p c r e : ” /\xFF\xFE\x3F\ x10 \ x00 \ x00 . { 1 4 } [ \
x2Bx\x2Fa−z0 −9]{20}/ smi ” ; metadata : i m p a c t f l a g red , p o l i c y balanced −
i p s drop , p o l i c y s e c u r i t y −i p s drop , s e r v i c e h t t p ; r e f e r e n c e : u r l ,www.
v i r u s t o t a l . com/ en / f i l e /
C003CA9C9694489F202E5A77FBD4973ADF7286C414EB98D525A8BFBC582D8962/
a n a l y s i s / ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 3 0 2 1 1 ; r e v : 1 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
TCP. El origen de la comunicación es cualquier dirección IP que no pertenezca
al segmento de la intranet. Los puertos de origen de la comunicación podrán ser
los puertos HTTP que se mencionaron en la alerta 28806.

El destino de la comunicación es cualquier dirección IP que pertenezca al segmento

de la intranet y el puerto destino puede ser cualquiera.

Opciones de la regla:
El argumento de la opción msg (MALWARE-CNC Win.Trojan.ZeusVM embed-
ded image config file download), mostrará este mensaje cuando dicha alerta haya
sido disparada, permitiendo identificar esta alerta con mayor facilidad.

Los argumentos de la opción flow (to client, established), indican que se aplique la
regla solo a un sentido de la comunicación y que sean peticiones hacia un cliente.
El argumento established indica que deben existir conexiones TCP establecidas.

Los argumento de la opción flowbits (isset,file.jpeg), le permite asegurar a Snort

que debe buscar un archivo JPEG.

La opción file data, en conjunto con el argumento de la opción content (|FF FE

3F 10 00 00|); asegura que el contenido en hexadecimal se encuentra en el flujo

100
 3.3 Eventos generados (Alertas)

del archivo actual con extensión JPEG.

El argumento de la opción fast pattern (only), establece que debe usar el conte-
nido en hexadecimal por el Fast Pattern Matcher, para que no se evalúe como la
opción “content” de la regla.

El argumento de la opción pcre (/\xFF\xFE\x3F\x10\x00\x00.{14}[\x2Bx\x2Fa-

z0-9]{20}/smi), sirve para indicar el uso de una expresión regular. Esta expresión
regular indica que debe de buscar las referencias hexadecimales de caracteres en
regex. El punto indica que puede ser cualquier carácter, excepto saltos de lı́nea.
El valor dentro de las llaves (14), indica que cualquier carácter se debe repetir
14 veces, seguida de la repetición de 20 veces de una cadena compuesta por una
combinación de una referencia hexadecimal, el carácter “x”, una letra minúscu-
la o un número. A continuación los delimitadores “smi”; s, indica que debe de
considerar los espacios en blanco como espacios en blanco; m, el modo debe ser
multilı́nea y la i que distinga entre mayúsculas y minúsculas.

Los argumentos de la opción metadata (impact flag red, policy balanced-ips drop,
policy security-ips drop y service http) establecen información adicional acerca de
la regla, sin que afecte los patrones de búsqueda. Los primeros tres argumentos
se emplean en el modo inline de Snort. El cuarto argumento identifica a la regla
como un servicio HTTP.

El argumento de la opción reference (url), establece una referencia externa, de

sistemas de identificación externos.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (30211), establece el identificador único para esta

regla en especı́fico. El identificador de esta regla es el 30211.

El argumento de la opción rev (1), indica que es la versión 1 dicha regla.

Snort Alert [1:28039:4]

La regla que generó al evento “Snort Alert [1:28039:4]” se ubica en el fichero
/etc/snort/rules/indicator-compromise.rules. El contenido de la regla es el siguiente:

101
3. RECOLECCIÓN DE EVIDENCIA

a l e r t udp $HOME NET any −> any 53 ( msg : ”INDICATOR−COMPROMISE S u s p i c i o u s .

pw dns query ” ; f l o w : t o s e r v e r ; c o n t e n t : ” | 0 1 00 00 01 00 00 00 00 00
0 0 | ” ; depth : 1 0 ; o f f s e t : 2 ; c o n t e n t : ” | 0 2 | pw | 0 0 | ” ; d i s t a n c e : 0 ;
f a s t p a t t e r n ; metadata : p o l i c y balanced −i p s a l e r t , p o l i c y s e c u r i t y −i p s
drop , s e r v i c e dns ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 2 8 0 3 9 ; r e v : 4 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
UDP. El origen de la comunicación es cualquier dirección IP que pertenezca al
segmento 172.16.0.0/12. Los puertos de origen de la comunicación pueden ser
cualquiera.

El destino de la comunicación es cualquier dirección IP y el puerto destino es el

53.

Opciones de la regla:
El argumento de la opción msg (INDICATOR-COMPROMISE Suspicious .pw
dns query), mostrará este mensaje cuando dicha alerta haya sido disparada, per-
mitiendo identificarla con mayor facilidad.

El argumento de la opción flow (to server), indican que se aplique la regla solo
a un sentido de la comunicación y que sean peticiones hacia un servidor, en este
caso un DNS.

El argumento de la opción content (|01 00 00 01 00 00 00 00 00 00|), junto con

el argumento de la opción depth (10) y el argumento de la opción offset (2); es-
tablece la búsqueda en el payload del paquete después de los primeros 2 bytes.
Con la opción depth se le indica a Snort que busque en los siguientes 10 bytes el
contenido “|01 00 00 01 00 00 00 00 00 00|”.

El argumento de la opción content (|02|pw|00|) junto con la opción distance y

su respectivo argumento (0); establece que debe empezar a buscar el contenido
“|02|pw|00|” a partir del byte 0.

La opción fast pattern, establece que debe usar el contenido por el Fast Pattern
Matcher, para que no se evalúe como la opción “content” de la regla.

Los argumentos de la opción metadata (policy balanced-ips alert, policy security-

ips drop, service dns) establecen información adicional acerca de la regla, sin que

102
 3.3 Eventos generados (Alertas)

afecte los patrones de búsqueda. Los argumentos policy balanced-ips alert y po-
licy security-ips drop; se emplean en el modo inline de Snort. El tercer argumento
identifica a la regla como un servicio DNS.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (28039), establece el identificador único para esta

regla en especı́fico.

El argumento de la opción rev (4), indica que es la versión 4 dicha regla.

Snort Alert [1:31683:1]

La regla que generó al evento “Snort Alert [1:31683:1]” se ubica en el fichero
/etc/snort/rules/malware-cnc.rules. El contenido de la regla es el siguiente:

a l e r t t c p $HOME NET any −> $EXTERNAL NET $HTTP PORTS ( msg : ”MALWARE−CNC Win
. Trojan . Badur v a r i a n t outbound c o n n e c t i o n ” ; f l o w : t o s e r v e r , e s t a b l i s h e d
; c o n t e n t : ” / g e t /? data=” ; depth : 1 1 ; h t t p u r i ; c o n t e n t : ” User−Agent :
win32 | 0D 0A| ” ; f a s t p a t t e r n : o n l y ; h t t p h e a d e r ; metadata : i m p a c t f l a g
red , p o l i c y balanced −i p s drop , p o l i c y s e c u r i t y −i p s drop , r u l e s e t
community , s e r v i c e h t t p ; r e f e r e n c e : u r l ,www. v i r u s t o t a l . com/ en / f i l e /840
b3b76030696b1ce9eccd5ee6d55dd79c0120871094cb9266769c09f03029c / a n a l y s i s
/ ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 3 1 6 8 3 ; r e v : 1 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
TCP. El origen de la comunicación es cualquier dirección IP que pertenezca al
segmento de la intranet. Cualquier puerto puede ser el origen.

El destino de la comunicación es cualquier dirección IP que sea diferente al seg-

mento de la intranet y los puertos de destino son los puertos HTTP que se men-
cionaron en la alerta 28806.

Opciones de la regla:
La opción msg con su respectivo argumento (MALWARE-CNC Win.Trojan.Badur
variant outbound connection), informa al administrador el motivo por el cual esa
alerta ha sido disparada. Además permite identificar de una forma más sencilla
esa alerta.

103
3. RECOLECCIÓN DE EVIDENCIA

Los argumentos de la opción flow (to server, established), indican que se apli-
que la regla sólo a un sentido de la comunicación y que sean peticiones hacia
un servidor. El argumento established indica que deben existir conexiones TCP
establecidas.

El argumento de la opción content (/get/?data=), junto con el argumento de

la opción depth (11) y la opción http uri; establece la búsqueda del contenido
“/get/?data=” en los primeros 11 bytes de la URI normalizada.

El argumento de la opción content (User-Agent: win32|0D 0A|), el argumento de

la opción fast pattern (only) y la opción http header ; establecen que Snort realice
la búsqueda de “User-Agent: win32|0D 0A|” en las cabeceras de las solicitudes
HTTP. Además, el contenido es usado por el Fast Pattern Matcher, para que no
se evalúe como la opción “content” de la regla. Esto es de gran ayuda ya que per-
mite realizar un menor esfuerzo al momento de evaluar la regla, ya que permite
ubicar el contenido en el payload, independientemente de su ubicación en el flujo
de la comunicación.

Los argumentos de la opción metadata (impact flag red, policy balanced-ips drop,
policy security-ips drop, ruleset community, service http) proporcionan informa-
ción adicional, sin que interfiera en las demás opciones establecidas. Los primeros
tres argumentos se emplean en el modo inline de Snort. El cuarto argumento pro-
porciona información acerca de que esta regla pertenece al grupo de reglas de la
comunidad de Snort. El último argumento identifica a la regla como un servicio
HTTP.

El argumento de la opción reference (url), establece una referencia externa, de

sistemas de identificación externos, respecto a esta actividad maliciosa.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (31683), establece el identificador único para esta

regla en especı́fico.

El argumento de la opción rev (1), indica la versión actual de la regla.

Snort Alert [1:28801:2]

La regla que generó al evento “Snort Alert [1:28801:2]”, se ubica en el fichero /et-
c/snort/rules/local.rules. El contenido de la regla es el siguiente:

104
 3.3 Eventos generados (Alertas)

a l e r t t c p $HOME NET any −> $EXTERNAL NET $HTTP PORTS ( msg : ”DELETED MALWARE
−CNC Win . Trojan . Bancos outbound c o n n e c t i o n attempt ” ; f l o w : t o s e r v e r ,
e s t a b l i s h e d ; c o n t e n t : ” . exe HTTP/ 1 . 1 | 0D 0A| Accept : ∗ / ∗ | 0D 0A| Accept−
Encoding : g z i p , d e f l a t e | 0D 0A| User−Agent : ” ; f a s t p a t t e r n : o n l y ;
c o n t e n t : ” | 3B | MSIE ” ; h t t p h e a d e r ; c o n t e n t : ! ” Accept−Language : ” ;
h t t p h e a d e r ; r e f e r e n c e : u r l ,www. v i r u s t o t a l . com/ en / f i l e /26
c60976776d212aefc9863efde914059dd2847291084c158ce51655fc1e48d0 /
a n a l y s i s / 1 3 8 2 6 2 0 1 3 7 / ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 2 8 8 0 1 ; r e v : 2 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
TCP. El origen de la comunicación es cualquier dirección IP que pertenezca al
segmento de la intranet. Cualquier puerto puede ser el origen.

El destino de la comunicación es cualquier dirección IP que sea diferente al seg-

mento de la intranet y los puertos de destino son los puertos HTTP que se men-
cionaron en la alerta 28806.

Opciones de la regla:
La opción msg con su respectivo argumento (DELETED MALWARE-CNC
Win.Trojan.Bancos outbound connection attempt); informa al administrador el
motivo por el cual esa alerta ha sido disparada. Además permite identificar de
una forma más sencilla esa alerta.

Los argumentos de la opción flow (to server, established), indican que se apli-
que la regla solo a un sentido de la comunicación y que sean peticiones hacia
un servidor. El argumento established indica que deben existir conexiones TCP
establecidas.

El argumento de la opción content (.exe HTTP/1.1|0D 0A|Accept: */*|0D 0A|

Accept-Encoding: gzip, deflate|0D 0A|User-Agent:) junto con la opción fast pattern
y su argumento (only); establece que debe usar el contenido anteriormente mos-
trado en el argumento de la opción content, por el Fast Pattern Matcher, para
que no se evalúe como la opción “content” de la regla.

La opción content con su respectivo argumento y la opción http header, le indica

a Snort que debe de realizar la búsqueda de “|3B| MSIE” en la cabecera de las
solicitudes HTTP.

105
3. RECOLECCIÓN DE EVIDENCIA

La opción content con su argumento (Accept-Language:) y la opción http header,

le indica a Snort que debe realizar la búsqueda de una cadena diferente a la del
argumento de la opción content, en los encabezados de las solicitudes HTTP.

El argumento de la opción reference (url), establece una referencia externa, de

sistemas de identificación externos, respecto a esta actividad maliciosa.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (28801), establece el identificador único para esta

regla en especı́fico. Ası́, el identificador de esta regla es el 28801.

El argumento de la opción rev (2), indica que la versión actual de la regla es la 2.

Snort Alert [1:28423:1]

La regla que generó al evento “Snort Alert [1:28423:1]”, se ubica en el fichero
/etc/snort/rules/exploit-kit.rules. El contenido de la regla es el siguiente:
a l e r t t c p $EXTERNAL NET $HTTP PORTS −> $HOME NET any ( msg : ”EXPLOIT−KIT
M u l t i p l e e x p l o i t k i t s i n g l e d i g i t exe d e t e c t i o n ” ; f l o w : t o c l i e n t ,
e s t a b l i s h e d ; c o n t e n t : ” f i l e n a m e=” ; h t t p h e a d e r ; c o n t e n t : ” . exe ” ; w i t h i n
: 6 ; f a s t p a t t e r n ; h t t p h e a d e r ; p c r e : ” / f i l e n a m e =[\ x22 \ x27 ] ? \ d \ . exe [ \ x22
\ x27 ] ? / Hi ” ; metadata : p o l i c y balanced −i p s drop , p o l i c y s e c u r i t y −i p s
drop , s e r v i c e h t t p ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 2 8 4 2 3 ; r e v : 1 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
TCP. El origen de la comunicación es cualquier dirección IP externa. El puerto
de origen son los puertos HTTP que se mostraron en la alerta 28806.

El destino de la comunicación es cualquier dirección IP que pertenezca al segmento

de la intranet y los puertos de destino pueden ser cualquiera.

Opciones de la regla:
La opción msg junto con su argumento (EXPLOIT-KIT Multiple exploit kit sin-
gle digit exe detection), aporta información acerca de la actividad maliciosa que
activó esa alerta.

Los argumentos de la opción flow (to client, established), indican que se aplique la
regla solo a un sentido de la comunicación y que sean peticiones hacia un cliente.

106
 3.3 Eventos generados (Alertas)

El argumento established indica que deben existir conexiones TCP establecidas.

La opción content con su respectivo argumento y la opción http header, le indica

a Snort que debe de realizar la búsqueda de “filename=” en la cabecera de las
solicitudes HTTP.

La opción content con el argumento (.exe), junto con las opciones within y el
argumento (6), la opción fast pattern y http header, establece que Snort debe de
inspeccionar en las cabeceras de las solicitudes HTTP el contenido “.exe” a partir
de 6 bytes desde que encontró la última coincidencia. Además se le indica que ese
contenido es usado por el Fast Pattern Matcher.

La opción pcre y el argumento (/filename=[\x22\x27]?\d\.exe[\x22\x27]?/Hi),

sirve para indicar el uso de una expresión regular. Esta expresión regular esta-
blece que el contenido a buscar debe de contener la cadena “filename=”, seguido
de una cadena compuesta por cualquiera de las dos referencias hexadecimales.
El signo de interrogacón, indica que no puede o que puede coincidir la cadena
solo una vez; pero no más. Posteriormente se establece que la coincidencia va ir
proseguido de cualquier número del 0 al 9. Después debe de existir la palabra
“.exe”, seguido a una cadena compuesta por cualquiera de las dos referencias he-
xadecimales. Nuevamente se establece que no puede existir ninguna cadena o solo
una. A continuación los delimitadores “Hi”. El delimitador “H” establece una re-
presentación en hexadecimal y la “i” que distinga entre mayúsculas y minúsculas.

Los argumentos de la opción metadata (policy balanced-ips drop, policy security-

ips drop, service http) proporcionan información adicional, sin que interfiera en
las demás opciones establecidas. Los primeros dos argumentos se emplean en el
modo inline de Snort. El tercer argumento identifca a la regla como un servicio
HTTP.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (28423), establece el identificador único para esta

regla en especı́fico.

El argumento de la opción rev (1), indica que la versión actual de la regla es la 1.

Snort Alert [1:27919:3]

La regla que generó al evento “Snort Alert [1:27919:3]”, se ubica en el fichero
/etc/snort/rules/malware-cnc.rules. El contenido de la regla es el siguiente:

107
3. RECOLECCIÓN DE EVIDENCIA

a l e r t t c p $HOME NET any −> $EXTERNAL NET $HTTP PORTS ( msg : ”MALWARE−CNC Win
. Trojan . Zeus e n c r y p t e d POST Data e x f i l t r a t i o n ” ; f l o w : t o s e r v e r ,
e s t a b l i s h e d ; c o n t e n t : ” Accept−Encoding | 3A| i d e n t i t y , ∗ | 3B | q =0|0D 0A| ” ;
f a s t p a t t e r n : o n l y ; h t t p h e a d e r ; c o n t e n t : ” | 3B | MSIE ” ; h t t p h e a d e r ;
p c r e : ” / [ ˆ −˜\ r \n ] { 4 } /P” ; metadata : i m p a c t f l a g red , p o l i c y balanced −i p s
drop , p o l i c y s e c u r i t y −i p s drop , r u l e s e t community , s e r v i c e h t t p ;
r e f e r e n c e : u r l ,www. v i r u s t o t a l . com/ en / f i l e /8825
abfca1a6d843ce5670858886cb63bb1317ddbb92f91ffd46cfdcaba9ac00 / a n a l y s i s
/ ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 2 7 9 1 9 ; r e v : 3 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
TCP. El origen de la comunicación es cualquier dirección IP que pertenezca a la
intranet. El puerto de origen puede ser cualquiera.

El destino de la comunicación es cualquier dirección IP que sea diferente al seg-

mento de la intranet y los puertos HTTP de destino pueden ser los que se mos-
traron en la alerta 28806.

Opciones de la regla:
La opción msg junto con su argumento (MALWARE-CNC Win.Trojan.Zeus encry-
pted POST Data exfiltration), aporta información acerca de la actividad maliciosa
que activó esta alerta.

Los argumentos de la opción flow (to server, established), indican que se apli-
que la regla solo a un sentido de la comunicación y que sean peticiones hacia
un servidor. El argumento established indica que deben existir conexiones TCP
establecidas.

El argumento de la opción content (Accept-Encoding|3A| identity,

*|3B|q=0|0D 0A|), el argumento de la opción fast pattern (only) y la opción
http header ; establecen que Snort realice la búsqueda de “Accept-Encoding|3A|
identity, *|3B|q=0|0D 0A|” en las cabeceras de las solicitudes HTTP. Además, el
contenido es usado por el Fast Pattern Matcher, para que no se evalúe como la
opción “content” de la regla.

El argumento de la opción content (|3B| MSIE), junto con la opción http header
indica que Snort debe de realizar la búsqueda de dicho contenido en los encabe-
zados de las solicitudes HTTP.

108
 3.3 Eventos generados (Alertas)

La opción pcre y el argumento (/[∧ -˜\r\n]{4}/P), sirve para indicar el uso de

una expresión regular. Esta expresión regular establece que coincida cualquier
carácter que no se encuentre dentro del rango “espacio en blanco” hasta “˜”
(código de caracteres del 32 al 126), y que no sea un retorno de carro y un salto
de lı́nea. Además debe de existir una repetición de 4 veces de la cadena anterior
que no contenga los caracteres especificados.

Los argumentos de la opción metadata (impact flag red, policy balanced-ips drop,
policy security-ips drop, ruleset community, service http) proporcionan informa-
ción adicional, sin que interfiera en las demás opciones establecidas. Los primeros
tres argumentos se emplean en el modo inline de Snort. El cuarto argumento pro-
porciona información acerca de que esta regla pertenece al grupo de reglas de la
comunidad de Snort. El quinto argumento es un identificador propio de la regla
en la que establece el tipo de servicio que Snort va a observar.

El argumento de la opción reference (url), establece una referencia externa, de

sistemas de identificación externos, respecto a esta actividad maliciosa.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (27919), establece el identificador único para esta

regla en especı́fico.

El argumento de la opción rev (3), indica que la versión actual de la regla es la 3.

Snort Alert [1:32125:1]

La regla que generó al evento “Snort Alert [1:32125:1]”, se ubica en el fichero /et-
c/snort/rules/blacklist.rules. El contenido de la regla es el siguiente:
a l e r t t c p $HOME NET any −> $EXTERNAL NET any ( msg : ”BLACKLIST User−Agent
known m a l i c i o u s u s e r −a g e n t s t r i n g − update − Win . Backdoor . Upatre ” ;
f l o w : t o s e r v e r , e s t a b l i s h e d ; c o n t e n t : ” User−Agent : update | 0D 0A| ” ;
f a s t p a t t e r n : o n l y ; metadata : i m p a c t f l a g red , p o l i c y balanced −i p s drop ,
p o l i c y s e c u r i t y −i p s drop , s e r v i c e h t t p ; r e f e r e n c e : u r l ,www. v i r u s t o t a l .
com/ en / f i l e /8
f98fce6c20dbbe8a156e5a5b671066ccd0db240140e81d69d1a7205457605cb /
a n a l y s i s / ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 3 2 1 2 5 ; r e v : 1 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser

109
3. RECOLECCIÓN DE EVIDENCIA

TCP. El origen de la comunicación es cualquier dirección IP que pertenezca a la

intranet. El puerto de origen puede ser cualquiera.

El destino de la comunicación es cualquier dirección IP que sea diferente al seg-

mento de la intranet y el puerto de destino puede ser cualquiera.

Opciones de la regla:
La opción msg junto con su argumento (BLACKLIST User-Agent known ma-
licious user-agent string - update - Win.Backdoor.Upatre), aporta información
acerca de la actividad maliciosa que activó esta alerta.

Los argumentos de la opción flow (to server, established), indican que se aplique
la regla solo a un sentido de comunicación y que sean peticiones hacia un servidor.
El argumento established indica que deben existir conexiones TCP establecidas.

El argumento de la opción content (User-Agent: update|0D 0A|), establece que

Snort busque “User-Agent: update|0D 0A|” en el payload del paquete, el cual
es la extensión de un archivo ejecutable. El argumento de la opción fast pattern
(only), establece que debe usar el contenido por el Fast Pattern Matcher, para
que no se evalúe como la opción “content” de la regla.

Los argumentos de la opción metadata (impact flag red, policy balanced-ips drop,
policy security-ips drop, service http) proporcionan información adicional, sin que
interfiera en las demás opciones establecidas. Los argumentos impact flag red,
policy balanced-ips drop y policy security-ips drop se emplean cuando el IDS se
configura en modo inline. El último argumento identifica que el tipo de servicio
que Snort monitoreará será HTTP.

El argumento de la opción reference (url), establece una referencia externa, de

sistemas de identificación externos, respecto a esta actividad maliciosa.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (32125), establece el identificador único para esta

regla en especı́fico. El identificador de esta regla es el 32125.

El argumento de la opción rev (1), indica que la versión actual de la regla es la 1.

Snort Alert [1:31527:1]

La regla que generó al evento “Snort Alert [1:31527:1]”, se ubica en el fichero
/etc/snort/rules/malware-cnc.rules. El contenido de la regla es el siguiente:

110
 3.3 Eventos generados (Alertas)

a l e r t t c p $HOME NET any −> $EXTERNAL NET [ 4 4 3 , 4 4 6 , 4 4 7 ] ( msg : ”MALWARE−CNC

Win . Trojan . Ramnit v a r i a n t outbound d e t e c t e d ” ; f l o w : t o s e r v e r ,
e s t a b l i s h e d ; d s i z e : 6 ; c o n t e n t : ” | 0 0 FF 01 00 00 0 0 | ” ; f a s t p a t t e r n : o n l y
; metadata : p o l i c y balanced −i p s drop , p o l i c y s e c u r i t y −i p s drop , s e r v i c e
s s l ; r e f e r e n c e : u r l ,www. v i r u s t o t a l . com/ en / f i l e /83
F75C8D52B84795A526CA7DAEA29186CDC2CDD4A33871A942BB00D673BB0E20/
a n a l y s i s / ; c l a s s t y p e : t r o j a n −a c t i v i t y ; s i d : 3 1 5 2 7 ; r e v : 1 ; )

Encabezado de la regla:
Esta regla es una alerta y establece que el protocolo que va a observar va a ser
TCP. El origen de la comunicación es cualquier dirección IP que pertenezca a la
intranet. El puerto de origen puede ser cualquiera.

El destino de la comunicación es cualquier dirección IP que sea diferente al seg-

mento de la intranet y el puerto de destino puede ser el 443, el 446 o el 447.

Opciones de la regla:
La opción msg junto con su argumento (MALWARE-CNC Win.Trojan.Ramnit
variant outbound detected), aporta información acerca de la actividad maliciosa
que activó esta alerta.

Los argumentos de la opción flow (to server, established), indican que se aplique
la regla solo a un sentido de comunicación y que sean peticiones hacia un servidor.
El argumento established indica que deben existir conexiones TCP establecidas.

El argumento de la opción dsize (6), establece el tamaño del payload. Esta opción
se emplea para verificar tamaños anómalos en el paquete.

El argumento de la opción content (|00 FF 01 00 00 00|) y el argumento de la

opción fast pattern (only), establecen que el contenido “|00 FF 01 00 00 00|” es
usado por el Fast Pattern Matcher, para que no se evalúe como la opción “con-
tent” de la regla.

Los argumentos de la opción metadata (policy balanced-ips drop, policy security-

ips drop, service ssl) proporcionan información adicional, sin que interfiera en las
demás opciones establecidas. Los primeros dos argumentos se emplean cuando el
IDS está en modo inline. El último argumento establece el identificador de servi-
cio que la regla va a estar monitoreando.

111
3. RECOLECCIÓN DE EVIDENCIA

El argumento de la opción reference (url), establece una referencia externa, de

sistemas de identificación externos, respecto a esta actividad maliciosa.

El argumento de la opción classtype (trojan-activity), clasifica e identifica el tipo

de ataque que contiene el paquete.

El argumento de la opción sid (31527), establece el identificador único para esta

regla en especı́fico. El identificador de esta regla es el 31527.

El argumento de la opción rev (1), indica que la versión actual de la regla es la 1.

112
 3.3 Eventos generados (Alertas)

3.3.2. Contenido y análisis del payload de los paquetes capturados

Snort Alert [1:28806:2]

Figura 3.12: Paquete de la firma 28806. Fuente: Captura propia.

En el paquete mostrado en la figura 3.12, se muestran los encabezados meta, IP,

113
3. RECOLECCIÓN DE EVIDENCIA

TCP, ası́ como el payload del paquete que fue capturado. En el encabezado metadata
se establece la fecha (2015-04-08) y hora (12:55:06) en la que fue emitida la alerta, ası́
como al identificador del evento (1-264584) que generó dicha regla.

En la cabecera IP y de acuerdo a la regla establecida; se comprueba que existe una

conexión TCP desde una dirección local (172.17.1.3) hacia una dirección IP remota
(205.251.133.42). En la cabecera TCP se muestra el puerto de origen (1626) y destino
(80).

En el payload del paquete se validan las búsquedas de contenido especı́fico que se

describieron en el cuerpo de la regla, el cual encontró que la longitud de la URI es de
6 bytes, ası́ como el contenido especı́fico de búsqueda (/w.exe). En dicho payload se
muestra el método GET del protocolo HTTP para la descarga de un archivo ejecutable.

Snort Alert [1:30211:1]

114
 3.3 Eventos generados (Alertas)

115
3. RECOLECCIÓN DE EVIDENCIA

Figura 3.13: Paquete de la firma 30211. Fuente: Captura propia.

En la alerta mostrada en la figura 3.13, se muestran los encabezados metada, IP,

TCP, ası́ como el payload del paquete que fue capturado. En el encabezado metadata
se establece la fecha y hora en la que fue emitida la alerta, ası́ como al identificador del
evento que generó dicha regla.

En la cabecera IP y de acuerdo a la regla correspondiente al evento 30211; se

comprueba que existe una conexión TCP desde una dirección externa a la intranet
(195.238.181.21) hacia una dirección IP interna (172.17.1.44). En la cabecera TCP se
muestra información acerca del puerto de origen (80) y destino (2492).

En el payload del paquete se validan las búsquedas de contenido especı́fico que se

describieron en el cuerpo de la regla, el cual encontró coincidencia para el contenido y
la expresión regular en la lı́nea 550.

116
 3.3 Eventos generados (Alertas)

Snort Alert [1:28039:4]

Figura 3.14: Paquete de la firma 28039. Fuente: Captura propia.

En la alerta mostrada en la figura 3.14, es posible observar los encabezados metada-

ta, IP, UDP y el área de datos. En la sección de metadata es posible observar la fecha
y hora en que fue generado este evento.

En la cabecera IP, se muestra la dirección IP de origen y destino que tuvo lugar

en esta conexión UDP. La IP de origen pertenece al segmento de la intranet, la cual
es la 172.17.2.177. La dirección de destino es una dirección que también pertenece
al segmento de red y es la 172.17.0.2. En esta dirección IP se encuentra el servicio
DNS, el cual resuelve nombres de dominio. En el encabezado UDP se muestra el puerto
de origen y destino de la comunicación, que corresponden al 1025 y 53 respectivamente.

En el payload del paquete se encuentra la petición de resolución de un nombre de

dominio, el cual es el tup27nyt.oiasdgfr.pw. Actualmente este dominio se encuentra libre
para el público en general.

117
3. RECOLECCIÓN DE EVIDENCIA

Snort Alert [1:31683:1]

118
 3.3 Eventos generados (Alertas)

Figura 3.15: Paquete de la firma 31683. Fuente: Captura propia.

En la figura 3.15 se muestra el encabezado metadata, IP, TCP y el contenido de

los datos. Este evento muestra información respecto a la fecha y hora en que esta aler-
ta fue disparada, mostrando también el identificador de la regla que generó dicho evento.

En la cabecera IP es posible observar la dirección IP de origen y destino para esta

conexión TCP. DE acuerdo a la regla para este evento, la dirección de origen tiene que
ser una dirección local, que en este caso es la 172.17.2.177; mientras que la de destino
tiene que ser una dirección IP que no pertenezca a la intranet (54.213.128.72). De la
misma manera, la regla establece que para que esta sea disparada, es necesario que el
puerto de origen sea cualquiera y el puerto de destino sea uno de los que se encuentran
establecidos en el archivo de configuración de Snort. En la cabecera TCP se muestra
que estos corresponden al 2062 como puerto de origen y el 80 como puerto de destino.

En el payload del paquete es posible realizar la coincidencia con el contenido “/ge-

t/?data=” establecido en la regla para su búsqueda. El match se realizó en la lı́nea 000
dentro de los primeros 11 bytes del payload del paquete.

119
3. RECOLECCIÓN DE EVIDENCIA

Snort Alert [1:28801:2]

Figura 3.16: Figura 3.16: Paquete de la firma 28801. Fuente: Captura propia.

La figura 3.16 muestra los encabezados metadata, IP, TCP y el contenido del pa-
quete; que corresponden al evento 28801. En la cabecera metadata se encuentra la fecha
y hora en que se generó dicho evento, junto con su respectivo identificador. En el enca-
bezado IP, se puede consultar la dirección IP de origen y destino. De acuerdo a la regla
establecida se indica que la dirección IP de origen pertenece al segmento 172.16.0.0/12,
mientras que la dirección IP de destino es cualquier dirección IP externa. Para este
evento dichas direcciones IP son la 172.17.1.43 y la 173.236.50.26 respectivamente. En
la cabecera TCP se muestran los puertos de origen y destino, los cuales corresponden

120
 3.3 Eventos generados (Alertas)

al 1305 y al 80 respectivamente.

En el payload del paquete se validan las búsquedas de contenido especı́fico que se

describieron en el cuerpo de la regla, el cual establece que debe de buscar en el payload
del paquete, la extensión de un archivo ejecutable, seguida de un String de 68 bytes de
longitud. Esta coincidencia se puede encontrar a partir de la lı́nea 010. También existe
una segunda coincidencia de un string que contenga el byte “3B” o la cadena “MSIE”
que se encuentra a partir del renglón 070.

Snort Alert [1:28423:1]

121
3. RECOLECCIÓN DE EVIDENCIA

122
 3.3 Eventos generados (Alertas)

Figura 3.17: Paquete de la firma 28423. Fuente: Captura propia.

En la figura 3.17, se muestran los encabezados metadata, IP, TCP y el contenido

del paquete; que corresponden al evento 28423. En la cabecera metadata se encuentra
información respecto al identificador único de ese evento; ası́ como la fecha y hora.

En la cabecera IP, se puede obtener la información de las direcciones IP de origen y

destino que se establecieron en la regla para este evento. La IP de origen no pertenece
al segmento de la intranet (116.255.152.168), mientras que la IP de destino pertenece
a la red interna (172.17.2.5). En el encabezado TCP, el puerto de origen pertenece al
conjunto de puertos de HTTP configurados en el archivo snort.conf (80) y el puerto de
destino puede ser cualquiera. En este caso es el 1528.

En el payload del paquete se validan las búsquedas de contenido especı́fico que se

describieron en el cuerpo de la regla, el cual encontró el contenido especı́fico de búsque-
da (.exe). Esta coincidencia se encuentra en la lı́nea 100. Con el uso de la expresión
regular es posible establecer el contenido preciso que debe buscar Snort en el payload
del paquete.

Snort Alert [1:27919:3]

123
3. RECOLECCIÓN DE EVIDENCIA

Figura 3.18: Paquete de la firma 27919. Fuente: Captura propia.

En el paquete mostrado en la figura 3.18, en el encabezado metadata se establece

la fecha y hora en la que fue emitida la alerta, ası́ como al identificador del evento que
generó dicha regla.

En la cabecera IP y de acuerdo a la regla establecida; se comprueba que existe una

conexión TCP desde una dirección local (172.17.1.244) hacia una dirección IP remota
(50.62.74.148). En la cabecera TCP se muestra el puerto de origen (1052) y destino (80).

En el payload del paquete se validan las búsquedas de contenido especı́fico que se

describieron en el cuerpo de la regla. Con el uso de la expresión regular es posible
establecer el contenido preciso que debe de buscar Snort en el payload del paquete. Las
coincidencias se encuentran a partir de la lı́nea 040.

124
 3.3 Eventos generados (Alertas)

Snort Alert [1:32125:1]

Figura 3.19: Paquete de la firma 32125. Fuente: Captura propia.

En la alerta mostrada en la figura 3.19, es posible constatar que en el encabezado

metada se establece la fecha en que hubo una coincidencia, el identificador de la regla
que generó ese evento; ası́ como el ID del evento. En el encabezado IP, y de acuerdo a
la regla establecida, se determina que la dirección de origen de la comunicación es una
dirección de la intranet (172.17.1.43) y la dirección de destino es una dirección externa
a la red local (59.56.66.150). En la cabecera TCP se observa que el puerto de origen es
el 1499 y el puerto destino es el 80.

En el payload del paquete se validan las búsquedas de contenido especı́fico que se

125
3. RECOLECCIÓN DE EVIDENCIA

describieron en el cuerpo de la regla, el cual establece que debe de buscar en el payload

del paquete, la cadena “User-Agent update |0D 0A|”, en el cual los valores en 0D y 0A,
son retorno de carro y salto de lı́nea respectivamente.

Snort Alert [1:31527:1]

Figura 3.20: Paquete de la firma 31527. Fuente: Captura propia.

En el paquete de la figura 3.20, se observa que en el encabezado metadata se esta-

blece la fecha y hora en la que fue emitida la alerta, ası́ como al identificador del evento
que generó dicha regla (1-418119).

En el encabezado IP, y de acuerdo a la regla establecida, se determina que la di-

rección de origen de la comunicación es una dirección de la intranet (172.17.2.177) y
la dirección de destino es una dirección externa a la red local (173.230.158.166). En la

126
 3.3 Eventos generados (Alertas)

cabecera TCP se especifica el puerto de origen 1027 y el puerto destino es el 443.

En el payload del paquete se validan las búsquedas de contenido especı́fico que

se describieron en el cuerpo de la regla, el cual establece un tamaño de 6 bytes del
payload, en los cuales existan 6 caracteres. Estos valores se establecen en hexadecimal
en el patrón a buscar en la regla.

127
3. RECOLECCIÓN DE EVIDENCIA

3.3.3. Análisis en Cuckoo SandBox

A continuación se explicará la estructura y el contenido de los reportes generados
por Cuckoo Sandbox sobre los archivos y URL obtenidos en cada uno de los eventos
anteriores.

Snort Alert [1:28806:2]

El siguiente informe que se muestra en la figura 3.21, corresponde a una conexión
que Snort detectó como una actividad de un troyano, que generó el evento 28806. El
reporte se encuentra dividido en dos partes.

En la primera parte del reporte de Cuckoo, se muestra el tipo de objeto que fue
analizado, la fecha en que se inició y terminó el análisis, la duración del análisis, ası́
como la versión de Cuckoo con la que se realizó el análisis.

A continuación se muestran algunos campos en los cuales es posible identificar la

muestra analizada. En estos campos se muestra el nombre del archivo analizado, su
tamaño en bytes, el tipo de archivo, el CRC32 y diversas funciones hash como MD5,
SHA1, SHA256 y SHA512, que sirven para identificar unı́vocamente a la muestra ana-
lizada. A continuación se muestra un algoritmo de fuzzy hashing (Ssdeep). Después, un
campo en el que se despliega información acerca de Yara, la cual es una herramienta
de clasificación de malware y finalmente un campo de Virus Total, el cual despliega el
número de motores antivirus que detectaron la muestra como una amenaza. Adicional-
mente Cuckoo toma capturas de pantalla mientras se realiza el análisis de la muestra.

128
 3.3 Eventos generados (Alertas)

129
3. RECOLECCIÓN DE EVIDENCIA

Figura 3.21: Análisis con Cuckoo SandBox del evento 28806. Fuente: Captura propia.

La sección de análisis estático muestra información respecto a la estructura del

archivo ejecutable. Aquı́ es posible encontrar información sobre las secciones que con-
forman el archivo y las direcciones de memoria. Ası́ mismo, es posible determinar sı́
el archivo malicioso importa alguna librerı́a durante la ejecución del mismo. Para este
archivo se importaron las siguientes librerı́as:

winspool. user32.dll version.dll comctl32.dll

drv
advapi32.dll gdi32.dll comdlg32.dll

kernel32.dll oleaut32.dll opengl32.dll winmm.dll

Sı́ hay información a mostrar en esta sección, bastará con seleccionar las subseccio-
nes localizadas en el área de análisis estático.

En el área Dropped Files se notifica que el archivo w.exe no descargó archivos adi-
cionales. Por ende, en el área Network Analysis se informa que dicho archivo malicioso
no se conectó a ningún sitio en Internet y que tampoco envı́a información robada del
sistema. En la sección Behavior Summary, se encuentra un historial de aquellos archi-
vos que fueron modificados, el detalle de las exclusiones mutuas (mutexes) ası́ como las

130
 3.3 Eventos generados (Alertas)

llaves de registro.

Al final del reporte, se selecciona el nombre del archivo analizado, y desplegará una
tabla con el resumen de las operaciones realizadas sobre el sistema. Estas operaciones
se encuentran separadas por categorı́as, y se diferencian por un color distinto que está
indicado en la sección processes.

Snort Alert [1:28039:4]

131
3. RECOLECCIÓN DE EVIDENCIA

132
 3.3 Eventos generados (Alertas)

133
3. RECOLECCIÓN DE EVIDENCIA

Figura 3.22: Análisis con Cuckoo SandBox del evento 28039. Fuente: Captura propia.

El informe mostrado en la figura 3.22, corresponde al evento con ID 28039 que Snort
detectó como una actividad relacionada con un troyano. Esta actividad fue detectada
como maliciosa, ya que la muestra analizada fue una resolución del nombre de dominio
tup27nyt.oiasdgfr.pw.

134
 3.3 Eventos generados (Alertas)

Como se observa al inicio del reporte, la muestra fue analizada en la versión de

Cuckoo SandBox 1.1 con una duración de 174 segundos.

En la sección de los detalles de la URL analizada, se observa que únicamente un

antivirus del portal Virus Total detectó el dominio como peligroso.

Posterior a los detalles de la URL analizada, se encuentran las capturas de pantalla

realizadas durante la ejecución del análisis de la muestra. Por otro lado, el reporte gene-
rado por Cuckoo despliega que no fue descargado ningún archivo durante la ejecución
del análisis y que no emplea la técnica drive-by-download, ni se realizaron conexiones
a sitios externos durante la ejecución.

Adicionalmente, se muestra el resúmen del comportamiento que tuvo el archivo

durante el análisis. Al inicio se encuentra un registro con los archivos que fueron mo-
dificados durante la realización del análisis de la URL tup27nyt.oiasdgfr.pw.

Debajo de lo anterior, se observan los detalles de los mutexes y las llaves de registro
que fueron modificadas.

Al final del reporte se muestra el proceso iexplore.exe lanzado durante el análisis,

que corresponde al proceso de Internet Explorer con el identificador de proceso 2031.

Snort Alert [1:31683:1]

El siguiente informe que se muestra en la figura 3.23, corresponde a una conexión
que Snort detectó como una actividad de un troyano, que generó el evento 31683. A
continuación se explicará el contenido del reporte que arrojó Cuckoo SandBox al ana-
lizar el dominio factorygood.net.

En la primera parte del reporte de Cuckoo, se muestra la categorı́a de la muestra

que fue analizada, la fecha en que se inició y terminó el análisis, la duración del análisis,
ası́ como la versión de Cuckoo con la que se realizó el análisis. En la sección correspon-
diente al análisis de la URL, se identifica que 5 motores antivirus detectaron el dominio
como un sitio web malicioso. Posterior de los detalles anteriores, son mostradas las
capturas de pantalla durante el análisis de la URL y se informa que no fue descargado
ningún archivo ni que se realizaron conexiones a sitios remotos.

En la sección del resúmen del comportamiento de la muestra se despliegan los ar-

chivos que sufrieron modificaciones al analizar la URL, lo que permite realizar una
trazabilidad sobre algún comportamiento sospechoso. Por otro lado, continuando con
los detalles del reporte generado, son informadas las exclusiones mutuas ası́ como las
modificaciones en el registro de Windows.

Para poder realizar el análisis de la URL tuvo que realizarse sobre el navegador

135
3. RECOLECCIÓN DE EVIDENCIA

Internet Explorer con su correspondiente proceso iexplore.exe con PID 2016.

136
 3.3 Eventos generados (Alertas)

137
3. RECOLECCIÓN DE EVIDENCIA

138
 3.3 Eventos generados (Alertas)

Figura 3.23: Análisis con Cuckoo SandBox del evento 31683. Fuente: Captura propia.

139
3. RECOLECCIÓN DE EVIDENCIA

Snort Alert [1:28801:2]

A continuación se muestra el informe realizado por Cuckoo Sandbox, respecto al
evento 28801. En la figura 3.24, se detalla que el objeto analizado fue un archivo, la
fecha de inicio y finalización del análisis del archivo Officekeyserial15.exe ası́ como la
duración total del análisis. Este análisis se realizó en la versión 1.1 de Cuckoo Sandbox.

En el apartado detalles del archivo se muestran las caracterı́sticas del archivo anali-
zado para su identificación. En esta sección se muestra el nombre del archivo analizado,
el tamaño del archivo (1232165 bytes), se identifica al archivo como un archivo ejecu-
table. Por otro lado, también se despliega el CRC32 del archivo Officekeyserial15.exe,
ası́ como las 4 diferentes funciones hash con las cuales es posible identificarlo.

Se muestra el valor del algoritmo de fuzzy hashing Ssdeep, y Yara no encontró una
clasificación para dicho malware. En la sección de Virus Total se muestra que 28 mo-
tores antivirus de 57 identificaron la muestra como malicioso. Durante el análisis se
realizaron 5 capturas de pantalla.

La sección análisis estático muestra información respecto a la estructura del archivo

ejecutable. Aquı́ se muestra información sobre la versión del archivo, las secciones que
conforman el archivo y las direcciones de memoria que tiene cada una de ellas. Al exa-
minar el módulo de importaciones del reporte de Cuckoo SandBox es posible detectar
las siguientes librerı́as:

kernel32.dll ole32.dll versión.dll

advapi32.dll oleaut32.dll
wininet.dll
comctl32.dll psapi.dll
comdlg32.dll shell32.dll
winmm.dll
gdi32.dll user32.dll
mpr.dll userenv.dll wsock32.dll

De la misma manera, se observa que el archivo malicioso descargó algunos archivos

adicionales. Los archivos descargados son:

data.bin aut2.tmp

sh.bin svchost.exe

aut1.tmp aut3.tmp

No hay ningún comportamiento de red para mostrar en la sección análisis de red.

Continuando con la revisión del reporte del evento 28801, es posible ver el historial de

140
 3.3 Eventos generados (Alertas)

los archivos que fueron modificados, información respecto a los mutexes, ası́ como las
llaves de registro.

141
3. RECOLECCIÓN DE EVIDENCIA

142
 3.3 Eventos generados (Alertas)

Figura 3.24: Análisis con Cuckoo SandBox del evento 28801. Fuente: Captura propia.

Al final del informe, mostrado en la figura anterior, se encuentran todos los proce-
sos involucrados durante el análisis del binario malicioso. Estos procesos se encuentran
separados por categorı́as. Esta tabla puede ser consultada seleccionando cada uno de
los diferentes procesos que fueron creados durante la ejecución de la muestra.

Snort Alert [1:27919:3]

Derivado del evento 27919 generado por el IDS Snort, se realizó un análisis en
Cuckoo Sandbox de la URL www.acaciadeperus.com.br/home/po/gate.php. Como se
observa en la figura 3.25. el informe se realizó en Cuckoo Sandbox versión 1.1, deta-
llando el tipo de objeto que fue analizado, en este caso una URL. También se muestra
la fecha de inicio y fin del análisis. El tiempo total del análisis fue de 2 minutos y 54
segundos.

Por tratarse de un objeto de tipo URL, en la sección de Virus Total, al realizar el

desglose de los motores antivirus que detectaron el dominio como malicioso, se especifica
que 3 motores antivirus de 62 fueron capaces de identificar la URL como un sitio
malicioso. Los antivirus que determinaron que el sitio es malicioso fueron:
BitDefender
Kaspersky
Websense ThreatSeeker

143
3. RECOLECCIÓN DE EVIDENCIA

144
 3.3 Eventos generados (Alertas)

145
3. RECOLECCIÓN DE EVIDENCIA

Figura 3.25: Análisis con Cuckoo SandBox del evento 27919. Fuente: Captura propia.

Continuando con el reporte de Cuckoo SandBox, se establece que no fueron des-

cargados archivos adicionales y que por ende la sección de análisis de red no tiene
información por mostrar.

En el resúmen del comportamiento de la muestra se despliegan los archivos mo-

dificados durante su análisis. Por otra parte, continuando con los detalles del reporte
generado, son informadas las exclusiones mutuas ası́ como las modificaciones en el re-
gistro de Windows.

146
 3.3 Eventos generados (Alertas)

Para poder realizar el análisis de la URL tuvo que realizarse sobre el navegor Inter-
net Explorer con su correspondiente proceso iexplore.exe con PID 2016.

Snort Alert [1:32125:1]

El reporte mostrado en la figura 3.26, corresponde al análisis del evento 32125 gene-
rado por el IDS Snort. A continuación se explicará el contenido del reporte que arrojó
Cuckoo SandBox al analizar el dominio update.kele55.com.

En la primera parte del reporte de Cuckoo, se muestran los detalles del análisis
realizado sobre la muestra, que en este caso en particular, se trató de una URL. Se
establece la fecha de inicio y término ası́ como la duración del análisis de la URL. De
la misma manera que los reportes mostrados anteriormente, el análisis de la muestra
se realizó sobre la versión 1.1 de Cuckoo SandBox.

En la sección de los detalles del análisis de la URL, se establece que únicamente

1 antivirus detectó el dominio como un sitio web malicioso. Posterior de los detalles
anteriores, son mostradas las capturas de pantalla durante el análisis de la URL y se
informa que no fue descargado ningún archivo ni que se realizaron conexiones a sitios
remotos.

En la sección resúmen del comportamiento de la muestra durante el análisis, es

mostrada la información sobre los archivos que sufrieron modificaciones en la máquina
huésped durante el proceso de análisis de la URL, ası́ como las exclusiones mutuas y
las modificaciones en el registro de Windows.

Al final del reporte de Cuckoo SandBox se muestra el identificador del proceso

iexplore.exe, que permitió poder examinar la URL a través de Internet Explorer.

147
3. RECOLECCIÓN DE EVIDENCIA

148
 3.3 Eventos generados (Alertas)

149
3. RECOLECCIÓN DE EVIDENCIA

Figura 3.26: Análisis con Cuckoo SandBox del evento 32125. Fuente: Captura propia.

Respecto a los eventos 30211, 28423 y 31527, los cuales fueron alertados por el
IDS Snort, en el payload capturado de éstos, no fue encontrada información útil como
para poder obtener una muestra y realizar el proceso de análisis de las muestras con la
SandBox.

150
 Capı́tulo 4

Automatización del proceso de análisis

de un evento

En este capı́tulo se explicará el proceso automatizado de análisis con la SandBox

Cuckoo de un evento alertado por el IDS Snort.

Para el administrador de una red este proceso simplifica, en gran medida, el análisis
de una posible amenaza que atente contra los activos crı́ticos de una organización. Ası́
de una manera sencilla y eficaz, podrá determinar sı́ se trata de un falso positivo o en
realidad se trata de un software malicioso detectado en la intranet de la organización
que él administra, para que pueda contenerlo y evitar ası́ su propagación. El análisis de
la muestra que contiene el evento alertado por el IDS Snort, es un proceso delicado, ya
que sı́ se realiza en un ambiente fı́sico y de producción; podrı́a propagarse a otros equi-
pos y sistemas; pudiendo poner en riesgo los activos y la información que reside en éstos.

Para alcanzar este objetivo, se realizó un programa en shell de Unix, el cual tiene
la función principal de obtener el archivo del payload del paquete descargado desde el
IDS de Snort o de un archivo con formato pcap, el cual se obtiene a través de cualquier
sniffer de paquetes como Wireshark, Windump entre otros. Una vez que dicho archivo
ejecutable ha sido obtenido desde el payload del paquete o desde el archivo pcap, éste
puede ser enviado de manera inmediata a la SandBox Cuckoo para su análisis en un
entorno seguro y aislado; evitando ası́ su propagación.

Dicho programa fue realizado para que funcione en la versión 2.9.6.2 del IDS de
Snort, Cuckoo SandBox 1.1, y que ambos se encuentren instalados en un sistema Ubuntu
12.04 Precise Pangolin. Es posible que sı́ se instalan versiones diferentes de los compo-
nentes mencionados anteriormente, el script no funcione correctamente, por lo que se
recomienda adaptarlo a nuevas versiones, para su correcto funcionamiento.

Otras tareas que se pueden realizar a través de este programa son las siguientes:

151
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

Eliminar los eventos de la Base de Datos del IDS Snort.

Comprobar el estado de Cuckoo SandBox.

Enviar una muestra para su análisis con Cuckoo SandBox.

Obtener información del repositorio de reportes a partir de las muestras analizadas

con Cuckoo SandBox, para su despliegue a través de una página web.

Habilitar la interfaz web de Cuckoo SandBox.

Para facilitar la lectura de los resultados del análisis de la muestra, se diseñó una
página web, en la que se despliegan los datos más relevantes que pueden dar un indicio
al administrador de red, que el IDS ha detectado una potencial amenaza, por lo cual
debe actuar inmediatamente para su mitigación de los equipos infectados y ası́ evitar
que se siga propagando o inclusive que usuarios maliciosos puedan tomar control del
equipo infectado.

4.1. Estructura y módulos del programa de automatiza-

ción
El programa de automatización fue desarrollado en Shell de Unix, debido a su
flexibilidad, rapidez y eficiencia con la que se pueden realizar tareas asignadas por parte
del usuario. El script hace uso de las herramientas GREP, SED y AWK, las cuales en
conjunto permiten el procesamiento de archivos e información basada en texto mediante
el uso de expresiones regulares. Como se mencionó anteriormente, el programa consta
de 6 módulos y en cada uno de ellos se pueden realizar diferentes tareas, las cuales se
pueden observar en la figura 4.1.

152
 4.1 Estructura y módulos del programa de automatización

Figura 4.1: Módulos principales. Fuente: Captura propia.

4.1.1. Módulo de análisis de archivos descargados del IDS Snort

Este módulo se encarga de obtener el archivo que se encuentra en el payload de un
paquete o desde un archivo con formato pcap. Tanto el payload del paquete como el
archivo .pcap son generados de forma automática cuando el IDS emite una alerta de
un evento que ha sido detectado como una posible amenaza, por lo que ambos tipos de
archivos pueden ser descargados a través de la interfaz gráfica (B.A.S.E.) del IDS Snort.

Como se muestra en la figura 4.2, una vez que el usuario ha seleccionado el módulo de
análisis de archivos descargados, debe elegir sı́ desea analizar el payload de un paquete
(archivo .bin) o sı́ requiere analizar un archivo .pcap.

Figura 4.2: Análisis de archivo con extensión .bin o .pcap. Fuente: Captura propia.

153
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

En las páginas 205 y 209 del apéndice B se presentan las funciones payload paquetes()
y archivos pcap() las cuales se encargan de realizar el análisis de los archivos .bin o .pcap
para la descarga del archivo que fue detectado como malicioso. Sı́ la descarga ha sido
exitosa, se le indicará al usuario la carpeta en la que ha sido guardada la muestra, como
se muestra a continuación en la figura 4.3:

Figura 4.3: Descarga de archivo desde un archivo .bin y .pcap. Fuente: Captura propia.

Después de 5 segundos, aparecerá un nuevo módulo en el que se le indica al usuario

sı́ desea realizar el análisis de la muestra en la SandBox. Para poder realizar dicho
análisis, Cuckoo SandBox debe estar ejecutándose y la máquina virtual invitada en la
que se analizará la muestra debe estar escuchando para que le sean asignadas tareas de
análisis. Para comprobar lo anterior, el usuario deberá seleccionar el módulo número 3,
el cual se explicará más adelante.

Finalmente al terminar este proceso de análisis de archivos descargados del IDS

Snort, el usuario elegirá sı́ desea repetir el proceso para otro archivo .pcap o .bin; por
lo que en caso de no repetir el proceso anterior, regresará al menú principal.

4.1.2. Módulo para eliminar los incidentes de la Base de Datos del

IDS Snort
Como se mencionó en el capı́tulo 2, el IDS Snort registra los incidentes en una Base
de Datos MySQL, para que puedan ser revisadas y analizadas las alertas a través de la
aplicación B.A.S.E.

Este módulo permite eliminar todos los registros de los incidentes almacenados en
las tablas que contiene la Base de Datos Snort. Es importante mencionar que una vez
que se proceda con esta tarea, no se podrá recuperar ningún evento capturado por el
IDS Snort.

Este módulo se basa en la función llamada borrar base de datos() (apéndice B, pági-
na 216) para poder realizar la eliminación de los registros capturados por el IDS Snort.
A su vez, esta función hace uso de dos programas adicionales, los cuales en conjunto

154
 4.1 Estructura y módulos del programa de automatización

permiten eliminar todos los registros tanto en las tablas de la base de datos, ası́ como
los archivos generados por Snort. Uno está realizado en shell de Unix, mientras que el
otro está desarrollado en PHP.

El primer programa del que se apoya la función anterior es eliminar eventos ids, el
cual tiene la función de eliminar todos los archivos generados por las alertas del IDS,
ası́ como ejecutar el programa realizado en PHP para eliminar los valores de las tablas
de la Base de Datos. Por otro lado, el programa eliminar tablas ids.php, realiza una
conexión a MySQL, en la cual se envı́a una serie de consultas para la eliminación de
datos de las siguientes tablas:

icmphdr opt event

data signature
iphdr tcphdr acid event

Una vez que se ha seleccionado este módulo, aparecerá un mensaje de confirmación

para la eliminación de las tablas como se muestra en la figura 4.4:

Figura 4.4: Mensaje para la eliminación de eventos de las tablas de la Base de Datos de
Snort. Fuente: Captura propia.

Cuando se confirma la eliminación de los eventos de la Base de Datos, comenzará

el proceso de borrado de los archivos que contienen las alertas del IDS Snort, ası́ como
los valores de las tablas de la Base de Datos Snort. El tiempo que se tome en eliminar
los eventos detectados por el IDS Snort, dependerá de la cantidad de información que
contengan las tablas de la base de datos.

Una vez terminado el proceso anterior, se mostrará un mensaje como el de la figura

4.5, en la que se confirma el número de elementos borrados que contenı́an las tablas
mencionadas anteriormente.

155
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

Figura 4.5: Borrado de información de las tablas de la Base de Datos Snort. Fuente:
Captura propia.

Finalmente el usuario será dirigido al menú principal para consultar otros módulos
y realizar otras tareas.

4.1.3. Módulo para comprobar que Cuckoo SandBox está en ejecución

El módulo para comprobar el estado de Cuckoo SandBox es fundamental para el
análisis automatizado de muestras, ya que sı́ la SandBox no está ejecutándose, o la
máquina virtual huésped no se encuentra en espera de tareas de análisis, será imposible
realizar el análisis del comportamiento de archivos sospechosos. Mediante este módulo
se pueden resolver estos inconvenientes.

Al ejecutar este módulo se permite determinar si los componentes de la SandBox

Cuckoo se encuentran listos y preparados para poder realizar el análisis de las muestras
obtenidas. En el caso de que Cuckoo SandBox se encuentre ejecutándose, este módulo
proporcionará el identificador del proceso para conocer el proceso correspondiente. En
la figura 4.6 se comprueba que Cuckoo se está ejecutando correctamente, al igual que la
máquina virtual huésped, donde se analizarán las muestras. Cabe aclarar que sı́ existe

156
 4.1 Estructura y módulos del programa de automatización

un problema con la interfaz virtual de la máquina huésped o la misma máquina virtual,

Cuckoo no puede iniciarse, por lo que no podrı́a tener un PID asociado que identifique
su correcta ejecución.

Figura 4.6: Cuckoo SandBox ejecutándose correctamente. Fuente: Captura propia.

Sı́ la SandBox no se encuentra en ejecución, este módulo permite notificarle esto

al usuario por lo que podrá ejecutarse de manera automática, como es mostrado a
continuación en la figura 4.7:

Figura 4.7: Notificación de que Cuckoo SandBox no está actualmente en ejecución.

Fuente: Captura propia.

Una vez que el usuario ha indicado que desea ejecutar Cuckoo SandBox, se desple-
gará una pantalla como la que se muestra en la figura 4.8, confirmando que la SandBox
está lista para poder realizar el proceso de analizar archivos sospechosos automática-
mente.

157
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

Figura 4.8: Activación de Cuckoo SandBox. Fuente: Captura propia.

Finalmente, la función status cuckoo() proporciona información sobre el PID de

Cuckoo y que permite comprobar la correcta de ejecución de Cuckoo SandBox, el cual
puede ser consultado en la página 217 del apéndice B.

4.1.4. Módulo para enviar una muestra para su análisis con Cuckoo
SandBox
Este módulo, depende de que Cuckoo SandBox se encuentre en ejecución. Como se
explicó previamente, la función del módulo anterior es validar la correcta ejecución de
Cuckoo SandBox, por lo que será de apoyo para poder enviar una muestra a la SandBox
para su análisis.

Sı́ se hace uso de este módulo y la SandBox no está ejecutándose, se mostrará un

mensaje en el que se indica que se puede iniciar la ejecución de Cuckoo en la opción 3
del menú principal.

Una vez que la SandBox se encuentra lista para que le sean asignadas tareas de
análisis, como se muestra en la figura 4.9, se debe ingresar el nombre de la muestra
que se desea analizar, y que no necesariamente tiene que ser un archivo obtenido de

158
 4.1 Estructura y módulos del programa de automatización

los archivos descargados a través de B.A.S.E., ya que puede ser cualquier archivo que
pudo ser obtenido a través de internet o cualquier otro medio y pueda ser dudoso.

Figura 4.9: Nombre de la muestra a analizar. Fuente: Captura propia.

Este módulo puede ser empleado para comprobar el comportamiento de archivos

ejecutables en los que se tenga duda acerca de su comportamiento, antes de que sean
instalados en un ambiente de producción. La única restricción es que los archivos que
se requieran analizar, deberán encontrarse en la carpeta Descargas.

Una vez que la muestra ha sido enviada para su análisis, como se observa en la figura
4.10, el programa notifica que se asignó una nueva tarea con su respectivo identificador,
ası́ como el nombre y tipo de la muestra; en este caso un archivo ejecutable llamado
DoomJuice.exe.

Figura 4.10: Análisis de un archivo ejecutable. Fuente: Captura propia.

Este módulo realiza este proceso a través de la función llamada

analisis archivo descargado(), en la que se puede observar su estructura en la página
219 del apéndice B.

159
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

4.1.5. Módulo para analizar el repositorio de reportes de malware

generados por Cuckoo SandBox
El módulo que a continuación se describe permite analizar un repositorio de reportes
de muestras previamente analizadas. La función analisis repositorio(), que se encuentra
en la página 220 del apéndice B, es la que analiza cada uno de los reportes con formato
html generados por Cuckoo SandBox. Para esta tarea, la función invoca la ejecución del
archivo analisis reportes cuckoo el cual obtiene las caracterı́sticas más relevantes de las
muestras analizadas por Cuckoo. Estas caracterı́sticas incluyen el directorio analizado,
la fecha actual del análisis del repositorio de Cuckoo, el nombre de la muestra, la fun-
ción hash que permite identificar unı́vocamente la muestra, el porcentaje de antivirus
que detectaron la muestra como maliciosa y finalmente la reputación que los usuarios
de la página de Virus Total le han asignado a la muestra (el rango de la reputación es
de -100 a 100, por lo que entre más negativa sea la reputación, mayor es el número de
usuarios que lo habrán clasificado como malicioso).

En la figura 4.11 se muestra dicho proceso:

160
 4.1 Estructura y módulos del programa de automatización

Figura 4.11: Proceso de análisis del repositorio de reportes de Cuckoo SandBox. Fuente:
Captura propia.

Al mismo tiempo que la información obtenida del repositorio de reportes de Cuckoo

es mostrada en pantalla, también se almacena con un formato especı́fico en un archivo
ubicado en el Escritorio llamado Información Muestras.txt. Este proceso es realizado,
para que la información pueda ser consultada a través de la página web, la cual fue
diseñada para la fácil comprensión de las caracterı́sticas más relevantes de cada una
de las muestras analizadas por Cuckoo SandBox. Esta funcionalidad se explicará en la
sección 4.2.

Cuando ha terminado el proceso, el usuario regresará al menú principal.

Para más detalles del archivo analisis reportes cuckoo consultar la página 225 del
apéndice B.

4.1.6. Módulo para habilitar el servicio web de Cuckoo SandBox

Cuckoo también cuenta con una interfaz gráfica para poder administrar todos los
reportes de las muestras y la revisión de estos informes desde una interfaz web. También

161
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

desde aquı́ se pueden enviar muestras para su análisis, de la misma manera en que se
realiza desde el módulo 4.

Este módulo permite comprobar que el servicio web de Cuckoo esté ejecutándose,
y en caso de no hacerlo, permite activar el servicio para la interfaz gráfica. Para ello,
la función web cuckoo comprueba sı́ ya existen los procesos del servicio de la interfaz
gráfica.

Cuando el usuario elige este módulo, el programa determina sı́ el servicio web de
Cuckoo está ejecutándose. Sı́ este servicio de Cuckoo SandBox se encuentra ejecutándo-
se, el programa devolverá el identificador de los procesos correspondientes a la interfaz
web. De acuerdo con lo descrito anteriormente, en la figura 4.12 se muestran los PID’s
del servicio web de Cuckoo.

Figura 4.12: Servicio web de Cuckoo SandBox en ejecución. Fuente: Captura propia.

Sı́ el servicio web no está activo, este módulo permite notificarle al usuario esto, por
lo que se podrá activar el servicio como se muestra a continuación en la figura 4.13:

Figura 4.13: Notificación de que el servicio web de Cuckoo SandBox no está

actualmente en ejecución. Fuente: Captura propia.

Cuando el usuario elige habilitar el servicio web de Cuckoo SandBox, aparece un

mensaje de confirmación que dicho servicio está activo y que puede ser accedido a éste

162
 4.2 Sistema de Consulta de Malware

desde cualquier navegador web, a través del puerto 8080. Esto se muestra a continuación
en la figura 4.14:

Figura 4.14: Servicio web de Cuckoo ejecutándose. Fuente: Captura propia.

El código fuente completo de este programa puede ser consultado en el apéndice B.

4.2. Sistema de Consulta de Malware

Para facilitar la revisión del impacto de las probables muestras obtenidas a través
de los archivos descargados desde el IDS y las muestras analizadas independientemen-
te, se desarrolló una página web, en la que se presentan de una manera ordenada y
organizada los datos más relevantes de éstos.

Para establecer un nivel mı́nimo de seguridad para el sistema de consulta de malwa-

re, se creó una nueva base de datos en MySQL para permitir la autenticación de usuarios
autorizados. Los pasos se describen a continuación:

Accedemos a MySQL a través del terminal de Ubuntu de la siguiente manera:

# mysql −u r o o t −p
Enter password : <Password r o o t de MySQL>

Una vez que se ingresó con el usuario root del manejador de base de datos MySQL,
se creó la base de datos usuario web.

mysql> create d a t a b a s e u s u a r i o w e b ;

Se selecciona la base de datos anterior y se crea una tabla llamada usuario con sus
respectivas columnas de la siguiente manera:

163
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

mysql> u s e u s u a r i o w e b ;
mysql> CREATE TABLE u s u a r i o ( i d i n t ( 1 ) , nombre VARCHAR( 2 0 ) , password BLOB
(40) , v i s i t c o u n t e r int ( 1 ) ) ;

Una vez creada la tabla usuario, se insertan los valores en la tabla que tendrá por
defecto el usuario administrador del sistema de consulta de malware:

mysql> INSERT INTO u s u a r i o VALUES ( ’ 1 ’ , ’<n o m b r e d e u s u a r i o > ’ , AES ENCRYPT

( ’<p a s s w o r d u s u a r i o > ’ , ’ k e y a e s ’ ) , ’ 0 ’ ) ;

Finalmente se validó la información que contiene la tabla usuario a través del si-
guiente query:

mysql> s e l e c t ∗ from u s u a r i o ;

La información contenida en la tabla usuario, es como la que se muestra en la figura

4.15:

Figura 4.15: Contenido de la tabla usuario. Fuente: Captura propia.

El sistema de consulta de malware está desarrollado con las tecnologı́as PHP, Ja-
vaScript, jQuery y Bootstrap; el cual está compuesto por los siguientes archivos, los
cuales se explican a continuación:

index.php: Archivo que permite autenticar las credenciales de un usuario con

las que se encuentran en la base de datos usuario web del servidor.

validacion.php: Archivo que es invocado cuando las credenciales del usuario son
incorrectas. Es desplegado un mensaje de aviso de error de autenticación.

principal.php: Página que es desplegada una vez que el usuario ha logrado

autenticarse de manera exitosa. En ella se muestra la información más relevante
de las muestras analizadas con la SandBox.

164
 4.2 Sistema de Consulta de Malware

reiniciar contador.php: Archivo que es invocado una vez que el usuario ha

decidido reestablecer el número de ingresos al sistema.

sendmail.php: Archivo que tiene la función de realizar el proceso de envı́o de

correo electrónico con el reporte de la muestra seleccionada.

sesion.class.php: Archivo que gestiona las sesiones.

cerrarsession.php: Archivo que tiene la función de destruir toda la información

registrada de una sesión.

Como se mencionó anteriormente, el módulo 5 del programa realizado en shell ge-

nera un archivo de texto, para que la información pueda ser consultada a través de la
página web, para una mayor comprensión de las caracterı́sticas de cada muestra anali-
zada en la SandBox. A continuación se explicará el detalle de la página web.

Como se observa en la figura 4.16, en la página de autenticación el usuario deberá

ingresar sus credenciales para poder tener acceso al sistema de consulta de malware.
Adicionalmente en esta página de inicio, el usuario indicará sı́ la consulta es realizada
debido un incidente de seguridad. Esto es de ayuda para llevar un registro de los inci-
dentes relacionados con algún malware o archivo malicioso detectado en algún activo.

Figura 4.16: Página de autenticación del sistema de consulta de malware. Fuente:

Captura propia.

165
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

Como lo muestra la figura 4.17, sı́ el usuario ingresa erróneamente sus credenciales,
será desplegado un mensaje como se muestra a continuación; en el cual le es negado el
acceso y deberá intentar nuevamente autenticarse al sistema.

Figura 4.17: Mensaje de fallo de autenticación. Fuente: Captura propia.

Una vez que el usuario logra autenticarse, obtiene acceso al sistema de consulta de
malware. Es importante validar que exista el archivo Información Muestras.txt y su
nombre sea el correcto, para que pueda ser leı́do por la página web, y los datos de este
puedan ser desplegados en la página web.

Sı́ es la primera vez que se ingresa al sistema, se debe ejecutar el módulo 5 del
programa de shell, para que se genere el archivo mencionado anteriormente y pueda ser
consumida la información de éste por la página web.

Sı́ el archivo no existe o su nombre es diferente al mencionado anteriormente, le será

notificado al usuario como se aprecia en la figura 4.18:

166
 4.2 Sistema de Consulta de Malware

Figura 4.18: Mensaje de error de lectura del archivo Información Muestras.txt. Fuente:
Captura propia.

Cuando el archivo existe y la autenticación es exitosa, el usuario tendrá acceso al

sistema de consulta de malware, en la que es desplegada la información más relevante
y que caracteriza a cada una de las muestras analizadas. Por orden de columnas la
información desplegada es la siguiente:

ID: Permite identificar el número de la muestra analizada.

Fecha de análisis: Fecha en la que se realizó el análisis del repositorio de reportes

de Cuckoo.

Nombre muestra: Nombre de la muestra analizada.

SHA256: Suma de verificación compuesta por 64 números hexadecimales, que

permite identificar la muestra.

Tasa de Detección de Antivirus: Porcentaje de antivirus disponibles en la

página de Virus Total que detectaron la muestra como una potencial amenaza.

Reputación Virus Total (-100 a 100): Calificación otorgada por los usua-
rios de Virus Total, en la que determinan que la muestra es identificada como
maliciosa.

Reporte de Cuckoo: Hipervı́nculo que conduce al reporte del análisis de la

muestra, generado por Cuckoo SandBox.

Enviar reporte por e-mail: Permite enviar el reporte de análisis de la muestra

por correo electrónico.

A continuación, en la figura 4.19, se muestra como es desplegada la información del

archivo Información Muestras.txt en la página web:

167
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

Figura 4.19: Despliegue de información en el sistema de consulta de malware. Fuente:

Captura propia.

Como se observa en la figura 4.20, la parte superior derecha de la página web

del sistema de consulta de malware contiene un grupo de opciones. A continuación se
describe la funcionalidad de estos:

Ingresar al repositorio de análisis de Cuckoo: Permite acceder a la interfaz

gráfica de Cuckoo SandBox en la que se administran las tareas de análisis de
Cuckoo SandBox.

Reiniciar contador de Consultas de Malware: Esta opción reinicia el con-

tador de ingresos al sistema de consulta de malware.

Cerrar Sesión: Permite cerrar sesión y salir del sistema.

168
 4.2 Sistema de Consulta de Malware

Figura 4.20: Menú de la página web. Fuente: Captura propia.

Cuando se desea compartir vı́a e-mail el reporte realizado por Cuckoo SandBox,
respecto a una muestra en especı́fico, se debe seleccionar la opción “Enviar” de la
última columna que aparece en la página web. Posterior a esto, como se aprecia a
continuación en la figura 4.21, se despliega una ventana modal, en la que el usuario
debe ingresar el e-mail del destinatario.

Figura 4.21: Envı́o de correo con el reporte de la muestra analizada. Fuente: Captura
propia.

Para el envı́o exitoso del e-mail, debe ser ingresado un correo electrónico válido. Sı́
el correo electrónico no es válido, el sistema desplegará el siguiente mensaje mostrado
en la figura 4.22:

169
4. AUTOMATIZACIÓN DEL PROCESO DE ANÁLISIS DE UN EVENTO

Figura 4.22: Dirección de e-mail no válida. Fuente: Captura propia.

Cuando es ingresado un correo electrónico válido de destinatario, el sistema infor-

mará que ha sido enviado exitosamente el reporte de análisis de la muestra, indicando
el nombre de la muestra correspondiente. A continuación, en la figura 4.23, es mostrado
el proceso descrito anteriormente. Es importante mencionar que el tiempo que tarde en
enviarse el correo dependerá del tamaño del reporte de Cuckoo, ası́ como la velocidad
de subida con la que cuente el servidor.

Figura 4.23: Envı́o exitoso de correo electrónico. Fuente: Captura propia.

Una vez que ha sido confirmado el envı́o exitoso del correo electrónico desde el siste-
ma de consulta de malware, se procede a revisar la bandeja de entrada del destinatario,
para la descarga y revisión del reporte de la muestra analizada con Cuckoo SandBox.
La figura 4.24 muestra la recepción del correo electrónico por parte del destinatario.

170
 4.2 Sistema de Consulta de Malware

El reporte es comprimido en un archivo con extensión .zip para facilitar el envı́o

a través del correo electrónico. El usuario destinatario, debe descomprimir el archivo
Reporte.zip para poder tener acceso al reporte realizado por Cuckoo SandBox. Por otro
lado, para revisión del reporte, se recomienda hacerlo con un navegador web moderno
como Google Chrome, Mozilla Firefox, Safari, entre otros; para su correcto despliegue
y visualización.

Figura 4.24: Correo electrónico con el reporte de la muestra recibido. Fuente: Captura
propia.

El código fuente de la página web, puede ser consultado en el apéndice C.

171
 Capı́tulo 5

Conclusiones

Finalizada la instalación del Sistema de Detección de Intrusos en el servidor (ver

capı́tulo 2), se realizaron pruebas de conectividad para comprobar el correcto funciona-
miento de dicho sistema en la intranet de la SEDESA, resultando contundentes. Para
ello fue necesario establecer un port mirroring en el switch core, en el que todo el tráfico
saliente del enlace troncal hacia el enlace WAN, fue capturado y enviado hacia el port
mirroring especı́fico donde se encontraba el IDS.

Una vez que se obtuvo la evidencia por parte del IDS, se implementó en el mismo
servidor la SandBox. Inicialmente se realizaron pruebas manuales para el análisis de los
eventos generados por Snort, pero este proceso fue tedioso y tardado, y más sı́ era ne-
cesario saber con prontitud su comportamiento e impacto que tendrı́a sobre los activos
de información; sin dejar de lado que para un usuario con pobres o nulos conocimientos
sobre administración Linux podrı́a ser muy complicado su correcta operación. Por lo
anterior, se pensó en la realización de un programa para automatizar el proceso de
recolección de evidencia y automatización del análisis.

El programa para automatizar el análisis de las alertas capturadas por el IDS a

través de Cuckoo SandBox, surgió de la necesidad de realizar este proceso de una ma-
nera práctica, ágil y eficiente; ya que con la ejecución de dicho programa, se tiene acceso
a muchas funcionalidades adicionales que permiten administrar y operar de una manera
sencilla este sistema. Como se explicó anteriormente (ver capı́tulo 4), este programa es
capaz de analizar archivos capturados por el IDS en busca de muestras que puedan
ser enviadas a Cuckoo para su análisis, además de tener la capacidad de comprobar el
estado y el servicio web de la SandBox, por mencionar algunos.

Para poder tener un panorama general de los análisis de las amenazas, se desarrolló
una página web principalmente en PHP, en la cual son desplegados de manera sen-
cilla y ordenada los datos más relevantes derivados del análisis con la SandBox. Por
ejemplo, en ella es capaz de visualizar el nombre de la muestra analizada, ası́ como su
respectiva suma de verificación (SHA-256) permitiendo identificar unı́vocamente a ésta.

173
5. CONCLUSIONES

Finalmente, son mostrados dos valores que proporcionan la evidencia necesaria para
identificar a la muestra como altamente potencial: la tasa de detección de antivirus y
la reputación de Virus Total. La página también cuenta con un módulo para poder
compartir mediante correo electrónico el reporte de análisis de la muestra.

Por lo anterior, la página web es una herramienta vital dentro del sistema, ya que
permite al administrador del sistema observar y determinar de una manera sencilla el
impacto negativo de la muestra analizada, descartando falsos positivos detectados por
el IDS.

Cuckoo SandBox es un servicio que pertenece al proyecto Honeynet, el cual, se de-

dica a la investigación de los últimos ataques de piratas informáticos y al desarrollo
de herramientas de seguridad de código abierto para mejorar la seguridad en Internet.
Este proyecto está formado por voluntarios de todo el mundo, que han contribuido a
luchar contra la propagación de malware.

Durante la implementación de la SandBox, surgieron problemas de incompatibili-

dad con las librerı́as requeridas por Cuckoo y las del sistema operativo original. Dicho
problema fue detectado en Debian 6 Squeeze. Después de investigar en diferentes foros
de discusión de Linux, se determinó que las librerı́as y paquetes basados en Python que
necesita Cuckoo para su implementación son incompatibles con dicha versión de siste-
ma operativo, ya que a su vez dependı́a de otras librerı́as y paquetes desarrollados por
terceros que no siempre resultaba exitosa su compilación y mucho menos su instalación.

Por lo anterior se concluye, que para Debian 6 Squeeze, por el momento, la imple-
mentación de Cuckoo SandBox no es compatible y funcional; por lo que se descartó la
posibilidad de que éste fuese el sistema operativo anfitrión del sistema.

El siguiente sistema operativo que se empleó para realizar la implementación de

ambos sistemas fue Ubuntu 12.04 Precise Pangolin. La implementación del IDS y de la
SandBox se realizó sin mayor contratiempo, resultando exitosa.

Inicialmente el proceso de implementación de ambos sistemas se realizó en un am-

biente virtual sobre VMware Workstation 10. La puesta en funcionamiento del IDS en
un ambiente virtual resultó exitoso, ya que se configuró una red de pruebas, en la que el
IDS monitoreaba y emitı́a alertas por el tráfico entre los diversos equipos virtuales que
se encontraban en el mismo segmento. Por otro lado, al realizar las pruebas de análisis
de muestras en Cuckoo SandBox no pudo ser exitoso, ya que para el análisis de mues-
tras necesita realizarse sobre la máquina huésped, la cual debe ser virtual. La versión
10 de VMware Workstation no es capaz de ejecutar una máquina huésped virtual sobre
una máquina anfitriona virtualizada, por lo que se puso en marcha la implementación
de ambos sistemas en un equipo fı́sico, resultando exitosa.

174
 Durante el tiempo que estuvo el IDS en la red de producción de la SEDESA no
sólo se lograron identificar alertas con actividades relacionadas al malware, sino que
se detectaron otros eventos, tales como ataques de DoS a páginas web nacionales y
extranjeras, ası́ como escaneos de segmentos y equipos de red, entre otros.

Como se planteó al inicio de este proyecto, el objetivo principal fue desarrollar e

implementar una SandBox sobre un sistema operativo Linux, el cual tiene la función
de analizar los eventos que son alertados por el IDS, y a su vez poder determinar el
nivel de criticidad e impacto que pueden llegar a tener sobre los activos de información
e incluso determinar sı́ los eventos generados por el IDS son falsos positivos.

Para poder brindar dicho servicio, ambos sistemas se pusieron en marcha en una
infraestructura de red funcional y en producción, lo que hizo posible que se pudiera
capturar cualquier tipo de actividad anómala, la cual se almacenó en bitácoras y en
una base de datos para su posterior análisis mediante Cuckoo SandBox.

Durante el desarrollo de este proyecto mejoré mis habilidades sobre la administra-

ción de sistemas Linux, al mismo tiempo que aprendı́ las diferentes arquitecturas en que
puede funcionar un Sistema de Detección de Intrusos. Por otro lado, también aprendı́
sobre las técnicas, herramientas y programas que emplean los piratas informáticos y
como éstas han ido evolucionando, haciéndose cada vez más sofisticadas.

Es importante mencionar que el desarrollo e implementación de este proyecto es

una versión mejorada y adaptada del proyecto Honeynet, ya que a diferencia del origi-
nal, éste emplea otro sistema (IDS) del cual obtiene información acerca del tráfico de
red en una organización, para posteriormente con ayuda del programa desarrollado en
shell de Unix, realizar el análisis del tráfico de una manera automatizada en la SandBox.

Durante el desarrollo del proyecto profundicé sobre la administración de Sistemas

Operativos, especı́ficamente sobre Linux y la manera en que un script de Unix puede
simplificar y automatizar los procesos. Por otro lado, este proyecto me permitió identi-
ficar las tres principales arquitecturas de un IDS, ası́ como sus alcances y las acciones
que deciden cuál de estas diferentes arquitecturas es mejor implantarse dentro de una
organización. Adicionalmente, este proyecto me permitió aprender sobre los problemas
de seguridad actuales. Lo anterior reflejó en mı́, un crecimiento profesional en mı́ carrera
en el ámbito de las redes de datos y como especialista en la seguridad de la información.

La realización de este proyecto responde a los esfuerzos de formación y generaración

de recursos humanos de la Universidad Nacional Autónoma de México y de la Facultad
de Ingenierı́a, capaces de responder y solucionar los problemas y necesidades actuales
de la sociedad.

La formación que me brindó la Facultad de Ingenierı́a me permitió obtener el conoci-

175
5. CONCLUSIONES

miento teórico, técnico y las habilidades necesarias para afrontar y aportar soluciones a
proyectos relacionados en el ámbito de las redes de datos y seguridad de la información.
Lo anterior fue posible gracias a materias como redes de datos, seguridad informática
I y II, ası́ como el programa de formación de becarios de la Unidad de Servicios de
Cómputo Académico de la Facultad de Ingenierı́a y a la currı́cula CCNA de Cisco que
es impartida en esta Facultad.

Para finalizar, el objetivo de esta tesis, es servir como guı́a a usuarios u organizacio-
nes que necesiten un sistema de bajo costo para la detección y análisis de actividades
maliciosas, que atente contra los activos de información, ası́ como la información que
reside en ellos; para poder actuar con prontitud ante una amenaza y lograr la conten-
ción de ésta, a fin de evitar su propagación para su posterior erradicación total de los
activos de información infectados.

176
 Glosario

adodb (p. 54) • Capa de abstracción de un programa al mismo tiempo en los

de bases de datos para PHP, que pemite sistemas Windows, lo que permiten que
a los programadores desarrollar aplicacio- estos se carguen y ejecuten más rápido
nes web con caracterı́sticas de portabili- y necesiten menos espacio en disco en el
dad. equipo.
archivo CPL (p. 36) • La extensión AWK (p. 152) • AWK es un lengua-
CPL hace referencia a un conjunto de ar- je de programación diseñado para el pro-
chivos de sistema asociados con el panel cesamiento de datos basados en texto, el
de control de Windows, que contiene con- cual resulta apropiado para extraer datos
troladores de red y sonido que emplean individuales. La potencia de este lenguaje
los sistemas operativos Windows. de programación radica en el uso exten-
archivo DLL (p. 36) • Un archivo sivo de expresiones regulares para la se-
DLL es una biblioteca que contiene código lección de los fragmentos de información
y datos que pueden ser utilizados por más apropiados.

B.A.S.E. (pp. 51, 53, 54, 55, 56, 153, intérprete, de código abierto, de archivos
154) • Basic Analysis and Security En- de salida en formato unified2, que permite
gine, es un motor de análisis basado en registrar las alertas en una base de datos.
PHP, que busca y procesa una base de Bootstrap (pp. 164, 235) • Conjun-
datos de eventos de seguridad generados to de herramientas de Twitter de código
por un IDS. abierto que simplifica el proceso de crea-
Barnyard (p. 50) • Barnyard es un ción del diseño de las páginas web.

177
C

Cisco Systems (p. 16) • Compañı́a de datos de forma segura.

lı́der en el área de TI a nivel mundial, Cloud Computing (p. 29) • Con-
que se encarga de la fabricación, venta, junto compartido de recursos fı́sicos y vir-
mantenimiento y consultorı́a de equipos tuales de cómputo, para ofrecer servicios
de telecomunicaciones. en demanda a través de Internet.
classful (p. 16) • Protocolo que no
incluye la máscara de subred en sus ac- convergencia (p. 16) • Estado en
tualizaciones. el que las tablas de enrutamientos de los
classless (p. 16) • Protocolo que in- routers se encuentran en un estado de uni-
cluye la máscara de subred en sus actua- formidad.
lizaciones. CRC32 (pp. 128, 140) • Cyclic Re-
clave GPG (pp. 41, 42) • GNU Pri- dundancy Check, es un código para la de-
vacy Guard o GPG; es una herramienta tección de errores y verificar la integridad
de cifrado y firmas digitales, para el envı́o de los datos.

drive-by-download (p. 135) • Tam- ción de malware en equipos informáticos,

bién conocido como drive-by-exploit es con el solo hecho de acceder a determina-
una técnica para la infección y propaga- do sitio web.

e-learning (p. 2) • Cursos que son exclusión mutua (pp. 130, 135, 146,
enviados utilizando recursos de red o a 147) • Método empleado en el que
través de Internet. un proceso evita el uso de recursos si-
enlace troncal (pp. 76, 173) • Un multáneos, excluyendo temporalmente a
enlace troncal es un enlace punto a punto todos los demás procesos, para usar un
entre dos dispositivos de red, que trans- recurso compartido en común.
portan más de una VLAN.

178
F

falso positivo (pp. 77, 83, 151, 174, temática que se realiza sobre cualquier
175) • Falla o error de cualquier softwa- conjunto de datos de cualquier longitud.
re de detección de virus, en el que infor- La salida de dicha operación es una huella
ma que un archivo se encuentra infectado, digital de tamaño fijo para ese conjunto
cuando en realidad el archivo está libre de de datos que se les aplicó la función hash.
infecciones de virus informáticos. fuzzy hashing (pp. 63, 128, 140) •
Fast Pattern Matcher (pp. 99, 101, Técnica que divide un archivo en cantida-
102, 104, 105, 107, 108, 110, 111) • El des iguales de bytes y en las que por cada
Fast Pattern Matcher se emplea para se- grupo calcula un hash. A partir de todos
leccionar sólo aquellas reglas que coinci- los hash obtenidos, se calcula un hash fi-
dieron usando el contenido de la regla, sı́ nal, que representará el total del archivo.
y sólo sı́, el contenido fue encontrado en Es este hash el que compara con otros pa-
la regla. ra obtener la similitud con otros archivos.
función hash (pp. 128, 140, 160) • Los algoritmos más conocidos son Ssdeep
Una función hash es una operación ma- y Sdhash.

gateway interior (p. 16) • Proto- bre.

colos usados dentro de un solo sistema GREP (p. 152) • GREP es una he-
autónomo. rramienta de la lı́nea de comandos desa-
Google Summer of Code (pp. 37, rrollada para ser utilizada en los sistemas
38) • Programa anual, en el que la com- UNIX. Ésta, toma un patrón inicial pa-
pañı́a Google gratifica a los participantes ra realizar la búsqueda en un archivo y
que puedan completar el desarrollo de un mostrar las lı́neas que coincidan con di-
proyecto de programación de software li- cho patrón.

ingenierı́a social (p. 25) • Técnica de redes interconectadas. La internetwork

que emplean algunos individuos para ob- más conocida, utilizada y accedida por el
tener información, acceso o privilegios en público en general es Internet.
los sistemas de información mediante en- ISP (p. 12) • Un Proveedor de Ser-
gaños a usuarios legı́timos; para realizar vicios de Internet, brinda conexiones de
algún daño. Internet a sus clientes a través de diferen-
internetwork (p. 3) • Malla global tes tecnologı́as.

179
J

JavaScript (pp. 164, 235) • Lengua- jQuery (pp. 164, 235) • Biblioteca
je de programación, que se ejecuta del la- de JavaScript que permite simplificar el
do del cliente para permitir efectos atrac- desarrollo de páginas web, la animación,
tivos y dinámicos en las páginas web. y la gestión de eventos.

llamada al sistema (p. 82) • Una realiza una aplicación para solicitar un
llamada al sistema es un mecanismo que servicio al kernel del sistema operativo.

métrica (p. 16) • Valor utilizado por misma red remota.

los protocolos de enrutamiento para asig- multiplexación (p. 8) • Es la com-
nar costos a fin de alcanzar las redes re- binación de dos o más canales de comu-
motas. La métrica se utiliza para deter- nicación sobre un mismo medio de trans-
minar qué ruta tiene mayor preferencia misión.
cuando existen múltiples rutas hacia la

PHP (pp. 36, 43, 52, 155, 164, 173) chivos multimedia (audio, video, texto y
• Lenguaje popular de programación de notas) que pueden descargarse desde In-
código abierto, diseñado para el desarro- ternet mediante una previa suscripción,
llo web y que puede ser embebido dentro que pueden reproducirse posteriormente
de páginas HTML. en una computadora o un reproductor di-
podcasts (p. 2) • Distribución de ar- gital.

180
R

Rapid7 (p. 37) • Proveedor de se- implementar un enfoque activo basada en

guridad de la información y soluciones de un análisis de seguridad cibernética.
análisis, que permite a las organizaciones

SED (p. 152) • SED es una potente sistema autónomo (p. 16) • Gru-
herramienta de la lı́nea de comandos para po de redes bajo el control administra-
los sistemas UNIX, la cual permite modi- tivo de una única entidad, que presenta
ficar el contenido de las diferentes lı́neas una polı́tica de enrutamiento propia e in-
de un archivo, con base a una serie de co- dependiente.
mandos o expresiones regulares definidos.

token (p. 26) • Dispositivo electróni- de un usuario para poder tener acceso a
co que facilita el proceso de autenticación un sistema informático.

URI (pp. 91, 99, 104, 114) • Son las cual es una cadena corta de caracteres que
siglas de Uniform Resource Identifier, la sirve para identificar recursos en internet.

VirtualBox (pp. 66, 67, 71, 72, 74, Un volcado de memoria es el proceso en
79) • VirtualBox es una software de el que el contenido de la memoria es des-
virtualización de sistemas operativos, en plegado y almacenado en caso de que un
el que podremos crear sistemas invitado- sistema o aplicación colapse. Este proceso
s/huéspedes. permite a los desarrolladores de software
VLSM (p. 16) • Máscara de Subred y administradores de sistemas, diagnosti-
de Longitud Variable. car, identificar y resolver el problema que
volcado de memoria (pp. 36, 74) • condujo al fallo del sistema o aplicación.

181
 Bibliografı́a

[1] Automated malware analysis. https://www.cuckoosandbox.org/. Consultado en

agosto de 2014.

[2] Cisco certified network associate routing and switching currı́cula versión 5.
www.netacad.com. Consultado en febrero de 2016.

[3] Create beautiful looking css registration forms. http://codeconvey.com/html-css-

registration-forms/. Consultado en marzo de 2016.

[4] The honeynet project. http://www.honeynet.org/project. Consultado en enero y

febrero de 2014.

[5] Introducción al conjunto de protocolos tcp/ip. https://docs.oracle.com/cd/E19957-

01/820-2981/6nei0r0r9/index.html. Consultado en febrero y marzo de 2016.

[6] Oracle vm virtualbox. https://www.virtualbox.org/. Consultado en agosto de 2014.

[7] Snort - network intrusion detection and prevention system. https://www.snort.org/.

Consultado en mayo y junio de 2014.

[8] Snort users manual. http://manual.snort.org/. Consultado en mayo y junio de

2014.

[9] (2013). Iso/iec 27002:2013. In Information technology — Security techniques —

Code of practice for information security controls, pages 30–38. International Orga-
nizational for Standardization, 2 edition.

[10] Alder, R., Babbin, J., Beale, J., Doxtater, A., Foster, J. C., Kohlenberg, T., and
Rash, M. (2004). Snort 2.1 Intrusion Detection Second Edition, chapter Intrusion De-
tection Systems, Introducing Snort 2.1, pages 2, 9–14, 20–23, 25–27, 67–69. Syngress
Publishing, Inc, 2 edition.

[11] Alder, R., Carter, D. E. F., Foster, J. C., Jonkman, M., Marty, R., and Seagren,
E. (2007). Snort IDS and IPS Toolkit, chapter Intrusion Detection Systems, pages
8–11. Syngress Publishing, Inc.

183
BIBLIOGRAFÍA

[12] Beale, J., Foster, J. C., Posluns, J., and Caswell, B. (2003). Snort 2.0 Intrusion
Detection, chapter Intrusion Detection Systems, Advanced Snort, pages 4–6, 478.
Syngress Publishing, Inc.

[13] Galindo, C. J. (2009). Diseño y optimización de un Sistema de Detección de Intru-

sos Hı́brido, chapter Snort hı́brido, pages 71–75. Editorial Universidad de Almerı́a.

[14] https://cryptome.org (2013). Fundamental Security Concepts, chapter Fundamen-

tal Security Concepts, pages 4–11, 18–20. Cryptome. Consultado en internet en
febrero de 2016.

[15] Huerta, A. V. (2012). Seguridad en UNIX y redes, chapter Introducción y conceptos

previos, pages 2–10. GNU Free Documentation License. Versión 2.1.

[16] López, J. G. (2009). Optimización de Sistemas de Detección de Intrusos en Red,

utilizando técnicas computacionales avanzadas, chapter Snort, pages 27–35. Editorial
Universidad de Almerı́a.

[17] Stallings, W. (2000). Comunicaciones y Redes de Computadoras, chapter Intro-

ducción, Tecnologı́as LAN, pages 17–19, 403–407. Prentice-Hall, 6 edition.

[18] Tanenbaum, A. S. (2003). Redes de computadoras, chapter Introducción, pages

3–5, 37–44. Pearson Educacion, 4 edition.

[19] Whitman, M. E. and Mattord, H. J. (2011). Principles of Information Security,

chapter Introduction to Information Security, The Need for Security, Risk Manage-
ment, Security Technology: Firewalls and VPNs, pages 1–13, 67, 140–141, 147, 149,
164, 246–247, 447. Cengage Learning, 4 edition.

184
 Apéndice A

Archivos de configuración de Cuckoo

SandBox

En este apartado se establecen los archivos de configuración de Cuckoo SandBox,

mencionados en la sección 2.2.6 de esta tesis.

Archivo auxiliary.conf

[ sniffer ]
# Enable or d i s a b l e t h e u s e o f an e x t e r n a l s n i f f e r ( tcpdump ) [ y e s /no ] .
enabled = yes

# S p e c i f y t h e p a t h t o your l o c a l i n s t a l l a t i o n o f tcpdump . Make s u r e t h i s

# path i s c o r r e c t .
tcpdump = / u s r / s b i n /tcpdump

# S p e c i f y t h e n e t w o r k i n t e r f a c e name on which tcpdump s h o u l d monitor t h e

# t r a f f i c . Make s u r e t h e i n t e r f a c e i s a c t i v e .
i n t e r f a c e = vboxnet0

# S p e c i f y a B e r k e l e y p a c k e t f i l t e r t o p a s s t o tcpdump .
# b p f = n o t arp

185
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

Archivo cuckoo.conf

[ cuckoo ]
# Enab le or d i s a b l e s t a r t u p v e r s i o n c h e c k . When e n a b l e d , Cuckoo w i l l
connect
# t o a remote l o c a t i o n t o v e r i f y w h e t h e r t h e r u n n i n g v e r s i o n i s t h e l a t e s t
# one a v a i l a b l e .
v e r s i o n c h e c k = on

# I f t u r n e d on , Cuckoo w i l l d e l e t e t h e o r i g i n a l file after its analysis

# has been c o m p l e t e d .
delete original = off

# I f t u r n e d on , Cuckoo w i l l d e l e t e t h e copy o f t h e o r i g i n a l f i l e in the

# l o c a l b i n a r i e s r e p o s i t o r y a f t e r t h e a n a l y s i s has f i n i s h e d . (On ∗ n i x t h i s
# w i l l also i n v a l i d a t e the f i l e c a l l e d ” b i n a r y ” i n each a n a l y s i s d i r e c t o r y
,
# as t h i s i s a s y m l i n k . )
delete bin copy = off

# S p e c i f y t h e name o f t h e machinery module t o use , t h i s module w i l l

# d e f i n e t h e i n t e r a c t i o n b e t w e e n Cuckoo and your v i r t u a l i z a t i o n s o f t w a r e
# of choice .
machinery = v i r t u a l b o x

# Enab le c r e a t i o n o f memory dump o f t h e a n a l y s i s machine b e f o r e s h u t t i n g

# down . Even i f t u r n e d o f f , t h i s f u n c t i o n a l i t y can a l s o be e n a b l e d a t
# s u b m i s s i o n . C u r r e n t l y a v a i l a b l e f o r : V i r t u a l B o x and l i b v i r t modules (KVM
).
memory dump = o f f

# Enab le a u t o m a t i c a l l y re−s c h e d u l e o f ” b r o k e n ” t a s k s each s t a r t u p .

# Each t a s k found i n s t a t u s ” p r o c e s s i n g ” i s re−queued f o r a n a l y s i s .
reschedule = off

186
# Enable p r o c e s s i n g o f r e s u l t s w i t h i n t h e main cuckoo p r o c e s s .
# This i s t h e d e f a u l t b e h a v i o r b u t can be s w i t c h e d o f f f o r s e t u p s t h a t
# r e q u i r e h i g h s t a b i l i t y and p r o c e s s t h e r e s u l t s i n a s e p a r a t e t a s k .
p r o c e s s r e s u l t s = on

# L i m i t t h e amount o f a n a l y s i s j o b s a Cuckoo p r o c e s s g o e s t h r o u g h .
# This can be used t o g e t h e r w i t h a watchdog t o m i t i g a t e r i s k o f memory
leaks .
max analysis count = 0

# Minimum amount o f f r e e s p a c e ( i n MB) a v a i l a b l e b e f o r e s t a r t i n g a new

task .
# This t r i e s t o a v o i d f a i l i n g an a n a l y s i s b e c a u s e t h e r e p o r t s can ’ t be
written
# due out−of −d i s k s p a c e e r r o r s . S e t t i n g t h i s v a l u e t o 0 d i s a b l e s t h e c h e c k .
# ( Note : t h i s f e a t u r e i s c u r r e n t l y n o t s u p p o r t e d under Windows . )
f r e e s p a c e = 64

# Temporary d i r e c t o r y c o n t a i n i n g t h e f i l e s u p l o a d e d t h r o u g h Cuckoo
interfaces
# ( web . py , a p i . py , Django web i n t e r f a c e ) .
tmppath = /tmp

[ resultserver ]
# The R e s u l t S e r v e r i s used t o r e c e i v e i n r e a l time t h e b e h a v i o r a l l o g s
# p ro d uc e d by t h e a n a l y z e r .
# S p e c i f y t h e IP a d d r e s s o f t h e h o s t . The a n a l y s i s machines s h o u l d be a b l e
# t o c o n t a c t t h e h o s t t h r o u g h such a d d r e s s , so make s u r e i t ’ s v a l i d .
# NOTE: i f you s e t r e s u l t s e r v e r IP t o 0 . 0 . 0 . 0 you have t o s e t t h e o p t i o n
# ‘ r e s u l t s e r v e r i p ‘ f o r a l l your v i r t u a l machines i n machinery
configuration .
ip = 192.168.56.1

# S p e c i f y a p o r t number t o b i n d t h e r e s u l t s e r v e r on .
p o r t = 2042

187
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

# S h o u l d t h e s e r v e r w r i t e t h e l e g a c y CSV f o r m a t ?
# ( i f you have any custom p r o c e s s i n g on t h o s e , s w i t c h t h i s on )
store csvs = off

# Maximum s i z e o f u p l o a d e d f i l e s from VM ( s c r e e n s h o t s , dropped f i l e s , l o g )

# The v a l u e i s e x p r e s s e d i n b y t e s , by d e f a u l t 10Mb.
u p l o a d m a x s i z e = 10485760

[ processing ]
# S e t t h e maximum s i z e o f a n a l y s i s ’ s g e n e r a t e d f i l e s t o p r o c e s s .
# This i s used t o a v o i d t h e p r o c e s s i n g o f b i g f i l e s which can b r i n g memory
leak .
# The v a l u e i s e x p r e s s e d i n b y t e s , by d e f a u l t 100Mb.
a n a l y s i s s i z e l i m i t = 104857600

# Enab le or d i s a b l e DNS l o o k u p s .
r e s o l v e d n s = on

[ database ]
# Specify the database connection s t r i n g .
# Examples , s e e d o c u m e n t a t i o n f o r more :
# s q l i t e : / / / f o o . db
# p o s t g r e s q l : / / f o o : b a r @ l o c a l h o s t : 5 4 3 2 / mydatabase
# mysql : / / f o o : b a r @ l o c a l h o s t / mydatabase
# I f empty , d e f a u l t i s a SQLite i n db / cuckoo . db .
c o n n e c t i o n = mysql : / / s n o r t : s n o r t @ l o c a l h o s t / cuckoo

# Database c o n n e c t i o n t i m e o u t i n s e c o n d s .
# I f empty , d e f a u l t i s s e t t o 60 s e c o n d s .
timeout =

[ timeouts ]
# S e t t h e d e f a u l t a n a l y s i s t i m e o u t e x p r e s s e d i n s e c o n d s . This v a l u e w i l l
be

188
# used t o d e f i n e a f t e r how many s e c o n d s t h e a n a l y s i s w i l l t e r m i n a t e u n l e s s
# otherwise s p e c i f i e d at submission .
d e f a u l t = 120

# Set the c r i t i c a l timeout expressed in seconds . After t h i s timeout i s h i t

# Cuckoo w i l l c o n s i d e r t h e a n a l y s i s f a i l e d and i t w i l l shutdown t h e
machine
# no m a t t e r what . When t h i s happens t h e a n a l y s i s r e s u l t s w i l l most l i k e l y
# be l o s t . Make s u r e t o have a c r i t i c a l t i m e o u t g r e a t e r than t h e
# d e f a u l t timeout .
c r i t i c a l = 600

# Maximum time t o w a i t f o r v i r t u a l machine s t a t u s change . For example when

# s h u t t i n g down a vm . D e f a u l t i s 300 s e c o n d s .
v m s t a t e = 300

189
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

Archivo memory.conf

# Volatility configuration

# Basic s e t t i n g s
[ basic ]
# P r o f i l e t o a v o i d w a s t i n g time i d e n t i f y i n g i t
g u e s t p r o f i l e = WinXPSP2x86
# D e l e t e memory dump a f t e r v o l a t i l i t y p r o c e s s i n g .
delete memdump = no

# L i s t o f a v a i l a b l e modules
# e n a b l e d : e n a b l e t h i s module
# f i l t e r : u s e f i l t e r s t o remove b e n i g n s y s t e m d a t a from t h e l o g s
# F i l t e r s a r e d e f i n e d i n t h e mask s e c t i o n a t b e l o w

# Scans f o r h i d d e n / i n j e c t e d code and d l l s

# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#m a l f i n d
[ malfind ]
enabled = yes
f i l t e r = on

# L i s t s hooked a p i i n u s e r mode and k e r n e l s p a c e

# E x p e c t i t t o be v e r y s l o w when e n a b l e d
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#a p i h o o k s
[ apihooks ]
e n a b l e d = no
f i l t e r = on
# L i s t s o f f i c i a l p r o c e s s e s . Does n o t d e t e c t h i d d e n p r o c e s s e s
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReference23#p s l i s t
[ pslist ]
enabled = yes
filter = off

# L i s t s h i d d e n p r o c e s s e s . Uses s e v e r a l t r i c k s t o i d e n t i f y them

190
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#p s x v i e w
[ psxview ]
enabled = yes
filter = off

# Show c a l l b a c k s
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#c a l l b a c k s
[ callbacks ]
enabled = yes
filter = off

# Show i d t
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#i d t
[ idt ]
enabled = yes
filter = off

# Show t i m e r s
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#t i m e r s
[ timers ]
enabled = yes
filter = off

# Show m e s s a g e h o o k s
# E x p e c t i t t o be v e r y s l o w when e n a b l e d
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReferenceGui23#
messagehooks
[ messagehooks ]
e n a b l e d = no
filter = off

# Show s i d s
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReference23#g e t s i d s
[ getsids ]
enabled = yes

191
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

filter = off

# Show p r i v i l e g e s
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReference23#p r i v s
[ privs ]
enabled = yes
filter = off

# D i s p l a y p r o c e s s e s ’ l o a d e d DLLs− Does n o t d i s p l a y h i d d e n DLLs

# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReference23# d l l l i s t
[ dlllist ]
enabled = yes
f i l t e r = on

# L i s t open h a n d l e s o f p r o c e s s e s
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReference23#h a n d l e s
[ handles ]
enabled = yes
f i l t e r = on

# D i s p l a y s p r o c e s s e s ’ l o a d e d DLLs − Even h i d d e n one ( u n l i n k e d from PEB

linked l i s t )
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#
ldrmodules
[ ldrmodules ]
enabled = yes
f i l t e r = on

# Scan f o r Mutexes ( w h o l e s y s t e m )
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReference23#mutantscan
[ mutantscan ]
enabled = yes
f i l t e r = on

# L i s t d e v i c e s and d r i v e r s

192
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#
devicetree
[ devicetree ]
enabled = yes
f i l t e r = on

# Scan f o r s e r v i c e s
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i /CommandReferenceMal23#s v c s c a n
[ svcscan ]
enabled = yes
f i l t e r = on

# Scan f o r k e r n e l d r i v e r s ( i n c l u d e s hidden , u n l o a d e d )
# h t t p : / / code . g o o g l e . com/p/ v o l a t i l i t y / w i k i / CommandReference23#modscan
[ modscan ]
enabled = yes
f i l t e r = on

# Masks . Data t h a t s h o u l d n o t be l o g g e d
# J u s t g e t t h i s i n f o r m a t i o n from your p l a i n VM S n a p s h o t ( w i t h o u t r u n n i n g
malware )
# This w i l l f i l t e r o u t unwanted i n f o r m a t i o n i n t h e l o g s
[ mask ]
e n a b l e d = no
pid generic =

193
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

Archivo processing.conf

# Enab le or d i s a b l e t h e a v a i l a b l e p r o c e s s i n g modules [ on/ o f f ] .

# I f you add a custom p r o c e s s i n g module t o your Cuckoo s e t u p , you have t o
add
# a d e d i c a t e d e n t r y i n t h i s f i l e , or i t won ’ t be e x e c u t e d .
# You can a l s o add a d d i t i o n a l o p t i o n s under t h e s e c t i o n o f your module and
# t h e y w i l l be a v a i l a b l e i n your Python c l a s s .

[ analysisinfo ]
enabled = yes

[ behavior ]
enabled = yes

[ debug ]
enabled = yes

[ dropped ]
enabled = yes

[ memory ]
e n a b l e d = no

[ network ]
enabled = yes
[ static ]
enabled = yes

[ strings ]
enabled = yes

[ targetinfo ]
enabled = yes

194
[ virustotal ]
enabled = yes
# Add your V i r u s T o t a l API k e y h e r e . The d e f a u l t API key , k i n d l y p r o v i d e d
# by t h e V i r u s T o t a l team , s h o u l d e n a b l e you w i t h a s u f f i c i e n t t h r o u g h p u t
# and w h i l e b e i n g s h a r e d w i t h a l l our u s e r s , i t s h o u l d n ’ t a f f e c t your u s e .
key = a 0 2 8 3 a 2 c 3 d 5 5 7 2 8 3 0 0 d 0 6 4 8 7 4 2 3 9 b 5 3 4 6 f b 9 9 1 3 1 7 e 8 4 4 9 f e 4 3 c 9 0 2 8 7 9 d 7 5 8 0 8 8

195
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

Archivo reporting.conf

# Enab le or d i s a b l e t h e a v a i l a b l e r e p o r t i n g modules [ on/ o f f ] .

# I f you add a custom r e p o r t i n g module t o your Cuckoo s e t u p , you have t o
add
# a d e d i c a t e d e n t r y i n t h i s f i l e , or i t won ’ t be e x e c u t e d .
# You can a l s o add a d d i t i o n a l o p t i o n s under t h e s e c t i o n o f your module and
# t h e y w i l l be a v a i l a b l e i n your Python c l a s s .

[ jsondump ]
enabled = yes

[ reporthtml ]
enabled = yes

[ mmdef ]
e n a b l e d = no

[ maec40 ]
e n a b l e d = no
mode = o v e r v i e w
p r o c e s s t r e e = true
output handles = false
s t a t i c = true
s t r i n g s = true
v i r u s t o t a l = true
[ mongodb ]
e n a b l e d = no
host = 1 2 7 . 0 . 0 . 1
p o r t = 27017

[ hpfclient ]
e n a b l e d = no
host =
p o r t = 10000

196
ident =
secret =
channel =

197
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

Archivo virtualbox.conf

[ virtualbox ]
# S p e c i f y which V i r t u a l B o x mode you want t o run your machines on .
# Can be ” g u i ” , ” s d l ” or ” h e a d l e s s ” . R e f e r t o V i r t u a l B o x ’ s o f f i c i a l
# documentation to understand the d i f f e r e n c e s .
mode = g u i

# Path t o t h e l o c a l i n s t a l l a t i o n o f t h e VBoxManage u t i l i t y .
path = / u s r / b i n /VBoxManage

# S p e c i f y a comma−s e p a r a t e d l i s t o f a v a i l a b l e machines t o be used . For

each
# s p e c i f i e d ID you have t o d e f i n e a d e d i c a t e d s e c t i o n c o n t a i n i n g t h e
details
# on t h e r e s p e c t i v e machine . (E . g . cuckoo1 , cuckoo2 , cuckoo3 )
machines = cuckoo1

[ cuckoo1 ]
# S p e c i f y t h e l a b e l name o f t h e c u r r e n t machine as s p e c i f i e d i n your
# VirtualBox con figur ation .
l a b e l = cuckoo1

# S p e c i f y t h e o p e r a t i n g s y s t e m p l a t f o r m used by c u r r e n t machine
# [ windows / darwin / l i n u x ] .
p l a t f o r m = windows

# S p e c i f y t h e IP a d d r e s s o f t h e c u r r e n t v i r t u a l machine . Make s u r e t h a t
the
# IP a d d r e s s i s v a l i d and t h a t t h e h o s t machine i s a b l e t o r e a c h i t . I f
not ,
# the analysis w i l l fail .
ip = 192.168.56.101

198
# ( O p t i o n a l ) S p e c i f y t h e s n a p s h o t name t o u s e . I f you do n o t s p e c i f y a
snapshot
# name , t h e V i r t u a l B o x MachineManager w i l l u s e t h e c u r r e n t s n a p s h o t .
# Example ( S n a p s h o t 1 i s t h e s n a p s h o t name ) :
# snapshot = Snapshot1

# ( O p t i o n a l ) S p e c i f y t h e name o f t h e n e t w o r k i n t e r f a c e t h a t s h o u l d be us e d
# when dumping n e t w o r k t r a f f i c from t h i s machine w i t h tcpdump . I f
specified ,
# o v e r r i d e s t h e d e f a u l t i n t e r f a c e s p e c i f i e d i n cuckoo . c o n f
# Example ( v b o x n e t 0 i s t h e i n t e r f a c e name ) :
# i n t e r f a c e = vboxnet0

# ( O p t i o n a l ) S p e c i f y t h e IP o f t h e R e s u l t S e r v e r , as your v i r t u a l machine
sees i t .
# The R e s u l t S e r v e r w i l l a l w a y s b i n d t o t h e a d d r e s s and p o r t s p e c i f i e d i n
cuckoo . conf ,
# however you c o u l d s e t up your v i r t u a l n e t w o r k t o u s e NAT/PAT, so you can
s p e c i f y here
# t h e IP a d d r e s s f o r t h e R e s u l t S e r v e r as your machine s e e s i t . I f you don
’ t s p e c i f y an
# a d d r e s s here , t h e machine w i l l u s e t h e d e f a u l t v a l u e from cuckoo . c o n f .
# NOTE: i f you s e t t h i s o p t i o n you have t o s e t r e s u l t s e r v e r IP t o 0 . 0 . 0 . 0
i n cuckoo . c o n f .
# Example :
# r e s u l t s e r v e r i p = 192.168.56.1

# ( O p t i o n a l ) S p e c i f y t h e p o r t f o r t h e R e s u l t S e r v e r , as your v i r t u a l
machine s e e s i t .
# The R e s u l t S e r v e r w i l l a l w a y s b i n d t o t h e a d d r e s s and p o r t s p e c i f i e d i n
cuckoo . conf ,
# however you c o u l d s e t up your v i r t u a l n e t w o r k t o u s e NAT/PAT, so you can
s p e c i f y here
# t h e p o r t f o r t h e R e s u l t S e r v e r as your machine s e e s i t . I f you don ’ t
specify a port

199
A. ARCHIVOS DE CONFIGURACIÓN DE CUCKOO SANDBOX

# here , t h e machine w i l l u s e t h e d e f a u l t v a l u e from cuckoo . c o n f .

# Example :
# r e s u l t s e r v e r p o r t = 2042

# ( O p t i o n a l ) S e t your own t a g s . These a r e comma s e p a r a t e d and h e l p t o

identify
# s p e c i f i c VMs. You can run s a m p l e s on VMs w i t h t a g you r e q u i r e .
# t a g s = windows xp sp3 ,32 b i t , a c r o b a t r e a d e r 6

200
 Apéndice B

Código fuente para la automatización del

análisis de una muestra con Cuckoo
SandBox y Administración de eventos
del IDS Snort.

En este apartado es presentado el código fuente completo del programa realizado

en Shell de Unix, para la automatización del proceso de análisis de un evento, men-
cionado en la sección 4.1. Es importante mencionar que dichos archivos que componen
este programa, deben ser colocados en un directorio llamado admon malware, el cual
debe estar ubicado en el Escritorio de Ubuntu. Únicamente se le debe otorgar permiso
de ejecución al archivo admon malware, ya que durante la ejecución a los demás ar-
chivos, le son aignados estos permisos, y al término de la ejecución son retirados estos
permisos. Las variables de entorno declaradas tanto en el archivo admon malware y
analisis reportes cuckoo deben ser modificados de acuerdo al nombre del usuario del
sistema operativo en el que se desee implementar (para esta tesis el nombre de usuario
fue snort-cuckoo).

Archivo admon malware

#! / b i n / b a s h

# CAPTURA LAS SEÑALES DEL TECLADO ” C t r l −C y C t r l −Z” PARA EVITAR QUE EL

USUARIO TERMINE ABRUPTAMENTE LA EJECUCIÓN DEL PROGRAMA

201
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

trap −− ’ ’ SIGTSTP
trap −− ’ ’ SIGINT

# DECLARACIÓN DE VARIABLES DE ENTORNO

export ADMONMALWARE=/home/ s n o r t −cuckoo / E s c r i t o r i o / admon malware

export CUCKOO=/opt / cuckoo
export DESCARGAS=/home/ s n o r t −cuckoo / D e s c a r g a s /
export TEMP DESCARGAS=/home/ s n o r t −cuckoo / D e s c a r g a s / t e m p d e s c a r g a
export CUCKOO UTILS=/opt / cuckoo / u t i l s
export MUESTRAS MALWARE=/home/ s n o r t −cuckoo / D e s c a r g a s / m u es t r a s m a lw a r e

# FUNCIÓN QUE DESPLIGA EL T ÍTULO DEL PROGRAMA

admon analisis malware () {

clear
echo ” | ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ | ”
echo ” | |”
echo ” | ADMINISTRACIÓN DE ANÁLISIS DE MALWARE| ”
echo ” | |”
echo −e ” | ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ | \ n”
}

# FUNCIÓN QUE DESPLIGA LOS MÓDULOS QUE COMPONEN EL PROGRAMA PARA EL

PROCESO DE AUTOMATIZACIÓN DE LAS MUESTRAS DE MALWARE CON CUCKOO
SANDBOX

menu principal () {
admon analisis malware
echo −e ” Por f a v o r s e l e c c i o n e una o p c i ón : \ n”
echo ” 1 ) Aná l i s i s de a r c h i v o s d e s c a r g a d o s d e l IDS S n o r t . ”
echo ” 2 ) B o r r a r Base de Datos d e l IDS S n o r t . ”
echo ” 3 ) Comprobar e s t a d o de Cuckoo SandBox . ”
echo ” 4 ) A n a l i z a r a r c h i v o d e s c a r g a d o con Cuckoo SandBox . ”

202
 echo ” 5 ) A n a l i z a r r e p o s i t o r i o de r e p o r t e s de malware de Cuckoo SandBox .
”
echo ” 6 ) A c t i v a r s e r v i c i o web de Cuckoo SandBox”
echo ” 7 ) S a l i r . ”
echo −e −n ” \n−> ”
}

# FUNCIÓN QUE DETERMINA LA EJECUCIÓN DE LOS DIFERENTES MÓDULOS CONTENIDOS

EN EL PROGRAMA.

main ( ) {
menu principal
read answer
case $answer in
1)
archivos ids
;;

2)
borrar BD Snort
;;

3)
status cuckoo
;;

4)
analisis archivo descargado
;;

5)
analisis repositorio
;;

203
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

6)
web cuckoo
;;

7)
kill script
;;

∗)
opcion no valida
;;
esac
}

# FUNCIÓN QUE PERMITE ANALIZAR EL PAYLOAD DE UN PAQUETE O UN ARCHIVO PCAP,

PARA LA OBTENCIÓN DE UN ARCHIVO PARA SU POSTERIOR ANÁLISIS CON CUCKOO
SANDBOX

archivos ids () {
admon analisis malware
echo −e ” Por f a v o r s e l e c c i o n e una o p c i ón : \ n”
echo ” 1 ) A n a l i z a r e l Payload de un p aq ue te . ”
echo ” 2 ) A n a l i z a r a r c h i v o con fo rma to pcap . ”
echo ” 3 ) R e g r e s a r a l menú p r i n c i p a l . ”
echo −e −n ” \n−> ”
read o p c i o n
case $ o p c i o n in
1)
payload paquetes
;;

2)
archivos pcap
;;

204
 3)
main
;;

∗)
admon analisis malware
echo −e ”ERROR! Opci ón no vá l i d a ! \ n”
echo ” Para r e g r e s a r oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
archivos ids
fi
;;
esac
}

# FUNCIÓN QUE OBTIENE UN ARCHIVO QUE SE ENCUENTRA EN EL PAYLOAD DE UN

PAQUETE

payload paquetes () {
admon analisis malware
echo ” Por f a v o r i n g r e s a e l nombre d e l p ay l oa d a a n a l i z a r ( ∗ . b i n ) : ”
echo −e −n ”−> ”
read p ay l oa d
i f [ −f $DESCARGAS$payload ] ; then
admon analisis malware
echo ” Obteniendo i n f o r m a c i ón d e l a r c h i v o \ ” $ p a y l oa d \ ” . . . ”
cd $DESCARGAS
h o s t =‘ e g r e p −i h ’ ( Host . ∗ ) ’ $DESCARGAS$payload | sed ’ s / Host . ∗ // g ’ |
sed ’ s / . $ / / ’ ‘ g e t =‘ e g r e p −i h ’ ( ˆGET. ∗ ) ’ $DESCARGAS$payload | sed
’ s /GET // g ’ | sed ’ s /HTTP. ∗ / / g ’ | sed ’ s / ˆ [ \ t ] ∗ / / ; s / [ \ t ] ∗ $
// ’ ‘
d o w n l o a d e d f i l e =‘echo $ g e t | awk −F ” / ” ’ { p r i n t $NF } ’ ‘
URL=‘echo $ h o s t $ g e t ‘

205
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

s t a t u s u r l =‘ c u r l −I s −−connect −t i m e o u t 2 $URL | head −n 1 | c u t −d ”

” −f 2 ‘
i f [ ” $ s t a t u s u r l ” == ” 200 ” ] ; then
i f [ −d $MUESTRAS MALWARE ] ; then
cd $MUESTRAS MALWARE
wget −e r o b o t s=o f f −o t e m p d e s c a r g a $URL &> / dev / n u l l
i f [ −f $MUESTRAS MALWARE/ t e m p d e s c a r g a ] ; then
mv t e m p d e s c a r g a $DESCARGAS
fi
admon analisis malware
echo ” Se d e s c a r g ó e l a r c h i v o \ ” $ d o w n l o a d e d f i l e \ ” en :
$MUESTRAS MALWARE”
sleep 5s
analyses payload
else
mkdir $MUESTRAS MALWARE && cd $MUESTRAS MALWARE
wget −e r o b o t s=o f f −o t e m p d e s c a r g a $URL &> / dev / n u l l
i f [ −f $MUESTRAS MALWARE/ t e m p d e s c a r g a ] ; then
mv t e m p d e s c a r g a $DESCARGAS
fi
admon analisis malware
echo ” Se d e s c a r g ó e l a r c h i v o \ ” $ g e t \ ” en : $MUESTRAS MALWARE”
sleep 5s
analyses payload
fi
else
admon analisis malware
echo ”ERROR! El Archivo \ ” $ g e t \ ” no s e e n c u e n t r a para su d e s c a r g a
!”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi

206
 else
admon analisis malware
echo ”ERROR! El a r c h i v o \ ” $ p a y l o ad \ ” no e x i s t e ! ”
sleep 2s
payload paquetes
fi
}

# FUNCIÓN QUE ES INVOCADA UNA VEZ QUE SE DESCARGÓ EL ARCHIVO CONTENIDO EN

EL PAYLOAD DE UN PAQUETE. ESTA FUNCIÓN PERMITE ENVIAR LA MUESTRA
OBTENIDA PARA SU ANÁLISIS A LA SANDBOX

analyses payload () {
admon analisis malware
echo ” A n a l i z a r e l a r c h i v o ahora con Cuckoo SandBox ? [ S/N] ”
echo −e −n ”−> ”
read r e s p u e s t a
case $ r e s p u e s t a in
s | S)
obtiene nombre archivo descargado
;;

n |N)
reanalizar payload
;;

∗)
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”
echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
analyses
fi
;;

207
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

esac
}

# FUNCIÓN QUE PERMITE REPETIR EL PROCESO ANTERIOR PARA LA OBTENCIÓN DE UN

ARCHIVO DESDE EL PAYLOAD DE UN PAQUETE

reanalizar payload () {
admon analisis malware
echo ” Desea a n a l i z a r o t r o a r c h i v o ( ∗ . b i n ) ? [ S/N] ”
echo −e −n ”−> ”
read r e s p u e s t a
case $ r e s p u e s t a in
s | S)
borra temp descargas
payload paquetes
;;

n |N)
admon analisis malware
borra temp descargas
echo ” Para r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
;;

∗)
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”
echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
reanalizar payload
fi

208
 ;;
esac
}

# FUNCIÓN QUE OBTIENE UN ARCHIVO QUE SE ENCUENTRA EN UN ARCHIVO CON

EXTENSIÓN PCAP

archivos pcap () {
admon analisis malware
echo ” Por f a v o r i n g r e s a e l nombre d e l a r c h i v o pcap a a n a l i z a r ( ∗ . pcap ) :
”
echo −e −n ”−> ”
read pcap
i f [ −f $DESCARGAS$pcap ] ; then
admon analisis malware
echo ” Obteniendo i n f o r m a c i ón d e l a r c h i v o \ ” $pcap \ ” . . . ”
cd $DESCARGAS
t c p t r a c e −xHTTP $DESCARGAS$pcap &> / dev / n u l l
f i l e x p l =‘ l s −1 ∗ . x p l | c u t −d ” ” −f 1 0 ‘
f i l e t i m e s =‘ l s −1 ∗ . times | c u t −d ” ” −f 1 0 ‘
o u t p u t f i l e =‘ l s −1 ∗ . dat | c u t −d ” ” −f 1 0 ‘
i f [ −f $ f i l e x p l ] && [ −f $ f i l e t i m e s ] ; then
rm ∗ . x p l ∗ . times
fi
i f [ −f $DESCARGAS$output file ] ; then
cd $DESCARGAS
h o s t =‘ e g r e p −i h ’ ( Host . ∗ ) ’ $DESCARGAS$output file | sed ’ s / Host . ∗
// g ’ | sed ’ s / . $ / / ’ ‘
g e t =‘ e g r e p −i h ’ ( ˆGET. ∗ ) ’ $DESCARGAS$output file | sed ’ s /GET // g
’ | sed ’ s /HTTP. ∗ / / g ’ | sed ’ s / ˆ [ \ t ] ∗ / / ; s / [ \ t ] ∗ $ / / ’ ‘
d o w n l o a d e d f i l e =‘echo $ g e t | awk −F ” / ” ’ { p r i n t $NF } ’ ‘
URL=‘echo $ h o s t $ g e t ‘
s t a t u s u r l =‘ c u r l −I s −−connect −t i m e o u t 2 $URL | head −n 1 | c u t −
d ” ” −f 2 ‘
rm $ o u t p u t f i l e

209
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

i f [ ” $ s t a t u s u r l ” == ” 200 ” ] ; then
i f [ −d $MUESTRAS MALWARE ] ; then
cd $MUESTRAS MALWARE
wget −e r o b o t s=o f f −o t e m p d e s c a r g a $URL &> / dev / n u l l
i f [ −f $MUESTRAS MALWARE/ t e m p d e s c a r g a ] ; then
mv t e m p d e s c a r g a $DESCARGAS
fi
admon analisis malware
echo ” Se d e s c a r g ó e l a r c h i v o \ ” $ d o w n l o a d e d f i l e \ ” en :
$MUESTRAS MALWARE”
sleep 5s
analyses pcap
else
mkdir $MUESTRAS MALWARE && cd $MUESTRAS MALWARE
wget −e r o b o t s=o f f −o t e m p d e s c a r g a $URL &> / dev / n u l l
i f [ −f $MUESTRAS MALWARE/ t e m p d e s c a r g a ] ; then
mv t e m p d e s c a r g a $DESCARGAS
fi
admon analisis malware
echo ” Se d e s c a r g ó e l a r c h i v o \ ” $ g e t \ ” en : $MUESTRAS MALWARE
”
sleep 5s
analyses pcap
fi
else
admon analisis malware
echo ”ERROR! El a r c h i v o \ ” $ g e t \ ” no s e e n c u e n t r a para su
descarga ! ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
else

210
 admon analisis malware
echo ”ERROR! Hubo un problema a l p r o c e s a r e l a r c h i v o \ ” $pcap \ ” ”
sleep 2s
archivos pcap
fi
else
admon analisis malware
echo ”ERROR! El a r c h i v o \ ” $pcap \ ” no e x i s t e ! ”
sleep 2s
archivos pcap
fi
}

# FUNCIÓN QUE ES INVOCADA UNA VEZ QUE SE DESCARGÓ EL ARCHIVO CONTENIDO EN

EL ARCHIVO .PCAP. ESTA FUNCIÓN PERMITE ENVIAR LA MUESTRA OBTENIDA A
CUCKOO SANDBOX PARA SU ANÁLISIS

analyses pcap () {
admon analisis malware
echo ” A n a l i z a r e l a r c h i v o ahora con Cuckoo SandBox ? [ S/N] ”
echo −e −n ”−> ”
read r e s p u e s t a
case $ r e s p u e s t a in
s | S)
obtiene nombre archivo descargado
;;

n |N)
reanalizar pcap
;;

∗)
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”
echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”

211
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
analyses pcap
fi
;;
esac
}

# FUNCIÓN QUE PERMITE REPETIR EL PROCESO ANTERIOR PARA LA OBTENCIÓN DE UN

ARCHIVO DESDE UN ARCHIVO CON LA EXTENSIÓN PCAP

reanalizar pcap () {
admon analisis malware
echo ” Desea a n a l i z a r o t r o a r c h i v o ( ∗ . pcap ) ? [ S/N] ”
echo −e −n ”−> ”
read r e s p u e s t a
case $ r e s p u e s t a in
s | S)
borra temp descargas
archivos pcap
;;

n |N)
admon analisis malware
borra temp descargas
echo ” Para r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
;;

∗)
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”

212
 echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
reanalizar pcap
fi
;;
esac
}

# FUNCIÓN QUE PERMITE OBTENER EL NOMBRE DEL ARCHIVO DESCARGADO DESDE EL

PAYLOAD DE UN PAQUETE O DESDE UN ARCHIVO CON PCAP. UNA VEZ QUE SE
OBTUVO EL NOMBRE DEL ARCHIVO DESCARGADO, SE LE PROPORCIONA ESTA
INFORMACIÓN A LA SANDBOX PARA PODER REALIZAR EL ANÁLISIS

obtiene nombre archivo descargado () {

i f [ −f $TEMP DESCARGAS ] ; then
cd $DESCARGAS
n a m e f i l e d o w n l o a d =‘ e g r e p −i h ’ ( Grabando a : ∗ ) ’ t e m p d e s c a r g a | sed ’
s / Grabando a : // g ’ | sed ’ s / ˆ [ ” ] ∗ / / ; s / [ \ t ] ∗ $ / / ’ | s e d ’ s / [ ” ] ∗ $
//; s /[ \t ]∗ $ // ’ ‘
admon analisis malware
p i d c u c k o o =‘ps −e f | g r e p −v g r e p | g r e p cuckoo . py | awk ’ { p r i n t $2
}’‘
borra temp descargas
i f [ ” $ p i d c u c k o o ” != ” ” ] ; then
i f [ −f $MUESTRAS MALWARE/ $ n a m e f i l e d o w n l o a d ] ; then
admon analisis malware
cd $CUCKOO UTILS && . / submit . py $MUESTRAS MALWARE/
$name file download
echo −e ” \nÉ x i t o ! Se e s t á r e a l i z a n d o e l an á l i s i s d e l a r c h i v o \
” $ n a m e f i l e d o w n l o a d \ ” con Cuckoo Sandbox . ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main

213
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

fi
else
admon analisis malware
echo ” E r r o r ! El nombre de a r c h i v o no e x i s t e ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
else
echo −e ” E r r o r ! \ n\nNo s e e n c u e n t r a a c t i v o Cuckoo SandBox . Puedes
a c t i v a r Cuckoo SandBox en l a o p c i ón 3 d e l menú p r i n c i p a l . ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
else
admon analisis malware
echo ”No e x i s t e n d e s c a r g a s por a n a l i z a r ”
sleep 2s
main
fi
}

# FUNCIÓN QUE PERMITE ELIMINAR EL ARCHIVO LOG DE LA DESCARGA DE LA MUESTRA

, EL CUAL FUE GENERADO A PARTIR DEL ANÁLISIS DEL PAYLOAD DE UN PAQUETE
Y EL ARCHIVO PCAP

borra temp descargas () {

i f [ −f $TEMP DESCARGAS ] ; then
rm $TEMP DESCARGAS
fi

214
}

# FUNCIÓN QUE DESPLIEGA EL MENSAJE DE CONFIRMACIÓN PARA BORRAR LOS DATOS

DE LA BASE DE DATOS DE SNORT

borrar BD ( ) {
admon analisis malware
echo −e ”W A R N I N G! \n\ nDesea b o r r a r l a Base de Datos d e l IDS S n o r t
? [ S/N] ”
echo −e −n ”−> ”
}

# FUNCIÓN QUE DETERMINA S Í ES REALIZADO EL BORRADO DE LOS DATOS DE LAS

TABLAS DE LA BASE DE DATOS DE SNORT, O SE REGRESA AL MENÚ PRINCIPAL

borrar BD Snort ( ) {
borrar BD
read b o r r a r
case $ b o r r a r in
s | S)
borrar base de datos
;;

n |N)
admon analisis malware
echo ” Para r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
;;

∗)
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”

215
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”

read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
borrar BD Snort
fi
;;
esac
}

# FUNCIÓN QUE SE INVOCA PARA ELIMINAR LA INFORMACIÓN DE LAS TABLAS DE LA

BASE DE DATOS Y ELIMINAR TODOS LOS ARCHIVOS GENERADOS POR LAS ALERTAS
DEL IDS SNORT

borrar base de datos () {

admon analisis malware
p i d e l i m i n a r t a b l a s i d s =‘ps −e f | g r e p −v g r e p | g r e p
e l i m i n a r t a b l a s i d s . php | awk ’ { p r i n t $2 } ’ ‘
i f [ −f $ADMON MALWARE/ e l i m i n a r e v e n t o s i d s ] && [ −f ADMONMALWARE/
e l i m i n a r t a b l a s i d s . php ] ; then
i f [ ” $ p i d e l i m i n a r t a b l a s i d s ” == ” ” ] ; then
echo −e ” Borrando t a b l a s de l a Base de Datos d e l IDS S n o r t . . . \ n”
cd $ADMON MALWARE
chmod 755 e l i m i n a r e v e n t o s i d s && . / e l i m i n a r e v e n t o s i d s
wait $ p i d e l i m i n a r t a b l a s i d s
chmod 644 e l i m i n a r e v e n t o s i d s
echo −e ” \n\ nAcci ón e j e c u t a d a e x i t o s a m e n t e . ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
else

216
 echo ” E r r o r ! R e v i s e que s e e n c u e n t r e n l o s s i g u i e n t e s a r c h i v o s :
e l i m i n a r e v e n t o s i d s y e l i m i n a r t a b l a s i d s . php en l a r u t a
$ADMON MALWARE. ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
}

# FUNCIÓN QUE PERMITE COMPROBAR SI LA SANDBOX SE ENCUENTRA EN EJECUCIÓN.

EN CASO DE NO ESTAR EJECUTÁNDOSE EL USUARIO PODRÁ HABILITAR LA SANDBOX
PARA QUE PUEDAN ENVIARSE MUESTRAS PARA SU ANÁLISIS

status cuckoo () {
admon analisis malware
p i d c u c k o o =‘ps −e f | g r e p −v g r e p | g r e p cuckoo . py | awk ’ { p r i n t $2 } ’ ‘
i f [ ” $ p i d c u c k o o ” == ” ” ] ; then
echo ” Cuckoo no s e e n c u e n t r a a c t i v o . Desea a c t i v a r Cuckoo ? [ S/N] ”
echo −e −n ”−> ”
read a c t i v a r
case $ a c t i v a r in
s | S)
admon analisis malware
echo ” C o n f i g u r a n d o i n t e r f a z vboxnet0 . . . ”
i f u p vboxnet0 &> / dev / n u l l
i f c o n f i g vboxnet0 1 9 2 . 1 6 8 . 5 6 . 1 &> / dev / n u l l
sleep 1s
echo −e ” \ nConfigurando Má quina V i r t u a l \ ” cuckoo1 \ ” . . . ”
VBoxManage startvm ” cuckoo1 ”
sleep 1s
cd $CUCKOO && . / cuckoo . py
sleep 2s
i f [ ” $ p i d c u c k o o ” == ” ” ] ; then

217
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

reintentar cuckoo
fi
;;

n |N)
admon analisis malware
echo ” Para r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
;;

∗)
status cuckoo
;;
esac
else
echo ” Cuckoo ya e s t a a c t i v o con e l PID = $ p i d c u c k o o . ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
}

# FUNCIÓN QUE PERMITE HABILITAR EL SERVICIO DE CUCKO SANDBOX, EN CASO DE

QUE AL REALIZARLO ANTERIORMENTE NO HAYA SIDO EXITOSO

reintentar cuckoo () {
admon analisis malware
echo ”ERROR! F a l l ó a l i n t e n t a r a c t i v a r e l s e r v i c i o de Cuckoo SandBox . ”
echo −e ” \ n I n t e n t a r de nuevo ? [ S/N] ”
echo −e −n ”−> ”

218
 read r e s p u e s t a
case $ r e s p u e s t a in
s | S)
status cuckoo
;;

n |N)
admon analisis malware
echo ” Para r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
;;

∗)
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”
echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
reintentar cuckoo
fi
;;
esac
}

# FUNCIÓN QUE PERMITE ENVIAR A CUCKOO SANDBOX EL ENVÍO DE UNA MUESTRA O

ARCHIVO SOSPECHOSO

analisis archivo descargado () {

admon analisis malware
p i d c u c k o o =‘ps −e f | g r e p −v g r e p | g r e p cuckoo . py | awk ’ { p r i n t $2 } ’ ‘
i f [ ” $ p i d c u c k o o ” != ” ” ] ; then
echo ” Por f a v o r i n g r e s a e l nombre d e l a r c h i v o d e s c a r g a d o : ”

219
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

echo −e −n ”−> ”
read d e s c a r g a d o
i f [ −f $DESCARGAS$descargado ] ; then
admon analisis malware
cd $CUCKOO UTILS && . / submit . py $DESCARGAS$descargado
echo −e ” \nÉ x i t o ! Se e s t á r e a l i z a n d o e l an á l i s i s d e l a r c h i v o \ ”
$ d e s c a r g a d o \ ” con Cuckoo Sandbox . ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
else
admon analisis malware
echo ” E r r o r ! El a r c h i v o \ ” $ d e s c a r g a d o \ ” no e x i s t e ! ”
sleep 2s
analisis archivo descargado
fi
else
echo −e ” E r r o r ! \ n\nNo s e e n c u e n t r a a c t i v o Cuckoo SandBox . Puedes
a c t i v a r Cuckoo SandBox en l a o p c i ón 3 d e l menú p r i n c i p a l . ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
}

# FUNCIÓN QUE INICIA EL PROCESO DE ANALIZAR EL REPOSITORIO DE REPORTES DE

CUCKOO SANDBOX

analisis repositorio () {
i f [ −f $ADMON MALWARE/ a n a l i s i s r e p o r t e s c u c k o o ] ; then
ejecuta analisis repositorio

220
 echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
else
admon analisis malware
echo −e ” \nNo e s p o s i b l e r e a l i z a r e l an á l i s i s de l o s r e p o s i t o r i o s . ”
echo −e ” \ nPor f a v o r r e v i s e que e l s c r i p t \ ” a n a l i s i s r e p o r t e s c u c k o o
\ ” s e e n c u e n t r a en l a s i g u i e n t e r u t a : $ADMON MALWARE”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
}

# FUNCIÓN QUE EJECUTA EL ARCHIVO a d m o n a n a l i s i s m a l w a r e PARA EL PROCESO DE

ANÁLISIS DEL REPOSITORIO DE REPORTES DE MUESTRAS PREVIAMENTE
ANALIZADAS

ejecuta analisis repositorio () {

admon analisis malware
cd $ADMON MALWARE
chmod 755 a n a l i s i s r e p o r t e s c u c k o o && . / a n a l i s i s r e p o r t e s c u c k o o
chmod 644 a n a l i s i s r e p o r t e s c u c k o o
}

# FUNCIÓN QUE PERMITE COMPROBAR S Í EL SERVICIO WEB DE CUCKOO SE ENCUENTRA

EN EJECUCIÓN. EN CASO DE NO ESTAR EJECUTÁNDOSE, EL USUARIO PODRÁ
HABILITAR EL SERVICIO WEB DE CUCKOO

web cuckoo ( ) {
admon analisis malware

221
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

p i d w e b c u c k o o =‘ps −e f | g r e p −v g r e p | g r e p web . py | awk ’ { p r i n t $2 } ’ ‘

i f [ ” $ p i d w e b c u c k o o ” == ” ” ] ; then
echo ” El s e r v i c i o web de Cuckoo SandBox no s e e n c u e n t r a a c t i v o .
Desea a c t i v a r e l s e r v i c i o web de Cuckoo SandBox ? [ S/N] ”
echo −e −n ”−> ”
read a c t i v a r
case $ a c t i v a r in
s | S)
admon analisis malware
echo −e ” C o n f i g u r a n d o S e r v i c i o Web de Cuckoo SandBox . . . \ n”
cd $CUCKOO UTILS && . / web . py
sleep 1s
i f [ ” $ p i d w e b c u c k o o ” == ” ” ] ; then
reintentar web cuckoo
fi
;;

n |N)
admon analisis malware
echo ” Para r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
;;

∗)
web cuckoo
;;
esac
else
echo ” El s e r v i c i o web de Cuckoo SandBox ya e s t á a c t i v o con l o s
s i g u i e n t e s PID ’ s : $ p i d w e b c u c k o o . ”
echo −e ” \ nPara r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r

222
 i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
fi
}

# FUNCIÓN QUE PERMITE HABILITAR EL SERVICIO WEB DE CUCKO SANDBOX, EN CASO

DE QUE AL REALIZARLO ANTERIORMENTE NO HAYA SIDO EXITOSO

reintentar web cuckoo () {

admon analisis malware
echo ”ERROR! F a l l ó a l i n t e n t a r a c t i v a r e l s e r v i c i o web de Cuckoo
SandBox . ”
echo −e ” \ n I n t e n t a r de nuevo ? [ S/N] ”
echo −e −n ”−> ”
read r e s p u e s t a
case $ r e s p u e s t a in
s | S)
web cuckoo
;;

n |N)
admon analisis malware
echo ” Para r e g r e s a r a l menú p r i n c i p a l oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
;;

∗)
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”
echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”
read e n t e r

223
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

i f [ ” $ e n t e r ” != ” ” ] ; then
reintentar web cuckoo
fi
;;
esac
}

# FUNCIÓN QUE PERMITE TERMINAR LA EJECUCIÓN DEL PROGRAMA

k i l l s c r i p t () {
k i l l $ ( p i d o f . / admon malware ) 2> / dev / n u l l
clear
return 0
}

# FUNCIÓN QUE DEVUELVE UN MENSAJE DE OPCIÓN INVÁLIDA , CUANDO ES

SELECCIONADO UN MÓDULO FUERA DEL ALCANCE

opcion no valida () {
admon analisis malware
echo ”ERROR! Opci ón no vá l i d a ! ”
echo −e ” \ nPara r e g r e s a r oprime e n t e r . . . ”
read e n t e r
i f [ ” $ e n t e r ” != ” ” ] ; then
main
fi
}

main

224
 Archivo analisis reportes cuckoo

#! / b i n / b a s h

# DECLARACIÓN DE VARIABLES DE ENTORNO

export ADMONMALWARE=/home/ s n o r t −cuckoo / E s c r i t o r i o / admon malware

export ESCRITORIO=/home/ s n o r t −cuckoo / E s c r i t o r i o
export ANALYSES=/opt / cuckoo / s t o r a g e / a n a l y s e s
export WEB CUCKOO=/var /www/ b a s e / web cuckoo

# FUNCIÓN QUE PERMITE OBTENER LA FECHA ACTUAL DEL SISTEMA

fecha () {
f e c h a =‘ date ‘
echo ”La f e c h a e s : $ f e c h a ”
}

# FUNCIÓN QUE PERMITE OBTENER EL NOMBRE DE LA MUESTRA ANALIZADA, DESDE UN

REPORTE GENERADO POR CUCKOO SANDBOX

nombre muestra ( ) {
nombre=‘awk ’/< span c l a s s=”mono” >/’ r e p o r t . html ‘
nombre=‘echo $nombre | c u t −d ”>” −f 3 | c u t −d ”<” −f 1 ‘
echo ” El nombre de l a muestra a n a l i z a d a e s : $nombre ”
}

# FUNCIÓN QUE PERMITE DETERMINAR S Í EL REPORTE ANALIZADO CON CUCKOO

SANDBOX CORRESPONDE A UN ARCHIVO O A UNA URL

reputacion vt () {
v a l i d a =‘awk ’/<h4>/ { p r i n t } ’ r e p o r t . html ‘
v a l i d a =‘echo $ v a l i d a | c u t −d ”>” −f 2 | c u t −d ”<” −f 1 ‘
}

225
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

# FUNCIÓN QUE PERMITE OBTENER LA FUNCIÓN HASH SHA256 DE LA MUESTRA

ANALIZADA

sha256 archivo () {
SHA256=‘awk ’NR==405’ r e p o r t . html ‘
SHA256=‘echo $SHA256 | c u t −d ”>” −f 3 | c u t −d ”<” −f 1 ‘
echo ” El SHA256 de l a muestra a n a l i z a d a e s : $SHA256”
}

# PARA EL ANÁLISIS DE URL’ s DE CUCKOO SANDBOX, NO EXISTE UNA FUNCIÓN HASH,

POR LO QUE DESPLIEGA EL MENSAJE QUE NO CUENTA CON DICHA FUNCIÓN HASH

url sha256 () {
SHA256=” S i n SHA256”
echo ” El SHA256 de l a muestra a n a l i z a d a e s : $SHA256”
}

# FUNCIÓN QUE OBTIENE EL PORCENTAJE DE ANTIVIRUS QUE DETECTARON LA MUESTRA

COMO UNA AMENAZA.

detection rate () {
r a t e =‘awk ’ / D e t e c t i o n Rate : / { p r i n t } ’ r e p o r t . html ‘
r a t e =‘echo $ r a t e | c u t −d ” : ” −f 2 | c u t −d ” ” −f 2 ‘
numerador =‘echo $ r a t e | c u t −d ” / ” −f 1 ‘
denominador =‘echo $ r a t e | c u t −d ” / ” −f 2 ‘
d i v i s i o n=$ ( echo ” $numerador / $denominador ” | bc − l )
p o r c e n t a j e=$ ( echo ” $ d i v i s i o n ∗100 ” | bc − l )
echo ” El ı́ n d i c e de d e t e c c i ón de a n t i v i r u s e s : $ p o r c e n t a j e ” ” %”
}

# FUNCIÓN QUE PERMITE OBTENER LA REPUTACIÓN DE VIRUS TOTAL DE UN ARCHIVO

ANALIZADO, DESDE UN REPORTE GENERADO POR CUCKOO SANDBOX

reputacion archivo () {
cd $ADMON MALWARE

226
 v i r u s t o t a l a r c h i v o=h t t p s : / /www. v i r u s t o t a l . com/ e s / f i l e /$SHA256/ v o t e s −
resume /
s t a t u s a r c h i v o =‘ c u r l −I s −−connect −t i m e o u t 3 $ v i r u s t o t a l a r c h i v o |
head −n 1 | c u t −d ” ” −f 2 ‘
i f [ ” $ s t a t u s a r c h i v o ” == ” 200 ” ] ; then
wget −e r o b o t s=o f f $ v i r u s t o t a l a r c h i v o &> / dev / n u l l
r e p u t a c i o n =‘ c u t −d ” \ ” −f 9 i n d e x . html | c u t −d ” e ” −f 6 | c u t −d ”
” −f 2 ‘
echo −e ”La r e p u t a c i ón d e l a r c h i v o $nombre e s de : $ r e p u t a c i o n \n”
i f [ −f i n d e x . html ] ; then
rm i n d e x . html
fi
else
echo −e ”Pá g i n a de V i r u s T o t a l no e n c o n t r a d a ! \ n”
fi
}

# FUNCIÓN QUE PERMITE OBTENER LA REPUTACIÓN DE VIRUS TOTAL DE UNA URL

ANALIZADA, DESDE UN REPORTE GENERADO POR CUCKOO SANDBOX

reputacion URL ( ) {
r u r l =‘awk ’ / h t t p s / { p r i n t } ’ r e p o r t . html ‘
r u r l =‘echo $ r u r l | c u t −d ”=” −f 2 | c u t −d ”>” −f 1 ‘
p r o t o c o l o =‘echo $ r u r l | c u t −d ” / ” −f 1 ‘
dominio =‘echo $ r u r l | c u t −d ” / ” −f 3 ‘
d i r e c t o r i o 1 =‘echo $ r u r l | c u t −d ” / ” −f 4 ‘
d i r e c t o r i o 2 =‘echo $ r u r l | c u t −d ” / ” −f 5 ‘
v i r u s t o t a l u r l=$ ( echo ” $ p r o t o c o l o // $dominio / e s / $ d i r e c t o r i o 1 /
$ d i r e c t o r i o 2 / v o t e s −resume ” )
s t a t u s u r l =‘ c u r l −I s −−connect −t i m e o u t 3 $ v i r u s t o t a l u r l | head −n 1 |
c u t −d ” ” −f 2 ‘
i f [ ” $ s t a t u s u r l ” == ” 301 ” ] ; then
cd $ADMON MALWARE
wget −e r o b o t s=o f f $ v i r u s t o t a l u r l &> / dev / n u l l

227
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

r e p u t a c i o n =‘ c u t −d ”=” −f 4 v o t e s −resume | c u t −d ” e ” −f 5 | c u t −d
” ” −f 2 ‘
echo −e ”La r e p u t a c i ón de l a URL $nombre e s de : $ r e p u t a c i o n \n”
i f [ −f v o t e s −resume ] ; then
rm v o t e s −resume
fi
else
echo −e ”Pá g i n a de V i r u s T o t a l no e n c o n t r a d a ! \ n”
fi
}

# REALIZA ITERATIVAMENTE LA OBTENCIÓN DE INFORMACIÓN POR CADA UNO DE LOS

REPORTES ENCONTRADOS EN EL REPOSITORIO

i f [ −d $ANALYSES ] ; then
NUM=0
cd $ANALYSES
a n a l y s e s=$ ( l s −1 | wc − l )
f o r ( ( i =1; i<=a n a l y s e s ; i ++))
do
i f [ −f $ANALYSES/ $ i / r e p o r t s / r e p o r t . html ] ; then
r u t a c u c k o o=$ANALYSES/ $ i / r e p o r t s / r e p o r t . html
p a t h w e b c u c k o o=$WEB CUCKOO/ $ i
f i l e w e b c u c k o o=$WEB CUCKOO/ $ i / r e p o r t . html
r e p o r t s c u c k o o =/web cuckoo / $ i / r e p o r t . html
i f [ −d $WEB CUCKOO ] ; then
i f [ ! −d $ p a t h w e b c u c k o o ] ; then
mkdir $ p a t h w e b c u c k o o
cp $ r u t a c u c k o o $ p a t h w e b c u c k o o
else
i f [ ! −f $ f i l e w e b c u c k o o ] ; then
cp $ r u t a c u c k o o $ p a t h w e b c u c k o o
fi
fi
else

228
 mkdir $WEB CUCKOO
mkdir $ p a t h w e b c u c k o o
cp $ r u t a c u c k o o $ p a t h w e b c u c k o o
fi
cd $ANALYSES/ $ i / r e p o r t s
echo ” D i r e c t o r i o $ i a n a l i z a d o ”

# CUENTA EL NÚMERO DE DIRECTORIOS ANALIZADOS

NUM=‘expr $NUM + 1 ‘
NEW NUM=‘echo $ {NUM} ‘

# SE LLAMAN LAS FUNCIONES ANTERIORES

fecha
nombre muestra
reputacion vt

# SE OBTIENE EL SHA256 DE LA MUESTRA ANALIZADA

i f [ ” $ v a l i d a ” == ” F i l e D e t a i l s ” ] ; then
sha256 archivo
else
url sha256
fi

# ÍNDICE DE DETECCIÓN DE ANTIVIRUS

detection rate

# SE DETERMINA S Í ES UN ARCHIVO O UNA URL, PARA OBTENER SU

RESPECTIVA REPUTACIÓN

i f [ ” $ v a l i d a ” == ” F i l e D e t a i l s ” ] ; then
reputacion archivo
else
reputacion URL
fi

229
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

# SALIDA QUE ES REDIRECCIONADA AL ARCHIVO I n f o r m a c i o n M u e s t r a s .

txt
echo $ f e c h a ! $nombre ! $SHA256 ! $ p o r c e n t a j e %!$ r e p u t a c i o n !
$ r e p o r t s c u c k o o >> $ESCRITORIO/ I n f o r m a c i o n M u e s t r a s . t x t
fi
done
echo ” Se han a n a l i z a d o $NEW NUM r e p o r t e s de an á l i s i s de malware
exitosamente ! ”
else
echo ” E r r o r : No e x i s t e n r e p o r t e s de Cuckoo por a n a l i z a r ”
fi

230
 Archivo eliminar eventos ids

#! / b i n / sh

# DECLARACIÓN DE VARIABLES DE ENTORNO

export ADMONMALWARE=/home/ s n o r t −cuckoo / E s c r i t o r i o / admon malware /

e l i m i n a r t a b l a s i d s . php
export SNORT=/var / l o g / s n o r t / a l e r t
export BARNYARD=/var / l o g / barnyard2

# DETERMINA LA EXISTENCIA DEL ARCHIVO e l i m i n a r t a b l a s i d s . php PARA

POSTERIORMENTE ELIMINAR LOS DATOS DE LAS TABLAS DE LA BASE DE DATOS
DEL IDS

i f [ −f $ADMON MALWARE ] ; then

/ u s r / b i n /php −f $ADMON MALWARE
fi

# REALIZA EL BORRADO DE LAS ALERTAS QUE EMPLEA BARNYARD

i f [ −f $BARNYARD ] ; then
cat / dev / n u l l > $BARNYARD/ a l e r t
fi

# ELIMINA TODOS LOS LOGS GENERADOS POR EL IDS SNORT

i f [ −f $SNORT ] ; then
rm $SNORT/ s n o r t . ∗
fi

231
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

Archivo eliminar tablas ids.php

<?php

// DECLARACIÓN DE VARIABLES

$Icmphdr = ’ icmphdr ’ ;
$Data = ’ data ’ ;
$Iphdr = ’ iphdr ’ ;
$Opt = ’ opt ’ ;
$Signature = ’ signature ’ ;
$Tcphdr = ’ t c p h d r ’ ;
$Event = ’ e v e n t ’ ;
$Acid event = ’ acid event ’ ;

// SE ESTABLECE LA CONEXIÓN CON MYSQL

$cnx = mysql connect ( ” l o c a l h o s t ” , ” r o o t ” , ”MySQL” ) ;

i f ( ! $cnx ) {
die ( ” \nNo s e pudo c o n e c t a r : ” . mysql error ( ) . ” \n” ) ;
}

// SE REALIZA LA CONEXIÓN A LA BASE DE DATOS

$ bd s n = mysql select db ( ” s n o r t ” , $cnx ) ;

i f ( ! $ bd s n ) {
die ( ” \ n E r r o r a l s e l e c c i o n a r s n o r t : ” . mysql error ( ) . ” \n” ) ;
}

// SE REALIZAN LAS CONSULTAS PARA EL BORRADO DE LAS TABLAS DE LA BASE DE

DATOS DE SNORT

$qry1 = mysql query ( ” d e l e t e from $Icmphdr ” ) ;

$qry2 = mysql query ( ” d e l e t e from $Data ” ) ;
$qry3 = mysql query ( ” d e l e t e from $Iphdr ” ) ;
$qry4 = mysql query ( ” d e l e t e from $Opt” ) ;

232
$qry5 = mysql query ( ” d e l e t e from $ S i g n a t u r e ” ) ;
$qry6 = mysql query ( ” d e l e t e from $Tcphdr ” ) ;
$qry7 = mysql query ( ” d e l e t e from $Event ” ) ;
$qry8 = mysql query ( ” d e l e t e from $ A c i d e v e n t ” ) ;

// VALIDACIÓN DEL CORRECTO BORRADO DE LOS DATOS DE LAS TABLAS DE LA BASE

DE DATOS DEL IDS SNORT

i f ( ! $qry1 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $Icmphdr : ” .
mysql affected rows ( ) . ” \n” ;
}

i f ( ! $qry2 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $Data : ” .
mysql affected rows ( ) . ” \n” ;
}

i f ( ! $qry3 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $Iphdr : ” .
mysql affected rows ( ) . ” \n” ;
}

i f ( ! $qry4 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $Opt : ” .
mysql affected rows ( ) . ” \n” ;
}

233
B. CÓDIGO FUENTE PARA LA AUTOMATIZACIÓN DEL ANÁLISIS DE UNA
MUESTRA CON CUCKOO SANDBOX Y ADMINISTRACIÓN DE EVENTOS
DEL IDS SNORT.

i f ( ! $qry5 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $ S i g n a t u r e : ” .
mysql affected rows ( ) . ” \n” ;
}

i f ( ! $qry6 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $Tcphdr : ” .
mysql affected rows ( ) . ” \n” ;
}

i f ( ! $qry7 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $Event : ” .
mysql affected rows ( ) . ” \n” ;
}

i f ( ! $qry8 ) {
echo ” \ n E r r o r en c o n s u l t a ” . mysql error ( ) . ” \n” ;
} else {
echo ” \nÉ x i t o ! Elementos Borrados de l a t a b l a $ A c i d e v e n t : ” .
mysql affected rows ( ) . ” \n” ;
}

// CIERRE DE CONEXIÓN A MYSQL

m y s q l c l o s e ( $cnx ) ;
?>

234
 Apéndice C

Código fuente del Sistema de Consulta

de Malware.

Este apartado contiene el código fuente y los archivos que componen la página web
desarrollada con las tecnologı́as PHP, JavaScript, jQuery y Bootstrap. Cabe recordar
que la principal función de este sistema web es presentar los valores más importantes
de las amenzas, detectadas tras ser analizadas con Cuckoo SandBox. Estos valores son
presentados al usuario de una manera clara y fácil de comprender.

Para el correcto despliegue de la página web, es necesario que los archivos que a
continuación se describen, se encuentren en un directorio llamado login en la ruta /va-
r/www/base.

Para acceder al Sistema de Consulta de Malware, el usuario podrá emplear cual-

quier navegador web moderno, e ingresar la dirección IP del servidor para acceder a
la página de autenticación de dicho sistema. Esto se describe de la siguiente manera:
http://<dirección ip servidor>/login/.

Archivo index.php

<?php
r e q u i r e o n c e ( ” s e s i o n . c l a s s . php” ) ;
$ s e s i o n = new s e s i o n ( ) ;

i f ( i s s e t ( $ POST [ ” i n i c i a r ” ] ) ) {
$ u s u a r i o = $ POST [ ” u s e r ” ] ;
$password = $ POST [ ” p a s s ” ] ;
$ v a l i d a t e = v a l i d a r U s u a r i o ( $ u s u a r i o , $password ) ;

235
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

i f ( $ v a l i d a t e [ ” f l a g ” ] == true ) {
$ s e s i o n −> s e t ( ” u s e r ” , $ u s u a r i o , $ v a l i d a t e [ ” c o u n t e r ” ] ) ;
header ( ” l o c a t i o n : p r i n c i p a l . php” ) ;
} else {
header ( ” l o c a t i o n : v a l i d a c i o n . php” ) ;
}
}

f u n c t i o n v a l i d a r U s u a r i o ( $ u s u a r i o , $password ) {
$ c o n e x i o n = m y s q l i c o n n e c t ( ” l o c a l h o s t ” , ” r o o t ” , ”<Password r o o t MySQL>
” , ” usuario web ” ) ;
$ s q l = ”SELECT ∗ FROM u s u a r i o WHERE nombre=’ $ u s u a r i o ’ AND password=
AES ENCRYPT( ’ $password ’ , ’ k e y a e s ’ ) ” ;
$consulta = mysqli query ( $conexion , $ s q l ) ;
$ r e s u l t = mysqli num rows ( $ c o n s u l t a ) ;
i f ( $ POST [ ’ I n c i d e n t e ’ ] == ’ 1 ’ && $ r e s u l t > 0 ) {
while ( $ o b j = m y s q l i f e t c h o b j e c t ( $ c o n s u l t a ) ) {
$ c o u n t e r = $ o b j −> v i s i t c o u n t e r ;
}
$counter = $counter + 1;
$ u p d a t e q u e r y = ”UPDATE u s u a r i o SET v i s i t c o u n t e r=” . $ c o u n t e r . ”
WHERE nombre = ’ ” . $ u s u a r i o . ” ’ ” ;
mysqli query ( $conexion , $update query ) ;
} else {
while ( $ o b j = m y s q l i f e t c h o b j e c t ( $ c o n s u l t a ) ) {
$ c o u n t e r = $ o b j −> v i s i t c o u n t e r ;
}
}
}

m y s q l i f r e e r e s u l t ( $conexion , $ r e s u l t ) ;
mysqli close ( $link ) ;
i f ( $ r e s u l t > 0) {
$ r e s p o n s e = array ( ” f l a g ” => true , ” c o u n t e r ” => $ c o u n t e r ) ;
return $response ;

236
 } else {
$ r e s p o n s e = array ( ” f l a g ” => f a l s e ) ;
return $response ;
}
?>

<!DOCTYPE html>
<html l a n g=” en ” c l a s s=”demo−1 no−j s ”>
<head>
<meta c h a r s e t=”UTF−8” />
<meta http−e q u i v=”X−UA−Compatible ” c o n t e n t=” IE=edge ”>
<meta name=” v i e w p o r t ” c o n t e n t=” width=d e v i c e −width , i n i t i a l −s c a l e =1”>
< t i t l e >S i s t e m a de C o n s u l t a de Malware</ t i t l e >
<meta name=” d e s c r i p t i o n ” c o n t e n t=” Muestras de malware d e t e c t a d a s por
un IDS y que han s i d o a n a l i z a d a s por Cuckoo SandBox . ” />
<meta name=” keywords ” c o n t e n t=” malware , i d s , samples , worms . ” />
<meta name=” a u t h o r ” c o n t e n t=” A l e j a n d r o Bá r c e n a s ”/>
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” c s s /demo . c s s ” />
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” c s s / component . c s s ” />
</head>
<body>
<d i v c l a s s=” c o n t a i n e r ”>
<header c l a s s=” c c h e a d e r ”>
<h1><b>S i s t e m a de C o n s u l t a de Malware</b></h1>
</header>

<d i v c l a s s=” wrapper ”>

<d i v c l a s s=” c c l o g i n i c o n s ”>
<h2 a l i g n= ’ c e n t e r ’> I n i c i a r s e s i o n </h2>
<form method=” p o s t ” a c t i o n=” ”>
<p>
<span c l a s s=” c c l o g i n −addon ”><i c l a s s=” f a f a −u s e r f a −2x
f a −s p i n ”></i ></span>
<i n p u t type=” t e x t ” name=” u s e r ” v a l u e=” ” p l a c e h o l d e r=”
Nombre de u s u a r i o ”>

237
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

</p>
<p>
<span c l a s s=” c c l o g i n −addon ”><i c l a s s=” f a f a −key f a −2x f a
−s p i n ”></i ></span>
<i n p u t type=” password ” name=” p a s s ” v a l u e=” ” p l a c e h o l d e r=
” C o n t r a s e ña ”>
</p>
<p>
< s e l e c t name=” I n c i d e n t e ”>
<o p t i o n d i s a b l e d=” ” s e l e c t e d=” ” v a l u e=” 0 ”>La c o n s u l t a
e s por un i n c i d e n t e de s e g u r i d a d ?</ o p t i o n >
<o p t i o n v a l u e=” 1 ”>Si </o p t i o n >
<o p t i o n v a l u e=” 0 ”>No</o p t i o n >
</ s e l e c t >
</p>
<h2 a l i g n= ’ c e n t e r ’>
<p><i n p u t type=” submit ” name=” i n i c i a r ” a l i g n=” c e n t e r ”
v a l u e=” I n i c i a r s e s i o n ”></p>
</h2>
</form>

<?php
i f ( i s s e t ( $ POST [ ’ submit ’ ] ) ) {
$ s e l e c t e d v a l u e = $ POST [ ’ I n c i d e n t e ’ ] ;
}
?>
</div>
</div>
</div>
</body>
</html>

238
 Archivo validacion.php

<!DOCTYPE html>
<html l a n g=” en ” c l a s s=”demo−1 no−j s ”>
<head>
<meta c h a r s e t=”UTF−8” />
<meta http−e q u i v=”X−UA−Compatible ” c o n t e n t=” IE=edge ”>
<meta name=” v i e w p o r t ” c o n t e n t=” width=d e v i c e −width , i n i t i a l −s c a l e =1”>
< t i t l e >S i s t e m a de R e g i s t r o de Malware</ t i t l e >
<meta name=” a u t h o r ” c o n t e n t=” A l e j a n d r o Bá r c e n a s ”/>
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” c s s /demo . c s s ” />
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” c s s / component . c s s ” />
</head>
<body>
<d i v c l a s s=” c o n t a i n e r ”>
<header c l a s s=” c c h e a d e r ”>
<h1><b>S i s t e m a de R e g i s t r o de Malware</b></h1>
</header>

<d i v c l a s s=” wrapper ”>

<d i v c l a s s=” c c l o g i n i c o n s ”>
<h2 a l i g n= ’ c e n t e r ’>El nombre de u s u a r i o o l a c o n t r a s e ña que
i n g r e s a s t e no c o i n c i d e n con n u e s t r o s r e g i s t r o s . <p>
Por f a v o r , r e v i s a e i n t é n t a l o de nuevo .
<form a c t i o n= ’ i n d e x . php ’ method=POST>
<p><br><i n p u t type=” submit ” v a l u e=” R e g r e s a r ”></p>
</form>
</h2>
</div>
</div>
</div>
</body>
</html>

239
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

Archivo principal.php

<?php
r e q u i r e o n c e ( ” s e s i o n . c l a s s . php” ) ;
r e q u i r e o n c e ( ” s e s i o n . c l a s s . php” ) ;
$ s e s i o n = new s e s i o n ( ) ;
$ u s u a r i o = $ s e s i o n −>g e t ( ” u s e r ” ) ;
$cnx = m y s q l i c o n n e c t ( ” l o c a l h o s t ” , ” r o o t ” , ”<Password r o o t MySQL>” , ”
usuario web ” ) ;
$ c o u n t e r q u e r y = ”SELECT v i s i t c o u n t e r FROM u s u a r i o WHERE nombre=’
$usuario ’” ;
$ c o n s u l t a = m y s q l i q u e r y ( $cnx , $ c o u n t e r q u e r y ) ;
$ r e s u l t = mysqli num rows ( $ c o n s u l t a ) ;
i f ( $ r e s u l t > 0) {
while ( $ o b j = m y s q l i f e t c h o b j e c t ( $ c o n s u l t a ) )
$ c o u n t e r = $ o b j −> v i s i t c o u n t e r ;
}
$ SESSION [ ’ c o u n t e r ’ ] = $ c o u n t e r ;
mysqli close () ;
i f ( $ u s u a r i o == f a l s e ) {
header ( ” L o c a t i o n : i n d e x . php” ) ;
} else {
?>
<!DOCTYPE html>
<html l a n g=” en ” c l a s s=”demo−1 no−j s ”>
<head>
<meta c h a r s e t=”UTF−8” />
<meta http−e q u i v=”X−UA−Compatible ” c o n t e n t=” IE=edge ”>
<meta name=” v i e w p o r t ” c o n t e n t=” width=d e v i c e −width , i n i t i a l −
s c a l e =1”>
< t i t l e >S i s t e m a de C o n s u l t a de Malware</ t i t l e >
<meta name=” a u t h o r ” c o n t e n t=” A l e j a n d r o Bá r c e n a s ”/>
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” c s s /demo . c s s ” />
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” c s s / component . c s s
” />

240
 <l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” a s s e t s / b o o t s t r a p /
c s s / b o o t s t r a p . min . c s s ” />
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” c s s /
e s t i l o s t a b l a s . c s s ”>
<l i n k r e l=” s t y l e s h e e t ” type=” t e x t / c s s ” h r e f=” a s s e t s /
s w e e t a l e r t 2 . c s s ”>
</head>
<body>
<header>
<!−− BOOTSTRAP NAVBAR −−>
<nav c l a s s=” navbar navbar−i n v e r s e navbar−f i x e d −top ”>
<d i v c l a s s=” c o n t a i n e r ”>
<d i v c l a s s=” navbar−h e a d e r ”>
<button type=” button ” c l a s s=” navbar−t o g g l e
c o l l a p s e d ” data−t o g g l e=” c o l l a p s e ” data−t a r g e t=
”#navbar ” a r i a −expanded=” f a l s e ” a r i a −c o n t r o l s=
” navbar ”>
<span c l a s s=” s r −o n l y ”>Toggle n a v i g a t i o n </span>
<span c l a s s=” i c o n −bar ”></span>
<span c l a s s=” i c o n −bar ”></span>
<span c l a s s=” i c o n −bar ”></span>
</button>
<a c l a s s=” navbar−brand ” h r e f=”#”><img s r c=” images
/ unam white . png” s t y l e=” width : 40 px ; margin−top
: −10px ; ”></a>
</div>
<d i v i d=” navbar ” c l a s s=” c o l l a p s e navbar−c o l l a p s e ”>
<u l c l a s s=” nav navbar−nav navbar−r i g h t ”>
< l i ><a h r e f=”#”>Bienvenid@ <?php echo $ s e s i o n −>
g e t ( ” u s e r ” ) ; ?></a></ l i >
<l i c l a s s=” dropdown ”>
<a h r e f=”#” c l a s s=”dropdown−t o g g l e ” data−t o g g l e
=” dropdown ” r o l e=” button ” a r i a −haspopup=”
t r u e ” a r i a expanded=” f a l s e ”> Menú <span
c l a s s=” c a r e t ”> </span></a>

241
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

<u l c l a s s=”dropdown−menu”>
< l i ><a h r e f=” h t t p :// <? php p r i n t $ SERVER { ’
SERVER ADDR ’ } ; ? >:8080/ browse / page /1 ”
t a r g e t=” b l a n k ”>I n g r e s a r a l r e p o s i t o r i o
de an á l i s i s de Cuckoo</a></ l i >
< l i ><a h r e f=”#” o n c l i c k=” r e i n i c i a r c o n t a d o r
( ) ”>R e i n i c i a r c o n t a d o r de C o n s u l t a s de
Malware</a></ l i >
<i n p u t i d=” s e s i o n u s e r ” type=” hidden ” name=”
s e s i o n ” v a l u e=”<?php echo $ s e s i o n −> g e t
( ’ u s e r ’ ) ;? > ” />
< l i ><a h r e f=” c e r r a r s e s i o n . php”>C e r r a r S e s i ón
</a></ l i >
</ul>
</ l i >
</ul>
</div ><!−−/.nav−c o l l a p s e −−>
</div>
</nav>
</header>
<!−− BOOTSTRAP NAVBAR −−>
<d i v c l a s s=” c o n t a i n e r ” s t y l e=” margin−top : 40 px ; ”>
<header c l a s s=” c c h e a d e r ”>
<h1><b>S i s t e m a de C o n s u l t a de Malware</b></h1>
</header>
<?php
$ f i l e = fopen ( ” /home/ s n o r t −cuckoo / E s c r i t o r i o /
Informacion Muestras . txt ” , ” r ” ) ;
if (! $file ){

242
 echo ’<button c l a s s =”btn btn−primary ” type=”button ”
s t y l e =”margin−bottom : 10 px ; background−c o l o r
:#054586;” > V i s i t a s para c o n s u l t a de malware <
span i d=”c o u n t e r ” c l a s s =”badge”> ’ . $ SESSION [ ’
c o u n t e r ’ ] . ’</span></button><p a l i g n=c e n t e r ><br><
f o n t c o l o r =”r e d”><b>ERROR! </b></f o n t ></br></br>
No ha s i d o p o s i b l e l e e r e l a r c h i v o <b>”
I n f o r m a c i o n Muestras . t x t ”</b>.</br> Favor de
r e v i s a r su nombre y s u s p e r m i s o s . </p> ’ ;
} else {
$loop = 0;
echo ’<button c l a s s =”btn btn−primary ” type=”button ”
s t y l e =”margin−bottom : 10 px ; background−c o l o r
:#054586;” > V i s i t a s para c o n s u l t a de malware <
span i d=”c o u n t e r ” c l a s s =”badge”> ’ . $ SESSION [ ’
c o u n t e r ’ ] . ’</span></button><t a b l e c l a s s =” c e n t e r
t a b l e t a b l e −condensed t a b l e −r e s p o n s i v e t a b l e −
b o r d e r e d”>< t r c l a s s =”panel −d e f a u l t ” s t y l e =”border
−c o l o r : #054586; background−c o l o r : #054586; c o l o r :
w h i t e ;”><th>ID</th><th>Fecha de an á l i s i s </th><th>
Nombre muestra </th><th>SHA256</th><th>Tasa de
D e t e c c i ón de A n t i v i r u s ( %)</th><th>R e p u t a c i ón
V i r u s T o t a l (−100 a 1 0 0 )</th><th>Reporte de
Cuckoo</th><th>Enviar r e p o r t e por e−mail </th></t r
>’ ;
$c = ” ’ ” ;
while ( ! f e o f ( $ f i l e ) ) {
$ l o o p ++;
$line = fgets ( $file ) ;
$ f i e l d [ $ l o o p ] = explode ( ’ ! ’ , $ l i n e ) ;
$muestra = $c . trim ( $ f i e l d [ $ l o o p ] [ 1 ] ) . $c ;
$path = $c . trim ( $ f i e l d [ $ l o o p ] [ 5 ] ) . $c ;
i f ( $ f i e l d [ $ l o o p ] [ 0 ] == ’ ’ ) {
break ;
}

243
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

echo ’<t r ><td> ’ . $ l o o p . ’</td><td> ’ . $ f i e l d [ $ l o o p

] [ 0 ] . ’</td><td> ’ . $ f i e l d [ $ l o o p ] [ 1 ] . ’</td><td
> ’ . $ f i e l d [ $ l o o p ] [ 2 ] . ’</td><td> ’ . substr (
$ f i e l d [ $ l o o p ] [ 3 ] , 0 , 5 ) . ’ %</td><td> ’ . $ f i e l d [
$ l o o p ] [ 4 ] . ’</td><td><a h r e f =” ’ . $ f i e l d [ $ l o o p
] [ 5 ] . ’ ” t a r g e t =” b l a n k ”>Ver</a></td><td><a
h r e f =”#” o n c l i c k =”m a i l a t t a c h m e n t ( ’ . $path . ’
, ’ . $muestra . ’ ) ;” > Enviar </a></td></t r > ’ ;
$ f i l e ++;
}
echo ’</ t a b l e > ’ ;
fclose ( $ f i l e ) ;
}
?>
</div>
<f o o t e r >
< s c r i p t s r c=” a s s e t s / j q u e r y − 2 . 2 . 1 . min”></ s c r i p t >
< s c r i p t s r c=” a s s e t s / b o o t s t r a p / j s / b o o t s t r a p . min . j s ”></ s c r i p t
>
< s c r i p t s r c=” a s s e t s / s w e e t a l e r t 2 . min . j s ”></ s c r i p t >
< s c r i p t c h a r s e t=”UTF−8”>f u n c t i o n m a i l a t t a c h m e n t ( ruta ,
nombre muestra ) {
swal ({
title : ’ Enviar c o r r e o a l SysAdmin : ’ ,
showCancelButton : true ,
confirmButtonText : ’ Enviar ’ ,
closeOnConfirm : f a l s e ,
html : ’<p><i n p u t i d=”e m a i l ” p l a c e h o l d e r =”e−m a i l”><i n p u t
i d=”r u t a ” v a l u e=” ’+ r u t a + ’ ” type=”hidden”><i n p u t i d
=”nombre muestra ” v a l u e=” ’+ nombre muestra + ’ ” type
=”hidden ”/> ’ ,
allowOutsideClick : false
},
function () {
var parametro1 = {

244
 ” muestra ” : $ ( ’#nombre muestra ’ ) . v a l ( ) ,
” e m a i l ” : $ ( ’#e m a i l ’ ) . v a l ( ) ,
” path ” : $ ( ’#r u t a ’ ) . v a l ( )
};

$ . ajax ({
data : parametro1 ,
url : ’ s e n d m a i l . php ’ ,
type : ’POST ’ ,
beforeSend : function () {
},
success : function ( response ) {
swal ( response )
}
}) ;
})
}

function reiniciar contador () {

var u s u a r i o p h p = {
” s e s i o n u s e r ” : $ ( ’#s e s i o n u s e r ’ ) . v a l ( )
};

$ . ajax ({
data : u s u a r i o p h p ,
url : ’ r e i n i c i a r c o n t a d o r . php ’ ,
type : ’POST ’ ,
} ) . done ( f u n c t i o n ( msg ) {
<?php
$ SESSION [ ’ c o u n t e r ’ ] = 0 ;
?>
location . reload () ;
}) ;
}
</ s c r i p t >

245
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

</ f o o t e r >
</body>
</html>
<?php
}
?>

246
 Archivo reiniciar contador.php

<?php
$ u s e r s e s s i o n = $ POST [ ’ s e s i o n u s e r ’ ] ;
$ c o n e x i o n = m y s q l i c o n n e c t ( ” l o c a l h o s t ” , ” r o o t ” , ”<Password r o o t MySQL>” , ”
usuario web ” ) ;
$ u p d a t e q u e r y = ”UPDATE u s u a r i o SET v i s i t c o u n t e r = ’0 ’ WHERE nombre=’” .
$user session . ” ’” ;
mysqli query ( $conexion , $update query ) ;
?>

Archivo sendmail.php

<?php
$ a r c h i v o a d j u n t o = $ POST [ ’ muestra ’ ] ;
$ m y f i l e = ” r e p o r t . html ” ;
$my name = ”<nombre>” ;
$my mail = ”<c o r r e o d e s d e donde s e e n v i a r án l o s c o r r e o s e l e c t r ó n i c o s >” ;
$ m y r e p l y t o = ”<c o r r e o h a c i a donde podr á s e r r e s p o n d i d o e l c o r r e o
e l e c t r ó n i c o e n t r a n t e >” ;
$my subject = ” $archivo adjunto ” ;
$my message = ” Reporte de l a muestra \” $ a r c h i v o a d j u n t o \” a n a l i z a d a con
Cuckoo SandBox . ” ;
$ m y n a m e f o l d e r = ’ Reporte . z i p ’ ;
$ m a i l t o = $ POST [ ’ e m a i l ’ ] ;
$ l i n k = $ POST [ ’ path ’ ] ;
$ a r c h i v e = $ SERVER [ ’DOCUMENT ROOT’ ] . $ l i n k ;
$ m y f i l e n a m e = ’ r e p o r t . html ’ ;

m a i l a t t a c h m e n t ( $ m y f i l e , $ m a i l t o , $my mail , $my name , $ m y r e p l y t o ,

$ m y s u b j e c t , $my message , $my name folder , $ a r c h i v e , $my filename ,
$archivo adjunto ) ;

f u n c t i o n m a i l a t t a c h m e n t ( $ f i l e n a m e , $ m a i l t o , $ f r o m m a i l , $from name ,
$ r e p l y t o , $ s u b j e c t , $message , $ n a m e f o l d e r , $ f i l e , $ f i l e n a m e ,
$attached file ) {
i f ( f i l t e r v a r ( $ m a i l t o , FILTER VALIDATE EMAIL) ) {

247
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

$ z i p = new Z i p A r c h i v e ;
i f ( $ z i p −> open ( $ n a m e f o l d e r , Z i p A r c h i v e : : CREATE)!==TRUE) {
exit ( ” Imposible a b r i r e l archivo : $name folder ” ) ;
} else {
$ z i p −> a d d F i l e ( $ f i l e , $ f i l e n a m e ) ;
$ z i p −> c l o s e ( ) ;
}

$ f i l e = $name folder ;
$file size = filesize ( $file ) ;
$ h a n d l e = fopen ( $ f i l e , ” r ” ) ;
$ c o n t e n t = fread ( $handle , $ f i l e s i z e ) ;
fclose ( $handle ) ;
$ c o n t e n t = chunk split ( base64 encode ( $ c o n t e n t ) ) ;
$ u i d = md5( uniqid ( time ( ) ) ) ;
$ h e a d e r = ”From : ” . $from name . ” <” . $ f r o m m a i l . ”>\r \n” ;
$ h e a d e r .= ” Reply−To : ” . $ r e p l y t o . ” \ r \n” ;
$ h e a d e r .= ”MIME−V e r s i o n : 1 . 0 \ r \n” ;
$ h e a d e r .= ” Content−Type : m u l t i p a r t / mixed ; boundary=\”” . $ u i d . ” \”\
r \n\ r \n” ;
$ h e a d e r .= ” This i s a multi −p a r t message i n MIME format . \ r \n” ;
$ h e a d e r .= ”−−” . $ u i d . ” \ r \n” ;
$ h e a d e r .= ” Content−type : t e x t / p l a i n ; c h a r s e t=i s o −8859−1\ r \n” ;
$ h e a d e r .= ” Content−T r a n s f e r −Encoding : 7 b i t \ r \n\ r \n” ;
$ h e a d e r .= $message . ” \ r \n\ r \n” ;
$ h e a d e r .= ”−−” . $ u i d . ” \ r \n” ;
$ h e a d e r .= ” Content−Type : a p p l i c a t i o n / o c t e t −stream ; name=\”” .
$ f i l e . ” \”\ r \n” ;
$ h e a d e r .= ” Content−T r a n s f e r −Encoding : b a s e 6 4 \ r \n” ;
$ h e a d e r .= ” Content−D i s p o s i t i o n : attachment ; f i l e n a m e =\”” . $ f i l e . ”
\”\ r \n\ r \n” ;
$ h e a d e r .= $ c o n t e n t . ” \ r \n\ r \n” ;
$ h e a d e r .= ”−−” . $ u i d . ”−−” ;
i f ( mail ( $ m a i l t o , $ s u b j e c t , ” ” , $ h e a d e r ) ) {

248
 echo ” El r e p o r t e de l a muestra \” $ a t t a c h e d f i l e \” ha s i d o
enviado exitosamente ! ” ;
unlink ( $ f i l e ) ;
} else {
echo ”ERROR! El c o r r e o no pudo s e r e n v i a d o . ” ;
}
} else {
echo ” D i r e c c i ón de e−m a i l no vá l i d a ! ” ;
}
}
?>

249
C. CÓDIGO FUENTE DEL SISTEMA DE CONSULTA DE MALWARE.

Archivo sesion.class.php

<?php
class sesion {
function construct () {
session start () ;
}

p u b l i c f u n c t i o n s e t ( $nombre , $ v a l o r , $ c o n t a d o r ) {
$ SESSION [ $nombre ] = $ v a l o r ;
$ SESSION [ ” c o u n t e r ” ] = $ c o n t a d o r ;
}

p u b l i c f u n c t i o n g e t ( $nombre ) {
i f ( i s s e t ( $ SESSION [ $nombre ] ) ) {
r e t u r n $ SESSION [ $nombre ] ;
} else {
return false ;
}
}

p u b l i c f u n c t i o n e l i m i n a v a r i a b l e ( $nombre ) {
unset ( $ SESSION [ $nombre ] ) ;
}

public function termina sesion () {

$ SESSION = array ( ) ;
session destroy ( ) ;
}
}
?>

250
 Archivo cerrarsession.php

<?php
r e q u i r e o n c e ( ” s e s i o n . c l a s s . php” ) ;
$ s e s i o n = new s e s i o n ( ) ;
$ u s u a r i o = $ s e s i o n −> g e t ( ” u s e r ” ) ;
i f ( $ u s u a r i o == f a l s e ) {
header ( ” L o c a t i o n : i n d e x . php” ) ;
} else {
$ u s u a r i o=$ s e s i o n −> g e t ( ” u s e r ” ) ;
$ s e s i o n −> t e r m i n a s e s i o n ( ) ;
header ( ” l o c a t i o n : i n d e x . php” ) ;
}
?>

251