Lección 3: Montando un NIDS con Snort. Ejercicios Francisco Javier Cervigon Ruckauer

Lección 3: Montando un NIDS con Snort


Ejercicio: Preparar el entorno para el resto de actividades

En esta lección se utilizará snort como NIDS. Para ello, durante la práctica se usarán las máquinas exta, extf, fw, dmza e inta, cada una con el rol que se describe a continuación:
  • La máquina exta se usará como sonda de snort en todas las actividades. Aunque la configuración correcta de una sonda sería que tuviera dos interfaces de red, una sin IP para analizar el tráfico, y otra conectada a una red para detección de intrusos independiente de la(s) red(es) a monitorizar; la configuración que se propone es más sencilla y se considera adecuada para una primera toma de contacto con la herramienta.  Además, la ubicación de exta (antes del filtrado de paquetes que realiza fw) permitirá detectar todo lo que ocurra, y no solamente lo que llegue a las redes perimétrica e interna, donde en un caso real se instalarían sondas adicionales, conectadas entre sí y con la consola del analista a través de una red dedicada.
  • Los ataques se llevarán a cabo desde la máquina extf, que simulará una máquina maliciosa ubicada en cualquier parte de Internet.
  • fw realizará su papel habitual de encaminador y filtro de paquetes.
  • Como máquinas víctima se usarán inta (de la red interna) y dmza (de la red perimétrica, que también tiene el alias "www.example.net").

Se recomienda, además, restaurar la copia de seguridad inicial que viene con NETinVM ("uml_machines_2016-04-01_14-19_initial.tgz") para evitar que los cambios realizados en otras actividades del curso puedan interferir con el trabajo a realizar en esta lección.
Aviso
Al restaurar una copia de seguridad se elimina el estado actual de las UML. Por lo tanto, se recomienda realizar una copia de seguridad antes.
Acciones a realizar:
  1. Realizar, si no se ha hecho antes, una copia del estado actual y etiquetarlo adecuadamente renombrando el fichero resultante.
  2. Restaurar la copia de seguridad inicial.
  3. Editar el guión "uml_run_my_uml.sh" para que solamente se ejecuten las máquinas indicadas.
  4. Lanzar las máquinas UML usando el icono "Run my UMLs".
  5. Comprobar que efectivamente se han puesto en marcha las máquinas esperadas.

Ejercicio: Preparar el fichero de configuración

El fichero de configuración de snort contiene seis secciones básicas que pueden ser ajustadas en función de las necesidades corporativas:
  1. Definición de variables. Sección para establecer las variables de entorno apropiadas para reflejar la configuración de la red: HOME_NET, EXTERNAL_NET, HTTP_SERVERS...
  2. Configuración de bibliotecas dinámicas. Especificar qué bibliotecas dinámicas cargar durante la ejecución de snort.
  3. Configuración de preprocesadores. Establecer los preprocesadores (frag3, stream5, http_inspect, sfportscan...) que deben ejecutarse y ajustar su configuración.
  4. Configuración de los complementos de salida. Configurar qué complementos usar (syslog, mysql...) y su configuración.
  5. Configuración adicional de snort. Usar sentencias config (ignore_ports, flowbits_size...) para afinar el comportamiento de snort.
  6. Configuración del conjunto de reglas. Indicar qué conjuntos de reglas debe incluir snort.

Aunque posteriormente se realizarán ajustes adicionales, para comenzar a trabajar con snort será necesario realizar los siguientes ajustes:
  • Establecer las redes interna y externa: la red interna debe estar formada por las redes INT y DMZ, y todas las demás deben considerarse como externas.
  • Indicar en el fichero de configuración que se envíen las alertas a "syslog".
  • Cambiar la sensibilidad del módulo de detección (sfportscan): establecer la seguridad alta (high).

Acciones a realizar:
  1. En exta, como root, editar el fichero "/etc/snort/snort.conf" y realizar los ajustes recomendados.
  2. Guardar una copia del fichero de configuración por si fuera necesario. (Sugerencia: guardarlo como "/mnt/tmp/snort.conf", por si surgiera algún problema con exta).

Ejercicio: Generar y analizar las primeras alertas

El primer paso tras la configuración inicial consiste en poner en marcha snort y comprobar que efectivamente es capaz de detectar intentos de intrusión y que las alertas aparecen en el registro del sistema. (Si se ha usado el modelo que viene con el fichero de configuración para syslog en Unix, las alertas se generan con la facilidad auth, por lo que se irán almacenando en el fichero "/var/log/auth.log").
Para poner en marcha snort usando la configuración preparada en el ejercicio anterior, basta con ejecutar (como root en exta) la orden:
snort -c /etc/snort/snort.conf

Acción a realizar: poner en marcha snort en la máquina exta.
Una vez puesto en marcha snort, es necesario monitorizar el contenido del fichero de registro correspondiente. Para ello es suficiente con ejecutar, también como root, en otra terminal de exta la orden "tail -f /var/log/auth.log". (Esta orden muestra las últimas líneas del fichero y monitoriza los cambios en el mismo, mostrando las líneas que se van añadiendo).
Acción a realizar: comenzar a monitorizar el fichero "/var/log/auth.log".
Finalmente, para generar las primeras alertas es suficiente con realizar un barrido de puertos sobre exta. Para ello, en extf, como root, basta con ejecutar la orden "nmap exta".
Acción a realizar: realizar un barrido de puertos sobre exta desde extf.
Tras obtener las primeras alertas, el siguiente paso es comprender su significado y ser capaz de averiguar qué módulo o qué regla las ha generado, tal y como se ha visto en apartados anteriores.
Acciones a realizar:
  1. Para cada una de las reglas del apartado anterior, identificar el módulo que las ha generado. (Sugerencia: apoyarse en el fichero "/etc/snort/gen-msg.map").
  2. Para aquéllas generadas por una regla:
    • encontrar el fichero en el que está la regla (sugerencia: usar el SID)
    • identificar la línea del fichero en que está (sugerencia: usar el SID

Ejercicio: Comprender el módulo sfportscan

El preprocesador sfportscan permite detectar diferentes tipos de escaneos (portscan, portsweep...; ver http://manual.snort.org/node78.html). Para comprobar su funcionamiento y analizar las diferencias entre los diferentes tipos de ataques será necesario monitorizar el registro de mensajes. No obstante, para analizar exclusivamente las alertas correspondientes a sfportscan, se recomienda usar grep(una forma sería usar la orden "tail -f /var/log/auth.log | grep 'snort: \[122:'").
Acciones a realizar:
  1. Asegurarse de que snort está ejecutándose en exta.
  2. Comenzar a monitorizar el registro.

Una vez preparado el entorno, es el momento de realizar diferentes tipos de escaneos y revisar las alertas que generan. Para ello se usará la utilidad nmap con diferentes opciones.
Acciones a realizar:
  1. Averiguar, usando el manual, qué hacen las órdenes "nmap -sS 10.5.1.10" y "nmap -v -sV -p 80,443 10.5.1-2.1-10".
  2. En extf, como root, ejecutar la orden "nmap -sS 10.5.1.10" y anotar las alertas que genera.
  3. En extf, como root, ejecutar la orden "nmap -v -sV -p 80,443 10.5.1-2.1-10" y anotar las alertas que genera.
  4. Comparar las alertas generadas por las dos órdenes.

El módulo sfportscan permite ajustar el tipo de escaneos que detecta, así como las direcciones IP de las máquinas que deben ser tenidas en cuenta o ignoradas, ya sea como origen o como destino de los escaneos. Esta flexibilidad es necesaria para evitar falsos positivos (por ejemplo, porque se usen herramientas automáticas de comprobación), así que es conveniente saber ajustar la configuración adecuadamente.
Acciones a realizar:
  1. Modificar la configuración de sfportscan para que solamente se tengan en cuenta barridos de puertos sobre dmza y dmzb. (Nótese que es necesario reiniciar snorttras cambiar el fichero de configuración).
  2. En extf, como root, ejecutar la orden "nmap -PN -sS --host-timeout 1m10.5.2.1-15" y comprobar que no se producen alertas.
  3. En extf, como root, ejecutar la orden "nmap -PN -sS --host-timeout 1m 10.5.1.1-15" y comprobar que se generan alertas para dmza y dmzb.

Ejercicio: Entender las reglas de snort

Una vez realizado todo el preprocesamiento, snort analiza el tráfico aplicando las reglas indicadas en el fichero de configuración. Un aspecto importante del trabajo con snort consiste en comprender el lenguaje de descripción de reglas. Para ello se va a realizar un ataque sencillo al servidor web de NETinVM (www.example.net, que es un alias de dmza, con IP 10.5.1.10). El objetivo de este apartado es comprender las reglas detectan este tipo de ataque. Para ello será necesario, como ya se ha realizado en el ejercicio "Generar y analizar las primeras alertas", analizar la alerta y localizar la regla que la ha generado.
Para el análisis de las reglas, se recomienda consultar el manual de snort, en concreto la sección sobre escritura de reglas de snort: http://manual.snort.org/node27.html.
Acciones a realizar:
  1. Monitorizar el registro de mensajes. (Asegurarse de estar revisando una versión completa del fichero de registro, y no la versión filtrada con grep del ejercicio anterior).
  2. En extf, ejecutar la orden "wget www.example.net/../../../etc/passwd".
  3. A partir de las alertas generadas, identificar las reglas que las han generado.
  4. Analizar cada una de las reglas asegurándose de comprender todas las opciones.

Ejercicio: Crear una regla de snort para detectar ataques SHELLSHOCK

La vulnerabilidad SHELLSHOCK (CVE-2014-6271, CVE-2014-7169) fue descubierta en 2014 y tuvo un gran impacto mediático porque permite, por ejemplo, ejecutar código en servidores web que usen el intérprete de órdenes (shell) para ejecutar directamente CGIs o, indirectamente, en otros lenguajes como PHP mediante la función system().
Buscando esta vulnerabilidad en SecurityFocus se puede obtener el exploit en Python: "70137.py". Se puede comprobar que "www.example.net" no es vulnerable descargando el exploit desde SecurityFocus (buscar el CVE-2014-7169 y seleccionar la pestaña "exploit") y ejecutándolo en extf y, al mismo tiempo, observar que las reglas instaladas en exta para snort no detectan el intento de ataque. No obstante, puesto que se desea ser capaz de detectar dicho ataque, se pide crear una regla para snort que lo detecte.
Nota: los conjuntos de reglas actualizados sí detectan este tipo de ataque.
La vulnerabilidad consiste en que el intérprete de órdenes evalúa las órdenes incluidas en la declaración de una variable de entorno cuando la variable contiene una declaración de función. Por ejemplo:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

El comportamiento esperado es que se cree una variable de entorno x con el contenido '>() { :;}; echo vulnerable'. Por lo tanto, un sistema que no sea vulnerable simplemente imprimirá "this is a test". En cambio, un sistema vulnerable evaluaría la orden "echo vulnerable" y, por tanto, la palabra "vulnerable" aparecerá en la salida.
Por tanto, la regla de snort debe incluir:
  • alertar solamente cuando se contacte con un servidor web (HTTP_SERVERS) en un puerto web (HTTP_PORTS)
  • un mensaje adecuado
  • exigir flujo de cliente a servidor en una conexión establecida
  • encajar con la cadena "() {"
  • referencias a CVE-2014-6271, CVE-2014-7169
  • clasificar la alerta como "attempted-admin"
  • un identificador único mayor o igual que 1.000.000, pues es una regla definida localmente

La regla debe añadirse al fichero "/etc/snort/rules/local.rules".
Acciones a realizar:
  1. Monitorizar el registro de mensajes ("tail -f /var/log/auth.log").
  2. Ejecutar el exploit en extf:
    python 70137.py -s -t http://www.example.net
  3. Comprobar que "www.example.net" no es vulnerable.
  4. Comprobar que snort no lo detecta.
  5. Añadir una regla adecuada para detectar SHELLSHOCK en "/etc/snort/rules/local.rules".
  6. Reiniciar snort.
  7. Ejecutar de nuevo el exploit en extf.
  8. Comprobar que snort lo detecta.
Francisco Javier Cervigon Ruckauer
Etiquetas:

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)