Permitir tanto a porta tcp e UDP 53 para seus servidores DNS

praticantes de segurança por décadas aconselharam as pessoas a limitar as consultas DNS contra seus servidores DNS para apenas usar a porta UDP 53. A realidade é que as consultas DNS também podem usar a porta tcp 53 se a porta UDP 53 não for aceita. Agora, com a iminente implantação da DNSSEC e a eventual adição de IPv6, vamos precisar permitir que nossas firewalls para a frente tanto TCP e UDP port 53 pacotes.

DNS pode ser usado pelos atacantes como uma de suas técnicas de reconhecimento., A informação pública continha servidores de um alvo é valiosa para um atacante e ajuda-os a focar seus ataques. Os atacantes podem usar uma variedade de técnicas para recuperar informações DNS através de consultas. No entanto, os hackers muitas vezes tentam realizar uma transferência de zona a partir de seus servidores DNS autoritários para obter acesso a ainda mais informações. Você pode usar o comando dig para coletar informações de um servidor para um arquivo de zona específica.,

dig @192.168.11.24 example.org -t AXFR

Zone transfers take place over TCP port 53 and in order to prevent our DNS servers from divulging critical information to attackers, TCP port 53 is typically blocked. Se a firewall da organização protegendo o servidor DNS autorizado permitiu o port 53 pacotes TCP e o servidor DNS foi configurado para permitir transferências de zona para qualquer um, então este comando dig seria bem sucedido. No entanto, a maioria das organizações configuraram seus servidores DNS para evitar transferências de zonas de servidores DNS não intencionais., Isto pode ser configurado no arquivo BIND zone usando qualquer uma destas formas do comando allow-transfer Como mostrado abaixo.

allow-transfer {"none";}; allow-transfer { address_match_list }; allow-transfer {192.168.11.11;};

além disso, a maioria das organizações também tem usado firewalls para bloquear a porta tcp 53 para e de seus servidores DNS e da Internet. Isto é dupla proteção no caso do servidor DNS permitir transferências acidentalmente.

configurar os seus servidores de DNS para permitir transferências de Zonas para apenas servidores de DNS legítimos sempre foi e continua a ser uma boa prática., No entanto, a prática de negar a porta tcp 53 de e para servidores DNS está começando a causar alguns problemas. Há duas boas razões que gostaríamos de permitir tanto TCP e UDP port 53 conexões para nossos servidores DNS. Um é DNSSEC e o segundo é IPv6.

DNSSEC cria respostas DNS maiores

I love reading the IP Journal and have read it since the first issue in 1998.

na edição recente do IP Journal havia um artigo de um amigo meu, Stephan Lagerholm, do Secure64 e do Texas IPv6 Task Force, intitulado “Operational Challenges When Implementing DNSSEC”., Este artigo cobriu muitas das advertências que as organizações encontram à medida que se movem para implantar a DNSSEC.uma das principais questões mencionadas é que o DNSSEC pode fazer com que as respostas do DNS sejam maiores que 512 bytes. DNSSEC (definido em RFC 4033, RFC 4034 e RFC 4035) requer a capacidade de transmitir mensagens DNS maiores por causa da informação chave extra contida nas respostas da consulta. TCP port 53 pode ser usado nos casos em que as respostas DNS são superiores a 512 bytes., No entanto, usar mensagens UDP são preferíveis a usar TCP para mensagens DNS grandes é devido ao fato de que conexões TCP podem consumir recursos computacionais para cada conexão. Os servidores DNS recebem várias conexões por segundo e usando TCP pode adicionar muito overhead. Para abordar esta questão, o IETF RFC 2671 “Extension Mechanisms for DNS (EDNS0)” define um método para estender o tamanho do buffer UDP para 4096 bytes para permitir respostas DNSSEC e consultas maiores., Para activar o EDNS0 na sua configuração do BIND 9, poderá usar a seguinte declaração de operações do BIND

edns-udp-size 4096 ;

consciência do DNSSEC aumentou devido às vulnerabilidades divulgadas Há 2 anos e com notícias recentes sobre o governo dos EUA a tentar implementá-lo. Muitas organizações estão planejando seus desdobramentos da DNSSEC. DNSSEC está se tornando mais amplamente implantado agora que os principais domínios de alto nível (TLDs) estão sendo assinados. O TLD .org foi assinado. A zona raiz da Internet foi assinada há dois meses numa cerimónia na Virgínia., A VeriSign declarou seu desejo de apoiar a DNSSEC para.com e. Net até 2011. Comcast criou um site DNSSEC Information Center que pode ajudá-lo a manter-se atualizado sobre o estado DNSSEC mais recente.

para continuar a ler este artigo registe agora

Saiba Mais sinais de utilizadores existentes em

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *