yarrick/iodineInstrada dati IPv4 attraverso server DNS per bypassare le restrizioni del firewall e fornire accesso di rete occulto per i test di penetrazione.
Questo è un software che permette di instradare dati IPv4 attraverso un server DNS. Può essere utile in diverse situazioni in cui l'accesso a Internet è filtrato da un firewall, ma le query DNS sono consentite.
Iodine non ha uno script configure. Ci sono due funzionalità opzionali per Linux (supporto SELinux e systemd) che verranno abilitate automaticamente se i relativi file header vengono trovati in /usr/include. (Vedi script in ./src/osflags)
Esegui make per compilare i binari del server e del client. Esegui make install per copiare i binari e il manpage nella directory di destinazione. Esegui make test per compilare ed eseguire i test unitari. (Richiede la libreria check)
Provatelo nella vostra LAN! Seguite questi semplici passi:
./iodined -f 10.0.0.1 test.com.
Se usi già la rete 10.0.0.0, usa un'altra rete interna come 172.16.0.0../iodine -f -r 192.168.0.1 test.com.
Sostituisci 192.168.0.1 con l'indirizzo IP del tuo server.10.0.0.2 e il server ha 10.0.0.1.Per usarlo realmente attraverso un nameserver che inoltra, vedi sotto.
Nota: il server e il client devono parlare esattamente lo stesso protocollo. Nella maggior parte dei casi, questo significa eseguire la stessa versione di iodine. Purtroppo, implementare la compatibilità di protocollo all'indietro e in avanti di solito non è fattibile.
Per usare questo tunnel, devi avere il controllo di un dominio reale (come mydomain.com) e un server con un indirizzo IP pubblico su cui eseguire iodined. Se questo server esegue già un programma DNS, cambia la sua porta di ascolto e poi usa l'opzione -b di iodined per permettere a iodined di inoltrare le richieste DNS. (Nota che questa procedura non è consigliata in ambienti di produzione, perché l'inoltro DNS di iodined non è completamente trasparente, ad esempio i trasferimenti di zona non funzioneranno.) In alternativa, puoi inoltrare il sottodominio dal tuo server DNS a iodined, che deve quindi essere eseguito su una porta diversa (-p).
Quindi, delega un sottodominio (ad esempio, t1.mydomain.com) al server iodined. Se usi BIND per il tuo dominio, aggiungi due righe come queste al file di zona:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
La riga NS è tutto ciò che serve per instradare le query per il sottodominio t1 al server t1ns. Usiamo un nome breve per il sottodominio, per lasciare quanto più spazio possibile al traffico dati. Alla fine della riga NS c'è il nome del tuo server iodined. Può essere qualsiasi nome, che punta ovunque, ma in questo caso è facilmente mantenuto nello stesso file di zona. Deve essere un nome (non un indirizzo IP), e quel nome stesso deve avere un record A (non un CNAME).
Se il tuo server iodined ha un IP dinamico, usa un provider DNS dinamico. Punta semplicemente la riga NS ad esso e ometti la riga A:
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
Quindi ricarica o riavvia il tuo programma nameserver. Ora tutte le query DNS per i domini che terminano con t1.mydomain.com verranno inviate al tuo server iodined.
Infine, avvia iodined sul tuo server. Il primo argomento è l'indirizzo IP all'interno del tunnel, che può appartenere a qualsiasi intervallo che non usi ancora (per esempio 192.168.99.1), e il secondo argomento è il dominio assegnato (in questo caso t1.mydomain.com). Usare l'opzione -f mantiene iodined in esecuzione in primo piano, il che aiuta durante i test. iodined aprirà un'interfaccia virtuale ("dispositivo tun") e inizierà anche ad ascoltare le query DNS sulla porta UDP 53. Inserisci una password sulla riga di comando (-P pass) o dopo l'avvio del server. Ora tutto è pronto per il client.
Se c'è la possibilità che tu debba usare un tunnel iodine da ambienti imprevisti, avvia iodined con l'opzione -c. Linea di comando risultante in questa situazione di esempio:
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com
Tutta la configurazione è pronta, basta avviare iodine. Accetta uno o due argomenti: il primo è il server DNS relaying locale (opzionale) e il secondo è il dominio che hai usato (t1.mydomain.com). Se non specifichi il primo argomento, verrà consultata l'impostazione DNS corrente del sistema.
Se le query DNS sono consentite verso qualsiasi computer, puoi dare direttamente l'indirizzo del server iodined come primo argomento (nell'esempio: t1ns.mydomain.com o 10.15.213.99). In quel caso, può anche accadere che qualsiasi traffico sia consentito verso la porta DNS (53 UDP) di qualsiasi computer. Iodine lo rileverà e passerà al tunneling UDP grezzo se possibile. Per forzare il tunneling DNS in ogni caso, usa l'opzione -r (particolarmente utile quando si fanno test nella propria rete).
L'interfaccia del tunnel del client avrà un IP vicino a quello del server (in questo caso 192.168.99.2 o .3, ecc.) e un MTU adatto. Inserisci la stessa password del server, come opzione della riga di comando o dopo l'avvio del client. Usare l'opzione -f mantiene il client iodine in esecuzione in primo piano.
Linea di comando risultante in questa situazione di esempio: aggiungere -r forza il tunneling DNS anche se il tunneling UDP grezzo sarebbe possibile:
./iodine -f -P secretpassword t1.mydomain.com
Da entrambi i lati, ora dovresti essere in grado di fare ping all'indirizzo IP all'altra estremità del tunnel. In questo caso, ping 192.168.99.1 dal client iodine e 192.168.99.2 dal server iodine.
I dati all'interno del tunnel sono solo IPv4.
Il server ascolta sia IPv4 che IPv6 per le richieste in ingresso per impostazione predefinita. Usa le opzioni -4 o -6 per ascoltare solo su un protocollo. La modalità raw verrà tentata sullo stesso protocollo usato per il login.
Il client può usare nameserver IPv4 o IPv6 per connettersi a iodined. I nameserver relay tradurranno automaticamente tra i protocolli se necessario. Usa le opzioni -4 o -6 per forzare il client a usare una versione IP specifica per le sue query DNS.
Se il tuo server è in ascolto su IPv6 ed è raggiungibile, aggiungi un record AAAA per esso alla tua configurazione DNS. Estendendo l'esempio precedente si otterrebbe questo:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
t1ns IN AAAA 2001:db8::1001:99
È possibile instradare tutto il traffico attraverso il tunnel DNS. Per farlo, aggiungi prima una route dell'host verso il nameserver usato da iodine sull'interfaccia cablata/wireless con il gateway predefinito come gateway. Quindi sostituisci il gateway predefinito con l'indirizzo IP del server iodined all'interno del tunnel DNS e configura il server per fare NAT.
Tuttavia, nota che il traffico dati in tunnel non è affatto cifrato e può essere letto e modificato da terze parti con relativa facilità. Per la massima sicurezza, esegui una VPN attraverso il tunnel DNS (= doppio tunneling) oppure usa l'accesso tramite secure shell (SSH), possibilmente con port forwarding. Quest'ultimo può essere usato anche per la navigazione web, se esegui un proxy web (ad esempio Privoxy) sul tuo server.
Il server iodined risponde alle richieste NS inviate per i sottodomini del dominio del tunnel. Se il tuo sottodominio iodined è t1.mydomain.com, invia una richiesta NS per foo123.t1.mydomain.com per verificare se la delega funziona. dig è un buon strumento per questo:
% dig -t NS foo123.t1.mydomain.com
ns.io.citronna.de.
Inoltre, il server iodined risponderà alle richieste che iniziano con 'z' per qualsiasi tipo di richiesta supportato, ad esempio:
dig -t TXT z456.t1.mydomain.com
dig -t SRV z456.t1.mydomain.com
dig -t CNAME z456.t1.mydomain.com
In tutti questi casi, la risposta dovrebbe apparire come testo confuso/illeggibile.
Su Mac OS X 10.6 e successivi, iodine supporta i dispositivi utun nativi integrati nel sistema operativo: usa -d utunX.
La dimensione dei frammenti delle risposte DNS viene normalmente rilevata automaticamente per ottenere la massima larghezza di banda. Per forzare un valore specifico (e accelerare le cose), usa l'opzione -m.
I nomi host DNS vengono normalmente usati fino alla loro lunghezza massima, 255 caratteri. Sono stati trovati alcuni relay DNS che rispondono alle query a lunghezza piena in modo piuttosto inaffidabile, dando risultati molto variabili (e per lo più pessimi) del rilevamento automatico della dimensione dei frammenti a tentativi ripetuti. In questi casi, usa l'opzione -M per ridurre la lunghezza del nome host DNS, ad esempio a 200 caratteri, rendendo questi relay DNS molto più stabili. Questo è utile anche su alcuni relay DNS "de-ottimizzanti" che riempiono la risposta con due copie complete della query, lasciando pochissimo spazio per i dati in downstream (e inoltre non supportano EDNS0). L'opzione -M può scambiare un po' di larghezza di banda in upstream per larghezza di banda in downstream. Nota che il valore minimo di -M è circa 100, poiché il protocollo può dividere i pacchetti (massimo 1200 byte) in soli 16 frammenti, richiedendo almeno 75 byte di dati reali per frammento.
I dati in upstream vengono inviati compressi con gzip e codificati con Base32; oppure Base64 se il server relay supporta maiuscole/minuscole e + nei nomi di dominio; oppure Base64u se invece è supportato _; oppure Base128 se sono supportati caratteri con valore alto. Questa codifica upstream viene rilevata automaticamente. Il protocollo DNS consente una query per pacchetto e una query può essere lunga al massimo 256 caratteri. Ogni parte del nome di dominio può essere lunga al massimo 63 caratteri. Quindi il tuo nome di dominio e sottodominio dovrebbero essere il più corti possibile per consentire il massimo throughput in upstream.
Sono supportati diversi tipi di richiesta DNS; ci si aspetta che i tipi NULL e PRIVATE forniscano la maggiore larghezza di banda in downstream. Il tipo PRIVATE usa il valore 65399 nell'intervallo di uso privato. Gli altri tipi disponibili sono TXT, SRV, MX, CNAME e A (che restituisce CNAME), in ordine decrescente di larghezza di banda. Normalmente il tipo di richiesta "migliore" viene rilevato e usato automaticamente. Tuttavia, i relay DNS possono imporre limiti, ad esempio su NULL e TXT, rendendo SRV o MX effettivamente la scelta migliore. Questo non viene rilevato automaticamente, ma può essere forzato con l'opzione -T. È consigliabile provare varie alternative, specialmente quando il tipo di richiesta rilevato automaticamente fornisce una dimensione dei frammenti in downstream inferiore a 200 byte.
Nota che le query SRV, MX e A (che restituiscono CNAME) possono/causeranno lookup aggiuntivi da parte di nameserver con cache "intelligenti" per ottenere un indirizzo IP reale, il che può rallentare o fallire del tutto.
Le risposte DNS per query non-NULL/PRIVATE possono essere codificate con lo stesso insieme di codec dei dati upstream. Anche questo viene normalmente rilevato automaticamente, ma non vengono effettuati test completamente esaustivi, quindi alcuni problemi potrebbero non essere notati quando si selezionano codec più avanzati. In tal caso, vedrai errori/corruzione nel rilevamento automatico della dimensione dei frammenti. In particolare, sono stati trovati diversi relay DNS che convertono le risposte contenenti hostname (SRV, MX, CNAME, A) in minuscolo solo quando quell'hostname supera circa 180 caratteri. In questi e simili casi, usa l'opzione -O per provare altri codec downstream; Base32 dovrebbe funzionare sempre.
Il funzionamento normale ora prevede che il server non risponda a una richiesta DNS finché non è arrivata la richiesta DNS successiva, cioè che sia "pigro" (lazy). In questo modo, il server avrà sempre una richiesta DNS a disposizione quando devono essere inviati nuovi dati in downstream. Ciò migliora notevolmente le prestazioni (interattive) e la latenza e consente di rallentare le richieste ping di quiete a intervalli di 4 secondi per impostazione predefinita, e possibilmente molto più lenti. In effetti, lo scopo principale dei ping ora è forzare una risposta al ping precedente e prevenire i timeout del server DNS (di solito almeno 5-10 secondi secondo RFC1035). Alcuni server DNS sono più impazienti e restituiranno errori SERVFAIL (timeout) nei periodi senza traffico dati in tunnel. In questi casi, tutti i dati dovrebbero comunque passare, ma iodine ridurrà comunque l'intervallo di ping a 1 secondo (-I1) per ridurre il numero di messaggi di errore. Questo potrebbe non aiutare per relay DNS molto impazienti come dnsadvantage.com (ultradns), che vanno in timeout in 1 secondo o anche meno. Tuttavia, i dati passeranno comunque e puoi ignorare gli errori SERVFAIL.
Se stai eseguendo su una rete locale senza alcun server DNS intermedio, prova -I 50 (iodine e iodined chiudono la connessione dopo 60 secondi di silenzio). L'unico momento in cui noterai un rallentamento è quando i pacchetti di risposta DNS si perdono; il server iodined deve quindi attendere un nuovo ping per rinviare i dati. Puoi accelerare generando un po' di traffico in upstream (tasti premuti, ping). Se questo accade spesso, controlla la rete per colli di bottiglia e/o esegui con -I1.
La risposta ritardata in modalità lazy causerà ad alcuni relay DNS commerciali "carrier grade" di rinviare ripetutamente la stessa query DNS al server iodined. Se il relay DNS è effettivamente implementato come un pool di server paralleli, le richieste duplicate possono persino arrivare da più fonti. Questo effetto sarà visibile solo nel traffico di rete sul server iodined e non influirà sulla connessione del client. Iodined noterà questi duplicati e invierà la stessa risposta (quando sarà il momento) sia alla query originale che all'ultimo duplicato. Dopodiché, la risposta completa viene memorizzata nella cache per un breve periodo. I duplicati ritardati che arrivano al server ancora più tardi ricevono una risposta che il client iodine ignorerà (se mai arriverà).
Se hai problemi, prova a ispezionare il traffico con strumenti di monitoraggio di rete come tcpdump o ethereal/wireshark e assicurati che il server DNS relaying non abbia memorizzato nella cache la risposta. Un messaggio di errore in cache potrebbe significare che hai avviato il client prima del server. L'opzione -D (e -DD) sul server può anche mostrare le query ricevute e inviate.
Se la tua porta 53 è occupata su un'interfaccia specifica da un'applicazione che non la usa, usa -p su iodined per specificare una porta alternativa (come -p 5353) e usa ad esempio iptables (su Linux) per inoltrare il traffico:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
(Inviato da Tom Schouten)
Iodined rifiuterà i dati provenienti da client che non sono stati attivi (dati/ping) per più di 60 secondi. Allo stesso modo, iodine terminerà quando non vengono ricevuti dati downstream per 60 secondi. In caso di un'interruzione di rete prolungata o simile, basta riavviare iodine (ri-login), possibilmente più volte finché non recuperi il tuo vecchio indirizzo IP. Una volta fatto, attendi un po' e alla fine vedrai il traffico TCP in tunnel continuare a fluire da dove era rimasto prima dell'interruzione.
Con l'introduzione della coda dei pacchetti downstream nel server, il suo utilizzo di memoria è aumentato di diversi megabyte nella configurazione predefinita. Per l'uso in ambienti con poca memoria (ad es. in esecuzione sul tuo router DSL), puoi ridurre USERS e non definire OUTPACKETQ_LEN in user.h senza conseguenze negative, supponendo che al massimo un client sia connesso alla volta. È comunque consigliato un DNSCACHE_LEN piccolo, preferibilmente 2 o superiore; puoi comunque anche non definirlo per risparmiare qualche kilobyte in più.
Un singolo server iodine può gestire più domini. Configura diversi record NS sullo stesso dominio che puntano tutti allo stesso host e usa un wildcard all'inizio dell'argomento topdomain (esempio *.mydomain.com). iodine accetterà traffico tunnel per tutti i domini che corrispondono a quel modello. Il wildcard deve essere all'inizio dell'argomento topdomain ed essere seguito da un punto.
Questa sezione riporta alcune misurazioni delle prestazioni. Per visualizzarle correttamente, usa un carattere a larghezza fissa come Courier.
Le misurazioni sono state effettuate con il protocollo 00000502 in modalità lazy; codifica upstream sempre Base128; iodine -M255; iodined -m1130. Le condizioni di rete non erano estremamente favorevoli; i risultati non sono benchmark ma un'indicazione realistica delle prestazioni reali che ci si può aspettare in situazioni simili.
Il throughput upstream/downstream è stato misurato copiando con scp un file precedentemente letto da /dev/urandom (cioè non comprimibile) e misurando la dimensione con ls -l ; sleep 30 ; ls -l su una connessione separata non tunnelizzata. Data la grande dimensione del blocco scp di 16 kB, ciò offre una risoluzione di 4,3 kbit/s, il che spiega perché alcuni valori sono esattamente uguali. I tempi di round-trip del ping sono stati misurati con ping -c100; presentati sono rtt medio e deviazione media (che indica la dispersione attorno alla media), in millisecondi.
Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter iodine DNS "relay" bind9 DNS cache iodined
downstr. upstream downstr. ping-up ping-down
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
-----------------------------------------------------------------------------
iodine -> Wifi AP :53
-Tnull (= -Oraw) 982 43.6 131.0 28.0 4.6 26.8 3.4
iodine -> Home server :53
-Tnull (= -Oraw) 1174 48.0 305.8 26.6 5.0 26.9 8.4
iodine -> DSL provider :53
-Tnull (= -Oraw) 1174 56.7 367.0 20.6 3.1 21.2 4.4
-Ttxt -Obase32 730 56.7 174.7*
-Ttxt -Obase64 874 56.7 174.7
-Ttxt -Obase128 1018 56.7 174.7
-Ttxt -Oraw 1162 56.7 358.2
-Tsrv -Obase128 910 56.7 174.7
-Tcname -Obase32 151 56.7 43.6
-Tcname -Obase128 212 56.7 52.4
iodine -> DSL provider :53
wired (no Wifi) -Tnull 1174 74.2 585.4 20.2 5.6 19.6 3.4
[174.7* : these all have 2frag/packet]
Laptop -> Wifi+vpn / wired -> Home server iodine iodined
downstr. upstream downstr. ping-up ping-down
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
-----------------------------------------------------------------------------
wifi + openvpn -Tnull 1186 166.0 1022.3 6.3 1.3 6.6 1.6
wired -Tnull 1186 677.2 2464.1 1.3 0.2 1.3 0.1
Le prestazioni sono fortemente legate a tempi di ping bassi, poiché iodine richiede una conferma per ogni frammento di dati prima di passare al successivo. Consentire più frammenti in volo come TCP potrebbe aumentare le prestazioni, ma probabilmente causerebbe un serio sovraccarico per i server DNS intermedi. Il protocollo attuale adatta le prestazioni alla reattività del DNS, poiché i server DNS gestiscono in media al massimo una richiesta DNS per client.
iodine è stato testato su Linux (arm, ia64, x86, AMD64 e SPARC64), FreeBSD (ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc e x86, con http://tuntaposx.sourceforge.net/) e Windows (con driver OpenVPN TAP32, vedi file readme win32). Dovrebbe essere facile portarlo su altri sistemi simili a Unix che hanno supporto per il tunneling TUN/TAP. Facci sapere se riesci a farlo funzionare su altre piattaforme.
Il nome iodine è stato scelto perché inizia con IOD (IP Over DNS) e perché lo iodio ha numero atomico 53, che è anche il numero della porta DNS.
Copyright (c) 2006-2014 Erik Ekman [email protected], 2006-2009 Bjorn Andersson [email protected]. Anche contributi importanti di Anne Bezemer.
Con la presente è concessa l'autorizzazione a usare, copiare, modificare e/o distribuire questo software per qualsiasi scopo, con o senza compenso, a condizione che l'avviso di copyright sopra riportato e questo avviso di autorizzazione compaiano in tutte le copie.
IL SOFTWARE È FORNITO "COSÌ COM'È" E L'AUTORE DECLINA OGNI GARANZIA RIGUARDO A QUESTO SOFTWARE, INCLUSE TUTTE LE GARANZIE IMPLICITE DI COMMERCIABILITÀ E IDONEITÀ. IN NESSUN CASO L'AUTORE SARÀ RESPONSABILE PER DANNI SPECIALI, DIRETTI, INDIRETTI O CONSEQUENZIALI, O PER QUALSIASI DANNO DERIVANTE DA PERDITA DI USO, DATI O PROFITTI, SIA IN UN'AZIONE CONTRATTUALE, PER NEGLIGENZA O ALTRO ATTO ILLECITO, DERIVANTE DA O IN RELAZIONE ALL'USO O ALLE PRESTAZIONI DI QUESTO SOFTWARE.
Implementazione MD5 di L. Peter Deutsch (licenza e sorgente in src/md5.[ch])
Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. Tutti i diritti riservati.