Sistema de detección de Intrusos by SISCOT Elearning Evolution

seguridad Detección de intrusos

Sistema de detección de Intrusos Andrés E. Ovalle Gahona

linux@software.com.pl

Hoy en día las redes se encuentran expuestas a ataques informáticos con tanta frecuencia que es necesario imponer una gran cantidad de requisitos de seguridad para la protección de los recursos.

unque las deficiencias de los sistemas se pueden comprobar con herramientas convencionales, no siempre estas corrigen el problema. En general, estas debilidades pueden provocar un agujero en la seguridad de la red y facilitar entradas ilegales en el sistema. La mayoría de las empresas disponen actualmente de mecanismos de prevención y de mecanismos de protección de los datos integrados en sus redes (datos críticos). Sin embargo aunque estos mecanismos se deben considerar imprescindibles, la seguridad siempre debe ir en aumento en una organización. Así un nivel de seguridad perimetral (basado tan solo en la integración en la red de un sistema de firewall y otros mecanismos de prevención) no debería ser suficiente. Debemos pensar que no todos los accesos a la red o a los servicios pasan por el firewall, y que no todas las amenazas son originadas en la zona externa del firewall (ingeniería social). Una buena forma de mejorar la seguridad de la red pasa por la instalación de mecanismos de detección, capaces de avisar al administrador de la red en el momento en que se produzcan estos ataques (casi en tiempo real).

Linux+ 12/2008

Luego de esta pequeña introducción, podemos decir, que los mecanismos para la detección de ataques e intrusos tratan de encontrar y reportar las actividades maliciosas en la red, pudiendo llegar a reaccionar adecuadamente ante un ataque. Los mecanismos de detección de intrusos, en la mayoría de los casos pueden identificar el tipo de ataque exacto que se produjo, de forma que sea posible detenerlo. En otras situaciones solo sera posible detectar e informar de la actividad sospechosa que se ha encontrado, imposibilitando lo que sucedió realmente.

Un poco de historia

Los sistemas de detección de intrusos son una evolución directa de los primeros sistemas de auditorias. Estos sistemas tenían como finalidad medir el tiempo que dedicaban los usuarios finales a usar los sistemas. Con esta finalidad, se monitorizaban con una precisión de milésimas de segundos y servían, entre otras cosas, para poder facturar el servidor. Los primeros sistemas aparecieron en la década de los cincuenta, cuando una empresa norteamericana creo un grupo de desarrollo con el objetivo de analizar el uso de computadores en empresas de telefonía, pero faltaba mucho como

seguridad Detección de intrusos para llamarse sistema de detección de intrusos. Todo esto llevo a que en la década de los 80 se creara el proyecto IDES (Intrusion Detection Expert System), en la cual desarrollo el primer sistema de detección de intrusos en tiempo real. IDES utilizaba perfiles para describir los sujetos del sistema (principalmente enfocado a usuarios), y reglas de actividades para definir las acciones que tenían lugar. Estos elementos permitían establecer mediante métodos estadísticos las pautas de comportamiento necesarios para la detección de posibles anomalías.

Gracias a la información almacenada, esta ayudara y sera la base de decisiones para la detección. Por lo tanto, sera importante garantizar su integridad frente a posibles ataques de modificación a la hora de transmitir estos eventos entre el sensor que lo genero y el componente que lo procesara. Existen tipos de sensores, estos dependerán en que estén basados.

Arquitectura general de un sistema de detección de intrusos

•

Desde que se empezaron a crear estos sistemas de detección de intrusos, se han llevado a cabo multiples estudios referentes a él. En todos estos estudios se han realizado diferentes pro- • puestas de diseño con el objetivo de cumplir los siguientes requerimientos: •

•

Precisión: Un sistema de detección de intrusos no debe confundir acciones legitimas con acciones deshonestas a la hora de realizar su detección. Si el sistema de detección no pueda hacer la diferencia, este puede provocar una denegación de servicios contra un usuario legitimo. (falso positivo). Eficiencia: El detector de intrusos debe minimizar la tasa de actividad maliciosa no detectada (falso negativo). Cuanto menor sea la tasa de falso negativos, mayor sera la eficiencia del sistema. Requisito complicado, debido a que puede ser imposible obtener todo el conocimiento necesario sobre ataques pasados, actuales y futuros. Escalabilidad: A medica que la red vaya creciendo, también aumentara el numero de eventos que deberá tratar el sistema. El detector tiene que se capaz de soportar este aumento en el numero de eventos, sin que se produzca perdida de información. Tolerancia en fallos: El sistema de detección de intrusos debe ser capaz de continuar ofreciendo su servicio aunque sean atacados distintos elementos del sistema.

Tanto el CIDF (Common Intrusion Detection Framework) como el IDWG (Intrusion Detection Working Group) realizador propuestas, en la cual nombraron los elementos necesarios para la construcción de un sistema de detección de intrusos

Sensores basados en equipos: Se encarga de analizar y recoger información de eventos a nivel de sistema operativos Sensores basados en red: Se encarga de recoger información de eventos sucedidos a nivel de trafico de red (analizando las cabeceras IP de todos los data gramas que pasan por la interfaz de red). Sensores basados en aplicaciones: Se encarga de recoger información de aplicaciones que se estén ejecutando, y podrían ser considerados como un caso especial de sensores basados en equipo.

¿Ahora la consulta va en donde se instalan dichos sensores?

Empezaremos diciendo que no es para nada trivial determinar el lugar exacto en el que se deben colocar estos componentes. Los mas sencillos de colocar son los sensores basados en aplicaciones, generalmente instalados en aquellas partes del programa donde se ofrecen servicios de depuración y generación de ficharos de registro. Pero la situación es mucho mas difícil para las otras 2 variantes. Cuando consideramos la instalación de sensores basados en equipo, la gran variedad de sistemas operativos que existen y las distintas facilidades ofrecidas por cada uno de ellos, nos da un serio problema. Ademas no suele ser simple determinar que parte de la información generada por el nucleo de un sistema operativo debería ser relevante a la hora de analizar. En el caso de sensores basados en red, la utilización de redes segmentadas mediante router de red supone un gran inconveniente en cuanto a escoger el lugar correcto en el que

Evento X?

Falso

Vardadero

Recolector de Información

se deben colocar estos sensores. Una primera opción seria colocar el sensor sobre el enlace donde se unen todos los equipos de la red. Esta opción podría suponer la necesidad de analizar una cantidad de datos tan elevada que el sensor acabaría perdiendo información. La otra opción seria la colocación del sensor entre el enlace de red que separa el interior y el exterior, como si se tratara de un sistema de prevención perimetral adicional. Una variante de estas dos opciones seria la utilización del puerto de intervención (tap port) que ofrecen muchos router. Se trata de un puerto especial que refleja todo el trafico que pasa a través del equipo. Desgraciadamente este puerto podría fácilmente sobrecargar la capacidad de análisis de los sensores si la cantidad de trafico es muy elevada. Ademas el ancho de banda interno del dispositivo es suficiente para tratar con todo los puertos activos a la vez, pero si el trafico analizado compienza a crecer, es posible que se supere la capacidad de intervención del puerto, con la correspondiente perdida de paquetes.

Procesadores de eventos

También conocidos como analizadores, conforman el núcleo central del sistema de detección. Tienen la responsabilidad de operar sobre la información recogida por los sensores para poder inferir posibles intrusos. Pero como inferimos intrusos? Los analizadores deben implementar algunos esquemas de detección. Dos de los esquemas mas utilizados para realizar la detección son el modelo de detección de uso indebidos y el modelo de detección de anomalías, en la cual se dará un comentario breve de ellos.

Esquema de detección basado en usos indebidos

Este modelo se basa en un conocimiento a priori de secuencias y actividades deshonestas. Los procesadores de eventos que implementan este esquema analizan los eventos en busca de patrones de ataques conocidos o actividad que ataque vulnerabilidades típicas de los equipos.

Evento Y?

Falso

Vardadero

Evento Z?

Falso

Vardadero Ataque

Conocidos como sensores, es el responsable de la recolección de información de los equipos Figura 1. Esquema de regla in-then-else monitorizados por el sistema de detección.

www.lpmagazine.org

seguridad Detección de intrusos Esta secuencias o patrones se conocen bajo el nombre de firmas de ataques, así los componentes de detección basados en el modelo de uso indebidos, comparan los eventos enviados por los sensores con las firmas de ataque que mantienen almacenadas en sus bases de conocimiento. En el momento de detectar alguna concordancia de algún acontecimiento o secuencia de eventos con alguna firma de ataque, el componente lanzara una alarma. La detección basada en usos indebidos, usan dos modelos, uno a base de patrones y otro basado en transiciones de estado •

Basado en patrones: Mediante la utilización de reglas del tipo if-then-else para examinar los datos, la información es procesada por medio de funciones internas del sistema, de forma completamente transparente al usuario. Mirar Figura nº1

La desventaja principal de este modelo es que los patrones no definen un orden secuencial de acciones. Por otra parte, el mantenimiento y la actualización de la base de datos de patrones son otro punto critico de este modelo. •

Basado en transiciones de estado: Este modelo hace uso de autómatas finitos para Listado 1. Deshabilitando las reglas include $RULE_PATH/rservices.rules include $RULE_PATH/dos.rules include $RULE_PATH/ddos.rules include $RULE_PATH/web-cgi.rules include $RULE_PATH/webcoldfusion.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/webfrontpage.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-

representar los ataques, donde los nodos detectar ataques desconocidos. Esto es posible representan los estados y las fechas las por que independientemente como haya consetransiciones. guido el atacante entrar a un sistema, tan pronto como sus actividades comiencen a desviarse La utilización de diagramas de transición facili- del comportamiento de un usuario normal, ta la asociación entre los estados y los distintos el procesador de eventos lanzara una alarma pasos que realiza un atacante desde que entra a de un posible intruso. Aun asi este esquema un sistema, con privilegios limitados, hasta que igualmente presenta bastantes inconvenientes, se hace con el control del mismo. el primero es que debemos destacar es la falta Como principal ventaja de este modelo se de garantía en el proceso de detección, un intrupuede destacar que los diagramas de transición so podría realizar sus acciones lentamente para permiten realizar una representación a alto nivel ir provocando cambios en el perfil de usuario de escenarios respecto a los intrusos, ofreciendo del procesador de eventos, con la finalidad que una forma de identificar una serie de secuencias su presencia en el sistema pasara desapercique conforman el ataque. La desventaja de este bida. Como segundo inconveniente podemos es que los pasos de las secuencia, se deben crear destacar la dificultad que aparece a la hora de mediante lenguaje específicos, que en muchas clasificar y describir con precisión los ataques ocasiones suelen ser muy limitados e insufi- detectados mediante analizadores basados en cientes para recrear un ataque complejo. anomalías. Generalmente un analizador no solo tiene que lanzar una alarma, si no que deberá Esquema de especificar de donde procede el ataque, que detección basado en anomalías cambios ha sufrido el sistema, etc. Este esquema trata de identificar actividades Ademas la tasa de falsos positivos y negasospechosas comparando el comportamiento tivos que puede darse utilizando este esquema de un usuario, proceso o servicio, con el com- de detección es un gran inconveniente, ya que portamiento de perfil clasificado como normal. no siempre una desviación respecto al perfil Entonces cualquier desviación que supere un esperado coincidirá con un ataque o intento de cierto umbral respecto al perfil almacenado intruso. En el caso de procesadores cuyos evensera tratado como una evidencia de ataque o tos procedan de sensores basados en red, es intruso. posible que el numero de alarmas lanzadas (en Uno de los requisitos de este modelo es la una red de tamaño medio) supere fácilmente el necesidad de inicializar un perfil por defecto centenar. Esto provoca que, con frecuencia los que se ira adaptando progresivamente al com- administradores de la red acaben ignorando las portamiento de un usuario, proceso o servicio alarmas lanzadas por el sistema de detección, o no sospechoso. Es necesario, por lo tanto, el incluso desactivando el sistema completo. uso de heurísticas y descriptores estadísticos que ayuden a modelar correctamente cambios Unidades de Respuesta en el comportamiento tan pronto como suceda. La unidad de respuesta de un sistema de deOtra propuesta trata de incorporar técnicas de tección, se encargaran de iniciar acciones de inteligencia artificial para realizar estas tareas respuesta en el momento en que se detecte un (redes neuronales o algoritmos genéticos) ataque o intruso. Estas acciones de respuesta Esta detección ofrece claras ventajas res- pueden ser automáticas (respuesta activas) pecto a la detección basada en usos indebidos. o requerir de interacción humana (respuesta La ventaja mas destacarle es la posibilidad de pasiva).

attacks.rules include $RULE_PATH/sql.rules include $RULE_PATH/x11.rules include $RULE_PATH/icmp.rules include $RULE_PATH/netbios.rules

Comprobaciones

exists (object) = false attacker!=root

owner (object) = user setuid (object) =disabled

owner (object) = user setuid (object) =enabled

include $RULE_PATH/backdoor.rules # include $RULE_PATH/ shellcode.rules # include $RULE_PATH/policy.rules # include $RULE_PATH/porn.rules # include $RULE_PATH/info.rules # include $RULE_PATH/icmpinfo.rules # include $RULE_PATH/virus.rules

Figura 2. Esquema de reglas de transición de estado

Linux+ 12/2008

seguridad Detección de intrusos Las respuestas activas tiene como objetivo actuar contra el ataque, intentando su neutralización, en el momento en que es detectado (o mientras esta continua en curso). Un ejemplo de respuesta activa puede ser la cancelación de la conexión en la red que origino el ataque o el propio seguimiento del ataque que permitiría mas adelante el análisis correspondiente. Por contra, las respuestas pasivas se limitan a lanzar una alarma para informar y describir el ataque detectado para administrador del sistema La mayoría de los componentes de respuesta pasiva ofrecen distintas formas de hacer llegar esta información al administrador, como por ejemplo, mediante correo electrónico o la utilización de mensajes SMS, etc. El problema de las respuestas activas es que pueden acabar en una denegación de servicio contra usuarios o sistemas legítimos. Es muy probable que algunas de las alarmas que los procesadores hacen saltar sean incorrectas. Por ejemplo, si la unidad de respuesta cortara inmediatamente con la conexión que origino esta alarma, o con aquellos procesos considerados sospechosos, ellos podrían suponer la perdida de trabajo de un usuario o servicio inocente. En la mayoría de los sistemas este tipo de errores puede suponer la perdida de clientes, la cual cosa es inadmisible. Por este motivo, la mayoría de empresas del sector del comercio electrónico contratan especialistas que, manualmente, analicen los informes generados por el sistema de detección, para determinar si es necesario una respuesta activa ante tal aviso. Al igual que los sensores, las unidades de respuesta se pueden clasificar en distintas categorías según el punto de actuación. •

•

información sin penalizar las posibilidades de análisis. Una posibilidad es la clasificación de la información en términos de análisis a corto y largo plazo. En el caso de análisis a corto plazo, la información sera almacenada directamente en los propios sensores (buffer internos) de forma que después de realizar un proceso previo de los datos, y su transformación en un formato de evento, estos sean transmitidos a los elementos de análisis. En el caso de información a medio plazo, los datos pre procesados serán almacenados en dispositivos secundarios en lugar de ser transmitidos a los analizadores del sistema. El tiempo de almacenamiento de información puede ser del orden de dos o tres días, con el objetivo de que pueda ser consultada a los analizadores del sistema en el caso de que el proceso de análisis así lo requiera. Eventualmente, y después de un proceso de compresión (para reducir el tamaño), parte de la información medio plazo podrá continuar almacenada durante largos periodos de tiempo (meses hasta años) a la espera de que pueda ser consultada por procesos de detección a largo plazo.

Un poco de practica

Como pueden ver, un sistema de detección de intrusos es un tema bastante complejo pero necesario para un administrador de sistemas, ya que facilita mucho la tarea de él. Luego de un poco de teoría vamos a pasar a la practica, hablaremos de Snort (www.snort.org) www.snort.org) un sniffer www.snort.org y detector de intrusos basado en red (uno de mis preferidos). Es un software muy flexible que ofrece la posibilidad de almacenar sus

bitácoras tanto como en archivo de texto o en una base de datos. Igualmente implementa un motor de detección de ataques y un barrido de puertos, registrando, alertando y respondiendo ante cualquier anomalía. Todo esto se puede complementar un informes en tiempo real gracias a ACID (http: //acidlab.sourceforge.net/) Ok!, empecemos to//acidlab.sourceforge.net/ do esto lo haremos en mi distribución favorita, Debian. Lo primero que tenemos que hacer es: apt-get install mysql-server apt-get install snort-mysql

Esto hará que tengamos instalado MySQL y Snort con soporte para base de datos, ahora tenemos que configurara MySQL creando la base de datos para Snort pueda almacenar la información. Primero un poco de seguridad configurando la clave del root de MySQL $mysqladmin -uroot password nueva-pass

Creamos la nueva base de datos : $mysqladmin -uroot -p create snort

Existe en el paquete snort-mysql un archivo con el volcado de tablas que necesita Snort para funcionar: $gunzip /usr/share/doc/snort-mysql /contrib/create_mysql.gz $mysql -uroot -p snort < /usr/share /doc/snort-mysql/contrib/create_ mysql

Unidades de respuesta basadas en equipo: Se encargaran de actuar a nivel de sistema operativo (bloqueos de usuarios, finalizar procesos, etc.) Unidad de respuesta basada en red: Actúan a nivel de red cortando intentos de conexión, filtrando direcciones sospechosas, etc.

Elementos de almacenamiento

En algunas situaciones, el volumen de información recogida por los sensores del sistema de detección llega a ser tan elevado que se hace necesario, previo análisis, un proceso de almacenamiento. Supongamos, por ejemplo, el caso de que todos los paquetes de una red de alta velocidad deben ser inspeccionados por los analizadores del sistema de detección. En este caso, sera necesario plantearse una jerarquía de almacenamiento que reduzca el volumen de Figura3. Herramienta ACID

www.lpmagazine.org

seguridad Detección de intrusos Ya tenemos las tablas listas, ahora creamos el Configurar los pre procesadores usuario para Snort : A partir de la versión 1.5 aparecieron los pre procesadores que permiten que las funcionalimysql> grant all on snort.* to dades de Snort sean extendidas por los usuarios snort@localhost identified by proporcionando un sistema de acceso a los 'xxxxxx'; paquetes antes de que sean procesados por el Query OK, 0 rows affected (0.13 sec) motor de detección. Para empezar podemos demysql> flush privileges; jar los valores por defecto que vienen (depende Query OK, 0 rows affected (0.19 sec) de tu paranoia). Si necesitas mas información, consulta la pagina oficial de Snort nombrada Las firmas de ataques que usa Snort para ge- anteriormente. nerar alertas se encuentran en el directorio de /etc/snort. Estas firmas se encuentran en Configuración los archivos con extensión *.rule y el nombre de Plugin de salida del archivo hace referencia al tipo de alertas Los plugin de salida nos permiten elegir de enque contienen. Lo cual el siguiente paso sera tre una gran de variedad de formatos de salida. configurar Snort, editando el fichero /etc/ En el snort.conf vienen todas comentadas y con snort/snort.conf para adecuarlo a lo que ejemplos. Nosotros vamos a configurara dos saqueremos detectar. El fichero se divide en 4 lidas (todo al fichero /var/log/snort/alert partes fundamentales y a MySQL) simultáneamente. Añadimos lo siguiente:

Configuración de variables de red

En esta sección asignamos los valores a las variables tales como la red que vamos a monitorear Snort en busca de ataques ((HOME_NET HOME_NET), HOME_NET), los servidores DNS ((DNS_SERVERS), servidores SMTP, etc. Se recomienda establecer al menos los servidores de DNS que utilizan nuestros equipos, para evitar falsos positivos.

Personalizar reglas

Acá deshabilitaremos si es necesario las reglas que no usaremos (Listado 1). Con esto ya tenemos Snort configurado y listo para trabajar. El siguiente paso es instalar ACID (Anlisys Console form Intrusion Databases). Esta herramienta entra dentro del proyecto AirCert, auspiciado por el CERT (Listado 2). ACID pide dos usuarios, el primero (snort) tendrá acceso como usuario, la segunda bd (snort_archive), sera creada por ACID para que los usuarios puedan archivar alertas importantes. Igualmente como se creo el primer usuario y la base de datos, hacemos lo mismo con snort_archive: mysql> to

grant

all

snort_archive.*

snort_archive@localhost

identified

by 'zzzzz';

# todo a /var/log/snort/alert

Query OK, 0 rows affected (0.05 sec)

output alert_full : alert

mysql> flush privileges;

#esto configura el log sobre MySQL

Query OK, 0 rows affected (0.19 sec)

output database: log, mysql:

Con esto ya tenemos Snort + ACID funcionando, ahora solo debes ingresar por tu navegador user=snort password=xxxxx dbname=snort vía http://localhost/acidlab/ http://localhost/acidlab/, el primer ingreso host=localhost te pedirá que se deberán crear algunos indices extras en la base de datos de Snort para poder Listado 2. Instalando ACID funcionar, es solo cosa de seguir las instrucciones, luego de esto ya podremos usar esta # apt-get install acidlab magnifica herramienta. # chown -R www-data:www-data /etc/acidlab # nano /etc/acidlab/acid_conf.php ponemos los datos de la base de datos: /* Alert DB connection parameters * - $alert_dbname : MySQL database name of Snort alert DB * - $alert_host : host on which the DB is stored - $alert_port : port on which to access the DB * - $alert_user : login to the database with this user * - $alert_password : password of the DB user * * This information can be gleaned from the Snort database * output plugin configuration. */ $alert_dbname = "snort"; $alert_host = "localhost"; $alert_port = "xxxxx"; $alert_user = "snort"; $alert_password = ""; /* Archive DB connection parameters */ $archive_dbname = "snort_archive"; $archive_host = "localhost"; $archive_port = ""; $archive_user = "snort_archive"; $archive_password = "zzzzz";

Linux+ 12/2008

Sobre el Autor Andrés E. Ovalle Gahona, egresado de Ingeniería en Ejecución en Computación e Informática la Universidad de Tarapaca de la ciudad de Arica – Chile. Se encuentra desarrollando su tesis sobre Restructuración de la Red Computacional del Departamento de Computación e Informática en la Universidad de Tarapaca. Igualmente se encuentra a cargo de la administración de los Servidores del Departamento de Computación. Con mas de 8 años de experiencia en Administracion y Seguridad de Servidores bajo la distribucion GNU/ Linux Debian. Ha participado y organizado en eventos de Software Libre, tales como Encuentro Linux 2007, FLISOL 20072008, Día del Software Libre, DebianDay, etc. Lider del Proyecto Debianchile.cl (http: //www.debianchile.cl), su pagina personal es http://kill-9.debianchile.cl