stealth/fraud-bridgeOutil de tunneling ICMP, DNS et NTP pour contourner la censure, avec protection d'intégrité HMAC et clamping MSS pour des sessions web efficaces sur des réseaux restrictifs.
fraud-bridge aide à contourner les environnements de censure restrictifs qui bloquent les connexions TCP ou UDP directes, en mettant en place des tunnels ICMP, NTP ou DNS (sur IPv4 ou IPv6).
Il corrige automatiquement l'option TCP MSS pour obtenir un flux de paquets non fragmenté (appelé MSS-clamping) afin d'améliorer les performances et de permettre l'utilisation de sessions web à travers le pont.
Il utilise MD5 pour protéger l'intégrité (HMAC) du tunnel contre les paquets TCP malveillants injectés. Si vous avez besoin de confidentialité, vous devez utiliser le chiffrement vous-même. Il est supposé que vous utilisez SSH sur le tunnel de toute façon. Soit directement, soit avec l'option proxy SSH si vous avez besoin d'un tunnel HTTP.
Lors du tunneling DNS, fraud-bridge utilise les en-têtes d'extension EDNS0 pour mettre autant d'octets que possible dans la réponse TXT.
fraud-bridge inclut également d'autres techniques pour faire face à certaines limitations de bind, par exemple les quotas/limitations.
Vous pouvez également l'utiliser pour obtenir un support complet de l'itinérance/mobilité pour vos sessions SSH sans aucun patch.
Une fois le tunnel configuré, vous voudrez peut-être lire comment faire fonctionner votre messagerie à travers le tunnel.
Notez également que c->skills fournit toute la chaîne d'équipement anti-censure qui pourrait vous intéresser : crash et psc
Faites simplement make sous Linux.
L'utilisation est la suivante :
fraud-bridge -- https://github.com/stealth/fraud-bridge
Usage: fraud-bridge <-k key> [-R IP] [-L IP] [-pP port] [-iIuUnN] [-s sz]
[-E sz] [-d dev] [-D domain] [-S usec] [-X user] [-r dir] [-t type] [-v]
-k -- HMAC key to protect tunnel packets
-R -- IP or IPv6 addr of (outside) peer when started inside
-L -- local IP addr to bind to if started outside (can be omitted)
-p -- remote port when in DNS/NTP mode (default: 53/123)
-P -- local port when in DNS/NTP mode (outside default: 53/123)
-i -- use ICMP tunnel
-I -- use ICMPv6 tunnel
-u -- use DNS tunnel over IP
-U -- use DNS tunnel over IPv6
-n -- use NTP4 tunnel over IP
-N -- use NTP4 tunnel over IPv6
-E -- set EDNS0 size (default: 1024)
-s -- set MSS size (default: 1024)
-d -- tunnel device to use (default: tun1)
-D -- DNS domain to use when DNS tunneling
-S -- usec slowdown for DNS ping (default: 5000)
-X -- user to run as (default: nobody)
-r -- chroot directory (default: /var/empty)
-t -- override ICMP/ICMP6 type (usually no need to change)
-v -- enable verbose mode
Quelques définitions : inside fait référence à la machine à l'intérieur du réseau censuré, très probablement votre ordinateur portable/PC. outside fait référence à un VPS ou une machine à l'extérieur du réseau censuré, c'est-à-dire ce qu'on appelle « internet libre ».
Après le démarrage, fraud-bridge ouvre un tunnel point-à-point : 1.2.3.4 <-> 1.2.3.5
Ensuite, vous devez lancer inside.sh sur la machine interne et outside.sh sur la machine externe.
Cela ressemble à ceci :
Du côté externe du tunnel (par ex. un serveur sur internet) :
# ./fraud-bridge -u -L 192.168.2.222 -D f.sub.dnstunnel.com -k key
(et lancer outside.sh)
Et du côté interne :
# ./fraud-bridge -u -R 127.0.0.1 -D f.sub.dnstunnel.com -k key
(et lancer inside.sh)
à titre d'exemple pour un tunnel DNS avec un named local tournant sur 127.0.0.1 et
le pair externe étant à 192.168.2.222. Comme dit, la partie externe du
tunnel peut (et doit en fait) être démarrée avant et se contente d'écouter
le pair pour ouvrir le tunnel. Des exemples de fichiers de zone sont inclus si
vous voulez expérimenter avec vos propres configurations bind. Pour les tunnels en situation réelle, ils ne sont pas nécessaires.
Le périphérique de tunnel par défaut est tun1. Assurez-vous de ne pas exécuter plusieurs instances de
fraud-bridge en même temps ni aucun autre logiciel de tunnel utilisant ce
périphérique de tunnel. Après chaque arrêt/redémarrage du démon fraud-bridge, vous devez exécuter
à nouveau les scripts inside/outside à l'extrémité concernée où vous l'avez redémarré.
Le paramètre -L sur la machine externe peut (devrait) être omis. Dans les configurations réelles, le paramètre -R
sur les configurations internes contient l'adresse IP ou IP6 du serveur externe, ou si
la récursion DNS est utilisée, l'adresse IP du serveur DNS de votre fournisseur ou
d'un résolveur DNS récursif public. Si vous n'avez pas votre propre serveur DNS,
vous pouvez toujours utiliser le tunneling DNS en utilisant l'adresse IP de votre VPS comme paramètre -R
sur la machine interne et en utilisant un paramètre de domaine -D identique (mais quelconque) sur les deux extrémités
qui semble légitime pour un régime de censure, par ex. -D blah.gov.
Avant d'essayer le tunneling DNS, vous voudrez probablement d'abord essayer le tunneling ICMP ou NTP.
Si vous voyez des avertissements chroot dans le syslog, vous pouvez les ignorer ou fournir
des arguments valides à -r.
Vous pouvez ensuite utiliser ssh -D 1234 1.2.3.5 pour obtenir une connexion SSH vers 192.168.2.222
dans l'exemple ci-dessus et utiliser le proxy SOCKS5 sur le port :1234 pour votre session de navigateur web
qui transite alors par le tunnel.
Vous pouvez également le faire avec ICMP : -i et ICMP sur IPv6 : -I ou DNS sur UDP via
IPv6 : -U ou NTP via UDP : -n ou NTP via UDP/IPv6 : -N.
Il est aussi possible de changer le type de tunnel (DNS vers ICMP ou ICMP vers NTP) au-delà de votre connexion SSH, ou de passer en itinérance vers une autre adresse IP locale (par ex. passer du wifi à la 5G) car l'état TCP est conservé dans les noyaux local et distant et non dans le pont. Cela permet un support complet de l'itinérance/mobilité SSH sans aucun patch SSH.
En mode verbeux, fraud-bridge laisse stdout ouvert pour rapporter les erreurs ou les messages,
vous devez donc l'exécuter dans un screen ou rediriger la sortie vers /dev/null si vous avez besoin
qu'il tourne en arrière-plan (verbeux). Gardez cela à l'esprit car vous devez lancer les scripts inside/outside
après avoir invoqué fraud-bridge. Si vous n'utilisez pas -v, il passe en arrière-plan et enregistre
les erreurs dans syslog.
Avant d'utiliser des tunnels ICMP, assurez-vous d'assouplir les règles de pare-feu de votre modem câble
afin de recevoir les paquets de réponse de votre pair distant. fraud-bridge fonctionne derrière
un NAT, mais il a besoin de recevoir les paquets de réponse en bout de chaîne. Lorsque vous utilisez le tunneling ICMP et que les échos ICMP
sont bloqués, vous pouvez définir le paramètre de type via -t. Par exemple, en utilisant -t 13 à l'intérieur et -t 14
à l'extérieur pour obtenir des paires requête/réponse d'horodatage.
Lors du tunneling DNS, fraud-bridge utilise les en-têtes d'extension EDNS0 pour mettre autant d'octets que possible dans
la réponse TXT. Dans mes tests, comme il essaie de répondre à tous les paquets de temporisation,
il ne produit aucun journal dans le fichier de log système de bind9. Si vous modifiez
la taille EDNS0 (-E), vous devez le faire sur les deux extrémités avec la même valeur.
(Car la machine interne annonce la taille maximale de la charge utile UDP au serveur de noms et l'extrémité externe
calcule le MSS à partir de la valeur donnée avec -E.)
Lors de l'utilisation du tunneling NTP, certains fournisseurs avec CGN bloquent les gros paquets NTP (sur IPv4 uniquement). Chez un FAI
allemand courant, tous les paquets NTP > 256 octets étaient bloqués. Vous devez donc définir le MSS en conséquence pour obtenir des paquets plus petits
comme -s 100 afin que la pile TCP envoie les segments avec des tailles plus petites.
Comme fraud-bridge ouvre un tunnel PtP, il peut supprimer l'en-tête IP des paquets qu'il transmet et le synthétiser à chaque extrémité. Ainsi, pour le tunneling ICMP, vous avez simplement un surcoût de 8 (ICMP) + 16 (HMAC) octets, ce qui est acceptable. Le tunneling DNS offre encore une bonne latence et une bonne bande passante en mode direct, grâce au MSS clamping. En tunneling indirect via des résolveurs DNS publics, les valeurs par défaut sont suffisantes pour avoir une session raisonnable, mais bien sûr le tunneling ICMP est à privilégier lorsque c'est possible.
En utilisant ssh -D [0.0.0.0]:1234 1.2.3.5, vous pouvez configurer un proxy SOCKS local sur votre machine
sur le port 1234 (côté interne) et le distribuer via WLAN à votre voisinage pour des sessions web sans censure.
Vous pouvez également configurer un tor local sur la machine externe, offrant un port SOCKS sur 127.0.0.1:9150
comme d'habitude, puis utiliser ssh -L 9150:127.0.0.1:9150 1.2.3.5 pour transférer ce port externe
vers votre machine interne, afin de refléter exactement la configuration tor externe localement et de la distribuer
comme port SOCKS tor via WLAN à vos utilisateurs. Ainsi, nous n'avons pas besoin d'implémenter des transports enfichables
et vous pouvez toujours utiliser tor comme avant. Cela fonctionne également avec les sessions crash ou psc ou tout autre
mécanisme de tunnel.
Le paramètre -S a une valeur par défaut raisonnable pour les paquets de temporisation DNS qui doivent être envoyés
au serveur à intervalle constant. Des valeurs plus faibles donnent une meilleure latence du tunnel mais peuvent surcharger
le serveur DNS récursif et générer plus de bruit.
fièrement sponsorisé par :
