                    Pontes de Filtragem (Filtering Bridges)

  Alex Dupre

   <ale@FreeBSD.org>

   Revisao: 74f84751b4

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   3Com and HomeConnect are registered trademarks of 3Com Corporation.

   Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium,
   Pentium, and Xeon are trademarks or registered trademarks of Intel
   Corporation or its subsidiaries in the United States and other countries.

   Many of the designations used by manufacturers and sellers to distinguish
   their products are claimed as trademarks. Where those designations appear
   in this document, and the FreeBSD Project was aware of the trademark
   claim, the designations have been followed by the "(TM)" or the "(R)"
   symbol.

   2018-09-16 01:21:25 +0000 por Edson Brandi.
   Resumo

   Geralmente, e util dividir uma rede fisica (como uma Ethernet) em dois
   segmentos separados, sem precisar criar sub-redes, e usar um roteador para
   vincula-los. O dispositivo que conecta as duas redes dessa maneira e
   chamado de ponte (bridge). Um sistema FreeBSD com duas interfaces de rede
   e suficiente para atuar como uma ponte.

   Uma ponte funciona examinando os enderec,os do nivel MAC (enderec,os
   Ethernet) dos dispositivos conectados a cada uma de suas interfaces de
   rede e encaminhando o trafego entre as duas redes apenas se a origem e o
   destino estiverem em diferentes segmentos. Sob muitos pontos de vista, uma
   ponte e semelhante a um switch Ethernet com apenas duas portas.

   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   1. Por que usar uma ponte de filtragem?

   2. Como instalar

   3. Preparac,ao final

   4. Habilitando a ponte

   5. Configurando o Firewall

   6. Colaboradores

1. Por que usar uma ponte de filtragem?

   Cada vez mais frequentemente, grac,as aos custos reduzidos de conexoes de
   banda larga `a Internet (xDSL) e tambem devido `a reduc,ao de enderec,os
   IPv4 disponiveis, muitas empresas estao conectadas `a Internet 24 horas
   por dia e com poucos (`as vezes nem mesmo 2) enderec,os IP. Nestas
   situac,oes, geralmente e desejavel ter um firewall que filtre o trafego de
   entrada e de saida de e para a Internet, mas uma soluc,ao de filtragem de
   pacotes baseada em roteador pode nao ser aplicavel, quer seja devido a
   problemas de sub-redes, quer seja porque o roteador e de propriedade do
   provedor de conectividade (ISP), ou porque ele nao suporta tais
   funcionalidades. Nestes cenarios, o uso de uma ponte de filtragem e
   altamente recomendado.

   Um firewall baseado em uma ponte de filtragem pode ser configurado e
   inserido entre o roteador xDSL e seu hub/switch Ethernet sem causar nenhum
   problema de numerac,ao IP.

2. Como instalar

   Adicionar funcionalidades de bridge a um sistema FreeBSD nao e dificil.
   Desde a versao 4.5 e possivel carregar tais funcionalidades como modulos
   ao inves de ter que reconstruir o kernel, simplificando bastante o
   procedimento. Nas subsec,oes seguintes, explicarei as duas formas de
   instalac,ao.

  Importante:

   Nao siga as duas instruc,oes: um procedimento exclui o outro. Selecione a
   melhor opc,ao de acordo com suas necessidades e habilidades.

   Antes de continuar, certifique-se de ter pelo menos duas placas Ethernet
   compativeis com o modo promiscuo para recepc,ao e transmissao, pois elas
   devem ser capazes de enviar pacotes Ethernet com qualquer enderec,o, nao
   apenas o deles. Alem disso, para ter uma boa taxa de transferencia, as
   placas devem ser placas do barramento PCI. As melhores opc,oes ainda sao
   as Intel EtherExpress(TM) Pro, seguido pela serie 3Com(R) 3c9xx. Para
   simplificar a configurac,ao do firewall, pode ser util ter duas placas de
   diferentes fabricantes (usando drivers diferentes) para distinguir
   claramente qual interface esta conectada ao roteador e qual esta conectada
   `a rede interna.

  2.1. Configurac,ao do Kernel

   Entao voce decidiu usar o metodo de instalac,ao mais antigo, e tambem o
   mais bem testado. Para comec,ar, voce precisa adicionar as seguintes
   linhas ao seu arquivo de configurac,ao do kernel:

 options BRIDGE
 options IPFIREWALL
 options IPFIREWALL_VERBOSE

   A primeira linha adiciona o suporte para o servic,o de ponte (bridge), a
   segunda adiciona o suporte ao firewall e a terceira e referente as
   func,oes de registro do firewall.

   Agora e necessario compilar e instalar o novo kernel. Voce pode encontrar
   instruc,oes detalhadas na sec,ao Compilando e Instalando um Kernel
   Personalizado do Handbook do FreeBSD.

  2.2. Carregamento de modulos

   Se voce escolheu usar o metodo de instalac,ao mais novo e mais simples, a
   unica coisa a fazer agora e adicionar a seguinte linha ao
   /boot/loader.conf:

 bridge_load="YES"

   Desta forma, durante a inicializac,ao do sistema, o modulo bridge.ko sera
   carregado junto com o kernel. Nao e necessario adicionar uma linha
   semelhante para o modulo ipfw.ko, pois ele sera carregado automaticamente
   apos a execuc,ao das etapas na sec,ao a seguir.

3. Preparac,ao final

   Antes de reinicializar para carregar o novo kernel ou os modulos
   requeridos (de acordo com o metodo de instalac,ao escolhido
   anteriormente), voce deve fazer algumas alterac,oes no arquivo de
   configurac,ao /etc/rc.conf. A regra padrao do firewall e rejeitar todos os
   pacotes IP. Inicialmente vamos configurar um firewall open (aberto), a fim
   de verificar sua operac,ao sem qualquer problema relacionado `a filtragem
   de pacotes (no caso de voce executar este procedimento remotamente, tal
   configurac,ao evitara que voce permanec,a isolado da rede). Coloque estas
   linhas no /etc/rc.conf:

 firewall_enable="YES"
 firewall_type="open"
 firewall_quiet="YES"
 firewall_logging="YES"

   A primeira linha ativara o firewall (e carregara o modulo ipfw.ko se ele
   nao estiver compilado no kernel), a segunda ira configura-lo no modo open
   (como explicado em /etc/rc.firewall), a terceira para nao mostrar o
   carregamento de regras e a quarta para ativar o suporte aos logs.

   Sobre a configurac,ao das interfaces de rede, a maneira mais usada e
   atribuir um IP a apenas uma das placas de rede, mas a ponte funcionara
   igualmente, mesmo que ambas as interfaces ou nenhuma tenha um IP
   configurado. No ultimo caso (IP-less) a maquina bridge ficara ainda mais
   oculta, e tambem inacessivel pela rede: para configura-la sera necessario
   efetuar o login a partir do console ou atraves de uma terceira interface
   de rede separada da ponte. As vezes, durante a inicializac,ao do sistema,
   alguns programas exigem acesso `a rede, digamos, para resoluc,ao de nomes
   de dominio: neste caso, e necessario atribuir um IP `a interface externa
   (aquela conectada `a Internet, onde o servidor DNS se encontra), uma vez
   que a ponte sera ativada no final do procedimento de inicializac,ao. Isso
   significa que a interface fxp0 (no nosso caso) deve ser mencionada na
   sec,ao ifconfig do arquivo /etc/rc.conf, enquanto o xl0 nao e. Atribuir um
   IP a ambas as placas de rede nao faz muito sentido, a menos que, durante o
   procedimento de inicializac,ao, os aplicativos acessem os servic,os em
   ambos os segmentos de Ethernet.

   Ha outra coisa importante a saber. Ao executar o IP sobre Ethernet,
   existem dois protocolos Ethernet em uso: um e o IP, o outro e o ARP. O ARP
   faz a conversao do enderec,o IP de um host em seu enderec,o Ethernet
   (camada MAC). Para permitir a comunicac,ao entre dois hosts separados pela
   ponte, e necessario que a ponte envie pacotes ARP. Esse protocolo nao esta
   incluido na camada IP, uma vez que ele existe apenas com IP sobre
   Ethernet. O firewall do FreeBSD filtra exclusivamente na camada IP e,
   portanto, todos os pacotes nao-IP (ARP incluso) serao encaminhados sem
   serem filtrados, mesmo que o firewall esteja configurado para nao permitir
   nada.

   Agora e hora de reiniciar o sistema e usa-lo como antes: havera algumas
   novas mensagens sobre a ponte e o firewall, mas a ponte nao sera ativada e
   o firewall, estando no modo open, nao evitara operac,oes.

   Se houver algum problema, voce deve resolve-los agora antes de prosseguir.

4. Habilitando a ponte

   Neste ponto, para habilitar a ponte, voce tem que executar os seguintes
   comandos (tendo a perspicacia para substituir os nomes das duas interfaces
   de rede fxp0 e xl0 com as suas proprias):

 # sysctl net.link.ether.bridge.config=fxp0:0,xl0:0
 # sysctl net.link.ether.bridge.ipfw=1
 # sysctl net.link.ether.bridge.enable=1

   A primeira linha especifica quais interfaces devem ser ativadas pela
   ponte, a segunda habilitara o firewall na ponte e, finalmente, a terceira
   habilitara a ponte.

  Nota:

   Se voce tem o FreeBSD 5.1-RELEASE ou anterior, as variaveis do sysctl sao
   escritas de forma diferente. Veja bridge(4) para detalhes.

   Neste ponto voce deve ser capaz de inserir a maquina entre dois conjuntos
   de hosts sem comprometer quaisquer habilidades de comunicac,ao entre eles.
   Em caso afirmativo, o proximo passo e adicionar as partes
   net.link.ether.bridge.[blah]=[blah] dessas linhas ao arquivo
   /etc/sysctl.conf, para que eles sejam executados na inicializac,ao.

5. Configurando o Firewall

   Agora e hora de criar seu proprio arquivo com regras de firewall
   personalizadas, a fim de proteger a rede interna. Havera alguma
   complicac,ao em fazer isso porque nem todas as funcionalidades do firewall
   estao disponiveis em pacotes em ponte. Alem disso, ha uma diferenc,a entre
   os pacotes que estao sendo encaminhados e os pacotes que estao sendo
   recebidos pela maquina local. Em geral, os pacotes de entrada passam pelo
   firewall apenas uma vez, nao duas vezes, como e normalmente o caso; na
   verdade eles sao filtrados somente apos o recebimento, portanto, as regras
   que usam out ou xmit nunca darao match. Pessoalmente, eu uso in via que e
   uma sintaxe antiga, mas uma que tem sentido quando voce a le. Outra
   limitac,ao e que voce esta restrito a usar somente comandos pass ou drop
   para os pacotes filtrados por uma ponte. Coisas sofisticadas como divert,
   forwar ou reject nao estao disponiveis. Essas opc,oes ainda podem ser
   usadas, mas apenas no trafego para ou a partir da propria maquina ponte
   (se ela tiver um enderec,o IP).

   O conceito de filtragem stateful e novo no FreeBSD 4.0. Esta e uma grande
   melhoria para o trafego UDP, que normalmente e um pedido que sai, seguido
   pouco depois por uma resposta com exatamente o mesmo conjunto de
   enderec,os IP e numeros de porta (mas com origem e destino invertidos, e
   claro). Para firewalls que nao possuem manutenc,ao de estado, quase nao ha
   como lidar com esse tipo de trafego como uma sessao unica. Mas com um
   firewall que pode "lembrar" de um pacote UDP de saida e, nos proximos
   minutos, permitir uma resposta, o manuseio de servic,os UDP e trivial. O
   exemplo a seguir mostra como fazer isso. E possivel fazer a mesma coisa
   com pacotes TCP. Isso permite que voce evite alguns ataques de negac,ao de
   servic,o e outros truques desagradaveis, mas tambem faz com que sua tabela
   de estado cresc,a rapidamente em tamanho.

   Vamos ver um exemplo de configurac,ao. Note primeiro que no topo do
   /etc/rc.firewall ja existem regras padrao para a interface de loopback
   lo0, entao nao devemos mais precisar delas. Regras customizadas devem ser
   colocadas em um arquivo separado (digamos, /etc/rc.firewall.local) e
   carregadas na inicializac,ao do sistema, modificando a linha de
   /etc/rc.conf onde definimos o firewall open:

 firewall_type="/etc/rc.firewall.local"

  Importante:

   Voce tem que especificar o caminho completo, caso contrario ele nao sera
   carregado com o risco de permanecer isolado da rede.

   Para nosso exemplo, imagine ter a interface fxp0 conectada para o exterior
   (Internet) e a xl0 para o interior (LAN). A maquina ponte tem o IP 1.2.3.4
   (nao e possivel que o seu ISP possa lhe dar um enderec,o assim, mas para
   nosso exemplo ele e bom).

 # Things that we have kept state on before get to go through in a hurry
 add check-state

 # Throw away RFC 1918 networks
 add drop all from 10.0.0.0/8 to any in via fxp0
 add drop all from 172.16.0.0/12 to any in via fxp0
 add drop all from 192.168.0.0/16 to any in via fxp0

 # Allow the bridge machine to say anything it wants
 # (if the machine is IP-less do not include these rows)
 add pass tcp from 1.2.3.4 to any setup keep-state
 add pass udp from 1.2.3.4 to any keep-state
 add pass ip from 1.2.3.4 to any

 # Allow the inside hosts to say anything they want
 add pass tcp from any to any in via xl0 setup keep-state
 add pass udp from any to any in via xl0 keep-state
 add pass ip from any to any in via xl0

 # TCP section
 # Allow SSH
 add pass tcp from any to any 22 in via fxp0 setup keep-state
 # Allow SMTP only towards the mail server
 add pass tcp from any to relay 25 in via fxp0 setup keep-state
 # Allow zone transfers only by the slave name server [dns2.nic.it]
 add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
 # Pass ident probes.  It is better than waiting for them to timeout
 add pass tcp from any to any 113 in via fxp0 setup keep-state
 # Pass the "quarantine" range
 add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state

 # UDP section
 # Allow DNS only towards the name server
 add pass udp from any to ns 53 in via fxp0 keep-state
 # Pass the "quarantine" range
 add pass udp from any to any 49152-65535 in via fxp0 keep-state

 # ICMP section
 # Pass 'ping'
 add pass icmp from any to any icmptypes 8 keep-state
 # Pass error messages generated by 'traceroute'
 add pass icmp from any to any icmptypes 3
 add pass icmp from any to any icmptypes 11

 # Everything else is suspect
 add drop log all from any to any

   Aqueles de voces que ja configuraram firewalls antes podem notar algumas
   coisas que estao faltando. Em particular, nao ha regras anti-spoofing, na
   verdade nos nao adicionamos:

 add deny all from 1.2.3.4/8 to any in via fxp0

   Ou seja, dropar os pacotes que estao vindo do lado de fora dizendo ser da
   nossa rede. Isso e algo que voce normalmente faria para ter certeza de que
   alguem nao tentaria escapar do filtro de pacotes, gerando pacotes nefastos
   que parecem ser de dentro. O problema e que existe pelo menos um host na
   interface externa que voce nao deseja ignorar: o roteador. Mas geralmente
   ISP tem anti-spoofs em seu roteador, entao nao precisamos nos incomodar
   muito.

   A ultima regra parece ser uma duplicata exata da regra padrao, ou seja,
   nao deixa passar nada que nao seja especificamente permitido. Mas ha uma
   diferenc,a: todo trafego suspeito sera registrado.

   Existem duas regras para passar o trafego SMTP e o do DNS para o servidor
   de e-mail e o servidor de nomes, se voce os tiver. Obviamente, todo o
   conjunto de regras deve ser definido de acordo com as suas preferencias
   pessoais, isso e apenas um exemplo especifico (o formato da regra e
   descrito com precisao na pagina de manual do ipfw(8)). Note que, para que
   o "relay" e o "ns" funcionem, as pesquisas de servic,o de nomes devem
   funcionar antes da ponte ser ativada. Este e um exemplo de quando voce
   precisa ter certeza de que definiu o IP na placa de rede correta. Como
   alternativa, e possivel especificar o enderec,o IP em vez do nome do host
   (necessario se a maquina nao tiver IP).

   As pessoas que estao acostumadas a configurar firewalls provavelmente
   tambem estao acostumadas a ter uma regra reset ou forward para pacotes
   ident (TCP porta 113). Infelizmente, esta nao e uma opc,ao aplicavel com a
   ponte, entao o melhor e simplesmente passa-las ao seu destino. Enquanto
   essa maquina de destino nao estiver executando um daemon ident, isso e
   relativamente inofensivo. A alternativa e descartar as conexoes na porta
   113, o que criara alguns problemas com servic,os como por exemplo o IRC (o
   probe do ident ira dar timeout).

   A unica outra coisa que e um pouco estranha e que voce pode ter notado e
   que existe uma regra para deixar a maquina ponte falar, e outra para os
   hosts internos. Lembre-se que isso ocorre porque os dois conjuntos de
   trafego terao caminhos diferentes atraves do kernel e do filtro de
   pacotes. A rede interna passara pela ponte, enquanto a maquina local usara
   a pilha IP normal para falar. Assim, as duas regras lidam com casos
   diferentes. As regras in via fxp0 funcionam nos dois caminhos. Em geral,
   se voce usar as regras in via em todo o filtro, precisara abrir uma
   excec,ao para pacotes gerados localmente, porque eles nao vieram em
   nenhuma de nossas interfaces.

6. Colaboradores

   Muitas partes deste artigo foram tiradas, atualizadas e adaptadas de um
   texto antigo sobre pontes, editado por Nick Sayer. Um par de inspirac,oes
   deve-se a uma introduc,ao sobre pontes de Steve Peterson.

   Um grande obrigado ao Luigi Rizzo pela implementac,ao do codigo de ponte
   (bridge) no FreeBSD e pelo tempo que ele dedicou a mim respondendo a todas
   as minhas perguntas relacionadas.

   Agradec,o tambem a Tom Rhodes, que olhou para o meu trabalho de traduc,ao
   do italiano (a lingua original deste artigo) para o ingles.
