PRUEBAS REALIZADAS CON 10 ATRIBUTOS

El primer acercamiento se hizo definiendo 10 atributos, donde un atributo corresponde a un elemento de la cadena, con ayuda de una ventana deslizante en uno. Para este tipo de prueba se aplico la ventana deslizante en uno y la función de normalización generando 862 datos de entrenamiento, se generaron de la siguiente manera. Se tiene el siguiente requerimiento:

http://localhost/scripts../afwinnt/system32/cmd.exe?/c+dir

En este caso las cadenas “cmd” y “exe” son cadenas alfanuméricas definidas por el usuario ya que no son propias de una aplicación Web en particular si no de un sistema operativo. Por lo tanto la función de normalización no las transforma en el símbolo @ dejándolas intactas.

@../@/@/@.@?/cmd.exe+@

Una vez aplicada la función de normalización al requerimiento tenemos 22 caracteres, ahora aplicamos la ventana deslizante para fijarlo a 10 atributos. La ventana se va recorriendo un lugar hasta recorrer todos los caracteres del requerimiento como se muestra en la figura 4.1.

@ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @

@ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @ @ . . / @ / @ / @ . @ ? / c m d . e x e + @

Figura 4.1 Ventana deslizante en uno, 10 atributos

Con este tipo de tratamiento mostrado en la figura 4.1 siempre se tendrán 10 atributos y de esta manera el algoritmo ID3 puede generar el árbol a partir de los datos normalizados. El impacto negativo es que en lugar de tener una sola cadena (refiriéndonos al requerimiento original) se tienen 13 cadenas a ser analizadas, aumentando el tiempo de cómputo al generar el árbol de decisión. En la figura 4.2 se muestra un ejemplo de los atributos y sus clases.

A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 Clases & @ / . . c m d . @ Injection ‘ ( @ . . . / @ . + Injection . & ? . / . . / d i Injection / @ ? @ @ @ . c g I Normal ; = ? @ @ @ @ @ @ @ Normal \? [ @ / @ / @ @ @ @ Normal @ . . . / . . / @ . PATH _ @ @ / . . / / . . PATH = ? . ( “ @ “ ) . @ XSS : ( “ @ “ ) @ . [ @ XSS ‘ \? @ \? 1 = = 1 - @ SQL ‘ \? group \? @ \? \? \? \? \? SQL ‘ \? - - @ \? \? \? \? \? SQL

Los datos donde se definen las clases y las instancias de los atributos son guardados en el archivo llamado “datos.names” siguiendo el mismo formato que utiliza C4.5 [30]. En la figura 4.2 se muestra parte del contenido del archivo.

Figura 4.2. Contenido del archivo “datos.names”

La primera línea del archivo “datos.names” mostrada en la figura 4.2 se refiere a las clases formadas por la suma de las instancias de los atributos, es decir:

A1 + A2 + A3 +....+ A10 = INJECTION ó NORMAL ó PATH ó SQL ó XSS.

@ + ? + . + / + . . . + ) = Injection ó Normal ó Path ó Sql ó XSS

Los datos de entrenamiento son guardados en el archivo “datos.data”, siguiendo el mismo formato de C4.5 [30]. La figura 4.2 muestra parte del contenido del archivo.

Figura 4.2 Contenido del archivo “datos.data” INJECTION, NORMAL, PATH, SQL, XSS.

A1: &,',\.,/,;,\?,@,_,\|,\:,=,a,,b,c,t,-,[,\\,e,h,j,p,s,t,x,",%,*,],\\307,\\302,\\301,\\257,\\243,+,f,i,n,o,(,`,~,<.

A2: @,(,b,E,e,',;,\?,&, ,%,\|,\.,/,-,_,+,=,",`,t,a,g,\\,c,e,p,[,],s,x,h,0,o,*,\\257,\\243,\\302,n,i,f,union,),>,j,<.

A3: =,@,/,a,X,x,&,\.,;, ,\|,-,0,_,=,cgi,(,b,c,E,e,",>,%,',`,+,t,i,g,h,d,p,[,*,],\\,n,,f,group,having, ,<,\:,),OR,UNION,s.

… …

A10: ;,@,\.,\\,\|,=,`,/,i,\:,",_,+,<,&,t,x,e,p,h,,-, d,n,%,\\257,a,',\\307,b,\\200,\\243,\\302,>,(,<,),\?.

&,@,=,",;,@, ,',',;,INJECTION &,@,=,;,@, ,/,@,/,@,INJECTION ... /,@,-,@,/,\.,@,/,@,/,NORMAL /,@,-,@,/,@,\.,@,/,@,NORMAL ... \.,\.,@,/,\.,\.,/,\.,\.,/,PATH \.,\.,@,/,/,\.,\.,/,\.,\.,PATH ... ;,@,(,',@,',),;,&,@,XSS ;,<,/,@,>,&,@,=,@,&,XSS ... @, ,1,=,=,1,-,@,SQL ', ,OR, ,1,=,=,1,-,@,SQL ...

Para obtener el árbol de decisión, ID3 toma los dos archivos mostrados en las figuras 4.1 y 4.2. En ocasiones los requerimientos cuentan con espacios en blanco (caracteres NULL). Estos caracteres faltantes son sustituidos por el símbolo “?”, para no generar confusiones con el mismo símbolo que pudiera venir en un requerimiento normal, a éste se le agrega el símbolo “\” quedando como un solo carácter “\?”. Consideremos la siguiente cadena normalizada:

@?@=@&@=../../@

En este caso el símbolo “?” proviene de un requerimiento normal, por lo tanto ID3 lo procesaría como: “\?”, así ya no hay problema cuando se haga la sustitución de los espacios en blanco por el símbolo “?”.

En la figura 4.3 se muestra una parte del árbol generado por ID3.

: / = ... ... @ ( \? [ : .... ... ... ... ... “ @ . = ) ... ...

Figura 4.3 Árbol parcial generado por ID3 con 10 atributos (la altura del árbol real es de 1756)

A4

A2 A6 A9

A7 A10 A5

El algoritmo ID3 encontró que el atributo ganador es A4, y de ahí empieza a evaluar los diferentes nodos de decisión hasta llegar a clasificar todos las instancias de los atributos. La clasificación no tuvo errores, la lógica del árbol resultante es clara ya que al seguir una rama en particular se llega a la clasificación deseada.

4.6.1.1 Prueba de validación

La siguiente prueba fue para validar la veracidad y la predicción del árbol de decisión resultante con 10 atributos. La validación se hizo contra 100 datos que no estuvieron incluidos en el archivo de entrenamiento “datos.data”.

Para esta fase de prueba se programó el algoritmo ID3 para que recibiera un archivo extra donde se guardarán datos desconocidos para ID3. Esta técnica de guardar datos nuevos en un archivo es tomada de la versión de ID3 programada por Ross Quinlan C4.5 [29]. El archivo se llama “datos.test”, donde son guardados todos los datos nuevos para probar el algoritmo ID3 programado para este proyecto. El archivo conserva el mismo formato que el archivo “datos.data”. Los resultados son los siguientes:

Detección:

Cadenas Anómalas Cadenas normales Total

Número de patrones 68 32 100

Detectados 71 29 100

Figura 4.4 Tabla de detección con 10 atributos

De la figura 4.4 se detectaron 71 datos como cadenas anómalas de 68 cadenas anómalas reales, es decir que 3 datos que en realidad fueron cadenas normales ID3 las clasificó como cadenas anómalas. De las 32 cadenas normales, fueron detectadas 29 ya que 3 fueron clasificadas como anómalas.

Clasificación:

INJECTION 31 25 NORMAL 32 29 SQL 14 14 PATH 13 22 XSS 10 10 Total 100 100

Figura 4.5 Tabla de clasificación con 10 atributos

En la figura 4.5 se muestra la clasificación arrojada por ID3. De 31 cadenas del tipo INJECTION ID3 clasificó correctamente 25; de 32 cadenas del tipo NORMAL ID3 clasificó correctamente 29; de 14 cadenas del tipo SQL ID3 no tuvo problemas en clasificar las 14 cadenas correctamente; de 13 cadenas del tipo PATH ID3 clasificó 22 cadenas como PATH; y de 10 cadenas del tipo XSS ID3 no tuvo problemas en clasificar las 10 cadenas correctamente.

Tras un análisis más detallado, observamos que en las cadenas del tipo INJECTION y PATH existen similitudes; es por eso que ID3 clasificó 9 cadenas que originalmente eran del tipo INJECTION como PATH. Veamos el siguiente ejemplo de cadenas normalizadas.

Cadena normalizada manipulación del PATH

@../@/@/@.@ Cadena normalizada INJECTION

@..@/@/cmd.exe+@

Si observamos ambas cadenas, los primeros 4 atributos son bastante parecidos. Debido a estas similitudes ID3 los clasifica incorrectamente. Este tipo de errores si lo vemos en un ambiente real no es tan importante ya que ID3 está clasificando a estas cadenas como anómalas y ese es uno de los principales objetivos de los IDS’s.