Túneis Aninhados com o SSH para Disfarce de IP

Hoje vou mostrar como usar o SSH para criar túneis criptografados aninhados (um dentro do outro), técnica também conhecida como "Roteamento Cebola" ("Onion Routing"), a mesma usada pelo célebre utilitário Tor. A abordagem que usaremos aqui tem a vantagem de evitar algumas fraquezas no esquema de túneis encadeados que discuti no post anterior.

No post anterior, eu usei dois intermediários. Hoje vou usar três, que, como vou discutir, é talvez o melhor número. Mas preste atenção, porque o negócio é meio confuso à primeira vista. Como das vezes anteriores, estou assumindo que você já tem boa familiaridade com o uso do SSH, inclusive com o recurso de criação de "port forwards" (apelidados de "túneis") com a opção -L.

A Receita

Em uma janela ou terminal, entrei com o seguinte comando:

ssh -L 22222:halfway.tempest.com.br:22 [email protected]

A máquina frown.postcogito.org vai ser o nosso primeiro intermediário; no jargão de roteamento cebola, ele se chama o "nó de entrada". Esse comando não apenas se conecta na máquina frown, mas também engatilha um túnel para a máquina halfway.tempest.com.br, quer será nosso segundo intermediário ou "nó central".

Note que o túnel para halfway começa na porta 22222 da nossa própria máquina.

Após minimizar essa janela, abri uma segunda janela e nela executei o seguinte comando:

ssh -p 22222 -L 22223:cactuscooler.dreamhost.com:22 [email protected]

Esse comando aciona o túnel para a máquina halfway que havíamos previamente deixado preparado. Como vimos acima, esse túnel começa na porta 22222 da nossa própria máquina. Então, o que estamos na realidade fazendo é nos conectando em halfway – por isso que passamos o nome de login com o qual estamos cadastrados em lá em halfway; e se, você estiver usando autenticação por senha clássica (o que?!?!? você ainda usa esse negócio antiquado?!) ao invés de por chave pública, você deverá digitar a senha da sua conta em halfway.

Paralelamente, preparamos um outro túnel, novamente começando na nossa própria máquina, só que dessa vez na porta 22223 (uma vez que a 22222 já está em uso) e indo parar no nosso terceiro e último intermediário, a máquina cactuscooler.dreamhost.com, chamada "nó de saída", porque é a partir dela que nossos dados vão sair para o site de destino; é o endereço dela que vai aparecer nos logs dos sites que visitarmos.

Minimizei a janela com o comando acima e abri uma terceira janela para executar o seguinte comando:

ssh -p 22223 -D 9050 [email protected] -C

Com isso, conectamos à ponta do túnel para cactuscooler, que começa na nossa própria máquina (localhost) na porta 22223. Paralelamente, armamos o proxy SOCKS do SSH para ouvir na porta 9050. (Lembre-se, é a mesma porta usada pelo Tor; então, se você já tem um Tor instalado, desative-o ou use outro número de porta).

A opção -C é para ativar a compressão automática, que, em geral, tende a melhorar ligeiramente a performance. Funciona também sem ela, mas talvez um pouco mais lenta.

Finalmente, fui nas configurações de rede e conexões do meu navegador e ativei o uso de um proxy tipo SOCKs, na porta 9050. Com isso feito, pude navegar normalmente.

Características

A estrutura das linhas de comando do SSH faz esse esquema parecer mais complicado do que realmente é. Analisando com atenção, porém, algumas características ficam claras:

  • O nó de entrada (o primeiro intermediário) sabe nosso IP de origem – afinal, ele recebeu a conexão diretamente de nós –, mas não sabe qual nosso destino final, pois essa informação está enterrada no tráfego cifrado. Tudo que ele sabe é qual o próximo intermediário. Ele recebe nossos dados triplamente cifrados, "descasca" a camada de cifragem mais externa (criada pelo primeiro comando SSH) e repassa os dados para o próximo intermediário.
  • O nó central (o segundo intermediário) é o "cego" da história: ele não sabe nem nosso IP de origem, nem quais nossos destinos. Tudo que ele sabe são os IPs do intermediário anterior e do próximo. Ele recebe nossos dados duplamente cifrados, "descasca" outra camada de cifragem e repassa para o próximo intermediário.
  • O nó de saída (o terceiro intermediário) descasca a última camada de cifragem e tem acesso aos nossos dados, repassando-os para o site de destino. Ele sabe para onde vamos, mas não de onde viemos; ele só sabe o IP do intermediário anterior.

Contraste isso com o esquema descrito no post anterior: lá, cada intermediário tinha acesso aos nossos dados decifrados – se não pudéssemos garantir que os intermediários não estavam registrando nossas atividades, nossa segurança contra rastreabilidade iria por água abaixo. Aqui, nosso tráfego vai totalmente cifrado até o nó de saída (ou, se usarmos HTTPS, até o destino), negando aos intermediários saber ao certo o que estamos fazendo, de onde viemos e pra onde vamos. Tudo que eles sabem é o IP do intermediário anterior e do próximo.

Lembre-se que o que aparecer nos logs dos sites que visitarmos usando esse esquema é o endereço IP do nó de saída. Se ele já for em um país/jurisdição diferente dos sites-destino, um eventual investigador que estiver tentando nos rastrear vai enfrentar, logo de cara, uma tremenda burocracia para tentar intimar o intermediário a revelar de onde viemos. Supondo que consiga, tudo que o conseguirá descobrir é quais sites visitamos (o que, se não formos cuidadosos, pode nos denunciar) e o IP do intermediário anterior.

Se tivermos escolhido cada intermediário em um país/jurisdição diferente, multiplicaremos o trabalho do investigador: ele terá de passar por esse mesmo calvário outras duas vezes se quiser descobrir nosso endereço IP – e uma terceira vez para intimar nosso provedor de acesso a revelar nosso cadastro baseado no nosso IP e data/hora de acesso. Não é impossível, é claro, mas é uma canseira considerável, capaz de desencorajar até adversários consideravelmente poderosos e persistentes.

Quanto mais intermediários pusermos, maior essa canseira, mas também tão mais lenta a nossa navegação – o zigzag que fazemos com os dados através da Internet aumentam muito a latência, essencial para a velocidade percebida da navegação interativa via HTTP. Para fazer downloads ou uploads grandes, porém, não afeta muito (desde que, naturalmente, nenhum dos intermediários, nem a origem, nem o destino, estejam com os links saturados) porque o TCP lida bem latências altas. Não obstante, isso tudo é um argumento para mantermos o número de intermediários no mínimo.

A razão pela qual se considera três um número bom de intermediários é que a latência fica ainda dentro tolerável, ao mesmo tempo que dilui o risco de rastreamento caso algum intermediário esteja consipirando para monitorar e correlacionar nossas origens e destinos. É mais difícil três operadores conspirarem do que dois. Além disso, três é o mínimo número de intermediários para se ter o "nó central" que não sabe nem de onde viemos nem para onde vamos.

Tor vs SSH

O leitor bem informado talvez tenha percebido que esse esquema que descrevi se assemelha bastante com o funcionamento do Tor. De fato, pode-se dizer que implementamos, usando o SSH, parte do "roteamento cebola" do Tor.

A diferença é que o Tor tem uma rede de uns dois mil voluntários mais ou menos fixos que atuam como intermediários e a cada dez minutos ele estabelece um novo "circuito" de três intermediários, sorteados aleatoriamente entre os dois mil, com o cuidado de tentar escolhê-los para que os três sejam de países diferentes e, de preferência, diferentes também do país de destino. Assim, se seus acessos a um determinado site-destino levarem mais do que dez minutos, você aparecerá nos logs deles como vindo de dois ou mais endereços diferentes; um investigador que estiver te rastreando vai ter ainda mais trabalho pra juntar as peças do quebra-cabeça.

O pacote do Tor também vem com várias outros adendos interessantes: por exemplo, ele vem com um proxy-cache chamado Polipo (uma espécie de mini-Squid, para os acostumados com o Unix; ou um mini-ISA, para os Windowscêntricos), que alivia os problemas oriundos da latência alta.

No Firefox, há um plugin chamado TorButton que transforma em um único clique de mouse o processo de ativar ou desativar o Tor – livrando você de ficar mexendo manualmente naquelas mil janelas até se chegar às configurações de Proxy. Além disso, ele implementa um monte de precauções essenciais para manter a anonimidade: desabilita cookies, plugins e JavaScript, lembra que abas você acessou com o Tor e sem o Tor, bem como adota várias salvaguardas contra vários truques que os criadores dos sites podem usar para te rastrear.

Outro benefício de se usar o Tor é o conceito de "esconder-se na multidão": como muita gente o usa o tempo todo, nossos acessos ficam misturados e diluídos por dentre os dos outros usuários, dificultando mais ainda o trabalho de um investigador.

Se o Tor faz isso tudo, então qual a vantagem de usarmos um sistema baseado em SSH como esse que eu descrevi aqui? Algumas idéias:

  • Podemos combinar as ferramentas auxiliares do Tor – o TorButton e o Polipo – com os SSHs. Venho fazendo isso há anos e, na minha experiência, a navegação fica substancialmente mais rápida do que com o Tor. Para aplicações onde você não está tão preocupado assim em ser rastreado – por exemplo, para circunavegar um proxy ou firewall sem ter de mudar suas regras de bloqueio, ou pra ver como um site muda de aparência e/ou comportamento dependendo do país ou região de onde é acessado, esse esquema pode ser muito mais do que suficiente;
  • Até quando sua preocupação é mesmo não ser rastreável, há um certo conforto psicológico no fato de alguns dos (ou até mesmo todos os) intermediários estarem sob nosso controle.
  • Podemos combinar os vários métodos de anonimização: podemos usar esse esquema dos SSHs com o lance do sufixo .nyud.net (descrito no segundo artigo desta série).

Nessa linha de combinar os mecanismos, vou mostrar no próximo post como podemos usar o SSH e o Tor em conjunto para reforçar a anonimidade com um grau maior de "negabilidade plausível"; e também vou mostrar que esse esquema combinado pode aplacar a vulnerabilidade a correlação de volume de tráfego, que é uma das poucas coisas que o Tor não trata muito bem.

Partes anteriores

Próxima parte

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.
Carlos Henrique | 2010-11-23 16:18:40 | permalink | topo

Kiko,

Tentei reproduzir os procedimentos acima, e funcionou beleza!

Abraços,

Carlos Henrique