Recursos y algunas notas sobre Suricata IDS

Suricata es un sistema de detección de intrusiones y monitorización de red de fuentes abiertas publicado con la licencia GPL. Sus tres principales fortalezas en la actual versión, 2.0.8 son:

• Escalabilidad gracias a su arquitectura multihilo.
• Identificación de protocolos en los flujos de datos, lo que permite escribir reglas de detección de patrones orientadas al protocolo no a puertos.
• La posibilidad de calcular huellas md5 de ficheros al vuelo, extraer los mismos e identificarlos.

Por motivos laborales, he estado buscando bastante información sobre Suricata el último mes. Con esta entrada pretendo crear un pequeño índice que me sirva de ayuda cuando necesite buscar información sobre el mismo.

Documentación y ayudas

Existe un pequeño índice con la documentación oficial de Suricata, donde está la Guía de usuario como documentación más completa y base donde se puede consultar.

Hay tres blogs con una serie de entradas sobre Suricata y su configuración muy interesantes:

• To Linux and beyond ! el blog de Éric Leblond en el que podéis buscar aquellas entradas etiquetadas con suricata
• Inliniac, el blog de Victor Julien.
• IT Security through Open Source, el blog de Peter Manev.

Hay dos listas de correos donde se puede obtener información Oisf-users, la lista de usurios de Suricata y para los más aventureros la lista de desarrollo Oisf-devel

Otro recurso importante para obtener información y ayuda es el canal Suricata en la red de IRC Freenode

Estadísticas

Suricata es capaz de generar diversas estadísticas: uso de memoria, alertas, paquetes capturados y perdidos, etc en el fichero stats.log. Para que se generen las mismas es necesario que esté activado en el fichero de configuración. Érin Leblod tiene un programa suri-stats que puede ayudar a analizar y hacer gráficos sobre las mismas. Para activar las estadísticas basta con añadir al fichero de configuración las opciones correspondiente en la sección outputs:

outputs:
  - stats:
      enabled: yes
      filename: stats.log
      append: yes
      interval: 20

Las opciones anteriores hará que Suricata vaya generando cada 20 segundos - interval - la información en el fichero $PREFIX/var/log/stats.log. Además , la información no se borra en cada rearranque (append es yes). El formato de los ficheros de configuración de Suricata es Yaml

Algunas opciones de línea de comandos

Cuando estás midiendo rendimiento y probando configuraciones hay dos opciones que son importante mirar:

• --build-info Suricata listará las opciones que se ha usado a la hora de generar el binario, las rutas de instalación por defecto y librerías que ha usado. Puede ser una buena idea incluir esta información cuando se va a pedir ayuda.
• --dump-config Suricata volcará la configuración. Además, el formato en la que la vuelca es muy cómodo porque permite modificar los parámetros al vuelo en la línea de comandos con --set
.

Hardware

Es importante tener hardware que tenga la capacidad suficiente para captura el flujo de datos que se quiere analizar. Si se está trabajando bajo Linux implica el uso de hardware al cual se pueda tener acceso con la interfaz de captura AF_PACKET y soporte para los anillos de captura. Además, en función del número de reglas - esto es algo crítico - , se necesitará memoria y CPUs. Leyendo las listas de correo de Suricata no es raro hablar de 64 Gbytes de RAM y 16 cores para poder procesar un conjunto respetable de reglas y tráficos de varios gigabytes por segundo.

Nota sobre configuraciones y pruebas

Cuando se está haciendo pruebas para obtener una configuración óptima de Suricata en un hardware determinado es conveniente ir versionando los ficheros de configuraciones para que seamos capaces de saber que se ha tocado y el rendimiento esperado con las modificaciones. Quizás lo más cómodo sea usar algún sistema de contro de versiones como git que nos permita almacenar cada cambio. Tener algún tipo de sistema de pruenas automático con un tráfico defino también ayuda en esta labor.

Multiplexar conexiones ssh

Las últimas versiones de OpenSSH tienen una funcionalidad que permite usar una única conexión ssh para multiplexar varios canales. Se abre y autentifica la primera conexión, y de manera automática, se usa ésta para establecer el resto de canales con la mísma máquina. Es el mismo mecanismo que se utiliza en el forwarding de X11 pero aplicado a todas las conexiones ssh.

Cuando se configura de esta manera el ssh, se establece una conexión master la cual abre un socket Unix y se pone a la escucha en el mismo. Cuando se quiere conectar con la misma máquina, el proceso ssh intentará usar este socket. En caso de que no se pueda, realizará la conexión de manera habitual en función de como hayamos configurado la multiplexación de conexiones.

Para configurar la multiplexación de conexiones hay que modificar el fichero $HOME/.ssh/config y usar las opciones ControlMaster, ControlPath y ControlPersist. Si queremos que sólo estén activas estas opciones para los host de la red 192.168.120.0/24, sería necesario modificar el fichero de la siguiente manera:

host 192.168.120.*
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 300

Controlmaster activa la multiplexación de conexiones y se activa en modo auto. Esto quiere decir que ssh intentará usar la compartición de conexiones y si no está disponible, usará la conexión normal. ControlPath establece la ruta donde se creará el socket Unix que crea ssh para escuchar conexiones y multiplexarlas. Como puede verse en la ruta existe ciertas plantillas que se sustituyen por sus valores: %r es el usuario remoto usado para conectar, %h es el nombre del host y %p es el puerto remoto que se está usando. ControlPersist controla el comportamiento del ssh una vez que se ha cerrado la conexión master. Si vale yes, ssh pasa a segundo plano de manera indefinida, esperando más conexiones, si vale no se cerrará la conexión y en caso de que especifique un valor de tiempo, estará en segundo plano el tiempo que se especifique y finalizará si no hay nuevas conexiones o tráfico.

En la primera captura de pantalla se ve dos conexiones ssh sin compartir el socket. En la segunda se puede ver la multiplexación de conexiones con netstat -na --inet (las opciones de este comando son sólo válidas en Linux)

ssh sin multiplexar

ssh multiplexado

Devaluaciones e incentivos

Como aficionado a la economía, durante estos últimos años de crisis económica he leído varios artículos donde se acusa al euro de ser un corset demasiado estricto para aquellas economías menos competitivas dentro de la eurozona ya que no permite aplicar devaluaciones que permitan a estas economías ser competitivas respecto a aquellas que tienen una mayor productividad. Esta diferencia de productivad hace que se compren productos de otros países dando lugar a un déficit que hay que financiar a través de deuda, la cual, llegado a un punto, es insostenible.

Tener una moneda propia y poder devaluarla cuando el Banco Central del país quiera - es decir, cuando el Gobierno quiera -, sería un mecanismo que evitaría que dicho déficit se disparara y que podría hacer más competitiva la economía. Llegado a un punto, una devaluación teóricamente tendría dos beneficios y

• El ser más caro comprar al exterior bienes y servicios debido a la devaluación, se buscarían alternativas dentro del propio país, evitando que los déficit y su necesidad de financiación se dispararan.
• Haría más atractivas las exportaciones del país que ha realizado la devaluación, ya que sería más barato producir el el mismo.
• Durante este periodo se compra tiempo durante el cual se podrían realizar reformas en la economía del país que permitiesen ganar productividad y poder competir con otros países.

Pero a veces, pienso que este mecanismo se convierte en un incentivo para que no se produzcan los correspondientes ajustes en aquellos sectores de la economía de un país que se han quedado obsoletas, tienen que modernizarse y ganar en competitividad. En especial, si existen los suficientes grupos de presión en esos sectores que puedan hacer que los gobiernos se inclinen por devaluar la moneda en vez de un programa de reformas. Una de las razones de la existencia del euro es - precisamente - acabar con este tipo de devaluaciones competitivas.

Obtener estadísticas de capturas de red con tshark

Aparte de la interfaz gráfica, el analizador de protocolos Wireshark tiene una versión que funciona desde la línea de comandos,similar a tcpdump. Una funcionalidad interesante es la posibilidad de obtener estadísticas de las capturas para su posterior análisis a través de la opción -z. Para poder probar las opciones, se puede usar los pcaps de ejemplo smallFlows.pcap y bigFlows.pcap que tienen los autores del tcpreplay colgado en sus páginas.

Puede consultarse todas las estadísticas disponibles en la página de manual de tshark o ejecutando la orden tshask -z help. Estas estadísticas se pueden obtener tanto de una captura en tiempo real como de un fichero con una captura que se haya grabado previamente. Si sólo se está interesando en las estadísticas, la opción -q hace que tshark no vuelque la información de los paquetes. La estadísticas se muestran ordenas en función del número de tramas que coinciden con el criterio de filtrado que se ha aplicado.

Analizar los flujos de una captura

Supongamos que se quiere saber el número de flujos TCP que tiene una captura determinada. Usando como ejemplo smallFlows.pcap, el comando para obtener esa información sería:

baldurgate:~ terron$tshark -q -z conv,tcp -r smallFlows.pcap

tshark mostrará una tabla con cada una de los flujos, el número de paquetes y bytes en cada sentido, los bytes totales que ha registrado, cuando empieza el flujo en la captura y su duración:

tshark -q -z conv,tcp -r smallFlows.pcap

Para ver los flujos que existen a nivel ethernet se puede usar la siguiente orden

baldurgate:~ terron$tshark -q -z conv,eth -r smallFlows.pcap

tshark -q -z conv,eth -r smallFlows.pcap

Exiten varios filtros que permiten analizar los flujos eth (ethernet), fc (fiber channel), fddi, ip, ipx (el viejo protocolo de Novell), sctp (stream control transmision protocol, tcp,tr (token ring) y udp.

Opcionalmente, a la opción conv se le puede especificar un filtro para poder seleccionar aquellos paquetes que interesen. Por ejemplo, si sólo se quisiera sacar las estadísticas de aquellos flujos que usen los puertos 80 o 443, se puede usar el filtro tcp.port == 80 or tcp.port == 443

baldurgate:~ terron$tshark -z conv,tcp,"tcp.port == 80 or tcp.port == 443" -r smallFlows.pcap

Resumen de protocolos

Con la opción -z io,phs se puede extraer los protocolos que existen en una determinada captura y ver sus estadísticas, mostrando cada uno de los protocolos encapsulados en las tramas, desde la capa de enlace que se tenga. Usando el mismo ejemplo smallFlows.pcap y con el siguiente comando:

baldurgate:~ terron$tshark -r smallFlows.pcap -q -z io,phs

tshark -r smallFlows.pcap -q -z io,phs

Como en el caso anterior, también se puede especificar un filtro que nos seleccione los paquetes. Por ejemplo, si sólo se desea los paquetes arp se puede usar el el filtro "arp", con lo cual la opción sería -z -z io,phs,arp, mientras si sólo se deseara capturar el tráfico http y dns se puede usar -z io,phs,"http or dns"¹

Obtención de información de http

tshark tiene algunas estadísticas que permiten obtener información sobre el uso de http. Con la opción -z http,stat,² se mostrará el resumen de los métodos que hay en las peticiones que se han enviado, pero sólo los métodos que han hecho peticiones. Si se quiere tener la estadística de todas las peticiones y las respuestas se puede usar el filtro -z http,tree. Un ejemplo de la salida de este comando se puede ver en la siguiente captura de pantalla

baldurgate:~ terron$tshark -r smallFlows.pcap -q -z "http,tree"

tshark -r smallFlows.pcap -q -z "http,tree"

Si se quiere, se puede obtener información de http por dirección IP y cada uno de los hosts virtuales que están en la misma. Para ello se usa la opción -z http_srv,tree cuya salida está agrupada por dirección IP y host virtual sobre la misma. También da el número de peticiones por cliente

baldurgate:~ terron$tshark -r smallFlows.pcap -q -z http_srv,tree

tshark -r smallFlows.pcap -q -z http_srv,tree

Resumen

tshark proporciona a través de la opción -z diversas estadísticas para los protocolos más usados que pueden ser de utilidad a la hora de analizar una captura de red. Consultando la página de manual de la utilidad están disponobles todos las estadísiticas posibles.

Notas

1. Curiosamente, al usar este filtro en el caso de la versión de tshark que estoy usando, 1.12.6, me saca información de ICMP
2. Ojo, hay que poner la coma al final.

El Parlamento francés apoya el espionaje sin orden judicial

(vía Barcepundit ) La Asamblea Nacional ha dado el apoyo a la ley francesa de servicios secretos, la cual permite la obtención de todo tipo de datos relacionados con llamadas telefónicas y uso de Internet. Básicamente, cualquier operadora de telecomunicaciones será pinchable por el gobierno francés, el cual usará en sus servicios de información los datos obtenidos sin necesidad de responder ante tribunales.

No sé si mucha gente tenía la esperanza que tras los casos de espionaje publicados por Snowden o la filtraciones de Wikileaks se iba a cambiar la legislación para tener más control sobre los servicios de información. Siempre he sido de la opinión contraria: Se aprobarían leyes que hicieran legal dicha obtención de información. Y habrá un endurecimiento de las leyes, cuando se empiezan a publicar información como los datos de los trabajador es del gobierno de los Estados Unidos.

Desde mi punto de vista - ojalá me confunda - la batalla por la privacidad en Internet está perdida.