Una aproximación basada en Snort para el desarrollo e...

Una aproximación basada en Snort para el desarrollo eimplantación de IDS híbridos

J.E. Díaz-Verdejo, P. García-Teodoro, P. Muñoz, G. Maciá-Fernández, F. De ToroDepartamento de Teoría de la Señal, Telemática y Comunicaciones. Universidad de Granada

ETSI de Ing. Informática. C/ Daniel Saucedo Aranda S/N18071 - Granada

Teléfono: 958 24 23 04 Fax: 958 24 08 31E-mail: [email protected]

Abstract Apart from the modeling techniques, the development and deployment of anomaly-based intrusion detection systems still faces two main problems. The �rst one is relatedto the acquisition and handling of real tra�c to be used for training purposes. The secondone concerns the better performance of signature-based IDS for known attacks. In this paperthe authors propose the use of a modi�ed version of Snort which results in a hybrid detec-tor/classi�er. This version can be used both during the training phase of the anomaly-basedsystem and as a deployed hybrid detector and tra�c sni�er. Furthermore, it can be adjustedto work just as signature-based, anomaly-based or both (hybrid) detector. On the other hand,this version can be used to directly sni�, classify and split the network tra�c according to itsmalicious nature, which eases the problems related to the acquisition and handling of trainingtra�c.

1. IntroducciónLos sistemas de detección de intrusiones (IDS, delinglés Intrusion Detection Systems) constituyenun tema de investigación y desarrollo de enormerelevancia en el contexto actual, dada la gran pe-netración de las redes de ordenadores, en general,y de Internet, en particular, en las actividadescotidianas. Esta expansión de Internet ha venidoaparejada a un fuerte incremento en el númerode incidentes de seguridad [1], con el consiguienteimpacto, tanto económico como tecnológico, en lasactividades y servicios desempeñados. Resulta evi-dente, en consecuencia, la necesidad de disponerde técnicas y sistemas de protección, prevencióny mitigación de fallos frente a actividades mali-ciosas. Entre estos sistemas se encuentran los yamencionados sistemas de detección de intrusiones,cuya �nalidad es detectar actividades maliciosasen un sistema o red de ordenadores y alertara los administradores para que desencadenen losmecanismos de defensa que se consideren opor-tunos [2] [3]. Una evolución de estos sistemasson los denominados IPS (Intrusion PreventionSystems), que incluyen la capacidad de respuestaautomática frente a incidentes sin necesidad deintervención humana. Aunque el presente trabajose centra en los IDS, los problemas, técnicas yprocedimientos que se abordarán también son deaplicación a los IPS.El despliegue de los IDS requiere de la resoluciónprevia de varios problemas de índole tecnológica ylegal. Entre ellos, el más relevante está relacionadocon los métodos de detección de actividad mali-

ciosa a utilizar. Atendiendo a estos, los IDS se sue-len clasi�car en basados en �rmas (signature-based,S-IDS) o basados en anomalías (anomaly-based,A-IDS) [4] [5]. Los primeros utilizan una base dedatos de conocimiento (�rmas o reglas) que incluyelos patrones de actividad de comportamientosmaliciosos conocidos, de tal forma que cualquieractividad detectada que siga algunos de los pa-trones contenidos en la base de datos es etiquetadacomo maliciosa, actuándose en consecuencia. Porel contrario, los sistemas basados en anomalías sefundamentan en la construcción de un modelo dela actividad normal (o anormal en algunos casos)del sistema o red monitorizado, de tal forma quecualquier desviación de dicha actividad es etique-tada como sospechosa o anómala y asimilada a uncomportamiento malicioso (hipótesis de sospecha).Ambos tipos de sistemas presentan ventajas einconvenientes que hacen que ninguna de las dossoluciones sea claramente superior a la otra. Así,los S-IDS resultan más �ables y proporcionanmejores rendimientos frente a ataques conocidos.Sin embargo, su capacidad para detectar nuevosataques no incluidos en la base de datos de �rmases prácticamente inexistente. Por el contrario, losA-IDS presentan la capacidad de detectar ataquespreviamente desconocidos, aunque su rendimientoresulte, con la tecnología actualmente disponible,inferior. En cualquier caso, y sin desdeñar lanecesidad de proteger los sistemas frente a ataquespreviamente observados, resulta de vital impor-tancia disponer de sistemas que sean capaces dereaccionar ante el desarrollo de un nuevo ataque(0-day attacks), al resultar éstos los más dañinos

precisamente por la ausencia de defensas pre-establecidas.En este contexto, en el presente trabajo se presentaun IDS híbrido basado en red (NIDS, network-based IDS) desarrollado a partir de la incorpo-ración de módulos adicionales a Snort [6] [7] que,adicionalmente, puede operar como clasi�cadordel trá�co capturado en las fases de desarrollodel sistema. El sistema resultante puede operar,según la con�guración utilizada, en modo S-IDS(operación normal de Snort), en modo A-IDS o enmodo de detección híbrida (que denominaremosHy-IDS)1.Otro problema que es necesario resolver, especial-mente en el caso de los A-IDS, es la disposiciónde trazas de trá�co capturadas en un entornoreal que posibiliten el análisis de las actividadesobservadas, maliciosas o no, con la �nalidad deextraer �rmas de ataques y/o entrenar los modelosde normalidad, según el caso [8] [9]. Con indepen-dencia de los problemas legales que se planteen,relacionados con la privacidad de los datos, ycentrándonos en el caso de los A-IDS, resulta deinterés disponer de metodologías y técnicas quepermitan una clasi�cación automática del trá�coen diversas categorías en función de sus caracterís-ticas y las necesidades de desarrollo. Así, a modode ejemplo, será interesante disponer de trá�coetiquetado como normal y trá�co etiquetado comoataque para el desarrollo de los modelos de nor-malidad (entrenamiento de los modelos). A esterespecto, los autores han propuesto recientementeuna metodología que permite abordar, con lasgarantías adecuadas, el entrenamiento y ajustede los modelos de normalidad a partir de trá�coreal [10]. Esta metodología requiere del uso deherramientas que permitan capturar y clasi�car eltrá�co obtenido de forma automática, para lo quese ha considerado incluir dicha funcionalidad enlas modi�caciones a realizar en Snort.El presente trabajo se estructura en los apartadosque se describen a continuación. En el Apartado 2se aborda la problemática relacionada con el desar-rollo de A-IDS, especialmente en lo que conciernea la gestión de trá�co real y entrenamiento delos modelos de normalidad. En el Apartado 3 seproponen y describen una serie de modi�caciones ymódulos adicionales para Snort que proporcionanlas funcionalidades requeridas para el presentetrabajo: clasi�cación de trá�co, operación comoA-IDS y operación como IDS híbrido. El sistemaresultante se aplica en el Apartado 4 a un casode estudio, consistente en la implantación de unatécnica de detección de anomalías desarrolladapor el grupo de investigación de los autores,denominada SSM [11], que es aplicada y evaluadaen un servicio HTTP. Finalmente, se presentan unresumen de las características más relevantes delsistema desarrollado y las conclusiones.

2. Desarrollo de IDS basadosen anomalías

El desarrollo de IDS basados en anomalías pre-senta la peculiaridad, frente al basado en �rmas,de necesitar un conjunto de datos a partir de losque obtener los modelos de normalidad en losque se fundamenta la detección. Este problemadista de ser de solución trivial, debido a lasmúltiples características que debe presentar dichoconjunto de datos. Estas características, que seránabordadas brevemente en el apartado siguiente,incluyen la recomendación de que los datos autilizar correspondan a trá�co real capturado enredes en explotación [12] [9], lo que genera losproblemas legales relacionados con la privacidadde los datos anteriormente mencionados. En con-secuencia, aparecen dos efectos importantes rela-cionados con el desarrollo de este tipo de sistemas:la di�cultad de obtención de datos adecuados y laimposibilidad práctica de comparar las diferentestécnicas y sistemas desarrollados, al no ser posiblecompartir los datos de entrenamiento y evaluación.

2.1. Metodología de desarrollobasada en trá�co capturado

Para paliar estos problemas, los autores han pro-puesto recientemente una metodología [10] para lacaptura y acondicionamiento de los datos que per-mite el entrenamiento, evaluación y validación delos sistemas de forma adecuada. Esta metodologíase basa en el establecimiento de particiones enla base de datos de trá�co capturado de acuerdoa dos criterios principales: su carácter normal,anómalo o de ataque y su uso en el desarrollo delsistema, esto es, entrenamiento, test y validación.En la Fig. 1 se muestra un ejemplo de las parti-ciones resultantes en la base de datos en el caso deentrenar un sistema híbrido (basado en �rmas yen anomalías) sin contemplar la validación del sis-tema (particiones para entrenamiento y test), re-sultando en 6 particiones: NormE (trá�co normalpara entrenamiento), NormT (trá�co normal paratest), AnE (trá�co anómalo para entrenamiento),AnT (trá�co anómalo para test), AtE (trá�code ataque para entrenamiento) y AtT (trá�code ataque para test). Evidentemente, según elsistema a desarrollar, algunas de las particionespueden resultar inútiles (e.g., AtE y AnE eneste caso), aunque es necesario de�nirlas parapreservar la representatividad de los resultadosobtenidos (problema de sesgos debidos a faltade proporcionalidad [12] [13]). En cualquier caso,pueden usarse técnicas de tipo Leaving-k-out [14]para aumentar la representatividad de los datos

1Se propone el acrónimo Hy-IDS, del inglés Hybrid IDS en lugar de H-IDS debido a que en la bibliografía se reserva estetérmino para los IDS basados en el ordenador (host)

152 VI Jornadas de Ingeniería Telemática. JITEL 2007

y posibilitar un mayor aprovechamiento de losmismos, al poder usarse todos los datos obtenidos.

En cualquier caso, uno de los problemas prácticosque se plantean, una vez capturado el trá�coreal, es la categorización del mismo como normal,anómalo o ataque. A este �n, en [10] los autoresproponen el uso de un detector basado en �rmascon diferentes versiones de reglas o �rmas (actua-lizadas y no actualizadas) de la siguiente forma(Fig. 2, bloque captura/clasi�cación de trá�co). Enprimer lugar, el tra�co capturado por el programade captura (sni�er) elegido, DB.cap, se clasi�cautilizando un conjunto no actualizado de �rmas,de tal forma que se obtienen los paquetes quegeneran alguna alerta, que serán los paquetes deataque (DB-ataque.cap en la �gura), y se vuelvena procesar los restantes (DB-interm.cap) con unconjunto actualizado de reglas. Este segundo �l-trado separará los paquetes normales (los que noactivan ninguna �rma), DB-normal.cap, de los quese considerarán anómalos (los que activan alguna�rma), DB-anom.cap. Posteriormente será nece-sario establecer las particiones de entrenamien-to, test y validación (no todas mostradas en la�gura) para el desarrollo global del sistema. Esta�losofía de operación está en consonancia con eldesarrollo de detectores híbridos, al considerar quelos ataques que corresponden con �rmas conocidasson detectados por el módulo de �rmas sin ningunadi�cultad y centrar el desarrollo del módulo deanomalías en los ataques de reciente aparición que,es de suponer, serán los que marcarán la tendenciatecnológica de los nuevos ataques.

A partir de los bloques de datos capturados seprocederá al entrenamiento y evaluación de losdetectores.

La aplicación de esta metodología en un entornoreal requiere de la disposición de un IDS basadoen �rmas que sea capaz de clasi�car y separarel trá�co en dos bloques con su�ciente �abilidad,de acuerdo a las �rmas de ataques, y de un IDShíbrido capaz de combinar ambos mecanismos dedetección. Las herramientas disponibles carecen,en la actualidad, de la funcionalidad requerida, yaque los IDS existentes únicamente alertan de unataque y, en algunos casos, lo �ltran eliminándolode la salida cuando operan a modo de �ltrode entrada al sistema. Aunque cabría desarrollarun sistema especí�co, resultaría más adecuadoadaptar un IDS basado en �rmas ya disponiblepara que incorporase estas funcionalidades. Deesta forma, la operación como detector basado en�rmas estaría respaldada por la operación habitualde dicho detector (disponibilidad y �abilidad delos conjuntos de reglas/�rmas). Un sistema quereúne las características necesarias (disponibilidaddel código fuente junto con la �abilidad y disponi-bilidad de las reglas) es Snort [7].

Figura 1: Particionado inicial del trá�co captura-do para el desarrollo de IDS [10].

Figura 2: Metodología para la captura y clasi�-cación de trá�co real basada en Snort.

3. Adaptaciones de SnortSnort es un detector de intrusiones basado en redque utiliza el paradigma de detección mediante�rmas (S-IDS). Es de dominio público, de códigoabierto y de amplia implantación, por lo queexisten bases de datos de �rmas de ataques quese actualizan con frecuencia y que presentan lasgarantías su�cientes para su utilización. Las basesde datos de �rmas presentan varias versiones,dependiendo de su procedencia, destacando las de-nominadas VRT, Vulnerability Research Team, decarácter cuasi-o�cial, y las community rules, cons-tituidas por aportaciones de los usuarios de Snort.Ambos conjuntos de reglas están disponibles enla página o�cial de Snort (http://www.snort.org),existiendo numerosos conjuntos de reglas aporta-dos por otros organismos o individuos. Las reglas

VI Jornadas de Ingeniería Telemática. JITEL 2007 153

VRT son veri�cadas y comprobadas por un equipode trabajo, garantizándose así un nivel de calidadadecuado.La operación de Snort sobre los paquetes captura-dos es secuencial, aplicándose sucesivamente diver-sos módulos, de acuerdo al esquema mostrado en laFig. 3.a). En primer lugar, tras su captura, los pa-quetes son analizados por diversos módulos deco-di�cadores y preprocesadores cuya �nalidad básicaes preparar los paquetes para su análisis (norma-lización, detección de �ujos, etc.). A continuaciónson procesados por los motores de detección que,en función de las reglas activas, van activandosecuencialmente, en el orden establecido por lasreglas, los diferentes módulos detectores asociadosa las mismas. De esta forma, tras ser veri�cado elcumplimiento o no de alguna o varias de las reglas,lo que haría que el paquete fuese considerado comode ataque, se envía a los módulos posprocesadoresindicándose los códigos de las reglas activadas. La�nalidad de los posprocesadores es presentar losdatos a la salida bien mediante la generación de losoportunos informes y estadísticas, bien mediante el�ltrado de los paquetes de ataque, cuando opera enel denominado modo inline [15]. Es importante eneste punto resaltar que, a la salida, sólo es posibleobtener un informe de actividad o los paquetesque no han activado ninguna regla y, por tanto, sepueden considerar inocuos.Las funcionalidades adicionales requeridas rela-tivas a la detección de anomalías serán imple-mentadas en forma de módulos de posprocesado,como se muestra en la Fig. 3.b), ya que debenoperar sobre los resultados de detección obtenidosa partir de las �rmas para no interferir en el pro-ceso habitual. Como se comentará posteriormente,esta aproximación aporta ventajas adicionales alposibilitar un modo de operación híbrido. Por otraparte, la capacidad de generación de dos �ujosde trá�co de salida para separar el trá�co normaly el de ataque debe considerarse, obviamente, enlas etapas �nales del procesamiento y en funciónde los resultados de los detectores, tanto basadosen �rmas como los adicionales basados en anoma-lías. Por tanto, para conseguir las funcionalidadesadicionales requeridas es necesario modi�car el�ujo de procesamiento de Snort en dos aspectos.En primer lugar, se hace necesario incluir algúnmecanismo que etiquete los paquetes que no ac-tiven ninguna regla y, por tanto, no sean con-siderados como de ataque. Este etiquetado actúaa modo de marcado para que, posteriormente,los posprocesadores adicionales que se establezcanpuedan determinar qué paquetes corresponden acada categoría (ataque/no ataque) de acuerdo alconjunto de reglas activas. En segundo lugar, esnecesario añadir dos posprocesadores diferentesencargados de implementar las dos funciones deinterés: analizar los paquetes no marcados comoataques, de acuerdo a la técnica de detección deanomalías deseada, y generar un �ujo de salida

sólo con los paquetes marcados como ataque y otrocon los no marcados.Adicionalmente, será necesario establecer lasvariables globales que requieran las fun-ciones/módulos a implementar, así como losprocedimientos de inicialización y/o �nalizacióntanto de dichas variables como de los módulosañadidos. La �losofía de diseño de Snort [16] facili-ta todos estos procedimientos, teniendo previstospuntos de inserción de rutinas de inicialización,preprocesadores, detectores y posprocesadores.

3.1. Marcado y selección de paque-tes

El marcado de los paquetes se realiza mediantela inclusión de una regla especí�ca �regla dederivación en la Fig. 3.b)� que incluye a todoslos paquetes que se deseen procesar. De estaforma, al considerarse que el paquete es de ataque,se activan los módulos de posprocesado para elmismo. La regla, como cualquier otra regla deSnort, debe contener el nombre del módulo deposprocesado que se activará, las condiciones quedebe cumplir el paquete para que se considereafectado por la misma y algunas opciones respectode la salida que debe presentarse. Así, a modo deejemplo, podría incluirse una regla de la forma:

ruletype selector {type logoutput log_selector: selector.log

} selector tcp any any ->any any(msg:"Marca todo el tráfico";sid:9999;)

que afectaría a todos los paquetes tcp cualesquieraque fuesen su origen o destino, marcándolos comouna instanciación de un ataque asociado a la reglacon número sid=9999. Evidentemente, no sería unataque real, en el sentido de que no ha activadouna �rma de ataque, por lo que, en lo que sigue,diremos que es un falso ataque. En este ejemploconcreto se activaría un módulo de posprocesadodenominado selector al que se enviaría el trá�cocon la identi�cación de la regla activada, sid,con valor 9999 en este caso, almacénándose lainformación asociada a la alerta en el archivoselector.log.El módulo selector asociado responde al esquemadel código mostrado en la Fig. 4. En éste sepuede comprobar que se veri�ca si la regla queactivó la alerta que está siendo procesada es lade derivación (sid=9999 en el ejemplo), en cuyocaso se envía el paquete asociado a dicha reglaa los módulos de posprocesado adicionales y seactualizan los contadores de alertas de Snort y al-gunos auxiliares convenientemente. Para determi-nar el número de alertas generadas por el paqueteque está siendo procesado se utiliza un contadorglobal del número de alertas que se han activado,propio de Snort, junto con otros establecidos al


a) b)

Figura 3: Diagrama de operación de Snort, a) versión o�cial, de acuerdo a [17], b) versión modi�cada.

efecto. Si únicamente se ha activado una reglay ésta corresponde a la de derivación, podremosconcluir que corresponde a un falso ataque yactuar en consecuencia. En caso contrario, será unpaquete de ataque, lo que también determinará elprocesamiento posterior a realizar por los módulosadicionales, en su caso.

3.2. Clasi�cación del trá�coLa clasi�cación del trá�co mediante su separaciónen dos �ujos de salida correspondientes a trá�conormal y a trá�co de ataque se puede realizar deforma sencilla, a partir de la estructura del móduloselector mostrada en la Fig. 4, sin más que progra-mar adecuadamente las rutinas ProcesaLimpio()y ProcesaAtaque(). Estas rutinas pueden haceruso de las funcionalidades propias de Snort paragenerar archivos de paquetes en formato cap y,simplemente, escribir los paquetes en dos archivosdiferentes previamente establecidos.Por tanto, a partir de las modi�caciones propues-tas, únicamente será necesario inicializar/cerrarlos archivos de captura y establecer y gestionarlas opciones de línea de comando asociadas.

3.3. Detección de anomalíasLa inclusión de módulos de detección de anomalíasse hace de forma análoga a la indicada en elapartado anterior, si bien en este caso puederesultar inadecuado procesar un paquete que ya hasido clasi�cado como ataque por el sistema basadoen �rmas si lo que se pretende es simplementesu clasi�cación. En consecuencia, bastaría consustituir la rutina ProcesaLimpio() del móduloselector con la que implemente la detección deanomalías. La información que es posible enviara dicha rutina contiene el paquete completo, in-cluidas cabeceras y carga útil, por lo que son deaplicación los métodos de detección de anomalíasque consideren un único paquete.

En este caso, las rutinas de inicialización y/oterminación pueden resultar de mayor complejidadque en el caso de clasi�cación del trá�co, ya que,obviamente, es necesario establecer la con�gura-ción y parámetros en los que se base la detección,así como generar informes con los resultados.Es posible utilizar la versión de Snort modi�cadade acuerdo a lo indicado únicamente como detectorde anomalías. Para ello bastaría con utilizar comoúnica regla la de derivación, lo que haría quelos paquetes se etiquetasen como falsos ataquesúnicamente.

3.4. Snort como IDS híbridoLa operación de la versión modi�cada de Snortcomo detector híbrido, es decir, que combine ladetección de �rmas y de anomalías, resulta trivialde acuerdo a la �losofía seguida en la introducciónde las modi�caciones. El �ujo de procesamientode los paquetes, en presencia de reglas a las quese añade al �nal la regla de derivación, respondeal mostrado en la Fig. 5. Como se puede observar,los paquetes son analizados en primer lugar porlos módulos ordinarios de Snort, que realizan ladetección basada en �rmas, y, posteriormente, porlos detectores de anomalías que se establezcan.Debido a esta operación de forma natural comodetector híbrido, denominaremos Hy-Snort a laversión modi�cada en lo sucesivo.En cualquier caso, también resulta posible operarde forma inversa, realizando en primer lugar ladetección de anomalías y, posteriormente, la basa-da en �rmas. Para ello únicamente es necesarioincluir en primer lugar la regla de derivación. Eneste caso, todos los paquetes serán consideradosfalsos ataques, independientemente de que puedanser detectados posteriormente como ataques realesy, por tanto, sometidos al proceso de detección deanomalías. Este modo de operación puede resultarde interés para evaluar las capacidades de losdetectores de anomalías incluidos, así como para


global int limpias; // Número de alertas "falsas"global int alertas; // Número de alertas reales (firmas)

void Selector(Packet *p,char *msg,void *arg,Event *event) {unsigned long salert;int nsid;salert=(unsigned long)pc.alert_pkts; // Número total de alertas generadasnsid=(int)event->sig_id; // El número SID que generó esta llamadaif (nsid==9999) { // Actuar solo si regla de derivación

limpias++;if (alertas==salert) { // El paquete actual sólo generó una falsa alerta

alertas++;if (p) { // Llamada a rutinas proc. (Paquete normal)

if (p->packet_flags & PKT_REBUILT_STREAM)ProcesaLimpioStream(p, msg, arg, event);

elseProcesaLimpioSingle(p, msg, arg, event);

}} } else {ProcesaAtaque(p, msg, arg, event); // Llamada a rutinas proc. (Paquete ataque)alertas=salert; //Se actualiza num. alertasalertas++;

}}

Figura 4: Esquema de la función de posprocesado para la selección de paquetes a analizar (móduloselector).

realizar la detección de forma conjunta a partir dela combinación de los informes generados tanto porlos módulos de �rmas como de anomalías de acuer-do a un análisis más complejo. Sin embargo, estaúltima posibilidad no se encuentra actualmenteimplementada.

4. Caso de estudio: im-plantación de la técnicaSSM mediante Snort

Las modi�caciones propuestas han sido implemen-tadas y evaluadas durante el desarrollo de unsistema de detección de intrusiones que utilizatécnicas de detección desarrolladas por nuestrogrupo de investigación. En particular, se ha imple-mentado el sistema de detección de anomalías de-nominado SSM (Segmental Stochastic Modelling)[18], aplicable a las URI de las peticiones delprotocolo HTTP.

Figura 5: Flujo de procesamiento de paquetesdel IDS híbrido propuesto.

Figura 6: Autómata utilizado en el sistema SSMpara el procesado de las URI [18].

De forma breve, el funcionamiento del sistemaSSM se basa en la de�nición de un autómatade estados �nitos estocástico capaz de evaluarla probabilidad de generación de una peticiónconcreta. Dicho autómata, mostrado en la Fig. 6,es obtenido a partir de la especi�cación del propioprotocolo, que de�ne tipos de cadenas (campos)diferenciados, y de las probabilidades de apariciónen cada uno de dichos campos de las diferentes ca-denas que componen la petición. Cada estado delautómata corresponde a uno de los posibles cam-pos: inicial (SI), servidor (SS), camino/recurso(SP ), atributo (SV ), valor (SV ) y �nal (SF ). Cadapetición es segmentada, de acuerdo a un conjuntode delimitadores determinados por el protocolo, enlos campos que la constituyen. Por otra parte, paracada estado existirá un diccionario con el conjuntode posibles valores del campo y la probabilidad decada uno de dichos valores. El autómata permitirá,por tanto, dada una petición, evaluar si dichapetición es legítima (corresponde al modelo) y


Figura 7: Metodología utilizada para el desarrollo e implantación de un IDS híbrido basado en Snort queimplementa la técnica SSM.

su probabilidad. En función de la probabilidad yde un umbral se clasi�carán las peticiones comonormales o anómalas. Por otra parte, aquellaspeticiones que no puedan ser evaluadas debidoa la aparición de transiciones no contempladasserán etiquetadas como fuera de especi�cación,pudiéndose considerar como incorrectas.El modelo propuesto presenta, pues, dos com-ponentes: uno basado en especi�cación y, portanto, establecido a partir del protocolo; y otroprobabilístico, que depende del servidor concre-to considerado, que debe ser estimado a partirde la observación de peticiones lícitas a dichoservidor. Se requiere, por tanto, de una fase deentrenamiento a partir de trá�co libre de ataques.En consecuencia, para el desarrollo de este sistemaresulta necesaria la aplicación de la metodologíadescrita en el Apartado 2.Para la implantación de la técnica SSM se hanutilizado las dos funcionalidades añadidas a Snort,junto con las ya incluidas en la versión original. Enprimer lugar, se ha procedido a capturar trá�coreal mediante el propio Hy-Snort operando comosni�er. A continuación se utilizó la capacidadpara agrupar en dos archivos diferentes el trá�cocapturado separando el trá�co libre de ataques yel trá�co de ataque, de acuerdo a la metodologíapropuesta (Fig. 7, bloque Captura/clasi�cacióntrá�co). A partir de los bloques de datos cap-turados se procedió al entrenamiento y evalua-ción del módulo de detección de anomalías, quefue convenientemente ajustado para optimizar su

rendimiento (bloque Entrenamiento modelos enFig. 7). El sistema fue entrenado con una partedel trá�co libre de ataques y evaluado con el restoy los ataques. La evaluación se realizó mediante eluso del detector de anomalías SSM incluido en Hy-Snort. Una vez ajustado el modelo, se ha procedidoa su puesta en explotación en un entorno real apartir de los modelos desarrollados y las �rmasdisponibles (bloque Implantación exp.).Adicionalmente, una vez en explotación, seanalizaron las capacidades del detector median-te la instanciación de 1500 ataques sintéticosdiferentes generados a partir de la informacióndisponible en [19], con resultados satisfactorios. Esdecir, se alcanzó un 100% de detección operandoen modo híbrido, así como en modo AIDS (opera-ción sin las �rmas de los ataques).El sistema resultante ha mostrado unas presta-ciones acordes a lo esperado, según el sistemaSSM y la detección basada en �rmas. Por otraparte, la inclusión del módulo selector no pro-duce ningún incremento apreciable en el tiempode procesamiento de cada uno de los paquetesoperando en modo híbrido.

5. ConclusionesEn el presente trabajo se han presentado unconjunto de modi�caciones de Snort destinadasa facilitar su utilización en el desarrollo e im-plantación de sistemas IDS híbridos. Las modi�ca-


ciones presentan una doble motivación: posibilitarla implantación de detectores híbridos que combi-nen la detección basada en �rmas con la basada enanomalías con las garantías adecuadas respecto alrendimiento y permitir la clasi�cación automáticadel trá�co capturado en las fases iniciales deldesarrollo de IDS. Las modi�caciones han si-do implementadas satisfactoriamente, habiéndosecomprobado su utilidad durante el desarrollo deun IDS híbrido para la detección de ataquesen las cargas útiles de las peticiones HTTP. Laincorporación de estas características no degradade forma apreciable el rendimiento, en númerode paquetes procesados, y garantiza un nivel dedetección superior o, en el peor caso, igual alproporcionado por el sistema basado en �rmas.Si bien el resultado es satisfactorio, resulta con-veniente explorar la posibilidad de incluir otrascaracterísticas adicionales relacionadas con la de-tección en �ujos de trá�co, en lugar de en paquetesaislados. También resulta de interés la inclusiónde mecanismos que decidan qué paquetes son deataque a partir de la combinación de la informa-ción procedente de ambos tipos de detección.

AgradecimientosEste trabajo ha sido parcialmente �nanciado porel Programa Nacional de I+D+I (2004-2007) delMEC (proyecto TSI2005-08145-C02-02, 70% fon-dos FEDER).

Referencias[1] CERT coordination Center statistics,

http://www.cert.org/stats/cert_stats.html,2006.

[2] Kabiri P., Ghorbani A.; Research on Intrusiondetection and response: A survey, InternationalJournal on Network Security, Vol. 1, N. 2,pp84-102, 2005.

[3] McHugh, J.; Intrusion and Intrusion Detec-tion, Internation Journal on Information Se-curity, Vol. 1., No. 1., pp.14-35, 2001.

[4] Allen, J. y otros; State of the Practice ofIntrusion Detection Technologies. TechnicalReport CMU/SEI-99-TR-028, Software Engi-neering Institute, Carnegie Mellon Univ., 2000.

[5] Estévez-Tapiador, J.M.; García-Teodoro, P.;Díaz-Verdejo, J.E.; Anomaly Detection Meth-ods in Wired Networks: A Survey And Taxon-omy, Computer Communications 0140-3664;Vol 27, pp. 1569- 1584, 2004.

[6] Sturges, S.; Snort users manual, available atwww.snort.org, 2006.

[7] Roesch, M.; Snort-Lightweight Intrusion De-tection for Networks. Proc. USENIX, Lisa,1999.

[8] McHugh, J.; The 1998 Lincoln Laboratory IDSEvaluation. A critique, In RAID 2000, LNCS1907, pp 145-161, 2000.

[9] Antonatos, S., Anagnostakis, K., andMarkatos, E.; Generating Realistic Workloadsfor Network Intrusion Detection Systems,Proc. of the 4th International Workshop onSoftware Performance (WOSP), 2004.

[10] M. Bermúdez-Edo, R. Salazar-Hernández, J.Díaz-Verdejo, and P. García-Teodoro, Propos-als on Assessment Environments for Anomaly-Based Network Intrusion Detection Systems, J.Lopez (Ed.): CRITIS 2006, LNCS 4347, pp.210-221, Springer-Verlag, 2006.

[11] P. García Teodoro, J M Estévez Tapiador,J. E. Díaz Verdejo; Detection of Web-BasedAttacks Through Markovian Protocol Parsing,10th Symposium on Computers and Commu-nications; Cartagena 2005.

[12] McHugh, J.; Testing Intrusion Detection Sys-tems: A Critique to the 1998 and 1999 DARPAIntrusion Detection Evaluations as Performedby Lincoln Laboratory, ACM Transactions onInformation and Systems Security, Vol. 3. No.4, pp. 262-294, 2000.

[13] Athanasiades, N. y otros; Intrusion Detec-tion Testing and Benchmarking Methodologies,Proc. 1st IEEE International Workshop onInformation Assurance (IWIA'03), Darmstadt(Germany), 2003, pp. 63-72.

[14] Duda, R., and Hart, P.; Pattern Classi�cationand Scene Analysis. John Wiley and Sons,1973.

[15] Vossen, J.P.; Snort Technical Guide,disponible en http://www.snort.org/docs/.

[16] HNS Sta�, The Story of Snort: Past, Presentand Future, disponible en http://www.net-security.org/article.php?id=860.

[17] Arboleda, A. Bedón, A.; SnortTMdiagrams for developers, disponible enhttp://afrodita.unicauca.edu.co/ cbedon-/snort/snort.html, 2005.

[18] Estevez-Tapiador, J. M. y otros; StochasticProtocol Modeling for Anomaly-Based NetworkIntrusion Detection, Proc. 1st IEEE Inter-national Workshop on Information Assurance(IWIA'03), pp. 3-12, Darmstadt, 2003.

[19] Arachnids: Advanced ReferenceArchive of Current Heuristics forNetwork Intrusion Detection Systems.http://www.whitehats.com/ids, 2003.


Una aproximación basada en Snort para el desarrollo e...

Documents

Transcript of Una aproximación basada en Snort para el desarrollo e...