DNS Open Resolvers con IPv4
O CSIRT do LACNIC, conjuntamente com o CSIRT CEDIA, estão pondo em prática o projeto “DNS Open Resolvers com IPv4” a fim de conhecer o estado atual da região, identificar os opens resolvers e, de forma proativa, alertar e recomendar uma possível correção da configuração deste serviço.
Ter servidores DNS Open Resolvers é muito negativo, tanto para quem deixa o serviço aberto quanto para a segurança na Internet em geral. Estes servidores são usados como vetor de ataques de DDoS por amplificação, já que a partir de uma mensagem de consulta pequena pode ser obtida uma resposta muito maior. Desta forma, esse servidor DNS se torna um amplificador de tráfego muito poderoso, já que suas consultas amplificadas podem ser direcionadas para um IP específico, que receberia todo esse volume de tráfego, causando a indisponibilidade de seus serviços. Para este ataque, nem é necessário que o hardware seja controlado pelo atacante.
Um servidor DNS recursivo apenas deveria responder consultas (queries) para todos os clientes que estiverem dentro de sua mesma rede, rejeitando qualquer outro que venha de fora.
Como resolver isso?
É altamente recomendável reconfigurar os servidores DNS/Resolver; a seguir, algumas ajudas para fazê-lo:
* Deve responder apenas a seus clientes e não responder a consultas de IPs que estejam fora de sua rede [no BIND, isso é feito definindo um grupo limitado de computadores na regra “allow-query” (“permitir consultas”)]. No exemplo a seguir, somente as redes 192.168.196.0/24 e 2001:db8::/32 poderão fazer queries (consultas). Pode colocar mais redes separadas por ponto e vírgula (;):
allow-query {
192.168.196.0/24;
2001:db8::/32;
localhost;
}
}
* Para servir apenas domínios que fazem parte da sua zona autoritativa (no BIND, isso é feito definindo um conjunto limitado de hosts na regra “allow-query” para o servidor geral, mas configurando “allow-query” em “any” para cada zona). Exemplo:
allow-query {
192.168.196.0/24;
2001:db8::/32;
localhost;
}
}
type master;
file “example.com.db”;
allow-query { any; };
}
}
* No unbound pode obter o mesmo comportamento usando a diretiva access-control (controle de acesso) no arquivo unbound.conf. Ficaria da seguinte forma (adicione tantas diretivas de access-control quanto redes tiver):
server:
access-control: 192.168.196.0/24 allow
access-control: 2001:db8::/32 allow
* No caso de equipamentos mikrotik, podemos parar de resolver terceiros desmarcando o checkbox: “permitir pedidos remotos”:
Ou desde o painel de controle web do mikrotik vamos para IP→ DNS e desmarcamos “Allow Remote Requests”:
Além disso, se a sua empresa for um ISP, verifique a configuração de sua rede e certifique-se de não permitir que o “spoofed traffic” (que pretende ser de endereços IP externos) saia da sua rede. As redes e equipamentos que permitem o “spoofed traffic” (tráfego com endereços IP falsificados) tornam este e outros tipos de ataques possíveis.
* Se você usar openwrt, dd-wrt ou um equipamento Linux, possivelmente esteja usando dnsmasq. No caso de dnsmasq a solução é impedir que pacotes UDP entrem desde a Internet ao porto 53 na nossa interface WAN. Isso pode ser configurado no firewall de seu openwrt/dd-wrt ou usando iptables no seu equipamento Linux:
iptables -I INPUT -p udp –dport 53 -j DROP
Como verificar se as minhas alterações foram efetivas?
Depois de fazer as alterações necessárias, você pode acessar https://openresolver.com/ e verificar se o IP que lhe informamos é ou não é um open resolver.
Open Resolvers com IPv6
Se você tiver Servidores DNS configurados para IPv6 ou dual stack, sugerimos que consulte informações e recomendações em: