DNS sinkholing es un técnica mediante la cual podemos prevenir el acceso a sitios maliciosos devolviendo IPs falsas o nulas como respuesta a peticiones DNS intentando resolver dominios conocidos con malware. Se lleva utilizando desde hace años, incluso por operadores Tier-1, sobretodo para impedir las conexiones a servidores de comando y control (C&C) y, en definitiva, para detener a grandes botnets. Su implementación es sumamente sencilla: sólo configura manualmente o mediante DHCP el uso de un DNS con sinkholing. Y si detectas un falso positivo corrige la zona o, si sólo eres un usuario de "a pie", añade el host correspondiente a tu fichero host o utiliza otro servidor DNS y a otra cosa...
Básicamente un DNS sinkhole falsea los servidores DNS autorizados para hosts y dominios maliciosos y no deseados. Un administrador configura el forwarder DNS correspondiente para devolver direcciones IP falsas para estos hosts y dominios conocidos. Cuando un cliente solicita resolver la dirección de uno de estos hosts o dominios, el DNS sinkhole devuelve una dirección no enrutable o cualquier dirección excepto la dirección real. Esto deniega al cliente una conexión con el host de destino.
Veamos un claro ejemplo con bind, el servidor DNS en Linux de facto. Ya veréis lo sencilla que es una implementación básica.
Primero instalamos el software:
Y a continuación comprobamos cómo resuelve una dirección cualquiera de Internet:
Ahora editamos el fichero de configuración (en sistemas Debian normalmente está situado en /etc/bind/named.conf.local) para especificar los dominios que queremos bloquear:
Y luego creamos el fichero especificado /etc/bind/blacklisted.zones con algunos dominios de prueba:
Como podéis ver arriba, estamos definiendo las zonas para los que el DNS está autorizado. Cuando una consulta es recibida preguntando por el servidor DNS para resolver por ejemplo la IP de google.co.uk, el servidor proporcionará los datos del archivo asociado. En este caso, como estamos tratando a todos estos dominios para el sinkhole podemos apuntar a todos al mismo archivo de zona /etc/bind/blockeddomains.db para simplificar las cosas. Lo editaremos y añadiremos los siguientes registros:
En el ejemplo hemos puesto que las peticiones se redireccionen a localhost para bloquearlas, si bien podríamos haber puesto cualquier otra IP falsa, por ejemplo de un honeypot, un NIDS u otro nodo en una darknet.
Una vez que hemos realizado todos los cambios de configuración anteriores sólo necesitamos recargar/reconfigurar el servidor DNS (service bind9 restart) y comprobar que ahora el fqdn www.google.co.uk nos devuelve una IP 127.0.0.1:
Ya está. Imaginad que acabamos de dar una IP incorrecta a un supuesto artefacto de malware que está intentando comunicarse con su C&C, es decir, hemos bloqueado su conexión de esta forma tan tonta pero a la vez tan efectiva.
Evidentemente esta implementación aunque funcional es casi una prueba de concepto. Si queréis extender un poco la funcionalidad podéis programar un cron para que se descargue la lista abierta de malwaredomains con unos 15000 dominios identificados:
Aquí es donde radica la clave de un buen servicio DNS sinkholing, en obtener una lista muy actualizada de numerosos dominios, libre de falsos positivos. Porque estoy seguro de que, aunque la lista de malwaredomains es muy generosa, no puede compararse a la de otros servicios de pago como la de Palo Alto u OpenDNS.
Luego una vez que tenemos una sólida fuente de dominios, el resto de pasos para crearte un DNS sinkhole potente es básicamente realizar un desarrollo para el análisis de logs para alerta temprana (ya sea localmente o mediante la correlación de un SIEM), la custodia de logs para análisis forenses y la creación de frontends para facilitar su administración.
Lo iremos viendo más adelante, incluyendo la parte ofensiva mediante tentativas con fast flux o MiTM y envenenamiento si se da el caso que el sinkhole de turno no utiliza DNSSEC.
Fuentes:
- DNS sinkhole - Wikipedia, the free encyclopedia
- DNS sinkhole - The IT Law Wiki - Wikia
- Understanding DNS Sinkholes – A weapon against malware
- Sinkholes: Legal and Technical Issues in the Fight against Botnets
- Sinkholing, with reporting, using Windows DNS, Netcat, and BLAT on a Zero Dollar Budget
- How to block or sinkhole domains in BIND
- Build Securely a DNS Sinkhole Step - by - Step Powered by Slackware Linux
- Using DNS to protect clients from malicious domains
- Bind DNS Sinkhole, Elasticsearch and Logstash
- dns.py
- BlackHole DNS for Malware and Spyware
- Otras listas de dominios:
. http://pgl.yoyo.org/adservers/serverlist.php?hostformat=bindconfig&showintro=0&mimetype=plaintext
. http://malc0de.com/bl/ZONES
Básicamente un DNS sinkhole falsea los servidores DNS autorizados para hosts y dominios maliciosos y no deseados. Un administrador configura el forwarder DNS correspondiente para devolver direcciones IP falsas para estos hosts y dominios conocidos. Cuando un cliente solicita resolver la dirección de uno de estos hosts o dominios, el DNS sinkhole devuelve una dirección no enrutable o cualquier dirección excepto la dirección real. Esto deniega al cliente una conexión con el host de destino.
Veamos un claro ejemplo con bind, el servidor DNS en Linux de facto. Ya veréis lo sencilla que es una implementación básica.
Primero instalamos el software:
# apt-get install bind9
# service bind9 start
Y a continuación comprobamos cómo resuelve una dirección cualquiera de Internet:
# dig @127.0.0.1 www.google.co.uk
; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @127.0.0.1 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45058
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; ANSWER SECTION:
www.google.co.uk. 300 IN A 216.58.210.227
;; AUTHORITY SECTION:
google.co.uk. 172799 IN NS ns2.google.com.
google.co.uk. 172799 IN NS ns4.google.com.
google.co.uk. 172799 IN NS ns1.google.com.
google.co.uk. 172799 IN NS ns3.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 172800 IN A 216.239.32.10
ns2.google.com. 172800 IN A 216.239.34.10
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN A 216.239.38.10
;; Query time: 766 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 27 11:40:14 EDT 2015
;; MSG SIZE rcvd: 207
Ahora editamos el fichero de configuración (en sistemas Debian normalmente está situado en /etc/bind/named.conf.local) para especificar los dominios que queremos bloquear:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
include "/etc/bind/blacklisted.zones";
zone "example.local" {
type master;
file "/etc/bind/zones/master/example.local.db";
};
Y luego creamos el fichero especificado /etc/bind/blacklisted.zones con algunos dominios de prueba:
zone "blockeddomain.com" {type master; file "/etc/bind/blockeddomains.db";};
zone "buymalwarehere.ru" {type master; file "/etc/bind/blockeddomains.db";};
zone "s23a93884skf.net" {type master; file "/etc/bind/blockeddomains.db";};
zone "almost-somedodgeybank.com" {type master; file "/etc/bind/blockeddomains.db";};
zone "google.co.uk" {type master; file "/etc/bind/blockeddomains.db";};
Como podéis ver arriba, estamos definiendo las zonas para los que el DNS está autorizado. Cuando una consulta es recibida preguntando por el servidor DNS para resolver por ejemplo la IP de google.co.uk, el servidor proporcionará los datos del archivo asociado. En este caso, como estamos tratando a todos estos dominios para el sinkhole podemos apuntar a todos al mismo archivo de zona /etc/bind/blockeddomains.db para simplificar las cosas. Lo editaremos y añadiremos los siguientes registros:
; BIND data file for example.local
$TTL 3600
@ IN SOA ns1.example.local. info.example.local. (
2014052101 ; Serial
7200 ; Refresh
120 ; Retry
2419200 ; Expire
3600) ; Default TTL
;
A 127.0.0.1 ; esto significa que el dominio banneado será redireccionado a la IP que especifiques, en el ejemplo localhost
* IN A 127.0.0.1 ; este wildcard significa que cualquier permutación del dominio (ej. xxx.prohibido.com) será redireccionado a la IP que especifiques
AAAA ::1 ; esto significa que el dominio banneado será redirecionado la IPv6 de localhost
* IN AAAA ::1 ; este wildcard significa que cualquier permutación del dominio (ej. xxx.prohibido.com) será redirecionado a la IPv6 que especifiques
En el ejemplo hemos puesto que las peticiones se redireccionen a localhost para bloquearlas, si bien podríamos haber puesto cualquier otra IP falsa, por ejemplo de un honeypot, un NIDS u otro nodo en una darknet.
Una vez que hemos realizado todos los cambios de configuración anteriores sólo necesitamos recargar/reconfigurar el servidor DNS (service bind9 restart) y comprobar que ahora el fqdn www.google.co.uk nos devuelve una IP 127.0.0.1:
# dig @127.0.0.1 google.co.uk
; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @127.0.0.1 google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27515
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.co.uk. IN A
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 27 11:56:56 EDT 2015
;; MSG SIZE rcvd: 41
Ya está. Imaginad que acabamos de dar una IP incorrecta a un supuesto artefacto de malware que está intentando comunicarse con su C&C, es decir, hemos bloqueado su conexión de esta forma tan tonta pero a la vez tan efectiva.
Evidentemente esta implementación aunque funcional es casi una prueba de concepto. Si queréis extender un poco la funcionalidad podéis programar un cron para que se descargue la lista abierta de malwaredomains con unos 15000 dominios identificados:
curl "http://malwaredomains.lehigh.edu/files/spywaredomains.zones" | sed 's/\/etc\/namedb\/blockeddomain.hosts/\/etc\/bind\/blockeddomains.db/g' > blacklisted.zones && dos2unix blacklisted.zones
Aquí es donde radica la clave de un buen servicio DNS sinkholing, en obtener una lista muy actualizada de numerosos dominios, libre de falsos positivos. Porque estoy seguro de que, aunque la lista de malwaredomains es muy generosa, no puede compararse a la de otros servicios de pago como la de Palo Alto u OpenDNS.
Luego una vez que tenemos una sólida fuente de dominios, el resto de pasos para crearte un DNS sinkhole potente es básicamente realizar un desarrollo para el análisis de logs para alerta temprana (ya sea localmente o mediante la correlación de un SIEM), la custodia de logs para análisis forenses y la creación de frontends para facilitar su administración.
Lo iremos viendo más adelante, incluyendo la parte ofensiva mediante tentativas con fast flux o MiTM y envenenamiento si se da el caso que el sinkhole de turno no utiliza DNSSEC.
Fuentes:
- DNS sinkhole - Wikipedia, the free encyclopedia
- DNS sinkhole - The IT Law Wiki - Wikia
- Understanding DNS Sinkholes – A weapon against malware
- Sinkholes: Legal and Technical Issues in the Fight against Botnets
- Sinkholing, with reporting, using Windows DNS, Netcat, and BLAT on a Zero Dollar Budget
- How to block or sinkhole domains in BIND
- Build Securely a DNS Sinkhole Step - by - Step Powered by Slackware Linux
- Using DNS to protect clients from malicious domains
- Bind DNS Sinkhole, Elasticsearch and Logstash
- dns.py
- BlackHole DNS for Malware and Spyware
- Otras listas de dominios:
. http://pgl.yoyo.org/adservers/serverlist.php?hostformat=bindconfig&showintro=0&mimetype=plaintext
. http://malc0de.com/bl/ZONES
http://someonewhocares.org/hosts/
ResponderEliminarDesde http://malc0de.com/bl/ZONES
ResponderEliminarzone "appinformatica.com" {type master; file "/etc/namedb/blockeddomain.hosts";};
Espectacular :-?
:-O falso positivo? he estado mirando un poco y tiene pinta...
ResponderEliminarY si no uso bind, puedo bloquearlos con otra cosa?
ResponderEliminar