Criando túneis seguros

Uma forma simples de encriptar protocolos que em condições normais não suportam encriptação é usar o SSH para criar túneis seguros, ligando uma das portas da sua máquina à porta do servidor onde o serviço em questão está ativo. Nesse caso, é criada uma espécie de VPN temporária, através da qual é possível acessar o serviço de forma segura. Todas as informações transmitidas são encriptadas pelo SSH, tornando seguros mesmo protocolos “escancarados”, como o Telnet e o FTP. Um dos usos mais comuns para este recurso é encriptar sessões do VNC, evitando que pessoas mal intencionadas tenham acesso ao que foi feito dentro da sessão, mesmo que ela seja interceptada.

O VNC utiliza uma chave de encriptação de mão única durante a autenticação, de forma que a senha não circula abertamente pela rede. Isso impede que alguém sniffando a rede consiga capturar sua senha do VNC, como acontece no caso do Telnet, por exemplo. Apesar disso, o algoritmo de encriptação de senha usado pelo VNC não é muito seguro e, depois que a conexão é iniciada, os dados são enviados de forma não-encriptada, abrindo a possibilidade de que alguém capaz de capturar os pacotes transmitidos possa ver o que você está fazendo e até mesmo capturar as teclas digitadas no teclado.

Se você utiliza o VNC para tarefas sensíveis, como administrar servidores, acessar sistemas bancários, etc., pode implantar uma camada extra de segurança, utilizando o VNC em conjunto com o SSH. Nesse caso, a segurança é quase total, pois além de ser necessária uma dupla autenticação (primeiro no SSH e depois no VNC), todos os dados são transmitidos através da rede de forma encriptada, utilizando um algoritmo reconhecidamente seguro.

Para utilizar o SSH em conjunto com o VNC, utilizamos a opção “-L”, que permite redirecionar uma determinada porta local para uma porta no servidor, criando o túnel. A sintaxe do SSH, neste caso, seria “ssh -L porta_local:servidor:porta_do_servidor servidor”. Parece complicado, mas vai melhorar… 🙂

O servidor VNC escuta na porta 5900 + o número do display (5901, 5902, 5903, etc.). Note que a porta é diferente do servidor Java, acessível utilizando o browser, que utiliza as portas de 5800 em diante.

Se você vai acessar o display 1 (porta 5901), na máquina 220.132.54.78, precisamos orientar o SSH a redirecionar esta porta para uma porta acessível pelo cliente VNC (a própria porta 5901, ou qualquer outra) no PC local. Para isso, é necessário que o servidor SSH esteja aberto no servidor remoto e que você tenha uma conta nele. O comando seria:

Substitua o “login” pela sua conta de usuário na máquina remota. O SSH pedirá a senha (ou passphrase) e, pronto, o túnel estará criado.

Tudo o que você precisa fazer agora é abrir o cliente VNC e acessar o endereço “127.0.0.1:1”. Isso fará com que o cliente acesse a porta 5901 na máquina local, que por sua vez será redirecionada (através do túnel) para a porta 5901 do servidor remoto. Você usará o VNC da mesma forma, mas desta vez usando um túnel seguro.

Se por acaso a porta 5901 local já estiver em uso, você pode simplesmente criar o túnel apontando para outra porta da sua máquina. Se você fosse acessar o display 4 (porta 5904) no servidor 192.168.0.4, redirecionando-o para a porta 5905 (display 5) da máquina local, logando-se usando o usuário “tux”, o comando seria:

Nesse caso, você acessaria o endereço “127.0.0.1:5” no cliente VNC, que faz com que ele se conecte na porta 5905.

A desvantagem de utilizar o SSH em vez de acessar o servidor VNC diretamente é que a atualização de tela ficará um pouco mais lenta, pois o servidor terá dois trabalhos, o de compactar os dados usando um dos algoritmos do VNC e, em seguida, encriptar os pacotes usando a chave do SSH, uma dupla jornada. Entretanto, se pensarmos do ponto de vista da segurança, a troca acaba sendo vantajosa.

Além do VNC, este comando pode ser usado para criar túneis para outras portas. Para redirecionar portas privilegiadas, da 1 a 1024, você precisa executar o comando como root. Para as portas altas (como as usadas pelo VNC), você pode usar um login normal de usuário.

O parâmetro “-f” dentro do comando faz com que ele seja executado em background, liberando o terminal depois que a conexão é estabelecida. O “-N” faz com que o SSH apenas crie o redirecionamento da porta, sem abrir um terminal do servidor remoto, enquanto o “-L” é a opção principal, que especifica que queremos fazer um redirecionamento de portas. Ele é seguido (sem espaços) pela porta local que receberá a porta remota, o endereço do servidor e a porta do servidor que será redirecionada (“-L2525:192.168.0.4:25” redireciona a porta 25 do servidor remoto para a porta 2525 da máquina local). Concluindo, o “-l” em seguida especifica o login que será usado para estabelecer a conexão, seguido pelo endereço IP do servidor.

Em resumo, a sintaxe deste longo comando é “ssh -f -N -Lporta-local:servidor:porta-do-servidor -l login servidor” (veja que é necessário especificar o endereço do servidor remoto duas vezes).

Seja qual for a porta destino, todo o tráfego é transportado através da porta do SSH e encaminhada localmente para a porta final. Graças a essa peculiaridade, os túneis são uma forma muito usada para acessar ferramentas como o Webmin, phpMyAdmin ou Swat em servidores remotos, sem precisar manter as respectivas portas abertas para toda a Internet. Basta que a porta 22 (ou outra em que o servidor SSH esteja escutando) esteja aberta para que você consiga acessar qualquer outra usando túneis. Em casos em que o servidor remoto esteja configurado para usar uma porta diferente da padrão para o SSH, adicione a opção “-p porta” no início do comando, como em:

Continuando, um segundo exemplo interessante de uso seria usar um túnel para encriptar todo o tráfego web, de forma que você possa navegar de forma segura, ler seus e-mails, etc. mesmo ao acessar através de uma conexão wireless sem qualquer tipo de encriptação.

Para isso, é preciso que o gateway da rede (ou alguma máquina na Internet, que seja acessível por você) esteja com um servidor proxy aberto (se você estiver usando o Squid, por exemplo, o proxy ficará aberto na porta 3128 do servidor). Podemos usar então o SSH para criar um túnel, ligando a porta 3128 do servidor à porta 3128 (ou qualquer outra) do seu micro, como em:

O próximo passo é configurar o navegador na sua máquina para acessar usando o proxy. Entretanto, em vez de configurar o navegador para acessar o proxy diretamente, vamos configurá-lo para procurar o proxy na porta 3128 do localhost. Isso faz com que todos os acessos sejam direcionados ao túnel criado através do SSH e cheguem até o proxy de forma encriptada:

Para ser usado dessa forma, o proxy rodando no servidor remoto deve ser configurado para aceitar conexões de qualquer cliente, já que mesmo passando pelo túnel, o acesso será computado pelo Squid como partindo do seu IP de Internet atual. Um exemplo de configuração do Squid para que o servidor permitisse a conexão de qualquer cliente remoto seria:

Como você pode ver, essa configuração simplesmente permite acessos provenientes de qualquer endereço. O truque é que como o servidor será acessado através dos túneis criados usando o SSH, você pode manter a porta 3128 fechada no firewall do servidor, permitindo apenas conexões através da porta 22. Com isso, o servidor não ficará vulnerável, já que a única forma de chegar até o proxy é criando um túnel até ele através do SSH.