Snort y las reglas de la Russian Business Network

Supongo que a muchos de ustedes les sonarán las reglas de Emerging Threats y sobretodo les sonarán el conjunto de reglas de la archiconocida “Russian Business Network” (RBN), sobretodo si disponen de sus sondas NIDS en un entorno mediano/grande, con gran cantidad de tráfico, donde por regla general suelen hacer acto de presencia. Estas reglas para el que no las conozcan alertan de conexiones realizadas o recibidas de direcciones de red que han sido clasificadas como maliciosas, sospechosas, peligrosas o similar. Este listado se actualizada de manera diaria, por lo menos en Emerging Threats, por lo que es bastante recomendable que nosotros también actualicemos este conjunto de reglas a la par que la fuente, ya que es un grupo bastante dinámico.

Estas reglas son muy útiles y no lo vamos a negar, ya que son un indicador que nos alerta de que existen conexiones sospechosas, desde orígenes o hacia destinos sospechosos; y lo que aportan merece la pena. Pero por otro lado, hemos podido comprobar que generan falsos positivos ciertos segmentos de red que están incluidos y que se han producido tras una simple navegación de un usuario.

Además, de los falsos positivos, las reglas de la RBN ofrecen poca información para ir poniendo filtros o realizar una investigación inicial, ya que alertan cuando el flag tcp SYN está activo, como muestra la siguiente regla:

alert tcp [108.59.9.65,108.60.159.33,109.108.128.28,109.110.0.0/19,109.120.128.0/18,
109.123.117.10,109.123.117.85,109.123.118.42,109.123.88.25,109.127.8.242,109.127.8.243,
109.169.62.114,109.169.68.137,109.169.70.121,109.196.130.42,109.196.130.58,
109.196.134.0/24,109.196.140.19,109.196.141.0/24,109.196.142.0/24] any -> $HOME_NET any (msg:"ET RBN Known Russian Business Network IP TCP (1)"; flags:S; reference:url,doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork; threshold: type limit, track by_src, seconds 60, count 1; flowbits:set,ET.RBN; flowbits:set,ET.Evil; classtype:misc-attack; sid:2406000; rev:273;)

El paquete que nos encontraremos cuando esta regla salta carecerá de contenido que pueda ayudarnos a ver de una manera rápida (siempre podemos hacer una investigación más en profundidad, pero entornos con un volumen de tráfico considerable puede suponer mucho esfuerzo) si se trata de un falso positivo o por el contrario se trata de una alerta significativa que requiera una investigación. Por otro lado, debido a la limitación de cantidad de elementos que tienen las reglas de Snort, el fichero de reglas de la RBN contiene muchas reglas, por lo que su personalización y sobretodo su reducción, resulta a priori costoso, aunque sería posible con oinkmaster o pulledpork poder realizar una personalización, pero también es costoso por lo menos la primera puesta a punto.

Ante esto, buscando si existían comentarios en la red sobre las reglas de RBN, me encontré en la lista del proyecto Emerging Threats en una entrada que sí se había hablado sobre las reglas de RBN y donde “Eoin Millar” del blog TrojanedBinaries ofrecía una manera de tratar las reglas de RBN muy interesante. El proceso sería el siguiente:

  • 1. Descargarse el fichero de IPs de la RBN alojado en la url http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt
  • 2. Crear un fichero donde se creen bloques de variables del tipo ipvar (requisito para usar ipvar que Snort esté compilado con soporte para ipv6) para almacenar las direcciones ip. Os pongo el ejemplo que comenta Eoin donde se ve muy claro la estructura del fichero (fichero rbn.conf):
    ipvar RBN_1 [127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1]
    ipvar RBN_2 [127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1]
    ipvar RBN_NET [$RBN_1,$RBN_2]

    En el proceso de creación de este fichero nosotros hemos añadido ciertos controles para prevenir errores en el listado de la RBN, como ha sido fijar un tamaño mínimo de máscara de red y no aceptar direcciones IPs reservadas para redes privadas. Pero esto cada uno a su gusto :).

  • 3. Una vez creado este fichero lo incluiremos dentro de nuestro snort.conf, mediante un include rbn.conf.
  • 4. Ahora ya nos será más flexible la información de la RBN. Por ejemplo, podemos crear reglas como esta:
    alert tcp $HOME_NET any -> $RBN_NET 80 (msg:"ET accesos de la RBN a servidores WEB"; flow:to_server,established; dsize:>1; detection_filter:track by_src, count 1, seconds 60; reference:url,doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork; classtype:misc-attack; sid:3000001; rev:1;)

Con esta regla podemos monitorizar los accesos desde direcciones IP de nuestra red a servidores Web dentro de la RBN y podremos visualizar parte del contenido enviado.

Con esto lo que hemos conseguido es reducir el número de reglas, ya que con 2,3 reglas podríamos disponer de todas las del fichero de Emerging Threats y por lo tanto podemos hacer cambios de una manera más sencilla. Por otro lado, disponemos de una variable nueva que puede ser utilizada en otras reglas creadas por nosotros o por terceros.

Por último agradecer a Joaquín Moreno la colaboración en el script para automatizar este proceso :) y sobretodo espero como siempre que os sea de utilidad.

Actualización: Pueden descargarse el script para autogenerar el fichero rbn.conf de este enlace: rbnupdate.py.

Comments

  1. Muy interesante. Paso a votarte en Bitácoras, veo que vas bien situado. Suerte.
    Saludos.
    P.D.: Te invito a pasar por mi blog DISEÑO GRAFICO CON PHOTOSHOP. Espero te guste y si crees que lo merece contar con tu voto. Gracias.

  2. Excelente!!! Antes, casi a diario sufría con los continuos e infinitos eventos inservibles de RBN, hasta que opté por almacenarlos a parte del resto, ya que eran muchos y no aportaban apenas información, como bien dices.

    Por cierto, ¿Podrías compartir el script para autogenerar el fichero rbn.conf? Sería de gran ayuda para poner en práctica este enfoque.

    Un saludo y gracias

  3. cjmateos, dentro de un rato lo colgamos.

  4. Fichero añadido al final del post.

  5. cjmateos, en la versión de snort 2.9.1 no da ningún tipo de problema (por lo menos a nosotros). Para las versiones 2.8.x, tendrá que estar compilado el snort con soporte para ipv6.

    Un saludo.

  6. Muchas gracias por el aporte :) La verdad que el snort que tengo instalado es un 2.8.6 y tendría que compilar el soporte de ipv6, así que creo que voy a aprovechar para actualizarme a la 2.9 ya que leí en el blog de Snort que en cuestión de días dejarán de dar soporte y actualizaciones de reglas para la 2.8.6.1.

    De nuevo, muchas gracias.