Mini-COMO FAZER Firewall
François-René Rideau, fare@tunes.org
Traduzido e Revisado por Conectiva Informática,
info@conectiva.com.br, no dia 30 de Março de 1999.
v0.3, 22 de Agosto de 1998
Orientações para o uso do ppp sobre uma conexão telnet para tornar o
tráfego de rede transparente através de um firewall da Internet.
______________________________________________________________________
Índice geral
1. Material
1.1 RENÚNCIA DE UM DIREITO LEGAL
1.2 Publicidade Legal
1.3 Créditos
2. Introdução
2.1 Prefácio
2.2 Problemas de segurança
2.3 Outros requisitos
2.4 Recebendo o Programa
3. Entendendo o problema
3.1 Dando nomes às coisas
3.2 O Problema
3.3 Dificuldade adicional
4. A solução
4.1 Princípio
4.2 fwprc
4.3 .fwprcrc
5. Travessia Reversa
5.1 Exposição de Razões
5.2 Configurando a ativação automática de correio eletrônico
6. Notas Finais
6.1 Outras montagens
6.2 Manutenção do COMO FAZER
______________________________________________________________________
11.. MMaatteerriiaall
11..11.. RREENNÚÚNNCCIIAA DDEE UUMM DDIIRREEIITTOO LLEEGGAALL
PPoorr mmeeiioo ddeessttaa oo aauuttoorr nneeggaa ttooddaa aa rreessppoonnssaabbiilliiddaaddee ppoorr eessttee pprrooggrraammaa..
SSee oo ttiirroo ssaaiirr ppeellaa ccuullaattrraa,, éé aa vviiddaa.. NNããoo éé mmiinnhhaa ccuullppaa.. SSee vvooccêê nnããoo
eenntteennddeerr ooss rriissccooss aaoo ffaazzeerr iissssoo,, nnããoo oo ffaaççaa.. SSee vvooccêê uussaarr eessttee
pprrooggrraammaa ee eellee ppeerrmmiittiirr qquuee vvâânnddaallooss sseellvvaaggeennss iinnvvaaddaamm ooss ccoommppuuttaaddoorreess
ddaa ssuuaa ccoommppaannhhiiaa ee iissttoo ccuussttaarr sseeuu eemmpprreeggoo ee àà ssuuaa ccoommppaannhhiiaa mmiillhhõõeess
ddee ddóóllaarreess,, bbeemm,, iissttoo éé ssóó ppeeddrreeiirraa.. NNããoo vveennhhaa cchhoorraarr ppaarraa mmiimm..
11..22.. PPuubblliicciiddaaddee LLeeggaall
Direitos autorais & cópia; 1998 por François-René Rideau. Este
documento pode ser distribuído sujeito aos termos e condições
destacadas na licença LDP na
<http://metalab.unc.edu/LDP/LICENSE.html>.
11..33.. CCrrééddiittooss
Muito embora eu tenha reescrito quase tudo, menos a renúncia dos
direitos legais, sou grato a Barak Pearlmutter bap@cs.unm.edu
<mailto:bap@cs.unm.edu> pelo seu mini-COMO FAZER Term-Firewall: acho
que houve necessidade de um mini-COMO FAZER sobre firewall e
acessórios e apesar de suas deficiências seu mini-COMO FAZER foi um
modelo e um incentivo.
22.. IInnttrroodduuççããoo
22..11.. PPrreeffáácciioo
Porque os usuários e administradores têm limites e competências
diferentes, pode acontecer que um usuário possa se achar atrás de um
firewall, que ele pode atravessar, mas apenas de uma maneira
desastrada. Este mini-COMO FAZER explica de uma maneira genérica e
prática como usar as ferramentas padrão Internet através de tais
firewalls através do uso de um emulador IP sobre uma sessão telnet.
Este focumento é livremente inspirado pelo mini-COMO FAZER Term-
Firewall de Barak Pearlmutter bap@cs.unm.edu <mailto:bap@cs.unm.edu>,
que se apóia num programa antigo e não mais suportado chamado Term
(ainda que tenha sido um grande programa em sua época), bem como em
peculiaridades de uma implementação telnet não tão padrão, isto é,
muitos fatos obsoletos e não portáteis.
22..22.. PPrroobblleemmaass ddee sseegguurraannççaa
Claro que se o administrador de sistemas tiver configurado um
firewall, ele deve ter uma boa razão e você pode ter assinado um
acordo para não desrespeitá-lo. Por outro lado, o fato de que se poder
estabelecer uma conexão com o exterior (o que é um requisito para os
programas aqui apresentados funcionarem) significa ser possível
acessar sistemas externos, além do fato de ser possível registrar-se
neles.
Assim tudo é uma questão de usar _c_o_n_v_e_n_i_e_n_t_e_m_e_n_t_e as falhas de
segurança legais num firewall e permitir que programas genéricos
funcionem com protocolos genéricos, ao contrário dos programas
especiais exigidos ou modificados (e recompilados) atravessando muitos
proxies de propósito especial que são configurados por um
administrador de sistema descuidado e incompetente, ou pela instalação
de muitos conversores de propósito especial para acessar cada um dos
seus serviços usuais (como correio-eletrônico) através de caminhos
suportados pelo firewall (como a rede). Além disso, o uso do emulador
IP a nível de usuário tal como o SLiRP deve ainda prevenir atacantes
externos de entrarem por uma falha de segurança do firewall de uma
outra maneira, a menos que explicitamente permitida. Afinal de
contas, o programa apresentado deve ser _r_e_l_a_t_i_v_a_m_e_n_t_e seguro. Porém,
tudo depende das circunstâncias nas quais foram configuradas as coisas
e não é possível fornecer garantias sobre este programa. Muitas
coisas são intrinsecamente inseguras nas conexões da Internet, seja
com este programa ou não, por isso não suponha que nada é seguro a
menos que tenha boas razões para isso, e/ou usar alguma espécie de
criptografia durante todo o tempo.
Para resumir, não use este programa a menos que você saiba o que está
fazendo. Releia a renúncia a direito legal acima.
22..33.. OOuuttrrooss rreeqquuiissiittooss
Supõe-se que você saiba o que está fazendo, que você saiba como
configurar uma conexão de rede; que você tenha contas de ambiente de
trabalho nos dois lados do firewall; que de alguma forma se possa
conectar (ou ssh, ou equivalente) de uma conta para outra; que se
possa executar um emulador IP nas duas contas de ambiente de trabalho;
que se tenha programas capazes de usar a conexão IP emulada em seu
lado. Note que qualquer programa pode usar a conexão, no caso o
emulador local é o pppd conversando com o kernel do Linux, outros
emuladores, como o Term, precisam de recompilação e ligação com uma
biblioteca especial. Falando de emuladores, o pppd pode ser
encontrado em qualquer boa distribuição Linux ou servidor ftp, assim
como o SLiRP. Se sua conta de ambiente de trabalho remota é somente a
nível de usuário, você pode usar o SLiRP para conectar.
22..44.. RReecceebbeennddoo oo PPrrooggrraammaa
A maioria dos programas descritos devem estar disponíveis a partir de
suas distribuições padrão, possivelmente entre os contribuintes; pelo
menos todos, menos os dois últimos que estão disponíveis em pacotes
rpm. No caso de se querer buscar os fontes mais recentes ou binários
(afinal, uma das pontas da conexão pode não estar executando o Linux)
devem ser usados os endereços abaixo:
· SLiRP pode ser encontrado em <http://blitzen.canberra.edu.au/slirp>
e/ou <ftp://www.ibc.wustl.edu/pub/slirp_bin/>.
· zsh pode ser encontrado em <http://www.peak.org/zsh/>.
· ppp pode ser encontrado em <ftp://cs.anu.edu.au/pub/software/ppp/>.
· fwprc e cotty pode ser encontrado em
<http://www.tunes.org/~fare/files/>.
33.. EEnntteennddeennddoo oo pprroobblleemmaa
Entender o problema é a metade do caminho para resolvê-lo.
33..11.. DDaannddoo nnoommeess ààss ccooiissaass
Para que este programa funcione para você, há que se ter uma idéia de
como ele funciona, pois se alguma coisa falhar, se terá uma idéia de
onde procurar as causas.
O primeiro passo em direção ao entendimento do problema é dar um nome
aos conceitos relevantes.
Por isso nós chamaremos aqui de "local" a máquina que inicia a
conexão, bem como os programas e arquivos daquela máquina. Por outro
lado chamaremos de "remoto" o que estiver do outro lado da conexão.
33..22.. OO PPrroobblleemmaa
O objetivo é conectar a entrada e saída de um emulador IP local para a
saída e entrada de um emulador IP remoto respectivamente.
Os emuladores IP interagem somente com canais de comunicação como
dispositivos diretos (como o caso comum do pppd) ou o "terminal
atual". O caso anterior obviamente não acontece com as sessões telnet.
O último é complicado, porque quando se lança o emulador local a
partir da linha de comando, o terminal atual é ligado à linha de
comando do usuário e não à uma sessão remota. Devemos abrir uma nova
sessão (local ou remota) num novo terminal, sincronizar o lançamento e
a conexão dos emuladores IP nos dois lados, pois a menor parcela de
saída de lixo de uma sessão poderá ser entendida como comandos na
outra sessão, o que recursivamente produziria mais lixo.
33..33.. DDiiffiiccuullddaaddee aaddiicciioonnaall
Para facilitar o uso, o emulador IP local tem que prover um IP para o
kernel de rede, ou seja habilitar o pppd. Porém o pppd é limitado para
só aceitar dados através de arquivos /dev ou através do terminal em
uso. Ou seja, deve ser um tty e não um par de conectores. Isto é ótimo
para o pppd remoto se houver, pois ele pode usar o tty das sessões
telnet, mas o pppd local não pode lançar a sessão telnet para
conectar-se, conseqüentemente deve haver algum tipo de invólucro ao
redor dele.
O telnet se comporta _q_u_a_s_e corretamente com um par de conectores,
exceto que ainda insistirá em executar controles de entrada e saída no
terminal atual, com o qual interferirá. Usar telnet sem um tty também
causa condições de uso intenso de recurso, de maneira que toda a
conexão falhará nos computadores "lentos". (fwprc 0.1 funcionou
perfeitamente num Pentium MMX 233, uma vez em 6 num 6x86-P200+ e nunca
funcionará em um 486dx2/66).
[Nota: se eu encontrar o autor (provavelmente uma cara da MULTICS ,
embora tenha havido pessoas de UNIX tolas o suficiente para copiar a
idéia) que inventou o princípio dos dispositivos "tty" pelos quais se
pode ler e escrever um "mesmo" pseudo arquivo, ao invés de ter pares
de conectores, eu o estrangulo!]
44.. AA ssoolluuççããoo
44..11.. PPrriinnccííppiioo
O programa complementar de firewall, fwprc, usará um "proxy tty "
denominado cotty, que abre dois dispositivos pseudo tty, lança alguns
comandos em cada daqueles dispositivos e copia todos os caracteres de
saída para o terminal, os quais servem de entrada para outro comando.
Um comando será a conexão telnet com o servidor remoto e o outro será
o pppd local. O pppd pode então abrir e controlar a sessão telnet
através um programa de acesso normal.
44..22.. ffwwpprrcc
Eu escrevi um programa muito bem documentado para complementar
firewalls chamado fwprc, disponível do meu servidor
<http://www.tunes.org/~fare/files/>, junto com cotty (que é
requisitado por fwprc 0.2 e posteriores). Ao escrever estas linhas, as
versões mais recentes eram fwprc 0.2a e cotty 0.3.
O nome "fwprc" foi feito propositadamente ilegível e impronunciável,
de maneira que ele possa confundir o administrador de sistema
paranóico e incompetente que possa ser o responsável pelo firewall que
irrita você (claro que pode haver firewalls legítimos também).
CONCURSO: mande-me um arquivo de áudio .au com uma gravação de áudio
digital de como você pronuncia "fwprc". A pior entrada ganhará uma
atualização gratuita e seu nome na página do fwprc 0.3!
Testei o programa em vários ambientes, configurando-o, através de
arquivos de recursos. Mas claro, pela lei de Murphy, ele falhará em
algum momento. Sinta-se à vontade para contribuir com sugestões e
conselhos que tornarão mais fácil a vida de outras pessoas que farão a
configuração depois de você.
44..33.. ..ffwwpprrccrrcc
O fwprc pode ser personalizado através do arquivo .fwprcrc, feito para
ser igual nos dois lados da firewall. Existem várias configurações
alternadas para se escolher, porém também indicamos ele como um
exercício para o leitor.
Para iniciar, copie a seção apropriada de fwprc (o anterior por
exemplo) para um arquivo chamado .fwprcrc em seu diretório pessoal.
Então substitua os valores variáveis por configurações que se ajustem
à sua configuração. Finalmente, copie para a outra máquina e teste.
O comportamento padrão é usar o pppd localmente e o slirp remotamente.
Para modificar isto, pode-se redefinir a função apropriada no .fwprcrc
na linha como:
remote_IP_emu () { remote_pppd }
Note que o SLiRP é mais seguro que o pppd, e mais fácil de se ter
acesso, uma vez que ele não requer que a máquina remota tenha
privilégios de superusuário. Uma outra característica segura é que ele
abandonará os pacotes que não venham diretamente da máquina conectada
(cuja característica se torna um problema ao se tentar rotear uma
subrede sobre ela com mascaramento). A funcionalidade básica do SLiRP
funciona bastante bem, mas achei que os sinais de soma publicados
(como no controle de tempo corrido) eram deficientes. Claro que desde
que é um programa gratuito, sinta-se à vontade para programar a fonte
de maneira a implementar realmente a característica que você precisa.
55.. TTrraavveessssiiaa RReevveerrssaa
55..11.. EExxppoossiiççããoo ddee RRaazzõõeess
Às vezes, só um lado da firewall pode lançar sessões telnet para o
outro lado; porém, alguns meios de comunicação são possíveis
(tipicamente através do correio-eletrônico). Atravessar o firewall é
ainda possível, através da habilitação da capacidade de troca de
mensagens em uma conexão telnet a partir do lado certo do firewall
para o outro.
O fwprc inclui o código para iniciar tais conexões de uma mensagem de
correio-eletrônico autenticada via PGP. Tudo o que se precisa é
acrescentar fwprc como um filtro do procmail(1) para mensagens
(instruções incluídas em fwprc). Note-se porém, que se for lançar o
pppd com os privilégios apropriados, você pode precisar criar seu
próprio suid para se tornar um superusuário. Instruções inclusas em
fwprc.
Também o início de sessão autenticada não significa nem remotamente
uma conexão segura. Deve-se realmente usar o ssh (talvez sobre o
telnet) para conexões seguras. E então, cuidado com o que acontece
entre o início da conexão da telnet e o ssh assumindo o comando
daquela conexão.
55..22.. CCoonnffiigguurraannddoo aa aattiivvaaççããoo aauuttoommááttiiccaa ddee ccoorrrreeiioo eelleettrrôônniiccoo
Caso se esteja dentro de uma área sob um firewall, as mensagens podem
estar num servidor central que não tenha filtros procmail ou que não
permita sessões telnet. Sem problemas! Pode-se usar o fetchmail(1) em
modo servidor para apurar e obter as mensagens do cliente em um
sistema Linux, e/ou acrescentar uma tarefa em horário pré-definido
para apurar automaticamente a correspondência a cada 1 a 5 minutos por
exemplo. O fetchmail enviará as mensagens a um endereço local através
do sendmail(8), que terá sido configurado para usar o procmail(1) para
entrega. Note que se você executar o fetchmail(1) como um servidor de
segundo plano, ele irá evitar qualquer outra instância do fetchmail
que se gostaria de executar somente em outro momento, como quando se
executa o fwprc. Logicamente também pode-se executar um servidor
fetchmail como um outro usuário. Muito freqüentemente a busca de
mensagens não será boa nem para o servidor nem para sua máquina. Muito
raramente ela significará que se deva esperar para que a mensagem
fique pronta e a conexão inversa se estabeleça. Uso uma freqüência de
dois minutos para a busca de mensagens.
66.. NNoottaass FFiinnaaiiss
66..11.. OOuuttrraass mmoonnttaaggeennss
Há outros tipos de firewalls além daqueles que permitem conexões
telnet. Contanto que um fluxo contínuo de pacotes possam atravessar
uma firewall e transmitir informações de duas maneiras é possível
penetrá-la, porém o preço de escrever um programa que transpasse o
firewall pode ser mais alto ou mais baixo.
Num caso simples, pode-se lançar o ssh sobre um pty e executar pppd em
um tty escravo. O cotty 0.3 deve ser capaz de executá-lo, mas ninguém
modificou ainda o fwprc para tanto. Talvez seja o exercício da noite
para você. Pode-se até mesmo querer fazê-lo sem um firewall na outra
extremidade da rede, a fim de construir uma "VPN" (Rede Virtual
Privada). Se precisar usar uma linha de 7 bits, pode-se querer usar
SLIP ao invés do PPP. Nunca tentei porque as linhas usam normalmente 8
bits, mas não deve ser difícil. Agora, se a única maneira de cruzar
uma firewall for um proxy WWW (usualmente, o mínimo para uma rede
conectada a Internet), pode-se querer escrever um servidor que guarde
os dados em buffers e os envie durante as conexões HTTP, usando
sessões telnet sobre HTTP, onde se executa o fwprc. Pode ser lento e
não muito ágil, mas ainda é bom o suficiente para se usar o
fetchmail(1), suck(1) e outros programas não interativos.
Caso se queira um melhor desempenho, ou se a única coisa que pode
passar sem filtro é algo menos usual (perguntas DNS, pacotes ICMP, ou
o que quer que seja), então pode-se estar numa situação difícil onde
se terá que reprogramar uma pilha IP usando (por exemplo) as funções
de protocolo do projeto Fox. Será possível alcançar alguns IPs sobre
HTTP, IPs sobre DNS, IPs sobre ICMP, ou outros, que exigem não somente
um protocolo complexo, mas também uma interface com o kernel, onde
ambas as soluções têm implementações custosas.
A propósito, ao se usar algum servidor HTTP que passe através de um
Firewall, não esqueça de fazê-lo servir páginas falsas para enganar os
administradores de firewall contrários desconfiados.
66..22.. MMaannuutteennççããoo ddoo CCOOMMOO FFAAZZEERR
Eu senti que era necessário escrevê-lo, mas eu não tenho aquele tempo
disponível, por isso este mini COMO FAZER é ainda um pouco rudimentar.
E assim será até que se receba retorno suficiente para saber que
seções melhorar. O retorno é bem vindo. Ajuda também.
De qualquer maneira as seções acima mostraram muitos problemas cujas
soluções são só uma questão de alguém (você?) gastar algum tempo (ou
dinheiro, contratando outra pessoa) para sentar e escrever: nada
conceitualmente complicado, embora os detalhes possam ser complexos.
Não hesite em contribuir com mais problemas e se Deus quiser com mais
soluções para este mini-COMO FAZER.