Mini COMO FAZER Bridge+Firewall no Linux versão 1.2.0 Peter Breuer (ptb@it.uc3m.es) - Traduzido por Conectiva Informática, , revisado em 7 de Abril de 1999. v, 19 de Dezembro de 1997. ____________________________________________________________ Índice geral 1. Introdução 2. O quê, Porquê e Como? 2.1 O quê? 2.2 Por quê? 2.3 Como? 3. BRIDGING 3.1 Software 3.2 Leitura Prévia 3.3 Configuração de inicialização 3.4 Configuração do kernel 3.5 Endereços de rede 3.6 Roteamento de Rede 3.7 Configuração de placas de rede 3.8 Roteamentos adicionais 3.9 Configuração da Bridge 3.10 Testando o Sistema 3.11 Verificações 4. FIREWALLING 4.1 Software e Leitura 4.2 Verificações preliminares 4.3 Regra padrão 4.4 Regras por endereço 4.5 Regras por protocolo 4.6 Verificações ______________________________________________________________________ 11.. IInnttrroodduuççããoo Pode-se pesquisar o documento original mini COMO FAZER Bridge desenvolvido por Chris Cole para se ter uma perspectiva diferente. Ele está disponível ainda neste Guia, assim como em . O autor pode ser encontrado em chris@polymer.uakron.edu. A versão do COMO FAZER no qual eu baseei este documento é a 1.03 datada de 23 de agosto de 1996. 22.. OO qquuêê,, PPoorrqquuêê ee CCoommoo?? 22..11.. OO qquuêê?? Uma Bridge é um fio de conexão inteligente entre duas placas de rede. Um firewall é um isolante inteligente. 22..22.. PPoorr qquuêê?? Pode-se utilizar uma Bridge caso estejam disponíveis diversos computadores, e para: 1. Economizar o valor de um novo hub inteligente quando haja um placa Ethernet disponível. 2. Poupar o aborrecimento de aprender como fazer reenvio IP e outros truques quando se tem duas placas de rede em um computador. 3. Poupar trabalho de manutenção futura, quando as coisas mudarem! ``Diversos computadores'' podem ser somente três, se estes forem roteadores ou Bridges, ou no caso de circularem pelas salas de tempos em tempos! Pode-se ainda querer uma Bridge somente pelo prazer de descobrir o que ela faz e como funciona. Caso se esteja realmente interessado ``1'', sugerimos a verificação dos documentos COMO FAZER localizados em NET-2-HOWTO e Serial- HOWTO para maiores informações. Pode-se querer um firewall para: 1. Proteger a rede local de acessos externos, ou 2. Para negar o acesso para o mundo exterior a partir da rede local. Curiosamente, eu precisei ``2'' de um firewall também. A política na minha Universidade é tal que não podemos atuar como provedores de serviços Internet para alunos não-graduados. 22..33.. CCoommoo?? As iniciar as placas de rede com a opção BRIDGING habilitada em um computador com firewall em funcionamento e após finalizar o firewall, a Bridge permanece ativa. Parece funcionar corretamente e é mais flexível que qualquer configuração individual. É possível encerrar o firewall e manter a bridging ou retirar a Bridge quando se quiser uma configuração mais restrita. Pode-se supor que o código da Bridge reside acima da camada do dispositivo físico e o código do firewall está localizado em uma camada mais acima, então as configurações de bridge e de firewall agem efetivamente como se estivessem sendo executadas juntas e ``em seqüência'' e não ``em paralelo'', na seguinte seqüência: -> Entrada-Bridge -> Entreda-Firewall -> Kernel -> Firewall-Saída -> Bridge-Saída -> Não existe outra maneira para explicar como uma máquina pode ser um ``conector'' e um ``isolante'' simultaneamente. Existem alguns cuidados que serão citados adiante. Basicamente deve-se rotear pacotes que devem também ser protegidos. De qualquer modo, eles todos parecem funcionar muito bem juntos. 33.. BBRRIIDDGGIINNGG 33..11.. SSooffttwwaarree Deve-se obter o Utilitário de Configuração de Bridge das páginas de Alan Cox. É a mesma referenciada no documento de Christopher Cole. 33..22.. LLeeiittuurraa PPrréévviiaa Deve-se ler o documento COMO FAZER Ethernets Múltiplas para informações sobre a instalação simultânea de mais de uma placa de rede. Mais alguns detalhes sobre o tipo de mágica de inicialização que se possa precisar podem ser encontrados em COMO FAZER Prompt de Inicialização . Deve-se ainda verificar o conteúdo de COMO FAZER NET-2 . É uma boa e longa leitura e pode-se retirar dela os detalhes necessários sobre a rede como um todo. 33..33.. CCoonnffiigguurraaççããoo ddee iinniicciiaalliizzaaççããoo O material de leitura acima, dirá que é necessário preparar o kernel para reconhecer um segundo dispositivo Ethernet na inicialização, adicionando-se o seguinte conteúdo ao arquivo //eettcc//lliilloo..ccoonnff e após deve-se reexecutar o programa lliilloo: append = "ether=0,0,eth1" Observe que "eth0" é a primeira placa, enquanto que "eth1" é a segunda. Pode-se sempre adicionar os parâmetros da inicialização na resposta à linha que o lilo oferece. Para três placas teremos a seguinte configuração: linux ether=0,0,eth1 ether=0,0,eth2 Pode-se usar o llooaaddlliinn para inicializar o kernel a partir do DOS, no seguinte formato: loadlin.exe c:\vmlinuz root=/dev/hda3 ro ether=0,0,eth1 ether=0,0,eth2 Note que este truque faz com que o kernel teste as placas na inicialização do sistema. Isto não acontecerá caso os controladores Ethernet sejam carregados como mmóódduullooss (por segurança, desde que a ordem de entrada não pode ser determinada quando da verificação automática). Na utilização de módulos deverá ser acrescentada a IRQ apropriada, assim como os parâmetros para o controlador no arquivo //eettcc//ccoonnff..mmoodduullooss, como no arquivo de exemplo a seguir: alias eth0 3c509 alias eth1 de620 options 3c509 irq=5 io=0x210 options de620 irq=7 bnc=1 Para verificar se o kernel está utilizando módulos, deve-se executar o comando ``ps -aux'' e verificar se o kkeerrnneelldd está sendo executado, assim como verificar se existem arquivos .o em um subdiretório do diretório //lliibb//mmoodduulleess//. Será possível verificar o diretório, através do uso do comando uname -r que indicará o nome em uso. Caso o kerneld esteja sendo executado e/ou haja um arquivo foo.o, deve ser editado o arquivo //eettcc//ccoonnff..mmoodduulleess e deve-se ler a página manual on-line de depmod cuidadosamente. Note também que até recentemente (kernel 2.0.25) o controlador 33cc550099 não podia ser usado por mais de um placa, caso fosse usado como módulo. Há uma atualização que corrige este aspecto. 33..44.. CCoonnffiigguurraaççããoo ddoo kkeerrnneell Deve-se recompilar o kernel com a opção Bridging habilitada no seguinte formato: CONFIG_BRIDGE=y Deve-se ainda habilitar as funções de firewall e IP-forwarding e -masquerading, caso se deseje utilizar as funções de firewall: CONFIG_FIREWALL=y CONFIG_NET_ALIAS=y CONFIG_INET=y CONFIG_IP_FORWARD=y CONFIG_IP_MULTICAST=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_VERBOSE=y CONFIG_IP_MASQUERADE=y Caso não se utilizem estas opções, pode-se somente configurar os parâmetros padrões de rede através do parâmetro: CONFIG_REDE=y Penso que não haja necessidade de se preocupar com qualquer outra opção de rede. Não há nenhuma opção que não se tenha compilado no kernel disponível através de módulos que não possa ser acrescentada posteriormente. A seguir deve-se instalar o novo kernel, reexecutando o programa lilo e reinicializando o sistema com o novo kernel. Nada deve ter mudado até este ponto! 33..55.. EEnnddeerreeççooss ddee rreeddee Chris afirma que uma Bridge não deve ter um endereço IP, mas esta não é a configuração a ser descrita aqui. Uma vez que ela seja utilizada para conexão com a Internet, por exemplo, um endereço IP será então necessário, assim como assegurar-se que um dispositivo de rede local esteja configurado da forma correta, permitindo assim a conexão com outros pontos da rede da maneira usual. Caso o dispositivo de rede local não esteja ativo, o sistema de resolução de nomes ou outro serviço de rede pode falhar. Veja o COMO FAZER NET-2, porém a configuração padrão do sistema já deve conter a seguinte configuração: ifconfig lo 127.0.0.1 route add -net 127.0.0.0 Deve-se então fornecer os endereços para as placas de rede. Pode-se por exemplo alterar o arquivo /etc/rc.d/rc.inet1 em uma sistema Slackware (3.x) para se configurar duas placas. Provavelmente o que se deve fazer é verificar no arquivo de configuração de rede e dobrar ou triplicar o número de instruções ali contidas. Supondo-se que já se tenha o endereço: 192.168.2.100 (isto está no intervalo reservado a endereços da redes privadas, mas não importa - não fará mal a ninguém o uso deste endereço) então provavelmente já se tem uma linha no formato: ifconfig eth0 192.168.2.100 netmask 255.255.255.0 metric 1 na configuração do sistema. A primeira coisa que provavelmente será feita é cortar pela metade o espaço de endereço abrangido por esta placa, podendo-se criar eventualmente uma Bridge ou proteger as duas metades. Para tanto deve-se acrescentar uma linha que reduz a máscara para endereçar um menor número de máquinas: ifconfig eth0 netmask 255.255.255.128 Isto restringe a placa ao espaço de endereços entre .0 e .127. Agora é possível configurar a segunda placa na outra metade do intervalo de endereços locais. Assegure-se de que ninguém já esteja utilizando este endereço. Por simetria configuramos aqui os endereços no seguinte formato: 228 = 128+100. Qualquer endereço fará o mesmo, contanto que não invada o intervalo de outra máscara. Endereços especiais devem ser evitados como por exemplo .0, .1, .128 etc. a não ser que se esteja seguro do que se está fazendo. ifconfig eth1 192.168.2.228 netmask 255.255.255.128 metric 1 Isto restringe a segunda placa ao intervalo de endereços entre .128 e .255. 33..66.. RRootteeaammeennttoo ddee RReeddee Aqui é onde tem que ser descritas as "armadilhas" do esquema Bridge + Firewall: não se pode proteger pacotes que não estiverem sendo roteados, ou seja sem rotas não há proteção. Pelo menos isto parece ser verdadeiro no kernel 2.0.30 e nos mais recentes. Os filtros de proteção estão muito envolvidos com o código de reenvio de IP. Isto não significa que não se pode ter uma Bridge. Pode-se ter uma Bridge entre duas placas e um firewall em uma terceira. Pode-se ter somente duas placas e proteger ambas de IPs externos, como um roteador, desde que o roteamento seja realizado por uma das placas. Em outras palavras, para uso do firewall é necessário controlar precisamente o destino físico de alguns pacotes. Em uma pequena rede de máquinas ligadas a um hub através da interface eth0, a configuração poderia ser a seguinte: route add -net 192.168.2.128 netmask 255.255.255.128 dev eth0 O 128 poderia ser igual a 0 caso se estivesse utilizando uma classe C inteira. Neste caso, por definição, o espaço foi dividido ao meio. O parâmetro "dev eth0" não é necessário aqui porque os endereços de placas estão enquadrados dentro da máscara, mas ele pode ser necessário em outras situações. Pode ser necessária mais de um placa nesta sub-rede (127 máquinas em um segmento é um número relativamente elevado), sendo que estas placas funcionariam como uma Bridge sob a mesma máscara de rede, parecendo serem um dispositivo único para o código de roteamento. Na outra placa há uma conexão indo diretamente para um grande roteador confiável: cliente 129 __ | __ client 1 \ .0 .128 | / net 1 client 2 --- Hub - eth0 - Kernel - eth1 - Hub - Router --- net 2 client 3 __/ .100 .228 .2 | \__ net 3 | cliente 254 Define-se o endereço do roteador para esta placa através de uma rota fixa ("static") porque, de outro modo, ele poderia cair dentro da faixa de endereços da primeira máscara e o kernel, erroneamente, enviaria os pacotes para o roteador. Ainda, pode-se querer proteger estes pacotes e essa é outra razão para querer roteá-los desta forma. route add 192.168.2.2 dev eth1 Caso se tenha mais máquinas na segunda metade do espaço de endereços, deve-se declarar uma rede também na segunda placa. Separando as interfaces dentro de duas configurações via roteamento permitirá fazer eventualmente proteções mais adequadas. route add -net 192.168.2.128 netmask 255.255.255.128 dev eth1 Deve-se ainda indicar ao kernel para enviar para o roteador todos os pacotes não endereçados à rede local. route add default gw 192.168.2.2 33..77.. CCoonnffiigguurraaççããoo ddee ppllaaccaass ddee rreeddee A configuração da rede é padronizada, mas como estamos executando funções de bridging, então as duas placas devem tratar todos os pacotes que transitem pela rede, mesmo os não dirigidos para elas. Logo elas devem ter a seguinte configuração: ifconfig promisc eth0 ifconfig promisc eth1 A página de manual informa allmulti=promisc, mas isto na verdade não parece funcionar muito bem. 33..88.. RRootteeaammeennttooss aaddiicciioonnaaiiss Algo observado na prática, foi a necessidade de se colocar ao menos a segunda placa dentro de um modo em que ela possa responder para o roteador questões sobre quais máquinas estão contidas na rede local. Nestes casos deve-se utilizar o comando: ifconfig arp eth1 Para garantir um fluxo de comunicação permanente, isso foi feito também nas demais placas. ifconfig arp eth0. 33..99.. CCoonnffiigguurraaççããoo ddaa BBrriiddggee Para habilitar o funcionamento da Bridge, deve-se ter o seguinte conteúdo no seu arquivo de configuração: brcfg -enable A configuração da Bridge apresentará alguns números. Pode-se experimentar o seu funcionamento ligando e desligando as portas, uma de cada vez: brcfg -port 0 -disable/-enable brcfg -port 1 -disable/-enable É possível ainda obter informações sobre o estado do sistema a qualquer momento, bastando informar: brcfg sem qualquer parâmetro. Pode-se perceber que a Bridge inicialmente ouve o tráfego, aprende e posteriormente executa o reenvio (não compreendo porque o código repete os mesmos endereços de hardware para as duas placas, mas não importa. O COMO FAZER de Christopher diz que isto está correto). 33..1100.. TTeessttaannddoo oo SSiisstteemmaa Caso se esteja testando realmente este roteiro e verificando a configuração, deve-se agora desabilitar as duas placas de rede através do comando: ifconfig eth0 down ifconfig eth1 down /etc/rc.d/rc.inet1 Com um pouco de sorte, os vários subsistemas (nnffss, yyppbbiinndd, etc.) não notarão a falta de comunicação imediatamente, porém isso deve ser realizado com o operador sentado na frente do teclado! Caso se queira ser mais cuidadoso, deve-se desativar previamente o maior número possível de programas servidores e desmontar os diretórios NFS. O pior que poderá acontecer é ter que reiniciar o sistema no modo monousuário (com o parâmetro "ssiinnggllee" do lliilloo ou llooaaddlliinn) e retirar as mudanças realizadas, antes de reinicializar o sistema no modo multiusuário. 33..1111.. VVeerriiffiiccaaççõõeess Deve ser checada a existência de tráfego diferente em cada uma das interfaces: tcpdump -i eth0 tcpdump -i eth1 O usuário deve habituar-se a usar o utilitário ttccppdduummpp para procurar por possíveis problemas de comunicação de rede. Por exemplo, procure os pacotes que foram enviados através da Bridge para a segunda placa da rede interna. No exemplo a seguir estamos procurando pacotes da máquina com endereço final igual a .22: tcpdump -i eth1 -e host 192.168.2.22 Deve-se então executar o comando ping destinado ao roteador. Deverá ser possível visualizar o pacote através do tcpdump. Neste estágio deve-se ter uma Bridge pronta que tem dois endereços de rede. Deve-se testar o funcionamento do "ping" de fora e de dentro da rede local, e verificar se é possível executar os utilitários "telnet" e "ftp" de dentro para fora e vice e versa. 44.. FFIIRREEWWAALLLLIINNGG 44..11.. SSooffttwwaarree ee LLeeiittuurraa É recomendada a leitura do COMO FAZER COMO FAZER Firewall . Ele descreverá como obter o programa iippffwwaaddmm, caso ele ainda não esteja disponível. Existem outras duas ferramentas que podem ser utilizadas, mas não fiz nenhum progresso até tentar o iippffwwaaddmm. Ele é bom, além de se poder visualizar exatamente o que ele está fazendo. 44..22.. VVeerriiffiiccaaççõõeess pprreelliimmiinnaarreess Caso o kernel esteja compilado com as opções IP-forwarding e masquerading, então é desejável que a proteção esteja em seu estado padrão (aceitando) através do comando: ipfwadm -I -l ipfwadm -O -l ipfwadm -F -l Isso mostra respectivamente, "as regras que afetam o " tráfego que entra, sai ou reenviado "pelo firewall". O parâmetro "-l" significa "listar". Caso se tenha compilado com a opção de contabilização pode ser utilizando ainda o comando: ipfwadm -A -l Neste caso pode-se verificar que não existem regras definidas e que o padrão indica que todos os pacotes transitados serão aceitos. Pode-se retornar para o modo normal de operação a qualquer momento através dos comandos: ipfwadm -I -f ipfwadm -O -f ipfwadm -F -f O parâmetro "-f" significa "atualizar". 44..33.. RReeggrraa ppaaddrrããoo Caso se deseje evitar qualquer tráfego externo em relação à rede interna, pode-se informar uma única regra (padrão) onde o firewall deve ignorar qualquer pacote vindo da rede interna destinado ao mundo exterior. As regras podem ser colocadas (nesta ordem) no arquivo //eettcc//rrcc..dd//rrcc..ffiirreewwaallll e executadas pelo //eettcc//rrcc..dd//rrcc..llooccaall durante a inicialização do sistema. ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0 O parâmetro "-S" indica o endereço e a máscara da origem do pacote. O parâmetro "-D" define o endereço e a máscara do destino do pacote. Este formato é denominado longo. O IIppffwwaaddmm reconhece nomes de redes e algumas abreviações comuns. Por favor verifique as páginas de manual on-line para maiores informações. É possivelmente mais conveniente e óbvio colocar algumas ou todas estas regras somente na metade de saída do firewall usando "-O" ao invés de "-I", porém para tornar os exemplos mais claros, apresentamos aqui as regras no seu formato completo. 44..44.. RReeggrraass ppoorr eennddeerreeççoo Antes da regra padrão, há que se colocar algumas regras que servem como exceções para esta recusa geral de serviços externos para clientes internos. Deve-se tratar o endereço da máquinas de firewall de forma especial na rede interna. No nosso exemplo é a máquina de endereço final igual a .100 . Vamos interromper o acesso de pessoas ao firewall, a não ser que elas tenham permissão especial, porém uma vez que elas tenham acesso, terão permissão de se comunicar com o mundo. ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 \ -D 0.0.0.0/0.0.0.0 Pode-se desejar ainda que os clientes internos estejam capacitados a falar com firewall. Talvez para eles possam persuadi-lo a deixá-los sair. ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 \ -D 192.168.2.100/255.255.255.255 Neste ponto, pode-se verificar que a rede admite clientes de fora do firewall, utilizando por exemplo tteellnneett, mas não se pode sair da rede local. Isto significa que é possível somente fazer o primeiro contato, mas os clientes externos não podem receber qualquer linha de comando. É possível entrar em todos os caminhos ao usar o firewall como um posto de verificação. Tente executar o comando rrllooggiinn e ppiinngg e verifique como o ttccppdduummpp opera com uma ou com a outra placa. 44..55.. RReeggrraass ppoorr pprroottooccoolloo Aqui continuamos a relatar as regras protocolo a protocolo. Neste caso queremos permitir que "pings" externos possam receber o eco do comando, por exemplo. Neste caso devemos inserir a seguinte regra: ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 \ -D 0.0.0.0/0.0.0.0 O parâmetro "-P icmp" funciona no protocolo especificado magicamente. Até que seja instalado um proxy ffttpp, queremos permitir ainda chamadas ftp em portas específicas. A seguinte regra permite que as portas 20, 21 e 115 sejam acessadas por máquinas externas. ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \ -D 0.0.0.0/0.0.0.0 20 21 115 Não foi possível conseguir com que o servidor de correio sseennddmmaaiill funcionasse com clientes locais sem um servidor de nomes. Melhor que configurar um servidor de nomes é configurá-lo no firewall, basta apenas aceitar através do firewall as solicitações do serviço de domínio de tcp destinadas ao servidor de nomes mais próximo e colocar seu endereço no arquivo //eettcc//rreessoollvv..ccoonnff dos clientes ("nameserver 123.456.789.31" em uma linha separada). ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \ -D 123.456.789.31/255.255.255.255 54 Pode-se descobrir qual o número da porta e o protocolo requisitados por um serviço utilizando o ttccppdduummpp. Para tanto deve-se iniciar o serviço com o comando ffttpp ou tteellnneett ou qualquer outro a partir de uma máquina interna e após pesquisá-lo nas portas de entrada e saída do firewall com o utilitário ttccppdduummpp: tcpdump -i eth1 -e host cliente04 por exemplo. O arquivo //eettcc//sseerrvviicceess é uma outra fonte importante de informações nestes casos. Para permitir o uso de tteellnneett e ffttpp de DENTRO para fora do firewall, é necessário permitir que os clientes locais acessem externamente uma porta específico. Entendo porque isto é necessário para o protocolo ffttpp - é o servidor que estabelece o fluxo de dados - mas não estou certo porque isso se faz necessário também para o programa tteellnneett. ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \ -D 0.0.0.0/0.0.0.0 Há um problema particular com alguns programas servidores que pesquisam pelo nome da máquina de firewall para decidir qual é o seu endereço de rede. RRppcc..yyppppaasssswwdddd é um dos que apresentam problemas. Ele insiste em transmitir informações dizendo que ele se encontra fora do firewall (na segunda placa). Isto significa que os clientes internos não podem contactá-la. Melhor que utilizar IPs alternativos ou mudar o código do servidor, é indicado mapear o nome do programa para o endereço da placa interna no arquivo //eettcc//hhoossttss. 44..66.. VVeerriiffiiccaaççõõeess Deve-se testar a configuração através de tteellnneett, rrllooggiinn e ppiinngg a partir de uma rede externa. Internamente deve ser possível executar o comando ppiinngg para uma máquina externa à rede. Deve ainda ser possível a execução de tteellnneett para a máquina de firewall a partir da rede interna e o firewall deve poder executar qualquer ação. É isto. Neste ponto provavelmente deve ser necessário conhecer um pouco mais sobre rrppcc, PPáginas AAmarelas e a interação com o arquivo de senhas. A rede protegida pode querer ainda que seus usuários sem privilégios possam se conectar ao firewall - e assim acessarem as redes externas. Bons temas para outros documentos COMO FAZER!