Вы находитесь на странице: 1из 33

Este laboratorio estará dividido en dos apartados:

A. Instalación, configuración y pruebas sobre un IDS Snort con Front-end Snorby

1. Instalación, configuración y pruebas sobre un IDS Snort con Front-end Snorby

Snorby es un front-end para la gestión de alertas de Snort basado en sensores. No se puede utilizar Snorby para la gestión de sensores remotos y configuración de alertas y reglas, pero su interface gráfica es muy sencilla con una visión amplia e intuitiva de la visualización de las alertas.

Instalaremos el IDS en formato Snorby Virtual Appliance

Podemos descargarlo en:

Virtual Appliance Podemos descargarlo en: http://snorby.org/ Podemos encontrar información de instalación en las

Podemos encontrar información de instalación en las siguientes páginas

Creamos una nueva máquina virtual con la siguiente configuración:

Seleccionamos la imagen ISO de Snorby
Seleccionamos la imagen ISO de Snorby

Seleccionamos la imagen ISO de Snorby

Nota: se puede dejar ubuntu
Nota: se puede dejar ubuntu

Nota: se puede dejar ubuntu

Aumentamos la memoria RAM de la máquina virtual Si tuviéramos dos interfaces, uno con port

Aumentamos la memoria RAM de la máquina virtual

Aumentamos la memoria RAM de la máquina virtual Si tuviéramos dos interfaces, uno con port mirroring

Si tuviéramos dos interfaces, uno con port mirroring y otro para administración, añadiríamos otro “network Adapter”. Configuramos el adaptador de la máquina virtual a NAT.

Si dispusiéramos de un Oinkcode para la actualización de reglas se introduciría en la siguiente

Si dispusiéramos de un Oinkcode para la actualización de reglas se introduciría en la siguiente opción. El Oinkcode se obtiene registrándose en http://www.snort.org. Esta fase se puede saltar ya que no vamos a actualizar el Snort.

fase se puede saltar ya que no vamos a actualizar el Snort. El mismo interfaz de

El mismo interfaz de administración se utilizará como interfaz de monitorización, por lo que los ataques se realizarán a esa IP.

Se habilita OpenFPC para poder capturar tráfico que indicamos en caso de detectar un ataque

Se habilita OpenFPC para poder capturar tráfico que indicamos en caso de detectar un ataque y así poder analizarlo.

Se habilita OpenFPC para poder capturar tráfico que indicamos en caso de detectar un ataque y
Utilizamos la cuenta de root que hemos configurado para acceder a la máquina virtual, directamente
Utilizamos la cuenta de root que hemos configurado para acceder a la máquina virtual, directamente

Utilizamos la cuenta de root que hemos configurado para acceder a la máquina virtual, directamente en VMWARE o por SSH a la IP que hemos configurado.

Accedemos al interfaz gráfico Web, con el usuario por defecto snorby@snorby.org/snorby y cambiamos la cuenta

Accedemos al interfaz gráfico Web, con el usuario por defecto snorby@snorby.org/snorby y cambiamos la cuenta

Cambiamos la contraseña e email de nuestro usuario administrador
Cambiamos la contraseña e email de nuestro usuario administrador

Cambiamos la contraseña e email de nuestro usuario administrador

Podemos añadir usuarios
Podemos añadir usuarios

Podemos añadir usuarios

Cambiamos el nombre del sensor Desde la máquina virtual de Snorby, podemos configurar las reglas
Cambiamos el nombre del sensor Desde la máquina virtual de Snorby, podemos configurar las reglas

Cambiamos el nombre del sensor

Cambiamos el nombre del sensor Desde la máquina virtual de Snorby, podemos configurar las reglas de

Desde la máquina virtual de Snorby, podemos configurar las reglas de Snort

#nano /etc/snort/snort.conf

Habilitaremos todas las reglas (rules) eliminado las # de cada regla Paramos el servicio de

Habilitaremos todas las reglas (rules) eliminado las # de cada regla

todas las reglas (rules) eliminado las # de cada regla Paramos el servicio de Snort y

Paramos el servicio de Snort y lo volvemos a arrancar.

Cualquier cambio en snort.conf debe ir precedido de un reinicio del servicio, antes un stop, etc:

/etc/init.d/snort restart / stop / start

Realizamos ataques contra la IP del Snorby (en nuestro caso no tenemos un puerto de

Realizamos ataques contra la IP del Snorby (en nuestro caso no tenemos un puerto de SPAN), por ejemplo escaneos con distintos tipos con Nmap y Nessus, fuerza bruta al SSH con Hydra, etc…

En Snorby los eventos que se detectan se deben clasificar por un operador. Vamos a añadir a los que están por defecto uno para “Ataques Web”.

se detectan se deben clasificar por un operador. Vamos a añadir a los que están por
Ej: Inyección XSS Desde un cmd de Windows (considerando 192.168.116.131 la IP que hayamos asignado
Ej: Inyección XSS Desde un cmd de Windows (considerando 192.168.116.131 la IP que hayamos asignado
Ej: Inyección XSS Desde un cmd de Windows (considerando 192.168.116.131 la IP que hayamos asignado

Ej: Inyección XSS

Desde un cmd de Windows (considerando 192.168.116.131 la IP que hayamos asignado al interfaz de Snorby)

telnet 192.168.116.131 80 GET /?id=<script>alert(SXX)</script> HTTP/1.0

Después de un tiempo veremos

telnet 192.168.116.131 80 GET /?id=<script>alert(SXX)</script> HTTP/1.0 Después de un tiempo veremos
telnet 192.168.116.131 80 GET /?id=<script>alert(SXX)</script> HTTP/1.0 Después de un tiempo veremos
Clasificamos como ataque Web

Clasificamos como ataque Web

Clasificamos como ataque Web
En el Dashboard ya nos aparecería el evento con la clasificación que hemos hecho Se

En el Dashboard ya nos aparecería el evento con la clasificación que hemos hecho

aparecería el evento con la clasificación que hemos hecho Se podría capturar el tráfico para después

Se podría capturar el tráfico para después analizar el posible ataque

El archivo pcap se puede abrir por ejemplo con Wireshark Realizamos otro ataque haciendo una

El archivo pcap se puede abrir por ejemplo con Wireshark

Realizamos otro ataque haciendo una petición con un método HTTP que no existe, como Head (en realidad es HEAD).

telnet 192.168.116.131 80 Head / HTTP/1.0

Veríamos en el dashboard

HTTP que no existe, como Head (en realidad es HEAD). telnet 192.168.116.131 80 Head / HTTP/1.0

Realizamos un SQL Injection y realizamos los mismos pasos que para el XSS

telnet 192.168.116.131 80 GET /?id=’ and 1=1-- HTTP/1.0

telnet 192.168.116.131 80 GET /?id=’ and 1=2-- HTTP/1.0

telnet 192.168.116.131 80 GET /?id=’ or ‘1’=’1 HTTP/1.0

O cualquiera de los siguientes:

GET /?id=order by 1-- HTTP/1.0 GET /?id=’ group by 1-- HTTP/1.0 GET /?id=’ union all select 1,2,3,4,5-- HTTP/1.0 GET /?id=’ having 1=1-- HTTP/1.0

¿Snort detecta el ataque según está configurado?

La siguiente regla se podría introducir en /etc/snort/rules/web-misc.rules para que detectará intentos de Blind SQL. Para los otros casos sería similar

alert tcp any any -> $HOME_NET $PORT_HTTP (msg: "SQL Injection Attempt - and 1=1"; content: "GET"; http_method; uricontent: "and 1=1"; nocase;classtype:web- application-attack; sid:3000001; rev:1;)

Realizamos un ataque de Inyección de cabeceras

telnet 192.168.116.131 80 GET /?id=%0D%0ASet-Cookie=SSII HTTP/1.0

¿Snort detecta el ataque según está configurado?

Realizamos un ataque de Path Transversal

telnet 192.168.116.131 80

GET /?file=

/

/

/

/

/

/

/

/ /etc/shadow

HTTP/1.0

¿Snort detecta el ataque según está configurado?

Podemos exportar los datos en un PDF

Podemos exportar los datos en un PDF
Podemos exportar los datos en un PDF

Snorby captura los paquetes pero actualiza cada cierto tiempo. En el Dashboard veréis una línea: Last Updated con fecha y hora de última actualización.

El Dashboard se actualiza cada 30 minutos sin posibilidad de ser configurado. Esto es así para un correcto almacenaje en caché. Podemos comprobar que los datos se están guardando en la base de datos MySQL de una forma muy simple, por ejemplo:

La contraseña de la Base de Datos es mysqlUNAN

1. # mysql -u root -p

2. show databases;

3. use snorby;

4. show tables;

5. select * from event;

Base de Datos es mysqlUNAN 1. # mysql -u root -p 2. show databases; 3. use