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