mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-17 03:40:53 +01:00
399 lines
14 KiB
XML
399 lines
14 KiB
XML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||
|
<article>
|
||
|
<!--$Id$-->
|
||
|
|
||
|
<articleinfo>
|
||
|
<title>Shorewall and Bridged Firewalls</title>
|
||
|
|
||
|
<authorgroup>
|
||
|
<author>
|
||
|
<firstname>Tom</firstname>
|
||
|
|
||
|
<surname>Eastep</surname>
|
||
|
</author>
|
||
|
</authorgroup>
|
||
|
|
||
|
<pubdate>2004-06-11</pubdate>
|
||
|
|
||
|
<copyright>
|
||
|
<year>2004</year>
|
||
|
|
||
|
<holder>Thomas M. Eastep</holder>
|
||
|
</copyright>
|
||
|
|
||
|
<legalnotice>
|
||
|
<para>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
|
||
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||
|
</legalnotice>
|
||
|
</articleinfo>
|
||
|
|
||
|
<section>
|
||
|
<title>Background</title>
|
||
|
|
||
|
<para>Systems where Shorewall runs normally function as
|
||
|
<firstterm>routers</firstterm>. In the context of the Open System
|
||
|
Interconnect (OSI) reference model, a router operates at layer 3.
|
||
|
Beginning with Shorewall version 2.0.1, Shorewall may also be deployed on
|
||
|
a GNU Linux System that acts as a <firstterm>bridge</firstterm>. Bridges
|
||
|
are layer-2 devices in the OSI model (think of a bridge as an ethernet
|
||
|
switch).</para>
|
||
|
|
||
|
<para>Some differences between routers and bridges are:</para>
|
||
|
|
||
|
<orderedlist>
|
||
|
<listitem>
|
||
|
<para>Routers determine packet destination based on the destination IP
|
||
|
address while bridges route traffic based on the destination MAC
|
||
|
address in the ethernet frame.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>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.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>A router cannot forward broadcast packets while a bridge can.</para>
|
||
|
</listitem>
|
||
|
</orderedlist>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Requirements</title>
|
||
|
|
||
|
<para>In order to use Shorewall with a bridging firewall:</para>
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem>
|
||
|
<para>Your kernel must contain bridge support (CONFIG_BRIDGE=m or
|
||
|
CONFIG_BRIDGE=y).</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>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 <ulink url="http://bridge.sf.net">http://bridge.sf.net</ulink>).</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>Your iptables must contain physdev match support. iptables 1.2.9
|
||
|
and later contain this support.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>You must have the bridge utilities (bridge-utils) package
|
||
|
installed.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>You must be running Shorewall 2.0.1 Beta 1 or later.</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Application</title>
|
||
|
|
||
|
<para>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).</para>
|
||
|
|
||
|
<graphic fileref="images/bridge.png" />
|
||
|
|
||
|
<para>There are a several key differences in this setup and a normal
|
||
|
Shorewall configuration:</para>
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem>
|
||
|
<para>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.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>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.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para><command>traceroute</command> doesn't detect the
|
||
|
Bridge/Firewall as an intermediate router.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>If the router runs a DHCP server, the hosts connected to the LAN
|
||
|
can use that server without having <command>dhcrelay</command> running
|
||
|
on the Bridge/Firewall.</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
|
<para>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 <emphasis role="bold">router</emphasis> would still be configured with
|
||
|
IP addresses in 192.168.1.0/24 as shown below.<graphic
|
||
|
fileref="images/bridge3.png" /></para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Configuring the Bridge</title>
|
||
|
|
||
|
<para>Configuring the bridge itself is quite simple and uses the
|
||
|
<command>brctl</command> utility from the bridge-utils package. Bridge
|
||
|
configuration information may be found at <ulink
|
||
|
url="http://bridge.sf.net">http://bridge.sf.net</ulink>.</para>
|
||
|
|
||
|
<para>Unfortunately, Linux distributions don't have good bridge
|
||
|
configuration tools and the network configuration GUIs don't detect
|
||
|
the presence of bridge devices. You may refer to <ulink
|
||
|
url="http://shorewall.net/2.0/myfiles.htm">my configuration files</ulink>
|
||
|
for an example of configuring a three-port bridge at system boot under
|
||
|
<trademark>SuSE</trademark>. Here is an excerpt from a Debian
|
||
|
<filename>/etc/network/interfaces</filename> file for a two-port bridge
|
||
|
with a static IP address:</para>
|
||
|
|
||
|
<blockquote>
|
||
|
<programlisting>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</programlisting>
|
||
|
</blockquote>
|
||
|
|
||
|
<para>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.</para>
|
||
|
|
||
|
<para>The bridge may have its IP address assigned via DHCP. Here's an
|
||
|
example of an /etc/sysconfig/network/ifcfg-br0 file from a
|
||
|
<trademark>SuSE</trademark> system:</para>
|
||
|
|
||
|
<blockquote>
|
||
|
<programlisting>BOOTPROTO='dhcp'
|
||
|
REMOTE_IPADDR=''
|
||
|
STARTMODE='onboot'
|
||
|
UNIQUE='3hqH.MjuOqWfSZ+C'
|
||
|
WIRELESS='no'
|
||
|
MTU=''</programlisting>
|
||
|
</blockquote>
|
||
|
|
||
|
<para>Here's an /etc/sysconfig/network-scripts/ifcfg-br0 file for a
|
||
|
<trademark>Mandrake</trademark> system:</para>
|
||
|
|
||
|
<blockquote>
|
||
|
<programlisting>DEVICE=br0
|
||
|
BOOTPROTO=dhcp
|
||
|
ONBOOT=yes</programlisting>
|
||
|
</blockquote>
|
||
|
|
||
|
<para>On both the SuSE and Mandrake systems, a separate script is required
|
||
|
to configure the bridge itself (again see <ulink url="myfiles.htm">my
|
||
|
configuration files</ulink> for an example - <filename>/etc/init.d/bridge</filename>).</para>
|
||
|
|
||
|
<para>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.</para>
|
||
|
|
||
|
<blockquote>
|
||
|
<para><filename>/etc/sysconfig/network-scripts/ifcfg-br0:</filename></para>
|
||
|
|
||
|
<programlisting>DEVICE=br0
|
||
|
TYPE=Bridge
|
||
|
IPADDR=192.168.50.14
|
||
|
NETMASK=255.255.255.0
|
||
|
ONBOOT=yes</programlisting>
|
||
|
|
||
|
<para><filename>/etc/sysconfig/network-scripts/ifcfg-eth0:</filename><programlisting>DEVICE=eth0
|
||
|
TYPE=ETHER
|
||
|
BRIDGE=br0
|
||
|
ONBOOT=yes</programlisting><filename>/etc/sysconfig/network-scripts/ifcfg-eth1:</filename><programlisting>DEVICE=eth1
|
||
|
TYPE=ETHER
|
||
|
BRIDGE=br0
|
||
|
ONBOOT=yes</programlisting></para>
|
||
|
</blockquote>
|
||
|
|
||
|
<para>Florin Grad at <trademark>Mandrake</trademark> provides this script
|
||
|
for configuring a bridge:</para>
|
||
|
|
||
|
<blockquote>
|
||
|
<programlisting>#!/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</programlisting>
|
||
|
|
||
|
<para>The <filename>/etc/sysconfig/bridge file</filename>:</para>
|
||
|
|
||
|
<programlisting>BRIDGE_INTERFACE=br0 #The name of your Bridge
|
||
|
INTERFACES="eth0 eth1" #The physical interfaces to be bridged</programlisting>
|
||
|
</blockquote>
|
||
|
|
||
|
<para>Users who successfully configure bridges on other distributions,
|
||
|
with static or dynamic IP addresses, are encouraged to send <ulink
|
||
|
url="mailto:webmaster@shorewall.net">me</ulink> their configuration so I
|
||
|
can post it here.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Configuring Shorewall</title>
|
||
|
|
||
|
<para>Bridging in Shorewall is enabled using the BRIDGING option in
|
||
|
<filename>/etc/shorewall/shorewall.conf</filename>:</para>
|
||
|
|
||
|
<programlisting>BRIDGING=Yes</programlisting>
|
||
|
|
||
|
<para>In the scenario pictured above, there would probably be two zones
|
||
|
defined -- one for the internet and one for the local LAN so in
|
||
|
<filename>/etc/shorewall/zones</filename>:</para>
|
||
|
|
||
|
<programlisting>#ZONE DISPLAY COMMENTS
|
||
|
net Net Internet
|
||
|
loc Local Local networks
|
||
|
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
|
||
|
|
||
|
<para>A conventional two-zone policy file is appropriate here —
|
||
|
<filename>/etc/shorewall/policy</filename>:</para>
|
||
|
|
||
|
<programlisting>#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</programlisting>
|
||
|
|
||
|
<para>Only the bridge device itself is configured with an IP address so
|
||
|
only that device is defined to Shorewall in <filename>/etc/shorewall/interfaces</filename>:</para>
|
||
|
|
||
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||
|
- br0 192.168.1.255
|
||
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||
|
|
||
|
<para>The zones are defined using the <filename>/etc/shorewall/hosts</filename>
|
||
|
file. Assuming that the router is connected to <filename
|
||
|
class="devicefile">eth0</filename> and the switch to <filename
|
||
|
class="devicefile">eth1</filename>:</para>
|
||
|
|
||
|
<programlisting>#ZONE HOST(S) OPTIONS
|
||
|
net br0:eth0
|
||
|
loc br0:eth1
|
||
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE</programlisting>
|
||
|
|
||
|
<para>When Shorewall is stopped, you want to allow only local traffic
|
||
|
through the bridge — <filename><filename>/etc/shorewall/routestopped</filename></filename>:</para>
|
||
|
|
||
|
<programlisting>#INTERFACE HOST(S) OPTIONS
|
||
|
br0 192.168.1.0/24 routeback
|
||
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||
|
|
||
|
<para>The <filename>/etc/shorewall/rules</filename> file from the
|
||
|
two-interface sample is a good place to start for defining a set of
|
||
|
firewall rules.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Combination Router/Bridge</title>
|
||
|
|
||
|
<para>A system running Shorewall doesn't have to be exclusively a
|
||
|
bridge or a router -- it can act as both. Here's an example:<graphic
|
||
|
fileref="images/bridge2.png" /></para>
|
||
|
|
||
|
<para>This is basically the same setup as shown in the <ulink
|
||
|
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink> 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:</para>
|
||
|
|
||
|
<orderedlist>
|
||
|
<listitem>
|
||
|
<para>The <filename>/etc/shorewall/proxyarp</filename> file is empty
|
||
|
in this confiiguration.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>The <filename>/etc/shorewall/interfaces</filename> file is as
|
||
|
follows:<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||
|
- br0 detect routefilter
|
||
|
loc eth1 detect</programlisting></para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
|
<para>The <filename>/etc/shorewall/hosts</filename> file would have:</para>
|
||
|
|
||
|
<programlisting>#ZONE HOSTS OPTIONS
|
||
|
net br0:eth0
|
||
|
dmz br0:eth2</programlisting>
|
||
|
</listitem>
|
||
|
</orderedlist>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Limitations</title>
|
||
|
|
||
|
<para>Bridging doesn' t work with some wireless cards — see <ulink
|
||
|
url="http://bridge.sf.net">http://bridge.sf.net</ulink>.</para>
|
||
|
</section>
|
||
|
</article>
|