Unidad3 Paso5 Consolidado - 2150521 - 24 PDF

Paso 6 Actividad Colaborativa 3
CURSO ACCESO A LA WAN
Nombre del alumno

MIGUEL ANGEL ARIAS
BORIS DE JESUS VALVERDE
JONATHAN ALBERTO GOMEZ
SAMUEL ALEJANDRO CLAVIJO HERNANDEZ
Grupo: 2150521_24
Tutor
JUAN ESTEBAN TAPIAS
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA (UNAD)

ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERA
INGENIERÍA DE TELECOMUNICACIONES
BOGOTÁ – 2021
INTRODUCCION
En el presente trabajo contiene el desarrollo los laboratorios propuestos para las primeras
cuatro unidades del curso de REDES CCNA CYBEROPS, que se componen de; Seguridad y
análisis de terminales, Monitoreo de la seguridad, Análisis de datos de intrusiones Manejo
y respuesta ante los incidentes
Para el desarrollo de esta actividad hizo uso de los conocimientos obtenidos hasta el
momento y los contenidos compartidos por el tutor del grupo los cuales fueron de gran
ayuda para analizar y plasmar la que se debía implementar para dar solución a la guía
EJERCICIOS SELECCIONADOS
BORIS VALVERDE
Packet Tracer: Explorar una implementación de NetFlow

Topología
Objetivos
Parte 1: Observar registros de flujos de NetFlow - Un sentido
Parte 2: Observar registros de NetFlow correspondientes a una sesión que ingresa y
sale del colector
Aspectos básicos
En esta actividad utilizarán Packet Tracer para crear tráfico de red y observarán los registros
de flujos de NetFlow correspondientes en un colector de NetFlow. Packet Tracer ofrece una
simulación básica de la funcionalidad de NetFlow. No sustituye a aprender NetFlow en un
equipo físico. Puede haber algunas diferencias entre los registros de flujos de NetFlow
generados por Packet Tracer y los registros creados por un equipo de red con todas las
funciones.
Parte 1: Observar registros de flujos de NetFlow - Un sentido
Paso 1: Abran el colector de NetFlow.
a. En el Colector de NetFlow, hagan clic en la ficha Desktop (Escritorio). Hagan clic en el
icono del Colector de Netflow.
b. Hagan clic en el botón de opción “On” (“Activado”) para activar el colector según sea
necesario. Posicionen y cambien el tamaño de la ventana para poder verla desde la
ventana de la topología de Packet Tracer.
Paso 2: Hagan ping al gateway predeterminado desde PC-1.
a. Hagan clic en PC-1.
b. Abran la ficha Desktop y hagan clic en el icono del Símbolo del sistema.
c. Introduzcan el comando ping para probar la conectividad al gateway predeterminado
en 10.0.0.1.
C:\> ping 10.0.0.1
d. Después de una breve demora, en la pantalla del Colector de NetFlow se verá un gráfico
circular.
Nota: Es posible que no se envíe el primer conjunto de pings al Colector de NetFlow
porque el proceso de ARP primero debe resolver direcciones IP y MAC. Si no aparece un
gráfico circular después de 30 segundos, repitan el ping al gateway predeterminado.
e. Hagan clic en el gráfico circular o en la entrada de las referencia para mostrar los detalles
del registro del flujo.
f. El registro del flujo tendrá entradas similares a las de la siguiente tabla. Sus marcas de
hora serán diferentes.
Entrada Valor Explicación
Traffic contribution 100 % (1/1) Esta es la proporción de todo el tráfico

representado por este flujo.
IPV4 SOURCE ADDRESS 10.0.0.10 Esta es la dirección IP de origen de los
paquetes del flujo.
IPV4 DESTINATION ADDRESS 10.0.0.1 Esta es la dirección IP de destino de los
paquetes del flujo.
TRNS SOURCE PORT 0 Este es el puerto de origen de la capa de
transporte. El valor es 0 porque se trata
de un flujo ICMP.
TRNS DESTINATION PORT 0 Este es el puerto de destino de la capa de
transporte. El valor es 0 porque se trata
de un flujo ICMP.
IP PROTOCOL 1 Esto identifica al servicio de la Capa 4;
suele ser 1 para ICMP, 6 para TCP y 17
para UDP.
timestamp first 00:47:49.593 Esta es la marca de hora correspondiente
al comienzo del flujo.
timestamp last 00:47:52.598 Esta es la marca de hora correspondiente
al último paquete del flujo.
tcp flags 0x00 Este es el valor del marcador de TCP. En
este caso, no participa ninguna sesión de
TCP porque el protocolo es ICMP.
counter bytes 512 Esta es la cantidad de bytes en el flujo.
counter packets 4 Esta es la cantidad de paquetes en el flujo.
interface input Gig0/0 Esta es a interfaz del exportador de flujos
que recogió el flujo en el sentido de
entrada (ingreso a la interfaz del
dispositivo de monitoreo).
interface output Null Esta es a interfaz del exportador de flujos
que recogió el flujo en el sentido de salida
(egreso de la interfaz del dispositivo de
monitoreo). El valor es "Null" porque se
trataba de un ping a la interfaz de entrada.
En este caso, el flujo representa al ping de ICMP desde el host 10.0.0.10 hacia 10.0.0.1.
Había cuatro paquetes de ping en el flujo Los paquetes ingresaron a la interfaz Gig0/0 del
exportador.
Nota: En esta actividad, el router perimetral se ha configurado como exportador de flujos
de NetFlow. La interfaz LAN está configurada para monitorear los flujos que ingresan a ella
desde la red LAN. La interfaz en serie se ha configurado para recoger los flujos que
ingresan a ella desde Internet. Esto se ha hecho para simplificar esta actividad.
Para ver el tráfico que coincide con una sesión bidireccional completa, el exportador de
NetFlow tendría que configurarse para recoger flujos que ingresan y salen de la red.
Paso 3: Crear tráfico adicional

a. Haga clic en PC-2 > Escritorio.
b. Abran un símbolo del sistema y hagan ping al gateway predeterminado: 10.0.0.1.
¿Qué esperan ver en los registros de flujo del colector de NetFlow? ¿Cambiarán las
estadísticas correspondientes al registro de flujo ya existente, o aparecerá un flujo nuevo
en el gráfico circular?
Se visualiza un nuevo flujo desde la IP Origen PC2
c. Regresen a PC-1 y repitan el ping al gateway.

¿Cómo se representará este tráfico? ¿Como un segmento nuevo en el gráfico circular, o
modificará los valores del registro de flujo ya existente?
Modifico los valores
d. Emitan pings desde PC-3 y PC-4 a la dirección del gateway predeterminado.
¿Qué debería suceder en la pantalla del colector de flujos?
Se agrego nuevo registro
Parte 2: Observar registros de NetFlow correspondientes a una

sesión que ingresa y sale del colector
El exportador de NetFlow se ha configurado para recoger los flujos que salen de la red LAN e
ingresan al router desde Internet.
Paso 1: Acceder al servidor web por dirección IP

Antes de continuar, apaguen y enciendan el Colector de NetFlow para borrar los flujos.
a. Hagan clic en NetFlow Collector (Colector de NetFlow) > Ficha Physical (Físico).
b. Hagan clic en el botón de encendido rojo para apagar el servidor. Luego, vuelvan a hacerle
clic para encenderlo nuevamente.
c. En el Colector de NetFlow, hagan clic en la ficha Desktop (Escritorio).

d. Hagan clic en el icono del Colector de Netflow. Hagan clic en el botón de opción “On”
(“Activado”) para activar el colector. Cierren la ventana del Colector de NetFlow.
e. Antes de acceder a un servidor web desde PC-1, predigan cuántos flujos habrá en el
gráfico circular. Explique.
________________________________________________________________________
____________
________________________________________________________________________
____________
Basándose en los que saben sobre protocolos de red y NetFlow, predigan los valores
correspondientes a las solicitudes de páginas web que salen de la red LAN.
Campo de registro Valor Pautas
Dirección IP de origen 10.0.0.10 PC1

Dirección IP de destino 192.0.2.100 Servidor Web
1025–5000 (MS Windows de
manera predeterminada, que Se trata de un valor aproximado
Puerto de origen es lo que utiliza PT. que se crea dinámicamente.
Puerto de destino 80
Interfaz de entrada G0/0
Interfaz de salida S0/0/1
Predigan los valores correspondientes a la respuesta de la página web que ingresa al

router del exportador de NetFlow desde Internet.
Campo de registro Valor Pautas
Dirección IP de origen 192.0.2.100

Dirección IP de destino 10.0.0.10
Puerto de origen 80
Este es cualquier valor asignado
aleatoriamente desde el rango de
Puerto de destino 1025-5000 puertos efímeros.
Interfaz de entrada S0/0/1
Interfaz de salida G0/0
f. Hagan clic en PC-1 > Desktop. Si es necesario, cierren la ventana del Símbolo del
sistema. Hagan clic en el icono del navegador web.
g. En el navegador web de PC-1, introduzca 192.0.2.100 y haga clic en Ir. Aparecerá la
página web del Sitio web de ejemplo.
h. Después de una breve demora, aparecerá un gráfico circular nuevo en el colector de
NetFlow. Verán al menos dos segmentos circulares correspondientes a la solicitud y a la
respuesta HTTP. Podrían ver un tercer segmento si se excedió el tiempo de espera del
caché de ARP correspondiente a PC-1.
i. Hagan clic en el segmento circular de HTTP para mostrar el registro y verificar sus
predicciones.
j. Hagan clic en el enlace a la página de Copyrights.
¿Qué ocurrió? Expliquen. (Pista: comparen el número de puerto en el host correspondiente
a los flujos).
Se agregaron nuevos registros de trafico
Comparen los flujos. Sin contar las diferencias obvias en la marca de hora, las
direcciones IP de origen y destino, los puertos y las interfaces, ¿qué más difiere entre los
flujos de la solicitud y de la respuesta?
________________________________________________________________________
____________
________________________________________________________________________
____________
________________________________________________________________________
____________
Paso 2: Acceder al servidor web por dirección IP

a. Apaguen y enciendan el Colector de NetFlow para borrar los flujos.
b. Activen el servicio del Colector de NetFlow.
c. Antes acceder al servidor web por su dirección URL. ¿Qué esperan ver en la pantalla del
colector de NetFlow?
Cero flujo
d. En PC-1, introduzcan www.example.com en el campo de la URL y presionen Go.
e. Después de que los flujos aparezcan en la pantalla, inspeccionen cada registro de los
flujos.
¿Qué valores ven para el campo del protocolo IP del registro del flujo? ¿Qué significan
estos valores?
17
Tabla de calificación sugerida
Ubicación de la Posibles Puntos

consulta puntos obtenidos
Parte 1, Paso 3b 10
Parte 1, Paso 3c 10
Parte 1, Paso 3d 10
Parte 2, Paso 1f 30
Parte 2, Paso 1j 30
Parte 2, Paso 2c 10
Puntuación total 100
MIGUEL ARIAS
Packet Tracer: Generar archivos de registro desde varias

fuentes
Topología
Objetivos
Parte 1: Utilizar syslog para capturar archivos de registro de varios dispositivos de red
Parte 2: Observar los registros de acceso de usuarios AAA
Parte 3: Observar información de NetFlow
Antecedentes / Escenario
En esta actividad, utilizarán Packet Tracer para ver datos de red generados por syslog, AAA y
NetFlow.
Parte 1: Ver entradas de registro con Syslog
Paso 1: Servidor Syslog
Syslog es un sistema de mensajería diseñado para admitir el registro remoto. Los
clientes syslog envían entradas de registro a un servidor syslog. El servidor syslog concentra y
almacena las entradas de registro. Packet Tracer admite operaciones básicas de syslog y se
puede utilizar con fines de demostración. La red incluye un servidor syslog y clientes syslog.
R1, R2, el Switch de núcleo y el Firewall son clientes syslog. Estos dispositivos están
configurados para enviar sus entradas de registro al servidor syslog. El servidor syslog recoge
las entradas de registro y permite que se las lea.
Las entradas de registro se categorizan en siete niveles de gravedad. Los niveles más bajos
representan los eventos más graves. Los niveles son los siguientes: emergencias (0),
alertas (1), crítico (2) errores (3), advertencias (4), notificaciones (5), informativo (6) y
depuración (7). Los clientes syslog se pueden configurar para enviar entradas de registro a
servidores syslog en función del nivel de gravedad.
a. Hagan clic en el Servidor Syslog para abrir su ventana.
b. Seleccione la ficha Servicios y, luego, SYSLOG en la lista de servicios que aparece a la

izquierda.
c. Hagan clic en Activar para activar el servicio de Syslog.
d. Las entradas de Syslog provenientes de clientes syslog aparecerán en la ventana de la

derecha. En este momento no hay ninguna entrada.
e. Mantengan esta ventana abierta y visible y sigan con el Paso 2.

Paso 2: Habiliten Syslog.
Los dispositivos ya están configurados para enviar mensajes de registro al servidor syslog,
pero Packet Tracer solo admite el registro para el nivel de gravedad de depuración con syslog.
Por eso debemos generar mensajes del nivel de depuración (nivel 7) para que se puedan
enviar al servidor syslog.
a. Hagan clic en R1 > ficha CLI.
b. Presionen Intro para que aparezca un símbolo del sistema y escriban el comando enable.
c. Introduzca el comando debug eigrp packets para habilitar la depuración EIGRP. La

consola de la línea de comandos se llenará inmediatamente con mensajes de depuración.
d. Regresen a la ventana del Servidor Syslog. Verifiquen que las entradas de registro
aparezcan en el servidor syslog.
e. Después de que se hayan registrado algunos mensajes, hagan clic en el botón de

opciones para Desactivar el servicio de syslog.
Indiquen parte de la información que se incluye en los mensajes de syslog que está
mostrando el Servidor Syslog.
________________en el syslog vemos el nombre de sost que es la ip de origen, se ven
mensaje de sde firewall también , el protocolo EIGRP ,INTERFACES, origen
____________________________________________________________________
________________________________________________________________________
____________
f. Cierren la ventana del dispositivo R1.
Parte 2: Registrar el acceso de los usuarios

Otro tipo importante de registro está relacionado con el acceso de los usuarios. Tener registros
de los inicios de sesión de los usuarios es crucial para la solución de problemas y el análisis de
tráfico. Cisco IOS admite Autenticación, Autorización y Auditoría (AAA). Con AAA, es posible
no solo delegar la tarea de validación de usuarios a un servidor externo, sino también a
actividades de registro.
TACACS+ es un protocolo diseñado para permitir la autenticación remota a través de un
servidor centralizado.
Packet Tracer ofrece compatibilidad básica con AAA y TACACS+. R2 también está configurado
como servidor TACACS+. R2 le preguntará al servidor si ese usuario es válido; para ello se
verificará el nombre de usuario y la contraseña y se concederá o negará el acceso en función
de la respuesta. El servidor almacena las credenciales del usuario y también es capaz de
registrar transacciones de inicio de sesión del usuario. Sigan los pasos que se indican a
continuación para iniciar sesión en R2 y mostrar las entradas de registro relacionadas con ese
inicio de sesión:
a. Hagan clic en el Servidor Syslog para abrir su ventana.
b. Seleccionen la ficha Escritorio y, luego Auditoría AAA. Dejen esta ventana abierta.
c. Hagan clic en R2 > CLI.

d. Presionen Intro para que aparezca un símbolo del sistema. R2 le pedirá su nombre de
usuario y contraseña antes de otorgarle acceso a su CLI. Introduzca las siguientes
credenciales de usuario: analyst y cyberops como nombre de usuario y contraseña,
respectivamente.
e. Regresen a la ventana Registros de Auditoría AAA del servidor Syslog.
¿Qué información se incluye en la entrada de registro?
______fecha de inicio de session , ip del router
r2,______________________________________________________________________
________
________________________________________________________________________
____________
________________________________________________________________________
____________
________________________________________________________________________
____________
f. En R2, introduzca el comando logout.
¿Qué sucedió en la ventana Auditoría AAA?
_________flag stop significa que cerro

sesion___________________________________________________________________
________
________________________________________________________________________
____________
Parte 3: NetFlow y la visualización

En la topología, el servidor Syslog también es un colector de NetFlow. El firewall está
configurado como exportador de NetFlow.
a. Hagan clic en el Servidor Syslog para abrir su ventana. Cierren la ventana Registros de
Auditoría AAA.
b. En la ficha Escritorio, seleccione Colector de Netflow. Se deben activar los servicios del
Colector del NetFlow.
c. Desde cualquier PC, hagan un ping al Servidor web corporativo en 209.165.200.194.
Después de una breve demora, el gráfico circular se actualizará para mostrar el nuevo flujo
de tráfico.
Nota: Los gráficos circulares que se muestren variarán en función del tráfico que haya en
la red. Otros flujos de paquetes, como el tráfico relacionado con EIGRP, se están enviando
entre los dispositivos. NetFlow está capturando esos paquetes y exportando estadísticas al
Colector de NetFlow. Cuanto más tiempo se permita ejecutar NetFlow en una red se
capturarán más estadísticas sobre el tráfico.
Reflexión
Si bien las herramientas presentadas en esta actividad son útiles, cada una tiene su propio
servicio y es posible que tenga que ser ejecutada en dispositivos totalmente diferentes. Una
mejor manera (que se analiza más adelante en el curso) es concentrar toda la información de
registro en una sola herramienta, lo que permite facilitar la referencia cruzada y hace posibles
potentes funcionalidades de búsqueda. Las plataformas de Administración de información y
eventos de seguridad (Security Information and Event Management, SIEM) puede recopilar
archivos de registro y otros datos de diversas fuentes e integrar la información correspondiente
al acceso por medio de una sola herramienta.
JUAN ESTEBAN TAPIAS
Práctica de laboratorio: Configurar un entorno con varias

máquinas virtuales (VM)
Topología
Objetivos
En esta práctica de laboratorio, configurarán un entorno de red virtual; para ello, conectarán
varias máquinas virtuales en Virtualbox.
Se utiliza un sandbox de seguridad de la red virtual o un entorno de laboratorio con varias VM
para el análisis y las pruebas de seguridad. Este entorno con varias VM es obligatorio para
prácticas de laboratorio más avanzadas de este curso.
Recursos necesarios
 Máquina virtual CyberOps Workstation (cyberops_workstation.ova).
 Conexión a Internet
 Los siguientes archivos .ova para crear VM adicionales: kali_linux.ova, metasploitable.ova
y security_onion.ova. Hagan clic en cada enlace para descargar los archivos.
 Servidor con al menos 8 GB de RAM y 45 GB de espacio libre en disco.
Nota: Si sus computadoras solo tienen 8 GB de RAM, asegúrense de no tener ninguna
otra aplicación abierta excepto por un programa lector de PDF para consultar esta práctica
de laboratorio. Configuración de la VM
Tamaño
del Espacio Contrase
Máquina virtual SO RAM Usuario
archivo en disco ña
OVA
VM CyberOps Workstation Arch Linux 2,23 GB 7 GB 1 GB analyst cyberops

Kali Kali Linux 3,07 GB 10 GB 1 GB Raíz cyberops
Metasploitable Ubuntu Linux 851 MB 8 GB 512 MB msfadmin msfadmin
Security Onion Ubuntu Linux 2,35 GB 10 GB 4 GB analyst cyberops
Totales 8,5 GB 45 GB 6,5 GB
Nota: Si ha escrito incorrectamente el nombre de usuario correspondiente a la VM de Kali,

haga clic en Cancelar para introducir el nombre correcto.
Paso 1: Importar máquinas virtuales del dispositivo a VirtualBox

VirtualBox es capaz de alojar y ejecutar varias máquinas virtuales. Junto con la VM CyberOps
Workstation (Estación de trabajo CyberOps) que ya se ha instalado, importarán más máquinas
virtuales a VirtualBox para crear una red virtual.
Nota: Es posible que la pantalla tenga otro aspecto dependiendo de su versión de VirtualBox.
a. Utilice el menú de archivos de VirtualBox para instalar Kali Linux: Archivo > Importar
dispositivo; luego, diríjase al archivo kali_linux.ova y haga clic en Siguiente.
b. Aparecerá una ventana nueva en la que se presenta la configuración sugerida en el
archivo OVA. Marquen la casilla "Reinitialize the MAC address of all network cards"
("Reinicializar la dirección MAC de todas las tarjetas de red") en la parte inferior de la
ventana. Deje el resto de las configuraciones como predeterminadas. Haga clic en
Importar.
c. Una vez finalizada la importación, VirtualBox mostrará la nueva VM de Kali. El nombre de
archivo de su VM de Kali Linux podría ser diferente al del gráfico que se muestra a
continuación.
 Se realiza la importación de la MV Kali linux

d. Ahora importen las VM Metasploitable y Security Onion (Capa sobre capa de seguridad)
utilizando el mismo método.
e. Ahora, las cuatro VM aparecen en VirtualBox.
 MV Metasploitable
Paso 2: Conecte las máquinas virtuales en red para crear un laboratorio virtual.
En esta parte, se asegurarán de que la red esté configurada entre las VM. En VirtualBox, el
adaptador de red de una VM puede estar en modo puente (visible en la red como cualquier
otro dispositivo físico), en modo NAT (visible en la red pero en un espacio de direcciones IP
aparte) o en modo interno (solo visible para otras máquinas virtuales con el mismo nombre
interno o la misma red de área local [VLAN] virtual).
Examinen la configuración de red correspondiente a cada máquina virtual y fíjense de qué
manera los modos y nombres del adaptador de red ubican las VM en diferentes redes VLAN.
a. Kali tiene un adaptador de red que utiliza el modo red interna la VLAN Internet. Observe
de qué manera se corresponde con el diagrama de red de la página 1.
b. Metasploitable tiene dos adaptadores de red que utilizan el modo red interna, el Adaptador
1 corresponde a esta práctica de laboratorio y está en la VLAN de la dmz. Aunque se
muestra el Adaptador 2 para VirtualBox, no se lo utiliza en esta topología y se lo puede
ignorar.
c. Security Onion tiene cuatro adaptadores de red; tres de ellos utilizan el modo red interna y
uno el modo NAT, que se podría utilizar para conectarse a Internet. Security Onion conecta
a todas las VM de la red virtual, con un adaptador de red en cada una de las redes VLAN
(interna, dmz e Internet).
d. La VM CyberOps Workstation está en modo puente. No está en una red interna con las
otras VM. Tendrán que cambiar el adaptador de red a continuación.
e. Seleccionen la VM CyberOps Workstation en VirtualBox y hagan clic en Configuración.

Seleccione Red y pase el Adaptador 1 a red interna, con el nombre dentro. Hagan clic en
OK (Aceptar).
f. Ahora que el adaptador de red está en la red interna o en la VLAN correcta, encienda la
VM CyberOps Workstation e inicie sesión. Deberá cambiar la configuración de la dirección
IP con el objetivo de poder comunicarse en la red virtual.
g. Abran un símbolo del sistema y examinen el contenido de la carpeta de scripts que se
encuentra dentro de la carpeta lab.support.files/scripts.
[analyst@secOs~]$ ls lab.support.files/scripts
configure_as_dhcp.sh cyops.mn
start_ELK.sh
configure_as_static.sh fw_rules
start_miniedit.sh
cyberops_extended_topo_no_fw.py mal_server_start.sh
start_pox.sh
cyberops_extended_topo.py net_configuration_files
start_snort.sh
cyberops_topo.py reg_server_start.sh
start_tftpd.sh
[analyst@secOps ~]$
h. El script configure_as_dhcp.sh se utiliza para configurar la interfaz de red a fin de solicitar
una dirección IP a un servidor DHCP. Esta es la configuración predeterminada para la VM
CyberOps Workstation. Para configurar un entorno con varias VM, tendrán que ejecutar el
script configure_as_static.sh. Esta acción configurará la interfaz de red con la misma
dirección IP estática (192.168.0.11) y un gateway predeterminado de 192.168.0.1, que es
la VM Security Onion. La VM Security Onion es responsable del routing entre las redes
interna, DMZ e Internet. Ejecuten el script configure_as_static.sh e introduzcan la
contraseña (si el sistema se los solicita) para definir la dirección IP en 192.168.0.11 en la
red virtual.
[analyst@secOs~]$ sudo
./lab.support.files/scripts/configure_as_static.sh
[sudo] contraseña para analyst:
Configurar la NIC de la siguiente manera:
IP: 192.168.0.11/24
GW: 192.168.0.1
Nota: Si necesita utilizar la VM CyberOps Workstation como entorno autónomo con acceso
a Internet, regrese el adaptador de red a modo puente y ejecute el script
configure_as_dhcp.sh.
i. Regresen a VirtualBox y enciendan las otras VM: Kali Linux, Metasploitable y Security
Onion. Consulten la tabla Configuración de la VM para conocer la información del nombre
de usuario y de la contraseña.
Nota: Si es necesario, utilice la tecla control derecha para desbloquear el cursor y poder
navegar entre las ventanas.
j. Cuando se estén ejecutando todas las VM, hagan un ping desde la VM CyberOps
Workstation hacia las VM Metasploitable y Kali Linux. Utilicen Ctrl+C para detener el ping.
[analyst@secOps ~]$ ping 209.165.200.235
[analyst@secOps ~]$ ping 209.165.201.17
k. Cierren la ventana del terminal cuando hayan terminado.

Paso 3: Apaguen las VM.
a. Para cada VM, hagan clic en File > Close (Archivo > Cerrar).
b. Haga clic en el botón de opción Guardar el estado de la máquina y haga clic en Aceptar.
La próxima vez que inicie la máquina virtual, podrá volver a trabajar en el sistema operativo
en su estado actual.
Las otras dos opciones son las siguientes:

Enviar la señal de apagado: simula que se presiona el botón de encendido en una
computadora física.
Apagar la máquina: simula que se jala del enchufe de una computadora física.
CONCLUSIONES
Para realizar este tipo de laboratorios, es de suprema importancia tener bases claras en el sistema
operativo Linux, pues ejecutar comando por ejecutarlos es una tarea sencilla, pero al final no se
está aprendiendo, por ello se sugiere haber realizado los laboratorios de las primeras unidades
donde se trató el tema de OS linux desde cero. Por otro lado, se necesita si o si un computador
con mínimo 12 GB de memoria RAM para que todas las máquinas virtuales corran al mismo tiempo
sin problema.
BORIS VALVERDE
Práctica de laboratorio: Reglas de Snort y de firewalls
Topología
Objetivos
Parte 1: Preparar el entorno virtual
Parte 2: El firewall y los archivos de registro de IDS
Parte 3: Finalizar y desactivar el proceso de Mininet
En una red de producción segura, las alertas de red son generadas por diversos tipos de
dispositivos como dispositivos de seguridad, firewalls, dispositivos IPS, routers, switches y
servidores, entre otros. El problema es que no todas las alertas se crean de la misma manera.
Por ejemplo: las alertas generadas por un servidor las generadas por un firewall serán
diferentes y tendrán distintos contenidos y formatos.
En esta práctica de laboratorio, se familiarizará con las reglas de firewall y las firmas de IDS.
Recursos necesarios
 VM CyberOps Workstation
Nota: En esta práctica de laboratorio, la VM CyberOps Workstation es un contenedor para
alojar el entorno de Mininet que se muestra en la topología. Si se recibe un error de memoria
en un intento de ejecutar cualquier comando, cierre el paso, vaya a la configuración de VM y
aumente la memoria. El valor predeterminado es 1 GB; intente cambiarlo a 2 GB.

a. Abra Oracle VirtualBox y cambie la CyberOps Workstation al modo puente, si es
necesario. Seleccionen Machine > Settings > Network (Máquina > Configuración > Red).
En Conectado a, seleccione Adaptador de puente (o, si utiliza wifi con un proxy, puede
que necesite el adaptador NAT), y haga clic en Aceptar.
b. Inicie la VM CyberOps Workstation, abra un terminal y configure su red ejecutando el
script configure_as_dhcp.sh.
Como el script requiere privilegios de usuario avanzado, introduzcan la contraseña
correspondiente al usuario analyst.
[analyst@secOps ~]$ sudo
./lab.support.files/scripts/configure_as_dhcp.sh
[analyst@secOps ~]$
c. Utilicen el comando ifconfig para verificar que laVM CyberOps Workstation ahora tenga
una dirección IP en sus redes locales. También pueden probar la conectividad a un
servidor web público si emiten un ping a www.cisco.com. Presionen Ctrl+C para detener
los pings.
[analyst@secOps ~]$ ping www.cisco.com
PING e2867.dsca.akamaiedge.net (23.204.15.199) 56(84) bytes of
data.
64 bytes from a23-204-15-199.deploy.static.akamaitechnologies.com
(23.204.15.199): icmp_seq=1 ttl=54 time=28.4 ms
64 bytes from a23-204-15-199.deploy.static.akamaitechnologies.com
(23.204.15.199): icmp_seq=2 ttl=54 time=35.5 ms
^C
--- e2867.dsca.akamaiedge.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 28.446/32.020/35.595/3.578 ms
Parte 2: El firewall y los archivos de registro de IDS

A menudo se implementan firewalls y Sistemas de detección de intrusiones (Intrusion Detection
Systems, IDS) para automatizar parcialmente la tarea del monitoreo de tráfico. Tanto los
firewalls como los IDS comparan el tráfico entrante con reglas administrativas. Los firewalls
suelen comparar el encabezado de un paquete con un conjunto de reglas mientras que los IDS
utilizan la carga útil del paquete para compararla con los conjuntos de reglas. Como los
firewalls y los IDS aplican las reglas predefinidas a diferentes porciones del paquete IP, las
reglas de los IDS y de los firewalls tienen estructuras diferentes.
Aunque hay una diferencia en la estructura de las reglas, sigue habiendo ciertas similitudes
entre sus componentes. Por ejemplo: tanto las reglas de un firewall como las de un IDS
contienen componentes de correspondencia y componentes de acciones. Las acciones se
realizan una vez detectada una coincidencia.
 Componente de correspondencia: especifica los elementos de interés del paquete, por
ejemplo: origen del paquete, destino del paquete, protocolos y puertos de la capa de
transporte y los datos incluidos en la carga útil del paquete.
 Componente de acciones: especifica qué debe hacerse con el paquete que coincida con
un componente, por ejemplo: aceptar y reenviar el paquete, descartar el paquete, o enviar
el paquete a un conjunto de reglas secundario para profundizar su inspección.
Un diseño de firewall común es descartar paquetes de manera predeterminada y especificar
manualmente el tráfico que se debe permitir. Conocido como descartar por defecto, este
diseño tiene la ventaja de proteger la red de protocolos y ataques desconocidos. Como parte
de este diseño, es común registrar los eventos de los paquetes descartados porque se trata de
paquetes no permitidos explícitamente y, por lo tanto, infringen las políticas de la organización.
Tales eventos deben registrarse para próximos análisis.
Paso 1: Monitoreo de archivos de registro de un IDS en tiempo real

a. En la VM CyberOps Workstation VM, ejecuten el script para iniciar mininet.
./lab.support.files/scripts/cyberops_extended_topo_no_fw.py
*** Adding controller
*** Add switches
*** Add hosts
*** Add links
*** Starting network
*** Configuring hosts
R1 R4 H1 H2 H3 H4 H5 H6 H7 H8 H9 H10 H11
*** Starting controllers
*** Starting switches
*** Add routes
*** Post configure switches and hosts
*** Starting CLI:
mininet>
El cursor de mininet debería aparecer en la pantalla; eso indica que mininet está listo
para recibir comandos.
b. En el cursor de mininet, abran un shell en R1 con el siguiente comando:
mininet> xterm R1
mininet>
El shell de R1 se abre en una ventana del terminal con texto negro y fondo blanco. ¿Qué
usuario ha iniciado sesión en ese shell? ¿Qué nos lo indica?
c. En el shell de R1, inicien el IDS basado en Linux: Snort.

[root@secOps analyst]# ./lab.support.files/scripts/start_snort.sh
Running in IDS mode
--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
<output omitted>
Nota: No verá ningún indicador porque Snort ahora se está ejecutando en esta ventana. Si
por cualquier motivo, Snort deja de ejecutarse y aparece el indicador [root@secOps
analysts]#, vuelva a ejecutar el script para iniciar Snort. Snort debe estar en ejecución
para poder capturar alertas más adelante en la práctica de laboratorio.
d. En el indicador de mininet de la VM CyberOps Workstation, abra shells para los hosts
H5 y H10.
mininet> xterm H5
mininet> xterm H10
mininet>
e. H10 simulará ser un servidor de Internet que aloja malware. En H10, ejecute el script
mal_server_start.sh para iniciar el servidor.
[root@secOps analyst]#
./lab.support.files/scripts/mal_server_start.sh
f. En H10, utilicen netstat con las opciones -tunpa para verificar que el servidor web se esté
ejecutando. Cuando se utiliza como se indica arriba, netstat genera una lista de todos los
puertos asignados a servicios en este momento:
[root@secOps analyst]# netstat -tunpa
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
tcp 0 0 0.0.0.0:6666 0.0.0.0:*
LISTEN 1839/nginx: master
Tal como se ve en el resultado anterior, el servidor web ligero nginx se está ejecutando y
está escuchando conexiones en el puerto 6666 de TCP.Se está ejecutando una instancia
de Snort en la ventana del terminal de R1. Para introducir más comandos en R1, abra otro
terminal de R1; para ello, vuelva a introducir xterm R1 en la ventana del terminal de la VM
CyberOps Workstation, tal como se indica a continuación. También es posible que
quieran organizar las ventanas del terminal para poder ver e interactuar con cada
dispositivo. En la siguiente figura vemos una organización efectiva para el resto de esta
práctica de laboratorio.
g. En la nueva ficha del terminal de R1, ejecuten el comando tail con la opción -f para
monitorear el archivo /var/log/snort/alert en tiempo real. Es en este archivo que se
configura Snort para registrar alertas.
[root@sec0ps analyst]# tail -f /var/log/snort/alert
Como todavía no se registró ninguna alerta, el archivo de registro debería estar vacío. Sin
embargo, si ya han realizado esta práctica de laboratorio, es posible que aparezcan
entradas de alertas extrañas. En cualquier caso, no verán ningún cursor después de
escribir este comando. En esta ventana se mostrarán las alertas a medida que tengan
lugar.
h. En H5, utilicen el comando wget para descargar un archivo de nombre
W32.Nimda.Amm.exe. Diseñada para descargar contenido a través de HTTP, wget es
una excelente herramienta para descargar archivos desde servidores web directamente
desde la línea de comandos.
[root@secOps analyst]# wget 209.165.202.133:6666/W32.Nimda.Amm.exe
--2017-04-28 17:00:04-- http://209.165.202.133:6666/W32.Nimda.Amm.exe
Connecting to 209.165.202.133:6666... connected.
HTTP request sent, awaiting response... 200 OK
Length: 345088 (337K) [application/octet-stream]
Saving to: 'W32.Nimda.Amm.exe'
W32.Nimda.Amm.exe
100%[==========================================>] 337.00K --.-KB/s in
0.02s
2017-04-28 17:00:04 (16.4 MB/s) - 'W32.Nimda.Amm.exe' saved [345088/345088]
¿Qué puerto se utiliza al comunicarse con el servidor web que aloja malware? ¿Qué nos lo
indica?
No me conecta al servidor
¿Se descargó completamente el archivo? No
¿El IDS generó alguna alerta relacionada con la descarga del archivo? _______________
i. Como el archivo malicioso estaba transitando por R1, el IDS (Snort) pudo inspeccionar su
carga útil. La carga útil coincidió con al menos una de las firmas configuradas en Snort y
generó una alerta en la segunda ventana del terminal de R1 (la ficha en la que se está
ejecutando tail -f). A continuación, se muestra la entrada de la alerta. Sus marcas de hora
serán diferentes:
04/28-17:00:04.092153 [**] [1:1000003:0] Malicious Server Hit! [**]
[Priority: 0] {TCP} 209.165.200.235:34484 -> 209.165.202.133:6666
En función de la alerta que se muestra arriba, ¿cuáles fueron las direcciones IPv4 de
origen y de destino que se utilizaron en la transacción?
________________________________________________________________________
____________
________________________________________________________________________
____________
En función de la alerta que se muestra arriba, ¿cuáles fueron los puertos de origen y de
destino que se utilizaron en la transacción?
________________________________________________________________________
____________
________________________________________________________________________
____________
En función de la alerta que se muestra arriba, ¿cuándo tuvo lugar la descarga?
________________________________________________________________________
____________
________________________________________________________________________
____________
En función de la alerta que se muestra arriba, ¿qué mensaje registró la firma del IDS?
________________________________________________________________________
____________
________________________________________________________________________
____________
En H5, utilicen el comando tcpdump para capturar el evento y volver a descargar el
archivo malicioso y así poder capturar la transacción. Emitan el siguiente comando para
iniciar la captura de paquetes:
[root@secOps analyst]# tcpdump –i H5-eth0 –w nimda.download.pcap &
[1] 5633
[root@secOps analyst]# tcpdump: listening on H5-eth0, link-type EN10MB
(Ethernet), capture size 262144 bytes
El comando anterior le ordena a tcpdump que capture paquetes en la interfaz H5-eth0 y
que guarde la captura en un archivo de nombre nimda.download.pcap.
El símbolo & del final le indica al shell que ejecute tcpdump en segundo plano. Sin este
símbolo, tcpdump impediría el uso del terminal mientras se está ejecutando. Observen el
[1] 5633; indica que se envió un proceso al segundo plano y que su ID de proceso (PID) es
5366. Sus PID muy probablemente serán diferente.
j. Presionen INTRO un par de veces para recuperar el control del shell mientras tcpdump se
ejecuta en segundo plano.
k. Ahora que tcpdump está capturando paquetes, vuelvan a descargar el malware. En H5,
vuelvan a ejecutar el comando o utilicen la flecha hacia arriba para recuperarlo del centro
del historial de comandos.
Connecting to 209.165.202.133:6666... connected.
HTTP request sent, awaiting response... 200 OK
Length: 345088 (337K) [application/octet-stream]
Saving to: 'W32.Nimda.Amm.exe'
W32.Nimda.Amm.exe 100%[===================>] 337.00K --.-KB/s in
0.003s
02/05/2017 10:26:50 (105 MB/s) - 'W32.Nimda.Amm.exe' saved [345088/345088]

l. Lleve tcpdump al primer plano con el comando fg para detener la captura. Como
tcpdump era el único proceso que se había enviado a segundo plano, no es necesario
especificar el PID. Detengan el proceso de tcpdump con Ctrl+C. El proceso de tcpdump
se detiene y exhibe una resumen de la captura. La cantidad de paquetes puede diferir en
sus capturas.
[root@secOps analyst]# fg
tcpdump -i h5-eth0 -w nimda.download.pcap
^C316 packets captured
316 packets received by filter
0 packets dropped by kernel
m. En H5, utilicen el comando ls para verificar que el archivo pcap realmente se haya
guardado en el disco y que su tamaño sea mayor que cero:
[root@secOps analyst]# ls -l
total 1400
drwxr-xr-x 2 analyst analyst 4096 Sep 26 2014 Desktop
drwx------ 3 analyst analyst 4096 Jul 14 11:28 Downloads
drwxr-xr-x 8 analyst analyst 4096 Jul 25 16:27 lab.support.files
-rw-r--r-- 1 root root 371784 Aug 17 14:48 nimda.download.pcap
drwxr-xr-x 2 analyst analyst 4096 Mar 3 15:56 second_drive
-rw-r--r-- 1 root root 345088 Apr 14 15:17 W32.Nimda.Amm.exe
-rw-r--r-- 1 root root 345088 Apr 14 15:17 W32.Nimda.Amm.exe.1
Nota: Es posible que su lista de directorios tenga otra combinación de archivos, pero de
todos modos debería ver el archivo nimda.download.pcap.
¿Qué beneficios puede aportar este PCAP al analista especializado en seguridad?
________________________________________________________________________
____________
________________________________________________________________________
____________
Nota: El archivo PCAP se analizará en otra práctica de laboratorio.
Paso 2: Afinar reglas de firewall en función de alertas de un IDS

En el Paso 1 iniciaron un servidor malicioso de Internet. Para evitar que otros usuarios lleguen
a ese servidor, se recomienda bloquearlo en el firewall de perímetro.
En la topología de esta práctica de laboratorio, R1 no solo está ejecutando un IDS sino también
un firewall basado en Linux muy popular: iptables. En este paso, bloquearán el tráfico al
servidor malicioso identificado en el Paso 1; para ello, editarán las reglas de firewall presentes
en R1.
Nota: Aunque el estudio completo de iptables está fuera del alcance de este curso, la
estructura lógica y de reglas básica de iptables es relativamente sencilla.
El firewall iptables utiliza los conceptos de cadenas y reglas para filtrar tráfico.
El tráfico que ingresa al firewall y tiene como destino al propio dispositivo de firewall es
manejado por la cadena INPUT. Como ejemplo de este tráfico podemos mencionar a los
paquetes de ping provenientes de cualquier otro dispositivo en cualquier red y enviados a
cualquiera de las interfaces del firewall.
El tráfico que se origina en el propio dispositivo de firewall y tiene como destino cualquier otro
lugar es manejado por la cadena OUTPUT. Un ejemplo de este tráfico son las respuestas de
ping generadas por el propio dispositivo de firewall.
El tráfico originado en cualquier otro lugar y que atraviesas el dispositivo de firewall es
manejado por la cadena FORWARD. Un ejemplo de este tráfico son los paquetes que está
enrutando el firewall.
Cada cadena puede tener sus propias reglas independientes que especifican cómo se debe
filtrar el tráfico. Una cadena puede tener prácticamente cualquier cantidad de reglas, incluso
ninguna.
Las reglas se crean para comprobar características específicas de los paquetes; eso permite
que los administradores generen filtros muy integrales. Si un paquete no coincide con una
regla, el firewall pasa a la siguiente y repite la comprobación. Si se encuentra una coincidencia,
el firewall toma la medida definida en la regla pertinente. Si se han comprobado todas las
reglas de una cadena y no se encontró ninguna coincidencia, el firewall toma la medida
especificada en la política de la cadena, que suele ser permitir que el paquete circule o
rechazarlo.
a. En la VM CyberOps Workstation, inicien una tercera ventana del terminal de R1.
mininet > xterm R1
b. En la nueva ventana del terminal de R1, utilicen el comando iptables para generar una
lista de las cadenas y sus reglas en uso:
[root@secOps ~]# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy ACCEPT 6 packets, 504 bytes)

destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

destination
[root@secOps ~]#
¿Qué cadenas está utilizando R1 en este momento?
c. Las conexiones al servidor malicioso generan paquetes que deben atravesar el firewall
iptables en R1. Los paquetes que atraviesan el firewall son manejados por la regla de
FORWARD y, por lo tanto, esa es la cadena que recibirá la regla de bloqueo. Para impedir
que las computadoras de los usuarios se conecten al servidor malicioso identificado en el
Paso 1, agreguen la siguiente regla a la cadena FORWARD en R1:
[root@secOps ~]# iptables -I FORWARD -p tcp -d 209.165.202.133 --
dport 6666 -j DROP
[root@secOps ~]#
Donde:
o -I FORWARD: inserta una regla nueva en la cadena FORWARD.
o -p tcp: especifica el protocolo TCP.
o -d 209.165.202.133: especifica el destino del paquete.
o -dport 6666: especifica el puerto de destino.
o -j DROP: define la acción a descartar.
d. Vuelva a utilizar el comando iptables para asegurarse de que la regla se haya agregado a
la cadena FORWARD. La VM CyberOps Workstation puede demorar algunos segundos
para generar la salida:
[root@secOps analyst]# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

destination
0 0 DROP tcp -- any any anywhere
209.165.202.133 tcp dpt:6666
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

destination
e. En H5, trate de descargar el archivo nuevamente:

Connecting to 209.165.202.133:6666... failed: Connection timed out.
Retrying.
--2017-05-01 14:44:47-- (try: 2)

http://209.165.202.133:6666/W32.Nimda.Amm.exe
Connecting to 209.165.202.133:6666... failed: Connection timed out.
Retrying.
Si es necesario, presionen Ctrl+C para cancelar la descarga. ¿Esta vez la descarga se
completó correctamente? Explique.
________________________________________________________________________
____________
________________________________________________________________________
____________
¿Cuál sería un enfoque más agresivo (pero válido a la vez) cuando se está bloqueando el
servidor malicioso?
________________________________________________________________________
____________
________________________________________________________________________
____________
Parte 3: Finalizar y desactivar el proceso de Mininet

a. Diríjanse al terminal que se utilizó para iniciar Mininet. Introduzca quit en la ventana del
terminal principal de la VM CyberOps para finalizar Mininet.
b. Después de salir de Mininet, limpie los procesos que inició Mininet. Introduzcan la
contraseña cyberops cuando el sistema se los solicite.
[analyst@secOps scripts]$ sudo mn –c
Jhonathan gomez
Práctica de laboratorio: Convertir datos a un formato
universal
Objetivos
Parte 1: Normalizar marcas de hora en un archivo de registro
Parte 2: Normalizar marcas de hora en un archivo de registro Apache
Parte 3: Preparación de archivos de registro en Security Onion
Esta práctica de laboratorio preparará a los alumnos para aprender dónde se encuentran los
archivos de registro. También aprenderán cómo manipularlos y verlos. Las entradas de registro
son generadas por dispositivos de red, sistemas operativos, aplicaciones y diversos tipos de
dispositivos programables. A un archivo que contiene una secuencia temporizada de entradas
de registro se le llama archivo de registro.
Por naturaleza, los archivos de registro registran eventos que son relevantes a la fuente. La
sintaxis y el formato de los datos que se encuentran dentro de los mensajes de registro a
menudo son definidos por el desarrollador de la aplicación.
Por lo tanto, la terminología utilizada en las entradas de registro a menudo varía según la
fuente. Por ejemplo: dependiendo de la fuente, los términos "iniciar sesión", "conectarse",
"evento de autenticación" y "conexión del usuario" pueden aparecer en entradas de registro
para describir la autenticación exitosa de un usuario en un servidor.
A menudo es aconsejable tener terminología consistente y uniforme en los archivos de registro
generados por diferentes fuentes. Esto es especialmente cierto cuando todos los archivos de
registro son recopilados por un punto centralizado.
El término normalización se refiere al proceso de convertir partes de un mensaje, en este caso
una entrada de registro, a un formato común.
En esta práctica de laboratorio utilizarán herramientas de la línea de comando para normalizar
las entradas de registro manualmente. En la Parte 2, se normalizará el campo de la marca de
hora. En la Parte 3, se normalizará el campo de IPv6.
Nota: Si bien hay numerosos complementos para realizar la normalización de archivos de
registro, es importante comprender los fundamentos básicos que subyacen al proceso de
normalización.
Recursos necesarios
 VM Security Onion

Las marcas de hora se utilizan en entradas de registro para especificar cuándo tuvo lugar el
evento registrado. Si bien la práctica recomendada es registrar marcas de hora en UTC, el
formato de las marcas de hora varía según la fuente del archivo de registro. Hay dos formatos
de marca de hora comunes; se conocen como Unix Epoch y Human Readable (Legible por
seres humanos).
Las marcas de hora Unix Epoch registran la hora midiendo la cantidad de segundos
transcurridos desde el 1 de enero de 1970.
Las marcas de hora legibles registran la hora representando valores aparte para el año, el
mes, el día, las horas, los minutos y los segundos.
La marca de hora legible Wed, 28 Jun 2017 13:27:18 GMT equivale a 1498656439 en Unix
Epoch.
Desde un punto de vista de programabilidad, es mucho más fácil trabajar con Epoch, ya que
permite facilitar operaciones de suma y resta. Desde una perspectiva de análisis; sin embargo,
las marcas de hora legibles son mucho más fáciles de interpretar.
Convertir marcas de hora Epoch a marcas de hora legibles con AWK
AWK es un lenguaje de programación diseñado para manipular archivos de texto. Es muy
potente y especialmente útil para manejar archivos de texto en los que las líneas contienen
varios campos, separados por un carácter delimitador. Los archivos de registro contienen una
entrada por línea y tienen el formato de campos separados por delimitadores, por lo que AWK
es una excelente herramienta para la normalización.
Analicen el archivo applicationX_in_epoch.log que se muestra a continuación. La fuente del
archivo de registro no es relevante.
2|Z|1219071600|AF|0
3|N|1219158000|AF|89
4|N|1220799600|AS|12
1|Z|1220886000|AS|67
5|N|1220972400|EU|23
6|R|1221058800|OC|89
El archivo de registro anterior fue generado por la aplicación X. Los aspectos relevantes del
archivo son los siguientes:
o Las columnas están separadas, o delimitadas, por el carácter |. Por lo tanto, el archivo
tiene cinco columnas.
o La tercera columna contiene las marcas de hora en Unix Epoch.
o El archivo tiene una línea adicional al final. Esto será importante más adelante en la
práctica de laboratorio.
Supongan que un analista de archivos de registro necesita convertir las marcas de hora al
formato legible. Sigan los pasos que se detallan a continuación y utilicen AWK para realizar la
conversión manual fácilmente:
a. Abran la VM CyberOps Workstation y, luego, abran una ventana del terminal.
b. Utilicen el comando cd para pasar al directorio /home/analyst/lab.support.files/. Allí se
almacena una copia del archivo que se muestra arriba.
[analyst@secOps ~]$ cd ./lab.support.files/
[analyst@secOps lab.support.files]$ ls -l
total 580
-rw-r--r-- 1 analyst analyst 649 Jun 28 18:34 apache_in_epoch.log
-rw-r--r-- 1 analyst analyst 126 Jun 28 11:13 applicationX_in_epoch.log
drwxr-xr-x 4 analyst analyst 4096 Aug 7 15:29 attack_scripts
-rw-r--r-- 1 analyst analyst 102 Jul 20 09:37 confidential.txt
<output omitted>
[analyst@secOps lab.support.files]$
c. Emitan el siguiente comando de AWK para convertir e imprimir el resultado en el terminal:
Nota: Es común cometer un error de mecanografiado en el siguiente script. Consideren la
posibilidad de copiar el script en un editor de texto para quitar los saltos de línea
adicionales. Luego, copie el script del editor de texto a la ventana del terminal de la VM
CyberOps Workstation. Sin embargo, recuerden estudiar la explicación del script que se
incluye a continuación para enterarse de qué manera modifica el campo de la marca de
hora.
[analyst@secOps lab.support.files]$ awk 'BEGIN
{FS=OFS="|"}{$3=strftime("%c",$3)} {print}'
applicationX_in_epoch.log
2|Z|Mon 18 Aug 2008 11:00:00 AM EDT|AF|0
3|N|Tue 19 Aug 2008 11:00:00 AM EDT|AF|89
4|N|Sun 07 Sep 2008 11:00:00 AM EDT|AS|12
1|Z|Mon 08 Sep 2008 11:00:00 AM EDT|AS|67
5|N|Tue 09 Sep 2008 11:00:00 AM EDT|EU|23
6|R|Wed 10 Sep 2008 11:00:00 AM EDT|OC|89
||Wed 31 Dec 1969 07:00:00 PM EST
El comando anterior es un script de AWK. Puede parecer complicado. La estructura
principal del script de AWK es la siguiente:
 awk: invoca al intérprete de AWK.
 ‘BEGIN: define el comienzo del script.
 {}: define las acciones que se deben realizar en cada línea del archivo de texto de
entrada. Un script de AWK puede tener varias acciones.
 FS = OFS = “|”: esto define el separador de campos (es decir, el delimitador)
como el símbolo (|) de la barra. En distintos archivos de texto se pueden utilizar
diferentes caracteres delimitadores para separar campos. Este operador permite
que el usuario defina qué carácter se utiliza como el separador de campos en el
archivo de texto actual.
 $3: esto hace referencia al valor presente en la tercera columna de la línea actual.
En el archivo applicationX_in_epoch.log, la tercera columna contiene la marca
de hora en Epoch que se tiene que convertir.
 strftime: esta es la función interna de AWK diseñada para trabajar con la hora. Los
valores %c y $3 entre paréntesis son los parámetros que se pasan a strftime.
 applicationX_in_epoch.log: este es el archivo de texto de entrada que se tiene
que cargar y utilizar. Como ya está en el directorio lab.support.files, no es
necesario que agregue la información de la ruta:
/home/analyst/lab.support.files/applicationX_in_epoch.log.
La primera acción del script, definida en el primer conjunto de llaves es definir el carácter
separador de campos como la barra vertical ("|"). Luego, en el segundo conjunto de llaves,
se reescribe la tercera columna de cada línea con el resultado de la función strftime() que
se ejecutó. strftime() es una función interna de AWK creada para manejar la conversión de
la hora. Observen que el script le ordena a la función que utilice el contenido de la tercera
columna de cada línea antes del cambio ($3) y que dé formato a la salida (%c).
¿Se convirtieron las marcas de hora Unix Epoch al formato legible? ¿Se modificaron los
otros campos? Explique.
Sí, el script se convirtió de Epoch a Human Readable. El script cambió solo el campo de
marca de tiempo, conservando el resto del archivo.
Comparen el contenido del archivo con la salida impresa. ¿Por qué está la siguiente línea:
||Wed 31 Dec 1969 07:00:00 PM EST?
La razón de la línea adicional es porque el archivo tiene una línea vacía al final, lo que llevó
al script a interpretarlo erróneamente como 0 y convertirlo en una marca de tiempo legible
por humanos.
Al interpretar la línea vacía como 0, el script convirtió 0 Unix Epoch a Human Readable. 0
Unix Epoch se traduce a 0 segundos después de la medianoche del 1 de enero de 1970. El
script muestra "Wed 31 Dec 1969 07:00:00 PM EST" porque se ajusta automáticamente
para la zona horaria. Debido a que la estación de trabajo CyberOps está configurada para
EST (UTC -5), el script muestra la medianoche del 1 de enero de 1970 menos 5 horas.
d. Utilicen nano (o el editor de texto que prefieran) para quitar la línea vacía adicional del final
del archivo y vuelvan a ejecutar el script AWK.
[analyst@secOps lab.support.files]$ nano applicationX_in_epoch.log
¿Ahora la salida es correcta? Explique.
Sí. Debido a que se eliminó la línea vacía, el script no creó datos adicionales ni los agregó
al archivo de registro.
e. Si bien imprimir el resultado en la pantalla es útil para solucionar problemas en el script, los
analistas probablemente necesitarán guardar la salida en un archivo de texto. Redirijan la
salida del script anterior a un archivo de nombre applicationX_in_human.log para
guardarlo en un archivo:
[analyst@secOps lab.support.files]$ awk 'BEGIN
{FS=OFS="|"}{$3=strftime("%c",$3)} {print}'
applicationX_in_epoch.log > applicationX_in_human.log
¿Qué imprimió el comando anterior? ¿Es esperable?
No se imprimió nada en la pantalla. Sí, se espera, ya que la salida del comando se redirigió
a un archivo de texto denominado applicationX_in_human.log.
f. Utilicen cat para ver el archivo applicationX_in_human.log. Observen que ahora se quitó
la línea adicional y que las marcas de hora correspondientes a las entradas de registro se
han convertido al formato legible.
[analyst@secOps lab.support.files]$ cat applicationX_in_human.log
2|Z|Mon 18 Aug 2008 11:00:00 AM EDT|AF|0
3|N|Tue 19 Aug 2008 11:00:00 AM EDT|AF|89
4|N|Sun 07 Sep 2008 11:00:00 AM EDT|AS|12
1|Z|Mon 08 Sep 2008 11:00:00 AM EDT|AS|67
5|N|Tue 09 Sep 2008 11:00:00 AM EDT|EU|23
6|R|Wed 10 Sep 2008 11:00:00 AM EDT|OC|89
Apache
En forma similar a lo que se hizo con el archivo applicationX_in_epoch.log, los archivos de
registro Apache también se pueden normalizar. Sigan los pasos que se detallan a continuación
para convertir marcas de hora Unix Epoch al formato legible. Analicen el siguiente archivo de
registro Apache, apache_in_epoch.log:
[analyst@secOps lab.support.files]$ cat apache_in_epoch.log
198.51.100.213 - - [1219071600] "GET
/twiki/bin/edit/Main/Double_bounce_sender?topicparent=Main.ConfigurationVar
iables HTTP/1.1" 401 12846
198.51.100.213 - - [1219158000] "GET
/twiki/bin/rdiff/TWiki/NewUserTemplate?rev1=1.3&rev2=1.2 HTTP/1.1" 200 4523
198.51.100.213 - - [1220799600] "GET /mailman/listinfo/hsdivision HTTP/1.1"
200 6291
198.51.100.213 - - [1220886000] "GET /twiki/bin/view/TWiki/WikiSyntax
HTTP/1.1" 200 7352
198.51.100.213 - - [1220972400] "GET /twiki/bin/view/Main/DCCAndPostFix
HTTP/1.1" 200 5253
198.51.100.213 - - [1221058800] "GET
/twiki/bin/oops/TWiki/AppendixFileSystem?template=oopsmore&m1=1.12&m2=1.12
HTTP/1.1" 200 11382
El archivo de registro Apache anterior contiene seis entradas que registran eventos
relacionados con el servidor web Apache. Cada entrada tiene siete campos. Los campos
están delimitados por un espacio:
o La primera columna contiene la dirección IPv4 (198.51.100.213) del cliente web que
está elevando la solicitud.
o La segunda y tercera columna no se utilizan, y se emplea un carácter de “-“ para
representar que no hay ningún valor.
o La cuarta columna contiene la marca de hora en Unix Epoch, por ejemplo:
[1219071600].
o La quinta columna contiene texto con detalles sobre el evento; eso incluye direcciones
URL y los parámetros de la petición web. Las seis entradas son mensajes HTTP GET.
Como estos mensajes incluyen espacios, todo el campo está encerrado entre comillas.
o La sexta columna contiene el código de estado HTTP, por ejemplo: 401.
o La séptima columna contiene el tamaño de la respuesta al cliente (en bytes), por
ejemplo: 12846.
En forma similar a lo se hizo en la Parte uno, se creará un script para convertir la marca de
hora del formato Epoch al legible.
a. En primer lugar, respondan las siguientes preguntas. Son cruciales para la construcción del
script.
En el contexto de la conversión de marcas de hora, ¿qué carácter funcionará bien como
carácter delimitador para el archivo de registro Apache anterior?
El carácter espacial.
¿Cuántas columnas contiene el archivo de registro Apache anterior?

7
¿En el archivo de registro Apache anterior, qué columna contiene la marca de hora en Unix
Epoch?
Columna 4
b. En el terminal de la VM CyberOps Workstation se almacena una copia del archivo de

registro Apache (apache_in_epoch.log), en /home/analyst/lab.support.files.
c. Utilicen un script de awk para convertir el campo de la marca de hora al formato legible.
Observen que el comando contiene el mismo script que ya se utilizó, pero con algunos
ajustes en el campo de la marca de hora y en el nombre de archivo.
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS="
"}{$4=strftime("%c",$4)} {print}'
/home/analyst/lab.support.files/apache_in_epoch.log
¿El script pudo convertir las marcas de hora correctamente? Describan la salida.
No. Todas las marcas de tiempo son ahora Wed 31 Dec 1969 07:00:00 PM EST.
d. Antes de seguir adelante, piensen en la salida del script. ¿Pueden decir qué hizo que la
salida fuese incorrecta? ¿El script es incorrecto? ¿Cuáles son las diferencias relevantes
entre applicationX_in_epoch.log y apache_in_epoch.log?
El problema son los corchetes en el archivo del curso. El script espera que la marca de
tiempo esté en el formato Unix Epoch que no incluye los corchetes. Debido a que el script
no sabe qué número representa el carácter "[", asume cero y devuelve el principio de
tiempo de Unix en UTC -5.
e. Para corregir el problema se deben quitar los corchetes del campo de la marca de hora
antes de realizar la conversión. Corrijan el script; para ello, agreguen dos acciones antes
de la conversión, de la siguiente manera:
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS=" "}
{gsub(/\[|\]/,"",$4)}{print}{$4=strftime("%c",$4)}{print}'
apache_in_epoch.log
Observen que, después de especificar el espacio como delimitador con {FS=OFS=” “},
hay una acción de expresión regular para hacer coincidir y reemplazar los corchetes por
una cadena vacía; eso quita efectivamente los corchetes que aparecen en el campo de la
marca de hora. La segunda acción imprime la línea actualizada para que se pueda realizar
la acción de la conversión.
 gsub(): esta es una función interna de AWK que se utiliza para ubicar y sustituir
cadenas. En el script anterior, gsub() recibió tres parámetros separados por
comas, que se describen a continuación.
 /\[|\]/: esta es una expresión regular que se pasa a gsub() como primer parámetro.
La expresión regular debe leerse como ‘find “[” OR “]”’. A continuación se
muestra el desglose de la expresión:
o El primer y último carácter “/” marcan el comienzo y el final del bloque de
búsqueda. Cualquier elemento que se incluya entre la primera y la
segunda “/” estará relacionado con la búsqueda. El carácter “\” se utiliza
para dar escape al siguiente “[“. El escape es necesario porque “[“ también
puede ser utilizado por un operador en expresiones regulares. Al escapar
el “[“ con una barra “\” precedente, le estamos diciendo al intérprete que el
“]” forma parte del contenido y no de un operador. El carácter “|” es el
operador OR. Tengan en cuenta que la barra "|" no tiene escape y, por lo
tanto puede verse como un operador. Por último, la expresión regular da
escape al corchete de cierre con “\]”, como se hizo antes.
 "": esto representa la ausencia de caracteres, o una cadena vacía. Este parámetro
le dice a gsub() con qué debe reemplazar “[“ y “]”, cuando los encuentre. Al
reemplazar “[“ y “]” por “”, gsub() quita efectivamente los caracteres “[“ y “]”.
 $4: esto le dice a gsub() que trabaje solamente en la cuarta columna de la línea
actual, la columna de la marca de hora.
Nota: La interpretación de expresiones regulares es un tema del examen de SECOPS. Las
expresiones regulares se analizan más detalladamente en otra práctica de laboratorio de
este capítulo. Sin embargo, pueden buscar tutoriales en Internet.
f. En un terminal de la VM CyberOps Workstation, ejecuten el script modificado, de la
siguiente manera:
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS="
"}{gsub(/\[|\]/,"",$4)}{print}{$4=strftime("%c",$4)}{print}'
apache_in_epoch.log
¿El script pudo convertir las marcas de hora correctamente esta vez? Describan la salida.
Sí. El resultado ahora muestra dos líneas para cada entrada de registro. La primera línea
muestra la marca de tiempo en formato Unix Epoch y la segunda línea es la misma entrada de
registro con la marca de tiempo mostrada usando el formato Human Readable.
Parte 3: Preparación de archivos de registro en Security Onion

Como la normalización de los archivos de registro es importante, las herramientas para el
análisis de registros a menudo incluyen características de normalización de registros. Las
herramientas que no incluyen tales características a menudo dependen de complementos para
la normalización y preparación de registros. La meta de estos complementos es permitir que
las herramientas para el análisis de registros normalicen y preparen los archivos de registro
recibidos para que las herramientas puedan utilizarlos.
El dispositivo Security Onion depende de diversas herramientas para proporcionar servicios de
análisis de registros. ELSA, Bro, Snort y SGUIL sin duda son las más utilizadas.
ELSA (Enterprise Log Search and Archive [Búsqueda y archivo empresarial de registros]) es
una solución que permite hacer lo siguiente:
 Normalizar, almacenar e indexar registros en volúmenes y velocidades sin límite.
 Proporcionar una interfaz de búsqueda y API simple y transparente.
 Proporcionar una infraestructura para alertar, informar y compartir registros.
 Controlar las acciones de los usuarios con permisos locales o basados en LDAP/AD.
 Contar con un sistema complementario para realizar acciones con los registros.
 Funcionar como un proyecto totalmente gratuito y de código abierto.
Bro es un marco diseñado para analizar el tráfico de red y generar registros de eventos en
función de dicho tráfico. Al analizar el tráfico de red, Bro crea registros que describen eventos
como los siguientes:
 Conexiones de red TCP/UDP/ICMP
 Actividad del DNS
 Actividad de FTP
 Peticiones y respuestas HTTPS
 Protocolos de enlace SSL/TLS
Snort y SGUIL
Snort es un IDS que depende de reglas predefinidas para señalar tráfico potencialmente
dañino. Snort analiza todas las porciones de los paquetes de red (encabezados y cargas útiles)
en busca de los patrones definidos en sus reglas. Cuando los encuentra, Snort toma la medida
definida en la misma regla.
SGUIL proporciona una interfaz gráfica para los registros y las alertas de Snort, lo que permite
que el analista de seguridad pase de SGUIL a otras herramientas para obtener más
información. Por ejemplo: si se envía un paquete potencialmente malicioso al servidor web de
la organización y Snort elevó una alerta al respecto, SGUIL incluirá esa alerta en una lista.
Entonces, el analista puede hacer clic derecho sobre esa alerta para buscar en las bases de
datos de ELSA o Bro y así comprender mejor el evento.
Nota: El listado de directorios puede diferir del resultado de muestra que se incluye a
continuación.
Paso 1: Pasen a Security Onion.

Inicie la VM de Security Onion desde el panel de control de VirtualBox (nombre de usuario:
analyst/contraseña: cyberops). Se puede cerrar la VM CyberOps Workstation para liberar
memoria en el servidor para esta parte de la práctica de laboratorio.
Paso 2: Registros de ELSA
a. Abran una ventana de terminal en la VM Security Onion. Pueden acceder al menú de
aplicaciones que se muestra en la siguiente captura de pantalla:
b. También pueden hacer clic derecho en el Escritorio > Open Terminal Here (Abrir terminal
aquí), tal como se muestra en la siguiente captura de pantalla:
c. Los registros de ELSA se pueden encontrar en el directorio /nsm/elsa/data/elsa/log/.

Cambien de directorio con el siguiente comando:
analyst@SecOnion:~/Desktop$ cd /nsm/elsa/data/elsa/log
analyst@SecOnion:/nsm/elsa/data/elsa/log$
d. Utilicen el comando ls –l para incluir los archivos en una lista:
analyst@SecOnion:/nsm/elsa/data/elsa/log$ ls -l
total 99112
total 169528
-rw-rw---- 1 www-data sphinxsearch 56629174 Aug 18 14:15 node.log
-rw-rw---- 1 www-data sphinxsearch 6547557 Aug 3 07:34 node.log.1.gz
-rw-rw---- 1 www-data sphinxsearch 7014600 Jul 17 07:34 node.log.2.gz
-rw-rw---- 1 www-data sphinxsearch 6523029 Aug 18 14:15 query.log
-rw-rw---- 1 www-data sphinxsearch 53479942 Aug 18 14:15 searchd.log
-rw-rw---- 1 www-data sphinxsearch 32613665 Aug 18 14:15 web.log
analyst@SecOnion:/nsm/elsa/data/elsa/log$
Paso 3: Registros de Bro en Security Onion
a. Los registros de Bro se almacenan en /nsm/bro/logs/. Como es habitual en sistemas
Linux, los archivos de registro se rotan en función de la fecha, se les cambia el nombre y
se almacenan en el disco. Los archivos de registro actuales se pueden encontrar en el
directorio current. Desde la ventana del terminal, cambien de directorio con el siguiente
comando:
analyst@SecOnion:/nsm/elsa/data/elsa/log$ cd /nsm/bro/logs/current
analyst@SecOnion:/nsm/logs/current$
b. Utilicen el comando ls -l para ver todos los archivos de registro que generó Bro:
analyst@SecOnion:/nsm/bro/logs/current$ ls -l
total 100
-rw-rw-r-- 1 sguil sguil 368 Aug 18 14:02 capture_loss.log
-rw-rw-r-- 1 sguil sguil 46031 Aug 18 14:16 communication.log
-rw-rw-r-- 1 sguil sguil 2133 Aug 18 14:03 conn.log
-rw-rw-r-- 1 sguil sguil 2028 Aug 18 14:16 stats.log
-rw-rw-r-- 1 sguil sguil 40 Aug 18 14:00 stderr.log
-rw-rw-r-- 1 sguil sguil 188 Aug 18 13:46 stdout.log
analyst@SecOnion:/nsm/bro/logs/current$
Paso 4: Archivos de registro de Snort

a. Los archivos de registro de Snort se pueden encontrar en /nsm/sensor_data/. Cambien de
directorio de la siguiente manera:
analyst@SecOnion:/nsm/bro/logs/current$ cd /nsm/sensor_data
analyst@SecOnion:/nsm/sensor_data$
b. Utilicen el comando ls -l para ver todos los archivos de registro que generó Snort:
analyst@SecOnion:/nsm/sensor_data$ ls -l
total 16
drwxrwxr-x 7 sguil sguil 4096 Jun 19 23:16 seconion-eth0
c. Observen que Security Onion separa los archivos en función de la interfaz. Como la
imagen de la VM Security Onion tiene cuatro interfaces, se conservan cuatro directorios.
Utilicen el comando ls –l seconion-eth0 para ver los archivos que generó la interfaz
ethernet 0.
analyst@SecOnion:/nsm/sensor_data$ ls -l seconion-eth0/
total 52
drwxrwxr-x 2 sguil sguil 4096 Jun 19 23:09 argus
drwxrwxr-x 10 sguil sguil 4096 Jul 7 12:09 dailylogs
drwxrwxr-x 2 sguil sguil 4096 Jun 19 23:08 portscans
drwxrwxr-x 2 sguil sguil 4096 Jun 19 23:08 sancp
drwxr-xr-x 2 sguil sguil 4096 Jul 7 12:12 snort-1
-rw-r--r-- 1 sguil sguil 27566 Jul 7 12:12 snort-1.stats
-rw-r--r-- 1 root root 0 Jun 19 23:08 snort.stats
Paso 5: Registros varios
a. Si bien en el directorio /nsm/ se almacenan algunos archivos de registro, se pueden
encontrar otros más específicos en /var/log/nsm/. Cambien de directorio y utilicen el
comando ls -l para ver todos los archivos de registro presentes en el directorio.
analyst@SecOnion:/nsm/sensor_data$ cd /var/log/nsm/
analyst@SecOnion:/var/log/nsm$ ls -l
total 8364
-rw-r--r-- 1 sguil sguil 4 Aug 18 14:56 eth0-packets.log
-rw-r--r-- 1 sguil sguil 182 Aug 18 13:46 ossec_agent.log
-rw-r--r-- 1 sguil sguil 202 Jul 11 12:02
ossec_agent.log.20170711120202
-rw-r--r-- 1 sguil sguil 202 Aug 2 12:02
-rw-r--r-- 1 sguil sguil 42002 Aug 4 07:33 pulledpork.log
drwxr-xr-x 2 sguil sguil 4096 Aug 18 13:46 seconion-eth0
drwxr-xr-x 2 sguil sguil 4096 Jun 19 23:08 securityonion
-rw-r--r-- 1 sguil sguil 1647 Jun 19 23:09 securityonion-elsa-
config.log
-rw-r--r-- 1 sguil sguil 7708106 Aug 18 14:56 sensor-clean.log
-rw-r--r-- 1 sguil sguil 1603 Aug 4 00:00 sensor-newday-
argus.log
-rw-r--r-- 1 sguil sguil 1603 Aug 4 00:00 sensor-newday-http-
agent.log
-rw-r--r-- 1 sguil sguil 8875 Aug 4 00:00 sensor-newday-
pcap.log
-rw-r--r-- 1 sguil sguil 53163 Aug 4 05:01 sguil-db-purge.log
-rw-r--r-- 1 sguil sguil 369738 Aug 4 07:33 sid_changes.log
-rw-r--r-- 1 sguil sguil 22598 Aug 8 01:35 so-bro-cron.log
drwxrwxr-x 2 sguil securityonion 4096 Jun 19 23:09 so-elsa
-rw------- 1 sguil sguil 7535 Jun 19 23:09 sosetup.log
-rw-r--r-- 1 sguil sguil 14046 Jun 19 23:09 sosetup_salt_call.log
-rw-r--r-- 1 sguil sguil 63208 Jun 19 23:09
sphinx_initialization.log
-rw-r--r-- 1 sguil sguil 81 Aug 18 14:55 squert-ip2c-5min.log
-rw-r--r-- 1 sguil sguil 1079 Jul 16 06:26 squert-ip2c.log
-rw-r--r-- 1 sguil sguil 125964 Aug 18 14:54 watchdog.log
analyst@SecOnion:/var/log/nsm$
Observen que el directorio que se muestra arriba también contiene registros utilizados por
herramientas secundarias como OSSEC, Pulledpork, Sphinx y Squert.
b. Tómense un momento para investigar estas herramientas en Google y respondan las
siguientes preguntas:
En cada una de las herramientas antes enumeradas, describan su función, importancia y
ubicación en el flujo de trabajo del analista de seguridad.
Sphinx es un motor de búsqueda de código abierto y es utilizado por ELSA para
proporcionar capacidades de búsqueda.
Pulledpork es un sistema de gestión de reglas de Snort. Facilita la actualización de las
reglas de Snort. Las reglas obsoletas de Snort hacen que todo el sistema sea inútil.
OSSEC es un sistema utilizado para normalizar y concentrar los registros del sistema local.
Cuando se implementa en toda la organización, OSSEC permite a un analista tener una
idea clara de lo que está sucediendo en los sistemas.
Squert es una herramienta visual que intenta proporcionar contexto adicional a los eventos
mediante el uso de metadatos, representaciones de series temporales y conjuntos de
resultados ponderados y agrupados lógicamente.
Parte 4: Reflexión
La normalización de registros es importante y depende del entorno implementado.
Las herramientas populares incluyen sus propias características de normalización, pero los
registros también se pueden normalizar manualmente.
Cuando estén normalizando y preparando archivos de registro manualmente, revisen bien los
scripts para garantizar que se llegue al resultado deseado. Un script de normalización mal
escrito puede modificar los datos, y eso afectaría directamente el trabajo del analista.
Práctica de laboratorio: Tutorial de expresiones regulares
Objetivos
En esta práctica de laboratorio, aprenderán a utilizar expresiones regulares para buscar las
cadenas de información que deseen.
Una expresión regular (regex) es un patrón de símbolos que describe datos que deben
coincidir en una consulta o en cualquier otra operación. Las expresiones regulares se
construyen en forma similar a las aritméticas, utilizando diversos operadores para combinar
expresiones más pequeñas. Hay dos estándares principales de expresiones regulares: POSIX
y Perl.
En esta práctica de laboratorio utilizarán un tutorial en línea para estudiar expresiones
regulares. También describirán la información que coincide con expresiones regulares dadas.
Recursos necesarios
Paso 1: Completen el tutorial regexone.com.

a. Abran un navegador web y vayan a https://regexone.com/ desde su computadora host.
Regex One es un tutorial que les ofrece lecciones para aprender sobre los patrones de las
expresiones regulares.
Paso 2:
a. Después de que hayan terminado el tutorial, registren la función de algunos de los
metacaracteres que se utilizan en expresiones regulares.
Metacaracteres Descripción
$ Coincide con la posición final dentro de la cadena
* Coincide con cero o más veces para el elemento anterior
. Coincide con cero o más veces para el elemento anterior
[] cualquier carácter único en la lista
\. Periodo
\d Cualquier carácter digito
\D Cualquier carácter no digito
^ Coincide con la posición inicial dentro de la cadena
{m} Coincide con m número de repeticiones
{n,m} al menos n número de repeticiones, pero no más de m veces
$ Coincide con la posición final dentro de la cadena
* Coincide con cero o más veces para el elemento anterior

Recibe cualquier coincidencia en la cadena entre las expresiones 1 2 3
abc|123 y ABC
Paso 3: Describan el patrón de expresión regular proporcionado.
Patrón de
expresión regular Descripción
^83 Cualquier cadena que comience con el número 83

Cualquier cadena que contenga de 2 a 4 letras mayúsculas
[A-Z]{2,4} consecutivas
2015 Cualquier cadena que contenga el número 2015
05:22:2[0-9] Cualquier cadena que contenga de 05:22:20 a 05:22:29
\.com Cualquier cadena que contenga .com
complete|GET Cualquier cadena que coincida con complete o GET
0{4} Cualquier cadena que contenga 4 ceros consecutivamente
Paso 4: Verifiquen sus respuestas.

En este paso verificarán sus respuestas del paso anterior con un archivo de texto almacenado
en la VM CyberOps Workstation.
a. Abra la VM CyberOps Workstation e inicie sesión (nombre de usuario:
analyst/contraseña: cyberops).
b. Abran un terminal y diríjanse a la siguiente carpeta:
[analyst@secOps ~]$ cd lab.support.files/
c. Utilicen el comando less para abrir el archivo logstash-tutorial.log.
[analyst@secOps lab.support.files]$ less logstash-tutorial.log
d. En la parte inferior de la pantalla verán que logstash-tutorial.log: está resaltado. Es el
cursor en que introducirán la expresión regular. Antecedan la expresión regular con una
barra inclinada hacia adelante (/). Por ejemplo: el primer patrón de la tabla de arriba
es ^83. Introduzcan /^83.
El texto que coincide del archivo de registro está resaltado. Utilicen la rueda de
desplazamiento del mouse o las teclas j o k del teclado para ubicar los patrones
seleccionados.
e. Para la expresión siguiente, introduzcan /[A-Z]{2,4} en el cursor de los dos puntos (:).
Nota: El signo de los dos puntos se reemplazará por una / cuando escriban la expresión.
f. Introduzcan el resto de las expresiones regulares de la tabla del Paso 2. Asegúrense de
que todas las expresiones estén precedidas por una barra inclinada hacia adelante (/).
Continúen hasta haber verificado sus respuestas. Presionen q para salir del
archivo logstash-tutorial.log.
g. Cierren el terminal y apaguen la máquina virtual.
Práctica de laboratorio: Manejo de incidentes
Objetivos
Apliquen todo lo que saben sobre procedimientos para el manejo de seguridad para
formular preguntas sobre determinados escenarios de incidentes.
La respuesta a ante incidentes de seguridad informática se ha convertido en un
componente vital de cualquier organización. El proceso para manejar un incidente de
seguridad puede ser complicado e implicar a muchos grupos diferentes. Una
organización debe tener estándares para responder ante incidentes. Estos estándares
deben ser políticas, procedimientos y listas de comprobación. Para responder
correctamente a un incidente de seguridad, el analista debe estar capacitado para
saber qué hacer, y también tiene que seguir todas las pautas estipuladas por la
organización. Las organizaciones disponen de muchos recursos que les permiten
crear y mantener una política para el manejo de las respuestas ante incidentes de
seguridad informática, pero en los temas de los exámenes de SECOPS (Operaciones
de seguridad) de la CCNA se hace referencia específicamente a la Publicación
especial 800-61 del NIST. Aquí pueden encontrar esta publicación:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
Paso 1: Infestación por gusanos y agentes de Denegación distribuida de servicio

(Distributed Denial of Service, DDoS)
Estudien el siguiente escenario para analizar y determinar las preguntas sobre el
manejo de la respuesta ante incidentes que se deberían formular en cada etapa del
proceso de respuesta ante incidentes. Consideren los detalles de la organización y el
CSIRC cuando formulen sus preguntas.
Este escenario es una firma de inversiones pequeña y familiar. La organización tiene
solo una sede y menos de 100 empleados. Es martes por la mañana y se libera un
gusano nuevo; se propaga por medios extraíbles, y se puede copiar a sí mismo en
recursos compartidos de Windows. Cuando el gusano infecta a un host, instala un
agente de DDoS. Solo hubo firmas de antivirus disponibles varias horas después de
que el gusano comenzara a propagarse. La organización ya había sufrido infecciones
masivas.
La firma de inversiones ha contratado a un pequeño grupo de expertos en seguridad
que suelen utilizar el modelo diamante para el manejo de incidentes de seguridad.
Preparación:
Las respuestas variarán especialmente según los detalles del CSIRC. Ejemplos:
¿Consideraría la organización que esta actividad es un incidente? Si es así, ¿cuál de
las políticas de la organización viola esta actividad?
¿Qué medidas existen para intentar evitar que este tipo de incidente vuelva a ocurrir o
para limitar su impacto?
Detección y análisis:
¿Qué precursores del incidente, si los hubiera, podría detectar la organización? ¿Algún
precursor haría que la organización tomara medidas antes de que ocurriera el incidente?
¿Qué indicadores del incidente podría detectar la organización? ¿Qué indicadores
harían que alguien pensara que un incidente podría haber ocurrido?
¿Qué herramientas adicionales podrían ser necesarias para detectar este incidente en
particular?
¿Cómo priorizaría el equipo el manejo de este incidente?
Contención, erradicación y recuperación:
¿Qué estrategia debe tomar la organización para contener el incidente? ¿Por qué esta
estrategia es preferible a otras?
¿Qué herramientas adicionales podrían ser necesarias para responder a este
incidente en particular?
¿Qué personal participaría en los procesos de contención, erradicación y/o
recuperación?
¿Qué fuentes de evidencia, si las hay, debería adquirir la organización? ¿Cómo se
adquirirían las pruebas?
¿Dónde se almacenaría? ¿Cuánto tiempo debe conservarse?
Actividad posterior al incidente:
Las respuestas variarán según los detalles del CSIRC. Ejemplos:

¿Qué se podría hacer para evitar que ocurran incidentes similares en el futuro?
¿Qué se podría hacer para mejorar la detección de incidentes similares?
Paso 2: Acceso no autorizado a registros de nómina

Estudien el siguiente escenario. Analicen y determinen las preguntas sobre el manejo
de la respuesta ante incidentes que se deberían formular en cada etapa del proceso
de respuesta ante incidentes. Consideren los detalles de la organización y el CSIRC
cuando formulen sus preguntas.
Este escenario se trata de un hospital de mediana magnitud con varios consultorios y
servicios médicos externos. La organización tiene decenas de sedes y más de
5000 empleados. Debido al tamaño de la organización, han adoptado un
modelo CISRC con equipos distribuidos de respuesta ante incidentes. También tienen
un equipo de coordinación que controla a los CSIRT y les ayuda a comunicarse entre
sí.
Son las últimas horas de la tarde de un miércoles, el equipo de seguridad física de la
organización recibe una llamada de una administradora de nómina que vio salir de su
oficina a un desconocido, correr por el pasillo y salir del edificio. La administradora se
había alejado de su estación de trabajo solo durante unos pocos minutos y la había
dejado desbloqueada. El programa de nóminas sigue con la sesión abierta y en el
menú principal, tal como ella lo había dejado, pero cree que han movido el mouse. Se
le ha solicitado al equipo de respuesta ante incidentes que reúna evidencia
relacionada con el incidente y determine qué medidas se deben tomar.
Los equipos de seguridad ponen en práctica el modelo de la cadena de eliminación y
saben utilizar la base de datos VERIS. A modo de nivel de protección adicional, han
tercerizado parcialmente el personal a una MSSP para tener monitoreo las 24 horas
del día, los 7 días de la semana.
Preparación:

¿Consideraría la organización que esta actividad es un incidente? Si es así, ¿cuál de
las políticas de la organización viola esta actividad?
¿Qué medidas existen para intentar evitar que ocurra este tipo de incidente o para
limitar su impacto?
Detección y análisis:

¿Qué precursores del incidente, si los hubiera, podría detectar la organización?
¿Algún precursor haría que la organización tomara medidas antes de que ocurriera el
incidente?
¿Qué indicadores del incidente podría detectar la organización? ¿Qué indicadores
harían que alguien pensara que un incidente podría haber ocurrido?
¿Qué herramientas adicionales podrían ser necesarias para detectar este incidente en
particular?
¿Cómo priorizaría el equipo el manejo de este incidente?
Contención, erradicación y recuperación:

¿Qué estrategia debe tomar la organización para contener el incidente? ¿Por qué esta
estrategia es preferible a otras?
¿Qué herramientas adicionales podrían ser necesarias para responder a este
incidente en particular?
¿Qué personal participaría en los procesos de contención, erradicación y/o
recuperación?
¿Qué fuentes de evidencia, si las hay, debería adquirir la organización? ¿Cómo se
adquirirían las pruebas?
¿Dónde se almacenaría? ¿Cuánto tiempo debe conservarse?
Actividad posterior al incidente:

¿Qué se podría hacer para evitar que ocurran incidentes similares en el futuro?
¿Qué se podría hacer para mejorar la detección de incidentes similares?
SAMUEL CALVIJO
Práctica de laboratorio: Extraer un ejecutable de un PCAP

Objetivos
Parte 2: Analizar archivos de registros precapturados y capturas de tráfico
Analizar registros es muy importante, pero también lo es comprender de qué manera suceden
las transacciones de red al nivel de los paquetes.
En esta práctica de laboratorio analizarán el tráfico de un archivo pcap previamente capturado
y extraerán un ejecutable del archivo.
Recursos necesarios

a. Abran Oracle VirtualBox. Hagan clic en CyberOps Workstation > Settings > Network
(CyberOps Workstation > Configuración > Red). Además de Conectada a, seleccione
Adaptador en puente, si es necesario, y haga clic en Aceptar.
b. Inicien sesión en la VM CyberOps Workstation (nombre de usuario: analyst / contraseña:

cyberops), abran un terminal, y ejecuten el script configure_as_dhcp.sh.
./lab.support.files/scripts/configure_as_dhcp.sh
Parte 2: Analizar archivos de registros precapturados y capturas
de tráfico
En la Parte 2 trabajarán con el archivo nimda.download.pcap. Capturado en una práctica de

laboratorio anterior, nimda.download.pcap contiene los paquetes relacionados con la
descarga del malware Nimda. Si crearon el archivo en la práctica de laboratorio anterior y no
reimportaron sus VM CyberOps Workstation, sus versiones del archivo se almacenarán en el
directorio /home/analyst. Sin embargo, también se almacena una copia de ese archivo en la
VM CyberOps Workstation en el directorio /home/analyst/lab.support.files/pcaps, así que
podrá realizar esta práctica de laboratorio independientemente de que haya terminado la
práctica anterior o no. A fines de preservar la coherencia del resultado, en la práctica de
laboratorio se utilizará la versión almacenada en el directorio pcaps.
Si bien tcpdump se puede utilizar para analizar archivos capturados, la interfaz gráfica de
Wireshark facilita mucho la tarea. También es importante tener en cuenta que tcpdump y
Wireshark comparten el mismo formato de archivo para las capturas de paquetes; por lo tanto,
los archivos PCAP creados con una herramienta se pueden abrir con la otra.
a. Cambien de directorio para ingresar a la carpeta lab.support.files/pcaps, y generen un
listado de los archivos con el comando ls –l.
[analyst@secOps ~]$ cd lab.support.files/pcaps
[analyst@secOps pcaps]$ ls –l
b. Emita el siguiente comando para abrir el archivo nimda.download.pcap en Wireshark.
[analyst@secOps pcaps]$ wireshark-gtk nimda.download.pcap
c. El archivo nimda.download.pcap contiene la captura de paquetes relacionadas con la
descarga de malware que se realizó en la práctica de laboratorio anterior. El pcap contiene
todos los paquetes enviados y recibidos mientras se estaba ejecutando tcpdump.
Seleccionen el cuarto paquete de la captura y expandan el Protocolo de transferencia de
hipertexto (HTTP) para que aparezca como se indica a continuación.
d. Los paquetes del uno al tres son la el protocolo de enlace TCP. En el cuarto paquete se
muestra la solicitud correspondiente al archivo de malware. A modo de confirmación de lo
que ya se sabía, la solicitud se realizó por HTTP, y se envió como solicitud GET.
e. Como HTTP se ejecuta por TCP, se puede utilizar la característica Follow TCP Stream
(Seguir flujo de TCP) de Wireshark para reconstruir la transacción TCP. Seleccionen el
primer paquete TCP de la captura; es un paquete SYN. Háganle clic derecho y elijan
Follow TCP Stream.
f. En Wireshark se abre otra ventana con los detalles correspondientes a todo el flujo de TCP
seleccionado.
¿Qué son todos esos símbolos que se ven en la ventana de Follow TCP Stream? ¿Son
interferencias de conexión? ¿Son datos? Explique.
 Todos esos símbolos son datos que están codificados.
Se pueden distinguir algunas palabras dispersas entre los símbolos. ¿Por qué están allí?
 Porque se transmite por el protocolo http.
g. En la ventana de Follow TCP Stream, hagan clic en Close (Cerrar) para regresar al archivo
nimda.download.pcap de Wireshark.
Parte 3: Extraer archivos descargados desde archivos PCAP

Como los archivos de capturas contiene paquetes relacionados con el tráfico, se puede utilizar
un PCAP de una descarga para recuperar un archivo descargado anteriormente. Siga los
pasos que se detallan a continuación para utilizar Wireshark y recuperar el malware Nimda.
a. En ese cuarto paquete del archivo nimda.download.pcap, observen que la solicitud HTTP
GET se generó desde 209.165.200.235 hacia 209.165.202.133. En la columna Info
(Información) también se ve que de hecho se trata de la solicitud GET correspondiente al
archivo.
b. Con el paquete de la solicitud GET seleccionado, diríjanse a File > Export Objects >
HTTP (Archivo > Exportar objetos > HTTP) desde el menú de Wireshark.
c. En Wireshark se mostrarán todos los objetos HTTP presentes en el flujo TCP que contiene
la solicitud GET. En este caso, el único archivo presente en la captura es
W32.Nimda.Amm.exe. El archivo aparecerá en pantalla después de algunos segundos.
¿Por qué W32.Nimda.Amm.exe es el único archivo presente en la captura?

 Porque es el único archivo que se obtuvo en la comunicación de las primeras lines.
d. En la ventana HTTP object list (Lista de objetos HTTP), seleccionen el archivo
W32.Nimda.Amm.exe y hagan clic en Save As (Guardar como), en la parte inferior de la
pantalla.
e. Hagan clic en la flecha hacia la izquierda hasta ver el botón Home (Inicio). Hagan clic en
Home y luego en la carpeta analyst (no en la ficha analyst). Guarden el archivo allí.
f. Regresen a su ventana del terminal y asegúrense de que el archivo se haya guardado.
Cambien de directorio para ingresar a la carpeta /home/analyst y generen una lista de los
archivos de la carpeta con el comando ls -l.
[analyst@secOps pcaps]$ cd /home/analyst
¿Se guardó el archivo? Si se guardó

g. El comando file proporciona información sobre el tipo de archivo. Utilicen el comando file
para averiguar un poco más sobre el malware, tal como se indica a continuación:
[analyst@secOps ~]$ file W32.Nimda.Amm.exe
Tal como se ve arriba, W32.Nimda.Amm.exe realmente es un archivo ejecutable de Windows.

En el proceso del análisis de malware, ¿cuál sería un próximo paso probable para un
analista especializado en seguridad?
 El siguiente paso sería enviar el archivo a un sandbox, para verificar el
comportamiento del malware en un ambiente simulado.
Miguel Arias
Práctica de laboratorio: Interpretar datos HTTP y DNS
para aislar al actor de la amenaza
Objetivos
En esta práctica de laboratorio, analizarán registros durante un aprovechamiento malicioso de
vulnerabilidades HTTP y DNS documentadas.
Parte 2: Investigar un ataque de Inyección SQL
Parte 3: Analizar una exfiltración de datos
MySQL es un sistema de administración de bases de datos relacionales (Relational Database
Management System, RDBMS) que utiliza el lenguaje de consultas estructurado (Structured
Query Language, SQL) para agregar contenido a una base datos, acceder a él y administrarlo.
MySQL es un RDBMS popular que utilizan numerosas aplicaciones web. Desafortunadamente,
un atacante puede emplear una técnica de hacking web llamada inyección SQL para ejecutar
comandos SQL maliciosos en un intento por controlar el servidor de bases de datos de una
aplicación web.
Los servidores de nombres de dominio (Domain Name Servers, DNS) son directorios de
nombres de dominio y traducen los nombres de dominio a direcciones IP. Este servicio puede
utilizarse para exfiltrar datos.
En esta práctica de laboratorio investigarán una posible inyección SQL para acceder a la base
de datos SQL del servidor. También analizarán los registros para investigar una posible
exfiltración de datos y el método de exfiltración.
Recursos necesarios
 Servidor con al menos 3 GB de RAM y 10 GB de espacio libre en disco.
 Versión más reciente de Oracle VirtualBox
 Una máquina virtual: VM Security Onion alternativa

a. Descarguen la máquina virtual Security Onion alternativa.
b. Abran Oracle VirtualBox. Importen la VM Security Onion alternativa.
c. Abran la VM Security Onion e inicien sesión. Inicien sesión con el usuario analyst y la
contraseña cyberops.
d. En la VM Security Onion alternativa, hagan clic derecho en el Escritorio > Open Terminal
Here (Abrir terminal aquí). Introduzcan el comando sudo service nsm status para verificar
que todos los servidores y sensores estén listos. Este proceso podría demorar unos
instantes. Si algunos servicios reportan una falla (FAIL), repitan el comando según sea
necesario hasta que todos los estados sean OK antes de pasar a la parte siguiente.
analyst@SecOnion:~/Desktop$ sudo service nsm status
Status: securityonion
* sguil server [
OK ]
Status: HIDS
* ossec_agent (sguil) [
OK ]
Status: Bro
Name Type Host Status Pid Started
manager manager localhost running 5577 26 Jun 10:04:27
proxy proxy localhost running 5772 26 Jun 10:04:29
seconion-eth0-1 worker localhost running 6245 26 Jun 10:04:33
Status: seconion-eth0
* netsniff-ng (full packet data) [ OK ]
* pcap_agent (sguil) [ OK ]
* snort_agent-1 (sguil) [ OK ]
* snort-1 (alert data) [ OK ]
* barnyard2-1 (spooler, unified2 format) [ OK ]
<output omitted>
Parte 2: Investigar un ataque de Inyección SQL
Cuando analizaron el registro de Sguil, notaron que había un posible ataque de Inyección SQL.
Investigarán los eventos para determinar la gravedad del posible aprovechamiento malicioso.
Paso 1: Analicen los registros de Sguil.

a. Diríjanse a la VM Security Onion alternativa. Haga doble clic en el icono de Sguil del
Escritorio. Introduzcan el nombre de usuario analyst y la contraseña cyberops cuando el
sistema se los solicite.
b. Hagan clic en Select All (Seleccionar todas) para monitorear todas las redes. Hagan clic
en Start SGUIL (Iniciar SGUIL) para continuar.
c. En la ventana inferior derecha de la consola de Sguil, hagan clic en Show Packet Data
(Mostrar datos de paquetes) y en Show Rule (Mostrar regla) para ver los detalles de una
alerta seleccionada.
a. Busquen alertas relacionadas con ET WEB_SERVER Possible SQL Injection Attempt
UNION SELECT. Seleccionen las alertas que comiencen con 5. Estas alertas están
relacionadas con seconion-eth1-1, y probablemente sean las más recientes. Seleccionen
las alertas con el siguiente ID: 5.5836.
d. Hagan clic derecho sobre el número que se encuentra debajo del encabezado de CNT
correspondiente a la alerta seleccionada para ver todas las alertas relacionadas.
Seleccionen View Correlated Events (Ver eventos correlacionados).
e. Hagan clic en el ID de una alerta en los resultados. Seleccionen Transcript (Transcripción)
para ver los detalles correspondientes a esta alerta.
f. En esta ventana pueden ver que la declaración GET que está utilizando el operador
UNION se empleó para acceder a la información de tarjetas de crédito. Si no ven esta
información, hagan clic derecho sobre otro de los eventos correlacionados.
¿Qué información pueden reunir de la ventana Transcript?
__________datos del cliente, datos del servidor y la transacción realizada, expiraciónde la
tarjeta de crédito
________________________________________________________________________
__
________________________________________________________________________
____________
________________________________________________________________________
____________
g. También puede determinar la información que recuperó el atacante. Hagan clic en Search
(Buscar) e introduzcan username (nombre de usuario) en el campo Find: (Buscar:).
Utilicen el botón Find para encontrar la información capturada. La misma información de
tarjetas de crédito puede aparecer en pantalla con un aspecto distinto al de la figura de
abajo.
Comparen la información de las tarjetas de crédito de la ventana de la transcripción con el

contenido que se extrajo con el ataque de Inyección SQL. ¿Qué pueden concluir?
R/=se observa la información de l atrajeta de crédito

________________________________________________________________________
____________
h. Cierren las ventanas cuando hayan terminado.
i. Regresen a la ventana de Sguil, hagan clic derecho sobre el mismo ID de alerta que
contiene la información de tarjetas de crédito exfiltrada y seleccionen Wireshark.
j. Hagan clic derecho sobre un paquete TCP y seleccionen Follow TCP Stream (Seguir flujo
de TCP).
k. En la ventana del flujo de TCP se muestran la solicitud GET y los datos exfiltrados. Sus
salidas pueden diferir de la figura de abajo, pero tiene que contener la misma información
de tarjetas de crédito que la transcripción anterior.
l.
m. En este punto podrían guardar los datos de Wireshark si hacen clic en Save As (Guardar
como), en la ventana del flujo de TCP. Como alternativa, también pueden guardar el
archivo pcap de Wireshark. También pueden documentar las direcciones IP y los puertos
de origen y destino, la hora del incidente y el protocolo utilizado para el análisis
subsiguiente a cargo de un analista Nivel 2.
n. Cierren o minimicen Wireshark y Sguil.
Paso 2: Analicen los registros de ELSA.

Los registros de ELSA también pueden proporcionar información similar.
a. Cuando estén en la VM Security Onion, hagan doble clic para iniciar ELSA desde el
Escritorio. Si ven el siguiente mensaje: "Your connection is not private" ("Su conexión no es
privada"), hagan clic en ADVANCED (AVANZADAS) para continuar.
b. Hagan clic en Proceed to localhost (unsafe) (Proseguir a un host local [inseguro]) para
continuar al host local.
c. Inicien sesión con el nombre de usuario analyst y la contraseña cyberops. Ahora
realizarán una consulta para buscar una Inyección SQL HTTP de la alerta de Sguil.
d. En el panel izquierdo, seleccionen HTTP > Top Potential SQL Injection (HTTP >
Principales inyecciones SQL potenciales).
e. Haga clic en el campo Desde y seleccione 11/11/17 como la fecha. Hagan clic en Submit
Query (Enviar consulta). Seleccionen 209.165.200.235.
f. Se abre información detallada de la alerta. Esta información está relacionada con la
inyección SQL exitosa. Observen la consulta union que se utilizó durante el ataque. En la
primera entrada, hagan clic en Info.
g. Hagan clic en Plugin > getPcap (Complemento > getPcap). Introduzcan el nombre de
usuario analyst y la contraseña cyberops cuando el sistema se los solicite. Si es
necesario, hagan clic en Submit (Enviar). CapMe es una interfaz web que les permite
obtener una transcripción pcap y descargar el pcap.
h. La transcripción de pcap se traduce utilizando tcpflow, y esta página también proporciona

el enlace para acceder al archivo pcap. También pueden buscar información sobre el
nombre de usuario. Presionen Ctrl + F para abrir el cuadro de diálogo Find… (Buscar…).
Introduzcan el nombre de usuario en el campo. Deberían poder localizar la información
de tarjetas de crédito que se expuso durante el ataque de inyección SQL.
Parte 3: Analizar una exfiltración de datos

Cuando analizaron los registros de ELSA, notaron que había algunas solicitudes de DNS
extrañas. Si meta es determinar si se exfiltró algún dato durante el aprovechamiento malicioso.
a. Si es necesario, abra ELSA desde el Escritorio de la VM alternativa Security Onion. Si ven
el siguiente mensaje: "Your connection is not private" ("Su conexión no es privada"), hagan
clic en ADVANCED (AVANZADAS) para continuar. Hagan clic en Proceed to localhost
(unsafe) (Proseguir a un host local [inseguro]) para continuar al host local. Introduzcan el
nombre de usuario analyst y la contraseña cyberops cuando el sistema se los solicite.
b. En las consultas de ELSA de la barra lateral izquierda, hagan clic en DNS > Bottom (DNS
> Menos frecuentes).
c. Haga clic en el campo Desde y seleccione 11/11/17 como la fecha. Hagan clic en Submit
Query (Enviar consulta). Esto devuelve registros correspondientes a todas las solicitudes
de DNS, ordenados de modo que los menos frecuentes aparezcan primero.
d. Desplácense hacia abajo por la lista de resultados para ver algunas consultas de
ns.example.com con una cadena hexadecimal como primera parte del nombre de
subdominio. Habitualmente, los nombres de dominio no son expresiones hexadecimales de
63 bytes. Esto podría indicar la presencia de actividad maliciosa porque los usuarios
probablemente no pueden recordar un nombre de subdominio largo con letras y número
aleatorios.
Paso 2:
a. Hagan clic en uno de los enlaces y copien la cadena de 63 bytes preanexada a

ns.example.com.
b. Abran una ventana del terminal y utilicen los comandos echo y xxd para revertir la cadena
hexadecimal. La opción -n impide la salida de la línea nueva de arrastre.
analyst@SecOnion:~/Desktop$ echo -n
"434f4e464944454e5449414c20444f43554d454e540a444f204e4f542053" |
xxd -r -p
CONFIDENTIAL DOCUMENT
DO NOT Sanalyst@SecOnion:~/Desktop$
¿Cuál es el resultado si siguen revirtiendo las cadenas hexadecimales?

R/=
Conclusiones
Si bien las herramientas presentadas en esta actividad son útiles, cada una tiene su propio servicio
y es posible que tenga que ser ejecutada en dispositivos totalmente diferentes. Una mejor manera
(que se analiza más adelante en el curso) es concentrar toda la información de registro en una sola
herramienta, lo que permite facilitar la referencia cruzada y hace posibles potentes funcionalidades
de búsqueda. Las plataformas de Administración de información y eventos de seguridad (Security
Information and Event Management, SIEM) puede recopilar archivos de registro y otros datos de
diversas fuentes e integrar la información correspondiente al acceso por medio de una sola
herramienta.
Para realizar este tipo de laboratorios, es de suprema importancia tener bases claras en el sistema
operativo Linux, pues ejecutar comando por ejecutarlos es una tarea sencilla, pero al final no se está
aprendiendo, por ello se sugiere haber realizado los laboratorios de las primeras unidades donde se
trató el tema de OS linux desde cero. Por otro lado, se necesita si o si un computador con mínimo
12 GB de memoria RAM para que todas las máquinas virtuales corran al mismo tiempo sin problema.

Unidad3 Paso5 Consolidado - 2150521 - 24 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad3 Paso5 Consolidado - 2150521 - 24 PDF

Cargado por

Copyright:

Formatos disponibles

Paso 6 Actividad Colaborativa 3

CURSO ACCESO A LA WAN

Nombre del alumno

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA (UNAD)

Packet Tracer: Explorar una implementación de NetFlow

Entrada Valor Explicación

Traffic contribution 100 % (1/1) Esta es la proporción de todo el tráfico

Paso 3: Crear tráfico adicional

c. Regresen a PC-1 y repitan el ping al gateway.

Parte 2: Observar registros de NetFlow correspondientes a una

Paso 1: Acceder al servidor web por dirección IP

c. En el Colector de NetFlow, hagan clic en la ficha Desktop (Escritorio).

Campo de registro Valor Pautas

Dirección IP de origen 10.0.0.10 PC1

Predigan los valores correspondientes a la respuesta de la página web que ingresa al

Campo de registro Valor Pautas

Dirección IP de origen 192.0.2.100

Paso 2: Acceder al servidor web por dirección IP

Tabla de calificación sugerida

Ubicación de la Posibles Puntos

Packet Tracer: Generar archivos de registro desde varias

b. Seleccione la ficha Servicios y, luego, SYSLOG en la lista de servicios que aparece a la

d. Las entradas de Syslog provenientes de clientes syslog aparecerán en la ventana de la

e. Mantengan esta ventana abierta y visible y sigan con el Paso 2.

c. Introduzca el comando debug eigrp packets para habilitar la depuración EIGRP. La

e. Después de que se hayan registrado algunos mensajes, hagan clic en el botón de

Parte 2: Registrar el acceso de los usuarios

c. Hagan clic en R2 > CLI.

¿Qué sucedió en la ventana Auditoría AAA?

_________flag stop significa que cerro

Parte 3: NetFlow y la visualización

Práctica de laboratorio: Configurar un entorno con varias

VM CyberOps Workstation Arch Linux 2,23 GB 7 GB 1 GB analyst cyberops

Nota: Si ha escrito incorrectamente el nombre de usuario correspondiente a la VM de Kali,

Paso 1: Importar máquinas virtuales del dispositivo a VirtualBox

 Se realiza la importación de la MV Kali linux

e. Seleccionen la VM CyberOps Workstation en VirtualBox y hagan clic en Configuración.

[analyst@secOps ~]$ ping 209.165.201.17

k. Cierren la ventana del terminal cuando hayan terminado.

Las otras dos opciones son las siguientes:

Parte 1: Preparar el entorno virtual

Parte 2: El firewall y los archivos de registro de IDS

Paso 1: Monitoreo de archivos de registro de un IDS en tiempo real

c. En el shell de R1, inicien el IDS basado en Linux: Snort.

2017-04-28 17:00:04 (16.4 MB/s) - 'W32.Nimda.Amm.exe' saved [345088/345088]

02/05/2017 10:26:50 (105 MB/s) - 'W32.Nimda.Amm.exe' saved [345088/345088]

Paso 2: Afinar reglas de firewall en función de alertas de un IDS

Chain FORWARD (policy ACCEPT 6 packets, 504 bytes)

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

e. En H5, trate de descargar el archivo nuevamente:

--2017-05-01 14:44:47-- (try: 2)

Parte 3: Finalizar y desactivar el proceso de Mininet

Parte 1: Normalizar marcas de hora en un archivo de registro

¿Cuántas columnas contiene el archivo de registro Apache anterior?

b. En el terminal de la VM CyberOps Workstation se almacena una copia del archivo de

Parte 3: Preparación de archivos de registro en Security Onion

Paso 1: Pasen a Security Onion.

c. Los registros de ELSA se pueden encontrar en el directorio /nsm/elsa/data/elsa/log/.

Paso 4: Archivos de registro de Snort

Paso 1: Completen el tutorial regexone.com.

$ Coincide con la posición final dentro de la cadena