Tunnels et VPN résistants au DPI

Nous vivons à une époque intéressante. Je dirais même de façon étonnante. D'un côté, nous voyons des gens qui veulent vraiment savoir ce que les autres se parlent et veulent vraiment leur dire ce qui peut être lu et ce qui ne peut pas être lu. D'autre part, les citoyens qui veulent faire valoir leurs droits aux secrets de la correspondance personnelle et des informations gratuites, et ne veulent pas que les faits de cette correspondance et la réception de ces informations soient utilisés contre eux. Un grand nombre de sites, services et entreprises tiers touchés par des «serrures de tapis» souffrent en prime.

Mais non, cet article n'est pas sur la société, mais sur la technologie.



La culture technique des gens, grâce à tout ce qui se passe, se développe également. Si auparavant les mots «VPN» et «mandataires» n'étaient familiers qu'aux informaticiens, maintenant même les femmes au foyer les connaissent, et en plus, elles utilisent ce que ces mots signifient.

En général, les nouvelles sont récemment devenues assez divertissantes. Par exemple, la fourniture de services VPN et similaires pour crypter le trafic et contourner les verrous est désormais punissable , et en Chine, ils les emprisonnent généralement pour cela. Et il n'y a pas si longtemps, ILV a commencé à utiliser l' analyse de paquets pour bloquer le protocole MTProxy. Vous pouvez également vous référer à l'expérience des autres pays qui réussissent le mieux dans ces domaines: Chine, Iran, Kazakhstan, Venezuela. Au Venezuela, par exemple, ils bloquent directement les connexions directes à Tor et le trafic obscurci vers les ponts. Sur la base de tout cela, nous pouvons supposer que l'avenir nous attend est également très intéressant, surtout si les "personnes responsables" cessent de faire de la fakapy stupide encore et encore, et agissent plus intelligemment et plus sophistiquées.

Sur Habré, à plusieurs reprises dans les commentaires, des prévisions ont été exprimées sur la façon dont la lutte avec les technologies de cryptage pour les citoyens ordinaires peut se poursuivre. En analysant les pensées exprimées et en examinant les témoignages d'autres pays, j'ai essayé de suggérer dans quelle direction les mesures visant à limiter la communication pourraient aller plus loin. DistortNeo et shifttstas ont proposé des idées plus intéressantes et j'ai finalement promis à el777 d' ajouter cet article.

Avec les filtres ACL, tout est clair. Ils agissent maintenant, et avec plus ou moins de succès, ils réussissent et échouent à se battre (bien qu'il y ait des prévisions assez pessimistes ). DPI est plus intéressant.

Les méthodes de "détermination" du type de trafic pour DPI peuvent être divisées en deux groupes:

• Analyse de signature. À savoir, démonter l'emballage "par les os", comparer les en-têtes et la structure avec les échantillons, et ainsi déterminer son objectif. Ainsi, de nombreux tunnels sont détectés, par exemple, OpenVPN, L2TP / IPSec, SOCKS, etc.
• Une analyse préliminaire des modèles d'échange de trafic, par exemple, le rapport du flux entrant / sortant, la fréquence de la demande-réponse et d'autres critères nous permettra de séparer le «trafic réel» d'un protocole et le tunnel qui se fait uniquement passer pour un protocole.

Vous pouvez répartir le trafic en plusieurs groupes et supposer ce qu'ils feront avec chacun d'eux.

1. VPN, tunnels et mandataires «explicites» (OpenVPN, L2TP / IPSec, SOCKS, etc.) Les VPN et tunnels ordinaires peuvent très bien être bloqués automatiquement, comme cela se produit par exemple en Chine et au Venezuela. Si certaines organisations ou entreprises en ont besoin pour travailler, laissez-les s'inscrire et certifier, comme le dit tout particulièrement la loi russe mentionnée ci-dessus. Avec un proxy, il est encore plus facile - que HTTP, que SOCKS transmette les adresses et les contenus en texte clair, ce qui ne pose généralement pas de problème pour la «coupe» sélective des demandes et l'écoute électronique des informations transmises.
2. Technologies à double usage telles que SSH . Peu de temps après l'établissement de la session, la vitesse est réduite à une tortue, de sorte que vous pouvez toujours travailler au moins d'une manière ou d'une autre dans la console, mais il n'y a plus de navigation et de téléchargement. Le fait que cela crée des problèmes pendant le travail normal ne dérange personne (ce qui nous a été montré plus d'une fois par ILV ces derniers temps).
3. Protocoles très spécifiques, tels que messagers, clients de jeux, etc.
4. Composés dont le type ne peut être déterminé .

Pour les éléments 3 et 4, des «listes blanches» sont tout à fait possibles (dans lesquelles, par exemple, des sous-réseaux de serveurs de jeu officiels ou des messagers «corrects» sont entrés, et tout ce que les propriétaires de serveurs veulent déclarer et organiser selon les besoins afin qu'ils ne soient pas touchés, par analogie avec celles que ILV possède déjà pour les domaines et les adresses IP). Et ceux qui ne figurent pas dans ces listes seront confrontés au même sort que le paragraphe 1 ou le paragraphe 2, bien qu'il soit tout à fait possible de ne pas bloquer ou couper carrément la vitesse, mais d'analyser les modèles d'échange précédemment mentionnés afin de déterminer si le trafic est «pur» "Ou" suspect. "

Autrement dit, si vous voulez vous déguiser en protocoles spéciaux, ou pour obscurcir les connexions afin qu'il soit impossible de déterminer leur type, vous devrez également prendre soin de créer du "bruit" qui empêche la détection de véritables modèles d'échange. Jusqu'à présent, de tels développements ne m'ont pas traversé les yeux.

Vous ne vous souvenez même pas des différents tunnels ICMP et DNS - une grande quantité de trafic «là où ils n’en sont pas nécessaires» soulève automatiquement des soupçons.

5. TLS et SSL, HTTPS . Il est impossible de couper net, car cela signifie automatiquement bloquer tout Internet. L'analyse de modèle n'a pas de sens, car la navigation sur le Web n'est que l'objectif principal de l'utilisation de HTTPS. De tout ce qui précède, SSL / TLS sur le port 443 ressemble à l'option la plus «sans méfiance» et la plus fiable. Par conséquent, essayons de nous déguiser en lui.

Se déguiser

Pour examen, il a été décidé de choisir les solutions Streisand et SoftEther.

Streisand - un ensemble complet de services différents: OpenConnect / AnyConnect, OpenVPN, stunnel, Shadowsocks, WireGuard. Tout cela est défini en mode «clé en main» automatique ou semi-automatique, et à la sortie, l'utilisateur reçoit un serveur configuré, ainsi que des fichiers et une documentation détaillée pour la configuration des clients.

SoftEther est un serveur VPN qui peut lever L2TP / IPsec, OpenVPN, SSTP et d'autres protocoles, et possède également son propre protocole SSL-VPN, qui, selon les auteurs, ne se distingue pas du trafic HTTPS normal.

Alors ...

OpenConnect / AnyConnect. Implémentation open source du protocole SSL Cisco AnyConnect. Lorsqu'une connexion est établie, non seulement les paquets TLS (TCP), mais aussi les paquets DTLS (UDP) sont visibles. DTLS, en principe, est également beaucoup utilisé "à des fins pacifiques", mais ce n'est pas du tout comme "HTTPS normal". Cependant, si vous coupez le trafic UDP sur le pare-feu, AnyConnect bascule immédiatement vers TCP et de l'extérieur ressemble, encore une fois, complètement et complètement au TLS normal, et même l'authentification à l'intérieur du tunnel crypté est presque comme dans HTTP.

Shadowsocks . Proxy SOCKS crypté. Apparemment, si vous le souhaitez, il peut être détecté , cependant, il existe des plugins qui le déguisent en «HTTPS pur» . Il existe également un plugin pour travailler via les websockets, mais plus à ce sujet plus tard.

Wireguard À en juger par la description, il dispose d'un cryptage bien tordu et d'un mécanisme de configuration de session, mais toutes les communications se font via UDP. Wireshark définit le type de packages comme quelque chose de complètement inaudible, et quelle opinion de ce qui se passe avec un DPI tiers est une très, très grande question. Mise à jour: les versions plus récentes définissent Wireguard uniquement comme Wireguard, donc la réponse à la question est évidente.

obfs3, obfs4 . Les paquets seront obscurcis de sorte que de l'extérieur, ils ressemblent à un ensemble de valeurs complètement aléatoire. Autrement dit, ils relèvent du point 4 de la liste ci-dessus.

SoftEther Il ressemble à HTTPS, mais avec une prise. En plus de TLS directement sur TCP, il envoie activement des paquets de paquets UDP. Comme cela a été découvert dans la documentation, UDP peut être utilisé pour accélérer le transfert de données dans le cas où il n'est pas tué sur le pare-feu. Cette fonctionnalité est désactivée dans la configuration et une fois désactivée, tout devient comme il se doit.

SSTP . VPN prokotol de Microsoft. Prise en charge native sur Windows, prise en charge des logiciels sur GNU / Linux. De l'extérieur, cela ressemble à HTTPS, et Wireshark le confirme pleinement.

Mais ce n'est pas tout

Supposons que vous ayez installé un serveur VPN ou l'extrémité d'un tunnel sur un hôte et que vous l'ayez configuré pour écouter sur le port 443. Il semblerait que tout va bien, mais il y en a un MAIS: si nous nous déguisons en HTTPS, vous pouvez vérifier qu'en fait il se bloque sur le port 443 simplement en essayant de vous enterrer dans ce port avec un simple navigateur ou CURL, ou de toute autre manière. Dans certains articles, une telle méthode est appelée "connexion de plomb" et, comme mentionné, est déjà assez utilisée en Chine.

Par conséquent, nous avons besoin que sur le 443e port, nous ayons le serveur Web le plus ordinaire et le plus décent. Et ici se pose un problème intéressant.

Aucun des services ci-dessus dans la documentation principale n'a trouvé de description du mécanisme de fonctionnement du partage de port. L' option SSLH ne convient pas, ne serait-ce que parce que sslh n'est pas en mesure de partager le trafic entre HTTPS et les services ci-dessus. Au moins, parce que si le type de trafic sans décryptage complet pouvait distinguer sslh, alors DPI serait en mesure de le faire.

La plupart des hommes, comme celui-ci , suggèrent d'utiliser l'indication de nom de serveur (SNI) - une extension TLS qui vous permet de spécifier un nom d'hôte, puis d'utiliser HAProxy, sniproxy et d'autres outils pour disperser les connexions pour les services. Le problème est que dans les implémentations TLS modernes, le nom d'hôte spécifié lors de l'utilisation de SNI est transmis en texte brut, c'est-à-dire sous forme non chiffrée, et, par conséquent, peut également être espionné et utilisé à l'avenir.

Par conséquent, nous allons improviser, puis deux options me sont venues à l'esprit.

Coup de port

Le détournement de port est juste conçu pour activer des "services cachés" sur le serveur. Par exemple, d'une manière similaire, le port sur lequel le démon SSH se bloque est souvent fermé "pour" afin d'éviter la force brute et l'utilisation de vulnérabilités 0-day. Dans la version classique (voir, par exemple, l'implémentation du démon knockd), le knocking est généralement compris comme des tentatives d'établir une connexion ou d'envoyer des paquets à certains ports hôtes dans une certaine séquence, à la suite de quoi le démon vous «reconnaît» comme lui-même et active une règle de pare-feu qui permet d'accéder à un port spécifique uniquement à partir de votre IP.

Dans notre cas, cette option n'est pas entièrement acceptable. Premièrement, les ports «non standard» eux-mêmes peuvent être bloqués quelque part en cours de route, et deuxièmement, la procédure elle-même, lorsqu'elle est analysée de l'extérieur, peut sembler suspecte. Puisque nous nous faisons passer pour HTTPS, nous devons «frapper» sur HTTPS.

Étonnamment, il n'y avait pas de heurteurs HTTP / HTTPS avec la fonctionnalité requise, et donc un nocker est né avec le nom romantique Labean (hussards, tais-toi !).

Éléments fournis: notre serveur, sur lequel Nginx s'exécute sur le port 443 avec des certificats correctement configurés et affiche du contenu complètement inoffensif, par exemple, des GIF avec des chats, des images ISO de distributions GNU / Linux ou un miroir Wikipedia et une bibliothèque Moshkov.

En même temps, les lignes du formulaire se cachaient dans la configuration 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

: 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, , , .



— 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;
( ).

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

, , , , — , , , .
.