iphelix/dnschefDNSChef - Proxy DNS pour testeurs de pénétration et analystes de malwares
| | version 0.4 | | / _|
| | __ ___ | | __| |
/ ` | ' / |/ | ' \ / _ \ |
| (| | | | _ \ (| | | | __/ |
_,|| ||/_|| ||___||
D O C U M E N T A T I O N
DNSChef est un proxy DNS hautement configurable destiné aux testeurs d'intrusion et aux analystes de logiciels malveillants. Un proxy DNS (aussi appelé « Fake DNS ») est un outil utilisé pour l'analyse du trafic réseau d'une application, entre autres usages. Par exemple, un proxy DNS peut être utilisé pour falsifier les requêtes vers « badguy.com » afin qu'elles pointent vers une machine locale pour terminaison ou interception au lieu d'un hôte réel quelque part sur Internet.
Il existe plusieurs proxys DNS. La plupart se contentent de rediriger toutes les requêtes DNS vers une seule adresse IP ou implémentent un filtrage rudimentaire. DNSChef a été développé dans le cadre d'un test d'intrusion où un système plus configurable était nécessaire. En conséquence, DNSChef est une application multiplateforme capable de falsifier les réponses en se basant sur des listes de domaines inclusives et exclusives, prenant en charge plusieurs types d'enregistrements DNS, la correspondance de domaines avec des jokers, le proxy des réponses réelles pour les domaines non correspondants, la définition de fichiers de configuration externes, l'IPv6 et de nombreuses autres fonctionnalités. Vous trouverez ci-dessous une explication détaillée de chacune des fonctionnalités et des utilisations suggérées.
L'utilisation d'un proxy DNS est recommandée dans les situations où il n'est pas possible de forcer une application à utiliser directement un autre serveur proxy. Par exemple, certaines applications mobiles ignorent totalement les paramètres de proxy HTTP du système d'exploitation. Dans ces cas, l'utilisation d'un serveur proxy DNS tel que DNSChef vous permettra de tromper cette application afin qu'elle redirige les connexions vers la destination souhaitée.
Avant de pouvoir commencer à utiliser DNSChef, vous devez configurer votre machine pour qu'elle utilise un serveur de noms DNS avec l'outil en cours d'exécution. Vous avez plusieurs options selon le système d'exploitation que vous allez utiliser :
Linux - Modifiez /etc/resolv.conf pour inclure une ligne tout en haut avec votre hôte d'analyse du trafic (par exemple, ajoutez « nameserver 127.0.0.1 » si vous exécutez localement). Alternativement, vous pouvez ajouter une adresse de serveur DNS à l'aide d'outils tels que Network Manager. Dans Network Manager, ouvrez les paramètres IPv4, sélectionnez Adresses automatiques (DHCP) uniquement ou Manuel dans la liste déroulante Méthode et modifiez la zone de texte Serveurs DNS pour inclure une adresse IP avec DNSChef en cours d'exécution.
Windows - Sélectionnez Connexions réseau dans le Panneau de configuration. Sélectionnez ensuite l'une des connexions (par exemple, « Connexion au réseau local »), faites un clic droit dessus et sélectionnez Propriétés. Dans la boîte de dialogue qui apparaît, sélectionnez Protocole Internet (TCP/IP) et cliquez sur Propriétés. Enfin, sélectionnez la case d'option Utiliser l'adresse de serveur DNS suivante et saisissez l'adresse IP avec DNSChef en cours d'exécution. Par exemple, si vous exécutez localement, saisissez 127.0.0.1.
OS X - Ouvrez Préférences Système et cliquez sur l'icône Réseau. Sélectionnez l'interface active et remplissez le champ Serveur DNS. Si vous utilisez Airport, vous devrez cliquer sur le bouton Avancé... et modifier les serveurs DNS à partir de là. Alternativement, vous pouvez modifier /etc/resolv.conf et ajouter un faux serveur de noms tout en haut (par exemple « nameserver 127.0.0.1 »).
iOS - Ouvrez Réglages et sélectionnez Général. Sélectionnez ensuite Wi-Fi et cliquez sur la flèche bleue à droite d'un point d'accès actif dans la liste. Modifiez l'entrée DNS pour pointer vers l'hôte sur lequel DNSChef est exécuté. Assurez-vous d'avoir désactivé l'interface cellulaire (si disponible).
Android - Ouvrez Paramètres et sélectionnez Réseau et Internet (ou Sans fil et réseaux selon la version). Cliquez sur Paramètres Wi-Fi et sélectionnez Avancé après avoir appuyé sur le bouton Options du téléphone. Activez la case à cocher Utiliser une adresse IP statique et configurez un serveur DNS personnalisé.
Si vous n'avez pas la possibilité de modifier manuellement les paramètres DNS de l'appareil, vous avez encore plusieurs options impliquant des techniques telles que l'usurpation ARP, le DHCP malveillant et d'autres méthodes créatives.
Enfin, vous devez configurer un service factice vers lequel DNSChef pointera toutes les requêtes. Par exemple, si vous essayez d'intercepter le trafic Web, vous devez démarrer soit un serveur Web séparé sur le port 80, soit configurer un proxy Web (par exemple Burp) pour intercepter le trafic. DNSChef pointera les requêtes vers votre hôte proxy/serveur avec des services correctement configurés.
DNSChef est une application multiplateforme développée en Python qui devrait fonctionner sur la plupart des plates-formes disposant d'un interpréteur Python. Vous pouvez utiliser l'exécutable dnschef.exe fourni pour l'exécuter sur des hôtes Windows sans installer d'interpréteur Python. Ce guide se concentre sur les environnements Unix ; cependant, tous les exemples ci-dessous ont été testés et fonctionnent également sous Windows.
Goûtons un peu à DNSChef avec sa fonctionnalité de surveillance la plus basique. Exécutez la commande suivante en tant que root (nécessaire pour démarrer un serveur sur le port 53) :
# ./dnschef.py
_ _ __
| | version 0.2 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
[email protected]
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
Sans aucun paramètre, DNSChef s'exécute en mode proxy complet. Cela signifie que toutes les requêtes sont simplement transférées à un serveur DNS en amont (8.8.8.8 par défaut) et renvoyées à l'hôte demandeur. Par exemple, interrogeons un enregistrement « A » pour un domaine et observons les résultats :
$ host -t A thesprawl.org
thesprawl.org has address 108.59.3.64
DNSChef affichera la ligne de journal suivante indiquant l'heure, l'adresse IP source, le type d'enregistrement demandé et, surtout, le nom interrogé :
[23:54:03] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
Ce mode est utile pour la surveillance simple d'une application lorsque vous devez déterminer les domaines qu'elle utilise pour ses communications.
DNSChef prend intégralement en charge IPv6, qui peut être activé à l'aide des options -6 ou --ipv6. Il fonctionne exactement comme le mode IPv4, à l'exception que l'interface d'écoute par défaut est remplacée par ::1 et le serveur DNS par défaut par 2001:4860:4860::8888. Voici un exemple de sortie :
# ./dnschef.py -6
_ _ __
| | version 0.2 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
[email protected]
[*] Using IPv6 mode.
[*] DNSChef started on interface: ::1
[*] Using the following nameservers: 2001:4860:4860::8888
[*] No parameters were specified. Running in full proxy mode
[00:35:44] ::1: proxying the response of type 'A' for thesprawl.org
[00:35:44] ::1: proxying the response of type 'AAAA' for thesprawl.org
[00:35:44] ::1: proxying the response of type 'MX' for thesprawl.org
REMARQUE : Par défaut, DNSChef crée un écouteur UDP. Vous pouvez utiliser TCP à la place avec l'argument --tcp présenté plus loin.
Maintenant que vous savez comment démarrer DNSChef, configurons-le pour falsifier toutes les réponses en pointant vers 127.0.0.1 à l'aide du paramètre --fakeip :
# ./dnschef.py --fakeip 127.0.0.1 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking all A replies to point to 127.0.0.1
[23:55:57] 127.0.0.1: cooking the response of type 'A' for google.com to 127.0.0.1
[23:55:57] 127.0.0.1: proxying the response of type 'AAAA' for google.com
[23:55:57] 127.0.0.1: proxying the response of type 'MX' for google.com
Dans la sortie ci-dessus, vous pouvez voir que DNSChef a été configuré pour transférer toutes les requêtes vers 127.0.0.1. La première ligne du journal à 08:11:23 montre que nous avons « cuisiné » la réponse de l'enregistrement « A » pour pointer vers 127.0.0.1. Cependant, les demandes ultérieures pour les enregistrements 'AAAA' et 'MX' sont simplement transférées depuis un serveur DNS réel. Voyons la sortie du programme demandeur :
$ host google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address 2001:4860:4001:803::1001
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
Comme vous pouvez le constater, le programme a été trompé en utilisant 127.0.0.1 pour l'adresse IPv4. Cependant, les informations obtenues à partir des enregistrements IPv6 (AAAA) et mail (MX) semblent tout à fait légitimes. L'objectif de DNSChef est d'avoir le moins d'impact possible sur le bon fonctionnement du programme, donc si une application dépend d'un serveur de messagerie spécifique, elle en obtiendra un correctement via cette requête transférée.
Falsifions une autre requête pour illustrer comment cibler plusieurs enregistrements en même temps :
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking all A replies to point to 127.0.0.1
[*] Cooking all AAAA replies to point to ::1
[00:02:14] 127.0.0.1: cooking the response of type 'A' for google.com to 127.0.0.1
[00:02:14] 127.0.0.1: cooking the response of type 'AAAA' for google.com to ::1
[00:02:14] 127.0.0.1: proxying the response of type 'MX' for google.com
En plus de l'option --fakeip, j'ai maintenant spécifié --fakeipv6 conçue pour falsifier les requêtes d'enregistrement 'AAAA'. Voici une sortie mise à jour du programme :
$ host google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address ::1
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
Encore une fois, tous les enregistrements non explicitement remplacés par l'application ont été transférés et renvoyés depuis le serveur DNS réel. Cependant, IPv4 (A) et IPv6 (AAAA) ont tous deux été falsifiés pour pointer vers une machine locale.
DNSChef prend en charge plusieurs types d'enregistrements :
+--------+------------------+-----------+-------------------------------+
| Enreg. | Description | Argument | Exemple |
+--------+------------------+-----------+-------------------------------+
| A | Adresse IPv4 | --fakeip | --fakeip 192.0.2.1 |
| AAAA | Adresse IPv6 | --fakeipv6| --fakeipv6 2001:db8::1 |
| MX | Serveur de courriel| --fakemail| --fakemail mail.fake.com |
| CNAME | Enregistrement | --fakealias| --fakealias www.fake.com |
| | CNAME | | |
| NS | Serveur de noms | --fakens | --fakens ns.fake.com |
+--------+------------------+-----------+-------------------------------+
REMARQUE : Pour des raisons d'utilisabilité, tous les types d'enregistrements DNS ne sont pas exposés en ligne de commande. Des enregistrements supplémentaires tels que PTR, TXT, SOA, etc. peuvent être spécifiés à l'aide de l'option --file et d'un en-tête d'enregistrement approprié. Voir la section fichier de définitions externes ci-dessous pour plus de détails.
Enfin, observons comment l'application gère les requêtes de type ANY :
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 --fakemail mail.fake.com --fakealias www.fake.com --fakens ns.fake.com -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking all A replies to point to 127.0.0.1
[*] Cooking all AAAA replies to point to ::1
[*] Cooking all MX replies to point to mail.fake.com
[*] Cooking all CNAME replies to point to www.fake.com
[*] Cooking all NS replies to point to ns.fake.com
[00:17:29] 127.0.0.1: cooking the response of type 'ANY' for google.com with all known fake records.
Les requêtes d'enregistrement DNS ANY entraînent le retour de tous les enregistrements falsifiés connus de DNSChef pour un domaine applicable. Voici la sortie que le programme verra :
$ host -t ANY google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address ::1
google.com mail is handled by 10 mail.fake.com.
google.com is an alias for www.fake.com.
google.com name server ns.fake.com.
En utilisant l'exemple ci-dessus, considérez que vous souhaitez intercepter uniquement les requêtes pour thesprawl.org et laisser les requêtes vers tous les autres domaines comme webfaction.com sans modification. Vous pouvez utiliser le paramètre --fakedomains comme illustré ci-dessous :
# ./dnschef.py --fakeip 127.0.0.1 --fakedomains thesprawl.org -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking replies to point to 127.0.0.1 matching: thesprawl.org
[00:23:37] 127.0.0.1: cooking the response of type 'A' for thesprawl.org to 127.0.0.1
[00:23:52] 127.0.0.1: proxying the response of type 'A' for mx9.webfaction.com
Dans l'exemple ci-dessus, la requête pour thesprawl.org a été falsifiée ; cependant, la requête pour mx9.webfaction.com a été laissée intacte. Le filtrage des domaines est très utile lorsque vous tentez d'isoler une seule application sans perturber le reste.
REMARQUE : DNSChef ne vérifie pas si le domaine existe ou non avant de falsifier la réponse. Si vous avez spécifié un domaine, il sera toujours résolu en une valeur falsifiée, qu'il existe réellement ou non.
Dans une autre situation, vous pouvez avoir besoin de falsifier les réponses pour toutes les requêtes sauf une liste définie de domaines. Vous pouvez accomplir cette tâche à l'aide du paramètre --truedomains comme suit :
# ./dnschef.py --fakeip 127.0.0.1 --truedomains thesprawl.org,*.webfaction.com -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking replies to point to 127.0.0.1 not matching: *.webfaction.com, thesprawl.org
[00:27:57] 127.0.0.1: proxying the response of type 'A' for mx9.webfaction.com
[00:28:05] 127.0.0.1: cooking the response of type 'A' for google.com to 127.0.0.1
Il se passe plusieurs choses dans l'exemple ci-dessus. Remarquez d'abord l'utilisation d'un joker (*). Tous les domaines correspondant à *.webfaction.com seront filtrés en inverse et résolus en leurs valeurs réelles. La requête pour 'google.com' a renvoyé 127.0.0.1 car elle ne faisait pas partie de la liste des domaines exclus.
REMARQUE : Les jokers sont spécifiques à une position. Un masque de type *.thesprawl.org correspondra à www.thesprawl.org mais pas à www.test.thesprawl.org. Cependant, un masque de type ..thesprawl.org correspondra à thesprawl.org, www.thesprawl.org et www.test.thesprawl.org.
Il peut y avoir des situations où la définition d'un seul enregistrement DNS falsifié pour tous les domaines correspondants n'est pas suffisante. Vous pouvez utiliser un fichier externe avec une collection de paires DOMAINE=ENREGISTREMENT définissant exactement où vous souhaitez que la requête aboutisse.
Par exemple, créons le fichier de définitions suivant et appelons-le dnschef.ini :
[A]
*.google.com=192.0.2.1
thesprawl.org=192.0.2.2
*.wordpress.*=192.0.2.3
Remarquez l'en-tête de section [A], il définit le type d'enregistrement pour DNSChef. Observons maintenant attentivement la sortie de plusieurs requêtes :
# ./dnschef.py --file dnschef.ini -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[+] Cooking A replies for domain *.google.com with '192.0.2.1'
[+] Cooking A replies for domain thesprawl.org with '192.0.2.2'
[+] Cooking A replies for domain *.wordpress.* with '192.0.2.3'
[00:43:54] 127.0.0.1: cooking the response of type 'A' for google.com to 192.0.2.1
[00:44:05] 127.0.0.1: cooking the response of type 'A' for www.google.com to 192.0.2.1
[00:44:19] 127.0.0.1: cooking the response of type 'A' for thesprawl.org to 192.0.2.2
[00:44:29] 127.0.0.1: proxying the response of type 'A' for www.thesprawl.org
[00:44:40] 127.0.0.1: cooking the response of type 'A' for www.wordpress.org to 192.0.2.3
[00:44:51] 127.0.0.1: cooking the response of type 'A' for wordpress.com to 192.0.2.3
[00:45:02] 127.0.0.1: proxying the response of type 'A' for slashdot.org
Les deux google.com et www.google.com correspondent à l'entrée *.google.com et sont correctement résolus en 192.0.2.1. D'autre part, la requête pour www.thesprawl.org a simplement été transférée au lieu d'être modifiée. Enfin, toutes les variantes de wordpress.com, www.wordpress.org, etc. correspondent au masque *.wordpress.* et sont correctement résolues en 192.0.2.3. Enfin, une requête non définie slashdot.org a simplement été transférée avec une réponse réelle.
Vous pouvez spécifier des en-têtes de section pour tous les autres types d'enregistrements DNS pris en charge, y compris ceux qui ne sont pas explicitement exposés en ligne de commande : [A], [AAAA], [MX], [NS], [CNAME], [PTR], [NAPTR] et [SOA]. Par exemple, définissons une nouvelle section [PTR] dans le fichier 'dnschef.ini' :
[PTR]
*.2.0.192.in-addr.arpa=fake.com
Observons le comportement de DNSChef avec ce nouveau type d'enregistrement :
./dnschef.py --file dnschef.ini -q
[sudo] password for iphelix:
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[+] Cooking PTR replies for domain *.2.0.192.in-addr.arpa with 'fake.com'
[00:11:34] 127.0.0.1: cooking the response of type 'PTR' for 1.2.0.192.in-addr.arpa to fake.com
Et voici ce qu'un client pourrait voir lors de l'exécution de requêtes DNS inverses :
$ host 192.0.2.1 localhost
1.2.0.192.in-addr.arpa domain name pointer fake.com.
Certains enregistrements nécessitent un formatage exact. De bons exemples sont SOA et NAPTR
[SOA]
*.thesprawl.org=ns.fake.com. hostmaster.fake.com. 1 10800 3600 604800 3600
[NAPTR]
*.thesprawl.org=100 10 U E2U+sip !^.*$!sip:[email protected]! .
Consultez le fichier dnschef.ini d'exemple pour des exemples supplémentaires.
Vous pouvez combiner les entrées d'un fichier et de la ligne de commande. Par exemple, la commande suivante utilise à la fois les paramètres --file et --fakedomains :
# ./dnschef.py --file dnschef.ini --fakeip 6.6.6.6 --fakedomains=thesprawl.org,slashdot.org -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[+] Cooking A replies for domain *.google.com with '192.0.2.1'
[+] Cooking A replies for domain thesprawl.org with '192.0.2.2'
[+] Cooking A replies for domain *.wordpress.* with '192.0.2.3'
[*] Cooking A replies to point to 6.6.6.6 matching: *.wordpress.*, *.google.com, thesprawl.org
[*] Cooking A replies to point to 6.6.6.6 matching: slashdot.org, *.wordpress.*, *.google.com, thesprawl.org
[00:49:05] 127.0.0.1: cooking the response of type 'A' for google.com to 192.0.2.1
[00:49:15] 127.0.0.1: cooking the response of type 'A' for slashdot.org to 6.6.6.6
[00:49:31] 127.0.0.1: cooking the response of type 'A' for thesprawl.org to 6.6.6.6
[00:50:08] 127.0.0.1: proxying the response of type 'A' for tor.com
Remarquez que la définition de thesprawl.org dans le paramètre de ligne de commande a pris le pas sur le fichier dnschef.ini. Cela peut être utile si vous souhaitez remplacer les valeurs du fichier de configuration. slashdot.org se résout toujours en l'adresse IP falsifiée car elle a été spécifiée dans le paramètre --fakedomains. La requête tor.com est simplement transférée car elle n'a été spécifiée ni en ligne de commande ni dans le fichier de configuration.
Autres configurations ====================Pour des raisons de sécurité, DNSChef écoute par défaut sur une interface locale 127.0.0.1 (ou ::1 pour IPv6). Vous pouvez faire écouter DNSChef sur une autre interface en utilisant le paramètre --interface :
# ./dnschef.py --interface 0.0.0.0 -q
[*] DNSChef started on interface: 0.0.0.0
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
[00:50:53] 192.0.2.105: proxying the response of type 'A' for thesprawl.org
ou pour IPv6 :
# ./dnschef.py -6 --interface :: -q
[*] Using IPv6 mode.
[*] DNSChef started on interface: ::
[*] Using the following nameservers: 2001:4860:4860::8888
[*] No parameters were specified. Running in full proxy mode
[00:57:46] 2001:db8::105: proxying the response of type 'A' for thesprawl.org
Par défaut, DNSChef utilise le serveur DNS public de Google pour effectuer les requêtes proxy. Cependant, vous pouvez définir une liste personnalisée de serveurs de noms en utilisant le paramètre --nameservers :
# ./dnschef.py --nameservers 4.2.2.1,4.2.2.2 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 4.2.2.1, 4.2.2.2
[*] No parameters were specified. Running in full proxy mode
[00:55:08] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
Il est possible de spécifier un port non standard pour le serveur de noms en utilisant la notation IP#PORT :
# ./dnschef.py --nameservers 192.0.2.2#5353 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 192.0.2.2#5353
[*] No parameters were specified. Running in full proxy mode
[02:03:12] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
Simultanément, il est possible de lancer DNSChef lui-même sur un port alternatif en utilisant le paramètre -p port# :
# ./dnschef.py -p 5353 -q
[*] Listening on an alternative port 5353
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
Le protocole DNS peut être utilisé sur UDP (par défaut) ou TCP. DNSChef implémente un mode TCP qui peut être activé avec le drapeau --tcp.
Voici quelques informations sur les aspects internes au cas où vous auriez besoin d'adapter l'outil à vos besoins. DNSChef est construit sur le module SocketServer et utilise le threading pour traiter plusieurs requêtes simultanément. L'outil est conçu pour écouter sur les ports TCP ou UDP (par défaut le port 53) pour les requêtes entrantes et transmettre ces requêtes, si nécessaire, à un vrai serveur DNS via UDP.
L'excellente bibliothèque dnslib est utilisée pour disséquer et réassembler les paquets DNS. Elle est particulièrement utile lors de la génération de paquets de réponse basés sur les requêtes.
DNSChef est capable de modifier les requêtes pour les enregistrements de type "A", "AAAA", "MX", "CNAME", "NS", "TXT", "PTR", "NAPTR", "SOA", "ANY". Il est très facile d'étendre ou de modifier le comportement pour n'importe quel enregistrement. Ajoutez simplement une autre entrée if qtype == "TYPE_ENREGISTREMENT") et indiquez ce qu'il doit répondre.
Profitez de l'outil et transmettez toutes les demandes et commentaires à iphelix [at] thesprawl.org.
Bon hacking ! -Peter