Como el anterior, la lección 1 realiza una introducción teórica, en este caso a la detección de intrusiones, y las lecciones 2 y 3 incluyen sendos ejercicios prácticos.
La lección 2 se centra los sistemas de detección de intrusos basados en el nodo (HIDS) y se toma como caso de ejemplo el sistema OSSEC. El objetivo de la práctica es realizar una instalación realista (aunque simplificada) de OSSEC y comprobar cómo funcionan algunos de sus elementos principales. Para ello, la lección incluye un vídeo explicativo del ejercicio y, en las demás unidades, instrucciones paso a paso del proceso.
La lección 3 aborda los sistemas de detección de intrusos basados en red (NIDS) y usa Snort como ejemplo. Tras el vídeo introductorio, el resto de las unidades guían al estudiante para configurar una sonda con Snort y, poco a poco, llegar a crear una nueva regla que detecte ataques que usen la vulnerabilidad SHELLSHOCK.
Los IDS de red, NIDS, monitorizan la actividad de las redes a las que están conectados. Los NIDS analizan tanto las cabeceras como el contenido de los paquetes, buscando tanto anomalías como firmas.
En el caso de las firmas, buscan patrones que identifican intentos de intrusión. Por ejemplo, pueden buscar la cadena "../../etc/passwd" en conexiones HTTP y así detectar un intento de acceso a información sensible del servidor (un típico ataque de path traversal).
Por otra parte, la búsqueda de anomalías supone tanto la realización de un análisis general, muchas veces estadístico, del tráfico de red, como un análisis a nivel de protocolo.
Análisis de tráfico de red. Se detectan los intentos de intrusión por cambios en el patrón de tráfico de red. Por ejemplo, una máquina que intenta conectarse a otra con la que habitualmente no intercambia información, una máquina que genera mucho más tráfico del habitual...
Análisis de protocolos. Se detectan desviaciones respecto al protocolo esperado. Una posibilidad es el envío de órdenes mal formadas o con un formato rebuscado con la intención de causar un comportamiento no esperado en el otro extremo (servidor o cliente). Otra posibilidad es hacer pasar un tipo de tráfico por otro, para tratar de aprovechar los tipos permitidos en cortafuegos. Por ejemplo, establecer una conexión SSH saliente para controlar remotamente una máquina usando el puerto 80 como destino, aprovechando que suele estar permitido en muchos casos.
El NIDS más conocido y utilizado es Snort, que es que se utiliza para los ejercicios prácticos; aunque más recientemente también está adquiriendo fuerza Suricata.
Estructura de los NIDS
Aunque sería perfectamente posible utilizar un único nodo como NIDS, esta solución tendría múltiples limitaciones, entre las que se pueden destacar las siguientes:
Falta de escalabilidad. Debido a que un NIDS debe analizar todo el tráfico de las redes que protege, es necesario que su capacidad de análisis pueda crecer al mismo ritmo que la capacidad de dichas redes, algo que no ocurre si se utiliza un único nodo.
Punto único de fallo. En caso de mal funcionamiento del único nodo, se pierde toda la capacidad de detección de intrusiones. No hace falta que sea necesariamente debido a un ataque, basta con un problema de hardware o un bug en el software.
Por estos motivos, es habitual utilizar una estructura distribuida como la que se muestra en la figura.
Como puede observarse, hay varios elementos que forman parte de la estructura de NIDS: las sondas, la consola del analista y la red de gestión del NIDS.
Las sondas son máquinas cuya finalidad es capturar y analizar el tráfico de una red (o de un conjunto de ellas, aunque en la figura se ha usado una sonda por red). La propuesta incluye en cada sonda dos interfaces de red, una conectada a la red a monitorizar, que se utiliza para poder monitorizar el tráfico, y la otra a la red de gestión del NIDS, que se utiliza para enviar alertas y para permitir la gestión de las sondas.
La consola del analista es la máquina que recibe las alertas de las diferentes sondas, las almacena y permite su análisis por la persona responsable. En realidad, dependiendo de la infraestructura, es habitual que se separen en máquinas diferentes, por una parte, la recepción y almacenamiento de las alertas y, por otra, la aplicación (habitualmente gráfica) que permite la explotación y análisis de los datos.
La red de gestión del NIDS es una red dedicada que conecta entre sí las sondas y la consola del analista.
Una estructura como la propuesta presenta numerosas ventajas respecto a un único nodo, tal y como se discute a continuación.
Con esta configuración, la interfaz de la sonda conectada a la red supervisada no necesita estar configurada, es decir, no necesita tener asignada una red IP. Esto dificulta la detección de la sonda, pues no participa en los protocolos de red y, precisamente por ello, también dificulta la realización de ataques dirigidos a la propia sonda.
Al utilizar una red separada, se evita que las sondas analicen el tráfico generado por otras sondas. Esto reduce la carga sobre ellas y, además, elimina los falsos positivos que podría causar este tipo de tráfico.
La red dedicada también dificulta a los atacantes la obtención y/o manipulación de los datos del NIDS.
La utilización de múltiples sondas aumenta la escalabilidad del sistema, pues cada una solamente debe analizar una parte del tráfico total.
Las diferentes sondas pueden ser configuradas y ajustadas al tráfico esperado en las redes que supervisan, reduciendo así tanto los falsos positivos como los falsos negativos.
Uno de los riesgos principales de cualquier mecanismo de seguridad, y los NIDS no son una excepción, es que se produzca una falsa sensación de seguridad. Para evitar el posible exceso de confianza es conveniente tener en cuenta las siguientes limitaciones, inherentes a los NIDS.
No todo es observable
Aunque dependiendo de los sistemas usados y de su configuración es posible tener mayor o menor confianza en el sistema, hay que tener en cuenta que exiten diferentes causas por las que el NIDS puede no estar observando todo lo que ocurre:
Pueden ocurrir eventos en redes no monitorizadas. Existen varios motivos por los que se puede decidir no monitorizar ciertos segmentos de red: económicos, limitación de personal para analizar los incidentes, redes a las que no se tiene permitido ese tipo de acceso... Lo importante es tener en cuenta este hecho y revisar dichas decisiones cuando sea necesario.
El NIDS puede dejar de estar operativo. Tanto por problemas software como hardware, por causa accidental o provocada, puede haber parte del NIDS que deje de funcionar total o parcialmente. El hecho de usar múltiples sondas permite cierta tolerancia a fallos, especialmente si se combinan varios tipos de IDS y se utiliza el principio de seguridad en profundidad.
Las sondas pueden descartar paquetes. Cuando el tráfico excede la capacidad de procesamiento de una sonda, ésta pierde efectividad y comenzará a producir falsos negativos.
No todo es analizable
Aún con un NIDS plenamente funcional, es necesario analizar las alertas. Lógicamente, cuanto mejor configurado y ajustado el NIDS, menor será el número de falsos positivos. También será posible activar medidas de respuesta activa automáticas para ciertos casos. Pero, finalmente, el problema no desaparece completamente, y puede llegar un momento en que las alertas se produzcan y no puedan ser analizadas a tiempo por falta de disponibilidad de personal cualificado.
Los atacantes utilizan técnicas de evasión
Como con otros mecanismos de seguridad, los atacantes serán los primeros en estudiar y comprender los NIDS, especialmente los más utilizados.
Algunas de las técnicas más habituales se basan en dividir el tráfico en diferentes paquetes y éstos en fragmentos IP, de forma que el NIDS, si trabaja paquete a paquete o fragmento a fragmento, no es capaz de identificar correctamente los patrones (porque el patrón está separado en partes, cada una en un paquete o fragmento diferente). Para evitarlo, los NIDS deben reensamblar los fragmentos y reconstruir el flujo de datos, de forma que la búsqueda de patrones no sea vulnerable a los ataques anteriores.
Un problema adicional es que no todos los sistemas reensamblan ciertos fragmentos y paquetes de la misma forma, por ejemplo, por ambiguedades en el estándar. Los atacantes usarán este hecho para separar la información tratando de conseguir que el NIDS reensamble de forma diferente al objetivo, de forma que el NIDS no detecte el patrón que sí procesará el destino final del tráfico. Por eso, los NIDS actuales permiten ajustar la forma de reensamblado en base al tipo de sistema al que va dirigido el tráfico (target-based).
Otra técnica habitual consiste en utilizar una codificación evasiva para evitar la detección. Por ejemplo, usando "%2e%2e%2f%2e%2e" en vez de "../..", para evitar que la cadena sea identificada por el NIDS como un intento de pathtraversal. Para evitarlo, los NIDS deben normalizar las cadenas antes de buscar los patrones. Además, la normalización debe hacerse de la misma forma que lo hará el destino (nuevamente target-based) para que sea realmente efectiva.
Los IDS de nodo, HIDS, monitorizan la actividad del sistema al que tratan de proteger. Son aplicaciones instaladas en cada uno de los nodos que desean proteger. Pueden estar ejecutándose continuamente en segundo plano, ejecutarse periódicamente, o bajo demanda.
La monitorización supone una o varias tareas complementarias: detectar cambios en el sistema de ficheros, análisis de registros y detección de rootkits y software malicioso en general.
Detección de cambios en sistemas de ficheros
La detección de cambios en el sistema de ficheros sigue un proceso con los siguientes pasos:
Creación de la base de datos de referencia. Durante la instalación o configuración inicial se crea una base de datos que recoge una instantánea del sistema de ficheros en la que se incluye el listado de ficheros y directorios, información sobre sus atributos (permisos, tamaño, fechas de acceso, modificación y cambio...), y uno o varios resúmenes criptográficos (hashes) de su contenido.
Detección de cambios. Se recorre de nuevo el sistema de ficheros y se compara la situación en ese momento con lo almacenado en la base de datos, generando un informe que recoje todos los cambios detectados. Nótese que este mecanismo no crea una traza de actividades, por lo que un fichero que es creado depués de crear la base de datos de referencia y borrado antes de la detección de cambios no aparecerá en el informe. No obstante, tanto la creación como la eliminación de objetos en un directorio supone la modificación de dicho directorio, y esta modificación sí aparecerá reflejada.
Actualización de la base de datos de referencia. Es un proceso en el que se crea una nueva base de datos de referencia y se compara con la anterior, generando un informe con todas las diferencias entre ellas. Los cambios deben ser revisados cuidadosamente y, una vez confirmado que son todos lícitos se procede a usar como referencia la nueva base de datos. La finalidad de este proceso es dar por buenos ciertos cambios realizados intencionadamente. Un buen ejemplo sería la actualización del sistema tras realizar cambios en la configuración o haber instalado actualizaciones de seguridad. Si no se actualiza la base de datos de referencia, en cada informe aparecerán todos estos cambios una y otra vez, con el peligro de que los cambios que indican actividad maliciosa pasen desapercibidos. Lógicamente, el punto crítico de la actualización es la comprobación de los cambios antes de dar por buena la nueva base de datos de referencia.
Un buen ejemplo de herramientas especializadas en la detección de cambios en el sistema de ficheros son Aide y Tripwire.
Análisis de registros
El análisis de registros consiste en el procesamiento automático de los registros del sistema y de las aplicaciones, descartando los mensajes inocuos y alertando de aquellas entradas relevantes para la seguridad.
Los registros del sistema suelen incluir actividad propia del sistema operativo, como conexiones y desconexiones de usuarios, cambios de usuario, ejecución de programas, arranque y parada de la máquina... Pero también suelen aglutinar mensajes de otros componentes como filtrado de paquetes, sistemas de ficheros distribuidos como NFS, servicios de acceso remoto como SSH... Por todo ello, es posible detectar actividades significativas para la seguridad de los sistemas como las siguientes: conexión (local o remota) del administrador, de la conexión de un usuario usando la consola del sistema (indica acceso físico, y puede ser significativo en el caso de servidores en un centro de datos, o cuando no es el usuario habitual de un ordenador portátil o de sobremesa), de la instalación de paquetes, de conexiones de red desde otros sistemas o hacia otros sistemas y, por supuesto, de intentos fallidos de todo lo anterior.
Aunque muchas aplicaciones envían su información al registro del sistema, otras generan y mantienen sus propios registros. Un ejemplo sería el servidor web Apache, que genera sus propios registros. En este caso la información lógicamente es específica de la aplicación, incluyendo, en el caso de un servidor web, información sobre páginas descargadas y errores al descargar. El HIDS puede estar diseñado para procesar este tipo de información (aplicación por aplicación) y, por tanto, ser capaz de alertar cuando se producen muchos intentos fallidos desde la misma IP o cuando se solicitan páginas que pueden indicar intentos de intrusión (por ejemplo, que intenten obtener acceso al fichero con la tabla de usuarios del sistema, "/etc/passwd").
Detección de rootkits
Los HIDS pueden incluir la capacidad de detectar las huellas que quedan tras un ataque con éxito. Habitualmente, el atacante trata de ocultar estas huellas y, al mismo tiempo, mantener su capacidad de acceso a la máquina. Para ello, lo habitual es que modifique el sistema realizando algunas de las siguientes acciones:
Eliminar las entradas sospechosas de los registros del sistema, para dificultar la detección.
Instalar versiones modificadas de ciertas herramientas del sistema, en particular las que listan componentes como procesos, conexiones de red, o ficheros y directorios. De esta forma, al inspeccionar el sistema no aparecerían elementos sospechosos, ya que estas versiones modificadas suelen ocultar solamente la actividad del atacante, por lo que los listados parecen correctos.
Instalar algún tipo de puerta trasera que permita el acceso al sistema independientemente de su configuración. Por ejemplo, un servidor SSH que acepte el acceso como administrador usando una determinada contraseña establecida por el atacante (independientemente de la contraseña real del administrador del sistema).
Modificar el núcleo del sistema operativo, normalmente añadiendo módulos que modifican el comportamiento de ciertas llamadas al sistema para ocultar la presencia del intruso. En este caso no es necesario modificar las herramientas del sistema, ya que éstas obtienen su información del núcleo del sistema.
Estos kits que ocultan las huellas y permiten mantener el acceso al sistema se denominan genéricamente rootkits. Lógicamente, la capacidad de detección dependerá del tipo de rootkit, ya que una vez modificado el núcleo del sistema operativo sería necesario arrancar de un sistema no infectado como, por ejemplo, un CD-ROM o un disco externo que tengan un sistema operativo de confianza.
Concepto de sistema de detección de intrusos (IDS)
Los sistemas de detección de intrusos (IDS, Intrusion Detection Systems) son las herramientas informáticas que se encargan de llevar a cabo la detección de intrusiones. Para ello, estas herramientas monitorizan el comportamiento de los sistemas a proteger y se activa en caso de actividad sospechosa. Todos los IDS son capaces de generar alertas ante una posible intrusión y, en muchos casos, también son capaces de responder automáticamente de forma activa (respuesta activa), cambiando la configuración el sistema. Por ejemplo, cambiando las reglas de filtrado para impedir el acceso desde ciertas direcciones IP.
Otro tipo de sistemas relacionados son los sistemas de prevención de intrusiones(IPS, Intrusion Prevention Systems). Estos sistemas se caracterizan por ser capaz de evitar que el ataque llegue a producirse (por eso se habla de prevención). Para ello deben estar integrados en el camino de acceso del posible intruso. Por ejemplo, hablando de redes, sería necesario que fuera parte del encaminador y/o del sistema de filtrado de paquetes, de forma que pueda impedir incluso ataques que puedan realizarse mediante un único paquete. En cambio, un IDS con respuesta activa deja abierta una ventana de tiempo en que el ataque puede tener éxito (aunque sea detectado) si es suficientemente rápido. Esta ventana se extiende desde el momento en que se inicia el ataque hasta que la respuesta (por ejemplo, cambio de las reglas de filtrado) es efectiva.
Algunos IDS pueden funcionar como IPS, pero es conveniente tener presente que el enfoque es diferente, aunque complementario. Efectivamente, un IPS, al estar en el camino crítico del acceso al sistema debe ser especialmente rápido, mientras que los IDS habitualmente usan sistemas dedicados fuera de este camino crítico y, por tanto, pueden realizar análisis más complejos.
¿Qué buscan los IDS?
Los IDS, aunque se pueden apoyar en tecnologías muy diferentes, se basan en dos enfoques complementarios: la búsqueda de anomalías y la búsqueda de patrones.
En el primer caso, la búsqueda de anomalías, el IDS parte de un comportamiento esperado y detecta desviaciones con respecto a dicho comportamiento. Por ejemplo, una máquina que repentinamente comienza a usar el procesador con mucha más intensidad de lo habitual, u otra que de pronto se conecta a máquinas a las que habitualmente no accede... El comportamiento esperado puede ser determinado mediante ficheros de configuración en los que el administrador establece algunos parámetros predeterminados o puede ser obtenido automáticamente por el IDS en una fase previa de aprendizaje, en el que "observa" el comportamiento "normal" del sistema. Evidentemente, en este segundo caso es imprescindible asegurarse de que el sistema está libre de intrusos durante el aprendizaje.
En el segundo, la búsqueda de patrones, el IDS incluye una serie de reglas que permiten detectar ataques conocidos. Por ejemplo, por la existencia de determinados ficheros, paquetes de red con cierto contenido... En este caso será necesario una actualización frecuente de las reglas para ir añadiendo los nuevos tipos de ataque a medida que se descubren, se analizan y se aprende cómo detectarlos.
¿Cuáles son las limitaciones principales?
Las limitaciones principales de los IDS son las siguientes:
Falsos positivos. Los IDS son propensos a generar alertas que no están relacionadas con intentos de intrusión. Si se buscan anomalías, es posible que un cambio en la carga de trabajo (por ejemplo, acercarse a la finalización de un proyecto o comenzar uno nuevo) genere una alarma. Igualmente, si se buscan patrones, es posible que se encuentren las firmas en ficheros o paquetes de red legítimos, especialmente cuando se trata de hacer las firmas lo más específicas posibles. Además, si se activa la respuesta automática, estos falsos positivos pueden generar la interrupción del servicio a usuarios legítimos. De hecho, una posible vía de ataque de denegación de servicio consiste en hacer saltar la respuesta automática falsificando la IP de origen.
Falsos negativos. Otra limitación importante de los IDS es que pueden dejar de detectar intentos reales de intrusión, especialmente si se llega demasiado lejos a la hora de tratar de evitar los falsos positivos. Además, los atacantes tratarán de camuflar su actividad como legítima, tratando de seguir los patrones habituales de comportamiento de los usuarios autorizados.
Técnicas de evasión de IDS. Los atacantes dedican tiempo a comprender el funcionamiento de los diferentes IDS y desarrollan técnicas para evitar que su actividad sea detectada. Por ejemplo, tratarán de ocultar los ficheros que creen en directorios con actividad frecuente, como un directorio temporal, utilizando nombres similares a ficheros habituales. O tratarán de dividir el tráfico de red en paquetes separados o fragmentos, de forma que al IDS le resulte difícil localizar un cierto patrón. Lógicamente, éste es un proceso continuo, en el que los IDS se refinan y, a su vez, también lo hacen las técnicas de evasión.
Seguridad del IDS. Otra limitación inherente a todos los IDS es que, a su vez, pueden ser atacados. Un IDS comprometido no solamente no será efectivo, sino que, peor aún, generará una sensación de falsa seguridad, ya que la ausencia de alertas se interpretará como que no se están produciendo intentos de intrusión.
Tipos de IDS
Los dos principales tipos de IDS son los de nodo (HIDS, Host-based IDS) y los de red (NIDS, Network IDS). Además, también se pueden utilizar como IDS los tarros de miel (honeypots y honeynets) que, aunque su objetivo va más allá de la propia detección, constituyen una valiosa herramienta de detección.
HIDS: IDS de nodo (Host-based IDS). Monitorizan la actividad del sistema en que están instalados. Es necesario instalar un HIDS en cada nodo a proteger.
NIDS: IDS de red (Network IDS). Monitorizan la actividad de las redes a las que están conectados.
Tarros de miel:honeypots y honeynets. Son entornos trampa, diseñados para ser atacados y ser comprometidos. Su efectividad como IDS radica en que, al no ofrecer ningún servicio legítimo, toda la actividad que ocurra en el tarro de miel es sospechosa y, por tanto, interesante. Permiten aprender mucho sobre los atacantes, incluyendo técnicas desconocidas previamente. No obstante, solamente capturan lo que va dirigido a ellos, por lo que no deben ser el único IDS presente. Además suponen un riesgo, puesto que al ser vulnerables por definición, pueden ser usados para atacar a otros sistemas desde dentro.
Es importante comenzar destacando que el concepto de detección ya se introdujo al comienzo del curso como parte de la seguridad como un proceso. Efectivamente, asumiendo que las medidas preventivas nunca van a ser efectivas al 100%, se plantea la necesidad de detectar los intentos de intrusión y reaccionar adecuadamente frente a ellos, para lo cual es necesario monitorizar el comportamiento del sistema y analizar la necesidad de cambios.
El primer objetivo de esta fase es ser capaz de detectar las actividades no deseadas a tiempo. Estas actividades no necesariamente tienen que estar relacionadas con ataques al sistema, ya que también pueden deberse a errores de software, a errores de configuración, o a situaciones accidentales, como un aumento de la temperatura por una refrigeración insuficiente. En este caso, la detección temprana debe permitir corregir los errores de funcionamiento y configuración antes de que causen más daño. Pero, lógicamente, las actividades no deseadas más peligrosas se corresponden con intentos de atacar el sistema. En este caso, idealmente, una detección temprana permite detectar las primeras fases de un ataque, cuando el intruso está reconociendo el sistema, incluso antes de haya sido capaz de lograr ejecutar código en la ninguna de las máquinas, permitiendo evitar que el ataque tenga éxito.
No obstante, los atacantes tratarán de preparar al máximo el ataque para que haya poco tiempo entre detección y reacción. Por lo tanto, es necesario aplicar la seguridad en profundidad, con varias barreras de contención que permitan tratar el incidente en sus fases iniciales, antes de que sea demasiado tarde. Estas medidas preventivas, como crear usuarios con privilegios limitados, el uso de seguridad perimétrica o la segmentación de la red corporativa dificultan la ejecución del ataque y facilitan su detección, proporcionando tiempo adicional para tratar el incidente y permitiendo reaccionar a tiempo.
div style="position:relative;height:0;padding-bottom:56.25%">
Ejercicio: Preparar el entorno para el resto de actividades
En esta lección se configurará OSSEC como servidor/agente, la forma recomendada cuando se desean proteger varias máquinas. En este caso, el papel de servidor lo realizará base, los agentes (las máquinas a proteger) serán dmza e inta, y los atacantes serán exta (ataques externos) e intf (ataques internos, es decir, desde la red corporativa). Por tanto, para realizar las actividades será necesario arrancar las máquinas UML siguientes: fw, exta, dmza, inta e intf.
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:
Realizar, si no se ha hecho antes, una copia del estado actual y etiquetarlo adecuadamente renombrando el fichero resultante.
Restaurar la copia de seguridad inicial.
Editar el guión "uml_run_my_uml.sh" para que solamente se ejecuten las máquinas indicadas.
Lanzar las máquinas UML usando el icono "Run my UMLs".
Comprobar que efectivamente se han puesto en marcha las máquinas esperadas.
Además, para que base pueda desempeñar su papel de estación de trabajo del analista deberá ser capaz de recibir los mensajes de los agentes. Para ello sería necesario abrir el puerto 1514 de UDP. Sin embargo, puesto que las interfaces tap0, tap1 y tap2 que conectan a base con las máquinas UML forman parte de la red interna del cortafuegos de openSUSE, no será necesario realizar ningún cambio en la configuración del cortafuegos de base.
También será necesario que el analista pueda leer los correos electrónicos que genere OSSEC. Puesto que los correos los genera el servidor, bastará con que cualquier usuario del sistema pueda enviar correos al resto de los usuarios del sistema. Ésta es la configuración por defecto de base, así que lo único que será necesario es configurar un cliente de correo. Aunque pueden usarse otros clientes, a continuación se describe cómo configurar el cliente gráfico kmail.
Acciones recomendadas:
Arrancar KMail por primera vez y rellenar la información solicitada por el asistente:
Primera pantalla:
"Full Name": User 1
"E-mail address": user1@base.example.net
No poner contraseña
Desmarcar "Find provider settings on the Internet"
Seleccionar "Next"
Segunda pantalla:
Seleccionar como "Account type": MailBox
Seleccionar "Next"
Tercera pantalla:
Introducir como "URL": /var/mail/user1
Seleccionar "Next"
Cuarta pantalla y última:
Seleccionar "Finish"
Comprobar la configuración:
Como usuario no privilegidado, en una terminal de base, ejecutar la orden:
date | mail -s "Prueba" user1@localhost
Comprobar que llega un correo a kmail con asunto "Prueba" y con contenido la fecha y la hora del momento en que se haya ejecutado la orden anterior. (Puede ser necesario presionar en "Next", en la barra de herramientas de KMail, para que se muestren los mensajes).
Ejercicio: Instalación de OSSEC en modo servidor/agentes
Obtención del programa OSSEC
Lo primero es obtener una copia del programa, disponible a través de su página web: http://www.ossec.net. El enlace directo a la página de descargas es: http://www.ossec.net/?page_id=19. Una vez en la página se debe seleccionar la versión "Server/Agent 2.8.3 – Linux/BSD" y su suma de comprobación (Checksum).
Acción a realizar: descargar el programa OSSEC (versión 2.8.3) y su suma de comprobación.
(Si todo ha ido bien, deben haber dos ficheros en la carpeta "Downloads" del directorio inicial de user1 en base, "ossec-hids-2.8.3.tar.gz" y "ossec-hids-2.8.3-checksum.txt").
Comprobación de la integridad del programa
Los hashes MD5 y SHA1 de "ossec-hids-2.8.3.tar.gz" están incluidos en el fichero "ossec-hids-2.8.3-checksum.txt". Para comprobar que "ossec-hids-2.8.3.tar.gz" no ha sufrido cambios durante la descarga, ambos hashes deben coincidir con los que se generen a partir del fichero descargado con los algoritmos MD5 y SHA1. La forma de generar los hashes sería:
md5sum ossec-hids-2.8.3.tar.gz
sha1sum ossec-hids-2.8.3.tar.gz
Acción a realizar: comprobar la integridad del programa descargado.
Instalación y configuración de OSSEC en el servidor
Este apartado debe realizarse como administrador del sistema (root) en base, por lo que lo primero es lanzar una terminal y, en ella, convertirse en administrador. (El resto de acciones de este apartado deberán realizarse en esta terminal).
Acción a realizar: convertirse en administrador en una terminal (sugerencia: usar "su -").
Lo siguiente es extraer el programa, compilarlo, configurarlo e instalarlo. La extracción se puede hacer de la forma habitual ("tar zxf /home/user1/Downloads/ossec-hids-2.8.3.tar.gz"), mientras que el resto de pasos se realizan ejecutando el fichero "install.sh" de la carpeta "ossec-hids-2.8.3" recién creada. Por ejemplo, ejecutando "sh ossec-hids-2.8.3/install.sh".
Durante la ejecución del programa de instalación, se debe seleccionar la instalación en modo servidor, utilizando las opciones por defecto; eso sí, teniendo cuidado de proporcionar una dirección de correo válida para recibir las notificaciones (usar "user1@localhost") y definiendo 127.0.0.1 como IP del servidor SMTP.
Acción a realizar: configurar e instalar OSSEC en modo servidor en base.
Finalmente, queda por poner en marcha el servidor de OSSEC. Para ello, tal y como sugiere el mismo programa, basta con ejectutar la orden "/var/ossec/bin/ossec-control start". Si todo funciona correctamente, dicha orden nos informará de que se han puesto en marcha diferentes módulos y, al final, que el arranque se ha completado. La puesta en marcha de un servidor genera una alerta de nivel 3 que debería traducirse en un correo electrónico recibido por "user1@localhost".
Acción a realizar: poner en marcha el servidor OSSEC en base y comprobar que se recibe el correo electrónico de notificación correspondiente.
Instalación y configuración de OSSEC en los agentes
La instalación en modo agente requiere acceso al programa OSSEC (fichero "ossec-hids-2.8.3.tar.gz"). La forma más sencilla de compartirlo entre base y los agentes es copiar dicho fichero al directorio "/home/user1/uml/mntdirs/tmp", al que los agentes (máquinas UML en este ejercicio) tienen acceso como el directorio local "/mnt/tmp".
Acción a realizar: como usuario normal, en base, copiar el fichero "ossec-hids-2.8.3.tar.gz" en la carpeta "/home/user1/uml/mntdirs/tmp".
El resto de este apartado debe realizarse como administrador del sistema (root) en cada uno de los agentes. A modo de ejemplo, se indica a continuación cómo realizar la instalación y configuración en inta, proceso que habrá que repetir posteriormente en dmza.
Acción a realizar: usando la terminal correspondiente, entrar como usuario root en inta.
Lo siguiente es extraer el programa, compilarlo, configurarlo e instalarlo. La extracción se puede hacer de la forma habitual ("tar zxf /mnt/tmp/ossec-hids-2.8.3.tar.gz"), mientras que el resto de pasos se realizan ejecutando el fichero "install.sh" de la carpeta "ossec-hids-2.8.3" recién creada. Por ejemplo, ejecutando "sh ossec-hids-2.8.3/install.sh".
Durante la ejecución del programa de instalación, se debe seleccionar la instalación en modo agente, proporcionando la dirección IP del servidor (10.5.2.1 en el caso de inta, en el caso de dmza será 10.5.1.1).
Acción a realizar: configurar e instalar OSSEC en modo agente en inta.
La comunicación entre el servidor y los agentes es cifrada y autentificada. Por este motivo, para cada agente es necesario crear una clave de autentificación en el servidor, exportarla, e importarla en el cliente.
A continuación se describe el mecanismo para inta. (Este mismo mecanismo debe ser repetido posteriormente para dmza teniendo cuidado de usar el identificador, nombre y dirección IP adecuados).
Dar de alta a inta en el servidor. Para ello es necesario:
Ejecutar la orden "/var/ossec/bin/manage_agents" como root en base, que es donde está el servidor.
Seleccionar 'A' (añadir un agente).
Proporcionar la información para inta: Nombre: inta, Dirección IP: 10.5.2.10, ID 001. (Tras revisar los datos introducidos, confirmar que se desea añadir el agente).
Generar y exportar una clave de autenticación para inta. Para ello, dentro del mismo programa del paso anterior:
Seleccionar 'E' (extraer una clave para un agente).
Introducir el ID de inta (habitualmente 001).
Copiar la clave al portapapeles.
Seleccionar 'Q' (salir del programa).
Relanzar el servidor OSSEC en base para que tenga en cuenta al nuevo agente. Para ello basta con ejecutar la orden "/var/ossec/bin/ossec-control restart".
Importar la clave en el agente (inta, en este caso). Para ello, en la terminal de inta en la que se tiene abierta la sesión como administrador:
Ejecutar el programa "/var/ossec/bin/manage_agents".
Seleccionar 'I' (importar clave del servidor).
Pegar la clave copiada en el paso anterior.
Revisar la información y confirmar.
Seleccionar 'Q' (salir del programa).
Acción a realizar: registrar a inta como agente en el servidor (base), generar una clave para inta e importarla en inta, siguiendo el mecanismo descrito.
En este punto, el agente inta está preparado para poderse conectar con el servidor base y comenzar a funcionar como agente del IDS, enviando las alertas al servidor. Por tanto, solamente queda poner en marcha OSSEC en inta. Como en el caso del servidor, es suficiente con ejecutar "/var/ossec/bin/ossec-control start". La puesta en marcha de un agente también genera una notificación que se debe traducir en un mensaje de correo electrónico dirigido a "user1@localhost".
Acción a realizar: poner en marcha el servidor OSSEC en inta y comprobar que se recibe el correo electrónico de notificación correspondiente.
A continuación, será necesario repetir el proceso de configuración como agente OSSEC en dmza, para completar el escenario de estar protegiendo una red de ordenadores. Es necesario tener en cuenta que la dirección IP de dmza es 10.5.1.10, que pertenece a la red DMZ y que, en esa red, el servidor base tiene la IP 10.5.1.1.
Acción a realizar: configurar dmza como agente OSSEC, comprobando que finalmente se recibe el correo electrónico de confirmación de que el nuevo agente se ha conectado al servidor.
Comprobación final de la instalación
Finalmente, para comprobar que la configuración es correcta (o para depurar los posibles problemas), se puede usar la orden "/var/ossec/bin/agent_control -l" (debe ser ejecutada como root en base). La opción "-l" solicita un listado de los agentes disponibles (registrados con el servidor). A continuación se muestra un ejemplo de sistema correctamente configurado (con base, inta y dmza registrados como agentes):
base:~ # /var/ossec/bin/agent_control -l
OSSEC HIDS agent_control. List of available agents:
ID: 000, Name: base (server), IP: 127.0.0.1, Active/Local
ID: 001, Name: inta, IP: 10.5.2.10, Active
ID: 002, Name: dmza, IP: 10.5.1.10, Active
List of agentless devices:
base:~ #
Acción a realizar: comprobar el listado de agentes disponibles.
Limpiando datos temporales de las UML
Para dar por finalizado el ejercicio, conviene limpiar todos los datos temporales generados durante la instalación de OSSEC en las UML. Así, las copias de seguridad serán más reducidas. Para ello, lo único que hay que hacer es borrar el directorio "ossec-hids-2.8.3" de inta y de dmza.
Acción a realizar: borrar los datos temporales en inta y dmza.
En las actividades siguientes se modificará el estado de las UML con acciones como instalar programas o simular diferentes tipos de ataques. Puesto que en este punto se dispone de una instalación limpia de los agentes, se recomienda realizar una copia de seguridad.
Antes de hacerla, es conveniente recordar que:
Se debe haber borrado el directorio "ossec-hids-2.8.3" en inta y dmza.
Se deben parar las máquinas.
Acciones a realizar: realizar una copia de seguridad del estado de las UML. (En caso de duda, se recomienda revisar el apartado sobre copias de seguridad).
La copia de seguridad debería tener unos 25 MiB, aproximadamente.
Una vez realizada la copia, solamente queda volver a arrancar las máquinas (con el icono "Run my UMLs") y comprobar que los agentes vuelven a registrarse correctamente con el servidor.
Acciones a realizar: arrancar las UML con "Run my UMLs" y comprobar que los agentes vuelven a conectarse con el servidor.
Para mostrar el funcionamiento de OSSEC, en esta actividad se realizarán acciones habituales que pueden generar alertas, y se aprenderá a valorar si deben ser consideradas, o no, como un intento de intrusión.
Ejemplo 1: Acceso físico de un usuario
Una de las cosas que genera una alerta es el hecho de que un usuario inicie una sesión directamente en la consola del sistema. Para comprobarlo, basta con ir a una de las terminales de las máquinas protegidas (inta y dmza) y conectarse como uno de los usuarios disponibles (user1 y root).
Este simple hecho genera una alerta, pero lógicamente no necesariamente supone una intrusión (o intento de intrusión), ya que la alerta se genera incluso aunque se introduzca la contraseña correctamente a la primera. Por este motivo, a la alerta se le asigna un nivel 3 (successful/authorized events), y no se notifica por correo electrónico.
La forma de ver todas las alertas que recibe el servidor es consultar el fichero "/var/ossec/logs/alerts/alerts.log" de base. Una forma cómoda de supervisar las modificaciones que se van produciendo es usar la orden "tail" con la opción "-f".
Acciones a realizar:
En una terminal de base, como root, comenzar a supervisar las alertas que recibe el servidor OSSEC.
En una terminal de inta, iniciar sesión en el sistema como usario root.
Identificar la alerta, tratando de interpretar la información que proporciona.
Ejemplo 2: Instalación de un programa nuevo
Otra acción que genera una alerta es instalar paquetes de software en un sistema. En este caso, esta actividad, aunque no supone necesariamente que haya una intrusión, sí es un evento significativo que debe ser comprobado cada vez que produzca. Dicho de otro modo, es deseable que el sistema nos avise cada vez que se instalen nuevos programas. Por este motivo, el nivel asignado a esta alerta es el 7, y se genera un aviso por correo electrónico (en la configuración por defecto de OSSEC).
Acciones a realizar:
En una terminal de base, como root, comenzar a supervisar las alertas que recibe el servidor OSSEC.
(Si no se tiene abierta). En una terminal de inta, iniciar sesión en el sistema como usario root.
(Si se ha iniciado). Identificar la alerta para no confundirla con las siguientes.
Instalar el programa "screen" en inta mediante la orden "apt-get install screen".
Identificar las alertas, tratando de interpretar la información que proporcionan y correlacionarla con los mensajes de "apt-get".
Comprobar que se recibe el correo electrónico correspondiente a las alertas recién generadas.
En este ejercicio se realizarán acciones para provocar la respuesta activa de OSSEC, identificando los cambios que realiza en el sistema.
Ejemplo 1: Ataque de fuerza bruta mediante SSH
Una forma de provocar la respuesta activa de SSH es tratar de adivinar nombres de usuarios y contraseñas en una máquina usando prueba y error (fuerza bruta). Las medidas de respuesta activa de OSSEC se pueden consultar ejecutando la orden "/var/ossec/bin/agent_control -L" como root en el servidor (base). Por defecto, OSSEC modifica la configuración de tcpwrappers (fichero "/etc/hosts.deny") y de IPTABLES.
Acciones a realizar:
Desde intf, simular un ataque de fuerza bruta a inta. Para ello, probar a conectarse como los usuarios uno, dos, tres..., hasta que no sea posible seguir probando.
En base, comprobar que se han recibido las alertas y la notificación por correo electrónico.
En inta, comprobar que se han añadido reglas de IPTABLES que bloquean el acceso desde intf.
En inta, comprobar que se ha añadido a intf al fichero "/etc/hosts.deny" para evitar el acceso a cualquier servicio desde dicho nodo.
Ejemplo 2: Tratar de adivinar nombres de ficheros o directorios en un servidor web
Otro ejemplo consiste en intentar descargar información no enlazada desde un servidor web, nuevamente usando prueba y error. Para ello, una utilidad muy conveniente es el programa wget, que permite descargar contenido desde la línea de órdenes y automatizarlo mediante un sencillo guión de una línea:
for x in $(seq 1000); do wget www.example.net/foo/$x; done
Para simular un ataque de este tipo, se usará una máquina externa, en este caso exta, que simulará ser un nodo cualquiera de Internet. El ataque se lanzará sobre el servidor web de NETinVM (ww.example.net, que es un alias de dmza).
Acciones a realizar:
Desde exta, simular el ataque descrito sobre www.example.net (dmza). Para ello, usar el guión anterior.
En base, comprobar que se han recibido las alertas y la notificación por correo electrónico.
En dmza, comprobar que se han añadido reglas de IPTABLES que bloquean el acceso desde exta.
En dmza, comprobar que se ha añadido a exta al fichero "/etc/hosts.deny" para evitar el acceso a cualquier servicio desde dicho nodo.
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:
Realizar, si no se ha hecho antes, una copia del estado actual y etiquetarlo adecuadamente renombrando el fichero resultante.
Restaurar la copia de seguridad inicial.
Editar el guión "uml_run_my_uml.sh" para que solamente se ejecuten las máquinas indicadas.
Lanzar las máquinas UML usando el icono "Run my UMLs".
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:
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...
Configuración de bibliotecas dinámicas. Especificar qué bibliotecas dinámicas cargar durante la ejecución de snort.
Configuración de preprocesadores. Establecer los preprocesadores (frag3, stream5, http_inspect, sfportscan...) que deben ejecutarse y ajustar su configuración.
Configuración de los complementos de salida. Configurar qué complementos usar (syslog, mysql...) y su configuración.
Configuración adicional de snort. Usar sentencias config (ignore_ports, flowbits_size...) para afinar el comportamiento de snort.
Configuración del conjunto dereglas. 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:
En exta, como root, editar el fichero "/etc/snort/snort.conf" y realizar los ajustes recomendados.
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:
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").
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:
Asegurarse de que snort está ejecutándose en exta.
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:
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".
En extf, como root, ejecutar la orden "nmap -sS 10.5.1.10" y anotar las alertas que genera.
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.
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:
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).
En extf, como root, ejecutar la orden "nmap -PN -sS --host-timeout 1m10.5.2.1-15" y comprobar que no se producen alertas.
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:
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).
En extf, ejecutar la orden "wget www.example.net/../../../etc/passwd".
A partir de las alertas generadas, identificar las reglas que las han generado.
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:
Monitorizar el registro de mensajes ("tail -f /var/log/auth.log").
Ejecutar el exploit en extf:
python 70137.py -s -t http://www.example.net
Comprobar que "www.example.net" no es vulnerable.
Comprobar que snort no lo detecta.
Añadir una regla adecuada para detectar SHELLSHOCK en "/etc/snort/rules/local.rules".
