
Herramienta de túneles ICMP, DNS y NTP para evadir la censura, con protección de integridad HMAC y sujeción MSS para sesiones web eficientes en redes restrictivas.
fraud-bridge ayuda a eludir entornos de censura restrictivos que bloquean conexiones TCP o UDP directas, configurando túneles ICMP, NTP o DNS (sobre IPv4 o IPv6).
Automáticamente parchea la opción TCP MSS para lograr un flujo no fragmentado de paquetes (conocido como MSS-clamping) para ganar rendimiento que permite usar sesiones web a través del puente.
Usa MD5 para proteger con integridad (HMAC-) el túnel de paquetes TCP inyectados maliciosos. Si necesitas privacidad, debes usar cifrado por tu cuenta. Se asume que usas SSH sobre el túnel de todas formas. Ya sea directamente o con la opción de proxy SSH si necesitas HTTP tunelado.
Al tunelar DNS, fraud-bridge usa cabeceras de extensión EDNS0 para poner tantos bytes como sea posible en la respuesta TXT.
fraud-bridge también incluye algunas otras técnicas para lidiar con ciertas limitaciones de bind, p.ej. cuotas/limitación.
También puedes usarlo para obtener soporte completo de roaming/movilidad en tus sesiones SSH sin ningún parche.
Una vez que hayas configurado el túnel, quizás quieras leer cómo hacer funcionar tu mensajería a través del túnel.
Ten en cuenta también que c->skills proporciona la cadena completa de equipo de censura que puede interesarte: crash y psc
Simplemente ejecuta make en Linux.
El uso es el siguiente:
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
Algunas definiciones: inside se refiere a la máquina dentro de la red censurada, muy probablemente tu portátil/PC. outside se refiere a un VPS o máquina fuera de la red censurada, es decir, lo que la gente llama "internet libre".
Después de iniciar, fraud-bridge abre un túnel punto a punto: 1.2.3.4 <-> 1.2.3.5
Luego necesitas iniciar inside.sh en el interior y outside.sh en el exterior.
Se ve así:
En el extremo exterior del túnel (p.ej. un servidor en internet):
# ./fraud-bridge -u -L 192.168.2.222 -D f.sub.dnstunnel.com -k key
(y iniciando outside.sh)
Y en el interior:
# ./fraud-bridge -u -R 127.0.0.1 -D f.sub.dnstunnel.com -k key
(y iniciando inside.sh)
como ejemplo de un túnel DNS con un named local en 127.0.0.1 ejecutándose y el par externo estando en 192.168.2.222. Como se dijo, la parte externa del túnel puede (y de hecho necesita) iniciarse de antemano y simplemente escuchará al par para abrir el túnel. Se incluyen archivos de zona de ejemplo si quieres experimentar con tus propias configuraciones de bind. Para ejecutar túneles ITW no son necesarios.
El dispositivo de túnel predeterminado es tun1. Asegúrate de no ejecutar múltiples instancias de fraud-bridge al mismo tiempo ni ningún otro software de túnel que esté usando este dispositivo de túnel. Después de cada matar/reiniciar el demonio de fraud-bridge tienes que ejecutar los scripts inside/outside nuevamente en el extremo particular donde lo reiniciaste.
El parámetro -L en el exterior puede (debe) omitirse. En configuraciones reales, el parámetro -R en configuraciones internas contiene la dirección IP o IP6 del servidor exterior, o si se usa recursión DNS, la dirección IP del servidor DNS de tu proveedor o del resolvedor DNS recursivo público. Si no tienes tu propio servidor DNS, aún puedes usar tunelado DNS usando la IP de tu VPS como parámetro -R en el interior y usando cualquier parámetro de dominio -D (pero el mismo) en ambos extremos que parezca legítimo para un régimen de censura, p.ej. -D blah.gov.
Antes de probar el tunelado DNS, muy probablemente quieras probar con tunelado ICMP o NTP. Si ves advertencias de chroot en el syslog, puedes ignorarlas o proporcionar argumentos válidos a -r.
Entonces puedes usar ssh -D 1234 1.2.3.5 para obtener una conexión SSH a 192.168.2.222 en el ejemplo anterior y usar el proxy SOCKS5 en el puerto :1234 para tu sesión de navegador web que luego se ejecuta a través del túnel.
También puedes hacer eso con ICMP: -i e ICMP en IPv6: -I o DNS en UDP a través de IPv6: -U o NTP a través de UDP: -n o NTP a través de UDP/IPv6: -N.
También es posible cambiar el tipo de túnel (DNS a ICMP o ICMP a NTP) más allá de tu conexión SSH, o cambiar a otra IP local (p. ej. cambiar de wifi a 5G) ya que el estado TCP se mantiene en el kernel local y remoto y no en el puente. Esto permite soporte completo de roaming/movilidad SSH sin ningún parche a SSH.
En modo verbose, fraud-bridge dejará stdout abierto para reportar errores o mensajes, por lo que debes ejecutarlo en una pantalla o redirigir la salida a /dev/null si necesitas que se ejecute en segundo plano (verbose). Tenlo en cuenta ya que necesitas iniciar los scripts inside/outside después de invocar fraud-bridge. Si no usas -v, va a segundo plano y registra errores en syslog.
Antes de usar cualquier túnel ICMP, asegúrate de relajar las reglas de firewall de tu módem de cable para recibir los paquetes de respuesta de tu par remoto. fraud-bridge funciona detrás de NAT, pero necesita recibir los paquetes de respuesta al final. Al usar tunelado ICMP y los ecos ICMP están bloqueados, puedes configurar el parámetro de tipo mediante -t. Por ejemplo, usando -t 13 en el interior y -t 14 en el exterior para obtener pares de solicitud/respuesta de timestamp.
Al tunelar DNS, fraud-bridge usa cabeceras de extensión EDNS0 para poner tantos bytes como sea posible en la respuesta TXT. En mis pruebas, como intenta responder a cualquier paquete de temporización, no produce registros en un archivo de registro del sistema bind9. Si cambias el EDNS0 (-E), debes hacerlo en ambos extremos con el mismo valor. (Ya que el interior anuncia el tamaño máximo de carga útil UDP al servidor de nombres y el punto final exterior calcula el MSS a partir de lo que se dio con -E.)
Al usar tunelado NTP, algunos proveedores con CGN bloquean paquetes NTP grandes (solo en IPv4). En un ISP alemán común, cualquier paquete NTP > 256 bytes era bloqueado. Por lo tanto, debes configurar el MSS en consecuencia para obtener paquetes más pequeños como -s 100 para que la pila TCP envíe los segmentos en tamaños más pequeños.
Dado que fraud-bridge abre un túnel PtP, puede quitar la cabecera IP de los paquetes que transmite y sintetizarla en cada extremo. Así que para tunelado ICMP solo tienes una sobrecarga de 8 (ICMP) + 16 (HMAC) bytes, lo cual es aceptable. El tunelado DNS aún tiene buena latencia y ancho de banda cuando se hace directamente, gracias al MSS clamping. Al tunelar indirectamente a través de resolvedores DNS públicos, los valores predeterminados son suficientemente buenos para tener una sesión razonable, pero por supuesto el tunelado ICMP es preferible siempre que sea posible.
Usando ssh -D [0.0.0.0]:1234 1.2.3.5 puedes configurar un proxy SOCKS local en tu máquina puerto 1234 (interior) y distribuirlo a través de WLAN a tu vecindario para sesiones web sin censura.
También puedes configurar un tor local en la caja exterior, ofreciendo un puerto SOCKS en 127.0.0.1:9150 como se hace normalmente y luego usando ssh -L 9150:127.0.0.1:9150 1.2.3.5 para reenviar este puerto exterior a tu máquina interior, de modo que refleje exactamente la configuración tor exterior localmente y distribuirla como puerto SOCKS tor a través de WLAN a tus usuarios. De esta manera no necesitamos implementar transportes conectables y aún puedes usar tor como antes. Lo mismo también funciona con sesiones crash o psc o cualquier otro mecanismo de tunelado.
El parámetro -S tiene un valor predeterminado razonable para los paquetes de temporizador DNS que deben enviarse al servidor en intervalo constante. Valores más bajos dan una mejor latencia del túnel pero pueden sobrecargar el servidor DNS recursivo y producir más ruido.
orgullosamente patrocinado por: