Presentando Suricata (II)

En esta segunda parte de la serie sobre Suricata (ver primera parte) vamos a continuar repasando las ventajas de Suricata, pero esta vez centrados en la información que podemos obtener de la aplicación.

Con Snort teníamos únicamente alertas, que podían provenir o bien de preprocesadores o bien de firmas que se cargaban a la aplicación. Suricata, si bien mantiene estas ideas, y ofrece total compatibilidad con las reglas existentes para Snort, ofrece muchísimo más.

Por una parte se ha mejorado el proceso de detección de protocolos, de forma que, para algunos de ellos (actualmente http, ssl, tls, smb, smb2, dcerpc, smtp, ftp, ssh y dns), ya no es necesario especificar los puertos en los que queremos buscarlos, sino que con añadir el protocolo correspondiente al principio de la firma se va a identificar el protocolo y procesar la regla, sea cual fuere el puerto en el que se ha detectado el tráfico.

Por ejemplo, supongamos una regla para detectar peticiones PUT en un servidor HTTP. En Snort podríamos tener algo así:

alert tcp $EXTERNAL_NET any -> $HOME_NET [80, 8080] (msg:”peticion PUT”; flow: established, to_server; 
content:”PUT“; http_method; sid: 9999; rev: 1;)

Mientras que para Suricata la misma regla se podría reescribir:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:”peticion PUT”; flow: established, to_server; 
content:”PUT“; http_method; sid: 9999; rev: 2;)

Así, quedarían cubiertos por esta firma de Suricata, por ejemplo, aplicaciones web que utilicen puertos extraños (Como el puerto 7777 que utilizan por defecto algunos servidores web de Oracle), o Servidores de Control de Malware que utilicen HTTP o cualquiera de los otros protocolos reconocidos en puertos extraños. En Snort necesitaríamos reescribir la regla o crear una nueva para añadir cada nuevo puerto que se detectase.

Otra mejora interesante tiene que ver con la extracción de ficheros potencialmente sospechosos de las comunicaciones analizadas por Suricata. Esto permite, por ejemplo, crear reglas como la siguiente (extraída de aquí):

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:”pdf upload claimed, but not pdf”; 
flow:established,to_server; content:”POST”; http_method; fileext:”pdf”; filemagic:!”PDF document”; 
filestore; sid:8888; rev:1;)

Con esta regla pedimos a Suricata que nos guarde en disco (filestore) los ficheros transmitidos por http con extensión PDF que encuentre (fileext) y cuyo contenido no corresponda con un fichero PDF (filemagic). En el wiki de Suricata podemos ver un listado completo de todos los parámetros existentes para el tratamiento de ficheros. Para activar esta funcionalidad, además de crear firmas como la que acabamos de ver, hay que modificar el apartado file-store de la configuración de Suricata.

Pasamos ahora a hablar del apartado de registros. Suricata ha incluido, dentro de su configuración la opción de guardar registros de diferentes tipos de comunicaciones que detecte, siendo los principales protocolos soportados HTTP y DNS.

Esto nos permite, por una parte, simular la existencia de un proxy HTTP, al menos a nivel de registro, y por otra, tener un log al estilo Replicación Pasiva de DNS (tratado aquí también: partes 1, 2 y 3), sin necesidad de desplegar ninguna herramienta adicional.

La configuración de estos logs, como otros muchos aspectos de Suricata, es muy sencilla, como podemos ver a continuación.

- http-log:
    enabled: yes 
    filename: http.log
    append: yes
    extended: no	

- dns-log:
    enabled: yes
    filename: dns.log
    append: yes
    filetype: regular

En registro de peticiones HTTP se puede configurar de varios modos, dependiendo de la cantidad de información que queramos registrar. El modo más básico (extended: no y custom: no) guarda únicamente el hostname, la URI, el user-agent y los equipos implicados, mientras que el modo extendido guarda mucha más información, incluyendo entre otros el valor de la cabecera X-Forwarded-For, el código de respuesta y el destino de la redirección en caso de existir, la cantidad de bytes transferidos, o el referer. Por último, también tenemos un modo personalizado en el que podemos elegir los campos que queremos guardar.

Un ejemplo de este log extendido:

03/25/15-09:42:59.016146 - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET 
CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E) HTTP/1.1 
GET meneame.net /api/check_url.js.php - 0 10.0.0.132:54321 -> 176.34.125.26:8003/26/15-07:08:26.014151 
10.0.0.123 Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20121210 Firefox/17.0 HTTP/1.1 GET elpais.com / -
0 172.16.1.2:12345 -> 91.216.63.241:80

El log DNS es más sencillo, e incluye los parámetros de las consultas y las respuestas, así como los equipos implicados en la comunicación:

02/17/2015-07:34:32.526263 [**] Query TX e862 [**] meneame.net [**] A [**] 172.16.1.1:11764 -> 
205.251.196.92:53
02/17/2015-07:34:32.526263 [**] Response TX e862 [**] meneame.net [**] A [**] TTL 60 [**] 
176.34.125.26 [**] 205.251.196.92:53 -> 172.16.1.1:11764
02/17/2015-07:34:32.526263 [**] Response TX e862 [**] meneame.net [**] NS [**] TTL 41728 [**] 
ns-1116.awsdns-11.org [**] 205.251.196.92:53 -> 172.16.1.1:11764
02/17/2015-07:34:32.526263 [**] Response TX e862 [**] meneame.net [**] NS [**] TTL 41728 [**] 
ns-172.awsdns-21.com [**] 205.251.196.92:53 -> 172.16.1.1:11764
02/17/2015-07:34:32.526263 [**] Response TX e862 [**] meneame.net [**] NS [**] TTL 41728 [**] 
ns-1982.awsdns-55.co.uk [**] 205.251.196.92:53 -> 172.16.1.1:11764
02/17/2015-07:34:32.526263 [**] Response TX e862 [**] meneame.net [**] NS [**] TTL 41728 [**] 
ns-799.awsdns-35.net [**] 205.251.196.92:53 -> 172.16.1.1:11764

Por si no fuera suficiente con incorporar la funcionalidad de dos herramientas que hasta ahora debíamos mantener por separado, Suricata incorpora la posibilidad de generar registros de orígenes diversos, entre los que encontramos los siguientes:

• Registro SMTP: Guarda un listado de los correos enviados con las direcciones de correo implicadas, el asunto, y los nombres de los ficheros adjuntos detectados (más información).
• Handshake TLS: Guarda un listado con información sobre los handshake TLS intercambiados. Con reglas específicas como las vistas anteriormente se pueden guardar los certificados intercambiados (más información).
• Tráfico SSH: Guarda la versión del protocolo y del software utilizados por cada cliente/servidor SSH que se detecte.
• Flujos uni/bidireccionales: Guarda las características de cada flujo unidireccional o bidireccional que se encuentra en la red (más información).
• Capturas PCAP completas: Guarda todo el tráfico que pasa por Suricata. Similar a OpenFPC, del que nos habló Nelo aquí y aquí (más información).

Con todos estos registros ya tenemos información más que suficiente para trabajar, aún sin necesidad de tener firmas que nos alerten de posibles ataques. Por eso Suricata también tiene un modo de funcionamiento (llamado modo NSM) en el que deshabilita la parte de detección de firmas —la más costosa— dejando activos todos estos registros.

En el próximo artículo veremos cómo guarda Suricata todos estos logs que genera y lo que podemos hacer con ellos.