Usando o SSH como Proxy para Disfarçar Endereços IP

O SSH é um programa utilitário muito conhecido entre os usuários avançados do Linux por permitir controlar remotamente o sistema. Mas ele tem um monte de outros recursos legais pouco apreciados porque pouca gente se dá ao trabalho de dissecar sua documentação. Hoje vou mostrar como usar seus recursos de encaminhamento de tráfego em conjunto com o suporte a proxies que muitos navegadores têm para "disfarçar" nossos endereços IP.

Aviso aos leitores que preferem meus posts "para leigos": esse post de hoje é um tanto técnico. Aqui vou assumir que você já tem o OpenSSH instalado (vem em toda distro Linux e no Windows ele vem no pacote Cygwin) e que você já tem alguma experiência no seu uso – em particular, que você sabe usá-lo com autenticação nome+senha ou por chave pública. Se você já tiver usado o recurso de encaminhamento de portas ("port forwarding", opções -L e -R), tanto melhor, mas acho que você conseguirá acompanhar a explicação mesmo sem isso.

Relembremos alguns pontos que vimos nos episódios anteriores desta série: se conectarmos diretamente a um site, o programa que recebe e atende nossas conexões tem acesso ao nosso endereço IP de origem e poderá registrá-lo em um histórico chamado "log" que poderá vir a ser usado para nos rastrear. O que precisamos fazer então é usar um terceiro computador como "intermediário" ou "laranja": nós conectamos nele e ele é que repassa nossos dados para o site-destino. Assim, do ponto de vista do site-destino, a conexão parece ter se originado no "laranja".

Suponha que você tem acesso via SSH a um computador e quer usá-lo como "laranja". No meu caso, o meu "laranja" é o computador cactuscooler.dreamhost.com. Eu normalmente me conecto via SSH nele usando o comando:

ssh -D 9050 [email protected]

A opção "-D 9050" ativa um recurso de criar um proxy SOCKS na porta cujo número você especifica. A partir daí, tudo que você precisa fazer é especificar, nas configurações do seu navegador, que deseja usar um proxy SOCKS na porta 9050.

Alguns leitores atentos podem notar que a porta 9050 é usada pelo Tor, um outro programa (muito bom) de anonimização sobre o qual vou falar longamente em um artigo posterior dessa série. Essa "coincidência" é, na realidade, proposital – vai facilitar algumas coisas ligeiramente. Por outro lado, se você já tem o Tor instalado e rodando, desative-o, senão vai conflitar com o nosso esquema aqui.

No meu firefox, isso é feito no menu principal, opção "Editar | Preferências" ("Edit | Preferences"), categoria "Avançado" ("Advanced"), aba "Rede" ("Network"), item "Conexão" ("Connection"), botão "Configurações..." ("Settings..."). Ao chegar lá, vai aparecer outra caixa de diálogo onde você deve marcar "Configuração Manual" ("Manual Proxy Configuration") e na caixa SOCKS Host, deve digitar "127.0.0.1" e na caixa ao lado o número da porta "9050". Se você usa outro navegador, tenho certeza que saberá achar as configurações de proxy nele.

O que realmente você fez? Reconfigurando o navegador dessa forma, você o instruiu a direcionar os acessos dele através de algum programa que estiver ouvindo na porta 9050 e usando o protocolo SOCKS – exatamente o SSH que você engatilhou no primeiro passo. Assim, ao navegar pelos sites, o navegador vai repassar seus dados para o seu cliente SSH, que, por sua vez, vai repassá-los para o servidor SSH rodando no computador remoto (no meu caso, o cactuscooler.dreamhost.com) e este, por sua vez, vai enviá-lo para o site de destino. Do ponto de vista do site de destino, a conexão vai parecer ter se originado na máquina cactuscooler e será o endereço dela que ficará armazenado no log.

Para conferir, eu fiz a seguinte experência: montei esse circo todo, acessei o site do Blog e o que apareceu no log do servidor web do Blog foi o seguinte (por brevidade, coloquei só o primeiro hit):

2010-10-27 10:41:14 208.113.180.8 200 10580 blog.tempest.com.br:80
Mozilla/5.0_(X11;_U;_Linux_i686;_en-US;_rv:1.9.2.11)_Gecko/
 20101013_Ubuntu/9.10_(karmic)_Firefox/3.6.11
none /index.html.gz

Note que o endereço IP 208.113.180.8 é mesmo da máquina cactuscooler.dreamhost.com (você pode verificar isso trivialmente com o nslookup, host ou dig).

Note, porém, que o USER_AGENT, que identifica o meu navegador, claramente mostrou tratar-se de um Firefox 3.6.11 rodando sob Linux. Isso acontece porque a opção -D do SSH implementa um proxy SOCKS TCP genérico – ele não interpreta nem entende, tampouco altera, os cabeçalhos do protocolo HTTP. O mesmo ocorre com os cookies, de sorte que, se você não tiver sido previdente em configurar seu navegador para rejeitar cookies daquele site, você pode acabar se traindo.

Contraste isso com o exemplo que vimos no post anterior, onde usamos a rede de proxies da CoralCDN – o Coral, sendo um proxy específico para HTTP, trocou o USER_AGENT, embora tenha aquela desvantagem quase fatal de revelar o IP de origem em um cabeçalho não-padrão.

Isso serve de prenúncio para uma "discussão filosófica" que teremos mais na frente: segurança contra rastreabilidade é muito mais do que apenas disfarçar o IP de origem – significa também desabilitar ou disfarçar cookies, web bugs e outras técnicas de correlação que os websites usam; significa usar pseudônimos e não fazer nada que lhe traia. Significa ser ligeiramente paranóico, meticuloso, paciente e evitar ser impulsivo – até fazer a coisa certa na hora errada pode fazer com que você se exponha.

Mas hoje nosso assunto é como forçar o tráfego a passar por um ou mais intermediários. Nessa linha, a primeira coisa a notar foi a minha escolha do intermediário: a máquina cactuscooler.dreamhost.com fica nos EUA, longe da jurisdição brasileira, e fica em um provedor de hospedagem baratíssimo, o DreamHost, onde você pode conseguir sua conta shell e muitas outras coisas legais por menos de USD 10/mês. A desvantagem é que você precisa usar seu cartão de crédito e se cadastrar, o que deixa um rastro periciável.

Melhor seria se a nossa máquina intermediária fosse em algum país relativamente obscuro e com legislações que dificultem o rastreamento e que a gente pudesse obter acesso sem ter de nos cadastrarmos. Como conseguir contas nessas máquinas eu vou deixar como exercício para o leitor, muito embora não seja nada que uma hora de buscas no Google não resolvam.

Outro aspecto interessante para se analisar é a disposição e característica das conexões TCP usadas nessa solução e sua propensão a interceptação. Simplificadamente, há em cada momento três conexões TCP em efeito:

  • A conexão do navegador para o cliente SSH: não é cifrada, mas começa e termina no nosso próprio computador, de sorte que não está vulnerável a um interceptador posicionado fora dele.
  • A 'conexão' que vai do nosso computador até a máquina intermediária: mas vai cifrada por dentro do túnel SSH – se usarmos o SSH corretamente, evitando o ataque 'man-in-the-middle' criptográfico (uma das únicas 'vulnerabilidades' do SSH), um interceptador não poderá ver o que estamos fazendo.
  • A terceira conexão se origina na máquina intermediária (a cactuscooler no meu exemplo) e vai parar no site de destino. Se o site destino usar HTTP, essa conexão não será cifrada e se um interceptador a estiver espiando, saberá o que estamos fazendo, embora não necessariamente nosso IP de origem. Todavia, se o site destino empregar HTTPS, a conexão será cifrada e o interceptador vai ter de ralar.

Contraste isso com o exemplo do episódio anterior, onde só tinhamos duas conexões: uma partindo da nossa máquina para o intermediário da Coral e outra da Coral para o site de destino. Nesse caso, o um interceptador bem posicionado poderia nos rastrear.

Novamente aquela lição: disfarçar o IP só evita sermos rastreados contra quem tiver acesso aos logs do site de destino. Se mudarmos nosso modelo de ameaça e assumirmos que temos interceptadores na rede (o que os provedores de acesso podem fazer e de fato fazem rotineiramente), vemos que o disfarce do IP é insuficiente – precisamos usar criptografia para blindar a maior quantidade possível dos caminhos entre nós e os intermediários.

Usando Mais de Um Intermediário

Imagine agora que eu quero usar, além do cactuscooler, um outro intermediário que eu tenho chamado frown.postcogito.org. Eu procederia da seguinte maneira – na minha máquina, eu executaria:

ssh -L 9050:127.0.0.1:9050 [email protected]

Ao chegar lá, usando o próprio shell que o SSH me disponibiliza, eu faria:

ssh -D 9050 [email protected]

O navegador ficaria configurado exatamente da mesma forma que no exemplo anterior.

Aqui temos, simplificadamente, cinco conexões TCP: (1) a entre o navegador e o cliente SSH, sem ser cifrada, mas que é totalmente contida na máquina de origem. Depois, (2) a conexão cifrada do SSH que cria o túnel até a máquina frown, a primeira intermediária. Em seguida, (3) uma conexão do servidor SSH de frown para o cliente SSH, também em frown, que eu rodei via linha de comando; essa conexão não é cifrada. Adiante, (4) temos a conexão SSH que cria o túnel cifrado de frown até cactuscooler. E de lá, (5) temos a conexão de cactuscooler, o segundo intermediário, para o site final. Esta última conexão não é cifrada se você usar HTTP, mas será cifrada se o site-destino aceitar HTTPS.

(Aviso aos pedantes de plantão: tenho plena consciência que entre o navegador e o SSH e em vários outros pontos pode haver não uma, mas várias conexões TCP, tanto porque o navegador pode originar várias conexões simultaneamente, quando pelo fato que as conexões abrem e fecham várias vezes ao longo do tempo. Chamei isso tudo de 'uma conexão só' apenas pra simplificar e ficar mais didático, pois não interfere com a essência da discussão.)

Esse esquema pode ser facilmente generalizado para quantos intermediários se quiser: os primeiros usam o -L 9050:127.0.0.1:9050 e o último usa o -D 9050.

Qual é o benefício de se usar mais de um intermediário? Diluição de risco: se alguém apreender a máquina cactuscooler e conseguir extrair dela ou de seu entorno alguma informação sobre a origem da conexão, chegará apenas até frown – vão ter de repetir todo o processo com ela. Se frown e cactuscooler estiverm em jurisdições diferentes, isso dificulta ou sobremaneira, ou quem sabe até inviabiliza, o trabalho investigativo.

Claro que há também desvantagens em se usar mais de um intermediário: primeiro, para obter e manter contas e permissões de acesso neles. Segundo, o tráfego entre você e o site de destino vai fazer um caminho mais longo, aumentando muito a latência (o tempo entre o dado sair do seu navegador e chegar no site). Como o protocolo HTTP é tipo "pare (após perguntar) e espere (pela resposta)", ele é dominado pela latência, o que fará a navegação do site ficar cada vez mais lenta a cada novo intermediário que você introduzir no processo.

Qual o número ideal de intermediários? Do ponto de vista da latência, a resposta é: "o menor possível". Zero intermediários – conectar diretamente – está fora de questão porque denuncia nosso IP. Se um ou dois intermediários te dá conforto suficiente em termos de proteção jurídica e em relação ao que você quer se defender (seu "modelo de ameaça"), vá fundo. Mas veremos nos episódios seguintes que, sob certos modelos de ameaça, há razões para usarmos pelo menos três intermediários.

Essa maneira de encadear os SSHs é chamada de "esquema dos túneis encadeados" e ela tem uma vulnerabilidade sutil: as conexões não-cifradas que, em cada intermediário, fazem a ponte entre o final do túnel no servidor SSH e o começo do próximo túnel no próximo SSH da cadeia – a conexão (3) na figura acima. Se o administrador de alguma das máquinas intermediárias não for você mesmo – o que geralmente não é o caso quando se usa máquinas de provedores de hospedagem –, fica difícil garantir que não haja nesse ponto uma armadilha que lhe monitore e lhe traia. No próximo post, vou mostrar como uma ligeira alteração no nosso esquema pode oferecer uma proteção melhor quanto a esse problema.

Partes anteriores

Próximas partes

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Tímido Visitante Anônimo | 2011-06-30 13:59:42 | permalink | topo

Ótimo artigo !

Uma outra boa abordagem é juntar TOR a sua mistura, o tráfego passando por 3 sevidores SSH caindo na rede TOR, dará um trabalho e tanto para rastrear !

O trecho "Aviso aos pedantes de plantão...." seria completamente dispensável se a internet não fosse um porão de vermes que visam detalhes inúteis.

Carlos Henrique | 2010-11-23 16:16:19 | permalink | topo

Kiko,

Muito legal o post! Testei os procedimentos que você descreveu, e funcionou perfeitamente!

Abraços,

Carlos Henrique

Tobias | 2010-11-01 21:44:52 | permalink | topo

Marco, devo ter me expressado mal. Quis dizer que testei a conexao para dois hosts diferentes, para verificar se o problema nao seria no destino.

Utilizei o comando: ssh -D 9050 [email protected] Configurei o proxy, via firefox e painel do gnome (separadamente) mas nao obtive sucesso, a pagina fica em branco.

Marco Carnut | 2010-11-01 21:31:24 | permalink | topo

Tobias,

O que eu acho mais provável é que você tenha dado os dois SSHs partindo da sua máquina. Na realidade, o primeiro parte da sua máquina e o segundo parte do primeiro intermediário. Tente novamente e me diga se deu certo!

-K.

Tobias | 2010-11-01 03:48:56 | permalink | topo

Não obtive exito realizando o procedimento descrito. No firefox o carregamento da pagina se completa sem que seja obtido nenhuma informação do destino. Utilizei dois servidores ssh, em maquinas diferentes.

Erik | 2010-10-28 16:11:35 | permalink | topo

Essa semana utilizei uma solução parecida com essa apresentada por vcs! show de bola !

Tinha um FW freebsd com 2 interfaces, onde precisava acessar uma rede 192.168.0.0/24. O acesso era feito via nat sem problemas de uma rede 10.X.0.0/20. O problema que tinha que fazer o acesso de outra rede 10.Y.0.0/20, que tinha rota para a rede 10.X. Até ai sem problemas se vc tivesse acesso a tudo, mas como era apenas para algo rápido fim um redirecionamento via ssh, que ficou show! Não precisei utilizar o ipfw fwd, nem natd redirect, nem proxy reverso ... bastou criar uma chave DSA sem senha, e fazer um script de 3 linhas para levantar 2 tuneis automaticamente rodando em bg e pronto! ssh rlz!!!