proxychains ng (nouvelle génération) — un préchargeur qui intercepte les appels aux sockets dans les programmes liés dynamiquement et les redirige à travers un ou plusieurs proxys socks/http. continuation du projet proxychains non maintenu. la page sf.net n'est actuellement pas mise à jour, utilisez les versions de la page de publication github à la place.
ProxyChains est un programme UNIX qui intercepte les fonctions libc liées au réseau dans les programmes LIÉS DYNAMIQUEMENT via une DLL préchargée (dlsym(), LD_PRELOAD) et redirige les connexions via des proxys SOCKS4a/5 ou HTTP. Il ne prend en charge que TCP (pas UDP/ICMP, etc.).
La façon dont cela fonctionne est fondamentalement un HACK ; il est donc possible que cela ne fonctionne pas avec votre programme, en particulier s'il s'agit d'un script, ou s'il démarre de nombreux processus comme des daemons en arrière-plan, ou s'il utilise dlopen() pour charger des « modules » (bug dans le dynlinker de glibc). Cela devrait toutefois fonctionner avec des programmes compilés simples (C/C++) liés dynamiquement.
Si votre programme ne fonctionne pas avec proxychains, envisagez plutôt d'utiliser une solution basée sur iptables ; c'est beaucoup plus robuste.
Plateformes prises en charge : Linux, BSD, Mac, Haiku.
*********** ATTENTION ***********
ce programme peut être utilisé pour contourner la censure. le faire peut être TRÈS DANGEREUX dans certains pays.
ASSUREZ-VOUS TOUJOURS QUE PROXYCHAINS FONCTIONNE COMME PRÉVU AVANT DE L'UTILISER POUR QUOI QUE CE SOIT D'IMPORTANT.
cela concerne à la fois le programme et le proxy que vous allez utiliser.
par exemple, vous pouvez vous connecter à un service « what is my ip » comme ifconfig.me pour vous assurer que votre vraie ip n'est pas utilisée.
UTILISEZ PROXYCHAINS UNIQUEMENT SI VOUS SAVEZ CE QUE VOUS FAITES.
LES AUTEURS ET MAINTENEURS DE PROXYCHAINS N'ASSUMENT AUCUNE RESPONSABILITÉ EN CAS D'ABUS OU DE MAUVAISE UTILISATION DE CE LOGICIEL ET DES CONSÉQUENCES QUI EN RÉSULTENT.
*** Installation ***
./configure --prefix=/usr --sysconfdir=/etc make [optional] sudo make install [optional] sudo make install-config (installs proxychains.conf)
si vous n'installez pas, vous pouvez utiliser proxychains depuis le répertoire de compilation comme ceci : ./proxychains4 -f src/proxychains.conf telnet google.com 80
Version 4.17
Version 4.16
Version 4.15
Version 4.14
Version 4.13
Version 4.12
Version 4.11
Version 4.10
Version 4.9
Version 4.8.1:
Version 4.8:
Version 4.7:
Version 4.6:
Version 4.5:
Version 4.4:
Version 4.3:
Version 4.2:
Version 4.1
Version 4.0
Version 3.0
Quand l'utiliser ?
Quelques fonctionnalités sympas :
proxychains recherche le fichier de configuration dans l'ordre suivant :
** généralement /etc/proxychains.conf
Exemple d'utilisation :
$ proxychains telnet targethost.com
dans cet exemple, telnet sera exécuté via le proxy (ou les proxys chaînés) spécifié(s) par proxychains.conf
Exemple d'utilisation :
$ proxychains -f /etc/proxychains-other.conf telnet targethost2.com
dans cet exemple, un fichier de configuration différent de proxychains.conf sera utilisé pour se connecter à l'hôte targethost2.com.
Exemple d'utilisation :
$ proxyresolv targethost.com
dans cet exemple, targethost.com sera résolu via le proxy (ou les proxys chaînés) spécifié(s) par proxychains.conf
les versions récentes de nmap essaient de déterminer l'interface réseau à utiliser même si ce n'est pas nécessaire (comme lors de simples syn scans qui utilisent l' API socket POSIX standard. cela provoque des erreurs lorsque proxychains attribue une adresse ip d'un espace d'adressage réservé. solutions possibles : désactiver proxy_dns, utiliser une ip numérique, ou utiliser le support natif de nmap pour les proxys SOCKS.
Mac OS X 10.11 (El Capitan) est livré avec une nouvelle fonctionnalité de sécurité appelée SIP qui empêche le hooking des applications système. les solutions consistent à désactiver partiellement SIP en exécutant csrutil enable --without debug en mode récupération, ou à copier le binaire système dans le répertoire personnel et à l'exécuter depuis là. voir le problème github #78 pour plus de détails.
le dynlinker de glibc a un bug ou une fonctionnalité de sécurité qui empêche les modules chargés via dlopen() d'être soumis aux mêmes hooks dlsym que ceux installés pour le programme principal. cela affecte principalement les langages de script comme perl ou python qui dépendent fortement de dlopen() pour que les modules écrits en C fonctionnent. des rapports non confirmés indiquent toutefois que cela fonctionne en root. musl libc n'est pas affecté par ce bug.
les sites suivants peuvent s'avérer utiles pour vérifier les fuites : https://ipfighter.com/ https://browserleaks.com/webrtc https://dnsleaktest.com http://check.torproject.org - tor specific http://ifconfig.me - can be used via curl http://ifconfig.io/
#proxychains sur irc.libera.chat
les dons en bitcoins sont les bienvenus - veuillez les envoyer à cette adresse : 1C9LBpuy56veBqw5N33sZMoZW8mwCw3tPh