#, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2018-12-08 14:45-0200\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Put one translator per line, in the form NAME , YEAR1, YEAR2 msgctxt "_" msgid "translator-credits" msgstr "" #. (itstool) path: info/title #: article.translate.xml:4 msgid "Filtering Bridges" msgstr "" #. (itstool) path: affiliation/address #: article.translate.xml:9 #, no-wrap msgid "ale@FreeBSD.org" msgstr "" #. (itstool) path: authorgroup/author #: article.translate.xml:8 msgid "" "AlexDupre <_:address-1/> " msgstr "" #. (itstool) path: legalnotice/para #: article.translate.xml:14 msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." msgstr "" #. (itstool) path: legalnotice/para #: article.translate.xml:16 msgid "3Com and HomeConnect are registered trademarks of 3Com Corporation." msgstr "" #. (itstool) path: legalnotice/para #: article.translate.xml:18 msgid "" "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." msgstr "" #. (itstool) path: legalnotice/para #: article.translate.xml:22 msgid "" "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 ™ or the ® symbol." msgstr "" #. (itstool) path: info/pubdate #. (itstool) path: info/releaseinfo #: article.translate.xml:30 article.translate.xml:32 msgid "" "$FreeBSD: head/en_US.ISO8859-1/articles/filtering-bridges/article.xml 44681 " "2014-04-28 20:19:20Z wblock $" msgstr "" #. (itstool) path: abstract/para #: article.translate.xml:35 msgid "" "Often it is useful to divide one physical network (like an Ethernet) into " "two separate segments without having to create subnets, and use a router to " "link them together. The device that connects the two networks in this way is " "called a bridge. A FreeBSD system with two network interfaces is enough in " "order to act as a bridge." msgstr "" #. (itstool) path: abstract/para #: article.translate.xml:41 msgid "" "A bridge works by scanning the addresses of MAC level " "(Ethernet addresses) of the devices connected to each of its network " "interfaces and then forwarding the traffic between the two networks only if " "the source and the destination are on different segments. Under many points " "of view a bridge is similar to an Ethernet switch with only two ports." msgstr "" #. (itstool) path: sect1/title #: article.translate.xml:51 msgid "Why use a filtering bridge?" msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:53 msgid "" "More and more frequently, thanks to the lowering costs of broad band " "Internet connections (xDSL) and also because of the reduction of available " "IPv4 addresses, many companies are connected to the Internet 24 hours on 24 " "and with few (sometimes not even a power of 2) IP addresses. In these " "situations it is often desirable to have a firewall that filters incoming " "and outgoing traffic from and towards Internet, but a packet filtering " "solution based on router may not be applicable, either due to subnetting " "issues, the router is owned by the connectivity supplier (ISP), or because it does not support such functionalities. In these " "scenarios the use of a filtering bridge is highly advised." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:65 msgid "" "A bridge-based firewall can be configured and inserted between the xDSL " "router and your Ethernet hub/switch without any IP numbering issues." msgstr "" #. (itstool) path: sect1/title #: article.translate.xml:71 msgid "How to Install" msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:73 msgid "" "Adding bridge functionalities to a FreeBSD system is not difficult. Since 4." "5 release it is possible to load such functionalities as modules instead of " "having to rebuild the kernel, simplifying the procedure a great deal. In the " "following subsections I will explain both installation ways." msgstr "" #. (itstool) path: important/para #: article.translate.xml:80 msgid "" "Do not follow both instructions: a procedure " "excludes the other one. Select the best choice " "according to your needs and abilities." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:85 msgid "" "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 EtherExpress Pro, followed by the 3Com 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." msgstr "" #. (itstool) path: sect2/title #: article.translate.xml:97 msgid "Kernel Configuration" msgstr "" #. (itstool) path: sect2/para #: article.translate.xml:99 msgid "" "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:" msgstr "" #. (itstool) path: sect2/programlisting #: article.translate.xml:103 #, no-wrap msgid "options BRIDGE\n" "options IPFIREWALL\n" "options IPFIREWALL_VERBOSE" msgstr "" #. (itstool) path: sect2/para #: article.translate.xml:107 msgid "" "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." msgstr "" #. (itstool) path: sect2/para #: article.translate.xml:111 msgid "" "Now it is necessary to build and install the new kernel. You may find " "detailed instructions in the Building and " "Installing a Custom Kernel section of the FreeBSD Handbook." msgstr "" #. (itstool) path: sect2/title #: article.translate.xml:118 msgid "Modules Loading" msgstr "" #. (itstool) path: sect2/para #: article.translate.xml:120 msgid "" "If you have chosen to use the new and simpler installation method, the only " "thing to do now is add the following row to /boot/loader.conf:" msgstr "" #. (itstool) path: sect2/programlisting #: article.translate.xml:124 #, no-wrap msgid "bridge_load=\"YES\"" msgstr "" #. (itstool) path: sect2/para #: article.translate.xml:126 msgid "" "In this way, during the system startup, the bridge.ko " "module will be loaded together with the kernel. It is not required to add a " "similar row for the ipfw.ko module, since it will be " "loaded automatically after the execution of the steps in the following " "section." msgstr "" #. (itstool) path: sect1/title #: article.translate.xml:136 msgid "Final Preparation" msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:138 msgid "" "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 /etc/rc.conf configuration file. " "The default rule of the firewall is to reject all IP packets. Initially we " "will set up an 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 /etc/rc." "conf:" msgstr "" #. (itstool) path: sect1/programlisting #: article.translate.xml:148 #, no-wrap msgid "" "firewall_enable=\"YES\"\n" "firewall_type=\"open\"\n" "firewall_quiet=\"YES\"\n" "firewall_logging=\"YES\"" msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:153 msgid "" "The first row will enable the firewall (and will load the module " "ipfw.ko if it is not compiled in the kernel), the " "second one to set up it in mode (as explained in " "/etc/rc.firewall), the third one to not show rules " "loading and the fourth one to enable logging support." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:159 msgid "" "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 DNS " "server resides), since the bridge will be activated at the end of the " "startup procedure. It means that the fxp0 interface (in " "our case) must be mentioned in the ifconfig section of the /etc/rc." "conf file, while the xl0 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." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:177 msgid "" "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). " "In order 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." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:190 msgid "" "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 mode, will not " "avoid any operations." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:195 msgid "" "If there are any problems, you should sort them out now before proceeding." msgstr "" #. (itstool) path: sect1/title #: article.translate.xml:200 msgid "Enabling the Bridge" msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:202 msgid "" "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 fxp0 and xl0 with your " "own ones):" msgstr "" #. (itstool) path: sect1/screen #: article.translate.xml:207 #, no-wrap msgid "" "# sysctl net.link.ether.bridge.config=fxp0:0,xl0:" "0\n" "# sysctl net.link.ether.bridge.ipfw=1\n" "# sysctl net.link.ether.bridge.enable=1" msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:211 msgid "" "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." msgstr "" #. (itstool) path: note/para #: article.translate.xml:216 msgid "" "If you have FreeBSD 5.1-RELEASE or previous the sysctl variables are spelled " "differently. See bridge4 for details." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:220 msgid "" "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 /etc/sysctl.conf " "file, in order to have them execute at startup." msgstr "" #. (itstool) path: sect1/title #: article.translate.xml:229 msgid "Configuring The Firewall" msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:231 msgid "" "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 or 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 or " " commands for packets filtered by a bridge. " "Sophisticated things like , " "or 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)." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:247 msgid "" "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." msgstr "" #. (itstool) path: sect1/para #: article.translate.xml:261 msgid "" "Let's look at an example setup. Note first that at the top of /etc/" "rc.firewall there are already standard rules for the loopback " "interface lo0, so we should not have to care for them " "anymore. Custom rules should be put in a separate file (say /etc/" "rc.firewall.local) and loaded at system startup, by modifying the " "row of /etc/rc.conf where we defined the