Definir qué 'features' quitar

unintendedbear commented 10 years ago

También @JJ si quiere contribuir. @amorag ya ha dicho esta mañana que, por ejemplo, la hora se podría quitar. A ver si podemos definir cuáles quitar, y se quitan. Lo mismo así hasta puedo cerrar el otro issue porque se puede procesar el fichero si tiene menos.

JJ commented 10 years ago

¿Qué features hay? En todo caso, la extracción de características no es tan directa: hay que hacer un análisis, probarlas en grupos, y a partir de ahí decidir. Una primera aproximación es dejar sólo las que tengan más variabilidad, pero si no sé las que hay...

unintendedbear commented 10 years ago

Pues ahora mismo hay estas:

Attributes: 27 http_reply_code http_method duration_milliseconds content_type_MCT content_type server_or_cache_address time squid_hierarchy bytes url_is_IP url_has_subdomains num_subdomains subdomain5 subdomain4 subdomain3 subdomain2 subdomain1 url_core url_TLD url_has_path folder1 folder2 url_has_file_extension file_extension url_protocol client_address label

Con la última, "label", que define el allow o el deny.

unintendedbear commented 10 years ago

Es más, es que después de ver esta mañana las (calificativo despectivo) reglas que se han obtenido... (y que @amorag debería ver) no sé si preguntarme qué hacer ahora o prenderle fuego a mi vida.

folder2 = fedora AND url_TLD = es AND url_core = uv AND bytes > 77376: allow (366.96)

folder2 = manuales AND url_core = abc AND time = 09:26:10: allow (12.83)

folder2 = manuales AND url_core = abc AND time = 09:44:37: allow (12.83)

time = 09:49:45 AND content_type = text/html: deny (3.08)

time = 08:35:33 AND bytes <= 71108: deny (3.66)

time = 09:45:30 AND content_type_MCT = text: deny (3.66/0.92)

time = 09:32:56 AND url_has_subdomains <= 0: deny (4.28/1.16)

time = 09:34:56 AND duration_milliseconds <= 189: allow (2.7)

... y un etcétera nonsense

Eso sí, 95% de aciertos, yay!

amorag commented 10 years ago

A ver, cosicas que veo (y propongo):

   “time” se puede quitar. Aunque clasificar en base a la hora de conexión puede resultar útil con estos datos (realmente se obtienen reglas fiables en base a ella), en la realidad no se podrá discernir entre que una URL sea permitida o no en base a la hora a la que se intenta acceder a ella. Creo yo.

   “client_address” sería lo mismo, aunque podría resultar útil para, digamos, denegar todo lo que haga una persona si infringe las normas muchas veces, en la práctica, un clasificador no podrá inferir ese tipo de reglas, si hay ALLOWS y DENIES en sus peticiones habrá potencialmente dos tipos de reglas.

   “subdomain5” se puede quitar. Ya se han considerado 4 subdominios y sólo hay 5 registros con subdomain5, que además estarían ‘cubiertos’ por la característica del número de subdominios (de algún modo ya se tendría en cuenta que hay más de 4 subdominios).

Además, yo añadiría algunas más de las que propusimos, que además incluyen numéricas, que siempre son bienvenidas, como:

   Número de parámetros (los que van junto a un ‘&’, creo)

   Algunos de los parámetros (2 o 3) podrían ser interesantes

```
   Longitud completa de la URL
```

Y podríamos pensar en considerar algunas de las ’raras’ que pensamos también (que son numéricas todas):

```
       Número de vocales en la URL
```
```
       Número de consonantes en la URL
```
```
       Número de números en la URL
```

       Número de caracteres no alfanuméricos

       Número de vocales del fichero final (la página a la que se accede)

       Número de consonantes del fichero final (la página a la que se accede)

       Número de números del fichero final (la página a la que se accede)

Nunca se puede decir que una URL maliciosa tendrá un número de consonantes o de vocales, pero puede que la gran mayoría tenga un número de consonantes mucho mayor del habitual, por ejemplo.

Este tipo de cosas las estaba probando Fátima en S2, según me dijo ella.

En todo caso, como dijo JJ lo ideal sería ver y analizar los resultados, ahora que parece que podremos obtenerlos. ;)

Luego podremos decidir con más criterios (quizá eliminar alguna otra) y probar incluyendo también estas nuevas, si os parece.

¿Qué opináis?

**Editado por Paloma porque al no responder en Github, se ha copiado aquí todo lo del mail...

amorag commented 10 years ago

Bueno, en mi opinión la primera puede ser válida.

Las demás, que incluyen el tiempo no.

Pero de esto se trata.

De analizar las reglas obtenidas.

Saca si puedes un listado mayor y también de otras técnicas y mañana lo vemos en la reunión de Geneura. ;)

**Editado again...

unintendedbear commented 10 years ago

Añadidas todas las features que se pidieron aquí ecd3c426eb669210ead391c0eb12c9ad1eaecee1

unintendedbear / TFM

Definir qué 'features' quitar #12