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.
Il s'agit d'un logiciel qui vous permet de tunneler des données IPv4 à travers un serveur DNS. Cela 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 compilation.
Essayez-le au sein de 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 rétroactive et prospective 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 y 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 disponible 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. Désormais, 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 cours d'exécution au
premier 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 un mot de passe en ligne de commande (-P pass) ou après le démarrage du serveur.
Tout est maintenant 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 terminée, il suffit de démarrer iodine. Il prend un ou deux arguments, le
premier est le serveur DNS relais local (facultatif) et le second est le domaine
que vous avez utilisé (t1.mydomain.com). Si vous ne spécifiez pas le premier argument, le
paramètre DNS actuel du système sera consulté.
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 le trafic soit autorisé vers le port DNS (53 UDP) de n'importe quel ordinateur. Iodine le détectera et basculera vers un tunneling UDP brut si possible. Pour forcer le tunneling DNS dans tous les cas, utilisez l'option -r (particulièrement utile lors de tests au sein de 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 un MTU approprié. Saisissez le même mot de passe que sur le serveur, soit comme option en ligne de commande, soit après le démarrage du client. L'utilisation de l'option -f maintiendra le client iodine au premier plan.
Ligne de commande résultante dans cette situation d'exemple, l'ajout de -r force le tunneling DNS même si le tunneling UDP brut serait possible :
./iodine -f -P secretpassword t1.mydomain.com
Des deux côtés, vous devriez maintenant pouvoir pinguer l'adresse IP à 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 par défaut à la fois en IPv4 et en IPv6 pour les requêtes entrantes. 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 celui-ci 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 chiffré du tout, et peut être lu et modifié par des tiers relativement facilement. Pour une sécurité maximale, faites passer un VPN à travers le tunnel DNS (=double tunneling), ou utilisez un accès secure shell (SSH), éventuellement avec redirection de ports. Ce dernier peut aussi être utilisé pour la navigation web, lorsque vous exécutez un proxy web (par exemple Privoxy) sur votre serveur.