
InspectorLOG v3.6
Tipo contribución/resultado
Herramienta pública (en proceso de publicación)
Descripción
Herramienta SIDS para detección de ataques basados en URI mediante firmas sobre archivos de traza del servicio
Acepta diferentes formatos de trazas y firmas en formato Snort, Nemesida y CRS

Este resultado ha sido parcialmente financiado por MCIN/ AEI/10.13039/501100011033/

Este resultado ha sido parcialmente financiado por FEDER/ Junta de Andalucía
Presentación
Los SIDS más habituales (p.ej. Snort, Suricata) operan sobre tráfico en tiempo real o capturas en formato pcap, no estando disponibles en la actualidad herramientas que apliquen las firmas correspondientes sobre trazas en formato texto. Por tanto, para la detección de ataques a partir de las trazas de HTTP usando ese tipo de firmas ha sido necesario desarrollar una herramienta específica. En sus primeras versiones, se implementaba una funcionalidad básica y únicamente se procesaban firmas en formato Snort. En las sucesivas versiones, sus funcionalidades y capacidades han sido complementadas, pudiendo usar también las firmas públicas usadas por Nemesida y ModSecurity. Inspectorlog únicamente considera el URI y, en su caso, el método contenido en cada petición. Es decir, la detección se realiza únicamente sobre esos campos de los archivos de traza.
En su versión actual (v3.6) se encuentra implementada mediante dos programas: inspectorlog y ms-inspectorlog que aplican, respectivamente, las firmas tipo Snort y Nemesida por un lado y las reglas compatibles con ModSecurity, por otro. Para esto último utiliza la librería libmodsecurity3.
Ambos programas toman como entradas un conjunto de firmas de ataque, en el formato correspondiente, y un archivo de trazas HTTP. A la salida se pueden generar diversos listados conteniendo los registros que han activado alguna regla, junto con detalles sobre las reglas activadas, así como listados de los registros que no activan ninguna de las reglas, es decir, presumiblemente legítimos. Es decir, permite la obtención de listados de peticiones limpias y listados de peticiones de ataque.
La herramienta ha ido evolucionando para posibilitar diferentes formatos de entrada para las trazas y capacidades cada vez más próximas a las de sus correspondientes versiones sobre tráfico real. Sin embargo, dada la naturaleza de la entrada, presenta algunas limitaciones relevantes, especialmente en lo que se refiere a los criterios relacionados con los flujos (flowbits, flow). Esta limitación es insalvable. En la versión actual, los campos de las reglas que determinan las posiciones relativas entre los diferentes componentes de las reglas (p.e. distance) son obviados.
Inspectorlog se encuentra en constante desarrollo, incorporándose nuevos elementos y capacidades a medida que va evolucionando. Ha sido validada con resultados satisfactorios sobre varios conjuntos de trazas, tanto públicas como privadas, pudiendo explicarse las pocas discrepancias existentes en base a las limitaciones descritas.
Funcionamiento
El funcionamiento de InspectorLog se basa en la búsqueda de las firmas asociadas a cada regla en las URI a partir de la comparación de cadenas, incluyendo la búsqueda de expresiones regulares. Para ello se utiliza una arquitectura modular (Fig. 1) en la que el núcleo es el módulo de detección, cuya función es aplicar secuencialmente el conjunto de reglas seleccionadas a cada una de las peticiones en las trazas.

La herramienta toma como entrada un archivo de traza y un conjunto de reglas (firmas) y genera a la salida listados con las URI consideradas legítimas y con las URI de ataque. El procesamiento realizado es:
– Inicialización: Durante la inicialización de la herramienta se leen una a una las reglas en los archivos correspondientes. Se extraen los diferentes campos de cada regla (módulo parser reglas) y se filtran para extraer únicamente las que afectan al servicio HTTP (módulo filtrado reglas). En función del tipo de formato para las trazas, se filtran también los métodos no considerados por la herramienta. Finalmente, se genera una base de datos de firmas (bloque firmas) a partir de la extracción de los patrones y condiciones a buscar (módulo extracción patrones).
– Análisis: Una vez inicializadas las reglas y parámetros de búsqueda, se leen uno a uno los registros en el archivo de traza, extrayendo los campos de interés de entre los disponibles según el formato de entrada (módulo parser trazas). En función de las opciones activas, se filtran las peticiones por código de respuesta (CR<300 o CR<400) (módulo filtrado CR). A continuación se normalizan los URI (módulo normalización URI), especialmente en relación al denominado percent encoding. Esta normalización se realiza de forma iterativa, de tal forma que en la primera iteración no se realiza ninguna modificación y en cada iteración posterior se decodifican las secuencias de percent encoding. El proceso se repite mientras existan caracteres codificados. Cada una de las iteraciones genera una petición a la salida que es procesada por el detector (módulo detección), que aplica las firmas una a una en busca de los patrones establecidos en cada una. En caso de detección en alguna de las iteraciones, se genera un registro de ataque en el que, opcionalmente, se incluye información sobre la detección (firmas activadas). En caso contrario se considera que el registro es legítimo y se añade al listado correspondiente.
La normalización de URI es necesaria, a pesar de que el RFC 3986 establece un formato estándar para la representación de los caracteres, porque son muchos los sistemas que no tienen en cuenta esta recomendación. Adicionalmente, algunos ataques usan la representación mediante percent encoding como método de ocultación. Es más, hemos constatado que se hace de forma iterativa (se usa %25 para codificar el símbolo ‘%’ y ocultar sucesivas codificaciones). Por otra parte, durante el análisis de las reglas Talos y ETOpen hemos detectado incoherencias en relación al uso de percent encoding. Para solucionar estos problemas hemos establecido, como se ha indicado anteriormente, un procesamiento opcional que, en caso de detectar el uso de percent encoding en un URI, aplica todas las reglas, procede a decodificar los caracteres y vuelve a aplicar todas las reglas, repitiéndose el proceso mientras existan caracteres codificados.
Una opción similar se contempla para el caso de mayúsculas/minúsculas en las reglas y en la codificación de los caracteres. En este caso, al activar la opción correspondiente se convierten todos los caracteres a minúscula para el procesamiento.
Los campos de las reglas considerados para el análisis, en el caso de reglas en formato Snort, son: content, pcre, http_uri, http_method, dsize, urilen y nocase. De cada regla se almacenan también los campos msg, reference, classtype y sid para mostrarlos a la salida, según las opciones establecidas, con cada activación de la regla en el informe de detección correspondiente.
La operación de la herramienta ms-inspectorlog se basa en la librería libmodsecurity3, que incorpora funciones para la carga de las reglas y la detección. Por tanto, el diagrama funcional se simplifica. En este caso, el bloque de inicialización corresponde a la llamada a la función correspondiente de la librería. De la misma forma, el módulo de detección se encuentra implementado en dicha librería y se ejecuta sobre cada petición. En este caso no se aplica el módulo de normalización de URI, por estar incorporado el procesamiento asociado en la función de la librería.
Uso y formatos
Analiza archivos de trazas conteniendo URIs en los formatos de entrada definidos y aplica las reglas contenidas en los archivos del directorio de reglas (snort) o el archivo indicado (nemesida), informando sobre las uris y alertas asociadas.
COMANDO:
inspectorlog -l logFile [-t <list|elist|apache|wellness|uri|telist>] [-b (labeled uris)] -a attack_output [-r ruleDir(snort)] [-m rulefile(nemeside)] [-o clean_log_output] [-f (raw_attacks)] [-n (nocase)] [-e (extended_alerts)] [-w (encoding warnings)] [-c (response code filtering)] [-x (strict response code filt)]
PARÁMETROS:
-l logFile | Archivo de traza a procesar |
-t <list|apache|wellness|uri| elist| telist> | (opcional) Formato del archivo de traza. Por defecto, se usa formato apache. |
-b | Se usan identificadores (labels) para cada petición en archivo de traza. |
-a attack_output | Archivo de salida (ataques). Por defecto en formato U2URI. |
-r ruleDir(snort) | (opcional) Directorio con los archivos de reglas de Snort. Se procesan TODOS los archivos en el directorio. |
-m rulefile(nemeside) | (opcional) Archivo de reglas Nemesida. |
-o clean_log_output | (opcional) Archivo de salida con los elementos de la traza que no han generado alertas (filtrado, en su caso). Formato de salida idéntico al de entrada. |
-f | (opcional) Generar el listado de ataques sin información de detección. El formato de salida será idéntico al de entrada. |
-n | (opcional) Aplicar las reglas ignorando mayúsculas y minúsculas en todos los casos. En caso contrario, se usará la regla de acuerdo a la etiqueta «nocase» existente o al switch de la expresión regular correspondiente. |
-e | (opcional) Activar información extendida de las alertas (se incluye mensaje de alerta y sid). Por defecto sólo se indica el sid. |
-w | (opcional) Generar avisos cuando no se puedan decodificar caracteres percent encoded. |
-c | (opcional) Filtrado por código de respuesta para CR >=400. |
-x | (opcional) Filtrado estricto por código de respuesta (para CR >=300). |
Analiza archivos de trazas conteniendo URIs en los formatos de entrada definidos y aplica reglas compatibles con ModSecurity (p.e. CRS), informando sobre las uris y alertas asociadas.
COMANDO:
ms-inspectorlog -l logFile [-t<list|elist|apache|wellness|uri|telist> <list|elist|apache|wellness|uri|telist>] [-b (labeled uris)] -a attack_output -r modsecurity_conf_file [-o clean_log_output] [-e (extended_alerts)] [-w (encoding warnings)] [-c (response code filtering)] [-x (strict response code filt)] [-d detailed_log_output]
PARÁMETROS:
-l logFile | Archivo de traza a procesar |
-t <list|apache|wellness|uri|elist|telist> | (opcional) Formato del archivo de traza. Por defecto, se usa formato apache. |
-b | Se usan identificadores (labels) para cada petición en archivo de traza. |
-a attack_output | Archivo de salida (ataques). Por defecto en formato U2URI. |
-r modsecurity_conf_file | Archivo de configuración de ModSecurity. |
-o clean_log_output | (opcional) Archivo de salida con los elementos de la traza que no han generado alertas (filtrado, en su caso). Formato de salida idéntico al de entrada. |
-e | (opcional) Activar información extendida de las alertas (se incluye mensaje de alerta y sid). Por defecto sólo se indica el sid. |
-w | (opcional) Generar avisos cuando no se puedan decodificar caracteres percent encoded. |
-c | (opcional) Filtrado por código de respuesta para CR >=400. |
-x | (opcional) Filtrado estricto por código de respuesta (para CR >=300). |
-d detailed_log_output | (opcional) Archivo de traza de libModSecurity. |
Formatos
Archivos de trazas
Los formatos disponibles en la versión actual para el archivo de traza son:
– apache: Formato estándar de Apache.
– wellness: Variante del formato Apache con datos adicionales.
– list: Lista de URIs sin método ni campos adicionales.
– elist: Lista de uris con 5 campos: petición uri protocolo codigo_respuesta tamaño_respuesta.
– telist: Idem elist con campos delimitados por tabuladores.
– uri: La primera línea contiene el número de uris en el archivo. Cada línea incluye la longitud y el uri.
Ejemplos
/* TIPO APACHE (12 campos) */ IP USERIDENTIFIER USERID [TIMESTAMP DIF] «METHOD URI PROTOCOL» RESP_CODE RESP_SIZE «-» «REFERER» 172.16.16.210 – – [02/May/2017:12:21:07 +0200] «GET http://127.0.0.1/finger HTTP/1.1» 404 289 «-» «Wget/1.17.1 (linux-gnu)» /* TIPO WELLNESS (10 campos) */ TIMESTAMP NODE PLACE IP:PORT {server} «METHOD URI VER» RESP_CODE RESP_SIZE 2017-06-22T06:25:15.356441+02:00 A-SQU-BAL-HAP03 haproxy[5518]: 10.128.2.64:46469 {www.wtelecom.es} «GET / HTTP/1.1» main_http_frontend WT_www_be/A-WTE-INF-WEB03 /* TIPO LIST */ URI /2003/padron.html /* TIPO ELIST (campos delimitados por espacios) / TELIST (campos delimitados por tabuladores) */ METHOD URI PROTOCOL» RESP_CODE RESP_SIZE GET /ingenieros/node HTTP/1.1″ 200 26091 /* TIPO URI (1a linea con numero de uris) */ 17 /2003/padron.html
|
Archivos de reglas
Se consideran tres formatos:
– Reglas estándar de Snort (Talos/VRT/suricata/ETOpen)
– Reglas de nemesida (archivo de texto, descargado desde https://rlinfo.nemesida-security.com/)
– Reglas y archivos de configuración en el formato definido por ModSecurity (CRS)
Reglas formato SNORT |
Se procesan las reglas en el formato estándar de Snort (Talos/VRT/suricata/ET). Sólo se consideran los siguientes campos para la aplicación de las reglas: http_method, http_uri, content, pcre, dsize, urilen, nocase . Los campos msg, reference, classtype, sid se procesan a efectos de referencia e indexación. Los restantes campos son ignorados. |
Reglas formato Nemesida |
El archivo de reglas de Nemesida (Nemesida Community Edition) es un archivo de texto obtenido a partir de https://rlinfo.nemesida-security.com/ en el que se eliminan las líneas que no contienen reglas y el formato html. El resultado presenta el siguiente formato: RID TIPO FIRMA ETIQUETA SCORE ZONA_COMPARACIÓN 1 RL nwaftest Other 12 BODY|URL|ARGS|HEADERS donde TIPO puede ser RL, RLx, WL o WLx para indicar una regla de lista negra (firma de ataque), de lista negra usando una expresión regular, lista blanca (petición legítima en todos los casos) o lista blanca usando una expresión regular, respectivamente. Para posibilitar la compatibilidad con las reglas en formato Snort, se asigna un SID a cada regla Nemesida a partir del RID sumándole 3000000. |
Formato de salida (U2URI)
La salida relativa a los ataques se realiza a un archivo y contiene información una primera sección con información sobre las reglas cargadas y su procesamiento. A continuación, cada línea corresponde a un registro clasificado como ataque con el siguiente formato:
Packet [numero_linea][etiqueta]\tUri [uri_analizado]\tNattacks [num_alertas]\t[info_alerta_1]\t … \t[info_alerta_n]
Los campos se encuentran delimitados por tabuladores y la [etiqueta] únicamente estará presente si existe en el archivo de traza de entrada.
La información sobre cada alerta depende de la opción -e (extendida), incluyendo siempre el SID de la regla activada y, opcionalmente, el mensaje asociado a la misma.
Finalmente, se incluye una línea con información sobre el número de registros (procesados, con alertas y número de alertas).
Las líneas que no contienen información relativa a un paquete comienzan por el carácter ‘#’ para facilitar su filtrado.
Ejemplo
# inspectorlog v3.6.0.1 #—– Initializing Rules (SNORT) ——————— # Rules directory : «/data/uri-data/biblio-ds/tmp/reglas» # Opening SNORT rule file ./tmp/reglas/http_uri-er-20220224-m2.rules… done # Rules: read [5918], erroneous [8], URI [5910] #—– Statistics (SNORT) —————————— # Read [9514] Snort rules, [9500] http-related, [13] with errors #—– Analysis results —————————- # Alerts & signatures generated from: /data/bin/inspectorlog -l raw-logs/apachelog-20170101.ltxt -t telist -b -r ./tmp/reglas/ -a rev3/attack-uris/apachelog-20170101-attacks.u2uri -n Packet [629][01-01-A000629] Uri [/politecnica/sites/all/modules/calendar/css/calendar_multiday.css?o8r51f] Nattacks [1] Signatures [882] Packet [763][01-01-A000763] Uri [/sites/wdn4.mu.xs/files/Biblioteca_Universitaria/calendario_web_sabados_2015-16.jpg] Nattacks [1] Signatures [882] Packet [805][01-01-A000805] Uri [/comunicacion/sites/all/modules/calendar/css/calendar_multiday.css?o86dyb] Nattacks [1] Signatures [882] # N. packets [35934], [44] with alerts, N. Alerts [49] |
Documentos técnicos / recursos
https://gitlab.com/neus_cslab/inspectorlogPublicaciones
Díaz-Verdejo, J.; Muñoz-Calle, J.; Alonso, R. Estepa; Alonso, A. Estepa
InspectorLog : A New Tool for Offline Attack Detection over Web Log Proceedings Article
En: Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), pp. 692–697, 2024, ISBN: 9789897587092.
@inproceedings{Diaz-Verdejo2024a,
title = {InspectorLog : A New Tool for Offline Attack Detection over Web Log},
author = {J. Díaz-Verdejo and J. Muñoz-Calle and R. Estepa Alonso and A. Estepa Alonso},
doi = {10.5220/0012764000003767},
isbn = {9789897587092},
year = {2024},
date = {2024-01-01},
urldate = {2024-01-01},
booktitle = {Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024)},
number = {Secrypt},
pages = {692–697},
abstract = {InspectorLog is a novel tool for offline analysis of HTTP logs. The tool processes web server logs to identify attacks using diverse rule sets, focusing primarily on the URI field. It is compatible with standard rule formats from systems such as Snort, Nemesida, and ModSecurity. This paper describes InspectorLog functionalities, architecture and applications to the scientific community. We also experimentally validate InspectorLog by comparing its detection power with that of the IDS from which rules are taken. Inspector log fills a gap in available tools in cybersecurity practices in forensic analysis, dataset sanitization, and signature tuning. Future enhancements are planned to support additionalWeb Application Firewalls (WAFs), new rule types, and HTTP protocol methods, aiming to broaden its scope and utility in the ever-evolving domain of network security.},
keywords = {},
pubstate = {published},
tppubtype = {inproceedings}
}