A partir de la versión 2.9, Snort ha ido introduciendo mejoras en sus preprocesadores de HTTP y SMTP que permiten la extracción por separado de varios campos importantes de conversaciones HTTP y SMTP.
La primera de ellas fue la posibilidad de reconocer las cabeceras X-Forwarded-For y True-Client-IP que añaden algunos proxies, para reconocer los equipos que realmente están produciendo las alertas en entornos en los que la navegación HTTP se realiza a través de estos dispositivos.
En la versión 2.9.1 se han introducido nuevos campos que pueden ser de utilidad en el análisis de alertas. Estas incluyen las siguientes:
HTTP: Dirección IPv4 True-Client-IP/XFF (Tipo 1) HTTP: Dirección IPv6 True-Client-IP/XFF (Tipo 2) HTTP: Datos Gzip descomprimidos (Tipo 4) SMTP: Nombre de fichero adjunto (Tipo 5) SMTP: Origen del correo (Campo MAIL FROM) (Tripo 6) SMTP: Destino del correo (Campo RCPT TO) (Tipo 7) SMTP: Cabeceras del correo (Tipo 8) HTTP: URI de la petición (Tipo 9) HTTP: Nombre de host solicitado (Cabecera Host) (Tipo 10) Dirección de origen IPv6 del paquete (Tipo 11) Dirección de destino IPv6 del paquete (Tipo 12)
Estos campos únicamente se obtienen en el plugin de salida Unified2, por lo que no serán visibles en ningún otro plugin, ni siquiera si se muestra la salida por consola. En esta entrada vamos a ver a través de un ejemplo cómo se obtienen estos campos de especial utilidad.
A continuación se muestra una alerta generada por Snort, tal como era guardada en un fichero Unified2 en versiones anteriores de Snort:
(Event)
sensor id: 0 event id: 131116 event second: 1327996311
event microsecond: 631933
sig id: 2001855 gen id: 1 revision: 30 classification: 21
priority: 1 ip source: AAA.AAA.AAA.AAA ip destination: BBB.BBB.BBB.BBB
src port: 48483 dest port: 80 protocol: 6 impact_flag: 0 blocked: 0
Packet
sensor id: 0 event id: 131116 event second: 1327996311
packet second: 1327996311 packet microsecond: 631933
linktype: 1 packet_length: 1434
[ 0] 00 00 5E 00 01 41 00 09 0F 09 00 17 08 00 45 00 ..^..A........E.
[ 16] 05 8C CD D1 40 00 3A 06 38 2D C1 91 C9 35 AE 78 ....@.:.8-...5.x
[ 32] FC 2D BD 63 00 50 74 40 EE 54 C1 17 1B 02 80 10 .-.c.Pt@.T......
[ 48] 00 2E 3B 8F 00 00 01 01 08 0A 03 0E 24 42 63 EC ..;.........$Bc.
[ 64] 60 CD 47 45 54 20 2F 61 64 53 65 72 76 65 2F 73 `.GET /adServe/s
[ 80] 74 61 74 69 63 2F 62 74 67 65 6E 2D 69 65 2D 69 tatic/btgen-ie-i
[ 96] 6D 33 2E 68 74 6D 6C 3F 74 69 64 3D 53 57 49 4D m3.html?tid=SWIM
[ 112] 30 36 20 48 54 54 50 2F 31 2E 30 0D 0A 41 63 63 06 HTTP/1.0..Acc
[ 128] 65 70 74 3A 20 2A 2F 2A 0D 0A 41 63 63 65 70 74 ept: */*..Accept
[ 144] 2D 4C 61 6E 67 75 61 67 65 3A 20 65 73 0D 0A 49 -Language: es..I
[ 160] 66 2D 4D 6F 64 69 66 69 65 64 2D 53 69 6E 63 65 f-Modified-Since
[ 176] 3A 20 4D 6F 6E 2C 20 31 32 20 44 65 63 20 32 30 : Mon, 12 Dec 20
[ 192] 31 31 20 31 30 3A 34 38 3A 35 37 20 47 4D 54 3B 11 10:48:57 GMT;
[ 208] 20 6C 65 6E 67 74 68 3D 32 31 36 34 0D 0A 55 73 length=2164..Us
[ 224] 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C er-Agent: Mozill
[ 240] 61 2F 34 2E 30 20 28 63 6F 6D 70 61 74 69 62 6C a/4.0 (compatibl
[ 256] 65 3B 20 4D 53 49 45 20 36 2E 30 3B 20 57 69 6E e; MSIE 6.0; Win
[ 272] 64 6F 77 73 20 4E 54 20 35 2E 31 3B 20 53 56 31 dows NT 5.1; SV1
[ 288] 3B 20 42 54 52 53 38 36 34 37 33 3B 20 46 75 6E ; BTRS86473; Fun
[ 304] 57 65 62 50 72 6F 64 75 63 74 73 3B 20 53 49 4D WebProducts; SIM
[ 320] 42 41 52 3D 7B 32 46 36 33 43 43 37 34 2D 31 37 BAR={2F63CC74-17
[ ...]
Packet
sensor id: 0 event id: 131116 event second: 1327996311
packet second: 1327996311 packet microsecond: 632015
linktype: 1 packet_length: 1132
[ 0] 00 00 5E 00 01 41 00 09 0F 09 00 17 08 00 45 00 ..^..A........E.
[ 16] 04 5E CD D2 40 00 3A 06 39 5A C1 91 C9 35 AE 78 .^..@.:.9Z...5.x
[ 32] FC 2D BD 63 00 50 74 40 F3 AC C1 17 1B 02 80 18 .-.c.Pt@........
[ 48] 00 2E BF 16 00 00 01 01 08 0A 03 0E 24 42 63 EC ............$Bc.
[ ...]
[ 976] 3D 32 38 31 37 38 30 33 31 33 36 0D 0A 56 69 61 =2817803136..Via
[ 992] 3A 20 31 2E 30 20 50 52 4F 58 59 2E 45 58 41 4D : 1.0 PROXY.EXAM
[ 1008] 50 4C 45 2E 43 4F 4D 3A 38 30 38 30 20 28 73 71 PLE.COM:8080 (sq
[ 1024] 75 69 64 2F 32 2E 36 2E 53 54 41 42 4C 45 36 29 uid/2.6.STABLE6)
[ 1040] 0D 0A 58 2D 46 6F 72 77 61 72 64 65 64 2D 46 6F ..X-Forwarded-Fo
[ 1056] 72 3A 20 31 37 32 2E 31 37 2E 41 41 41 2E 42 42 r: 172.16.AAA.BB
[ 1072] 42 0D 0A 43 61 63 68 65 2D 43 6F 6E 74 72 6F 6C B..Cache-Control
[ 1088] 3A 20 6D 61 78 2D 61 67 65 3D 32 35 39 32 30 30 : max-age=259200
[ 1104] 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 ..Connection: ke
[ 1120] 65 70 2D 61 6C 69 76 65 0D 0A 0D 0A ep-alive....
Analizando un poco los paquetes de la alerta, podemos ver que se trata de una típica alerta producida por una barra de navegador que redirige el tráfico hacia sus servidores, y puede ser considerada como spyware.
Podemos ver que en el segundo paquete asociado a esta alerta encontramos una cabecera X-Forwarded-For, que ni siquiera sería guardado en la base de datos por defecto de Snort. En versiones actuales (a partir de la 2.9.1) podemos activar las siguientes opciones en el preprocesador de HTTP para obtener información adicional:
preprocessor http_inspect_server: log_uri \ log_hostname \ enable_xff
Con estas opciones activadas, el fichero unified2 contendría, además de los dos paquetes mostrados anteriormente, el siguiente contenido:
(ExtraDataHdr) event type: 4 event length: 36 (ExtraData) sensor id: 0 event id: 131116 event second: 1327996311 type: 1 datatype: 1 bloblength: 12 Original Client IP: 172.16.AAA.BBB (ExtraDataHdr) event type: 4 event length: 76 (ExtraData) sensor id: 0 event id: 131116 event second: 1327996311 type: 9 datatype: 1 bloblength: 52 HTTP URI: /adServe/static/btgen-ie- im3.html?tid=SWIM06 (ExtraDataHdr) event type: 4 event length: 42 (ExtraData) sensor id: 0 event id: 131116 event second: 1327996311 type: 10 datatype: 1 bloblength: 18 HTTP Hostname: hostexterno.com
Con esta información bien procesada y guardada en una BBDD, se puede realizar un mejor análisis a posteriori de las alertas producidas, teniendo más información para poder trazar los comportamientos anómalos.
Lamentablemente, a fecha de la redacción de este artículo todavía no se dispone de una versión oficial de Barnyard2 que sea capaz de procesar estas cabeceras extra ni guardarlas en ninguna base de datos.
De todas formas, estad tranquilos. En una próxima entrada os mostraré como conseguir que finalmente se inserte información en la base de datos. Permaneced atentos ;)
Buen post, pero esto solo funcionaría con un forwarded_for on, lo que debería ser un grán “NO NO” en todos los entornos salvo excepciones controladas.
+1 por el 50 52 4F 58 59 2E 45 58 41 4D 50 4C 45 2E 43 4F 4D :)
espero ansiosa el siguiente post, sobre todo el tema de las URI y del SMTP.
Muchas gracias Bicho :)
Es cierto que el uso de las cabeceras x-forwarded-for pueden suponer un riesgo y su puesta en marcha debería ser revisada a conciencia.
De todas formas, creo que también se podrían poner dos niveles de proxy, uno interno en el que se utilicen estas cabeceras y otro externo que las quite, de forma que no salga a internet esta información y puedas además trazar las alertas hasta el equipo concreto.
No me he equivocado con el hexadecimal, ¿verdad? Estuve un buen rato para cambiar todos los caracteres :P
Muchas gracias, me alegro que te haya gustado el post ;)