Deseja acessar de forma segura o seu banco de dados e sem precisar abrir porta no firewall? Túnel. Acessar a porta 25 fazendo relay sem mudar as configurações do Postfix? Túnel. Existem inúmeras vantagens do uso de um túnel, inclusive a implantação de uma VPN é feita utilizando-se um túnel. Este artigo destina-se a explicar como usar o recurso de tunelamento existente no próprio SSH.
Situações práticas onde um túnel SSH pode ser uma saída
Um túnel SSH pode ser muito útil em muitos casos, principalmente quando a necessidade não justifica sacar ferramentas mais sofisticadas de criação de túnel ou tampouco a criação de uma VPN.
Como ilustração, pode-se citar três cenários reais de uso, sendo que eu mesmo os uso com extrema frequência. Um deles todo o dia.
Primeiro cenário:
Este não é um cenário que eu uso, mas sim que um conhecido meu usa. Na rede dele tem um servidor de banco de dados MYSQL. Na verdade este serviço encontra-se em execução na mesma máquina onde se encontra o serviço de HTTP e de SSH. A porta na qual o serviço MYSQL escuta é a 3306/TCP.
Evidente que por questões óbvias de segurança, o firewall iptables deste servidor HTTP/SSH/MYSQL não aceita conexões na porta 3306, até porque, como mencionado, apenas a própria máquina usa o banco de dados.
Frequentemente, porém, se desenvolve aplicações em casa, ou em outro lugar que não fisicamente no servidor, e estas aplicações precisam, mesmo que por teste, acessar o banco de dados do servidor.
O que se pode fazer?
Uma saída seria liberar temporariamente a porta 3306 para o máquina cliente quando estiver fazendo testes, mas isto traz sérios problemas de segurança, além de ser não muito prático. Abrir uma VPN com o servidor nem sempre se justifica, pois só se quer realmente acessar o MYSQL por tempo limitado.
Então, pode-se tranquilamente sacar o ssh em seu modo túnel apontando-a para o servidor. Supondo que o IP do servidor seja 10.1.2.3, o seguinte comando executado no cliente resolve:
ssh -TL 33060:localhost:3306 usuario@10.1.0.1
Agora basta apontar as ferramentas locais que usam o BD para o servidor localhost na porta 33060 (se colocou um zero a mais, pois a máquina local poderia ter também o seu próprio BD).
Segundo cenário:
Na faculdade que administro os equipamentos de rede, como switches, tem ips privados. Assim não tem como chegar neles através da Internet. A partir dos consoles da sala de administração, existe rotas que permitem acessar, por exemplo, o switch 192.168.34.100, seja até mesmo por sua interface gráfica sobre HTTP.
Porém, algumas vezes, estou em minha casa e preciso realizar uma pequena manutenção em um dos switches. Novamente, poderia criar uma VPN, mas quero uma solução mais imediata. Então, saco novamente o ssh em modo túnel e digito na linha de comando:
Feito isto, apenas abro um navegador e acesso a URL http://localhost:8080. Como já demonstrado nas seções anteriores, todos os pacotes que entrarem na porta 8080 do meu notebook, sairão cifrados de minha máquina, viajando rumo a porta 22 do servidor IPdoMeuConsole, sendo que chegando lá, o ssh decifra os dados e os repassa ao IP 192.168.34.100 na porta 80, sem criptografia.
Terceiro cenário:
Este eu realmente uso todos os dias a anos. Meu notebook tem seu próprio servidor SMTP. Um Postfix instalado para realizar relay em um IP inexistente, algo como 10.2.3.4 que não existe em nenhuma das redes que conheço. Assim, meu servidor SMTP/Postfix ficaria sem poder repassar os emails. Digo ficaria, pois tenho alguns truques na manga.
O conforto de ter um servidor SMTP no meu próprio notebook é que posso eu mesmo criar meus aliases de emails ou mesmo listas. Uso isto diariamente para enviar as notas dos alunos, durante o período letivo. Posso gerar os emails mesmo sem acesso a Internet, pois eles ficam na fila de espera do Postfix.
Porém, quando tenho acesso a Internet, saco o par iptables + ssh para fazer a mágica acontecer. Uso como relay um servidor que gerencio, que é MX do meu domínio. Claro, ele não aceita relay, evidentemente, a menos que seja de um ip autorizado. Tipo, conexões vindas dele mesmo, localhost.
Então eu abro um túnel SSH para este meu servidor:
ssh -TL 2525:localhost:25 elgio@IpdoMeuServidor
Agora todo o pacote jogado na porta local 2525, viajará cifrado até meu servidor e lá será enviado a porta 25 de localhost. Haverá aceitação de relay, pois para o servidor Postfix do MeuServidor o acesso por feito por ela mesmo!
Feito este túnel, eu agora insiro uma regra iptables desviando o tráfego que tentar sair pela porta 25 para a 2525 local, ou seja, quando o Postfix do meu notebook tentar entregar os emails para o falso IP 10.2.3.4 na porta 25, o iptables o irá pegar e jogar na porta 2525 local, que é a entrada do túnel.
Uso tanto isto que até fiz um script que coloca tudo no ar até com uma telinha de status. Caso seja do interesse de alguns, deixo este script como anexo.
[6] Comentário enviado por andre.vmatos em 04/08/2009 - 18:23h
Muito bom, novamente, Elgio. Artigo explendido, simplesmente didaticamente perfeito. Continue assim, por favor, nos enriquecendo com seu conhecimento. Só uma dúvida. No título da página 5, vc quis dizer SSH ou SSL mesmo? É pq não encontrei menção ao protocolo SSL na página, e sim ao SSH, motivo do artigo. Abçss
Atenciosamente,
[8] Comentário enviado por rsscwb em 17/09/2009 - 14:13h
Elgio,
Parabéns por seus artigos, são Excelentes!!! Não apenas este, mas todos!
Agora estou utilizando este túnel para acessar o webmin no meu servidor. Eu bloqueei o acesso externo na porta 10000 pelo iptables e, cada vez que eu precisava acessar o webmin, tinha que rodar um script pelo ssh liberando a porta pro meu ip local atual (que é dinâmico).
Agora apenas crio o túnel na minha máquina local e pronto! Nem tenho o trabalho de digitar minha senha, pois configurei a autenticação por desafio e resposta, conforme vc explicou em outro artigo. Simples e fácil!
[9] Comentário enviado por ikichl em 23/09/2009 - 09:23h
Bom dia
estou com um grande problema aqui tenho um sistema em php que faz conexoes
automaticas atravez e chave de seguranca, instalada na maquina remota, porem cada
nova conexao ele pede a confirmacao antes e conectar a primeira vez:
Are you sure you want to continue connecting (yes/no)?
ja tentei diversos meio para auto aceitar a conexao, mas sempre sem sucesso
echo -e "yes" | ssh root@200.175.121.18
[11] Comentário enviado por removido em 04/10/2009 - 23:39h
Buenas tchê.
Estava afastado da TI e do VOL, ao retornar encontro este artigo muito bem escrito, com um assunto palpável e com exemplos que realmente funcionam. Estas de parabéns.
Sei que existem alguns de meus usuários, os mais espertos, tunelando conexões em uma porta bem conhecida que meu firewall necessita deixar passar mas, estou estudando as técnicas disponíveis e em busca de soluções.
[12] Comentário enviado por _m4n14c_2 em 20/10/2011 - 04:06h
Só lembrando, o própro ssh possui uma switch para passar os dados pelo gzip (-C). Como voce propos usar o tar seria mais vantajoso usar algoritmo bzip no lugar do gzip, bastar usar a switch j no lugar do z. Assim ganha-se um pouco de velocidade na transmissão dos dados, já que o bzip é mais eficiente que o gzip:
tar cj dados/ | ssh root@172.20.1.132 "tar xj && echo SUCESSO na cópia. SCP é para os fracos"
[14] Comentário enviado por jwolff em 18/12/2012 - 16:47h
Eu iria criar um Artigo com Script sobre Tunelamento por SSH para burlar firewall e squid. Mas você mostrou todos os pontos fracos neste Post e seria em vão meu Artigo.
O que me resta é lhe dar os Parabéns,você é muito bom!