Tunelamento

Sumário
I Sobre essa Apostila 3
II Informações Básicas 5
III GNU Free Documentation License 10
IV Tunelamento 19
1 Tunelamento 20
2 Plano de ensino 21
2.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Publico Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Bibliograﬁa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Material de apoio 24
4 Introdução 25
4.1 O que é tunelamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Pra que serve tunelamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 O que vamos conhecer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Quando usar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Contornando Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6 Criptografando Conexões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7 Tunelamento Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.8 Acesso indireto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Instalando as ferramentas 30
5.1 Instalando o Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Instalando o OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 Instalando o Corkscrew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF
5.4 Instalando o HTTPTunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6 Iniciação prática 33
6.1 Netcat - Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Netcat - Conectando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Netcat - Servindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4 Netcat - Piruetas (opcional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4.1 Piruetas do Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4.2 Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4.3 Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4.4 Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4.5 Caso 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.4.6 Caso 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.4.7 Caso 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4.8 Caso 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4.9 Opções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Iniciação prática - OpenSSH 42
7.1 OpenSSH - Conectando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1.1 Autenticação do usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1.2 Legitimação do servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 OpenSSH - Servindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2.1 Porta de escuta e outras conﬁgurações . . . . . . . . . . . . . . . . . . . . . 44
8 Tunelamento - Netcat 46
8.1 Tunelando com o Netcat - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4 Simulando um túnel com redirecionamentos Netcat (opcional) . . . . . . . . . . . . 48
8.4.1 Redirecionamentos Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9 Tunelamento - OpenSSH e algumas idéias 51
9.1 Tunelando com o OpenSSH - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.4.1 Múltiplos túneis com OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.4.2 Tunelando outros protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.4.3 Concatenando túneis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10 Tunelamento em HTTP 58
10.1 Corkscrew - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2 Corkscrew - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.3 HTTPTunnel - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.4 HTTPTunnel - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
11 Últimas notas 62
11.1 Tunelamento reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2

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 (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 oﬁcial).
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 serão bem-vindas a qualquer hora.
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
vêm sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto com
outros parceiros institucionais, e 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 dos 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 do 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 modiﬁcar 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 se fazendo ser respeitado pelos mesmos;
• 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 reﬂete 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 Fórum 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
GNU Free Documentation License
10

(Traduzido pelo João S. O. Bueno através do CIPSGA em 2001)
Esta é uma tradução não oficial da Licença de Documentação Livre GNU em Português Brasi-
leiro. Ela não é publicada pela Free Software Foundation, e não se aplica legalmente a distribuição
de textos que usem a GFDL - apenas o texto original em Inglês da GNU FDL faz isso. Entretanto,
nós esperamos que esta tradução ajude falantes de português a entenderem melhor a GFDL.
This is an unofficial translation of the GNU General Documentation License into Brazilian Por-
tuguese. It was not published by the Free Software Foundation, and does not legally state the
distribution terms for software that uses the GFDL–only the original English text of the GFDL does
that. However, we hope that this translation will help Portuguese speakers understand the GFDL
better.
Licença de Documentação Livre GNU Versão 1.1, Março de 2000
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
É permitido a qualquer um copiar e distribuir cópias exatas deste documento de licença, mas
não é permitido alterá-lo.
INTRODUÇÃO
O propósito desta Licença é deixar um manual, livro-texto ou outro documento escrito "livre"no
sentido de liberdade: assegurar a qualquer um a efetiva liberdade de copiá-lo ou redistribui-lo,
com ou sem modificações, comercialmente ou não. Secundariamente, esta Licença mantém
para o autor e editor uma forma de ter crédito por seu trabalho, sem ser considerado responsável
pelas modificações feitas por terceiros.
Esta Licença é um tipo de "copyleft"("direitos revertidos"), o que significa que derivações do
documento precisam ser livres no mesmo sentido. Ela complementa a GNU Licença Pública Ge-
ral (GNU GPL), que é um copyleft para software livre.
Nós fizemos esta Licença para que seja usada em manuais de software livre, por que software
livre precisa de documentação livre: um programa livre deve ser acompanhado de manuais que
provenham as mesmas liberdades que o software possui. Mas esta Licença não está restrita a
manuais de software; ela pode ser usada para qualquer trabalho em texto, independentemente
do assunto ou se ele é publicado como um livro impresso. Nós recomendamos esta Licença prin-
cipalmente para trabalhos cujo propósito seja de introdução ou referência.
APLICABILIDADE E DEFINIÇÕES
Esta Licença se aplica a qualquer manual ou outro texto que contenha uma nota colocada pelo
detentor dos direitos autorais dizendo que ele pode ser distribuído sob os termos desta Licença.
O "Documento"abaixo se refere a qualquer manual ou texto. Qualquer pessoa do público é um
11

licenciado e é referida como "você".
Uma "Versão Modificada"do Documento se refere a qualquer trabalho contendo o documento
ou uma parte dele, quer copiada exatamente, quer com modificações e/ou traduzida em outra
língua.
Uma "Seção Secundária"é um apêndice ou uma seção inicial do Documento que trata ex-
clusivamente da relação dos editores ou dos autores do Documento com o assunto geral do
Documento (ou assuntos relacionados) e não contém nada que poderia ser incluído diretamente
nesse assunto geral (Por exemplo, se o Documento é em parte um livro texto de matemática, a
Seção Secundária pode não explicar nada de matemática).
Essa relação poderia ser uma questão de ligação histórica com o assunto, ou matérias relaci-
onadas, ou de posições legais, comerciais, filosóficas, éticas ou políticas relacionadas ao mesmo.
As "Seções Invariantes"são certas Seções Secundárias cujos títulos são designados, como
sendo de Seções Invariantes, na nota que diz que o Documento é publicado sob esta Licença.
Os "Textos de Capa"são certos trechos curtos de texto que são listados, como Textos de Capa
Frontal ou Textos da Quarta Capa, na nota que diz que o texto é publicado sob esta Licença.
Uma cópia "Transparente"do Documento significa uma cópia que pode ser lida automatica-
mente, representada num formato cuja especificação esteja disponível ao público geral, cujos
conteúdos possam ser vistos e editados diretamente e sem mecanismos especiais com editores
de texto genéricos ou (para imagens compostas de pixels) programas de pintura genéricos ou
(para desenhos) por algum editor de desenhos grandemente difundido, e que seja passível de
servir como entrada a formatadores de texto ou para tradução automática para uma variedade
de formatos que sirvam de entrada para formatadores de texto. Uma cópia feita em um formato
de arquivo outrossim Transparente cuja constituição tenha sido projetada para atrapalhar ou de-
sencorajar modificações subsequentes pelos leitores não é Transparente. Uma cópia que não é
"Transparente"é chamada de "Opaca".
Exemplos de formatos que podem ser usados para cópias Transparentes incluem ASCII sim-
ples sem marcações, formato de entrada do Texinfo, formato de entrada do LaTex, SGML ou XML
usando uma DTD disponibilizada publicamente, e HTML simples, compatível com os padrões, e
projetado para ser modificado por pessoas. Formatos opacos incluem PostScript, PDF, formatos
proprietários que podem ser lidos e editados apenas com processadores de texto proprietários,
SGML ou XML para os quais a DTD e/ou ferramentas de processamento e edição não estejam
disponíveis para o público, e HTML gerado automaticamente por alguns editores de texto com
finalidade apenas de saída.
A "Página do Título"significa, para um livro impresso, a página do título propriamente dita,
mais quaisquer páginas subsequentes quantas forem necessárias para conter, de forma legível,
o material que esta Licença requer que apareça na página do título. Para trabalhos que não
tenham uma página do título, "Página do Título"significa o texto próximo da aparição mais proe-
minente do título do trabalho, precedendo o início do corpo do texto.
12

FAZENDO CÓPIAS EXATAS
Você pode copiar e distribuir o Documento em qualquer meio, de forma comercial ou não
comercial, desde que esta Licença, as notas de copyright, e a nota de licença dizendo que esta
Licença se aplica ao documento estejam reproduzidas em todas as cópias, e que você não acres-
cente nenhuma outra condição, quaisquer que sejam, às desta Licença.
Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou confecção de
cópias subsequentes das cópias que você fizer ou distribuir. Entretanto, você pode aceitar com-
pensação em troca de cópias. Se você distribuir uma quantidade grande o suficiente de cópias,
você também precisa respeitar as condições da seção 3.
Você também pode emprestar cópias, sob as mesmas condições colocadas acima, e também
pode exibir cópias publicamente.
FAZENDO CÓPIAS EM QUANTIDADE
Se você publicar cópias do Documento em número maior que 100, e a nota de licença do
Documento obrigar Textos de Capa, você precisará incluir as cópias em capas que tragam, clara
e legivelmente, todos esses Textos de Capa: Textos de Capa da Frente na capa da frente, e
Textos da Quarta Capa na capa de trás. Ambas as capas também precisam identificar clara e
legivelmente você como o editor dessas cópias. A capa da frente precisa apresentar o título com-
pleto com todas as palavras do título igualmente proeminentes e visíveis. Você pode adicionar
outros materiais às capas. Fazer cópias com modificações limitadas às capas, tanto quanto estas
preservem o título do documento e satisfaçam a essas condições, pode ser tratado como cópia
exata em outros aspectos.
Se os textos requeridos em qualquer das capas for muito volumoso para caber de forma
legível, você deve colocar os primeiros (tantos quantos couberem de forma razoável) na capa
verdadeira, e continuar os outros nas páginas adjacentes.
Se você publicar ou distribuir cópias Opacas do Documento em número maior que 100, você
precisa ou incluir uma cópia Transparente que possa ser lida automaticamente com cada cópia
Opaca, ou informar, em ou com, cada cópia Opaca a localização de uma cópia Transparente
completa do Documento acessível publicamente em uma rede de computadores, à qual o público
usuário de redes tenha acesso a download gratuito e anônimo utilizando padrões públicos de
protocolos de rede. Se você utilizar o segundo método, você precisará tomar cuidados razoavel-
mente prudentes, quando iniciar a distribuição de cópias Opacas em quantidade, para assegurar
que esta cópia Transparente vai permanecer acessível desta forma na localização especificada
por pelo menos um ano depois da última vez em que você distribuir uma cópia Opaca (direta-
mente ou através de seus agentes ou distribuidores) daquela edição para o público.
É pedido, mas não é obrigatório, que você contate os autores do Documento bem antes de
redistribuir qualquer grande número de cópias, para lhes dar uma oportunidade de prover você
com uma versão atualizada do Documento.
13

MODIFICAÇÕES
Você pode copiar e distribuir uma Versão Modificada do Documento sob as condições das se-
ções 2 e 3 acima, desde que você publique a Versão Modificada estritamente sob esta Licença,
com a Versão Modificada tomando o papel do Documento, de forma a licenciar a distribuição
e modificação da Versão Modificada para quem quer que possua uma cópia da mesma. Além
disso, você precisa fazer o seguinte na versão modificada:
A. Usar na Página de Título (e nas capas, se houver alguma) um título distinto daquele do Do-
cumento, e daqueles de versões anteriores (que deveriam, se houvesse algum, estarem listados
na seção "Histórico do Documento"). Você pode usar o mesmo título de uma versão anterior se
o editor original daquela versão lhe der permissão;
B. Listar na Página de Título, como autores, uma ou mais das pessoas ou entidades responsá-
veis pela autoria das modificações na Versão Modificada, conjuntamente com pelo menos cinco
dos autores principais do Documento (todos os seus autores principais, se ele tiver menos que
cinco);
C. Colocar na Página de Título o nome do editor da Versão Modificada, como o editor;
D. Preservar todas as notas de copyright do Documento;
E. Adicionar uma nota de copyright apropriada para suas próprias modificações adjacente às
outras notas de copyright;
F. Incluir, imediatamente depois das notas de copyright, uma nota de licença dando ao público
o direito de usar a Versão Modificada sob os termos desta Licença, na forma mostrada no tópico
abaixo;
G. Preservar nessa nota de licença as listas completas das Seções Invariantes e os Textos de
Capa requeridos dados na nota de licença do Documento;
H. Incluir uma cópia inalterada desta Licença;
I. Preservar a seção entitulada "Histórico", e seu título, e adicionar à mesma um item dizendo
pelo menos o título, ano, novos autores e editor da Versão Modificada como dados na Página de
Título. Se não houver uma sessão denominada "Histórico"no Documento, criar uma dizendo o
título, ano, autores, e editor do Documento como dados em sua Página de Título, então adicionar
um item descrevendo a Versão Modificada, tal como descrito na sentença anterior;
J. Preservar o endereço de rede, se algum, dado no Documento para acesso público a uma
cópia Transparente do Documento, e da mesma forma, as localizações de rede dadas no Docu-
mento para as versões anteriores em que ele foi baseado. Elas podem ser colocadas na seção
"Histórico". Você pode omitir uma localização na rede para um trabalho que tenha sido publicado
pelo menos quatro anos antes do Documento, ou se o editor original da versão a que ela se refira
der sua permissão;
K. Em qualquer seção entitulada "Agradecimentos"ou "Dedicatórias", preservar o título da
14

seção e preservar a seção em toda substância e fim de cada um dos agradecimentos de contri-
buidores e/ou dedicatórias dados;
L. Preservar todas as Seções Invariantes do Documento, inalteradas em seus textos ou em
seus títulos. Números de seção ou equivalentes não são considerados parte dos títulos da seção;
M. Apagar qualquer seção entitulada "Endossos". Tal sessão não pode ser incluída na Versão
Modificada;
N. Não reentitular qualquer seção existente com o título "Endossos"ou com qualquer outro
título dado a uma Seção Invariante.
Se a Versão Modificada incluir novas seções iniciais ou apêndices que se qualifiquem como
Seções Secundárias e não contenham nenhum material copiado do Documento, você pode optar
por designar alguma ou todas aquelas seções como invariantes. Para fazer isso, adicione seus
títulos à lista de Seções Invariantes na nota de licença da Versão Modificada. Esses títulos preci-
sam ser diferentes de qualquer outro título de seção.
Você pode adicionar uma seção entitulada "Endossos", desde que ela não contenha qual-
quer coisa além de endossos da sua Versão Modificada por várias pessoas ou entidades - por
exemplo, declarações de revisores ou de que o texto foi aprovado por uma organização como a
definição oficial de um padrão.
Você pode adicionar uma passagem de até cinco palavras como um Texto de Capa da Frente
, e uma passagem de até 25 palavras como um Texto de Quarta Capa, ao final da lista de Textos
de Capa na Versão Modificada. Somente uma passagem de Texto da Capa da Frente e uma de
Texto da Quarta Capa podem ser adicionados por (ou por acordos feitos por) qualquer entidade.
Se o Documento já incluir um texto de capa para a mesma capa, adicionado previamente por
você ou por acordo feito com alguma entidade para a qual você esteja agindo, você não pode
adicionar um outro; mas você pode trocar o antigo, com permissão explícita do editor anterior que
adicionou a passagem antiga.
O(s) autor(es) e editor(es) do Documento não dão permissão por esta Licença para que seus
nomes sejam usados para publicidade ou para assegurar ou implicar endossamento de qualquer
Versão Modificada.
COMBINANDO DOCUMENTOS
Você pode combinar o Documento com outros documentos publicados sob esta Licença, sob
os termos definidos na seção 4 acima para versões modificadas, desde que você inclua na com-
binação todas as Seções Invariantes de todos os documentos originais, sem modificações, e liste
todas elas como Seções Invariantes de seu trabalho combinado em sua nota de licença.
O trabalho combinado precisa conter apenas uma cópia desta Licença, e Seções Invariantes
Idênticas com multiplas ocorrências podem ser substituídas por apenas uma cópia. Se houver
múltiplas Seções Invariantes com o mesmo nome mas com conteúdos distintos, faça o título de
15

cada seção único adicionando ao final do mesmo, em parênteses, o nome do autor ou editor
origianl daquela seção, se for conhecido, ou um número que seja único. Faça o mesmo ajuste
nos títulos de seção na lista de Seções Invariantes nota de licença do trabalho combinado.
Na combinação, você precisa combinar quaisquer seções entituladas "Histórico"dos diver-
sos documentos originais, formando uma seção entitulada "Histórico"; da mesma forma combine
quaisquer seções entituladas "Agradecimentos", ou "Dedicatórias". Você precisa apagar todas as
seções entituladas como "Endosso".
COLETÂNEAS DE DOCUMENTOS
Você pode fazer uma coletânea consitindo do Documento e outros documentos publicados
sob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos com
uma única cópia incluida na coletânea, desde que você siga as regras desta Licença para cópia
exata de cada um dos Documentos em todos os outros aspectos.
Você pode extrair um único documento de tal coletânea, e distribuí-lo individualmente sob
esta Licença, desde que você insira uma cópia desta Licença no documento extraído, e siga esta
Licença em todos os outros aspectos relacionados à cópia exata daquele documento.
AGREGAÇÃO COM TRABALHOS INDEPENDENTES
Uma compilação do Documento ou derivados dele com outros trabalhos ou documentos se-
parados e independentes, em um volume ou mídia de distribuição, não conta como uma Ver-
são Modificada do Documento, desde que nenhum copyright de compilação seja reclamado pela
compilação. Tal compilação é chamada um "agregado", e esta Licença não se aplica aos outros
trabalhos auto-contidos compilados junto com o Documento, só por conta de terem sido assim
compilados, e eles não são trabalhos derivados do Documento.
Se o requerido para o Texto de Capa na seção 3 for aplicável a essas cópias do Documento,
então, se o Documento constituir menos de um quarto de todo o agregado, os Textos de Capa
do Documento podem ser colocados em capas adjacentes ao Documento dentro do agregado.
Senão eles precisarão aparecer nas capas de todo o agregado.
TRADUÇÃO
Tradução é considerada como um tipo de modificação, então você pode distribuir traduções
do Documento sob os termos da seção 4. A substituição de Seções Invariantes por traduções
requer uma permissão especial dos detentores do copyright das mesmas, mas você pode incluir
traduções de algumas ou de todas as Seções Invariantes em adição às versões orignais dessas
Seções Invariantes. Você pode incluir uma tradução desta Licença desde que você também in-
clua a versão original em Inglês desta Licença. No caso de discordância entre a tradução e a
16

versão original em Inglês desta Licença, a versão original em Inglês prevalecerá.
TÉRMINO
Você não pode copiar, modificar, sublicenciar, ou distribuir o Documento exceto como expres-
samente especificado sob esta Licença. Qualquer outra tentativa de copiar, modificar, sublicen-
ciar, ou distribuir o Documento é nula, e resultará automaticamente no término de seus direitos
sob esta Licença. Entretanto, terceiros que tenham recebido cópias, ou direitos de você sob esta
Licença não terão suas licenças terminadas, tanto quanto esses terceiros permaneçam em total
acordo com esta Licença.
REVISÕES FUTURAS DESTA LICENÇA
A Free Software Foundation pode publicar novas versões revisadas da Licença de Documen-
tação Livre GNU de tempos em tempos. Tais novas versões serão similares em espirito à versão
presente, mas podem diferir em detalhes ao abordarem novos porblemas e preocupações. Veja
http://www.gnu.org/copyleft/.
A cada versão da Licença é dado um número de versão distinto. Se o Documento especificar
que uma versão particular desta Licença "ou qualquer versão posterior"se aplica ao mesmo, você
tem a opção de seguir os termos e condições daquela versão específica, ou de qualquer versão
posterior que tenha sido publicada (não como rascunho) pela Free Software Foundation. Se o
Documento não especificar um número de Versão desta Licença, você pode escolher qualquer
versão já publicada (não como rascunho) pela Free Software Foundation.
ADENDO: Como usar esta Licença para seus documentos
Para usar esta Licença num documento que você escreveu, inclua uma cópia desta Licença
no documento e ponha as seguintes notas de copyright e licenças logo após a página de título:
Copyright (c) ANO SEU NOME.
É 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 publicada pela Free Soft-
ware Foundation; com as Seções Invariantes sendo LISTE SEUS TÍTULOS, com os Textos da
Capa da Frente sendo LISTE, e com os Textos da Quarta-Capa sendo LISTE. Uma cópia da li-
cença está inclusa na seção entitulada "Licença de Documentação Livre GNU".
Se você não tiver nenhuma Seção Invariante, escreva "sem Seções Invariantes"ao invés de
dizer quais são invariantes. Se você não tiver Textos de Capa da Frente, escreva "sem Textos de
Capa da Frente"ao invés de "com os Textos de Capa da Frente sendo LISTE"; o mesmo para os
Textos da Quarta Capa.
Se o seu documento contiver exemplos não triviais de código de programas, nós recomenda-
mos a publicação desses exemplos em paralelo sob a sua escolha de licença de software livre,
17

tal como a GNU General Public License, para permitir o seu uso em software livre.
18

Capítulo 1
Tunelamento
O tunelamento é uma das técnicas, 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 desaﬁos 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.
20

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 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;
21

• 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
22

2.9 Bibliograﬁa
• Site oﬁcial: 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
23

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
24

Capítulo 4
Introdução
4.1 O que é tunelamento
Um túnel TCP é, basicamente, uma 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 especiﬁcado 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 ﬁnal 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;
25

• 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 ressaltamos 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 vamos 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;
26

– 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. Fora 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 exemplos 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 freqüentemente 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 proibindo 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
27

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 emails 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 a 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 por segu-
rança 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
28

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 pode dar ao tunelamento é o acesso local à serviços que não são disponí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). Se fôssemos 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 nossas máquinas internas serve para fora conexões SSH.
Certamente existem outros casos diferentes em que um acesso indireto por tunelamento tam-
bém se mostrará útil.
29

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 ﬁca a sugestão de que eventualmente conﬁram 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:
# 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
30

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 instalado.
5.2 Instalando o OpenSSH
SSH signiﬁca "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 certiﬁcaçã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 nossas máquinas,
a instalação como descrita a seguir talvez seja desnecessária. Mas, para aquelas(es) que ainda
não o têm 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 tanto quanto
o próprio SSH, outrora nossa ferramenta de tunelamento. Ele 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,
31

com todo tipo de protocolo. O Corkscrew vai servir como uma introdução simples e breve ao
tunelamento de contorno de ﬁrewalls.
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 ﬁrewall 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
32

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. A seguir você terá acesso a uma listagem de algumas coisas que ele pode executar:
• 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.
33

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 coisa 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 mesmo comando com ’ -vv ’:
34

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 trasferi-
dos. 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 e 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
35

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. 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
Conﬁra 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] <Ctrl-c>
from localhost.localdomain [127.0.0.1] 50480
olá
sent 0, rcvd 4
$
O mesmo acontece se passarmos o arquivo pela ponta do servidor:
36

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
Ora, se podemos passar conteúdo de um arquivo e também podemos repassar o conteúdo
recebido para um arquivo na outra ponta, será que podemos passar um arquivo em uma ponta e
recebê-lo em outra? Sim, podemos.
Observe a cena a seguir:
37

6.4.5 Caso 4
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 simplesmente estabelece uma conexão, o que faz com ela não interesse a ele (na
próxima página, na verdade, vamos conhecer algumas opções do Netcat que podem soﬁsticar
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 ítens 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 estabe-
lecer um servidor de shell remota. Observe essa maravilha:
38

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ássemos 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 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:
6.4.8 Caso 7
Ainda assim temos que ﬁcar trocando de terminais para passar de um comando e em outro
ver sua saída. Uma alternativa funcional é no T3, ao invés de simplsmente nos conectarmos,
nos conectarmos e enviarmos os dados que chegarem para o T2 usando redirecionamento e o
identiﬁcador do terminal do diretório /dev. Por exemplo:
39

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 dar seu uso mais funcional e oti-
mizado. 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;
-w, –wait=SECS tempo limite para tentativas de conexões e para ’final net reads’;
40

-z, –zero modo zero-I/O (utilizado para escaneamento);
Marquei em negrito as 2 opções que vou comentar no resto da 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 é
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 snifﬁng.
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 especiﬁcado
para a outra ponta da conexão e ao receber dados retorna a saída do comando, caso responda,
de volta para a ponta remota. Experimente escutar uma porta como fazíamos nos casos apre-
sentados e passar o parâmetro -e seguido do caminho, digamos, do shell bash, -e /bin/bash, terá
como resultado 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!
41

Capítulo 7
Iniciação prática - OpenSSH
7.1 OpenSSH - Conectando
Assim como o Netcat, o OpenSSH é capaz de servir em uma dada porta quanto capaz de co-
nectar a uma porta especificada, mas todas as 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 um de nós já tenhamos acesso à 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
42

Fazendo conexões com esses parâmetros somos levados ao shell da máquina remota. Po-
demos, entretanto, passarmos diretamente um comando para ser executado 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 estebelecimento 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 à 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 identiﬁcaçã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 bloqueado 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 conﬁgaração. No entanto, não faria
sentido nos envolver aqui com a solução de como implementar essa ou outra solução adequada.
43

Sugiro, portanto, que aquelas pessoas que tiverem esses problemas de autenticação simples-
mente removam o arquivo /.ssh/known_hosts, onde ficam armazenadas as chaves e as identifi-
caçõ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 quere-
mos evitar ataques brute force automático de bots, para passar ao largo de scannings de porta
mais estreitos, 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
44

Se será permitido 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 estabelecimento de conexões com redirecionamento dos aplicativos
gráﬁcos pela conexão.
Estas opções e outras, no entanto, não nos interessam neste curso.
45

Capítulo 8
Tunelamento - Netcat
8.1 Tunelando com o Netcat - Parte 1
Vamos enfim utilizar uma breve experiência para tentar montar nossos primeiros túneis. Para
começ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 e 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
46

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 terminará
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áquinas 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 duas linhas seguintes foram tira-
das da saída do comando netstar -a | grep localhost ao montar um túnel simples como mostrado
na página anterior.
47

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, 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, como 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
48

é obrigatória neste curso, e deve ser lida por aquelas pessoas que tiverem curiosidade e interesse
em soﬁsticar 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
tunelamento, 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 ’redirecionamento’, 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 simplesmente 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
49

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 inﬂada desempenharia 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 eﬁcaz 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.
50

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 serve para nos permitir acessar o shell de máquinas remotas com segurança (tanto
de dados quanto de legitimidade do servidor, entre outras dúzias de recursos que promovem
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. Naqueles 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 ﬁdelidade. 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 que 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
51

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
conexã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 precisa-
ríamos 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 situaçã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:
52

$ 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 (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á tiver reconhecido o servidor (intermediário), pedirá uma senha para o login.
Como não especificamos nome de usuário, temos de oferecer a senha do 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
53

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 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:
• 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.
54

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
Analogamente, como existem três nós envolvidos no tunelamento, podemos envolver até três
diferentes portas de escuta na operação:
• A - A porta em que a máquina intermediária escuta para 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-túnel -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.
55

9.4.1 Múltiplos túneis com OpenSSH
O OpenSSH é 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, T 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, su-
geri 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 sim-
plesmente de um túnel mais consistente e seguro do que um túnel Netcat. Para tanto precisamos,
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 ﬁcamos 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 especiﬁcamente 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.
56

$ 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 de 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 Concatenando 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
tanto basta, é claro, que a porta do serviço para onde um túnel leva conexão 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 aconteça 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 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!
57

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, simplesmente 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
OpenSSHe 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
58

Com a diretiva host definimos para quais máquinas a configuração que se segue vai valer.
Podemos, em geral, simplesmente setar *, que vale para quaisquer hosts.
ProxyCommand é a diretiva que vai chamar o Corkscrew para 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 simplesmente 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, simplesmente 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 é do próprio OpenSSH, e chama o Corkscrew para atravessar 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 transparentemente,
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
Adicionando 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 a mesma que a do Corkscrew, encapsular uma co-
nexã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.
59

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áquinas 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 passará 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.
Como 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 ﬁm, com o esquema de túneis preparado fazemos a conexão propriamente dita como
clientes obviamente:
$ nc -vv localhost 1500
60

É claro que em um cenário típico se a conexão a ser realizada tem regularmente o seu esquema
de túneis já vai estar preparado, estático. Essa estrutura não precisa ser desmontada por que
uma conexão foi fechada, um servidor, especialmente, pode manter o seu túnel funcionando
permanentemente e divulgar sua porta já como sendo a porta aberta com o hts.
61

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áquina,
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 do -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: a primeira 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
com:
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
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.
62

Tunelamento

Mais conteúdo relacionado

Mais procurados

Semelhante a Tunelamento

Mais de Tiago

Último

Tunelamento