Overview

Project website docs.freebsd.org/en
Translation license BSD 2-Clause "Simplified" License
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Only chosen users can contribute.
  • The translation uses bilingual files.
File mask documentation/content/*/articles/filtering-bridges/_index.po
Translation file Download documentation/content/pt_BR/articles/filtering-bridges/_index.po
Last change Dec. 29, 2024, 9:35 p.m.
Last author Danilo G. Baio

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 61 2,591 15,287
Translated 100% 61 100% 2,591 100% 15,287
Needs editing 0% 0 0% 0 0% 0
Read-only 0% 0 0% 0 0% 0
Failing checks 0% 0 0% 0 0% 0
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

68 changes 0 changes 24 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 2 changes 11 changes 0 changes 0 changes 0 changes 0 changes 0 changes
Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar

Quick numbers

2,591
Hosted words
61
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
+100%
—
Hosted strings
+100%
—
Translated
+100%
—
Contributors
—
User avatar dbaio

Committed changes

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

Committed changes 3 months ago
User avatar dbaio

Translation changed

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

New in FreeBSD 4.0, is the concept of stateful filtering. This is a big improvement for UDP traffic, which typically is a request going out, followed shortly thereafter by a response with the 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 "remember" an outgoing UDP packet and, for the next few minutes, allow a response, handling UDP services is trivial. The following example shows how to do it. It is possible to do the same thing with TCP 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 UDP, que geralmente é uma solicitação que sai, seguida logo depois por uma resposta com o mesmo conjunto de endereços IP e portas (mas com origem e destino invertidos, é claro). Para firewalls que não têm o controle 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 "lembrar" de um pacote UDP de saída e, nos próximos minutos, permitir uma resposta, lidar com serviços UDP é trivial. O exemplo a seguir mostra como fazer isso. É possível fazer a mesma coisa com pacotes TCP. Isso permite evitar alguns ataques de negação de serviço e outros truques desagradáveis, mas também faz com que a tabela de estado cresça rapidamente em tamanho.
3 months ago
User avatar None

New string to translate

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

1 new string to translate appeared in the translation. a year ago
User avatar None

Resource update

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

The "documentation/content/pt_BR/articles/filtering-bridges/_index.po" file was changed. a year ago
User avatar None

String updated in the repository

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

There are two rules for passing SMTP and DNS 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 man:ipfw[8] man page). Note that for "relay" and "ns" to work, name service lookups must work _before_ 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 permitir o tráfego SMTP e DNS direcionado ao servidor de e-mail e servidor de nomes, se você tiver esses servidores. Obviamente, todo o conjunto de regras deve ser personalizado de acordo com as preferências pessoais, este é apenas um exemplo específico (o formato da regra é descrito com precisão na página do manual man:ipfw[8]). Observe que, para o "relay" e o "ns" funcionarem, as consultas ao serviço de nomes devem funcionar _antes_ de habilitar a ponte. Isto é um exemplo para garantir que você configure o IP no cartão de rede correto. Alternativamente, é possível especificar o endereço IP em vez do nome do host (obrigatório se a máquina não possuir um IP).
a year ago
User avatar None

String updated in the repository

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

New in FreeBSD 4.0, is the concept of stateful filtering. This is a big improvement for UDP traffic, which typically is a request going out, followed shortly thereafter by a response with the 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 "remember" an outgoing UDP packet and, for the next few minutes, allow a response, handling UDP services is trivial. The following example shows how to do it. It is possible to do the same thing with TCP 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 UDP, que geralmente é uma solicitação que sai, seguida logo depois por uma resposta com o mesmo conjunto de endereços IP e portas (mas com origem e destino invertidos, é claro). Para firewalls que não têm o controle 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 "lembrar" de um pacote UDP de saída e, nos próximos minutos, permitir uma resposta, lidar com serviços UDP é trivial. O exemplo a seguir mostra como fazer isso. É possível fazer a mesma coisa com pacotes TCP. Isso permite evitar alguns ataques de negação de serviço e outros truques desagradáveis, mas também faz com que a tabela de estado cresça rapidamente em tamanho.
a year ago
User avatar None

Source string changed

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

New in FreeBSD 4.0, is the concept of stateful filtering. This is a big improvement for UDP 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 "remember" an outgoing UDP packet and, for the next few minutes, allow a response, handling UDP services is trivial. The following example shows how to do it. It is possible to do the same thing with TCP 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.
a year ago
User avatar None

String updated in the repository

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

Now it is time to create your own file with custom firewall rules, 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 `out` or `xmit` will never match. Personally, I use `in via` 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 `pass` or `drop` commands for packets filtered by a bridge. Sophisticated things like `divert`, `forward` or `reject` 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 personalizadas de firewall, para proteger a rede interna. Haverá alguma complicação em fazer isso porque nem todas as funcionalidades do firewall estão disponíveis em pacotes encaminhados através de uma bridge. Além disso, há uma diferença entre os pacotes que estão em processo de encaminhamento e os pacotes que estão sendo recebidos pela máquina local. Em geral, os pacotes de entrada são filtrados apenas uma vez, não duas vezes como normalmente ocorre; de fato, eles são filtrados apenas no momento do recebimento, portanto, as regras que usam `out` ou `xmit` nunca darão match. Pessoalmente, eu uso `in via`, que é uma sintaxe mais antiga, mas que faz sentido quando você lê. Outra limitação é que você está restrito a usar apenas comandos `pass` ou `drop` para pacotes filtrados por uma ponte. Coisas sofisticadas como `divert`, `forward` ou `reject` não estão disponíveis. Tais opções ainda podem ser usadas, mas apenas no tráfego destinado ou originado na máquina que atua como bridge em si (se ela tiver um endereço IP).
a year ago
User avatar None

String updated in the repository

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

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 `net.link.ether.bridge._[blah]_=_[blah]_` portions of these rows to the [.filename]#/etc/sysctl.conf# file, to have them execute at startup.
Neste ponto, você deverá ser capaz de inserir a máquina entre dois conjuntos de hosts sem comprometer as habilidades de comunicação entre eles. Se sim, o próximo passo é adicionar as partes `net.link.ether.bridge._[blah]_=_[blah]_` dessas linhas ao arquivo [.filename]#/etc/sysctl.conf#, para que elas sejam executadas na inicialização.
a year ago
User avatar None

String updated in the repository

Documentation / articles/filtering-bridges/_index — Portuguese (Brazil)

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 ARP. ARP does the conversion of the IP address of a host into its Ethernet address (MAC layer). To allow the communication between two hosts separated by the bridge, it is necessary that the bridge will forward ARP 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 (ARP included) will be forwarded without being filtered, even if the firewall is configured to not permit anything.
Uma outra coisa importante a se saber é que, ao executar IP sobre Ethernet, existem na verdade dois protocolos Ethernet em uso: um é o IP e o outro é o ARP. ARP faz a conversão do endereço IP de um host em seu endereço Ethernet (camada MAC). Para permitir a comunicação entre dois hosts separados pela bridge, é necessário que a bridge encaminhe pacotes ARP. 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 (incluindo ARP) serão encaminhados sem serem filtrados, mesmo se o firewall estiver configurado para não permitir nada.
a year ago
Browse all translation changes