Relatório livre: Avere FXT com FlashMove e FlashMirror
Poderia defender o Domain Name System (DNS) infra-estrutura contra ataques de amplificação ser tão simples como mudar os protocolos de resolvedores? Provavelmente não - mas um experimento realizado em APNIC tem implicações de longo alcance.
Como Geoff Huston, cientista-chefe da APNIC, escreve , amplificação ataques de DNS são fáceis de lançar e pode ser relativamente difícil de defender.
A facilidade com que um ataque pode ser lançado é praticamente construído em DNS: um ataque de amplificação - uma pequena consulta retornando resposta grande - é muito pouco diferente de "DNS se comportando como deveria". Isso é muito bonito a característica de DNS que foi explorada no ataque Cloudflare no início deste ano.
Com muitos resolvedores abertas do mundo, e muito poucas redes execução egresso fonte filtragem especificada no BCP38 documento de melhores práticas de autoria, em 2000, os ataques de amplificação provavelmente irá continuar.
O resultado, escreve ele, é que o UDP "permite que um atacante para montar um ataque de reflexão por cooptar um grande conjunto de resolvedores abertas para enviar suas respostas para o sistema alvo, usando consultas UDP cujo endereço IP de origem é o endereço IP de a vítima. "
Olhando para esta "vulnerabilidade abrangente para a Internet", o Dr. Huston - atualmente cientista chefe da APNIC - conduziu um experimento que olha para um aspecto quase esquecido das especificações DNS.
Como ele descreve, quase todas as transações DNS no mundo hoje usa UDP para consultas DNS. No entanto, a especificação de DNS, RFC 1123, permite UDP ou TCP para ser usado.
TCP caiu fora do uso para a maioria das operações de DNS, observa ele, mas ele tem uma característica atraente na Internet de hoje: TCP não é vulnerável a ataques de amplificação. Isso é porque é stateful, enquanto que o UDP é apátrida. Estabelecimento da sessão do TCP iria quebrar o aspecto reflexão de ataques de DNS.
Neste exemplo simplificado, mensagens UDP apátridas
spoofing o gatilho endereço de destino número enorme de
Respostas DNS, em um ataque de Denial-of-Service
"Se um invasor tentar abrir uma sessão TCP usando um endereço da vítima pretendida IP de origem, a vítima iria receber um pacote IP curto (IP e só cabeçalho TCP, que é um pacote de 40 bytes) contendo apenas o SYN e flags ACK definida. Como o sistema de vítima não tem estado pré-existente para esta conexão TCP, ele irá descartar o pacote ", escreve ele. Com nenhuma forma de manter uma sessão de um endereço falso, o ataque irá falhar.
TCP, no entanto, cai a sessão devido
o alvo não responder com um ACK
Poderia reconfigurar o DNS para usar TCP ser uma solução prática para o problema de ataque de amplificação? Para isso, APNIC configurar um experimento para testar uma pergunta: "Quantos clientes foram capazes de mudar com sucesso para TCP após o recebimento de uma resposta truncada em UDP?"
A experiência de APNIC
A mudança de configuração no resolvedor teste era bastante simples: ao receber uma consulta UDP, ele enviou uma resposta truncada, o que deve provocar o cliente a mudar para o TCP. Sem contar todas as nuances do experimento, houve alguns encorajadores e alguns resultados não tão animadores.
No lado positivo: apenas 2,6 por cento de 2 milhões de clientes (ainda "grande o suficiente para ser significativo") não conseguiu recuperar suas consultas quando redirecionado para TCP.
Investigação das falhas revelou que os 2 milhões de clientes utilizaram mais de 80.000 resolvedores, e destes, houve uma taxa muito maior de falha - 17 por cento.
Para obter uma alça sobre o que tudo isso significa, The Register falou APNIC cientista George Michaelson, que trabalhou com Huston no experimento.
Michaelson explicou há um debate debate TCP-versus-UDP ativa na comunidade DNS, muitas vezes centrada na preocupação de que escalar o lado do servidor para usar TCP exclusivamente seria impossível, já que as grandes resolvedores executar cargas de trabalho de 13 mil solicitações por segundo ou mais.
O experimento APNIC olhou para o outro lado da questão: qual seria a taxa de falha seja, todo o caminho para os clientes? A partir desse ponto de vista, uma taxa de falha de 2 por cento iria levantar uma questão séria para os fornecedores: "É um em cinquenta e um número que você está feliz com isso?"
Embora o experimento não podia ver todo o caminho até os clientes, Michaelson acredita que há um grande número de PME e em casa kit de rede que não consegue lidar com a fallover de TCP para solicitações de DNS.
"Talvez o resolvedor está atrás de um firewall de idade, por exemplo." Há sugestões, segundo ele, que as pessoas que executam "magia antiga" em seus firewalls têm listas de controle de acesso que bloqueiam TCP sobre DNS. E um monte de kit de rede doméstica "está executando uma pilha que não mudou em 15 anos e não pode lidar com isso", acrescentou Michaelson.
Mas isso não é tudo: as questões também pode ocorrer com base no sistema operacional do usuário final está sendo executado. "Vanilla OSX, por exemplo, só pode fazer DNS sobre UDP", acrescentou.
Não é uma questão meramente acadêmica, porque, mesmo se o mundo de DNS não de repente mudar para o TCP como uma questão de política, alguns usuários podem encontrar-se refém de tendências em tecnologia: a mudança para o IPv6 eo lançamento slow-motion-avalanche de DNSSEC.
Estes tornam-se problemática, Michaelson, porque eles criam grandes respostas para perguntas - e pode, portanto, desencadear uma fallover automático para TCP. Isso porque, se uma operação de DNS excede 512 bytes, o UDP envia uma resposta "truncado" para indicar que o TCP deve ser usado.
Como Michaelson explicou, "se não há mais DNSSEC, há grandes pacotes mais".
"Por exemplo, se o governo brasileiro decide assinar. Gov.au haverá mais DNSSEC. E isso significa que há mais DNS-sobre-TCP descendo a linha.
"Nós absolutamente precisamos DNSSEC - queremos uma estrutura que permite que você obtenha a confiança segura na pessoa que você está falando." ®
Nenhum comentário:
Postar um comentário