1.1 Per qu s tan important l'eficincia dels sistemes de detecci d'intrusions?

Quina s la diferncia entre falsos positius i falsos negatius?

La eficiencia en un IDS es importante para intentar analizar, en tiempo real, la

actividad que se produce en el sistema en el que se implanta. De nada nos
puede servir un IDS si tarda en detectar un ataque, o si no es capaz de discernir
entre una actividad legal o ilegal para detectarla como maliciosa.

Un IDS eficiente se considera a aquel sistema de deteccin de intrusos que es

capaz de detectar la mxima actividad maliciosa que se produzca en el sistema
en tiempo real, para que ste sea lo ms seguro posible. Debe cumplir las
siguientes caractersticas:

A) Precisin: Capacidad del sistema para detectar ataques y distinguirlos de lo

que se define como comportamiento normal del sistema.
B) Rendimiento: Capacidad de detectar un ataque en tiempo real
C) Completitud: La capacidad de detectar todos los tipos de ataques.
D) Tolerancia a fallos: Capacidad del IDS a resistir un fallo del sistema.
E) Tiempo de respuesta: Es el tiempo que tarda el IDS en reaccionar ante un
ataque.

Un falso negativo es la actividad que se produce en el sistema de tipo intrusivo

pero que no es detectada como anmala por parte del IDS, o sea el sistema de
forma errnea indica ausencia de intrusin cuando si la hay.

Un falso positivo, por el contrario, es la actividad que se produce en el sistema

de tipo no intrusivo pero cmo se comporta de forma anmala, el IDS decide
que es de tipo intrusiva, o sea el sistema de forma errnea indica existencia de
intrusin cuando no la hay.

La existencia de muchos falsos positivos hace que el sistema no sea preciso y

que el usuario pueda perder la confianza ante el IDS ya que algunas actividades
permitidas en el sistema, el IDS las contempla como errneas.

La existencia de muchos falsos negativos hace que el sistema no sea eficiente,

o sea que aunque aparentemente el IDS no detecta actividad intrusiva, puede
ocurrir que se estn haciendo actividades ilegales, y el IDS no sea capaz de
detectarlas.

En resumen un IDS con muchos falsos negativos es muy peligroso en cuanto a

la seguridad que debe controlar pues no es capaz de detectar muchas
intrusiones pero un IDS con muchos falsos positivos es muy pesado de cara al
usuario, en cuanto a su actividad cotidiana, ya que mucha de esta actividad, la
marca como intrusiva.

1.2 Quins sn els diferents tipus de sensors en el sistemes de detecci

d'intrusions i en qu es diferencien?
Indica i argumenta quin tipus de sensor de sistemes de detecci d'intrusions
implantaries en els segents tipus de sistemes:
base de dades amb una baixa taxa de connexions d'usuaris

base de dades amb una alta taxa de connexions d'usuaris

 sistema d'usuari tipus porttil / ordinador d'escriptori
xarxa de control industrial amb sistemes embebits tipus Raspberry Pi
Los tipos de sensores en los IDS son:

Sensores basados en sistema o equipo (HIDS), se encargan de monitorizar los

datos generados por un usuario o el sistema, en un equipo, para poder
identificar una amenaza o intrusin en ste. Suelen recoger la informacin de
logs del sistema, recursos que se usan, conexiones de usuario, etc.

Sensores basados en red (NDIS) se encargan de monitorizar los datos que

circulan por el segmento de red donde estn instalados para poder detectar
ataques que se produzcan en ste. Suelen capturar los paquetes que pasan por
la red y los almacenan en un repositorio o base de datos, para poder analizarlos
posteriormente en busca de patrones significativos de ataque.

Sensores basados en aplicacin (AIDS) se encargan de monitorizar las

aplicaciones que se ejecutan en un equipo para poder identificar una amenaza o
intrusin en ste. Suelen recoger la informacin de los logs de las aplicaciones,
recursos que usan, actividad que realizan, etc. Algunos expertos, los consideran
un caso especial de HIDS. La diferencia estriba en que unos actan sobre los
programas propios del sistema operativo (HIDS) y otros en las aplicaciones que
se ejecutan en ste (AIDS).

Los sensores basados en sistema o en aplicaciones solo recogen informacin

sobre eventos ocurridos dentro de un equipo sin tener en cuenta el trfico de
red, por el contrario los sensores de red pueden recoger informacin de los
paquetes que circulan por la red pero no pueden recoger informacin de los
equipos

Otro tipo de sensores que se podran considerar son los sensores hbridos o los
sensores distribuidos, que combinan las funciones de los HIDS y de los NDIS
para explotar las ventajas de cada uno de estos tipos de sensores.

o En un sistema de base de datos con baja tasa de conexin de usuarios

aconsejara usar sensores basado en aplicacin (AIDS) para monitorizar la
aplicacin que gestiona la base de datos.

o En un sistema de base de datos con alta tasa de conexin de usuarios

aconsejara usar sensores basados en red (NIDS) para monitorizar el
trfico de red pues al haber una alta tasa de conexin de usuarios los
sistemas de tipo AIDS o HIDS podran ralentizar la eficiencia del equipo.

o En un sistema de usuario con porttil o desktop aconsejara un sistema de

sensores basados en hosts (HDIS) porque proporcionan mucha
informacin, y de calidad, sobre el equipo en cuestin y as se podra
detectar de forma ms fcil ataques en el equipo. Adems al no haber, a
priori, actividad multiusuario, no penalizara en demasa el rendimiento
del equipo.

o En un sistema de red de control industrial con sistemas embebidos tipo

Raspberry Pi aconsejara un sistema hbrido en el que habra sistemas de
tipo HDIS para controlar los ataques que se pudieran producir en las
Raspberry Pi y sistemas de tipo NDIS para monitorizar el trfico de red e
intentar controlar acciones ilcitas en la red.
1.3 Explica al menys dues formes en que un atacant podria aprofitar i explotar
els desavantatges que tenen els sistemes de detecci d'intrusions amb sensors
basats en xarxa per a no ser detectat en llanar un atac contra la xarxa que
aquests sensors protegeixen. Indica al menys una eina de sistemes de detecci
d'intrusions basat en xarxa.

Una forma en la que un intruso pudiera ser no detectado por un NDIS es usando
una comunicacin cifrada en la red pues as la informacin capturada no podra
ser interpretada por el NDIS

Otra forma sera realizar ataques en una red con mucho trfico, (se podra saber
por el tiempo de respuesta de un ping, por ejemplo) usando paquetes
fragmentados, pues el NDIS no podra ser capaz de analizar todos los paquetes
para determinar el ataque, y encima se aadira el inconveniente de que stos
estn fragmentados.

Algunos ejemplos de herramientas NDIS son: Snort o Bro que son de cdigo
abierto o Etrust Intrusion Detection o Cisco Secure Intrusion Detection Sysytem
que son herramientas comerciales.

1.4 En una xarxa d'alta seguretat protegida per un sistema de detecci

d'intrusions basat en xarxa, argumenta quina tcnica d'escaneig de
vulnerabilitats faria servir un atacant per evitar ser detectat fcilment, i indica
almenys una eina que es pugui utilitzar en aquest cas.

Lo que utilizara es un escaneo de vulnerabilidades basados en red usando la

tcnica de mtodos de inferencia, pues es una tcnica menos invasiva, aunque
con resultados ms pobres que los obtenidos con otras tcnicas. Lo que hace
esta tcnica es buscar la versin del sistema, comprobar que puertos estn
abiertos, etc., por eso no es tan agresiva y puede pasar desapercibida por un
NDIS.

Una herramienta que puede utilizar esta tcnica es Nessus. Otras herramientas
podrn ser Retina Network Community, OpenVas o NeXpose Community
Edition.

1.5 Per qu els equips de decepci proporcionen un valor afegit tan important
en l'mbit de detecci i prevenci d'intrusions? Argumenta en quin lloc dels
marcats amb *desplegaries un equip de decepci en el diagrama de xarxa
adjunt.
[ Xarxa interna ] * <-> Tallafocs 1 <-> DMZ <-> * Tallafocs 2 *
<-> Internet
| |
Servidor BD Servidor mail

Por qu lo que hacen es intentar atraer a los atacantes en un sistema,

simulando ser equipos reales que estn situados dentro de la red, para obtener
2 objetivos bsicamente:
 Ver los intentos de ataque que se producen y analizar cmo se producen,
para as poder detener posibles ataques a la red corporativa y poder asegurar
los puntos dbiles de sta.

Prevenir que un atacante no pueda acceder totalmente a los equipos de la red

corporativa, bien por que dedica un tiempo extra a analizar un equipo ficticio, o
bien por qu es capaz de advertir al administrador del sistema de que se est
produciendo un ataque para que tome las medidas ms oportunas.

Los equipos de decepcin se deben instalar detrs de los cortafuegos,

permitiendo las conexiones de entrada al equipo, para hacerlo ms atrayente
para el intruso y limitando las conexiones de salida para qu, desde el equipo
de decepcin, no pueda atacar equipos reales de la red corporativa.

Por esta regla de tres, los equipos de decepcin que instalara seran los
siguientes:
Entre el cortafuego 1 y la red interna para intentar atraer a los atacantes a
la red interna de la empresa
Entre el cortafuego 2 y la zona DMZ para intentar atraer a los atacantes
de la zona desmilitarizada que contiene el servidor de correo y la BD de la
empresa.
2.1 Qu s el projecte HoneyMix i quins problemes intenta solucionar?

HoneyMix es un proyecto que se basa en la tecnologa SDN (Redes Definidas por

Software) para crear una HoneyNet inteligente que permita eludir los
mecanismos de deteccin de los Honeypots de la red por parte de los
atacantes, por ejemplo con tcnicas fingerprinting, y que permita gestionar de
forma detallada los HoneyPots de la HoneyNet.

Lo que pretende solucionar es la deteccin de un Honeypot, por parte de un

atacante, pues sino el atacante cambia de objetivo. Para ello HoneyMix
establece mltiples conexiones con los honeypots que tiene y elige la conexin
ms conveniente para engaar al atacante y que ste permanezca conectado.

2.2 Quines caracterstiques t una HoneyNet de tercera generaci (Gen-III) i

quines limitacions presenta?

La HoneyNet de tercera generacin es una red de HoneyPots que usa un firewall

personalizado, HoneyWall, como gateway de capa 2 transparente, para obtener
un mejor control en el trfico entrante y saliente de la red, y que no es
detectado debido a que HoneyWall se oculta en la red (como he mencionado
acta como un Bridge de capa2). Tambin es capaz de limitar el trfico saliente
cuando se intenta usar un ataque DDoS desde un HoneyPot atacado y adems
puede capturar procesos o datos malignos gracias a que integra herramientas
de anlisis de datos como Argus + Hflow( recolectan y analizan el trfico de red)
o Swatch (que analiza los ficheros de logs) y utilidades como iptables (Firewall
de Linux), snort (Un sistema NIPS) o sebek (Una HoneyNet de 3 generacin)

Las limitaciones que presenta, debido a que no tiene un control minucioso sobre
los datos, es que no puede emular a 2 o ms sistemas vulnerables (HoneyPots)
con el mismo servicio a la vez. Por ejemplo si usa un servicio HTTP para emular
un ataque XSS en un HoneyPot y se usa un servicio HTTP para emular Sql
Injection en otro, no es capaz de recoger o filtrar los datos de ambos ataques a
la vez, solo podr usar uno.

Otra de las limitaciones que presenta, aunque de menor trascendencia, es que

no es capaz de detectar si un honeypot interno atacado intenta infectar a otro
honeypot interno de la misma red interna ya que HoneyWall protege el trfico
malicioso que va a la red externa.

El problema principal es pues, que la arquitectura de una HoneyNet de 3

generacin para atraer a un mayor nmero de intrusos, no es capaz de
combinar 2 o ms HoneyPots a la vez, que usen el mismo servicio, ya sea de
baja interaccin (simulan algunas de las utilidades del servicio) o de alta
interaccin (simulan todas las prestaciones del servicio), pues HoneyWall no es
capaz de transmitir los datos de forma dinmica al honeypot ms apropiado
para que pueda tratarlos correctamente.
2.3 Quins components formen una HoneyMix i en qu es caracteritzen? Quins
avantatges t una HoneyMix enfront d'una simple honeynet?

Una de las ventajas que tiene HoneyMix sobre una HonyeNet es que es ms
inteligente, gracias al uso de SDN (Redes definidas por Software), en el sentido
de que es capaz de crear un mapa con todos los servicios disponibles en la red y
administrar el control de los datos de estos servicios.

HomeyMix lo que hace es optimizar el uso de cada HoneyPot, creando mtodos

de comunicacin (multicast) entre grupos de HoneyPots asociados, para
distribuir el trfico entrante. De esta forma, es capaz de seleccionar la conexin
ms apropiada, cuando se produce un ataque, y derivarla a un grupo asociado
de HoneyPots para que recojan los datos de ese ataque. As puede recoger
mltiples ataques al mismo servicio, cosa que no puede hacer una HoneyNet.

Los componentes de una HoneyMix son:

1. El mdulo Response Scrubber, lo que hace es manipular la respuesta que se

le da a un atacante que aplique tcnicas de fingerprinting para la deteccin de
un honeypot, con el objetivo de camuflar el honeypot.

2. Forwarding Decision Engine (FDE). Crea un mapa de servicios de la honeynet

teniendo en cuenta los servicios que estn solapados en los HoneyPots, Cuando
se produce un ataque enva todas las solicitudes a los honeypots asociados a
ese servicio y pone en cuarentena a los honeypots afectados, creando una
instancia idntica de cada uno de ellos (gracias al uso de NFV), para seguir
ofreciendo una buena consistencia en la red.

3. Connection Selection Engine (CSE), establece una conexin entre el atacante

y un honeypot. l HoneyPot es elegido por HoneyMix, de entre los HoneyPots
asociados al servicio afectado, a travs del peso que calcula Behavior Learner

4. El mdulo Behavior Learner, calcula un peso por cada conexin que se

produce entre el switch SDN y el honeypot, para indicar la actividad del
atacante, contra ms tiempo este la conexin activa y menos intentos de
modificacin por parte del mdulo Response Rouber sean hechos, ms peso
tendr la conexin.

5. SDN switch. Es gestionado por el motor FDE. En caso de ataque, conecta con
HoneyMix para recibir las instrucciones sobre qu direccin debe tomar el flujo
de datos para redirigirlo al HoneyPot apropiado, ponindolo en cuarentena, y
gracias al uso de NFV, crea una nueva instancia del HoneyPot afectado y
establece un nuevo flujo de datos para dicha instancia.
2.4 Quines tcniques s'utilitzen per realitzar fingerprinting de sistemes de
decepci honeypot?

Hay varias tcnicas que pueden utilizar los intrusos para detectar si estn en un
sistema honeypot, algunas de ellas son:

Fijarse en el tipo de sistema operativo o servicio que usa el sistema

atacado, pues algunas respuestas indican que el sistema operativo o el
servicio es emulado, al devolver siempre un valor caracterstico, como por
ejemplo el HoneyPot Kippo que devuelve en la versin de Linux una fecha
concreta. En este caso se pueden usar tcnicas de fingerprinting como
uname r o nmap A.

Fijarse en las variables de entorno del sistema atacado, pues la mayora

de HoneyPots se ejecutan en entornos virtualizados y el atacante puede
analizar sus variables de entorno, como en qu modo de usuario est, que
tarjeta de video o que tarjeta de red usa, etc. para luego deducir si se
trata de un entorno virtualizado de un Honeypot.

2.5 Explica qu sn les tecnologies de Software Defined Networks (SDN) i

Network Function Virtualization (NFV), i com es beneficia el projecte HoneyMix
d'aquestes dues tecnologies.

SDN (Redes Definidas por Software) y NFV (Virtualizacin de las Funciones de

Red) son 2 tecnologas, complementaras, que lo que pretenden es dar un
aspecto ms flexible y ligero a la hora de disear y gestionar las redes,
procurando enfocarlas ms desde el punto de vista del software para evitar la
dependencia fsica del hardware.

SDN procura independizar la capa de control (protocolos de enrutamiento, listas

ACLs, etc.), de la capa de datos (switching, routing), realizando un control
centralizado de la capa de control que permite automatizar el comportamiento
de la red, pudiendo as, por ejemplo, gestionar el ancho de banda entre los
diferentes elementos de la red.

La idea es que haya un software SDN controller, que centraliza la capa de

control y que aplica la lgica del switching/routing (reglas almacenadas en las
flow tables de los switches/routers) a los equipos de la red, usando un protocolo
especfico, Openflow. As se optimizan los recursos de red, haciendo que la red
sea ms dinmica y flexible y que se reduzcan los costes econmicos.

NFV implementa funciones de red mediante software, evitando el uso de

dispositivos hardware, que hacen que la red no sea tan escalable, sea ms cara,
ms ineficiente energticamente y ms costosa de mantener. Por ejemplo para
realizar un cifrado de red se puede usar un software de cifrado en un servidor
en lugar de adquirir un dispositivo hardware especfico para esa funcin.

Con la combinacin de NFV y SDN, HoneyMix puede activar un nuevo HoneyPot

(en el caso de que un HoneyPot sea atacado) y habilitar la comunicacin de
datos de forma dinmica para volver a ofrecer un servicio de red idntico.
3.1. Detecci descaneig de ports TCP amb Bro
Bro ve installat per defecte amb molts scripts a /usr/share/bro/ que detecten
molts atacs, com per exemple un escaneig TCP. Referncia:
https://www.bro.org/sphinx/scripts/policy/misc/scan.bro.html

Assegura't que l'script Bro /usr/share/bro/policy/misc/scan.bro es carrega des

de /etc/bro/site/local.bro.
cat /etc/bro/site/local.bro | grep scan
@load misc/scan
Posteriorment, llana Bro des de la lnia de comandes de la segent manera
perqu utilitzi lscript /etc/bro/site/local.bro.
sudo bro -i eth0 -C local

3.1.1 A continuaci llana un escaneig dels 20 ports ms comuns amb nmap

contra el sistema que corre Bro. Indica la comanda nmap utilitzada.

Previamente se ha debido preparar la orden bro, porque si no es capaz de

detectar la subred, se puede hacer de 2 formas:
bro -i eth0 C local Site::local_nets += {192.168.1.0/24,
172.17.0.0/16}

O bien aadiendo la subred, en el archivo local.bro, debajo de la orden

@load protocols/dns/detect-external-names
redef Site::local_nets = {192.168.1.0/24, 172.17.0.0/16};
(Nota: uso 2 subredes, la personal y la del trabajo)

Despus se lanza el script en la mquina que tiene instalado bro y se ejecuta

desde otro equipo, el escaneo de los 20 puertos ms comunes contra el sistema
que ejecuta bro, con la orden:
nmap top-ports 20 192.168.1.140
(Nota: Si se ejecuta nmap haca s misma, desde la propia mquina que
contiene bro no es capaz de obtener el fichero notice.log, pues no analiza su
propia ip, pues no llega a pasar por la interface. Tambin se podra capturar el
trfico de nmap a otro equipo de la red, si la tarjeta de red del equipo virtual
donde se ejecuta bro se configura en modo promiscuo)

3.1.2 Finalment, comprova els resultats de notice.log i afegeix-los com a part

de la resposta a l'exercici.

Destacar que al analizar el fichero log de notificaciones aparece, entre otros, el

siguiente mensaje Scan::Port_Scan192.168.1.128 scanned at least 15
unique ports of host 192.168.1.140, donde se aprecia la IP de origen que ha
intentado escanear un mnimo de 15 puertos del equipo que ejecuta bro

3.2 Detecci dincidents de seguretat mitjanant signatures

Bro tamb pot fer servir signatures per a detectar incidents de seguretat.
Referncies
https://www.bro.org/sphinx/quickstart/
https://www.bro.org/sphinx/frameworks/signatures.html

Hi ha tres formes despecificar els arxius que contenen signatures:

 Fent servir el flag -s quan sexecuta Bro des de la lnia de comandes, com per
exemple
sudo bro -i eth0 -C -s firmas.sig
Fent servir la directiva @load-sigs en un script Bro, com per exemple amb la
segent comanda amb la que es carrega lscript de Bro ubicat a
/etc/bro/site/local.bro.
sudo bro -i eth0 -C local
estenent la variable signature_files de Bro fent servir loperador +=.

3.2.1 Crea unes signatures per a detectar datagrames ICMP Echo Request i una
altra per a detectar els ICMP Timestamp Request.

Per a fer que es processin aquestes firmes, utilitza eines com hping3 i nmap per
generar el trnsit necessari.

Com a resposta a aquest apartat, inclou les signatures creades, les comandes
utilitzades i el contingut de l'arxiu signatures.log.

He ejecutado sudo bro -i eth0 -C -s firmas_icmp.sig

En el fichero de firmas, firmas_icmp.sig, he incluido las 2 firmas para detectar

los datagramas ICMP utilizando la cabecera header [0:1] que analiza el primer
byte a partir de la posicin 0 del datagrama.

Las rdenes que he ejecutado para hacer peticiones ICMP Timestamp Request:
nmap -sn 192.168.1.128
hping3 192.168.1.128 --icmp-ts

Las rdenes que he ejecutado para hacer peticiones ICMP Echo Request:
hping3 192.168.1.128 --icmp
nmap -PR 192.168.1.128

Nota: El fichero de firmas se llama firmas_icmp.sig y el de signatures lo he

renombrado a signatures_icmp.log para poder seguir trabajando, sin que sea
modificado posteriormente.

3.2.2 Crea una signatura per a detectar connexions al port TCP/80 de la teva
mquina Kali Linux. Per a aix, abans inicia el servidor Apache2 amb la segent
comanda:
/etc/init.d/apache2 start

Posteriorment, visita el servidor web Apache2 de la teva mquina Kali Linux

amb un navegador web o amb eines com wget, curl, telnet, netcat o fins i tot
nmap.

Com a resposta a aquest apartat, inclou la signatura creada, les comandes

utilitzades i el contingut de l'arxiu signatures.log obtingut desprs de la visita al
servidor web Apache2.

He ejecutado sudo bro -i eth0 -C -s firmas_tcp80.sig

Este es el contenido del fichero de firmas, firmas_tcp80.sig
ip-proto == tcp protocolo a analizar
dst-ip == 192.168.1.128 equipo a analizar
dst-port == 80 Puerto a analizar
payload /.*/ Contenido a analizar
event "Conexion TCP/80" Evento a realizar en caso de coincidencia con la
firma

Nota: En alguna prueba no se iniciaba el servidor apache2 debido a que le

faltaba asignar un nombre de servidor en el fichero /etc/apache2/apache2.conf.
Pe. ServerName localhost
Las rdenes que he ejecutado para hacer pruebas son:

Netcat 192.168.1.128 80 herramienta que abre puertos remotos (usada en

hacking)
telnet 192.168.1.128 80 herramienta para usar remotamente un host
nmap -A 192.168.1.128 herramienta de escaneo de equipos
wget 192.168.1.128 herramienta de descarga de contenidos web
curl 192.168.1.128 herramienta de transferencia archivos por URL
y desde el navegador Iceweasel 192.168.1.128

En el fichero signatures, signatures_tcp80.log se puede apreciar que

herramienta ha sido usada para conectarse al equipo.

Nota: El fichero de firmas se llama firmas_tcp80.sig y el de signatures lo he

renombrado a signatures_tcp80.log para poder seguir trabajando, sin que sea
modificado posteriormente.

3.2.3 Crea unes signatures per a detectar connexions al port TCP/80 de la teva
mquina Kali Linux que continguin la paraula root tant en la URL com al
payload de la petici HTTP. Per a aix, abans inicia el servidor Apache2 amb la
segent comanda:
/etc/init.d/apache2 start

Posteriorment, visita el servidor web Apache2 de la teva mquina Kali Linux

amb un navegador web o amb eines com wget, curl, telnet, netcat o fins i tot
amb daltres eines web com nikto.

Com a resposta a aquest apartat, inclou les signatures creades, les comandes
utilitzades i el contingut de l'arxiu signatures.log.

He ejecutado sudo bro -i eth0 -C -s firmas_root.sig

Este es el contenido del fichero de firmas, firmas_root.sig

ip-proto == tcp Protocolo a analizar
dst-ip == 192.168.1.128 Equipo a analizar
dst-port == 80 Puerto a analizar
payload /.* [Rr][Oo][Oo][Tt]/ Busca palabra root de forma case insensitive
en payload
http-request /.* [Rr][Oo][Oo][Tt]/ Busca palabra root de forma case
insensitive en URL
 event " Detectar root" Evento a realizar en caso de matching con la firma

Las rdenes que he ejecutado para hacer pruebas son:

nikto -h 192.168.1.128 herramienta que escanea servidores web

y desde el navegador Iceweasel http://192.168.1.128/index.html?peticion=rOoT
(para comprobar que detecta combinacin de maysculas y minsculas)

En el fichero signatures, signatures_root.log se puede apreciar las peticiones

que van en la propia URL, http-request, y las que transmiten los datos, payload,
como orden GET del protocolo HTTP

Nota: El fichero de firmas se llama firmas_root.sig y el de signatures lo he

renombrado a signatures_root.log para poder seguir trabajando, sin que sea
modificado posteriormente.

3.3 Anlisi d'un arxiu de captura de trfic amb malware

Bro tamb t la capacitat de processar arxius de captura de trfic pcap,
extreure arxius del trfic i corroborar si els arxius sn maliciosos contra una
base de dades, en aquest cas online.

Per a aquests apartats utilitzarem un arxiu pcap que cont malware, i que
podem descarregar de la segent URL.
http://malware-traffic-analysis.net/2016/03/14/2016-03-14-Rig-EK-
afterdtransrentcar.com.pcap

3.3.1 Extreu els arxius del pcap utilitzant Bro. Per aix es suggereixen dos
scripts:

lscript Bro que sinclou en el sistema a linstallar Bro i es troba a la segent

ubicaci
/usr/share/bro/policy/frameworks/files/extract-all-files.bro

lscript Bro de la segent URL a lapartat "Part 3: Extract All The Files".
https://www.bro.org/current/exercises/faf/index.html#part-3-extract-all-
thefiles

No obstant aix, en lloc d'utilitzar l'esdeveniment

event file_new(f: fa_file)

utilitza l'esdeveniment file_sniff ja que proporciona la informaci de metadata

event file_sniff(f: fa_file, meta: fa_metadata)

tal i com sindica al segent script

https://github.com/bro/bro/blob/2b1cd66f17194a30b90490965cbdffdd71c18c09/doc/httpmonito
r/file_extraction.bro

Com a resposta a aquest apartat, inclou les comandes utilitzades, els scripts
utilitzats, el llistat darxius extrets, els tipus d'arxius mitjanant l's de l'eina
file , i els hashes MD5 i SHA1.
Para hacer este ejercicio, lo primero que he hecho es extraer los archivos del
pcap pero usando el script hash-all-files.bro, para que aada en files.log el
hash del MD5 y del SHA1, tal como se explica en
https://www.bro.org/current/exercises/faf/index.html. El objetivo es comprobar
que coinciden con la comprobacin final que se hace de hashes. La orden es:
(Nota he hecho una copia de files.log con el nombre files_hash.log)

bro -r 2016-03-14-Rig-EK-after-dtransrentcar.com.pcap frameworks/files/hash-all-

files.bro

Despus he realizado la extraccin de ficheros con el script extract-all-files.bro

bro -r 2016-03-14-Rig-EK-after-dtransrentcar.com.pcap extract-all-files.bro y he

observado que ha extrado 4 ficheros en la carpeta extract-files:
extract-1457964470.81812-HTTP-FQaIef2WWa35bqB8R9
extract-1457964471.945205-HTTP-F7OeBh4UPZ0FFFJl7g
extract-1457964474.406903-HTTP-FDR5lD2W8BYmzZprSa
extract-1457964474.979204-HTTP-Fq8PFd2Y4tfPc9CPZd
(Nota: como no los puedo adjuntar en el informe por que el antivirus de mi
equipo no me los permite copiar, los he incluido todos comprimidos en
extract_files1.tar.gz )

Luego con la herramienta file, sha1sum y md5sum he mostrado el tipo de

archivo y los hashes de cada uno de ellos:

extract-1457964470.81812-HTTP-FQaIef2WWa35bqB8R9: HTML document,

ASCII text
sha1: 0eef1b7cc193b47ace73a3b7dc93871f4d3c8732
md5: 9d6c0a5b2902cd75717fd23e5924d20a

extract-1457964471.945205-HTTP-F7OeBh4UPZ0FFFJl7g: very short file (no

magic)
sha1: b858cb282617fb0956d960215c8e84d1ccf909c6
md5: 7215ee9c7d9dc229d2921a40e899ec5f
(Nota: por su corto tamao, no es capaz de determinar qu tipo de archivo
es)

extract-1457964474.406903-HTTP-FDR5lD2W8BYmzZprSa: HTML document,

ASCII text, with very long lines, with no line terminators
sha1: d1cdeb0cdb9eff8bdd80458983aec023b01f93dc
md5: 9e1a6fa0403e2655df93bcb295eec36d

extract-1457964474.979204-HTTP-Fq8PFd2Y4tfPc9CPZd: Macromedia Flash

data (compressed), version 13
sha1: a5e4171f0b7631f70bf1110c121d8bd60b214e16
md5: 8f651757d2e8e74c160a456dfcebf120

Los resultados coinciden con los del informe files_hash.log.

Por curiosidad, tambin he hecho una extraccin utilizando el otro script que se
recomendaba, lo he llamado extract-all.bro, siguiendo las indicaciones que se
aportaban, pero en un primer intento solo ha podido extraer 2 ficheros.
El motivo es que trabaja con tipos de archivo y al no estar referenciado el
archivo flash y al no poder identificar el otro, no los ha podido extraer.

Lo que he hecho es aadir la lnea, en el archivo, debajo de mime_to_ext:

["application/x-shockwave-flash"] = "swf", para poder identificar el archivo flash

Ahora s en un segundo intento, al ejecutar:

bro -r 2016-03-14-Rig-EK-after-dtransrentcar.com.pcap extract-all.bro

se han extrado los 3 ficheros pero con otro nombre:

HTTP-FDR5lD2W8BYmzZprSa.html
HTTP-Fq8PFd2Y4tfPc9CPZd.swf
HTTP-FQaIef2WWa35bqB8R9.html
Aqu no repito los hashes porque son los mismos archivos que antes pero
renombrados.

(Nota: como no los puedo adjuntar en el informe por que el antivirus de mi

equipo no me los permite copiar, los he incluido todos comprimidos en
extract_files2.tar.gz )

3.3.2 Carrega el segent script Bro que realitza cerques contra la base de
dades de Team Cymru mitjanant el hash SHA1 dels arxius que es transfereixen
a travs de la xarxa. Per aix, modifica larxiu /etc/bro/site/local.bro i fes servir la
directiva
" @load "./usr/share/bro/policy/frameworks/files/detect-MHR.bro

Referncies
http://www.team-cymru.org/MHR.html
https://www.bro.org/sphinx/scripts/policy/frameworks/files/detect-
MHR.bro.html

Copia larxiu Flash extret anteriorment del pcap al directori pblic

/var/www/html del servidor web Apache2 en Kali Linux.
Descarrega l'arxiu Flash SWF des d'un altre sistema en la teva xarxa mitjanant
wget, curl, telnet o netcat.

ATENCI! No utilitzis un navegador per descarregar l'arxiu ja que al

descarregar-lo el teu navegador, aquest ho executaria i podria infectar el teu
sistema.

Com a resposta a aquest apartat, inclou les comandes utilitzades, modificacions

als scripts i la lnia de l'arxiu notice.log creada quan es transfereix l'arxiu
malicis a travs de la xarxa.

Segons l'informe de virustotal.com d'aquest arxiu malicis, quin s el nom de

larxiu original que es va pujar a virustotal.com per al seu anlisi?
En este apartado, para trabajar de forma ms cmoda, he renombrado el
archivo HTTP-Fq8PFd2Y4tfPc9CPZd.swf por descarga.swf y lo he copiado en el
directorio html de apache2

A continuacin he iniciado el servidor apache2: /etc/init.d/apache2 start

He iniciado el script local desde una carpeta llamada analizar, con la orden:
bro -i eth0 C local Site::local_nets += {192.168.1.0/24, 172.17.0.0/16}
(Nota: no he tenido que hacer nada ya que la lnea @load
frameworks/files/detect-MHR ya estaba descomentada)

Desde otro equipo he realizado la descarga del archivo, con la orden:

curl 192.168.1.128/descarga.swf > infectada.swf
y he parado el script local.bro desde la mquina que tiene bro. El resultado en la
carpeta ha sido la creacin de los siguientes archivos:

En la lnea que detecta notice.log aparece el enlace de virustotal, informando

sobre el malware detectado

https://www.virustotal.com/en/search/?
query=a5e4171f0b7631f70bf1110c121d8bd60b214e16

En este link, sale un informe donde aparece que el nombre del archivo original
analizado es: HTTP-Fq8PFd2Y4tfPc9CPZd

pero el informe dice que se ha localizado tambin en los siguientes ficheros:

2016-03-14-Rig-EK-flash-exploit.swf.txt
4ebd11c7a4e36f910d48ff78bf40cd42dac7e7e1
2016-03-14-Rig-EK-flash-exploit.swf

Como curiosidad comentar que hasta la fecha es detectado como malware por
32 de los 56 antivirus que lo analizan (56%). Entre los que lo detectan destacan
Avast, Kaspersky, McAfee, Symantec y Microsoft, y entre los que no lo detectan
destacan Comodo, F-Prot, MalwareBytes y Panda

3.4 Eines auxiliars de Bro

Bro tamb inclou eines auxiliars per al tractament dels esdeveniments que Bro
genera. Una d'elles s bro-cut, que pot analitzar i parsejar els logs en format
text que Bro genera a l'executar-se en temps real o offline en processar un arxiu
pcap. Per utilitzar bro-cut, primer s'ha d'installar amb la segent comanda a
Kali Linux:
sudo apt-get install bro-aux

o tamb pots fer servir aptitude

sudo aptitude install bro-aux

Referncia
https://www.bro.org/sphinx-git/logs/index.html

Per a aquests apartats utilitzarem un arxiu pcap que cont malware, i que
podem descarregar de la segent URL.
http://malware-traffic-analysis.net/2016/03/11/2016-03-11-Angler-EK-
afterfixwindowsproblems.com.pcap

Abans d'utilitzar bro-cut hem de generar els logs en format text. Per a aix,
executa Bro
per a processar l'arxiu pcap de la segent forma.
bro -r 2016-03-11-Angler-EK-after-fixwindowsproblems.com.pcap

3.4.1 Utilitza bro-cut per a processar els arxius de logs i indica la data, adrea IP
d'origen, port d'origen, direcci IP de dest, port de dest i durada per a totes les
connexions TCP. Indica la comanda utilitzada i els resultats obtinguts com a
resposta a aquest apartat.

La orden usada es:

bro-cut -U %d-%m-%Y---%H:%M:%S ts id.orig_h id.orig_p id.resp_h id.resp_p
proto duration < conn.log | awk '$6=="tcp"' >solucion_tcp.log

Muestro fecha y hora separada por guiones y busco protocolo tcp en el fichero
conn.log, que nos da informacin sobre las conexiones que se han producido y
que protocolo se ha utilizado. El resultado lo creo en el fichero solucin_tcp.log

En otros ficheros log no tiene sentido analizar la informacin pues es este el que
nos aporta toda la informacin pedida. El fichero files.log aporta informacin
sobre ficheros que se usan en la conexin y http.log informa sobre las rdenes
que usa el protocolo http

3.4.2 Utilitza bro-cut per a processar els arxius de logs i indica la data, adrea IP
d'origen, port de dest, longitud de resposta (en bytes), nom del host dest i URI
per a totes les connexions HTTP amb una longitud de resposta major a 0 bytes.
Indica la comanda utilitzada i els resultats obtinguts com a resposta a aquest
apartat.

Aqu he usado varias rdenes, debido a que la informacin la he tenido que

buscar en 2 ficheros logs diferentes, la longitud de respuesta est en con.log y
el resto de informacin est en http.log, es por eso que he tenido que usar el
campo uid, comn a ambos ficheros, para despus unir la informacin de ambos
a travs de dicho campo.
Con la primera orden obtengo el uid y las longitudes de respuesta superiores a 0
del fichero con.log y lo guardo en el fichero file_conn.log, ordenando por su uid.

bro-cut uid resp_bytes < conn.log | awk '$2>0' | sort > file_conn.log

Con la segunda orden obtengo el uid y el resto de informacin, procurando

eliminar la informacin repetida y lo guardo en el fichero file_http.log,
ordenando por su uid.

bro-cut uid -U %d-%m-%Y ts id.orig_h id.resp_p host uri < http.log | sort | unique
file_http.log

Por ltimo uno los ficheros por su primer campo en comn, uid, y obtengo el
resultado final.

join file_conn.log file_http.log > solucion_http.log

El resultado lo creo en el fichero solucin_http.log

Nota: A pesar de unir por su UID, se pueden apreciar resultados con UID
repetidos, esto se debe a que hay filas que tienen el mismo UID pero diferente
URI en el fichero http.log