Русский
English
Українська
Deutsch
Español
Português
Türkçe
中文
Um tunnel proxy estabelece uma conexão ponta a ponta entre um cliente e um servidor de destino, encapsulando todo o tráfego dentro de um canal seguro que passa pelo servidor proxy, normalmente sem que o proxy inspecione o conteúdo.
Entendendo o tunelamento de tráfego
O tunelamento de tráfego por um proxy faz com que o servidor proxy atue como retransmissor de fluxos brutos de dados, em vez de intermediário da camada de aplicação. Diferentemente dos forward proxies tradicionais, que encerram as conexões do cliente, interpretam requisições HTTP e então iniciam novas conexões com os servidores de origem, um tunnel proxy cria um canal direto, byte a byte, entre o cliente e o destino final. Esse mecanismo é usado principalmente para protocolos que exigem uma conexão criptografada ou que não é compreendida no nível HTTP, como HTTPS, SSH ou tráfego de VPN.
O método CONNECT
O método mais comum para estabelecer um túnel por um proxy HTTP é o método HTTP CONNECT. Quando um cliente precisa se conectar a um serviço não HTTP ou a um serviço HTTP criptografado (HTTPS) por meio de um proxy, ele envia uma requisição CONNECT ao proxy.
Exemplo de requisição do cliente:
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive
Ao receber essa requisição, o servidor proxy tenta estabelecer uma conexão TCP com o host e a porta especificados (por exemplo, www.example.com na porta 443).
Exemplo de resposta do proxy:
HTTP/1.1 200 Connection established
Proxy-Agent: Squid/5.8
Se o proxy conseguir estabelecer a conexão com o destino, ele responde com o status 200 Connection established. A partir desse ponto, o proxy deixa de interpretar os dados que passam por ele. Em vez disso, atua como um simples retransmissor TCP, encaminhando todos os bytes seguintes do cliente para o servidor de destino e vice-versa. O cliente e o destino podem então estabelecer o próprio protocolo (por exemplo, o handshake TLS do HTTPS) sobre esse túnel.
Casos de uso de tunnel proxies
Os tunnel proxies são parte essencial de diversas operações de rede e posturas de segurança.
- Tráfego HTTPS (SSL/TLS): o caso de uso principal. Os navegadores usam
CONNECTpara tunelar tráfego HTTPS, permitindo que a criptografia ponta a ponta entre o cliente e o servidor web permaneça intacta, já que o proxy não descriptografa o conteúdo. - Protocolos criptografados: qualquer protocolo criptografado baseado em TCP, como SSH (Secure Shell), SFTP ou túneis de VPN (por exemplo, OpenVPN, WireGuard), pode ser roteado por um tunnel proxy.
- Protocolos não HTTP: protocolos como FTP, SMTP, IMAP ou protocolos de aplicação personalizados também podem ser tunelados se configurados para usar um proxy compatível com o método
CONNECTou um proxy SOCKS. - Contornar restrições de rede: em alguns ambientes, firewalls básicos podem bloquear conexões diretas a certas portas ou serviços. Um tunnel proxy pode rotear esse tráfego por uma porta permitida (por exemplo, a porta 80 ou 443 do próprio proxy), contornando efetivamente a restrição baseada em portas.
- Preservar a privacidade: como o proxy não inspeciona o conteúdo tunelado, a confidencialidade da comunicação entre o cliente e o servidor de destino é preservada do ponto de vista do proxy.
Tunnel proxy vs. outros tipos de proxy
Entender a diferença entre tunnel proxies e outros tipos de proxy é fundamental para implantá-los corretamente e com segurança.
| Característica | Tunnel proxy (por exemplo, HTTP CONNECT) |
Forward proxy (HTTP sem tunelamento) | Proxy SOCKS | Reverse proxy |
|---|---|---|---|---|
| Camada de protocolo | Camada de sessão/transporte (TCP) | Camada de aplicação (HTTP/HTTPS) | Camada de sessão (TCP/UDP) | Camada de aplicação (HTTP/HTTPS) |
| Visão do conteúdo | Nenhuma (os dados são opacos) | Total (interpreta cabeçalhos/corpo HTTP) | Nenhuma (os dados são opacos) | Total (interpreta cabeçalhos/corpo HTTP) |
| Uso principal | HTTPS, SSH, VPN, conexões TCP não HTTP | Cache, filtragem, logging, controle de acesso para HTTP | Tunelamento genérico TCP/UDP, contornar firewalls | Balanceamento de carga, terminação SSL, segurança para servidores |
| Criptografia | Preserva a criptografia ponta a ponta entre cliente/destino | Pode descriptografar e recriptografar (man-in-the-middle) para HTTPS | Preserva a criptografia ponta a ponta | Pode encerrar o SSL/TLS do cliente e recriptografar para o backend |
| Método de requisição | CONNECT |
GET, POST, PUT etc. |
CONNECT (SOCKS5) |
O cliente requisita diretamente os serviços de backend |
Vantagens dos tunnel proxies
- Segurança: por não descriptografar nem inspecionar o tráfego tunelado, os tunnel proxies mantêm a integridade de protocolos de criptografia ponta a ponta como o TLS, garantindo que dados sensíveis permaneçam confidenciais entre o cliente e o servidor final.
- Independência de protocolo: uma vez estabelecido o túnel, o proxy é indiferente ao protocolo de aplicação utilizado. Isso permite tunelar praticamente qualquer serviço baseado em TCP.
- Menor sobrecarga no proxy: como o proxy não executa inspeção profunda de pacotes nem processamento de camada de aplicação para o tráfego tunelado, sua carga computacional é menor do que a de proxies que inspecionam conteúdo. O proxy basicamente gerencia estados de conexões TCP.
- Flexibilidade: oferece um mecanismo para rotear tráfego que poderia ser bloqueado por políticas de rede restritivas, melhorando a conectividade do cliente com serviços diversos.
Limitações e considerações
- Sem inspeção de conteúdo: a impossibilidade de inspecionar o tráfego tunelado significa que o proxy não pode aplicar políticas de segurança baseadas em conteúdo, fazer varredura de vírus, prevenção de perda de dados (DLP) nem implementar controles de acesso granulares a partir de dados da camada de aplicação. Isso pode ser uma vulnerabilidade de segurança se não for tratado adequadamente.
- Evasão de controles de segurança: agentes maliciosos podem usar tunnel proxies para driblar equipamentos de segurança de rede que dependem de inspeção de conteúdo (por exemplo, sistemas de detecção/prevenção de intrusão, Web Application Firewalls), encapsulando seu tráfego ilícito dentro de um túnel criptografado.
- Consumo de recursos: mesmo sem inspecionar o conteúdo, manter um grande número de túneis TCP simultâneos consome recursos do sistema (memória para estados de conexão, descritores de arquivo abertos, banda de rede).
- Transparência: tunnel proxies padrão são explícitos; os clientes precisam ser configurados para usá-los. Proxies transparentes normalmente não suportam
CONNECTdiretamente, mas podem interceptar e redirecionar tráfego de formas que simulam tunelamento para determinados protocolos. - Aplicação de políticas: organizações que implantam tunnel proxies precisam considerar as implicações para a segurança da rede e a conformidade. As políticas devem definir quais clientes podem estabelecer túneis e para quais destinos.
Exemplo de configuração (proxy Squid)
Configurar um servidor proxy como o Squid para permitir tunelamento pelo método CONNECT é simples. O trecho de configuração a seguir permite requisições CONNECT para a porta HTTPS padrão (443) e a porta SSH (22), além de uma porta personalizada específica (8443).
# Permitir CONNECT para as portas padrão de SSL/TLS e SSH
acl SSL_ports port 443
acl SSL_ports port 22
acl SSL_ports port 8443 # Exemplo de porta segura personalizada
# Bloquear CONNECT para outras portas
http_access deny CONNECT !SSL_ports
# Permitir CONNECT para todo o restante do tráfego
# Esta regra deve vir depois de eventuais regras de negação específicas
http_access allow CONNECT
Essa configuração garante que, embora o tunelamento seja permitido, ele fique restrito a portas seguras de uso comum ou a portas personalizadas explicitamente autorizadas, mitigando parte dos riscos associados ao tunelamento irrestrito. Em ambientes de produção, normalmente são implementadas listas de controle de acesso (ACLs) mais granulares para restringir o acesso de clientes e os endereços de destino.