phillipmartin/gopassivednsEnregistreur DNS passif basé sur le réseau capturant et enregistrant les requêtes DNS à partir du trafic en direct ou de fichiers pcap, produisant du JSON pour l'intégration avec les plateformes SIEM et de renseignement sur les menaces.
Journalisation DNS basée sur le réseau en Go
Un journaliseur DNS basé sur la capture réseau, inspiré de https://github.com/gamelinux/passivedns. Il utilise gopacket pour traiter libpcap et le traitement des paquets. Il produit des journaux au format JSON. Il est conçu pour gérer la capture de requêtes à haut volume dans des environnements comptant de un à des centaines de résolveurs DNS.
C'est un bon choix. J'ai construit celui-ci car je pense que les tâches impliquant le traitement de grandes quantités de données non fiables avec de nombreux cas particuliers mal documentés devraient être gérées par un runtime managé pour éviter les attaques par corruption mémoire. J'ai déployé PassiveDNS dans plusieurs organisations, et j'ai créé gopassivedns pour résoudre quelques problèmes spécifiques que j'ai observés : j'avais besoin d'instrumenter de nombreux emplacements, j'avais besoin de faire évoluer la couche de stockage pour gérer BEAUCOUP de requêtes et je voulais une suite de tests avec une bonne couverture autour de tous les cas limites DNS.
Également un bon choix. Les systèmes comme Bro sont généralement déployés sur les sorties réseau, ce qui a pour conséquence de masquer la source réelle de la requête derrière vos résolveurs récursifs. Cela signifie que vous devez généralement déployer Bro et faire la journalisation des requêtes du résolveur (en supposant que vous le puissiez), et intégrer les journaux des deux dans un système de journalisation central pour suivre une requête jusqu'à un client. gopassivedns a été conçu pour être déployé sur vos résolveurs sans modification de configuration du résolveur et/ou sur vos sorties réseau, pour journaliser de manière centralisée via un protocole fiable et être analysé simplement dans tout système de journalisation.
Le support de la journalisation des requêtes par les résolveurs, incluant à la fois la question et la réponse, est inégal au mieux. L'un des serveurs DNS les plus déployés, BIND, ne le supporte pas du tout. D'autres, comme le DNS Windows, ont des formats de journal vraiment horribles. De plus, la journalisation basée sur le réseau capturera les requêtes envoyées directement à des serveurs distants (par exemple Google DNS) depuis vos clients.
Les options de configuration peuvent être spécifiées en tant que variables d'environnement, dans un fichier .env ou sur la ligne de commande. La priorité est : les drapeaux de ligne de commande, le fichier .env, et enfin les variables déjà définies dans l'environnement. Les options de configuration sont les suivantes
Vous devez fournir soit -dev soit -pcap.
Il existe des problèmes connus avec les goroutines et le processus de démonisation standard (https://github.com/golang/go/issues/227), donc je recommande fortement d'utiliser l'une des méthodes détaillées ici : http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu pour exécuter ce processus en tant que démon en utilisant les outils système.
Si vous choisissez d'utiliser la journalisation syslog, nous utilisons le "log/syslog" de golang qui nécessite qu'un socket Unix utilisé pour communiquer avec syslog se trouve à l'un des emplacements suivants : /dev/log, /var/run/log ou /var/run/syslog.
Vous avez 3 choix : le déployer sur votre(vos) résolveur(s) ou le déployer sur votre(vos) passerelle(s) ou les deux. Le déployer sur vos résolveurs est intéressant car vous obtiendrez l'adresse IP du client qui a envoyé la requête originale. Vous pouvez également voir la branche montante de la requête (du résolveur au résolveur suivant dans la chaîne), à moins que vous n'ajustiez votre filtre BPF pour ignorer cette branche. Le déployer sur vos passerelles signifie que vous ne voyez pas la branche client -> résolveur interne, donc il peut être difficile de relier une requête à un client spécifique. D'un autre côté, vous verrez les requêtes qui contournent vos résolveurs internes. Vous verrez également, bien sûr, les requêtes provenant du résolveur vers le résolveur montant qu'il utilise. Dans un monde idéal, je déploierais cet outil sur chacun de mes résolveurs internes et sur une sonde sur mes passerelles. Les résolveurs internes auraient un filtre BPF tel qu'il ignore la branche montante de la requête, et la passerelle n'ignorerait rien.
Pour l'instant, je recommanderais d'utiliser logstash pour acheminer les journaux vers un cluster elasticsearch. Tous les journaux sont au format JSON, donc cela devrait être assez facile. Je suggérerais également d'utiliser quelque chose comme HDFS pour le stockage à long terme et l'analyse en masse. Les requêtes DNS sont une source incroyable de données internes !
