Translation

(itstool) path: sect1/para
A thanks goes out also to Tom Rhodes who looked over my job of translation from Italian (the original language of this article) into English.
131/1410
Context English Portuguese (Brazil) State
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
Those of you who have set up firewalls before may notice some things missing. In particular, there are no anti-spoofing rules, in fact we did <emphasis>not</emphasis> add: Aqueles de vocês que já configuraram firewalls antes podem notar algumas coisas que estão faltando. Em particular, não há regras anti-spoofing, na verdade nós <emphasis>não</emphasis> adicionamos:
add deny all from 1.2.3.4/8 to any in via fxp0 add deny all from 1.2.3.4/8 to any in via fxp0
That is, drop packets that are coming in from the outside claiming to be from our network. This is something that you would commonly do to be sure that someone does not try to evade the packet filter, by generating nefarious packets that look like they are from the inside. The problem with that is that there is <emphasis>at least</emphasis> one host on the outside interface that you do not want to ignore: the router. But usually, the <acronym>ISP</acronym> anti-spoofs at their router, so we do not need to bother that much. Ou seja, dropar os pacotes que estão vindo do lado de fora dizendo ser da nossa rede. Isso é algo que você normalmente faria para ter certeza de que alguém não tentaria escapar do filtro de pacotes, gerando pacotes nefastos que parecem ser de dentro. O problema é que existe <emphasis>pelo menos</emphasis> um host na interface externa que você não deseja ignorar: o roteador. Mas geralmente <acronym>ISP</acronym> tem anti-spoofs em seu roteador, então não precisamos nos incomodar muito.
The last rule seems to be an exact duplicate of the default rule, that is, do not let anything pass that is not specifically allowed. But there is a difference: all suspected traffic will be logged. A última regra parece ser uma duplicata exata da regra padrão, ou seja, não deixa passar nada que não seja especificamente permitido. Mas há uma diferença: todo tráfego suspeito será registrado.
There are two rules for passing <acronym>SMTP</acronym> and <acronym>DNS</acronym> traffic towards the mail server and the name server, if you have them. Obviously the whole rule set should be flavored to personal taste, this is only a specific example (rule format is described accurately in the <citerefentry><refentrytitle>ipfw</refentrytitle><manvolnum>8</manvolnum></citerefentry> man page). Note that in order for <quote>relay</quote> and <quote>ns</quote> to work, name service lookups must work <emphasis>before</emphasis> the bridge is enabled. This is an example of making sure that you set the IP on the correct network card. Alternatively it is possible to specify the IP address instead of the host name (required if the machine is IP-less). Existem duas regras para passar o tráfego <acronym>SMTP</acronym> e o do <acronym>DNS</acronym> para o servidor de e-mail e o servidor de nomes, se você os tiver. Obviamente, todo o conjunto de regras deve ser definido de acordo com as suas preferências pessoais, isso é apenas um exemplo específico (o formato da regra é descrito com precisão na página de manual do <citerefentry><refentrytitle>ipfw</refentrytitle><manvolnum>8</manvolnum> </citerefentry>). Note que, para que o <quote>relay</quote> e o <quote>ns</quote> funcionem, as pesquisas de serviço de nomes devem funcionar <emphasis>antes</emphasis> da ponte ser ativada. Este é um exemplo de quando você precisa ter certeza de que definiu o IP na placa de rede correta. Como alternativa, é possível especificar o endereço IP em vez do nome do host (necessário se a máquina não tiver IP).
People that are used to setting up firewalls are probably also used to either having a <option>reset</option> or a <option>forward</option> rule for ident packets (<acronym>TCP</acronym> port 113). Unfortunately, this is not an applicable option with the bridge, so the best thing is to simply pass them to their destination. As long as that destination machine is not running an ident daemon, this is relatively harmless. The alternative is dropping connections on port 113, which creates some problems with services like <acronym>IRC</acronym> (the ident probe must timeout). As pessoas que estão acostumadas a configurar firewalls provavelmente também estão acostumadas a ter uma regra <option>reset</option> ou <option>forward</option> para pacotes ident (<acronym>TCP</acronym> porta 113). Infelizmente, esta não é uma opção aplicável com a ponte, então o melhor é simplesmente passá-las ao seu destino. Enquanto essa máquina de destino não estiver executando um daemon ident, isso é relativamente inofensivo. A alternativa é descartar as conexões na porta 113, o que criará alguns problemas com serviços como por exemplo o <acronym>IRC</acronym> (o probe do ident irá dar timeout).
The only other thing that is a little weird that you may have noticed is that there is a rule to let the bridge machine speak, and another for internal hosts. Remember that this is because the two sets of traffic will take different paths through the kernel and into the packet filter. The inside net will go through the bridge, while the local machine will use the normal IP stack to speak. Thus the two rules to handle the different cases. The <literal>in via fxp0</literal> rules work for both paths. In general, if you use <option>in via</option> rules throughout the filter, you will need to make an exception for locally generated packets, because they did not come in via any of our interfaces. A única outra coisa que é um pouco estranha e que você pode ter notado é que existe uma regra para deixar a máquina ponte falar, e outra para os hosts internos. Lembre-se que isso ocorre porque os dois conjuntos de tráfego terão caminhos diferentes através do kernel e do filtro de pacotes. A rede interna passará pela ponte, enquanto a máquina local usará a pilha IP normal para falar. Assim, as duas regras lidam com casos diferentes. As regras <literal>in via fxp0</literal> funcionam nos dois caminhos. Em geral, se você usar as regras <option>in via</option> em todo o filtro, precisará abrir uma exceção para pacotes gerados localmente, porque eles não vieram em nenhuma de nossas interfaces.
Contributors Colaboradores
Many parts of this article have been taken, updated and adapted from an old text about bridging, edited by Nick Sayer. A pair of inspirations are due to an introduction on bridging by Steve Peterson. Muitas partes deste artigo foram tiradas, atualizadas e adaptadas de um texto antigo sobre pontes, editado por Nick Sayer. Um par de inspirações deve-se a uma introdução sobre pontes de Steve Peterson.
A big thanks to Luigi Rizzo for the implementation of the bridge code in FreeBSD and for the time he has dedicated to me answering all of my related questions. Um grande obrigado ao Luigi Rizzo pela implementação do código de ponte (bridge) no FreeBSD e pelo tempo que ele dedicou a mim respondendo a todas as minhas perguntas relacionadas.
A thanks goes out also to Tom Rhodes who looked over my job of translation from Italian (the original language of this article) into English. Agradeço também a Tom Rhodes, que olhou para o meu trabalho de tradução do italiano (a língua original deste artigo) para o inglês.

Loading…

No matching activity found.

Browse all component changes

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:391
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/filtering-bridges.po, string 59