Túneis e VPNs resistentes a DPI

Vivemos um momento interessante. Eu diria mesmo de maneiras surpreendentes. Por um lado, vemos algumas pessoas que realmente querem saber o que as outras pessoas estão falando e querem realmente dizer a elas o que pode ser lido e o que não pode ser lido. Por outro lado, os cidadãos que desejam reivindicar seus direitos a segredos de correspondência pessoal e informações gratuitas e não querem que os fatos dessa mesma correspondência e o recebimento dessas informações sejam usados ​​contra eles. Um grande número de sites, serviços e empresas de terceiros atingidos por "bloqueios de carpete" sofre como um bônus.

Mas não, este artigo não é sobre sociedade, mas sobre tecnologia.



A alfabetização técnica das pessoas, graças a tudo o que está acontecendo, também está crescendo. Se antes as palavras “VPN” e “proxies” eram familiares apenas aos especialistas em TI, agora até as donas de casa as conhecem e, além disso, usam o que essas palavras significam.

Em geral, as notícias chegaram recentemente bastante divertidas. Por exemplo, o fornecimento de serviços VPN e similares para criptografar tráfego e contornar bloqueios agora é punível e, na China, eles geralmente os aprisionam por isso. E não faz muito tempo, o ILV começou a usar a análise de pacotes para bloquear o protocolo MTProxy. Você também pode se referir à experiência dos países mais bem-sucedidos em tais assuntos: China, Irã, Cazaquistão, Venezuela. Na Venezuela, por exemplo, eles bloqueiam diretamente as conexões diretas com o Tor e ofuscam o tráfego para as pontes. Com base em tudo isso, pode-se presumir que o futuro nos espera também é muito interessante, especialmente se as “pessoas responsáveis” pararem de fazer falsas idiotas repetidas vezes e agirem de maneira mais inteligente e sofisticada.

Sobre Habré, repetidamente, nos comentários, previsões de como a luta com tecnologias de criptografia para cidadãos comuns pode continuar. Analisando os pensamentos expressos e observando testemunhos de outros países, tentei sugerir em que direção as medidas para limitar a comunicação poderiam avançar ainda mais. DistortNeo e shifttstas lançaram algumas idéias mais interessantes e, no final, prometi à el777 adicionar este artigo.

Com os filtros ACL, tudo fica claro. Eles estão agindo agora, e com sucesso variado, conseguem e não conseguem lutar (embora haja previsões bastante pessimistas ). DPI é mais interessante.

Os métodos para "determinar" o tipo de tráfego para DPI podem ser divididos em dois grupos:

• Análise de assinatura. Ou seja, desmontar a embalagem "pelos ossos", comparando os cabeçalhos e a estrutura com as amostras, e assim determinando sua finalidade. Assim, muitos túneis são detectados, por exemplo, OpenVPN, L2TP / IPSec, SOCKS, etc.
• Uma análise preliminar dos padrões de troca de tráfego, por exemplo, a proporção do fluxo de entrada / saída, a frequência da solicitação-resposta e outros critérios nos permitirá separar o "tráfego real" de um protocolo e o túnel que apenas se disfarça como protocolo.

Você pode dividir o tráfego em vários grupos e assumir o que eles farão com cada um deles.

1. VPNs, túneis e proxies “explícitos” (OpenVPN, L2TP / IPSec, SOCKS, etc.) VPNs e túneis comuns podem ser bloqueados automaticamente, como, por exemplo, na China e na Venezuela. Se algumas organizações ou empresas precisarem dela para trabalhar, deixe-as se registrar e certificar, como fala especificamente a lei russa mencionada acima. Com um proxy, é ainda mais fácil - que o HTTP, o SOCKS transmite endereços e conteúdos em texto não criptografado, o que geralmente não cria problemas para o "corte" seletivo de solicitações e a escuta telefônica das informações transmitidas.
2. Tecnologias de uso duplo, como SSH . Pouco tempo depois da sessão ter sido estabelecida, a velocidade é reduzida a uma tartaruga, para que você possa trabalhar pelo menos de alguma forma no console, mas não há mais navegação e download. O fato de isso criar problemas durante o trabalho normal não incomoda ninguém (o que nos foi mostrado pela ILV mais de uma vez nos últimos tempos).
3. Protocolos altamente específicos, como mensageiros, clientes de jogos etc.
4. Compostos cujo tipo não pode ser determinado .

Para os itens 3 e 4, as “listas brancas” são bastante possíveis (nas quais, por exemplo, são inseridas sub-redes de servidores oficiais de jogos ou mensageiros “corretos” e tudo o que os proprietários do servidor desejam declarar e organizar conforme necessário para que não sejam tocados, aqueles que a ILV já possui para domínios e endereços IP). E aqueles que não estão nessas listas enfrentarão o mesmo destino que o parágrafo 1 ou o parágrafo 2, embora seja possível não bloquear ou diminuir abruptamente a velocidade, mas analisar os padrões de troca mencionados anteriormente para determinar se o tráfego é "puro" "Ou" suspeito. "

Ou seja, se você deseja se disfarçar de protocolos especiais ou ofuscar as conexões para que seja impossível determinar seu tipo, você também precisará criar um "ruído" que impeça a detecção de padrões reais de troca. Até o momento, esses desenvolvimentos não passaram pela minha cabeça.

Você nem se lembra dos diferentes túneis de ICMP e DNS - uma grande quantidade de tráfego "onde não é necessário" neles automaticamente também levanta suspeitas.

5. TLS e SSL, HTTPS . É impossível fazer uma limpeza, pois isso significa automaticamente bloquear toda a Internet. A análise de padrões não faz sentido, pois a navegação na web é apenas o principal objetivo do uso de HTTPS. De todas as opções acima, o SSL / TLS na porta 443 parece a opção mais "desavisada" e confiável. Portanto, vamos tentar nos disfarçar como ele.

Disfarçar-nos

Para consideração, foi decidido escolher as soluções Streisand e SoftEther.

Streisand - um conjunto completo de serviços diferentes: OpenConnect / AnyConnect, OpenVPN, stunnel, Shadowsocks, WireGuard. Tudo isso é definido no modo “chave na mão” automático ou semiautomático e, na saída, o usuário recebe um servidor configurado, além de arquivos e documentação detalhada para a configuração de clientes.

O SoftEther é um servidor VPN capaz de levantar L2TP / IPsec, OpenVPN, SSTP e outros protocolos, além de possuir seu próprio protocolo SSL-VPN, que, segundo os autores, é indistinguível do tráfego HTTPS normal.

Então ...

OpenConnect / AnyConnect. Implementação de código aberto do protocolo Cisco AnyConnect SSL. Quando uma conexão é estabelecida, não apenas os pacotes TLS (TCP), mas também os pacotes DTLS (UDP) são visíveis. O DTLS, em princípio, também é usado muito onde "para fins pacíficos", mas isso não é como "HTTPS normal". No entanto, se você cortar o tráfego UDP no firewall, o AnyConnect imediatamente retornará ao TCP e, do lado de fora, parecerá completamente e completamente como o TLS normal, e até a autenticação dentro do túnel criptografado é quase como no HTTP.

Shadowsocks . Proxy SOCKS criptografado. Aparentemente, se desejado, ele pode ser detectado , no entanto, existem plugins que o disfarçam como "puro HTTPS" . Há também um plugin para trabalhar com websockets, mas mais sobre isso mais tarde.

Wireguard A julgar pela descrição, ele possui criptografia bem distorcida e um mecanismo de configuração de sessão, mas toda a comunicação ocorre através do UDP. O Wireshark define o tipo de pacote como algo completamente inaudível, e que opinião do que está acontecendo com um DPI de terceiros é uma questão muito, muito grande. Upd: As versões mais recentes definem o Wireguard exclusivamente como Wireguard, portanto a resposta para a pergunta é óbvia.

obfs3, obfs4 . Os pacotes serão ofuscados para que, de fora, pareçam um conjunto de valores completamente aleatório. Ou seja, eles se enquadram no item 4 da lista acima.

SoftEther Parece HTTPS, mas com uma captura. Além de TLS diretamente sobre TCP, ele envia ativamente pacotes de pacotes UDP. Como foi descoberto na documentação, o UDP pode ser usado para acelerar a transferência de dados no caso em que não é eliminado no firewall. Essa funcionalidade está desabilitada na configuração e, depois de desabilitada, tudo se torna como deveria.

SSTP . Prokotol VPN da Microsoft. Suporte nativo no Windows, suporte a software no GNU / Linux. Do lado de fora, parece HTTPS, e o Wireshark confirma isso completamente.

Mas isso não é tudo

Suponha que você instalou um servidor VPN ou o fim de um túnel em um host e o configurou para escutar na porta 443. Parece que está tudo bem, mas há um MAS: se nos disfarçarmos de HTTPS, você pode verificar se, na verdade, está travado na porta 443, simplesmente tentando se enterrar nessa porta com um navegador simples ou CURL, ou de qualquer outra maneira. Em alguns artigos, esse método é chamado de "conexão de chumbo" e, como mencionado, já é bastante utilizado na China.

Portanto, precisamos que, na porta 443, tenhamos o servidor da Web mais comum e decente. E aqui surge um problema interessante.

Nenhum dos serviços acima na documentação principal encontrou uma descrição do mecanismo de trabalho do compartilhamento de portas. A opção SSLH não é adequada, apenas porque o sslh não pode compartilhar tráfego entre HTTPS e os serviços acima. Pelo menos, porque se o tipo de tráfego sem descriptografia completa puder distinguir sslh, o DPI poderá.

A maioria dos homens, assim, sugere o uso de Server Name Indication (SNI) - uma extensão TLS que permite especificar um nome de host e, em seguida, usar HAProxy, sniproxy e outras ferramentas para dispersar as conexões de serviços. O problema é que, nas implementações modernas do TLS, o nome do host especificado ao usar o SNI é transmitido em texto sem formatação, ou seja, em forma não criptografada e, portanto, também pode ser espionado e usado no futuro.

Portanto, improvisaremos, e então duas opções vieram à minha mente.

Porto batendo

A batida na porta foi projetada apenas para ativar "serviços ocultos" no servidor. Por exemplo, de uma maneira semelhante, a porta na qual o daemon SSH trava é frequentemente fechada "para fora" para evitar força bruta e o uso de vulnerabilidades de 0 dia. Na versão clássica (consulte, por exemplo, a implementação do daemon knockd), a batida é geralmente entendida como tentativas de estabelecer uma conexão ou enviar pacotes para portas de host específicas em uma determinada sequência, como resultado do qual o daemon o “reconhece” por si próprio e ativa uma regra de firewall que permite o acesso a uma porta específica somente do seu IP.

No nosso caso, essa opção não é totalmente aceitável. Em primeiro lugar, as próprias portas “não padronizadas” podem ser bloqueadas em algum ponto do caminho e, em segundo lugar, o próprio procedimento, quando analisado de fora, pode parecer suspeito. Desde que nos disfarçamos como HTTPS, precisamos "bater" no HTTPS.

Surpreendentemente, não havia batedores HTTP / HTTPS com a funcionalidade necessária e, portanto, um nocker nasceu com o nome romântico Labean (hussardos, fique quieto!).

Dado: nosso servidor, no qual o Nginx é executado na porta 443 com certificados configurados corretamente e exibe algum conteúdo completamente inofensivo, por exemplo, GIFs com gatos, imagens ISO de distribuições GNU / Linux ou um espelho da Wikipedia e a biblioteca de Moshkov.

Ao mesmo tempo, as linhas do formulário ocultam na configuração do 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., , « », .

, , , , — , , , .
.