Fornecendo redirecionamento de DNS para o servidor honeypot para domínios inválidos conhecidos

Question

Atualmente estou executando o BIND no RHEL 5.4 e estou procurando uma maneira mais eficiente de fornecer redirecionamento de DNS a um servidor honeypot para uma lista grande (mais de 30.000) de domínios proibidos.

Nossa solução atual para esse requisito é incluir um arquivo contendo uma declaração do mestre da zona para cada domínio bloqueado no named.conf. Posteriormente, cada uma dessas declarações de zona aponta para o mesmo arquivo de zona, que resolve todos os hosts desse domínio para nossos servidores de honeypots. Basicamente, isso nos permite capturar qualquer tentativa de "home phone home" por malware que possa se infiltrar nos sistemas internos.

O problema com essa configuração é o grande tempo gasto para carregar todos os 30.000+ domínios, bem como o gerenciamento do próprio arquivo de configuração da lista de domínios ... se algum erro entrar nesse arquivo, o servidor BIND falhará ao iniciar , tornando a automação do processo um pouco assustadora. Então, estou procurando algo mais eficiente e potencialmente menos propenso a erros.

entrada do named.conf:

include "blackholes.conf";

Exemplo de entrada

blackholes.conf:

zone "bad-domain.com" IN { type master; file "/var/named/blackhole.zone"; allow-query { any; }; notify no; };

entradas blackhole.zone:

$INCLUDE std.soa

@ NS ns1.ourdomain.com.
@ NS ns2.ourdomain.com.
@ NS ns3.ourdomain.com.

                       IN            A                192.168.0.99
*                      IN            A                192.168.0.99

    

Answer 1

Em teoria você pode evitar o tempo de carregamento lento tornando sua lista negra parte de seu arquivo de dicas de raiz (por exemplo, via $INCLUDE ) e alterando esse arquivo de hint para um %código%. Esse último bit é necessário para impedir que o seu servidor baixe as dicas de raiz real da Internet.

por exemplo. em master :

a.root-servers.net.  IN A ....
m.root-servers.net.  IN A ....
$INCLUDE blackhole.zone

e, em seguida, em named.ca :

$ORIGIN example.com.
@ IN 192.168.0.99
* IN 192.168.0.99

$ORIGIN example.net.
@ IN 192.168.0.99
* IN 192.168.0.99

; ad-infinitum

Não há necessidade real de registros NS ou declarações blackhole.zone separadas para cada zona "blackholed" - você está efetivamente inserindo dados autoritativos falsos em sua cópia local da zona raiz. Apenas certifique-se de baixar a zona raiz real ocasionalmente!

Depois, basta ir com a sugestão @ syn de executar zone antes de recarregar e / ou reiniciar.

NB: eu não testei isso.

    

Answer 2

Editar : Desculpe por não ler bem sua pergunta. Eu proponho as mesmas coisas que você. Talvez você possa incluir um arquivo gerado a partir de um banco de dados?

Eu tenho um arquivo dropDomain com:

$TTL 3600       ; 1 hour
@               IN SOA  xxxxxxxx.fr. dnsmaster.xxxxxxxx.fr. (
                2009112001 ; serial 20yymmdd+nn
                                900        ; refresh (15 minutes)
                                600        ; retry (10 minutes)
                                86400      ; expire (1 day)
                                3600       ; minimum (1 hour)
                                )
                        NS      dns1.xxxxxxxx.fr.
                        NS      dns2.xxxxxxxx.fr.
                        MX      0       smtp.xxxxxxx.fr.

*                       A       127.0.0.1

; vim:filetype=bindzone

Depois, adiciono os domínios da minha lista em named.conf.local:

# Master pour les zones que l'on ne veut plus resoudre (pirates, virus, prise en main a distance...)
zone "zzzzzzz.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "yyyyyyy.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "ttttttt.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };

Eu não preciso defini-lo no arquivo de zona, é genérico.

    

Answer 3

Já considerou uma alternativa ao BIND? Ainda não usei nenhum, mas existem alternativas baseadas no MySQL com frontends da web, como PowerDNS com Poweradmin. Isso pode tornar as atualizações menos propensas a erros e arriscadas. O PowerDNS ainda tem uma ferramenta para converter um arquivo de zona BIND em SQL para migração.

Além disso, posso perguntar se essa lista está disponível publicamente? Estou muito interessado nisso mesmo.

    

Answer 4

Não encontrou uma boa maneira de eliminar a necessidade de carregar cada domínio em sua própria zona, mas o uso do seguinte comando rndc elimina a preocupação de fazer com que o servidor falhe no caso de uma entrada malformada.

rndc reconfig

Uma reinicialização / reinicialização total do servidor ainda resultará em falha na inicialização.