|-----------------------------------------------------------------------------|
  [ 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 dao 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 pequeos 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:

- Comunicaciones entre procesos en una misma maquina

- Comunicaciones entre procesos de distintas maquinas

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 pequeos, pudiendo un atacante forzar un tamao 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 diseo 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 caso
mandando 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 dao 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 pequeos 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 pequeo 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 pequeos 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
tegnologia 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
seran del tamao 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 IDSs.

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 tamao del buffer del host origen.

mss representa el tamao 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 pequea 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.

--==[Ejemplo 1]==--

hacker.net.23 > 172.16.3.33.23: . ack 398615726 win 1028
hacker.net.110 > 172.16.3.33.110: . ack 398615726 win 1028
hacker.net.23 > 172.16.48.99.23: . ack 398615726 win 1028
hacker.net.150 > 172.16.85.122.150: . ack 398615726 win 1028
hacker.net.110 > 172.16.85.101.110: . ack 829647361 win 1028

Esto es una simple exploracion, aunque el atacante al menos esta intentando
pasar un poco desapercibido, no lo esta haciendo todo lo bien que pudiera.
Si una maquina esta viva al recibir un ACK a un puerto abierto o cerrado
deberia de mandar como respuesta un RESET.
Este escaneo tiene varios puntos por los que es facilmente reconocible, por
lo que no debe de suponer ningun problema su deteccion y bloqueo.

--==[Ejemplo 2]==--

truncated-tcp 18 (frag 38524:18@0+)
hacker.net > victima.com: (frag 38524:2@18)
truncated-tcp 18 (frag 8563:18@0+)
hacker.net > victima.com: (frag 8563:2@18)

Aqui un atacante ha fragmentado los encabezamientos TCP, los cuales son de
20 bytes, en varios fragmentos para intentar no ser descubierto.
Este individuo en su intento de escanear un determinado puerto se le ha
ocurrido hacerlo mediante un normal SYN, pero lo ha hecho fragmentando su
peticion, por lo que puede que varios IDS no capten su presencia.
Ha hecho un fragmento de 18 bytes de datos, cuando el encabezamiento minimo
es de 20 bytes, enviando seguidamente los 2 bytes restantes del 
encabezamiento TCP.

--==[Ejemplo 3]==--   
  
hacker.net > 172.16.145.0: (frag 14114:1460@2880+)
hacker.net > 172.16.145.0: (frag 14114:1460@4480+)
hacker.net > 172.16.145.0: (frag 14114:1460@2880+)
hacker.net > 172.16.145.0: (frag 14114:1460@2880+)
hacker.net > 172.16.145.0: (frag 14114:1460@4480+)

Esto es un bonito ejemplo de fragmentacion mutante, para empezar no hay
fragmento inicial, ni tampoco fragmento final, ademas hay muchos valores
que tienen el mismo ID de fragmento compartido a la vez que muchos 
fragmentos tienen el mismo valor.
Todo tiene una respuesta o al menos podemos reflexionar para encontrar una,
la mas convincente para este caso seria que nos encontramos ante una
peticion eco ICMP, las cuales estan restringidas en nuestra red de ejemplo,
por lo tanto el primer fragmento fue bloqueado, pero esta unidad de filtrado
que paro el primer fragmento tiene un grave problema, ya que no tiene estado
por lo que permitio que todos los fragmentos asociados pasaran al interior
de la red, siendo este un problema muy serio a la vez que muy comun.
Y todo esto para que, pues simplemente para conseguir un efectivo DoS, los
fragmentos se dirigen a una direccion de difusion al encontrarnos con una
pila TCP/IP BSD, donde los hosts de destino intentaran ensamblar los 
fragmentos, siendo esta fragmentacion mutante demasiado para el enrutador
que quedo noqueado.
En mi opinion los DoS son seguramente la forma mas sucia de atacar a una
maquina, a la vez que se requieren pocos conocimientos para llevar a cabo
este tipo de ataques, pero como todo tiene su encanto, me atreveria a decir
que este es un buen ejemplo para demostrar que tambien existen DoS en cierta
manera elegantes, refiriendome con ello a que este tipo de ataques tambien
pueden llegar a tener cierto grado de ingenio.
  
--==[Ejemplo 4]==--

hacker.net > 172.16.85.255: icmp: echo request
hacker.net > 172.16.85.0: icmp: echo request
hacker.net > 172.16.86.255: icmp: echo request
hacker.net > 172.16.86.0: icmp: echo request

Este es un escaneo muy ruidoso, consistente en mandar a las direcciones de
difusion una peticion eco ICMP, para intentar averiguar los hosts que estan
vivos, si es que este tipo de trafico se permite.

--==[Ejemplo 5]==--

hacker.net.48369 > victima.com.domain: . win 4286 <wscale 10,nop,mss 265,
_timestamp 1052208436 0,eol> (DF)

[4500 003c 5823 3600 2c06 07bc 0358 0503
68da 0602] ad58 0035 1515 598e 0000 0000_
a000 8200 fa4f 0000 0606 0a01 0703 0208
4f4f 4f4f 0805 0000 0000 0000

Esto nos indica la intervencion de un scanner para obtener huellas digitales
de la maquina objetivo, para poder identificar su sistema operativo lo que
constituye una informacion muy valiosa para el atacante.
En la salida estandar podemos observar que no hay nada que nos indique esta
situacion, pero con la opcion -x conseguimos volcar el datagrama en
hexadecimal, lo que nos sirve para comprobar si tenemos ante nosotros un
indicador TCP falso, al ver la configuracion del byte del indicador TCP.

Solo hay 6 indicadores TCP, por lo que hay otros 2 bits, siendo los 2 bits
de alto nivel o reservados, debiendo ser su valor 0.
Pues bien sabiendo todo esto se abre toda una nueva serie de trafico mutado,
consistente en jugar con estos indicadores.
En este ejemplo debemos fijarnos en el nibble de bajo nivel para examinar el
valor de estos bits.
Si observamos el byte del indicador TCP a000, vemos que todos los bits
estan desactivados, lo cual se conoce como una sesion nula, siendo una
configuracion mutante del indicador TCP. Por lo tanto ese 00 nos esta
indicando que no se ha establecido ningun indicador TCP, cuando un indicador
TCP normal tiene un bit establecido.
Ante este estimulo la victima puede no responder, o en cambio hacerlo con
RESET, lo que serviria al atacante para identificar la pila TCP/IP de la
victima y por tanto su sistema operativo.

--==[Ejemplo 6]==--

hacker1.net.5100 > victima.com.1137: SFP 3241821:3242365(544) win 13234 
urg 55134 (DF)
hacker2.net.18350 > victima.com.22555: SF 8440982:8441538(556) win 10240
(DF)
hacker1.net.8596 > victima.com.555: SFRP 2029978156:2029978684(528) 
ack 2029978156 win 556 urg 556 <[bad opt]> (DF) 
hacker2.net.18350 > victima.com.4713: SFRP 2029994540:2029995068(528) 
ack 2029994540 win 16940 urg 16940 <[bad opt]> (DF)

Esto es un simple ejemplo de un escaneo coordinado, donde como no se 
pretende obtener informacion de ciertos puertos de la maquina victima,
aunque tambien habria que decir que un escaneo de estas caracteristicas
puede hacer que la maquina se venga abajo, siendo otro indicio de esta
actividad la relacion de las marcas de tiempo, la cuales irian bastante
seguidas.

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 IDSs 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 :

Anomalias de Login  - Anomalias de Tiempo

                    - Anomalias de Lugar 

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 contrasea de un usuario de nuestra red, y
este atacante entra en el sistema usando esta contrasea 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 diseado 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:

1. Identificador de version
2. Longitud del gido
3. Time stamp
4. Identificador thread
5. Identificador de clase
6. Identificador del creador
7. 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:

--==[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 aadir 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 diviones que son
las siguientes:

1. 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.

2. 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.


3. 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.

4. Lenguajes 'exploit':

En estos lenguajes se describen las distintas acciones o pasos que han de
tener lugar para que un determinado ataque tenga exito.

5. 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.

6. 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 pequeas 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]==--

Alert Nombre_de_la_alerta (parametros)
{
<exploit>
  <precond>

  requerimientos para lanzar el ataque  

  </precond>
  <attack>

  codigo para lanzar el ataque

  </attack>
  <postcond>

  resultados del ataque una vez que este se ha efectuado

  </postcond>
</exploit>

<detection>
  <detect>
    <events>

    se nombran todos los eventos que tendran lugar durante el ataque

    </events>
    <enchain>

    se relacionan las distintas acciones del ataque con las alertas que iran
    surgiendo durante el mismo, ya que un ataque puede constar de micro
    eventos o acciones que se consideren ofensivas por si solas

    </enchain>
    <context>

    se definen las distintas caracteristicas que definen a cada evento y a
    su correspondiente alarma

    </context>
  </detect>
  <confirm>

  en esta seccion se definen las acciones a seguir para asegurarse de que el
  ataque ha sido real y que no se trataba de una falsa alarma

  </confirm>
  <report>

  aqui se describe la alerta que ha de ser notificada una vez que se ha 
  confirmado el ataque

  </report>
</detection>
<response>

se definen las respuestas automaticas que se pondran en marcha para intentar
mitigar el ataque aun sabiendo que este tipo de respuestas pueden resultar
no demasiado acertadas, por lo que solo se tendra en consideracion a los
usuarios internos a la hora de imponer restricciones

</response>
}

Los metodos usados internamente para llevar a cabo cada accion son una 
simple cuestion de sintaxis.

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 pequea introduccion de un pequeo
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 bambu mas alto es el que mas se inclina"

[memonix, memonix@softhome.net, 2001]                    



*EOF*
