Patrones secuenciales para la detención de instrusiones vía web

Texto completo

(1)PATRONES SECUENCIALES PARA LA DETECCION DE INTRUSIONES VIA WEB. JUAN MANUEL SOLER RINCON. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS Y COMPUTACIÓN Bogota D.C., 2005.

(2) PATRONES SECUENCIALES PARA LA DETECCION DE INTRUSIONES VIA WEB. JUAN MANUEL SOLER RINCON. Tesis para optar al título de Ingeniero de Sistemas y Computación. Asesor Jose Eusebio Abasolo. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS Y COMPUTACIÓN Bogota D.C., 2005.

(3) AGRADECIMIENTOS. A mi familia por las oportunidades y el apoyo que me han brindado, por apoyarme en todas las decisiones que he tomado y los valores y principios que me han inculcado. A Jose Abasolo por ser mi asesor y orientarme en este proceso de investigación y desarrollo, por sus aportes y correcciones y disponibilidad e interés durante este proceso. A Jeimy Cano por sus aportes y conocimientos en el tema de seguridad informática. A Andrea Cuervo por su colaboración en la construcción de este documento y por el apoyo incondicional durante este proceso. A mis amigos por su apoyo incondicional durante mi proceso de formación como ingeniero, en especial a Ronald Manrique y Carlos Ochoa, con los cuales compartimos experiencias dentro y fuera de la Universidad..

(4) I. TABLA D E CONTENIDO. LISTA DE ANEXO S..............................................................................................................III INT RODUCCIÓN ....................................................................................................................1 1 1.1. 1.2.. OBJETIVO S......................................................................................................................2 O BJETIVOS G ENERALES..................................................................................................2 O BJETIVOS ESPECÍFICOS ................................................................................................2. 2.. ALCANCE........................................................................................................................3. 3.. JUSTIFICACIÓ N.............................................................................................................4. 4.. ANTEC EDENTES ............................................................................................................5. 4.1. S ISTEMAS DE DETECCIÓN DE INTRUSOS ..........................................................................5 4.2. IDS ACTUALES ...............................................................................................................7 4.2.1. DESARROLLOS EN LA UNIVERSIDAD DE C OLUMB IA ......................................................7 4.2.2. ADAM (AUDIT DATA ANALYSIS AND MINING ).............................................................8 4.2.3. EMERALD ( EVENT MONITOR ENAB LING RESPONSE TO ANOMALOUS LIVE DISTURB ANCES)......................................................................................................................10 4.2.4. LIMITACIONES DE LOS IDS ACTUALES.......................................................................11 5. 5.1. 5.2. 5.3. 5.4. 6. 6.1. 6.2. 7.. DESCRIPCIÓ N DEL PRO BLEMA ................................................................................14 HTTP ...........................................................................................................................14 INYECCIÓN SQ L...........................................................................................................14 CANALES ENCUBIERTOS ...............................................................................................17 C ONCLUSIONES.............................................................................................................18 MARCO TEÓ RICO........................................................................................................19 MINERÍA DE DATOS.......................................................................................................19 PATRONES S ECUENCIALES............................................................................................20 PATRO NES SECUENCIALES PARA LA DETECCIÓ N DE INTRUSIO NES EN HTTP 25.

(5) II. 7.1.1. DISEÑO.......................................................................................................................25 7.2. H ERRAMIENTAS............................................................................................................26 7.2.1. H ERRAMIENTAS DE S OFTWARE..................................................................................26 7.2.2. SPAM........................................................................................................................26 7.2.3. TRANSFORMADOR ......................................................................................................27 7.3. AMB IENTE DE PRUEB AS ................................................................................................28 7.3.1. INYECCIÓN SQ L.........................................................................................................29 7.3.2. CANALES ENCUBIERTOS.............................................................................................30 7.3.3. G ENERADOR...............................................................................................................30 7.4. PRUEBAS Y RESULTADOS ..............................................................................................31 7.5. LIMITACIONES DE LAS PRUEB AS....................................................................................33 8.. CONCLUSIO NES...........................................................................................................34. 9.. CONTINUIDAD Y RECO MENDACIO NES...................................................................35. GLO SARIO ...........................................................................................................................44 REFERENCIAS.....................................................................................................................45.

(6) III. LISTA DE ANEXO S. ANEXO 1: SECUENCIAS DE CO MUNICACIÓ N................................................................36 ANEXO 2: DESCRIPCIÓN DEL SERVIDO R DEL AMBIENTE DE PRUEBAS .................39 ANEXO 3: GENERADO R EN EJ ECUCIÓN.........................................................................40 ANEXO 4: SPAM EN EJ ECUCIÓ N......................................................................................41 ANEXO 5: CAMPOS INVISIBLES DE UNA PAGINA WEB ...............................................42.

(7) 1. INTRODUCCIÓN. El presente trabajo parte de la necesidad de mejorar los mecanismos encargados de la seguridad en una red, específicamente los sistemas que detectan los ataques que se producen sobre la red (Sistemas de Detección de Intrusos). Este trabajo tiene como objetivo analizar información de las actividades realizadas sobre un servidor web, buscando relaciones poco comunes entre los eventos ocurridos, y específicamente se buscan aquellos ataques en los cuales las etapas que los componen pueden ocurrir independientemente, lo cual permite tener lapsos de tiempo variables entre ellas. Inicialmente se describen las principales características de los sistemas de detección de intrusos actuales, y se dan ejemplos de algunos que usan Minería de Datos; luego se dan las desventajas de cada clase. Luego se describe el ambiente de pruebas en el que se simulan las actividades tanto de los usuarios autorizados como de posibles atacantes, una vez se tiene esta información es necesario transformarla para que pueda ser analizada por el algoritmo de Minería de Datos (Patrones Secuenciales). Finalmente se describe la arquitectura del sistema que se usará para afrontar el problema descrito, así como los resultados de las pruebas realizadas, las cuales mostraron que aunque la técnica usada es adecuada, aún es necesario hacer ajustes para que el sistema tenga la capacidad de detectar cualquier ataque que cumpla con el problema descrito..

(8) 2. 1 Objetivos 1.1. Objetivos Generales Aplicar técnicas de M inería de Datos al problema de detección de intrusiones en Intranets ejecutadas sobre http. Esto con el objetivo de apoyar el proceso de generación de reglas de identificación de intrusiones con una herramienta eficiente y con un margen de errores bajo. 1.2. Objetivos Específicos Desarrollar un sistema capaz de, analizando logs, identificar patrones de ataques en los cuales los eventos que lo componen deben ocurrir en una secuencia específica, sin importar el lapso de tiempo entre ellos. Este sistema debe permitir la integración de nueva información obtenida, esto incluye nuevos algoritmos de M inería de Datos, y/o firmas de ataques, las cuales pueden ser suministradas manualmente o generadas por alguna herramienta. Utilizar la técnica de patrones secuenciales para hacer el análisis de intrusiones. Para el conjunto de entrenamiento de este algoritmo se desarrollaran herramientas que generen tráfico normal -simula el proceso de navegación sobre páginas en internet- y que periódicamente ejecuten cada una de las etapas del ataque, para esto se montará un sistema dentro de una red asilada para tener controlado el tráfico que se capture posteriormente. Diseñar el sistema pensando en la escalabilidad, para esto es necesario usar estándares de desarrollo. También se debe tener en cuenta que la escalabilidad del sistema no debe afectar ninguna de las ventajas ofrecidas por el mismo..

(9) 3. 2. Alcance Se pretende desarrollar el componente de detección de un IDS, que use patrones secuenciales como técnica de minería de datos para la detección de ataques via web, cuyas etapas puedan ser ejecutadas independientemente. El sistema resultante debe ser fácilmente integrable y escalable, para que el desarrollo del componente correctivo no implique cambios sobre el mismo. Debido a la gran capacidad de adaptabilidad a diferentes ambientes, y a las variaciones que se pueden hacer sobre los algoritmos de M inería de Datos el sistema aún tendrá áreas de investigación en las cuales se pueden hacer muchas mejoras al sistema, facilitando su continuidad..

(10) 4. 3. Justificación Debido a la necesidad de mejorar los sistemas de seguridad actuales, se hace necesario un sistema versátil que se pueda adaptar a las condiciones cambiantes del medio, no solo en cuanto a su relación con el entorno (plataforma, esquemas de seguridad), sino también frente a las amenazas que debe ser capaz de identificar. Basándose en el aprendizaje del que son capaces los algoritmos de M inería de Datos, se pueden disminuir problemas como: la ventana de vulnerabilidad, ya que la generación de reglas es realizada paralelamente entre el personal especializado en el tema y el IDS, tarea que este último realiza a una gran velocidad, de manera que se disminuye el tiempo de exposición a un ataque. La cantidad de falsos negativos se disminuye ya que se tiene una fuente adicional de reglas, ya que las reglas construidas por el personal especializado solo abarcan el criterio de dicho personal; de manera que al unir las reglas hechas por el personal especializado con las generadas por el sistema se provee protección contra una mayor cantidad de ataques, aunque la validez de las reglas generadas por el sistema también esta sujeta a la evaluación por parte del personal especializado, así que aún se tiene un conjunto de reglas incompleto y/o con errores. Dado que se tiene la suposición de que el sistema tiene una gama de reglas más amplia, se deduce que se disminuye la cantidad de ajustes necesarios. Adicionalmente se tiene que algunos de los ajustes se consiguen entrenando al sistema con un nuevo conjunto de datos, de manera que el modelo construido es afinado. El uso de patrones secuenciales le da la capacidad al sistema de analizar información en busca de ataques que puedan ser ejecutados en un lapso de tiempo variable, esta es un área en la que aún no se tiene protección alguna..

(11) 5. 4. Antecedentes 4.1. Sistemas de Detección de Intrusos Los mecanismos necesarios para garantizar la seguridad de un sistema son muy variados debido a las funciones que cumplen, estos mecanismos intentan prevenir, detectar, y mitigar el efecto de los ataques o intrusiones dirigidos hacia el sistema. La detección de intrusos es el área aplicada de la seguridad informática encargada de informar de eventos que puedan tener lugar en un sistema informático y pueda ser considerado, por unas u otras razones, como parte de un intento de intrusión. Los sistemas que se encargan de realizar ésta tarea son los Sistemas de Detección de Intrusos (IDS), cuya función es “notificar en tiempo real de los ataques que se producen en las infraestructuras TIC” [19]. Existen diferentes clases de ID S, los cuales pueden ser clasificados según la tecnología usada [20]: Tecnología Específica Detección de Patrones. M inería de Datos. M étodos estadísticos. Características Detectan ciertas actividades en diferentes puntos de la arquitectura organizacional que indican una actividad que pertenece o se relaciona con ataques conocidos. Realizan la misma tarea que en la detección de patrones, con la diferencia que estos son generados por el algoritmo en si. Identifican desviaciones numéricas en ciertos indicadores, basándose en perfiles previamente definidos.. Tabla 1: Mensajes entre cliente y servidor [20]. Los IDS más difundidos usan reglas preestablecidas, las cuales tiene información acerca de cómo se lleva a cabo un ataque en específico, así que la información que pasa a través del IDS es comparada con dichas reglas. En el caso en el que la información cumpla con el patrón descrito en la regla, el ID S lanza una alerta. Inicialmente los IDS eran de dos clases: los IDS a nivel del host (HIDS) y los IDS a nivel de red (NIDS); los HIDS son aquellos que analizan los logs generados por la máquina donde se encuentra el sistema objetivo de la intrusión; esto incluye tanto logs de los servidores web, ftp, etc, como logs del sistema operativo. Los NIDS son aquellos que analizan el tráfico en tiempo real, es decir que el NIDS analiza todo el tráfico de red en el momento en el que es generado, y lo compara con las reglas que tiene para identificar si es un ataque o no [1] [20]..

(12) 6. Figura 1a: Ubicación de un HIDS [20] Figura 1b: Ubicación de un NIDS [20]. Tomando en cuenta que ningún sistema provee seguridad total y que la comunidad hacker evoluciona rápidamente en los tipos de ataques que realiza, es necesario que los sistemas de seguridad también evolucionen. Con este objetivo se crean nuevos tipos de IDS, los cuales deben ser clasificados según el método usado para hacer la identificación: la primera clase la conforman los Sistemas de Detección de Anomalías (ADS), los cuales trabajan de forma muy diferente ya que lo que hacen es construir un patrón del comportamiento normal de una gran variedad de ambientes: conexiones de red, llamadas al sistema, y otros [13], así cuando un paquete se salga del patrón se genera una alerta, la segunda clase la componen los detectores de usos indebidos (misuse detection), cuyo objetivo es identificar ataques comparando la actividad de red actual con las actividades que se espera que realice un ataque [16]. En ambos casos existen IDS que usan M inería de Datos y análisis estadístico. Los sistemas que usan técnicas de M inería de Datos tienen la capacidad de “aprender” de sucesos ocurridos en el pasado; basándose en estos es posible crear patrones de actividades que se usan para generar reglas que describan dichas actividades, las reglas mencionadas pueden ser refinadas entrenando posteriormente al sistema con un conjunto diferente de información, esto con el objetivo de hacer las reglas más precisas y confiables. Debido a que se identifica un patrón y no un ataque específico, es posible generar reglas que identifiquen variaciones de ataques que aun no hayan ejecutado. Algunos de los sistemas con un alto grado de madurez en el tema son los siguientes: un conjunto de sistemas desarrollados en la Universidad de Columbia [8], ADAM [9] desarrollado en George M ason University, y EM ERALD [10] desarrollado en el SRI (Stanford Research Institute)..

(13) 7. 4.2. IDS Actuales 4.2.1. Desarrollos en la Universidad de Columbia En la Universidad de Columbia se desarrollaron un conjunto de herramientas que en identifican patrones de actividades y optimizan su funcionamiento. Los modelos de detección son construidos usando algoritmos de aprendizaje de máquinas con base en costos dados (costo que puede tener un ataque en específico, para un sistema específico). El sistema encuentra grupos (clusters) de firmas de ataques y perfiles normales, y con base en lo anterior construye un modelo por cada grupo, para así obtener la máxima utilidad de cada modelo. 4.2.1.1.Sensores El conjunto de desarrollos hechos en las Universidad de Columbia pueden ser apliacados a diferentes ambientes de donde se puede extraer información El conjunto de sensores usados esta compuesto por: • •. Un grupo de BAM `s (Basic Audit M odules), para Windows y para Unix, con los cuales se registra información de los procesos del sistema y del tráfico de red. Wrappers [21] de archivos y procesos que registran todos los accesos a/de un archivo o proceso.. Para la comunicación entre los sensores se desarrolló un lenguaje basado en XM L, el cual cumple con el estándar del Formato de Intercambio de M ensajes en Detección de Intrusos (IDM EF) [11], y que permite a cualquier ID S que cumpla con el estándar; conectarse a la infraestructura. 4.2.1.2.Construcción de Modelos Se desarrolló el sistema M ADAM /ID (M ining Audit Data for Automated M odels for Intrusion Detection) [22], cuyo objetivo es analizar la información para catalogar la información que servirá de entrada para los algoritmos de generación de modelos, para realizar dicha clasificación se usan dos algoritmos [8]: •. Una variante del algoritmo de reglas de asociación fue desarrollado, para identificar las principales variables que caracterizan a un ataque en especial.. •. El algoritmo de episodios frecuentes tiene como objeto encontrar relaciones entre eventos, por ejemplo eventos sobre la red que generalmente ocurren al mismo tiempo..

(14) 8. Para la generación de los modelos se uso RIPPER (algoritmo de aprendizaje de máquinas) [22]; las reglas generadas por dicho algoritmo son fácilmente entendibles por personas y/o un sistema. Posteriormente el equipo de la Universidad de Columbia hizo cambios sobre el conjunto de entrenamiento de RIPPER, para minimizar el número de clasificaciones erróneas, lo que condujo al desarrollo del algoritmo AdaCost [9]. El problema de la sobrecarga que un IDS genera es permanente y en el caso en el que se use minería de datos es aproximadamente cuatro veces mayor, para afrontar este problema se desarrolló un sistema de evaluación de reglas, que divide las tareas pesadas computacionalmente en dos o más computadores, con lo cual se consigue reducir la sobrecarga y disminuir el tiempo de repuesta [9]. La sobrecarga también puede ser consecuencia de un ataque, en el que el objetivo es el IDS; para afrontar esto se construyó un modelo en el cual la variable objetivo es el costo operacional del IDS, con lo cual se logra tener un modelo del rendimiento del ID S para que se puedan identificar las ocasiones en las que el rendimiento baja y sus causas. Ante la necesidad de liberar modelos rápidamente, sin procesos de re-entrenamiento que requieran mucho tiempo, para esto se trabajó sobre un sistema basado en múltiples modelos llamado JAM que usa un sistema de reglas de decisión para incorporar eficientemente modelos a un sistema. El primer paso es convertir un modelo de intrusiones a un modelo combinado de intrusiones y anomalías, esto se hace insertando anomalías artificialmente en el conjunto de entrenamiento, este algoritmo se llama DBA2 (Distriution-Based Artificial Anomaly), cuya salida es un detector que es capaz de identificar ataques conocidos, tráfico normal o tráfico anómalo. Posteriormente se agregan reglas para identificar los nuevos ataques. Realizando pruebas se llegó a la conclusión de que el esquema de ensamble reduce en aproximadamente 150 veces el tiempo de construcción de nuevos modelos frente a un sistema monolítico [9]. El conjunto de datos de entrenamiento del sistema debe estar catalogado como normal o anormal, pero no se tiene la seguridad de que la información que se tiene como normal, en realidad lo sea, ya que mientras se capturaba dicha información un ataque pudo estar en curso. Para evitar este problema se uso SIMNET, que es una herramienta desarrollada por el M IT con el fin hacer una simulación de tráfico de red. Adicionalmente en el análisis en tiempo real se tiene una probabilidad P de que un dato sea normal y 1-P de que sea una anomalía, de manera que para un dato para el que se desconozca su procedencia se puede hacer una aproximación de a que grupo pertenece. 4.2.2. ADAM (Audit Data Analysis and Mining) Primero se construye una base de datos con un conjunto de información frecuente usando minería de datos sobre información que este libre de ataques. Luego se corre un algoritmo,.

(15) 9. que analiza el tráfico en tiempo real para encontrar información frecuente en las últimas D conexiones, las cuales son variables; esta información es comparada con la encontrada en la primera fase, si no concuerda quiere decir que la información que se está analizando no es normal, de manera que pasa a ser catalogada por un algoritmo de clasificación (árboles de decisión), el cual ha sido previamente entrenado [9][18]. El proceso de identificación de información frecuente (fase de entrenamiento) se hace usando el algoritmo de reglas de asociación, que tiene en cuenta la hora del día y el día de la semana, de manera que se puede identificar la naturaleza de la información analizada, este proceso construye el perfil de actividades normales que será usado para comparar los ítems frecuentes encontrados [9].. Figura 3: Fase de entrenamiento de ADAM [9]. Debido a que inicialmente se sabe cual es la información que contiene las amenazas dentro del conjunto de entrenamiento, se guarda con un vector de parámetros asociados (salida de la primera fase del entrenamiento), y con estos parámetros se hace el entrenamiento del algoritmo de clasificación [9]. La segunda etapa consiste en analizar el tráfico en tiempo real, etapa en la cual la información es buscada en el perfil generado, si hay coincidencias significa que ese tipo de tráfico es normal y no realiza ninguna acción sobre él, la información que no concuerde con el perfil generado es analizada más profundamente para ser clasificada, en esta clasificación existen 3 categorías [9]: ataque conocido, ataque desconocido, o falsa alarma, de donde se resalta la segunda categoría ya que ningún conjunto de entrenamiento puede preparar un.

(16) 10. algoritmo para detectar ataques desconocidos, esto lo hace creado una categoría por defecto, a la cual asigna la información que no es capaz de clasificar en ninguna de las categorías establecidas.. Figura 4: Descubriendo Intrusiones con ADAM [9]. 4.2.3. EMERALD (Event Monitor Enabling Response to Anomalous Live Disturbances) Este sistema está diseñado con una alta capacidad de integración e interoperabilidad con sistemas militares y comerciales, mediante el uso de monitores que pueden funcionar de manera distribuida, y se pueden ajustar a los cambios de la red o del sistema en si. El sistema tiene una arquitectura de capas. 4.2.3.1.Arquitectura Tiene 3 tipos de monitores: monitores de servicios, de dominio, de empresa. Los monitores de servicios analizan las actividades sobre los servicios prestados (web, ftp) y la infraestructura de la red; pueden interactuar pasivamente con el entorno (leyendo logs) o activamente probando la captura de datos. Este cubrimiento de servicios e infraestructura del dominio es el componente a más bajo nivel en el esquema de capas de EM ERALD. Los monitores de dominio conforman la segunda capa dentro del esquema. Relacionan los reportes de intrusión de los monitores de servicios para tener una visón más amplia de de las actividades globales, cubriendo ataques sobre múltiples servicios. Adicionalmente reconfigura los parámetros del sistema, haciendo un puente con otros monitores fuera del dominio, y reportando las amenazas a los administradores. Los monitores de empresa componen la capa más alta, cuya función es relacionar y distribuir la información de los monitores de dominio. Contiene todos los parámetros de los monitores y la semántica de los análisis a realizar para un objetivo específico..

(17) 11. El flujo de información entre los monitores se hace mediante la suscripción: un monitor se puede suscribir para recibir la información de otro, de manera que cuando se produzcan resultados, un monitor envía dichos resultados a todos los monitores-cliente suscritos a ese monitor. 4.2.3.2.Descripción General de Monitores La arquitectura es lo suficientemente flexible para poder incluir o retirar un motor de análisis; la configuración inicial de EM ERALD combina análisis basado en firmas con el análisis estadístico de perfiles, pero puede tener cualquier otro método para el análisis de eventos o simplemente tener una respuesta generada por otro monitor. El hecho de que un monitor se suscriba para recibir información de otro monitor hace que el sistema sea escalable y adaptable a cambios en la infraestructura de la red, y que las alertas se propaguen en el momento en el que el ataque esta en curso. Al realizar un análisis estadístico de perfiles se está preparando contra variaciones de ataques existentes, la ventaja de este análisis es que se pueden tomar medidas frente ataques que aun no suceden. La información de entrada para los monitores de servicio puede ser: información de auditoria, tráfico de red, tráfico SNM P, logs, resultados del análisis de otras herramientas. La información de salida del análisis es un pequeño grupo de reportes (con respecto a la cantidad de información de entrada), que sirven de entrada para el resolutor, cuya función es coordinar dichos reportes y es el encargado de implementar las políticas de respuesta frente a un ataque. El centro del sistema es llamado el objeto-recurso, que contiene la información de configuración de un objetivo específico y métodos que le permiten ser independiente del objetivo analizado. 4.2.4. Limitaciones de los IDS Actuales Cada implementación tiene limitaciones propias, a continuación se muestran las principales desventajas de cada una: Limitaciones de los IDS a nivel del host [26]: • • • • •. Se coloca en la máquina a analizar Se debe deshabilitar la generación de logs. Se debe verificar la integridad archivos. Sobrecarga de la máquina, y por lo tanto baja el rendimiento de la misma. Dependencia de entre las aplicaciones instaladas en la máquina, ya que una falla (casual o debida a un ataque) en una puede afectar a las demás [19].. Limitaciones de los IDS a nivel de red [26]:.

(18) 12. • • • •. La cantidad de firmas puede hacer bajar el rendimiento de la red, ya que todas deben ser evaluadas. Calidad de las firmas. Alta capacidad de procesamiento de paquetes. Entendimiento y procesamiento de cada protocolo.. Limitaciones de los ADS [26]: • Las implementaciones actuales producen demasiados falsos positivos y negativos. • No se identifica la causa de la anormalidad, por lo tanto no es posible identificar el ataque de una forma precisa. Limitaciones de los Detectores de usos indebidos (M isuse detection) [26]: • No puede detectar algo desconocido. • Necesita ser actualizado constantemente con nuevas reglas. • Fácil de engañar. Adicionalmente existen limitaciones comunes para algunas de las clases de IDS: •. En los sistemas que tienen reglas de reconocimiento fijas, un nuevo tipo de ataque primero tiene que ser identificado, lo cual adiciona un factor de incertidumbre en la detección debido a que dicha identificación depende de la habilidad de la(s) persona(s) para realizar un proceso exhaustivo de análisis del recurso que se esta protegiendo, luego se deben realizar los cambios necesarios a la implementación del IDS, lo cual puede ser muy demorado, dejando una ventana de vulnerabilidad alta y la necesidad de estar realizando continuos ajustes, lo cual es costoso.. •. Los falsos positivos y los falsos negativos son comunes en todos los IDS.. •. Para el caso específico de HTTP, se tiene que es un protocolo de comunicación con proxies/gateways hacia otros sistemas, incluyendo sistemas soportados por otros protocolos [2]. El problema que existe es que en una organización típica, protegida por un firewall, se permite el tráfico HTTP o HTTPS, y ya que sobre dicho protocolo viaja información de muchos otros protocolos; HTTP se vuelve un medio el cual puede ser muy usado para dirigir los ataques una organización [3] [12].. •. Algunos IDS comerciales no han sido exitosos debido a la gran cantidad de falsas alarmas y a sus limitaciones en cuanto a escalabilidad e integración con otros sistemas existentes [5].. •. Los IDS actuales no tienen en cuenta la posibilidad de actividades que provengan de diferentes fuentes, o en los cuales los eventos ocurran con un intervalo de tiempo elevado..

(19) 13. Los IDS que usan técnicas de inteligencia artificial y análisis estadístico contribuyen a solucionar parte de las limitaciones mencionadas, pero generan nuevos problemas: • •. Debido a la mayor complejidad, estos sistemas son más caros en cuanto a su implementación y mantenimiento. Debido a que se hace un análisis más profundo, el procesamiento requerido aumenta..

(20) 14. 5. Descripción del Problema Ninguno de los IDS descritos tiene la capacidad de correlacionar eventos que puedan ocurrir independientemente; los atacantes usan esta debilidad para ejecutar los pasos de un ataque con lapsos de tiempo variables entre ellos, así que estos ataques aún siguen si poder ser prevenidos y/o detectados. Dos ejemplos de ataques que pueden ser llevados a cabo de ésta forma son: Inyección SQL y Canales Encubiertos. Para la detección de este tipo de ataques se necesita un sistema que este en la capacidad de adaptarse a las variaciones de los ataques, variaciones que principalmente consisten en el orden de ejecución de las etapas y/o el tiempo transcurrido entre ellas; dicha capacidad de adaptación implica que el sistema debe “aprender” de la información analizada para incorporar algún patrón encontrado al conjunto de información que el sistema toma como base para realizar la identificación de ataques. 5.1. HTTP Una dificultad que presenta la realización de cualquier ataque es como hacerlo pasar desapercibido, ya sea ante los sistemas de seguridad o ante los ojos de cualquier persona que pueda realizar un análisis de las actividades realizadas sobre los sistemas de la empresa. Para el caso de los sistemas de seguridad, se tiene que los firewall [24] permiten el tráfico a través de http debido a que es un protocolo sobre el cual se envía todo tipo de información, y que es ampliamente usado. 5.2. Inyección SQL El objetivo de este ataque es acceder y/o modificar la Base de Datos de un sistema de forma no autorizada y se basa en la falta de manejo de los errores que ocurren en el procesamiento de las solicitudes hechas por los usuarios, ya que esto es evidencia que el atacante puede usar para identificar cómo están construidas las páginas del sistema y así saber las vulnerabilidades del mismo [25]. Cuando un sistema solicita información del usuario, este puede introducir cualquier tipo de información, es en este momento donde se pueden realizar las pruebas mencionadas. Para el caso de aplicaciones web, este ataque resulta muy fácil de llevar a cabo, ya que este únicamente consiste en la manipulación de la información enviada por el cliente al sistema, e incluso en los casos en los que el sistema restringe ésta información usando campos que solo permiten algunas opciones (checkbox, select) [23], el atacante puede realizar el ataque ya que toda la información es enviada en el URL, o incluso este puede construir una solicitud con las características deseadas. La forma de identificar los puntos donde la aplicación web es vulnerable es modificando los parámetros del URL enviado [25]; la vulnerabilidad existe en aquellas páginas que devuelven errores de Base de Datos (Figura5), ya que esto muestra que no se realiza una correcta validación sobre los parámetros enviados, sino que estos son enviados directamente a la Base de Datos. Adicionalmente algunos servidores de Base de Datos.

(21) 15. devuelven partes de la sentencia que generó el error, lo cual resulta muy útil para el atacante, ya que se identifica cual fue el error y por lo tanto es fácil identificar como corregirlo.. Figura 5: Error de Base de Datos al manipular los parámetros de un URL. Sabiendo esto, el atacante solo necesita saber como se construye la sentencia que es enviada al servidor para poder llevar a cabo el ataque, lo cual resulta muy fácil ya que las sentencias SQL tienen una estructura básica, de manera que una sentencia clásica puede ser construida de la siguiente manera: sentenciaSQL = “Select nombre from usuarios where login=´” + strLogin password =´” + strPass + “´” Si el usuario (atacante) en los campos de login y password sentencia generada sería la siguiente:. + “´ AND. introduce “ÓR´´=´”, la. Select nombre from usuarios where login=´ÓR´´=´´ AND password =´ÓR´´=´´.

(22) 16. En este caso la condición ´´=´´ siempre es verdadera, y al estar con el operador “OR” toda la condición del “where” es verdadera para todos los registros de la tabla “usuarios”, devolviendo así los nombres de todos los usuarios existentes en dicha tabla, esta respuesta es generalmente suficiente prueba de autenticación exitosa, dándole acceso al sistema con el perfil del primer usuario devuelto por la Base de Datos.. Figura 6: Acceso concedido usando Inyección SQL.. La siguiente modalidad es adicionar sentencias SQL completas, esto se hace usando las sentencias a las cuales se le agregan los parámetros enviados en el URL. Una forma de identificar cuando es posible hacer este tipo de ataque es adicionar la cadena “ OR” a uno de los parámetros del URL, si se produce un error, es posible llevarlo a cabo [25]. Un ejemplo de este ataque puede ser realizado cuando el sistema tiene una sentencia del siguiente estilo: SELECT nombre FROM empleados WHERE cedula=” + strCedula En este caso si el usuario en el campo de cedula escribe lo siguiente: “-1 UNION SELECT login FROM usuarios”, se invalidará la primera sentencia, ya que probablemente no haya.

(23) 17. una ciudad con el identificador “-1”, así que solo se devolverán los resultados correspondientes a la sentencia agregada. En el caso de “UNION” se deben usar la misma cantidad de columnas que en el “SELECT”, y los tipos de estas columnas también deben coincidir, el atacante debe identificar la cantidad de columnas, y el tipo de cada de una de estas por prueba y error y basándose en los mensajes de error que el servidor devuelve [25]. Si se examinan todos los casos, es posible identificar que s iempre es necesario realizar una etapa de pruebas, en la cual se debe identificar el servidor de Base de Datos, las páginas donde es posible realizar el ataque, y las vulnerabilidades de dichas páginas. 5.3. Canales Encubiertos Un canal encubierto puede ser descrito como: “Cualquier canal de comunicación que puede ser aprovechado por un proceso para transferir información en una manera que viola un política de seguridad del sistema” y es usado para transferir información a usuarios del sistema que normalmente no tendrían acceso a dicha información [17]. Para ejecutarlo se necesitan dos programas, uno afuera de la red (servidor) y otro que este en una máquina dentro de la red (cliente) que tenga acceso al servidor del cual se quiere sacar la información, este último debe ser introducido por medios que no hacen parte de esta investigación (virus, mail). El servidor es el encargado de recibir la información que envíe el cliente, esto quiere decir que en el servidor es donde se especifica que es el lo que el cliente debe hacer en un momento determinado; de igual manera el cliente realiza la tarea especificada por el servidor y envía la respuesta. Una de las mejores formas de ocultar toda esta comunicación es usando http para que los sistemas de seguridad no puedan detectarla; para esto el servidor debe ser un servidor web y el cliente debe ser configurado para construir solicitudes de páginas html y para procesar la correspondiente respuesta, adicionalmente dicha comunicación se hace usando campos no visibles para el usuario final (Ver Anexo 5). La comunicación entre el cliente y el servidor se hace usando los encabezados de las páginas (aquellos invisibles para el usuario final): el servidor manipula el “Content-Type” para dar las instrucciones al cliente, mientras que el cliente usa “Accept” para enviar las respuestas [17]. En la Tabla 2 se ve un ejemplo de los valores que pueden ser enviados por el cliente y el servidor:. Servidor image/gif. Comandos Cliente-Servidor Significado Cliente Solicitud de image/gif conexión al FTP. Se envía login en el. Significado Conexión iniciada, FTP abierto..

(24) 18. parámetro “ProgID” y password en “Generator”. image/jpeg Solicitud de la image/jpeg Enviando lista de lista. Se archivos del envía una FTP lista de archivos separa por “,” en el parámetro “lista=”. image/png Solicitud de image/png Enviando envió de archivo archivo. Se solicitado. envía el Se envía el nombre del archivo en archivo en el el parámetro parámetro “Originator” “archivo=”. El archivo va codificado con encode64. image/tiff Solicitud de image/tiff La cierre FTP y conexión se finalización ha de finalizado. comunicación. Tabla 2: Mensajes entre cliente y servidor [17]. 5.4. Conclusiones En estos dos casos se puede ver que los ataques pueden ser llevados a cabo sin evidencia alguna de que fueron realizados ya que son ejecutados de manera que parezcan funciones normales del sistema, y una ventaja adicional de estos ataques es que el atacante no necesita obtener privilegios y no necesita instalar ningún software que sirva como indicio para el administrador, lo cual le da la oportunidad de ejecutar el ataque en cualquier momento, donde cada uno de sus pasos puede ser llevado a cabo sin realizar otros pasos anteriormente, esta característica hace que los rastros dejados sean mínimos y cada uno de ellos esta dentro de una gran cantidad de información, lo cual lo hace difícilmente detectable..

(25) 19. 6. Marco Teórico 6.1. Minería de Datos La M inería de Datos es el proceso de exploración y análisis de grandes cantidades de información con el objetivo de encontrar información no trivial. Existen 6 actividades que pueden ser realizadas, en cada una de las cuales se extrae nueva información relevante; el objetivo de las 3 primeras actividades es construir un modelo que describa una variable en particular en términos del el resto de información disponible, en las siguientes 3 actividades no hay una variable objetivo, lo que se busca es establecer relaciones entre todas las variables [15]: •. Clasificación: la clasificación consiste en la asignación de una categoría específica a cada uno de los registros del conjunto de entrenamiento. El objetivo es construir un modelo que puede ser aplicado a un conjunto de información sin clasificar para clasificarlo con ayuda del modelo.. •. Estimación: La estimación realiza la misma tarea que la clasificación, con la diferencia de la forma como se muestran los datos. La clasificación da como resultado una variable discreta, la cual representa una categoría especifica: si o no, bueno, regular, malo, etc. La estimación da como resultado una variable continua, esto quiere decir que el resultado es un valor numérico, ya sea un porcentaje, un valor de probabilidad, etc. Una vez se ha hecho la estimación, puede ser realizada la clasificación sobre el resultado usando los valores estimados, las categorías son definidas con base en límites para los dichos valores.. •. Predicción: cualquier predicción puede ser vista como clasificación o estimación, la diferencia es que dentro del conjunto de entrenamiento, el valor de la variable objetivo es conocido de antemano, así que el modelo construido describe el comportamiento de la variable objetivo y el valor de ésta puede ser predicho.. •. Agrupación por afinidad o Reglas de Asociación: dado un grupo de datos, la agrupación por afinidad o reglas de asociación consiste en hallar reglas que definen relaciones entre las variables del conjunto de entrenamiento, por ejemplo los productos que generalmente van juntos en una compra de supermercado.. •. Clustering: consiste en clasificar la información en grupos con cierta similaridad, estos grupos y las características que lo identifican son encontrados por el algoritmo en si, a diferencia de la clasificación que se base en clases predefinidas. Estas características hacen que sea una actividad que se realiza comúnmente antes de hacer otra de las actividades..

(26) 20. •. Descripción y Visualización: al usar esta técnica se busca proveer un mejor entendimiento de los datos, en esta etapa hace falta la interpretación por parte del personal especializado para dar un concepto acerca de los patrones encontrados.. 6.2. Patrones Secuenciales Este algoritmo busca relaciones entre eventos que no ocurren al mismo tiempo, dichas relaciones se buscan sobre eventos que ocurren cronológicamente en orden. La forma de controlar que se encuentren relaciones no triviales es buscar secuencias que la mayoría de los clientes tengan. Partiendo de que se buscan secuencias de eventos, es necesario primero definir que es una secuencia y como se construye, para esto es necesario primero definir lo siguiente [14]: Item: elemento o evento que puede ocurrir en instante determinado. Transacción: serie de ítems ordenada cronológicamente. Secuencia: serie de transacciones ordenadas cronológicamente. Una secuencia X está contenida en una secuencia Y si todos los ítems de de X están contenidos en Y en el mismo orden que ocurren en X [14]. El conjunto de entrenamiento está construido de la siguiente forma: (cid, tid, X), donde cid es el identificador del cliente, tid es el identificador de la transacción, el cual se basa en el tiempo, lo cual significa que no hay dos identificadores de transacción iguales, y X es el identificador del item; este esquema puede ser visto de la siguiente manera [14]. CID 1 1 1 2 2 3 3. TID 1 3 6 2 4 5 7. Itemset {a,b,d} {b,c,d} {b,c,d} {b} {a,b,c} {a,b} {b,c,d}. Tabla 3: Eventos realizados por los usuarios (Vista de Transacciones ) [14].. Para efectos de entendimiento del funcionamiento del algoritmo la anterior vista es transformada a la vista de secuencia [14]: CID 1 2 3. Secuencia {a,b,d},{b,c,d},{b,c,d} {b},{a,b,c} {a,b},{b,c,d}. Tabla 4: Vista de secuencia de los eventos realizados por los usuarios [14]..

(27) 21. El soporte de una secuencia S es definido como el número total de secuencias que contienen a S. Partiendo de esto se dice que una S es un patrón secuencial frecuente si el soporte de este supera un mínimo establecido. 6.2.1. Mapas de Bits Verticales Esta es una variante del algoritmo clásico y recibe su nombre ya que usa mapas de bits para almacenar la información acerca de las secuencias. Se crea un mapa de bits para cada posible secuencia que pueda ocurrir, así que para calcular el soporte de una secuencia dada, solo es necesario hacer una búsqueda sobre el mapa de bits correspondiente. Para calcular cada posible secuencia y su respectivo soporte, se crea un árbol, cuya raíz es una cadena vacía, y los nodos se van construyendo a partir del nodo padre usando una los dos siguientes métodos [14]: •. Extensión de tipo secuencia: se adiciona una secuencia de tamaño 1. {a,b}Æ{a,b}{a} • Extensión de tipo elemento: se adiciona un elemento al último ítem de la secuencia. {a,b}{a,b} Esto quiere decir que cada uno de los hijos de la raíz es cada uno de los ítems existentes (que cumplan con el soporte mínimo) y así sucesivamente hasta construir un árbol 1 lexicográficamente ordenado. Esta estructura de árbol permite validar el principio Apriori 1 rápidamente ya que una vez una secuencia ha sido catalogada como no frecuente, no se realizan extensiones a esta.. 1. Una vez una secuencia ha sido catalogada como no frecuente, se descart an todas las posibles secuencias que se derivan de esta [15]..

(28) 22. Figura 7: Árbol lexicograficamente ordenado [14].. A continuación se muestra todo el procedimiento explicado reflejado en los mapas de bits: cada ítem/secuencia tiene un mapa de bits asociado, el cual solo tiene una columna y tiene una fila por cada transacción, y se le da la siguiente interpretación: si en la posición k del mapa de bits del ítem/secuencia j hay un uno significa que j aparece en la transacción k. Si se tiene el conjunto de datos del Tabla 3, el correspondiente mapa de bits queda de la siguiente manera [14]: CID. TID. 1 1 1 2 2. 1 3 6 2 4. {a} {b} 1 0 0 0 0 1. 1 1 1 0 1 1. {c}. {d}. 0 1 1 0 0 1. 1 1 1 0 0 0.

(29) 23. 2 2 3 3 3 3. 5 7 -. 0 0 1 0 0 0. 0 0 1 1 0 0. 0 0 0 1 0 0. 0 0 0 1 0 0. Tabla 5: Mapas de Bits [14].. •. Secuencias extendidas de tipo elemento: para generar las secuencias de este tipo se realiza un AND entre la posición k (K=1,2,..,m, m= tamaño del mapa de bits) de los mapas de bits en los cuales se esta basando para realizar la extensión. CID. TID. 1 1 1 2 2 2 2 3 3 3 3. 1 3 6 2 4 5 7 -. {a},{b} {d} 0 1 1 0 0 0 0 0 0 1 0 0. 1 1 1 0 0 0 0 0 0 1 0 0. {a},{b,d} 0 1 1 0 0 1 0 0 0 1 0 0. Tabla 6: Secuencias extendidas de tipo elemento [14].. •. Secuencias extendidas de tipo secuencia: para realizas las extensiones de este tipo primero se crea un mapa de bits temporal; si suponemos que k es la posición del mapa de bits del ítem/secuencia j en donde se encuentra el primer uno, el mapa de bits temporal tiene ceros desde la primera posición hasta la posición k, y tiene unos en las posiciones mayores a k..

(30) 24. CID. TID. 1 1 1 2 2 2 2 3 3 3 3. 1 3 6 2 4 5 7 -. {a} {a}t 1 0 0 0 0 1 0 0 1 0 0 0. 0 1 1 1 0 0 1 1 0 1 1 1. {b} {a},{b} 1 1 1 0 1 1 0 0 1 1 0 0. 0 1 1 0 0 0 0 0 0 1 0 0. Tabla 7: Secuencias extendidas de tipo secuenci a [14].. En ambos casos los valores de los mapas de bits de las secuencias resultantes son interpretados de la siguiente forma: si en dicha posición existe un uno significa que el ultimo ítem de la secuencia existe en la transacción, y que los demás ítems de la secuencia en las transacciones anteriores a j. Con base en esta estructura de datos el calculo del soporte de una secuencia k se convierte en un conteo de los bits correspondientes a las pariciones de cada cliente, de manera que si todos los bits son cero el cliente no tiene la secuencia k dentro ninguna de sus transacciones, así que el cliente no soporta dicha secuencia, en caso contrario el soporte de la secuencia k aumenta en 1..

(31) 25. 7. Patrones Secuenciales para la Detección de Intrusiones en HTTP 7.1.1. Diseño El primer paso para realizar un análisis de información es decidir que tipo de información se necesita y como puede ser obtenida, en el caso de la detección de intrusiones que pueden ser llevadas a cabo en períodos largos de tiempo no es viable usar datos de un sniffer ya que en este caso el sistema que analice los resultados debería tener “memoria” de los hechos ocurridos durante períodos largos de tiempo, y esto tiene varias desventajas: la primera es que al analizar un paquete determinado, el sistema debería buscar la relación de este último con cualquiera de los recibidos anteriormente, lo cual deteriora rápidamente el rendimiento de la máquina; y la segunda es que se le debería especificar un límite de tiempo dentro del cual se deberían buscar las relaciones, con lo cual se puede estar perdiendo capacidad de análisis y por lo tanto los resultados no serían confiables. Con estos inconvenientes para realizar el análisis de la información en tiempo real se decidió que la mejor forma de obtener la información era a partir de los logs generados, ya que con estos es posible analizar toda la información y no solo un fragmento de tiempo determinado, y adicionalmente no se deteriora el rendimiento del sistema que haga uso de las reglas generadas.. Figura 8: Diseño del prototipo.

(32) 26. 7.2. Herramientas 7.2.1. Herramientas de S oftware •. Jdk1.4.2 - JVM (Java Virtual M achine) Compilador del lenguaje Java. •. Generador: aplicación encargada de generar todo el tráfico necesario para la realización de pruebas.. •. Transformador: aplicación encargada de transformar un log generado por un servidor web en un archivo con el formato para que SPAM pueda procesarlo.. •. SPAM 1.3.1 (Sequential Pattern M ining): herramienta para encontrar patrones secuenciales frecuentes. •. Sistema Operativo Linux (M andrake 10.1) 7.2.2. S PAM. Esta es una herramienta hecha en c++ que corre sobre Linux. Esta aplicación encuentra patrones secuenciales dado un conjunto de información y un soporte mínimo, este conjunto de información debe ser suministrada en un archivo que contiene los identificadores de los clientes, las transacciones y los ítems que conforman cada una de las transacciones hechas por dicho cliente. El archivo debe tener el siguiente formato: <idCliente> <idTransaccion> <idItem> En el siguiente ejemplo la transacción 2 esta conformada por los ítems 1,2 y 5, pero ocurren en el siguiente orden 1, 5, 2: Datos de Vista de Transacciones Entrada 121 125 122 133 134. IdCliente. IdTrans. IdItem. 1. 2 3. 1,5,2 3,4. Tabla 8: Transformación de datos de entrada.

(33) 27. Estos datos son transformados para que queden en el mismo formato que en la Tabla 2, para luego hacer uso del algoritmo de mapas de bits verticales (Tabla 8), proceso en el cual crea un mapa de bits del tamaño adecuado para cada cliente, tamaños que inicialmente eran 4, 8, 16, 32, y 64; pero debido a la gran cantidad de solicitudes que un cliente puede generar (en especial en períodos largos de tiempo), esto tuvo que ser modificado para que la herramienta pudiera analizar una mayor cantidad de información por cliente, como resultado se obtuvo que se pudieran analizar clientes con máximo 2048 transacciones. Una modificación adicional se realizó con respecto al soporte, ya que por defecto se tiene que se buscan patrones de las secuencias que superen un soporte mínimo, pero en este contexto se deben buscar aquellas secuencias que no superen un límite establecido, ya que los ataques pertenecen a una pequeña porción de las transacciones realizadas sobre un servidor web. La herramienta genera dos archivos, uno con un resumen del proceso llamado summary.txt (Ver Anexo 4) y otro con las reglas encontradas, donde cada línea tiene las transacciones que componen la regla separadas por el caracter “-1” y finaliza con el número de clientes que tienen dicha secuencia, en el siguiente ejemplo la secuencia (1,2)(1)(1,2) la tienen 2 clientes: 1 2 -1 1 -1 1 2 – 2 SPAM usa la técnica depth-first [14] para encontrar los patrones secuenciales, la cual tiene como salida todos los patrones secuenciales sin importar su longitud, a diferencia de breathfirst, la cual primero sacaba los patrones de longitud 1, luego los de longitud 2 y así consecutivamente, para esto se crea una representación en mapas de bits verticales. 7.2.3. Transformador Teniendo en cuenta que se desean encontrar patrones de comportamiento que relacionen solicitudes hechas por los clientes, y sabiendo que la información con la cual se trabaja esta compuesta por 3 niveles de información: ítems, transacciones y secuencias; la mejor forma de transformar la información contenida el los logs generados por Tomcat es de la siguiente manera: una solicitud se toma como una transacción, los ítems son los elementos que conforman la solicitud y una secuencia esta conformada por un conjunto de transacciones ordenadas por fecha y hora. Con respecto a la información que se extrae de los logs, es claro que no todos los elementos de una solicitud pueden servir como evidencia en la detección de intrusiones; así que únicamente se analizan las variables que son usadas por cada ataque, para el caso de Inyección SQL el único rastro dejado es en los parámetros del URL y la respuesta del servidor ante una solicitud; para el caso de Canales Encubiertos se analiza el “contenttype”, así que se debe buscar y transformar la información de estos campos. Adicionalmente se toma la dirección IP desde la cual se generó la solicitud como el.

(34) 28. identificador del cliente. Teniendo esto en cuenta se asigna un código a cada posible valor que puedan tomar las variables mencionadas: Información. Identificador Valor en el log. Código de Status <200 respuesta del servidor >=200,< 300 >=300,< 400 >=400,< 500 >=500 Parámetros Parameter 'INSERT, enviados en 'DELETE, el URL. 'UPDATE, 'SELECT, 'OR''=' ContentContent-Type image/pcx Type image/gif image/png image/jpeg. Código 1. 2 3 4 5 100. 51 52 53 54. Tabla 9: Códigos asignados a los eventos ocurridos. Al realizar la transformación se almacena las direcciones IP encontradas en una tabla de hashing, y a cada una de estas le es asignado un identificador (id de cliente); se genera un identificador de transacción por cada solicitud, y un identificador de ítem por cada elemento de la solicitud. Los identificadores de los ítems son generados a partir de los valores que puedan tomar aquellos tags que hayan sido identificados como relevantes (Ver Tabla 9). La aplicación genera dos archivos, el primero es un archivo en el que se asocia el identificador de un cliente con una dirección IP y se llama mapaDirecciones.txt, el segundo es el archivo que contiene toda la información ya transformada y con el formato que SPAM requiere. 7.3. Ambiente de Pruebas Para que el análisis sea preciso y los resultados confiables, es necesario analizar logs de los cuales se tenga un alto nivel de conocimiento, esto implica que se deben poder catalogar las transacciones que hacen parte de un ataque y las que no. Adicionalmente el análisis debe ser realizado sobre una gran cantidad de información, la cual debe tener en su mayoría.

(35) 29. registros de actividades inofensivas. Para esto se construyó un sito en el cual se registrara toda la información necesaria (Ver Anexo 2). 7.3.1. Inyección SQL Para hacer una Inyección SQL se desarrolló una página con jsp (inicio.jsp) cuya única función es capturar los datos de un usuario cuanto intenta ingresar al sistema y con estos datos construye una sentencia sql con el objetivo de autenticar al usuario, de manera que sobre esta página puede ser realizadas las pruebas de Inyección SQL, este desarrollo se hizo de la misma forma como se hace comúnmente en muchas organizaciones, es decir que no se construyó una arquitectura específica, sino que el procesamiento de la información, conexión a la Base de Datos y construcción de las consultas es realizado sobre la página. Este diseño se hizo con el objetivo de simular el ambiente organizacional y de permitir la ejecución del ataque. select * from usuarios where nombre='" + request.getParameter("usuario") + "' and pass='" + request.getParameter("pass") + "'" Para generar los logs correspondientes al ataque se modifico la aplicación mencionada para que aleatoriamente hiciera solicitudes en donde los parámetros son asignados con 5 posibles valores: 'INSERT, 'DELETE, 'UPDATE, 'SELECT',OR''=', con esto se consigue simular el comportamiento del atacante ya que con los 4 primeros valores el servidor no puede interpretar sentencia sql generada y devuelve un error, es decir que se esta simulando la etapa en al cual el atacante esta comprobando la configuración del servidor para luego ejecutar el ataque. A continuación se muestra la línea que muestra como se construye la solicitud con la cual se puede llevar a cabo el ataque; donde SQLCommand es un vector que contiene las 5 posibles cadenas que pueden ser agregadas a la solicitud: http://localhost:8080/encuesta/inicio.jsp?usuario=" + SQLCommand[random] + "&pass=" + SQLCommand[random] Tomando la cadena anterior se pueden construir las siguientes solicitudes: http://localhost:8080/encuesta/inicio.jsp?usuario='INSERT&pass='INSERT http://localhost:8080/encuesta/inicio.jsp?usuario='OR''='&pass='OR''=' Y tomando el código de inicio.jsp donde se construye la sentencia sql, las sentencias generadas serían las siguientes: select * from usuarios where nombre=''INSERT' and pass=''INSERT'; select * from usuarios where nombre=''OR''='' and pass=''OR''='';.

(36) 30. La primera sentencia es inválida y el servidor de Base de Datos no la puede interpretar, por lo tanto genera un error que es desplegado en la página, pero la segunda sentencia esta correctamente construida y devuelve la lista de usuarios del sistema.. 7.3.2. Canales Encubiertos Para la simulación de Canales Encubiertos se uso como base una aplicación desarrollada en C y que debe ser compilada usando Visual C, a este proyecto se le deben incluir las librerias ws2_32.lib y wininet.lib. Esta aplicación realiza todos los pasos del ataque, es decir que construye y envía todos los mensajes, abre y cierra la conexión con el servidor ftp, solicita y reenvía el archivo requerido; y todo esto lo hace automáticamente y sin lapsos de tiempo entre cada paso. Para simular la forma como se comportan los atacantes en la realidad se modificó la aplicación para que los mensajes enviados varíen en cada ejecución, adicionalmente se adicionó un tiempo de espera aleatorio entre la ejecución de cada uno de los pasos. Las combinaciones usadas se pueden ver en el Anexo 1. Debido a que el cliente coge estas secuencias y las envía al servidor, y este último evalúa la solicitud para decidir la página con la cual responderá, es necesario crear una página por cada combinación posible, para que el servidor responda con la secuencia adecuada en cada ejecución. El servidor ftp usado fue WardFtp, dentro del cual se creo un usuario con todos los permisos, este usuario es el usado por el cliente del ataque para conectarse a dicho servidor. 7.3.3. Generador Para generar un conjunto de entrenamiento con las características deseadas se desarrlló una aplicación que usa un URL dado para hacer una solicitud al servidor; una vez se ha recibido la página solicitada, esta es analizada en busca de los posibles URL que pueda contener, dichos URL son almacenados para hacer posteriores solicitudes y realizar el mismo procedimiento. Todo este proceso genera los mismos logs sobre el servidor web que los usuarios normales podrían generar en un posible ingreso al sistema. Con todo lo anterior se generan los logs que podrían generar usuarios normales navegando por el sistema. Para generar los logs de una Inyección SQL, aleatoriamente se hace una solicitud a inicio.jsp con las características mencionadas, y para la ejecución de canales encubiertos se ejecuta aleatoriamente la aplicación modificando el parámetro que recibe, para que en cada ejecución se realice el ataque con un patrón de mensajes diferente..

(37) 31. 7.4. Pruebas y Resultados Teniendo en cuenta que el porcentaje de usuarios que realizan ataques es mucho menor que el porcentaje que usa los sistemas para los propósitos que fueron creados, el conjunto de entrenamiento debe cumplir estas características, para esto se generó el tráfico de manera que los usuarios que realizan ataques fueran menos del 10% del total. Una primera aproximación fue asignar un código diferente para cada evento, es decir que si el un parámetro tomaba el valor “'INSERT”, a este se le asignaba el código 101; y si tomaba el valor “'DELETE”, se le asignaba el código 102; pero debido a que cada vez la comprobación de la configuración del sistema puede ser realizada de forma diferente, esta codificación no produjo resultados satisfactorios, ya que se generaban un gran número de reglas y con grandes variaciones entre ellas. Archivo. Numero de Reglas Transacciones Generadas. SPAM -infile2005-06-12.txt (código único) SPAM -infile2005-06-12.txt (diferentes códigos). 13000. 7592. Reglas asociadas a ataques (Inyección SQL) 105. 13000. 10477. 200. Tabla 10: Comparación de resultados con respecto al código asignado. Algunas de las reglas generadas usando códigos diferentes fueron del siguiente estilo: 5 -1 101 -1 103 -1 5 -1 105 -1 103 -1 5 -1 105 -1 102 – 1 5 -1 101 -1 103 -1 5 -1 105 -1 103 -1 5 -1 105 -1 104 – 1 Estas dos reglas aunque son concluyentes, no son muy útiles, ya que este estilo es muy poco común entre el conjunto generado, y debido a la cantidad de reglas, ésta puede pasar desapercibida. Adicionalmente se puede ver que la única diferencia entre las dos es el último código, pero en ambos casos se identifica que dicho código está asociado a una palabra de la sintaxis de SQL; para efectos del análisis que se está realizando no es necesario hacer esta diferenciación; de manera que con este esquema el conjunto de reglas generadas, y por consiguiente el de reglas asociadas a ataques es demasiado grande y en su gran mayoría no es concluyente, lo cual hace que el conjunto de reglas sea más difícil de interpretar. El siguiente esquema con el cual se realizaron pruebas fue asignando un código único (100) para todos los casos en los que se encuentren cadenas pertenecientes a la sintaxis de SQL, con el cual se consiguieron resultados más claros y se bajo el número de reglas generadas. Con este esquema solo es necesario buscar en el log los identificadores que se encuentran.

(38) 32. en la Tabla 9 para identificar cuándo se esta comprobando la configuración del servidor, ya que las transacciones que tienen los códigos 100 y 5 preceden a la que tienen los códigos 100 y 2. El siguiente fragmento muestra tres ejemplos de las reglas encontradas, el primero es un ejemplo de una regla inválida, ya que el primer valor corresponde a un código de redirección del URL solicitado, el cual no esta relacionado con los demás (5, 100); el segundo es un ejemplo que muestra las reglas que se buscaban: 3 -1 5 -1 100 -1 100 -1 100 - 1 3 -1 100 – 4 100 -1 5 -1 100 -1 5 -1 100 -1 100 -1 100 -1 100 -1 100 – 1 100 -1 100 -1 5 -1 100 -1 100 -1 100 -1 100 -1 100 – 1 3 -1 100 -1 100 -1 5 -1 100 -1 100 -1 100 -1 100 -1 100 -1 100 -1 100 -1 100 -1 100 -1 100 -1 100 – 1 El segundo ejemplo muestra una secuencia de errores ocurridos después de que un URL tenia una de las palabras reservadas de SQL, lo cual se deduce como el proceso de comprobación de la configuración del servidor; esto seguido de una secuencia solicitudes que contienen dichas palabras pero el servidor no genera errores (el código 2 no se ve porque es un evento muy común), lo que se asocia con un ataque exitoso. El tercer ejemplo aunque no muestra un secuencia como la que se buscaba, si muestra un alto número de transacciones con cadenas SQL y sin un código de error asociado, lo cual es sospechoso y puede ser considerado para un análisis más exhaustivo. Los resultados obtenidos con el esquema planteado fueron los siguientes: Archivo. Número de Reglas Transacciones Generadas 10520. Reglas asociadas a ataques (Inyección SQL) 1025. Tiempo Ejecución SPAM 0.4. SPAM -infile2005-06-13.txt SPAM -infile2005-06-14.txt SPAM -infile2005-06-15.txt. 95000 37000. 4709. 480. 0.18. 217000. 30268. 1200. 0.86. de de. Tabla 11: Resultados de pruebas con código único. Los resultados demuestran que es viable usar patrones secuenciales dentro de la implementación de un IDS para eliminar algunas de las limitaciones de los IDS existentes, como son: • Se puede aumentar el rango de actividades que puede ser identificadas.

(39) 33. • • •. Tiempo de ejecución del algoritmo Se disminuye la complejidad de los ajustes necesarios, ya que la mayoría de estos se hacen en la transformación de los datos y no en la herramienta de M inería de Datos. Independencia de la información analizada, lo cual le da la capacidad de integrarse con una gran variedad de sistemas.. 7.5. Limitaciones de las pruebas Durante la realización de las pruebas se identificaron algunas limitaciones: •. Información usada: debido a que se uso información generada específicamente para la realización de estas pruebas, no es posible dar conclusiones acerca de la cantidad de información que es recomendable usar durante cada análisis. Al tener información real se podría llegar a una conclusión de analizar la información correspondiente a un período de tiempo determinado.. •. La herramienta usada: la herramienta no permitía configurar un intervalo de tiempo máximo entre eventos, de manera que se pueden relacionar eventos que estén separados por mucho tiempo (indicio de que no hay relación entre ellos). Adicionalmente no permitía refinar un modelo creado mediante la adición de un nuevo conjunto de información..

(40) 34. 8. Conclusiones Durante el desarrollo de este trabajo se han generado múltiples conclusiones que son parte fundamental de los objetivos de este proyecto, el siguiente es un compendio de las más importantes: •. Al trabajar sobre http y no sobre los niveles bajos del modelo OSI es posible enfocar los problemas que ocurren en este nivel, a diferencia de los IDS tradicionales que realizan los análisis en niveles más bajos.. •. La M inería de Datos resultó ser una técnica adecuada para solucionar el problema planteado.. •. La generación de reglas que ayuden en la detección de Inyecciones SQL es viable ya que el rastro dejado es fácilmente identificable.. •. La generación de reglas que ayuden en la detección de canales encubiertos no es viable con el diseño propuesto, ya que el rastro dejado hace parte de un conjunto de información muy grande, por lo cual no es tenido en cuenta por la herramienta para buscar patrones sobre los eventos que componen dicho rastro.. •. El diseño propuesto es escalable en la medida que la herramienta que hace la minería de datos (SPAM ) es independiente de la herramienta que genera los logs, es decir que solo es necesario adaptar la transformación de los datos para que funcione con un nuevo tipo de entrada, ya sea logs provenientes de una fuente diferente, o una patrón de un ataque.. •. Debido a que SPAM no analiza directamente los logs, el análisis puede ser realizado en una máquina diferente, así que el rendimiento de la máquina en donde se encuentran los logs no se ve afectado, y el funcionamiento de SPAM no puede ser alterado por un mal funcionamiento de otra aplicación.. •. Las herramientas desarrolladas para en el ambiente de pruebas generaron el tráfico con características que reproducían satisfactoriamente el ambiente real.. •. La herramienta que encuentra los patrones no es la mejor, ya que la forma en la que se muestran los patrones encontrados no es fácil de entender, y adicionalmente no tiene la opción de refinar los modelos construidos con un nuevo conjunto de información..

(41) 35. 9. Continuidad y Recomendaciones El prototipo planteado pretende ser un punto de partida para nuevas investigaciones en el área de seguridad informática, y en el diseño e implementación de mecanismos que la mejoren. A continuación se da una lista de aspectos que se deben mejorar y/o investigaciones que se pueden realizar: •. Con respecto a canales encubiertos, hacer pruebas a partir de información de tráfico http y del servidor ftp.. •. Hacer pruebas con otro tipo de ataques.. •. Agregar la posibilidad de agregar nuevos conjuntos de información a modelos previamente construidos.. •. Transformar las reglas encontradas a un formato que sea más fácilmente interpretado por cualquier persona y/o sistema..

(42) 36. Anexo 1: Secuencias de Comunicación A continuación se muestran todas las combinaciones usadas al realizar el ataque de Canales Encubiertos: "image/pcx, image/gif, image/jpeg, image/png, image/tiff" "image/pcx, image/gif, image/jpeg, image/tiff, image/png" "image/pcx, image/gif, image/png, image/jpeg, image/tiff" "image/pcx, image/gif, image/png, image/tiff, image/jpeg" "image/pcx, image/gif, image/tiff, image/jpeg, image/png" "image/pcx, image/gif, image/tiff, image/png, image/jpeg" "image/pcx, image/jpeg, image/gif, image/png, image/tiff" "image/pcx, image/jpeg, image/gif, image/tiff, image/png" "image/pcx, image/png, image/gif, image/jpeg, image/tiff" "image/pcx, image/png, image/gif, image/tiff, image/jpeg" "image/pcx, image/tiff, image/gif, image/jpeg, image/png" "image/pcx, image/tiff, image/gif, image/png, image/jpeg" "image/pcx, image/jpeg, image/png, image/gif, image/tiff" "image/pcx, image/jpeg, image/tiff, image/gif, image/png" "image/pcx, image/png, image/jpeg, image/gif, image/tiff" "image/pcx, image/png, image/tiff, image/gif, image/jpeg" "image/pcx, image/tiff, image/jpeg, image/gif, image/png" "image/pcx, image/tiff, image/png, image/gif, image/jpeg" "image/pcx, image/jpeg, image/png, image/tiff, image/gif" "image/pcx, image/jpeg, image/tiff, image/png, image/gif" "image/pcx, image/png, image/jpeg, image/tiff, image/gif" "image/pcx, image/png, image/tiff, image/jpeg, image/gif" "image/pcx, image/tiff, image/jpeg, image/png, image/gif" "image/pcx, image/tiff, image/png, image/jpeg, image/gif" "image/gif, image/pcx, image/jpeg, image/png, image/tiff" "image/gif, image/pcx, image/jpeg, image/tiff, image/png" "image/gif, image/pcx, image/png, image/jpeg, image/tiff" "image/gif, image/pcx, image/png, image/tiff, image/jpeg" "image/gif, image/pcx, image/tiff, image/jpeg, image/png" "image/gif, image/pcx, image/tiff, image/png, image/jpeg" "image/jpeg, image/pcx, image/gif, image/png, image/tiff" "image/jpeg, image/pcx, image/gif, image/tiff, image/png" "image/png, image/pcx, image/gif, image/jpeg, image/tiff" "image/png, image/pcx, image/gif, image/tiff, image/jpeg" "image/tiff, image/pcx, image/gif, image/jpeg, image/png" "image/tiff, image/pcx, image/gif, image/png, image/jpeg" "image/jpeg, image/pcx, image/png, image/gif, image/tiff" "image/jpeg, image/pcx, image/tiff, image/gif, image/png" "image/png, image/pcx, image/jpeg, image/gif, image/tiff".