Detección de Intrusiones con SNORT

ADMINISTRACIÓN • Snort

60 Número 46 W W W . L I N U X - M A G A Z I N E . E S

Hace poco implementamos un Sis-

tema de Detección de Intrusos (IDS)

para una granja de webs alojada

remotamente. Tras la configuración inicial,

comenzamos a hacer pruebas y a optimizar

el sistema. Tan pronto como se conectó,

detectamos un tipo de tráfico que no debería

pasar del DMZ. El cortafuegos controlado

por el ISP estaba mal configurado y permitía

la entrada de casi todo el tráfico.

Durante el poco tiempo en que estuvo el

test en funcionamiento, el IDS registró un

gran número de escaneos de puertos e inten-

tos de acceso a los servidores principales. Era

W W W . L I N U X - M A G A Z I N E . E S60

obvio, observando estos logs, que los servi-

dores no estaban recibiendo la atención ade-

cuada.

La moraleja de esta historia es que siem-

pre hay que tener un ojo puesto en la red.

Incluso aunque no tengamos el problema de

un cortafuegos mal configurado, nuestros

sistemas pueden beneficiarse de la vigilancia

de un IDS. En el nivel más básico, lo que un

IDS hace es capturar todo el tráfico de una

red. Luego compara el contenido de los

paquetes con reglas específicas para ver si

existen vulnerabilidades conocidas o código

malicioso.

Cada vez que el IDS encuentra una coinci-

dencia en una regla, se dispara una acción

preconfigurada. La acción varía depen-

diendo de la configuración de dicha regla,

aunque en modo IDS básico, el sistema sim-

plemente registra el tráfico peligroso o envía

una alerta. Un sensor, es decir, un equipo

situado en el perímetro de la red, permanece

vigilante al tráfico que el cortafuegos deja

pasar; con otro sensor, situado en el exterior

del cortafuegos, se pueden ver los intentos

de acceso.

Snort [1] es un IDS alternativo de código

abierto, y al igual que otros proyectos de

código abierto, cuenta ahora con una rama

corporativa, Sourcefire [2]. Lo bueno es que

Snort sigue estando disponible bajo licencia

GPL.

Búsqueda de ataques ocultos con el sistema de detección de intrusos

Snort. POR CHRIS RILEY

SEGURIDAD SNORT

pcp

ho

tos, F

oto

lia

Detección de Intrusiones con Snort

Snort • ADMINISTRACIÓN

61Número 46W W W . L I N U X - M A G A Z I N E . E S

Para ver un listado com-

pleto de las opciones

soportadas ejecutaremos

./configure -h. Si se produ-

cen 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, pcap-

bpf.h y mysql.h en el

directorio /usr/include. Si

no se encuentran estos

archivos, algunas de las

dependencias pueden no

instalarse correctamente

(Listados 1 y 2). Es posi-

ble además que tengamos problemas con el

archivo libpcap.so. En determinadas distri-

buciones tenemos que recrear este enlace

simbólico mediante

ln -sU

/usr/lib/libpcap.so.<versión>U

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

mos asegurarnos de que nos encontramos

en el directorio desde el que hemos descom-

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

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

/var/log/snort

cp etc/* /etc/snort/

Para descargar las últimas reglas debemos

conectarnos al sitio web de Snort [1] y regis-

trarnos. El sitio ofrece opciones de registro

En este artículo explicamos cómo usar

Snort para vigilar nuestra red.

InstalaciónLa 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.

En el momento de escribir estas líneas, la

última 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 sis-

tema. Para compilarlo necesitaremos el tar-

ball con las fuentes y, opcionalmente, la

suma MD5 que usaremos para comprobar la

integridad del paquete.

wget http://www.snort.org/U

dl/snort-2.8.3.1.tar.gz

Opcional:

wget http://www.snort.org/U

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

mos dónde nos dejará los registros y las aler-

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

ción. La elección dependerá de lo que quera-

mos 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 quiere utilizarse

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

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

damente ante nuevos ataques. Una vez nos

hemos registrado (o suscrito), ya podemos

descargar el nuevo juego de reglas para des-

comprimirlas en /etc/snort/rules. No hay que

olvidarse de la comprobación del tar con

md5sum.

Preparación de la Base deDatosAhora que ya hemos instalado el sistema

básico, ha llegado el momento de preparar la

base de datos. Una vez tengamos en ejecu-

ció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 debe-

mos elegir una contraseña adecuada, crear la

base de datos necesaria y definir la estruc-

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

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

Figura 1: El archivo snort.conf es el eje central en la

configuración de Snort.

que por fuerza bruta. Se recomienda usar un

mínimo de ocho caracteres y que contengan

mayúsculas, minúsculas y caracteres espe-

ciales.

create database snort;

grant INSERT, SELECT on root.*U

to snort@localhost;

set PASSWORD for U

snort@localhost=PASSWORDU

(‘ConTR4sEña_3leg|da’);

grant CREATE, INSERT, SELECT,U

DELETE, UPDATE on snort.* toU

snort@localhost;

grant CREATE, INSERT, SELECT,U

DELETE, UPDATE on snort.* toU

snort;

exit

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

primimos Snort. Ejecutamos entonces el

siguiente comando:

mysql -u root -p schemasU

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

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

mos listos para empezar a configurar Snort.

Configuración de SnortUna 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 (Figura

1), 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 infraes-

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

NAL_NET es un listado de direcciones espe-

cí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 guar-

dar la información en la base de datos. Cerca

del final del archivo snort.conf hay una sec-

ción para configurar la salida de los plugins.

Debemos descomentar la línea output data-

base: log,mysql ~ y reemplazarla por la

localización de la base de datos MySQL

(Figura 2).

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

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

zará a registrar o alertarnos sobre todo el trá-

fico capturado. Al terminar, mostrará estadís-

ticas sobre la sesión (Figura 3). 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 directo-

rio /etc/init.d. Para crear el script, abrimos

nuestro editor favorito e introducimos las

líneas:

#!/bin/bash

#

# Script de inicio de SnortU

-/etc/init.d/snortstart

#

/usr/local/bin/snort -Dq -u U

snortusr -g snortgrp -c U

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

Reglas para SnortSnort proporciona una selección de reglas de

filtrado para el tráfico no deseado. Las mayo-

ría de las reglas de Snort son de fácil com-

prensión y modificación. Cada regla consta

de dos secciones: la cabecera y las opciones.

La cabecera describe el mensaje que se mos-

trará al dispararse la acción. La opción con-

tiene palabras clave para indicar a Snort

Figura 2: Configuración de la conexión MySQL en snort.conf.

Figura 3: Snort muestra estadísticas sobre

la sesión al finalizar.

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.

Veamos un ejemplo:

alert tcp $EXTERNAL_NET anyU

->$HTTP_SERVERS U

$HTTP_PORTS(msg:”WEB-IIS U

unicode directorytraversal U

attempt”; flow:to_ U

server,established;content:”/ U

..%c1%1c../”; nocase; U

reference:cve,2000-0884; U

reference:nessus,10537;#

classtype:U

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

dos). 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 esta-

mos usando Snort como IPS (Intrusion Pre-

vention System) integrado, podemos usar las

opciones Drop, Reject o Sdrop para gestionar

el tráfico no deseado. Snort puede compro-

bar paquetes TCP, UDP, IP e ICMP, depen-

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

mente, 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 varia-

ble $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 igno-

radas, ya que no concuerdan con el sentido

indicado en la regla.

El resto ya son las

opciones de la regla.

La sección de opcio-

nes comienza dicién-

dole a Snort qué

mensaje mostrar en

la alerta.

En este caso, la

regla insta a Snort a

mostrar WEB-IIS uni-

code directory traver-

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

dos al servidor de destino una vez iniciada la

sesión. Este requisito evita que Snort exa-

mine también el saludo de tres fases SYN,

SYN-ACK, ACK que inicializa la conexión. En

un IDS con mucha carga, eliminar de la regla

de comprobación el tráfico de los prelimina-

res puede suponer una mejora muy signifi-

cativa en el rendimiento del sistema.

En la sección content es donde verdadera-

mente radica el meollo de la regla. Dicho de

otro modo, Snort tomará el valor de la eti-

queta content y la comparará con las peticio-

nes enviadas al servidor. La regla del ejem-

plo anterior busca la cadena /..%c1%1c../.

Esta cadena utiliza unicode para ocultar un

intento de acceso transversal a otro directo-

rio. La mayoría de los sistemas ya son inmu-

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

cias en el contenido.

La última etiqueta es classtype. La infor-

mació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 rendi-

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

saria, desactivamos todas las reglas sobran-

tes para servicios y protocolos que en reali-

dad no usamos.

Por defecto ya hay varias reglas deshabili-

tadas. Muchas de ellas pueden, ocasional-

mente, 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 80

(por ejemplo, el 8080), tendríamos que edi-

tar cada una de las reglas de Snort para alte-

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

[10.10.10.100/32,10.10.10.111/U

32]

var HTTP_PORTS [80,8080]

También es posible definir un rango de puer-

tos, en vez de una lista, usando dos puntos

(por ejemplo, 8000:8080).

Snort • ADMINISTRACIÓN

63Número 46W W W . L I N U X - M A G A Z I N E . E S

Figura 4: Configuración del acceso a MySQL desde la página de

configuración BASE.

tema de detección por si el pro-

blema aparece.

Los Preprocesadoresde SnortLos preprocesadores, los cuales

podemos activar y desactivar a

través de snort.conf, permiten a

Snort la manipulación del tráfico

entrante. Snort activa automáti-

camente varios preprocesadores para el tra-

tamiento del tráfico fragmentado, la inspec-

ción del flujo con control de estado, la moni-

torización del rendimiento, la decodificación

del tráfico RPC, la monitorización del tráfico

ftp/telnet/SMTP/DNS/SMB y el escaneo de

puertos. Hay incluso un preprocesador espe-

cialmente diseñado para el troyano Back Ori-

fice. Cada preprocesador tiene su propio

juego de opciones y configuraciones. Las

opciones y configuraciones predeterminadas

deberían bastar como punto de partida, pero

para sacar el máximo partido a nuestro IDS

debemos invertir algún tiempo en la

configuración del preprocesador. En particu-

lar, el preprocesador sfPortscan puede gene-

rar falsos positivos si se configura de forma

inadecuada. Si comenzamos a recibir falsos

positivos, podemos deshabilitar fácilmente

sfPortscan desde snort.conf.

En el caso de servidores con poca RAM,

podríamos tener que ajustar algunas confi-

guraciones relacionadas con la memoria del

preprocesador. Por ejemplo, el preprocesa-

dor frag3 usa 64MB de RAM de forma prede-

terminada para el almacenamiento y reen-

samblado del tráfico fragmentado. Aunque

64MB no parezca mucho para un servidor

de hoy día, se puede apreciar que, aña-

diendo varios procesadores, se puede llegar

a hacer mella en el rendimiento de un servi-

dor. Por contra, si se dispone de una canti-

dad de RAM más que suficiente, podemos

incrementar la memoria disponible para

garantizar que el tráfico fragmentado no se

convierte en un problema en entornos con

una carga elevada.

Registros y AlertasNuestro IDS 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 nin-

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

Hay otros productos disponibles para la

visualización de los datos de Snort en forma

de gráficos y estadísticas. Uno de los siste-

mas más populares es BASE [3] (Basic

Analysis and Security Engine). Descargamos

la versión 1.3.9 de BASE desde el sitio web

del proyecto. Para comenzar con este sis-

tema necesitamos tener instalado Apache y

PHP en el servidor. BASE depende además

de ADOdb [4] para el acceso a la base de

datos a través de PHP. Por razones de seguri-

dad y rendimiento, siempre es mejor insta-

larlo todo en un sistema distinto del sensor

de Snort.

Ninguna consola de administración es

buena si no podemos acceder a ella cuando

el IDS está ocupado con otro tráfico. A veces

lo mejor es tener una segunda interfaz de red

en el sensor de Snort dedicada especial-

mente para la monitorización y la gestión.

Una vez instalados los paquetes de Apache,

PHP y ADOdb, hemos de descomprimir los

fuentes de BASE en /var/www/base.

LLegados a este punto, cambiamos los

permisos del directorio /var/www/base de

modo que todo el mundo pueda escribir en

él (chmod 777). Es una práctica terrible en

cuanto a seguridad se refiere, pero sólo lo

necesitaremos así durante el proceso de

configuración. Luego podemos dirigirnos a

nuestra página web de BASE, http://

nuestro_servidor/base, y configurar el acceso

El archivo snort.conf incluye también

variables predefinidas para los servicios

HTTP, AIM y Oracle. Además podemos aña-

dir nuestras propias variables en caso de pla-

near usarlas con otros servicios.

Proporcionar a Snort la información

sobre dónde y cómo se configuran los ser-

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

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

tá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 probar-

las. Haciéndolo, las protegemos de sobrees-

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

dad conocida. Al añadir una de estas reglas,

dotamos a nuestro IDS/IPS de una capa adi-

cional de protección o, al menos, de un sis-



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

Listado 1: Dependencias deSnort

Para instalar un servidor de Snort es

importante tener en cuenta qué trafico

esperamos manejar. Snort puede ejecu-

tarse en casi cualquier tipo de hard-

ware. Pero de todos modos, si quere-

mos tener un IDS rápido y fiable sin un

alto porcentaje de paquetes perdidos,

Snort necesitará un procesador relati-

vamente potente. Sobra decir que nece-

sitaremos además espacio de almace-

namiento para los registros y alertas. El

elemento más crítico, sin embargo, es

una buena interfaz de red. Siempre que

nos sea posible, nos aseguraremos de

que la interfaz de red es dedicada, y

nunca integrada en la placa base. La

mayoría de los fabricantes actuales

ofrecen una tarjeta de red especial para

servidores, con un procesador inte-

grado específicamente diseñado para el

procesamiento del tráfico de red.

Mejorando el Servidor

Figura 5: Arte ASCII de la vieja escuela: Ojo al cerdito de

la izquierda.

snort -vd -rU

snort.log.1206804587U

not host 192.168.0.1

Prevención o DetecciónSnort ofrece varias opciones para la preven-

ción (y detección) de intrusiones. Los tres

modos principales para la prevención de

intrusiones son el filtrado integrado, la coo-

peración con un cortafuegos existente

basado en iptables y el modo TCP-RST.

Cuando Snort trabaja como filtro inte-

grado, 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 acti-

varon. La solución integrada ofrece seguri-

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

ral, el sistema será más lento en la respuesta

a los ataques. Cada vez que el tráfico mali-

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

tivas para provocar una denegación de servi-

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

bar poniendo servicios necesarios en la lista

negra. Para combatirlo, usamos una lista

blanca con direcciones que nunca baneare-

mos. Como contrapartida, un atacante que

conociese alguna de las direcciones de nues-

tra lista blanca podría falsear ataques para

que pareciesen venir desde una dirección en

la que confiamos, sin temor a quedar blo-

queado.

La última opción es permitir a Snort des-

conectar las conexiones no deseadas

mediante el envío de paquetes TCP-RST (a

través del parche flexresp2). Con esto

podemos terminar una conexión no dese-

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

tos ataques, pero puede resultar menos fia-

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

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

ConclusiónSnort tiene muchas otras funcionalidades

aún por descubrir. Por ejemplo, nunca men-

cionamos el cerdito en arte ASCII retro

(Figura 5).

Hay muchos libros y recursos en línea que

nos ayudarán a iniciarnos en el sistema de

detección de intrusos Snort. El sitio web del

proyecto Snort contiene un gran número de

documentos para ayudarnos a resolver pro-

blemas. También aqui disponemos de un

foro en el que encontraremos noticias y asis-

tencia al usuario. �

a la base de datos (Figura 4). Habremos de

introducir la ruta a los archivos de ADOdb,

así como el nombre del servidor MySQL, el

nombre de usuario y la contraseña.

Si la página web de BASE dice que no

tiene permiso de escritura sobre los archivos

de configuración, comprobaremos el chmod

que acabamos de ejecutar. BASE añade con-

tenido a la base de datos MySQL para regis-

trar los reportes y, una vez completados

éstos, la instalación estará completa. Si tene-

mos problemas, probablemente tengamos

que descomentar la extensión mysql.so de

nuestro archivo php.ini. No hay que olvidar

restablecer los permisos al directorio /var/

www/base para que sea legible por nuestro

servidor Apache. Es importante que desta-

quemos que BASE no proporciona ninguna

seguridad integrada para la interfaz web. Por

lo que, de ser posible, habilitaremos SSL y

nos aseguraremos de que hay un archivo

.htpasswd en el directorio de BASE.

Además de en la base de datos, encontra-

remos registros y alertas en /var/log/snort.

Estos archivos de registro contienen los

datos de registro completos en formato

tcpdump. Si así lo quisiésemos, podríamos

escribir un script para informarnos cada vez

que se registra una nueva alerta. Para traba-

jar con estos archivos, usamos snort -r para

procesar el archivo tcpdump y convertirlo en

algo más comprensible. Los parámetros -vd

proporcionan información adicional. Para

facilitar un poco las cosas, Snort soporta ade-

más el uso de BPF [5] (Berkeley Packet Fil-

ter) para filtrar la salida de la línea de coman-

dos.

snort -vd -rU

snort.log.1206804587U

tcp and src port 22



[1] Página de inicio de Snort: http://www.

snort.org

[2] Sourcefire: http://www.sourcefire.

com

[3] BASE: Basic Analysis and Security

Motor: http://base.secureideas.net

[4] ADOdb, librería de abstracción para

bases de datos para PHP: http://

adodb.sourceforge.net

[5] BPF (Berkeley Packet Filter): http://

tcpdump.org

RECURSOS

• apache(-ssl)

• php5

• php5-mysql

• php5-gd

• libphp-adodb

Listado 2: Dependencias deBASE

MD5 es una función de suma criptográ-

fica que proporciona una suma de 128

bits basada en el contenido de un

archivo. Al descargar un programa o un

documento, podemos usar el comando

md5sum para garantizar que el archivo

descargado es idéntico al original.

Md5sum compara el valor de la suma

de la descarga con una suma MD5 pro-

porcionada por la versión oficial. Son

muchos los proyectos de software que

proporcionan sumas MD5 de sus bina-

rios. El MD5 normalmente se encuentra

en la sección de descargas del sitio web

del proyecto. Esta comprobación nos

puede ayudar a evitar la instalación de

software dañado o malicioso.

¿Qué es MD5?

Detección de Intrusiones con SNORT

Documents

Transcript of Detección de Intrusiones con SNORT