Preprocesador de reputación IP de Snort

El preprocesador reputacional de Snort no es algo nuevo; de hecho, apareció en agosto de 2011 con la versión 2.9.1. Hasta aquel momento, la única forma de manejar listas negras de direcciones IP era a través de reglas con el motor de detección, creando una regla con una lista de direcciones IP, como las utilizadas en el conjunto BotCC (emerging-botcc.rules).

alert tcp $HOME_NET any -> [103.6.207.37,106.187.42.91,106.187.48.236,107.20.73.183,
108.170.20.73,108.170.56.211,108.61.240.240,108.61.26.189,109.109.228.186,109.111.79.4,
109.163.233.16,109.163.233.22,109.196.130.50,109.228.25.175,109.234.106.53, 109.74.194.110,
112.175.124.170] any (msg:"ET CNC Shadowserver Reported CnC Server TCP (group 1)"; flags:S; 
reference:url,doc.emergingthreats.net/bin/view/Main/BotCC; reference:url,www.shadowserver.org; 
threshold: type limit, track by_src, seconds 3600, count 1; classtype:trojan-activity; 
flowbits:set,ET.Evil; flowbits:set,ET.BotccIP; sid:2404000; rev:3259;)

Esta forma tenía una limitación por lo que se creaban listas interminables de reglas relacionadas con una lista negra separadas en grupos teniendo alertas del estilo “ET CNC Shadowserver Reported CnC Server UDP (group 49)” o “ET COMPROMISED Known Compromised or Hostile Host Traffic UDP (43)”.

Pero esta no era la limitación principal, o mejor dicho, este no era el inconveniente principal de utilizar este conjunto de reglas: el principal problema es el rendimiento. Al tratarse de reglas de detección se tarda más en procesar los paquetes para compararlos con estas reglas, lo que afecta al rendimiento global de la aplicación.

Cuando manejamos mucho tráfico y muchas listas negras (o listas muy largas) como Shadowserver, Abuse.ch, Malwaredomains… más las nuestas generadas internamente, esto se convierte en una carga importante para Snort que nos obliga a buscar una alternativa. Así que llega un momento en que te planteas la necesidad de utilizar este preprocesador.

Lo primero es obtener una lista de direcciones IP desde las numerosas fuentes existentes (en este ejemplo, Abuse.ch) y las copiamos en una carpeta en $SNORT_PATH/etc/reputation/:

$ wget -O spyeeye.blf https://spyeyetracker.abuse.ch/blocklist.php?download=ipblocklist
$ wget -O zeus.blf https://zeustracker.abuse.ch/blocklist.php?download=ipblocklist
$ mv spyeye.blf zeus.blf $SNORT_PATH/etc/reputation/

A continuación configuramos el preprocesador:

$BLACK_LIST_PATH $SNORT_PATH/etc/reputation/
# Reputation preprocessor. For more information see README.reputation
preprocessor reputation: \
   memcap 500, \
   priority whitelist, \
   nested_ip inner, \
   blacklist $RULES/compromised-ips.txt, \
   blacklist $RULES/rbn-ips.txt, \
   blacklist $BLACK_LIST_PATH/spyeye.blf, \
   blacklist $BLACK_LIST_PATH/zeus.blf

Este preprocesador generará alertas por cada paquete enviado o dirigido a una dirección IP incluida en dichas listas negras. El mensaje que veremos será el indicado en el archivo gen-msg.map para el preprocesador 136:

[...]
136 || 1 || reputation: Packet is blacklisted
136 || 2 || reputation: Packet is whitelisted
[...]

Si queremos cambiar el mensaje o modificar algunas de las condiciones de la regla podremos hacerlo através de las reglas de preprocesador, preprocessor.rules:

alert ( msg: "reputation: Packet is blacklisted"; sid: 1; gid: 136; rev: 1; \
        metadata: rule-type decode ; classtype:bad-unknown;)

O definir límites en el archivo threshold.conf:

event_filter \
        gen_id 136, sig_id 1, \
        type limit, track by_src,  \
        count 1, seconds 3600

A mi parecer este método tiene un inconveniente que debería valorar la gente de Sourcefire (ahora Cisco): la alerta no informa acerca de la lista en la que aparece la dirección IP. Esto puede ser muy útil cuando estamos trazando diferentes botnets ya que el mensaje de la alerta se nos queda un poco corto y perdemos cierta información sobre el evento. Por ello, estaría bien que apareciese la lista que genera la alerta y así saber, siguendo nuestro ejemplo, si viene de la botnet Zeus o de SpyEye. Pasamos de tener muchas alertas repetidas que se diferencian por un sufijo del grupo, a tener una única alerta pero si esto no es un impedimento, obtendremos una mejora considerable en el rendimiento.