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).
"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".
"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.