39360.zip
El Sistema de Detección de Intrusiones de Red (NIDS) de código abierto, escalable y eficiente, utiliza una serie de reglas bien definidas para detectar paquetes anómalos en su red. El mantenimiento de estos conjuntos de reglas mejora notablemente la eficacia del sistema. Algunas técnicas de gestión de reglas pueden ayudarle a mantener su Snort IDS. En primer lugar, puede evitar una sobrecarga de alertas ajustando las definiciones de las variables y preparando sus reglas de Snort. También puede persistir sus reglas personalizadas a través de las actualizaciones del conjunto de reglas. Finalmente, puede deconstruir una regla para entender cómo personalizar las reglas para su entorno.
Por defecto, Snort contiene más de 1900 reglas de stock dentro de una serie de casi 50 archivos de texto organizados por tipo, como muestra la Figura 1. Estas reglas definen desencadenantes de respuesta a muchos exploits de vulnerabilidad conocidos pertenecientes a Windows, UNIX y aplicaciones ampliamente utilizadas como Microsoft IIS, Apache, Microsoft SQL Server y Oracle SQL. Las reglas también ayudan a Snort a proporcionar datos de reconocimiento y posibles advertencias de configuración para alertar de los escaneos de la red o de una máquina que está emitiendo una cadena de comunidad por defecto de SNMP, por ejemplo. Como puedes imaginar, Snort puede generar un enorme número de alertas. Para reducir el ruido de las reglas de stock, la configuración por defecto de Snort habilita sólo alrededor de 1300 de las reglas por defecto y deshabilita tipos enteros de reglas, como políticas, chat y virus, por defecto. (Un tipo de regla suele estar contenido en su propio archivo de texto, por lo que las reglas de tipo virus están contenidas en el archivo virus.rules). Revise los grupos de reglas deshabilitados y habilite los que puedan aplicarse a su entorno.
Perfeccione sus reglas
Incluso con las muchas reglas que Snort deshabilita por defecto, su sistema Snort IDS probablemente generará muchas alertas. Pasar por todas estas alertas podría embotar sus sentidos para el tráfico verdaderamente sospechoso. Después de instalar Snort en tu entorno, poda las reglas para eliminar aquellas que no pertenecen a tu entorno o que no te preocupan. Por ejemplo, si no tienes el lenguaje de scripting PHP incrustado en HTML: Hypertext Preprocessor (PHP) instalado en su entorno, puede desactivar el archivo de reglas web-php.rules. Sin embargo, cuando decida qué reglas desactivar, tenga en cuenta que los usuarios pueden tener varios programas en sus máquinas. Por ejemplo, uno de sus sensores Snort podría recoger paquetes sospechosos de una máquina doméstica comprometida a través de una conexión VPN. Así que, continuando con el ejemplo anterior, incluso si no tienes PHP instalado en ninguno de tus ordenadores corporativos, uno de tus usuarios finales podría haberlo instalado en casa. Si esa computadora en casa fuera comprometida a través de una vulnerabilidad de PHP, el atacante podría ser capaz de acceder a su red corporativa mientras la computadora comprometida está conectada remotamente a la red corporativa (como a través de una VPN).
La mayoría de los sistemas de alerta y reporte muestran el nombre y el SID para cada regla para una fácil referencia. Para recortar aún más su lista de reglas habilitadas, monitoree sus sistemas, anote los nombres o SID de las reglas extrañas y luego desactive esas reglas. Para desactivar manualmente una regla de Snort, abra el archivo de la regla e inserte un signo de libra (#) delante de la regla. Para desactivar toda una clase de reglas, añada un signo de libra delante del nombre de la regla en el archivo de configuración de Snort. Debe reiniciar Snort para cargar las reglas modificadas.
Revisar sus reglas con regularidad y seguir eliminando las que no se aplican a su red disminuirá drásticamente el número de alertas que genera Snort, facilitando así la detección e identificación de paquetes realmente sospechosos. Y recuerde volver a habilitar las reglas según sea necesario cuando introduzca una nueva tecnología que las reglas actualmente deshabilitadas protegerían.
Mantenga las reglas actualizadas
Snort.org alberga dos versiones de las reglas de Snort: snortrules-stable y snortrules-current, que funcionan con Snort 2.0x y Snort 1.9x, respectivamente. Las reglas más nuevas contienen firmas adicionales y actualizaciones de las reglas existentes para hacer uso de variables ampliadas. Por ejemplo, las reglas de la versión 2.0.0 definen variables que describen específicamente ciertas funciones de la máquina (por ejemplo, las variables HTTP_SERVERS y HTTP_PORTS caracterizan a los ordenadores que ejecutan servicios web y podrían ser propensos a ataques de servicios web). Estas nuevas variables funcionan en las nuevas reglas para filtrar mejor los ataques entrantes. Una regla antigua podría alertarle de una petición HTTP sospechosa destinada a cualquier ordenador de su red, pero la nueva regla busca el mismo ataque sólo cuando está destinado a un servidor web que la variable HTTP_SERVERS define. Este proceso de clasificación ayuda a reducir las falsas alarmas.
Snort.org actualiza los conjuntos de reglas con frecuencia para mantenerse al día con los nuevos descubrimientos de exploits. Para mantenerse al día, busque, descargue y aplique regularmente nuevas reglas que puedan ser útiles en su entorno. Sin embargo, tenga en cuenta que cada vez que descargue un conjunto de reglas nuevas, los archivos de texto que contienen las nuevas reglas sobrescriben los que contienen las reglas antiguas. Rápidamente se dará cuenta de que comentar todas las reglas no utilizadas cada vez que actualice sus archivos de reglas es una carga.
Oinkmaster al rescate
Por suerte, varias herramientas de código abierto pueden ayudarle a superar este problema. Un programa de script Perl llamado Oinkmaster, que puede descargar de http://www.algonet.se/~nitzer/oinkmaster, automatiza la descarga de nuevas reglas y gestiona las reglas desactivadas o modificadas. Adaptado a los sistemas UNIX, el script Perl utiliza las herramientas wget, tar y gzip para obtener y expandir nuevas reglas cada vez que se ejecuta el script. La mayoría de estas herramientas vienen instaladas en los sistemas UNIX, pero puedes descargar las herramientas para Windows. Recuerda que las soluciones de código abierto tienen un soporte dedicado limitado (si es que hay alguno), así que busca en Internet soluciones a cualquier problema o pregunta que puedas tener. La comunidad del software de código abierto (OSS) abunda en información útil. Un buen lugar para empezar es suscribirse a una de las listas de correo de Snort, a la que puede apuntarse en http://www.snort.org/lists.html.
Asegúrese de consultar el archivo README para obtener instrucciones detalladas de instalación para su plataforma. El procedimiento básico de instalación de Oinkmaster consiste en expandir los archivos oinkmaster.pl y oinkmaster.conf en tu directorio de Snort (o en un directorio que especifiques), y luego usar oinkmaster.conf para configurar Oinkmaster.
Abre oinkmaster.conf y sigue los comentarios en línea para configurar la herramienta. Primero, confirme la ubicación de las reglas actualizadas como una dirección web (por ejemplo, http://www.snort.org/dl/signatures/snortrules.tar.gz). Asegúrese de dirigir Oinkmaster a un sitio de confianza y de buena reputación, especialmente si elige descargar e instalar las reglas automáticamente. De lo contrario, corre el riesgo de descargar reglas corruptas (o peor aún, manipuladas) que podrían comprometer su IDS.
A continuación, especifique los archivos a omitir, modificar y desactivar. Por defecto, Oinkmaster no procesa (es decir, omite) local.rules y snort.conf.
La función modifysid del script le permite modificar las reglas recién descargadas; piense en modifysid como una función de Buscar y Reemplazar para una regla específica que usted identifica por SID. Con este comando, puede modificar el texto de una regla específica. Por ejemplo, puede utilizar modifysid para activar una regla que está desactivada por defecto. Para ello, añada un nuevo comando modifysid que identifique la regla que desea habilitar y pídale que elimine el carácter de comentario (#). Cada vez que se descargue un nuevo conjunto de reglas, este carácter de comentario se eliminará cuando Oinkmaster analice esa regla. También puede utilizar modifysid para elevar el tipo de acción de una regla. Por ejemplo, el comando
modifysid 2003 "alert" | "sev1"
eleva la alerta con un SID de 2003 a un tipo de acción personalizado de sev1. Oinkmaster hace esto buscando «alert» y sustituyéndolo por «sev1». Y sí, hará múltiples sustituciones, así que úsalo con cuidado.
La última y más popular característica de Oinkmaster, disablesid, te permite deshabilitar reglas seleccionadas. Especifique los SID de todas las reglas que desee mantener desactivadas. Por ejemplo, para deshabilitar las alertas en los escaneos de red, puedes empezar con una entrada similar a
disablesid 469, 615, 618, 620
Después de descargar y analizar un nuevo conjunto de reglas, Oinkmaster busca los SIDs especificados y comenta las reglas. Mientras Oinkmaster gestione sus reglas, éstas permanecerán desactivadas, incluso a través de las actualizaciones del conjunto de reglas.
Ejecute manualmente el script cada vez que quiera actualizar sus reglas. Si se atreve, programe el script para que se ejecute y actualice las reglas de forma recurrente. Oinkmaster obtendrá las reglas, las expandirá y las copiará en el directorio de reglas de su sensor. Como con la mayoría de los OSS, utilice Oinkmaster con discreción y aprenda primero lo que hace y cómo afectará a su entorno. Por ejemplo, pruebe un nuevo conjunto de reglas ejecutando Snort en el modo de auto-prueba (usando snort -T más sus otros parámetros) antes de desplegar las reglas en su entorno de producción.
Oinkmaster le permite evitar los riesgos de descargar actualizaciones dudosas dándole la opción de hacer una copia de seguridad de las reglas antiguas y entregando un registro de sus acciones a la consola. Revise esta salida, que muestra las reglas eliminadas, las reglas activas modificadas, las revisiones de no reglas y los archivos nuevos, para confirmar que Oinkmaster ha completado con éxito sus tareas y para confirmar las reglas que Oinkmaster ha modificado. Si decide programar la ejecución automática de Oinkmaster, considere la posibilidad de enviar los resultados por correo electrónico para facilitar su revisión, como muestra la Figura 2. El siguiente ejemplo muestra cómo programar Oinkmaster para que se ejecute diariamente a las 6:15 a.m. utilizando el comando crontab de Linux (crontab permite programar trabajos en Linux):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Los parámetros de Oinkmaster especifican el directorio de reglas (-o), el directorio de reglas de respaldo (-b) y un comando para enviar los resultados por correo electrónico al propietario. El comando 2>&1 envía la salida StdErr a StdOut (la consola) antes de enviarla a la aplicación de correo electrónico.
Mirando una regla Snort
Además de deshabilitar o hacer modificaciones básicas a las reglas de stock, puede crear sus propias reglas y adaptar aún más las reglas Snort directamente a su entorno. Por ejemplo, considere un despliegue de sensores que monitoree el tráfico dentro y fuera de su firewall. Aunque saber cuántos ataques de gusanos repele tu cortafuegos puede interesarte, saber si alguno de esos ataques se originó dentro de tu red probablemente te interese aún más. Recientemente, las reglas de Snort han incluido reglas «afinadas» como el ejemplo anterior, pero aún quedan muchas otras que quizás quieras personalizar de forma similar. El listado 1 muestra una regla estándar que te alerta cuando detecta el gusano SQL Slammer (también conocido como Sapphire). Vamos a deconstruir rápidamente esta regla. (Para obtener información detallada sobre todos los parámetros disponibles que definen las reglas, consulte la exhaustiva documentación sobre reglas de Snort en http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Todas las reglas deben residir en una línea y comenzar con una acción de regla, que en este caso es
alert
La acción de regla define cómo responde Snort a la regla si se activa. Puede modificar el tipo de regla (por ejemplo, a una cadena como ‘sev1’) para proporcionar un manejo personalizado-por ejemplo, para escalar la acción en caso de una coincidencia. Este paso es diferente del ejemplo anterior, en el que usamos Oinkmaster para cambiar el tipo de alerta de una regla existente; en este ejemplo, estamos creando una nueva regla usando una regla existente como plantilla.
El conjunto de parámetros
udp $EXTERNAL_NET any -> $HOME_NET 1434
proporciona el protocolo, la dirección IP, la información del puerto y la dirección del tráfico para la regla. Esta regla le dice a Snort que encuentre cualquier paquete UDP de una fuente de red (que la variable $EXTERNAL_NET define) que intente ir a la variable $HOME_NET en el puerto 1434. La mayoría de las reglas por defecto utilizan principalmente las variables $EXTERNAL_NET y $HOME_NET. Sin embargo, algunas reglas utilizan variables más específicas. Por ejemplo, las reglas que pertenecen a los servidores DNS (en el archivo dns.rules) utilizan la variable $DNS_SERVERS. Defina estas variables en el archivo de configuración de Snort (normalmente snort.conf). Opcionalmente, cree sus propias variables para reflejar su topología (por ejemplo, $MAIL_SERVERS) y para su uso en reglas personalizadas. Defina una variable utilizando su nombre (por ejemplo, var MAIL_SERVERS= 192.168.0.20/30), y luego haga referencia a la variable anteponiendo un signo de dólar ($-e.g., $MAIL_SERVERS). La acción de la regla y estos parámetros conforman la cabecera de la regla.
Las opciones de la regla refinan aún más la regla para que un paquete sospechoso (y sólo un paquete sospechoso) active una respuesta. Como puede adivinar, estas firmas pueden llegar a ser bastante detalladas y se extienden mucho más allá de la simple coincidencia de puertos. Por ejemplo, imagine los falsos positivos que resultarían si esta regla de Slammer simplemente le alertara de cualquier tráfico del puerto UDP 1434.
La opción msg
msg:"MS-SQL Worm propagation attempt"
proporciona una descripción simple de la alerta para su uso en actividades de alerta e informe. La opción de contenido
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
contiene la cadena de coincidencia de patrones de carga útil que distingue entre mayúsculas y minúsculas, en valores ASCII o hexadecimales (encierre los valores hexadecimales con el carácter pipa-|). Puede especificar varias opciones de contenido. La opción de profundidad sigue a cada opción de contenido y especifica cuántos bytes dentro de la carga útil desea buscar para el contenido especificado. En este ejemplo, un paquete desencadenará una respuesta si contiene el valor hexadecimal 04 en el primer byte o el contenido restante en cualquier parte de la carga útil.
Las reglas descargadas a menudo contienen referencias a información detallada sobre el exploit sospechoso o la razón detrás de la creación de la regla. Algunos sistemas de notificación admiten la opción de referencia proporcionando enlaces directos a esta información:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort asigna reglas a clases y asigna a estas clases una prioridad alta, media o baja. Actualmente, existen más de 30 clasificaciones, entre las que se incluyen intento de administración, actividad de troyanos, intento de denegación de servicio y exploración de la red. En nuestro ejemplo, la clasificación es
classtype:misc-attack
Snort registra la prioridad de respuesta para las intrusiones detectadas. Puede utilizar una herramienta externa o un script para analizar esta prioridad y tomar medidas con su aplicación de informes.
En el segmento final
sid:2003; rev:2;
sid representa una regla Snort única, y rev denota el número de revisión. Estas propiedades identifican la regla de forma única.
Adaptación de la regla
Examinemos cómo modificar esta regla para proporcionar una alerta escalada cuando detecte hosts internos infectados. Como estamos tratando con el mismo exploit que la regla original, la definición del contenido de la regla sigue siendo la misma. Sólo tenemos que modificar las direcciones IP y la dirección del tráfico. Cambiemos la dirección IP de origen a $HOME_NET, de la siguiente manera:
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf define $EXTERNAL_NET como «cualquiera», por lo que esta regla seguirá capturando paquetes corruptos dirigidos a hosts internos (al igual que la regla original). Sin embargo, ahora que tenemos una regla dedicada que rastrea sólo las direcciones IP de origen interno, podemos cambiar el tipo de acción a un tipo de acción personalizado que desencadena una alerta escalada.
Las reglas actuales de Snort incluyen esta regla de detección de gusanos Slammer salientes en el conjunto de reglas por defecto. Sin embargo, cuando un nuevo gusano, virus u otro exploit comience a propagarse, considere la posibilidad de crear nuevas reglas que destaquen intrusiones específicas.
Cómo crear sus reglas
Además de las reglas existentes o personalizadas que puede modificar o crear, es posible que desee incluir reglas que obtenga de otra fuente. Por ejemplo, cuando las noticias de un nuevo gusano se propagan por Internet, los sitios de seguridad y los grupos de noticias se apresuran a publicar reglas únicas de Snort que pueden detectar el nuevo gusano. Pegue estas nuevas reglas en el archivo local.rules, luego reinicie Snort para que las nuevas reglas surtan efecto.
Snort proporciona el marco para un IDS barato y personalizable. Con un conjunto de reglas apoyadas por la comunidad, Snort sigue siendo un sistema flexible y eficaz. Mantener sus reglas actualizadas aumentará su vigilancia y disminuirá el ruido que resulta de las alertas inefectivas. Como con cualquier proyecto de código abierto, tomarse el tiempo para entender cómo funciona y familiarizarse con sus complementos desarrollados por la comunidad mejorará drásticamente su comodidad con el sistema y aumentará su eficacia en su entorno.