Tunnélisez des données IPv4 à travers des serveurs DNS pour contourner les restrictions de pare-feu et fournir un accès réseau furtif pour les tests d'intrusion.
Ce logiciel permet de tunneliser des données IPv4 à travers un serveur DNS. Il peut être utile dans différentes situations où l'accès à Internet est filtré par un pare-feu, mais où les requêtes DNS sont autorisées.
Pour compiler iodine, vous avez besoin de meson.
Exécutez les commandes suivantes pour compiler dans le répertoire build :
meson setup build
cd build
ninja
Pour compiler et exécuter les tests, vous avez besoin de la bibliothèque check. Lancez-les en
exécutant ninja test dans le répertoire de build.
Essayez-le sur votre propre LAN ! Suivez ces étapes simples :
./iodined -f 10.0.0.1 test.com.
Si vous utilisez déjà le réseau 10.0.0.0, utilisez un autre réseau interne comme
172.16.0.0../iodine -f -r 192.168.0.1 test.com.
Remplacez 192.168.0.1 par l'adresse IP de votre serveur.10.0.0.2 et le serveur de 10.0.0.1.Pour l'utiliser réellement à travers un serveur de noms relais, voir ci-dessous.
Remarque : le serveur et le client doivent parler exactement le même protocole. Dans la plupart des cas, cela signifie exécuter la même version d'iodine. Malheureusement, implémenter une compatibilité de protocole ascendante et descendante n'est généralement pas faisable.
Pour utiliser ce tunnel, vous devez contrôler un vrai domaine (comme mydomain.com),
et disposer d'un serveur avec une adresse IP publique pour exécuter iodined. Si ce serveur
exécute déjà un programme DNS, changez son port d'écoute puis utilisez l'option
-b d'iodined pour laisser iodined transmettre les requêtes DNS. (Notez que cette procédure
n'est pas conseillée en environnement de production, car la transmission DNS d'iodined
n'est pas complètement transparente, par exemple les transferts de zone ne fonctionneront pas.)
Alternativement, vous pouvez transmettre le sous-domaine depuis votre serveur DNS vers iodined
qui doit alors s'exécuter sur un port différent (-p).
Ensuite, déléguez un sous-domaine (par exemple, t1.mydomain.com) au serveur iodined.
Si vous utilisez BIND pour votre domaine, ajoutez deux lignes comme celles-ci au fichier de zone :
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
La ligne NS est tout ce qui est nécessaire pour router les requêtes du sous-domaine t1
vers le serveur t1ns. Nous utilisons un nom court pour le sous-domaine, afin de conserver autant
d'espace que possible pour le trafic de données. À la fin de la ligne NS
se trouve le nom de votre serveur iodined. Cela peut être n'importe quel nom, pointant n'importe où,
mais dans ce cas il est facilement conservé dans le même fichier de zone. Il doit s'agir d'un nom
(pas d'une adresse IP), et ce nom lui-même doit avoir un enregistrement A
(pas un CNAME).
Si votre serveur iodined a une IP dynamique, utilisez un fournisseur de DNS dynamique. Pointez simplement
la ligne NS vers celui-ci, et omettez la ligne A :
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
Rechargez ou redémarrez ensuite votre programme de serveur de noms. Maintenant, toutes les requêtes DNS pour
les domaines se terminant par t1.mydomain.com seront envoyées à votre serveur iodined.
Enfin, démarrez iodined sur votre serveur. Le premier argument est l'adresse IP
à l'intérieur du tunnel, qui peut provenir de n'importe quelle plage que vous n'utilisez pas encore (par
exemple 192.168.99.1), et le second argument est le domaine assigné (dans ce
cas t1.mydomain.com). L'utilisation de l'option -f maintiendra iodined en
avant-plan, ce qui aide lors des tests. iodined ouvrira une interface virtuelle
(« tun device »), et commencera également à écouter les requêtes DNS sur le port UDP 53.
Saisissez soit un mot de passe en ligne de commande (-P pass) soit après que le serveur a
démarré. Maintenant tout est prêt pour le client.
S'il y a une chance que vous utilisiez un tunnel iodine depuis des environnements inattendus,
démarrez iodined avec une option -c.
Ligne de commande résultante dans cette situation d'exemple :
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com
Toute la configuration est faite, démarrez simplement iodine. Il prend un ou deux arguments, le
premier est le serveur DNS relais local (optionnel) et le second est le domaine
que vous avez utilisé (t1.mydomain.com). Si vous ne spécifiez pas le premier argument, la
configuration DNS actuelle du système sera consultée.
Si les requêtes DNS sont autorisées vers n'importe quel ordinateur, vous pouvez directement donner l'adresse du serveur
iodined comme premier argument (dans l'exemple : t1ns.mydomain.com ou
10.15.213.99). Dans ce cas, il peut aussi arriver que tout trafic soit autorisé
vers le port DNS (53 UDP) de n'importe quel ordinateur. Iodine détectera cela, et basculera
vers le tunnel UDP brut si possible. Pour forcer le tunnel DNS dans tous les cas, utilisez l'option
-r (particulièrement utile lors de tests sur votre propre réseau).
L'interface tunnel du client obtiendra une IP proche de celle du serveur (dans ce
cas 192.168.99.2 ou .3 etc.) et une MTU appropriée. Saisissez le même mot de passe que
sur le serveur, soit comme option en ligne de commande soit après que le client a démarré.
L'utilisation de l'option -f maintiendra le client iodine en avant-plan.
Ligne de commande résultante dans cette situation d'exemple, l'ajout de -r force le tunnel DNS même si le tunnel UDP brut serait possible :
./iodine -f -P secretpassword t1.mydomain.com
Des deux côtés, vous devriez maintenant pouvoir pinguer l'adresse IP de l'autre
extrémité du tunnel. Dans ce cas, ping 192.168.99.1 depuis le client iodine, et
192.168.99.2 depuis le serveur iodine.
Les données à l'intérieur du tunnel sont uniquement IPv4.
Le serveur écoute à la fois IPv4 et IPv6 pour les requêtes entrantes par défaut.
Utilisez les options -4 ou -6 pour n'écouter que sur un seul protocole. Le mode brut sera
tenté sur le même protocole que celui utilisé pour la connexion.
Le client peut utiliser des serveurs de noms IPv4 ou IPv6 pour se connecter à iodined. Les serveurs de noms
relais traduiront automatiquement entre les protocoles si nécessaire. Utilisez
les options -4 ou -6 pour forcer le client à utiliser une version IP spécifique pour ses requêtes
DNS.
Si votre serveur écoute en IPv6 et est joignable, ajoutez un enregistrement AAAA pour lui dans votre configuration DNS. En étendant l'exemple ci-dessus, cela ressemblerait à ceci :
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
t1ns IN AAAA 2001:db8::1001:99
Il est possible de router tout le trafic à travers le tunnel DNS. Pour ce faire, ajoutez d'abord une route d'hôte vers le serveur de noms utilisé par iodine via l'interface filaire/sans fil avec la passerelle par défaut comme passerelle. Remplacez ensuite la passerelle par défaut par l'adresse IP du serveur iodined à l'intérieur du tunnel DNS, et configurez le serveur pour faire du NAT.
Cependant, notez que le trafic de données tunnelisé n'est pas du tout chiffré, et peut être lu et modifié par des tiers relativement facilement. Pour une sécurité maximale, exécutez un VPN à travers le tunnel DNS (=double tunnelisation), ou utilisez un accès secure shell (SSH), éventuellement avec redirection de port. Ce dernier peut également être utilisé pour la navigation web, lorsque vous exécutez un proxy web (par exemple Privoxy) sur votre serveur.