|
IDS: AGENTES AUTONOMOS
|------------------------------------------------------------------------|
[ 7a69#14 ] [ 21-10-2002 ]
\ /
\--------------------------------------------------------------------/
{ 10 - Agentes autonomos. }{ MemoniX }
|------------------------------------------------------------------|
============================================================================
= Introduccion
============================================================================
Los agentes autonomos son un concepto avanzado en el campo de los IDS o Intrusion
Detection Systems, basado en la utilizacion de programas independientes o "agentes" para llevar a cabo un control total
sobre los hosts de una red que permitan detectar intentos de intrusion en tiempo real.
La herramienta que hace uso de este sistema es AAFID (Autonomous Agents For Intrusion
Detection), la cual se podria catalogar dentro de los sistemas basados en normas, aunque realmente esta herramienta fue
la que introdujo este concepto, ya que hoy en dia muchos IDS incorportan todas estas capacidades, siendo este sistema a
dia de hoy obsoleto.
En este articulo se intentara explicar todos los conceptos relacionados, no debiendo el
lector caer en la erronea suposicion de que este tipo de sistemas son los mas fiables, ya que el campo de los Sistemas
de Deteccion de Intrusos es relativamente nuevo estando en una constante evolucion, a la vez que tambien hay que tener
en cuenta que existen una gran cantidad de sistemas de deteccion de intrusos los cuales son privados, por lo que basan
su seguridad sobre todo en la "oscuridad" a la que son sometidos.
En este articulo tambien se expondran otras tecnicas / sistemas dentro del campo de los
IDS que pueden resultar interesantes.
============================================================================
= El problema
============================================================================
No a la centralizacion, ese es el principal objetivo de estos sistemas que vienen a mostrar una posible alternativa a
los sistemas mas comunes, los cuales se centran en un unico punto central que es el encargado de la recoleccion y
procesamiento de la gran mayoria de los datos. Una vez dicho esto podemos pasar a enumerar algunas caracteristicas que
deberian de estar implantadas en cualquier IDS:
-
Un sistema ha de ser tolerante a fallos, significando esto que ha de ser capaz de
recuperarse de cualquier caida o incidente provocada por un intruso o actividad maliciosa, a la vez que lograr regresar
a su estado inicial
-
Un sistema ha de ser capaz de salir airoso si uno sus componentes se viene abajo por
cualquier circunstancia en el sentido de que el resto de los componentes debe de continuar con su trabajo de la mejor
forma posible
-
Si un numero considerable de maquinas estan siendo monitoreadas, ese sistema ha de
permitir una reconfiguracion dinamica para que no sea necesario el tener que desconectar el sistema de todas las
maquinas a la hora de tener que realizar un cambio cualquiera
Como se puede apreciar las arquitecturas dominantes de IDS en el mercado actual no
incorporan muchas de estas caracteristicas, ya que estas usan un unico analizador central aun en el caso de que nos
encontremos con IDS formados por modulos distribuidos entre las maquinas de esa red que analizen el trafico de esta
misma, ya que a fin de cuentas los datos siguen siendo encaminados a un punto central.
Ese analizador central es el punto de falla de todo el sistema ya que como es sabido una
cadena es tan fuerte como el mas debil de sus eslabones, si un atacante se propone como objetivo ese punto toda la red
se vera comprometida. A su vez otro problema que se deriva es que ha de existir un limite en la cantidad de trafico que
puede ser analizado, ya que un exceso de trafico para una unica maquina puede suponer la caida de esta misma.
============================================================================
= Concepto de agentes
============================================================================
Un agente puede realizar tanto una tarea simple como una de gran complejidad a la vez que puede que necesiten
informacion para su correcto funcionamiento producida por otro agente, pero aun asi se les sigue considerando a todos
los efectos "autonomos", ante esto puede que la idea de total autonomia no se vea tan clara, por lo que se clasifica a
los agentes verdaderamente dentro de dos categorias.
-
Agentes totalmente independientes, cuyos resultados son producidos por el mismo sin
necesitar de la asistencia de ningun otro agente
-
Agentes pertenecientes a un grupo, donde la informacion generada por cada agente es
necesaria para el correcto funcionamiento del resto de los agentes englobados dentro de ese grupo
Como se ve en todo momento el daño que se puede producir contra un sistema esta
restringido, ya sea a un unico agente o a un grupo de agentes organizados dentro de una misma estructura. A su vez todo
el conjunto de agentes que forman el sistema en su totalidad estan organizados mediante una estructura jerarquica
compuesta por multiples capas de agentes, donde cada capa inferior reporta la informacion necesaria a su respectiva
capa superior.
Una sistema conocido por todo el mundo que se puede en cierta medida asemejar al comportamiento de los agentes
autonomos es el sistema inmunologico humano, formado por una gran cantidad de celulas las cuales se encuentran en el
sistema sanguineo dispersas a traves de todo el cuerpo, debiendo de atacar en el momento en que se encuentran con una
posible amenaza para el cuerpo, siendo a veces necesario la union de varias celulas para destruir al atacante, es decir
el cuerpo esta en todo momento preparado para defenderse gracias a que tiene un gran numero de estas "celulas", tambien
siendo importante la caracteristica de que si una zona del cuerpo se ve infectada las celulas se desplazan a esa parte
para luchar, lo cual tambien es una caracteristica de los agentes autonomos en la medida en que se pueden reconfigurar
dinamicamente y migrar de un sistema a otro.
Un sistema AAFID esta compuesto por tres tipos de componentes:
-
Agentes
-
Transmisores
-
Supervisores
Pasando a ver el funcionamiento de cada uno de ellos.
============================================================================
= Agentes
============================================================================
Cada maquina de una red en la que queramos instalar un sistema AAFID puede contener cualquier numero de agentes, siendo
la funcion de estos la de vigilar la maquina en la que se encuentran segun las normas que tengan establecidas y
reportar a su transmisor correspondiente si ocurre algun suceso definido como sospechoso o peligroso, ya que un agente
no tiene la "autoridad" necesaria para generar una alarma por si solo, ocupandose de ello los transmisores o
receptores. Tambien se podria decir que los agentes no se comunican directamente con los demas agentes del sistema,
habiendo entre ellos el correspondiente transmisor en todo momento.
Pero aun asi los agentes disponen de ciertos privilegios o caracteristicas importantes como pueden ser la posibilidad
de retener estados entre sesiones para poder detectar cambios importantes o cualquier tipo de ataques, pero lo que es
mas fascinante, la capacidad de aprendizaje que pueden llegar a tener aunque al comienzo se dijese que un sistema AAFID
es un sistema basado en normas, teoricamente debido a ciertas caracteristicas se le puede encuadrar dentro de los
llamados sistemas adaptables, ya que no solo se limita a trabajar a partir de firmas de ataques conocidas, sino que
puede aprender nuevas lo cual se lleva a cabo mediante tecnicas de inteligencia artificial y en el caso que nos ocupa
mediante tecnicas de programacion genetica, lo que ahorraria la construccion de una enorme base de datos, estando
formada por pequeños programas encargados de detectar actividades muy simples en el sistema. Pero en la mayoria de
las ocasiones el problema no ofrece una solucion sencilla o esta es muy "cara" computacionalmente, por lo que la
posible solucion es representada mediante arboles de decision los cuales son manipulados mediante operaciones parecidas
a las que se producen en la genetica, lo que reduce en gran medida el trabajo del operador ya que este simplemente ha
de "guiar" el aprendizaje del agente sin tener que ajustar especificamente las operaciones de ningun agente el cual
llegado el momento en que ha terminado su fase de aprendizaje se dedicara a observar la actividad del sistema y
cooperara con los demas agentes para decidir cuando se ha producido un ataque, sin que el proceso de encontrar nuevas
combinaciones de acciones a analizar se detenga en ningun momento.
La complejidad de un agente puede ser muy variada, ya que se trata de un simple programa encargado de una funcion
especifica dentro del complejo entramado del sistema, pudiendo estar escrito en una gran cantidad de lenguajes de
programacion, aunque puede hacer uso de elementos sintacticos creados por un lenguaje especialmente creado para esta
funcion, lo que ayuda a la hora de tener que manejar parametros importantes del sistema como podria ser el uso de la
CPU, lo que estaria disponible para el programa como la variable CPU_USAGE, o el valor de varios campos de las
cabeceras de los paquetes que lleguen hacia esa red, siendo esta abstraccion tambien posible en gran parte gracias a la
capa de codigo entre los agentes y el sistema. Es decir, en todo momento los agentes consultan a la capa encargada de
la abstraccion de las caracteristicas importantes del sistema, comparando los valores que le son devueltos con su
modelo interno del sistema mediante sus propios calculos para poder llegar a la conclusion de si el sistema esta bajo
una intrusion o no.
Varios ejemplos de estas abstracciones usadas en los arboles de decision en pseudocodigo
podrian ser:
--==[Ejemplo 1]==--
for-each-packet do
if( ip-destination-address-of-packet
is-not-equal-to my-ip-address )
then generate-a-suspicion-broadcast
endif
endfor
Donde IP-DEST obtendria la direccion ip de destino del paquete de la capa de abstraccion y la funcion IP-NEQ compararia
esta direccion con la direccion del sistema dada por MY-IP. Este simple agente podria colaborar con otros para llegar a
desarrollar alguna funcion util para la seguridad del sistema.
--==[Ejemplo 2]==--
for-each-packet do
if( get-subnet-part(ip-destination-address-of-packet )
is-not-equal-to my-subnet-address )
then
generate-a-suspicion-broadcast
if( (packet-protocol equals UDP) and
(udp-dest-port equals 520)) then
generate-a-suspicion-broadcast
endif
endif
endfor
Este fragmento muestra como se puede detectar si un paquete entrante tiene como destino una subred fuera del firewall,
y si el paquete es del tipo UDP y va dirigido al puerto 520 se genera un mensaje de advertencia.
Como se ve esta forma de trabajo ofrece mucha flexibilidad, ya que podriamos usar este
simple agente para ocuparse de esta actividad en todo el sistema o un agente en el firewall, lo que nos ahorraria
muchos quebraderos de cabeza si la red se ve atacada, ya que las maquinas podrian perder la conexion entre ellas, pero
los agentes seguirian trabajando independientemente, mientras que si trabajasemos con un IDS simple dentro del firewall
muchas de las maquinas al perder la conexion entre ellas dejarian de estar protegidas.
--==[Ejemplo 3]==--
for-each-packet do
if( packet-protocol equals UDP) then
if( ip-source-address-of-second-packet
is-not-equal-to ip-destination-address-of-first-packet )
then generate-a-suspicion-broadcast
endif
if( udp-source-port-of-second-packet
is-not-equal-to udp-dest-port-of-first-packet )
then generate-a-suspicion-broadcast
endif
if( ip-destination-address-of-second-packet
is-not-equal-to ip-source-address-of-first-packet )
then generate-a-suspicion-broadcast
endif
if( udp-dest-port-of-second-packet
is-not-equal-to udp-source-port-of-first-packet )
then generate-a-suspicion-broadcast
endif
endif
endfor
Este simple agente vendria a hacer alguna de las caracteristicas conocidas como filtrado dinamico de paquetes, todo
ello debido a que los encabezados UDP no tienen nada parecido a un bit ACK como sucede en los paquetes TCP, por lo que
no se puede saber con solo examinar el encabezado de un paquete UDP entrante si es el primer paquete de un cliente
externo a un servidor interno, o en cambio es una respuesta de un servidor externo a un cliente interno.
El concepto de este agente es que "recordaria" los paquetes UDP salientes que ha visto, lo
que le serviria para permitir regresar unicamente a los paquetes con las respuestas correspondientes. Para que este
paquete entrante se tome como una respuesta valida, ha de ser del anfitrion y puerto al que se envio el paquete
saliente y debe estar dirigido al anfitrion y puerto que envio el paquete de salida.
============================================================================
= Transmisores
============================================================================
Los transmisores tienen como funcion controlar todas las operaciones que realizan los agentes de una maquina, a la vez
que procesando toda la informacion que es generada por estos, es decir por cada maquina hay un transmisor siendo el
canal de comunicacion de esta con el resto de las maquinas de la red; siendo tambien responsables de reducir la
informacion que les presentan los agentes para ser pasada a los supervisores.
============================================================================
= Supervisores
============================================================================
Los supervisores estan en la parte mas alta de la jerarquia del sistema, teniendo acceso a toda la informacion de la
red, ya que los transmisores mandan sus informes a uno o varios supervisores, por lo que son los encargados de detectar
intrusiones cuando estas implican a mas de una maquina de la red pudiendo detectar eventos que no son reportados por
los transmisores.
A su vez los supervisores pueden recibir instrucciones por parte de otros supervisores del
sistema, ya que puede existir una estructura jerarquizada entre ellos tambien, siendo estos finalmente los que se
comunican con el usuario tomando la ultima decision en todo momento, es decir puede que un agente informe de alguna
actividad sospechosa en el sistema, pero si esta actividad no es respaldada por mas agentes sera ignorada como un falso
positivo ya que los agentes no tienen la decision final, una vez que varios agentes de una maquina confirman dicha
actividad entra en juego el transmisor que volvera a evaluar la situacion pasando de nuevo su propio informe al
supervisor correspondiente donde se haran las ultimas estimaciones.
Como se puede ver los supervisores son un posible punto de fallo, ya que si cae uno todos
los transmisores que dependen de el dejaran de pasar informacion, pero esto se resuelve gracias a la estructura
jerarquica que esta presente en este tipo de sistemas, ya que si un supervisor cae los supervisores por encima de el se
encargaran de examinar la situacion.
============================================================================
= Canales de comunicacion
============================================================================
Como es logico la transmision de mensajes entre las distintas partes del sistema (agentes, transmisores y supervisores)
es una parte fundamental de este tipo de sistemas, debiendo de cuidar la seguridad de estos canales en gran medida para
protegerlos contra ataques externos o subsistemas internos en algunos casos, a la vez que se debe de contar con
mecanismos de autentificacion y privacidad para defender tales canales.
Los sistemas distribuidos usan RCP (Remote Procedure Call) o TCP/IP como su principal
canal de comunicacion, mientras que las aplicaciones internas pueden usar streaming protocols, multicast, RPC entre
otros, siendo muy comun el que esten programadas usando librerias de paso de mensajes como MPI (Message Passing
Interface) o lenguajes de programacion como HPF o HPC ++ que ya nos pueden permitir asegurar la creacion de procesos y
los mecanismos de seguridad.
En terminos generales podemos clasificar los tipos de comunicaciones en dos tipos:
Como posible desventaja podemos ver que hay un cierto riesgo de sufrir un DoS, ya que
cuando un proceso manda un mensaje a otro el kernel copia los datos en memoria, habiendo una logica limitacion en el
numero de mensajes que se pueden almacenar.
============================================================================
= Un paso mas alla: Sensores encajados
============================================================================
Viendo de una manera global a los sistemas que hacen uso de los agentes autonomos se puede comprobar que aun siguen
teniendo ciertos puntos que los hacen vulnerables a varios tipos de ataques ya que estos agentes en todo momento hacen
uso de una gran cantidad de informacion del sistema lo que hace que la cantidad de recursos necesarios para su
funcionamiento se dispare.
Ante esta problematica nos encontramos con los sensores encajados, los cuales son usados
por sistemas como OpenBSD, sirviendo para detectar ataques especificos y estando en el caso de OpenBSD "encajados" en
el kernel ocupando muy poco codigo, usando recursos del sistema solo cuando son ejecutados a la vez que estan mas
protegidos a ser desactivados por un atacante al ser parte del codigo del kernel, reduciendo tambien el numero de
falsos positivos y negativos al estar situados cada uno en el segmento de codigo donde se encuentra el fallo del que
puede intentar aprovecharse el atacante.
Un ejemplo simple podria ser:
--==[Ejemplo 1]==--
char buf[1024];
strcpy(buf,getenv("TERM"));
En este ejemplo la variable de entorno TERM es copiada a un buffer sin chequear su longitud, pudiendose obtener un
buffer overflow.
Un posible sensor que se encargase de vigilar esta variable podria ser:
char buf[1024];
{
if (strlen(getenv("TERM")) > 1024 {
log_alert("buffer overflow");
}
}
strcpy(buf,getenv("TERM"));
Donde una vez que se ha implantado el sensor la funcion log_alert nos alertaria de que se ha producido un buffer
overflow, pudiendo otros sensores intentar parar la intrusion, aunque tiene otras complicaciones que no vamos a
tratar.
Algunos sensores implantados en OpenBSD de ataques concretos son:
--==[Land]==--
case TCPS_LISTEN: {
...
if (ti->ti_dst.s_addr == ti->ti_scr.s_addr) {
/* ESP */
#ifdef ESP_LAND
if (esp.sensors.land) printf("LAND attack\n");
#endif
goto drop;}
... }
Este ataque puede causar un DoS en varias implementaciones de TCP, mandando un paquete TCP SYN a un puerto de la
maquina, estableciendo la direccion de la maquina victima tanto como destino a la vez que fuente, usando tambien el
mismo puerto de la maquina victima como destino y fuente, causando que la maquina entre en un bucle infinito enviandose
paquetes ACK a si misma hasta que cae.
--==[Teardrop]==--
i = p->ipqe_ip->ip_off +
p->ipqe_ip->ip_len -
ipqe->ipqe_ip->ip_off;
if (i > 0) {
if (i >= ipqe->ipqe_ip->ip_len) {
/* ESP */
#ifdef ESP_TEARDROP
if (esp.sensors.teardrop) {printf("TEARDROP attack\n"); ... }
#endif
goto dropfrag;}
Teardrop es un ataque de solape de fragmentacion IP, debido a que se hacen comprobaciones para gestionar los fragmentos
grandes pero no para los fragmentos demasiado pequeños, pudiendo un atacante forzar un tamaño de fragmento
negativo, provocando la caida del sistema.
--==[TCP RST DoS]==--
if (tiflags & TH_RST) {
if (ti->ti_seq!=tp->last_ack_sent) {
/* ESP */
#ifdef ESP_RSTDOS
if (esp.sensors.rstdos) printf("TCP RST DOS attack\n");
#endif
goto drop;}
... }
Este ataque consiste en el envio de un falso paquete TCP RST que provoca la desconexion de la sesion TCP, debido a que
no se comprueban los numeros de secuencia de los paquetes RST.
--==[TCP Sequence Number Prediction]==--
if (tiflags & TH_ACK) {
...
if (SEQ_LEQ(th->th_ack,tp->snd_una) ||
SEQ_GT(th->th_ack,tp->snd_max)) {
/* ESP */
#ifdef ESP_TCPSEQNR
if (esp.sensors.tcpseqnr) printf("TCP SEQNOPRED attack\n");
#endif
goto dropwithreset;}
... }
Aqui el problema viene debido a que el numero inicial de secuencia de TCP no es elegido tan aleatoriamente como
debiera, por lo que un atacante puede adivinarlo y completar la conexion con una direccion spoofeada.
Esta clase de sensores son una gran solucion para la defensa de un sistema debido a las ventajas que conllevan y
deberian de ser tomadas en cuenta para el diseño de un IDS, pudiendo ser tambien utilizados para construir un
honeypot "universal".
============================================================================
= No solo deteccion: NetRanger
============================================================================
La gran mayoria de los IDS solo se dedican a reportar actividad no autorizada pero no a terminar con esta actividad,
encontrandonos con NetRanger que si que es capaz de hacerlo eliminando las conexiones sospechosas, siendo posible esto
cambiando las Access Control Lists (ACLs) de los routers Cisco. En este sistema tambien se recurre a un tipo de
sensores encargados de capturar los paquetes, pudiendo actualizar dinamicamente las ACLs para negar actividad no
autorizada, a su vez estos sensores no pueden ser detectados al no tener direccion IP por lo que ningun paquete es
enviado hacia ellos.
Cuando un ataque es detectado no solo se cambian las ACLs, el sensor manda un TCP Reset para terminar con esa conexion
en el caso de que sea TCP.
Las reglas son del formato:
ip audit attack {action [alarm] [drop] [reset]}
Donde alarm, drop y reset son las acciones que se pueden tomar.
Un ejemplo de configuracion seria:
--==[Ejemplo 1]==--
ip audit smtp spam 25
/* especificamos el numero de receptores de un mensaje para ser considerado como
un spam attack */
ip audit notify nr-director
/* especificamos el metodo de notificacion de sucesos a usar, en este casomandando
mensajes en el formato NetRanger al director NetRanger o al sensor */
ip audit notify log
/* a su vez tambien notificamos de los sucesos acaecidos mandando mensajes en el
formato syslog */
ip audit po local hostid 55 orgid 123
/* especificamos los parametros a usar a la hora de mandar los mensajes al director
NetRanger, donde 55 identifica la maquina local dentro de todo el
conjunto de
comunicaciones y 123 identifica el grupo al que pertenece */
ip audit po remote hostid 14 orgid 123 rmtaddress 10.1.1.99 localaddress 10.1.1.1 preference 1
/* parecido a lo anterior con la salvedad de que en este caso configuramos los
parametros a la hora de recibir mensajes del router, donde 10.1.1.99 es
la direccion
IP del director NetRanger, 10.1.1.1 la direccion IP del router y 1 indica
el router
designado para esa comunicacion */
ip audit name AUDIT.1 attack action alarm drop reset
/* creamos un conjunto de reglas con el nombre de AUDIT.1 configurada para tener firmas
de informacion, firmas de ataques y en el caso de que se produjese un
ataque se
mandaria una alarma ya sea a la consola, a syslog o al director
NetRanger, se dejaria el
paquete en cuestion y se resetearia la conexion */
interface e0
ip address 10.1.1.1 255.255.255.0
/* direcciones */
ip audit AUDIT.1 in
/* especifica que el conjunto de reglas llamado AUDIT.1 sera aplicado al trafico entrante */
============================================================================
= Ataques Coordinados
============================================================================
Hoy en dia los llamados ataques coordinados son una de las mayores fuentes de problemas para los profesionales de la
seguridad informatica debido a la dificultad que estos conllevan para ser detenidos, la relativa facilidad con que
pueden ser lanzadas y el tremendo daño que pueden llegar a causar.
Los tradicionales DoS son faciles de detectar y prevenir, ya que lo que se hace es
monitorear la cantidad de trafico proveniente de cada direccion, saltando las alarmas si esta cantidad de trafico es
inusual, pero los DDoS no son tan faciles de manejar, ya que entran en juego una gran cantidad de maquinas, por lo que
ya no se puede aplicar la anterior tecnica.
LLegado a este punto, deberiamos de mencionar a los ISP, los cuales son uno de los puntos mas importantes de defensa
contra un DDoS, debiendo estos de seguir unas sencillas reglas para intentar mitigar este tipo de ataques, pudiendose
dar el caso de que en un hipotetico futuro solo sobrevivan aquellos ISP capaces de reaccionar a este tipo de ataques,
ya sea por el cumplimiento de todas las reglas preventivas necesarias como por su tremendo ancho de banda, y ante esto
ultimo los pequeños ISP no podrian reaccionar.
Actualmente se estan llevando a cabo numerosas investigaciones en el campo defensivo, ya sean monitores distribuidos
inteligentes, metodos criptograficos como protocolos "puzzle", herramientas IP Traceback o ICMP Traceback, etc.
Ante esta avalancha de nuevos problemas lo unico que se puede hacer es mediante la ayuda conjunta de un IDS y de un
firewall intentar prevenir estos ataques, para que estos tengan lugar la supuesta eleet necesita de maquinas
vulnerables para la instalacion de maestros y demonios, por lo que un esfuerzo global de cara a la seguridad, reduciria
las posibilidades de que se produzcan dichos ataques, aunque esto por supuesto puede que sea una utopia.
Por ultimo podriamos resaltar la existencia de herramientas como Stick, las cuales pueden ser capaces de producir un
DoS contra un IDS, basandose como no en la simple idea de flodear al IDS, donde llegado cierto momento este no es capaz
de manejar todos los eventos generados en ese pequeño intervalo de tiempo, suponiendo este tipo de herramientas
mas posibilidades de ataque para los individuos que se dedican a llevarlas a cabo, aunque el concepto en si no tiene
ningun misterio.
============================================================================
= Protocolos Puzzle: Reservando el derecho de admision
============================================================================
Esta seccion no tiene un enlace directo con el campo de los sistemas de deteccion de intrusos, pero supone unos
conceptos interesantes para cualquier 'doctor en seguridad', ya que mediante estos protocolos se abre una nueva via
para la defensa de un servidor ante DoS lanzados por los atacantes siendo la idea la de proponer un "juego" para ver
quien puede y quien no resolverlo.
En el momento en que un servidor equipado con este tipo de sistemas comprueba que esta siendo atacado, lo que hace es
enviar a los clientes que solicitan sus servicios unos pequeños puzzles criptograficos, siendo necesario su
resolucion si el cliente quiere tener acceso a ese servicio.
Hay que recordar que este tipo de sistemas estan aun en fase experimental, siendo hoy en
dia uno de los metodos en teoria mas efectivos el de los "syncookies", que aunque suponen un gran avance en la lucha
contra los DoS del lado de los servidores, siguen teniendo ciertas posibles vulnerabilidades, aunque lo justo seria
decir que estas se reducen a un rango muy concreto y reducido. En este punto es donde los desarrolladores de los
llamados puzzles criptograficos partieron, para hacer que su tecnologia fuese lo mas perfecta posible.
Como punto de partida debemos de decir que los protocolos puzzle no parten de hipotesis como si hacen otros sistemas
defensivos, por lo que son mucho mas robustos que estos otros, siendo tambien utiles para ser usados contra ataques
internos, como para manejar ataques montados a grandes velocidades, ya que como parte de sus caracteristicas de
adaptacion los puzzles generados eran del tamaño correspondiente a cada tipo de ataque, a la vez que estos han de
ser resueltos en un intervalo determinado de tiempo.
Como se puede ver, el punto mas critico de este tipo de sistemas lo constituyen los
puzzles, por lo que estos han sido desarrollados de una forma cuidadosa, estando compuestos estos a su vez por
sub-puzzles para evitar los ataques por fuerza bruta, siendo importante el decir que cada subpuzzle tiene una unica
solucion, a la vez que cada uno se construye independientemente del resto, por lo que los problemas de una mala
eleccion de la "semilla" parecen haber sido parcialmente tenidos en cuenta, siendo tambien bastante complejo intentar
montar un ataque criptoanalitico contra estos sistemas.
Aunque a este tipo de sistemas les quedan por pasar pruebas a pie de campo auguran un gran avance en el campo
defensivo, ya que para cualquier IDS la deteccion y bloqueo de un DDoS es bastante problematica, por lo que estos
sistemas pueden ser de gran ayuda, aunque solo serian validos para cierto tipo de servidores ya que como se ha dicho,
el cliente que quiera tener acceso al servidor ha de tener que resolver el "juego" que se le proponga, para lo que
necesita una cierta cantidad de datos por parte del servidor, es decir los protocolos puzzle segun estan planteados
solo son validos para servidores de uso privado en cierta manera, por lo que los sitios publicos en un principio no
podrian beneficiarse de este tipo de sistemas.
============================================================================
= Jugando con TCPdump: Trafico Mutante
============================================================================
TCPdump es una herramienta que nos permite analizar el trafico de la red, siendo de gran utilidad para los analistas de
seguridad y cualquier otra persona que este interesada en saber que es lo que esta ocurriendo en su red a traves del
analisis de su trafico de entrada y salida.
En esta seccion veremos ejemplos mostrados por TCPdump de trafico altamente sospechoso para intentar mostrar las ideas
o fundamentos para que el lector sea capaz por si mismo de detectar este trafico inusual, que en muchas ocasiones puede
pasar desapercibido incluso para muchas unidades de filtrado y IDS´s.
Para empezar veamos un ejemplo de una conexion TCP absolutamente normal
09:35:22:850000 cliente.net.35956 > telnet.com.23: S
244859854:244859854(0)
win 8855 <mss 1460> (DF)
telnet.com.23 > cliente.net.35956: S 1153650586:1153650586(0) ack
244859855 win 1024 <mss 1460> (DF)
cliente.net.35956 > telnet.com.23: . ack 1 win 8855 (DF)
-
El primer campo es el de la marca de tiempo que solo esta presente en la primera linea,
habiendo sido omitido por razones de claridad.
-
El siguiente es el host de origen con el numero de puerto origen.
-
Despues de > que indica la direccion de la conexion, viene el host destino y el puerto
destino.
-
Despues de : esta S que nos indica que el protocolo es TCP, representando la S el
indicador SYN, siendo la peticion de inicar una conexion TCP.
-
244859854:244859854(0) es el numero de secuencia inicial de TCP:numero de secuencia final
de TCP(bytes de datos). Donde el numero de secuencia final TCP es igual al numero de secuencia inicial mas el numero de
bytes de datos enviados, que suele ser 0 cuando se trata de una peticion de establecimiento de conexion.
-
win 8855 indica el tamaño del buffer del host origen.
-
mss representa el tamaño de segmento maximo, sirviendo para indicar al host destino
que el host origen no debe recibir mas de 1460 bytes de TCP, siendo todo lo que puede recibir la red fisica, aunque el
host origen pueda aceptar hasta 8855 bytes de datos.
-
DF es el indicador de no fragmentacion.
Una vez explicado esto las demas partes del proceso no son muy dificiles de entender, ya que es una simple conexion
TCP, el cliente envia un SYN al servidor para solicitar una conexion TCP con este, el servidor si esta en condiciones
de hacerlo manda al cliente un SYN mas un ACK y por ultimo si el cliente desea continuar con la conexion envia un
ACK.
Una vez visto esta pequeña introduccion vamos a ver ejemplos de trafico mutado por los atacantes, sirviendo para
muchos propositos, desde causar un DoS en el host, pasando por la recoleccion de informacion de este mismo.
Para entenderlo totalmente se necesita un dominio bastante aceptable de TCPdump, al igual
que comprender las tecnicas de escaneo silencioso siendo algo que esta fuera del ambito de este articulo.
--==[Ejemplos 1, 2, 3, 4, 5, 6]==--
[eliminados por maty]
Todos estos ejemplos se podria decir que no son mas que unos cuantos granos de arena en la inmensidad de una playa, ya
que existen una gran variedad de configuraciones de trafico mutado, mas todas las posibles configuraciones que aun
estan por descubrirse que de alguna manera pueden ayudar a los intrusos para sus propositos.
Jugando con esta herramienta se pueden llegar a descubrir verdaderas joyas ya que siempre
hay gente que se las ingenia para desarrollar nuevas mutaciones, por lo que la actitud de cualquier persona que este
enfrente de esta herramienta ha de ser la de no creer al pie de la letra lo que esta viendo, tomando una actitud
paranoide para poder distinguir entre percepcion y realidad.
Tambien decir que aunque las marcas de tiempo han sido omitidas por cuestiones de claridad, para un analisis real son
de vital importancia, ya que gracias a ella podemos averiguar muchas cosas sobre la mentalidad del atacante hacia
nuestra maquina, al igual que poder discernir sobre el supuesto 'nivel' de este atacante y la clase de herramientas que
esta usando para obtener informacion.
============================================================================
= LAD: Login Anomaly Detection
============================================================================
Es posible que nos encontremos con ciertos IDS´s bastante agresivos, los cuales tengan estipulado que ante ciertas
anomalias han de llevar a cabo acciones ofensivas contra el supuesto atacante, no solo como pudiera ser en el caso de
NetRanger de cortar una comunicacion, sino tambien llegar al extremo de congelar una cuenta dada, otro IDS que actua
tambien de un modo similar en cuanto a su dinamismo es RealSecure.
Por supuesto la funcion de un IDS es la de responder ante ciertas anomalias, pero en esta seccion veremos otro tipo de
anomalias que pueden ser interesantes para usar, todas estas parten de todo el rango de posibilidades que se puede dar
dentro de las llamadas anomalias de login, las mas usadas son :
Para ello el sistema hace uso de un metodo estadistico, donde esta reunido una gran
cantidad de informacion sobre los habitos de los usuarios. Si un atacante se hace con la contraseña de un usuario
de nuestra red, y este atacante entra en el sistema usando esta contraseña de una manera normal, nuestro IDS como
es logico no detectara nada y es aqui donde entran en juego estos metodos estadisticos.
Ejemplos de aspectos a tener en cuenta para cada cuenta pueden ser, duracion de una sesion Telnet, cantidad de bytes
transmitidos, la fecha exacta en que el usuario suele acceder a su cuenta en el sistema, la direccion de origen desde
la que conecta el usuario, la cantidad de recursos de la CPU que utiliza un usuario, etc.
Este tipo de sistemas estan orientados hacia maquinas de alto riesgo e importancia, donde los usuarios son plenamente
conscientes del lugar en que se encuentran, contando con una gran cantidad de recursos en el sistema para poder manejar
una base de datos de esa magnitud.
============================================================================
= IAP: Intrusion Alert Protocol
============================================================================
Este protocolo esta orientado al intercambio de informacion de alerta entre los distintos componentes que forman un
sistema de deteccion de intrusos, usando TCP como mecanismo de transporte.
Al encontrarnos en una red cualquiera nuestro IDS estara dividido en varios sensores,
teniendo cada uno una mision especifica, sirviendo IAP para transmitir los mensajes de alerta desde los sensores o
analizadores al modulo encargado de ese conjunto de sensores.
IAP hace uso de MIME para la encapsulacion de los datos, pero los datos de alerta son mandados en el formato XML,
constando este proceso de intercambio de informacion de dos conexiones simultaneas, una para el flujo de datos del
sensor y otra para el flujo de datos del modulo encargado, debiendo en todo momento estas dos conexiones atenerse a un
perimetro de seguridad establecido por IAP.
En el proceso de establecimiento de los parametros de seguridad se establecen los parametros tipicos, como son la
version del protocolo, los algoritmos criptograficos a usar generando claves privadas para las siguientes fases, no
sabiendo a ciencia cierta si este proceso es vulnerable al igual que pasaba con SSL a los llamados "rollback
attacks".
Existen varios modelos de comunicacion entre los componentes de un IDS, pero el mas extendido es el modelo de peticion
- respuesta.
+------------------------+
/ V
+--------+ +----------+ / +---------+ +---------+
| | report | |/ alert | | | |
| Sensor |------->| Analyzer |--------->| Manager | | Manager |
| | | | | | | |
| | | | query | | | |
| | | |<---------| | | |
| | | | response | | | |
| | | |--------->| | | |
| | | | | | | |
+--------+ +----------+ +---------+ +---------+
IDS #1 |
.................................................|..................
IDS #2 | alert
V
+---------+
| |
| Manager |
| |
+---------+
Donde los analizadores no mandan toda la informacion referente a los eventos sino que solo
mandan cierta cantidad de datos sobre la alerta, como pueden ser el tipo o la prioridad de dicha alerta, lo cual no se
da en los restantes modelo, sirviendo entre otras cosas para reducir la carga.
Un ejemplo que he encontrado del formato de los mensajes de alerta para quien desee iniciarse seria el siguiente :
--==[Phf Attack]==--
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.3//EN"
"idmef-message.dtd">
<IDMEF-Message version="0.3">
<Alert ident="abc123456789" impact="attempted-recon">
<Analyzer analyzerid="bc-sensor01">
<Node category="dns">
<name>sensor.bigcompany.com</name>
</Node>
</Analyzer>
<CreateTime ntpstamp="0x12345678.0x98765432">
2000-03-09T08:12:32-01:00
</CreateTime>
<Source ident="abc123">
<Node ident="abc123-001">
<Address ident="abc123-002" category="ipv4-addr">
<address>222.121.111.112</address>
</Address>
</Node>
<Service ident="abc123-003">
<port>21534</port>
</Service>
</Source>
<Target ident="xyz789">
<Node ident="xyz789-001" category="dns">
<name>www.bigcompany.com</name>
<Address ident="xyz789-002" category="ipv4-addr">
<address>123.45.67.89</address>
</Address>
</Node>
<Service>
<port>8080</port>
<WebService>
<url>
http://www.bigcompany.com/cgi-bin/phf?/etc/group
</url>
<cgi>/cgi-bin/phf</cgi>
<method>GET</method>
</WebService>
</Service>
</Target>
<Classification origin="databaseid">
<name>629</name>
<url>http://www.securitycompany.com</url>
</Classification>
</Alert>
</IDMEF-Message>
============================================================================
= GIDO: Generalized Intrusion Detection Objects
============================================================================
CIDF (Common Intrusion Detection Framework), es una serie de estandares orientados para que los IDS puedan trabajar
entre ellos de una forma conjunta, y en este punto nos encontramos con Gidos, que es un formato especifico
diseñado para intercambiar mensajes entre los IDS para tener conocimiento del estado de su "universo" a la vez que
poder recomendar las acciones a tomar segun los eventos ocurridos.
Es decir Gidos permite:
-
Describir eventos que han sucedido en los sistemas pertenecientes a la red
-
Recomendar a un IDS llevar a cabo una accion
-
Preguntar a un IDS sobre los eventos ocurridos
Es decir cuando alguna de estas acciones se lleva a cabo, se estan produciendo gidos,
habiendo por tanto diversas clases de gidos, por ello hay componentes que obtienen gidos de otros componentes para
trabajar sobre ellos devolviendo mas tarde nuevos gidos, hay tanto consumidores de gidos como productores de gidos,
pudiendo configurar cada componente para que solo acepte los gidos que desee.
Como cualquier otro paquete un gido consta de una cabecera y de un cuerpo, donde el cuerpo esta formado por sentencias
que describen el estado de una maquina, recomiendan algun tipo de acccion o reportan algun evento ocurrido, siendo el
verbo la parte mas importante de la sentencia, diciendo lo que ha ocurrido como puede ser "Delete", tambien esta el
identificador de quien ha llevado a cabo la accion como "Operand" por ejemplo, otros campos habituales son RealName,
UserName, UserID, etc.
Un ejemplo de la sintaxis:
(def RemoveFile ($username $filename)
(Remove
(Initiator (UserName $username))
(Operand (ObjectType file) (ObjectName $filename))
)
)
La cabecera contiene la informacion basica sobre todo del gido mismo, mas que del analisis de los eventos o cualquier
otra accion a tomar, que iria en el cuerpo.
Los campos principales en la cabecera son:
-
Identificador de version
-
Longitud del gido
-
Time stamp
-
Identificador thread
-
Identificador de clase
-
Identificador del creador
-
Flags
============================================================================
= CISL: Common Intrusion Specification Language
============================================================================
CISL es el lenguaje usado entre los componentes CIDF para comunicarse entre ellos intercambiando informacion, este
lenguaje se basa en lo que se conoce como expresiones S, siendo muy similar al lenguaje Lisp, constando de etiquetas y
datos, siendo expresados por suerte o por desgracia segun la sintaxis del ingles, unos simples ejemplos:
¼b>--==[Ejemplo 1]==--
(And
(OpenApplicationSession
(When
(Time 15:00:30 22 Nov 2000)
)
(Initiator
(HostName 'memonix.net')
)
(Account
(UserName 'memonix')
(RealName 'memonix')
(HostName 'host.net')
(ReferAs 0x12345678)
)
(Receiver
(StandardTCPPort 23)
)
)
(Delete
(World Unix)
(When
(Time 15:01:29 22 Nov 2000)
)
(Initiator
(ReferTo 0x12345678)
)
(FileSource
(HostName 'host.net')
(FullFileName '/etc/passwd')
)
)
(OpenApplicationSession
(World Unix)
(Outcome
(CIDFReturnCode failed)
(Comment '/etc/passwd missing')
)
(When
(Time 15:03:17 22 Nov 2000)
)
(Initiator
(HostName 'evil.net')
)
(Account
(UserName 'kenobi')
(RealName 'kenobi')
(HostName 'host.net')
)
(Receiver
(StandardTCPPort 23)
)
)
)
En esta expresion S se esta queriendo decir lo siguiente, alguien desde memonix.net se
conecta a la maquina host.net conectandose a la cuenta memonix, borrando esta misma persona despues el archivo
/etc/passwd, mas tarde alguien desde evil.net intenta conectarse a host.net y en concreto a la cuenta kenobi.
En este ejemplo se ven involucrados varios SIDs o Semantic IDentifiers, que vienen a ser
las etiquetas, viniendo a expresar cosas muy distintas, desde acciones, objetos a tiempos y localizaciones.
--==[Ejemplo 2]==--
(Execute
(Initiator
(UserName 'memonix')
)
(Process
(FileName 'ls')
)
(Process
(FileName 'ps')
)
(Process
(FileName 'cd')
)
(Process
(FileName 'chmod')
)
)
Aqui se expresa que el usuario memonix ejecuto los comandos ls, ps, cd y chmod.
--==[Ejemplo 3]==--
(OpenApplicationSession
(When
(Time 16:00:36 22 Nov 2000)
)
(Initiator
(IPV4Address 242.2.2.2)
)
(Account
(UserName 'kenobi')
(RealName 'kenobi')
(HostName 'host.net')
(IPV4Address 241.1.1.1)
)
(Receiver
(StandardTCPPort 23)
)
)
Un usuario desde la maquina 242.2.2.2 se autentifico como el usuario kenobi en la maquina host.net, tanto esta notacion
como las anteriores son usadas, aunque lo mas frecuente es encontrar la direccion ip.
En el anterior apartado sobre gidos vimos que uno de los campos de la cabecera de un gido
es el identificador de clase, siendo este un campo que para ciertos propositos nos puede resultar de mucha utilidad,
los codigos identificativos de cada clase son los siguientes:
0x0020 = trace
0x0021 = response prescription
0x0022 = report
0x0023 = evidence of event
0x0024 = notification
0x0025 = request from discovery coordinator (DC)
0x0026 = response from DC
0x0027 = exchange
0x0028 = suggested action
0x0029 = status report from DC
0x002a = undo request from DC
0x002b = detection
0x002c = informational message from DC
0x002d = merge from DC
0x002e = do request from DC
0x002f = table update
Estos codigos junto con los pertenecientes a cada etiqueta nos pueden servir para desarrollar un decodificador de
gidos, ya que las sentencias son codificadas en flujos de octetos, por ejemplo Allow es 0x08000804, BlockMessage es
0x08000073, Attack es 0x08000081, etc.
Como se puede ver la forma de actuar seria similar a la de los crackers cuando estan ante un listado con los bytes
pertenecientes a cada nemotecnico lo unico que por supuesto cabe decir es que si los gidos van correctamente
encriptados de poco nos serviria esto.
Un ejemplo de como iria el tema:
--==[Ejemplo 1]==--
(HostName 'memonix.net') 00 00 00 13
04 00 00 0c
00 00 00 0b
6d 65 6d 6f 6e 69 78
En primer lugar tenemos el codigo para HostName que es 0x0400000c, luego tenemos que poner la longitud de la cadena
'memonix.net' que es de 11 siendo el once 0x0000000b y por ultimo la codificacion de la cadena 'memonix.net' que es 6d
65 6d 6f 6e 69 78, siendo el penultimo paso el de concatenar todo.
Una vez hecho todo esto se pasa a añadir al principio la longitud de la combinacion
entera, siendo de ocho de HostName mas once de memonix.net, es decir diecinueve que es 00 00 00 13.
============================================================================
= Lenguajes de ataque
============================================================================
En el mundo de los IDS existen otro tipo de lenguajes llamados lenguajes de ataque debido a que su fin es el de llegar
a detectar cuando uno de ellos ha tenido lugar, para ello los creadores de estos lenguajes lo que hacen es codificar
como tienen lugar los distintos tipos de ataque, diviendo a estos en una secuencia de acciones, pudiendo tambien llegar
a detectar ataques coordinados.
Dentro de este tipo de lenguajes podemos encontrar varias divisiones que son las
siguientes:
-
Lenguajes de eventos:
Estos lenguajes son usados para la simple descripcion de eventos o posibles
acciones que pueden tener lugar, para su inmediata comprension por parte
del ids.
-
Lenguajes de reporte:
Este tipo de lenguajes se usan para reportar alarmas, dando cierta
informacion sobre el tipo de ataque al que esta siendo sometida la maquina
al igual que el posible origen de este ataque.
-
Lenguajes de respuesta:
En estos lenguajes se especifican las acciones que han de ser tomadas en
el momento en que se detecta un ataque, pudiendo llegar a producirse
distintos tipos de respuestas segun se va desarrollando el ataque.
-
Lenguajes 'exploit':
En estos lenguajes se describen las distintas acciones o pasos que han de
tener lugar para que un determinado ataque tenga exito.
-
Lenguajes de correlacion:
Con estos lenguajes se pretende poder llegar a determinar cual es el origen
entre determinados ataques, analizando para ello de una forma un tanto
distinta toda la informacion que se tiene sobre los eventos que estan
teniendo lugar en la maquina.
-
Lenguajes de deteccion:
Los lenguajes de deteccion son seguramente los mas conocidos, ya que dentro
de este grupo se encuadran los lenguajes usados para la creacion de filtros
en los ids mas comunes.
Ejemplos existentes de este tipo de lenguajes podrian ser por ejemplo STATL en el cual se
pasa a dividir cada ataque en pequeñas secuencias, teniendo tambien como ayuda los STD o State Transition Diagram
que vienen a representar graficamente los eventos que van ocurriendo, siendo el funcionamiento de STATL muy similar al
de una maquina finita de estados ya que encontramos estados y funciones de transicion que van desde el momento en que
la maquina esta libre de todo ataque hasta que el momento en que ha sido comprometida.
Otros lenguajes de este tipo algo mas populares sobre los que no dire nada son CASL y
NASL.
============================================================================
= ADELE: Una alternativa para el testeo de IDS
============================================================================
Este lenguaje es un proyecto del ministerio de defensa frances que nace con la intencion de servir de ayuda a los
analistas de ids para el testeo de estos mismos, utilizando para ello el modelado de ataques conocidos para llevar a
cabo la contruccion de una base de datos, este lenguaje reune caracteristicas de los lenguajes de deteccion,
correlacion, respuesta y exploit, siendo una caracteristica curiosa el que las descripciones ADELE contienen como era
de esperar codigo para llevar a cabo los distintos tipos de ataque.
Estos descriptores constan de tres campos, campo de explotacion, de deteccion y de
respuesta, constando cada uno de ellos de un campo de precondicion, postcondicion donde se dan a entender cuales son
los requisitos que necesita el atacante para llevar a cabo ese determinado ataque y cuales seran los resultados una vez
que ese ataque se haya llevado a cabo con exito.
Segun veo esto podria decir que puede constituir una buena forma para el aprendizaje de ciertas vulnerabilidades pero
teniendo el codigo de los exploits en c por ejemplo este lenguaje vendria a ser algo redundante ademas de que habria
que tener en cuenta el tiempo gastado para traspasar todos los exploits a este lenguaje, adjunto el esqueleto de como
se formarian tales descriptores.
--==[Ejemplo 1]==--
[eliminado por maty]
Otros tipos de sistemas que tambien sirven para el testeo de IDS podrian ser el lenguaje Lambda tambien del ministerio
de defensa frances, siendo un proyecto que se desarrollo en paralelo a Adele teniendo la misma finalidad o el paquete
expect aunque este es ya algo antiguo.
============================================================================
= Curvas ROC: Receiver Operating Characteristic
============================================================================
Para terminar de hablar sobre las tecnicas usadas para el testeo de IDS mencionar el uso de las tecnicas conocidas como
curvas roc, las cuales tienen como letit motiv el que un ids no solo se puede considerar bueno segun el porcentaje de
ataques que pueda capturar, sino que tambien se ha de tener en cuenta el porcentaje de falsos positivos generado por
este mismo, ya que si un ids es capaz de detectar el 90% de ataques de un determinado tipo pero a su vez genera una
media de mas de 100 falsos positivos por dia es un ids poco eficaz, ya que la validacion de los datos seria demasiado
costosa en niveles de tiempo, siendo por ello por lo que las curvas roc son usadas en el testeo de ids, ya que estas
determinan los radios de deteccion de ataques frente al radio de falsos positivos generados, por lo que cuando se desea
comparar un determinado grupo de productos entre si lo que se hace es someter a tales productos ante trafico generado
'artificialmente', es decir ante trafico considerado como normal o comun para esa maquina junto con un determinado
numero de ataques los cuales se dividen en ciertas categorias, por supuesto los encargados de cada producto desconocen
de ante mano cuales seran esos determinados ataques, despues del numero de dias que se considere oportuno se pasa a
comparar los resultados generados por cada producto, pudiendo por tanto llegar a diversas conclusiones como son que ids
tiene un menor numero de falsos positivos, cual es capaz de detectar un mayor porcentaje de ataques de un determinado
tipo, siendo esto ultimo de gran utilidad ya que si los desarrolladores de un determinado ids comprueban que su
producto es capaz de detectar un porcentaje considerable de bofs pero en cambio el porcentaje de DoS detectados es
mediocre saben por donde han de intentar meter mano para mejorar su producto.
Por supuesto decir que las curvas roc son como no originarias de otros campos del saber,
para quien este interesado en conocer estos origenes le remito a 'The Relative Operating Characteristic in
Psychology', 'Signal detection theory and ROC-analysis' y 'Coronary Artery Bypass Risk Prediction Using Neural
Networks'.
============================================================================
= CIDDS: Un ejemplo de sistema dedicado
============================================================================
Por ultimo hablar sobre los sistemas dedicados, siendo un ejemplo CIDDS (Common Intrusion Detection Director System) el
cual es propiedad del Air Force Information Warfare Center, constando este producto de un hardware, software y sistema
operativo dedicado para la deteccion de intrusos, trabajando en cierta manera en paralelo con el tambien producto
dedicado ASIM (Automated Security Incident Measurement), pudiendo estos sistemas almacenar todos los datos recibidos en
tiempo real en bases de datos locales, en las cuales se llevan a cabo las funciones de correlacion siendo estas
llevadas a cabo tanto por analistas humanos como por otro tipo de software especializado, puediendo debido a la
magnitud de estas bases de datos reconocer secuencias o fases de ataques en largos periodos de tiempo, pudiento tambien
llevar a cabo analisis 'keystroke by keystroke' de conexiones en tiempo real, siendo de nuevo la idea central de este
tipo de sistemas la de agentes autonomos.
============================================================================
= Conclusion
============================================================================
Todo lo expuesto aqui no es mas que una pequeña introduccion de un pequeño conjunto de aspectos del campo de
los IDS, hasta que me he cansado de escribir, ya que este campo es tremendamente extenso a la vez que interesante para
su estudio.
Uno de los aspectos que deberian de quedarnos claros es la necesidad de los IDS ya que es
preferible antes de tener que hacer un estudio post mortem de nuestro sistema, hacerlo cuando el atacante esta
empezando a interesarse por nuestra maquina, aunque tambien hay que tener claro que al igual que ocurre con los
firewalls, los IDS no deben de ser mas que uno de nuestros elementos de defensa y prevencion, ya que estos tampoco
suponen la defensa perfecta, aunque si es cierto que nos ayudaran para quitarnos de en medio a la mayoria de los
parasitos, pero sabiendo en todo momento que las personas que le dan a esto noche y dia siempre van un paso por
delante.
Segun van las cosas y por lo que se comenta, es posible que el conjunto de estandares CIDF
sea finalmente engullido por IDWG, pero aun asi todo lo expuesto sobre CIDF sigue siendo valido debido a que pasara a
formar parte de la base de IDWG.
De manera paralela a este tipo de estandares podemos encontrarnos por ejemplo con la
alianza OPSEC la cual augura avances en el campo de la seguridad superando seguramente a otro tipo de iniciativas como
puedan ser CCI ya que en este tipo de asuntos uno de los mayores logros seria la unificacion de esfuerzos, aunque para
ello sea necesaria la total eliminacion del oscurantismo muchas veces existente en estos temas.
"El bambú más alto es el que más se inclina"
[memonix, memonix@softhome.net_QUITAESTO, 2001]
Web oficial: http://www.7a69ezine.org
*EOF*
- DETECCION DE INTRUSOS -
|
