Túnel SSH como proxy

Um túnel SSH pode ser usado como proxy SOCKS aproveitando o recurso de encaminhamento dinâmico de portas do cliente SSH, que permite encaminhar o tráfego de uma porta local através do servidor SSH até destinos arbitrários na rede acessível por esse servidor.

Entendendo SOCKS via SSH

SOCKS (Socket Secure) é um protocolo de internet que roteia pacotes de rede entre um cliente e um servidor através de um proxy. Combinado com o encaminhamento dinâmico de portas do SSH, o cliente SSH cria um servidor proxy SOCKS local. Qualquer aplicação configurada para usar esse proxy SOCKS local terá seu tráfego criptografado e roteado pela conexão SSH até o servidor SSH remoto. O servidor SSH então atua como o proxy SOCKS, estabelecendo conexões com o destino final em nome do cliente.

Esse mecanismo, na prática, estende o alcance de rede do cliente até o alcance do servidor SSH e, ao mesmo tempo, criptografa todos os dados transmitidos entre o cliente e o servidor SSH.

Como funciona o encaminhamento dinâmico de portas

O encaminhamento dinâmico de portas, definido pela opção -D do SSH, instrui o cliente SSH a:
1. Escutar uma porta local específica aguardando conexões de entrada.
2. Ao receber uma conexão nessa porta local, agir como servidor SOCKS.
3. Negociar o protocolo SOCKS com a aplicação cliente (por exemplo, um navegador).
4. Com base na requisição SOCKS (que inclui host e porta de destino), encaminhar essa requisição pelo túnel SSH criptografado até o servidor SSH.
5. O servidor SSH então inicia uma conexão com o host e a porta de destino a partir do seu próprio contexto de rede.
6. Todos os dados trocados em seguida entre a aplicação cliente e o host de destino são retransmitidos pelo túnel SSH, criptografados entre o cliente e o servidor SSH.

Configurando um proxy SOCKS por SSH

Para estabelecer um proxy SOCKS por SSH, usa-se um cliente SSH para conectar a um servidor SSH remoto. O servidor precisa estar configurado para permitir encaminhamento TCP (normalmente já habilitado por padrão via AllowTcpForwarding yes no sshd_config).

O comando básico para configurar um encaminhamento dinâmico de portas é:

ssh -D [LOCAL_PORT] [USER]@[SSH_SERVER_IP] -N -f

Opções do comando explicadas:

• -D [LOCAL_PORT]: define o encaminhamento dinâmico de portas. O cliente SSH vai escutar em LOCAL_PORT na máquina local. Essa porta funcionará como proxy SOCKS. Escolhas comuns para LOCAL_PORT são 1080, 8080, 9050 ou qualquer porta não privilegiada acima de 1024.
• [USER]: o nome de usuário para autenticação no servidor SSH remoto.
• [SSH_SERVER_IP]: o endereço IP ou hostname do servidor SSH remoto.
• -N: impede a execução de comandos remotos. Use quando só o encaminhamento de portas é desejado, sem shell interativo.
• -f: envia o ssh para segundo plano antes da execução do comando. Permite que o túnel SSH rode como processo em background. Se omitido, a conexão SSH permanece em primeiro plano.
• -q: suprime a maioria das mensagens de aviso e diagnóstico.
• -C: solicita compressão de todos os dados (incluindo stdin, stdout, stderr e dados X11 e TCP encaminhados). Útil em links lentos.

Exemplo de configuração:

Para criar um proxy SOCKS escutando na porta local 8080, conectando a [email protected]:

ssh -D 8080 [email protected] -N -f

Após executar esse comando, o processo do cliente SSH roda em segundo plano, escutando em localhost:8080.

Configurando clientes para usar o proxy SOCKS

Com o proxy SOCKS por SSH ativo, as aplicações precisam ser configuradas para rotear seu tráfego por localhost:[LOCAL_PORT].

Navegadores

Firefox:

1. Abra as configurações do Firefox.
2. Busque por "proxy" ou vá até "Configurações de Rede" (normalmente about:preferences#general -> Configurações de Rede).
3. Selecione "Configuração manual de proxy".
4. No campo "Host SOCKS", informe localhost e a PORT (por exemplo, 8080).
5. Selecione "SOCKS v5".
6. Marque "Usar DNS do proxy ao usar SOCKS v5" para evitar vazamentos de DNS.
7. Clique em OK.

Chrome/Chromium:

O Chrome não tem configuração nativa de proxy SOCKS. Ele normalmente depende das configurações de proxy do sistema, ou exige flags de linha de comando ou extensões.

Usando flags de linha de comando (temporário):

google-chrome --proxy-server="socks5://localhost:8080" --host-resolver-rules="MAP * 0.0.0.0 , EXCLUDE localhost"

A flag --host-resolver-rules garante que as requisições DNS também sejam roteadas pelo proxy SOCKS5, evitando vazamentos de DNS.

Usando extensões de troca de proxy:
Instale uma extensão como "Proxy SwitchyOmega" e configure-a para usar um proxy SOCKS5 em localhost:[LOCAL_PORT].

Configurações de proxy de todo o sistema (macOS/Windows/ambientes desktop Linux)

Muitos sistemas operacionais permitem definir um proxy SOCKS para todo o sistema. Isso afeta a maioria das aplicações que respeitam as configurações de proxy do sistema.

• macOS: Ajustes do Sistema -> Rede -> selecione o serviço de rede -> Detalhes -> Proxies -> marque "Proxy SOCKS" -> informe localhost e a PORT.
• Windows: Configurações -> Rede e Internet -> Proxy -> configuração manual de proxy -> ative "Usar um servidor proxy" -> defina "proxy SOCKS" como localhost e a PORT.
• Linux (GNOME/KDE): normalmente em Rede ou nas configurações de proxy dentro das preferências do sistema, de forma semelhante a macOS/Windows.

Ferramentas de linha de comando

curl:

curl --socks5-hostname localhost:8080 http://example.com

Usar --socks5-hostname garante que a resolução DNS também ocorra via servidor proxy SOCKS, evitando possíveis vazamentos de DNS.

git:

Configure o Git para usar o proxy SOCKS em conexões HTTPS/HTTP ou SSH.

Para HTTPS/HTTP:

git config --global http.proxy socks5://localhost:8080
git config --global https.proxy socks5://localhost:8080

Para SSH (se o Git usar SSH para clone/push):
Edite ~/.ssh/config:

Host github.com
    ProxyCommand nc -X 5 -x localhost:8080 %h %p

Isso diz ao SSH para conectar a github.com via proxy SOCKS5 local.

proxychains-ng:

Para aplicações que não suportam proxies SOCKS diretamente, o proxychains-ng pode forçá-las a usar um.
1. Instale o proxychains-ng: normalmente disponível pelos gerenciadores de pacotes (por exemplo, sudo apt install proxychains4).
2. Configure: edite /etc/proxychains.conf ou ~/.proxychains/proxychains.conf (se criado) e acrescente:
socks5 127.0.0.1 8080
3. Execute a aplicação:
bash proxychains4 [your_application]

Casos de uso

Proxies SOCKS por SSH oferecem várias vantagens práticas:

• Contornar restrições de rede: acesse serviços ou sites bloqueados por firewalls locais ou restrições geográficas, roteando o tráfego por um servidor SSH em uma rede sem restrições.
• Criptografar tráfego não criptografado: todo o tráfego entre o cliente e o servidor SSH é criptografado, protegendo os dados contra escuta em redes locais, especialmente em Wi-Fi público.
• Acessar recursos de rede privada: se o servidor SSH está dentro de uma rede privada (por exemplo, uma LAN corporativa), o proxy SOCKS pode dar acesso seguro aos recursos dessa rede a partir de um local externo.
• Mascarar o endereço IP do cliente: para o servidor de destino, a conexão parece originar-se do IP do servidor SSH, oferecendo uma camada de anonimato ao cliente.
• Administração remota segura: acessar serviços remotos (por exemplo, bancos de dados, servidores web) por um túnel criptografado, mesmo quando os próprios serviços não suportam criptografia.

Túnel SSH vs. VPN

Embora túneis SSH e VPNs (Virtual Private Networks) forneçam acesso de rede criptografado, eles diferem em escopo e implementação.

Considerações de segurança

Usar um proxy SOCKS por SSH traz considerações de segurança específicas:

• Confiança no servidor SSH: o servidor SSH se torna um ponto crítico na cadeia de confiança. Todo o tráfego passa por ele, então o operador do servidor pode, teoricamente, inspecionar o tráfego não criptografado depois que ele deixa o túnel SSH, caso o serviço de destino não use TLS/SSL.
• Segurança do servidor SSH: o próprio servidor SSH precisa ser seguro. Isso inclui autenticação forte (chaves SSH em vez de senhas), manter o daemon SSH atualizado e aplicar regras de firewall adequadas. Um servidor SSH comprometido compromete a segurança do túnel.
• Exposição da porta local: a porta local do proxy SOCKS (LOCAL_PORT) normalmente fica vinculada a localhost (127.0.0.1), ou seja, só aplicações da máquina local podem se conectar a ela. Se 0.0.0.0 for usado (por exemplo, ssh -D 0.0.0.0:8080 ...), o proxy passa a ser acessível a outras máquinas da rede local, o que pode ser um risco de segurança se não for intencional.
• Vazamento de DNS: se o proxy SOCKS não estiver configurado corretamente (por exemplo, usando SOCKS4 ou sem ativar "Proxy DNS" no navegador), as requisições DNS podem ir direto ao servidor DNS padrão, revelando a atividade de navegação mesmo com o tráfego da aplicação tunelado. O SOCKS5 suporta resolução DNS remota; garanta que ela esteja em uso.

Considerações de desempenho

Impactos de desempenho ao usar um proxy SOCKS por SSH:

• Latência: cada conexão passa por um salto adicional pelo servidor SSH. Isso aumenta a latência, o que pode ser perceptível em aplicações sensíveis a latência.
• Largura de banda: a vazão máxima é limitada tanto pela banda da conexão do cliente ao servidor SSH quanto pela banda do servidor SSH até o destino final.
• Overhead de criptografia: a criptografia e a descriptografia SSH consomem CPU no cliente e no servidor, podendo reduzir a banda efetiva.
• TCP sobre TCP: ao tunelar tráfego TCP por uma conexão SSH que já é baseada em TCP, pode haver degradação de desempenho pelo fenômeno do "TCP meltdown". Isso ocorre quando a perda de pacotes na conexão TCP subjacente causa retransmissões, que são então retransmitidas de novo pela conexão TCP interna, levando a backoff exponencial e queda de vazão. Usar túneis baseados em UDP (como WireGuard) ou SSH sobre UDP (sshovudp) pode mitigar isso, mas não é o padrão para SOCKS via SSH.