sistema de detección de intrusos

seguridadDetección de intrusos

36 Linux+ 12/2008

Detección de intrusos

linux

@so

ftwar

e.co

m.p

l

Aunque las defi ciencias de los sistemas se pue-den comprobar con herramientas convencio-nales, no siempre estas corrigen el problema. En general, estas debilidades pueden provocar

un agujero en la seguridad de la red y facilitar entradas ilega-les 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 fi rewall y otros mecanismos de prevención) no debería ser sufi ciente. Debe-mos pensar que no todos los accesos a la red o a los servicios pasan por el fi rewall, y que no todas las amenazas son origi-nadas en la zona externa del fi rewall (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).

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 identifi car el tipo de ataque exacto que se produjo, de forma que sea posible detenerlo. En otras si-tuaciones solo sera posible detectar e informar de la actividad sospechosa que se ha encontrado, imposibilitando lo que sucedió realmente.

Un poco de historiaLos sistemas de detección de intrusos son una evolución directa de los primeros sistemas de auditorias. Estos sistemas tenían como fi nalidad medir el tiempo que dedicaban los usuarios fi nales a usar los sistemas. Con esta fi nalidad, 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 gru-po de desarrollo con el objetivo de analizar el uso de compu-tadores en empresas de telefonía, pero faltaba mucho como

Sistema dedetección de IntrusosAndrés E. Ovalle Gahona

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

Detección de intrusosseguridad


37www.lpmagazine.org

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 perfi les para describir los sujetos del sistema (principalmente enfocado a usuarios), y reglas de actividades para defi nir las acciones que tenían lugar. Estos elementos permitían establecer mediante métodos estadís-ticos las pautas de comportamiento necesarios para la detección de posibles anomalías.

Arquitectura general de un siste-ma de detección de intrusosDesde 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 in-trusos no debe confundir acciones legitimas con acciones deshonestas a la hora de reali-zar su detección. Si el sistema de detección no pueda hacer la diferencia, este puede provocar una denegación de servicios con-tra un usuario legitimo. (falso positivo).

• Efi ciencia: El detector de intrusos debe mi-nimizar la tasa de actividad maliciosa no detectada (falso negativo). Cuanto menor sea la tasa de falso negativos, mayor sera la efi ciencia del sistema. Requisito com-plicado, 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 detec-ción de intrusos debe ser capaz de conti-nuar ofreciendo su servicio aunque sean atacados distintos elementos del sistema.

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

Recolector de InformaciónConocidos como sensores, es el responsable de la recolección de información de los equipos monitorizados por el sistema de detección.

Gracias a la información almacenada, esta ayudara y sera la base de decisiones para la de-tección. Por lo tanto, sera importante garantizar su integridad frente a posibles ataques de mo-difi cació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.

• Sensores basados en equipos: Se encarga de analizar y recoger información de even-tos a nivel de sistema operativos

• Sensores basados en red: Se encarga de recoger información de eventos sucedidos a nivel de trafi co 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 aplica-ciones 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 fi cha-ros 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

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 perime-tral 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 refl eja todo el trafi co 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 trafi co es muy elevada. Ademas el ancho de banda interno del dispositivo es sufi -ciente para tratar con todo los puertos activos a la vez, pero si el trafi co analizado compienza a crecer, es posible que se supere la capacidad de intervención del puerto, con la correspondiente perdida de paquetes.

Procesadores de eventosTambién conocidos como analizadores, confor-man el núcleo central del sistema de detección. Tienen la responsabilidad de operar sobre la in-formación recogida por los sensores para poder inferir posibles intrusos.

Pero como inferimos intrusos? Los anali-zadores deben implementar algunos esquemas de detección. Dos de los esquemas mas utili-zados 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ónbasado en usos indebidosEste 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.

Figura 1. Esquema de regla in-then-else

Evento X? Evento Y?Falso Falso Falso

Evento Z?

Ataque

Vardadero Vardadero Vardadero

38


Linux+ 12/2008


Esta secuencias o patrones se conocen bajo el nombre de fi rmas de ataques, así los com-ponentes de detección basados en el modelo de uso indebidos, comparan los eventos enviados por los sensores con las fi rmas de ataque que mantienen almacenadas en sus bases de cono-cimiento.

En el momento de detectar alguna concor-dancia de algún acontecimiento o secuencia de eventos con alguna fi rma de ataque, el compo-nente 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 utiliza-ción de reglas del tipo if-then-else para examinar los datos, la información es procesada por medio de funciones inter-nas del sistema, de forma completamente transparente al usuario. Mirar Figura nº1

La desventaja principal de este modelo es que los patrones no defi nen 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 fi nitos para

representar los ataques, donde los nodos representan los estados y las fechas las transiciones.

La utilización de diagramas de transición facili-ta la asociación entre los estados y los distintos pasos que realiza un atacante desde que entra a un sistema, con privilegios limitados, hasta que se hace con el control del mismo.

Como principal ventaja de este modelo se puede destacar que los diagramas de transición permiten realizar una representación a alto nivel de escenarios respecto a los intrusos, ofreciendo una forma de identifi car una serie de secuencias que conforman el ataque. La desventaja de este es que los pasos de las secuencia, se deben crear mediante lenguaje específi cos, que en muchas ocasiones suelen ser muy limitados e insufi -cientes para recrear un ataque complejo.

Esquema de detección basado en anomalíasEste esquema trata de identifi car actividades sospechosas comparando el comportamiento de un usuario, proceso o servicio, con el com-portamiento de perfi l clasifi cado como normal. Entonces cualquier desviación que supere un cierto umbral respecto al perfi l almacenado sera tratado como una evidencia de ataque o intruso.

Uno de los requisitos de este modelo es la necesidad de inicializar un perfi l por defecto que se ira adaptando progresivamente al com-portamiento de un usuario, proceso o servicio no sospechoso. Es necesario, por lo tanto, el uso de heurísticas y descriptores estadísticos que ayuden a modelar correctamente cambios en el comportamiento tan pronto como suceda. Otra propuesta trata de incorporar técnicas de inteligencia artifi cial para realizar estas tareas (redes neuronales o algoritmos genéticos)

Esta detección ofrece claras ventajas res-pecto a la detección basada en usos indebidos. La ventaja mas destacarle es la posibilidad de

detectar ataques desconocidos. Esto es posible por que independientemente como haya conse-guido el atacante entrar a un sistema, tan pronto como sus actividades comiencen a desviarse del comportamiento de un usuario normal, el procesador de eventos lanzara una alarma de un posible intruso. Aun asi este esquema igualmente presenta bastantes inconvenientes, el primero es que debemos destacar es la falta de garantía en el proceso de detección, un intru-so podría realizar sus acciones lentamente para ir provocando cambios en el perfi l de usuario del procesador de eventos, con la fi nalidad que su presencia en el sistema pasara desaperci-bida. Como segundo inconveniente podemos destacar la difi cultad que aparece a la hora de clasifi car y describir con precisión los ataques detectados mediante analizadores basados en anomalías. Generalmente un analizador no solo tiene que lanzar una alarma, si no que deberá especifi car de donde procede el ataque, que cambios ha sufrido el sistema, etc.

Ademas la tasa de falsos positivos y nega-tivos que puede darse utilizando este esquema de detección es un gran inconveniente, ya que no siempre una desviación respecto al perfi l esperado coincidirá con un ataque o intento de intruso. En el caso de procesadores cuyos even-tos procedan de sensores basados en red, es posible que el numero de alarmas lanzadas (en una red de tamaño medio) supere fácilmente el centenar. Esto provoca que, con frecuencia los administradores de la red acaben ignorando las alarmas lanzadas por el sistema de detección, o incluso desactivando el sistema completo.

Unidades de RespuestaLa unidad de respuesta de un sistema de de-tección, se encargaran de iniciar acciones de respuesta en el momento en que se detecte un ataque o intruso. Estas acciones de respuesta pueden ser automáticas (respuesta activas) o requerir de interacción humana (respuesta pasiva).

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

S1 S2 S3

Comprobaciones Comprobaciones Comprobaciones

exists (object) = falseattacker!=root

owner (object) = usersetuid (object) =disabled

owner (object) = usersetuid (object) =enabled

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

coldfusion.rules

include $RULE_PATH/web-iis.rules


frontpage.rules

include $RULE_PATH/web-misc.rules


attacks.rules

include $RULE_PATH/sql.rules

include $RULE_PATH/x11.rules

include $RULE_PATH/icmp.rules

include $RULE_PATH/netbios.rules

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

info.rules

# include $RULE_PATH/virus.rules


39


www.lpmagazine.org

Las respuestas activas tiene como objetivo actuar contra el ataque, intentando su neutrali-zació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 pasi-va ofrecen distintas formas de hacer llegar esta información al administrador, como por ejem-plo, 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 ser-vicio 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 consi-derados 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, ma-nualmente, 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 clasifi car en distintas cate-gorías según el punto de actuación.

• Unidades de respuesta basadas en equipo: Se encargaran de actuar a nivel de sistema operativo (bloqueos de usuarios, fi nalizar procesos, etc.)

• Unidad de respuesta basada en red: Ac-túan a nivel de red cortando intentos de conexión, fi ltrando direcciones sospecho-sas, etc.

Elementos de almacenamientoEn algunas situaciones, el volumen de infor-mació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

información sin penalizar las posibilidades de análisis. Una posibilidad es la clasifi cació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 trans-mitidos a los analizadores del sistema. El tiem-po 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 pe-riodos 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 practicaComo 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 teoría vamos a pasar a la teoría practica, hablaremos de Snort (www.snort.org) un sniffer www.snort.org) un sniffer www.snort.orgy detector de intrusos basado en red (uno de mis preferidos). Es un software muy fl exible 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 detec-ción de ataques y un barrido de puertos, regis-trando, 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/) 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 confi gurara MySQL creando la base de datos para Snort pueda almacenar la información.

Primero un poco de seguridad confi guran-do 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

Figura3. Herramienta ACID

40


Linux+ 12/2008

Ya tenemos las tablas listas, ahora creamos el usuario para Snort :

mysql> grant all on snort.* to

snort@localhost identifi ed by

'xxxxxx';

Query OK, 0 rows affected (0.13 sec)

mysql> fl ush privileges;


Las fi rmas de ataques que usa Snort para ge-nerar alertas se encuentran en el directorio de/etc/snort. Estas fi rmas se encuentran en los archivos con extensión *.rule y el nombre del archivo hace referencia al tipo de alertas que contienen. Lo cual el siguiente paso sera confi gurar Snort, editando el fi chero /etc/

snort/snort.conf para adecuarlo a lo que queremos detectar. El fi chero se divide en 4 partes fundamentales

Confi guración de variables de redEn esta sección asignamos los valores a las va-riables tales como la red que vamos a monito-rear Snort en busca de ataques (HOME_NETrear Snort en busca de ataques (HOME_NETrear Snort en busca de ataques ( ), HOME_NET), HOME_NETlos servidores DNS (DNS_SERVERS)los servidores DNS (DNS_SERVERS)los servidores DNS ( , servido-res SMTP, etc. Se recomienda establecer al me-nos los servidores de DNS que utilizan nuestros equipos, para evitar falsos positivos.

Confi gurar los pre procesadoresA partir de la versión 1.5 aparecieron los pre procesadores que permiten que las funcionali-dades de Snort sean extendidas por los usuarios proporcionando un sistema de acceso a los paquetes antes de que sean procesados por el motor de detección. Para empezar podemos de-jar los valores por defecto que vienen (depende de tu paranoia). Si necesitas mas información, consulta la pagina ofi cial de Snort nombrada anteriormente.

Confi guración de Plugin de salidaLos plugin de salida nos permiten elegir de en-tre una gran de variedad de formatos de salida. En el snort.conf vienen todas comentadas y con ejemplos. Nosotros vamos a confi gurara dos sa-lidas (todo al fi chero /var/log/snort/alerty a MySQL) simultáneamente. Añadimos lo siguiente:

# todo a /var/log/snort/alert

output alert_full : alert

#esto confi gura el log sobre MySQL

output database: log, mysql:

user=snort password=xxxxx dbname=snort

host=localhost

Personalizar reglasAcá deshabilitaremos si es necesario las reglas que no usaremos (Listado 1).

Con esto ya tenemos Snort confi gurado y listo para trabajar.

El siguiente paso es instalar ACID (An-lisys 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 im-portantes.

Igualmente como se creo el primer usua-rio y la base de datos, hacemos lo mismo con snort_archive:

mysql> grant all on snort_archive.*

to snort_archive@localhost identifi ed

by 'zzzzz';


mysql> fl ush privileges;


Con esto ya tenemos Snort + ACID funcionan-do, ahora solo debes ingresar por tu navegador vía http://localhost/acidlab/, el primer ingreso http://localhost/acidlab/, el primer ingreso http://localhost/acidlab/te pedirá que se deberán crear algunos indices extras en la base de datos de Snort para poder funcionar, es solo cosa de seguir las instruc-ciones, luego de esto ya podremos usar esta magnifi ca herramienta.

Listado 2. Instalando ACID# apt-get install acidlab

# 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 confi guration.

*/

$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";

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 Restructura-ción de la Red Computacional del Depar-tamento de Computación e Informática en la Universidad de Tarapaca. Igualmente se encuentra a cargo de la administra-ció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 2007-2008, 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

Sobre el Autor

sistema de detección de intrusos

Documents