Túneles y VPN resistentes a DPI

Vivimos en un momento interesante. Incluso diría de maneras asombrosas. Por un lado, vemos algunas personas que realmente quieren saber lo que otras personas están hablando entre sí, y realmente quieren decirles qué se puede leer y qué no se puede leer. Por otro lado, los ciudadanos que desean hacer valer sus derechos a los secretos de la correspondencia personal y la información gratuita, y no quieren que los hechos de esta correspondencia y el recibo de esta información se utilicen en su contra. Una gran cantidad de sitios de terceros, servicios y negocios que son golpeados por “cerraduras de alfombra” sufren como un bono.

Pero no, este artículo no se trata de la sociedad, sino de la tecnología.

imagen

La alfabetización técnica de las personas, gracias a todo lo que está sucediendo, también está creciendo. Si antes las palabras "VPN" y "proxies" eran familiares solo para los especialistas de TI, ahora incluso las amas de casa las conocen y, además, usan lo que significan estas palabras.

En general, la noticia recientemente ha sido bastante entretenida. Por ejemplo, la prestación de servicios VPN y similares para cifrar el tráfico y evitar los bloqueos ahora es punible , y en China generalmente los encarcelan por esto. Y no hace mucho tiempo, ILV comenzó a usar el análisis de paquetes para bloquear el protocolo MTProxy. También puede referirse a la experiencia de los países que tienen más éxito en tales asuntos: China, Irán, Kazajstán, Venezuela. En Venezuela, por ejemplo, bloquean directamente las conexiones directas a Tor y el tráfico ofuscado a los puentes. En base a todo esto, podemos suponer que el futuro nos espera también es muy interesante, especialmente si las "personas responsables" dejan de hacer tonterías una y otra vez y actúan de manera más inteligente y sofisticada.

En Habré repetidamente en los comentarios se expresaron pronósticos de cómo puede continuar la lucha con las tecnologías de cifrado para los ciudadanos comunes. Analizando los pensamientos expresados ​​y mirando los testimonios de otros países, traté de sugerir en qué dirección podrían avanzar las medidas para limitar la comunicación. DistortNeo y shifttstas arrojaron algunas ideas más interesantes, y al final le prometí a el777 agregar este artículo.

Con los filtros ACL, todo está claro. Están actuando ahora, y con un éxito variable tienen éxito y no luchan (aunque hay pronósticos bastante pesimistas ). DPI es más interesante.

Los métodos para "determinar" el tipo de tráfico para DPI se pueden dividir en dos grupos:

  • Análisis de firma. Es decir, desmontar el paquete "por los huesos", comparar los encabezados y la estructura con las muestras, y así determinar su propósito. Por lo tanto, se detectan muchos túneles, por ejemplo, OpenVPN, L2TP / IPSec, SOCKS, etc.
  • Un análisis preliminar de los patrones de intercambio de tráfico, por ejemplo, la relación del flujo entrante / saliente, la frecuencia de solicitud-respuesta y otros criterios nos permitirán separar el "tráfico real" de un protocolo y el túnel que solo se disfraza como protocolo.

imagen

Puede dividir el tráfico en varios grupos y asumir lo que harán con cada uno de ellos.

  1. VPN, túneles y servidores proxy "explícitos" (OpenVPN, L2TP / IPSec, SOCKS, etc.) Los VPN y túneles ordinarios pueden bloquearse automáticamente, como, por ejemplo, esto sucede en China y Venezuela. Si algunas organizaciones o empresas lo necesitan para el trabajo, permítales registrarse y certificarse, como lo menciona la ley rusa mencionada anteriormente. Con un proxy, es aún más fácil: ese HTTP, que los SOCKS transmiten direcciones y contenidos en texto claro, lo que generalmente no crea ningún problema para el "corte" selectivo de solicitudes y escuchas telefónicas de la información transmitida.
  2. Tecnologías de doble uso como SSH . Poco tiempo después de que se estableció la sesión, la velocidad se reduce a una tortuga, por lo que todavía puede trabajar al menos de alguna manera en la consola, pero no hay más navegación y descarga. El hecho de que esto cree problemas durante el trabajo normal no molesta a nadie (lo que ILV nos ha demostrado más de una vez en los últimos tiempos).
  3. Protocolos altamente específicos, como mensajeros, clientes de juegos, etc.
  4. Compuestos cuyo tipo no se puede determinar .

Para los ítems 3 y 4, las "listas blancas" son bastante posibles (en las cuales, por ejemplo, se ingresan subredes de servidores oficiales del juego o mensajeros "correctos", y todo lo que los propietarios del servidor desean declarar y organizar según sea necesario para que no se toquen, por analogía con los que ILV ya tiene para dominios y direcciones IP). Y aquellos que no están en estas listas enfrentarán el mismo destino que el párrafo 1 o el párrafo 2, aunque es bastante posible no bloquear o cortar la velocidad sin rodeos, sino analizar los patrones de intercambio mencionados anteriormente para determinar si el tráfico es "puro" "O" sospechoso ".

Es decir, si desea disfrazarse de protocolos especiales, u ofuscar las conexiones para que sea imposible determinar su tipo, también deberá crear un "ruido" que evite la detección de patrones de intercambio reales. Hasta ahora, tales desarrollos no me han llegado a los ojos.

Ni siquiera puede recordar acerca de los diferentes túneles ICMP y DNS: una gran cantidad de tráfico "donde no se necesita" en ellos también automáticamente genera sospechas.

5. TLS y SSL, HTTPS . Es imposible cortar limpio, ya que esto automáticamente significa bloquear todo Internet. El análisis de patrones no tiene sentido, ya que la navegación web es solo el propósito principal de usar HTTPS. De todo lo anterior, SSL / TLS en el puerto 443 parece la opción más "desprevenida" y confiable. Por lo tanto, tratemos de disfrazarnos como él.

imagen

Disfrazarse


Para su consideración, se decidió elegir las soluciones Streisand y SoftEther.

Streisand : un conjunto completo de servicios diferentes: OpenConnect / AnyConnect, OpenVPN, stunnel, Shadowsocks, WireGuard. Todo esto se configura en modo automático o semiautomático "llave en mano", y en la salida el usuario recibe un servidor configurado, así como archivos y documentación detallada para configurar clientes.

SoftEther es un servidor VPN que puede levantar L2TP / IPsec, OpenVPN, SSTP y otros protocolos, y también tiene su propio protocolo SSL-VPN, que, según los autores, es indistinguible del tráfico HTTPS normal.

Entonces ...

OpenConnect / AnyConnect. Implementación de código abierto del protocolo SSL de Cisco AnyConnect. Cuando se establece una conexión, no solo son visibles los paquetes TLS (TCP), sino también los paquetes DTLS (UDP). DTLS, en principio, también se usa mucho "con fines pacíficos", pero esto no es en absoluto como "HTTPS normal". Sin embargo, si corta el tráfico UDP en el cortafuegos, AnyConnect cambia inmediatamente a TCP y desde el exterior se ve, de nuevo, completamente y completamente como TLS normal, e incluso la autenticación dentro del túnel encriptado es casi como en HTTP.

Calcetines sombríos . Proxy cifrado SOCKS. Aparentemente, si se desea, se puede detectar , sin embargo, hay complementos que lo disfrazan como "HTTPS puro" . También hay un complemento para trabajar a través de websockets, pero más sobre eso más adelante.

Guardia de alambre A juzgar por la descripción, tiene un cifrado bien retorcido y un mecanismo de configuración de sesión, pero toda la comunicación se realiza a través de UDP. Wireshark define el tipo de paquetes como algo completamente inaudible, y la opinión de lo que está sucediendo con un DPI de terceros es una pregunta muy, muy grande. Upd: las versiones más nuevas definen Wireguard únicamente como Wireguard, por lo que la respuesta a la pregunta es obvia.

obfs3, obfs4 . Los paquetes se ofuscarán para que desde el exterior se vean como un conjunto de valores completamente aleatorio. Es decir, se incluyen en el elemento 4 de la lista anterior.

SoftEther Parece HTTPS, pero con una captura. Además de TLS directamente sobre TCP, envía activamente paquetes de paquetes UDP. Como se descubrió en la documentación, UDP puede usarse para acelerar la transferencia de datos en el caso de que no se elimine en el firewall. Esta funcionalidad está deshabilitada en la configuración, y después de deshabilitarla, todo se vuelve como debería.

SSTP . VPN prokotol de Microsoft. Compatible de forma nativa en Windows, software de soporte en GNU / Linux. Desde afuera parece HTTPS, y Wireshark lo confirma completamente.

Pero eso no es todo


Supongamos que instaló un servidor VPN o el final de un túnel en un host y lo configuró para escuchar en el puerto 443. Parece que todo está bien, pero hay una PERO: si nos disfrazamos de HTTPS, puede verificar que de hecho se cuelga en el puerto 443 simplemente tratando de enterrarse en este puerto con un simple navegador o CURL, o de cualquier otra manera. En algunos artículos, dicho método se llama "conexión de plomo" y, como se mencionó, ya se usa bastante en China.

Por lo tanto, necesitamos que en el puerto 443 tengamos el servidor web más común y decente. Y aquí surge un problema interesante.

Ninguno de los servicios anteriores en la documentación principal encontró una descripción del mecanismo de trabajo de uso compartido de puertos. La opción SSLH no es adecuada, aunque solo sea porque sslh no puede compartir el tráfico entre HTTPS y los servicios anteriores. Al menos, porque si el tipo de tráfico sin descifrado completo pudiera distinguir sslh, entonces DPI podrá hacerlo.

La mayoría de los hombres, como este , sugieren usar la Indicación de nombre del servidor (SNI), una extensión TLS que le permite especificar un nombre de host y luego usar HAProxy, sniproxy y otras herramientas para dispersar las conexiones de los servicios. El problema es que en las implementaciones TLS modernas, el nombre de host especificado cuando se usa SNI se transmite en texto sin formato, es decir, en forma no cifrada y, por lo tanto, también se puede espiar y usar en el futuro.

Por lo tanto, improvisaremos, y luego se me ocurrieron dos opciones.

Golpe de puerto


imagen

La eliminación de puertos está diseñada para activar "servicios ocultos" en el servidor. Por ejemplo, de manera similar, el puerto en el que se cuelga el demonio SSH a menudo se cierra "fuera" para evitar la fuerza bruta y el uso de vulnerabilidades de 0 días. En la versión clásica (ver, por ejemplo, la implementación del demonio knockd), el bloqueo generalmente se entiende como intentos de establecer una conexión o enviar paquetes a puertos host específicos en una secuencia determinada, como resultado de lo cual el demonio lo "reconoce" como propio y activa una regla de firewall que permite el acceso a un puerto específico solo desde tu IP.

En nuestro caso, esta opción no es del todo aceptable. En primer lugar, los puertos "no estándar" pueden estar bloqueados en algún lugar del camino y, en segundo lugar, el procedimiento en sí, cuando se analiza desde el exterior, puede parecer sospechoso. Dado que nos disfrazamos de HTTPS, necesitamos "tocar" HTTPS.

Sorprendentemente, no había aldabas HTTP / HTTPS con la funcionalidad requerida y, por lo tanto, nació un nocker con el nombre romántico Labean (húsares, ¡ cállate !).

Dado: nuestro servidor, en el que Nginx se ejecuta en el puerto 443 con certificados configurados correctamente y muestra contenido completamente inofensivo, por ejemplo, GIF con gatos, imágenes ISO de distribuciones GNU / Linux, o un espejo de Wikipedia y una biblioteca de Moshkov.

Al mismo tiempo, las líneas del formulario se ocultaron en la configuración de Nginx

 location ~ ^/somesecret/(.*) {
    auth_basic      "Administrator Login";
    auth_basic_user_file  /var/www/.htpasswd;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_pass http://127.0.0.1:8080/$1;
  }

, CURL'
https://ourserver.org/somesecret/vpn/on
, , , IP-, -
iptables -t nat -A PREROUTING -p tcp -s {clientIP} --dport 443 -j REDIRECT --to-port 4443
.

N (, ) , , , IP .

, , URL , /off .

, IPv6 (v6- X-Real-IP ).

Go, , , . , nginx init- Gihub:
https://github.com/uprt/labean

Websockets


image

: HTTPS — . Web- TCP , Websocket (RFC 6455). HTTP-, , TCP-. , , HTTPS .

WS , - — , CDN, , Cloudflare . , : IP CDN/proxy CDN, VPN/proxy CDN, .

WS- ( Haskell), wstunnel, nodejs , .

. wss://-,

wstunnel -t 33 wss://server:443

, «» ws- «» . wstunnel, , URI - :

wstunnel -t 33 wss://ourserver.org:443/hiddenws/

:

, 443 Nginx c - .

proxy- Websockets-:

location /hiddenws {
    proxy_pass http://127.0.0.1:8081;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
  }

websockets-. SOCKS- (, Dante), OpenVPN, , , .

selinux
RHEL , SELinux, nginx
2018/07/05 13:28:03 [crit] 7724#0: *11 connect() to 127.0.0.1:8081 failed (13: Permission denied) while connecting to upstream, client: IP_ADDRES, server: _, request: «GET /hiddenws/?dst=localhost:22 HTTP/1.1», upstream: «127.0.0.1:8081/hiddenws/?dst=localhost:22»,

:

semanage port -a -t http_port_t -p tcp 22
semanage port -m -t http_port_t -p tcp 22
semanage port -a -t http_port_t -p tcp 8081


Renatk .


— SOCKS- VPN- wstunnel, «» .

, v2ray shadowcocks, websockets shadowsocks. : https://github.com/shadowsocks/v2ray-plugin


— VPN- - MTU, 1400;
— VPN- 2 IP-. VPN/, ;
— «» IP- , ICMP ping;
— - reverse DNS , -, , gateway-001.somehomeisp.net;
— VPN/ DNS- OpenNIC;
( ).


image

- , — . , , — , , . , HTTPS — , , - « »/ /etc., , « », .

, , , , — , , , .
.

Source: https://habr.com/ru/post/es415977/


All Articles