Tune Lamento

Tunelamento
18 de abril de 2007
Sumário
I Sobre essa Apostila 2
II Informações Básicas 4
III Tunelamento 9
1 Tunelamento 10
2 Plano de ensino 11
2.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Publico Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Material de apoio 14
4 Introdução 15
4.1 O que é tunelamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Pra que serve tunelamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 O que vamo conhecer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Quando usar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Contornando Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6 Criptografando Conexões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7 Tunelamento Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.8 Acesso indireto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Instalando as ferramentas 20
5.1 Instalando o Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Instalando o OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Instalando o Corkscrew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4 Instalando o HTTPTunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF
6 Iniciação prática 23
6.1 Netcat - Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Netcat - Conectando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 Netcat - Servindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4 Netcat - Piruetas (opcional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4.1 Piruetas do Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4.2 Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.3 Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.4 Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.5 Caso 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.6 Caso 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.7 Caso 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.8 Caso 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.9 Opções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7 Iniciação prática - OpenSSH 32

7.1 OpenSSH - Conectando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.1 Autenticação do usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.2 Legitimação do servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 OpenSSH - Servindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.1 Porta de escuta e outras configurações . . . . . . . . . . . . . . . . . . . . . 34
8 Tunelamento - Netcat 36
8.1 Tunelando com o Netcat - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.4 Simulando um túnel com redirecionamentos Netcat (opcional) . . . . . . . . . . . . 38
8.4.1 Redirecionamentos Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9 Tunelamento - OpenSSH e algumas idéias 41

9.1 Tunelando com o OpenSSH - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.4.1 Múltiplos túneis com OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.4.2 Tunelando outros protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.4.3 Concatenado túneis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10 Tunelamento em HTTP 48
10.1 Corkscrew - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.2 Corkscrew - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.3 HTTPTunnel - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.4 HTTPTunnel - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11 Últimas notas 52
11.1 Tunelamento reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2
Parte I
Sobre essa Apostila
3
Conteúdo
O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na in-
ternet, disponíveis em diversos sites ou originalmente produzido no CDTC em http://www.cdtc.org.br.
O formato original deste material bem como sua atualização está disponível dentro da licença
GNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção de
mesmo nome, tendo inclusive uma versão traduzida (não oficial).
A revisão e alteração vem sendo realizada pelo CDTC (suporte@cdtc.org.br) desde outubro
de 2006. Críticas e sugestões construtivas são bem-vindas a qualquer tempo.
Autores
A autoria deste é de responsabilidade de Tomas Ribeiro Cardoso (tomas@cdtc.org.br).
O texto original faz parte do projeto Centro de Difusão de Tecnologia e Conhecimento, que
vem sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto com
outros parceiros institucionais, atuando em conjunto com as universidades federais brasileiras
que tem produzido e utilizado Software Livre, apoiando inclusive a comunidade Free Software
junto a outras entidades no país.
Informações adicionais podem ser obtidas através do email ouvidoria@cdtc.org.br, ou da

home page da entidade, através da URL http://www.cdtc.org.br.
Garantias
O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabi-
lidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizam
direta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br) .
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.1 or any later version published by
the Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOS-
TILA. A copy of the license is included in the section entitled GNU Free Documentation
License.
4
Parte II
Informações Básicas
5
Sobre o CDTC
Objetivo Geral
O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-

ção de soluções que utilizem padrões abertos e não proprietários de tecnologia, em proveito do
desenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira.
Objetivo Específico
Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário e

de código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre os
servidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercado
nacional a adotar novos modelos de negócio da tecnologia da informação e de novos negócios
de comunicação com base em software não-proprietário e de código fonte aberto, oferecendo
treinamento específico para técnicos, profissionais de suporte e funcionários públicos usuários,
criando grupos de funcionários públicos que irão treinar outros funcionários públicos e atuar como
incentivadores e defensores de produtos de software não proprietários e código fonte aberto, ofe-
recendo conteúdo técnico on-line para serviços de suporte, ferramentas para desenvolvimento de
produtos de software não proprietários e de seu código fonte livre, articulando redes de terceiros
(dentro e fora do governo) fornecedoras de educação, pesquisa, desenvolvimento e teste de pro-
dutos de software livre.
Guia do aluno
Neste guia, você terá reunidas uma série de informações importantes para que você comece
seu curso. São elas:
• Licenças para cópia de material disponível
• Os 10 mandamentos do aluno de Educação a Distância
• Como participar dos foruns e da wikipédia
• Primeiros passos
É muito importante que você entre em contato com TODAS estas informações, seguindo o
roteiro acima.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br).
6
É dada permissão para copiar, distribuir e/ou modificar este documento sob os termos
da Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior
públicada pela Free Software Foundation; com o Capitulo Invariante SOBRE ESSA
APOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-
mentação Livre GNU".
Os 10 mandamentos do aluno de educação online
• 1. Acesso à Internet: ter endereço eletrônico, um provedor e um equipamento adequado é

pré-requisito para a participação nos cursos a distância.
• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-

tica é necessário para poder executar as tarefas.
• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-

cia conta muitos pontos, pois irá colaborar para o processo ensino-aprendizagem pessoal,
dos colegas e dos professores.
• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seus

colegas de turma respeitando-os e fazendo ser respeitado pelo mesmo.
• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisão
e a sua recuperação de materiais.
• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações e
realizá-las em tempo real.
• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre.
• 8. Flexibilidade e adaptação: requisitos necessário à mudança tecnológica, aprendizagens

e descobertas.
• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente é

ponto - chave na comunicação pela Internet.
• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual não
controla a sua dedicação, mas reflete os resultados do seu esforço e da sua colaboração.
Como participar dos fóruns e Wikipédia
Você tem um problema e precisa de ajuda?
Podemos te ajudar de 2 formas:
A primeira é o uso dos fóruns de notícias e de dúvidas gerais que se distinguem pelo uso:
. O fórum de notícias tem por objetivo disponibilizar um meio de acesso rápido a informações
que sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a
7
todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação que
interesse ao grupo, favor postá-la aqui.
Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico do
curso. É recomendado que você faça uso do Forum de dúvidas gerais que lhe dá recursos mais
efetivos para esta prática.
. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativo
para solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadas
a todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podem
ajudar.
Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com a
formalização ou a gramática. Responda! E não se esqueça de que antes de abrir um novo tópico
é recomendável ver se a sua pergunta já foi feita por outro participante.
A segunda forma se dá pelas Wikis:
. Uma wiki é uma página web que pode ser editada colaborativamente, ou seja, qualquer par-
ticipante pode inserir, editar, apagar textos. As versões antigas vão sendo arquivadas e podem
ser recuperadas a qualquer momento que um dos participantes o desejar. Assim, ela oferece um
ótimo suporte a processos de aprendizagem colaborativa. A maior wiki na web é o site "Wikipé-
dia", uma experiência grandiosa de construção de uma enciclopédia de forma colaborativa, por
pessoas de todas as partes do mundo. Acesse-a em português pelos links:
• Página principal da Wiki - http://pt.wikipedia.org/wiki/
Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!
Primeiros Passos
Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:
• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;
• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar das
ferramentas básicas do mesmo;
• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;
• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.
Perfil do Tutor
Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.
O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivos

valores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita as
idéias dos estudantes, é paciente, pessoal, tolerante, apreciativo, compreensivo e pronto a ajudar.
8
A classificação por um tutor desta natureza proporciona o melhor feedback possível, é crucial, e,
para a maior parte dos alunos, constitui o ponto central do processo de aprendizagem.’ Este tutor
ou instrutor:
• fornece explicações claras acerca do que ele espera, e do estilo de classificação que irá
utilizar;
• gosta que lhe façam perguntas adicionais;
• identifica as nossas falhas, mas corrige-as amavelmente’, diz um estudante, ’e explica por-
que motivo a classificação foi ou não foi atribuída’;
• tece comentários completos e construtivos, mas de forma agradável (em contraste com um
reparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, de
ameaça e de nervossismo’)
• dá uma ajuda complementar para encorajar um estudante em dificuldade;
• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;
• ajuda o estudante a alcançar os seus objetivos;
• é flexível quando necessário;
• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,

talvez numa fase menos interessante para o tutor);
• escreve todas as correções de forma legível e com um nível de pormenorização adequado;
• acima de tudo, devolve os trabalhos rapidamente;
9
Parte III
Tunelamento
10
Capítulo 1
Tunelamento
O tunelamento é uma das ténicas, se quisermos assim, mais úteis das tecnologias de rede.
Uma técnica que muitos usam regular e diariamente sem saber que o fazem, mas certamente
aqueles que a conhecem solucionarão problemas e desafios de rede com mais elegância e matu-
ridade. O tunelamento, basicamente, é a técnica de encapsular conjuntos de dados que trafegam
em rede dentro de outro conjunto de dados, de forma que a rota que os primeiros iam tomar seja
conduzida para um lugar ou de uma maneira que sem o encapsulamento eles não poderiam fazer.
Existe tunelamento tanto de conexões TCP quanto de protocolos de baixo nível, e os softwares,
assim como as utilidades que um túnel pode ter, são diversos.
11
Capítulo 2
Plano de ensino
2.1 Objetivo
Qualificar usuários para o uso do HylaFAX.
2.2 Publico Alvo

Interessados em uma solução econômica e fácil para enviar e receber faxes.
2.3 Pré-requisitos
Os usuários deverão ser, necessariamente, indicados por empresas públicas e ter conheci-
mento básico acerca de programas de arquitetura cliente-servidor.
2.4 Descrição
O curso será realizado na modalidade Educação a Distância e utilizará a Plataforma Moodle
como ferramenta de aprendizagem. Ele é composto de um conjunto de lições e uma avaliação
que será dada no no final do curso. O material didático estará disponível on-line de acordo com
as datas pré-estabelecidas no calendário. A versão utilizada para o HylaFAX será a 4.3.0
2.5 Metodologia
O curso está dividido da seguinte maneira:
2.6 Cronograma
• Lição 1 - Introdução
• Lição 2 - Instalação e Configuração
• Lição 3 - Testando
12
• Lição 4 - Cliente
• Lição 5 - Detalhes
• Avaliação de Aprendizagem
• Avaliação de Curso
Todo o material está no formato de lições, e estará disponível ao longo do curso. As lições
poderá ser acessadas quantas vezes forem necessárias. Aconselhamos a leitura de "Ambienta-
ção do Moodle", para que você conheça o produto de Ensino a Distância, evitando dificuldades
advindas do "desconhecimento"sobre o mesmo.
Ao final de cada semana do curso será disponibilizada a prova referente ao módulo estudado
anteriormente que também conterão perguntas sobre os textos indicados. Utilize o material de
cada semana e os exemplos disponibilizados para se preparar para prova.
Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dvida deve ser
disponibilizada no fórum ou enviada por e-mail. Diariamente os monitores darão respostas e es-
clarecimentos.
2.7 Programa
O curso de Hylafax oferecerá o seguinte conteúdo:
• Introdução e Instalação
• Uso das ferramentas mais comuns.
2.8 Avaliação
Toda a avaliação será feita on-line.
Aspectos a serem considerados na avaliação:
• Iniciativa e autonomia no processo de aprendizagem e de produção de conhecimento;

• Capacidade de pesquisa e abordagem criativa na solução dos problemas apresentados.
Instrumentos de avaliação:
• Participação ativa nas atividades programadas.
• Avaliação ao final do curso.
• O participante fará várias avaliações referente ao contedo do curso. Para a aprovação e
obtenção do certificado o participante deverá obter nota final maior ou igual a 6.0 de acordo
com a fórmula abaixo:
• Nota Final = ((ML x 7) + (AF x 3)) / 10 = Média aritmética das lições
• AF = Avaliações
13
2.9 Bibliografia
• Site oficial: http://www.hylafax.org
• http://www.rzg.mpg.de/networking/tunnelling.html
• http://br-linux.org/artigos/dicas_httptunnel.htm
• http://www.jfranken.de/homepages/johan.en.html
• http://en.wikipedia.org/wiki/HTTP-Tunnel
• http://www.brandonhutchinson.com/ssh_tunnelling.html
• http://gentoo_wiki.com/TIP_SSH_Reverse_Tunnel
14
Capítulo 3
Material de apoio
Perguntas Frequetes: http://www.hylafax.org/content/FAQ
How To: http://www.hylafax.org/content/How-To
Lista de Modens compativeis: http://www.hylafax.org/modem
15
Capítulo 4
Introdução
4.1 O que é tunelamento

Um túnel TCP é, basicamente, um conexão realizada a partir de dentro e através de uma
outra conexão pré-estabelecida. Tipicamente um tunelamento envolve três nós, digamos assim:
1. o ponto (IP/porta) de onde a conexão pré-estabalecida parte;
2. o ponto (IP/porta) de onde a conexão a ser tunelada parte;
3. o ponto (IP/porta) para onde o tunelamento leva.
Se o destino especificado de uma conexão (origem no Nó 1) for o ponto em que um túnel

escuta (Nó 2), sua saída será a ponta final do túnel (Nó 3).
Este túnel pode ser estabelecido de algumas formas diferentes, e serem de espécies dife-
rentes. Cada tipo de tunelamento vai, é claro, satisfazer necessidades diferentes solucionando
problemas diferentes. Vamos tentar listar a seguir algumas das diferentes funções que um túnel
pode desempenhar.
4.2 Pra que serve tunelamento

Existem vários motivos pelos quais se pode querer implementar um túnel. Aqueles propósitos
que vão estar em foco neste curso são:
• Proteger dados através de uma conexão criptografada não suportada localmente;
• Realizar uma conexão cujo protocolo seria bloqueado não fosse o uso do túnel;
• Conectar-se a um destino bloqueado para conexão direta;
• Conectar-se a uma máquina de rede interna como se fosse de dentro para fora;
16
• Mascaramento de IP.
Outras razões que poderiam ser levantadas são:
• Transferir dados por uma rede cujos protocolos de camada 2 não são suportados;
• Praticidade na realização de uma conexão.
De qualquer forma as finalidades que resaltamos a pouco se devem todas a um mesmo fato
sobre o tunelamento: a conexão tunelada é realizada sempre sob a máscara da conexão-túnel
de forma que, dependendo da espécie deste, os dados da conexão principal podem transitar em
outros protocolos, ou ordenados sob algorítmos de criptografia e até sua origem e seu destino
podem aparecer mascarados dependendo do ponto da rede em vista.
Utilizamos já o tunelamento em uma ou outra tarefa diária, mesmo que não saibamos, atra-
vés de aplicativos que se aproveitam das funções listadas acima para funcionar devidamente,
como em tecnologias de redes VPN ou tecnologias PPPoE (Potocolo point-to-point tunelado por
Ethernet).
4.3 O que vamo conhecer

Existem diversos aplicativos que nos permitem abrir túneis manualmente. Diferentemente de
programas ou tecnologias que se utilizam de tunelamento, são aqueles que nos interessam neste
curso. Como o tunelamento pode possuir diferentes formas e funções, os aplicativos naturalmente
funcionando de maneiras e sob condições diferentes. Alguns deles foram projetados especifica-
mente para tunelar conexões, enquanto outros podem ter mais de uma função ou mesmo ser um
canivete suíço do TCP/IP. Os aplicativos que vamos conhecer aqui são:
• Netcat (canivete suíco TCP/IP)
• OpenSSH (shell remoto/túnel criptográfico)
• Httptunnel (túnel http para atravessar firewalls)
• Corkscrew (tunela SSH em http para atravessar firewalls)
4.4 Quando usar

Como já sabemos, cada aplicativo listado aqui satifaz, com o tunelamento, uma necessidade
diferente. Ainda que venhamos a conhecer e a aprender a usar diferentes tunelamentos com este
curso, talvez somente um ou dois deles farão parte de nosso cotidiano uma hora ou outra.
O Netcat nos será útil como ferramenta genérica de experiências de rede e de tunelamento
bruto, enquanto os outros quatro serão apresentados como alternativas a um caso ou outro.
Especificamente o OpenSSH, por ser mais consagrado e desempenhar um papel mais funcio-
nal (versátil) que o dos outros, visto ser ele mais do que uma ferramenta de tunelamento, receberá
uma prioridade alta neste curso.
De qualquer forma, podemos separar os aplicativos selecionados para este curso tendo em
vista as funções listadas em dois grupos principais:
• Aplicativos de tunelamento por criptografia;
17
– OpenSSH;
• Aplicativos de tunelamento para contornar firewalls.
– Corkscrew;
– HTTPTunnel;
É evidente que esses dois papéis se baseiam na mesma característica do que é o tunela-
mento. Afora os dois grupos acima, cada aplicativo pode servir para mascaramento de IP e o
OpenSSH, como veremos, é capaz de realizar o tal de tunelamento reverso.
Mapeados os aplicativos às suas respectivas funções de tunelamento, vamos entender um
pouco melhor a solução que tais funções oferecem. Terminadas as breves apresentações parti-
remos já para a instalação destes programas.
4.5 Contornando Firewalls

O problema que nos motiva a utilizar tunelamento atrás de firewalls restritivos é o bloquea-
mento de porta de saída que queremos acessar. Existem inúmeros exemplo deste cenário em
redes coorporativas. Portas muitas vezes bloqueadas são, por exemplo:
• 143 (IMAP)
• 22 (SSH)
• 6667 (IRC)
• 25 (SMTP)
• 42 (NS)
• 21 (FTP)
• 110 (POP3)
O tunelamento pode nos ajudar permitindo que façamos uma conexão para uma dessas por-
tas de destino através de uma das portas autorizadas pelo firewall, que funcionaria como o nó
intermediário da conexão que nos interessa. Uma das portas muito frequentemente habilitadas
mesmo por firewalls restritivos de redes empresariais é a porta 80, de acesso à web. Ela acaba
sendo, por esse motivo, a saída principal das conexões que de outra forma seriam bloqueadas.
Poderíamos utilizar em algumas conexões também a porta 22 como saída do firewall, se estiver
liberada.
Temos em mente casos em que conexões a determinadas portas de destino são bloqueadas,
o que poderíamos contornar também, se tivermos acesso ao servidor, reconfigurando o serviço
visado para escutar em uma porta autorizada pelo firewall. Existem casos, porém, nada raros, em
que os próprios protocolos das conexões que queremos fazer são bloqueados com, por exemplo,
um proxy. Nestes casos precisamos mascarar o protocolo proíbido o tunelando dentro de um
outro autorizado; mais uma vez este protocola será, principalmente, o http.
Em todo caso, as ferramentas que contornam firewalls no segundo caso também o fazem
no primeiro. Uma ferramenta que obviamente poderíamos utilizar aqui é o HTTPTunnel, capaz
de tunelar todos os dados da camadas de aplicação em HTTP para que atravessem o firewall
18
no formato que ele espera. Outra que pode interessar a quem quer fazer uma conexão a um
shell remoto com SSH bloqueado é o Corkscrew, que tunela em HTTP, através de um proxy,
especificamente o protocolo SSH, outrora a própria ferramenta de tunelamento.
Ambas ferramentas de tunelamento em HTTP repassam os dados para estações que rever-
tem o formato dos dados para os protocolos que o servidor de destino espera receber. Por tabela
o IP de origem da conexão, do ponto de vista do servidor da conexão, fica mascarado como um
IP dos servidores de conversão de dado intermediários.
Por enquanto estamos somente mapeando as funções destas quatro ferramentas de tune-
lamento. Mais tarde vamos conhecê-las pessoalmente, e junto a elas o uso do Netcat, nosso
canivete suíço dos milagres em rede.
4.6 Criptografando Conexões

Existem inúmeras situações cotidianas em que fazemos conexões com protocolos inseguros
(que transferem dados em claro), como por exemplo, em conexões http, pop, imap, ldap, samba,
syslog e outros. Estes serviços listados desempenham papéis particulares, mas até mesmo
conexões para acesso a shell, como o telnet, úteis como podem ser, trasferem dados em claro.
O problema de transferir dados não criptografados por uma rede é o risco de que alguma
máquina no caminho roteado ou no mesmo segmento (em casos de interfaces promíscuas es-
cutando broadcasts) esteja vasculhando o conteúdo dos pacotes que enviamos. Sabe-se muito
bem, inclusive, que uma máquina pode escutar conexões que sequer são destinadas ao seu
próprio segmento.
Ferramentas como o OpenSSH e o Stunnel permitem que encapsulemos muitas dessas co-
nexões inseguras dentro de túneis criptografados. Poderíamos, por exemplo, no lugar de acessar
diretamente o servidor de emais pop, tunelarmos nossa conexão pop com o Stunnel, que faz uso
do OpenSSL, e criptografar os dados com SSL. Esse procedimento permite que façamos uso
também de certificados SSL, diminuindo a possibilidade de uma interceptação.
Da mesma forma poderíamos antes estabelecer um túnel SSH entre nossa máquina e má-
quina destino e então atravessá-lo com nossa conexão telnet, acessando a entrada do túnel na
máquina local e saínda criptografado no destino, no lugar de fazer uma conexão direta insegura
com telnet.
Apesar de achar importante citá-lo, o uso do Stunnel não será abordado neste curso. Vale
lembrar, porém, que o Stunnel é uma das ferramentas mais populares de tunelament o por se-
gurança, e que ele é capaz de funcionar tanto acoplado a um cliente sem suporte nativo a SSL
quanto a um servidor mesmo, onde o Stunnel pode funcionar atrás de um TCPWrapper assim
como através do inetd. No caso de estar servidor a um servidor, o uso de certificação passa a
ser importante.
4.7 Tunelamento Reverso

Uma das capacidades especialmente incríveis de um túnel é permitir que uma máquina ex-
terna a uma rede se conecte à rede interna através de uma conexão estabelecida desde dentro.
A ferramenta que vamos utilizar para realizar um tunelamento reverso é o OpenSSH. Com o tune-
lamento reverso temos a chance de, com as restrições de quem está do lado de dentro da rede,
acessar de fora uma máquina da rede interna, o que é possível porque utilizamos para tanto uma
conexão - o túnel - que passou pelo firewall de dentro para fora. Ou seja, basicamente o firewall
19
autoriza a saída de uma conexão, na verdade um túnel, por dentro da qual podemos estabelecer
outra conexão a partir de fora sobre a qual o firewall jamais ficará sabendo.
4.8 Acesso indireto

Outro uso que se poder dar ao tunelamento é o acesso local à serviços que não são dispo-
níveis à sua máquina diretamente. Com local quero dizer que o acesso ao serviço, neste caso,
se comporta como se estivéssemos acessando diretamente da máquina local, e não realizando
duas conexões, uma à máquina intermediária e dela para a máquina de destino.
Isso pode não fazer diferença se acessamos uma shell, visto que os dados de um terminal de
texto são facilmente repassados por SSH, por exemplo. Essa manobra faz uma diferença mais
clara, no entanto, se estivermos acessando um serviço web, por exemplo, em que queremos
utilizar um browser (normalmente gráfico), e se fossemos nesse caso realizar duas conexões
teríamos de repassar dados gráficos, seja por SSH, com o X forward, seja com XDMCP, recursos
raramente disponíveis nos servidores. Com um acesso tunelado, neste caso poderíamos acessar
o serviço com nosso aplicativo gráfico como se acessássemos a máquina diretamente. E isso
sem ter que implementar um proxy reverso é claro.
Um exemplo bastante palpável deste tipo de caso é quando queremos acessar, de fora, a
porta 80 do roteador que conecta nossa rede interna à internet, sendo que o roteador só recebe
conexões de dentro e que uma de nossa máquina internas serve para fora conexões SSH.
Certamente existem casos outros e diferentes em que um acesso indireto por tunelamento
também se mostrará útil.
20
Capítulo 5
Instalando as ferramentas
5.1 Instalando o Netcat

O Netcat, como vamos conhecer mais tarde, é dito ser um canivete suíço das tarefas de
rede. O aplicativo foi desenvolvido para realizar na rede o que o comando ’cat’ realiza em nosso
sistema. O Netcat pode, portanto, "ler e escrever"através de conexões tanto TCP quanto UDP
brutas. Mas cada coisa em sua hora, vamos agora instalar o nosso canivete de rede.
Usuários debian poderiam simplismente instalá-lo com o pacote dos repositórios, mas a ver-
são que queremos instalar aqui até o momento não está disponível nos repositórios em que
procurei. Talvez encontre, no entanto, a versão mais recente nos repositóios Sid. Nada sei a
respeito da disponibilidade do Netcat em outros sistemas de pacotes. Certamente ele vai estar
presente em todos, mas agora precisamos da versão mais nova.
A novidade que nos interessa é que a recente versão (0.7.1) pode estabelecer túneis. Ora se
isto não nos diz respeito! Olhe que ele já era um canivete suíço muito antes desta capacidade
ser anunciada.
De qualquer maneira, para todos os aplicativos instalados nesta lição, vale a regra de que a
versão mais recente é a melhor. Portanto, caso venham a encontrar nos sites indicados versões
mais atualizadas, dêem preferência a estas. Este texto foi escrito no dia 27 de Novembro de 2006,
então fica a sugestão de que eventualmente confiram a presença de uma versão mais nova dos
aplicativos aqui instalados. Para os outros aplicativos aqui instalados, os usuários debian podem
tranquilamente utilizar o sistema de pacotes apt.
Bom, em uma linha de comando digitem as seguintes linhas:
# wget http://osdn.dl.sourceforge.net/sourceforge/netcat/netcat-0.7.1.tar.gz
# tar xfzv netcat-0.7.1.tar.gz
# cd netcat-0.7.1
# ./configure
# make
# make install
No site em que está o arquivo que baixamos está também o hash md5 para quem quiser
21
conferir sua legitimidade. Teste a instalação do aplicativo com o comando que lista a suas opções
de uso:
# netcat -h
Se uma lista de parâmetros for apresentada, o Netcat foi instaldo.
5.2 Instalando o OpenSSH

SSH significa "Secure Shell"e é provavelmente o protocolo mais popular e seguro para aces-
sos a um sistema ou uma shell remota. O OpenSSH é o aplicativo do OpenBSD que realiza
conexões sobre o protocolo SSH. Diferentemente de uma conexão estabelecida com o netcat, o
SSH implementa um sistema de certificação do servidor com chaves digitais e criptografa todos
os dados trocados na conexão. O OpenSSH é capaz de estabelecer túneis também criptografa-
dos, que, como vimos, pode nos servir para criptografar uma conexão que de outro modo seria
realizada em claro.
Não há preferência de versão para nossos testes de tunelamento com OpenSSH, e como,
na verdade, muito provavelmente ele próprio já está instalado na maioria de nosass máquinas,
a instalação como descrita a seguir talvez seja desnecessária. Mas, para aquelas(es) que ainda
não o tem instalado e nem podem baixá-lo com um sistema de pacotes, o procedimento de
instalação se dá como a seguir:
Novamente no console, digitemos os seguintes comandos:
# wget ftp://ftp.openbsd.org.br/pub/OpenBSD/OpenSSH/portable/openssh-4.5p1.tar.gz
# tar xfzv openssh-4.5p1.tar.gz
# cd openssh-4.5p1
# ./configure
# make
# make install
5.3 Instalando o Corkscrew

O Corkscrew desempenha um papel interessante como tunelador. Ele nos é útil quando o
próprio SSH, outrora nossa ferramenta de tunelamento, precisa ser tunelado para fora de uma
rede interna através de um proxy que de outra forma o bloquearia. O Corkscrew faz o trabalho
barra pesada de fazer a conversão e reconversão entre os protocolos SSH e HTTP. Na verdade
não vamos com o Corkscrew montar túneis na mão como o fazemos com o Netcat e com o
OpenSSH, mas vamos utilizá-lo para ver a manobra do tunelamento fazendo mágica.
Dentro todos programas que vamos instalar e conhecer, este é o único do qual poderíamos
abrir mão sem desfalcar este estudo sobre tunelamento. Ele será utilizado, entretanto, como
exemplo do tipo de tunelamento com SSH que vamos ver o HTTPTunnel fazendo, mais tarde,
22
com todo tipo de protocolo. O Corkscrew vai servir como uma introdução simples e breve ao
tunelamento de contorno de firewalls.
Vamos digitar os mesmos seguintes comandos para compilar e instalar o Corkscrew em nossa
máquina, caso não o possamos fazer com um gerenciador de pacotes.
# wget http://ftp.debian.org/debian/pool/main/c/corkscrew/corkscrew_2.0.orig.tar.gz
# tar xfzv corkcrew_2.0.orig.tar.gz
# cd corkcrew_2.0.orig
# ./configure
# make
# make install
5.4 Instalando o HTTPTunnel

O HTTPTunnel é nossa ferramenta mestra (principal) para atravessar um firewall típico com
sua legitimação. Como o protocolo HTTP costuma ser habilitado em conexões que saem da rede,
podemos, com o HTTPTunnel, transitar todo tipo de dado em protocolos bloqueados em forma de
HTTP.
Para instalá-lo, vamos proceder passos idênticos aos das outras instalações com os seguintes
comandos:
# wget http://ftp.gnu.org/gnu/httptunnel/httptunnel-3.3.tar.gz
# tar xfzv httptunnel-3.3.tar.gz
# cd httptunnel-3.3
# ./configure
# make
# make install
23
Capítulo 6
Iniciação prática
6.1 Netcat - Introdução

O Netcat, como já devem saber, é uma ferramenta profundamente útil e versátil. Seria difícil e
inapropriado apresentar aqui os diversos usos nativos e criativos que se pode fazer do canivete
suíço. Uma listagem de suas utilidades, até onde meu conhecimento vai pode ser:
• Conexões simples:
– Acessar um serviço;
– Pegar o banner de um serviço;
• Servir conexões:
– Estabelecer chats;
– Disponibilizar acesso remoto à aplicativos locais:
* Acesso à própria shell;
* Disparar um processo qualquer;
– Repassar dados pela rede para monitoramento remoto em tempo real para a máquina
local ou para outra(s);
• Tunelar conexões;
Como consequência temos funções criativas que podemos dar ao Netcat como:
• Varrer máquinas para listagem de portas abertas;
• Vasculhar pacotes da rede sem permissão de super-usuário;
• Clonar HDs via rede;
Sabendo que o comando do Netcat é ’nc’, vamos agora realizar algumas de suas operações
básicas para ganharmos alguma familiaridade com ele.
Note que daqui para frente, o texto que estiver em negrito corresponde os dados que forem
inseridos e comandos digitados (exceto o caractere cifrão $, que indica a linha de comando do
shell), enquanto o texto em itálico corresponderá ao texto impresso na tela como resposta do
aplicativo.
24
6.2 Netcat - Conectando

O Netcat deve receber dois parâmetros para realizar uma conecção simples: o endereço da
máquina e a porta a se conectar, exemplo:
$ nc google.com 80
Quando conectados, experimentem passar a requisição "GET / HTTP/1.0 ":
$ nc google.com 80
GET / HTTP/1.0 <Enter>
Outro exemplo pode ser uma conexão a um servidor SSH:
$ nc servidor-ssh 22
Em minha máquina eu fiz:
$ nc localhost 22
SSH-2.0-OpenSSH_4.3p2 Debian-3
qualquer coisa <Enter>
Protocol mismatch.
É claro, o próprio cliente OpenSSH espera que reconheçamos o certificado do servidor, mas
não ’falamos SSH’ e ao digitarmos qualquer coisa (literalmente, no exemplo) aparece, natural-
mente, a mensagem Protocol Mismatch, indicando o erro de protocolo.
6.3 Netcat - Servindo

Para servir em uma porta dada com o Netcat precisamos indicar que queremos escutar com
a opção ’ -l ’ (de listen) e indicar a porta em que queremos escutar com a opção ’ -p ’ (de port).
Como as portas que vão de 1024 para baixo são reservadas, somente o super-usuário poderá
escolhê-las para servir, mas todo as outras podem ser teoricamente indicadas por um usuário
regular. Exemplo:
$ nc -l -p 1025
Abra outro terminal e se conecte à porta aberta:

$ nc localhost 1025
Agora experimente digitar qualquer coias pelas duas pontas da conexão e verá que tem um
chat pessoal funcionando!
Uma boa prática, especialmente ao abrir portas para escuta, é setar o parâmetro ’ -v ’, que,
previsivelmente significa verbose e serve para nos informar do que estiver acontecendo com o
serviço. Pode-se setar o parâmetro verbose duas vezes com ’ -vv ’ para solicitar ainda mais
informação. Experimente o msmo comando com ’ -vv ’:
25
T1 (terminal 1) - Servidor T2 (terminal 2) - Cliente

$ nc -l -vv -p 1025 $ nc localhost 1025
listening on [any] 1025 ... alo
oi
connect to [127.0.0.1] from localhost.localdomain [127.0.0.1] 46699 <Ctrl-c>
alo
oi
sent 3, rcvd 4
$
Como último comentário a montagem de serviços com Netcat, gostaria de ressaltar que o
Netcat transfere dados em claro, o que permite que alguém facilmente capture os dados trasfe-
ridos. Para se utilizar dos recursos que o Netcat oferece em situações em que a segurança dos
dados for importante experimente o tal Cryptcat, que dizem ser o Netcat criptografado. Existe,
porém, maneiras de tornar serviços Netcat um pouco mais seguros do que da forma como vimos
acima. Podemos, por exemplo, restringir o acesso ao serviço posto designando os IPs específi-
cos dos quais esperamos a conexão, assim como podemos especificar uma porta de origem de
conexão como critério de filtro. Essas medidas não protegem, é claro, uma conexão Netcat de ser
observada clandestinamente com uma ferramente de sniffing. Caso queiramos utilizar o próprio
Netcat e ainda assim proteger os dados com criptografia podemos também simplismente tunelar
o Netcat em um túnel criptográfico, como vamos aprender a fazer até o final deste curso.
6.4 Netcat - Piruetas (opcional)

Atenção:
A leitura desta página da lição é opcional, visto que seu conteúdo não é fundamental para a
prática do tunelamento como será vista mais adiante. O seu aprendizado não será, portanto, co-
brado nas questões ou na avalição. Praticar o que é apresentado abaixo pode servir à criatividade
de cada um na solução de ’problemas’ que se possa encontrar.
Aqui vamos conhecer rascunhar algumas maneiras de potencializar o uso no Netcat. Caso
não tenha tempo ou interesse, passe para a próxima página.
6.4.1 Piruetas do Netcat

O Netcat foi desenvolvido com a referência de ser o cat para redes. O cat basicamente tem a
função de jogar conteúdos de texto para um lado e para o outro. De fato, o Netcat faz as mesmas
estripulias só que através de conexões estabelecidas. Vamos experimentar agora alguns desses
usos do cat utilizando o Netcat para conhecermos melhor suas utilidades.
Um deles acabamos de conhecer na página anterior. Se chamamos o cat sem qualquer
parâmetro, ele entra em modo interativo e tudo o que digitarmos será ecoado na tela.
$ cat
alo
alo
26
eco
eco
sair
sair
<Ctrl>-d
O mesmo vimos acontecer quando estabelecemos a conexão entre o Netcat escutando em

uma porta e o Netcat cliente. Ao digitarmos ’alo’ em uma ponta da conexão víamos o conteúdo
’alo’ aparecendo na outra.
Outro uso do cat é o que fazemos para ler o conteúdo de um arquivo e jogar para a saída
padrão, o terminal. Para tanto vamos antes criar um arquivo simples.
$ echo 'olá' > mensagem
Podemos jogar o conteúdo do arquivo para a saída padrão de duas formas:
$ cat arquivo
ou
$ cat < arquivo
A segunda forma também funciona com o Netcat. Vamos lá. Primeiro abrimos uma porta para
escuta por um terminal e em seguida nos conectamos com o comando simples que estabelece a
conexão, que já conhecemos, seguido do redirecionador e do nome do arquivo ’< mensagem’, ou
seja:
$ nc servidor porta < arquivo
Confira os passos na tabela a seguir:
6.4.2 Caso 1

$ nc -l -vv -p 1025 $ nc localhost 1025 < mensagem
listening on [any] 1025 ... <Ctrl-c>
oi
connect to [127.0.0.1] from localhost.localdomain [127.0.0.1] 50480 <Ctrl-c>
olá
sent 0, rcvd 4
$
O mesmo acontece se passarmos o arquivo pela ponta do servidor:
27
6.4.3 Caso 2
$ nc -l -vv -p 1025 < mensagem $ nc localhost 1025
olá
listening on [any] 1025 ...
<Ctrl-c>
connect to [127.0.0.1] from localhost.localdomain [127.0.0.1] 50480 $
sent 0, rcvd 4
$
Pense agora que se podemos passar o conteúdo de um arquivo para dentro de uma conexão
Netcat, como faríamos com o próprio cat, e se o Netcat joga os dados que chegam da outra ponta
para a saída padrão, o terminal, então podemos também jogar o conteúdo de saída, que iria para
o terminal, igualmente para dentro de um arquivo.
Observe então a seguinte cena.
Antes de mais nada:
$ echo 'Mas porquê você não come carne?' > pergunta-chata
6.4.4 Caso 3

$ nc -l -vv -p 1025 < pergunta-chata > resposta-obvia-No1 $ nc localhost 1025
listening on [any] 1025 ... Mas porquê você não come carne?
connect to [127.0.0.1] from localhost.localdomain Eu não como carne,
[127.0.0.1] 3456 leite, ovo e seus derivados porque
não quero corroborar os
hábitos (e os valores) mantidos e
incitados por uma indústria especista
que luta explorando e
massacrando animais.
<Ctrl-c>
$
Ora, se podemos passar conteúdo de um arquivo e também podemos repassar conteúdo

recebido para um arquivo na outra ponta, devemos poder passar um arquivo em uma ponta e
recebê-lo em outra! Sim, podemos.
Observe a cena a seguir:
6.4.5 Caso 4
28

$ nc -l -vv -p 1025 < /bin/nc $ nc localhost 1025 > copia-nc
listening on [any] 1025 ... <Ctrl-c>
connect to [127.0.0.1] from localhost.localdomain $ md5sum copia-nc
[127.0.0.1] 3325
sent 20192, rcvd 0 8be0c375b01da07206c070b3e7d72084 copia-nc
$ md5sum /bin/nc $
8be0c375b01da07206c070b3e7d72084 /bin/nc
$
Enviamos o executável de uma ponta da conexão (do servidor) para outra (para o cliente).
Checamos que o conteúdo dos arquivo é idêntico.
O Netcat simplismente estabelce uma conexão, o que faz com ela não interessa a ele (na
próxima página, na verdade, vamos conhecer algumas opções do Netcat que podem sofisticar
suas funções). Podemos preparar todo tipo de serviço útil combinando as milhares de funções
úteis do bash com o uso do Netcat. Mais um exemplo simples, mas útil, é o uso do pipe ( | ).
Pense que assim como podemos passar o conteúdo de um arquivo pela conexão também po-
demos passar o conteúdo resultante de um procedimento qualquer, com um comando qualquer.
Por exemplo, podemos passar uma lista de ítems pela conexão ordenando-a antes de enviá-la.
6.4.6 Caso 5
$ cat lista | sort | nc localhost 1025
Essa é uma saída estática de um comando, mas imagine o envio permanente de dados de
saída de um pipe qualquer. Por exemplo, podemos monitorar remotamente os processos que
mais consomem recursos de nosso sistema com a seguinte manobra:
Servidor:
$ top | nc -l -vv -p 1025
Cliente:
$ nc servidor 1025
Uau!
Agora mais que isso, podemos repassar pela conexão a própria execução de um comando
interativo qualquer. E ainda mais, esse aplicativo pode ser o próprio shell! O Netcat pode, ora se
não poderia, estabelecer um servidor de shell remota. Observe essa maravilha:
29
6.4.7 Caso 6
$ nc -l -vv -p 1025 | /bin/bash $ nc localhost 1025
listening on [any] 1025 ... ls -1
connect to [127.0.0.1] from localhost [127.0.0.1] 4572
copia-nc <Ctrl>-c
exemplo1 $
lista
mensagem $
pergunta-chata
piruetas-netcat
piruetas-netcat˜
resposta-obvia-No1
sent 0, rcvd 6
$
Da maneira que foi feita acima o cliente, que passa o comando, não pode ver a sua saída.
No caso de um comando como o ls este fato é relevante, mas diversos comandos poderiam ser
dados pelo lado do cliente sem que se esperasse qualquer resposta, como ’init 0’, por exemplo,
para desligar a máquina.
Mas e se precisássemeos da saída do comando dado? Como podemos fazer para vê-la
do lado do cliente? Ora, se podemos, via pipe, passar quaisquer comandos tanto para dentro
da conexão Netcat quanto podemos podemos passar da conexão Netcat afora para dentro de
um comando, então podemos redirecionar as saídas do shell no servidor para dentro de outra
conexão Netcat! Observe a manobra olímpica:
6.4.8 Caso 7
T1 - Servidor 1 e 2 T2 Cliente 1 T2 Cliente 2

$ nc -l -vv -p 1025 | /bin/bash | nc -l -vv -p 1026 $ nc localhost 1025 $ nc localhost 1026
ls copia-nc
listening on [any] 1026 ... exemplo1
$ lista
listening on [any] 1025 ... mensagem
connect to [127.0.0.1] from localhost [127.0.0.1] 3560 pergunta-chata
piruetas-netcat
connect to [127.0.0.1] from localhost [127.0.0.1] 3445 piruetas-netcat˜
resposta-obvia
<Ctrl>-c resposta-obvia-No1
sent 115, rcvd 0 $

sent 0, rcvd 3
$
Ainda assim temos de ficar trocando de terminais para em um passar um comando e em outro
ver sua saída. Uma alternativa funcional é no T3, ao invés de simplismente nos conectarmos,
30
nos conectarmos e enviarmos os dados que chegarem para o T2 usando redirecionamento e o

identificador do terminal do diretório /dev. Por exemplo:
T2:
$ nc localhost 1026 > /dev/pts/1
Isso que vimos acima é a solução crua para a implementação de um servidor de shell remoto.
O Netcat oferece várias opções passadas em parâmetros para tar seu uso mais funcional e otimi-
zado. O conhecimento de como se realizar as manobras acima ainda se mostrará importante, no
entanto, para que você encontre soluções criativas quando precisar. Como informei, o domínio
deste trecho da lição não é fundamental para o aprendizado e uso do tunelamento, e por isso
este curso não espera que tenha aprendido a realizar as piruetas do Netcat.
6.4.9 Opções
Brevemente, vamos ver agora algumas das opções que o Netcat nos oferece.
Abaixo está a lista de opções obtida com o comando ’nc -h’ e traduzida por mim.
-c, –close fecha conexão ao encontrar EOF do stdin
-e, –exec=PROGRAM programa a executar depois de conectar
-g, –gateway=LIST nós de ’route-sourcing’, até 8
-G, –pointer=NUM ponteiro de ’source-routing’: 4, 8, 12, ...
-h, –help apresenta este menu e sai
-i, –interval=SECS intervalo de espera para linhas enviadas e para porta escaneadas
-l, –listen modo de escuta, para conexões que chegam
-L, –tunnel=ADDRESS:PORT repassa porta local para um endereço remoto
-n, –dont-resolve somente endereços de IP numéricos, sem DNS
-o, –output=FILE imprime o tráfico hexdump para ARQUIVO (implica em -x)
-p, –local-port=NUM número da porta local
-r, –randomize randomiza portas locais e remotas
-s, –source=ADDRESS endereço do ’source’ local (ip o hostname)
-t, –tcp modo TCP (padrão)
-T, –telnet responder usando negociação TELNET
-u, –udp modo UDP
-v, –verbose modo verboso (utilizar duas vezes para ser ainda mais verboso)
-V, –version mostra informações sobre a versão e sai
-x, –hexdump faz um hexdump tanto do tráfico que chega quanto do que sai
31
-w, –wait=SECS tempo limite para tentativas de conexões e para ’final net reads’
-z, –zero modo zero-I/O (utilizado para escaneamento)
Marquei em negrito as 2 opções que vou comentar neste resto de página. Como podem ver
já conhecemos algumas opções como -h, -l, -p, -v e -vv. A opção que nos é central neste curso
é, é claro, a -L. Outras são muito interessantes, como a -u, para realizar conexões UDP, -z, -r, -w
e -i para escaneamento de portas e -o para sniffing.
A opção -c permite que automaticamente fechemos uma conexão ao término da transferência
de um arquivo. Isso pode ser útil caso não possamos manualmente interromper o netcat com
<Ctrl>-c, por exemplo. Especialmente útil se estivermos mantendo o serviço em pé com um while
ou com outra manobra. Experimente refazer o caso 4 apresentado acima com a opção -c. Esta
opção funciona sempre quando informada do lado da conexão que vai inserir dados.
A opção -e soluciona de forma elegante e nativa o problema que só "resolvemos"com a mano-
bra completa apresentada no Caso 7. A opção -e passa a execução de um comando especificado
para a outra ponta da conexão, e ao recebere dados, retorna a saída do comando, caso responda,
devolta para a ponta remota. Experimente escutar uma porta como fazíamos nos casos apresen-
tados e passar o parâmetro -e seguido do caminho, digamos, do shell bash, -e /bin/bash. Pimba,
um servidor de shell remoto perfeito.
Uma última dica: Para realizar as mesmas peripércias que fazemos com o Netcat, mas com
segurança de dados, pode-se utilizar o tal Criptcat, que se diz ser o Netcat com conexões crip-
tografadas. Uma alternativa, no entanto, seria tunelar as conexões Netcat por dentro de SSH, é
claro!
32
Capítulo 7
Iniciação prática - OpenSSH
7.1 OpenSSH - Conectando

Assim como o Netcat, o OpenSSH é tanto capaz de servir em uma dada porta quanto capaz de
conectar a uma porta especificada, mas todas conexões que o OpenSSH estabelece funcionam
sobre o protocolo criptográfico SSH. O cliente OpenSSH pode acessar qualquer porta dada, mas
uma conexão só será estabelecida se o serviço a escutar na porta em vista falar o protocolo SSH.
Suponho aqui que cada de nós já tenhamos acesso a ao menos uma máquina por SSH,
mas caso alguém não tenha, estes exercícios poderão ser feitos na máquina local depois de
colocarmos o sshd para rodar como veremos na página seguinte.
Bom, o modelo de comando a seguir é o formato do acesso padrão mais simples possível por
SSH com o OpenSSH:
$ ssh servidor
Simples assim. Quando não especificamos com que nome de usuário vamos ser autenticados
pelo servidor, o OpenSSH tenta logar com o nosso nome de usuário local, com o qual lançamos
o cliente OpenSSH. Acontece que geralmente o nome de usuário com o qual nos logaremos no
servidor não é o mesmo que usamos para dar o comando. Nestes casos, precisamos especificá-
lo adicionando ’usuario@’ antes do nome do servidor. Modelo:
$ ssh usuário@servidor
Uma segunda alternativa para a especificação do nome de usuário com o qual logarmos
no shell remoto é a utilização do parâmetro ’ -l ’, provavelmente de login. Observe, o seguinte
comando faz o mesmo que o anterior:
$ ssh -l usuário servidor
Da maneira como foi apresentado acima, o comando não especifica a porta à qual tentará
se conectar. O OpenSSH, neste caso, assume que queremos nos conectar à porta padrão dos
servidores SSH, que é a 22. Um serviço de protocolo SSH, ao contrário de um servidor Netcat,
possui uma porta padrão vastamente conhecida. Para especificar a porta à qual tentaremos nos
conectar por SSH passamos o parâmetro identificado por ’ -p ’ para o nosso comando. Modelo:
$ ssh usuário@servidor -p 22
33
Fazendo conexões com esses parâmetros somos levados ao shell da máquina remota. Po-
demos, entretanto, passarmos diretamente um comando para ser execuatado ao conecatarmos.
Por exemplo, podemos fazer uma conexão que retorna a saída do comando ’who’, listando os
usuários logados no sistema:
$ ssh usuário@servidor -p 22 "who"
7.1.1 Autenticação do usuário

O protocolo SSH implementa uma série de cerimônias tcp para estabelecer uma conexão.
Isso acontece porque além de querer ser um protocolo seguro, uma conexão SSH liga um cli-
ente de um lado à shell da máquina servidora do outro. Um servidor SSH padrão espera que
somente pessoas reconhecidas possam se conectar à sua máquina. O método de autenticação
do OpenSSH é pelo nome de usuário, que deve estar presente no arquivo /etc/passwd do sistema
que serve. Ao contrário do estebelecimente de uma conexão Netcat, portanto, uma conexão SSH
envolve a informação de um nome de usuário e sua senha.
7.1.2 Legitimação do servidor

# ssh localhost The authenticity of host 'localhost (127.0.0.1)'
can't be established. RSA key fingerprint is
05:99:21:19:92:7c:d2:02:3b:1a:14:46:1c:7d:63:e1.
Are you sure you want to continue connecting (yes/no)?
Esta mensagem será aprensentada à primeira vez que nos conectarmos a cada servidor a
partir de uma mesma máquina. Essa mensagem acusa que o serviço ao qual o cliente OpenSSH
está prestes a se conectar não pode ser autenticado, ou seja, ou ele não pode garantir que à
máquina à qual estamos nos conectando é realmente aquela que apontamos no comando ou
(nem) que a máquina que apontamos é a que pensamos que é. Tipicamente essa operação não
é arriscada porquanto não estamos fazendo uma conexão de sigilo coorporativo.
A partir da primeira conexão autorizada por nós, através do ’yes’, o OpenSSH armazenará
no arquivo /.ssh/know_hosts a chave de identificação do servidor que legitimamos. Na próxima
vez que nos conectarmos ao mesmo servidor, o OpenSSH vai poder comparar a chave dada
pelo servidor encontrado com a chave armazenada associada ao servidor que pensamos estar
encontrando. Com o nível de segurança setado por padrão, a conexão será interrompida caso as
chaves não batam.
Sobre o risco corrido na primeira conexão, podemos anteriormente requerer do administrador
da máquina servidora, por uma via que pensamos ser mais segura, como por email ou pessoal-
mente, a chave do servidor para comparação. Existem também maneiras de checar a legitimidade
do servidor após logados, o que nem sempre é conveniente e seguro.
Importante:
Caso venhamos a nos conectar mais de uma vez a uma mesma máquina, pode ser o caso
que o OpenSSH não reconheça a chave ou o IP do servidor, caso tenham mudado. Isso pode
acontecer por um motivo ou outro, e é provável que ao longo dos exercícios tenhamos nosso
acesso bolqueado a máquinas seguras pelo nosso próprio cliente OpenSSH por essa razão de
segurança. Existem várias saídas elegantes para este problema, como, por exemplo, alterar
as medidas de segurança do cliente OpenSSH no arquivo de configaração. No entanto, não
faria sentido nos envolver aqui com a soução de como implementar essa ou outra solução ade-
quada. Sugiro, portanto, que aquelas pessoas que tiverem esses problemas de autenticação
34
simplismente removam o arquivo /.ssh/known_hosts, onde ficam armazenadas as chaves e as

identificações dos hosts autorizados. Lembrem, entretanto, que essa prática não é segura para
todas as máquinas em qualquer instituição.
7.2 OpenSSH - Servindo

Vamos agora, brevemente, conhecer o passos básicos com os quais podemos colocar o
OpenSSH para escutar conexões pelo protocolo SSH. Se instalou o OpenSSH na mão, você
pode iniciar o serviço com o seguinte comando:
$ /usr/local/sbin/sshd
Caso tenha instalado o OpenSSH pelo sistema de pacotes debian podemos iniciar o serviço
através do init.d com o comando
$ /etc/init.d/sshd start
Como dizíamos, a porta padrão para serviços SSH é a 22, e o OpenSSH escutará nesta
mesma porta caso não setemos outra. Tentemos pois nos conectar à porta 22 de nossa própria
máquina com o comando que aprendemos na página anterior:
$ ssh localhost
7.2.1 Porta de escuta e outras configurações

Muitas vezes queremos alterar a porta em que nosso serviço escutará, ou porque queremos
evitar ataques brute force automático de bots, ou para passar ao largo de scannings de porta
mais estreitos, ou porque a porta padrão é bloqueada para acesso externo pelo nosso provedor,
por exemplo, ou por qualquer outro motivo mais exótico.
Para alterar a porta em o OpenSHH vai escutar temos de editar o arquivo de configuração do
sshd, o /etc/ssh/sshd_config.
1 # Package generated configuration file

2 # See the sshd(8) manpage for details
3
4 # What ports, IPs and protocols we listen for
5 Port 22
Logo na quinta linha do arquivo está indicada a porta em que o OpenSSH vai abrir o socket
para conexão. Podemos setar qualquer outro valor no lugar de 22, e o sshd funcionará com a
nova configuração contanto que o reiniciemos. Para tanto, podemos interromper o processo do
serviço e o reiniciarmos da mesma maneira. Caso se utilize o init.d, o fazemos da mesma maneira
como antes mas com restart no lugar de start.
Outras linhas deste mesmo arquivo de configuração são interessantes, mesmo para quem
não quer montar um servidor profissional. Por exemplo, podemos decidir, através da seguinte
diretiva,
26 PermitRootLogin
35
, se será permito que a autenticação se dê com o nome de usuário do próprio root, o que
poderia ser uma fraqueza na segurança.
A diretiva
62 X11Forwarding
decide se será possível o estabelecimente de conexões com redirecionamento dos aplicativos

gráficos pela conexão.
Estas opções e outras, no entanto, não nos interessam neste curso.
36
Capítulo 8
Tunelamento - Netcat
8.1 Tunelando com o Netcat - Parte 1

Vamos enfim utilizar breve experiência para tentar montar nossos primeiros túneis. Para co-
meçar, vamos utilizar o querido canivete suiço Netcat, que em suas novas versões oferece o
recurso de tunelamento.
Como devemos todos lembrar, o tunelamente envolve pelo menos três nós conectados e,
portanto, elos de conexão. Um desses, em princípio sempre o primeiro, é estabelecido com uma
conexão regular, já o segundo elo é o próprio túnel, por dentro do qual a primeira conexão vai
ser levada até a saída na terceira ponta. Apesar da prensença necessária dos três nós de que
falo, podemos envolver somente duas ou até mesmo uma máquina no processo de tunelamento.
Vamos ver alguns casos diferentes ao longo deste curso, inclusive porque a maior parte das
utilidades de um túnel se dá em configurações de rede específicas entre duas ou mais máquinas.
Para apresentar os exemplos com mais consistência, no entanto, farei os testes de tunelamento
em uma única máquina. Mas, novamente, nada impede que façam os mesmos testes em rede
envolvendo mais de uma máquina.
Abram três terminais. A idéia é que um primeiro terminal vai escutar em uma porta de forma
regular, um segundo vai abrir um túnel de uma porta arbitrária até a porta em que o servidor
do primeiro terminal estiver escutando e o terceiro terminal vai se conectar, também de maneira
regular, à porta arbitrária do tunel, que levará essa conexão até a sua saída no serviço do primeiro
terminal. Um comando será dado para cada uma das três partes do processo. Esse processo,
quando realizado no console, é completamente evidente, transparente.
T 1 (servidor):
$ nc -l -vv -p 1026
T 2 (túnel):
$ nc -L localhost:1026 -p 1025
T 3 (cliente):
$ nc localhost 1025
Este teste mostra que a conexão que entra na porta aberta pelo túnel, no caso a 1025, atra-
vessa o túnel e cai na porta do serviço para o onde o túnel leva, no caso a 1026. Este é um
37
cenário bastante semelhante ao que vimos na lição sobre escutar em portas com o Netcat. Aqui
é estabelecida uma conexão clara em que tudo que for passado em uma ponta sai na outra, sem
que o nó intermediário, o túnel, interfira na passagem. Experimente portanto digitar qualquer
coisa em quaisquer das duas pontas, e observe que os dados saem na outra. Aquilo que for
escrito no terminal do túnel parece não ir a lugar algum. Observe:
T1 - Servidor T2 - Túnel T 3 - Cliente

$ nc -l -vv -p 1026 $ nc -L localhost:1026 -p 1025 $ nc localhost 1025
Listening on any address 1026 $ ola, sou o terminal 1
Connection from 127.0.0.1:50454 oi, sou o terminal 3
ola, sou o terminal 1 $
oi, sou o terminal 3 <Ctrl>-c
Total received bytes: 21
Total sent bytes: 22
$

Repare que nenhum dado ficou no nó intermediário da conexão entre as duas pontas, e que,
isto é importante, ao pressionar <Ctrl-c> no lado cliente do túnel, o próprio servidor terminou
a escuta, como acontecia quando cortávamos a conexão do lado do cliente em nossos testes
de escuta com o Netcat, e o servidor fechava. É importante ver que a relação entre o servidor
e cliente mediada pelo túnel Netcat mantém este detalhe, que revela um elo entre as pontas
diferente daquele existente em um redirecionamento de conexão simples. Tipicamente em um
redirecionamento de conexão, na verdade, duas conexões simples são estabelecidas, sendo que
os dados de uma são passados para a outra como em um pipe (às vezes com o próprio pipe).
Assim o término de uma conexão em um lado não pode ser reconhecido pelo outro, e não é a toa
que em um redirecionamento simples de conexão o repasse de dados é unidirecional, que não é
o caso, é claro, da conectividade em um tunelamento.
O mesmo teste pode ser realizado, como disse, envolvendo três máquina diferentes, o que
pode tornar a operação apresentada acima uma pirueta das mais úteis. A adaptação do tunela-
mento acima envolvendo três máquinas poderia ser como o seguinte:
Servidor na internet:
(servidor-x) $ nc -l -vv -p porta-x
Servidor de túnel na internet:
(servidor-tunel) $ nc -L servidor-x:porta-x -p porta-inocente
Cliente em rede interna que bloqueia saídas para a porta-x:
$ nc servidor-tunel porta-inocente
E o cliente acessa a porta-x na internet que, em um acesso direto, seria bloqueada pelo
firewall ou pelo proxy da rede interna.
PS.: Uma maneira de acompanhar um pouco mais do que acontece em nosso sistema en-
quanto fazemos esses exercícios de tunelamento é utilizar o netstat ou outra ferramenta de rede
que apresente as conexões estabelecidas com a máquina. As seguintes duas linhas foram tira-
das da saída do comando netstar -a | grep localhost ao montar um túnel simples como mostrado
na página anterior.
38
tcp 0 0 localhost:1025 localhost:2702 ESTABELECIDA

tcp 0 0 localhost:4186 localhost:1026 ESTABELECIDA
Quem estiver mais a vontade com redes e interessado, pode também, e isso sim eu reco-
mendo fortemente, acompanhar os testes com uma ferramenta de sniffing, como o wireshark (que
antes era o ethereal), o snort ou o próprio tcpdump. Um acompanhamento deste tipo permite que
vejam o papel que tem um túnel criptográfico, por exemplo, assim como a origem aparente de
cada pacote e outras informações. Não posso, no entanto, fazer esse acompanhamento para os
testes que fizermos aqui.

Note, e isso é muito importante mesmo, que os exemplos apresentados até então assumiram
cenários com servidores e clientes Netcat tunelados por Netcat. Um túnel pode, no entanto,
tunelar todo tipo de conexão. Para um tunelamento funcionar basta que o cliente e o servidor
nas pontas sejam compatíveis entre si. O túnel é, nos termos que nos interessa aqui, cego ao
protocolo falado entre o cliente e o servidor.
Para ilustrar, vamos conhecer alguns casos de um tunelamento Netcat de uma conexão SSH,
que já conhecemos. Assumindo que tanto a máquina de tunelamento quanto a máquina cliente
são a mesma:
(T1) $ nc -L servidor-ssh:porta-ssh -p 1025
(T2) $ ssh localhost -p 1025
No primeiro terminal o Netcat faz a sua única participação: aponta para um servidor SSH,
escuta na porta 1025 e espera por uma conexão SSH. No segundo terminal, um cliente SSH se
conecta à porta aberta pelo túnel Netcat. A conexão SSH acontece normalmente, e por dentro
do túnel até o seu fim os dados aparecem criptografados.
Um exemplo talvez mais surpreendente e aparentemente útil seja o tunelamento de uma co-
nexão HTTP. Considere uma rede interna em que um site específico seja bloqueado. Se temos
acesso a uma máquina externa, na internet, podemos nela montar um túnel que aponte para o
servidor web na internet que queremos ver e em seguida nos conectar ao túnel com, é claro, um
browser, capaz de falar o protocolo do servidor, o HTTP.
Faça o teste em uma rede interna. Comece inicializando o Apache (caso não tenha um
rodando, ou teste logo com um site na internet) na porta que quiser, mas suponhamos que tenha
sido na porta padrão 80. De uma segunda máquina, monte um túnel Netcat que aponte para o
servidor Apache, escutando por conexões que entrem. De uma terceira máquina, o cliente, abra
um browser e se conecte à porta aberta pelo túnel na máquina em que está escutando. Veja o
resultado!
8.4 Simulando um túnel com redirecionamentos Netcat (opcional)

8.4.1 Redirecionamentos Netcat
Nota 1: Quem acompanhou a página da lição anterior que apresentou algumas piruetas com o
Netcat vai certamente poder acompanhar melhor o que é mostrado nesta página. Sua leitura não
39
é obrigatória neste curso, e deve ser lida por aquelas pessoas que tiverem curiosidade e interesse
em sofisticar suas técnicas de manipulação de conexões com o Netcat. As técnicas apresentadas
nesta página têm suas utilidades superadas, ao menos de forma geral, pela possibilidade de um
túnelamento, agora nas novas versões do Netcat.
Nota 2: Note que o redirecionamento de que falo não é um controle de roteamento, como o
que o módulo redirect do Iptables faz. Estou, com ’redireciomento’, me referindo à operação de
passar os dados que chegam de uma conexão para dentro de outra.
Existe, como dizia a pouco, a possibilidade de simplismente redirecionarmos os dados que
chegam de uma conexão para dentro de outra, o que estabelece uma conectividade unilateral,
ou seja, uma conexão indireta na qual só uma das pontas pode enviar dados à outra. É claro que
podemos, no entanto, determinar para que lado da conexão o redirecionamente vai estar virado,
o que nos leva a dois cenários diferentes. Com o Netcat podemos montá-los das seguintes
maneiras:
Sentido 1 (O servidor fala):
T1 - Servidor * recebe: do redirecionador somente * envia: para o cliente somente
$ nc -l -vv -p 1025
T2 - Redirecionador * recebe: do cliente somente (e não repassa para o servidor) *

envia: para o servidor somente
$ nc localhost 1025 | nc -l -vv -p 1026
T3 - Cliente * recebe: do servidor somente * envia: para o redirecionador somente
$ nc localhost 1026
Sentido 2 (O cliente fala):
T1 - Servidor * recebe: do cliente somente * envia: para o redirecionador somente
$ nc -l -vv -p 1025
T2 - Redirecionador * recebe: do servidor somente (e não repassa para o cliente) *

envia: para o cliente somente
$ nc -l -vv -p 1026 | nc localhost 1025
T3 - Cliente * recebe: do redirecionador somente * envia: para o servidor somente
$ nc localhost 1026
40
Podemos combinar esses dois sentidos estabelecendo duas rotas simultâneas entre um cli-
ente e um servidor. Cada um com duas conexões estabelecidas, uma para ouvir e outra para
falar. Essa operação inflada desenpenharia um papel bastante semelhante ao papel de um tú-
nel, e pode satisfazer as necessidades daquelas pessoas cujo Netcat não possui o recurso de
tunelamento.
Existe, ainda, uma maneira mais eficaz de simular um túnel com o Netcat envolvendo quatro
terminais (e não seis, como no caso acima), em que a ponta do servidor escuta e fala através
de um centro de redirecionamento com dois clientes, um que fala e outro que escuta. É claro,
permitindo a conectividade bidirecional que buscamos aqui (e que um tunelamento oferceria).
Observe:
T 1 - Servidor
$ nc -l -vv -p 1025
T 2 - Redirecionador
$ nc -l -vv -p 1026 | nc localhost 1025 | nc -l -vv -p 1027
T 3 - Cliente 1
$ nc localhost 1026
T 4 - Cliente 2
$ nc localhost 1027
Repare que em um redirecionamento de conexões, cada uma delas envolvidas é estabelecida

independentemente, ainda que quando uma termine outras se comprometam por problema de
bronken pipe (pipe quebrado). Ainda assim elas são independentes na medida em que cada
uma se estabecelem em momentos diferentes. Um túnel, por sua vez, só se conecta ao servidor
quando receber a conexão do cliente, ligando as duas pontas.
41
Capítulo 9
Tunelamento - OpenSSH e algumas

idéias
9.1 Tunelando com o OpenSSH - Parte 1

O OpenSSH, como já enfatizei, é um aplicativo que só faz conexões que respeitem o protocolo
SSH, e este nos serve para nos permitir acessarmos shell de máquinas remotas com segurança
(tanto de dados quanto de legitimidade do servidor, entre outras dúzias de recursos que promo-
vem segurança - que usuários podem logar remotamente, que endereços IP podem se conectar,
que restrições um acesso tem, etc.). O que temos de lembrar agora, depois de tantos exemplos
com o Netcat, é que quando nos conectarmos com o OpenSSH a um servidor SSH, este servidor
vai estar servindo um shell remoto e vai estar, provavelmente, na porta 22 - mas isso somente se
o servidor na ponta do túnel estiver escutando em SSH. Assim estarei assumindo nos próximos
exercícios.
Os testes vão envolver, em geral, três máquinas - uma para cada nó da operação. Nada me
impediria de forjar a operação toda em uma única máquina (ou duas), como vimos acontecer
nos experimentos com o Netcat. Naquele testes, entretanto, era importante que víssemos o
tunelamento de forma transparente, com os seus integrantes (cliente, servidor e túnel) lado a lado
em terminais. Penso que podemos, estudando agora o tunelamento com o OpenSSH, envolver
em nossos estudos de caso máquinas diferentes, inclusive para representarmos cenários reais
com mais fidelidade. Já sabemos colocar o OpenSSH para escutar em portas, então caso já
não tenham acesso a um servidor SSH nós mesmos podemos montar o nosso (lembre que
podemos tunelar em SSH conexões não SSH até um servidor qualquer, não SSH). Acontece que,
naturalmente, a máquina que vai fazer o túnel também deve ter o OpenSSH instalado, mesmo que
o comando que estabelece o túnel seja dado a partir da máquina cliente.
O OpenSSH, como já enfatizei, é um aplicativo que só faz conexões que respeitem o protocolo
SSH, e este nos serve para nos permitir acessarmos shell de máquinas remotas com segurança
(tanto de dados quanto de legitimidade do servidor, entre outras dúzias de recursos que promo-
vem segurança - que usuários podem logar remotamente, que endereços IP podem se conectar,
que restrições um acesso tem, etc.). O que temos de lembrar agora, depois de tantos exemplos
com o Netcat, é que quando nos conectarmos com o OpenSSH a um servidor SSH, este servidor
vai estar servindo um shell remoto e vai estar, provavelmente, na porta 22 - mas isso somente se
o servidor na ponta do túnel estiver escutando em SSH. Assim estarei assumindo nos próximos
exercícios.
Os testes vão envolver, em geral, três máquinas - uma para cada nó da operação. Nada me
42
impediria de forjar a operação toda em uma única máquina (ou duas), como vimos acontecer
nos experimentos com o Netcat. Naquele testes, entretanto, era importante que víssemos o
tunelamento de forma transparente, com os seus integrantes (cliente, servidor e túnel) lado a lado
em terminais. Penso que podemos, estudando agora o tunelamento com o OpenSSH, envolver
em nossos estudos de caso máquinas diferentes, inclusive para representarmos cenários reais
com mais fidelidade. Já sabemos colocar o OpenSSH para escutar em portas, então caso já
não tenham acesso a um servidor SSH nós mesmos podemos montar o nosso (lembre que
podemos tunelar em SSH conexões não SSH até um servidor qualquer, não SSH). Acontece que,
naturalmente, a máquina que vai fazer o túnel também deve ter o OpenSSH instalado, mesmo que
o comando que estabelece o túnel seja dado a partir da máquina cliente.
O fato de que o comando que estabelece o túnel seja dado pelo cliente é algo relevante. Nos
exemplos que conhecemos e nas experiências que fizemos com o Netcat, o túnel era sempre
estabelecido a partir da própria máquina que intermediaria as duas pontas. Como fazíamos a co-
nexão da máquina local para a própria máquina local, não precisamos sentar em outra cadeira ou
logar remotamente para fazer o túnel, mas nos casos sugeridos de tunelamento real precisaría-
mos de dar o comando de tunelamento em uma outra máquina (presencialmente ou por acesso
remoto). Com o OpenSSH não é diferente, mas o próprio comando de tunelamento traz imbutido
na sintaxe uma conexão remota, de forma que podemos montar o túnel na máquina intermediária
diretamente a partir da máquina cliente. (Como sugeri, o mesmo poderia ser feito com o Netcat,
ainda que não tenhamos visto este caso).
O túnel do OpenSSH tem uma característica especial para nós. Quando estabelecemos o
túnel com um comando remoto, a porta que abrimos para o túnel escutar fica na nossa própria
máquina local, o que é uma mudança de estratégia com relação ao tunelamento regular do Netcat.
Essa estratégia permite que a conexão desde o cliente até o servidor receba o mesmo tratamento
de protocolo, segurança e etc., tendo em vista que uma conexão tunelada normalmente possui
duas fases - a entre o cliente e a entrada do túnel e deste até o servidor. A consequência desta
característica é que quando formos nos conectar ao túnel com o cliente vamos apontar a conexão
para a própria máquina local, na porta que setamos.
Outro detalhe é que quando passado o comando desde o cliente, o túnel é montado e o ter-
minal do cliente recebe a shell deste sistema intermediário. Mas não se passarmos um comando
como aprendemos na página sobre o cliente OpenSSH. Como devem lembrar, podemos passar
um comando para execução automática no lugar de receber uma shell do sistema remoto. Nos
exemplos que mostrarei aqui vou utilizar esse recurso de execução remota automática com o
comando ’sleep’, para contar em segundos o tempo em que o túnel se manterá aberto.

Vamos começar com um exemplo inócuo, mas didático. Ele não representa nenhuma sistua-
ção real, nem parece poder nos servir de qualquer coisa, mas ainda assim me soa conveniente.
Vamos fazer estabelecer uma conexão entre um cliente e um servidor SSH através de um túnel
SSH estando todos na mesma máquina, como fazíamos nos experimentos com Netcat.
Com o OpenSSH já servindo na porta 22, podemos nos livrar de abrir um terminal só para
escutar na porta, como antes (nos exemplos com Netcat) e abrimos somente dois terminais,
ambos representando a máquina cliente. A sintaxe do comando de tunelamento é explicada logo
após o exemplo.
T1 (Cliente) - Se conecta à máquina que intermediará a conexão e abre um túnel:
43
$ ssh localhost -L 1025:localhost:22 -t sleep 120
T2 (Cliente) - Se conecta ao túnel (que abre na máquina local) e sai na ponta do

servidor:
$ ssh localhost -p 1025
O comando dado no terminal T1 pode ser dividido em três partes:

Parte 1: ssh localhost
Este trecho do comando indica a máquina que intermediará a conexão entre as pon-
tas, fazendo o túnel. Esta passagem também poderia ser escrita como ssh usu-
ario_atual@localhost -p 22, que são os valores padrões assumidos quando não
especificados. Já vimos isso na página do cliente OpenSSH, mas vamos entender
melhor o papel do nome de usuário no tunelamento SSH na próxima página.
Parte 2: -L 1025:localhost:22
Esta passagem é o comando de tunelamento propriamente dito. Como foi explicado,

o túnel aberto com OpenSSH começa na própria máquina cliente, e então atravessa
a máquina intermediária até chegar ao servidor. Antes de atingir a máquina interme-
diária fazemos uma conexão à própria máquina local, na porta que setamos para abrir
o túnel, identificada depois do parâmetro de modo de tunelamento -L, no exemplo a
porta 1025. Ou seja, esta porta foi aberta na máquina local, e a máquina indicada a
seguir é o servidor para onde o tunelamento leva, na porta indicada em seguida (no
caso a porta padrão de um servidor mesmo).
Parte 3: -t sleep 120
O parâmetro -t permite a execução de um comando associado à conexão cliente-

maq.intermediária para o estabeleciemento do túnel. Quando um comando é exe-
cutado, como vimos na página do cliente OpenSSH, ao término do qual a conexão
se fecha naturalmente. Como o comando executado no exemplo é um contador de
tempo, a conexão será fechada (e com ela também o túnel feito) ao término da conta-
gem dos segundos dados, no caso 120. Esse recurso permite que vejamos o terminal
(no cliente) que dá o comando de tunelamento ficar em stand by, esperando, como tí-
nhamos nossos terminais de tunelamento com Netcat. Além disso, podemos terminar
a conexão, e assim também o túnel, com um simples <Ctrl>-c e realizarmos um novo
teste.
No primeiro terminal, no momento que executamos o primeiro comando, o OpenSSH,
se já tendo reconhecido o servidor (intermediário), pedirá uma senha para o login.
Como não especificamos nome de usuário, temos de oferecer a senha que o usuário
com o mesmo nome que o nosso possui na máquina remota. Esse é o acesso que
precisamos ter à máquina do meio para executar o comando de tunelamento propria-
mente dito. Como essa máquina é a própria máquina local, no exemplo dado, então
o usuário com o mesmo nome que o nosso é o nosso próprio usuário! A senha a ser
fornecida é, portanto, a nossa senha.
No segundo terminal, ao nos conectarmos através da entrada do túnel na máquina
local ao servidor, neste caso particular também na máquina local, é requerida a senha
44
do usuário com nosso nome no servidor, que normalmente seria remoto, mas que,
mais uma vez, está em nosso própria máquina. Logo, mais um vez, a senha a ser
fornecida no segundo terminal também é a nossa própria senha, a senha do nosso
usuário (com o qual executamos o comando).
Em um caso típico, envolvendo três máquinas, o comando de tunelamento teria o seguinte

formato:
T1 (Cliente = máquina local) - Se conecta à máquina que intermediará a conexão e

abre um túnel:
$ ssh máquina-túnel -L porta-cliente:servidor:porta-servidor -t sleep 120
T2 (Cliente) - Se conecta ao túnel (que abre na máquina local) e sai na ponta do

servidor:
$ ssh cliente -p 1025
Observe como é curioso que, pelo túnel OpenSSH partir do cliente, para nos conectarmos ao
servidor acabamos por fazer um acesso SSH para a nossa própria máquina!

No exemplo que vimos na página anterior, assumiu-se que o usuário com que nos logaríamos
na(s) máquina(s) dos três nós envolvidos porderia e seria o mesmo - e de fato pôde ser, visto que
os três nós estavam na mesma máquina. Como o OpenSSH assume, se não for especificado,
que o usuário a se conectar no shell remoto tem o mesmo nome que o usuário que o executa,
não precisamos em nenhum momento indicar que usuário vamos utilizar, se vamos justamente,
como no exemplo, logar com o nosso próprio nome.
Acontece que muitas vezes não é o caso que o acesso que temos às diferentes máquinas
seja feito através de exatamente os mesmos nomes de usuários. Podemos inclusive ter motivos
para querer nos conectar à nossa própria máquina por algum motivo com outro usuário que não
o nosso, caso o servidor ou o nó intermediário esteja na mesma máquina que o cliente.
Estrito senso, cinco usuários diferentes podem participar do processo de tunelamento com
OpenSSH. Desses, somente dois são especificáveis nos próprios comandos de tunelamento, e
os outros três são:
• usuário que inicializou o servidor OpenSSH, provavelmente o root;
• O usuário que rodar o comando do T1;
• O usuário que rodar o comando do T2;
Os dois especificáveis nos comandos são:
• O usuário com o qual logar na máquina intermediária;
• O usuário com o qual logar no servidor quando dentro da conexão tunelada, cujo login é
logicamente posterior ao login do da máquina intermediária.
45
No primeiro comando, podemos determinar com que usuário vamos nos autenticar na má-
quina intermediária, a que nos tunelará. Lembre que só precisamos nos autenticar nela para
estabelecer o túnel de forma confortável, a partir do cliente. Podemos definí-lo com duas sintaxes
diferentes:
Podemos utilizar a sintaxe usual:
(T1) $ ssh usuário@maquina-tunel porta-cliente:servidor:porta-servidor
Ou indicá-lo com o parâmetro ’ -l ’ que já conhecemos:
(T1) $ ssh -l usuário máquina-tunel porta-cliente:servidor:porta-servidor
No segundo comando, podemos determinar com que usuário vamos nos autenticar no servi-
dor, observe:
(T2) $ ssh usuário@localhost -p porta-cliente
Ou, da mesma maneira, como já vimos:
(T2) $ ssh -l usuário localhost -p porta-cliente
Análogamente, como exisetm três nós envolvidos no tunelamento, podemos envolver até três
diferentes portas de escuta na operação:
• A - A porta em que máquina intermediária escuta para a fazermos um servidor de túnel,

tipicamente a 22;
• B - A porta de entrada do túnel, que vamos designar à nossa máquina, de valor arbitrário.
• C - A porta em que o servidor escuta, tipicamente a 22;
Tendo as letras acima como identificadores das portas descritas, eis aqui a posição em que
cada porta é especificada no primeiro comando:
(T1) $ ssh -l usuário máquina-tunel -p A B:servidor:C
O porta apontada no segundo comando tem , naturalmente, de ser a especificada no T1 para

a entrada do túnel:
(T2) $ ssh -l usuário localhost -p B
PS.: Depois que o túnel for estabelecido com o primeiro comando em um primeiro terminal,
podemos no lugar de fazer uma conexão SSH simples, fazer outro tipo de conexão que fale o
protocolo SSH, como conexões scp, sftp, slogin etc. Podemos, depois que o túnel estiver pronto,
dar um comando no T2 como o seguinte, para, como no exemplo, copiar uma pasta remota por
inteira na máquina local:
$ scp -r -P 1025 localhost:"/pasta-remota/" /pasta-local/
Esta manobra, como sugerida acima, é claramente útil quando se quer copiar arquivos de
uma máquina a qual não se tem acesso direto. Isso pode acontecer, por exemplo, em razão de
problemas de DNS. De qualquer forma, com a técnica acima conseguimos copiar de uma vez o
que em outro caso precisaríamos de primeiramente passar para a máquina intermediária e só
então copiar para a máquina local.
46

9.4.1 Múltiplos túneis com OpenSSH
O OpenSSH tem é preparado para em um único comando poder abrir mais de um túnel
através de uma mesma rota intermediária. Ou seja, sabendo que eu tenho acesso à máquina M
e que esta tem acesso à serviços aos quais não tenho, eu posso estabelecer em um comando
vários túneis que saem da minha máquina e passam pela máquina M, um para cada serviço que
desejo acessar.
O comando utilizado seja uma sintaxe intuitiva para quem entendeu a de um túnel simples.
Primeiramente a conexão à máquina intermediária, depois os comandos de tunelamento. Dado
que Pl é Porta Local, Ps é Porta do Serviço, S é Serviço, o túnel e L é login:
$ ssh servidor-tunel -L Pl1:S1:Ps1 -L Pl2:S2:Ps2 -L Pl3:S3:Ps3 ...
9.4.2 Tunelando outros protocolos

Quando começamos a Parte 1 de nossos estudos sobre tunelamento com o OpenSSH, pro-
pus que utilizássemos o OpenSSH para tunelar conexões SSH, portanto envolvendo um cliente
e um servidor também SSH. Como já havia sugerido desde o começo do curso, podemos utilizar
o OpenSSH (assim como vimos com o Netcat) para tunelar todo tipo de conexão de quaisquer
protocolos, o que pode ser bem útil caso precisemos de segurança de dados, por exemplo, ou
simplismente de um túnel mais consistente e seguro do que um túnel Netcat. Para tanto preci-
samos, da mesma maneira, tanto de um servidor quanto de um cliente falando a mesma língua,
enquanto o OpenSSH os conecta em um túnel SSH sem que os dados sejam afetados. Lembrem-
se que o túnel não precisa compreender o que está passando por ele, ao menos no sentido que
nos cabe aqui.
Na lição de tunelamento com Netcat experimentamos tunelar SSH por dentro de um túnel Net-
cat. Agora vamos fazer o contrário. Vamos experimentar tunelar em SSH uma conexão simples
de Netcat, utilizando ambas as ferramentas de que ficamos tão íntimos recentemente.
Abra três terminais e, se puder, se conecte à três máquinas distintas com o OpenSSH. Vamos
dizer que na máquina 3 é mantido consistentemente um servidor de protocolo em claro na porta
2000, com o Netcat. Queremos nos conectar a este serviço de nossa máquina local, a máquina
1, e para isso precisamos de ser tunelados lá de fora de nossa rede interna através da máquina
2, que está livre e à qual temos acesso. Imagine. Poderíamos fazê-lo logo com um tunelamento
Netcat, mas especificamente agora vamos transferir dados pessoais ou sigilosos que alguém
da nossa rede interna pode querer capturar. Preferimos, portanto, enviar os dados por SSH ao
menos até a máquina 2, a partir da qual não temos problema em tranferir dados em claro até o
servidor Netcat. Então:
Terminal 2:
* Se conecta à máquina 2, por SSH, e estabelece um túnel para o serviço (porta 2000) na máquina
três a partir de uma porta arbitrária da máquina 1 (digamos, 1025).
$ ssh máquina2 -L 1025:máquina3:2000 -t cat -
Terminal 1:
* Estabelece uma conexão em claro com o túnel criptogrado na máquina local (1) na porta 1025
e sai no serviço Netcat na porta 2000 da máquina 3.
47
$ nc localhost 1025
Observe o uso de ’-t cat -’ no comando do terminal 2 no lugar de ’-t sleep n’. É uma alternativa
para quem quiser manter o túnel aberto indefinidademente sem que haja uma contagem tempo
para o fechamento da conexão.
O mesmo que fizemos na lição de tunelamento com o Netcat pode ser repetido aqui com um
túnel SSH, que era o exercício de tunelar uma conexão que um aplicativo que não seja modo
texto, como uma conexão HTTP, que um browser fala.
9.4.3 Concatenado túneis

Nem precisaria dizer que podemos, se quisermos, concatenar a saída de um túnel com a
entrada de outro. Ou seja, re-tunelar a conexão que chegar de um túnel em outro túnel. Para
tanta basta, já é claro, que a porta do serviço para onde um túnel leva seja a porta de entrada
de um outro túnel. Isso não é também uma capacidade exclusiva do OpenSSH, já que um túnel
não precisa saber se a conexão que recebe é tunelada ou não. Todo tipo de túneis podem estar
envolvidos, desde que o cliente fale o mesmo protocolo do servidor na ponta final para que a
conexão aconteca adequadamente.
Como um exercício desta idéia, vamos concatenar um túnel SSH com um túnel Netcat e
atravessar por eles uma conexão SSH até um servidor na ponta do túnel Netcat. Essa operação
poderia envolver até quatro máquinas, mas vamos fazer deixar o servidor SSH na nossa própria
máquina, a máquina cliente e ao conectarmos seremos tunelados por outras duas de volta a
máquina local. Para tanto vamos precisar de três máquinas. Vamos assumir que a máquina 1 é
a máquina local, cliente e servidora, a máquina 2 é a que tunela em SSH e a máquina 3 a que
tunela em Netcat. Vou assumir que abrimos três terminais, cada qual associado a uma máquina.
No entanto, vamos dar os comandos todos remotamente às duas máquinas a partir da máquina
local. Assumo também que o servidor OpenSSH já está rodando na máquina 1 na porta 22.
Terminal 2 (túnel SSH):
$ ssh máquina2 -L 1025:maquina3:1026 -t cat -

Terminal 3 (túnel Netcat):
$ ssh máquina3 "nc -L máquina1:22 -p 1026 && -t cat -"

Terminal 1 (Cliente SSH):

E eis é uma forma bastante sofisticada e confusa de se utilizar o console de uma máquina,
caímos em uma sessão modo texto de nossa própria máquina!
48
Capítulo 10
Tunelamento em HTTP
Nessa lição teremos uma visão geral a respeito do que é o SpamAssassin e um pouco de sua
origem.
10.1 Corkscrew - Parte 1

Como já foi comentado, tanto na introdução quanto na instalação, o Corkscrew é uma fer-
ramenta que tunela conexões SSH para além e para aquém do proxy em HTTP. Depois que o
Corkcrew estiver configurado, se estiver bem configurado, nem precisamos lembrar que ele está
operando para conectar, simplismente fazemos nossas conexões com OpenSSH normalmente, e
elas vão ser tratadas automática e invisivelmente pelo Corkscrew.
Corkscrew significa, em inglês, ’saca-rolhas’, que sugere seu papel de abrir uma rota. Se-
gundo o site de seu criador, os proxies em que o Corkscrew já foi testado com sucesso são:
• Gauntlet
• CacheFlow
• JunkBuster
• Squid
• Apache’s mod_proxy
Para automatizar a tarefa do Corkscrew, precisamos editar um único arquivo que vai fazer o
OpenSSH sempre chamá-lo antes de tentar estabelecer a conexão por conta própria. Com o
Corkscrew já instalado e logados com o usuário com que pretendemos nos conectar, vamos criar
o arquivo /.ssh/config:
$ vim ~/.ssh/config
E completem com os dados:
Host *
ProxyCommand corkscrew http-proxy.com porta %h %p
49
Com a diretiva host definimos para quais máquinas a configuração que se segue vai valer.
Podemos, em geral, simplismente setar *, que vale para quaisquer hosts.
ProxyCommand é a diretiva que vai chamar o Corkscrew par tunelar a conexão atual pelo
proxy dado na sua porta (que também deve ser indicada). %h e %p são variáveis recebidas
como argumentos do comando OpenSSH que estamos dando, respectivamente, o host e a porta
de destino.
O normal é que possamos simplismente utilizar o comando ssh como se não houvesse proxy
algum em nosso caminho. Experimente.
10.2 Corkscrew - Parte 2

Note que este arquivo de configuração não é do Corkscrew, e sim do próprio OpenSSH. Ele
é, na verdade, simplismente o arquivo de configuração pessoal de cada usuário, em comple-
mento ao /etc/ssh/ssh_config, onde podemos setar diretivas suplementares ao arquivo global, e
personalizar algumas opções. Naturalmente, outros programas que se utilizam do OpenSSH vão
requerer uma configuração especial no /.ssh/config, como por exemplo o proxytunnel, que não
cobrimos neste curso.
A diretiva ProxyCommand é, é claro, do próprio OpenSSH, e chama o Corkscrew para atra-

vessar o proxy dado (no modelo dado, o http-proxy.com) na porta indicada (por exemplo, 8080 ou
3128 que o Squid poderia usar, etc.). %h e %p são variáveis recebidas por parâmetro transparen-
temente, e correspondem respectivamente ao host e à porta visados na conexão a ser tunelada
para fora.
PS.: Quem tiver interesse pode aproveitar o embalo e aprender a utilizar o /.ssh/config para
configurações úteis no dia-a-dia, como automatizar tunelamentos SSH ou conexões simples. Por
exemplo, as linhas abaixo automatizam a conexão para minha-casa.no-ip.org. Quando digitarmos
ssh casa o comando é convertido adequadamente:
Host casa
HostName minha-casa.no-ip.org
Port 443
User tomas
Adicinando a linha a baixo estaremos a um passo de uma automatização igualmente grande
de um comando de tunelamento (no caso utilizaria o Host casa como máquina intermediária para
o túnel. Para terminar de fazê-lo, os interessados(as) podem consultar o manual da configurações
do OpenSSH com o comando ’ man ssh_config ’.
LocalForward localhost:1025 servidor:porta
10.3 HTTPTunnel - Parte 1

A função deste software é basicamente mesma que a do Corkscrew, encapsular uma conexão
em HTTP para atravessar um proxy HTTP restritivo. A diferença é que o Corkscrew é distinado
ao tunelamento exclusivamente de SSH, enquanto o HTTPTunnel se propõe a tunelar todo tipo
de protocolo em HTTP.
50
Para que o HTTPTunnel funcione, é necessário que tanto o servidor quanto o cliente estejam
atrás de uma interface do HTTP. Ou seja, ambas as máquina devem ter o software instalado e
rodando. Isso certamente é uma restrição ao uso se lembrarmos de como podíamos nos tunelar
para qualquer canto sem que o servidor sequer imaginasse por onde passara a conexão do cli-
ente.
O comando do lado do servidor tem o formato:

hts -F host:porta_do_serviço porta_do_túnel_serv
O comando do lado do cliente tem o formato:
htc -F porta_do_tunel_cliente -P proxy:porta_do_proxy servidor:porta_do_tunel_serv
Invistam algum tempo tentando intuir os dois comando acima.
10.4 HTTPTunnel - Parte 2

Vamos dizer que queiramos realizar uma conexão qualquer cujo protocolo ou porta de destino
sejam bloqueados. Como um modelo didático, vamos usar o Netcat. Desejamos acessar um
servidor na internet, o servidor.externo.net que escuta na porta 1027. O serviço pode ter sido
inciado com um comando como:
$ nc -l -p 1027
Desejamos acessá-lo com nosso Netcat cliente. No entanto, existe um proxy restritivo na
saída de nossa rede, o proxy.rede.local.org, pelo qual só passam conexões HTTP, todas pela
porta, digamos 3128. Nosso servidor deve iniciar o HTTP-Tunnel com o comando hts (http tunnel
server), abrindo uma porta de escuta (arbitrária, digamos, 3000) associada a porta real do ser-
viço, que, como sabemos, é a porta 1027.
O cliente, nós, devemos iniciar o HTTP-Tunnel com o comando htc (http tunnel client), abrindo
uma porta (arbitrária, digamos, 1500) local, de onde a conexão vai ser enviada para a porta de
escuta do servidor passando pelo proxy na sua porta, no caso, a porta 3128 do lado interno do
proxy proxy.rede.local.org. Os comandos de tunelamento serão:
HTTPTunnel - SERVIDOR
$ hts -F localhost:1027 3000
HTTPTunnel - CLIENTE
$ htc -F 1500 -P proxy.rede.local.org:3128 servidor.externo.net:3000
Por fim, com o esquema de túneis preparado, fazemos a conexão propriamente dita, (como
clientes, obviamente):
$ nc -vv localhost 1500
51
É claro que em um cenário típico, se a conexão a ser realizada tem o ser regularmente, o es-
quema de túneis já vai estar preparado, estático. Essa estrutura não precisa ser desmoantada
por que um conexão foi fechada, um servidor, especialmente, pode manter o seu túnel funcio-
nando permanentemente e divulgar sua porta já como sendo a porta aberta com o hts.
52
Capítulo 11
Últimas notas
11.1 Tunelamento reverso

Como já explicamos brevemente, a técnica de tunelamento reverso permite que, de uma má-
quina, setemos um túnel não para reapontar uma porta para o serviço de uma terceira máquima,
mas sim para que uma máquina monte um túnel que retorna a conexão para ela mesma. Pode-
mos, com tunelamento reverso, permitir acesso à uma rede interna a partir de fora e atrave? de
um firewall restritivo, visto que a conexão autorizada é aquela do tunelamento entre a máquina
intermediária, fora da rede, e o servidor, que dispara o túnel reverso. O túnel reverso deve ser
iniciado, portanto, do lado do servidor.
O parâmetro do OpenSSH que constitui um tunelamento reverso é -R, claramente de Reverse.

O uso do parâmetro -R exclui a possibilidade do uso o -L regular, que vem de Local. Enfim, a
ordem de um comando de tunelamento reverso com o OpenSSH é inversa à de um comando de
tunelamento regular: primeiro a porta a ser aberta na máquina intermediária, depois a porta do
serviço local que vai receber as conexões tuneladas e, por fim, o comando de conexão à máquina
intermediária.
Para fazer um túnel reverso com o OpenSSH, a partir do servidor dê um comando do formato:
SERVIDOR:
$ ssh -R 1025:localhost:22 maquina-intermediaria -t sleep 999
E, com o túnel montado, experimente, a partir da máquina intermediária, conectar-se ao túnel
MÁQUINA INTERMEDIÁRIA:

E paramos diretamente no servidor. O mesmo pode ser feito a partir de outras máquinas cli-
entes, desde que uma diretriz esteja presente no arquivo de configuração do servidor OpenSSH,
o /etc/ssh/sshd_config, da máquina intermediária. Experimente adicionar a linha
GatewayPorts yes
53
e tente fazer o mesmo a partir de outras máquinas. A utilidade é auto-evidente.

Existem outras ferramentas capazes de realizar tunelamento reverso, como a rrs.
54

Tune Lamento

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tune Lamento

Enviado por

Direitos autorais:

Formatos disponíveis

Tunelamento

I Sobre essa Apostila 2

7 Iniciação prática - OpenSSH 32

9 Tunelamento - OpenSSH e algumas idéias 41

Sobre essa Apostila

Informações adicionais podem ser obtidas através do email ouvidoria@cdtc.org.br, ou da

O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-

Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário e

• Licenças para cópia de material disponível

• Os 10 mandamentos do aluno de Educação a Distância

• Como participar dos foruns e da wikipédia

Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br).

Os 10 mandamentos do aluno de educação online

• 1. Acesso à Internet: ter endereço eletrônico, um provedor e um equipamento adequado é

• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-

• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-

• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seus

• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre.

• 8. Flexibilidade e adaptação: requisitos necessário à mudança tecnológica, aprendizagens

• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente é

Como participar dos fóruns e Wikipédia

Você tem um problema e precisa de ajuda?

Podemos te ajudar de 2 formas:

A segunda forma se dá pelas Wikis:

• Página principal da Wiki - http://pt.wikipedia.org/wiki/

Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!

• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;

• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;

• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.

Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.

O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivos

• gosta que lhe façam perguntas adicionais;

• dá uma ajuda complementar para encorajar um estudante em dificuldade;

• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;

• ajuda o estudante a alcançar os seus objetivos;

• é flexível quando necessário;

• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,

• escreve todas as correções de forma legível e com um nível de pormenorização adequado;

• acima de tudo, devolve os trabalhos rapidamente;

2.2 Publico Alvo

• Lição 2 - Instalação e Configuração

• Iniciativa e autonomia no processo de aprendizagem e de produção de conhecimento;

Perguntas Frequetes: http://www.hylafax.org/content/FAQ

How To: http://www.hylafax.org/content/How-To

Lista de Modens compativeis: http://www.hylafax.org/modem

4.1 O que é tunelamento

1. o ponto (IP/porta) de onde a conexão pré-estabalecida parte;

2. o ponto (IP/porta) de onde a conexão a ser tunelada parte;

3. o ponto (IP/porta) para onde o tunelamento leva.

Se o destino especificado de uma conexão (origem no Nó 1) for o ponto em que um túnel

4.2 Pra que serve tunelamento

• Proteger dados através de uma conexão criptografada não suportada localmente;

• Conectar-se a um destino bloqueado para conexão direta;

Outras razões que poderiam ser levantadas são:

• Praticidade na realização de uma conexão.

4.3 O que vamo conhecer

• Netcat (canivete suíco TCP/IP)

• OpenSSH (shell remoto/túnel criptográfico)

• Httptunnel (túnel http para atravessar firewalls)

• Corkscrew (tunela SSH em http para atravessar firewalls)

4.4 Quando usar

• Aplicativos de tunelamento por criptografia;

• Aplicativos de tunelamento para contornar firewalls.

4.5 Contornando Firewalls