Servidores DNS recursivos públicos - regras do iptables


16

Executamos servidores DNS recursivos voltados para o público em máquinas Linux. Fomos usados ​​para ataques de amplificação de DNS. Existem iptablesregras recomendadas que ajudem a atenuar esses ataques?

A solução óbvia é apenas limitar os pacotes DNS de saída a um determinado nível de tráfego. Mas eu esperava encontrar algo um pouco mais inteligente, para que um ataque bloqueie o tráfego no endereço IP da vítima.

Procurei conselhos e sugestões, mas todas parecem "não executar servidores de nomes recursivos voltados para o público". Infelizmente, estamos de volta a uma situação em que coisas que não são fáceis de mudar vão quebrar se não o fizermos, e isso se deve a decisões tomadas mais de uma década atrás antes que esses ataques fossem um problema.


2
As pessoas que o aconselham a não administrar um servidor de nomes recursivo público estão certas. Você pode explicar por que é aparentemente necessário?
Alnitak

11
@Alnitak: Coisas que não são fáceis de mudar vão quebrar se não o fizermos devido a decisões tomadas mais de uma década atrás.
David Schwartz

Sim, eu vi isso na pergunta original. Você pode explicar por que essa configuração é necessária?
Alnitak

2
@ Alnitak: Porque coisas que não são fáceis de mudar dependem disso. Estes são dispositivos que têm seu firmware gravado e são implantados em todo o mundo, muitos em instalações seguras às quais nem sequer temos acesso.
David Schwartz

Seus sistemas embarcados oferecem suporte à resolução de nomes TCP em vez de UDP? Em caso afirmativo, quão fácil seria desativar o UDP para resolução?
Mike Pennington

Respostas:


9

Todo esse tipo de coisa cheira a um cenário "não é meu problema" que não é realmente sua culpa e deve / pode ser 100% resolvido tomando a ação apropriada, independentemente de quão "difícil" ou "difícil" seja, e que está encerrando sua servidor recursivo aberto .

Eliminar gradualmente: informe aos clientes que esse servidor está saindo do ar na data X. Após esse período, eles precisam instalar um patch (supondo que você tenha um) para impedir o uso do servidor DNS. Isso é feito o tempo todo. Administradores de sistemas, administradores de rede, pessoal de helpdesk, programadores? Nós entendemos ; essa coisa de fim da vida útil acontece o tempo todo, porque seu procedimento operacional padrão para um fornecedor / provedor de serviços / parceiro nos diz para parar de usar algo após a data X. Nem sempre gostamos, mas é um fato da vida em TI.

Você diz que não tem esse problema nos dispositivos atuais, portanto, suponho que você tenha resolvido esse problema com uma atualização ou patch de firmware. Eu sei que você disse que não pode tocar no dispositivo, mas certamente eles podem? Quero dizer, se eles estão permitindo que essas caixas telefonem basicamente para casa, você não pode ser tão anal sobre quem está fazendo o que com seus dispositivos; você pode ter uma configuração de proxy reverso, pelo que eles sabem; então, por que não instalar um patch que conserte isso ou peça para eles usarem seus próprios servidores DNS . Certamente o seu dispositivo suporta DHCP; Não consigo pensar em um dispositivo de rede (não importa quantos anos / frágil / ímpar) não funcione .

Se você não pode fazer isso, a próxima coisa a fazer é controlar quem pode acessar seu servidor recursivo : você diz que é "difícil dizer" quem o está usando e como, mas é hora de descobrir com certeza e começar a perder tráfego. não é legítimo.

Essas são organizações "quase militares / governamentais", certo? Bem, eles provavelmente fazem parte de um netblock legítimo que eles possuem; esses dispositivos não são roteadores domésticos atrás de IPs dinâmicos. Descobrir. Entre em contato com eles, explique o problema e como você está economizando muito dinheiro, não forçando a substituição de firmware ou produto, se eles puderem confirmar o endereço IP / bloco de rede / IP que o dispositivo usará para acessar o servidor DNS.

Isso é feito o tempo todo: tenho vários clientes que restringem o acesso à extranet ou ouvintes HL7 para parceiros de assistência médica dessa maneira; não é tão difícilpara que eles preencham um formulário e forneçam o IP e / ou o bloco de rede, eu deveria estar esperando tráfego: se eles desejam acessar a extranet, precisam fornecer um IP ou sub-rede. E isso raramente é um alvo em movimento, por isso não é como se você fosse inundado com centenas de solicitações de alteração de IP todos os dias: grandes redes hospitalares do campus que possuem seus próprios bloqueios de rede com centenas de sub-redes e milhares e milhares de IPs de host normalmente me dão um punhado de endereços IP ou uma sub-rede que eu deveria estar esperando; novamente, esses não são usuários de laptops vagando pelo campus o tempo todo, então por que eu esperaria ver pacotes de origem UDP a partir de um endereço IP em constante mudança? Claramente, estou fazendo uma suposição aqui, mas aposto que não é tanto quanto você pensa em <100s de dispositivos. Sim, será uma ACL longa e sim,

Se, por algum motivo, os canais de comunicação não estiverem abertos (ou alguém tem muito medo ou não pode se incomodar em entrar em contato com esses proprietários de dispositivos herdados e fazer isso corretamente), é necessário estabelecer uma linha de base do uso / atividade normal para poder formular alguma outra estratégia que ajudará (mas não impedirá) sua participação em ataques de amplificação de DNS.

Uma execução demorada tcpdumpdeve funcionar com a filtragem no UDP 53 de entrada e com o log detalhado no aplicativo do servidor DNS. Eu também gostaria de começar a coletar informações de endereços IP / netblocks / geoIP de origem (todos os seus clientes nos EUA? Bloqueiam todo o resto) porque, como você diz, não está adicionando novos dispositivos, apenas fornece um legado serviço às instalações existentes.

Isso também ajudará você a entender quais tipos de registro estão sendo solicitados e para quais domínios, por quem e com que frequência : para que a amplificação de DNS funcione conforme o planejado, o invasor precisa poder solicitar um tipo de registro grande (1) a um domínio funcional (2).

  1. "tipo de registro grande": seus dispositivos precisam de registros TXT ou SOA para serem resolvidos pelo servidor DNS recursivo? Você pode especificar quais tipos de registro são válidos no seu servidor DNS; Acredito que seja possível com o BIND e, talvez, com o DNS do Windows, mas você teria que fazer algumas escavações. Se o servidor DNS responder SERVFAILa qualquer registro TXT ou SOA, e pelo menos essa resposta for uma ordem de magnitude (ou duas) menor que a carga útil pretendida. Obviamente, você ainda é "parte do problema" porque a vítima falsificada ainda está recebendo essas SERVFAILrespostas do seu servidor, mas pelo menos você não as está martelando e talvez seu servidor DNS seja "excluído" da (s) lista (s) coletada (s) os bots usam com o tempo para não "cooperar".

  2. "domínio em funcionamento": você poderá colocar na lista de permissões apenas domínios válidos. Eu faço isso nas configurações reforçadas do meu data center, onde os servidores precisam apenas do Windows Update, Symantec etc. para funcionar. No entanto, você está apenas mitigar os danos que está causando neste ponto: a vítima ainda iria ficar bombardeados com NXDOMAINou SERVFAILrespostas a partir do servidor porque o servidor seria ainda respondem à fonte forjada IP. Novamente, o script Bot também pode atualizar automaticamente sua lista de servidores abertos com base nos resultados, portanto, isso pode remover o servidor.

Eu também usaria alguma forma de limitação de taxa, como outros sugeriram, no nível do aplicativo (ou seja, tamanho da mensagem, solicitações por limitações do cliente) ou no nível do firewall (consulte as outras respostas), mas, novamente, você vai precisa fazer algumas análises para garantir que você não esteja matando tráfego legítimo.

Um sistema de detecção de intrusões que foi sintonizado e / ou treinado (novamente, precisa de uma linha de base aqui) deve ser capaz de detectar tráfego anormal ao longo do tempo por fonte ou volume, mas provavelmente exigiria babysitting / ajuste / monitoramento regulares para evitar falsos positivos e / ou veja se está realmente impedindo ataques.

No final do dia, você deve se perguntar se todo esse esforço vale a pena ou se deve apenas insistir para que a coisa certa seja feita e que isso elimine o problema em primeiro lugar.


11
Bem, um patch não é possível. Não temos mais hardware de trabalho para algumas plataformas. Quanto ao netblock do qual eles esperam tráfego, eles geralmente não sabem. Não sei se você aprecia o quão incomum é o ambiente em que alguns desses dispositivos estão. Alguns estão em redes privadas onde eles têm seu próprio esquema de DNS e talvez não haja mais ninguém por perto que saiba como o sistema foi configurado. acima. Basicamente, apenas precisamos mantê-lo funcionando até o término do contrato.
David Schwartz

Então, o melhor que você pode fazer é solucionar o problema da limitação de taxa, a menos que esteja disposto a fazer alguma análise. Honestamente, se esses sistemas são estáticos / negligenciados, as chances são de que sua pegada não mude e você provavelmente poderá se safar das ACLs da camada 3 por IP de origem depois de coletar todas elas.
Gravyface

11
Estou pensando em uma abordagem híbrida. IPs da lista de permissões que podemos identificar (talvez os sujeite a um limite alto). Submeter outros IPs a um limite bastante baixo. Faça uma auditoria periódica para verificar se algum IP precisa ser incluído ou removido da lista de permissões.
David Schwartz

@DavidSchwartz, você pode nem precisar de um limite alto. Novamente, ter uma linha de base de tráfego legítimo ajudaria imensamente.
gravyface

6

Depende do tipo de limitação de taxa que você deseja fazer.

A limitação de taxa com iptablesé realmente mais destinada à limitação de pacotes recebidos, uma vez que os pacotes até o limite corresponderão ao filtro e terão o destino especificado aplicado (por exemplo, ACCEPT). Presumivelmente, você teria um destino subsequente para DROPpacotes não correspondidos pelo filtro. E embora iptablestenha um QUEUEdestino, ele simplesmente passa o pacote para o espaço do usuário, onde você precisa fornecer seu próprio aplicativo de enfileiramento. Você também pode classificar o limite de pacotes de saída, mas poucas pessoas realmente querem começar a eliminar o tráfego de saída.

iptables queda do limite de taxa:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

Usar em hashlimitvez de limitfornecerá o limite de taxa por IP de destino. Ou seja, cinco pacotes para 8.8.8.8 que atingem o limite impedirão o envio de pacotes para 8.8.4.4, enquanto hashlimitse 8.8.8.8 estiver no máximo, você ainda poderá alcançar 8.8.4.4, que soa mais como o que você deseja.

Se você não deseja que pacotes além do limite sejam descartados, o que você realmente deseja é tc. tcregulará o fluxo para obter um fluxo estável e agradável, em vez de muito tráfego estourado. No lado de entrada, os pacotes são entregues ao aplicativo mais lentamente, mas todos chegarão em ordem. Nos pacotes de saída, o aplicativo será deixado o mais rápido possível, mas colocado no fio em um fluxo consistente.

Não usei tcmuito, mas aqui está um exemplo de ICMP de limitação de taxa, que você provavelmente pode adaptar facilmente ao DNS.


11
Meu artigo em francês sobre esta configuração (usado para um resolvedor aberta real): bortzmeyer.org/rate-limiting-dns-open-resolver.html
Bortzmeyer

4

Aqui está uma coisa que você pode fazer para reduzir potencialmente as respostas a consultas falsas, mas é preciso um pouco de trabalho:

Primeiro, dê uma olhada no seu log do canal de segurança e encontre um endereço IP que está sendo falsificado.

Em seguida, execute um tcpdump usando o IP de origem (10.11.12.13) assim:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

Você obterá algo como isto:

18: 37: 25.969485 IP (tos 0x0, ttl 52, id 46403, deslocamento 0, sinalizadores [nenhum], proto: UDP (17), comprimento: 45) 10.11.12.13.51169> 01.02.03.04.domínio: 4215+ ANY ? . (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w ..
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

Agora a parte divertida! Abra o rfc1035 em http://tools.ietf.org/html/rfc1035 e vá para a seção 4.1.1.

É hora de traduzir os resultados do tcpdump e descobrir um padrão que podemos usar para criar um filtro no nível de pacote.

O ID do cabeçalho começa em 0x1C, então temos alguns sinalizadores em 0x1E, QDCOUNT em 0x20, ANCOUNT em 0x22, NSCOUNT em 0x24 e ARCOUNT em 0x26.

Isso deixa a pergunta real em 0x28, que neste caso é nula (ROOT) para o NOME, 0xFF para QTYPE = ANY e 0x01 para QCLASS = IN.

Para resumir uma longa história, descobri que adicionar as seguintes regras do iptables bloqueia mais de 95% das consultas falsificadas que estão solicitando QUALQUER registro EM ROOT:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

Sua milhagem pode variar ... espero que isso ajude.


3

Usando tce enfileirando disciplinas no linux para a porta de saída 53 UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

Irá configurá-lo com um disclimite de 10mbit para qualquer pacote com a marca de firewall '1'. As marcações do firewall são internas apenas ao firewall e não modificam o pacote. Apenas o manuseio do pacote pela disciplina de enfileiramento. Aqui está como você usa iptablespara fazer as marcações do firewall:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

Modifique ao seu gosto para excluir sub-redes e / ou destinos confiáveis. A -o eth0limita a formação de apenas pacotes de saída. Espero que isto ajude.


DNS usa UDP e TCP ...
Patrick Mevzek

1

Eu tentaria compor uma lista de todos os clientes que dependem dos seus resolvedores recursivos externos. Comece com um dia ou mais de rastreamento de pacotes nas caixas DNS. A partir daí, comece a criar regras do iptables para permitir o tráfego que você reconhece e autoriza. O padrão será eventualmente reduzir o tráfego para 53 / tcp e 53 / udp. Se isso quebrar alguma coisa, ajuste suas regras.


1

dependendo da posição da rede em que você está [tendo vários feeds bgp ou estando no 'final' da internet - como uma rede stub], você pode tentar algo como uRPF para impedir a falsificação de endereços de origem.

outra fonte de informação.


Você só pode usar o uRPF para impedir que seus próprios clientes falsifiquem. Portanto, a única maneira de o uRPF me fazer bem seria se eu conseguisse que todos usassem. Não estou preocupado com ataques lançados por meus próprios clientes. Estou preocupado com os ataques vindos da Internet. Não há como executar o uRPF em uma conexão não cliente. O roteamento assimétrico é a norma (se você tiver mais de um link real) ou todas as rotas apontam para essa conexão (se você tiver apenas um link real).
22412 David Schwartz

@DavidSchwartz eu decidi cancelar a exclusão da minha resposta. Eu entendo que não é muito útil no seu caso, mas pode ser útil para outras pessoas. interessante caso btw - estou curioso sobre outras respostas por vir.
PQD

1

Esses dispositivos ainda estão sob um contrato de suporte? Nesse caso, entre em contato com seus clientes. Informe a eles que a Internet evoluiu um pouco na última década e, para continuar fornecendo resolução de nomes para esses dispositivos, você precisará conhecer o IP do SRC para esperar consultas. Defina uma data ~ 6 meses no futuro, momento em que você não poderá mais atender clientes desconhecidos e cumpra-a. Isso é bastante comum na indústria. Se esses dispositivos não estiverem mais sob um contrato de suporte ... isso soa como uma decisão de negócios. Quanto tempo sua empresa pretende gastar recursos em produtos antigos que não geram mais receita?

Eles parecem dispositivos especializados, são tão especializados que você pode prever razoavelmente em quais domínios esperar consultas legítimas? bind suporta exibições, crie uma exibição pública que faça recursão apenas para esses domínios.

Use isso como uma oportunidade de aprendizado; se ainda não o fez, pare de lançar produtos nos quais você não tem a capacidade de corrigir bugs. Isso é o que é isso, um bug. Um que certamente elimine esse dispositivo prematuramente, mais cedo ou mais tarde.


11
Lendo algumas outras respostas. Você diz que não pode nem mesmo desenvolver um patch porque não possui mais o hardware para testá-lo. Sendo assim, qual é a validade de qualquer contrato de suporte atual? O que você faria se um desses dispositivos 'suportados' tivesse uma falha de hardware? Faça a mesma coisa aqui.
Jason Preston

Nós não suportamos o hardware. Nem sequer podemos tocar no hardware. Se o hardware falhar, é destruído e substituído. Apoiamos a infraestrutura remota e precisamos fazê-lo por contrato até 2015. (Não é que não tenhamos o hardware para testar, é que não podemos fazer o teste. Quaisquer alterações requerem uma aprovação). já não é possível obter porque o padrão de aprovação expirou Bem-vindo ao lidar com governos)..
David Schwartz

1

De nanog em algum lugar, isso:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

Isto não é o ideal. Talvez seja melhor permitir menos pacotes por segundo e ter uma explosão maior.


-1

Aqui está uma solução que eu usei algumas vezes contra ataques DDOS, não é perfeita, mas me ajudou. A solução consiste em um script que está sendo chamado a cada N minutos (como 1,2,3 etc. minutos) pelo cron e bloqueia os IPs que estão criando um número de conexões maiores que o especificado no script:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp

3
Eu não acho que funcionará: o DNS é uma solicitação / resposta sobre o UDP e não deixa conexões abertas.
Bortzmeyer
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.