Criando túneis seguros com SSH

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:

$ ssh -f -N -L5901:220.132.54.78:5901 -l login 220.132.54.78

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:

$ ssh -f -N -L5905:192.168.0.4:5904 -l tux 192.168.0.4

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:

# ssh -p 2222 -f -N -L901:gdhn.com.br:901 -l login gdhn.com.br

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:

$ ssh -f -N -L3128:gdhn.com.br:3128 -l tux gdhn.com.br

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:

http_port 3128
visible_hostname gdh
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1
acl SSL_ports port 443 563
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow all

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.

SSH no Windows

Existem diversas versões do SSH. A maioria das distribuições Linux inclui o OpenSSH, que não possui um cliente para Windows. No entanto, isso não chega a ser um problema, pois o SSH é um protocolo aberto, o que permite o desenvolvimento de clientes para várias plataformas, inclusive Windows. Eles são usados por muita gente para administrar servidores Linux remotamente.

Um exemplo de cliente simples e gratuito é o PuTTY, que inclui também o PSFTP, um cliente de SFTP, que permite também transferir arquivos usando os comandos de transferência que já vimos (put, get, cd, lcd, pwd, lpwd, etc.). Ambos podem ser baixados no: http://www.putty.nl/

Usar o PuTTY para se conectar a servidores Linux é bem simples, pois ele não precisa sequer ser instalado. Basta baixar o arquivo e executá-lo:

O PuTTY também permite criar túneis encriptados. Para isso, comece colocando o IP ou o domínio do servidor a que vai se conectar no campo "Host Name (or IP address)" na tela principal, como se estivesse abrindo uma conexão normal, mas, ao invés de clicar no "open", acesse a opção "Connection > SSH > Tunels".

Na opção "source port" vai a porta do seu micro que receberá o túnel (3128, por exemplo) e no "Destination" vai o endereço IP ou domínio do servidor remoto a que você está se conectando, seguido da porta, como em "meuservidor.com.br:3128". Clique no "Add" (você pode adicionar várias portas) e em seguida no "Open", para abrir a conexão.

Outro exemplo de cliente SSH para Windows é a versão da SSH Security, que possui vários recursos mas é gratuita apenas para universidades e usuários domésticos e é por isso bem menos usada. O link é: http://www.ssh.com

O PuTTY e o SSH da SSH Security são inteiramente compatíveis com o OpenSSH. A grande limitação é que esses dois clientes são limitados ao modo texto, pois para exibir aplicativos gráficos via SSH, é necessário que o sistema cliente possua um servidor X, coisa que o Windows não possui nativamente. Ao tentar abrir qualquer aplicativo gráfico, você recebe a fatídica mensagem "cannot connect to X server". Também não existem servidores SSH "de verdade" para Windows, que permitam administrar um servidor Windows remotamente. As soluções de servidores SSH para Windows se concentram nos recursos de encriptação para transferências de arquivos e criação de túneis.

Voltando ao tema principal, existem alguns servidores X para Windows, que abrem uma sessão do X dentro de uma janela, como o X-Win32 (http://xwin32.dk) e o WinaXe (http://labf.com), mas uma opção muito melhor é o Xming, um software gratuito e de código aberto, disponível no:
http://www.straightrunning.com/XmingNotes/.

Quando aberto, o Xming fica residente ao lado do relógio, esperando que algum aplicativo precise dele. Para usá-lo em conjunto com o PuTTY, marque (no PuTTY) a opção "Connection > SSH > X11 > Enable X11 forwarding" (sem colocar nada no campo "X display location"). Isso faz com que o PuTTY encaminhe todas as requisições gráficas para o Xming, permitindo que os aplicativos gráficos rodem normalmente, mesmo no Windows. Embora não seja uma solução muito elegante, realmente funciona:

O Xming resolve o problema do uso de aplicativos gráficos via SSH no Windows, mas ele ainda não é a solução ideal para muitas situações, já que exige uma certa dose de configuração e o uso é centralizado em torno do terminal. Se você está procurando uma solução mais prática e simples, a melhor opção é o Cliente NX, que (uma vez configurado o servidor) é muito mais simples de usar e oferece uma performance muito melhor que a obtida ao rodar aplicativos gráficos através do SSH "puro", graças às várias otimizações utilizadas. Veremos mais detalhes sobre ele logo a seguir.

Você pode baixar o cliente NX for Windows no http://nomachine.com. No site, você pode fazer um "testdrive", acessando um dos servidores da empresa. O NX trabalha sobre o SSH, implementando um conjunto de otimizações para reduzir o tráfego e a latência das conexões. O resultado é algo similar ao VNC, mas com um desempenho bem melhor. Ao contrário do PuTTY, no NX tudo é feito através de um cliente gráfico:

Na hora de transferir arquivos via SFTP, uma boa opção é o FileZilla, um cliente de FTP gráfico e bastante amigável, que inclui suporte ao SFTP. Você pode baixá-lo no:
http://filezilla.sourceforge.net/

Para conectar via SFTP, use a opção "File > Site Manager > New Site" para criar a conexão. Só assim você tem acesso à opção de usar o SFTP, já que os campos na tela principal servem apenas para servidores FTP:

Na tela seguinte, informe o IP do servidor, a porta (22) e a conta de acesso. Uma vez conectado, você acessa os arquivos usando a interface tradicional dos clientes de FTP, com as duas janelas, uma mostrando os arquivos locais e outra mostrando os do servidor. Para transferir arquivos, basta arrastá-los entre as duas.