phillipmartin/gopassivednsRegistrador DNS passivo baseado em rede que captura e registra consultas DNS de tráfego ao vivo ou arquivos pcap, gerando saída em JSON para integração com plataformas SIEM e de inteligência de ameaças.
Registro de DNS baseado em rede em Go
Um registrador de DNS baseado em captura de rede, inspirado por https://github.com/gamelinux/passivedns. Ele usa gopacket para lidar com libpcap e processamento de pacotes. Ele gera logs em JSON. Ele é projetado para lidar com captura de consultas de alto volume em ambientes com de um a centenas de resolvedores DNS.
É uma boa escolha. Construí isso porque acredito que tarefas que envolvem processar grandes quantidades de dados não confiáveis com muitos casos extremos mal documentados devem ser tratadas por um runtime gerenciado para evitar ataques de corrupção de memória. Implantei o PassiveDNS em várias organizações, e construí o gopassivedns para resolver alguns pontos específicos de dor que observei: precisava instrumentar muitos locais, precisava escalar a camada de armazenamento para lidar com MUITAS consultas e queria um conjunto de testes com boa cobertura em torno de todos os casos extremos de DNS.
Também uma boa escolha. Sistemas como Bro são geralmente implantados nas saídas de rede, o que tem a consequência de mascarar a fonte real da consulta atrás dos seus resolvedores recursivos. Isso significa que você geralmente precisa implantar o Bro e fazer o registro de consultas do resolvedor (assumindo que você possa), e integrar os logs de ambos em um sistema de registro central para rastrear uma consulta de volta a um cliente. O gopassivedns foi projetado para ser implantado nos seus resolvedores sem alterações de configuração do resolvedor e/ou nas suas saídas de rede, registrar centralmente via um protocolo confiável e analisar simplesmente em qualquer sistema de log.
O suporte do resolvedor para registro de consultas, incluindo tanto a pergunta quanto a resposta, é irregular na melhor das hipóteses. Um dos servidores DNS mais implantados, o BIND, não suporta isso de forma alguma. Outros, como o DNS do Windows, têm formatos de log realmente horríveis. Além disso, o registro baseado em rede capturará consultas enviadas diretamente a servidores remotos (ex.: Google DNS) a partir dos seus clientes.
As opções de configuração podem ser especificadas como variáveis de ambiente, em um arquivo .env ou na linha de comando. A prioridade é flags de linha de comando, arquivo .env e, finalmente, variáveis já definidas no ambiente. As opções de configuração são as seguintes
Você deve fornecer -dev ou -pcap.
Existem problemas conhecidos com goroutines e o processo padrão de daemonização (https://github.com/golang/go/issues/227), então recomendo fortemente que você use um dos métodos detalhados aqui: http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu para executar este processo como um daemon usando ferramentas do sistema.
Se você escolher usar registro syslog, usamos o "log/syslog" do golang que requer um socket unix usado para comunicar com syslog em um dos seguintes: /dev/log, /var/run/log ou /var/run/syslog.
Você tem 3 opções: implantá-lo no(s) seu(s) resolvedor(es) ou implantá-lo no(s) seu(s) gateway(s) ou ambos. Implantar nos seus resolvedores é bom porque você obterá o endereço IP do cliente que enviou a solicitação original. Você também pode ver a etapa upstream da solicitação (do resolvedor para o próximo resolvedor na cadeia), a menos que ajuste seu filtro BPF para ignorar essa etapa. Implantar nos seus gateways significa que você não vê a etapa cliente -> resolvedor interno, então pode ser difícil associar uma solicitação a um cliente específico. Por outro lado, você verá solicitações que ignoram seus resolvedores internos. Você também verá, é claro, as consultas vindas do resolvedor para qualquer resolvedor upstream que ele use. Em um mundo ideal, eu implantaria esta ferramenta em cada um dos meus resolvedores internos e em um tap nos meus gateways. Os resolvedores internos teriam um filtro BPF que ignora a etapa upstream da consulta, e o gateway não ignoraria nada.
No momento, recomendo usar o logstash para enviar os logs para um cluster elasticsearch. Todos os logs são JSON, então isso deve ser bem fácil. Sugiro também usar algo como HDFS para armazenamento de longo prazo e análise em massa. Consultas DNS são uma fonte incrível de dados internos!
