CAPTULO 2

SNORT

1 Introduccin
El sistema que se ha elegido para el desarrollo del proyecto ha sido Snort [SNO04].
Snort (www.snort.org) es un sistema de deteccin de intrusiones basado en red (NIDS).
Su funcionamiento es similar al de un sniffer ya que monitoriza todo el trfico de la red
en bsqueda de cualquier tipo de intrusin. Implementa un motor de deteccin de
ataques y barrido de puertos que permite registrar, alertar y responder ante cualquier
anomala previamente definida como patrones.

Snort est disponible bajo licencia GPL, es gratuito y funciona bajo plataformas
Windows y GNU/Linux. Es uno de los ms usados y dispone de una gran cantidad de
filtros o patrones ya predefinidos, y actualizaciones constantes.

La primera versin de Snort (Snort-0.96), surgi en Diciembre de 1998. Su autor fue

Marty Roesch. La primera aproximacin de Snort fue APE, un programa para Linux
escrito en Noviembre de 1998, por Marty Roesch. Este programa tena carencias como
la falta de capacidad para trabajar en mltiples sistemas operativos o la de mostrar todos
los tipos de paquetes del mismo modo.

Fue en Diciembre de 1998, cuando Marty Roesch cre la primera versin de Snort
(Snort-0.96), que ya estaba desarrollada con libcap, lo que la dotaba de una gran
portabilidad. Esta primera versin era slo un sniffer de paquetes y no tena las
capacidades reales de un IDS/IPS. Sin embargo, a partir de aqu, se han ido sucediendo
numerosas versiones de Snort que han hecho de esta herramienta una de las ms
importantes en la seguridad software.

2 Elementos del sistema

Antes de iniciar la instalacin y configuracin de Snort es importante conocer los
elementos que lo componen. Tal y como muestra la figura 2-1, los elementos que
componen el esquema bsico de su arquitectura son:

Mdulo de captura del trfico. Es el encargado de capturar todos los paquetes

de la red utilizando la librera libpcap.

Decodificador. Se encarga de formar las estructuras de datos con los paquetes

capturados e identificar los protocolos de enlace, de red, etc.

Preprocesadores. Permiten extender las funcionalidades preparando los datos

para la deteccin. Existen diferentes tipos de preprocesadores dependiendo del
2 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

trfico que queremos analizar (por ejemplo, existen los preprocesadores http,
telnet)

Motor de Deteccin. Analiza los paquetes en base a las reglas definidas para
detectar los ataques.

Archivo de Reglas. Definen el conjunto de reglas que regirn el anlisis de los

paquetedes detectados.

Plugins de deteccin. Partes del software que son compilados con Snort y se
usan para modificar el motor de deteccin.

Plugins de salida. Permiten definir qu, cmo y dnde se guardan las alertas y
los correspondientes paquetes de red que las generaron. Pueden ser archivos de
texto, bases de datos, servidor syslog, etc.

Figura 2-1. Arquitectura de snort

Seguidamente se describir cada uno de los elementos que componen Snort:

2.1 Mdulo de captura de datos

El mdulo de captura de paquetes del sensor se encarga, tal y como su propio

nombre indica, de realizar la captura del trfico que circula por la red, aprovechando al
mximo los recursos de procesamiento y minimizando por tanto la prdida de paquetes
a tasas de inyeccin elevadas.

Para que los preprocesadores y posteriormente el motor de deteccin puedan

conseguir paquetes se deben realizar algunas tareas previas. Snort no tiene ninguna
facilidad nativa de paquetes an; por lo que requiere de una biblioteca de sniffing de
paquetes externa: libpcap. Libpcap fue escogida para la captura de paquetes por su
independencia de plataforma. Puede ser controlada sobre todas las combinaciones de
hardware y S.O.; e incluso sobre WIN32 con winpcap.
 Captulo 2. Snort 3

Debido a que Snort usa la biblioteca libpcap para capturar paquetes por la red, puede
utilizar su transportabilidad para ser instalado en casi todas partes. La utilizacin de
libpcap hace que Snort tenga un uso realmente independiente de plataforma.

La responsabilidad de capturar paquetes directamente de la tarjeta de interfaz de red

pertenece a libpcap. Esto hace que la facilidad de captura para paquetes raw
proporcionados por el sistema operativo est disponible a otras aplicaciones.

Un paquete raw es un paquete que se deja en su forma original, sin modificar

como haba viajado a travs de la red del cliente al servidor. Un paquete raw tiene toda
su informacin de cabecera de protocolo de salida intacta e inalterada por el sistema
operativo. Las aplicaciones de red tpicamente no tratan paquetes raw; estos dependen
del S.O. para leer la informacin del protocolo y expedir los datos de carga til
correctamente. Snort es inslito en este sentido, usa la informacin de cabecera del
protocolo que habra sido quitada por el sistema operativo para descubrir algunas
formas de ataques.

La utilizacin de libpcap no es el modo ms eficiente de adquirir paquetes raw. Ya

que slo puede tratar un paquete a la vez, ocasionando un cuello de botella para anchos
de banda altos (1Gbps). En el futuro, Snort probablemente pondr en prctica
bibliotecas de captura de paquetes especficas para un S.O. o incluso un hardware. Hay
otros mtodos adems de libpcap para capturar paquetes de una tarjeta de interfaz de
red. Como el Filtro de Paquete Berkeley (BPF), el Interfaz de Proveedor de Enlace de
transmisin (DLPI), y el mecanismo SOCK_PACKET en el kernel de Linux son otros
instrumentos para capturar paquetes raw.

2.2 Decodificador

El motor de decodificacin est organizado alrededor de las capas de la pila de

protocolos presentes en las definiciones soportadas de los protocolos de Enlace de Datos
y TCP/IP. Cada subrutina en el decodificador impone orden sobre los datos del paquete,
sobreponiendo estructuras de datos sobre el trfico de la red.

Snort posee capacidades de decodificacin para protocolos Ethernet, SLIP y PPP. Se

encarga de tomar los paquetes que recoge el libpcap y almacenarlos en una estructura de
datos en la que se apoyan el resto de capas.

En cuanto los paquetes han sido capturados, Snort debe descifrar los elementos de
protocolo especficos para cada paquete. El decodificador de paquetes es en realidad
una serie de decodificadores, de forma que cada uno descifra elementos de protocolos
especficos. Funciona sobre la pila de protocoles de Red, que comienza con el nivel ms
bajo: protocolos de la capa de Enlace de Datos, descifrando cada protocolo conforme
asciende en la pila de protocolos de red. Un paquete sigue este flujo de datos
movindose a travs del decodificador de paquetes, como se puede ver en la figura 2-2.
4 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Figura 2-2. Flujo de Datos del Decodificador

En cuanto los paquetes de datos son almacenados en una estructura de datos estn
listos para ser analizados por los preprocesadores y por el motor de deteccin.

2.3 Preprocesadores
Para comprender mejor lo que es un preprocesador en primer lugar hay que entender
la forma de comunicacin de un sistema. Como se puede ver en la figura 2-3, el
protocolo TCP/IP es un protocolo basado en capas. Cada capa del protocolo tiene una
funcionalidad determinada y para trabajar correctamente necesita una informacin
(cabecera). Por ejemplo, la capa de enlace utiliza para enviar y recibir datos las
direcciones MAC de los equipos, la capa de red utiliza las direcciones IP, etc.

Los datos que se transmiten por la red en paquetes de forma individual, pueden
llegar a su destino de forma desordenada, siendo el receptor el encargado de ordenar los
paquetes y darles sentido.

Figura 2-3. Capas TCP/IP

Como Snort tiene que leer todo el trfico de la red e interpretarlo tambin tiene que
llevar un control de los paquetes que se envan por la red y as poder darle forma a la
informacin. Por ejemplo, escucha todo el trfico que tiene como destino una direccin
y puertos determinados para ensamblar los datos y as poder interpretarlos.

Los Preprocesadores son componentes de Snort que no dependen de las reglas ya

que el conocimiento sobre la intrusin depende del mdulo Preprocesador. Se llaman
siempre que llegue un paquete y se les puede aplicar reglas que estn cargadas en Snort.
As pues, se encargan de coger la informacin que viaja por la red de una manera
 Captulo 2. Snort 5

catica y darle forma para que pueda ser interpretada la informacin. De esta forma una
vez que tenemos los datos ordenados que viajan por la red aplicaremos las reglas (rules)
para buscar un determinado ataque.

La arquitectura de preprocesadores de Snort consiste en pequeos programas C que

toman decisiones sobre qu hacer con el paquete. Estos pequeos programas C se
compilan junto a Snort en forma de librera. Estos preprocesadores son llamados justo
despus que Snort realice la Decodificacin, y posteriormente se llama al Motor de
Deteccin. Si el nmero de preprocesadores es muy alto el rendimiento de Snort puede
caer considerablemente.

Las configuraciones predeterminadas para estos subsistemas son muy generales, a

medida que experimentemos con Snort, podremos ajustarlas para obtener un mejor
rendimiento y resultados.

Seguidamente se muestra una lista de preprocesadores que incluye la versin 2.8 de

Snort:

frag3. El preprocesador frag3 se basa en la fragmetacin IP de los mdulos de

Snort. Frag3 est intentando reemplazar el mdulo de fragmentacin frag2 y fue
diseado con los objetivos siguientes:

1. Ejecucin ms rpida que frag2 con gestin de datos menos compleja.

2. Modelo de Host con tcnicas de antievasin.

Formato de Frag3:
preprocessor frag3_global
preprocessor frag3_engine

stream4 y stream4_reassemble. El mdulo Stream4 proporciona un flujo de

reensamblado TCP y capacidades de anlisis de Snort. Stream4 tambin da a
gran cantidad de usuarios la capacidad de rastrear muchas conexiones TCP
simultneas. Stream4 puede manejar 8192 conexiones simultneas TCP en su
configuracin por defecto; pero puede manejar ms de 100.000 conexiones
simultneas.

Formato de Stream4:
preprocessor stream4: [noinspect], [asynchronous_link], [keepstats
[machine|binary]], \
[detect_scans], [log_flushed_streams], [detect_state_problems], \
[disable_evasion_alerts], [timeout <seconds>], [memcap
<bytes>], \
[max_sessions <num sessions>], [enforce_state], \
[cache_clean_sessions <num of sessions>], [ttl_limit <count>], \
[self_preservation_threshold <threshold>], \
[self_preservation_period <seconds>], \
[suspend_threshold <threshold>], [suspend_period <seconds>], \
[state_protection], [server_inspect_limit <bytes>], \
[enable_udp_sessions], [max_udp_sessions <num sessions>], \
[udp_ignore_any]
6 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Formato de Stream4_reassemble:
preprocessor stream4_reassemble: [clientonly], [serveronly], [both], [noalerts], \
[favor_old], [favor_new], [flush_on_alert], \
[flush_behavior random|default|large_window], \
[flush_base <number>], [flush_range <number>], \
[flush_seed <number>], [overlap_limit <number>], \
[ports <portlist>], [emergency_ports <portlist>] \
[zero_flushed_packets], [flush_data_diff_size <number>] \
[large_packet_performance]

Flow. El mdulo Flow se propone para comenzar a unificar el estado que

mantiene los mecanismos de Snort en un nico lugar. Desde la versin 2.1.0,
slo se implementaba un detector portscan, pero a largo plazo, muchos de los
subsistemas de Snort migrarn sobre plugins flow. Con la introduccin de flow,
se hace la conversin del preprocesador anticuado.

Formato de Flow:
preprocessor flow: [memcap <bytes>], [rows <count>], \
[stats_interval <seconds>], [hash <1|2>]

Stream5. El preprocesador Stream5 es un mdulo de reensamblado TCP para

Snort.Intenta suplantar a Stream4 y a Flow, y es capaz de rastrear sesiones tanto
para TCP como para UDP. Con Stream5, la regla 'flow' y palabras clave
'flowbits' son utilizables tanto con TCP como con UDP.

Sfportscan. El mdulo sfPortscan, desarrollado por Sourcefire, es diseado para

descubrir la primera fase en un ataque de red: Reconocimiento. En la fase de
Reconocimiento, un atacante determina qu tipos de protocolos de red o
servicios soporta un host. Detecta escaneos a nivel de herramienta, como puede
ser un escaneo de puertos realizado con Nmap.

Formato de Sfportscan:
preprocessor sfportscan: proto <protocols> \
scan_type
<portscan|portsweep|decoy_portscan|distributed_portscan|all>\
sense_level <low|medium|high> watch_ip <IP or IP/CIDR>
ignore_scanners <IP list>\
ignore_scanned <IP list> logfile <path and filename>

Rpc_decode. El preprocesador rpc_decode normaliza mltiples registros RPC

fragmentados en un nico registro infragmentado. Esto normaliza el paquete en
el buffer del paquete. Si permite stream4, esto slo tratar el trfico del lado
cliente. Por defecto, se ejecuta sobre los puertos 111 y 32771.

Formato de rpc_decode:
preprocessor rpc_decode: <ports> [ alert_fragments ] \
[no_alert_multiple_requests] [no_alert_large_fragments] \
[no_alert_incomplete]
 Captulo 2. Snort 7

Performance Monitor. Este preprocesador mide el funcionamiento en tiempo

real y terico mximo de Snort. Siempre que este preprocesador se active,
debera tener un modo de salida permitido, consola que imprime la estadstica
por pantalla o un archivo con un nombre, donde se almacenen las estadsticas.

Http_instpect y http_inspect_server. HTTP Inspect, es un decodificador

genrico HTTP para usos de usuario.Dado un buffer de datos, HTTP Inspect,
decodificar el buffer, encontrar campos HTTP, y los normalizar. HTTP
Inspect trabaja tanto con respuestas del cliente como del servidor.

Formato de http_inspect globlal:

preprocessor http_inspect: global \
iis_unicode_map <map_filename> \
codemap <integer> \
[detect_anomalous_servers] \
[proxy_alert]

Smtp. El preprocesador SMTP es un decodificador SMTP para aplicaciones de

usuario. Considerando un buffer de datos, SMTP descodifica el buffer y
encuentra rdenes SMTP y respuestas.

Ftp/telnet preprocessor. FTP/Telnet es una mejora al decodificador Telnet y

proporciona la capacidad de inspeccin tanto del FTP como de Telnet.
FTP/Telnet descodificar el flujo de datos, identificando rdenes de FTP,
respuestas y secuencias de escape de Telnet y normalizar los campos.
FTP/Telnet trabaja tanto con respuestas del cliente como del servidor.

Formato de ftp/telnet:
preprocessor ftp_telnet: global \
inspection_type stateful \
encrypted_traffic yes \
check_encrypted

Ssh. El preprocesador SSH detecta lo siguiente:Gobbles, CRC 32, Seguridad

CRT, y el protocolo Mismatch exploit .

Dce/rpc. El preprocesador dce/rpc detecta y descifra el trfico SMB y

DCE/RPC. Principalmente est interesado en datos DCE/RPC, y slo descifra
SMB para llegar a los datos DCE/RPC que transporta la capa SMB.

Dns. El preprocesador DNS descifra respuestas DNS y puede detectar lo

siguiente: DNS Desbordamientos Cliente RData, Tipos Anticuados De registro,
y Tipos Experimentales De registro.

Estos preprocesadores se activan en Snort en el fichero de configuracin snort.conf,

simplemente con comentar una lnea en dicho fichero el preprocesador se cargara o no.
Tambin podemos implementar nuestros propios procesadores.

A continuacin se muestra en la tabla 2-1, un resumen con una descripcin general

de los preprocesadores de Snort.
8 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Tabla 2-1. Preprocesadores de snort

Preprocesador Descripcin
Frag3 El preprocesador frag3 se basa en la fragmentacin IP de los
mdulos de snort. Frag3 permite una ejecucin ms rpida que frag2
y permite tcnicas de antievasin.
stream4 y Proporciona un flujo de ensamblado TCP y capacidades de anlisis
stream4_reasemble para poder rastrear hasta 100.000 conexiones simultneas.
Flow Permite unificar el estado que mantiene los mecanismos de Snort en
un nico lugar. Desde la versin 2.1.0 slo se implementaba el
detector portscan, pero a largo plazo muchos subsistemas de Snort
utilizan flow.
stream5 Es un mdulo de reensablado que intenta suplantar a stream4 y a
flow. Permite rastrear tanto comunicaciones TCP como UDP.
sfportscan Es un mdulo desarrollado por sourcefire para detectar el primer
paso de un ataque: el escaneo de puertos.
rpc_decode Permite normalizar mltiples registros RPC fragmentados en un
nico registro.
perfomance monitor Permite medir en tiempo real el funcionamiento de Snort. El
funcionamiento de ste preprocesador lo veremos ms tarde.
http_inspect y Es un decodificador genrico para analizar el trfico http. Permite
http_inspect_server trabajar tanto para analizar las respuestas de los clientes como de los
servidores.
smtp Es un decodificador SMTP para los clientes de correo electrnico.
ftp/telnet Permite decodificar el trfico ftp y telnet para buscar cualquier
actividad anormal. Se utiliza para analizar tanto las respuestas de los
clientes como de los servidores.
ssh Permite analizar el trfico ssh de clientes y servidores.
dce/rpc Analiza el trfico SMB (compartir archivos y carpetas de Windows).
dns Permite analizar el trfico de DNS para detectar diferentes tipos de
ataques.

2.4 Reglas (Rules)

Las reglas o firmas son los patrones que se buscan dentro de los paquetes de datos.
Las reglas de Snort son utilizadas por el motor de deteccin para comparar los paquetes
recibidos y generar las alertas en caso de existir coincidencia entre el contenido de los
paquetes y las firmas. El archivo snort.conf permite aadir o eliminar clases enteras de
reglas. En la parte final del archivo se pueden ver todos los conjuntos de reglas de
alertas. Se pueden desactivar toda una categora de reglas comentando la lnea de la
misma.

A continuacin, se vern las distintas reglas de Snort, y el formato de las mismas,

para poder realizar su configuracin.

2.4.1 Categoras de reglas Snort

Hay cuatro categoras de reglas para evaluar un paquete. Estas cuatro categoras
estn divididas a su vez en dos grupos, las que tienen contenido y las que no tienen
contenido. Hay reglas de protocolo, reglas de contenido genricas, reglas de paquetes
mal formados y reglas IP.
 Captulo 2. Snort 9

Reglas de Protocolo. Las reglas de protocolo son reglas las cuales son
dependientes del protocolo que se est analizando, por ejemplo en el protocolo
Http est la palabra reservada uricontent.

Reglas de Contenido Genricas. Este tipo de reglas permite especificar

patrones para buscar en el campo de datos del paquete, los patrones de bsqueda
pueden ser binarios o en modo ASCII, esto es muy til para buscar exploits los
cuales suelen terminar en cadenas de tipo /bin/sh.

Reglas de Paquetes Malformados. Este tipo de reglas especifica caractersticas

sobre los paquetes, concretamente sobre sus cabeceras las cuales indican que se
est produciendo algn tipo de anomala, este tipo de reglas no miran en el
contenido ya que primero se comprueban las cabeceras en busca de
incoherencias u otro tipo de anomala.

Reglas IP. Este tipo de reglas se aplican directamente sobre la capa IP, y son
comprobadas para cada datagrama IP, si el datagrama luego es Tcp, Udp o Icmp
se realizar un anlisis del datagrama con su correspondiente capa de protocolo,
este tipo de reglas analiza con contenido y sin l.

En la tabla 2-2, se puede observar una lista con las clases de reglas ms habituales
en Snort y una pequea descripcin de las mismas.

Tabla 2-2. Clases de reglas de Snort

Clase de Regla Descripcin
attack-response.rules Son las alertas para paquetes de respuesta comunes despus de que
un ataque haya tenido xito. Raramente se informan como falsos
positivos y debemos activarlas en la mayora de los casos.
backdoor.rules Permiten detectar puertas traseras o troyanos en el sistema.
bad-traffic.rules Representan el trfico de red no estndar que normalmente no debera
verse en la mayora de las redes.
chat.rules Permite detectar el uso en la red interna de programas de Chat. Si en
nuestra red permitimos el uso del Chat debemos deshabilitarla.
ddos.rules Permite detectar ataques de denegacin de servicio. Estas reglas no
sirven mucho en la red externa o la DMZ porque si se produce un
ataque de ste tipo lo sabremos enseguida. Sin embargo, resulta muy
til activarla en la red interna. Busca tipos de ataques de denegacin
de servicio distribuido estndares.
dns.rules Buscan algunos ataques tpicos contra servidores DNS. Si no dispone
dos.rules de un servidor DNS propio debemos desactivarlas.
experimental.rules Por defecto estn deshabilitadas. Generalmente se utilizan slo para
probar nuevas reglas hasta que se desplazan a otra categora.
exploit.rules Se utilizan para alertar de la utilizacin de exploit en nuestra red.
finger.rules Se utilizan para detectar ataques sobre servidores finger.
ftp.rules Permiten detectar ataques en nuestros servidores FTP. Se recomienda
activar la regla para poder detectar si alguien instala en la red un
servidor de FTP ilegal.
icmp-info.rules Registran el uso de los mensajes ICMP (por ejemplo, pings, escaneo
icmp.rules de puertos). A menudo producen falsos positivos, podemos desactivar
toda la clase a no ser que deseemos estar pendientes del trfico ICMP
en nuestra red.
10 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

imap.rules Reglas correspondientes al uso del protocolo de acceso a mensajes

desde internet (IMAP, Internet Message Access Protocol).
info.rules Registra los mensajes de error de los servidores Web, FTP, etc.
local.rules Por defecto el fichero se encuentra vaco y se utiliza para poder
especificar nuestras propias reglas.
misc.rules Reglas que no encajan en ninguna de las restantes categoras.
multimedia.rules Permite registrar el uso de programas de videoconferencia en la red.
mysql.rules Permite detectar ataques dirigidos a los servidores de bases de datos
MySQL.
Netbios.rules Permite detectar actividad sospechosa sobre NetBIOS en la red
interna.
nntp.rules Permite detectar ataques a servidores de noticias tanto desde el punto
de vista del cliente como del servidor.
oracle.rules Reglas del servidor de base de datos Oracle. Si no tenemos un
servidor de este tipo, las deshabilitamos.
other-ids.rules Estas reglas se relacionan con exploits en los IDS de otros
fabricantes.
p2p.rules Reglas que permiten detectar el uso de software para compartir
archivos punto a punto.
pop3.rules Permite detectar ataques en servidores de correo entrante.
porn.rules Esta regla permite detectar si los clientes de la red interna visitan
pginas pornogrficas. No permite el filtrado de contenido. Si quieres
filtrar el contenido debemos utilizar un Proxy (por ejemplo, squid).
rpc.rules Esta clase controla las alertas de llamadas a procedimientos remotos
(RPC). Es importante habilitar esta regla ya que los sistemas
Windows dependen mucho de este servicio y hay muchos ataques
dirigidos al mdulo RPC.
rservices.rules Registra el uso de diversos programas de servicios remotos, como
rlogin y rsh. Estas reglas en general, son de servicios inseguros, pero
si tenemos que utilizarlos, pueden examinarse con este conjunto de
reglas.
scan.rules Permite detectar cualquier intento de escaneo de puertos en la red.
shellcode.rules Permite detectar la actividad sospechosa de los clientes que utilizan
un terminal. Permite detectar ataques de desbordamiento de memoria,
exploits, escalada de privilegios, etc.
smtp.rules Contienen las alertas para el uso del servidor de correo en la LAN.
Esta seccin necesitar algn ajuste ya que muchas actividades de
servidor de correo normales activarn reglas de esta seccin.
sql.rules Permite detectar ataques genricos sobre servidores de base de datos
SQL.
telnet.rules Registra el uso de telnet en la red. Es recomendable activar la regla
ya que telnet se puede utilizar para conectarnos a routers u otros
dispositivos.
tftp.rules TFTP es una versin lite del servidor FTP. Es muy recomendable
activar esta regla porque muchos troyanos utilizan TFTP para enviar
datos desde la red interna al exterior.
virus.rules Contiene las firmas de algunos gusanos y virus conocidos. Su
utilizacin no implica en ningn caso dejar de utilizar antivirus pero
si es recomendable activarla.
web-attacks.rules Todas estas clases se refieren a diversos tipos de actividad web
web-cgi.rules sospechosa. Algunas son genricas, como las clases web-attacks.
web-client.rules Otras clases, como web-iis y web-frontpage, son especficas de una
web-coldfusion.rules determinada plataforma. Sin embargo, aunque creamos que no
 Captulo 2. Snort 11

web-frontpage.rules estamos ejecutando un servidor web Microsoft o PHP, es mejor

web-iis.rules habilitarlas todas para descubrir cualquier tipo de esta actividad en
web- nuestra red.
php.rules
X11.rules Registra el uso del entorno grfico X11.

2.4.2 Personalizacin de reglas

La forma ms fcil de limitar el trfico de las alertas es desactivar reglas que no se

aplican en nuestro sistema, esto lo podemos hacer entrando en la configuracin de
Snort. El directorio /etc/snort/rules/ contiene muchos archivos con la extensin .rules,
cada uno de ellos contiene las reglas agrupadas por categoras.

Se puede deshabilitar una clase entera de reglas comentndola en el archivo de

configuracin o se puede deshabilitar reglas individuales si se requiere de la proteccin
del resto de reglas de la clase. Para comentar una regla concreta, se busca en los
archivos .rules apropiados y se inserta un comentario delante de la lnea de dicha regla.
Hay que tener en cuenta que normalmente es mejor deshabilitar una sola regla que toda
la clase, a no ser que sta no se aplique en una determinada configuracin.

El motor de deteccin es realmente el corazn de la funcionalidad de Snort. Snort

usa un lenguaje de descripcin simple y flexible para indicar cmo se deben de manejar
los datos. Para que Snort pueda coger las ltimas vulnerabilidades, deberemos de
actualizar nuestras reglas.

Aunque los conjuntos de reglas estndar incluidos en Snort proporcionan una

proteccin adecuada contra armas de ataques conocidas, podemos disear algunas
reglas personalizadas especficas para que nuestra red obtenga el mejor rendimiento del
IDS.

Snort permite mucha versatilidad para crear nuevas reglas. Modificando nuestras
propias reglas, minimizaremos los falsos positivos. Las reglas que abarcan muchos
casos generales suelen poseer altos ndices de falsos positivos, mientras que las
particulares no. La idea es crear nuevas reglas avanzadas, en funcin de los servicios
que se desean monitorizar.

Se pueden escribir reglas para:

Registrar el acceso hacia o desde determinados servidores.

Buscar determinados tipos de nombres de archivos en nuestra organizacin.
Vigilar determinados tipos de trfico que no pertenecen a nuestra propia red.

La escritura de reglas de Snort es fcil de aprender y nos permite aadir

funcionalidades al programa, sin muchos conocimientos de programacin. Como hemos
podido comprobar, las reglas de Snort son simplemente declaraciones de texto dentro de
un archivo de reglas.

Si se desea que Snort busque un comportamiento nico que debera ser sospechoso
en nuestra red, se puede codificar rpidamente una regla y probar el resultado. El
formato de una regla de Snort es bsicamente una sola lnea de texto que empieza con
12 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

una accin (normalmente alert) seguida por diversos argumentos. Se pueden aadir
mltiples lneas simplemente aadiendo una barra inclinada (/) al final de cada lnea.
Tambin se puede llamar a otros programas utilizando una declaracin de inclusin para
obtener una regla ms compleja.

En su forma bsica, una regla de Snort consta de dos partes:

Un encabezado
Las opciones

En la Figura 2-4, se puede ver la estructura que presenta una regla y su cabecera.

Figura 2-4. Estructura de una Regla y su Cabecera

A continuacin se muestran ms detalladamente los distintos componentes de una

regla.

2.4.2.1 Cabecera de una regla

La cabecera permite establecer el origen y destino de la comunicacin, y sobre dicha

informacin realizar una determinada accin. La cabecera contiene algunos criterios
para unir la regla con un paquete y dictar qu accin debe tomar una regla. Su estructura
es:

<accin> <protocolo> <red origen> <puerto origen> <direccin> <red destino>

<puerto destino>

La estructura general de la cabecera de la regla es la que se puede observar en la

Tabla 2-3.

Tabla 2-3: Estructura de la Cabecera de una regla Snort

Accin Protocolo Red Origen
Puerto Direccin Red Destino Puerto
Origen Destino
alert tcp $EXTERNAL_NET any
$HOME_NET 53

Y el significado de cada campo es el siguiente:

Protocolo. Permite establecer el protocolo de comunicaciones que se va a

utilizar. Los posibles valores son: TCP, UDP, IP e ICMP.
 Captulo 2. Snort 13

Red de origen y red de destino. Permite establecer el origen y el destino de la

comunicacin.

Puerto de origen y destino. Permite establecer los puertos origen y destino de

la comunicacin. Indica el nmero de puerto o el rango de puertos aplicado a la
direccin de red que le precede.

Direccin. Permite establecer el sentido de la comunicacin. Las posibles

opciones son: ->, <- y <>.

Accin. Permite indicar la accin que se debe realizar sobre dicho paquete. Los
posibles valores son:

o alert: Genera una alerta usando el mtodo de alerta seleccionado y

posteriormente loggea el paquete.
o log: Comprueba el paquete.
o pass: Ignora el paquete.
o activate: Alerta y luego activa otra regla dinmica.
o dynamic: Permanece ocioso hasta que se active una regla, entonces actua
como un inspector de reglas.

A continuacin se puede ver un ejemplo donde se aplica a una regla al trfico que va
a dos servidores web internos:

alert tcp any any <> [10.0.0.11, 10.0.0.12] 80

Las dos direcciones de Red pueden ser una nica IP, bloques CIDR, o una lista que
combine las dos opciones. Podemos listar mltiples direcciones individuales y redes
separndolas con una coma, sin espacios y escribiendo la declaracin entre corchetes,
por ejemplo:

alert tcp any <> [192.168.0.2,192.168.0.5,192.168.0.10] 80 /

(content:"|00 05 A4 6F 2E|";msg:"Test Alert";)

Esta sentencia se centra en el trfico que proviene de cualquier direccin enlazada

para las mquinas 192.168.0.2, 192.168.0.5 y 192.168.0.10 en el puerto 80. Suponiendo
que se tratan de los servidores Web, la sentencia buscar el trfico entrante con los datos
hexadecimales de la seccin de contenido.

2.4.2.2 Las Opciones de las reglas

Las opciones estn separadas entre s, por (;) y las claves de las opciones estn
separadas por (:). Hay cuatro tipos de opciones:

Meta-data. Proporciona la informacin sobre la regla pero no tenga alguno

afecta durante la deteccin.

Payload. Busca patrones (firmas) dentro de la carga til del paquete.

14 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Non-Payload. Busca patrones dentro de los dems campos del paquete, que no
sean carga til (por ejemplo, la cabecera).

Post-detection. Permite activar reglas especficas que ocurren despus de que se

ejecute una regla.

La tabla 2-4, muestra las opciones de las reglas de Snort.

Tabla 2-4. Ejemplo de Opciones de las Reglas Snort

Opcin Tipo Claves de Opcin
msg meta-data "DNS EXPLOIT named 8.2->8.2.1"
flow non-payload to_server,established
content payload "../../../"
reference meta-data bugtraq,788
reference meta-data cve,1999-0833
classtype meta-data attempted-admin
sid meta-data 258
rev meta-data 6

Seguidamente se describen las principales opciones de las reglas:

msg. Informa al motor de alerta que mensaje debe de mostrar. Los caracteres
especiales de las reglas como : y ; deben de colocarse dentro de la opcin msg
con el carcter \.

flow. Se usa junto con los flujos TCP, para indicar qu reglas deberan de
aplicarse slo a ciertos tipos de trfico.

content. Permite que Snort realice una bsqueda sensitiva para un contenido
especfico del payload del paquete.

referente. Define un enlace a sistemas de identificacin de ataques externos,

como bugtraq, con id 788.

classtype. Indica qu tipo de ataques intent el paquete. La opcin classtype, usa

las classifications definidas en el archivo de configuracin de Snort y que se
encuentran en archivos como classification.config.

La sintaxis del classification.config es:

<nombre_clase>, <descripcin_clase >, <priorididad_por_defecto >.

La prioridad es un valor entero, normalmente 1 para prioridad alta, 2 para media

y 3 para baja.

La opcin classification para el attempted-admin que aparece en

classification.config, es la siguiente:

config classification: attempted-admin,Attempted Administrator Privilege

Gain,1
 Captulo 2. Snort 15

La opcin sid, en combinacin con la opcin rev, unicamente identifica una

regla Snort, correlacionando el ID de la regla individual con la revisin de la
regla.

Un ejemplo de regla sera:

alert tcp $EXTERNAL_NET any -> $HOME_NET 53 \

(msg:"DNS EXPLOIT named 8.2->8.2.1"; flow:to_server,established; \
content:"../../../"; reference:bugtraq,788; reference:cve,1999-0833; \
classtype:attempted-admin; sid:258; rev:6;)

La regla genera la alerta DNS EXPLOIT named 8.2->8.2.1 cuando en una

comunicacin establecida al servidor DNS se encuentre el texto ./../../. Los campos
reference permiten indicar el tipo de vulnerabilidad que se ha detectado.

Seguidamente se muestra en la tabla 2-5 con las principales opciones de

personalizacin de las reglas Snort.

Tabla 2-5. Opciones de Personalizacin en las reglas Snort

Opcin Descripcin
msg Proporciona la descripcin del texto de una alerta.
logto Registra el paquete para un nombre de archivo especfico de un usuario
en lugar de para el archivo de salida estndar.
ttl Prueba el valor del campo TTL del encabezado IP.
tos Prueba el valor del campo TOS del encabezado IP.
if Prueba el campo ID del fragmento del encabezado IP para un valor
especfico.
ipoption Vigila los campos de opcin IP buscando cdigos especficos.
fragbits Prueba los bits de fragmentacin del encabezado IP.
dsize Prueba el tamao de carga til del paquete frente a un valor.
flags Prueba los indicadores TCP para determinados valores.
seq Prueba el campo de nmero de secuencia TCP para un valor especfico.
ack Prueba el campo de reconocimiento TCP para un valor especfico.
itype Prueba el campo de tipo ICMP frente a un valor especfico.
icode Prueba el campo de cdigo ICMP frente a un valor especfico.
Icmp_id Prueba el campo ICMP ECHO ID frente a un valor especfico.
Icmp_seq Prueba el nmero de secuencia ICMP ECHO frente a un valor especfico.
content Busca un patrn en la carga til del paquete.
content-list Busca un conjunto de patrones en la carga til del paquete
offset Modificador para la opcin de contenido. Establece la compensacin en
el intento de coincidencia con el patrn.
depth Modificador para la opcin de contenido. Establece la profundidad de
bsqueda para un intento de coincidencia con el patrn.
nocase Compara la cadena de contenido anterior sin tener en cuenta las
maysculas y las minsculas.
session Descarga la informacin de la capa de aplicacin para una determinada
sesin.
Vigila los servicios RPC en bsqueda de determinadas llamadas de
aplicaciones o procedimientos.
rpc Respuesta activa (por ejemplo, cerrar todas las conexiones).
16 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

resp Respuesta activa. Responde con un conjunto de comportamientos

cifrados (por ejemplo, bloquear determinados sitios web).
react Los ID de referencia de ataques externos.
referernce ID de regla Snort.
sid Nmero de revisin de regla.
rev Identificador de clasificacin de regla.
classtype Identificador de severidad de regla.
priority Identificador de severidad de regla.
uricontent Busca un patrn en la parte URI del paquete.
tag Acciones de registro avanzadas para las reglas.
Ip_proto Valor de protocolo del encabezado IP.
sameip Determina si la IP de origen es igual a la IP de destino.
stateless Vlido independientemente del estado del flujo.
regex Coincidencia de patrn de caracteres comodn.
byte test Evaluacin numrica.
distance Obliga a que la coincidencia de patrn relativa omita determinado
nmero de bytes en el paquete.
byte test Prueba numrica del patrn.
byte jump Prueba numrica del patrn y ajuste de compensacin

2.4.2.3 Ejemplos de personalizacin de reglas

A continuacin se muestran varios ejemplos de reglas y de formas de personalizar

estas reglas:

Por ejemplo, se puede generar el mensaje Ping como alerta, ante la presencia de
ICMP de la siguiente forma:

alert icmp any any -> any any \

(msg: "Ping";)

Otro ejemplo es activar un protocolo antiguo en un servidor. Por ejemplo si un

servidor responde con SSH-1 es porque tiene activado el protocolo antiguo SSH1 como
se indica:
alert tcp $HOME 22 -> $EXTERNAL any \
(msg: "SSH version 1 support detected; \
flow: to_client, established; \
content: "SSH-1."; \
nocase; \
offset: 0; \
depth: 6;)

Tambin podemos activar reglas de la siguiente forma:

activate tcp $EXTERNAL any -> $HOME 143 \

(flags: PA; \
content: "|E8C0FFFFFF|/bin";
activates: 1; \
msg: "IMAP buffer overflow";)
 Captulo 2. Snort 17

dynamic tcp $EXTERNAM any -> $HOME 143 \

(activated_by 1;
count: 50;
msg: "50 paquetes al 143, una vez activado el IMAP bo")

Cuando se configura una regla, para mejorar su eficacia y velocidad se deben de

tener en cuenta los siguientes aspectos:

Intentar analizar la vulnerabilidad en s, no el cdigo exploit, ya que estos

pueden cambiar con facilidad.

Utilizar content en la medida que sea posible. La primera fase del motor de
deteccin del Snort 2.x, busca el patrn del content, cuanto ms exacto sea ms
exacta ser la comparacin.

Atrapar las singularidades del protocolo.

Ejemplo:
Se pretende generar una alerta cuando se intenta conectar un usuario como
root al ftp. La alerta que se podra sugerir en un principio sera:
alert tcp any any -> any any 21 (content:"user root";)

Aqu aparece el problema de que el protocolo ftp acepta:

USER root
user root
user<tab>root

Una regla mejor sera:

alert tcp any any -> any 21 \
(flow:to_server,established; \
content:"root"; \
pcre:"/user\s+root/i"; )

Donde la opcin flow se utiliza para verificar que el trafico est yendo hacia el
servidor y est establecido. El content comprueba la palabra root, las reglas
content son importantes ya que descartan rpidamente opciones si no encuentra
coincidencia entre ellas. El pcre es para expresiones regulares, y en este caso
busca la expresin: user root, separada por uno o ms carcteres (espacios o
tabulaciones), e ignorando entre maysculas y minsculas.

Optimizacin de reglas

Las reglas poseen una naturaleza recursiva, si un patrn de una regla coincide y si
ninguna de las opciones posteriores falla, entonces se vuelve a buscar en el paquete otra
vez, desde el lugar donde coincidi la vez anterior. Y se repite hasta que el patrn no
sea encontrado o hasta que las opciones concuerden.

Si se busca un paquete de tamao 1 byte con el ; dentro, se podra pensar esta

regla:
content:"|29|"; dsize:1;
18 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Sin embargo, por la naturaleza recursiva del Snort, si tenemos un paquete de 1000
bytes con todos ;, lo realizar 1000 veces.

Para evitar esto:

dsize:1; content:"|29|";

De esta manera slo toma payloads con data size de 1 byte.

Para probar valores numricos, existen dos opciones muy importantes que se
incluyeron a partir de la versin 2.x: byte test y byte jmp, las dos son tiles para
configurar reglas que chequeen bytes dentro de una cadena o payload.

2.5 El motor de deteccin

El motor de deteccin es la parte ms importante de Snort. Su responsabilidad es

descubrir cualquier actividad de intrusin existente en un paquete. Para ello, el motor de
deteccin emplea las reglas de Snort. Las reglas son ledas en estructuras de datos
internas o cadenas donde son comparadas con cada paquete. Si un paquete empareja con
cualquier regla, se realiza la accin apropiada. De lo contrario el paquete es descartado.
Las acciones apropiadas pueden ser registrar el paquete o generar alarmas.

El motor de deteccin es la parte de tiempo crtico de Snort. Los factores que

influyen en el tiempo de respuesta y en la carga del motor de deteccin son los
siguientes:

Las caractersticas de la mquina.

Las reglas definidas.
Velocidad interna del bus usado en la mquina Snort.
Carga en la red.

Estos factores son muy importantes ya que por ejemplo, si el trfico en la red es
demasiado alto, mientras Snort est funcionando en modo NIDS, se pueden descartar
paquetes y no se conseguir una respuesta en tiempo real. As pues, para el diseo del
IDS habr que tener en cuenta estos factores.

El motor de deteccin puede aplicar las reglas en distintas partes del paquete. Estas
partes son las siguientes:

La cabecera IP. Puede aplicar las reglas a las cabeceras IP del paquete.

La cabecera de la capa de Transporte. Incluye las cabeceras TCP, UDP e

ICMP.

La cabecera del nivel de la capa de Aplicacin. Incluye cabeceras DNS, FTP,

SNMP y SMPT.

Payload del paquete. Esto significa que se puede crear una regla que el motor
de deteccin use para encontrar una cadena que est presente dentro del paquete.
 Captulo 2. Snort 19

El motor de deteccin de Snort funciona de forma diferente en distintas versiones de

Snort. A continuacin se muestra la estructura del motor de deteccin en funcin de la
versin de Snort utilizada.

2.5.1 Antiguo motor de deteccin

La estructura del antiguo motor de deteccin de Snort, se basa en una lista enlazada
tridimensional de reglas con sus cabeceras y funciones de deteccin.

La reglas son a su vez una lista enlazada de la cabecera de la regla, llamada

RuleTreeNodes (RTN). Cada RTN es una lista enlazada de reglas que comparten una
misma cabecera, llamada OptTreeNodes (OTN). A su vez, cada OTN es una lista
enlazada de funciones de deteccin, llamada OptFpList. Cuando llega un paquete al
motor de deteccin, ste recorre la lista enlazada RTN, si coincide con sta, el motor de
deteccin recorre la lista enlazada OTN para esta RTN. El motor de deteccin
comprueba cada una de las funciones del OptFpList de la OTN. Si todas estas funciones
en la OTN emparejan, se dispara una alarma.

Cuando una alarma se dispara, el motor registra dicha alarma y el paquete que la
gener para despus comenzar de nuevo el proceso completo con la llegada del
siguiente paquete.

El antiguo motor de deteccin de Snort, el del 1.x, era simple de implementar y

aadirle a ste la nueva funcionalidad era relativamente fcil. Sin embargo este motor
no era muy eficiente y era muy dependiente del nmero de reglas que estuvieran
activas, a mayor nmero de reglas peor era la eficiencia de Snort.

En los ltimos aos el nmero de reglas se ha disparado en Snort, actualmente hay

unas 2500 reglas activas. Con el antiguo motor de deteccin la gestin de estas reglas
era lo que haca que Snort fuese lento y poco eficiente, y ms para un sistema de este
tipo.
2.5.2 Nuevo motor de deteccin

El nuevo motor de deteccin de Snort introducido en la versin 2.0, parte con un

requisito inicial, que Snort sea capaz de funcionar en redes Gigabyte, y para que esto
sea posible se ha reescrito totalmente el motor de Snort para que este sea capaz de
gestionar trafico a GigaBytes.

Los desarrolladores de Snort realizaron un nuevo motor de deteccin usando

algoritmos multipatrn de bsqueda que es el ncleo del motor y que implementa
mltiples reglas, permitiendo a Snort funcionar sobre redes GigaByte.

El nuevo motor de deteccin construye cuatro grupos de reglas, una para el

protocolo TCP, para UDP, para ICMP y para IP.

Cuando un paquete se captura mediante la librera Libpcap lo primero que se realiza

es una decodificacin de ste para alinear cabeceras segn el protocolo, como se puede
ver en el siguiente diagrama de la Figura 2-5.
20 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Figura 2-5. Diagrama de Decodificacin de Paquetes

En primer lugar se realiza la decodificacin de los paquetes, todo depende del

protocolo analizado. Posteriormente se realizan las llamadas a los preprocesadores, por
cada uno de los que estn instalados en Snort o preprocesadores propios que hayamos
implementado nosotros.

2.6 Mdulos de salida

Los mdulos de salida o plugins pueden hacer diferentes operaciones dependiendo
de cmo se desee guardar la salida generada por el sistema de loggin y alerta de Snort.
Bsicamente estos mdulos controlan el tipo de salida generada por estos sistemas.

Existen varios mdulos de salida que se pueden utilizar, dependiendo del formato en
el que se deseen los datos: Syslog, Database y el nuevo mdulo denominado Unified,
que es un formato binario genrico para exportar datos a otros programas.

El formato general para configurar los mdulos de salida es:

output module_name: configuration options

Siendo module name bien alert syslog, database o alert unified dependiendo del
mdulo que se cargue.

Las opciones de configuracin para cada mdulo de salida son las siguientes:
 Captulo 2. Snort 21

Syslog. Enva las alarmas al syslog

Formato Syslog:
output alert_syslog: LOG_AUTH LOG_ALERT
output alert_syslog: host= hostname:port, LOG_AUTH LOG_ALERT

Donde hostaname y port son la direccin IP y el puerto de nuestro servidor

Syslog.

Alert_Fast. El modo Alerta Rpida nos devolver informacin sobre: tiempo,

mensaje de la alerta, clasificacin, prioridad de la alerta, IP y puerto de origen y
destino.

Formato alert_Fast:
alert_fast: <output filename>
output alert_fast: alert.fast

Alert_Full. El modo de Alerta Completa nos devolver informacin sobre:

tiempo, mensaje de la alerta, clasificacin, prioridad de la alerta, IP y puerto de
origen/destino e informacin completa de las cabeceras de los paquetes
registrados.

Formato alert_Full:
alert_full: <output filename>
output alert_full: alert.full

Alert_smb. Permite a Snort realizar llamadas al cliente de SMB, y enviar

mensajes de alerta a hosts Windows (WinPopUp). Para activar este modo de
alerta, se debe compilar Snort con el conmutador de habilitar alertas SMB
(enable smbalerts). Evidentemente este modo es para sistemas Linux/UNIX.
Para usar esta caracterstica enviando un WinPopUp a un sistema Windows,
aadiremos a la lnea de comandos de Snort: -M WORKSTATIONS.

Formato alert_smb:
alert_smb: <alert workstation filename>
output alert_smb: workstation.list

Alert_unixsock. Manda las alertas a travs de un socket, para que las escuche
otra aplicacin.

Formato alert_unixsock:
alert_unixsock
output alert_unixsock

Log_tcpdump. Este mdulo asocia paquetes a un archivo con formato tcpdump.

Formato log_tcpdump:
log_tcpdump: <output filename>
output log_tcpdump: snort.log
22 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Database. Snort admite directamente cuatro tipos de salida a base de datos:

MySQL, PostgreSQL, Oracle y unixODBC. El mdulo de salida de base de
datos requiere: parmetros y configuraciones, dentro del archivo de
configuracin y en tiempo de compilacin

Formato Database
output database: log, database_type, user= user_name password= password
dbname host= database_address

Donde se debe reemplazar database type por una base de datos vlida, user
name por un nombre de usuario vlido en la base de datos y password por la
contrasea asociada al usuario.

La variable dbname identifica el nombre de la base de datos en la que se va a

realizar el registro.

Por timo, database address es la direccin P del servidor que contiene la base
de datos.

No se recomienda intentar ejecutar Snort y la base de datos en el mismo servidor

ya que suele provocar una bajada considerable del rendimiento del sistema.

CSV. El plugin de salida CSV permite escribir datos de alerta en un formato

fcilmente importable a una base de datos. Este plugin requiere 2 argumentos,
directorio hacia un archivo y la opcin de formato de salida.

Formato CSV:
output alert_CSV: <filename> <format>
output alert_CSV: /var/log/alert.csv default
output alert_CSV: /var/log/alert.csv timestamp, msg

Unified. Es un formato binario bsico para registrar los datos y usarlos en el

futuro. Los dos argumentos admitidos son filename y limit.

Formato Unified:
output alert_unified: filename snort.alert, limit 128

Log Null. A veces es til ser capaz de crear las reglas que provocarn alertas
sobre ciertos tipos de trfico, pero no causarn entradas en los archivos de log.

Formato Log Null:

output log_null

Eventlog. Registra las alertas para visualizarse a travs del visor de sucesos de
un sistema windows. Esta opcin se activar mediante -E y slo para Win32.
 Captulo 2. Snort 23

3 Plugins de Snort
Hay una serie de mdulos o complementos para Snort, que contribuyen a aumentar
su funcionalidad.

Entre ellos destaca SPADE (Statical Packet Anomaly Detection Engine) [BIL]. Se
trata de un IDS basado en actividades anmalas, publicado bajo licencia GNU GPL por
lo que es de libre distribucin y es para el NIDS Snort. Se trata de un plug-in
preprocesador para el motor de deteccin de intrusos de Snort. Detecta el trfico de red
que se desva del comportamiento normal.

Otro complemento para Snort es Snort Inline de Jed Haile, [PAL]. Snort Inline es
un IPS de libre distribucin para el NIDS Snort. Snort Inline es bsicamente una versin
modificada de Snort que acepta paquetes de iptables e IPFW va libipq (linux) o desde
sockets (FreeBSD), en vez de libpcap. Por ello, usa nuevos tipos de reglas (drop, sdrop,
reject) para transmitirle a iptables/IPFW si el paquete debe ser eliminado, rechazado,
modificado, o permitido, basndose en un conjunto de reglas de Snort. Es un Sistema de
Prevencin de Intrusin (IPS) que usa el Sistema de Deteccin de Intrusin basado en
firmas para tomar decisiones sobre los paquetes que atraviesan Snort Inline.

Bro est desarrollado en la Universidad de California en Berkeley. Bro est

considerado como un IDS basado en Red. Usa una variedad de mdulos de anlisis de
protocolos para inspeccionar el trfico y hacer juicios en cuanto a su conformidad a
varias normas. Se trata de un complemento muy potente para Snort que monitoriza
pasivamente el trfico de red y busca actividad sospechosa. Su anlisis incluye la
deteccin de ataques especficos (incluyendo aquellos definidos por firmas, pero
tambin aquellos definidos en trminos de eventos) y actividades inusuales (p.ej.,
ciertos hosts conectados a ciertos servicios, o intentos de conexin fracasados).

SAM (Snort Alert Monitor) [RAH06] es una plataforma independiente basada en

Java que revisa rpidamente las alarmas de Snort de la base de datos. SAM produce una
descripcin de alto nivel, de forma que supervisa la base de datos MySQL y da la
alarma si se encuentra la condicin dada. SAM se trata pues, de un programa para
supervisar en tiempo real el nmero de alarmas generadas por Snort.

Otro mdulo que se encarga de analizar las alertas de Snort es Snort Log Parser.
Snort Log Parser es un programa que analiza los mensajes de Snort desde el archivo de
log de alertas y los muestra de forma que sea fciles de entender. Esto permite la opcin
de ver solamente los mensajes del da actual por defecto y permite ver das especficos o
todos los das mediante lnea de comando.

Para modificar los archivos de configuracin se puede usar IDS Policy Manager
que ofrece una interfaz grfica amigable para la configuracin de Snort. Tiene la
capacidad aadida de combinar nuevos conjuntos de reglas, manejar preprocesadores,
configurar mdulos de salida y copiar reglas a sensores, facilitando as la configuracin
de Snort.

En la tabla 2-6 se muestra un resumen de algunos mdulos y complementos

existentes para Snort.
24 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Tabla 2-6. Complementos de Snort

Nombre Comentario url
Spade Mdulo detector de http://majorgeeks.com/Sam_Spade_d594.html
Anomalas.
Inline Snort Sistema de Prevencin http://snort-inline.sourceforge.net/
de Intrusos.
BRO NIDS que usa una gran http://www.bro-ids.org/
variedad de mdulos
para el anlisis de
protocolos.
SAM Monitor de Alertas de http://www.darkaslight.com/projects/sam
Snort.
Snort Log Parser Analiza los mensajes http://linux-bsd-
del archivo de alertas central.com/index.php/content/view/17/28/
de Snort.
IDS Policy Facilita el manejo de http://www.activeworx.org/Default.aspx?tabid=55
Manager los preprocesadores y
de las salidas de Snort.
ACID Consola web para http://acidlab.sourceforge.net/
visualizar los registros
de Snort.
BASE Evolucin de ACID. http://sourceforge.net/projects/secureideas/

4 Sistemas que utilizan Snort

Son muchas las arquitecturas que integran Snort como sistema de deteccin de
intrusos un ejemplo es el propuesto en el artculo de la [CAR07]. En l se describe un
SPP-NIDS, que es una arquitectura para deteccin de intrusos, que soporta las reglas
Snort. Proporciona escalabilidad, flexibilidad y rendimiento. Tiene un cluster
parametrizable de procesadores: un procesador controlador IDS, un coprocesador
dedicado reconfigurable, un procesador host e interfaces para unirse a la red exterior y
para unir la red interior. El esquema del SPP-NIDS es el que se muestra en la figura 2-6.

Figura 2-6. Sistema SPP-NIDS

 Captulo 2. Snort 25

Otros autores, han realizado implementaciones mejoradas sobre Snort. El artculo de

Ryan Proudfoot entre otros [PRO07], propone un sistema que ejecuta una versin
mejorada de Snort en el software hasta conseguir el emparejamiento de formas (pattern
matching) y luego descarga el procesamiento sobre una serie de FPGA. Se trata de una
nueva arquitectura co-hardware/software que permitir usar una solucin software
flexible y probada con la velocidad y la eficacia de los dispositivos hardware FPGA.

Snort tambin se ha usado en implantacin de IDS hbridos (permite tanto la

deteccin de anomalas como la de uso indebido). Ejemplo de ello se puede ver en el
artculo de J.E. Daz-Verdejo [GAR07], que se ha comentado anteriormente, en el que
se propone el uso de una versin modificada de Snort para operar como
detector/clasificador hbrido. Esta versin puede ser utilizada durante la fase de
entrenamiento del sistema basado en anomalas y como detector hbrido.

Otras investigaciones proponen la combinacin del IDS Snort con un sistema de

prevencin de Intrusos, IPS [NIC]. El prototipo de la arquitectura propuesta extiende la
funcionalidad bsica de Snort, haciendo uso del preprocesado, que permite el anlisis de
los protocolos de las capas superiores del TCP/UDP. El bloque de preprocesadores es
muy poderoso ya que permite implementar tanto tcnicas basadas en la deteccin de
intrusos como tcnicas basadas en la prevencin.

Otro sistema que usa Snort es SANTA-G (Grid-enabled System Area

NetworksTrace Analysis) [KEN04]. Se trata de una herramienta que monitoriza el
framework que usa el RGMA (Relational Grid Monitoring Architecture).

SANTA-G NetTracer se compone de tres componentes que consideran los datos de

monitorizacin para tener acceso por la R-GMA: un Sensor (que es instalado sobre el
nodo/s para ser monitorizado), un QueryEngine, y un Monitor GUI (como se puede ver
en la Figura 2-7). El Sensor monitoriza los archivos de alertas creados por el sensor
externo Snort, y notifica al QueryEngine cuando se descubren nuevos archivos de alerta.
El sensor monitoriza el archivo de alertas generado por Snort.
26 Utilizacin de Sistemas de Deteccin de Intrusos como Elemento de Seguridad Perimetral

Figura 2-7. SANTA-G NetTracer, monitorizando SNORT

A continuacin se puede ver en la tabla 2-7, un resumen de los sistemas que integran
Snort como Sistema de Deteccin de Intrusos.

Tabla 2-7. Sistemas que integran Snort

Nombre Descripcin Referencia
SPP-NIDS Arquitectura para deteccin de [CAR07]
intrusos, que soporta las reglas
SNORT.
High Performance Software- Propone un sistema que ejecuta una [PRO07]
Hardware Network Intrusion versin mejorada de Snort haciendo
Detection System uso de FPGAs.
Snort Hbrido Implementacin de Snort como IDS [GAR07]
hbrido (deteccin de anomalas y de
uso indebido).
Intrusion Detection and Combinacin de Snort con un [NIC]
Prevention sistema de prevencin de Intrusos,
IPS.
Monitoriza el framework que usa el [KEN04]
SANTA-G RGMA (Relational Grid Monitoring
Architecture).

Adems de sistemas que usan Snort, tambin hay una versin de Snort para el
anlisis de redes inalmbricas. Esta herramienta se llama AirSnort y su nico propsito
es romper la encriptacin WEP (obteniendo as la contrasea de encriptacin) de todas
las redes inalmbricas que se encuentren en el radio de alcance del dispositivo
 Captulo 2. Snort 27

inalmbrico que utilice la herramienta. Esta herramienta opera bsicamente

monitorizando de forma pasiva las transmisiones de las redes inalmbricas que se
producen alrededor del dispositivo inalmbrico que la ejecuta capturando todos y cada
unos de los paquetes que circulan entre las mquinas conectadas a dicha red. [JIM].