{"id":916,"date":"2023-03-25T12:12:55","date_gmt":"2023-03-25T11:12:55","guid":{"rendered":"http:\/\/localhost\/neus-cslab\/?page_id=916"},"modified":"2024-12-11T12:39:49","modified_gmt":"2024-12-11T11:39:49","slug":"inspectorlog","status":"publish","type":"page","link":"https:\/\/dtstc.ugr.es\/neus-cslab\/recursos\/inspectorlog\/","title":{"rendered":"Inspectorlog"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\n\t\t\t\tProgreso\t\t\t<\/span>\n\t\t\n\t\t
\n\t\t\t
\n\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t98%<\/span>\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

InspectorLOG v3.6<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\n\t\t\t\t\t\t
\n\t\t\t\t\n\t\t\t\t<\/i>\t\t\t\t<\/span>\n\t\t\t<\/div>\n\t\t\t\n\t\t\t\t\t\t
\n\n\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tTipo contribuci\u00f3n\/resultado\t\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/h3>\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\tHerramienta p\u00fablica (en proceso de publicaci\u00f3n)\t\t\t\t\t<\/p>\n\t\t\t\t\n\t\t\t<\/div>\n\t\t\t\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\n\t\t\t\t\t\t
\n\t\t\t\t\n\t\t\t\t<\/i>\t\t\t\t<\/span>\n\t\t\t<\/div>\n\t\t\t\n\t\t\t\t\t\t
\n\n\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tDescripci\u00f3n\t\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/h3>\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\tHerramienta SIDS para detecci\u00f3n 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
\t\t\t\t\t<\/p>\n\t\t\t\t\n\t\t\t<\/div>\n\t\t\t\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t
\"\"<\/figure>

Este resultado ha sido parcialmente financiado por MCIN\/ AEI\/10.13039\/501100011033\/<\/p><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t
\"\"<\/figure>

Este resultado ha sido parcialmente financiado por FEDER\/ Junta de Andaluc\u00eda<\/p><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Presentaci\u00f3n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Los SIDS m\u00e1s habituales (p.ej. Snort, Suricata) operan sobre tr\u00e1fico 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\u00f3n de ataques a partir de las trazas de HTTP usando ese tipo de firmas ha sido necesario desarrollar una herramienta espec\u00edfica. En sus primeras versiones, se implementaba una funcionalidad b\u00e1sica y \u00fanicamente se procesaban firmas en formato Snort<\/em>. En las sucesivas versiones, sus funcionalidades y capacidades han sido complementadas, pudiendo usar tambi\u00e9n las firmas p\u00fablicas usadas por Nemesida<\/em> y ModSecurity<\/em>. Inspectorlog \u00fanicamente considera el URI<\/strong> y, en su caso, el m\u00e9todo<\/strong> contenido en cada petici\u00f3n. Es decir, la detecci\u00f3n se realiza \u00fanicamente sobre esos campos de los archivos de traza.<\/p>

En su versi\u00f3n actual (v3.6) se encuentra implementada mediante dos programas: inspectorlog<\/strong> y ms-inspectorlog <\/strong>que aplican, respectivamente, las firmas tipo Snort<\/em> y Nemesida<\/em> por un lado y las reglas compatibles con ModSecurity<\/em>, por otro. Para esto \u00faltimo utiliza la librer\u00eda libmodsecurity3<\/em>.
<\/strong><\/p>

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,\u00a0 as\u00ed como listados de los registros que no activan ninguna de las reglas, es decir, presumiblemente leg\u00edtimos. Es decir, permite la obtenci\u00f3n de listados de peticiones limpias<\/strong> y listados de peticiones de ataque<\/strong>.<\/p>

La herramienta ha ido evolucionando para posibilitar diferentes formatos de entrada<\/strong> para las trazas y capacidades cada vez m\u00e1s pr\u00f3ximas a las de sus correspondientes versiones sobre tr\u00e1fico 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<\/em>, flow<\/em>). Esta limitaci\u00f3n es insalvable. En la versi\u00f3n actual, los campos de las reglas que determinan las posiciones relativas entre los diferentes componentes de las reglas (p.e.<\/em> distance<\/em>) son obviados.<\/p>

Inspectorlog se encuentra en constante desarrollo, incorpor\u00e1ndose nuevos elementos y capacidades a medida que va evolucionando. Ha sido validada<\/strong> con resultados satisfactorios sobre varios conjuntos de trazas, tanto p\u00fablicas como privadas, pudiendo explicarse las pocas discrepancias existentes en base a las limitaciones descritas.\u00a0<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Funcionamiento<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

El funcionamiento de InspectorLog<\/strong> se basa en la b\u00fasqueda de las firmas asociadas a cada regla en las URI a partir de la comparaci\u00f3n de cadenas, incluyendo la b\u00fasqueda de expresiones regulares.\u00a0 Para ello se utiliza una arquitectura modular (Fig. 1) en la que el n\u00facleo es el m\u00f3dulo de detecci\u00f3n, cuya funci\u00f3n es aplicar secuencialmente el conjunto de reglas seleccionadas a cada una de las peticiones en las trazas.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t
Fig. 1: Diagrama de bloques de InspectorLog<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

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\u00edtimas y con las URI de ataque. El procesamiento realizado es:<\/p>\n

– Inicializaci\u00f3n:\u00a0 <\/i>Durante la inicializaci\u00f3n de la herramienta\u00a0 se leen una a una las reglas en los archivos correspondientes. Se extraen los diferentes campos de cada regla (m\u00f3dulo parser reglas<\/em>) y se filtran para extraer \u00fanicamente las que afectan al servicio HTTP (m\u00f3dulo filtrado reglas<\/em>). En funci\u00f3n del tipo de formato para las trazas, se filtran tambi\u00e9n los m\u00e9todos no considerados por la herramienta.\u00a0 Finalmente, se genera una base de datos de firmas (bloque firmas<\/em>) a partir de la extracci\u00f3n de los patrones y condiciones a buscar (m\u00f3dulo extracci\u00f3n patrones<\/em>).<\/p>\n

– An\u00e1lisis<\/i>: Una vez inicializadas las reglas y par\u00e1metros de b\u00fasqueda, se leen uno a uno los registros en el archivo de traza, extrayendo los campos de inter\u00e9s de entre los disponibles seg\u00fan el formato de entrada (m\u00f3dulo parser trazas<\/em>). En funci\u00f3n de las opciones activas, se filtran las peticiones por c\u00f3digo de respuesta (CR<300 o CR<400) (m\u00f3dulo filtrado CR<\/em>). A continuaci\u00f3n se normalizan los URI (m\u00f3dulo normalizaci\u00f3n URI<\/em>), especialmente en relaci\u00f3n al denominado percent encoding<\/i>. Esta normalizaci\u00f3n se realiza de forma iterativa, de tal forma que en la primera iteraci\u00f3n no se realiza ninguna modificaci\u00f3n y en cada iteraci\u00f3n\u00a0 posterior se decodifican las secuencias de percent encoding<\/em>. El proceso se repite mientras existan caracteres codificados. Cada una de las iteraciones genera una petici\u00f3n a la salida que es procesada por el detector (m\u00f3dulo detecci\u00f3n<\/em>), que aplica las firmas una a una en busca de los patrones establecidos en cada una. En caso de detecci\u00f3n en alguna de las iteraciones, se genera un registro de ataque en el que, opcionalmente, se incluye informaci\u00f3n sobre la detecci\u00f3n (firmas activadas). En caso contrario se considera que el registro es leg\u00edtimo y se a\u00f1ade al listado correspondiente.<\/p>\n

La normalizaci\u00f3n de URI es necesaria, a pesar de que el RFC 3986 establece un formato est\u00e1ndar para la representaci\u00f3n de los caracteres, porque son muchos los sistemas que no tienen en cuenta esta recomendaci\u00f3n. Adicionalmente, algunos ataques usan la representaci\u00f3n mediante percent encoding<\/em> como m\u00e9todo de ocultaci\u00f3n. Es m\u00e1s, hemos constatado que se hace de forma iterativa (se usa %25 para codificar el s\u00edmbolo ‘%’ y ocultar sucesivas codificaciones). Por otra parte, durante el an\u00e1lisis de las reglas Talos y ETOpen hemos detectado incoherencias en relaci\u00f3n al uso de percent encoding<\/em>. Para solucionar estos problemas hemos establecido, como se ha indicado anteriormente, un procesamiento opcional que, en caso de detectar el uso de percent encoding<\/em> en un URI, aplica todas las reglas, procede a decodificar los caracteres y vuelve a aplicar todas las reglas, repiti\u00e9ndose el proceso mientras existan caracteres codificados.<\/p>\n

Una opci\u00f3n similar se contempla para el caso de may\u00fasculas\/min\u00fasculas en las reglas y en la codificaci\u00f3n de los caracteres. En este caso, al activar la opci\u00f3n correspondiente se convierten todos los caracteres a min\u00fascula para el procesamiento.<\/p>\n

Los campos de las reglas considerados para el an\u00e1lisis, en el caso de reglas en formato Snort, son: content, pcre, http_uri, http_method, dsize, urilen<\/em> y nocase<\/em>. De cada regla se almacenan tambi\u00e9n los campos msg, reference, classtype<\/em> y sid <\/em>para mostrarlos a la salida, seg\u00fan las opciones establecidas, con cada activaci\u00f3n de la regla en el informe de detecci\u00f3n correspondiente.<\/p>\n

La operaci\u00f3n de la herramienta ms-inspectorlog<\/strong> se basa en la librer\u00eda libmodsecurity3<\/strong><\/em>, que incorpora funciones para la carga de las reglas y la detecci\u00f3n. Por tanto, el diagrama funcional se simplifica. En este caso, el bloque de inicializaci\u00f3n corresponde a la llamada a la funci\u00f3n correspondiente de la librer\u00eda. De la misma forma, el m\u00f3dulo de detecci\u00f3n se encuentra implementado en dicha librer\u00eda y se ejecuta sobre cada petici\u00f3n. En este caso no se aplica el m\u00f3dulo de normalizaci\u00f3n de URI, por estar incorporado el procesamiento asociado en la funci\u00f3n de la librer\u00eda.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Uso y formatos<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tInspectorlog<\/strong><\/span>\n

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<\/em>) o el archivo indicado (nemesida<\/em>), informando sobre las uris y alertas asociadas.<\/p>\n

COMANDO:<\/p>\n

\u00a0inspectorlog -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)]<\/p>\n

PAR\u00c1METROS:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
-l logFile<\/td>\nArchivo de traza a procesar<\/td>\n<\/tr>\n
-t <list|apache|wellness|uri| elist| telist><\/td>\n(opcional) Formato del archivo de traza. Por defecto, se usa formato apache<\/span>.<\/td>\n<\/tr>\n
-b<\/td>\nSe usan identificadores (labels) para cada petici\u00f3n en archivo de traza.<\/td>\n<\/tr>\n
-a attack_output<\/td>\nArchivo de salida (ataques). Por defecto en formato U2URI.<\/td>\n<\/tr>\n
-r ruleDir(snort)<\/td>\n(opcional) Directorio con los archivos de reglas de Snort. Se procesan TODOS los archivos en el directorio.<\/td>\n<\/tr>\n
-m rulefile(nemeside)<\/td>\n(opcional) Archivo de reglas Nemesida.<\/td>\n<\/tr>\n
-o clean_log_output<\/td>\n(opcional) Archivo de salida con los elementos de la traza que no han generado alertas (filtrado, en su caso). Formato de salida id\u00e9ntico al de entrada.<\/td>\n<\/tr>\n
-f<\/td>\n(opcional) Generar el listado de ataques sin informaci\u00f3n de detecci\u00f3n. El formato de salida ser\u00e1 id\u00e9ntico al de entrada.<\/td>\n<\/tr>\n
-n<\/td>\n(opcional) Aplicar las reglas ignorando may\u00fasculas y min\u00fasculas en todos los casos. En caso contrario, se usar\u00e1 la regla de acuerdo a la etiqueta \u00abnocase<\/em>\u00bb existente o al switch de la expresi\u00f3n regular correspondiente.<\/td>\n<\/tr>\n
-e<\/td>\n(opcional) Activar informaci\u00f3n extendida de las alertas (se incluye mensaje de alerta y sid<\/em>). Por defecto s\u00f3lo se indica el sid<\/em>.<\/td>\n<\/tr>\n
-w<\/td>\n(opcional) Generar avisos cuando no se puedan decodificar caracteres percent encoded<\/em>.<\/td>\n<\/tr>\n
-c<\/td>\n(opcional) Filtrado por c\u00f3digo de respuesta para CR >=400.<\/td>\n<\/tr>\n
-x<\/td>\n(opcional) Filtrado estricto por c\u00f3digo de respuesta (para CR >=300).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nms-inspectorlog<\/strong><\/span>\n

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.<\/p>\n

COMANDO:<\/p>\n

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)]\u00a0 [-x (strict response code filt)] [-d detailed_log_output]<\/p>\n

PAR\u00c1METROS:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
-l logFile<\/td>\nArchivo de traza a procesar<\/td>\n<\/tr>\n
-t <list|apache|wellness|uri|elist|telist><\/td>\n(opcional) Formato del archivo de traza. Por defecto, se usa formato apache<\/span>.<\/td>\n<\/tr>\n
-b<\/td>\nSe usan identificadores (labels) para cada petici\u00f3n en archivo de traza.<\/td>\n<\/tr>\n
-a attack_output<\/td>\nArchivo de salida (ataques). Por defecto en formato U2URI.<\/td>\n<\/tr>\n
-r modsecurity_conf_file<\/td>\nArchivo de configuraci\u00f3n de ModSecurity.<\/td>\n<\/tr>\n
-o clean_log_output<\/td>\n(opcional) Archivo de salida con los elementos de la traza que no han generado alertas (filtrado, en su caso). Formato de salida id\u00e9ntico al de entrada.<\/td>\n<\/tr>\n
-e<\/td>\n(opcional) Activar informaci\u00f3n extendida de las alertas (se incluye mensaje de alerta y sid<\/em>). Por defecto s\u00f3lo se indica el sid<\/em>.<\/td>\n<\/tr>\n
-w<\/td>\n(opcional) Generar avisos cuando no se puedan decodificar caracteres percent encoded<\/em>.<\/td>\n<\/tr>\n
-c<\/td>\n(opcional) Filtrado por c\u00f3digo de respuesta para CR >=400.<\/td>\n<\/tr>\n
-x<\/td>\n(opcional) Filtrado estricto por c\u00f3digo de respuesta (para CR >=300).<\/td>\n<\/tr>\n
-d detailed_log_output<\/td>\n(opcional) Archivo de traza de libModSecurity.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Formatos<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Archivos de trazas<\/strong><\/span><\/p>

Los formatos disponibles en la versi\u00f3n actual para el archivo de traza son:<\/p>

– apache<\/em>: Formato est\u00e1ndar de Apache.<\/p>

– wellness<\/em>: Variante del formato Apache con datos adicionales.<\/p>

– list<\/em>: Lista de URIs sin m\u00e9todo ni campos adicionales.<\/p>

– elist<\/em>: Lista de uris con 5 campos: petici\u00f3n uri\u00a0 protocolo codigo_respuesta tama\u00f1o_respuesta.<\/p>

– telist<\/em>: Idem elist con campos delimitados por tabuladores.<\/p>

– uri<\/em>: La primera l\u00ednea contiene el n\u00famero de uris en el archivo. Cada l\u00ednea incluye la longitud y el uri.<\/p>

Ejemplos<\/strong><\/span><\/p>

\u00a0<\/p>

\/* TIPO APACHE (12 campos) *\/<\/p>

IP USERIDENTIFIER USERID [TIMESTAMP DIF] \u00abMETHOD URI PROTOCOL\u00bb RESP_CODE RESP_SIZE \u00ab-\u00bb \u00abREFERER\u00bb<\/p>

172.16.16.210 – – [02\/May\/2017:12:21:07 +0200]\u00a0 \u00abGET http:\/\/127.0.0.1\/finger HTTP\/1.1\u00bb 404 289 \u00ab-\u00bb \u00abWget\/1.17.1 (linux-gnu)\u00bb
37.152.139.155 – – [07\/Nov\/2013:17:00:31 -0800] \u00abGET \/2003\/padron.html HTTP\/1.1\u00bb 200 11800 \u00ab-\u00bb \u00abJava\/1.7.0_15\u00bb \u00abajedreznd.com\u00bb<\/p>

\/* TIPO WELLNESS (10 campos) *\/<\/p>

TIMESTAMP NODE PLACE IP:PORT {server} \u00abMETHOD URI VER\u00bb RESP_CODE RESP_SIZE<\/p>

2017-06-22T06:25:15.356441+02:00 A-SQU-BAL-HAP03 haproxy[5518]: 10.128.2.64:46469 {www.wtelecom.es} \u00abGET \/ HTTP\/1.1\u00bb main_http_frontend WT_www_be\/A-WTE-INF-WEB03<\/p>

\/* TIPO LIST *\/<\/p>

URI<\/p>

\/2003\/padron.html<\/p>

\/* TIPO ELIST (campos delimitados por espacios) \/ TELIST (campos delimitados por tabuladores) *\/<\/p>

METHOD URI PROTOCOL\u00bb RESP_CODE RESP_SIZE<\/p>

GET \/ingenieros\/node HTTP\/1.1″ 200 26091<\/p>

\/* TIPO URI (1a linea con numero de uris) *\/<\/p>

17 \/2003\/padron.html<\/p>

\u00a0<\/p><\/div><\/td><\/tr><\/tbody><\/table>

Archivos de reglas<\/strong><\/span><\/p>

Se consideran tres formatos:<\/p>

– Reglas est\u00e1ndar de Snort (Talos\/VRT\/suricata\/ETOpen)<\/p>

– Reglas de nemesida (archivo de texto, descargado desde https:\/\/rlinfo.nemesida-security.com\/<\/a>)<\/p>

– Reglas y archivos de configuraci\u00f3n en el formato definido por ModSecurity (CRS)<\/p>

\u00a0<\/p>
Reglas formato SNORT<\/td><\/tr>

Se procesan las reglas en el formato est\u00e1ndar de Snort<\/strong> (Talos\/VRT\/suricata\/ET).<\/p>

S\u00f3lo se consideran los siguientes campos para la aplicaci\u00f3n de las reglas: http_method, http_uri, content, pcre, dsize, urilen, nocase <\/span>.<\/p>

Los campos msg, reference, classtype, sid<\/span> se procesan a efectos de referencia e indexaci\u00f3n.<\/p>

Los restantes campos son ignorados.<\/p><\/td><\/tr>

Reglas formato Nemesida<\/td><\/tr>

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\u00edneas que no contienen reglas y el formato html. El resultado presenta el siguiente formato:<\/p>

RID TIPO FIRMA ETIQUETA SCORE ZONA_COMPARACI\u00d3N<\/p>

1 RL nwaftest Other 12 BODY|URL|ARGS|HEADERS<\/p>

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\u00f3n regular, lista blanca (petici\u00f3n leg\u00edtima en todos los casos) o lista blanca usando una expresi\u00f3n regular, respectivamente.<\/p>

Para posibilitar la compatibilidad con las reglas en formato Snort, se asigna un SID a cada regla Nemesida a partir del RID sum\u00e1ndole 3000000.<\/p><\/td><\/tr><\/tbody><\/table>

Formato de salida (U2URI)<\/strong><\/span><\/p>

La salida relativa a los ataques se realiza a un archivo y contiene informaci\u00f3n una primera secci\u00f3n con informaci\u00f3n sobre las reglas cargadas y su procesamiento. A continuaci\u00f3n, cada l\u00ednea corresponde a un registro clasificado como ataque con el siguiente formato:<\/p>

Packet [numero_linea][etiqueta]\\tUri [uri_analizado]\\tNattacks [num_alertas]\\t[info_alerta_1]\\t … \\t[info_alerta_n]<\/p>

Los campos se encuentran delimitados por tabuladores y la [etiqueta] \u00fanicamente estar\u00e1 presente si existe en el archivo de traza de entrada.
La informaci\u00f3n sobre cada alerta depende de la opci\u00f3n -e (extendida), incluyendo siempre el SID de la regla activada y, opcionalmente, el mensaje asociado a la misma.<\/p>

Finalmente, se incluye una l\u00ednea con informaci\u00f3n sobre el n\u00famero de registros (procesados, con alertas y n\u00famero de alertas).<\/p>

Las l\u00edneas que no contienen informaci\u00f3n relativa a un paquete comienzan por el car\u00e1cter ‘#’ para facilitar su filtrado.<\/p>

Ejemplo<\/strong><\/span><\/p>

\u00a0<\/p>

# inspectorlog v3.6.0.1<\/p>

#—– Initializing Rules (SNORT) ———————<\/p>

# Rules directory : \u00ab\/data\/uri-data\/biblio-ds\/tmp\/reglas\u00bb<\/p>

# Opening SNORT rule file .\/tmp\/reglas\/http_uri-er-20220224-m2.rules… done<\/p>

# Rules: read [5918], erroneous [8], URI [5910]<\/p>

#—– Statistics (SNORT) ——————————<\/p>

# Read [9514] Snort rules, [9500] http-related, [13] with errors<\/p>

#—– Analysis results —————————-<\/p>

# 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<\/p>

Packet [629][01-01-A000629] Uri [\/politecnica\/sites\/all\/modules\/calendar\/css\/calendar_multiday.css?o8r51f] Nattacks [1] Signatures [882]<\/p>

Packet [763][01-01-A000763] Uri [\/sites\/wdn4.mu.xs\/files\/Biblioteca_Universitaria\/calendario_web_sabados_2015-16.jpg] Nattacks [1] Signatures [882]<\/p>

Packet [805][01-01-A000805] Uri [\/comunicacion\/sites\/all\/modules\/calendar\/css\/calendar_multiday.css?o86dyb] Nattacks [1] Signatures [882]
…<\/p>

# N. packets [35934], [44] with alerts, N. Alerts [49]<\/p>

\u00a0<\/div><\/div><\/td><\/tr><\/tbody><\/table>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Documentos t\u00e9cnicos \/ recursos<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tLa herramienta est\u00e1 disponible en github en la direcci\u00f3n:\n
https:\/\/gitlab.com\/neus_cslab\/inspectorlog<\/a><\/pre>\n \n\nPublicaciones<\/strong><\/span>
\n\n
<\/a><\/form>
 D\u00edaz-Verdejo, J.;  Mu\u00f1oz-Calle, J.;  Alonso, R. Estepa;  Alonso, A. Estepa<\/p>
InspectorLog : A New Tool for Offline Attack Detection over Web Log<\/a> Proceedings Article<\/span> <\/p>
En: <\/span>Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), <\/span>pp. 692\u2013697, <\/span>2024<\/span>, ISBN: 9789897587092<\/span>.<\/p>
Resumen<\/a><\/span> | Enlaces<\/a><\/span> | BibTeX<\/a><\/span><\/p>
@inproceedings{Diaz-Verdejo2024a,
\r\ntitle = {InspectorLog : A New Tool for Offline Attack Detection over Web Log},
\r\nauthor = {J. D\u00edaz-Verdejo and J. Mu\u00f1oz-Calle and R. Estepa Alonso and A. Estepa Alonso},
\r\ndoi = {10.5220\/0012764000003767},
\r\nisbn = {9789897587092},
\r\nyear  = {2024},
\r\ndate = {2024-01-01},
\r\nurldate = {2024-01-01},
\r\nbooktitle = {Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024)},
\r\nnumber = {Secrypt},
\r\npages = {692\u2013697},
\r\nabstract = {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.},
\r\nkeywords = {},
\r\npubstate = {published},
\r\ntppubtype = {inproceedings}
\r\n}
\r\n<\/pre><\/div>
Cerrar<\/a><\/p><\/div>
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.<\/div>
Cerrar<\/a><\/p><\/div>