Proxychains : le retour

Table des matières

Dans un de mes billets sur proxychains, j'indiquais n'avoir jamais eu de soucis avec ce logiciel. Il a fallu que j'écrive ça pour en avoir. Je vais apporter une solution aux deux problèmes que j'ai rencontré. Je vous conseille de lire le billet précédent afin de comprendre ce dont je parle ici.

ERROR: ld.so: object 'libproxychains.so.3' from LD_PRELOAD cannot be preloaded: ignored.

Voici à quelle erreur je suis maintenant confronté. La solution exposée sur nombre de forums, a savoir créer un lien symbolique ne fonctionne pas chez moi.

En observant un peu, en lançant un programme proxychainé depuis un shell par exemple, on remarque que cette erreur apparaît lors de la résolution des noms de domaine. On se demande alors si l'erreur ne viendrait pas du script chargé de la résolution des noms de domaine, /usr/lib/proxychains3/proxyresolv. On l'ouvre et on remarque cette ligne :

export LD_PRELOAD=libproxychains.so.3

Si on en croit les forums qui conseillent de créer un lien symbolique, il faut créer le-dit lien car le chemin vers la libproxychains.so.3 serait codé en dur dans le code de proxychains et dans proxyresolv. C'est le déclic : et si nous mettons le chemin absolu vers la libproxychains.so.3 dans le script proxyresolv, cela corrige-t-il le problème ?

On cherche l'emplacement de la libproxychains.so.3 :

sudo find / -name "libproxychains.so.3"

On la trouve dans le répertoire /usr/lib, quelle surprise.

On modifie donc proxyresolv en remplaçant :

export LD_PRELOAD=libproxychains.so.3

par

export LD_PRELOAD=/usr/lib/libproxychains.so.3

Nous venons de résoudre le premier problème. Je ne sais pas expliquer pourquoi cela ne fonctionne plus subitement du jour au lendemain.

Les requêtes DNS ne sont plus proxychainées

En effet, je me suis aperçu que proxyresolv s'adresse bien au serveur définit dans sa variable "DNS_SERVER" mais sans passer par le tunnel SSH. Merci à mon netfilter bien configuré qui a évité les fuites vers le réseau local.

J'ai donc pensé à faire une redirection du port local tcp/53 vers le port tcp/53 de mon résolveur DNS. Cette redirection s'ajoute à ma redirection dynamique. Concrètement cela donne :

sudo ssh -ND6666 -L53:resolveurDNSDNS:53 login@server

Ensuite, il suffit de définir 127.0.0.1 comme "DNS_SERVER" dans le script proxyresolv et le problème sera résolu.

Pour ceux qui ne veulent pas lancer ssh avec les droits root, il y a un moyen de déporter les droits root sur un autre programme :

sudo apt-get install socat
ssh -ND6666 -L5300:resolveurDNS:53 login@server
sudo socat TCP4-LISTEN:53,reuseaddr,fork TCP4:127.0.0.1:5300

Explication : proxyresolv va envoyer sa requête sur le port tcp/53. socat va la relayer sur le port 5300. SSH va récupérer la requête, la faire transiter dans le tunnel et l'envoyer sur le port tcp/53 de la machine resolveurDNS.

Au lieu d'utiliser socat, on peut se la jouer netfilter ce qui évite de devoir créer des scripts pour lancer socat automatiquement et de donner des droits inutiles a ssh/socat :

ssh -ND6666 -L5300:serveurDNS:53 login@server
sudo iptables -t nat -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -p tcp --dport 53 -j REDIRECT --to-port 5300

Pour ceux qui se demande pourquoi définir 127.0.0.1 comme résolveur DNS dans proxyresolv et non pas dans /etc/resolv.conf : d'une part car cela empêcherait ssh de résoudre le nom de la machine avec laquelle il doit communiquer, dans le cas où votre serveur ssh a une ip dynamique. D'autre part, les autres applications fonctionnent très bien donc pourquoi les sanctionner ?

Pour ceux qui s'étonne de voir le protocole DNS agir sur le protocole TCP, sachez que cela avait été prévu par les RFC. Les administrateurs de réseaux qui bloquent le port tcp/53 ne sont donc pas consciencieux/informés. Néanmoins, une requête de résolution doit être effectuée sur TCP uniquement dans le cas où la réponse excède 512 octets (mais la taille autorisé via UDP a été augmentée dans le RFC 2671 afin de prendre en charge DNSSEC).

Nous faisons donc une entorse aux règles en faisant passer toutes nos requêtes, même celles qui n'excèdent pas la taille maximale, par le port tcp/53. Relativisons en disant que d'une part, comme SSH permet le port forwarding uniquement sur le protocole TCP, nous sommes obligé de passer via TCP à un moment donné. D'autre part, dés que l'on tente de masquer son trafic et/ou de contourner un firewall, on transgresse forcement les standards (on se souviens du TCP over TCP du billet précédent).

Pour ceux qui veulent étudier une solution alternative : Tunnelling UDP packets through SSH. Vous constaterez que cette méthode impose aussi un passage via TCP et qu'elle est plus complexe à mettre en place et à automatiser.

Aucun commentaire.

Ajoutez votre commentaire