The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: sect1/para
English
There is another important thing to know. When running IP over Ethernet, there are actually two Ethernet protocols in use: one is IP, the other is <acronym>ARP</acronym>. <acronym>ARP</acronym> does the conversion of the IP address of a host into its Ethernet address (<acronym>MAC</acronym> layer). In order to allow the communication between two hosts separated by the bridge, it is necessary that the bridge will forward <acronym>ARP</acronym> packets. Such protocol is not included in the IP layer, since it exists only with IP over Ethernet. The FreeBSD firewall filters exclusively on the IP layer and therefore all non-IP packets (<acronym>ARP</acronym> included) will be forwarded without being filtered, even if the firewall is configured to not permit anything.
742/7710 · 771
Context English Portuguese (Brazil) State
Before going on, be sure to have at least two Ethernet cards that support the promiscuous mode for both reception and transmission, since they must be able to send Ethernet packets with any address, not just their own. Moreover, to have a good throughput, the cards should be PCI bus mastering cards. The best choices are still the Intel <trademark>EtherExpress</trademark> Pro, followed by the <trademark class="registered">3Com</trademark> 3c9xx series. To simplify the firewall configuration it may be useful to have two cards of different manufacturers (using different drivers) in order to distinguish clearly which interface is connected to the router and which to the inner network. Antes de continuar, certifique-se de ter pelo menos duas placas Ethernet compatíveis com o modo promíscuo para recepção e transmissão, pois elas devem ser capazes de enviar pacotes Ethernet com qualquer endereço, não apenas o deles. Além disso, para ter uma boa taxa de transferência, as placas devem ser placas do barramento PCI. As melhores opções ainda são as Intel <trademark>EtherExpress</trademark> Pro, seguido pela série <trademark class="registered">3Com</trademark> 3c9xx. Para simplificar a configuração do firewall, pode ser útil ter duas placas de diferentes fabricantes (usando drivers diferentes) para distinguir claramente qual interface está conectada ao roteador e qual está conectada à rede interna.
Kernel Configuration Configuração do Kernel
So you have decided to use the older but well tested installation method. To begin, you have to add the following rows to your kernel configuration file: Então você decidiu usar o método de instalação mais antigo, e também o mais bem testado. Para começar, você precisa adicionar as seguintes linhas ao seu arquivo de configuração do kernel:
options BRIDGE
options IPFIREWALL
options IPFIREWALL_VERBOSE 		options BRIDGE
options IPFIREWALL
options IPFIREWALL_VERBOSE
The first line is to compile the bridge support, the second one is the firewall and the third one is the logging functions of the firewall. A primeira linha adiciona o suporte para o serviço de ponte (bridge), a segunda adiciona o suporte ao firewall e a terceira é referente as funções de registro do firewall.
Now it is necessary to build and install the new kernel. You may find detailed instructions in the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html">Building and Installing a Custom Kernel</link> section of the FreeBSD Handbook. Agora é necessário compilar e instalar o novo kernel. Você pode encontrar instruções detalhadas na seção <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html">Compilando e Instalando um Kernel Personalizado</link> do Handbook do FreeBSD.
Modules Loading Carregamento de módulos
If you have chosen to use the new and simpler installation method, the only thing to do now is add the following row to <filename>/boot/loader.conf</filename>: Se você escolheu usar o método de instalação mais novo e mais simples, a única coisa a fazer agora é adicionar a seguinte linha ao <filename>/boot/loader.conf</filename>:
bridge_load="YES" bridge_load="YES"
In this way, during the system startup, the <filename>bridge.ko</filename> module will be loaded together with the kernel. It is not required to add a similar row for the <filename>ipfw.ko</filename> module, since it will be loaded automatically after the execution of the steps in the following section. Desta forma, durante a inicialização do sistema, o módulo <filename>bridge.ko</filename> será carregado junto com o kernel. Não é necessário adicionar uma linha semelhante para o módulo <filename>ipfw.ko</filename>, pois ele será carregado automaticamente após a execução das etapas na seção a seguir.
Final Preparation Preparação final
Before rebooting in order to load the new kernel or the required modules (according to the previously chosen installation method), you have to make some changes to the <filename>/etc/rc.conf</filename> configuration file. The default rule of the firewall is to reject all IP packets. Initially we will set up an <option>open</option> firewall, in order to verify its operation without any issue related to packet filtering (in case you are going to execute this procedure remotely, such configuration will avoid you to remain isolated from the network). Put these lines in <filename>/etc/rc.conf</filename>: Antes de reinicializar para carregar o novo kernel ou os módulos requeridos (de acordo com o método de instalação escolhido anteriormente), você deve fazer algumas alterações no arquivo de configuração <filename>/etc/rc.conf</filename>. A regra padrão do firewall é rejeitar todos os pacotes IP. Inicialmente vamos configurar um firewall <option>open</option> (aberto), a fim de verificar sua operação sem qualquer problema relacionado à filtragem de pacotes (no caso de você executar este procedimento remotamente, tal configuração evitará que você permaneça isolado da rede). Coloque estas linhas no <filename>/etc/rc.conf</filename>:
firewall_enable="YES"
firewall_type="open"
firewall_quiet="YES"
firewall_logging="YES" 		firewall_enable="YES"
firewall_type="open"
firewall_quiet="YES"
firewall_logging="YES"
The first row will enable the firewall (and will load the module <filename>ipfw.ko</filename> if it is not compiled in the kernel), the second one to set up it in <option>open</option> mode (as explained in <filename>/etc/rc.firewall</filename>), the third one to not show rules loading and the fourth one to enable logging support. A primeira linha ativará o firewall (e carregará o módulo <filename>ipfw.ko</filename> se ele não estiver compilado no kernel), a segunda irá configurá-lo no modo <option>open</option> (como explicado em <filename>/etc/rc.firewall</filename>), a terceira para não mostrar o carregamento de regras e a quarta para ativar o suporte aos logs.
About the configuration of the network interfaces, the most used way is to assign an IP to only one of the network cards, but the bridge will work equally even if both interfaces or none has a configured IP. In the last case (IP-less) the bridge machine will be still more hidden, as inaccessible from the network: to configure it, you have to login from console or through a third network interface separated from the bridge. Sometimes, during the system startup, some programs require network access, say for domain resolution: in this case it is necessary to assign an IP to the external interface (the one connected to Internet, where <acronym>DNS</acronym> server resides), since the bridge will be activated at the end of the startup procedure. It means that the <filename>fxp0</filename> interface (in our case) must be mentioned in the ifconfig section of the <filename>/etc/rc.conf</filename> file, while the <filename>xl0</filename> is not. Assigning an IP to both the network cards does not make much sense, unless, during the start procedure, applications should access to services on both Ethernet segments. Sobre a configuração das interfaces de rede, a maneira mais usada é atribuir um IP a apenas uma das placas de rede, mas a ponte funcionará igualmente, mesmo que ambas as interfaces ou nenhuma tenha um IP configurado. No último caso (IP-less) a máquina bridge ficará ainda mais oculta, e também inacessível pela rede: para configurá-la será necessário efetuar o login a partir do console ou através de uma terceira interface de rede separada da ponte. Às vezes, durante a inicialização do sistema, alguns programas exigem acesso à rede, digamos, para resolução de nomes de domínio: neste caso, é necessário atribuir um IP à interface externa (aquela conectada à Internet, onde o servidor <acronym>DNS</acronym> se encontra), uma vez que a ponte será ativada no final do procedimento de inicialização. Isso significa que a interface <filename>fxp0</filename> (no nosso caso) deve ser mencionada na seção ifconfig do arquivo <filename>/etc/rc.conf</filename>, enquanto o <filename>xl0</filename> não é. Atribuir um IP a ambas as placas de rede não faz muito sentido, a menos que, durante o procedimento de inicialização, os aplicativos acessem os serviços em ambos os segmentos de Ethernet.
There is another important thing to know. When running IP over Ethernet, there are actually two Ethernet protocols in use: one is IP, the other is <acronym>ARP</acronym>. <acronym>ARP</acronym> does the conversion of the IP address of a host into its Ethernet address (<acronym>MAC</acronym> layer). In order to allow the communication between two hosts separated by the bridge, it is necessary that the bridge will forward <acronym>ARP</acronym> packets. Such protocol is not included in the IP layer, since it exists only with IP over Ethernet. The FreeBSD firewall filters exclusively on the IP layer and therefore all non-IP packets (<acronym>ARP</acronym> included) will be forwarded without being filtered, even if the firewall is configured to not permit anything. Há outra coisa importante a saber. Ao executar o IP sobre Ethernet, existem dois protocolos Ethernet em uso: um é o IP, o outro é o <acronym>ARP</acronym>. O <acronym>ARP</acronym> faz a conversão do endereço IP de um host em seu endereço Ethernet (camada <acronym>MAC</acronym>). Para permitir a comunicação entre dois hosts separados pela ponte, é necessário que a ponte envie pacotes <acronym>ARP</acronym>. Esse protocolo não está incluído 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 não-IP (<acronym>ARP</acronym> incluso) serão encaminhados sem serem filtrados, mesmo que o firewall esteja configurado para não permitir nada.
Now it is time to reboot the system and use it as before: there will be some new messages about the bridge and the firewall, but the bridge will not be activated and the firewall, being in <option>open</option> mode, will not avoid any operations. Agora é hora de reiniciar o sistema e usá-lo como antes: haverá algumas novas mensagens sobre a ponte e o firewall, mas a ponte não será ativada e o firewall, estando no modo <option>open</option>, não evitará operações.
If there are any problems, you should sort them out now before proceeding. Se houver algum problema, você deve resolvê-los agora antes de prosseguir.
Enabling the Bridge Habilitando a Bridge
At this point, to enable the bridge, you have to execute the following commands (having the shrewdness to replace the names of the two network interfaces <filename>fxp0</filename> and <filename>xl0</filename> with your own ones): Neste ponto, para habilitar a ponte, você tem que executar os seguintes comandos (tendo a perspicácia para substituir os nomes das duas interfaces de rede <filename>fxp0</filename> e <filename>xl0</filename> com as suas próprias):
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.config=fxp0:0,xl0:0</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.ipfw=1</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.enable=1</userinput> 		<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.config=fxp0:0,xl0:0</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.ipfw=1</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.enable=1</userinput>
The first row specifies which interfaces should be activated by the bridge, the second one will enable the firewall on the bridge and finally the third one will enable the bridge. A primeira linha especifica quais interfaces devem ser ativadas pela ponte, a segunda habilitará o firewall na ponte e, finalmente, a terceira habilitará a ponte.
At this point you should be able to insert the machine between two sets of hosts without compromising any communication abilities between them. If so, the next step is to add the <literal>net.link.ether.bridge.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal> portions of these rows to the <filename>/etc/sysctl.conf</filename> file, in order to have them execute at startup. Neste ponto você deve ser capaz de inserir a máquina entre dois conjuntos de hosts sem comprometer quaisquer habilidades de comunicação entre eles. Em caso afirmativo, o próximo passo é adicionar as partes <literal>net.link.ether.bridge.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal> dessas linhas ao arquivo <filename>/etc/sysctl.conf</filename>, para que eles sejam executados na inicialização.
Configuring The Firewall Configurando o Firewall
Now it is time to create your own file with custom firewall rules, in order to secure the inside network. There will be some complication in doing this because not all of the firewall functionalities are available on bridged packets. Furthermore, there is a difference between the packets that are in the process of being forwarded and packets that are being received by the local machine. In general, incoming packets are run through the firewall only once, not twice as is normally the case; in fact they are filtered only upon receipt, so rules that use <option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an older syntax, but one that has a sense when you read it. Another limitation is that you are restricted to use only <option>pass</option> or <option>drop</option> commands for packets filtered by a bridge. Sophisticated things like <option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can still be used, but only on traffic to or from the bridge machine itself (if it has an IP address). Agora é hora de criar seu próprio arquivo com regras de firewall personalizadas, a fim de proteger a rede interna. Haverá alguma complicação em fazer isso porque nem todas as funcionalidades do firewall estão disponíveis em pacotes em ponte. Além disso, há uma diferença entre os pacotes que estão sendo encaminhados e os pacotes que estão sendo recebidos pela máquina local. Em geral, os pacotes de entrada passam pelo firewall apenas uma vez, não duas vezes, como é normalmente o caso; na verdade eles são filtrados somente após o recebimento, portanto, as regras que usam <option>out</option> ou <option>xmit</option> nunca darão match. Pessoalmente, eu uso <option>in via</option> que é uma sintaxe antiga, mas uma que tem sentido quando você a lê. Outra limitação é que você está restrito a usar somente comandos <option>pass</option> ou <option>drop</option> para os pacotes filtrados por uma ponte. Coisas sofisticadas como <option>divert</option>, <option>forwar </option> ou <option>reject</option> não estão disponíveis. Essas opções ainda podem ser usadas, mas apenas no tráfego para ou a partir da própria máquina ponte (se ela tiver um endereço IP).
New in FreeBSD 4.0, is the concept of stateful filtering. This is a big improvement for <acronym>UDP</acronym> traffic, which typically is a request going out, followed shortly thereafter by a response with the exact same set of IP addresses and port numbers (but with source and destination reversed, of course). For firewalls that have no statekeeping, there is almost no way to deal with this sort of traffic as a single session. But with a firewall that can <quote>remember</quote> an outgoing <acronym>UDP</acronym> packet and, for the next few minutes, allow a response, handling <acronym>UDP</acronym> services is trivial. The following example shows how to do it. It is possible to do the same thing with <acronym>TCP</acronym> packets. This allows you to avoid some denial of service attacks and other nasty tricks, but it also typically makes your state table grow quickly in size. O conceito de filtragem stateful é novo no FreeBSD 4.0. Esta é uma grande melhoria para o tráfego <acronym>UDP</acronym>, que normalmente é um pedido que sai, seguido pouco depois por uma resposta com exatamente o mesmo conjunto de endereços IP e números de porta (mas com origem e destino invertidos, é claro). Para firewalls que não possuem manutenção de estado, quase não há como lidar com esse tipo de tráfego como uma sessão única. Mas com um firewall que pode <quote>lembrar</quote> de um pacote <acronym>UDP</acronym> de saída e, nos próximos minutos, permitir uma resposta, o manuseio de serviços <acronym>UDP</acronym> é trivial. O exemplo a seguir mostra como fazer isso. É possível fazer a mesma coisa com pacotes <acronym>TCP</acronym>. Isso permite que você evite alguns ataques de negação de serviço e outros truques desagradáveis, mas também faz com que sua tabela de estado cresça rapidamente em tamanho.
Let's look at an example setup. Note first that at the top of <filename>/etc/rc.firewall</filename> there are already standard rules for the loopback interface <filename>lo0</filename>, so we should not have to care for them anymore. Custom rules should be put in a separate file (say <filename>/etc/rc.firewall.local</filename>) and loaded at system startup, by modifying the row of <filename>/etc/rc.conf</filename> where we defined the <option>open</option> firewall: Vamos ver um exemplo de configuração. Note primeiro que no topo do <filename>/etc/rc.firewall</filename> já existem regras padrão para a interface de loopback <filename>lo0</filename>, então não devemos mais precisar delas. Regras customizadas devem ser colocadas em um arquivo separado (digamos, <filename>/etc/rc.firewall.local</filename>) e carregadas na inicialização do sistema, modificando a linha de <filename>/etc/rc.conf </filename> onde definimos o firewall <option>open</option>:
firewall_type="/etc/rc.firewall.local" firewall_type="/etc/rc.firewall.local"
You have to specify the <emphasis>full</emphasis> path, otherwise it will not be loaded with the risk to remain isolated from the network. Você tem que especificar o caminho <emphasis>completo</emphasis>, caso contrário ele não será carregado com o risco de permanecer isolado da rede.
For our example imagine to have the <filename>fxp0</filename> interface connected towards the outside (Internet) and the <filename>xl0</filename> towards the inside (<acronym>LAN</acronym>). The bridge machine has the IP <systemitem class="ipaddress">1.2.3.4</systemitem> (it is not possible that your <acronym>ISP</acronym> can give you an address quite like this, but for our example it is good). Para nosso exemplo, imagine ter a interface <filename>fxp0</filename> conectada para o exterior (Internet) e a <filename>xl0</filename> para o interior (<acronym>LAN</acronym>). A máquina ponte tem o IP <systemitem class="ipaddress">1.2.3.4</systemitem> (não é possível que o seu <acronym>ISP</acronym> possa lhe dar um endereço assim, mas para nosso exemplo ele é 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 		# 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

Loading…

No matching activity found.

Browse all component changes

Things to check

Double space

Translation contains double space

Fix string

Reset

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Source string location
article.translate.xml:177
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/filtering-bridges.po, string 33