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: http://snorby.org/ Podemos encontrar información de instalación en las siguientes páginas https://github.com/Snorby/snorby/wiki https://github.com/Snorby/snorby/wiki/Insta-Snorby-0.8.0-Install-Notes- %28Revised%29%3A Creamos una nueva máquina virtual con la siguiente configuración:

LaboratorioFinal - IDS Snorby y Firewall PIX

Embed Size (px)

Citation preview

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:

http://snorby.org/

Podemos encontrar información de instalación en las siguientes páginas https://github.com/Snorby/snorby/wiki https://github.com/Snorby/snorby/wiki/Insta-Snorby-0.8.0-Install-Notes-%28Revised%29%3A

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

Seleccionamos la imagen ISO de Snorby

Nota: se puede dejar ubuntu

Aumentamos la memoria RAM de la máquina virtual

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 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.

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 y así poder analizarlo.

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 [email protected]/snorby y cambiamos la cuenta http://192.168.116.131/users/login

Cambiamos la contraseña e email de nuestro usuario administrador

Podemos añadir usuarios

Cambiamos el nombre del sensor

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 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 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”.

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

Clasificamos como ataque Web

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

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 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

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

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;