diff --git a/docs/bridge-Shorewall-perl.xml b/docs/bridge-Shorewall-perl.xml new file mode 100644 index 000000000..5e1ebe713 --- /dev/null +++ b/docs/bridge-Shorewall-perl.xml @@ -0,0 +1,715 @@ + + +
+ + + + Shorewall-perl and Bridged Firewalls + + + + Tom + + Eastep + + + + + + + 2007 + + Thomas M. Eastep + + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, Version + 1.2 or any later version published by the Free Software Foundation; with + no Invariant Sections, with no Front-Cover, and with no Back-Cover + Texts. A copy of the license is included in the section entitled + GNU Free Documentation + License. + + + + + This article applies to Shorewall-perl 4.0 and + later. If you are running a version of Shorewall earlier than Shorewall + 4.0.0-Beta4 or you are not running Shorewall-perl then please see the + documentation for that release. + + +
+ Background + + Systems where Shorewall runs normally function as + routers. In the context of the Open System + Interconnect (OSI) reference model, a router operates at layer 3, + Shorewall may also be deployed on a GNU Linux System that acts as a + bridge. Bridges are layer 2 devices in the OSI + model (think of a bridge as an ethernet switch). + + Some differences between routers and bridges are: + + + + Routers determine packet destination based on the destination IP + address, while bridges route traffic based on the destination MAC + address in the ethernet frame. + + + + As a consequence of the first difference, routers can be + connected to more than one IP network while a bridge may be part of + only a single network. + + + + In most configurations, routers don't forward broadcast packets + while a bridges do. + + + Section 4 of RFC 1812 describes the conditions under which a + router may or must forward broadcasts. + + + +
+ +
+ Requirements + + Note that if you need a bridge but do not need to restrict the + traffic through the bridge then any version of Shorewall will work. See + the Simple Bridge documentation for + details. + + In order to use Shorewall as a bridging firewall: + + + + Your kernel must contain bridge support (CONFIG_BRIDGE=m or + CONFIG_BRIDGE=y). + + + + Your kernel must contain bridge/netfilter integration + (CONFIG_BRIDGE_NETFILTER=y). + + + + Your kernel must contain Netfilter physdev match support + (CONFIG_IP_NF_MATCH_PHYSDEV=m or CONFIG_IP_NF_MATCH_PHYSDEV=y). + Physdev match is standard in the 2.6 kernel series but must be patched + into the 2.4 kernels (see http://bridge.sf.net). Bering and + Bering uCLibc users must find and install ipt_physdev.o for their + distribution and add ipt_physdev to + /etc/modules. + + + + Your iptables must contain physdev match support and must + support multiple instances of '-m physdev' in a single rule. iptables + 1.3.6 and later contain this support. + + + + You must have the bridge utilities (bridge-utils) package + installed. + + +
+ +
+ Application + + The following diagram shows a typical application of a + bridge/firewall. There is already an existing router in place whose + internal interface supports a network, and you want to insert a firewall + between the router, and the systems in the local network. In the example + shown, the network uses RFC 1918 addresses but that is not a requirement; + the bridge would work exactly the same if public IP addresses were used + (remember that the bridge doesn't deal with IP addresses). + + + + There are a several key differences in this setup and a normal + Shorewall configuration: + + + + The Shorewall system (the Bridge/Firewall) has only a single IP + address even though it has two ethernet interfaces! The IP address is + configured on the bridge itself, rather than on either of the network + cards. + + + + The systems connected to the LAN are configured with the + router's IP address (192.168.1.254 in the above diagram) as their + default gateway. + + + + traceroute doesn't detect the Bridge/Firewall + as an intermediate router. + + + + If the router runs a DHCP server, the hosts connected to the LAN + can use that server without having dhcrelay running + on the Bridge/Firewall. + + + + + Inserting a bridge/firewall between a router and a set of local + hosts only works if those local hosts form a single IP network. In the + above diagram, all of the hosts in the loc zone are in the + 192.168.1.0/24 network. If the router is routing between several local + networks through the same physical interface (there are multiple IP + networks sharing the same LAN), then inserting a bridge/firewall between + the router and the local LAN won't work. + + + There are other possibilities here -- there could be a hub or switch + between the router and the Bridge/Firewall and there could be other + systems connected to that switch. All of the systems on the local side of + the router would still be configured with + IP addresses in 192.168.1.0/24 as shown below. +
+ +
+ Configuring the Bridge + + Configuring the bridge itself is quite simple and uses the + brctl utility from the bridge-utils package. Bridge + configuration information may be found at http://bridge.sf.net. + + Unfortunately, many Linux distributions don't have good bridge + configuration tools, and the network configuration GUIs don't detect the + presence of bridge devices. Here is an excerpt from a Debian + /etc/network/interfaces file for a two-port bridge + with a static IP address: + +
+ auto br0 +iface br0 inet static + address 192.168.1.253 + netmask 255.255.255.0 + network 192.168.1.0 + broadcast 192.168.1.255 + pre-up /sbin/ip link set eth0 up + pre-up /sbin/ip link set eth1 up + pre-up /usr/sbin/brctl addbr br0 + pre-up /usr/sbin/brctl addif br0 eth0 + pre-up /usr/sbin/brctl addif br0 eth1 +
+ + While it is not a requirement to give the bridge an IP address, + doing so allows the bridge/firewall to access other systems and allows the + bridge/firewall to be managed remotely. The bridge must also have an IP + address for REJECT rules and policies to work correctly — otherwise REJECT + behaves the same as DROP. It is also a requirement for bridges to have an + IP address if they are part of a bridge/router. + + + Get your bridge configuration working first, including bridge + startup at boot, before you configure and start Shorewall. + + + The bridge may have its IP address assigned via DHCP. Here's an + example of an /etc/sysconfig/network/ifcfg-br0 file from a + SUSE system: + +
+ BOOTPROTO='dhcp' +REMOTE_IPADDR='' +STARTMODE='onboot' +UNIQUE='3hqH.MjuOqWfSZ+C' +WIRELESS='no' +MTU='' +
+ + Here's an /etc/sysconfig/network-scripts/ifcfg-br0 file for a + Mandriva system: + +
+ DEVICE=br0 +BOOTPROTO=dhcp +ONBOOT=yes +
+ + On both the SUSE and Mandriva systems, a + separate script is required to configure the bridge itself. + + Here are scripts that I used on a SUSE 9.1 + system. + +
+ /etc/sysconfig/network/ifcfg-br0 + + BOOTPROTO='dhcp' +REMOTE_IPADDR='' +STARTMODE='onboot' +UNIQUE='3hqH.MjuOqWfSZ+C' +WIRELESS='no' +MTU='' + + /etc/init.d/bridge#!/bin/sh + +################################################################################ +# Script to create a bridge +# +# (c) 2004 - Tom Eastep (teastep@shorewall.net) +# +# Modify the following variables to match your configuration +# +#### BEGIN INIT INFO +# Provides: bridge +# Required-Start: coldplug +# Required-Stop: +# Default-Start: 2 3 5 +# Default-Stop: 0 1 6 +# Description: starts and stops a bridge +### END INIT INFO +# +# chkconfig: 2345 05 89 +# description: GRE/IP Tunnel +# +################################################################################ + + +PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin + +INTERFACES="eth1 eth0" +BRIDGE="br0" +MODULES="tulip" + +do_stop() { + echo "Stopping Bridge $BRIDGE" + brctl delbr $BRIDGE + for interface in $INTERFACES; do + ip link set $interface down + done +} + +do_start() { + + echo "Starting Bridge $BRIDGE" + for module in $MODULES; do + modprobe $module + done + + sleep 5 + + for interface in $INTERFACES; do + ip link set $interface up + done + + brctl addbr $BRIDGE + + for interface in $INTERFACES; do + brctl addif $BRIDGE $interface + done +} + +case "$1" in + start) + do_start + ;; + stop) + do_stop + ;; + restart) + do_stop + sleep 1 + do_start + ;; + *) + echo "Usage: $0 {start|stop|restart}" + exit 1 +esac +exit 0 +
+ + Axel Westerhold has contributed this example of configuring a bridge + with a static IP address on a Fedora System (Core 1 and Core 2 Test 1). + Note that these files also configure the bridge itself, so there is no + need for a separate bridge config script. + +
+ /etc/sysconfig/network-scripts/ifcfg-br0: + + DEVICE=br0 +TYPE=Bridge +IPADDR=192.168.50.14 +NETMASK=255.255.255.0 +ONBOOT=yes + + /etc/sysconfig/network-scripts/ifcfg-eth0:DEVICE=eth0 +TYPE=ETHER +BRIDGE=br0 +ONBOOT=yes/etc/sysconfig/network-scripts/ifcfg-eth1:DEVICE=eth1 +TYPE=ETHER +BRIDGE=br0 +ONBOOT=yes +
+ + Florin Grad at Mandriva provides this script + for configuring a bridge: + +
+ #!/bin/sh +# chkconfig: 2345 05 89 +# description: Layer 2 Bridge +# + +[ -f /etc/sysconfig/bridge ] && . /etc/sysconfig/bridge + +PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin + +do_stop() { + echo "Stopping Bridge" + for i in $INTERFACES $BRIDGE_INTERFACE ; do + ip link set $i down + done + brctl delbr $BRIDGE_INTERFACE +} + +do_start() { + + echo "Starting Bridge" + for i in $INTERFACES ; do + ip link set $i up + done + brctl addbr br0 + for i in $INTERFACES ; do + ip link set $i up + brctl addif br0 $i + done + ifup $BRIDGE_INTERFACE +} + +case "$1" in + start) + do_start + ;; + stop) + do_stop + ;; + restart) + do_stop + sleep 1 + do_start + ;; + *) + echo "Usage: $0 {start|stop|restart}" + exit 1 +esac +exit 0 + + The /etc/sysconfig/bridge file: + + BRIDGE_INTERFACE=br0 #The name of your Bridge +INTERFACES="eth0 eth1" #The physical interfaces to be bridged +
+ + Andrzej Szelachowski contributed the following. + +
+ Here is how I configured bridge in Slackware: + +1) I had to compile bridge-utils (It's not in the standard distribution) +2) I've created rc.bridge in /etc/rc.d: + +######################### +#! /bin/sh + +ifconfig eth0 0.0.0.0 +ifconfig eth1 0.0.0.0 +#ifconfig lo 127.0.0.1 #this line should be uncommented if you don't use rc.inet1 + +brctl addbr most + +brctl addif most eth0 +brctl addif most eth1 + +ifconfig most 192.168.1.31 netmask 255.255.255.0 up +#route add default gw 192.168.1.1 metric 1 #this line should be uncommented if + #you don't use rc.inet1 +######################### + +3) I made rc.brige executable and added the following line to /etc/rc.d/rc.local + +/etc/rc.d/rc.bridge +
+ + Joshua Schmidlkofer writes: + +
+ Bridge Setup for Gentoo + +#install bridge-utils +emerge bridge-utils + +## create a link for net.br0 +cd /etc/init.d +ln -s net.eth0 net.br0 + +# Remove net.eth*, add net.br0 and bridge. +rc-update del net.eth0 +rc-update del net.eth1 +rc-update add net.br0 default +rc-update add bridge boot + + + +/etc/conf.d/bridge: + + #bridge contains the name of each bridge you want created. + bridge="br0" + + # bridge_<bridge>_devices contains the devices to use at bridge startup. + bridge_br0_devices="eth0 eth1" + +/etc/conf.d/net + + iface_br0="10.0.0.1 broadcast 10.0.0.255 netmask 255.255.255.0" + #for dhcp: + #iface_br0="dhcp" + #comment this out if you use dhcp. + gateway="eth0/10.0.0.1" +
+ + Users who successfully configure bridges on other distributions, + with static or dynamic IP addresses, are encouraged to send me their configuration so I + can post it here. +
+ +
+ Configuring Shorewall + + As described above, Shorewall bridge support requires the + physdev match feature of Netfilter/iptables. + Physdev match allows rules to be triggered based on the bridge port that a + packet arrived on and/or the bridge port that a packet will be sent over. + The latter has proved to be problematic because it requires that the + evaluation of rules be deferred until the destination bridge port is + known. This deferral has the unfortunate side effect that it makes IPSEC + Netfilter filtration incompatible with bridges. To work around this + problem, in kernel version 2.6.20 the Netfilter developers decided to + removed the deferred processing in two cases: + + + + When a packet being sent through a bridge entered the firewall + on another interface and was being forwarded to the bridge. + + + + When a packet originating on the firewall itself is being sent + through a bridge. + + + + Notice that physdev match was only weakened with respect to the + destination bridge port -- it remains fully functional with respect to the + source bridge port. + + To deal with the asymmetric nature of the new physdev match, + Shorewall-perl supports a new type of zone - a Bridge + Port (BP) zone. Bridge port zones have a number of + restrictions: + + + + BP zones may only be associated with bridge ports. + + + + All ports associated with a given BP zone must be on the same + bridge. + + + + Policies from a non-BP zone to a BP are disallowed. + + + + Rules where the SOURCE is a non-BP zone and the DEST is a BP + zone are disallowed. + + + + In /etc/shorewall/zones, BP zones are specified using the bport (or bport4) + keyword. + + In the scenario pictured above, there would probably be two BP zones + defined -- one for the internet and one for the local LAN so in + /etc/shorewall/zones: + + #ZONE TYPE OPTIONS +fw firewall +world ipv4 +net:world bport +loc:world bport +#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE + + The world zone can be used when defining rules + whose source zone is the firewall itself (remember that fw-><BP + zone> rules are not allowed). + + A conventional two-zone policy file is appropriate here — + /etc/shorewall/policy: + + #SOURCE DEST POLICY LOG LIMIT:BURST +loc net ACCEPT +net all DROP info +all all REJECT info +#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE + + Bridges use a special syntax in + /etc/shorewall/interfaces. Assuming that the router + is connected to eth0 and the + switch to eth1: + + #ZONE INTERFACE BROADCAST OPTIONS +world br0 detect bridge +net br0:eth0 +loc br0:eth1 +#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE + + The world zone is associated with the bridge + itself which is defined with the bridge + option. Bridge port entries may not have any OPTIONS. + + + When a bridge is configured without an IP address, the + option must also be specified. + + + When Shorewall is stopped, you want to allow only local traffic + through the bridge — + /etc/shorewall/routestopped: + + #INTERFACE HOST(S) OPTIONS +br0 192.168.1.0/24 routeback +#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE + + The /etc/shorewall/rules file from the + two-interface sample is a good place to start for defining a set of + firewall rules. +
+ +
+ Combination Router/Bridge + + A system running Shorewall doesn't have to be exclusively a bridge + or a router -- it can act as both, which is also know as a brouter. Here's + an example: + + This is basically the same setup as shown in the Shorewall Setup Guide with the + exception that the DMZ is bridged rather than using Proxy ARP. Changes in + the configuration shown in the Setup Guide are as follows: + + + + The /etc/shorewall/proxyarp file is empty + in this configuration. + + + + The /etc/shorewall/zones file is + modified: + + #ZONE TYPE OPTIONS +fw firewall +pub ipv4 #zone containing all public addresses +net:pub bport4 +dmz:pub bport4 +loc ipv4 + + + + The /etc/shorewall/interfaces file is as + follows:#ZONE INTERFACE BROADCAST OPTIONS +pub br0 detect routefilter,bridge +net br0:eth0 +dmz br0:eth2 +loc eth1 detect + + + + The DMZ systems need a route to the 192.168.201.0/24 network via + 192.0.2.176 to enable them to communicate with the local + network. + + + + This configuration does not support separate fw->dmz and + fw->net policies/rules; similarly, it does not support separate + loc->dmz and loc->net rules. This will make it a bit trickier to + configure the rules. I suggest something like the following: + + /etc/shorewall/params: + + $SERVERS=192.0.2.177,192.0.2.178 #IP Addresses of hosts in the DMZ +DMZ=pub:$SERVERS #Use in place of 'dmz' in rule DEST +NET=pub:!$SERVERS #Use in place of 'net' in rule DEST + + /etc/shorewall/policy: + + #SOURCE DEST POLICY LEVEL +loc pub ACCEPT +loc $FW REJECT info +loc all REJECT info + +$FW pub REJECT info +$FW loc REJECT info +$FW all REJECT info + +dmz net REJECT info +dmz $FW REJECT info +dmz loc REJECT info +dmz all REJECT info + +net dmz DROP info +net $FW DROP info +net loc DROP info +net all DROP info + +# THE FOLLOWING POLICY MUST BE LAST +all all REJECT info + + /etc/shorewall/rules: + + #ACTION SOURCE DEST PROTO DEST SOURCE +# + PORT(S) PORT(S) +ACCEPT all all icmp 8 +ACCEPT loc $DMZ tcp 25,53,80,443,... +ACCEPT loc $DMZ udp 53 +ACCEPT loc $NET +ACCEPT $FW $DMZ udp 53 +ACCEPT $FW $DMZ tcp 53 + + +
+ +
+ Limitations + + Bridging doesn't work with some wireless cards — see http://bridge.sf.net. +
+
\ No newline at end of file