www.ietf.org rfc rfc5358

25/02/2015 www.ietf.org/rfc/rfc5358.txt

data:text/html;charset=utf8,%3Cpre%20style%3D%22color%3A%20rgb(0%2C%200%2C%200)%3B%20fontstyle%3A%20normal%3B%20fontvariant… 1/7

Rede Grupo de Trabalho J. DamasPedido de Comentários: 5358 ISCBCP: 140 F. NevesCategoria: melhores práticas correntes Registro.br Outubro 2008

Prevenção do uso de Recursivos Nameservers em ataques Refletores

Status do presente memorando

Este documento especifica uma Internet Melhores Práticas para a atual Comunidade Internet, e solicita discussão e sugestões para melhorias. A distribuição deste memorando é ilimitado.

Resumo

Este documento descreve maneiras de prevenir o uso de padrão configurado servidores de nomes recursiva como refletores em Denial of Service (DoS) ataques. Ele fornece configuração recomendada como medidas para mitigar o ataque.

Índice

1. Introdução. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Documento Terminologia. . . . . . . . . . . . . . . . . . . . . 2 3. Descrição do problema. . . . . . . . . . . . . . . . . . . . . . 2 4. Configuração recomendada. . . . . . . . . . . . . . . . . . . 4 5. Considerações de segurança. . . . . . . . . . . . . . . . . . . . 5 6. Agradecimentos. . . . . . . . . . . . . . . . . . . . . . . . 5 7. Referências. . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Referências normativas. . . . . . . . . . . . . . . . . . . 5 7.2. Referências informativo. . . . . . . . . . . . . . . . . . 6

Damas & Neves melhores práticas correntes []

RFC 5358 Prevenir Rec. NS no refletor Ataques outubro 2008

1. Introdução



Recentemente, DNS [RFC1034] tem sido apontado como um fator importante para o geração de grandes quantidades de tráfego de rede usados em Denial of Serviço (DoS). Estes ataques, chamados ataques refletor, são não devido a qualquer falha em particular na concepção de DNS ou o seu implementações, exceto que DNS depende fortemente de UDP, o fácil abuso de que está na origem do problema. Os ataques têm preferencialmente usado DNS devido a configurações padrão comuns que permitir a fácil utilização de servidores de nomes recursiva abertas que fazem uso de tal configuração padrão.

Além disso, devido ao pequeno potencial de resposta da consulta‐large do Sistema DNS, é fácil de produzir grande amplificação da fonte tráfego como refletido tráfego para as vítimas.

Servidores DNS autoritários que não fornecem recursão para clientes também pode ser usado como amplificadores; No entanto, o potencial de amplificação é muito reduzida quando autoritária servidores são usados. É igualmente impraticável para restringir o acesso a servidores autorizados a um subconjunto da Internet, uma vez que o seu funcionamento normal depende de eles serem capaz de servir um público amplo; daí, as oportunidades para mitigar a escala de um ataque, modificando servidor autoritário configurações são limitados. Recomendações deste documento são preocupado com apenas servidores de nomes recursivos.

Neste documento, descrevemos as características do ataque e recomendar as configurações de servidor DNS que aliviam especificamente o problema descrito, enquanto aponta para a única solução real: o implantação em larga escala de penetração de filtragem para evitar o uso de falsificado Endereços IP [BCP38].

2. Documento Terminologia

As palavras‐chave "deve", "não deve", "necessário", "deverá", "não", "Deveria", "não deve", "recomendados", "MAIO", e "opcionais" na presente documento devem ser interpretados como descrito em [RFC2119].

3. Descrição do problema

Porque a maioria do tráfego DNS é apátrida pelo design, um invasor pode iniciar um ataque de negação de serviço da seguinte forma:

1. O atacante começa configurando um registro em qualquer zona que ele tem acesso, normalmente com grande RDATA e Time to Live (TTL).

Damas & Neves melhores práticas correntes [Página 2]


2. Aproveitando clientes em redes não BCP38, o atacante em seguida, artesanato uma consulta usando o endereço de origem de seu alvo vítima e envia para um servidor de nomes recursivo aberto.

3. Cada servidor de nomes recursivo aberto prossegue com a resolução, armazena o registro, e, finalmente, envia‐lo para o destino. Depois Nesta primeira pesquisa, o acesso aos servidores de nomes de autoridade é normalmente não é mais necessário. O registro permanecerá em cache no o servidor de nomes recursivo aberto para a duração do TTL, mesmo se ele é excluído da zona.



4. Limpeza do fuso pode, dependendo da aplicação utilizada no servidor de nomes recursivo aberto, pagar uma maneira de limpar o armazenado em cache registro do servidor de nomes recursivo aberto. Isso faria possivelmente envolvem consultas atraindo o servidor de nomes recursivo aberto a informação de pesquisa para o mesmo nome que está a ser utilizado no amplificação.

Uma vez que as características do ataque normalmente envolvem um baixo volume de pacotes, entre todos os tipos de atores, além da vítima, é improvável que qualquer um deles iria perceber o seu envolvimento com base em padrão de tráfego muda.

Aproveitando‐se de um servidor de nomes recursivo aberto que suporta EDNS0 [RFC2671], o fator de amplificação (resposta pacote de tamanho / query tamanho do pacote) pode ser em torno de 80. Com este factor de amplificação, uma relativamente pequeno exército de clientes e servidores de nomes recursiva aberto poderia gerar gigabits de tráfego em direção à vítima.

Com o comprimento crescente de respostas DNS autoritários derivado de implantação de DNSSEC [RFC4033] e NAPTR registros de recursos como utilizados em serviços ENUM, servidores autoritários acabará por ser mais útil como atores desse tipo de ataque de amplificação.

Mesmo que este ataque amplificação só é possível devido à não‐ implantação de BCP38, é mais fácil de alavancagem por causa do histórico razões. Quando a Internet era uma comunidade muito mais unida, alguns implementações de servidor de nomes foram disponibilizados com padrão configurações que, quando usado para servidores de nomes recursiva, fizeram a servidor acessível a todos os hosts na Internet.

Durante anos, esta foi uma configuração conveniente e útil, possibilitando maior disponibilidade de serviços. Como este documento tem como objetivo fazer aparente, agora é muito melhor do que estar consciente da própria serviços de servidor de nomes e foco a prestação de serviços na público‐alvo desses serviços ‐ sejam eles um campus universitário, uma empresa, ou os clientes de um ISP. O público‐alvo também inclui operadores de pequenas redes e gerentes de servidores privados que



decidir operar servidores de nomes com o objectivo de optimizar o seu DNS serviço, uma vez que estes são mais propensos a usar as configurações padrão, como enviado por implementadores.

4. Configuração recomendada

Nesta seção descrevemos a melhores práticas correntes de operação servidores de nomes recursiva. Seguindo essas recomendações reduziria as chances de qualquer servidor de nome recursiva a ser utilizado para o geração de um ataque de amplificação.

A recomendação genérica para os operadores de servidor de nomes é usar o meios fornecidos pela implementação de escolha para fornecer recursiva nome do serviço de pesquisa para apenas os clientes pretendidos. Cliente autorização geralmente pode ser feito de várias maneiras:

o endereço IP de autorização baseado. Use o endereço IP de origem do Consultas DNS e filtrá‐los através de uma lista de controle de acesso (ACL) para atender apenas os clientes pretendidos. Isto é facilmente aplicada se



área de serviço do servidor de nomes recursiva é um IP fixo razoavelmente intervalo de endereços que estão protegidos contra falsificação de endereço externo, geralmente a rede local.

o Incoming interface de seleção de base. Use a interface de entrada para a consulta como um discriminador para selecionar quais os clientes estão a ser servido. Isto é de particular aplicabilidade para SOHO (Small Equipamentos de escritório, Home Office), tais como roteadores de banda larga que incluir servidores de nomes recursiva embutidos.

o TSIG [RFC2845] ou SIG (0) [RFC2931] assinado consultas para autenticar os clientes. Este é um método menos propenso a erro que permite que o servidor operadores para fornecer serviços aos clientes que mudam de endereço IP freqüentemente (por exemplo, os clientes de roaming). A desvantagem deste actual método é que muito poucas implementações stub resolvedor apoiar TSIG ou SIG (0) assinatura de consultas de saída. O uso efetivo desta método implica, na maioria dos casos, executando uma instância local de um nameserver caching ou despachante de que será capaz de assinar o TSIG consultas e enviá‐los para o servidor de nomes recursiva de escolha.

o Para os usuários móveis, use um servidor de nomes cache local em execução no dispositivo móvel ou usar uma rede privada virtual a um site servidor.

Em servidores de nomes que não precisa estar oferecendo um serviço recursivo, para servidores de instância que se destinam a ser autorizada apenas, volta recursão completamente. Em geral, é uma boa idéia para manter serviços recursiva e autoritária separar tanto quanto prático. Isso, é claro, depende de circunstâncias locais.



Mesmo com todas essas recomendações, os operadores de rede deveriam considerar a implantação de penetração de filtragem [BCP38] em roteadores para evitar o uso de falsificação de endereço como um curso de ação viável. Em situações em que mais configurações de rede complexas estão no local ", Ingress Filtrando por diversas bases de rede "[BCP84] talvez um adicional útil referência.

Por padrão, os servidores de nomes não deve oferecer serviço de recursiva para redes externas.

5. Considerações de Segurança

Este documento não cria quaisquer novas questões de segurança para o DNS protocolo, trata‐se de uma fraqueza em implementações.

Implantação de SIG (0) a segurança da transação [RFC2931] deve considerar as advertências com SIG (0) custo de cálculo, uma vez que utiliza a chave pública criptografia, em vez de as chaves simétricas usadas por TSIG [RFC2845]. Além disso, a identificação das teclas apropriadas precisa semelhante como os mecanismos para a implantação de TSIG ou, alternativamente, a utilização de DNSSEC [RFC4033] assinaturas (RRSIGs) sobre as CHAVE RRS se publicado no DNS. Este, por sua vez, exigem uma gestão adequada das DNSSEC âncoras de confiança.

6. Agradecimentos

Os autores gostariam de agradecer a colaboração e comentários úteis de Joe Abley, Olafur Gudmundsson, Pekka Savola, Andrew Sullivan, e



Tim Polk.

7. Referências

7.1. Referências normativas

[RFC1034] "Nomes de Domínio ‐ Conceitos e Recursos" Mockapetris, P., STD 13, RFC 1034, Novembro de 1987.

[RFC2119] Bradner, S., "palavras‐chave para uso em RFCs para indicar Níveis requisito ", BCP 14, RFC 2119, Março de 1997.

[RFC2671] Vixie, P., "Mecanismos de extensão para DNS (EDNS0)", RFC 2671, Agosto de 1999.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., e B. Wellington, "autenticação de transações Secret Key para DNS (TSIG) ", RFC 2845, Maio de 2000.



[RFC2931] Eastlake, D., "Pedido de DNS e Transação Signatures (SIG (0) s) ", RFC 2931, Setembro de 2000.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., e S. Rose, "DNS Introdução e Requisitos de Segurança", RFC 4033, março de 2005.

7.2. Referências informativo

[BCP38] Ferguson, P. e D. Senie ", rede penetração filtragem: Derrotar ataques de negação de serviço que empregam Fonte IP Falsificação de endereço ", BCP 38, RFC 2827, maio de 2000.

[BCP84] Baker, F. e P. Savola, "Ingress Filtering para Multihomed Networks ", BCP 84, RFC 3704, março de 2004.

Autores 'Endereços

João Damas Internet Systems Consortium, Inc. 950 Carta Rua Redwood City, CA 94063 EU

Telefone: +1 650 423 1300 EMail: [email protected] URI: http://www.isc.org/

Frederico AC Neves NIC.br / Registro.br Av. das Nacoes Unidas, 11541, 7 São Paulo, SP 04578‐000 BR

Telefone: +55 11 5509 3511 EMail: [email protected]



URI: http://registro.br/



Copyright plena afirmação

Copyright (C) O IETF Trust (2008).

Este documento está sujeito a direitos, licenças e restrições contidas no BCP 78, e exceto conforme estabelecido aí, os autores mantêm todos os seus direitos.

Este documento e as informações contidas neste documento são fornecidas por uma "COMO ESTÁ" O contribuinte e, a Organização ele / ela Representa Ou seja patrocinado por (se houver), a sociedade da Internet, o IETF e de confiança A internet engenharia task force REJEITAM TODAS AS GARANTIAS, EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO A QUALQUER GARANTIA QUE O USO DO AS INFORMAÇÕES AQUI não irá infringir quaisquer direitos ou quaisquer garantias envolvidas GARANTIAS DE COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO FIM.

Propriedade Intelectual

O IETF não toma posição sobre a validade ou âmbito de qualquer Direitos de Propriedade Intelectual ou outros direitos que podem ser reivindicados

deste documento ou a medida em que qualquer licença ao abrigo de tais direitos pode ou não estar disponível; nem representa que ele tem independente feito qualquer esforço para identificar cada um desses direitos. Informações sobre os procedimentos no que diz respeito aos direitos na RFC documentos podem ser BCP encontradas em 78 e BCP 79.

Cópias dos DPI divulgações feitas para a Secretaria e qualquer IETF garantias de licenças a ser disponibilizado, ou o resultado de uma tentativa de obter uma licença ou autorização geral para o uso de tais direitos proprietários ou utilizadores a implementadores do presente especificação pode ser obtido a partir do repositório DPI IETF on‐line em http://www.ietf.org/ipr.

O IETF convida qualquer parte interessada, para trazer ao seu conhecimento qualquer copyrights, patentes ou pedidos de patentes, ou outros títulos de propriedade direitos que podem abranger tecnologia que possam ser necessárias para implementar esta norma. Por favor, abordar as informações para o IETF em ietf‐[email protected].

dizem respeito à execução ou utilização da tecnologia descrita em

www.ietf.org rfc rfc5358

Documents