Vamos falar sobre DNS: entenda o que é e seus tipos!

O DNS (Domain Name System) é um sistema de gerenciamento de nomes hierárquico e distribuído para computadores, serviços ou qualquer recurso conectado à Internet ou em uma rede privada. Ele se baseia em nomes hierárquicos e permite a inscrição de vários dados digitados além do nome do host e seu endereçamento IP.

Em virtude do banco de dados de DNS ser distribuído, seu tamanho é ilimitado e o desempenho não degrada tanto quando se adiciona mais servidores à sua estrutura. Os servidores DNS padrão utilizam a porta 53.

O Windows NT 4.0 recebeu a implementação relacionada ao DNS, tornando-se padrão no Windows 2000. Nos dias atuais é impensado configurar uma rede sem a presença dos servidores de DNS, tanto que ao instalarmos o Active Directory fica como pré-requisito a presença do DNS.

O papel do DNS é o de converter nomes para endereçamentos IP, sejam eles de categoria 4 (IPV4) ou de categoria 6 (IPV6). Em uma infraestrutura de redes LAN, é aconselhável trabalhar sempre com pelo menos dois servidores de DNS, sendo um primário e outro secundário. Este modelo pode evoluir brutalmente dependendo da necessidade e tamanho da infraestrutura e parque de estações de trabalho.

As plataformas intituladas Open (cito aqui o Debian Linux), possuem servidores de DNS chamados de BIND. O Serviço de BIND gerencia os nomes e os relaciona com seus respectivos endereços. Recomenda-se cuidado ao implementar servidores de DNS em estruturas muito grandes que apresentem tantos recursos de WAN e LAN, pois fatores ligados a segurança podem influenciar diretamente a montagem do ambiente. É importante direcionar esforços para atuar com a máxima segurança possível, tanto dentro da LAN como pela DMZ, por exemplo.

Em um ambiente onde exista servidores de mensageira (e-mail), é necessário ainda a preocupação com o DNS Reverso. Seu papel é o de ofertar algo contrário ao do DNS padrão, pois em vez de conectar um nome a um endereçamento IP, ele conecta um endereçamento IP a um nome de domínio. Também é muito utilizado para configurações chamadas relações de confiança entre domínios (Trusts).

Tipos de registros DNS

Os servidores de DNS armazenam informações que são utilizadas basicamente para direcionar o trafego e requisições de aplicações e serviços. Cada registro dentro do banco de dados de um servidor de DNS possui seu papel específico e imutável, dos quais cito abaixo os principais.

Registros A: basicamente, associam um ou mais endereços IP a um ou mais domínios. Pode-se utilizar AAAA para endereços IPv6;

Registros CNAME (Canonical Name): servem para criar redirecionamentos para domínios ou subdomínios. É este parâmetro que dever ser utilizado, por exemplo, para criar um endereço do tipo blog ou e-mail em seu site. Esta entrada é também conhecida como apelido, pois pode adicionar um segundo ou terceiro nome a um servidor ou equipamento host em uma rede;

Registros MX (Mail Exchanger): são os parâmetros que devem ser configurados para contas de e-mail no domínio. São utilizados a priori por empresas que possuam o Exchange instalado e configurado. Dependendo do tamanho da infraestrutura de redes, é possível encontrar diversas entradas MX, trabalhando tanto com servidores primários quanto servidores secundários;

Registros NS (Name Server): indicam quais servidores atuam como serviço de DNS dentre de uma rede ou de um site.

Registros PTR (Pointer): informam quais domínios estão associados a determinados IPs, quase se fosse o reverso dos registros A.

Registros SRV (abreviação de Service): indicam a localização de determinados serviços dentro do domínio;

Registros SOA (Start of Authority): indicam o início de uma zona, isto é, de um conjunto de registros localizado dentro de um espaço de nomes de DNS. Cada zona deve ter um registro SOA;

Registros TXT (abreviação de Text): servem para a inserção de comentários, porém também servem para validação de servidores de disparo de e-mail pela linha de SPF, por exemplo. Quando disparamos e-mails a uma empresa, é verificado a linha de SPF com dados relacionados a quem disparou o e-mail. Se os dados baterem a mensagem é entregue a seu destinatário, se não ela é descartada ou encaminhada ao lixo eletrônico.

DNS e seu cache

O grande segredo relacionado ao DNS, está em seu cache dentro das estações de trabalho que efetuam a leitura de um respectivo endereço através de seu nome. Isso significa que não é necessário refazer toda a pesquisa de endereçamento sempre que digitamos algo na barra do navegador. O cache permite acesso de forma rápida a um conteúdo pela web ou da rede interna, gerando uma melhor utilização da banda real da rede.

Existem ataques concentrados relacionados ao cache como a poluição de cache. A poluição da cache do DNS pode ocorrer caso seja detectado um ataque de fraude de identidade no sistema de nomes de domínio (DNS). O ataque que visa a fraude de identidade descreve o envio de dados não seguros como resposta a uma consulta de DNS e geralmente é utilizado para redirecionar consultas para um servidor de DNS não controlado e pode ser de natureza maliciosa. Este ataque pode ser evitado com a assimilação do DNSSEC.

DNSSEC e sua estrutura funcional

O DNSSEC, também conhecido por Domain Name System Security Extensions, nada mais é que um padrão internacional que estende diretamente a tecnologia Domain Name System (DNS) para um nível superior de segurança.

O DNSSEC adiciona ao sistema de resolução de nomes técnicas e algoritmos que o deixam mais seguro, reduzindo o risco de manipulação de dados e domínios forjados. O DNSSEC possui um mecanismo baseado pela tecnologia de criptografia que emprega assinaturas digitais em suas requisições através de chaves assimétricas.

Na prática significa que alguém com um domínio compatível com DNSSEC possui um par de chaves eletrônicas que consistem em uma chave privada e uma chave pública, permitindo que somente haja resposta às solicitações pertinentes. Em razão do mantenedor das chaves utilizar a chave privada para assinar digitalmente sua própria zona no DNS, é possível que todas as estações clientes da estrutura com acesso a chave pública desta zona verifique que os dados transferidos desta zona estão intactos. É altamente recomendável que seja assimilado o DNSSEC nas empresas de grande e médio porte para evitar o vazamento de informações e o próprio ataque de poluição de DNS.

DNSSEC soluciona alguns problemas encontrados na atual tecnologia DNS. Falsas informações DNS criam oportunidades para roubo de informações de terceiros ou alteração de dados em diversos tipos de transações, como compras eletrônicas. Na tecnologia DNSSEC, um ataque DNS com informação forjada é extremamente difícil de ser detectado e não pratica impossível de ser prevenido. O objetivo da extensão DNSSEC é assegurar o conteúdo do DNS e impedir estes ataques validando os dados e garantindo a origem das informações.

Quando uma estação de trabalho requisita um endereço de um nome ao servidor de DNS, a autenticidade e integridade são verificadas e providas pela assinatura dos Conjuntos de Registros de Recursos (Resource Records Sets – RRset) com uma chave privada. As zonas delegadas (filhas) assinam seus próprios RRsets com sua chave privada e a autenticidade da chave é verificada pela assinatura na zona pai do Recurso DS (Record DS) (hash da chave pública da zona filha).

A chave pública é usada para verificar RRSIGs dos RRsets e a autenticidade da não existência de um nome ou tipo provida por uma cadeia de registros que aponta para o próximo em uma sequência canônica pode ser validada.

Poluição de Cache em Redes Orientadas a Conteúdo Sem-Fio

As Redes Orientadas a Conteúdo (ROCs) são redes de caches que armazenam conteúdo com a finalidade de aumentar a disponibilidade e atender os usuários com maior eficiência. Qualquer nó pode armazenar conteúdos, assim, o usuário pode se beneficiar da distribuição dos conteúdos e obtê-los de nós mais próximos, sendo desnecessário ir até a fonte. Nas ROCs os conteúdos são requisitados em função do nome, portanto esta proposta traz uma mudança de paradigmas.

Por outro lado, os dispositivos móveis estão cada vez mais presentes no dia-a-dia dos usuários da Internet. Entretanto, esta arquitetura atual tem a comunicação baseada no IP, que associa localização e identificação, o que torna difícil lidar com mudanças geográficas.

Neste contexto, a proposta de uma nova arquitetura que tenha suporte nativo para mobilidade torna-se interessante.

Nas Redes Orientadas a Conteúdo Sem fio baseadas na arquitetura Named Data-Centric Network (NDN) pode ser empregada uma política de cache proativo. Assim, um nó pode armazenar um conteúdo mesmo que não tenha um interesse pendente para esse conteúdo. O objetivo é aproveitar a natureza de difusão do meio sem fio para aumentar a disponibilidade dos conteúdos.

Um problema dessa abordagem, entretanto, é que a política de cache proativo pode potencializar ataques de poluição de cache. Este trabalho, portanto, avalia o impacto desses ataques em redes NDN sem fio através de simulações.

Compara-se o desempenho da rede considerando o uso das políticas de cache proativo e não proativo, em cenários com e sem mobilidade, em condições normais de operação e sob ataque. O desempenho é avaliado em relação à taxa de entrega, atraso, à ocupação maliciosa do cache dos nós, taxa de hit no cache e número médio de saltos atravessados pelo conteúdo.

O cache proativo potencializou o ataque de poluição dos caches no sentido de aumentar a ocupação maliciosa. Em contrapartida, melhorou a eficiência da rede. Os consumidores legítimos da rede foram atendidos em menor tempo e com maior taxa de entrega.

Para evitar acesso de dispositivos móveis a rede interna das empresas, recomenda-se a criação de uma rede Guest. As redes Guest são pontos de conexão WIFI com internet que ficam isoladas da rede principal, seja por uma simples segmentação lógica de endereços, ou até memo por equipamentos específicos como os fabricados pela Dell (SonicWall). Existem diversos fabricantes que podem atestar a funcionalidade e qualidade das redes Guest.

Ataques mais comuns relacionados ao DNS

Ataque Windows fora de banda (WinNuke) – um invasor lança um ataque de negação de serviço (DoS) fora de banda contra um host protegido por um firewall (como o Forefront TMG da Microsoft, por exemplo). Se o ataque obtiver êxito, ele causará falha no computador ou perda de conectividade de rede em computadores vulneráveis.

Ataque por terra – um invasor envia um pacote SYN TCP com um endereço IP de origem falsificado que corresponde ao endereço IP do computador de destino e com um número de porta permitido pelas regras de diretiva de um Firewall, para que o computador de destino tente estabelecer uma conexão TCP com ele mesmo. Se o ataque obtiver êxito, algumas implementações de TCP poderão entrar em loop, o que causará falha no computador.

Ping da morte – um invasor anexa uma grande quantidade de informações, que excedem o tamanho de pacote IP máximo, a uma solicitação echo (ping) do protocolo ICMP. Se o ataque obtiver êxito, um buffer kernel estoura, causando falha no computador.

Verificação parcial de IP – um invasor tenta repetidamente conectar-se a um computador de destino, mas não envia pacotes ACK em resposta aos pacotes SYN/ACK. Durante uma conexão TCP normal, a origem inicia a conexão enviando um pacote SYN para uma porta no sistema de destino. Se um serviço estiver escutando essa porta, o serviço responde com um pacote SYN/ACK. Em seguida, o cliente que iniciou a conexão responde com um pacote ACK e a conexão for estabelecida. Se o host de destino não estiver esperando por uma conexão na porta especificada, ele responde com um pacote RST. A maioria dos logs de sistema não registram conexões concluídas até que o pacote ACK final tenha sido recebido da origem. Enviar outros tipos de pacotes que não sigam esta sequência pode extrair respostas úteis do host de destino, sem causar o registro de uma conexão.

Bomba UDP – um invasor tenta enviar um datagrama do protocolo UDP com valores ilegais em alguns campos, o que pode causar falha em alguns sistemas operacionais mais antigos quando o datagrama é recebido. Por padrão, nenhum alerta é configurado para esse tipo de ataque.

Verificação de porta – um invasor tenta contar os serviços que estão sendo executados em um computador, investigando cada porta em busca de uma resposta. É possível especificar o número de portas que podem ser verificadas antes de um evento ser gerado.

Tais ataques podem ser devidamente identificados durante a monitoração do ambiente, portanto recomendo o uso de equipamentos ou softwares que permitam tornar o ambiente reiliente.

Alguns cuidados com o servidor de DNS

Excesso de nomes de host DNS – quando uma resposta DNS a um nome de host exceder 255 bytes, os aplicativos que não verificam o comprimento do nome do host poderão exceder os buffers internos ao copiar o nome desse host, permitindo que um invasor remoto execute comandos arbitrários em um computador de destino.

Excesso no tamanho do DNS – quando uma resposta DNS a um endereço IP exceder 4 bytes, alguns aplicativos que estão executando pesquisas DNS excederão os buffers internos, permitindo que um invasor remoto execute comandos arbitrários em um computador de destino. A ferramenta de monitoração escolhida para trabalhar como o servidor de DNS verificr se o valor de RDLength não excede o tamanho do restante da resposta DNS. Este é um ponto chave que deve ser levado como boa prática.

Transferência de zona DNS – um sistema cliente usa um aplicativo cliente DNS para transferir zonas de um servidor DNS interno.

A ferramenta de monitoração de DNS precisa ser configurada de forma a validar quando pacotes incorretos são detectados e descartados gerado um evento que dispara um alerta de Intrusão ao servidor de DNS. É possível configurar os alertas para notificarem que um ataque foi detectado requerendo uma ação humana ou mecânica.

Algumas empresas (incluindo a Microsoft), recomendam que caso o evento de Intrusão DNS seja gerado por cerca de cinco vezes durante um segundo para a transferência de zonas DNS, um alerta de Intrusão de Transferência de Zona DNS deve ser disparado. Por padrão, depois que os alertas predefinidos aplicáveis forem disparados, não serão disparados novamente até que sejam manualmente redefinidos.

Esse conteúdo foi postado originalmente no blog da HTBRAZ Connect, em 10 de dezembro de 2015, e pode ser conferido aqui.

E aí, ficou alguma dúvida? Deixe seu comentário.

Que tal se especializar em ambientes de redes?