{"id":5217,"date":"2022-09-15T12:28:11","date_gmt":"2022-09-15T15:28:11","guid":{"rendered":"https:\/\/base4sec.com\/nao-categorizado\/dns-sinkholing-a-partir-de-uma-perspectiva-activa-i\/"},"modified":"2025-02-25T19:41:39","modified_gmt":"2025-02-25T22:41:39","slug":"dns-sinkholing-a-partir-de-uma-perspectiva-activa-i","status":"publish","type":"post","link":"https:\/\/base4sec.com\/pt-br\/pesquisar\/dns-sinkholing-a-partir-de-uma-perspectiva-activa-i\/2022\/09\/15\/","title":{"rendered":"DNS Sinkholing a partir de uma perspectiva activa I"},"content":{"rendered":"

Em busca de uma defini\u00e7\u00e3o<\/h2>\n

Do ponto de vista de um atacante, a nossa infra-estrutura \u00e9 o espa\u00e7o onde o seu peda\u00e7o de malware ser\u00e1 executado, provavelmente com objectivos diferentes (desde a incorpora\u00e7\u00e3o dos nossos dispositivos a uma Botnet, o desvio dos nossos dados, a recolha de informa\u00e7\u00f5es de interesse, at\u00e9 aos casos mais engenhosos). Esse pequeno peda\u00e7o de c\u00f3digo precisa de utilizar alguns dos nossos recursos para atingir os seus objectivos.<\/p>\n

DNS Sinkhole \u00e9 uma t\u00e9cnica bem conhecida onde s\u00e3o fornecidos resultados manipulados para consultas a partir de dom\u00ednios considerados maliciosos. Isto permite ent\u00e3o que o atacante seja redireccionado para um sistema alvo diferente (controlado por n\u00f3s).<\/p>\n

Tradicionalmente, os v\u00e1rios servi\u00e7os que integram a protec\u00e7\u00e3o da conectividade ofereciam (e oferecem) a possibilidade de bloqueio preventivo destas consultas. Com esta t\u00e9cnica podemos ir um passo mais longe e levar esse simples pedido DNS feito pelo nosso dispositivo infectado e utiliz\u00e1-lo em nosso benef\u00edcio.<\/p>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

Apenas uma t\u00e9cnica para a nossa Defesa Activa<\/h2>\n

Como j\u00e1 explor\u00e1mos em posts anteriores, esta \u00e9 apenas uma de v\u00e1rias t\u00e9cnicas centradas na Defesa Activa (HoneyPots, Beaconing). Especificamente, podemos colocar o DNS Sinkholing no contexto do MITRE Engage Framework e ATT&CK como uma t\u00e9cnica onde manipulamos a nossa rede, claramente com o objectivo de evitar que o atacante avance com as suas opera\u00e7\u00f5es, mas tamb\u00e9m prejudicando opera\u00e7\u00f5es em curso, tais como fugas de dados.<\/p>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

Malware e NATeo<\/h2>\n

Chega um ponto no ciclo de execu\u00e7\u00e3o de qualquer pe\u00e7a de malware onde faz contacto com o mundo exterior, seja para reportar um estado de activa\u00e7\u00e3o, para fazer um push de dados, ou para procurar novos comandos (claro que cada cen\u00e1rio \u00e9 diverso, se pudermos generalizar). \u00c9 neste ponto que o malware \u00e9 exposto na nossa rede<\/p>\n

Por outro lado, as consultas DNS s\u00e3o normalmente realizadas atrav\u00e9s de uma rede complexa, pelo que detectar o IP a partir do qual a consulta de dom\u00ednio malicioso foi realizada n\u00e3o \u00e9 f\u00e1cil do ponto de vista das nossas NGFWs. A t\u00e9cnica DNS Sinkholing provoca a m\u00e1quina infectada a comunicar directamente com o nosso IP de detec\u00e7\u00e3o ou IP Sinkholing, e \u00e9 a\u00ed que capturamos o endere\u00e7o do nosso dispositivo comprometido para iniciar tarefas de remedia\u00e7\u00e3o.<\/p>\n

Antes de prosseguir, \u00e9 importante notar que esta tarefa nem sempre \u00e9 eficaz porque s\u00f3 funciona nos casos em que os dom\u00ednios utilizados pelos advers\u00e1rios j\u00e1 s\u00e3o detectados pelos fornecedores da lista de blocos. Al\u00e9m disso, existem muitas alternativas t\u00e3o simples como a utiliza\u00e7\u00e3o de um IP fixo (que anularia completamente a nossa medida). Outras t\u00e9cnicas engenhosas s\u00e3o tamb\u00e9m utilizadas, tais como a utiliza\u00e7\u00e3o de dom\u00ednios respeit\u00e1veis para comunica\u00e7\u00e3o externa ou a gera\u00e7\u00e3o aleat\u00f3ria de novos dom\u00ednios, embora “sorte a nossa”, uma \u00fanica ac\u00e7\u00e3o registada pela nossa t\u00e9cnica \u00e9 suficiente para detectar um computador infectado no nosso ambiente e para iniciar tarefas de mitiga\u00e7\u00e3o.<\/p>\n

Algumas implementa\u00e7\u00f5es<\/h2>\n

Existem muitos produtos de c\u00f3digo aberto e comerciais que nos permitem bloquear as consultas DNS feitas a nomes de s\u00edtios infectados. Alguns dos servi\u00e7os que podemos utilizar para esta protec\u00e7\u00e3o s\u00e3o:\u00a0Cloudfare<\/a>\u00a0,OpenDNS<\/a>,\u00a0AmazonRoute53<\/a>,\u00a0Checkpoint<\/a>, y\u00a0Fortinet<\/a>. No entanto, isto \u00e9 apenas metade dos benef\u00edcios que podemos obter com esta t\u00e9cnica. Alguns fornecedores deram nativamente a op\u00e7\u00e3o de oferecer uma resposta a essa consulta maliciosa com um resultado alterado (como no caso de Palo Alto). Neste caso, partilharemos umapequena implementa\u00e7\u00e3o na Amazon AWS.<\/p>\n

A sua configura\u00e7\u00e3o \u00e9 bastante simples atrav\u00e9s de uma s\u00e9rie de “Regras de Grupo” dentro dos VPCs. Desta forma, todas as consultas DNS s\u00e3o processadas de acordo com as regras definidas:<\/p>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

Esta implementa\u00e7\u00e3o pode ser destacada pela sua facilidade de configura\u00e7\u00e3o e integra\u00e7\u00e3o com a infra-estrutura j\u00e1 implantada na nuvem. Com estas regras, todas as consultas DNS que s\u00e3o detectadas no VPC atribu\u00eddo e correspondem a dom\u00ednios maliciosos ser\u00e3o sobrescritas com o nosso IP Sinkhole.<\/p>\n

Para os amantes de Open Source encontramos Pi-Hole, um micro SO que podemos integrar com os nossos servidores DNS j\u00e1 implantados (desde o Microsoft DNS no local at\u00e9 ao Google Cloud DNS) e oferecer uma extens\u00e3o das<\/p>\n

<\/div>\n

 <\/p>\n

O Pi-Hole pode ser utilizado como um reencaminhador DNS para interceptar consultas externas e responder com base em configura\u00e7\u00f5es. Ao contr\u00e1rio da implementa\u00e7\u00e3o anterior, onde s\u00f3 t\u00ednhamos listas de malware AWS, neste caso podemos integrar com v\u00e1rios fornecedores de DNS que j\u00e1 temos:<\/p>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

Ap\u00f3s algumas configura\u00e7\u00f5es simples do modo de bloqueio do dispositivo, estamos prontos para redireccionar pedidos de dom\u00ednios maliciosos:<\/p>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

Uma vez que a Pi-Hole esteja em funcionamento, permite-nos visualizar cada consulta para obter alguns detalhes. Neste caso, tom\u00e1mos alguns dos dom\u00ednios listados como maliciosos para realizar uma s\u00e9rie de testes:<\/p>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

\u00c9 claro que este cen\u00e1rio mostra apenas metade da hist\u00f3ria. Para o completar devemos utilizar algum servi\u00e7o que permita uma monitoriza\u00e7\u00e3o constante, por exemplo para pedidos HTTP e HTTPS, que s\u00e3o tipicamente utilizados para comunica\u00e7\u00e3o com C2s.<\/p>\n

Pode encontrar refer\u00eancias para a implementa\u00e7\u00e3o de um HoneyPot\u00a0aqui<\/a>\u00a0.<\/p>\n

Algumas conclus\u00f5es<\/h2>\n