Hola taringueros
Este post lo hago por que acabo de utilizar Snort y quiero que ustedes tengan a la mano la info que me sirvio para montar Snort.
Bueno si estan aqui, es por que necesitan o quieren saber como instalar y configurar Snort y pues ya tenemos algo de conocimientos, en fin vamos al grano; no voy a comentar que es Snort, mucho menos que es un IPS, para eso san google y wikipedia existen.
I N S T A L A C I O N
La instalación de Snort suele ser sencilla. Quien tenga un gestor de paquetes .dev o .rpm debería encontrar a Snort entre los paquetes disponibles para su distribución; aunque sea una versión algo más antigua. Este post refiere a la versión es la 2.8.3.1. Instalarlo desde las fuentes no es tan sencillo como hacerlo con apt-get, pero dispondremos de muchas más opciones para la configuración del sistema.
Para compilarlo necesitaremos el tarball con las fuentes y, opcionalmente, la suma MD5 que usaremos para comprobar la integridad del paquete.
wget http://www.snort.org/
dl/snort-2.8.3.1.tar.gz
Opcional:
wget http://www.snort.org/
dl/snort-2.8.3.1.tar.gz.md5
Opcional:
md5sum -cU
snort-2.8.3.1.tar.gz.md5
tar -xvf snort-2.8.3.1.tar.gz
cd snort-2.8.3.1
Una vez descomprimidas las fuentes, decidimos dónde nos dejará los registros y las alertas. Además, siempre podemos registrarlo todo en /var/log/snort/ o configurar una ruta escalable más flexible. Snort soporta una amplia variedad de bases de datos que nos permite centralizar fácilmente la información.
La elección dependerá de lo que queramos hacer y de la cantidad de tráfico con la que pensemos trabajar. Un cálculo sencillo puede ser multiplicar por 10 el nivel de tráfico estimado. La mayoría de las veces la gente se sorprende de cómo un mínimo tráfico puede sobrecargar con facilidad nuestro sistema de registros si no se está prevenido.
En este ejemplo instalamos MySQL como base de datos para Snort. Si quieres utilizar otra base de datos, se puede compilar el soporte para la misma mediante las opciones disponibles para ./configure.
./configure
—with-mysql
make
sudo make install
Para ver un listado completo de las opciones soportadas ejecutaremos
./configure -h.
Si se producen errores durante la compilación, quizá sea porque nos faltan algunos archivos de cabecera
necesarios. En particular, hay que asegurarse de tener pcre.h, pcap.h, pcapbpf. h y mysql.h en el directorio /usr/include. Si no se encuentran estos archivos, algunas de las dependencias pueden no instalarse correctamente Es posible además que tengamos problemas con el archivo libpcap.so. En determinadas distribuciones tenemos que recrear este enlace simbólico mediante
ln -sU
/usr/lib/libpcap.so.<versión>
/usr/lib/libpcap.so
Una vez hecho make y make install, damos los últimos toques antes de pasar a la configuración de la base de datos MySQL. Hay que crear un usuario para Snort (no querremos que el servicio se ejecute como root, ¿verdad?). Para crear un nuevo usuario, ejecutamos los siguientes comandos:
groupadd snortgrp
useradd -g snortgrp snortusr
Con ellos creamos el grupo snortgrp y el usuario snortusr. Antes de continuar debemos asegurarnos de que nos encontramos en el directorio desde el que hemos descomprimido Snort. Los siguientes comandos nos
sirven para crear los directorios necesarios para los archivos de configuración, reglas y registros de Snort, y copiar los archivos necesarios al recién creado directorio /etc/snort.
mkdir -p /etc/snort/rules
mkdir /var/log/snort
touch /var/log/snort/snort.log
touch /var/log/snort/alert
chown -R snortusr.snortgrp
/var/log/snort
cp etc/* /etc/snort/
Para descargar las últimas reglas debemos conectarnos al sitio web de Snort
y registrarnos. El sitio ofrece opciones de registro tanto gratuita como de pago, dependiendo de cómo de actualizado necesitemos nuestro juego de reglas. Las reglas para los miembros con suscripción de pago se actualizan 30 días antes que las de los usuarios normales.
Es mejor no usar las reglas proporcionadas por la versión liberada, ya que caducan rápidamente ante nuevos ataques. Una vez nos hemos registrado (o suscrito), ya podemos descargar el nuevo juego de reglas para descomprimirlas en /etc/snort/rules. No hay que olvidarse de la comprobación del tar con md5sum.
Preparación de la Base de Datos
Ahora que ya hemos instalado el sistema básico, ha llegado el momento de preparar la base de datos. Una vez tengamos en ejecución el servidor de MySQL (lo podemos comprobar con ps -A | grep mysqld to check), podemos empezar con la configuración. La configuración de la base de datos se divide en varios apartados. Primero debemos elegir una contraseña adecuada, crear la base de datos necesaria y definir la estructura de las tablas. Nos conectamos como root al servicio de MySQL y creamos la base de datos y los permisos para snortusr. Para abrir la línea de comandos de MySQL ejecutaremos mysql -u root -p desde la terminal. Luego se nos pide la contraseña del usuario root y entramos al intérprete de mysql>. En él introducimos los siguientes comandos para la finalización del primer apartado de la configuración (hemos de asegurarnos de que cada línea termina con un punto y coma “;”). Nos cercioraremos de que las contraseñas que creemos aguantarán bien un posible ataque por fuerza bruta. Se recomienda usar un mínimo de ocho caracteres y que contengan mayúsculas, minúsculas y caracteres especiales.
create database snort;
grant INSERT, SELECT on root.*
to snort@localhost;
set PASSWORD for
snort@localhost=PASSWORD
(‘ConTR4sEña_3leg|da’);
grant CREATE, INSERT, SELECT,
DELETE, UPDATE on snort.* to
snort@localhost;
grant CREATE, INSERT, SELECT,
DELETE, UPDATE on snort.* to
snort;
Cada uno de los comandos debería devolver una respuesta Query OK. En la segunda parte de la configuración le
pasamos al intérprete de MySQL un script sencillo. Hemos de asegurarnos de que nos encontramos en el directorio donde descomprimimos Snort. Ejecutamos entonces el siguiente comando:
mysql -u root -p schemas
/create_mysql snort
Una vez que hemos completado ambos pasos, verificamos que todas las piezas se encuentran en su sitio. Para confirmar que todo está bien, entramos en el intérprete de MySQL como el usuario de Snort que creamos antes. Comprobamos la base de datos y la estructura de tabla con los siguientes comandos:
show databases;
use snort;
show tables;
exit
Después de preparar la base de datos, ya estamos listos para empezar a configurar Snort.
C O N F I G U R A C I O N
Una vez finalizados todos los preparativos, ha llegado el momento de sumergirnos en la configuración de Snort. El archivo principal de configuración, snort.conf El archivo snort.conf es el eje central en la configuración de Snort. se encuentra en el directorio /etc/ snort. Abrimos este archivo con un editor de nuestra elección y echamos un vistazo a las distintas secciones. Con el archivo de configuración podemos
usar muchos trucos útiles para la configuración de nuestro IDS. Por ejemplo, necesitaremos añadir información acerca de la red y los servidores, de forma que Snort pueda relacionar las reglas correctamente.
Para garantizar que el sistema monitoriza el tráfico adecuado, las variables HOME_NET y EXTERNAL_NET deben reflejar la infraestructura de la red. En una red simple, HOME_NET probablemente se defina como un rango de IPs privado, como 192.168.0.0/24. Esto implica que todo el tráfico originado en el rango de IPs 192.168.0.1- 255 se considerará tráfico interno. Estos detalles variarán dependiendo de cada
configuración. Si en nuestra red interna hay varias subredes, podemos añadirlas todas separándolas con comas. La entrada EXTERNAL_ NET es un listado de direcciones específicas que se considerarán externas. La
forma más sencilla de configurarla es usando el valor !$HOME_NET, que Snort entenderá como “cualquier dirección distinta de HOME_NET”. Especificamos la ubicación de las reglas de Snort mediante el archivo de configuración. Suponiendo que hemos descargado las reglas en /etc/snort/rules, añadimos esta ¿misma ruta a la variable RULE_PATH. La última variable a configurar, pero no menos importante, es la usada por el IDS para guardar la información en la base de datos. Cerca del final del archivo snort.conf hay una sección para configurar la salida de los plugins. Debemos descomentar la línea output database: log,mysql ~ y reemplazarla por la localización de la base de datos MySQL, en mi ejemplo:
Una vez finalizada la configuración, ya tenemos la base de un servidor funcional. De todas formas, aún hay que configurar Snort para que se inicie durante el arranque del sistema y asegurarnos de que se ejecuta bajo la recién creada cuenta del usuario snortusr.
Llegados a este punto, podemos probar Snort desde la línea de comandos con snort -u snortusr -g snortgrp -c /etc/snort/snort.conf. Snort se ejecutará bajo las credenciales proporcionadas y comenzará a registrar o alertarnos sobre todo el tráfico capturado. Al terminar, mostrará estadísticas sobre la sesión, como a las que a mi arrojo:
El reporte en pantalla no está mal, pero tampoco es la mejor solución. Para hacer que Snort arranque al inicio, insertaremos un sencillo script en el directorio /etc/init.d. Para crear el script, abrimos nuestro editor favorito e introducimos las líneas:
#!/bin/bash
#
# Script de inicio de Snort
-/etc/init.d/snortstart
#
/usr/local/bin/snort -Dq -u
snortusr -g snortgrp -c
/etc/snort/snort.conf
Una vez colocado el script, ejecutamos chmod +x /etc/init.d/snortstart para que éste sea ejecutable, y update-rc.d /etc/init.d/snortstart defaults 95 para crear los enlaces simbólicos necesarios para los distintos niveles de ejecución. El proceso puede diferir dependiendo de la distribución de Linux que estemos usando.
R E G L A S
Snort proporciona una selección de reglas de filtrado para el tráfico no deseado. Las mayoría de las reglas de Snort son de fácil comprensión y modificación. Cada regla consta de dos secciones: la cabecera y las opciones.
La cabecera describe el mensaje que se mostrará al dispararse la acción. La opción contiene palabras clave para indicar a Snort cómo debe inspeccionar el paquete, así como referencias útiles para la investigación, que se mostrarán cada vez que se dispare una alerta.
Un ejemplo:
alert tcp $EXTERNAL_NET any
->$HTTP_SERVERS
$HTTP_PORTS(msg:”WEB-IIS
unicode directorytraversal
attempt”; flow:to_
server,established;content:”/
..%c1%1c../”; nocase;
reference:cve,2000-0884;
reference:nessus,10537;#
classtype:
web-application-attack;#
sid:982; rev:13
En la regla anterior, la cabecera incluye el comando alert tcp $EXTERNAL_NET any ->$HTTP_SERVERS $HTTP_PORTS. Esta cabecera le dice a Snort que alerte cuando se dispare la regla y que examinte sólo el tráfico proveniente de las redes externas (desde cualquier puerto) y dirigido a los servidores http internos (a los puertos http configurados). Aunque esta declaración de alerta podría parecer obvia, a veces puede que sólo queramos registrar el tráfico en la base de datos, o incluso hacer cosas más avanzadas con las acciones dynamic y activate. Si estamos usando Snort como IPS (Intrusion Prevention System) integrado, podemos usar las opciones Drop, Reject o Sdrop para gestionar el tráfico no deseado. Snort puede comprobar paquetes TCP, UDP, IP e ICMP, dependiendo de nuestras necesidades. Si la regla especifica TCP, y entra un paquete UDP, incluso aunque el resto de la cabecera de la regla y las opciones encajasen perfectamente, Snort no realizaría ninguna acción. Nuestra regla especifica TCP, perfectamente estándar para el tráfico http. La siguiente parte de la cabecera llama a algunas de las variables que definimos en el archivo de configuración de Snort. La regla examinará el tráfico proveniente de la variable $EXTERNAL_NET desde cualquier puerto. La flecha “->” indica el sentido del tráfico. En este caso, la regla es aplicable a todo lo que venga desde cualquier dirección de $EXTERNAL_NET y cualquier puerto de $HTTP_PORTS. El sentido del tráfico es muy importante. En este caso, las respuestas provenientes de los servidores $HTTP_SERVERS serán ignoradas, ya que no concuerdan con el sentido indicado en la regla.
El resto ya son las opciones de la regla. La sección de opciones comienza diciéndole a Snort qué mensaje mostrar en la alerta. En este caso, la regla insta a Snort a mostrar WEB-IIS unicode directory traversal attempt en el registro o la base de datos, y también en la alerta. Después de este comando llega la parte más importante de las opciones de la regla: la parte encargada de decidir el tráfico a seleccionar. La etiqueta flow indica a Snort que sólo debe examinar los paquetes enviadosal servidor de destino una vez iniciada la sesión. Este requisito evita que Snort examine también el saludo de tres fases SYN, SYN-ACK, ACK que inicializa la conexión. Enun IDS con mucha carga, eliminar de la regla de comprobación el tráfico de los preliminares puede suponer una mejora muy significativa en el rendimiento del sistema. En la sección content es donde verdaderamente radica el meollo de la regla. Dicho de otro modo, Snort tomará el valor de la etiqueta content y la comparará con las peticiones enviadas al servidor. La regla del ejemplo anterior busca la cadena /..%c1%1c../. Esta cadena utiliza unicode para ocultar un intento de acceso transversal a otro directorio. La mayoría de los sistemas ya son inmunes a este tipo de ataques, pero aún así se siguen viendo muchos con la intención de explotar esta vulnerabilidad. El comando nocase que sigue a la etiqueta content indica a la regla que debe ignorar la capitalización del texto a la hora de buscar las coincidencias en el contenido. La última etiqueta es classtype. La información contenida en ella indica a Snort el nivel de prioridad del evento. En este caso, el classtype de web-application-attack indica una prioridad alta. Estos niveles es más fácil explorarlos y configurarlos a través del archivo classifications.config. Para ver cómo queda el listado de reglas activas, echamos un ojo de nuevo a /etc/ snort/snort.conf y examinamos las reglas que proporcionan una vista general del tráfico entrante. Para ajustar las alertas hasta un nivel manejable y garantizar que monitorizamos los servicios correctos, podemos modificar el listado de reglas. Creando un listado más centralizado reducimos la cantidad de paquetes perdidos y mejoramos el rendimiento. Las reglas que dejaremos activas serán las que dependan de la infraestructura de nuestra red y nuestros requerimientos en general. Para reducir una sobrecarga innecesaria, desactivamos todas las reglas sobrantes para servicios y protocolos que en realidad
no usamos. Por defecto ya hay varias reglas deshabilitadas. Muchas de ellas pueden, ocasionalmente, causar falsos positivos, aunque es posible que queramos habilitar algunas para propósitos específicos. Una vez ajustada la lista a nuestras necesidades, invertimos algo de tiempo proporcionando la información sobre servicios específicos. Como puede observarse, Snort ofrece una serie de variables para simplificar la tarea de confeccionar las reglas. Sin dichas variables, si nuestra empresa tuviese varios servidores http a la escucha en puertos distintos del 8 (por ejemplo, el 8080), tendríamos que editar cada una de las reglas de Snort para alterar
el puerto http y cambiarlo por el 8080. Es más, tendríamos que modificar cada regla en cada actualización de un juego de reglas. En vez de eso, podemos usar las variables de Snort para definir el valor de $HTTP_PORTS
a 8080. Así podemos ejecutar los servidores en cualesquiera puertos sin tener que editar siempre las correspondientes reglas. Para cambiar el valor de $HTTP_PORTS a 8080, editamos el archivo snort.conf del siguiente modo:
var HTTP_SERVERS
[10.10.10.100/32,10.10.10.111/
32]
var HTTP_PORTS [80,8080]
También es posible definir un rango de puertos, en vez de una lista, usando dos puntos (por ejemplo, 8000:8080).
El archivo snort.conf incluye también variables predefinidas para los servicios HTTP, AIM y Oracle. Además podemos añadir nuestras propias variables en caso de planear usarlas con otros servicios. Proporcionar a Snort la información sobre dónde y cómo se configuran los servicios de nuestra red permite a nuestro IDS reducir la sobrecarga, restringiendo las comprobaciones de tráfico a una serie de paquetes determinados. ¿Para qué
vamos a comprobar el tráfico SMTP dirigido a un sistema que sólo ofrece servicios de SSH o FTP? En redes de mayor tamaño, nunca se puede estar seguro al 100% de qué tráfico viaja por los cables. Podría resultar que hay un servicio SMTP ejecutándose en un esquivo servidor, en lo más recóndito de la empresa, desde los inicios de su historia. Snort también nos permite crear reglas personalizadas. La mejor forma de aprender a crear nuevas reglas es viendo una ya hecha. Después de examinar unas pocas, podemos escoger alguna que se parezca mucho a lo que necesitamos y modificarla. Lo más frecuente es añadir las nuevas reglas personales al archivo local.rules para probarlas. Haciéndolo, las protegemos de sobreescrituras producidas al actualizar un nuevo
juego de reglas. Las reglas personales nos vienen muy bien en situaciones en las que aún no se ha publicado el parche para alguna vulnerabilidad conocida. Al añadir una de estas reglas, dotamos a nuestro IDS/IPS de una capa adicional de protección o, al menos, de un sistema de detección por si el problema aparece.
R E G I S T R O S Y A L E R T A S
Snor ya está marcando y registrando tráfico, y guardando alertas en la base de datos MySQL. Tener una base de datos llena de alertas y tráfico registrado es estupendo, sin embargo, recibir una alerta en nuestro escritorio cuando alguien nos escanea los puertos es mejor aún. Por desgracia, Snort no proporciona ninguna solución integrada para enviar alertas a un escritorio remoto. Como ocurre con muchos otros proyectos *nix, sin embargo, es fácil hacer que Snort interactúe con otras utilidades. Dos de los posibles candidatos
son Swatch y Logsurfer.
D E T E C C I O N O P R E V E N C I O N
Snort ofrece varias opciones para la prevención (y detección) de intrusiones. Los tres modos principales para la prevención de intrusiones son el filtrado integrado, la cooperación con un cortafuegos existente basado en iptables y el modo TCP-RST. Cuando Snort trabaja como filtro integrado, todo el tráfico debe pasar a través del
sistema con Snort antes de que llegue a la red interna. Si el tráfico dispara una regla de Snort, se desechan los paquetes que la activaron. La solución integrada ofrece seguridad avanzada a modo de cortafuegos con un juego de reglas actualizado regularmente. Aún con todo, la prevención de intrusiones puede impedir el acceso a los sistemas debido a falsos positivos, o ralentizar la red en caso de que haya más tráfico del que el sensor de Snort fuese capaz de manejar. Para el modo integrado, tendremos que añadir — enable-inline a la hora de hacer ./configure. Si ya disponemos de un cortafuegos basado en iptables, podemos configurar Snort para modificar reglas dinámicamente. La opción de iptables reduce algunos de los retardos en el tráfico entrante, pero en general, el sistema será más lento en la respuesta a los ataques. Cada vez que el tráfico malicioso dispara una alerta, Snort envía un comando al sistema que tiene iptables para que bloquee al atacante. Este estilo de IPS, si no se configura correctamente, podría ser manipulado por un atacante con dotes creativas para provocar una denegación de servicio a nuestros propios sistemas. Si un atacante falsease tráfico malicioso para que pareciese provenir de la pasarela de nuestro proveedor de servicios de internet, o desde nuestro servidor de DNS, podría acabar poniendo servicios necesarios en la lista negra. Para combatirlo, usamos una lista blanca con direcciones que nunca banearemos. Como contrapartida, un atacante que conociese alguna de las direcciones de nuesnuestra lista blanca podría falsear ataques para que pareciesen venir desde una dirección en la que confiamos, sin temor a quedar bloqueado. La última opción es permitir a Snort desconectar las conexiones no deseadas mediante el envío de paquetes TCP-RST (a través del arche flexresp2). Con esto podemos terminar una conexión no deseada desde ambos extremos de la misma. De todas formas, esta solución provoca una condición de carrera entre nuestro IPS y el tráfico malicioso. El IPS tratará de cerrar la conexión antes de que el atacante complete el ataque. El atacante tiene una ventaja en este caso, debido a que el tráfico malicioso ya se encuentra dentro de nuestra red antes de que Snort pueda actuar. Este modo de operar previene ciertos ataques, pero puede resultar menos fiable que las otras técnicas. La configuración de nuestro IDS/IPS dependerá de nuestros requisitos en materia de seguridad. Si pretendemos instalar un Snort como IPS, primero probaremos el servidor en modo IDS hasta haber ajustado bien la configuración y haber reducido el número de falsos positivos.
Una vez satisfechos con la configuración, ya podemos dejar que Snort asuma su nuevo rol de sistema de prevención.
D E P E N D E N C I A S
Libpcap
• Libpcap-dev
• PCRE
• PCRE-dev
• Libnet-1.0.2.a
• MySQL-Server-5.0 (para MySQL)
• MySQL-client (para MySQL)
• MySQL-dev (para MySQL)
Eso es todo. Esta algo laborioso, me tarde un ratito en dejarlo a punto, seguro ustedes con este apoyo pueden configurar a Snort de mejorar manera.
Saludos
WWW.LINUX-MAGAZINE.ES