DNS
Torne-se um Cyberwarrior!
Hackers-Arise
A melhaor introdução ao hacking!
Avaliações da Amazon
Noções básicas de rede para hackers: Domain Name Service (DNS) e BIND. Teoria, Vulnerabilidades e Implemen
Atualizada: Jan 8
Bem-vindos de volta, meus aspirantes a guerreiros cibernéticos!
O Domain Name System ou DNS é um daqueles protocolos de rede que fazem o mundo girar. Sem ele, precisaríamos nos lembrar de inúmeros endereços IP apenas para navegar para nossos sites favoritos. Imagine tentar lembrar os endereços IPv4 (32 bits) do Facebook, Amazon e Hackers-Arise, apenas para visitar cada um desses sites extremamente importantes (que só pioram com os endereços IPv6 de 128 bits).
O DNS foi projetado para traduzir um nome de domínio - algo que as pessoas são muito boas em lembrar - em um endereço IP, a linguagem do roteamento da Internet. Pense no DNS simplesmente como uma tradução de um nome de domínio para seus respectivos endereços IP. Portanto, quando você insere um domínio como www.hackers-arise.com em seu navegador, ele é convertido em um endereço IP amigável (23.236.62.147) que a Internet pode entender e rotear.
Neste tutorial sobre DNS, examinamos;
I. Como funcionam os nomes de domínio
II. Como funciona o DNS,
III. Uma análise de nível de pacote de solicitações e respostas de DNS,
4. Vulnerabilidades e segurança no DNS,
V. Construa seu próprio servidor DNS no Linux.
I. Nomes de domínio
Os nomes de domínio devem ser registrados na ICANN (Internet Corporation for Assigned Names and Numbers), geralmente por meio de um intermediário, como VeriSign ou GoDaddy. Os domínios de primeiro nível ou TLDs incluem .com, .edu, .org e muitos outros que normalmente vemos no final de Full Qualified Domain Name (FQDN).
O DNS funciona de maneira hierárquica. Os domínios de nível superior ou TLDs podem ter vários subdomínios sob eles. No diagrama acima, .redhat e .cnn fazem parte do domínio de nível superior .com. Um subdomínio é um domínio que faz parte de um domínio maior. Neste exemplo, redhat e cnn são frequentemente referidos apenas como o domínio na linguagem comum, mas são na verdade o Domínio de Segundo Nível ou (SLD) em .com.
Então, abaixo desses SLDs ou domínios comumente referidos, temos muitos subdomínios. Por exemplo, dentro e abaixo de .redhat, podemos ter vendas.redhat, engineering.radhat, development.redhat. Este é um método de subdividir o domínio. A porção mais à esquerda é sempre a mais específica, enquanto a mais à direita é a mais geral.
uma. Nome de domínio totalmente qualificado
Um domínio totalmente qualificado ou FQDN é o que muitas pessoas chamam de nome de domínio absoluto. Um Nome de domínio totalmente qualificado (FQDN) especifica sua localização na raiz absoluta do sistema DNS.
Agora que temos um entendimento básico de nomes de domínio, a próxima questão para entender como DNS é como traduzimos nomes de domínio em endereços IP. Inicialmente, os clientes usavam um arquivo hosts simples em cada cliente.
b. Arquivos de host
Quando a Internet era muito, muito pequena (em um universo muito, muito distante ...), a associação de nomes de domínio com endereços IP poderia caber em um único arquivo de texto (ARPANET, o predecessor e protótipo da Internet tinha apenas 4 sites) . Esse único arquivo de texto era, na época, e agora referido como um arquivo hosts . À medida que a Internet crescia, esse arquivo hosts se mostrou inadequado. Não era grande o suficiente e nem podia ser atualizado constantemente à medida que novos domínios eram registrados e os antigos eram deixados ou alterados. Apesar disso, seu sistema provavelmente ainda possui um arquivo hosts.
Em seu sistema Kali Linux, seu arquivo hosts está localizado no diretório / etc, conforme mostrado abaixo. Você pode abri-lo digitando;
kali> mousepad / etc / hosts
Observe que cada endereço IP está na mesma linha do host associado, neste caso localhost ou Kali. Sempre que você insere localhost em seu navegador, ele o traduz para seu IP "inicial" ou 127.0.0.1.
Na quarta linha do meu arquivo de hosts, você verá uma associação do endereço IP privado 192.168.1.114 ao domínio bankofamerica.com. Com esse arquivo de hosts instalado, sempre que entro em www.bankofamerica.com em meu navegador, eu gostaria de ser direcionado para o endereço IP 192.168.56.101, em vez do endereço IP real do Bank of America em 171.159.228.150.
Posso testar isso também executando ping em bankofamerica.com.
Como você pode ver acima, quando tento executar o ping em www.bankofamerica.com, meu ping é direcionado para o endereço associado ao bankofamerica em meu arquivo hosts. O arquivo hosts tem precedência sobre as consultas DNS. Esta pode ser uma informação importante ao tentar fazer spoofing de DNS em uma LAN (veja abaixo).
Era assim que o DNS funcionava quando a Internet era muito, muito pequena.
II. Como funciona o DNS
Agora que a Internet contém bilhões de endereços IP e FQDN, o arquivo host é terrivelmente inadequado. Digite DNS. Desenvolvido pela primeira vez por Paul Mockapetris (agora no Hall da Fama da Internet) em 1983, o DNS é distribuído e dinâmico, ao contrário de nosso arquivo hosts.
O DNS não depende de um arquivo ou servidor, mas de muitos arquivos em vários servidores em todo o mundo. Esses servidores são organizados de forma hierárquica. Devido a essa natureza distribuída, o sistema DNS é resistente a interrupções de um ou mais desses servidores.
Como podemos ver no diagrama acima, o usuário pede (consulta) ao servidor DNS local para acessar download.beta.example.com . O servidor DNS local não possui esse recurso, pois é novo. Em seguida, ele consulta o servidor raiz. O servidor raiz responde "Não sei", mas remete o servidor DNS local para o endereço IP do servidor autoritativo para o domínio de nível superior (TLD), neste caso .com . O servidor DNS local consultará o servidor TLD em busca de .com e responderá com o servidor autorizado para o domínio, neste caso example.com . O servidor DNS local irá então consultar o servidor autoritativo para beta.example.com. Se tiver o registro, retornará o recurso (endereço IP) e se não tiver, responderá "não sabe".
uma. Componentes DNS
O serviço DNS possui quatro (4) componentes;
1. Cache DNS
2. Resolvedores,
3. Servidores de nomes,
4. Espaço de nomes.
1. Cache DNS
Este termo é frequentemente confundido porque tem pelo menos dois significados. Primeiro, o cache DNS pode ser a lista de nomes e endereços IP que você já consultou e foi resolvido e é armazenado em cache para você, de forma que nenhum tráfego de rede seja gerado para resolvê-los (e muito mais rápido). O segundo significado diz respeito a um servidor DNS que simplesmente executa consultas recursivas e armazenamento em cache, sem realmente ser um servidor autoritativo.
2. Resolvedores
Resolvers são quaisquer hosts na Internet que precisam pesquisar informações de domínio, como o computador que você está usando para ler este site.
3. Servidores de nomes
Esses são servidores que contêm o banco de dados de nomes e endereços IP e atendem a solicitações de DNS para clientes.
4. Espaço de Nome
O espaço de nomes é o banco de dados de endereços IP e seus nomes associados.
b. Arquivos e registros de zona
Cada zona DNS possui um arquivo de zona. Este arquivo de zona pode ser considerado um banco de dados DNS.
Esses arquivos de zona têm um ou mais registros de recursos. Esses registros DNS devem ser atualizados periodicamente à medida que novos domínios são adicionados, alterados e outros eliminados. Sem esse processo, o sistema permaneceria estagnado e, eventualmente, totalmente desatualizado. Portanto, é essencial que o servidor DNS seja capaz de fazer transferências de zona.
1. Registros de recursos
O Registro de recursos é um único registro que descreve apenas uma informação no banco de dados DNS. Esses registros são linhas de texto simples, como;
Proprietário Classe TTL Tipo RDATA
Cada um desses campos deve ser separado por pelo menos um espaço.
2. Tipos de registros de recursos comuns
Registros SOA
O registro Start of Authority, ou SOA, é um registro obrigatório em todos os arquivos de zona. Deve ser o primeiro registro real em um arquivo (embora as especificações $ ORIGIN ou $ TTL possam aparecer acima). É também um dos mais complexos de entender. Os campos incluem o servidor de nome primário, o e-mail do administrador, o número do domínio e os temporizadores para atualizar a zona.
Registros NS
NS ou servidor de nomes identifica o servidor DNS autorizado para a zona.
Registros A
O registro A (endereço) é usado para mapear um domínio ou subdomínio para um endereço IPv4. Por exemplo, hackers-arise.com aponta para 23.236.62147.
Os registros AAAA apontam para um registro IPv6.
:
Registros CNAME (canônicos)
O CName ou nome canônico mapeia um domínio ou subdomínio para outro nome de domínio.
Registros PTR
Os registros PTR são usados em registros DNS reversos (ou seja, do endereço IP ao nome do host). PTR ou Ponteiro aponta para um nome canônico e apenas o nome é retornado na consulta. Você pode pensar nisso como o reverso dos registros A ou AAAA.
Registros MX
O registro MX direciona o correio para um servidor de correio específico responsável por aceitar o correio na zona. Como o CNAME, o registro MX deve sempre apontar para um domínio e nunca para um endereço IP.
III. Análise de nível de pacote de consultas DNS
O protocolo DNS, como outros protocolos de comunicação usados por nossas redes, tem uma estrutura de pacote padrão. É bastante simples e você pode visualizá-lo abaixo sem entrar em grandes detalhes aqui.
Se capturarmos as consultas DNS com o Wireshark, devemos ver algo como a captura abaixo. Observe que uma consulta DNS é enviada do cliente e a resposta DNS vem do servidor DNS .
Também é importante observar que essas consultas usam UDP e não TCP (as transferências de zona usam TCP).
Se expandirmos os pacotes DNS, podemos ver que eles vêm em duas variedades, Consulta Padrão, conforme mostrado abaixo ...
... e uma Resposta de Consulta Padrão, conforme visto aqui.
4. Segurança e vulnerabilidades de DNS
O Domain Name Service já foi muito frágil e vulnerável a ataques. Com o passar dos anos, o sistema foi fortalecido e os ataques são menos frequentes, mas ainda ocorrem. Em alguns casos, os hackers / atacantes podem simplesmente coletar informações dos servidores DNS no destino, como varredura de DNS e reconhecimento de DNS (consulte Abuso de DNS para reconhecimento ).
Em redes locais (LAN), pode ser possível falsificar o DNS com ferramentas como dnsspoof para enviar o tráfego do cliente para um sistema local de escolha do hacker. Por exemplo, o invasor pode enviar todo o tráfego bancário para seu site malicioso e colher credenciais lá.
A. Vulnerabilidades de DNS
Embora um dos ataques mais maliciosos ao DNS esteja a alteração do seu servidor DNS (Registro A) e a alteração para onde o seu cliente é levado ao solicitar um site, esses são cada vez mais raros, mas não inéditos. (veja os ataques DNS iranianos abaixo). Cada vez mais, os ataques bem-sucedidos contra DNS são ataques de negação de serviço (DOS).
Embora na maioria dos sistemas e protocolos os ataques DoS sejam uma inconveniência, com um serviço tão essencial como o DNS, um ataque DoS pode ser esmagador. Imagine se o servidor DNS da sua empresa ou do ISP caísse. Embora a Internet ainda esteja funcionando (você pode executar ping em qualquer endereço IP), você não conseguirá se conectar a nenhum site sem inserir o endereço IP completo (ou alterar o servidor DNS).
Se visualizarmos a lista de vulnerabilidades BIND (uma implementação Linux de DNS) no banco de dados CVE, podemos ver que a grande maioria das vulnerabilidades nos últimos anos são ataques DoS.
Entre os ataques DNS mais maliciosos estaria a transferência de zona. Uma zona são os dados que mapeiam endereços IP para domínios. Se um invasor puder alterar essas informações em um servidor DNS, até mesmo o tráfego da Internet será redirecionado para seu site, causando todos os tipos de danos.
B. Alterar as configurações do servidor DNS
Outro tipo de ataque contra o sistema DNS seria simplesmente alterar a configuração que direciona as consultas DNS para outro servidor DNS malicioso. De certa forma, isso não é tecnicamente um ataque contra o DNS, mas sim um ataque contra credenciais e servidores internos, como o servidor de e-mail. Você pode ler abaixo os detalhes de um ataque que o US CERT alertou no início de 2019, onde as credenciais do administrador do sistema (ou outro usuário com autoridade para alterar os registros DNS) e redirecionar as consultas DNS dos usuários para o servidor DNS malicioso.
Recentemente, um grupo de hackers iranianos conseguiu atacar o DNS de várias empresas para coletar credenciais. Eles fizeram isso de pelo menos 3 maneiras diferentes;
1. Os invasores alteram os registros DNS do servidor de e-mail da vítima para redirecioná-lo para seu próprio servidor de e-mail. Os invasores também usam certificados Let's Encrypt para oferecer suporte ao tráfego HTTPS e um balanceador de carga para redirecionar as vítimas de volta ao servidor de e-mail real depois de coletarem as credenciais de login das vítimas em seu servidor sombra
2. Igual ao primeiro, mas a diferença é onde os registros DNS legítimos da empresa estão sendo modificados. Na primeira técnica, os invasores alteraram os registros DNS A por meio de uma conta em um provedor de DNS gerenciado, enquanto nesta técnica os invasores alteraram os registros DNS NS por meio de uma conta de provedor de TLD (nome de domínio)
3. Às vezes, também implantado como parte das duas primeiras técnicas. Isso depende da implantação de uma "caixa de operações do invasor" que responde às solicitações de DNS para o registro de DNS sequestrado. Se a solicitação de DNS (para o servidor de e-mail de uma empresa) vier de dentro da empresa, o usuário é redirecionado para o servidor malicioso operado por invasores, mas se a solicitação vier de fora da empresa, a solicitação é direcionada para o servidor de e-mail real.
C. Segurança DNS ou DNSSec
DNS por padrão NÃO é seguro. O DNS pode ser facilmente falsificado devido ao fato de que o DNS é baseado em UDP, que não é orientado a conexões. DNSSEC ou DNS Security Extensions foi desenvolvido para fortalecer a autenticação no DNS usando assinaturas digitais.
Cada zona DNS possui uma chave pública / privada. Qualquer resolvedor recursivo que procura dados na zona, também recupera a chave pública da zona que pode ser usada para validar a autenticidade dos dados.
Antes do DNSSec, era possível que agentes mal-intencionados executassem transferências de zona em servidores DNS. Isso envenenaria os dados, tornando-os não confiáveis. DNSSEC impede isso por;
1. Verificar criptograficamente se os dados que recebe realmente vêm da zona de onde acredita que deveriam vir;
2. Garantir a integridade dos dados para que os dados não possam ser alterados durante o percurso, visto que os dados devem ser assinados digitalmente pela chave privada da zona.
V. Implementando DNS (BIND) no Linux
Agora que entendemos o básico de como o DNS funciona e como os invasores podem usar o DNS em seus ataques, vamos configurar um servidor DNS em nosso sistema Linux. BIND ou Berkeley Internet Domain System é comumente usado em sistemas Linux, é o servidor DNS mais usado na Internet e está entre os melhores sistemas DNS.
Embora instalar e configurar um servidor BIND seja uma profissão em si, aqui tentaremos definir um servidor BIND simples e básico em nossa rede local (LAN) para ajudá-lo a entender o funcionamento desses servidores.
1. Primeiro, vamos baixar e instalar o bind9 do repositório.
kali> apt-get install bind9
Se bind9 não estiver em seu repositório, você pode obtê-lo diretamente do repositório ISC.org usando clone git.
kali> git clone https://gitlab.isc.org/isc-projects/bind9.git
2. A seguir, vamos abrir o arquivo de configuração do BIND em /etc/bind/named.conf.options (todos os arquivos de configuração do BIND estão localizados em / etc / bind).
kali> leafpad /etc/bind/named.conf.options
Como você pode ver, editamos o parágrafo destacado para;
escute na porta 53 do localhost e nossa rede local em 192.168.1.0/24;
allow-query no localhost e 192.168.1.0/24
use o encaminhador em 75.75.75.75 (para onde encaminhar solicitações de DNS quando o servidor DNS não puder resolver a consulta)
e habilitar a recursão .
3. Em seguida, vamos abrir named.conf.local. É aqui que definimos os arquivos de zonas para nosso domínio.
Observe que definimos as localizações de nossos arquivos de zona de pesquisa direta e reversa. Agora, precisamos criar esses arquivos de zona direta e reversa.
Vamos navegar até o diretório / etc / bind. Lá você verá um arquivo chamado db.local. Este é um modelo para nosso arquivo fowarder. Vamos copiá-lo para um arquivo denominado forward.hackers-occur.local.
kali> cp db.local forward.hackers-rise.local
kali> leafpad /etc/bind/forward.hackers-arise.local
Vamos abrir este arquivo no leafpad e fazer algumas alterações especificando nosso domínio (hackers-arise.com), o endereço IP do nosso servidor DNS (192.168.1.27), nosso servidor de e-mail e finalmente os endereços IP do servidor web e e-mail servidor.
Agora, precisamos criar um arquivo de pesquisa reversa. Mais uma vez, temos um modelo no diretório / etc / bind. Nesse caso, é denominado db.127 . Vamos copiá-lo para reverse.hackers-occur.local.
kali> cp db.127 reverse.hackers-appear.local
Então, vamos abrir esse arquivo com o leafpad.
kali> leafpad /etc.bind/reverse.hackers-arise.local
Agora vamos fazer algumas mudanças.
Em "Seu servidor de nomes", adicione;
principal.seu domínio.local.
O endereço IP do servidor de nomes
Em "Pesquisa reversa", adicione;
o último octeto do endereço IP do NS e principal.seu domínio.local.
Em "Registros PTR", adicione;
o último octeto do servidor da web e www.seu domínio.local
o último octeto do servidor de e-mail e mail.seu domínio.local.
4. Em nossa etapa final, precisamos apenas reiniciar o serviço para que nossas alterações sejam capturadas e implementadas.
kali> reinicialização do serviço bind9
Para aqueles que preferem os novos comandos do systemd, isso funciona muito bem.
kali> systemctl restart bind9
Agora, nosso servidor BIND está pronto para resolver consultas DNS em nossa rede local!
Resumo
O DNS está entre os protocolos de comunicação mais essenciais para o bom funcionamento do seu acesso à Internet, traduzindo nomes de domínio legíveis por humanos em endereços IP legíveis por roteador. Tem havido uma série de ameaças de segurança ao DNS, incluindo roubo de credenciais de administrador DNS e alteração de arquivos de zona e ataques de negação de serviço (DoS).
Procure pelo novo livro da Master OTW "Network Basics for Hackers", que chegará no outono de 2021.
Comentários
Postar um comentário