Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
dnschef — DNSChef - proxy DNS per Penetration Tester e Analisti di Malware | Kitploit
Strumenti/GitHubGitHub/iphelix/dnschef
Raccolta InformazioniSicurezza di ReteAnalisi MalwarePenetration TestingAnalisi DNS
GitHubiphelix/dnschef

dnschef

DNSChef - proxy DNS per Penetration Tester e Analisti di Malware

Vedi Repository
1.1k2257 anni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

root@kitploit:~
 | | versione 0.4 | |        / _|

| | __ ___ | | __| | / ` | ' / |/ | ' \ / _ \ | | (| | | | _ \ (| | | | __/ |
_
,
|| ||/_|| ||___||

root@kitploit:~
   D O C U M E N T A Z I O N E

DNSChef è un proxy DNS altamente configurabile per tester di penetrazione e analisti di malware. Un proxy DNS (anche noto come "Fake DNS") è uno strumento utilizzato per l'analisi del traffico di rete delle applicazioni, tra gli altri usi. Ad esempio, un proxy DNS può essere usato per falsificare richieste verso "badguy.com" in modo che puntino a una macchina locale per la terminazione o l'intercettazione invece che a un host reale su Internet.

Esistono diversi proxy DNS là fuori. La maggior parte si limita a indirizzare tutte le query DNS verso un singolo indirizzo IP o implementa solo un filtraggio rudimentale. DNSChef è stato sviluppato nell'ambito di un penetration test dove c'era la necessità di un sistema più configurabile. Di conseguenza, DNSChef è un'applicazione multipiattaforma in grado di forgiare risposte basate su elenchi di domini inclusivi ed esclusivi, supportare più tipi di record DNS, abbinare domini con wildcard, inoltrare le risposte reali per i domini non corrispondenti, definire file di configurazione esterni, IPv6 e molte altre funzionalità. Di seguito troverai una spiegazione dettagliata di ciascuna funzionalità e suggerimenti per l'utilizzo.

L'uso di un proxy DNS è consigliato in situazioni in cui non è possibile forzare un'applicazione a utilizzare direttamente un altro proxy. Ad esempio, alcune applicazioni mobili ignorano completamente le impostazioni del proxy HTTP del sistema operativo. In questi casi, l'uso di un proxy DNS come DNSChef ti permetterà di ingannare quell'applicazione facendole instradare le connessioni verso la destinazione desiderata.

Impostazione di un proxy DNS

Prima di poter iniziare a usare DNSChef, devi configurare la tua macchina in modo che utilizzi un nameserver DNS con lo strumento in esecuzione. Hai diverse opzioni a seconda del sistema operativo che intendi utilizzare:

  • Linux - Modifica /etc/resolv.conf per includere una riga all'inizio con il tuo host di analisi del traffico (ad esempio, aggiungi "nameserver 127.0.0.1" se stai eseguendo localmente). In alternativa, puoi aggiungere un indirizzo del server DNS utilizzando strumenti come Network Manager. All'interno di Network Manager, apri Impostazioni IPv4, seleziona Solo indirizzi Automatic (DHCP) o Manuale dal menu a tendina Metodo e modifica la casella di testo Server DNS per includere un indirizzo IP con DNSChef in esecuzione.

  • Windows - Seleziona Connessioni di rete dal Pannello di controllo. Successivamente seleziona una delle connessioni (ad es. "Connessione alla rete locale"), fai clic destro su di essa e seleziona Proprietà. Dalla finestra di dialogo che appare, seleziona Protocollo Internet (TCP/IP) e fai clic su Proprietà. Infine seleziona il pulsante di opzione Utilizza i seguenti indirizzi server DNS e inserisci l'indirizzo IP con DNSChef in esecuzione. Ad esempio, se esegui localmente, inserisci 127.0.0.1.

  • OS X - Apri Preferenze di Sistema e fai clic sull'icona Rete. Seleziona l'interfaccia attiva e inserisci il campo Server DNS. Se stai usando Airport, dovrai fare clic sul pulsante Avanzate... e modificare i server DNS da lì. In alternativa, puoi modificare /etc/resolv.conf e aggiungere un nameserver falso all'inizio (ad es. "nameserver 127.0.0.1").

  • iOS - Apri Impostazioni e seleziona Generali. Successivamente seleziona Wi-Fi e fai clic sulla freccia blu a destra di un punto di accesso attivo dall'elenco. Modifica la voce DNS in modo che punti all'host con DNSChef in esecuzione. Assicurati di aver disabilitato l'interfaccia cellulare (se disponibile).

  • Android - Apri Impostazioni e seleziona Wireless e reti. Fai clic su Impostazioni Wi-Fi e seleziona Avanzate dopo aver premuto il pulsante Opzioni sul telefono. Abilita la casella Usa IP statico e configura un server DNS personalizzato.

Se non hai la possibilità di modificare manualmente le impostazioni DNS del dispositivo, hai comunque diverse opzioni che coinvolgono tecniche come ARP Spoofing, Rogue DHCP e altri metodi creativi.

Infine, devi configurare un servizio falso a cui DNSChef indirizzerà tutte le richieste. Ad esempio, se stai cercando di intercettare il traffico web, devi avviare un server web separato in esecuzione sulla porta 80 o impostare un proxy web (ad es. Burp) per intercettare il traffico. DNSChef indirizzerà le query al tuo host proxy/server con servizi configurati correttamente.

Esecuzione di DNSChef

DNSChef è un'applicazione multipiattaforma sviluppata in Python che dovrebbe funzionare sulla maggior parte delle piattaforme che dispongono di un interprete Python. Puoi utilizzare l'eseguibile dnschef.exe fornito per eseguirlo su host Windows senza installare un interprete Python. Questa guida si concentrerà sugli ambienti Unix; tuttavia, tutti gli esempi seguenti sono stati testati per funzionare anche su Windows.

Proviamo un assaggio di DNSChef con la sua funzionalità di monitoraggio più basilare. Esegui il seguente comando come root (necessario per avviare un server sulla porta 53):

root@kitploit:~
# ./dnschef.py
    
          _                _          __  
         | | versione 0.2 | |        / _| 
       __| |_ __  ___  ___| |__   ___| |_ 
      / _` | '_ \/ __|/ __| '_ \ / _ \  _|
     | (_| | | | \__ \ (__| | | |  __/ |  
      \__,_|_| |_|___/\___|_| |_|\___|_|  
                   [email protected]  

[*] DNSChef avviato sull'interfaccia: 127.0.0.1 
[*] Utilizzo dei seguenti nameserver: 8.8.8.8
[*] Nessun parametro specificato. Esecuzione in modalità proxy completo

Senza parametri, DNSChef funzionerà in modalità proxy completo. Ciò significa che tutte le richieste verranno semplicemente inoltrate a un server DNS upstream (8.8.8.8 per impostazione predefinita) e restituite all'host richiedente. Ad esempio, interroghiamo un record "A" per un dominio e osserviamo i risultati:

root@kitploit:~
$ host -t A thesprawl.org
thesprawl.org has address 108.59.3.64

DNSChef stamperà la seguente riga di log che mostra l'ora, l'indirizzo IP di origine, il tipo di record richiesto e, cosa più importante, quale nome è stato interrogato:

root@kitploit:~
[23:54:03] 127.0.0.1: inoltro della risposta di tipo 'A' per thesprawl.org

Questa modalità è utile per il semplice monitoraggio delle applicazioni, quando è necessario scoprire quali domini utilizza per le sue comunicazioni.

DNSChef supporta completamente IPv6, che può essere attivato usando i flag -6 o --ipv6*. Funziona esattamente come la modalità IPv4, con l'eccezione che l'interfaccia di ascolto predefinita viene cambiata in ::1 e il server DNS predefinito viene cambiato in 2001:4860:4860::8888. Ecco un esempio di output:

root@kitploit:~
# ./dnschef.py -6
          _                _          __
         | | versione 0.2 | |        / _|
       __| |_ __  ___  ___| |__   ___| |_
      / _` | '_ \/ __|/ __| '_ \ / _ \  _|
     | (_| | | | \__ \ (__| | | |  __/ |
      \__,_|_| |_|___/\___|_| |_|\___|_|
                   [email protected]

[*] Utilizzo della modalità IPv6.
[*] DNSChef avviato sull'interfaccia: ::1
[*] Utilizzo dei seguenti nameserver: 2001:4860:4860::8888
[*] Nessun parametro specificato. Esecuzione in modalità proxy completo
[00:35:44] ::1: inoltro della risposta di tipo 'A' per thesprawl.org
[00:35:44] ::1: inoltro della risposta di tipo 'AAAA' per thesprawl.org
[00:35:44] ::1: inoltro della risposta di tipo 'MX' per thesprawl.org

NOTA: Per impostazione predefinita, DNSChef crea un listener UDP. Puoi usare TCP invece con l'argomento --tcp discusso in seguito.

Intercettare tutte le risposte

Ora che sai come avviare DNSChef, configuriamolo per falsificare tutte le risposte in modo che puntino a 127.0.0.1 usando il parametro --fakeip:

root@kitploit:~
# ./dnschef.py --fakeip 127.0.0.1 -q
[*] DNSChef avviato sull'interfaccia: 127.0.0.1 
[*] Utilizzo dei seguenti nameserver: 8.8.8.8
[*] Cottura di tutte le risposte A per puntare a 127.0.0.1
[23:55:57] 127.0.0.1: cottura della risposta di tipo 'A' per google.com a 127.0.0.1
[23:55:57] 127.0.0.1: inoltro della risposta di tipo 'AAAA' per google.com
[23:55:57] 127.0.0.1: inoltro della risposta di tipo 'MX' per google.com

Nell'output sopra puoi vedere che DNSChef è stato configurato per inoltrare tutte le richieste a 127.0.0.1. La prima riga di log alle 08:11:23 mostra che abbiamo "cotto" la risposta del record "A" per puntare a 127.0.0.1. Tuttavia, le successive richieste per i record 'AAAA' e 'MX' sono semplicemente inoltrate da un server DNS reale. Vediamo l'output del programma richiedente:

root@kitploit:~
$ 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.

Come puoi vedere, il programma è stato ingannato per utilizzare 127.0.0.1 per l'indirizzo IPv4. Tuttavia, le informazioni ottenute dai record IPv6 (AAAA) e mail (MX) appaiono completamente legittime. L'obiettivo di DNSChef è avere il minimo impatto sul corretto funzionamento del programma, quindi se un'applicazione si basa su un server di posta specifico, lo otterrà correttamente tramite questa richiesta inoltrata.

Falsifichiamo un'altra richiesta per illustrare come targeting di più record contemporaneamente:

root@kitploit:~
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 -q
[*] DNSChef avviato sull'interfaccia: 127.0.0.1 
[*] Utilizzo dei seguenti nameserver: 8.8.8.8
[*] Cottura di tutte le risposte A per puntare a 127.0.0.1
[*] Cottura di tutte le risposte AAAA per puntare a ::1
[00:02:14] 127.0.0.1: cottura della risposta di tipo 'A' per google.com a 127.0.0.1
[00:02:14] 127.0.0.1: cottura della risposta di tipo 'AAAA' per google.com a ::1
[00:02:14] 127.0.0.1: inoltro della risposta di tipo 'MX' per google.com

Oltre al flag --fakeip, ho ora specificato --fakeipv6 progettato per falsificare le query del record 'AAAA'. Ecco un output aggiornato del programma:

root@kitploit:~
$ 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.

Ancora una volta, tutti i record non esplicitamente sovrascritti dall'applicazione sono stati inoltrati e restituiti dal server DNS reale. Tuttavia, sia IPv4 (A) che IPv6 (AAAA) sono stati falsificati per puntare a una macchina locale.

DNSChef supporta più tipi di record:

root@kitploit:~
+--------+-----------------------------+-----------+--------------------------------------+
| Record |  Descrizione                 | Argomento | Esempio                              |
+--------+-----------------------------+-----------+--------------------------------------+
|  A     | Indirizzo IPv4               |--fakeip   | --fakeip 192.0.2.1                   |
|  AAAA  | Indirizzo IPv6               |--fakeipv6 | --fakeipv6 2001:db8::1               |
|  MX    | Server di posta              |--fakemail | --fakemail mail.fake.com             |
|  CNAME | Record CNAME                 |--fakealias| --fakealias www.fake.com             |
|  NS    | Server dei nomi              |--fakens   | --fakens ns.fake.com                 |
+--------+-----------------------------+-----------+--------------------------------------+

NOTA: Per usabilità, non tutti i tipi di record DNS sono esposti sulla riga di comando. Record aggiuntivi come PTR, TXT, SOA, ecc. possono essere specificati usando il flag --file e un'intestazione di record appropriata. Vedi la sezione file di definizioni esterni di seguito per i dettagli.

Infine, osserviamo come l'applicazione gestisce le query di tipo ANY:

root@kitploit:~
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 --fakemail mail.fake.com --fakealias www.fake.com --fakens ns.fake.com -q
[*] DNSChef avviato sull'interfaccia: 127.0.0.1 
[*] Utilizzo dei seguenti nameserver: 8.8.8.8
[*] Cottura di tutte le risposte A per puntare a 127.0.0.1
[*] Cottura di tutte le risposte AAAA per puntare a ::1
[*] Cottura di tutte le risposte MX per puntare a mail.fake.com
[*] Cottura di tutte le risposte CNAME per puntare a www.fake.com
[*] Cottura di tutte le risposte NS per puntare a ns.fake.com
[00:17:29] 127.0.0.1: cottura della risposta di tipo 'ANY' per google.com con tutti i record falsi conosciuti.

Le query di record DNS ANY determinano il ritorno da parte di DNSChef di ogni record falso che conosce per un dominio applicabile. Ecco l'output che il programma vedrà:

root@kitploit:~
$ 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.

Filtraggio dei domini

Usando l'esempio precedente, supponi di voler intercettare solo le richieste per thesprawl.org e lasciare inalterate le query verso tutti gli altri domini come webfaction.com. Puoi usare il parametro --fakedomains come illustrato di seguito:

root@kitploit:~
# ./dnschef.py --fakeip 127.0.0.1 --fakedomains thesprawl.org -q
[*] DNSChef avviato sull'interfaccia: 127.0.0.1
[*] Utilizzo dei seguenti nameserver: 8.8.8.8  
[*] Cottura delle risposte per puntare a 127.0.0.1 corrispondente a: thesprawl.org
[00:23:37] 127.0.0.1: cottura della risposta di tipo 'A' per thesprawl.org a 127.0.0.1
[00:23:52] 127.0.0.1: inoltro della risposta di tipo 'A' per mx9.webfaction.com

Dall'esempio sopra, la richiesta per thesprawl.org è stata falsificata; tuttavia, la richiesta per mx9.webfaction.com è stata lasciata invariata. Filtrare i domini è molto utile quando si cerca di isolare una singola applicazione senza rompere il resto.

NOTA: DNSChef non verificherà se il dominio esiste o meno prima di falsificare la risposta. Se hai specificato un dominio, verrà sempre risolto a un valore falso, sia esso realmente esistente o meno.

Filtraggio inverso

In un'altra situazione potresti aver bisogno di falsificare le risposte per tutte le richieste tranne un elenco definito di domini. Puoi realizzare questo compito usando il parametro --truedomains come segue:

root@kitploit:~
# ./dnschef.py --fakeip 127.0.0.1 --truedomains thesprawl.org,*.webfaction.com -q
[*] DNSChef avviato sull'interfaccia: 127.0.0.1
[*] Utilizzo dei seguenti nameserver: 8.8.8.8  
[*] Cottura delle risposte per puntare a 127.0.0.1 non corrispondente a: *.webfaction.com, thesprawl.org
[00:27:57] 127.0.0.1: inoltro della risposta di tipo 'A' per mx9.webfaction.com
[00:28:05] 127.0.0.1: cottura della risposta di tipo 'A' per google.com a 127.0.0.1

Nell'esempio sopra accadono diverse cose. Innanzitutto nota l'uso di un wildcard (*). Tutti i domini corrispondenti a *.webfaction.com verranno abbinati inversamente e risolti ai loro valori reali. La richiesta per 'google.com' ha restituito 127.0.0.1 perché non era nell'elenco dei domini esclusi.

NOTA: I wildcard sono posizionali. Una maschera di tipo *.thesprawl.org corrisponderà a www.thesprawl.org ma non a www.test.thesprawl.org. Tuttavia, una maschera di tipo ..thesprawl.org corrisponderà a thesprawl.org, www.thesprawl.org e www.test.thesprawl.org.

File di definizioni esterni

Potrebbero verificarsi situazioni in cui definire un singolo record DNS falso per tutti i domini corrispondenti non è sufficiente. Puoi usare un file esterno con una raccolta di coppie DOMINIO=RECORD che definiscono esattamente dove vuoi che la richiesta vada.

Ad esempio, creiamo il seguente file di definizioni e chiamiamolo dnschef.ini:

root@kitploit:~
[A]
*.google.com=192.0.2.1
thesprawl.org=192.0.2.2
*.wordpress.*=192.0.2.3

Nota l'intestazione di sezione [A], che definisce il tipo di record per DNSChef. Ora osserviamo attentamente l'output di più query:

root@kitploit:~
# ./dnschef.py --file dnschef.ini -q
[*] DNSChef avviato sull'interfaccia: 127.0.0.1 
[*] Utilizzo dei seguenti nameserver: 8.8.8.8
[+] Cottura delle risposte A per il dominio *.google.com con '192.0.2.1'
[+] Cottura delle risposte A per il dominio thesprawl.org con '192.0.2.2'
[+] Cottura delle risposte A per il dominio *.wordpress.* con '192.0.2.3'
[00:43:54] 127.0.0.1: cottura della risposta di tipo 'A' per google.com a 192.0.2.1
[00:44:05] 127.0.0.1: cottura della risposta di tipo 'A' per www.google.com a 192.0.2.1
[00:44:19] 127.0.0.1: cottura della risposta di tipo 'A' per thesprawl.org a 192.0.2.2
[00:44:29] 127.0.0.1: inoltro della risposta di tipo 'A' per www.thesprawl.org
[00:44:40] 127.0.0.1: cottura della risposta di tipo 'A' per www.wordpress.org a 192.0.2.3
[00:44:51] 127.0.0.1: cottura della risposta di tipo 'A' per wordpress.com a 192.0.2.3
[00:45:02] 127.0.0.1: inoltro della risposta di tipo 'A' per slashdot.org

Sia google.com che www.google.com hanno corrisposto alla voce *.google.com e si sono correttamente risolte a 192.0.2.1. D'altra parte, la richiesta per www.thesprawl.org è stata semplicemente inoltrata invece di essere modificata. Infine, tutte le varianti di wordpress.com, www.wordpress.org, ecc. hanno corrisposto alla maschera *.wordpress.* e si sono correttamente risolte a 192.0.2.3. Infine, una query non definita slashdot.org è stata semplicemente inoltrata con una risposta reale.

Puoi specificare intestazioni di sezione per tutti gli altri tipi di record DNS supportati, inclusi quelli non esplicitamente esposti sulla riga di comando: [A], [AAAA], [MX], [NS], [CNAME], [PTR], [NAPTR] e [SOA]. Ad esempio, definiamo una nuova sezione [PTR] nel file 'dnschef.ini':

root@kitploit:~
[PTR]
*.2.0.192.in-addr.arpa=fake.com

Osserviamo il comportamento di DNSChef con questo nuovo tipo di record:

root@kitploit:~
 ./dnschef.py --file dnschef.ini -q
[sudo] password for iphelix: 
[*] DNSChef avviato sull'interfaccia: 127.0.0.1 
[*] Utilizzo dei seguenti nameserver: 8.8.8.8
[+] Cottura delle risposte PTR per il dominio *.2.0.192.in-addr.arpa con 'fake.com'
[00:11:34] 127.0.0.1: cottura della risposta di tipo 'PTR' per 1.2.0.192.in-addr.arpa a fake.com

Ed ecco cosa potrebbe vedere un client quando esegue query DNS inverse:

root@kitploit:~
$ host 192.0.2.1 localhost
1.2.0.192.in-addr.arpa domain name pointer fake.com.

Alcuni record richiedono una formattazione esatta. Buoni esempi sono SOA e NAPTR:

root@kitploit:~
[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]! .

Vedi il file dnschef.ini di esempio per ulteriori esempi.

Filtraggio avanzato

Puoi mescolare e abbinare l'input da un file e dalla riga di comando. Ad esempio, il seguente comando usa entrambi i parametri --file e --fakedomains:

root@kitploit:~
# ./dnschef.py --file dnschef.ini --fakeip 6.6.6.6 --fakedomains=thesprawl.org,slashdot.org -q
[*] DNSChef avviato sull'interfaccia: 127.0.0.1 
[*] Utilizzo dei seguenti nameserver: 8.8.8.8
[+] Cottura delle risposte A per il dominio *.google.com con '192.0.2.1'
[+] Cottura delle risposte A per il dominio thesprawl.org con '192.0.2.2'
[+] Cottura delle risposte A per il dominio *.wordpress.* con '192.0.2.3'
[*] Cottura delle risposte A per puntare a 6.6.6.6 corrispondente a: *.wordpress.*, *.google.com, thesprawl.org
[*] Cottura delle risposte A per puntare a 6.6.6.6 corrispondente a: slashdot.org, *.wordpress.*, *.google.com, thesprawl.org
[00:49:05] 127.0.0.1: cottura della risposta di tipo 'A' per google.com a 192.0.2.1
[00:49:15] 127.0.0.1: cottura della risposta di tipo 'A' per slashdot.org a 6.6.6.6
[00:49:31] 127.0.0.1: cottura della risposta di tipo 'A' per thesprawl.org a 6.6.6.6
[00:50:08] 127.0.0.1: inoltro della risposta di tipo 'A' per tor.com

Nota che la definizione per thesprawl.org nel parametro della riga di comando ha avuto la precedenza su dnschef.ini. Ciò potrebbe essere utile se desideri sovrascrivere i valori nel file di configurazione. slashdot.org si risolve ancora all'indirizzo IP falso perché è stato specificato nel parametro --fakedomains. La richiesta per tor.com viene semplicemente inoltrata poiché non è stata specificata né nella riga di comando né nel file di configurazione.

Altre configurazioni ====================Per ragioni di sicurezza, DNSChef ascolta su un'interfaccia locale 127.0.0.1 (o ::1 per IPv6) per impostazione predefinita. Puoi far ascoltare DNSChef su un'altra interfaccia usando il parametro --interface:

root@kitploit:~
# ./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

o per IPv6:

root@kitploit:~
# ./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

Per impostazione predefinita, DNSChef utilizza il server DNS pubblico di Google per effettuare richieste proxy. Tuttavia, puoi definire una lista personalizzata di nameserver usando il parametro --nameservers:

root@kitploit:~
# ./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

È possibile specificare una porta del nameserver non standard usando la notazione IP#PORTA:

root@kitploit:~
# ./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

Allo stesso tempo è possibile avviare DNSChef stesso su una porta alternativa usando il parametro -p porta#:

root@kitploit:~
# ./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

Il protocollo DNS può essere utilizzato su UDP (predefinito) o TCP. DNSChef implementa una modalità TCP che può essere attivata con il flag --tcp.

Architettura interna

Ecco alcune informazioni sugli interni nel caso tu debba adattare lo strumento alle tue esigenze. DNSChef è costruito sul modulo SocketServer e utilizza il threading per aiutare a elaborare più richieste contemporaneamente. Lo strumento è progettato per ascoltare su porte TCP o UDP (per impostazione predefinita è la porta 53) per le richieste in entrata e inoltrare tali richieste, quando necessario, a un server DNS reale su UDP.

L'eccellente libreria dnslib viene utilizzata per analizzare e riassemblare i pacchetti DNS. È particolarmente utile quando si generano pacchetti di risposta basati sulle query.

DNSChef è in grado di modificare le query per i record di tipo "A", "AAAA", "MX", "CNAME", "NS", "TXT", "PTR", "NAPTR", "SOA", "ANY". È molto semplice espandere o modificare il comportamento per qualsiasi record. Basta aggiungere un altro blocco if qtype == "TIPO DI RECORD") e dirgli cosa rispondere.

Divertiti con lo strumento e invia tutte le richieste e i commenti a iphelix [at] thesprawl.org.

Happy hacking! -Peter

Scarica lo strumento