Retomamos la serie sobre Suricata que iniciamos hace unos meses con dos entradas la presentación de sus principales características y la exposición de algunas de sus funcionalidades de detección de protocolos y extracción de registros adicionales.
En el final de la entrada anterior nos quedamos con un IDS que además de detectar nos ofrecía multitud de registros adicionales de muchos tipos diferentes.
Tanta cantidad de información puede desbordar a cualquier equipo de trabajo que intente procesarla, pero por suerte Suricata también proporciona una forma de unificar toda la información que puede generar para que nos sea más fácil de digerir. Esta forma unificada se llama Extensible Event Format (EVE) y utiliza el formato JSON para presentarnos toda la información disponible.
A continuación podemos ver un extracto del fichero de configuración suricata.yaml donde se aprecian las principales características que tiene este formato de salida de información:
# Extensible Event Format (nicknamed EVE) event log in JSON format
- eve-log:
enabled: yes
filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
filename: eve.json
types:
- alert:
# payload: yes # enable dumping payload in Base64
# payload-printable: yes # enable dumping payload in printable (lossy) format
# packet: yes # enable dumping of packet (without stream segments)
# http: yes # enable dumping of http fields
# tls: yes # enable dumping of tls fields
# ssh: yes # enable dumping of ssh fields
# smtp: yes # enable dumping of smtp fields
xff:
enabled: no
mode: extra-data
deployment: reverse
header: X-Forwarded-For
- http:
extended: yes # enable this for extended logging information
- dns
- tls:
extended: yes # enable this for extended logging information
- files:
force-magic: no # force logging magic on all logged files
force-md5: no # force logging of md5 checksums
#- drop:
# alerts: no # log alerts that caused drops
- smtp:
#extended: yes # enable this for extended logging information
- ssh
- stats:
totals: yes # stats for all threads merged together
threads: no # per thread stats
deltas: no # include delta values
#- flow # bi-directional flows
#- netflow # uni-directional flows
En primer lugar tenemos información sobre dónde enviar las alertas, si a un fichero, a syslog, a través de un socket o incluso enviarlo a una instancia de Redis para su posterior procesamiento.
A continuación tenemos información sobre todos los registros que se pueden incluir: alertas detectadas por el IDS; registros HTTP, DNS, TLS, SSH y SMTP; ficheros detectados; paquetes descartados; flujos unidireccionales o bidireccionales; e incluso las estadísticas de la propia aplicación.
A continuación podemos ver el aspecto que tendría una petición HTTP:
{
"timestamp": "2015-03-05T15:50:42.331219+0100",
"flow_id": 35722368,
"pcap_cnt": 283,
"event_type": "http",
"src_ip": "192.168.0.51",
"src_port": 60677,
"dest_ip": "91.189.89.240",
"dest_port": 80,
"proto": "TCP",
"http": {
"hostname": "start.ubuntu.com",
"url": "/12.04/sprite.png",
"http_user_agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0",
"http_content_type": "image/png",
"accept": "image/png,image/*;q=0.8,*/*;q=0.5",
"accept_encoding": "gzip, deflate",
"accept_language": "en-US,en;q=0.5",
"age": "2",
"connection": "keep-alive",
"content_length": "23678",
"content_type": "image/png",
"date": "Thu, 05 Mar 2015 14:50:40 GMT",
"last_modified": "Thu, 26 Apr 2012 11:53:49 GMT",
"server": "Apache/2.2.22 (Ubuntu)",
"http_method": "GET",
"protocol": "HTTP/1.1",
"status": 200,
"length": 23678,
"tx_id": 1
}
}
Y aquí el aspecto de una petición DNS:
{
"timestamp": "2015-03-05T15:50:42.335632+0100",
"flow_id": 35722672,
"pcap_cnt": 284,
"event_type": "dns",
"src_ip": "192.168.0.51",
"src_port": 4690,
"dest_ip": "192.168.0.1",
"dest_port": 53,
"proto": "UDP",
"dns": {
"type": "query",
"id": 51572,
"rrname": "www.google.com",
"rrtype": "A",
"tx_id": 0
}
}
Este formato JSON se puede introducir utilizando Logstash a una base de datos Elasticsearch, y desde ahí, utilizando Kibana, generar visualizaciones que nos permitan de un vistazo obtener información relevante sobre las alertas que se han generado y los registros que se han obtenido, como ya hemos visto en anteriores ocasiones aquí, aquí y aquí.
A continuación podemos ver una de las visualizaciones existentes creadas por uno de los desarrolladores de Suricata, en este caso la del tráfico HTTP (pinchar en la imagen para una versión ampliada y en detalle):
Podemos ver fácilmente la distribución temporal de las alertas, geolocalizar su origen en diferentes tipos de mapas, y tener los valores de diferentes parámetros de interés desglosados. Todo esto como ya hemos comentado en anteriores ocasiones es navegable de forma que si seleccionamos otro rango temporal o un valor concreto en cualquiera de los apartados de la visualización, el resto de apartados cambia para adaptarse a la nueva restricción.
Para finalizar, cabe recordar que, aunque ya hace tiempo que se ha publicado Kibana 4, estas visualizaciones están hechas para Kibana 3, por lo que deberemos descargar la versión anterior para poder cargarlas.
Grande el post Jose.
Mi pregunta es: ¿Has querido decir que con Kibana 4 no se pueden sacar esas visualizaciones?
Enhorabuena y… Esperamos la cuarta parte ;)
Hola Alberto,
Kibana 4 tiene más opciones que Kibana 3, pero salvo que lo hayan implementado en las últimas versiones no se podía importar/exportar visualizaciones, así que por simplicidad y facilidad de uso he optado por utilizar Kibana 3.
Me alegro que te haya gustado el artículo. En breve la cuarta, y seguramente última, parte de la presentación.
Saludos.