mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-22 06:10:42 +01:00
Shorewall 2.0.0+
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1196 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
1a3c0cef13
commit
4f45eeff82
@ -1,928 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shorewall 2.0 Reference</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /><meta name="description" content="This documentation is intended primarily for reference. Step-by-step instructions for configuring Shorewall in common setups may be found in the QuickStart Guides." /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="Documentation"></a>Shorewall 2.0 Reference</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>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
|
||||
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-03</p></div><div><div class="abstract"><p class="title"><b>Abstract</b></p><p>This documentation is intended primarily for reference.
|
||||
Step-by-step instructions for configuring Shorewall in common setups may
|
||||
be found in the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart
|
||||
Guides</a>.</p></div></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807627">Components</a></span></dt><dt><span class="section"><a href="#Variables">/etc/shorewall/params</a></span></dt><dt><span class="section"><a href="#Zones">/etc/shorewall/zones</a></span></dt><dt><span class="section"><a href="#Interfaces">/etc/shorewall/interfaces</a></span></dt><dt><span class="section"><a href="#Hosts">/etc/shorewall/hosts Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#Nested">Nested and Overlapping Zones</a></span></dt></dl></dd><dt><span class="section"><a href="#Policy">/etc/shorewall/policy Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#id2866348">Intra-Zone Traffic</a></span></dt><dt><span class="section"><a href="#CONTINUE">The CONTINUE policy</a></span></dt></dl></dd><dt><span class="section"><a href="#Rules">/etc/shorewall/rules</a></span></dt><dt><span class="section"><a href="#Masq">/etc/shorewall/masq</a></span></dt><dt><span class="section"><a href="#ProxyArp">/etc/shorewall/proxyarp</a></span></dt><dt><span class="section"><a href="#NAT">/etc/shorewall/nat</a></span></dt><dt><span class="section"><a href="#Tunnels">/etc/shorewall/tunnels</a></span></dt><dt><span class="section"><a href="#Conf">/etc/shorewall/shorewall.conf</a></span></dt><dt><span class="section"><a href="#modules">/etc/shorewall/modules Configuration</a></span></dt><dt><span class="section"><a href="#TOS">/etc/shorewall/tos Configuration</a></span></dt><dt><span class="section"><a href="#Blacklist">/etc/shorewall/blacklist</a></span></dt><dt><span class="section"><a href="#rfc1918">/etc/shorewall/rfc1918 (Added in Version 1.3.1)</a></span></dt><dt><span class="section"><a href="#Routestopped">/etc/shorewall/routestopped (Added in Version 1.3.4)</a></span></dt><dt><span class="section"><a href="#Maclist">/etc/shorewall/maclist (Added in Version 1.3.10)</a></span></dt><dt><span class="section"><a href="#ECN">/etc/shorewall/ecn (Added in Version 1.4.0)</a></span></dt><dt><span class="section"><a href="#Accounting">/etc/shorewall/accounting</a></span></dt><dt><span class="appendix"><a href="#id2875179">A. Revision History</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807627"></a>Components</h2></div></div><div></div></div><p>Shorewall consists of the following components:</p><div class="variablelist"><dl><dt><span class="term"><a href="#Variables" title="/etc/shorewall/params">params</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
that can be used to establish the values of shell variables for use
|
||||
in other files.</p></dd><dt><span class="term"><a href="#Conf" title="/etc/shorewall/shorewall.conf">shorewall.conf</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
that is used to set several firewall parameters.</p></dd><dt><span class="term"><a href="#Zones" title="/etc/shorewall/zones">zones</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
that defines a network partitioning into “<span class="quote">zones</span>”</p></dd><dt><span class="term"><a href="#Policy" title="/etc/shorewall/policy Configuration">policy</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
that establishes overall firewall policy.</p></dd><dt><span class="term"><a href="#Rules" title="/etc/shorewall/rules">rules</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
and used to express firewall rules that are exceptions to the
|
||||
high-level policies established in /etc/shorewall/policy.</p></dd><dt><span class="term"><a href="#Blacklist" title="/etc/shorewall/blacklist">blacklist</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
and used to list blacklisted IP/subnet/MAC addresses.</p></dd><dt><span class="term"><a href="#ECN" title="/etc/shorewall/ecn (Added in Version 1.4.0)">ecn</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
and used to selectively disable Explicit Congestion Notification
|
||||
(ECN - RFC 3168).</p></dd><dt><span class="term">functions</span></dt><dd><p>a set of shell functions used by both the firewall and
|
||||
shorewall shell programs. Installed in <tt class="filename">/usr/share/shorewall</tt>.</p></dd><dt><span class="term"><a href="#modules" title="/etc/shorewall/modules Configuration">modules</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
and that specifies kernel modules and their parameters. Shorewall
|
||||
will automatically load the modules specified in this file.</p></dd><dt><span class="term"><a href="#TOS" title="/etc/shorewall/tos Configuration">tos</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
that is used to specify how the Type of Service (TOS) field in
|
||||
packets is to be set.</p></dd><dt><span class="term">init.sh and init.debian.sh</span></dt><dd><p>a shell script installed in <tt class="filename">/etc/init.d
|
||||
</tt>to automatically start Shorewall during boot. The
|
||||
particular script installed depends on which distribution you are
|
||||
running.</p></dd><dt><span class="term"><a href="#Interfaces" title="/etc/shorewall/interfaces">interfaces</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
and used to describe the interfaces on the firewall system.</p></dd><dt><span class="term"><a href="#Hosts" title="/etc/shorewall/hosts Configuration">hosts</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
and used to describe individual hosts or subnetworks in zones.</p></dd><dt><span class="term"><a href="#Maclist" title="/etc/shorewall/maclist (Added in Version 1.3.10)">maclist</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
|
||||
and used to verify the MAC address (and possibly also the IP
|
||||
address(es)) of devices.</p></dd><dt><span class="term"><a href="#Masq" title="/etc/shorewall/masq">masq</a></span></dt><dd><p>This file also describes IP masquerading under Shorewall and
|
||||
is installed in <tt class="filename">/etc/shorewall</tt>.</p></dd><dt><span class="term">firewall</span></dt><dd><p>a shell program that reads the configuration files in
|
||||
<tt class="filename">/etc/shorewall</tt> and configures
|
||||
your firewall. This file is installed in <tt class="filename">/usr/share/shorewall</tt>.</p></dd><dt><span class="term"><a href="#NAT" title="/etc/shorewall/nat">nat</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
|
||||
used to define <a href="#NAT" title="/etc/shorewall/nat">one-to-one NAT</a>.</p></dd><dt><span class="term"><a href="#ProxyArp" title="/etc/shorewall/proxyarp">proxyarp</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
|
||||
used to define <a href="#ProxyArp" title="/etc/shorewall/proxyarp">Proxy Arp</a>.</p></dd><dt><span class="term"><a href="#rfc1918" title="/etc/shorewall/rfc1918 (Added in Version 1.3.1)">rfc1918</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
|
||||
used to define the treatment of packets under the <a href="#Interfaces" title="/etc/shorewall/interfaces">norfc1918 interface option</a>.</p></dd><dt><span class="term"><a href="#Routestopped" title="/etc/shorewall/routestopped (Added in Version 1.3.4)">routestopped</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
|
||||
used to define those hosts that can access the firewall when
|
||||
Shorewall is stopped.</p></dd><dt><span class="term"><a href="traffic_shaping.htm#tcrules" target="_self">tcrules</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall
|
||||
</tt>used to define rules for classifying packets for <a href="traffic_shaping.htm" target="_self">Traffic Shaping/Control</a>.</p></dd><dt><span class="term"><a href="#Tunnels" title="/etc/shorewall/tunnels">tunnels</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
|
||||
used to define IPSec tunnels.</p></dd><dt><span class="term">shorewall</span></dt><dd><p>a shell program (requiring a Bourne shell or derivative) used
|
||||
to control and monitor the firewall. This should be placed in
|
||||
<tt class="filename">/sbin</tt> or in <tt class="filename">/usr/sbin</tt> (the install.sh script and
|
||||
the rpm install this file in <tt class="filename">/sbin</tt>).</p></dd><dt><span class="term"><a href="Accounting.html" target="_self">accounting</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
|
||||
used to define traffic accounting rules. This file was added in
|
||||
version 1.4.7.</p></dd><dt><span class="term">version</span></dt><dd><p>a file created in <tt class="filename">/usr/share/shorewall</tt>
|
||||
that describes the version of Shorewall installed on your system.</p></dd><dt><span class="term"><a href="User_defined_Actions.html" target="_self">actions and
|
||||
action.template</a></span></dt><dd><p>files in /etc/shorewall that allow you to define your own
|
||||
actions for rules in <a href="#Rules" title="/etc/shorewall/rules">/etc/shorewall/rules</a>.</p></dd><dt><span class="term">actions.std and action.*</span></dt><dd><p>files in <tt class="filename">/etc/shorewall</tt>
|
||||
that define the actions included as a standard part of Shorewall.</p></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Variables"></a>/etc/shorewall/params</h2></div></div><div></div></div><p>You may use the file <tt class="filename">/etc/shorewall/params</tt> file
|
||||
to set shell variables that you can then use in some of the other
|
||||
configuration files.</p><p>It is suggested that variable names begin with an upper case letter
|
||||
to distinguish them from variables used internally within the Shorewall
|
||||
programs</p><div class="example"><a id="id2859972"></a><p class="title"><b>Example 1. shell variables</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">NET_IF=eth0 NET_BCAST=130.252.100.255
|
||||
NET_OPTIONS=blacklist,norfc1918</pre></td></tr></table></div><div class="example"><a id="id2859990"></a><p class="title"><b>Example 2. /etc/shorewall/interfaces record</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">net $NET_IF $NET_BCAST $NET_OPTIONS</pre></td></tr></table></div><p>The result will be the same as if the record had been written</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">net eth0 130.252.100.255 blacklist,norfc1918</pre></td></tr></table><p>Variables may be used anywhere in the other configuration files.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Zones"></a>/etc/shorewall/zones</h2></div></div><div></div></div><p>This file is used to define the network zones. There is one entry in
|
||||
<tt class="filename">/etc/shorewall/zones</tt> for each zone; Columns in an
|
||||
entry are:</p><div class="variablelist"><dl><dt><span class="term">ZONE</span></dt><dd><p>short name for the zone. The name should be 5 characters or
|
||||
less in length (4 characters or less if you are running Shorewall
|
||||
1.4.4 or later) and consist of lower-case letters or numbers. Short
|
||||
names must begin with a letter and the name assigned to the firewall
|
||||
is reserved for use by Shorewall itself. Note that the output
|
||||
produced by iptables is much easier to read if you select short
|
||||
names that are three characters or less in length. The name
|
||||
“<span class="quote">all</span>” may not be used as a zone name nor may the zone
|
||||
name assigned to the firewall itself via the FW variable in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</p></dd><dt><span class="term">DISPLAY</span></dt><dd><p>The name of the zone as displayed during Shorewall startup.</p></dd><dt><span class="term">COMMENTS</span></dt><dd><p>Any comments that you want to make about the zone. Shorewall
|
||||
ignores these comments.</p></dd></dl></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE DISPLAY COMMENTS
|
||||
net Net Internet
|
||||
loc Local Local networks
|
||||
dmz DMZ Demilitarized zone</pre></td></tr></table><p>You may add, delete and modify entries in the <tt class="filename">/etc/shorewall/zones</tt>
|
||||
file as desired so long as you have at least one zone defined.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you rename or delete a zone, you should perform “<span class="quote"><span><b class="command">shorewall
|
||||
stop; shorewall start</b></span></span>” to install the change rather
|
||||
than “<span class="quote"><span><b class="command">shorewall restart</b></span></span>”.</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>The order of entries in the <tt class="filename">/etc/shorewall/zones</tt>
|
||||
file is significant <a href="#Nested" title="Nested and Overlapping Zones">in some cases</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Interfaces"></a>/etc/shorewall/interfaces</h2></div></div><div></div></div><p>This file is used to tell the firewall which of your firewall's
|
||||
network interfaces are connected to which zone. There will be one entry in
|
||||
/etc/shorewall/interfaces for each of your interfaces. Columns in an entry
|
||||
are:</p><div class="variablelist"><dl><dt><span class="term">ZONE</span></dt><dd><p>A zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file or
|
||||
“<span class="quote">-</span>”. If you specify “<span class="quote">-</span>”, you must use the
|
||||
<a href="#Hosts">/etc/shorewall/hosts</a> file to define the zones accessed via this
|
||||
interface.</p></dd><dt><span class="term">INTERFACE</span></dt><dd><p>the name of the interface (examples: eth0, ppp0, ipsec+). Each
|
||||
interface can be listed on only one record in this file.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>You do not need to include the loopback interface (lo) in
|
||||
this file.</p></div></dd><dt><span class="term">BROADCAST</span></dt><dd><p>the broadcast address(es) for the sub-network(s) attached to
|
||||
the interface. This should be left empty for P-T-P interfaces (ppp*,
|
||||
ippp*); if you need to specify options for such an interface, enter
|
||||
“<span class="quote">-</span>” in this column. If you supply the special value
|
||||
“<span class="quote">detect</span>” in this column, the firewall will
|
||||
automatically determine the broadcast address. In order to use
|
||||
“<span class="quote">detect</span>”:</p><div class="itemizedlist"><ul type="disc"><li><p>the interface must be up before you start your firewall</p></li><li><p>the interface must only be attached to a single
|
||||
sub-network (i.e., there must have a single broadcast address).</p></li></ul></div></dd><dt><span class="term">OPTIONS</span></dt><dd><p>a comma-separated list of options. Possible options include:</p><div class="variablelist"><dl><dt><span class="term">arp_filter</span></dt><dd><p>(Added in version 1.4.7) - This option causes
|
||||
<tt class="filename">/proc/sys/net/ipv4/conf/<interface>/arp_filter</tt>
|
||||
to be set with the result that this interface will only answer
|
||||
ARP “<span class="quote">who-has</span>” requests from hosts that are routed
|
||||
out of that interface. Setting this option facilitates testing
|
||||
of your firewall where multiple firewall interfaces are
|
||||
connected to the same HUB/Switch (all interface connected to
|
||||
the single HUB/Switch should have this option specified). Note
|
||||
that using such a configuration in a production environment is
|
||||
strongly recommended against.</p></dd><dt><span class="term">newnotsyn</span></dt><dd><p>(Added in version 1.4.6) - This option overrides <a href="#Conf" title="/etc/shorewall/shorewall.conf">NEWNOTSYN=No</a> for packets arriving on
|
||||
this interface. In other words, packets coming in on this
|
||||
interface are processed as if NEWNOTSYN=Yes had been specified
|
||||
in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</p></dd><dt><span class="term">routeback</span></dt><dd><p>(Added in version 1.4.2) - This option causes Shorewall
|
||||
to set up handling for routing packets that arrive on this
|
||||
interface back out the same interface. If this option is
|
||||
specified, the ZONE column may not contain “<span class="quote">-</span>”.</p></dd><dt><span class="term">tcpflags</span></dt><dd><p>(added in version 1.3.11) - This option causes Shorewall
|
||||
to make sanity checks on the header flags in TCP packets
|
||||
arriving on this interface. Checks include Null flags,
|
||||
SYN+FIN, SYN+RST and FIN+URG+PSH; these flag combinations are
|
||||
typically used for “<span class="quote">silent</span>” port scans. Packets
|
||||
failing these checks are logged according to the
|
||||
TCP_FLAGS_LOG_LEVEL option in <a href="#Conf">/etc/shorewall/shorewall.conf</a> and are
|
||||
disposed of according to the TCP_FLAGS_DISPOSITION option.</p></dd><dt><span class="term">blacklist</span></dt><dd><p>This option causes incoming packets on this interface to
|
||||
be checked against the <a href="#Blacklist" title="/etc/shorewall/blacklist">blacklist</a>.</p></dd><dt><span class="term">dhcp</span></dt><dd><p>The interface is assigned an IP address via DHCP or is
|
||||
used by a DHCP server running on the firewall. The firewall
|
||||
will be configured to allow DHCP traffic to and from the
|
||||
interface even when the firewall is stopped. You may also wish
|
||||
to use this option if you have a static IP but you are on a
|
||||
LAN segment that has a lot of Laptops that use DHCP and you
|
||||
select the <span class="bold"><b>norfc1918</b></span> option
|
||||
(see below).</p></dd><dt><span class="term">norfc1918</span></dt><dd><p>Packets arriving on this interface and that have a
|
||||
source address that is reserved in RFC 1918 or in other RFCs
|
||||
will be dropped after being optionally logged. If <a href="#Conf" title="/etc/shorewall/shorewall.conf">packet mangling is enabled in
|
||||
<tt class="filename">/etc/shorewall/shorewall.conf</tt></a> ,
|
||||
then packets arriving on this interface that have a
|
||||
destination address that is reserved by one of these RFCs will
|
||||
also be logged and dropped.</p><p>Addresses blocked by the standard <a href="#rfc1918" title="/etc/shorewall/rfc1918 (Added in Version 1.3.1)">rfc1918 file</a> include those addresses
|
||||
reserved by RFC1918 plus other ranges reserved by the IANA or
|
||||
by other RFCs.</p><p>Beware that as IPv4 addresses become in increasingly
|
||||
short supply, ISPs are beginning to use RFC 1918 addresses
|
||||
within their own infrastructure. Also, many cable and DSL
|
||||
“<span class="quote">modems</span>” have an RFC 1918 address that can be
|
||||
used through a web browser for management and monitoring
|
||||
functions. If you want to specify <span class="bold"><b>norfc1918</b></span>
|
||||
on your external interface but need to allow access to certain
|
||||
addresses from the above list, see <a href="FAQ.htm#faq14" target="_self">FAQ
|
||||
14</a>.</p></dd><dt><span class="term">routefilter</span></dt><dd><p>Invoke the Kernel's route filtering (anti-spoofing)
|
||||
facility on this interface. The kernel will reject any packets
|
||||
incoming on this interface that have a source address that
|
||||
would be routed outbound through another interface on the
|
||||
firewall.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you specify this option for an interface then the
|
||||
interface must be up prior to starting the firewall.</p></div></dd><dt><span class="term">proxyarp</span></dt><dd><p>(Added in version 1.3.5) - This option causes Shorewall
|
||||
to set /proc/sys/net/ipv4/conf/<<span class="emphasis"><em>interface</em></span>>/proxy_arp
|
||||
and is used when implementing Proxy ARP Sub-netting as
|
||||
described at <a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/" target="_self">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>.
|
||||
Do <span class="bold"><b>not</b></span> set this option if you
|
||||
are implementing Proxy ARP through entries in <a href="#ProxyArp">/etc/shorewall/proxyarp</a>.</p></dd><dt><span class="term">maclist</span></dt><dd><p>(Added in version 1.3.10) - If this option is specified,
|
||||
all connection requests from this interface are subject to
|
||||
<a href="MAC_Validation.html" target="_self">MAC Verification</a>. May
|
||||
only be specified for ethernet interfaces.</p></dd></dl></div><div class="variablelist"><dl><dt><span class="term">detectnets</span></dt><dd><p>(Added in version 1.4.10) - If this option is specified,
|
||||
the zone named in the ZONE column will contain only the hosts
|
||||
routed through the interface named in the INTERFACE column.
|
||||
<span class="bold"><b>Do not set this option on your external
|
||||
(Internet) interface!</b></span> The interface must be in the
|
||||
UP state when Shorewall is [re]started.</p></dd><dt><span class="term">nosmurfs</span></dt><dd><p>(Added in version 2.0.0) - If this option is specified,
|
||||
incoming connection requests will be checked to ensure that
|
||||
they do not have a broadcast or multicast address as their
|
||||
source. Any such packets will be dropped after being
|
||||
optionally logged according to the setting of SMURF_LOG_LEVEL
|
||||
in <a href="#Conf" title="/etc/shorewall/shorewall.conf">/etc/shorewall/shorewall.conf</a>.</p></dd></dl></div><p>My recommendations concerning options:</p><div class="itemizedlist"><ul type="disc"><li><p>External Interface -- <span class="bold"><b>tcpflags,blacklist,norfc1918,routefilter,nosmurfs</b></span></p></li><li><p>Wireless Interface -- <span class="bold"><b>maclist,routefilter,tcpflags,detectnets,nosmurfs</b></span></p></li><li><p>Use <span class="bold"><b>dhcp</b></span> and <span class="bold"><b>proxyarp</b></span> when needed.</p></li></ul></div></dd></dl></div><div class="example"><a id="id2865298"></a><p class="title"><b>Example 3. You have a conventional firewall setup in which eth0 connects to
|
||||
a Cable or DSL modem and eth1 connects to your local network and eth0
|
||||
gets its IP address via DHCP. You want to check all packets entering
|
||||
from the internet against the <a href="#Blacklist" title="/etc/shorewall/blacklist">black list</a>.
|
||||
Your /etc/shorewall/interfaces file would be as follows:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
net eth0 detect dhcp,norfc1918,blacklist</pre></td></tr></table></div><div class="example"><a id="id2865327"></a><p class="title"><b>Example 4. You have a standalone dialup GNU/Linux System. Your
|
||||
/etc/shorewall/interfaces file would be:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
net ppp0</pre></td></tr></table></div><div class="example"><a id="id2865345"></a><p class="title"><b>Example 5. You have local interface eth1 with two IP addresses -
|
||||
192.168.1.1/24 and 192.168.12.1/24</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
loc eth1 192.168.1.255,192.168.12.255</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Hosts"></a>/etc/shorewall/hosts Configuration</h2></div></div><div></div></div><p>For most applications, specifying zones entirely in terms of network
|
||||
interfaces is sufficient. There may be times though where you need to
|
||||
define a zone to be a more general collection of hosts. This is the
|
||||
purpose of the <tt class="filename">/etc/shorewall/hosts</tt> file.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>The only times that you need entries in <tt class="filename">/etc/shorewall/hosts</tt>
|
||||
are:</p><div class="orderedlist"><ol type="1"><li><p>You have <a href="Multiple_Zones.html" target="_self">more than one zone
|
||||
connecting through a single interface</a>; or</p></li><li><p>You have a <a href="Shorewall_and_Aliased_Interfaces.html" target="_self">zone
|
||||
that has multiple subnetworks that connect through a single
|
||||
interface</a> and you want the Shorewall box to route traffic
|
||||
between those subnetworks.</p></li></ol></div><p><span class="bold"><b>IF YOU DON'T HAVE EITHER OF THOSE
|
||||
SITUATIONS THEN DON'T TOUCH THIS FILE!!</b></span></p></div><p>Columns in this file are:</p><div class="variablelist"><dl><dt><span class="term">ZONE</span></dt><dd><p>A zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file.</p></dd><dt><span class="term">HOST(S)</span></dt><dd><p>The name of a network interface followed by a colon (“<span class="quote">:</span>”)
|
||||
followed by a comma-separated list either:</p><div class="orderedlist"><ol type="1"><li><p>An IP address (example - eth1:192.168.1.3)</p></li><li><p>A subnet in CIDR notation (example - eth2:192.168.2.0/24)</p></li></ol></div><p>The interface name much match an entry in
|
||||
<tt class="filename">/etc/shorewall/interfaces</tt>.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you are running a version of Shorewall earlier than
|
||||
1.4.6, only a single host/subnet address may be specified in an
|
||||
entry in <tt class="filename">/etc/shorewall/hosts</tt>.</p></div></dd><dt><span class="term">OPTIONS</span></dt><dd><p>A comma-separated list of option</p><div class="variablelist"><dl><dt><span class="term">routeback</span></dt><dd><p>(Added in version 1.4.2) - This option causes Shorewall
|
||||
to set up handling for routing packets sent by this host group
|
||||
back back to the same group.</p></dd><dt><span class="term">maclist</span></dt><dd><p>Added in version 1.3.10. If specified, connection
|
||||
requests from the hosts specified in this entry are subject to
|
||||
<a href="MAC_Validation.html" target="_self">MAC Verification</a>.
|
||||
This option is only valid for ethernet interfaces.</p></dd></dl></div></dd></dl></div><p>If you don't define any hosts for a zone, the hosts in the zone
|
||||
default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the
|
||||
interfaces to the zone.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>You probably DON'T want to specify any hosts for your internet
|
||||
zone since the hosts that you specify will be the only ones that you
|
||||
will be able to access without adding additional rules.</p></div><div class="example"><a id="id2865682"></a><p class="title"><b>Example 6. Your local interface is eth1 and you have two groups of local
|
||||
hosts that you want to make into separate zones:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">192.168.1.0/25 192.168.1.128/25</pre></td></tr></table><p>Your /etc/shorewall/interfaces file might look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
net eth0 detect dhcp,norfc1918
|
||||
- eth1 192.168.1.127,192.168.1.255</pre></td></tr></table><p>The “<span class="quote">-</span>” in the ZONE column for eth1 tells Shorewall
|
||||
that eth1 interfaces to multiple zones.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
|
||||
loc1 eth1:192.168.1.0/25
|
||||
loc2 eth1:192.168.1.128/25</pre></td></tr></table></div><div class="example"><a id="id2865731"></a><p class="title"><b>Example 7. You have local interface eth1 with two IP addresses -
|
||||
192.168.1.1/24 and 192.168.12.1/24</b></p><p>Your /etc/shorewall/interfaces file might look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
net eth0 detect dhcp,norfc1918
|
||||
- eth1 192.168.1.255,192.168.12.255</pre></td></tr></table><p>Your /etc/shorewall/hosts file might look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
|
||||
loc eth1:192.168.1.0/24
|
||||
loc eth1:192.168.12.0/24</pre></td></tr></table><p>If you are running Shorewall 1.4.6 or later, your hosts file may
|
||||
look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
|
||||
loc eth1:192.168.1.0/24,192.168.12.0/24</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Nested"></a>Nested and Overlapping Zones</h3></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/interfaces</tt> and
|
||||
<tt class="filename">/etc/shorewall/hosts</tt> file allow you to define
|
||||
nested or overlapping zones. Such overlapping/nested zones are allowed
|
||||
and Shorewall processes zones in the order that they appear in the
|
||||
<tt class="filename">/etc/shorewall/zones</tt> file. So if you have nested
|
||||
zones, you want the sub-zone to appear before the super-zone and in the
|
||||
case of overlapping zones, the rules that will apply to hosts that
|
||||
belong to both zones is determined by which zone appears first in
|
||||
<tt class="filename">/etc/shorewall/zones</tt>.</p><p>Hosts that belong to more than one zone may be managed by the
|
||||
rules of all of those zones. This is done through use of the special
|
||||
<a href="#CONTINUE" title="The CONTINUE policy">CONTINUE policy</a> described below.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Policy"></a>/etc/shorewall/policy Configuration</h2></div></div><div></div></div><p>This file is used to describe the firewall policy regarding
|
||||
establishment of connections. Connection establishment is described in
|
||||
terms of <span class="emphasis"><em>clients</em></span> who initiate connections and
|
||||
<span class="emphasis"><em>servers</em></span> who receive those connection requests.
|
||||
Policies defined in <tt class="filename">/etc/shorewall/policy </tt>describe
|
||||
which zones are allowed to establish connections with other zones.</p><p>Policies established in <tt class="filename">/etc/shorewall/policy </tt>can
|
||||
be viewed as default policies. If no rule in /etc/shorewall/rules applies
|
||||
to a particular connection request then the policy from
|
||||
<tt class="filename">/etc/shorewall/policy</tt> is applied.</p><p>Five policies are defined:</p><div class="variablelist"><dl><dt><span class="term">ACCEPT</span></dt><dd><p>The connection is allowed.</p></dd><dt><span class="term">DROP</span></dt><dd><p>The connection request is ignored.</p></dd><dt><span class="term">REJECT</span></dt><dd><p>The connection request is rejected with an RST (TCP) or an
|
||||
ICMP destination-unreachable packet being returned to the client.</p></dd><dt><span class="term">CONTINUE</span></dt><dd><p>The connection is neither ACCEPTed, DROPped nor REJECTed.
|
||||
CONTINUE may be used when one or both of the zones named in the
|
||||
entry are sub-zones of or intersect with another zone. For more
|
||||
information, see below.</p></dd><dt><span class="term">NONE</span></dt><dd><p>(Added in version 1.4.1) - Shorewall should not set up any
|
||||
infrastructure for handling traffic from the SOURCE zone to the DEST
|
||||
zone. When this policy is specified, the <span class="bold"><b>LOG
|
||||
LEVEL</b></span> and <span class="bold"><b>BURST:LIMIT</b></span>
|
||||
columns must be left blank.</p></dd></dl></div><p>For each policy specified in /etc/shorewall/policy, you can indicate
|
||||
that you want a message sent to your system log each time that the policy
|
||||
is applied.</p><p>Entries in /etc/shorewall/policy have four columns as follows:</p><div class="variablelist"><dl><dt><span class="term">SOURCE</span></dt><dd><p>The name of a client zone (a zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file , the <a href="#Conf" title="/etc/shorewall/shorewall.conf">name of the
|
||||
firewall zone</a> or “<span class="quote">all</span>”).</p></dd><dt><span class="term">DEST</span></dt><dd><p>The name of a destination zone (a zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file , the <a href="#Conf" title="/etc/shorewall/shorewall.conf">name of the
|
||||
firewall zone</a> or “<span class="quote">all</span>”). Shorewall automatically
|
||||
allows all traffic from the firewall to itself so the <a href="#Conf" title="/etc/shorewall/shorewall.conf">name of the firewall zone</a> cannot appear in
|
||||
both the SOURCE and DEST columns.</p></dd><dt><span class="term">POLICY</span></dt><dd><p>The default policy for connection requests from the SOURCE
|
||||
zone to the DESTINATION zone.</p></dd><dt><span class="term">LOG LEVEL</span></dt><dd><p>Optional. If left empty, no log message is generated when the
|
||||
policy is applied. Otherwise, this column should contain an integer
|
||||
or name indicating a <a href="shorewall_logging.html" target="_self">syslog
|
||||
level</a>.</p></dd><dt><span class="term">LIMIT:BURST - optional</span></dt><dd><p>If left empty, TCP connection requests from the <span class="bold"><b>SOURCE</b></span> zone to the <span class="bold"><b>DEST</b></span>
|
||||
zone will not be rate-limited. Otherwise, this column specifies the
|
||||
maximum rate at which TCP connection requests will be accepted
|
||||
followed by a colon (“<span class="quote">:</span>”) followed by the maximum burst
|
||||
size that will be tolerated. Example: <span class="bold"><b>10/sec:40</b></span>
|
||||
specifies that the maximum rate of TCP connection requests allowed
|
||||
will be 10 per second and a burst of 40 connections will be
|
||||
tolerated. Connection requests in excess of these limits will be
|
||||
dropped. See the <a href="#Rules" title="/etc/shorewall/rules">rules file documentation</a>
|
||||
for an explaination of how rate limiting works.</p></dd></dl></div><p>In the SOURCE and DEST columns, you can enter “<span class="quote">all</span>” to
|
||||
indicate all zones.</p><p>The default <tt class="filename">/etc/shorewall/policy</tt> file is as
|
||||
follows.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||||
loc net ACCEPT
|
||||
net all DROP info
|
||||
all all REJECT info</pre></td></tr></table><p>This table may be interpreted as follows:</p><div class="itemizedlist"><ul type="disc"><li><p>All connection requests from the local network to hosts on the
|
||||
internet are accepted.</p></li><li><p>All connection requests originating from the internet are
|
||||
ignored and logged at level KERNEL.INFO.</p></li><li><p>All other connection requests are rejected and logged.</p></li></ul></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>The firewall script processes the <tt class="filename">/etc/shorewall/policy</tt>
|
||||
file from top to bottom and <span class="bold"><b>uses the first
|
||||
applicable policy that it finds</b></span>. For example, in the
|
||||
following policy file, the policy for (loc, loc) connections would be
|
||||
ACCEPT as specified in the first entry even though the third entry in
|
||||
the file specifies REJECT.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||||
loc all ACCEPT
|
||||
net all DROP info
|
||||
loc loc REJECT info</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2866348"></a>Intra-Zone Traffic</h3></div></div><div></div></div><p>Shorewall allows a zone to be associated with more than one
|
||||
interface or with multiple networks that interface through a single
|
||||
interface. Beginning with Shorewall 1.4.1, Shorewall will ACCEPT all
|
||||
traffic from a zone to itself provided that there is no explicit policy
|
||||
governing traffic from that zone to itself (an explicit policy does not
|
||||
specify “<span class="quote">all</span>” in either the SOURCE or DEST column) and that
|
||||
there are no rules concerning connections from that zone to itself. If
|
||||
there is an explicit policy or if there are one or more rules, then
|
||||
traffic within the zone is handled just like traffic between zones is.</p><p>Any time that you have multiple interfaces associated with a
|
||||
single zone, you should ask yourself if you really want traffic routed
|
||||
between those interfaces. Cases where you might not want that behavior
|
||||
are:</p><div class="orderedlist"><ol type="1"><li><p>Multiple “<span class="quote">net</span>” interfaces to different ISPs. You
|
||||
don't want to route traffic from one ISP to the other through
|
||||
your firewall.</p></li><li><p>Multiple VPN clients. You don't necessarily want them to
|
||||
all be able to communicate between themselves using your
|
||||
gateway/router.</p></li></ol></div><p>Beginning with Shorewall 2.0.0, you can control the traffic from
|
||||
the firewall to itself. As with any zone, fw->fw traffic is enabled
|
||||
by default. It is not necessary to define the loopback interface (lo) in
|
||||
<a href="#Interfaces" title="/etc/shorewall/interfaces">/etc/shorewall/interfaces</a> in order to
|
||||
define fw->fw rules or a fw->fw policy.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>So long as there are no intra-zone rules for a zone, all
|
||||
intra-zone traffic for that zone is accepted. As soon as you add a
|
||||
single rule from the zone to itself, then ALL traffic from that zone
|
||||
to itself is controlled by the rules and the first policy in
|
||||
<tt class="filename">/etc/shorewall/policy</tt> that matches the zone to
|
||||
itself.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="CONTINUE"></a>The CONTINUE policy</h3></div></div><div></div></div><p>Where zones are <a href="#Nested" title="Nested and Overlapping Zones">nested or overlapping</a>,
|
||||
the CONTINUE policy allows hosts that are within multiple zones to be
|
||||
managed under the rules of all of these zones. Let's look at an
|
||||
example:</p><p><tt class="filename">/etc/shorewall/zones</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE DISPLAY COMMENTS
|
||||
sam Sam Sam's system at home
|
||||
net Internet The Internet
|
||||
loc Local Local Network</pre></td></tr></table><p><tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
- eth0 detect dhcp,norfc1918
|
||||
loc eth1 detect</pre></td></tr></table><p><tt class="filename">/etc/shorewall/hosts</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
|
||||
net eth0:0.0.0.0/0
|
||||
sam eth0:206.191.149.197</pre></td></tr></table><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Sam's home system is a member of both the <span class="bold"><b>sam</b></span> zone and the <span class="bold"><b>net</b></span>
|
||||
zone and <a href="#Nested" title="Nested and Overlapping Zones">as described above</a> , that means
|
||||
that <span class="bold"><b>sam</b></span> must be listed before
|
||||
<span class="bold"><b>net</b></span> in <tt class="filename">/etc/shorewall/zones</tt>.</p></div><p><tt class="filename">/etc/shorewall/policy</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL
|
||||
loc net ACCEPT
|
||||
sam all CONTINUE
|
||||
net all DROP info
|
||||
all all REJECT info</pre></td></tr></table><p>The second entry above says that when Sam is the client,
|
||||
connection requests should first be process under rules where the source
|
||||
zone is <span class="bold"><b>sam</b></span> and if there is no match
|
||||
then the connection request should be treated under rules where the
|
||||
source zone is <span class="bold"><b>net</b></span>. It is important
|
||||
that this policy be listed BEFORE the next policy (<span class="bold"><b>net</b></span>
|
||||
to <span class="bold"><b>all</b></span>).</p><p>Partial <tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
...
|
||||
DNAT sam loc:192.168.1.3 tcp ssh
|
||||
DNAT net loc:192.168.1.5 tcp www
|
||||
...</pre></td></tr></table><p>Given these two rules, Sam can connect to the firewall's
|
||||
internet interface with ssh and the connection request will be forwarded
|
||||
to 192.168.1.3. Like all hosts in the <span class="bold"><b>net</b></span>
|
||||
zone, Sam can connect to the firewall's internet interface on TCP
|
||||
port 80 and the connection request will be forwarded to 192.168.1.5. The
|
||||
order of the rules is not significant.</p><p><a id="Exclude"></a>Sometimes it is necessary to suppress port forwarding
|
||||
for a sub-zone. For example, suppose that all hosts can SSH to the
|
||||
firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects
|
||||
to the firewall's external IP, he should be connected to the
|
||||
firewall itself. Because of the way that Netfilter is constructed, this
|
||||
requires two rules as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
...
|
||||
DNAT sam fw tcp ssh
|
||||
DNAT net loc:192.168.1.3 tcp ssh
|
||||
...</pre></td></tr></table><p>The first rule allows Sam SSH access to the firewall. The second
|
||||
rule says that any clients from the net zone with the exception of those
|
||||
in the “<span class="quote">sam</span>” zone should have their connection port
|
||||
forwarded to 192.168.1.3. If you need to exclude more than one zone in
|
||||
this way, you can list the zones separated by commas (e.g.,
|
||||
net!sam,joe,fred). This technique also may be used when the ACTION is
|
||||
REDIRECT.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Rules"></a>/etc/shorewall/rules</h2></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/rules</tt> file defines
|
||||
exceptions to the policies established in the <tt class="filename">/etc/shorewall/policy</tt>
|
||||
file. There is one entry in /etc/shorewall/rules for each of these rules.
|
||||
Entries in this file only govern the establishment of new connections —
|
||||
packets that are part of an existing connection or that establish a
|
||||
connection that is related to an existing connection are automatically
|
||||
accepted.</p><p>Rules for each pair of zones (source zone, destination zone) are
|
||||
evaluated in the order that they appear in the file — the first match
|
||||
determines the disposition of the connection request with a couple of
|
||||
caveats:</p><div class="itemizedlist"><ul type="disc"><li><p>LOG rules cause the connection request to be logged then
|
||||
processing continues with the next rule in the file.</p></li><li><p>QUEUE rules cause the connection request to be passed to
|
||||
user-space -- the user-space application can later insert them back
|
||||
into the stream for further processing by following rules.</p></li><li><p>CONTINUE rules may cause the connection request to be
|
||||
reprocessed using a different (source zone, destination zone) pair.</p></li></ul></div><p>Entries in the file have the following columns:</p><div class="variablelist"><dl><dt><span class="term">ACTION</span></dt><dd><div class="variablelist"><dl><dt><span class="term">ACCEPT, DROP, REJECT, CONTINUE</span></dt><dd><p>These have the same meaning here as in the policy file
|
||||
above.</p></dd><dt><span class="term">DNAT</span></dt><dd><p>Causes the connection request to be forwarded to the
|
||||
system specified in the DEST column (port forwarding).
|
||||
“<span class="quote">DNAT</span>” stands for “<span class="quote"><span class="bold"><b>D</b></span>estination
|
||||
<span class="bold"><b>N</b></span>etwork <span class="bold"><b>A</b></span>ddress
|
||||
<span class="bold"><b>T</b></span>ranslation</span>”</p></dd><dt><span class="term">DNAT-</span></dt><dd><p>The above ACTION (DNAT) generates two iptables rules:</p><div class="orderedlist"><ol type="1"><li><p>a header-rewriting rule in the Netfilter
|
||||
“<span class="quote">nat</span>” table</p></li><li><p>an ACCEPT rule in the Netfilter “<span class="quote">filter</span>”
|
||||
table.</p></li></ol></div><p>DNAT- works like DNAT but only generates the
|
||||
header-rewriting rule.</p></dd><dt><span class="term">REDIRECT</span></dt><dd><p>Causes the connection request to be redirected to a port
|
||||
on the local (firewall) system.</p></dd><dt><span class="term">REDIRECT-</span></dt><dd><p>The above ACTION (REDIRECT) generates two iptables
|
||||
rules:</p><div class="orderedlist"><ol type="1"><li><p>a header-rewriting rule in the Netfilter
|
||||
“<span class="quote">nat</span>” table</p></li><li><p>an ACCEPT rule in the Netfilter “<span class="quote">filter</span>”
|
||||
table.</p></li></ol></div><p>REDIRECT- works like REDIRECT but only generates the
|
||||
header-rewriting rule.</p></dd><dt><span class="term">LOG</span></dt><dd><p>Log the packet -- requires a syslog level (see below).</p></dd><dt><span class="term">QUEUE</span></dt><dd><p>Forward the packet to a user-space application. This
|
||||
facility is provided to allow interfacing to <a href="http://p2pwall.sourceforge.net" target="_self">ftwall</a> for <a href="Shorewall_and_Kazaa.html" target="_self">Kazaa filtering</a>.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When the protocol specified in the PROTO column is TCP
|
||||
(“<span class="quote">tcp</span>”, “<span class="quote">TCP</span>” or “<span class="quote">6</span>”),
|
||||
Shorewall will only pass connection requests (SYN packets)
|
||||
to user space. This is for compatibility with ftwall.</p></div></dd><dt><span class="term"><a href="User_defined_Actions.html" target="_self"><defined
|
||||
action></a></span></dt><dd><p>(Shorewall 1.4.9 and later) - An action defined in the
|
||||
<tt class="filename"><a href="User_defined_Actions.html" target="_self">/etc/shorewall/actions</a></tt>
|
||||
file.</p></dd></dl></div><p>The ACTION may optionally be followed by “<span class="quote">:</span>” and
|
||||
a <a href="shorewall_logging.html" target="_self">syslog level</a> (example:
|
||||
REJECT:info or ACCEPT:debug). This causes the packet to be logged at
|
||||
the specified level prior to being processed according to the
|
||||
specified ACTION. Note: if the ACTION is LOG then you MUST specify a
|
||||
syslog level.</p><p>The use of DNAT or REDIRECT requires that you have NAT enabled
|
||||
in your <a href="kernel.htm" target="_self">kernel configuration</a>.</p></dd><dt><span class="term">SOURCE</span></dt><dd><p>Describes the source hosts to which the rule applies.. The
|
||||
contents of this field must begin with the name of a zone defined in
|
||||
/etc/shorewall/zones, $FW or “<span class="quote">all</span>”. If the ACTION is
|
||||
DNAT or REDIRECT, sub-zones may be excluded from the rule by
|
||||
following the initial zone name with “<span class="quote">!</span>” and a
|
||||
comma-separated list of those sub-zones to be excluded. There is an
|
||||
<a href="#Exclude">example</a> above.</p><p>If the source is not “<span class="quote">all</span>” then the source may be
|
||||
further restricted by adding a colon (“<span class="quote">:</span>”) followed by
|
||||
a comma-separated list of qualifiers. Qualifiers are may include:</p><div class="variablelist"><dl><dt><span class="term">interface name</span></dt><dd><p>refers to any connection requests arriving on the
|
||||
specified interface (example loc:eth4). Beginning with
|
||||
Shorwall 1.3.9, the interface name may optionally be followed
|
||||
by a colon (“<span class="quote">:</span>”) and an IP address or subnet
|
||||
(examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).</p></dd><dt><span class="term">IP address</span></dt><dd><p>refers to a connection request from the host with the
|
||||
specified address (example net:155.186.235.151). If the ACTION
|
||||
is DNAT, this must not be a DNS name.</p></dd><dt><span class="term">MAC Address</span></dt><dd><p>in <a href="configuration_file_basics.htm#MAC" target="_self">Shorewall
|
||||
format</a>.</p></dd><dt><span class="term">subnet</span></dt><dd><p>refers to a connection request from any host in the
|
||||
specified subnet (example net:155.186.235.0/24).</p></dd></dl></div></dd><dt><span class="term">DEST</span></dt><dd><p>Describes the destination host(s) to which the rule applies.
|
||||
May take most of the forms described above for SOURCE plus the
|
||||
following two additional forms:</p><div class="itemizedlist"><ul type="disc"><li><p>An IP address followed by a colon and the port <span class="bold"><b>number</b></span> that the server is listening on
|
||||
(service names from /etc/services are not allowed - example
|
||||
loc:192.168.1.3:80).</p></li><li><p>A single port number (again, service names are not
|
||||
allowed) -- this form is only allowed if the ACTION is REDIRECT
|
||||
and refers to a server running on the firewall itself and
|
||||
listening on the specified port.</p></li></ul></div><p>Restrictions:</p><div class="itemizedlist"><ul type="disc"><li><p>MAC addresses may not be specified.</p></li><li><p>In DNAT rules, only IP addresses may be given -- DNS names
|
||||
are not permitted.</p></li><li><p>You may not specify both an IP address and an interface
|
||||
name in the DEST column.</p></li></ul></div><p>Unlike in the SOURCE column, a range of IP addresses may be
|
||||
specified in the DEST column as <<span class="emphasis"><em>first address</em></span>>-<<span class="emphasis"><em>last
|
||||
address</em></span>>. When the ACTION is DNAT or DNAT-,
|
||||
connections will be assigned to the addresses in the range in a
|
||||
round-robin fashion (load-balancing). <span class="bold"><b>This
|
||||
feature is available with DNAT rules only with Shorewall 1.4.6 and
|
||||
later versions; it is available with DNAT- rules in all versions
|
||||
that support DNAT-.</b></span></p></dd><dt><span class="term">PROTO</span></dt><dd><p>Protocol. Must be a protocol name from /etc/protocols, a
|
||||
number or “<span class="quote">all</span>”. Specifies the protocol of the
|
||||
connection request.</p></dd><dt><span class="term">DEST PORT(S)</span></dt><dd><p>Port or port range (<low port>:<high port>)
|
||||
being connected to. May only be specified if the protocol is tcp,
|
||||
udp or icmp. For icmp, this column's contents are interpreted as
|
||||
an icmp type. If you don't want to specify DEST PORT(S) but need
|
||||
to include information in one of the columns to the right, enter
|
||||
“<span class="quote">-</span>” in this column. You may give a list of ports and/or
|
||||
port ranges separated by commas. Port numbers may be either integers
|
||||
or service names from /etc/services.</p></dd><dt><span class="term">SOURCE PORTS(S)</span></dt><dd><p>May be used to restrict the rule to a particular client port
|
||||
or port range (a port range is specified as <low port
|
||||
number>:<high port number>). If you don't want to
|
||||
restrict client ports but want to specify something in the next
|
||||
column, enter “<span class="quote">-</span>” in this column. If you wish to
|
||||
specify a list of port number or ranges, separate the list elements
|
||||
with commas (with no embedded white space). Port numbers may be
|
||||
either integers or service names from /etc/services.</p></dd><dt><span class="term">ORIGINAL DEST</span></dt><dd><p>This column may only be non-empty if the ACTION is DNAT or
|
||||
REDIRECT.</p><p>If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column
|
||||
is left empty, any connection request arriving at the firewall from
|
||||
the SOURCE that matches the rule will be forwarded or redirected.
|
||||
This works fine for connection requests arriving from the internet
|
||||
where the firewall has only a single external IP address. When the
|
||||
firewall has multiple external IP addresses or when the SOURCE is
|
||||
other than the internet, there will usually be a desire for the rule
|
||||
to only apply to those connection requests directed to particular IP
|
||||
addresses (see Example 2 below for another usage). Those IP
|
||||
addresses are specified in the ORIGINAL DEST column as a
|
||||
comma-separated list.</p><p>The IP address(es) may be optionally followed by
|
||||
“<span class="quote">:</span>” and a second IP address. This latter address, if
|
||||
present, is used as the source address for packets forwarded to the
|
||||
server (This is called “<span class="quote">Source NAT</span>” or SNAT.</p><p>If this list begins with “<span class="quote">!</span>” then the rule will
|
||||
only apply if the original destination address matches none of the
|
||||
addresses listed.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When using SNAT, it is a good idea to qualify the source
|
||||
with an IP address or subnet. Otherwise, it is likely that SNAT
|
||||
will occur on connections other than those described in the rule.
|
||||
The reason for this is that SNAT occurs in the Netfilter
|
||||
POSTROUTING hook where it is not possible to restrict the scope of
|
||||
a rule by incoming interface.</p><div class="example"><a id="id2876539"></a><p class="title"><b>Example 8. </b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
|
||||
# PORT(S) PORT(S) DEST
|
||||
DNAT loc:<span class="bold"><b>192.168.1.0/24</b></span> loc:192.168.1.3 tcp www - 206.124.146.179:192.168.1.3</pre></td></tr></table></div></div><p>If SNAT is not used (no “<span class="quote">:</span>” and second IP
|
||||
address), the original source address is used. If you want any
|
||||
destination address to match the rule but want to specify SNAT,
|
||||
simply use a colon followed by the SNAT address.</p></dd><dt><span class="term">RATE LIMIT</span></dt><dd><p>Beginning with Shorewall version 1.4.7, you may rate-limit
|
||||
ACCEPT, DNAT[-], REDIRECT[-] or LOG rules with an entry in this
|
||||
column. Entries have the form</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><rate>/<interval>[:<burst>]</pre></td></tr></table><p>where <rate> is the number of connections per
|
||||
<interval> (“<span class="quote">sec</span>” or “<span class="quote">min</span>”) and
|
||||
<burst> is the largest burst permitted. If no burst value is
|
||||
given, a value of 5 is assumed.</p><p>There may be no whitespace embedded in the specification.</p><div class="example"><a id="id2876631"></a><p class="title"><b>Example 9. Let's take</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ACCEPT<2/sec:4> net dmz tcp 80</pre></td></tr></table><p>The first time this rule is reached, the packet will be
|
||||
accepted; in fact, since the burst is 4, the first four packets
|
||||
will be accepted. After this, it will be 500ms (1 second divided
|
||||
by the rate of 2) before a packet will be accepted from this rule,
|
||||
regardless of how many packets reach it. Also, every 500ms which
|
||||
passes without matching a packet, one of the bursts will be
|
||||
regained; if no packets hit the rule for 2 second, the burst will
|
||||
be fully recharged; back where we started.</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>When rate limiting is specified on a rule with
|
||||
“<span class="quote">all</span>” in the SOURCE or DEST fields below, the limit
|
||||
will apply to each pair of zones individually rather than as a
|
||||
single limit for all pairs of zones covered by the rule.</p></div><p>If you want to specify any following columns but no rate
|
||||
limit, place “<span class="quote">-</span>” in this column.</p></dd><dt><span class="term">USER/GROUP</span></dt><dd><p>Beginning with Shorewall release 1.4.7, output rules from the
|
||||
firewall itself may be restricted to a particular set of users
|
||||
and/or user groups. See the <a href="UserSets.html" target="_self">User Set
|
||||
Documentation</a> for details.</p></dd></dl></div><div class="example"><a id="id2876723"></a><p class="title"><b>Example 10. You wish to forward all ssh connection requests from the internet
|
||||
to local system 192.168.1.3. You wish to limit the number of connections
|
||||
to 4/minute with a burst of 8 (Shorewall 1.4.7 and later only):</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
DNAT<4/min:8> net loc:192.168.1.3 tcp ssh</pre></td></tr></table></div><div class="example"><a id="id2876744"></a><p class="title"><b>Example 11. You want to redirect all local www connection requests EXCEPT
|
||||
those to your own http server (206.124.146.177) to a Squid transparent
|
||||
proxy running on the firewall and listening on port 3128. Squid will of
|
||||
course require access to remote web servers. This example shows yet
|
||||
another use for the ORIGINAL DEST column; here, connection requests that
|
||||
were NOT (notice the “<span class="quote">!</span>”) originally destined to
|
||||
206.124.146.177 are redirected to local port 3128.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
REDIRECT loc 3128 tcp www - !206.124.146.177
|
||||
ACCEPT fw net tcp www</pre></td></tr></table></div><div class="example"><a id="id2876777"></a><p class="title"><b>Example 12. You want to run a web server at 155.186.235.222 in your DMZ and
|
||||
have it accessible remotely and locally. the DMZ is managed by Proxy ARP
|
||||
or by classical sub-netting.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT net dmz:155.186.235.222 tcp www
|
||||
ACCEPT loc dmz:155.186.235.222 tcp www</pre></td></tr></table></div><div class="example"><a id="id2876799"></a><p class="title"><b>Example 13. You want to run wu-ftpd on 192.168.2.2 in your masqueraded DMZ.
|
||||
Your internet interface address is 155.186.235.151 and you want the FTP
|
||||
server to be accessible from the internet in addition to the local
|
||||
192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks.</b></p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>since the server is in the 192.168.2.0/24 subnetwork,
|
||||
we can assume that access to the server from that subnet will not
|
||||
involve the firewall (<a href="FAQ.htm#faq2" target="_self">but see FAQ 2</a>)</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>unless
|
||||
you have more than one external IP address, you can leave the ORIGINAL
|
||||
DEST column blank in the first rule. You cannot leave it blank in the
|
||||
second rule though because then all ftp connections originating in the
|
||||
local subnet 192.168.1.0/24 would be sent to 192.168.2.2 regardless of
|
||||
the site that the user was trying to connect to. That is clearly not
|
||||
what you want.</p></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
DNAT net dmz:192.168.2.2 tcp ftp
|
||||
DNAT loc:192.168.1.0/24 dmz:192.168.2.2 tcp ftp - 155.186.235.151</pre></td></tr></table><p>If you are running wu-ftpd, you should restrict the range of
|
||||
passive in your /etc/ftpaccess file. I only need a few simultaneous FTP
|
||||
sessions so I use port range 65500-65535. In /etc/ftpaccess, this entry
|
||||
is appropriate:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">passive ports 0.0.0.0/0 65500 65534</pre></td></tr></table><p>If you are running pure-ftpd, you would include “<span class="quote">-p
|
||||
65500:65534</span>” on the pure-ftpd runline.</p><p>The important point here is to ensure that the port range used for
|
||||
FTP passive connections is unique and will not overlap with any usage on
|
||||
the firewall system.</p></div><div class="example"><a id="id2876887"></a><p class="title"><b>Example 14. You wish to allow unlimited DMZ access to the host with MAC
|
||||
address 02:00:08:E3:FA:55.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT loc:~02-00-08-E3-FA-55 dmz all</pre></td></tr></table></div><div class="example"><a id="id2876906"></a><p class="title"><b>Example 15. You wish to allow access to the SMTP server in your DMZ from all
|
||||
zones.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT all dmz tcp 25</pre></td></tr></table><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When “<span class="quote">all</span>” is used as a source or
|
||||
destination, intra-zone traffic is not affected. In this example, if
|
||||
there were two DMZ interfaces then the above rule would NOT enable SMTP
|
||||
traffic between hosts on these interfaces.</p></div></div><div class="example"><a id="id2876940"></a><p class="title"><b>Example 16. Your firewall's external interface has several IP addresses
|
||||
but you only want to accept SSH connections on address 206.124.146.176.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT net fw:206.124.146.176 tcp 22</pre></td></tr></table></div><div class="example"><a id="id2876962"></a><p class="title"><b>Example 17. (For advanced users running Shorewall version 1.3.13 or later).
|
||||
From the internet, you with to forward tcp port 25 directed to
|
||||
192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your DMZ. You also
|
||||
want to allow access from the internet directly to tcp port 25 on
|
||||
192.0.2.177.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
DNAT- net dmz:192.0.2.177 tcp 25 - 192.0.2.178
|
||||
DNAT- net dmz:192.0.2.177 tcp 25 - 192.0.2.179
|
||||
ACCEPT net dmz:192.0.2.177 tcp 25</pre></td></tr></table><p>Using “<span class="quote">DNAT-</span>” rather than “<span class="quote">DNAT</span>” avoids
|
||||
two extra copies of the third rule from being generated.</p></div><div class="example"><a id="id2877003"></a><p class="title"><b>Example 18. (Shorewall version 1.4.6 or later). You have 9 http servers
|
||||
behind a Shorewall firewall and you want connection requests to be
|
||||
distributed among your servers. The servers are
|
||||
192.168.1.101-192.168.1.109.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
DNAT net loc:192.168.1.101-192.168.1.109 tcp 80</pre></td></tr></table></div><p><a href="ports.htm" target="_self">Look here for information on other services.</a></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Masq"></a>/etc/shorewall/masq</h2></div></div><div></div></div><p>The /etc/shorewall/masq file is used to define classical IP
|
||||
Masquerading and Source Network Address Translation (SNAT). There is one
|
||||
entry in the file for each subnet that you want to masquerade. In order to
|
||||
make use of this feature, you must have NAT enabled.</p><p>Columns are:</p><div class="variablelist"><dl><dt><span class="term">INTERFACE</span></dt><dd><p>The interface that will masquerade the subnet; this is
|
||||
normally your internet interface. This interface name can be
|
||||
optionally qualified by adding “<span class="quote">:</span>” and a subnet or host
|
||||
IP. When this qualification is added, only packets addressed to that
|
||||
host or subnet will be masqueraded. Beginning with Shorewall version
|
||||
1.4.10, the interface name can be qualified with ":"
|
||||
followed by a comma separated list of hosts and/or subnets. If this
|
||||
list begins with “<span class="quote">!</span>” (e.g., “<span class="quote">eth0:!192.0.2.8/29,192.0.2.32/29</span>”)
|
||||
then only packets addressed to destinations <span class="bold"><b>not</b></span>
|
||||
listed will be masqueraded; otherwise (e.g., “<span class="quote">eth0:192.0.2.8/29,192.0.2.32/29</span>”),
|
||||
traffic will be masqueraded if it <span class="bold"><b>does</b></span>
|
||||
match one of the listed addresses.</p><p>Beginning with Shorewall version 1.3.14, if you have set
|
||||
ADD_SNAT_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>, you can cause
|
||||
Shorewall to create an alias <span class="emphasis"><em>label</em></span> of the form
|
||||
<span class="emphasis"><em>interfacename:digit</em></span> (e.g., eth0:0) by placing
|
||||
that label in this column. See example 5 below. Alias labels created
|
||||
in this way allow the alias to be visible to the ipconfig utility.
|
||||
<span class="bold"><b>THAT IS THE ONLY THING THAT THIS LABEL IS GOOD
|
||||
FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL
|
||||
CONFIGURATION.</b></span></p></dd><dt><span class="term">SUBNET</span></dt><dd><p>The subnet that you want to have masqueraded through the
|
||||
INTERFACE. This may be expressed as a single IP address, a subnet or
|
||||
an interface name. In the latter instance, the interface must be
|
||||
configured and started before Shorewall is started as Shorewall will
|
||||
determine the subnet based on information obtained from the
|
||||
“<span class="quote">ip</span>” utility.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>When using Shorewall 1.3.13 or earlier, when an interface
|
||||
name is specified, Shorewall will only masquerade traffic from the
|
||||
first subnetwork on the named interface; if the interface
|
||||
interfaces to more that one subnetwork, you will need to add
|
||||
additional entries to this file for each of those other
|
||||
subnetworks. Beginning with Shorewall 1.3.14, shorewall will
|
||||
masquerade/SNAT traffic from any host that is routed through the
|
||||
named interface.</p></div><p>The subnet may be optionally followed by “<span class="quote">!</span>” and
|
||||
a comma-separated list of addresses and/or subnets that are to be
|
||||
excluded from masquerading.</p></dd><dt><span class="term">ADDRESS</span></dt><dd><p>The source address to be used for outgoing packets. This
|
||||
column is optional and if left blank, the current primary IP address
|
||||
of the interface in the first column is used. If you have a static
|
||||
IP on that interface, listing it here makes processing of output
|
||||
packets a little less expensive for the firewall. If you specify an
|
||||
address in this column, it must be an IP address configured on the
|
||||
INTERFACE or you must have ADD_SNAT_ALIASES enabled in <a href="#Conf">/etc/shorewall/shorewall.conf</a>. Beginning with Shorewall version 1.4.6, you may
|
||||
include a range of IP addresses in this column to indicate that
|
||||
Netfilter should use the addresses in the range in round-robin
|
||||
fashion. Beginning with Shorewall version 1.4.7, you may include a
|
||||
list of ranges and/or addresses in this column; again, Netfilter
|
||||
will use all listed ranges/addresses in rounde-robin fashion.</p></dd></dl></div><div class="example"><a id="id2877263"></a><p class="title"><b>Example 19. You have eth0 connected to a cable modem and eth1 connected to
|
||||
your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq file
|
||||
would look like:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth0 192.168.9.0/24</pre></td></tr></table></div><div class="example"><a id="id2877282"></a><p class="title"><b>Example 20. You have a number of IPSEC tunnels through ipsec0 and you want to
|
||||
masquerade traffic from your 192.168.9.0/24 subnet to the remote subnet
|
||||
10.1.0.0/16 only.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
ipsec0:10.1.0.0/16 192.168.9.0/24</pre></td></tr></table></div><div class="example"><a id="id2877302"></a><p class="title"><b>Example 21. You have a DSL line connected on eth0 and a local network
|
||||
(192.168.10.0/24) connected to eth1. You want all local->net
|
||||
connections to use source address 206.124.146.176.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth0 192.168.10.0/24 206.124.146.176</pre></td></tr></table></div><div class="example"><a id="id2877324"></a><p class="title"><b>Example 22. Same as example 3 except that you wish to exclude 192.168.10.44
|
||||
and 192.168.10.45 from the SNAT rule.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth0 192.168.10.0/24!192.168.10.44,192.168.10.45 206.124.146.176</pre></td></tr></table></div><div class="example"><a id="id2877343"></a><p class="title"><b>Example 23. <span class="bold">(Shorewall version >= 1.3.14):</span>
|
||||
You have a second IP address (206.124.146.177) assigned to you and wish
|
||||
to use it for SNAT of the subnet 192.168.12.0/24. You want to give that
|
||||
address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth0:0 192.168.12.0/24 206.124.146.177</pre></td></tr></table></div><div class="example"><a id="id2877377"></a><p class="title"><b>Example 24. <span class="bold">(Shorewall version >= 1.4.7):</span>
|
||||
You want to use both 206.124.146.177 and 206.124.146.179 for SNAT of the
|
||||
subnet 192.168.12.0/24. Each address will be used on alternate outbound
|
||||
connections.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth0 192.168.12.0/24 206.124.146.177,206.124.146.179</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ProxyArp"></a>/etc/shorewall/proxyarp</h2></div></div><div></div></div><p>If you want to use proxy ARP on an entire sub-network, I suggest
|
||||
that you look at the <a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/" target="_self">Proxy ARP Subnet
|
||||
Mini HOWTO</a>. If you decide to use the technique described in that
|
||||
HOWTO, you can set the proxy_arp flag for an interface (<tt class="filename">/proc/sys/net/ipv4/conf/</tt><<span class="emphasis"><em>interface</em></span>><tt class="filename">/proxy_arp</tt>)
|
||||
by including the <span class="bold"><b>proxyarp</b></span> option in the
|
||||
interface's record in <a href="#Interfaces">/etc/shorewall/interfaces</a>. When using Proxy
|
||||
ARP sub-netting, you do <span class="bold"><b>NOT</b></span> include any
|
||||
entries in /etc/shorewall/proxyarp.</p><p>The <tt class="filename">/etc/shorewall/proxyarp </tt>file is used to
|
||||
define <a href="ProxyARP.htm" target="_self">Proxy ARP</a>. The file is typically
|
||||
used for enabling Proxy ARP on a small set of systems since you need one
|
||||
entry in this file for each system using proxy ARP. Columns are:</p><div class="variablelist"><dl><dt><span class="term">ADDRESS</span></dt><dd><p>address of the system.</p></dd><dt><span class="term">INTERFACE</span></dt><dd><p>the interface that connects to the system. If the interface is
|
||||
obvious from the subnetting, you may enter “<span class="quote">-</span>” in this
|
||||
column.</p></dd><dt><span class="term">EXTERNAL</span></dt><dd><p>the external interface that you want to honor ARP requests for
|
||||
the ADDRESS specified in the first column.</p></dd><dt><span class="term">HAVEROUTE</span></dt><dd><p>If you already have a route through INTERFACE to ADDRESS, this
|
||||
column should contain “<span class="quote">Yes</span>” or “<span class="quote">yes</span>”. If
|
||||
you want Shorewall to add the route, the column should contain
|
||||
“<span class="quote">No</span>” or “<span class="quote">no</span>”.</p></dd><dt><span class="term">PERSISTENT</span></dt><dd><p>If you specify "No" or "no" in the HAVEROUTE
|
||||
column, Shorewall will automatically add a route to the host in the
|
||||
ADDRESS column through the interface in the INTERFACE column. If you
|
||||
enter “<span class="quote">No</span>” or “<span class="quote">no</span>” in the PERSISTENT
|
||||
column or if you leave the column empty, that route will be deleted
|
||||
if you issue a <span><b class="command">shorewall stop</b></span> or
|
||||
<span><b class="command">shorewall clear</b></span> command. If you place
|
||||
“<span class="quote">Yes</span>” or “<span class="quote">yes</span>” in the PERSISTENT column,
|
||||
then those commands will not cause the route to be deleted.</p></dd></dl></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>After you have made a change to the <tt class="filename">/etc/shorewall/proxyarp
|
||||
file</tt>, you may need to flush the ARP cache of all routers on
|
||||
the LAN segment connected to the interface specified in the EXTERNAL
|
||||
column of the change/added entry(s). If you are having problems
|
||||
communicating between an individual host (A) on that segment and a
|
||||
system whose entry has changed, you may need to flush the ARP cache on
|
||||
host A as well.</p><p>ISPs typically have ARP configured with long TTL (hours!) so if
|
||||
your ISPs router has a stale cache entry (as seen using “<span class="quote">tcpdump
|
||||
-nei <external interface> host <IP addr></span>”), it
|
||||
may take a long while to time out. I personally have had to contact my
|
||||
ISP and ask them to delete a stale entry in order to restore a system to
|
||||
working order after changing my proxy ARP settings.</p></div><div class="example"><a id="id2877697"></a><p class="title"><b>Example 25. You have public IP addresses 155.182.235.0/28. You configure your
|
||||
firewall as follows:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">eth0 - 155.186.235.1 (internet connection) eth1 -
|
||||
192.168.9.0/24 (masqueraded local systems) eth2 - 192.168.10.1
|
||||
(interface to your DMZ)</pre></td></tr></table><p>In your DMZ, you want to install a Web/FTP server with public
|
||||
address 155.186.235.4. On the Web server, you subnet just like the
|
||||
firewall's eth0 and you configure 155.186.235.1 as the default
|
||||
gateway. In your <tt class="filename">/etc/shorewall/proxyarp</tt> file, you
|
||||
will have:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ADDRESS INTERFACE EXTERNAL HAVEROUTE
|
||||
155.186.235.4 eth2 eth0 NO</pre></td></tr></table><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>You may want to configure the servers in your DMZ with
|
||||
a subnet that is smaller than the subnet of your internet interface. See
|
||||
the <a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/" target="_self">Proxy
|
||||
ARP Subnet Mini HOWTO</a> for details. In this case you will want to
|
||||
place “<span class="quote">Yes</span>” in the HAVEROUTE column.</p></div></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Do not use Proxy ARP and FreeS/Wan on the same system unless you
|
||||
are prepared to suffer the consequences. If you start or restart
|
||||
Shorewall with an IPSEC tunnel active, the proxied IP addresses are
|
||||
mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to
|
||||
the interface that you specify in the INTERFACE column of
|
||||
<tt class="filename">/etc/shorewall/proxyarp</tt>. I haven't had the time
|
||||
to debug this problem so I can't say if it is a bug in the Kernel or
|
||||
in FreeS/Wan.</p><p>You <span class="bold"><b>might</b></span> be able to work around
|
||||
this problem using the following (I haven't tried it):</p><p>In <tt class="filename">/etc/shorewall/init</tt>, include:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">qt /etc/init.d/ipsec stop</b></span></pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/start</tt>, include:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">qt /etc/init.d/ipsec start</b></span></pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="NAT"></a>/etc/shorewall/nat</h2></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/nat</tt> file is used to define
|
||||
one-to-one NAT. There is one entry in the file for each one-to-one NAT
|
||||
relationship that you wish to define. In order to make use of this
|
||||
feature, you must have NAT enabled.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>If all you want to do is forward ports to servers behind your
|
||||
firewall, you do NOT want to use one-to-one NAT. Port forwarding can be
|
||||
accomplished with simple entries in the <a href="#Rules" title="/etc/shorewall/rules">rules file</a>.
|
||||
Also, in most cases <a href="#ProxyArp" title="/etc/shorewall/proxyarp">Proxy ARP</a> provides a
|
||||
superior solution to one-to-one NAT because the internal systems are
|
||||
accessed using the same IP address internally and externally.</p></div><p>Columns in an entry are:</p><div class="variablelist"><dl><dt><span class="term">EXTERNAL</span></dt><dd><p>External IP address</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>This should NOT be the primary IP address of the interface
|
||||
named in the next column.</p></div></dd><dt><span class="term">INTERFACE</span></dt><dd><p>Interface that you want the EXTERNAL IP address to appear on.
|
||||
Beginning with Shorewall version 1.3.14, if you have set
|
||||
ADD_IP_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>, you can specify an
|
||||
alias label of the form <span class="emphasis"><em>interfacename:digit</em></span>
|
||||
(e.g., eth0:0) and Shorewall will create the alias with that label.
|
||||
Alias labels created in this way allow the alias to be visible to
|
||||
the ipconfig utility. <span class="bold"><b>THAT IS THE ONLY THING
|
||||
THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN
|
||||
YOUR SHOREWALL CONFIGURATION.</b></span></p></dd><dt><span class="term">INTERNAL</span></dt><dd><p>Internal IP address.</p></dd><dt><span class="term">ALL INTERFACES</span></dt><dd><p>If “<span class="quote">Yes</span>” or “<span class="quote">yes</span>”, NAT will be
|
||||
effective from all hosts. If “<span class="quote">No</span>” or “<span class="quote">no</span>”
|
||||
(or if left empty) then NAT will be effective only through the
|
||||
interface named in the INTERFACE column.</p></dd><dt><span class="term">LOCAL</span></dt><dd><p>If Yes or yes and the ALL INTERFACES column contains Yes or
|
||||
yes, NAT will be effective from the firewall system.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>For this to work, you must be running kernel 2.4.19 or later
|
||||
and iptables 1.2.6a or later and you must have enabled <span class="bold"><b>CONFIG_IP_NF_NAT_LOCAL</b></span> in your kernel.</p></div></dd></dl></div><p><a href="NAT.htm" target="_self">Look here for additional information and an
|
||||
example.</a></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Tunnels"></a>/etc/shorewall/tunnels</h2></div></div><div></div></div><p>The /etc/shorewall/tunnels file allows you to define IPSec, GRE,
|
||||
IPIP, <a href="http://openvpn.sourceforge.net/" target="_self">OpenVPN</a>, PPTP
|
||||
and 6to4.tunnels with end-points on your firewall. To use ipsec, you must
|
||||
install version 1.9, 1.91 or the current <a href="http://www.xs4all.nl/%7Efreeswan/" target="_self">FreeS/WAN</a> development
|
||||
snapshot.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>For kernels 2.4.4 and above, you will need to use version 1.91 or
|
||||
a development snapshot as patching with version 1.9 results in kernel
|
||||
compilation errors.</p></div><p>Instructions for setting up <a href="IPSEC.htm" target="_self">IPSEC tunnels</a>
|
||||
may be found here, instructions for <a href="IPIP.htm" target="_self">IPIP and GRE
|
||||
tunnels</a> are here, instructions for <a href="OPENVPN.html" target="_self">OpenVPN
|
||||
tunnels</a> are here, instructions for <a href="PPTP.htm" target="_self">PPTP
|
||||
tunnels</a> are here, instructions for <a href="6to4.htm" target="_self">6to4
|
||||
tunnels</a> are here, and instructions for <a href="GenericTunnels.html" target="_self">integrating Shorewall with other types of
|
||||
tunnels</a> are here.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Conf"></a>/etc/shorewall/shorewall.conf</h2></div></div><div></div></div><p>This file is used to set the following firewall parameters:</p><div class="variablelist"><dl><dt><span class="term">SMURF_LOG_LEVEL</span></dt><dd><p>(Added at version 2.0.0) - Specifies the logging level for
|
||||
smurf packets (see the <span class="bold"><b>nosmurfs</b></span>
|
||||
option in <a href="#Interfaces" title="/etc/shorewall/interfaces">/etc/shorewall/interfaces</a>).
|
||||
If set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs
|
||||
are not logged.</p></dd><dt><span class="term">MODULE_SUFFIX</span></dt><dd><p>(Added at version 1.4.9) - The value of this variable
|
||||
determines the possible file extensions of kernel modules. The
|
||||
default value is "o gz ko and o.gz". See <a href="#modules">/etc/shorewall/modules</a> for more details.</p></dd><dt><span class="term">ADMINISABSENTMINDED</span></dt><dd><p>(Added at version 1.4.7) - The value of this variable affects
|
||||
Shorewall's <a href="starting_and_stopping_shorewall.htm" target="_self">stopped
|
||||
state</a>. When ADMINISABSENTMINDES=No, only traffic to/from
|
||||
those addresses listed in /etc/shorewall/routestopped is accepted
|
||||
when Shorewall is stopped.When ADMINISABSENTMINDED=Yes, in addition
|
||||
to traffic to/from addresses in /etc/shorewall/routestopped,
|
||||
connections that were active when Shorewall stopped continue to work
|
||||
and all new connections from the firewall system itself are allowed.
|
||||
If this variable is not set or is given the empty value then
|
||||
ADMINISABSENTMINDED=No is assumed.</p></dd><dt><span class="term">SHOREWALL_SHELL</span></dt><dd><p>(Added at version 1.4.6) - This parameter is used to specify
|
||||
the shell program to be used to interpret the firewall script
|
||||
(/usr/share/shorewall/firewall). If not specified or specified as a
|
||||
null value, /bin/sh is assumed.</p></dd><dt><span class="term">LOGFORMAT</span></dt><dd><p>(Added at version 1.4.4) - The value of this variable generate
|
||||
the --log-prefix setting for Shorewall logging rules. It contains a
|
||||
“<span class="quote">printf</span>” formatting template which accepts three
|
||||
arguments (the chain name, logging rule number (optional) and the
|
||||
disposition). To use LOGFORMAT with <a href="http://www.fireparse.com" target="_self">fireparse</a>, set it as:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGFORMAT="fp=%s:%d a=%s "</pre></td></tr></table><p>If the LOGFORMAT value contains the substring “<span class="quote">%d</span>”
|
||||
then the logging rule number is calculated and formatted in that
|
||||
position; if that substring is not included then the rule number is
|
||||
not included. If not supplied or supplied as empty
|
||||
(LOGFORMAT="") then “<span class="quote">Shorewall:%s:%s:</span>” is
|
||||
assumed.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span><b class="command">/sbin/shorewall</b></span> uses the leading part of
|
||||
the LOGFORMAT string (up to but not including the first
|
||||
“<span class="quote">%</span>”) to find log messages in the “<span class="quote">show log</span>”,
|
||||
“<span class="quote">status</span>” and “<span class="quote">hits</span>” commands. This part
|
||||
should not be omitted (the LOGFORMAT should not begin with
|
||||
“<span class="quote">%</span>”) and the leading part should be sufficiently
|
||||
unique for <span><b class="command">/sbin/shorewall</b></span> to identify
|
||||
Shorewall messages.</p></div></dd><dt><span class="term">CLEAR_TC</span></dt><dd><p>(Added at version 1.3.13) - If this option is set to
|
||||
“<span class="quote">No</span>” then Shorewall won't clear the current traffic
|
||||
control rules during [re]start. This setting is intended for use by
|
||||
people that prefer to configure traffic shaping when the network
|
||||
interfaces come up rather than when the firewall is started. If that
|
||||
is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do
|
||||
not supply an <tt class="filename">/etc/shorewall/tcstart</tt> file. That
|
||||
way, your traffic shaping rules can still use the “<span class="quote">fwmark</span>”
|
||||
classifier based on packet marking defined in
|
||||
/etc/shorewall/tcrules. If not specified, CLEAR_TC=Yes is assumed.</p></dd><dt><span class="term">MARK_IN_FORWARD_CHAIN</span></dt><dd><p>(Added at version 1.3.12) - If your kernel has a FORWARD chain
|
||||
in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes to cause
|
||||
the marking specified in the <a href="traffic_shaping.htm#tcrules" target="_self">tcrules file</a> to occur in
|
||||
that chain rather than in the PREROUTING chain. This permits you to
|
||||
mark inbound traffic based on its destination address when SNAT or
|
||||
Masquerading are in use. To determine if your kernel has a FORWARD
|
||||
chain in the mangle table, use the “<span class="quote"><span><b class="command">/sbin/shorewall
|
||||
show mangle</b></span></span>” command; if a FORWARD chain is
|
||||
displayed then your kernel will support this option. If this option
|
||||
is not specified or if it is given the empty value (e.g.,
|
||||
MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is
|
||||
assumed.</p></dd><dt><span class="term">RFC1918_LOG_LEVEL</span></dt><dd><p>(Added at version 1.3.12) - This parameter determines the
|
||||
level at which packets logged under the <a href="#rfc1918" title="/etc/shorewall/rfc1918 (Added in Version 1.3.1)">“<span class="quote">norfc1918</span>”
|
||||
mechanism</a> are logged. The value must be a valid <a href="shorewall_logging.html" target="_self">syslog level</a> and if no level is
|
||||
given, then info is assumed. Prior to Shorewall version 1.3.12,
|
||||
these packets are always logged at the info level.</p></dd><dt><span class="term">TCP_FLAGS_DISPOSITION</span></dt><dd><p>(Added in Version 1.3.11) - Determines the disposition of TCP
|
||||
packets that fail the checks enabled by the <a href="#Interfaces" title="/etc/shorewall/interfaces">tcpflags</a> interface option and must have
|
||||
a value of ACCEPT (accept the packet), REJECT (send an RST response)
|
||||
or DROP (ignore the packet). If not set or if set to the empty value
|
||||
(e.g., TCP_FLAGS_DISPOSITION="") then
|
||||
TCP_FLAGS_DISPOSITION=DROP is assumed.</p></dd><dt><span class="term">TCP_FLAGS_LOG_LEVEL</span></dt><dd><p>(Added in Version 1.3.11) - Determines the <a href="shorewall_logging.html" target="_self">syslog level</a> for logging
|
||||
packets that fail the checks enabled by the <a href="#Interfaces" title="/etc/shorewall/interfaces">tcpflags</a> interface option.The value must
|
||||
be a valid syslogd log level. If you don't want to log these
|
||||
packets, set to the empty value (e.g.,
|
||||
TCP_FLAGS_LOG_LEVEL="").</p></dd><dt><span class="term">MACLIST_DISPOSITION</span></dt><dd><p>(Added in Version 1.3.10) - Determines the disposition of
|
||||
connections requests that fail <a href="MAC_Validation.html" target="_self">MAC
|
||||
Verification</a> and must have the value ACCEPT (accept the
|
||||
connection request anyway), REJECT (reject the connection request)
|
||||
or DROP (ignore the connection request). If not set or if set to the
|
||||
empty value (e.g., MACLIST_DISPOSITION="") then
|
||||
MACLIST_DISPOSITION=REJECT is assumed.</p></dd><dt><span class="term">MACLIST_LOG_LEVEL</span></dt><dd><p>(Added in Version 1.3.10) - Determines the <a href="shorewall_logging.html" target="_self">syslog level</a> for logging
|
||||
connection requests that fail <a href="MAC_Validation.html" target="_self">MAC
|
||||
Verification</a>. The value must be a valid syslogd log level.
|
||||
If you don't want to log these connection requests, set to the
|
||||
empty value (e.g., MACLIST_LOG_LEVEL="").</p></dd><dt><span class="term">NEWNOTSYN</span></dt><dd><p>(Added in Version 1.3.8) - When set to “<span class="quote">Yes</span>” or
|
||||
“<span class="quote">yes</span>”, Shorewall will filter TCP packets that are not
|
||||
part of an established connention and that are not SYN packets (SYN
|
||||
flag on - ACK flag off). If set to “<span class="quote">No</span>”, Shorewall will
|
||||
silently drop such packets. If not set or set to the empty value
|
||||
(e.g., “<span class="quote">NEWNOTSYN=</span>”), NEWNOTSYN=No is assumed.</p><p>If you have a HA setup with failover to another firewall, you
|
||||
should have NEWNOTSYN=Yes on both firewalls. You should also select
|
||||
NEWNOTSYN=Yes if you have asymmetric routing.</p></dd><dt><span class="term">LOGNEWNOTSYN</span></dt><dd><p>(Added in Version 1.3.6) - Beginning with version 1.3.6,
|
||||
Shorewall drops non-SYN TCP packets that are not part of an existing
|
||||
connection. If you would like to log these packets, set LOGNEWNOTSYN
|
||||
to the <a href="shorewall_logging.html" target="_self">syslog level</a> at
|
||||
which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Packets logged under this option are usually the result of
|
||||
broken remote IP stacks rather than the result of any sort of
|
||||
attempt to breach your firewall.</p></div></dd><dt><span class="term">DETECT_DNAT_ADDRS</span></dt><dd><p>(Added in Version 1.3.4) - If set to “<span class="quote">Yes</span>” or
|
||||
“<span class="quote">yes</span>”, Shorewall will detect the first IP address of
|
||||
the interface to the source zone and will include this address in
|
||||
DNAT rules as the original destination IP address. If set to
|
||||
“<span class="quote">No</span>” or “<span class="quote">no</span>”, Shorewall will not detect
|
||||
this address and any destination IP address will match the DNAT
|
||||
rule. If not specified or empty, “<span class="quote">DETECT_DNAT_ADDRS=Yes</span>”
|
||||
is assumed.</p></dd><dt><span class="term">NAT_BEFORE_RULES</span></dt><dd><p>If set to “<span class="quote">No</span>” or “<span class="quote">no</span>”, port
|
||||
forwarding rules can override the contents of the <a href="#NAT">/etc/shorewall/nat</a> file. If set to “<span class="quote">Yes</span>” or
|
||||
“<span class="quote">yes</span>”, port forwarding rules cannot override one-to-one
|
||||
NAT. If not set or set to an empty value, “<span class="quote">Yes</span>” is
|
||||
assumed.</p></dd><dt><span class="term">FW</span></dt><dd><p>This parameter specifies the name of the firewall zone. If not
|
||||
set or if set to an empty string, the value “<span class="quote">fw</span>” is
|
||||
assumed.</p></dd><dt><span class="term">SUBSYSLOCK</span></dt><dd><p>This parameter should be set to the name of a file that the
|
||||
firewall should create if it starts successfully and remove when it
|
||||
stops. Creating and removing this file allows Shorewall to work with
|
||||
your distribution's initscripts. For RedHat, this should be set
|
||||
to /var/lock/subsys/shorewall. For Debian, the value is
|
||||
/var/state/shorewall and in LEAF it is /var/run/shorwall. Example:
|
||||
SUBSYSLOCK=/var/lock/subsys/shorewall.</p></dd><dt><span class="term">STATEDIR</span></dt><dd><p>This parameter specifies the name of a directory where
|
||||
Shorewall stores state information. If the directory doesn't
|
||||
exist when Shorewall starts, it will create the directory. Example:
|
||||
STATEDIR=/tmp/shorewall.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you change the STATEDIR variable while the firewall is
|
||||
running, create the new directory if necessary then copy the
|
||||
contents of the old directory to the new directory.</p></div></dd><dt><span class="term">MODULESDIR</span></dt><dd><p>This parameter specifies the directory where your kernel
|
||||
netfilter modules may be found. If you leave the variable empty,
|
||||
Shorewall will supply the value "/lib/modules/`uname
|
||||
-r`/kernel/net/ipv4/netfilter.</p></dd><dt><span class="term">LOGRATE and LOGBURST</span></dt><dd><p>These parameters set the match rate and initial burst size for
|
||||
logged packets. Please see the iptables man page for a description
|
||||
of the behavior of these parameters (the iptables option --limit is
|
||||
set by LOGRATE and --limit-burst is set by LOGBURST). If both
|
||||
parameters are set empty, no rate-limiting will occur.</p><div class="example"><a id="id2879060"></a><p class="title"><b>Example 26. </b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGRATE=10/minute LOGBURST=5</pre></td></tr></table></div></dd><dt><span class="term">LOGFILE</span></dt><dd><p>This parameter tells the /sbin/shorewall program where to look
|
||||
for Shorewall messages when processing the “<span class="quote">show log</span>”,
|
||||
“<span class="quote">monitor</span>”, “<span class="quote">status</span>” and “<span class="quote">hits</span>”
|
||||
commands. If not assigned or if assigned an empty value,
|
||||
/var/log/messages is assumed.</p></dd><dt><span class="term">IP_FORWARDING</span></dt><dd><p>This parameter determines whether Shorewall enables or
|
||||
disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward).
|
||||
Possible values are:</p><div class="variablelist"><dl><dt><span class="term">On or on</span></dt><dd><p>packet forwarding will be enabled.</p></dd><dt><span class="term">Off or off</span></dt><dd><p>packet forwarding will be disabled.</p></dd><dt><span class="term">Keep or keep</span></dt><dd><p>Shorewall will neither enable nor disable packet
|
||||
forwarding.</p></dd></dl></div><p>If this variable is not set or is given an empty value
|
||||
(IP_FORWARD="") then IP_FORWARD=On is assumed.</p></dd><dt><span class="term">ADD_IP_ALIASES</span></dt><dd><p>This parameter determines whether Shorewall automatically adds
|
||||
the <span class="emphasis"><em>external</em></span> address(es) in <a href="#NAT">/etc/shorewall/nat</a>.
|
||||
If the variable is set to “<span class="quote">Yes</span>” or “<span class="quote">yes</span>”
|
||||
then Shorewall automatically adds these aliases. If it is set to
|
||||
“<span class="quote">No</span>” or “<span class="quote">no</span>”, you must add these aliases
|
||||
yourself using your distribution's network configuration tools.</p><p>If this variable is not set or is given an empty value
|
||||
(ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.</p></dd><dt><span class="term">ADD_SNAT_ALIASES</span></dt><dd><p>This parameter determines whether Shorewall automatically adds
|
||||
the SNAT <span class="emphasis"><em>ADDRESS</em></span> in <a href="#Masq">/etc/shorewall/masq</a>. If
|
||||
the variable is set to “<span class="quote">Yes</span>” or “<span class="quote">yes</span>” then
|
||||
Shorewall automatically adds these addresses. If it is set to
|
||||
“<span class="quote">No</span>” or “<span class="quote">no</span>”, you must add these addresses
|
||||
yourself using your distribution's network configuration tools.</p><p>If this variable is not set or is given an empty value
|
||||
(ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.</p></dd><dt><span class="term">LOGUNCLEAN</span></dt><dd><p>This parameter determines the logging level of mangled/invalid
|
||||
packets controlled by the “<span class="quote">dropunclean and logunclean</span>”
|
||||
interface options. If LOGUNCLEAN is empty (LOGUNCLEAN=) then packets
|
||||
selected by “<span class="quote">dropclean</span>” are dropped silently (“<span class="quote">logunclean</span>”
|
||||
packets are logged under the “<span class="quote">info</span>” log level).
|
||||
Otherwise, these packets are logged at the specified level (Example:
|
||||
LOGUNCLEAN=debug).</p></dd><dt><span class="term">BLACKLIST_DISPOSITION</span></dt><dd><p>This parameter determines the disposition of packets from
|
||||
blacklisted hosts. It may have the value DROP if the packets are to
|
||||
be dropped or REJECT if the packets are to be replied with an ICMP
|
||||
port unreachable reply or a TCP RST (tcp only). If you do not assign
|
||||
a value or if you assign an empty value then DROP is assumed.</p></dd><dt><span class="term">BLACKLIST_LOGLEVEL</span></dt><dd><p>This paremter determines if packets from blacklisted hosts are
|
||||
logged and it determines the syslog level that they are to be logged
|
||||
at. Its value is a <a href="shorewall_logging.html" target="_self">syslog level</a>
|
||||
(Example: BLACKLIST_LOGLEVEL=debug). If you do not assign a value or
|
||||
if you assign an empty value then packets from blacklisted hosts are
|
||||
not logged.</p></dd><dt><span class="term">CLAMPMSS</span></dt><dd><p>This parameter enables the TCP Clamp MSS to PMTU feature of
|
||||
Netfilter and is usually required when your internet connection is
|
||||
through PPPoE or PPTP. If set to “<span class="quote">Yes</span>” or
|
||||
“<span class="quote">yes</span>”, the feature is enabled. If left blank or set to
|
||||
“<span class="quote">No</span>” or “<span class="quote">no</span>”, the feature is not enabled.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This option requires CONFIG_IP_NF_TARGET_TCPMSS <a href="kernel.htm" target="_self">in your kernel</a>.</p></div></dd><dt><span class="term">ROUTE_FILTER</span></dt><dd><p>If this parameter is given the value “<span class="quote">Yes</span>” or
|
||||
“<span class="quote">yes</span>” then route filtering (anti-spoofing) is enabled
|
||||
on all network interfaces which are brought up while Shorewall is in
|
||||
the started state. The default value is “<span class="quote">no</span>”.</p></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="modules"></a>/etc/shorewall/modules Configuration</h2></div></div><div></div></div><p>The file <tt class="filename">/etc/shorewall/modules</tt> contains
|
||||
commands for loading the kernel modules required by Shorewall-defined
|
||||
firewall rules. Shorewall will source this file during start/restart
|
||||
provided that it exists and that the directory specified by the MODULESDIR
|
||||
parameter exists (see <a href="#Conf">/etc/shorewall/shorewall.conf</a> above).</p><p>The file that is released with Shorewall calls the Shorewall
|
||||
function “<span class="quote">loadmodule</span>” for the set of modules that I load.</p><p>The <span class="emphasis"><em>loadmodule</em></span> function is called as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">loadmodule <<span class="emphasis"><em>modulename</em></span>> [ <<span class="emphasis"><em>module parameters</em></span>> ]</pre></td></tr></table><p>where</p><div class="variablelist"><dl><dt><span class="term"><<span class="emphasis"><em>modulename</em></span>></span></dt><dd><p>is the name of the modules without the trailing
|
||||
“<span class="quote">.o</span>” (example ip_conntrack).</p></dd><dt><span class="term"><<span class="emphasis"><em>module parameters</em></span>></span></dt><dd><p>Optional parameters to the insmod utility.</p></dd></dl></div><p>The function determines if the module named by <<span class="emphasis"><em>modulename</em></span>>
|
||||
is already loaded and if not then the function determines if the
|
||||
“<span class="quote">.o</span>” file corresponding to the module exists in the
|
||||
<span class="emphasis"><em><moduledirectory></em></span>; if so, then the following
|
||||
command is executed:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">insmod <span class="emphasis"><em><moduledirectory</em></span>>/<<span class="emphasis"><em>modulename</em></span>>.o <<span class="emphasis"><em>module parameters</em></span>></pre></td></tr></table><p>If the file doesn't exist, the function determines of the
|
||||
“<span class="quote">.o.gz</span>” file corresponding to the module exists in the
|
||||
<span class="emphasis"><em>moduledirectory</em></span>. If it does, the function assumes
|
||||
that the running configuration supports compressed modules and execute the
|
||||
following command:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">insmod <span class="emphasis"><em><moduledirectory</em></span>>/<<span class="emphasis"><em>modulename</em></span>>.o.gz <<span class="emphasis"><em>module parameters</em></span>></pre></td></tr></table><p>Beginning with the 1.4.9 Shorewall release, the value of the
|
||||
MODULE_SUFFIX option in determines which files the loadmodule function
|
||||
looks for if the named module doesn't exist. For each file
|
||||
<span class="emphasis"><em><extension></em></span> listed in MODULE_SUFFIX (default
|
||||
"o gz ko o.gz"), the function will append a period (".")
|
||||
and the extension and if the resulting file exists then the following
|
||||
command will be executed:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">insmod <span class="emphasis"><em>moduledirectory</em></span>/<<span class="emphasis"><em>modulename</em></span>>.<span class="emphasis"><em><extension></em></span> <<span class="emphasis"><em>module parameters</em></span>></pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="TOS"></a>/etc/shorewall/tos Configuration</h2></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/tos</tt> file allows you to set
|
||||
the Type of Service field in packet headers based on packet source, packet
|
||||
destination, protocol, source port and destination port. In order for this
|
||||
file to be processed by Shorewall, you must have mangle support enabled.</p><p>Entries in the file have the following columns:</p><div class="variablelist"><dl><dt><span class="term">SOURCE</span></dt><dd><p>The source zone. May be qualified by following the zone name
|
||||
with a colon (“<span class="quote">:</span>”) and either an IP address, an IP
|
||||
subnet, a MAC address <a href="configuration_file_basics.htm#MAC" target="_self">in
|
||||
Shorewall Format</a> or the name of an interface. This column
|
||||
may also contain the name of the firewall zone to indicate packets
|
||||
originating on the firewall itself or “<span class="quote">all</span>” to indicate
|
||||
any source.</p></dd><dt><span class="term">DEST</span></dt><dd><p>The destination zone. May be qualified by following the zone
|
||||
name with a colon (“<span class="quote">:</span>”) and either an IP address or an
|
||||
IP subnet. Because packets are marked prior to routing, you may not
|
||||
specify the name of an interface. This column may also contain
|
||||
“<span class="quote">all</span>” to indicate any destination.</p></dd><dt><span class="term">PROTOCOL</span></dt><dd><p>The name of a protocol in <tt class="filename">/etc/protocols </tt>or
|
||||
the protocol's number.</p></dd><dt><span class="term">SOURCE PORT(S)</span></dt><dd><p>The source port or a port range. For all ports, place a hyphen
|
||||
(“<span class="quote">-</span>”) in this column.</p></dd><dt><span class="term">DEST PORT(S)</span></dt><dd><p>The destination port or a port range. To indicate all ports,
|
||||
place a hyphen (“<span class="quote">-</span>”) in this column.</p></dd><dt><span class="term">TOS</span></dt><dd><p>The type of service. Must be one of the following:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Minimize-Delay (16)</td></tr><tr><td>Maximize-Throughput (8)</td></tr><tr><td>Maximize-Reliability (4)</td></tr><tr><td>Minimize-Cost (2)</td></tr><tr><td>Normal-Service (0)</td></tr></table></dd></dl></div><p><tt class="filename">/etc/shorewall/tos</tt> file that is included with
|
||||
Shorewall</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST PROTOCOL SOURCE PORTS(S) DEST PORTS(S) TOS
|
||||
all all tcp - ssh 16
|
||||
all all tcp ssh - 16
|
||||
all all tcp - ftp 16
|
||||
all all tcp ftp - 16
|
||||
all all tcp - ftp-data 8
|
||||
all all tcp ftp-data - 8</pre></td></tr></table><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Users have reported that odd routing problems result from adding
|
||||
the ESP and AH protocols to the <tt class="filename">/etc/shorewall/tos</tt>
|
||||
file.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Blacklist"></a>/etc/shorewall/blacklist</h2></div></div><div></div></div><p>Each line in <tt class="filename">/etc/shorewall/blacklist</tt> contains
|
||||
an IP address, a MAC address in Shorewall Format or subnet address.</p><div class="example"><a id="id2880054"></a><p class="title"><b>Example 27. </b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">130.252.100.69
|
||||
206.124.146.0/24</pre></td></tr></table></div><p>Packets <span class="bold"><b>from</b></span> hosts listed in the
|
||||
blacklist file will be disposed of according to the value assigned to the
|
||||
<a href="#Conf" title="/etc/shorewall/shorewall.conf">BLACKLIST_DISPOSITION</a> and <a href="#Conf" title="/etc/shorewall/shorewall.conf">BLACKLIST_LOGLEVEL</a>
|
||||
variables in /etc/shorewall/shorewall.conf. Only packets arriving on
|
||||
interfaces that have the “<span class="quote"><a href="#Interfaces" title="/etc/shorewall/interfaces">blacklist</a></span>”
|
||||
option in <tt class="filename">/etc/shorewall/interfaces</tt> are checked
|
||||
against the blacklist. The black list is designed to prevent listed
|
||||
hosts/subnets from accessing services on <span class="bold"><b>your</b></span>
|
||||
network.</p><p>Beginning with Shorewall 1.3.8, the blacklist file has three
|
||||
columns:</p><div class="variablelist"><dl><dt><span class="term">ADDRESS/SUBNET</span></dt><dd><p>As described above.</p></dd><dt><span class="term">PROTOCOL</span></dt><dd><p>Optional. If specified, only packets specifying this protocol
|
||||
will be blocked.</p></dd><dt><span class="term">PORTS</span></dt><dd><p>Optional; may only be given if PROTOCOL is tcp, udp or icmp.
|
||||
Expressed as a comma-separated list of port numbers or service names
|
||||
(from /etc/services). If present, only packets destined for the
|
||||
specified protocol and one of the listed ports are blocked. When the
|
||||
PROTOCOL is icmp, the PORTS column contains a comma-separated list
|
||||
of ICMP type numbers or names (see “<span class="quote">iptables -h icmp</span>”).</p></dd></dl></div><p>Shorewall also has a <a href="blacklisting_support.htm" target="_self">dynamic
|
||||
blacklist capability</a>.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>The Shorewall blacklist file is <span class="bold"><b>NOT</b></span>
|
||||
designed to police your users' web browsing -- to do that, I suggest
|
||||
that you install and configure <a href="http://www.squid-cache.org" target="_self">Squid</a>
|
||||
with <a href="http://www.squidguard.org/" target="_self">SquidGuard</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="rfc1918"></a>/etc/shorewall/rfc1918 (Added in Version 1.3.1)</h2></div></div><div></div></div><p>This file lists the subnets affected by the <a href="#Interfaces" title="/etc/shorewall/interfaces">norfc1918 interface option</a>. Columns in the
|
||||
file are:</p><div class="variablelist"><dl><dt><span class="term">SUBNET</span></dt><dd><p>The subnet using VLSM notation (e.g., 192.168.0.0/16).</p></dd><dt><span class="term">TARGET</span></dt><dd><p>What to do with packets to/from the SUBNET:</p><div class="variablelist"><dl><dt><span class="term">RETURN</span></dt><dd><p>Process the packet normally thru the rules and policies.</p></dd><dt><span class="term">DROP</span></dt><dd><p>Silently drop the packet.</p></dd><dt><span class="term">logdrop</span></dt><dd><p>Log then drop the packet -- see the <a href="#Conf" title="/etc/shorewall/shorewall.conf">RFC1918_LOG_LEVEL</a>
|
||||
parameter above.</p></dd></dl></div></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Routestopped"></a>/etc/shorewall/routestopped (Added in Version 1.3.4)</h2></div></div><div></div></div><p>This file defines the hosts that are accessible from the firewall
|
||||
when the firewall is stopped. Columns in the file are:</p><div class="variablelist"><dl><dt><span class="term">INTERFACE</span></dt><dd><p>The firewall interface through which the host(s) comminicate
|
||||
with the firewall.</p></dd><dt><span class="term">HOST(S) - (Optional)</span></dt><dd><p>A comma-separated list of IP/Subnet addresses. If not supplied
|
||||
or supplied as “<span class="quote">-</span>” then 0.0.0.0/0 is assumed.</p></dd></dl></div><div class="example"><a id="id2875076"></a><p class="title"><b>Example 28. When your firewall is stopped, you want firewall accessibility
|
||||
from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces
|
||||
through eth1 and your local hosts through eth2.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE HOST(S)
|
||||
eth2 192.168.1.0/24
|
||||
eth1 -</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Maclist"></a>/etc/shorewall/maclist (Added in Version 1.3.10)</h2></div></div><div></div></div><p>This file is described in the <a href="MAC_Validation.html" target="_self">MAC
|
||||
Validation Documentation</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ECN"></a>/etc/shorewall/ecn (Added in Version 1.4.0)</h2></div></div><div></div></div><p>This file is described in the <a href="ECN.html" target="_self">ECN Control
|
||||
Documentation</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Accounting"></a>/etc/shorewall/accounting</h2></div></div><div></div></div><p>This file is described in the <a href="Accounting.html" target="_self">Traffic
|
||||
Accounting Documentation</a>.</p></div><div class="appendix" lang="en" xml:lang="en"><h2 class="title" style="clear: both"><a id="id2875179"></a>A. Revision History</h2><div class="revhistory"><table border="0" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1.14</td><td align="left">2004-02-13</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
|
||||
a note about the order of rules.</td></tr><tr><td align="left">Revision 1.13</td><td align="left">2004-02-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Update
|
||||
for Shorewall 2.0.</td></tr><tr><td align="left">Revision 1.12</td><td align="left">2004-01-21</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
|
||||
masquerade destination list.</td></tr><tr><td align="left">Revision 1.12</td><td align="left">2004-01-18</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Correct
|
||||
typo.</td></tr><tr><td align="left">Revision 1.11</td><td align="left">2004-01-05</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Standards
|
||||
Compliance</td></tr><tr><td align="left">Revision 1.10</td><td align="left">2004-01-05</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Improved
|
||||
formatting of DNAT- and REDIRECT- for clarity</td></tr><tr><td align="left">Revision 1.9</td><td align="left">2003-12-25</td><td align="left">MN</td></tr><tr><td align="left" colspan="3">Initial
|
||||
Docbook Conversion Complete</td></tr></table></div></div></div></body></html>
|
||||
@ -221,7 +221,7 @@
|
||||
<term><link linkend="rfc1918">rfc1918</link></term>
|
||||
|
||||
<listitem>
|
||||
<para>a parameter file in <filename class="directory">/etc/shorewall</filename>
|
||||
<para>a parameter file in <filename class="directory">/usr/share/shorewall</filename>
|
||||
used to define the treatment of packets under the <link
|
||||
linkend="Interfaces">norfc1918 interface option</link>.</para>
|
||||
</listitem>
|
||||
@ -708,25 +708,12 @@ loc eth1 192.168.1.255,192.168.12.255</programlisting>
|
||||
purpose of the <filename>/etc/shorewall/hosts</filename> file.</para>
|
||||
|
||||
<warning>
|
||||
<para>The only times that you need entries in <filename>/etc/shorewall/hosts</filename>
|
||||
are:</para>
|
||||
<para>The only time that you need entries in <filename>/etc/shorewall/hosts</filename>
|
||||
is where you have <ulink url="Multiple_Zones.html">more than one zone
|
||||
connecting through a single interface</ulink>.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>You have <ulink url="Multiple_Zones.html">more than one zone
|
||||
connecting through a single interface</ulink>; or</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>You have a <ulink url="Shorewall_and_Aliased_Interfaces.html">zone
|
||||
that has multiple subnetworks that connect through a single
|
||||
interface</ulink> and you want the Shorewall box to route traffic
|
||||
between those subnetworks.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para><emphasis role="bold">IF YOU DON'T HAVE EITHER OF THOSE
|
||||
SITUATIONS THEN DON'T TOUCH THIS FILE!!</emphasis></para>
|
||||
<para><emphasis role="bold">IF YOU DON'T HAVE THIS SITUATION THEN
|
||||
DON'T TOUCH THIS FILE!!</emphasis></para>
|
||||
</warning>
|
||||
|
||||
<para>Columns in this file are:</para>
|
||||
@ -2863,7 +2850,8 @@ all all tcp ftp-data - 8</programlisting
|
||||
</section>
|
||||
|
||||
<section id="rfc1918" xreflabel="/etc/shorewall/rfc1918">
|
||||
<title>/etc/shorewall/rfc1918 (Added in Version 1.3.1)</title>
|
||||
<title>/etc/shorewall/rfc1918 — Moved to /usr/share/shorewall in Version
|
||||
2.0.0</title>
|
||||
|
||||
<para>This file lists the subnets affected by the <link
|
||||
linkend="Interfaces">norfc1918 interface option</link>. Columns in the
|
||||
@ -2913,6 +2901,10 @@ all all tcp ftp-data - 8</programlisting
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>If you want to modify this file, DO NOT MODIFY <filename>/usr/share/shorewall/rfc1918</filename>.
|
||||
Rather copy that file to <filename>/etc/shorewall/rfc1918 </filename>and
|
||||
modify the copy.</para>
|
||||
</section>
|
||||
|
||||
<section id="Routestopped" xreflabel="/etc/shorewall/routestopped">
|
||||
@ -2976,7 +2968,8 @@ eth1 -</programlisting>
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.14</revnumber><date>2004-02-13</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
<para><revhistory><revision><revnumber>1.15</revnumber><date>2004-02-16</date><authorinitials>TE</authorinitials><revremark>Move
|
||||
the rfc1918 file to /usr/share/shorewall.</revremark></revision><revision><revnumber>1.14</revnumber><date>2004-02-13</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
a note about the order of rules.</revremark></revision><revision><revnumber>1.13</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Update
|
||||
for Shorewall 2.0.</revremark></revision><revision><revnumber>1.12</revnumber><date>2004-01-21</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
masquerade destination list.</revremark></revision><revision><revnumber>1.12</revnumber><date>2004-01-18</date><authorinitials>TE</authorinitials><revremark>Correct
|
||||
|
||||
@ -1,640 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shorewall FAQs</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="id2590562"></a>Shorewall FAQs</h1></div><div><div class="authorgroup"><h3 class="corpauthor">Shorewall Community</h3><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>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
|
||||
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-03</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807299">Installing Shorewall</a></span></dt><dd><dl><dt><span class="section"><a href="#id2807598">Where do I find Step by Step Installation and Configuration
|
||||
Instructions?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2807623">Port Forwarding</a></span></dt><dd><dl><dt><span class="section"><a href="#faq1">(FAQ 1) I want to forward UDP port 7777 to my my personal PC with
|
||||
IP address 192.168.1.5. I've looked everywhere and can't find
|
||||
how to do it.</a></span></dt><dd><dl><dt><span class="section"><a href="#faq1a">(FAQ 1a) Ok -- I followed those instructions but it doesn't
|
||||
work</a></span></dt><dt><span class="section"><a href="#faq1b">(FAQ 1b) I'm still having problems with port forwarding</a></span></dt><dt><span class="section"><a href="#faq1c">(FAQ 1c) From the internet, I want to connect to port 1022 on
|
||||
my firewall and have the firewall forward the connection to port 22 on
|
||||
local system 192.168.1.3. How do I do that?</a></span></dt></dl></dd><dt><span class="section"><a href="#faq30">(FAQ 30) I'm confused about when to use DNAT rules and when
|
||||
to use ACCEPT rules.</a></span></dt></dl></dd><dt><span class="section"><a href="#id2859491">DNS and Port Forwarding/NAT</a></span></dt><dd><dl><dt><span class="section"><a href="#faq2">(FAQ 2) I port forward www requests to www.mydomain.com (IP
|
||||
130.151.100.69) to system 192.168.1.5 in my local network. External
|
||||
clients can browse http://www.mydomain.com but internal clients
|
||||
can't.</a></span></dt><dd><dl><dt><span class="section"><a href="#faq2a">(FAQ 2a) I have a zone Z with an RFC1918 subnet
|
||||
and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in
|
||||
Z. Hosts in Z cannot communicate with each other using their external
|
||||
(non-RFC1918 addresses) so they can't access each other using
|
||||
their DNS names.</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="#id2859698">Netmeeting/MSN</a></span></dt><dd><dl><dt><span class="section"><a href="#faq3">(FAQ 3) I want to use Netmeeting or MSN Instant Messenger with
|
||||
Shorewall. What do I do?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2859801">Open Ports</a></span></dt><dd><dl><dt><span class="section"><a href="#faq4">(FAQ 4) I just used an online port scanner to check my firewall
|
||||
and it shows some ports as closed rather than
|
||||
blocked. Why?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq4a">(FAQ 4a) I just ran an nmap UDP scan of my firewall and it
|
||||
showed 100s of ports as open!!!!</a></span></dt><dt><span class="section"><a href="#faq4b">(FAQ 4b) I have a port that I can't close no matter how I
|
||||
change my rules.</a></span></dt><dt><span class="section"><a href="#faq4c">(FAQ 4c) How to I use Shorewall with PortSentry?</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="#id2806601">Connection Problems</a></span></dt><dd><dl><dt><span class="section"><a href="#faq5">(FAQ 5) I've installed Shorewall and now I can't ping
|
||||
through the firewall</a></span></dt><dt><span class="section"><a href="#faq15">(FAQ 15) My local systems can't see out to the net</a></span></dt><dt><span class="section"><a href="#faq29">(FAQ 29) FTP Doesn't Work</a></span></dt><dt><span class="section"><a href="#id2806829">(FAQ 33) From clients behind the firewall, connections to some
|
||||
sites fail. Connections to the same sites from the firewall itself work
|
||||
fine. What's wrong.</a></span></dt></dl></dd><dt><span class="section"><a href="#id2806863">Logging</a></span></dt><dd><dl><dt><span class="section"><a href="#faq6">(FAQ 6) Where are the log messages written and how do I change
|
||||
the destination?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq6a">(FAQ 6a) Are there any log parsers that work with Shorewall?</a></span></dt><dt><span class="section"><a href="#faq6b">(FAQ 2b) DROP messages on port 10619 are flooding the logs with
|
||||
their connect requests. Can i exclude these error messages for this
|
||||
port temporarily from logging in Shorewall?</a></span></dt><dt><span class="section"><a href="#faq6c">(FAQ 6c) All day long I get a steady flow of these DROP
|
||||
messages from port 53 to some high numbered port. They get dropped,
|
||||
but what the heck are they?</a></span></dt><dt><span class="section"><a href="#faq6d">(FAQ 6d) Why is the MAC address in Shorewall log messages so
|
||||
long? I thought MAC addresses were only 6 bytes in length.</a></span></dt></dl></dd><dt><span class="section"><a href="#faq16">(FAQ 16) Shorewall is writing log messages all over my console
|
||||
making it unusable!</a></span></dt><dt><span class="section"><a href="#faq17">(FAQ 17) What does this log message mean?</a></span></dt><dt><span class="section"><a href="#faq21">(FAQ 21) I see these strange log entries occasionally; what are
|
||||
they?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2875168">Routing</a></span></dt><dd><dl><dt><span class="section"><a href="#faq32">(FAQ 32) My firewall has two connections to the internet from two
|
||||
different ISPs. How do I set this up in Shorewall?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2875693">Starting and Stopping</a></span></dt><dd><dl><dt><span class="section"><a href="#faq7">(FAQ 7) When I stop Shorewall using shorewall stop,
|
||||
I can't connect to anything. Why doesn't that command work?</a></span></dt><dt><span class="section"><a href="#faq8">(FAQ 8) When I try to start Shorewall on RedHat, I get messages
|
||||
about insmod failing -- what's wrong?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq8a">(FAQ 8a) When I try to start Shorewall on RedHat I get a
|
||||
message referring me to FAQ #8</a></span></dt></dl></dd><dt><span class="section"><a href="#faq9">(FAQ 9) Why can't Shorewall detect my interfaces properly at
|
||||
startup?</a></span></dt><dt><span class="section"><a href="#faq22">(FAQ 22) I have some iptables commands that I want to run when
|
||||
Shorewall starts. Which file do I put them in?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2876004">About Shorewall</a></span></dt><dd><dl><dt><span class="section"><a href="#faq10">(FAQ 10) What Distributions does it work with?</a></span></dt><dt><span class="section"><a href="#faq11">(FAQ 11) What Features does it have?</a></span></dt><dt><span class="section"><a href="#faq12">(FAQ 12) Is there a GUI?</a></span></dt><dt><span class="section"><a href="#faq13">(FAQ 13) Why do you call it Shorewall?</a></span></dt><dt><span class="section"><a href="#faq23">(FAQ 23) Why do you use such ugly fonts on your web site?</a></span></dt><dt><span class="section"><a href="#faq25">(FAQ 25) How to I tell which version of Shorewall I am running?</a></span></dt><dt><span class="section"><a href="#faq31">(FAQ 31) Does Shorewall provide protection against....</a></span></dt><dt><span class="section"><a href="#id2865341">Given that the Debian Stable Release includes Shorewall 1.2.12,
|
||||
how can you not support that version?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2865362">RFC 1918</a></span></dt><dd><dl><dt><span class="section"><a href="#faq14">(FAQ 14) I'm connected via a cable modem and it has an
|
||||
internal web server that allows me to configure/monitor it but as
|
||||
expected if I enable rfc1918 blocking for my eth0 interface (the
|
||||
internet one), it also blocks the cable modems web server.</a></span></dt><dd><dl><dt><span class="section"><a href="#faq14a">(FAQ 14a) Even though it assigns public IP addresses, my
|
||||
ISP's DHCP server has an RFC 1918 address. If I enable RFC 1918
|
||||
filtering on my external interface, my DHCP client cannot renew its
|
||||
lease.</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="#id2865509">Alias IP Addresses/Virtual Interfaces</a></span></dt><dd><dl><dt><span class="section"><a href="#faq18">(FAQ 18) Is there any way to use aliased ip addresses with
|
||||
Shorewall, and maintain separate rulesets for different IPs?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2865549">Miscellaneous</a></span></dt><dd><dl><dt><span class="section"><a href="#faq19">(FAQ 19) I have added entries to /etc/shorewall/tcrules but they
|
||||
don't seem to do anything. Why?</a></span></dt><dt><span class="section"><a href="#faq20">(FAQ 20) I have just set up a server. Do I have to change
|
||||
Shorewall to allow access to my server from the internet?</a></span></dt><dt><span class="section"><a href="#faq24">(FAQ 24) How can I allow conections to let's say the ssh port
|
||||
only from specific IP Addresses on the internet?</a></span></dt><dt><span class="section"><a href="#faq26">(FAQ 26) When I try to use any of the SYN options in nmap on or
|
||||
behind the firewall, I get operation not permitted. How
|
||||
can I use nmap with Shorewall?"</a></span></dt><dd><dl><dt><span class="section"><a href="#faq26a">(FAQ 26a) When I try to use the -O option of
|
||||
nmap from the firewall system, I get operation not permitted.
|
||||
How do I allow this option?</a></span></dt></dl></dd><dt><span class="section"><a href="#faq27">(FAQ 27) I'm compiling a new kernel for my firewall. What
|
||||
should I look out for?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq27a">(FAQ 27a) I just built and installed a new kernel and now
|
||||
Shorewall won't start. I know that my kernel options are correct.</a></span></dt></dl></dd><dt><span class="section"><a href="#faq28">(FAQ 28) How do I use Shorewall as a Bridging Firewall?</a></span></dt></dl></dd><dt><span class="appendix"><a href="#id2865882">A. Revision History</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807299"></a>Installing Shorewall</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807598"></a>Where do I find Step by Step Installation and Configuration
|
||||
Instructions?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Check out the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart Guides</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807623"></a>Port Forwarding</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq1"></a>(FAQ 1) I want to forward UDP port 7777 to my my personal PC with
|
||||
IP address 192.168.1.5. I've looked everywhere and can't find
|
||||
how to do it.</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> The first example in the
|
||||
<a href="Documentation.htm#Rules" target="_self">rules file documentation</a>
|
||||
shows how to do port forwarding under Shorewall. The format of a
|
||||
port-forwarding rule to a local system is as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT
|
||||
DNAT net loc:<l<span class="emphasis"><em>ocal IP address</em></span>>[:<<span class="emphasis"><em>local port</em></span>>] <<span class="emphasis"><em>protocol</em></span>> <<span class="emphasis"><em>port #</em></span>></pre></td></tr></table><p>So to forward UDP port 7777 to internal system 192.168.1.5, the
|
||||
rule is:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT
|
||||
DNAT net loc:192.168.1.5 udp 7777</pre></td></tr></table><p>If you want to forward requests directed to a particular address (
|
||||
<span class="emphasis"><em><external IP></em></span> ) on your firewall to an
|
||||
internal system:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
|
||||
# PORT DEST.
|
||||
DNAT net loc:<l<span class="emphasis"><em>ocal IP address</em></span>>[:<<span class="emphasis"><em>local port</em></span>>] <<span class="emphasis"><em>protocol</em></span>> <<span class="emphasis"><em>port #</em></span>> - <<span class="emphasis"><em>external IP</em></span>></pre></td></tr></table><p>Finally, if you need to forward a range of ports, in the PORT
|
||||
column specify the range as <span class="emphasis"><em><low-port>:<high-port></em></span>.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq1a"></a>(FAQ 1a) Ok -- I followed those instructions but it doesn't
|
||||
work</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> That is usually the
|
||||
result of one of four things:</p><div class="itemizedlist"><ul type="disc"><li><p>You are trying to test from inside your firewall (no, that
|
||||
won't work -- see <a href="#faq2" title="(FAQ 2) I port forward www requests to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 in my local network. External clients can browse http://www.mydomain.com but internal clients can't.">the section called “(FAQ 2) I port forward www requests to www.mydomain.com (IP
|
||||
130.151.100.69) to system 192.168.1.5 in my local network. External
|
||||
clients can browse http://www.mydomain.com but internal clients
|
||||
can't.”</a>).</p></li><li><p>You have a more basic problem with your local system (the
|
||||
one that you are trying to forward to) such as an incorrect
|
||||
default gateway (it should be set to the IP address of your
|
||||
firewall's internal interface).</p></li><li><p>Your ISP is blocking that particular port inbound.</p></li><li><p>You are running Mandrake Linux and have configured Internet
|
||||
Connection Sharing. In that case, the name of your local zone is
|
||||
'masq' rather than 'loc' (change all instances of
|
||||
'loc' to 'masq' in your rules). You may want to
|
||||
consider re-installing Shorewall in a configuration which matches
|
||||
the Shorewall documentation. See the <a href="two-interface.htm" target="_self">two-interface QuickStart Guide</a> for
|
||||
details.</p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq1b"></a>(FAQ 1b) I'm still having problems with port forwarding</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> To further diagnose
|
||||
this problem:</p><div class="itemizedlist"><ul type="disc"><li><p>As root, type “<span class="quote"><span><b class="command">iptables -t nat -Z</b></span></span>”.
|
||||
This clears the NetFilter counters in the nat table.</p></li><li><p>Try to connect to the redirected port from an external host.</p></li><li><p>As root type “<span class="quote"><span><b class="command">shorewall show nat</b></span></span>”</p></li><li><p>Locate the appropriate DNAT rule. It will be in a chain
|
||||
called <span class="emphasis"><em><source zone></em></span>_dnat (“<span class="quote">net_dnat</span>”
|
||||
in the above examples).</p></li><li><p>Is the packet count in the first column non-zero? If so, the
|
||||
connection request is reaching the firewall and is being
|
||||
redirected to the server. In this case, the problem is usually a
|
||||
missing or incorrect default gateway setting on the local system
|
||||
(the system you are trying to forward to -- its default gateway
|
||||
should be the IP address of the firewall's interface to that
|
||||
system).</p></li><li><p>If the packet count is zero:</p><div class="itemizedlist"><ul type="circle"><li><p>the connection request is not reaching your server
|
||||
(possibly it is being blocked by your ISP); or</p></li><li><p>you are trying to connect to a secondary IP address on
|
||||
your firewall and your rule is only redirecting the primary IP
|
||||
address (You need to specify the secondary IP address in the
|
||||
“<span class="quote">ORIG. DEST.</span>” column in your DNAT rule); or</p></li><li><p>your DNAT rule doesn't match the connection request
|
||||
in some other way. In that case, you may have to use a packet
|
||||
sniffer such as tcpdump or ethereal to further diagnose the
|
||||
problem.</p></li></ul></div></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq1c"></a>(FAQ 1c) From the internet, I want to connect to port 1022 on
|
||||
my firewall and have the firewall forward the connection to port 22 on
|
||||
local system 192.168.1.3. How do I do that?</h4></div></div><div></div></div><p>In /<tt class="filename">etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT
|
||||
DNAT net loc:192.168.3:22 tcp 1022</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq30"></a>(FAQ 30) I'm confused about when to use DNAT rules and when
|
||||
to use ACCEPT rules.</h3></div></div><div></div></div><p>It would be a good idea to review the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart Guide</a>
|
||||
appropriate for your setup; the guides cover this topic in a tutorial
|
||||
fashion. DNAT rules should be used for connections that need to go the
|
||||
opposite direction from SNAT/MASQUERADE. So if you masquerade or use
|
||||
SNAT from your local network to the internet then you will need to use
|
||||
DNAT rules to allow connections from the internet to your local network.
|
||||
In all other cases, you use ACCEPT unless you need to hijack connections
|
||||
as they go through your firewall and handle them on the firewall box
|
||||
itself; in that case, you use a REDIRECT rule.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859491"></a>DNS and Port Forwarding/NAT</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq2"></a>(FAQ 2) I port forward www requests to www.mydomain.com (IP
|
||||
130.151.100.69) to system 192.168.1.5 in my local network. External
|
||||
clients can browse http://www.mydomain.com but internal clients
|
||||
can't.</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> I have two objections to
|
||||
this setup.</p><div class="itemizedlist"><ul type="disc"><li><p>Having an internet-accessible server in your local network is
|
||||
like raising foxes in the corner of your hen house. If the server is
|
||||
compromised, there's nothing between that server and your other
|
||||
internal systems. For the cost of another NIC and a cross-over
|
||||
cable, you can put your server in a DMZ such that it is isolated
|
||||
from your local systems - assuming that the Server can be located
|
||||
near the Firewall, of course :-)</p></li><li><p>The accessibility problem is best solved using <a href="shorewall_setup_guide.htm#DNS" target="_self">Bind Version 9 “<span class="quote">views</span>”</a>
|
||||
(or using a separate DNS server for local clients) such that
|
||||
www.mydomain.com resolves to 130.141.100.69 externally and
|
||||
192.168.1.5 internally. That's what I do here at shorewall.net
|
||||
for my local systems that use one-to-one NAT.</p></li></ul></div><p>If you insist on an IP solution to the accessibility problem
|
||||
rather than a DNS solution, then assuming that your external interface
|
||||
is eth0 and your internal interface is eth1 and that eth1 has IP address
|
||||
192.168.1.254 with subnet 192.168.1.0/24.</p><p>If you are running Shorewall 1.4.0 or earlier see the <a href="1.3/FAQ.htm#faq2" target="_self">1.3 FAQ</a> for instructions suitable for
|
||||
those releases.</p><p>If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please
|
||||
upgrade to Shorewall 1.4.2 or later.</p><p>Otherwise:</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>In this configuration, all loc->loc
|
||||
traffic will look to the server as if it came from the firewall rather
|
||||
than from the original client!</p></div><div class="itemizedlist"><ul type="disc"><li><p>In <tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
loc eth1 detect <span class="bold"><b>routeback</b></span></pre></td></tr></table></li><li><p>In <tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
|
||||
# PORT DEST.
|
||||
DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69:192.168.1.254</pre></td></tr></table><p>That rule only works of course if you have a static external
|
||||
IP address. If you have a dynamic IP address and are running
|
||||
Shorewall 1.3.4 or later then include this in <tt class="filename">/etc/shorewall/init</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">ETH0_IP=`find_interface_address eth0`</b></span></pre></td></tr></table><p>and make your DNAT rule:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
|
||||
# PORT DEST.
|
||||
DNAT loc loc:192.168.1.5 tcp www - $ETH0_IP:192.168.1.254</pre></td></tr></table><p>Using this technique, you will want to configure your
|
||||
DHCP/PPPoE client to automatically restart Shorewall each time that
|
||||
you get a new IP address.</p></li></ul></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq2a"></a>(FAQ 2a) I have a zone “<span class="quote">Z</span>” with an RFC1918 subnet
|
||||
and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in
|
||||
Z. Hosts in Z cannot communicate with each other using their external
|
||||
(non-RFC1918 addresses) so they can't access each other using
|
||||
their DNS names.</h4></div></div><div></div></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If the ALL INTERFACES column in /etc/shorewall/nat is empty or
|
||||
contains “<span class="quote">Yes</span>”, you will also see log messages like the
|
||||
following when trying to access a host in Z from another host in Z
|
||||
using the destination hosts's public address:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Oct 4 10:26:40 netgw kernel:
|
||||
Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200
|
||||
DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF
|
||||
PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0</pre></td></tr></table></div><p><span class="bold"><b>Answer:</b></span> This is another problem
|
||||
that is best solved using Bind Version 9 “<span class="quote">views</span>”. It
|
||||
allows both external and internal clients to access a NATed host using
|
||||
the host's DNS name.</p><p>Another good way to approach this problem is to switch from
|
||||
one-to-one NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918
|
||||
addresses and can be accessed externally and internally using the same
|
||||
address.</p><p>If you don't like those solutions and prefer routing all
|
||||
Z->Z traffic through your firewall then:</p><div class="orderedlist"><ol type="1"><li><p>Set the Z->Z policy to ACCEPT.</p></li><li><p>Masquerade Z to itself.</p></li><li><p>Set the routeback option on the interface to Z.</p></li><li><p>Set the ALL INTERFACES column in the nat file to
|
||||
“<span class="quote">Yes</span>”.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>In this configuration, all Z->Z traffic will look to
|
||||
the server as if it came from the firewall rather than from the
|
||||
original client! I DO NOT RECOMMEND THIS SETUP.</p></div></li></ol></div><div class="example"><a id="id2810035"></a><p class="title"><b>Example 1. Example:</b></p><div class="literallayout"><p>Zone: dmz Interface: eth2 Subnet: 192.168.2.0/24</p></div><p>In <tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
loc eth2 192.168.2.255 <span class="bold"><b>routeback</b></span></pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/policy</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY LIMIT:BURST
|
||||
dmz dmz ACCEPT</pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/masq</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth2 192.168.2.0/24</pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/na</tt>t, be sure that you
|
||||
have “<span class="quote">Yes</span>” in the ALL INTERFACES column.</p></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859698"></a>Netmeeting/MSN</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq3"></a>(FAQ 3) I want to use Netmeeting or MSN Instant Messenger with
|
||||
Shorewall. What do I do?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> There is an <a href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/" target="_self">H.323
|
||||
connection tracking/NAT module</a> that helps with Netmeeting. Note
|
||||
however that one of the Netfilter developers recently posted the
|
||||
following:</p><div class="blockquote"><blockquote class="blockquote"><p>> I know PoM -ng is going to address this issue, but till it
|
||||
is ready, and > all the extras are ported to it, is there any way
|
||||
to use the h.323 > contrack module kernel patch with a 2.6 kernel?
|
||||
> Running 2.6.1 - no 2.4 kernel stuff on the system, so downgrade
|
||||
is not > an option... The module is not ported yet to 2.6, sorry.
|
||||
> Do I have any options besides a gatekeeper app (does not work in
|
||||
my > network) or a proxy (would prefer to avoid them)? I suggest
|
||||
everyone to setup a proxy (gatekeeper) instead: the module is really
|
||||
dumb and does not deserve to exist at all. It was an excellent tool to
|
||||
debug/develop the newnat interface.</p></blockquote></div><p>Look <a href="http://linux-igd.sourceforge.net" target="_self">here</a>
|
||||
for a solution for MSN IM but be aware that there are significant
|
||||
security risks involved with this solution. Also check the Netfilter
|
||||
mailing list archives at <a href="http://www.netfilter.org" target="_self">http://www.netfilter.org</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859801"></a>Open Ports</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq4"></a>(FAQ 4) I just used an online port scanner to check my firewall
|
||||
and it shows some ports as “<span class="quote">closed</span>” rather than
|
||||
“<span class="quote">blocked</span>”. Why?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> (Shorewall versions prior
|
||||
to 2.0.0 only). The common.def included with version 1.3.x always
|
||||
rejects connection requests on TCP port 113 rather than dropping them.
|
||||
This is necessary to prevent outgoing connection problems to services
|
||||
that use the “<span class="quote">Auth</span>” mechanism for identifying requesting
|
||||
users. Shorewall also rejects TCP ports 135, 137, 139 and 445 as well as
|
||||
UDP ports 137-139. These are ports that are used by Windows (Windows
|
||||
<span class="emphasis"><em>can</em></span> be configured to use the DCE cell locator on
|
||||
port 135). Rejecting these connection requests rather than dropping them
|
||||
cuts down slightly on the amount of Windows chatter on LAN segments
|
||||
connected to the Firewall.</p><p>If you are seeing port 80 being “<span class="quote">closed</span>”, that's
|
||||
probably your ISP preventing you from running a web server in violation
|
||||
of your Service Agreement.</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>You can change the default behavior of Shorewall through use of
|
||||
an /etc/shorewall/common file. See the <a href="shorewall_extension_scripts.htm" target="_self">Extension Script Section</a>.</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Beginning with Shorewall 1.4.9, Shorewall no longer rejects the
|
||||
Windows SMB ports (135-139 and 445) by default and silently drops them
|
||||
instead.</p></div><p><span class="bold"><b>Answer:</b></span> (Shorewall versions 2.0.0
|
||||
and later). The default Shorewall setup invokes the <span class="bold"><b>Drop</b></span> action prior to enforcing a DROP policy and
|
||||
the default policy to all zone from the internet is DROP. The Drop
|
||||
action is defined in <tt class="filename">/etc/shorewall/action.Drop</tt>
|
||||
which in turn invokes the <span class="bold"><b>RejectAuth</b></span>
|
||||
action (defined in <tt class="filename">/etc/shorewall/action.RejectAuth</tt>).
|
||||
This is necessary to prevent outgoing connection problems to services
|
||||
that use the “<span class="quote">Auth</span>” mechanism for identifying requesting
|
||||
users. That is the only service which the default setup rejects.</p><p>If you are seeing closed TCP ports other than 113 (auth) then
|
||||
either you have added rules to REJECT those ports or a router outside of
|
||||
your firewall is responding to connection requests on those ports.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq4a"></a>(FAQ 4a) I just ran an nmap UDP scan of my firewall and it
|
||||
showed 100s of ports as open!!!!</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Take a deep breath and
|
||||
read the nmap man page section about UDP scans. If nmap gets <span class="bold"><b>nothing</b></span> back from your firewall then it reports
|
||||
the port as open. If you want to see which UDP ports are really open,
|
||||
temporarily change your net->all policy to REJECT, restart
|
||||
Shorewall and do the nmap UDP scan again.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq4b"></a>(FAQ 4b) I have a port that I can't close no matter how I
|
||||
change my rules.</h4></div></div><div></div></div><p>I had a rule that allowed telnet from my local network to my
|
||||
firewall; I removed that rule and restarted Shorewall but my telnet
|
||||
session still works!!!</p><p><span class="bold"><b>Answer:</b></span> Rules only govern the
|
||||
establishment of new connections. Once a connection is established
|
||||
through the firewall it will be usable until disconnected (tcp) or
|
||||
until it times out (other protocols). If you stop telnet and try to
|
||||
establish a new session your firerwall will block that attempt.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq4c"></a>(FAQ 4c) How to I use Shorewall with PortSentry?</h4></div></div><div></div></div><p><a href="http://www.shorewall.net/pub/shorewall/contrib/PortsentryHOWTO.txt" target="_self">Here's
|
||||
a writeup</a> on a nice integration of Shorewall and PortSentry.</p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806601"></a>Connection Problems</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq5"></a>(FAQ 5) I've installed Shorewall and now I can't ping
|
||||
through the firewall</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> If you want your firewall
|
||||
to be totally open for “<span class="quote">ping</span>”,</p><div class="orderedlist"><ol type="1"><li><p>Create <tt class="filename">/etc/shorewall/common</tt> if it
|
||||
doesn't already exist.</p></li><li><p>Be sure that the first command in the file is “<span class="quote">.
|
||||
<tt class="filename">/etc/shorewall/common.de</tt>f</span>”</p></li><li><p>Add the following to <tt class="filename">/etc/shorewall/common</tt></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -A icmpdef -p ICMP --icmp-type echo-request -j ACCEPT</b></span></pre></td></tr></table></li></ol></div><p>For a complete description of Shorewall “<span class="quote">ping</span>”
|
||||
management, see <a href="ping.html" target="_self">this page</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq15"></a>(FAQ 15) My local systems can't see out to the net</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Every time I read
|
||||
“<span class="quote">systems can't see out to the net</span>”, I wonder where the
|
||||
poster bought computers with eyes and what those computers will
|
||||
“<span class="quote">see</span>” when things are working properly. That aside, the
|
||||
most common causes of this problem are:</p><div class="orderedlist"><ol type="1"><li><p>The default gateway on each local system isn't set to the
|
||||
IP address of the local firewall interface.</p></li><li><p>The entry for the local network in the /etc/shorewall/masq
|
||||
file is wrong or missing.</p></li><li><p>The DNS settings on the local systems are wrong or the user is
|
||||
running a DNS server on the firewall and hasn't enabled UDP and
|
||||
TCP port 53 from the firewall to the internet.</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq29"></a>(FAQ 29) FTP Doesn't Work</h3></div></div><div></div></div><p>See the <a href="FTP.html" target="_self">Shorewall and FTP page</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2806829"></a>(FAQ 33) From clients behind the firewall, connections to some
|
||||
sites fail. Connections to the same sites from the firewall itself work
|
||||
fine. What's wrong.</h3></div></div><div></div></div><p><span class="bold"><b>Answer</b></span>: Most likely, you need to
|
||||
set CLAMPMSS=Yes in <a href="Documentation.htm#Conf" target="_self">/etc/shorewall/shorewall.conf</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806863"></a>Logging</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq6"></a>(FAQ 6) Where are the log messages written and how do I change
|
||||
the destination?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> NetFilter uses the
|
||||
kernel's equivalent of syslog (see “<span class="quote">man syslog</span>”) to log
|
||||
messages. It always uses the LOG_KERN (kern) facility (see
|
||||
“<span class="quote">man openlog</span>”) and you get to choose the log level (again,
|
||||
see “<span class="quote">man syslog</span>”) in your <a href="Documentation.htm#Policy" target="_self">policies</a> and <a href="Documentation.htm#Rules" target="_self">rules</a>. The destination for
|
||||
messaged logged by syslog is controlled by <tt class="filename">/etc/syslog.conf</tt>
|
||||
(see “<span class="quote">man syslog.conf</span>”). When you have changed
|
||||
/etc/syslog.conf, be sure to restart syslogd (on a RedHat system,
|
||||
“<span class="quote">service syslog restart</span>”).</p><p>By default, older versions of Shorewall ratelimited log messages
|
||||
through <a href="Documentation.htm#Conf" target="_self">settings</a> in
|
||||
<tt class="filename">/etc/shorewall/shorewall.conf</tt> -- If you want to log
|
||||
all messages, set:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGLIMIT=""
|
||||
LOGBURST=""</pre></td></tr></table><p>Beginning with Shorewall version 1.3.12, you can <a href="shorewall_logging.html" target="_self">set up Shorewall to log all of its messages
|
||||
to a separate file</a>.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6a"></a>(FAQ 6a) Are there any log parsers that work with Shorewall?</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Here are several links
|
||||
that may be helpful:</p><div class="literallayout"><p><a href="http://www.shorewall.net/pub/shorewall/parsefw/" target="_self">http://www.shorewall.net/pub/shorewall/parsefw/</a><br />
|
||||
<a href="http://www.fireparse.com" target="_self">http://www.fireparse.com</a><br />
|
||||
<a href="http://cert.uni-stuttgart.de/projects/fwlogwatch" target="_self">http://cert.uni-stuttgart.de/projects/fwlogwatch</a><br />
|
||||
<a href="http://www.logwatch.org" target="_self">http://www.logwatch.org</a><br />
|
||||
<a href="http://gege.org/iptables" target="_self">http://gege.org/iptables</a><br />
|
||||
<a href="http://home.regit.org/ulogd-php.html" target="_self">http://home.regit.org/ulogd-php.html</a></p></div><p>I personnaly use Logwatch. It emails me a report each day from
|
||||
my various systems with each report summarizing the logged activity on
|
||||
the corresponding system.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6b"></a>(FAQ 2b) DROP messages on port 10619 are flooding the logs with
|
||||
their connect requests. Can i exclude these error messages for this
|
||||
port temporarily from logging in Shorewall?</h4></div></div><div></div></div><p>Temporarily add the following rule:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">DROP net fw udp 10619</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6c"></a>(FAQ 6c) All day long I get a steady flow of these DROP
|
||||
messages from port 53 to some high numbered port. They get dropped,
|
||||
but what the heck are they?</h4></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Jan 8 15:50:48 norcomix kernel:
|
||||
Shorewall:net2all:DROP:IN=eth0 OUT=
|
||||
MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00 SRC=208.138.130.16
|
||||
DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00 TTL=251 ID=8288 DF
|
||||
PROTO=UDP SPT=53 DPT=40275 LEN=33</pre></td></tr></table><p><span class="bold"><b>Answer:</b></span> There are two
|
||||
possibilities:</p><div class="orderedlist"><ol type="1"><li><p>They are late-arriving replies to DNS queries.</p></li><li><p>They are corrupted reply packets.</p></li></ol></div><p>You can distinguish the difference by setting the <span class="bold"><b>logunclean</b></span> option (<tt class="filename"><a href="Documentation.htm#Interfaces" target="_self">/etc/shorewall/interfaces</a></tt>)
|
||||
on your external interface (eth0 in the above example). If they get
|
||||
logged twice, they are corrupted. I solve this problem by using an
|
||||
/etc/shorewall/common file like this:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#
|
||||
# Include the standard common.def file
|
||||
#
|
||||
<span><b class="command">. /etc/shorewall/common.def</b></span>
|
||||
#
|
||||
# The following rule is non-standard and compensates for tardy
|
||||
# DNS replies
|
||||
#
|
||||
<span><b class="command">run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP</b></span></pre></td></tr></table><p>The above file is also include in all of my sample
|
||||
configurations available in the <a href="shorewall_quickstart_guide.htm" target="_self">Quick Start Guides</a> and in
|
||||
the common.def file in Shorewall 1.4.0 and later.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6d"></a>(FAQ 6d) Why is the MAC address in Shorewall log messages so
|
||||
long? I thought MAC addresses were only 6 bytes in length.</h4></div></div><div></div></div><p>What is labeled as the MAC address in a Shorewall log message is
|
||||
actually the Ethernet frame header. It contains:</p><div class="itemizedlist"><ul type="disc"><li><p>the destination MAC address (6 bytes)</p></li><li><p>the source MAC address (6 bytes)</p></li><li><p>the ethernet frame type (2 bytes)</p></li></ul></div><div class="example"><a id="id2806108"></a><p class="title"><b>Example 2. Example</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00</pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Destination
|
||||
MAC address = 00:04:4c:dc:e2:28</p></li><li><p>Source
|
||||
MAC address = 00:b0:8e:cf:3c:4c</p></li><li><p>Ethernet
|
||||
Frame Type = 08:00 (IP Version 4)</p></li></ul></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq16"></a>(FAQ 16) Shorewall is writing log messages all over my console
|
||||
making it unusable!</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> If you are running
|
||||
Shorewall version 1.4.4 or 1.4.4a then check the <a href="errata.htm" target="_self">errata</a>.
|
||||
Otherwise:</p><div class="itemizedlist"><ul type="disc"><li><p>Find where klogd is being started (it will be from one of the
|
||||
files in /etc/init.d -- sysklogd, klogd, ...). Modify that file or
|
||||
the appropriate configuration file so that klogd is started with
|
||||
“<span class="quote">-c <span class="emphasis"><em><n></em></span></span>” where
|
||||
<span class="emphasis"><em><n></em></span> is a log level of 5 or less; or</p></li><li><p>See the “<span class="quote">dmesg</span>” man page (“<span class="quote">man dmesg</span>”).
|
||||
You must add a suitable “<span class="quote">dmesg</span>” command to your startup
|
||||
scripts or place it in /etc/shorewall/start.</p></li></ul></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Under RedHat and Mandrake, the max <a href="shorewall_logging.html" target="_self">log level</a> that is sent to the
|
||||
console is specified in /etc/sysconfig/init in the LOGLEVEL variable.
|
||||
Set “<span class="quote">LOGLEVEL=5</span>” to suppress info (log level 6) messages
|
||||
on the console.</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Under Debian, you can set KLOGD=“<span class="quote">-c 5</span>” in
|
||||
<tt class="filename">/etc/init.d/klogd</tt> to suppress info (log level 6)
|
||||
messages on the console.</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Under SuSE, add “<span class="quote">-c 5</span>” to KLOGD_PARAMS in
|
||||
/etc/sysconfig/syslog to suppress info (log level 6) messages on the
|
||||
console.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq17"></a>(FAQ 17) What does this log message mean?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Logging occurs out of a
|
||||
number of chains (as indicated in the log message) in Shorewall:</p><div class="variablelist"><dl><dt><span class="term">man1918 or logdrop</span></dt><dd><p>The destination address is listed in <tt class="filename">/etc/shorewall/rfc1918</tt>
|
||||
with a <span class="bold"><b>logdrop</b></span> target -- see
|
||||
<tt class="filename"><a href="Documentation.htm#rfc1918" target="_self">/etc/shorewall/rfc1918</a></tt>.</p></dd><dt><span class="term">rfc1918 or logdrop</span></dt><dd><p>The source address is listed in <tt class="filename">/etc/shorewall/rfc1918</tt>
|
||||
with a <span class="bold"><b>logdrop</b></span> target -- see
|
||||
<tt class="filename"><a href="Documentation.htm#rfc1918" target="_self">/etc/shorewall/rfc1918</a></tt>.</p></dd><dt><a id="all2all"></a><span class="term">all2<zone>, <zone>2all or all2all</span></dt><dd><p>You have a <a href="Documentation.htm#Policy" target="_self">policy</a>
|
||||
that specifies a log level and this packet is being logged under
|
||||
that policy. If you intend to ACCEPT this traffic then you need a
|
||||
<a href="Documentation.htm#Rules" target="_self">rule</a> to that effect.</p></dd><dt><span class="term"><zone1>2<zone2></span></dt><dd><p>Either you have a <a href="Documentation.htm#Policy" target="_self">policy</a>
|
||||
for <span class="bold"><b><zone1></b></span> to <span class="bold"><b><zone2></b></span> that specifies a log level
|
||||
and this packet is being logged under that policy or this packet
|
||||
matches a <a href="Documentation.htm#Rules" target="_self">rule</a> that
|
||||
includes a log level.</p></dd><dt><span class="term"><interface>_mac</span></dt><dd><p>The packet is being logged under the <span class="bold"><b>maclist</b></span>
|
||||
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>.</p></dd><dt><span class="term">logpkt</span></dt><dd><p>The packet is being logged under the <span class="bold"><b>logunclean</b></span>
|
||||
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>.</p></dd><dt><span class="term">badpkt</span></dt><dd><p>The packet is being logged under the <span class="bold"><b>dropunclean</b></span>
|
||||
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>
|
||||
as specified in the <span class="bold"><b>LOGUNCLEAN</b></span>
|
||||
setting in <a href="Documentation.htm#Conf" target="_self"><tt class="filename">/etc/shorewall/shorewall.conf</tt></a>.</p></dd><dt><span class="term">blacklst</span></dt><dd><p>The packet is being logged because the source IP is
|
||||
blacklisted in the <tt class="filename"><a href="Documentation.htm#Blacklist" target="_self">/etc/shorewall/blacklist</a></tt>
|
||||
file.</p></dd><dt><span class="term">newnotsyn</span></dt><dd><p>The packet is being logged because it is a TCP packet that
|
||||
is not part of any current connection yet it is not a syn packet.
|
||||
Options affecting the logging of such packets include <span class="bold"><b>NEWNOTSYN</b></span> and <span class="bold"><b>LOGNEWNOTSYN</b></span>
|
||||
in <a href="Documentation.htm#Conf" target="_self"><tt class="filename">/etc/shorewall/shorewall.conf</tt></a>.</p></dd><dt><span class="term">INPUT or FORWARD</span></dt><dd><p>The packet has a source IP address that isn't in any of
|
||||
your defined zones (“<span class="quote">shorewall check</span>” and look at the
|
||||
printed zone definitions) or the chain is FORWARD and the
|
||||
destination IP isn't in any of your defined zones. Also see
|
||||
<a href="#faq2a" title="(FAQ 2a) I have a zone Z with an RFC1918 subnet and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in Z. Hosts in Z cannot communicate with each other using their external (non-RFC1918 addresses) so they can't access each other using their DNS names.">the section called “(FAQ 2a) I have a zone Z with an RFC1918 subnet
|
||||
and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in
|
||||
Z. Hosts in Z cannot communicate with each other using their external
|
||||
(non-RFC1918 addresses) so they can't access each other using
|
||||
their DNS names.”</a> for another cause of packets being logged
|
||||
in the FORWARD chain.</p></dd><dt><span class="term">logflags</span></dt><dd><p>The packet is being logged because it failed the checks
|
||||
implemented by the <span class="bold"><b>tcpflags</b></span>
|
||||
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>.</p></dd></dl></div><div class="example"><a id="id2874848"></a><p class="title"><b>Example 3. Here is an example:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Jun 27 15:37:56 gateway kernel:
|
||||
Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2
|
||||
DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP
|
||||
SPT=1803 DPT=53 LEN=47</pre></td></tr></table><p>Let's look at the important parts of this message:</p><div class="variablelist"><dl><dt><span class="term">all2all:REJECT</span></dt><dd><p>This packet was REJECTed out of the <span class="bold"><b>all2all</b></span>
|
||||
chain -- the packet was rejected under the “<span class="quote">all</span>”->“<span class="quote">all</span>”
|
||||
REJECT policy (<a href="#all2all">all2<zone>, <zone>2all or all2all</a> above).</p></dd><dt><span class="term">IN=eth2</span></dt><dd><p>the packet entered the firewall via eth2. If you see
|
||||
“<span class="quote">IN=</span>” with no interface name, the packet originated
|
||||
on the firewall itself.</p></dd><dt><span class="term">OUT=eth1</span></dt><dd><p>if accepted, the packet would be sent on eth1. If you see
|
||||
“<span class="quote">OUT=</span>” with no interface name, the packet would be
|
||||
processed by the firewall itself.</p></dd><dt><span class="term">SRC=192.168.2.2</span></dt><dd><p>the packet was sent by 192.168.2.2</p></dd><dt><span class="term">DST=192.168.1.3</span></dt><dd><p>the packet is destined for 192.168.1.3</p></dd><dt><span class="term">PROTO=UDP</span></dt><dd><p>UDP Protocol</p></dd><dt><span class="term">DPT=53</span></dt><dd><p>The destination port is 53 (DNS)</p></dd></dl></div><p>For additional information about the log message, see <a href="http://logi.cc/linux/netfilter-log-format.php3" target="_self">http://logi.cc/linux/netfilter-log-format.php3</a>.</p><p>In this case, 192.168.2.2 was in the “<span class="quote">dmz</span>” zone and
|
||||
192.168.1.3 is in the “<span class="quote">loc</span>” zone. I was missing the rule:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ACCEPT dmz loc udp 53</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq21"></a>(FAQ 21) I see these strange log entries occasionally; what are
|
||||
they?</h3></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Nov 25 18:58:52 linux kernel:
|
||||
Shorewall:net2all:DROP:IN=eth1 OUT=
|
||||
MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179
|
||||
DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP
|
||||
TYPE=3 CODE=3 [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00
|
||||
TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]</pre></td></tr></table><p>192.0.2.3 is external on my firewall... 172.16.0.0/24 is my
|
||||
internal LAN</p><p><span class="bold"><b>Answer:</b></span> While most people
|
||||
associate the Internet Control Message Protocol (ICMP) with
|
||||
“<span class="quote">ping</span>”, ICMP is a key piece of the internet. ICMP is used
|
||||
to report problems back to the sender of a packet; this is what is
|
||||
happening here. Unfortunately, where NAT is involved (including SNAT,
|
||||
DNAT and Masquerade), there are a lot of broken implementations. That is
|
||||
what you are seeing with these messages.</p><p>Here is my interpretation of what is happening -- to confirm this
|
||||
analysis, one would have to have packet sniffers placed a both ends of
|
||||
the connection.</p><p>Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS
|
||||
query to 192.0.2.3 and your DNS server tried to send a response (the
|
||||
response information is in the brackets -- note source port 53 which
|
||||
marks this as a DNS reply). When the response was returned to to
|
||||
206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and
|
||||
forwarded the packet to 172.16.1.10 who no longer had a connection on
|
||||
UDP port 2857. This causes a port unreachable (type 3, code 3) to be
|
||||
generated back to 192.0.2.3. As this packet is sent back through
|
||||
206.124.146.179, that box correctly changes the source address in the
|
||||
packet to 206.124.146.179 but doesn't reset the DST IP in the
|
||||
original DNS response similarly. When the ICMP reaches your firewall
|
||||
(192.0.2.3), your firewall has no record of having sent a DNS reply to
|
||||
172.16.1.10 so this ICMP doesn't appear to be related to anything
|
||||
that was sent. The final result is that the packet gets logged and
|
||||
dropped in the all2all chain. I have also seen cases where the source IP
|
||||
in the ICMP itself isn't set back to the external IP of the remote
|
||||
NAT gateway; that causes your firewall to log and drop the packet out of
|
||||
the rfc1918 chain because the source IP is reserved by RFC 1918.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2875168"></a>Routing</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq32"></a>(FAQ 32) My firewall has two connections to the internet from two
|
||||
different ISPs. How do I set this up in Shorewall?</h3></div></div><div></div></div><p>Setting this up in Shorewall is easy; setting up the routing is a
|
||||
bit harder.</p><p>Assuming that <tt class="filename">eth0</tt> and
|
||||
<tt class="filename">eth1</tt> are the interfaces to the
|
||||
two ISPs then:</p><p><tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
net eth0 detect
|
||||
net eth1 detect</pre></td></tr></table><p><tt class="filename">/etc/shorewall/policy</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY LIMIT:BURST
|
||||
net net DROP</pre></td></tr></table><p>If you have masqueraded hosts, be sure to update
|
||||
<tt class="filename">/etc/shorewall/masq</tt> to masquerade to both ISPs. For
|
||||
example, if you masquerade all hosts connected to <tt class="filename">eth2</tt> then:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth0 eth2
|
||||
eth1 eth2</pre></td></tr></table><p><i class="citetitle">There was an article in SysAdmin covering this topic.
|
||||
It may be found at <a href="http://www.samag.com/documents/s=1824/sam0201h/" target="_self">http://www.samag.com/documents/s=1824/sam0201h/</a></i></p><p><i class="citetitle">The following information regarding setting up routing
|
||||
for this configuration is reproduced from the <a href="http://www.lartc.org" target="_self">LARTC HOWTO</a> and has not been verified
|
||||
by the author. If you have questions or problems with the instructions
|
||||
given below, please post to the <a href="http://www.lartc.org/#mailinglist" target="_self">LARTC mailing list</a>.</i></p><div class="sidebar"><p>A common configuration is the following, in which there are two
|
||||
providers that connect a local network (or even a single machine) to
|
||||
the big Internet.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"> ________
|
||||
+------------+ /
|
||||
| | |
|
||||
+-------------+ Provider 1 +-------
|
||||
__ | | | /
|
||||
___/ \_ +------+-------+ +------------+ |
|
||||
_/ \__ | if1 | /
|
||||
/ \ | | |
|
||||
| Local network -----+ Linux router | | Internet
|
||||
\_ __/ | | |
|
||||
\__ __/ | if2 | \
|
||||
\___/ +------+-------+ +------------+ |
|
||||
| | | \
|
||||
+-------------+ Provider 2 +-------
|
||||
| | |
|
||||
+------------+ \________
|
||||
</pre></td></tr></table><p>There are usually two questions given this setup.</p><p><span class="bold"><b>Split access</b></span></p><p>The first is how to route answers to packets coming in over a
|
||||
particular provider, say Provider 1, back out again over that same
|
||||
provider.</p><p>Let us first set some symbolical names. Let <span class="bold"><b>$IF1</b></span> be the name of the first interface (if1 in
|
||||
the picture above) and <span class="bold"><b>$IF2</b></span> the name
|
||||
of the second interface. Then let <span class="bold"><b>$IP1</b></span>
|
||||
be the IP address associated with <span class="bold"><b>$IF1</b></span>
|
||||
and <span class="bold"><b>$IP2</b></span> the IP address associated
|
||||
with <span class="bold"><b>$IF2</b></span>. Next, let <span class="bold"><b>$P1</b></span> be the IP address of the gateway at
|
||||
Provider 1, and <span class="bold"><b>$P2</b></span> the IP address of
|
||||
the gateway at provider 2. Finally, let <span class="bold"><b>$P1_NET</b></span>
|
||||
be the IP network <span class="bold"><b>$P1</b></span> is in, and
|
||||
<span class="bold"><b>$P2_NET</b></span> the IP network <span class="bold"><b>$P2</b></span> is in.</p><p>One creates two additional routing tables, say <span class="bold"><b>T1</b></span> and <span class="bold"><b>T2</b></span>.
|
||||
These are added in /etc/iproute2/rt_tables. Then you set up routing in
|
||||
these tables as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add $P1_NET dev $IF1 src $IP1 table T1
|
||||
ip route add default via $P1 table T1
|
||||
ip route add $P2_NET dev $IF2 src $IP2 table T2
|
||||
ip route add default via $P2 table T2</pre></td></tr></table><p>Nothing spectacular, just build a route to the gateway and build
|
||||
a default route via that gateway, as you would do in the case of a
|
||||
single upstream provider, but put the routes in a separate table per
|
||||
provider. Note that the network route suffices, as it tells you how to
|
||||
find any host in that network, which includes the gateway, as
|
||||
specified above.</p><p>Next you set up the main routing table. It is a good idea to
|
||||
route things to the direct neighbour through the interface connected
|
||||
to that neighbour. Note the `src' arguments, they make sure the
|
||||
right outgoing IP address is chosen.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add $P1_NET dev $IF1 src $IP1
|
||||
ip route add $P2_NET dev $IF2 src $IP2</pre></td></tr></table><p>Then, your preference for default route:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add default via $P1</pre></td></tr></table><p>Next, you set up the routing rules. These actually choose what
|
||||
routing table to route with. You want to make sure that you route out
|
||||
a given interface if you already have the corresponding source
|
||||
address:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip rule add from $IP1 table T1
|
||||
ip rule add from $IP2 table T2</pre></td></tr></table><p>This set of commands makes sure all answers to traffic coming in
|
||||
on a particular interface get answered from that interface.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>'If $P0_NET is the local network and $IF0 is its
|
||||
interface, the following additional entries are desirable:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add $P0_NET dev $IF0 table T1
|
||||
ip route add $P2_NET dev $IF2 table T1
|
||||
ip route add 127.0.0.0/8 dev lo table T1
|
||||
ip route add $P0_NET dev $IF0 table T2
|
||||
ip route add $P1_NET dev $IF1 table T2
|
||||
ip route add 127.0.0.0/8 dev lo table T2</pre></td></tr></table></div><p>Now, this is just the very basic setup. It will work for all
|
||||
processes running on the router itself, and for the local network, if
|
||||
it is masqueraded. If it is not, then you either have IP space from
|
||||
both providers or you are going to want to masquerade to one of the
|
||||
two providers. In both cases you will want to add rules selecting
|
||||
which provider to route out from based on the IP address of the
|
||||
machine in the local network.</p><p><span class="bold"><b>Load balancing</b></span></p><p>The second question is how to balance traffic going out over the
|
||||
two providers. This is actually not hard if you already have set up
|
||||
split access as above.</p><p>Instead of choosing one of the two providers as your default
|
||||
route, you now set up the default route to be a multipath route. In
|
||||
the default kernel this will balance routes over the two providers. It
|
||||
is done as follows (once more building on the example in the section
|
||||
on split-access):</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
|
||||
nexthop via $P2 dev $IF2 weight 1</pre></td></tr></table><p>This will balance the routes over both providers. The <span class="bold"><b>weight</b></span> parameters can be tweaked to favor one
|
||||
provider over the other.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>balancing will not be perfect, as it is route based, and
|
||||
routes are cached. This means that routes to often-used sites will
|
||||
always be over the same provider.</p></div><p>Furthermore, if you really want to do this, you probably also
|
||||
want to look at Julian Anastasov's patches at <a href="http://www.ssi.bg/%7Eja/#routes" target="_self">http://www.ssi.bg/~ja/#routes</a>
|
||||
, Julian's route patch page. They will make things nicer to work
|
||||
with.</p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2875693"></a>Starting and Stopping</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq7"></a>(FAQ 7) When I stop Shorewall using “<span class="quote">shorewall stop</span>”,
|
||||
I can't connect to anything. Why doesn't that command work?</h3></div></div><div></div></div><p>The “<span class="quote"><span><b class="command">stop</b></span></span>” command is intended to
|
||||
place your firewall into a safe state whereby only those hosts listed in
|
||||
<tt class="filename">/etc/shorewall/routestopped</tt>' are activated. If
|
||||
you want to totally open up your firewall, you must use the
|
||||
“<span class="quote"><span><b class="command">shorewall clear</b></span></span>” command.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq8"></a>(FAQ 8) When I try to start Shorewall on RedHat, I get messages
|
||||
about insmod failing -- what's wrong?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> The output you will see
|
||||
looks something like this:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
|
||||
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
|
||||
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
|
||||
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
|
||||
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
|
||||
iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
|
||||
Perhaps iptables or your kernel needs to be upgraded.</pre></td></tr></table><p>This problem is usually corrected through the following sequence
|
||||
of commands</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">service ipchains stop
|
||||
chkconfig --delete ipchains
|
||||
rmmod ipchains</pre></td></tr></table><p>Also, be sure to check the <a href="errata.htm" target="_self">errata</a>
|
||||
for problems concerning the version of iptables (v1.2.3) shipped with
|
||||
RH7.2.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq8a"></a>(FAQ 8a) When I try to start Shorewall on RedHat I get a
|
||||
message referring me to FAQ #8</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> This is usually cured
|
||||
by the sequence of commands shown above in <a href="#faq8" title="(FAQ 8) When I try to start Shorewall on RedHat, I get messages about insmod failing -- what's wrong?">the section called “(FAQ 8) When I try to start Shorewall on RedHat, I get messages
|
||||
about insmod failing -- what's wrong?”</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq9"></a>(FAQ 9) Why can't Shorewall detect my interfaces properly at
|
||||
startup?</h3></div></div><div></div></div><p>I just installed Shorewall and when I issue the start command, I
|
||||
see the following:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Processing /etc/shorewall/params ...
|
||||
Processing /etc/shorewall/shorewall.conf ...
|
||||
Starting Shorewall...
|
||||
Loading Modules...
|
||||
Initializing...
|
||||
Determining Zones...
|
||||
Zones: net loc
|
||||
Validating interfaces file...
|
||||
Validating hosts file...
|
||||
Determining Hosts in Zones...
|
||||
<span class="bold"><b>Net Zone: eth0:0.0.0.0/0
|
||||
</b></span><span class="bold"><b>Local Zone: eth1:0.0.0.0/0</b></span>
|
||||
Deleting user chains...
|
||||
Creating input Chains...
|
||||
...</pre></td></tr></table><p>Why can't Shorewall detect my interfaces properly?</p><p><span class="bold"><b>Answer:</b></span> The above output is
|
||||
perfectly normal. The Net zone is defined as all hosts that are
|
||||
connected through eth0 and the local zone is defined as all hosts
|
||||
connected through <tt class="filename">eth1</tt>. If you
|
||||
are running Shorewall 1.4.10 or later, you can consider setting the
|
||||
<a href="Documentation.htm#Interfaces" target="_self"><span class="bold"><b>detectnets</b></span>
|
||||
interface option</a> on your local interface (<tt class="filename">eth1</tt> in the above example). That will
|
||||
cause Shorewall to restrict the local zone to only those networks routed
|
||||
through that interface.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq22"></a>(FAQ 22) I have some iptables commands that I want to run when
|
||||
Shorewall starts. Which file do I put them in?</h3></div></div><div></div></div><p>You can place these commands in one of the <a href="shorewall_extension_scripts.htm" target="_self">Shorewall Extension Scripts</a>.
|
||||
Be sure that you look at the contents of the chain(s) that you will be
|
||||
modifying with your commands to be sure that the commands will do what
|
||||
they are intended. Many iptables commands published in HOWTOs and other
|
||||
instructional material use the -A command which adds the rules to the
|
||||
end of the chain. Most chains that Shorewall constructs end with an
|
||||
unconditional DROP, ACCEPT or REJECT rule and any rules that you add
|
||||
after that will be ignored. Check “<span class="quote">man iptables</span>” and look
|
||||
at the -I (--insert) command.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2876004"></a>About Shorewall</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq10"></a>(FAQ 10) What Distributions does it work with?</h3></div></div><div></div></div><p>Shorewall works with any GNU/Linux distribution that includes the
|
||||
<a href="shorewall_prerequisites.htm" target="_self">proper prerequisites</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq11"></a>(FAQ 11) What Features does it have?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> See the <a href="shorewall_features.htm" target="_self">Shorewall Feature List</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq12"></a>(FAQ 12) Is there a GUI?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Yes. Shorewall support is
|
||||
included in Webmin 1.060 and later versions. See <a href="http://www.webmin.com" target="_self">http://www.webmin.com</a></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq13"></a>(FAQ 13) Why do you call it “<span class="quote">Shorewall</span>”?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Shorewall is a
|
||||
concatenation of “<span class="quote"><span class="emphasis"><em>Shore</em></span>line</span>” (<a href="http://www.cityofshoreline.com" target="_self">the city where I live</a>) and
|
||||
“<span class="quote">Fire<span class="emphasis"><em>wall</em></span></span>”. The full name of the
|
||||
product is actually “<span class="quote">Shoreline Firewall</span>” but
|
||||
“<span class="quote">Shorewall</span>” is must more commonly used.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq23"></a>(FAQ 23) Why do you use such ugly fonts on your web site?</h3></div></div><div></div></div><p>The Shorewall web site is almost font neutral (it doesn't
|
||||
explicitly specify fonts except on a few pages) so the fonts you see are
|
||||
largely the default fonts configured in your browser. If you don't
|
||||
like them then reconfigure your browser.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq25"></a>(FAQ 25) How to I tell which version of Shorewall I am running?</h3></div></div><div></div></div><p>At the shell prompt, type:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">/sbin/shorewall version</b></span></pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq31"></a>(FAQ 31) Does Shorewall provide protection against....</h3></div></div><div></div></div><div class="variablelist"><dl><dt><span class="term">IP Spoofing: Sending packets over the WAN interface using an
|
||||
internal LAP IP address as the source address?</span></dt><dd><p>Answer: Yes.</p></dd><dt><span class="term">Tear Drop: Sending packets that contain overlapping fragments?</span></dt><dd><p>Answer: This is the responsibility of the IP stack, not the
|
||||
Netfilter-based firewall since fragment reassembly occurs before
|
||||
the stateful packet filter ever touches each packet.</p></dd><dt><span class="term">Smurf and Fraggle: Sending packets that use the WAN or LAN
|
||||
broadcast address as the source address?</span></dt><dd><p>Answer: Shorewall can be configured to do that using the
|
||||
<a href="blacklisting_support.htm" target="_self">blacklisting</a>
|
||||
facility.</p></dd><dt><span class="term">Land Attack: Sending packets that use the same address as the
|
||||
source and destination address?</span></dt><dd><p>Answer: Yes, if the <a href="Documentation.htm#Interfaces" target="_self">routefilter interface option</a>
|
||||
is selected.</p></dd><dt><span class="term">DOS: - SYN Dos - ICMP Dos - Per-host Dos protection</span></dt><dd><p>Answer: Shorewall has facilities for limiting SYN and ICMP
|
||||
packets. Netfilter as included in standard Linux kernels
|
||||
doesn't support per-remote-host limiting except by explicit
|
||||
rule that specifies the host IP address; that form of limiting is
|
||||
supported by Shorewall.</p></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2865341"></a>Given that the Debian Stable Release includes Shorewall 1.2.12,
|
||||
how can you not support that version?</h3></div></div><div></div></div><p>The first release of Shorewall was in March of 2001. Shorewall
|
||||
1.2.12 was released in May of 2002. It is now the year 2004 and soon
|
||||
Shorewall 2.0 will be available. Shorewall 1.2.12 is poorly documented
|
||||
and is missing many of the features that Shorewall users find essential
|
||||
today.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865362"></a>RFC 1918</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq14"></a>(FAQ 14) I'm connected via a cable modem and it has an
|
||||
internal web server that allows me to configure/monitor it but as
|
||||
expected if I enable rfc1918 blocking for my eth0 interface (the
|
||||
internet one), it also blocks the cable modems web server.</h3></div></div><div></div></div><p>Is there any way it can add a rule before the rfc1918 blocking
|
||||
that will let all traffic to and from the 192.168.100.1 address of the
|
||||
modem in/out but still block all other rfc1918 addresses?</p><p><span class="bold"><b>Answer:</b></span> If you are running a
|
||||
version of Shorewall earlier than 1.3.1, create /etc/shorewall/start and
|
||||
in it, place the following:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</b></span></pre></td></tr></table><p>If you are running version 1.3.1 or later, simply add the
|
||||
following to <a href="Documentation.htm#rfc1918" target="_self">/etc/shorewall/rfc1918</a>:</p><p>Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SUBNET TARGET
|
||||
192.168.100.1 RETURN</pre></td></tr></table><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you add a second IP address to your external firewall
|
||||
interface to correspond to the modem address, you must also make an
|
||||
entry in /etc/shorewall/rfc1918 for that address. For example, if you
|
||||
configure the address 192.168.100.2 on your firewall, then you would
|
||||
add two entries to /etc/shorewall/rfc1918:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SUBNET TARGET
|
||||
192.168.100.1 RETURN
|
||||
192.168.100.2 RETURN</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq14a"></a>(FAQ 14a) Even though it assigns public IP addresses, my
|
||||
ISP's DHCP server has an RFC 1918 address. If I enable RFC 1918
|
||||
filtering on my external interface, my DHCP client cannot renew its
|
||||
lease.</h4></div></div><div></div></div><p>The solution is the same as <a href="#faq14" title="(FAQ 14) I'm connected via a cable modem and it has an internal web server that allows me to configure/monitor it but as expected if I enable rfc1918 blocking for my eth0 interface (the internet one), it also blocks the cable modems web server.">the section called “(FAQ 14) I'm connected via a cable modem and it has an
|
||||
internal web server that allows me to configure/monitor it but as
|
||||
expected if I enable rfc1918 blocking for my eth0 interface (the
|
||||
internet one), it also blocks the cable modems web server.”</a> above.
|
||||
Simply substitute the IP address of your ISPs DHCP server.</p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865509"></a>Alias IP Addresses/Virtual Interfaces</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq18"></a>(FAQ 18) Is there any way to use aliased ip addresses with
|
||||
Shorewall, and maintain separate rulesets for different IPs?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Yes. See <a href="Shorewall_and_Aliased_Interfaces.html" target="_self">Shorewall and Aliased
|
||||
Interfaces</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865549"></a>Miscellaneous</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq19"></a>(FAQ 19) I have added entries to /etc/shorewall/tcrules but they
|
||||
don't seem to do anything. Why?</h3></div></div><div></div></div><p>You probably haven't set TC_ENABLED=Yes in
|
||||
/etc/shorewall/shorewall.conf so the contents of the tcrules file are
|
||||
simply being ignored.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq20"></a>(FAQ 20) I have just set up a server. Do I have to change
|
||||
Shorewall to allow access to my server from the internet?</h3></div></div><div></div></div><p>Yes. Consult the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart
|
||||
guide</a> that you used during your initial setup for information
|
||||
about how to set up rules for your server.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq24"></a>(FAQ 24) How can I allow conections to let's say the ssh port
|
||||
only from specific IP Addresses on the internet?</h3></div></div><div></div></div><p>In the SOURCE column of the rule, follow “<span class="quote">net</span>” by a
|
||||
colon and a list of the host/subnet addresses as a comma-separated list.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">net:<ip1>,<ip2>,...</pre></td></tr></table><div class="example"><a id="id2865645"></a><p class="title"><b>Example 4. Example:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq26"></a>(FAQ 26) When I try to use any of the SYN options in nmap on or
|
||||
behind the firewall, I get “<span class="quote">operation not permitted</span>”. How
|
||||
can I use nmap with Shorewall?"</h3></div></div><div></div></div><p>Edit /etc/shorewall/shorewall.conf and change “<span class="quote">NEWNOTSYN=No</span>”
|
||||
to “<span class="quote">NEWNOTSYN=Yes</span>” then restart Shorewall.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq26a"></a>(FAQ 26a) When I try to use the “<span class="quote">-O</span>” option of
|
||||
nmap from the firewall system, I get “<span class="quote">operation not permitted</span>”.
|
||||
How do I allow this option?</h4></div></div><div></div></div><p>Add this command to your /etc/shorewall/start file:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP</b></span></pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq27"></a>(FAQ 27) I'm compiling a new kernel for my firewall. What
|
||||
should I look out for?</h3></div></div><div></div></div><p>First take a look at the <a href="kernel.htm" target="_self">Shorewall kernel
|
||||
configuration page</a>. You probably also want to be sure that you
|
||||
have selected the “<span class="quote"><span class="bold"><b>NAT of local connections
|
||||
(READ HELP)</b></span></span>” on the Netfilter Configuration menu.
|
||||
Otherwise, DNAT rules with your firewall as the source zone won't
|
||||
work with your new kernel.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq27a"></a>(FAQ 27a) I just built and installed a new kernel and now
|
||||
Shorewall won't start. I know that my kernel options are correct.</h4></div></div><div></div></div><p>The last few lines of <a href="troubleshoot.htm" target="_self">a startup
|
||||
trace</a> are these:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">+ run_iptables2 -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
|
||||
MASQUERADE
|
||||
+ '[' 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
|
||||
MASQUERADE' = 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.
|
||||
0/0 -j MASQUERADE' ']'
|
||||
+ run_iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
|
||||
MASQUERADE
|
||||
+ iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
|
||||
MASQUERADE
|
||||
iptables: Invalid argument
|
||||
+ '[' -z '' ']'
|
||||
+ stop_firewall
|
||||
+ set +x</pre></td></tr></table><p><span class="bold"><b>Answer:</b></span> Your new kernel
|
||||
contains headers that are incompatible with the ones used to compile
|
||||
your <span><b class="command">iptables</b></span> utility. You need to rebuild
|
||||
<span><b class="command">iptables</b></span> using your new kernel source.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq28"></a>(FAQ 28) How do I use Shorewall as a Bridging Firewall?</h3></div></div><div></div></div><p>Basically, you don't. While there are kernel patches that
|
||||
allow you to route bridge traffic through Netfilter, the environment is
|
||||
so different from the Layer 3 firewalling environment that very little
|
||||
of Shorewall works. In fact, so much of Shorewall doesn't work that
|
||||
my official position is that “<span class="quote">Shorewall doesn't work with
|
||||
Layer 2 Bridging</span>”.</p></div></div><div class="appendix" lang="en" xml:lang="en"><h2 class="title" style="clear: both"><a id="id2865882"></a>A. Revision History</h2><div class="revhistory"><table border="0" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1.17</td><td align="left">2004-02-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
|
||||
FAQ 33.</td></tr><tr><td align="left">Revision 1.16</td><td align="left">2004-02-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Updated
|
||||
for Shorewall 2.0.</td></tr><tr><td align="left">Revision 1.15</td><td align="left">2004-01-25</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Updated
|
||||
FAQ 32 to mention masquerading. Remove tables.</td></tr><tr><td align="left">Revision 1.14</td><td align="left">2004-01-24</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
|
||||
FAQ 27a regarding kernel/iptables incompatibility.</td></tr><tr><td align="left">Revision 1.13</td><td align="left">2004-01-24</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
|
||||
a note about the <span class="bold"><b>detectnets</b></span> interface
|
||||
option in FAQ 9.</td></tr><tr><td align="left">Revision 1.12</td><td align="left">2004-01-20</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Improve
|
||||
FAQ 16 answer.</td></tr><tr><td align="left">Revision 1.11</td><td align="left">2004-01-14</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Corrected
|
||||
broken link</td></tr><tr><td align="left">Revision 1.10</td><td align="left">2004-01-09</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
|
||||
a couple of more legacy FAQ numbers.</td></tr><tr><td align="left">Revision 1.9</td><td align="left">2004-01-08</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Corrected
|
||||
typo in FAQ 26a. Added warning to FAQ 2 regarding source address of
|
||||
redirected requests.</td></tr><tr><td align="left">Revision 1.8</td><td align="left">2003-12-31</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Additions
|
||||
to FAQ 4.</td></tr><tr><td align="left">Revision 1.7</td><td align="left">2003-12-30</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Remove
|
||||
dead link from FAQ 1.</td></tr><tr><td align="left">Revision 1.6</td><td align="left">2003.12-18</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
|
||||
external link reference to FAQ 17.</td></tr><tr><td align="left">Revision 1.5</td><td align="left">2003-12-16</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
|
||||
a link to a Sys Admin article about multiple internet interfaces. Added
|
||||
Legal Notice. Moved "abstract" to the body of the document. Moved
|
||||
Revision History to this Appendix.</td></tr><tr><td align="left">Revision 1.4</td><td align="left">2003-12-13</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Corrected
|
||||
formatting problems</td></tr><tr><td align="left">Revision 1.3</td><td align="left">2003-12-10</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Changed
|
||||
the title of FAQ 17</td></tr><tr><td align="left">Revision 1.2</td><td align="left">2003-12-09</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
|
||||
Copyright and legacy FAQ numbers</td></tr><tr><td align="left">Revision 1.1</td><td align="left">2003-12-04</td><td align="left">MN</td></tr><tr><td align="left" colspan="3">Converted
|
||||
to Simplified DocBook XML</td></tr><tr><td align="left">Revision 1.0</td><td align="left">2002-08-13</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Initial
|
||||
revision</td></tr></table></div></div></div></body></html>
|
||||
@ -17,7 +17,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-03</pubdate>
|
||||
<pubdate>2004-03-05</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -570,6 +570,19 @@ eth2 192.168.2.0/24</programlisting>
|
||||
<para><emphasis role="bold">Answer</emphasis>: Most likely, you need to
|
||||
set CLAMPMSS=Yes in <ulink url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section id="faq35">
|
||||
<title>(FAQ 35) I have two Ethernet interfaces to my local network which
|
||||
I have bridged. When Shorewall is started, I'm unable to pass
|
||||
traffic through the bridge. I have defined the bridge interface (br0) as
|
||||
the local interface in /etc/shorewall/interfaces; the bridged Ethernet
|
||||
interfaces are not defined to Shorewall. How do I tell Shorewall to
|
||||
allow traffic through the bridge?</title>
|
||||
|
||||
<para>Answer: Add the <firstterm>routeback</firstterm> option to
|
||||
<filename class="devicefile">br0</filename> in <ulink
|
||||
url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -617,7 +630,7 @@ url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/p
|
||||
<ulink url="http://gege.org/iptables">http://gege.org/iptables</ulink>
|
||||
<ulink url="http://home.regit.org/ulogd-php.html">http://home.regit.org/ulogd-php.html</ulink></literallayout>
|
||||
|
||||
<para>I personnaly use Logwatch. It emails me a report each day from
|
||||
<para>I personally use Logwatch. It emails me a report each day from
|
||||
my various systems with each report summarizing the logged activity on
|
||||
the corresponding system.</para>
|
||||
</section>
|
||||
@ -763,9 +776,9 @@ url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/p
|
||||
<term>man1918 or logdrop</term>
|
||||
|
||||
<listitem>
|
||||
<para>The destination address is listed in <filename>/etc/shorewall/rfc1918</filename>
|
||||
<para>The destination address is listed in <filename>/usr/share/shorewall/rfc1918</filename>
|
||||
with a <emphasis role="bold">logdrop</emphasis> target -- see
|
||||
<filename><ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink></filename>.</para>
|
||||
<filename><ulink url="Documentation.htm#rfc1918">/usr/share/shorewall/rfc1918</ulink></filename>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -773,9 +786,10 @@ url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/p
|
||||
<term>rfc1918 or logdrop</term>
|
||||
|
||||
<listitem>
|
||||
<para>The source address is listed in <filename>/etc/shorewall/rfc1918</filename>
|
||||
with a <emphasis role="bold">logdrop</emphasis> target -- see
|
||||
<filename><ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink></filename>.</para>
|
||||
<para>The source or destination address is listed in
|
||||
<filename>/usr/share/shorewall/rfc1918</filename> with a <emphasis
|
||||
role="bold">logdrop</emphasis> target -- see <filename><ulink
|
||||
url="Documentation.htm#rfc1918">/usr/share/shorewall/rfc1918</ulink></filename>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -1226,9 +1240,9 @@ Perhaps iptables or your kernel needs to be upgraded.</programlisting>
|
||||
<para>This problem is usually corrected through the following sequence
|
||||
of commands</para>
|
||||
|
||||
<programlisting>service ipchains stop
|
||||
<programlisting><command>service ipchains stop
|
||||
chkconfig --delete ipchains
|
||||
rmmod ipchains</programlisting>
|
||||
rmmod ipchains</command></programlisting>
|
||||
|
||||
<para>Also, be sure to check the <ulink url="errata.htm">errata</ulink>
|
||||
for problems concerning the version of iptables (v1.2.3) shipped with
|
||||
@ -1295,6 +1309,16 @@ Creating input Chains...
|
||||
after that will be ignored. Check <quote>man iptables</quote> and look
|
||||
at the -I (--insert) command.</para>
|
||||
</section>
|
||||
|
||||
<section id="faq34">
|
||||
<title>(FAQ 34) How can I speed up start (restart)?</title>
|
||||
|
||||
<para>Using a light-weight shell such as <command>ash</command> can
|
||||
dramatically decrease the time required to <emphasis role="bold">start</emphasis>
|
||||
or <emphasis role="bold">restart</emphasis> Shorewall. See the
|
||||
SHOREWALL_SHELL variable in <filename><ulink
|
||||
url="Documentation.htm#Conf">shorewall.conf</ulink></filename>.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -1380,7 +1404,9 @@ Creating input Chains...
|
||||
<listitem>
|
||||
<para>Answer: Shorewall can be configured to do that using the
|
||||
<ulink url="blacklisting_support.htm">blacklisting</ulink>
|
||||
facility.</para>
|
||||
facility. Shorewall versions 2.0.0 and later filter these packets
|
||||
under the <firstterm>nosmurfs</firstterm> interface option in
|
||||
<ulink url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -1414,10 +1440,11 @@ Creating input Chains...
|
||||
how can you not support that version?</title>
|
||||
|
||||
<para>The first release of Shorewall was in March of 2001. Shorewall
|
||||
1.2.12 was released in May of 2002. It is now the year 2004 and soon
|
||||
Shorewall 2.0 will be available. Shorewall 1.2.12 is poorly documented
|
||||
and is missing many of the features that Shorewall users find essential
|
||||
today.</para>
|
||||
1.2.12 was released in May of 2002. It is now the year 2004 and
|
||||
Shorewall 2.0 is available. Shorewall 1.2.12 is poorly documented and is
|
||||
missing many of the features that Shorewall users find essential today
|
||||
and it is silly to continue to run it simply because it is bundled with
|
||||
an ancient Debian release.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@ -1440,8 +1467,11 @@ Creating input Chains...
|
||||
|
||||
<programlisting><command>run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</command></programlisting>
|
||||
|
||||
<para>If you are running version 1.3.1 or later, simply add the
|
||||
following to <ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink>:</para>
|
||||
<para>If you are running version 1.3.1 or later, add the following to
|
||||
<ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink>
|
||||
(Note: If you are running Shorewall 2.0.0 or later, you may need to
|
||||
first copy <filename>/usr/share/shorewall/rfc1918</filename> to
|
||||
<filename>/etc/shorewall/rfc1918</filename>):</para>
|
||||
|
||||
<para>Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.</para>
|
||||
|
||||
@ -1583,19 +1613,19 @@ iptables: Invalid argument
|
||||
<section id="faq28">
|
||||
<title>(FAQ 28) How do I use Shorewall as a Bridging Firewall?</title>
|
||||
|
||||
<para>Basically, you don't. While there are kernel patches that
|
||||
allow you to route bridge traffic through Netfilter, the environment is
|
||||
so different from the Layer 3 firewalling environment that very little
|
||||
of Shorewall works. In fact, so much of Shorewall doesn't work that
|
||||
my official position is that <quote>Shorewall doesn't work with
|
||||
Layer 2 Bridging</quote>.</para>
|
||||
<para>Experimental Shorewall Bridging Firewall support is available —
|
||||
<ulink url="bridge.html">check here for details</ulink>.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.17</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
<para><revhistory><revision><revnumber>1.20</revnumber><date>2004-03-05</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
Bridging link.</revremark></revision><revision><revnumber>1.20</revnumber><date>2004-02-27</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
FAQ 35.</revremark></revision><revision><revnumber>1.19</revnumber><date>2004-02-22</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
mention of nosmurfs option under FAQ 31.</revremark></revision><revision><revnumber>1.18</revnumber><date>2004-02-15</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
FAQ 34.</revremark></revision><revision><revnumber>1.17</revnumber><date>2004-02-11</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
FAQ 33.</revremark></revision><revision><revnumber>1.16</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Updated
|
||||
for Shorewall 2.0.</revremark></revision><revision><revnumber>1.15</revnumber><date>2004-01-25</date><authorinitials>TE</authorinitials><revremark>Updated
|
||||
FAQ 32 to mention masquerading. Remove tables.</revremark></revision><revision><revnumber>1.14</revnumber><date>2004-01-24</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2003-04-08</pubdate>
|
||||
<pubdate>2004-03-01</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001</year>
|
||||
@ -24,6 +24,8 @@
|
||||
|
||||
<year>2003</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
@ -37,22 +39,15 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<important>
|
||||
<para>Before upgrading, be sure to review the <ulink
|
||||
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
|
||||
</important>
|
||||
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
QuickStart</ulink> Guide for the configuration that most closely matches
|
||||
your own.</para>
|
||||
</important>
|
||||
|
||||
<section id="Install_RPM">
|
||||
<title>Install using RPM</title>
|
||||
|
||||
<para>To install Shorewall using the RPM:</para>
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
QuickStart</ulink> Guide for the configuration that most closely matches
|
||||
your own.</para>
|
||||
</important>
|
||||
|
||||
<warning>
|
||||
<para>If you have RedHat 7.2 and are running iptables version 1.2.3 (at
|
||||
@ -63,18 +58,20 @@
|
||||
page</ulink> before attempting to start Shorewall.</para>
|
||||
</warning>
|
||||
|
||||
<para>To install Shorewall using the RPM:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Install the RPM</para>
|
||||
|
||||
<programlisting>rpm -ivh <shorewall rpm></programlisting>
|
||||
<programlisting><command>rpm -ivh <shorewall rpm></command></programlisting>
|
||||
|
||||
<note>
|
||||
<para>Some SuSE users have encountered a problem whereby rpm reports
|
||||
a conflict with kernel <= 2.2 even though a 2.4 kernel is
|
||||
installed. If this happens, simply use the --nodeps option to rpm.</para>
|
||||
|
||||
<programlisting>rpm -ivh --nodeps <shorewall rpm></programlisting>
|
||||
<programlisting><filename><command>rpm -ivh --nodeps <shorewall rpm></command></filename></programlisting>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
@ -87,7 +84,7 @@
|
||||
|
||||
<para>This may be worked around by using the --nodeps option of rpm.</para>
|
||||
|
||||
<programlisting>rpm -ivh --nodeps <shorewall rpm></programlisting>
|
||||
<programlisting><command>rpm -ivh --nodeps <shorewall rpm></command></programlisting>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
@ -109,7 +106,7 @@
|
||||
<listitem>
|
||||
<para>Start the firewall by typing</para>
|
||||
|
||||
<programlisting>shorewall start</programlisting>
|
||||
<programlisting><command>shorewall start</command></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
@ -117,6 +114,13 @@
|
||||
<section id="Install_Tarball">
|
||||
<title>Install using tarball</title>
|
||||
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
QuickStart</ulink> Guide for the configuration that most closely matches
|
||||
your own.</para>
|
||||
</important>
|
||||
|
||||
<para>To install Shorewall using the tarball and install script:</para>
|
||||
|
||||
<orderedlist>
|
||||
@ -135,33 +139,11 @@
|
||||
<ulink url="http://www.redhat.com">RedHat</ulink>, <ulink
|
||||
url="http://www.linux-mandrake.com">Mandrake</ulink>, <ulink
|
||||
url="http://www.corel.com">Corel</ulink>, <ulink
|
||||
url="http://www.slackware.com/">Slackware</ulink> or <ulink
|
||||
url="http://www.debian.org">Debian</ulink> then type</para>
|
||||
url="http://www.suse.com">SuSe</ulink>,<ulink
|
||||
url="http://www.slackware.com/"> Slackware</ulink> or <ulink
|
||||
url="http://www.debian.org">Debian/Gentoo</ulink> then type</para>
|
||||
|
||||
<programlisting>./install.sh</programlisting>
|
||||
|
||||
<orderedlist numeration="loweralpha">
|
||||
<listitem>
|
||||
<para>If you are using <ulink url="http://www.suse.com">SuSe</ulink>
|
||||
then type</para>
|
||||
|
||||
<programlisting>./install.sh /etc/init.d</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If your distribution has directory /etc/rc.d/init.d or
|
||||
/etc/init.d then type</para>
|
||||
|
||||
<programlisting>./install.sh</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>For other distributions, determine where your distribution
|
||||
installs init scripts and type</para>
|
||||
|
||||
<programlisting>./install.sh <init script directory></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<programlisting><command>./install.sh</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -169,10 +151,16 @@
|
||||
to match your configuration.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Enable Startup by removing <filename>/etc/shorewall/startup_disabled</filename>
|
||||
(Debian users will edit <filename>/etc/default/shorewall</filename>
|
||||
and set startup=1).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Start the firewall by typing</para>
|
||||
|
||||
<programlisting>shorewall start</programlisting>
|
||||
<programlisting><command>shorewall start</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -186,6 +174,13 @@
|
||||
<section id="LRP">
|
||||
<title>Install the .lrp</title>
|
||||
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
QuickStart</ulink> Guide for the configuration that most closely matches
|
||||
your own.</para>
|
||||
</important>
|
||||
|
||||
<para>To install my version of Shorewall on a fresh Bering disk, simply
|
||||
replace the <quote>shorwall.lrp</quote> file on the image with the file
|
||||
that you downloaded. See the <ulink url="two-interface.htm">two-interface
|
||||
@ -195,6 +190,11 @@
|
||||
<section id="Upgrade_RPM">
|
||||
<title>Upgrade using RPM</title>
|
||||
|
||||
<important>
|
||||
<para>Before upgrading, be sure to review the <ulink
|
||||
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
|
||||
</important>
|
||||
|
||||
<para>If you already have the Shorewall RPM installed and are upgrading to
|
||||
a new version:</para>
|
||||
|
||||
@ -212,24 +212,14 @@
|
||||
<listitem>
|
||||
<para>Upgrade the RPM</para>
|
||||
|
||||
<programlisting>rpm -Uvh <shorewall rpm file></programlisting>
|
||||
|
||||
<note>
|
||||
<para>If you are installing version 1.2.0 and have one of the 1.2.0
|
||||
Beta RPMs installed, you must use the <quote>--oldpackage</quote>
|
||||
option to rpm.</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</programlisting>
|
||||
</informalexample>
|
||||
</note>
|
||||
<programlisting><command>rpm -Uvh <shorewall rpm file></command></programlisting>
|
||||
|
||||
<note>
|
||||
<para>Some SuSE users have encountered a problem whereby rpm reports
|
||||
a conflict with kernel <= 2.2 even though a 2.4 kernel is
|
||||
installed. If this happens, simply use the --nodeps option to rpm.</para>
|
||||
|
||||
<programlisting>rpm -Uvh --nodeps <shorewall rpm></programlisting>
|
||||
<programlisting><command>rpm -Uvh --nodeps <shorewall rpm></command></programlisting>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
@ -242,7 +232,7 @@
|
||||
|
||||
<para>This may be worked around by using the --nodeps option of rpm.</para>
|
||||
|
||||
<programlisting>rpm -Uvh --nodeps <shorewall rpm></programlisting>
|
||||
<programlisting><command>rpm -Uvh --nodeps <shorewall rpm></command></programlisting>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
@ -250,13 +240,13 @@
|
||||
<para>See if there are any incompatibilities between your
|
||||
configuration and the new Shorewall version and correct as necessary.</para>
|
||||
|
||||
<programlisting>shorewall check</programlisting>
|
||||
<programlisting><command>shorewall check</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Restart the firewall.</para>
|
||||
|
||||
<programlisting>shorewall restart</programlisting>
|
||||
<programlisting><command>shorewall restart</command></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
@ -264,6 +254,11 @@
|
||||
<section id="Upgrade_Tarball">
|
||||
<title>Upgrade using tarball</title>
|
||||
|
||||
<important>
|
||||
<para>Before upgrading, be sure to review the <ulink
|
||||
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
|
||||
</important>
|
||||
|
||||
<para>If you already have Shorewall installed and are upgrading to a new
|
||||
version using the tarball:</para>
|
||||
|
||||
@ -281,7 +276,7 @@
|
||||
<listitem>
|
||||
<para>unpack the tarball.</para>
|
||||
|
||||
<programlisting>tar -zxf shorewall-x.y.z.tgz</programlisting>
|
||||
<programlisting><command>tar -zxf shorewall-x.y.z.tgz</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -295,46 +290,24 @@
|
||||
<ulink url="http://www.redhat.com">RedHat</ulink>, <ulink
|
||||
url="http://www.linux-mandrake.com">Mandrake</ulink>, <ulink
|
||||
url="http://www.corel.com">Corel</ulink>, <ulink
|
||||
url="http://www.suse.com">SuSe</ulink>, <ulink
|
||||
url="http://www.slackware.com/">Slackware</ulink> or <ulink
|
||||
url="http://www.debian.org">Debian</ulink> then type</para>
|
||||
url="http://www.debian.org">Debian/Gentoo</ulink> then type</para>
|
||||
|
||||
<programlisting>./install.sh</programlisting>
|
||||
|
||||
<orderedlist numeration="loweralpha">
|
||||
<listitem>
|
||||
<para>If you are using <ulink url="http://www.suse.com">SuSe</ulink>
|
||||
then type</para>
|
||||
|
||||
<programlisting>./install.sh /etc/init.d</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If your distribution has directory /etc/rc.d/init.d or
|
||||
/etc/init.d then type</para>
|
||||
|
||||
<programlisting>./install.sh</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>For other distributions, determine where your distribution
|
||||
installs init scripts and type</para>
|
||||
|
||||
<programlisting>./install.sh <init script directory></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<programlisting><command>./install.sh</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>See if there are any incompatibilities between your
|
||||
configuration and the new Shorewall version and correct as necessary.</para>
|
||||
|
||||
<programlisting>shorewall check</programlisting>
|
||||
<programlisting><command>shorewall check</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Start the firewall by typing</para>
|
||||
|
||||
<programlisting>shorewall start</programlisting>
|
||||
<programlisting><command>shorewall start</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -348,10 +321,13 @@
|
||||
<section id="LRP_Upgrade">
|
||||
<title>Upgrade the .lrp</title>
|
||||
|
||||
<para>If you already have a running Bering installation and wish to
|
||||
upgrade to a later version of Shorewall:</para>
|
||||
<important>
|
||||
<para>Before upgrading, be sure to review the <ulink
|
||||
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
|
||||
</important>
|
||||
|
||||
<remark>UNDER CONSTRUCTION...</remark>
|
||||
<para>There appears to be no standard method for upgrading LEAF/Bering
|
||||
packages — Sorry to be so unhelpful.</para>
|
||||
</section>
|
||||
|
||||
<section id="Config_Files">
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2004-02-03</pubdate>
|
||||
<pubdate>2004-02-17</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003-2004</year>
|
||||
@ -141,11 +141,12 @@
|
||||
file. If no rule in that file matches the connection request then the
|
||||
first policy in <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
||||
that matches the request is applied. If there is a common action defined
|
||||
for the policy in /etc/shorewall/actions then that action is invoked
|
||||
before the policy is enforces. In the standard Shorewall distribution, the
|
||||
DROP policy has a common action called <emphasis role="bold">Drop</emphasis>
|
||||
and the REJECT policy has a common action called <emphasis role="bold">Reject</emphasis>.
|
||||
Common actions are used primarily to discard </para>
|
||||
for the policy in /etc/shorewall/actions (or <filename>/usr/share/shorewall/actions.std</filename>)
|
||||
then that action is invoked before the policy is enforces. In the standard
|
||||
Shorewall distribution, the DROP policy has a common action called
|
||||
<emphasis role="bold">Drop</emphasis> and the REJECT policy has a common
|
||||
action called <emphasis role="bold">Reject</emphasis>. Common actions are
|
||||
used primarily to discard</para>
|
||||
|
||||
<para>The <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
||||
file included with the three-interface sample has the following policies:
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-07</pubdate>
|
||||
<pubdate>2004-03-15</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
@ -304,8 +304,9 @@ loc1 loc NONE</programlisting>
|
||||
(More on that topic may be found <ulink
|
||||
url="Shorewall_and_Aliased_Interfaces.html">here</ulink>). Hosts in the
|
||||
<quote>loc</quote> zone are configured with their default gateway set to
|
||||
the Shorewall router's RFC1918 address.<graphic
|
||||
fileref="images/MultiZone3.png" /></para>
|
||||
the Shorewall router's RFC1918 address.</para>
|
||||
|
||||
<para><graphic fileref="images/MultiZone3.png" /></para>
|
||||
|
||||
<para><filename>/etc/shorewall/zones</filename></para>
|
||||
|
||||
@ -324,7 +325,18 @@ net eth0 detect</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/hosts</filename></para>
|
||||
|
||||
<programlisting>#ZONE HOSTS
|
||||
loc eth0:192.168.1.0/24</programlisting>
|
||||
<programlisting>#ZONE HOSTS OPTIONS
|
||||
loc eth0:192.168.1.0/24 maclist</programlisting>
|
||||
|
||||
<para><filename><filename>/etc/shorewall/masq</filename></filename></para>
|
||||
|
||||
<programlisting>#INTERFACE SUBNET ADDRESS
|
||||
eth0:!192.168.1.0/24 192.168.1.0/24</programlisting>
|
||||
|
||||
<para>Note that the maclist option is specified in <filename>/etc/shorewall/interfaces</filename>.
|
||||
This is to help protect your router from unauthorized access by your
|
||||
friends and neighbors. Start without maclist then add it and configure
|
||||
your <ulink url="MAC_Validation.html"><filename>/etc/shorewall/maclist</filename></ulink>
|
||||
file when everything else is working.</para>
|
||||
</section>
|
||||
</article>
|
||||
@ -15,11 +15,13 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2003-10-14</pubdate>
|
||||
<pubdate>2004-03-12</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
@ -81,6 +83,9 @@
|
||||
<para><quote>Local Process</quote> means a process running on the
|
||||
Shorewall system itself.</para>
|
||||
|
||||
<para>A more elaborate version of this flow is available <ulink
|
||||
url="http://shorewall.net/pub/shorewall/misc/netfilterflow.pdf">here</ulink>.</para>
|
||||
|
||||
<para>In the above diagram are boxes similar to this:</para>
|
||||
|
||||
<graphic fileref="images/Legend.png" />
|
||||
|
||||
@ -13,11 +13,13 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2003-10-07</pubdate>
|
||||
<pubdate>2004-03-05</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<holder>Thomas M Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
@ -36,7 +38,9 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Be used to filter traffic through a Layer 2 Bridge</para>
|
||||
<para>Be used to filter traffic through a Layer 2 Bridge (although
|
||||
experimental Shorewall Bridge code is available — check <ulink
|
||||
url="bridge.html">here</ulink> for details).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
||||
@ -1,76 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Using Shorewall with Squid</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="Shorewall_Squid_Usage"></a>Using Shorewall with Squid</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2003-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>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
|
||||
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-04</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807725">Squid as a Transparent Proxy</a></span></dt><dt><span class="section"><a href="#id2807811">Configurations</a></span></dt><dd><dl><dt><span class="section"><a href="#Firewall">Squid (transparent) Running on the Firewall</a></span></dt><dt><span class="section"><a href="#Local">Squid (transparent) Running in the local network</a></span></dt><dt><span class="section"><a href="#DMZ">Squid (transparent) Running in the DMZ</a></span></dt></dl></dd><dt><span class="section"><a href="#id2859624">Squid as a Manual Proxy</a></span></dt></dl></div><p></p><p>This page covers Shorewall configuration to use with <a href="http://www.squid-cache.org" target="_self">Squid</a> running as a Transparent
|
||||
Proxy or as a Manual Proxy.</p><p>If you are running Shorewall 1.3, please see <a href="1.3/Shorewall_Squid_Usage.html" target="_self">this documentation</a>.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807725"></a>Squid as a Transparent Proxy</h2></div></div><div></div></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>Please observe the following general requirements:</p><div class="itemizedlist"><ul type="disc"><li><p>In all cases, Squid should be configured to run as a transrent
|
||||
proxy as described at
|
||||
http://tldp.org/HOWTO/mini/TransparentProxy.html.</p></li><li><p>The following instructions mention the files
|
||||
/etc/shorewall/start and /etc/shorewall/init -- if you don't
|
||||
have those files, siimply create them.</p></li><li><p>When the Squid server is in the DMZ zone or in the local zone,
|
||||
that zone must be defined ONLY by its interface -- no
|
||||
/etc/shorewall/hosts file entries. That is because the packets being
|
||||
routed to the Squid server still have their original destination IP
|
||||
addresses.</p></li><li><p>You must have iptables installed on your Squid server.</p></li><li><p>If you run a Shorewall version earlier than 1.4.6, you must
|
||||
have NAT and MANGLE enabled in your /etc/shorewall/conf file</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">NAT_ENABLED=Yes
|
||||
MANGLE_ENABLED=Yes</pre></td></tr></table></li></ul></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807811"></a>Configurations</h2></div></div><div></div></div><p>Three different configurations are covered:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Squid (transparent) Running on the Firewall</td></tr><tr><td>Squid (transparent) Running in the local Network</td></tr><tr><td>Squid (transparent) Running in a DMZ</td></tr></table><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Firewall"></a>Squid (transparent) Running on the Firewall</h3></div></div><div></div></div><p>You want to redirect all local www connection requests EXCEPT
|
||||
those to your own http server (206.124.146.177) to a Squid transparent
|
||||
proxy running on the firewall and listening on port 3128. Squid will of
|
||||
course require access to remote web servers.</p><p>In <tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
REDIRECT loc 3228 tcp www - !206.124.146.177
|
||||
ACCEPT fw net tcp www</pre></td></tr></table><p>There may be a requirement to exclude additional destination hosts
|
||||
or networks from being redirected. For example, you might also want
|
||||
requests destined for 130.252.100.0/24 to not be routed to Squid.</p><p>If you are running Shorewall version 1.4.5 or later, you may just
|
||||
add the additional hosts/networks to the ORIGINAL DEST column in your
|
||||
REDIRECT rule.</p><p><tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
REDIRECT loc 3228 tcp www - !206.124.146.177,130.252.100.0/24</pre></td></tr></table><p>If you are running a Shorewall version earlier than 1.4.5, you
|
||||
must add a manual rule in /etc/shorewall/start:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN</b></span></pre></td></tr></table><p>To exclude additional hosts or networks, just add additional
|
||||
similar rules.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Local"></a>Squid (transparent) Running in the local network</h3></div></div><div></div></div><p>You want to redirect all local www connection requests to a Squid
|
||||
transparent proxy running in your local zone at 192.168.1.3 and
|
||||
listening on port 3128. Your local interface is eth1. There may also be
|
||||
a web server running on 192.168.1.3. It is assumed that web access is
|
||||
already enabled from the local zone to the internet..</p><div class="orderedlist"><ol type="1"><li><p>* On your firewall system, issue the following command</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">echo 202 www.out >> /etc/iproute2/rt_tables</b></span></pre></td></tr></table></li><li><p>In /etc/shorewall/init, put:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">if [ -z "`ip rule list | grep www.out`" ] ; then
|
||||
ip rule add fwmark 202 table www.out
|
||||
ip route add default via 192.168.1.3 dev eth1 table www.out
|
||||
ip route flush cache
|
||||
echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
|
||||
fi</b></span></pre></td></tr></table></li><li><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>If you are running Shorewall 1.4.1 or Shorewall 1.4.1a,
|
||||
please upgrade to Shorewall 1.4.2 or later.</p></div><p>If you are running Shorewall 1.4.2 or later, then in
|
||||
<tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
|
||||
loc eth1 detect <span class="bold"><b>routeback</b></span> </pre></td></tr></table></li><li><p>In /etc/shorewall/rules:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT loc loc tcp www</pre></td></tr></table><div class="orderedlist"><ol type="a"><li><p>Alternativfely, if you are running Shorewall 1.4.0 you can
|
||||
have the following policy in place of the above rule.</p><p><tt class="filename">/etc/shorewall/policy</tt></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY
|
||||
loc loc ACCEPT</pre></td></tr></table></li></ol></div></li><li><p>In <tt class="filename">/etc/shorewall/start</tt> add:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</b></span></pre></td></tr></table></li><li><p>On 192.168.1.3, arrange for the following command to be
|
||||
executed after networking has come up</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></span></pre></td></tr></table><p>If you are running RedHat on the server, you can simply
|
||||
execute the following commands after you have typed the iptables
|
||||
command above:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables-save > /etc/sysconfig/iptables
|
||||
chkconfig --level 35 iptables on</b></span></pre></td></tr></table></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="DMZ"></a>Squid (transparent) Running in the DMZ</h3></div></div><div></div></div><p>You have a single Linux system in your DMZ with IP address
|
||||
192.0.2.177. You want to run both a web server and Squid on that system.
|
||||
Your DMZ interface is eth1 and your local interface is eth2.</p><div class="orderedlist"><ol type="1"><li><p>On your firewall system, issue the following command</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">echo 202 www.out >> /etc/iproute2/rt_tables</b></span></pre></td></tr></table></li><li><p>In /etc/shorewall/init, put:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">if [ -z "`ip rule list | grep www.out`" ] ; then
|
||||
ip rule add fwmark 202 table www.out
|
||||
ip route add default via 192.0.2.177 dev eth1 table www.out
|
||||
ip route flush cache
|
||||
fi</b></span></pre></td></tr></table></li><li><p>Do <span class="bold"><b>one</b></span> of the following:</p><div class="orderedlist"><ol type="a"><li><p>In <tt class="filename">/etc/shorewall/start</tt> add</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202</b></span></pre></td></tr></table></li><li><p>Set MARK_IN_FORWARD_CHAIN=No in <tt class="filename">/etc/shorewall/shorewall.conf</tt>
|
||||
and add the following entry in <tt class="filename">/etc/shorewall/tcrules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT
|
||||
202 eth2 0.0.0.0 tcp 80</pre></td></tr></table></li><li><p>Run Shorewall 1.3.14 or later and add the following entry
|
||||
in <tt class="filename">/etc/shorewall/tcrules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT
|
||||
202:P eth2 0.0.0.0 tcp 80</pre></td></tr></table></li></ol></div></li><li><p>In <tt class="filename">/etc/shorewall/rules</tt>, you will need:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT loc dmz tcp 80
|
||||
ACCEPT dmz net tcp 80</pre></td></tr></table></li><li><p>On 192.0.2.177 (your Web/Squid server), arrange for the
|
||||
following command to be executed after networking has come up</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></span></pre></td></tr></table><p>If you are running RedHat on the server, you can simply
|
||||
execute the following commands after you have typed the iptables
|
||||
command above:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables-save > /etc/sysconfig/iptables
|
||||
chkconfig --level 35 iptables on</b></span></pre></td></tr></table></li></ol></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859624"></a>Squid as a Manual Proxy</h2></div></div><div></div></div><p>Assume that Squid is running in zone SZ and listening on port SP;
|
||||
all web sites that are to be accessed through Squid are in the
|
||||
“<span class="quote">net</span>” zone. Then for each zone Z that needs access to the
|
||||
Squid server.</p><p><tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT Z SZ tcp SP
|
||||
ACCEPT SZ net tcp 80</pre></td></tr></table><div class="example"><a id="id2809851"></a><p class="title"><b>Example 1. Squid on the firewall listening on port 8080 with access from the
|
||||
“<span class="quote">loc</span>” zone:</b></p><p><tt class="filename">/etc/shorewall/rules:</tt></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT loc fw tcp 8080
|
||||
ACCEPT fw net tcp 80</pre></td></tr></table></div></div></div></body></html>
|
||||
@ -15,10 +15,12 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-14</pubdate>
|
||||
<pubdate>2004-03-10</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003-2004</year>
|
||||
<year>2003</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
@ -33,217 +35,267 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<para>Prior to Shorewall version 1.4.9, rules in <filename>/etc/shorewall/rules</filename>
|
||||
were limited to those defined by Netfilter (ACCEPT, DROP, REJECT, etc.).
|
||||
Beginning with Shorewall version 1.4.9, users may use sequences of these
|
||||
elementary operations to define more complex actions.</para>
|
||||
<section>
|
||||
<title>Creating a New Action</title>
|
||||
|
||||
<para>To define a new action:</para>
|
||||
<para>Prior to Shorewall version 1.4.9, rules in <filename>/etc/shorewall/rules</filename>
|
||||
were limited to those defined by Netfilter (ACCEPT, DROP, REJECT, etc.).
|
||||
Beginning with Shorewall version 1.4.9, users may use sequences of these
|
||||
elementary operations to define more complex actions.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Add a line to <filename><filename>/etc/shorewall/actions</filename></filename>
|
||||
that names your new action. Action names must be valid shell variable
|
||||
names as well as valid Netfilter chain names. It is recommended that the
|
||||
name you select for a new action begins with with a capital letter; that
|
||||
way, the name won't conflict with a Shorewall-defined chain name.</para>
|
||||
<para>To define a new action:</para>
|
||||
|
||||
<para>Beginning with Shorewall-2.0.0-Beta1, the name of the action may
|
||||
be optionally followed by a colon (<quote>:</quote>) and ACCEPT, DROP or
|
||||
REJECT. When this is done, the named action will become the
|
||||
<emphasis>common action </emphasis>for policies of type ACCEPT, DROP or
|
||||
REJECT respectively. The common action is applied immediately before the
|
||||
policy is enforced (before any logging is done under that policy) and is
|
||||
used mainly to suppress logging of uninteresting traffic which would
|
||||
otherwise clog your logs. The same policy name can appear in multiple
|
||||
actions; the last such action for each policy name is the one which
|
||||
Shorewall will use.</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Add a line to <filename><filename>/etc/shorewall/actions</filename></filename>
|
||||
that names your new action. Action names must be valid shell variable
|
||||
names as well as valid Netfilter chain names. It is recommended that
|
||||
the name you select for a new action begins with with a capital
|
||||
letter; that way, the name won't conflict with a Shorewall-defined
|
||||
chain name.</para>
|
||||
|
||||
<para>Shorewall includes pre-defined actions for DROP and REJECT -- see
|
||||
below.</para>
|
||||
</listitem>
|
||||
<para>Beginning with Shorewall-2.0.0-Beta1, the name of the action may
|
||||
be optionally followed by a colon (<quote>:</quote>) and ACCEPT, DROP
|
||||
or REJECT. When this is done, the named action will become the
|
||||
<emphasis>common action </emphasis>for policies of type ACCEPT, DROP
|
||||
or REJECT respectively. The common action is applied immediately
|
||||
before the policy is enforced (before any logging is done under that
|
||||
policy) and is used mainly to suppress logging of uninteresting
|
||||
traffic which would otherwise clog your logs. The same policy name can
|
||||
appear in multiple actions; the last such action for each policy name
|
||||
is the one which Shorewall will use.</para>
|
||||
|
||||
<listitem>
|
||||
<para>Once you have defined your new action name (ActionName), then copy
|
||||
/usr/share/shorewall/action.template to <filename>/etc/shorewall/action.ActionName</filename>
|
||||
(for example, if your new action name is <quote>Foo</quote> then copy
|
||||
<filename>/usr/share/shorewall/action.template</filename> to
|
||||
<filename>/etc/shorewall/action.Foo</filename>).</para>
|
||||
</listitem>
|
||||
<para>Shorewall includes pre-defined actions for DROP and REJECT --
|
||||
see below.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Now modify the new file to define the new action.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<listitem>
|
||||
<para>Once you have defined your new action name (ActionName), then
|
||||
copy /usr/share/shorewall/action.template to <filename>/etc/shorewall/action.ActionName</filename>
|
||||
(for example, if your new action name is <quote>Foo</quote> then copy
|
||||
<filename>/usr/share/shorewall/action.template</filename> to
|
||||
<filename>/etc/shorewall/action.Foo</filename>).</para>
|
||||
</listitem>
|
||||
|
||||
<para>Columns in the action.template file are as follows:</para>
|
||||
<listitem>
|
||||
<para>Now modify the new file to define the new action.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>TARGET - Must be ACCEPT, DROP, REJECT, LOG, QUEUE or <<emphasis>action</emphasis>>
|
||||
where <<emphasis>action</emphasis>> is a previously-defined
|
||||
action (that is, it must precede the action being defined in this file
|
||||
in your <filename>/etc/shorewall/actions</filename> file). The TARGET
|
||||
may optionally be followed by a colon (<quote>:</quote>) and a syslog
|
||||
log level (e.g, REJECT:info or ACCEPT:debugging). This causes the packet
|
||||
to be logged at the specified level. You may also specify ULOG (must be
|
||||
in upper case) as a log level.This will log to the ULOG target for
|
||||
routing to a separate log through use of ulogd (<ulink
|
||||
url="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</ulink>).</para>
|
||||
</listitem>
|
||||
<para>Columns in the action.template file are as follows:</para>
|
||||
|
||||
<listitem>
|
||||
<para>SOURCE - Source hosts to which the rule applies. A comma-separated
|
||||
list of subnets and/or hosts. Hosts may be specified by IP or MAC
|
||||
address; mac addresses must begin with <quote>~</quote> and must use
|
||||
<quote>-</quote> as a separator.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>TARGET - Must be ACCEPT, DROP, REJECT, LOG, CONTINUE, QUEUE or
|
||||
<<emphasis>action</emphasis>> where <<emphasis>action</emphasis>>
|
||||
is a previously-defined action (that is, it must precede the action
|
||||
being defined in this file in your <filename>/etc/shorewall/actions</filename>
|
||||
file). These actions have the same meaning as they do in the
|
||||
<filename>/etc/shorewall/rules</filename> file (CONTINUE terminates
|
||||
processing of the current action and returns to the point where that
|
||||
action was invoked). The TARGET may optionally be followed by a colon
|
||||
(<quote>:</quote>) and a syslog log level (e.g, REJECT:info or
|
||||
ACCEPT:debugging). This causes the packet to be logged at the
|
||||
specified level. You may also specify ULOG (must be in upper case) as
|
||||
a log level.This will log to the ULOG target for routing to a separate
|
||||
log through use of ulogd (<ulink
|
||||
url="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</ulink>).</para>
|
||||
</listitem>
|
||||
|
||||
<para>Alternatively, clients may be specified by interface name. For
|
||||
example, eth1 specifies a client that communicates with the firewall
|
||||
system through eth1. This may be optionally followed by another colon (<quote>:</quote>)
|
||||
and an IP/MAC/subnet address as described above (e.g.,
|
||||
eth1:192.168.1.5).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>SOURCE - Source hosts to which the rule applies. A
|
||||
comma-separated list of subnets and/or hosts. Hosts may be specified
|
||||
by IP or MAC address; mac addresses must begin with <quote>~</quote>
|
||||
and must use <quote>-</quote> as a separator.</para>
|
||||
|
||||
<listitem>
|
||||
<para>DEST - Location of Server. Same as above with the exception that
|
||||
MAC addresses are not allowed.</para>
|
||||
<para>Alternatively, clients may be specified by interface name. For
|
||||
example, eth1 specifies a client that communicates with the firewall
|
||||
system through eth1. This may be optionally followed by another colon
|
||||
(<quote>:</quote>) and an IP/MAC/subnet address as described above
|
||||
(e.g., eth1:192.168.1.5).</para>
|
||||
</listitem>
|
||||
|
||||
<para>Unlike in the SOURCE column, you may specify a range of up to 256
|
||||
IP addresses using the syntax <<emphasis>first ip</emphasis>>-<<emphasis>last
|
||||
ip</emphasis>>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>DEST - Location of Server. Same as above with the exception that
|
||||
MAC addresses are not allowed.</para>
|
||||
|
||||
<listitem>
|
||||
<para>PROTO - Protocol - Must be <quote>tcp</quote>, <quote>udp</quote>,
|
||||
<quote>icmp</quote>, a number, or <quote>all</quote>.</para>
|
||||
</listitem>
|
||||
<para>Unlike in the SOURCE column, you may specify a range of up to
|
||||
256 IP addresses using the syntax <<emphasis>first ip</emphasis>>-<<emphasis>last
|
||||
ip</emphasis>>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>DEST PORT(S) - Destination Ports. A comma-separated list of Port
|
||||
names (from <filename>/etc/services</filename>), port numbers or port
|
||||
ranges; if the protocol is <quote>icmp</quote>, this column is
|
||||
interpreted as the destination icmp-type(s).</para>
|
||||
<listitem>
|
||||
<para>PROTO - Protocol - Must be <quote>tcp</quote>, <quote>udp</quote>,
|
||||
<quote>icmp</quote>, a number, or <quote>all</quote>.</para>
|
||||
</listitem>
|
||||
|
||||
<para>A port range is expressed as <<emphasis>low port</emphasis>>:<<emphasis>high
|
||||
port</emphasis>>.</para>
|
||||
<listitem>
|
||||
<para>DEST PORT(S) - Destination Ports. A comma-separated list of Port
|
||||
names (from <filename>/etc/services</filename>), port numbers or port
|
||||
ranges; if the protocol is <quote>icmp</quote>, this column is
|
||||
interpreted as the destination icmp-type(s).</para>
|
||||
|
||||
<para>This column is ignored if PROTOCOL = all but must be entered if
|
||||
any of the following ields are supplied. In that case, it is suggested
|
||||
that this field contain <quote>-</quote>.</para>
|
||||
<para>A port range is expressed as <<emphasis>low port</emphasis>>:<<emphasis>high
|
||||
port</emphasis>>.</para>
|
||||
|
||||
<para>If your kernel contains multi-port match support, then only a
|
||||
single Netfilter rule will be generated if in this list and in the
|
||||
CLIENT PORT(S) list below:</para>
|
||||
<para>This column is ignored if PROTOCOL = all but must be entered if
|
||||
any of the following ields are supplied. In that case, it is suggested
|
||||
that this field contain <quote>-</quote>.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>There are 15 or less ports listed.</para>
|
||||
</listitem>
|
||||
<para>If your kernel contains multi-port match support, then only a
|
||||
single Netfilter rule will be generated if in this list and in the
|
||||
CLIENT PORT(S) list below:</para>
|
||||
|
||||
<listitem>
|
||||
<para>No port ranges are included.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>There are 15 or less ports listed.</para>
|
||||
</listitem>
|
||||
|
||||
<para>Otherwise, a separate rule will be generated for each port.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>No port ranges are included.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>SOURCE PORT(S) - Port(s) used by the client. If omitted, any
|
||||
source port is acceptable. Specified as a comma-separated list of port
|
||||
names, port numbers or port ranges.</para>
|
||||
<para>Otherwise, a separate rule will be generated for each port.</para>
|
||||
</listitem>
|
||||
|
||||
<para>If you don't want to restrict client ports but need to specify
|
||||
an ADDRESS in the next column, then place "-" in this column.</para>
|
||||
<listitem>
|
||||
<para>SOURCE PORT(S) - Port(s) used by the client. If omitted, any
|
||||
source port is acceptable. Specified as a comma-separated list of port
|
||||
names, port numbers or port ranges.</para>
|
||||
|
||||
<para>If your kernel contains multi-port match support, then only a
|
||||
single Netfilter rule will be generated if in this list and in the DEST
|
||||
PORT(S) list above:</para>
|
||||
<para>If you don't want to restrict client ports but need to
|
||||
specify an ADDRESS in the next column, then place "-" in this
|
||||
column.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>There are 15 or less ports listed.</para>
|
||||
</listitem>
|
||||
<para>If your kernel contains multi-port match support, then only a
|
||||
single Netfilter rule will be generated if in this list and in the
|
||||
DEST PORT(S) list above:</para>
|
||||
|
||||
<listitem>
|
||||
<para>No port ranges are included.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>There are 15 or less ports listed.</para>
|
||||
</listitem>
|
||||
|
||||
<para>Otherwise, a separate rule will be generated for each port.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>No port ranges are included.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>RATE LIMIT - You may rate-limit the rule by placing a value in
|
||||
this column:</para>
|
||||
<para>Otherwise, a separate rule will be generated for each port.</para>
|
||||
</listitem>
|
||||
|
||||
<para><programlisting> <<emphasis>rate</emphasis>>/<<emphasis>interval</emphasis>>[:<<emphasis>burst</emphasis>>]</programlisting>where
|
||||
<<emphasis>rate</emphasis>> is the number of connections per
|
||||
<<emphasis>interval</emphasis>> (<quote>sec</quote> or
|
||||
<quote>min</quote>) and <<emphasis>burst</emphasis>> is the
|
||||
largest burst permitted. If no <<emphasis>burst</emphasis>> is
|
||||
given, a value of 5 is assumed. There may be no whitespace embedded in
|
||||
the specification.</para>
|
||||
<listitem>
|
||||
<para>RATE LIMIT - You may rate-limit the rule by placing a value in
|
||||
this column:</para>
|
||||
|
||||
<para><programlisting> Example: 10/sec:20</programlisting></para>
|
||||
</listitem>
|
||||
<para><programlisting> <<emphasis>rate</emphasis>>/<<emphasis>interval</emphasis>>[:<<emphasis>burst</emphasis>>]</programlisting>where
|
||||
<<emphasis>rate</emphasis>> is the number of connections per
|
||||
<<emphasis>interval</emphasis>> (<quote>sec</quote> or
|
||||
<quote>min</quote>) and <<emphasis>burst</emphasis>> is the
|
||||
largest burst permitted. If no <<emphasis>burst</emphasis>> is
|
||||
given, a value of 5 is assumed. There may be no whitespace embedded in
|
||||
the specification.</para>
|
||||
|
||||
<listitem>
|
||||
<para>USER/GROUP - For output rules (those with the firewall as their
|
||||
source), you may control connections based on the effective UID and/or
|
||||
GID of the process requesting the connection. This column can contain
|
||||
any of the following:</para>
|
||||
<para><programlisting> Example: 10/sec:20</programlisting></para>
|
||||
</listitem>
|
||||
|
||||
<simplelist>
|
||||
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
||||
<listitem>
|
||||
<para>USER/GROUP - For output rules (those with the firewall as their
|
||||
source), you may control connections based on the effective UID and/or
|
||||
GID of the process requesting the connection. This column can contain
|
||||
any of the following:</para>
|
||||
|
||||
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
||||
<simplelist>
|
||||
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
||||
|
||||
<member>[!]:<<emphasis>group number</emphasis>></member>
|
||||
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
||||
|
||||
<member>[!]:<<emphasis>group name</emphasis>></member>
|
||||
<member>[!]:<<emphasis>group number</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user number</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
<member>[!]:<<emphasis>group name</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
<member>[!]<<emphasis>user number</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user inumber</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
</simplelist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<member>[!]<<emphasis>user inumber</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
|
||||
<para>Example:</para>
|
||||
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
</simplelist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><filename>/etc/shorewall/actions</filename>:</para>
|
||||
<para>Example:</para>
|
||||
|
||||
<para><programlisting> LogAndAccept</programlisting><phrase><filename>/etc/shorewall/action.LogAndAccept</filename></phrase><programlisting> LOG:info
|
||||
<para><filename>/etc/shorewall/actions</filename>:</para>
|
||||
|
||||
<para><programlisting> LogAndAccept</programlisting><phrase><filename>/etc/shorewall/action.LogAndAccept</filename></phrase><programlisting> LOG:info
|
||||
ACCEPT</programlisting></para>
|
||||
|
||||
<para>Beginning with Shorewall 2.0.0-Beta1, Shorewall includes a number of
|
||||
defined actions. These defined actions are listed in <filename>/usr/share/shorewall/actions.std</filename>.</para>
|
||||
<para>To use your action, in <filename>/etc/shorewall/rules</filename> you
|
||||
might do something like:</para>
|
||||
|
||||
<para>The <filename>/usr/share/shorewall/actions.std</filename> file
|
||||
includes the common actions <quote>Drop</quote> for DROP policies and
|
||||
<quote>Reject</quote> for REJECT policies.</para>
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
LogAndAccept loc fw tcp 22</programlisting>
|
||||
</section>
|
||||
|
||||
<para><filename>/usr/share/shorewall/actions.std</filename> is processed
|
||||
before <filename>/etc/shorewall/actions</filename> and if you have any
|
||||
actions defined with the same name as one in <filename>/usr/share/shorewall/actions.std</filename>,
|
||||
your version in <filename class="directory">/etc/shorewall</filename> will
|
||||
be the one used. So if you wish to modify a standard action, simply copy the
|
||||
associated action file from <filename class="directory">/usr/share/shorewall
|
||||
</filename>to <filename class="directory">/etc/shorewall and modify</filename>
|
||||
it to suit your needs. The next <command>shorewall restart</command> will
|
||||
cause your action to be installed in place of the standard one. In
|
||||
particular, if you want to modify the common actions <quote>Drop</quote> or
|
||||
<quote>Reject</quote>, simply copy <filename>action.Drop</filename> or
|
||||
<filename>Action.Reject</filename> to <filename class="directory">/etc/shorewall</filename>
|
||||
and modify that copy as desired.</para>
|
||||
<section>
|
||||
<title>Standard Actions In Shorewall 2.0</title>
|
||||
|
||||
<para>Beginning with Shorewall 2.0.0-Beta1, Shorewall includes a number of
|
||||
defined actions. These defined actions are listed in <filename>/usr/share/shorewall/actions.std</filename>.</para>
|
||||
|
||||
<para>The <filename>/usr/share/shorewall/actions.std</filename> file
|
||||
includes the common actions <quote>Drop</quote> for DROP policies and
|
||||
<quote>Reject</quote> for REJECT policies.</para>
|
||||
|
||||
<example>
|
||||
<title>Example of Using a Standard Action</title>
|
||||
|
||||
<para>Suppose that you wish to enable ftp from your local network to
|
||||
your firewall. In <filename>/etc/shorewall/rules</filename>:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO ...
|
||||
AllowFTP loc fw</programlisting>
|
||||
</example>
|
||||
|
||||
<para><filename>/usr/share/shorewall/actions.std</filename> is processed
|
||||
before <filename>/etc/shorewall/actions</filename> and if you have any
|
||||
actions defined with the same name as one in <filename>/usr/share/shorewall/actions.std</filename>,
|
||||
your version in <filename class="directory">/etc/shorewall</filename> will
|
||||
be the one used. So if you wish to modify a standard action, simply copy
|
||||
the associated action file from <filename class="directory">/usr/share/shorewall
|
||||
</filename>to <filename class="directory">/etc/shorewall and modify</filename>
|
||||
it to suit your needs. The next <command>shorewall restart</command> will
|
||||
cause your action to be installed in place of the standard one. In
|
||||
particular, if you want to modify the common actions <quote>Drop</quote>
|
||||
or <quote>Reject</quote>, simply copy <filename>action.Drop</filename> or
|
||||
<filename>Action.Reject</filename> to <filename class="directory">/etc/shorewall</filename>
|
||||
and modify that copy as desired.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Creating an Action using an Extension Script</title>
|
||||
|
||||
<para>There may be cases where you wish to create a chain with rules that
|
||||
can't be constructed using the tools defined in the action.template.
|
||||
In that case, you can use an extension script.<note><para>If you actually
|
||||
need an action to drop broadcast packets, use the <command>dropBcast</command>
|
||||
standard action rather than create one like this.</para></note></para>
|
||||
|
||||
<example>
|
||||
<title>An action to drop all broadcast packets</title>
|
||||
|
||||
<para>/etc/shorewall/actions<programlisting>DropBcasts</programlisting></para>
|
||||
|
||||
<para>/etc/shorewall/action.DropBcasts<programlisting># This file is empty</programlisting></para>
|
||||
|
||||
<para>/etc/shorewall/DropBcasts<programlisting>run_iptables -A DropBcasts -m pkttype --pkttype broadcast -j DROP</programlisting></para>
|
||||
</example>
|
||||
</section>
|
||||
</article>
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-01-17</pubdate>
|
||||
<pubdate>2004-02-17</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2002-2004</year>
|
||||
@ -57,7 +57,19 @@
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>Only the source address is checked against the blacklists.</para>
|
||||
<important>
|
||||
<para><emphasis role="bold">Only the source address is checked against
|
||||
the blacklists</emphasis>. Blacklists only stop blacklisted hosts from
|
||||
connecting to you — they do not stop you or your users from connecting
|
||||
to blacklisted hosts .</para>
|
||||
</important>
|
||||
|
||||
<important>
|
||||
<para><emphasis role="bold">Neither form of Shorewall blacklisting is
|
||||
appropriate for blacklisting 1,000s of different addresses</emphasis>.
|
||||
The blacklists will take forever to load and will have a very negative
|
||||
effect on firewall performance.</para>
|
||||
</important>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
||||
283
Shorewall-docs2/bridge.xml
Executable file
283
Shorewall-docs2/bridge.xml
Executable file
@ -0,0 +1,283 @@
|
||||
<?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-03-06</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, your kernel must
|
||||
meet the following requirements:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>It must contain bridge support (CONFIG_BRIDGE=m or
|
||||
CONFIG_BRIDGE=y).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>It must contain Netfilter physdev match support
|
||||
(CONFIG_IP_NF_MATCH_PHYSDEV=m or CONFIG_IP_NF_MATCH_PHYSDEV=y).
|
||||
Physdev match is available 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>
|
||||
</itemizedlist>
|
||||
|
||||
<para>You must also be running Shorewall 2.0.1 or later (users running
|
||||
Shorewall 2.0.0-RC* or Shorewall-2.0.0 may find the necessary updated
|
||||
files at <ulink url="http://shorewall.net/pub/shorewall/Bridging">http://shorewall.net/pub/shorewall/Bridging</ulink>).</para>
|
||||
</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 router would still be configured with IP addresses in 192.168.1.0/24.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Configuring the Bridge</title>
|
||||
|
||||
<para>Configuring the bridge itself is quite simple and used 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 bridge at system boot under
|
||||
<trademark>SuSE</trademark>. Here is an excerpt from a Debian
|
||||
<filename>/etc/network/interfaces</filename> file for a bridge:</para>
|
||||
|
||||
<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
|
||||
gateway:/etc/network#</programlisting>
|
||||
|
||||
<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. I have not tested Shorewall with a
|
||||
bridge configured without an IP address so if you try it and it
|
||||
doesn't work do not be surprised.</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 rfc1918,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>
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-15</pubdate>
|
||||
<pubdate>2004-02-20</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -80,9 +80,8 @@
|
||||
- define IP traffic accounting rules</para></listitem><listitem><para><filename>/etc/shorewall/actions</filename>
|
||||
and <filename>/usr/share/shorewall/action.template</filename> - define
|
||||
your own actions for rules in /etc/shorewall/rules (shorewall 1.4.9 and
|
||||
later).</para></listitem><listitem><para><filename>/etc/shorewall/actions.std</filename>
|
||||
- Actions defined by Shorewall. Included using the <link linkend="INCLUDE">INCLUDE
|
||||
command</link> by <filename>/etc/shorewall/actions</filename>.</para></listitem><listitem><para><filename>/etc/shorewall/actions.*</filename>
|
||||
later).</para></listitem><listitem><para><filename>/usr/share/shorewall/actions.std</filename>
|
||||
- Actions defined by Shorewall.</para></listitem><listitem><para><filename>/usr/share/shorewall/actions.*</filename>
|
||||
- Details of actions defined by Shorewall.</para></listitem></itemizedlist></para>
|
||||
</section>
|
||||
|
||||
@ -121,9 +120,9 @@ smtp,www,pop3,imap #Services running on the firewall</programlisting>
|
||||
|
||||
<para>Beginning with Shorewall version 1.4.2, any file may contain INCLUDE
|
||||
directives. An INCLUDE directive consists of the word INCLUDE followed by
|
||||
a file name and causes the contents of the named file to be logically
|
||||
included into the file containing the INCLUDE. File names given in an
|
||||
INCLUDE directive are assumed to reside in /etc/shorewall or in an
|
||||
a path name and causes the contents of the named file to be logically
|
||||
included into the file containing the INCLUDE. Relative path names given
|
||||
in an INCLUDE directive are assumed to reside in /etc/shorewall or in an
|
||||
alternate configuration directory if one has been specified for the
|
||||
command.</para>
|
||||
|
||||
@ -385,7 +384,7 @@ DNAT net loc:192.168.1.3 tcp 4000:4100</programlisting>
|
||||
numbers separated by colons.</para>
|
||||
|
||||
<example>
|
||||
<title>MAC Address of a NIC</title>
|
||||
<title>MAC Address of an Ethernet Controller</title>
|
||||
|
||||
<programlisting>      [root@gateway root]# <command>ifconfig eth0</command>
|
||||
     eth0 Link encap:Ethernet HWaddr <emphasis
|
||||
@ -404,7 +403,7 @@ role="bold">02:00:08:E3:FA:55</emphasis>
|
||||
Shorewall requires MAC addresses to be written in another way. In
|
||||
Shorewall, MAC addresses begin with a tilde (<quote>~</quote>) and consist
|
||||
of 6 hex numbers separated by hyphens. In Shorewall, the MAC address in
|
||||
the example above would be written <quote>~02-00-08-E3-FA-55</quote>.</para>
|
||||
the example above would be written <emphasis role="bold">~02-00-08-E3-FA-55</emphasis>.</para>
|
||||
|
||||
<note>
|
||||
<para>It is not necessary to use the special Shorewall notation in the
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-03</pubdate>
|
||||
<pubdate>2004-03-15</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -74,11 +74,17 @@
|
||||
<title>Problems in Version 2.0</title>
|
||||
|
||||
<section>
|
||||
<title>Shorewall 2.0.0-Beta 1</title>
|
||||
<title>Shorewall 2.0.0</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para></para>
|
||||
<para>When using an Action in the ACTIONS column of a rule, you may
|
||||
receive a warning message about the rule being a policy. While this
|
||||
warning may be safely ignored, it can be eliminated by installing
|
||||
<ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.0/firewall">this
|
||||
corrected firewall script</ulink> in /usr/share/shorewall as
|
||||
described above.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
BIN
Shorewall-docs2/images/bridge.png
Executable file
BIN
Shorewall-docs2/images/bridge.png
Executable file
Binary file not shown.
36671
Shorewall-docs2/images/bridge.vdx
Executable file
36671
Shorewall-docs2/images/bridge.vdx
Executable file
File diff suppressed because it is too large
Load Diff
BIN
Shorewall-docs2/images/bridge2.png
Executable file
BIN
Shorewall-docs2/images/bridge2.png
Executable file
Binary file not shown.
53411
Shorewall-docs2/images/bridge2.vdx
Executable file
53411
Shorewall-docs2/images/bridge2.vdx
Executable file
File diff suppressed because it is too large
Load Diff
Binary file not shown.
File diff suppressed because it is too large
Load Diff
BIN
Shorewall-docs2/images/network1.png
Executable file
BIN
Shorewall-docs2/images/network1.png
Executable file
Binary file not shown.
71311
Shorewall-docs2/images/network1.vdx
Executable file
71311
Shorewall-docs2/images/network1.vdx
Executable file
File diff suppressed because it is too large
Load Diff
@ -1,457 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>About My Network</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="id2590562"></a>About My Network</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>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
|
||||
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-13</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2815839">My Current Network</a></span></dt><dd><dl><dt><span class="section"><a href="#id2805857">Shorewall.conf</a></span></dt><dt><span class="section"><a href="#id2805874">Params File (Edited)</a></span></dt><dt><span class="section"><a href="#id2805900">Zones File</a></span></dt><dt><span class="section"><a href="#id2807778">Interfaces File</a></span></dt><dt><span class="section"><a href="#id2807811">Hosts File</a></span></dt><dt><span class="section"><a href="#id2807838">Routestopped File</a></span></dt><dt><span class="section"><a href="#RFC1918">RFC1918 File</a></span></dt><dt><span class="section"><a href="#id2810254">Blacklist File (Partial)</a></span></dt><dt><span class="section"><a href="#id2810278">Policy File</a></span></dt><dt><span class="section"><a href="#id2810297">Masq File</a></span></dt><dt><span class="section"><a href="#id2809846">NAT File</a></span></dt><dt><span class="section"><a href="#ProxyARP">Proxy ARP File</a></span></dt><dt><span class="section"><a href="#id2809906">Tunnels File (Shell variable TEXAS set in /etc/shorewall/params)</a></span></dt><dt><span class="section"><a href="#Actions">Actions File</a></span></dt><dt><span class="section"><a href="#id2809963">action.Mirrors File</a></span></dt><dt><span class="section"><a href="#id2809999">action.MyDrop</a></span></dt><dt><span class="section"><a href="#id2810040">action.MyReject</a></span></dt><dt><span class="section"><a href="#id2810089">Rules File (The shell variables are set in /etc/shorewall/params)</a></span></dt><dt><span class="section"><a href="#id2810110">/etc/network/interfaces</a></span></dt><dt><span class="section"><a href="#Dhcpd">/etc/dhcpd.conf (MAC Addresses Omitted)</a></span></dt></dl></dd></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2815839"></a>My Current Network</h2></div></div><div></div></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>I use a combination of One-to-one NAT and Proxy ARP, neither of
|
||||
which are relevant to a simple configuration with a single public IP
|
||||
address. If you have just a single public IP address, most of what you
|
||||
see here won't apply to your setup so beware of copying parts of
|
||||
this configuration and expecting them to work for you. What you copy may
|
||||
or may not work in your configuration.</p></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>The configuration shown here corresponds to Shorewall version
|
||||
2.0.0-Beta1. It may use features not available in earlier Shorewall
|
||||
releases.</p></div><p>I have DSL service and have 5 static IP addresses
|
||||
(206.124.146.176-180). My DSL “<span class="quote">modem</span>” (Fujitsu Speedport) is
|
||||
connected to eth0. I have a local network connected to eth2 (subnet
|
||||
192.168.1.0/24), a DMZ connected to eth1 (206.124.146.176/32) and a
|
||||
Wireless network connected to eth3 (192.168.3.0/24). Note that the IP
|
||||
address of eth1 is a duplicate of one on eth0.</p><p>I use:</p><div class="itemizedlist"><ul type="disc"><li><p>One-to-one NAT for Ursa (my personal system that dual-boots
|
||||
Mandrake 9.2 and Windows XP) - Internal address 192.168.1.5 and
|
||||
external address 206.124.146.178.</p></li><li><p>One-to-one NAT for EastepLaptop (My work system -- Windows XP
|
||||
SP2). Internal address 192.168.1.7 and external address
|
||||
206.124.146.180.</p></li><li><p>SNAT through 206.124.146.179 for my SuSE 9.0 Linux
|
||||
system (Wookie), my Wife's Windows XP system (Tarry), and
|
||||
our Windows XP laptop (Tipper) which connects through the
|
||||
Wireless Access Point (wap) via a Wireless Bridge (bridge).</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>While
|
||||
the distance between the WAP and where I usually use the laptop
|
||||
isn't very far (25 feet or so), using a WAC11 (CardBus wireless
|
||||
card) has proved very unsatisfactory (lots of lost connections). By
|
||||
replacing the WAC11 with the WET11 wireless bridge, I have virtually
|
||||
eliminated these problems (Being an old radio tinkerer (K7JPV), I was
|
||||
also able to eliminate the disconnects by hanging a piece of aluminum
|
||||
foil on the family room wall. Needless to say, my wife Tarry rejected
|
||||
that as a permanent solution :-).</p></div></li></ul></div><p>The firewall runs on a 256MB PII/233 with Debian Sarge (Testing).</p><p>Wookie, Ursa and the Firewall all run Samba and the Firewall acts as
|
||||
a WINS server.</p><p>The wireless network connects to eth3 via a LinkSys WAP11.
|
||||
In additional to using the rather weak WEP 40-bit encryption (64-bit with
|
||||
the 24-bit preamble), I use <a href="MAC_Validation.html" target="_self">MAC
|
||||
verification</a>. This is still a weak combination and if I lived near
|
||||
a wireless “<span class="quote">hot spot</span>”, I would probably add IPSEC or
|
||||
something similar to my WiFi->local connections.</p><p>The single system in the DMZ (address 206.124.146.177) runs postfix,
|
||||
Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP
|
||||
server (Pure-ftpd) under RedHat 9.0. The system also runs fetchmail to
|
||||
fetch our email from our old and current ISPs. That server is managed
|
||||
through Proxy ARP.</p><p>The firewall system itself runs a DHCP server that serves the local
|
||||
network.</p><p>All administration and publishing is done using ssh/scp. I have a
|
||||
desktop environment installed on the firewall but I am not usually logged
|
||||
in to it. X applications tunnel through SSH to Ursa. The server also has a
|
||||
desktop environment installed and that desktop environment is available
|
||||
via XDMCP from the local zone. For the most part though, X tunneled
|
||||
through SSH is used for server administration and the server runs at run
|
||||
level 3 (multi-user console mode on RedHat).</p><p>I run an SNMP server on my firewall to serve <a href="http://www.ee.ethz.ch/~oetiker/webtools/mrtg/" target="_self">MRTG</a> running
|
||||
in the DMZ.</p><div align="center"><img src="images/network.png" align="middle" /></div><p>The
|
||||
ethernet interface in the Server is configured with IP address
|
||||
206.124.146.177, netmask 255.255.255.0. The server's default gateway
|
||||
is 206.124.146.254 (Router at my ISP. This is the same default gateway
|
||||
used by the firewall itself). On the firewall, an entry in my
|
||||
/etc/network/interfaces file (see below) adds a host route to
|
||||
206.124.146.177 through eth1 when that interface is brought up.</p><p>Ursa (192.168.1.5 A.K.A. 206.124.146.178) runs a PPTP server for
|
||||
Road Warrior access.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2805857"></a>Shorewall.conf</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGFILE=/var/log/messages
|
||||
LOGRATE=
|
||||
LOGBURST=
|
||||
LOGUNCLEAN=$LOG
|
||||
BLACKLIST_LOGLEVEL=
|
||||
LOGNEWNOTSYN=$LOG
|
||||
MACLIST_LOG_LEVEL=$LOG
|
||||
TCP_FLAGS_LOG_LEVEL=$LOG
|
||||
RFC1918_LOG_LEVEL=$LOG
|
||||
SMURF_LOG_LEVEL=
|
||||
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
|
||||
SHOREWALL_SHELL=/bin/ash
|
||||
SUBSYSLOCK= #I run Debian which doesn't use service locks
|
||||
STATEDIR=/var/state/shorewall
|
||||
MODULESDIR=
|
||||
FW=fw
|
||||
IP_FORWARDING=On
|
||||
ADD_IP_ALIASES=Yes
|
||||
ADD_SNAT_ALIASES=Yes
|
||||
TC_ENABLED=Yes
|
||||
CLEAR_TC=No
|
||||
MARK_IN_FORWARD_CHAIN=No
|
||||
CLAMPMSS=Yes
|
||||
ROUTE_FILTER=No
|
||||
DETECT_DNAT_IPADDRS=Yes
|
||||
MUTEX_TIMEOUT=60
|
||||
NEWNOTSYN=Yes
|
||||
BLACKLISTNEWONLY=Yes
|
||||
BLACKLIST_DISPOSITION=DROP
|
||||
MACLIST_DISPOSITION=REJECT
|
||||
TCP_FLAGS_DISPOSITION=DROP
|
||||
</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2805874"></a>Params File (Edited)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">MIRRORS=<list of shorewall mirror ip addresses>
|
||||
NTPSERVERS=<list of the NTP servers I sync with>
|
||||
TEXAS=<ip address of gateway in Dallas>
|
||||
LOG=info</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2805900"></a>Zones File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE DISPLAY COMMENTS
|
||||
net Internet Internet
|
||||
WiFi Wireless Wireless Network on eth3
|
||||
dmz DMZ Demilitarized zone
|
||||
loc Local Local networks
|
||||
tx Texas Peer Network in Dallas
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807778"></a>Interfaces File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This is set up so that I can start the firewall before bringing
|
||||
up my Ethernet interfaces.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INERFACE BROADCAST OPTIONS
|
||||
net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags,nosmurfs
|
||||
loc eth2 192.168.1.255 dhcp,detectnets
|
||||
dmz eth1 -
|
||||
WiFi eth3 192.168.3.255 dhcp,maclist,detectnets
|
||||
- texas 192.168.9.255
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807811"></a>Hosts File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
|
||||
tx texas:192.168.8.0/22
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807838"></a>Routestopped File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE HOST(S)
|
||||
eth1 206.124.146.177
|
||||
eth2 -
|
||||
eth3 192.168.3.0/24
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="RFC1918"></a>RFC1918 File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>I use a stripped-down file which doesn't have to be updated
|
||||
when the IANA allocates a block of IP addresses.</p></blockquote></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SUBNET TARGET
|
||||
169.254.0.0/16 DROP # DHCP autoconfig
|
||||
172.16.0.0/12 logdrop # RFC 1918
|
||||
192.0.2.0/24 logdrop # Example addresses
|
||||
192.168.0.0/16 logdrop # RFC 1918
|
||||
10.24.60.56 DROP # Some idiot in my broadcast domain
|
||||
# has a box configured with this
|
||||
# address.
|
||||
10.0.0.0/8 logdrop # Reserved (RFC 1918)</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810254"></a>Blacklist File (Partial)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ADDRESS/SUBNET PROTOCOL PORT
|
||||
0.0.0.0/0 udp 1434
|
||||
0.0.0.0/0 tcp 1433
|
||||
0.0.0.0/0 tcp 8081
|
||||
0.0.0.0/0 tcp 57
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810278"></a>Policy File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY LOG LEVEL BURST:LIMIT
|
||||
fw fw ACCEPT # For testing fw->fw rules
|
||||
loc net ACCEPT # Allow all net traffic from local net
|
||||
$FW loc ACCEPT # Allow local access from the firewall
|
||||
$FW tx ACCEPT # Allow firewall access to texas
|
||||
loc tx ACCEPT # Allow local net access to texas
|
||||
loc fw REJECT $LOG # Reject loc->fw and log
|
||||
WiFi net ACCEPT # Allow internet access from wirless
|
||||
net all DROP $LOG 10/sec:40 # Rate limit and
|
||||
# DROP net->all
|
||||
all all REJECT $LOG # Reject and log the rest
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810297"></a>Masq File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>Although most of our internal systems use one-to-one NAT, my
|
||||
wife's system (192.168.1.4) uses IP Masquerading (actually SNAT)
|
||||
as does my SuSE system (192.168.1.3), our laptop (192.168.3.8) and
|
||||
visitors with laptops.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
|
||||
eth0:2 eth2 206.124.146.179
|
||||
eth0 eth3 206.124.146.179
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||||
</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809846"></a>NAT File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
|
||||
206.124.146.178 eth0:0 192.168.1.5 No No
|
||||
206.124.146.180 eth0:1 192.168.1.7 No No
|
||||
#
|
||||
# The following entry allows the server to be accessed through an address in
|
||||
# the local network. This is convenient when I'm on the road and connected
|
||||
# to the PPTP server. By doing this, I don't need to set my client's default
|
||||
# gateway to route through the tunnel.
|
||||
#
|
||||
192.168.1.193 eth2:0 206.124.146.177 No No
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="ProxyARP"></a>Proxy ARP File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
|
||||
206.124.146.177 eth1 eth0 Yes
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809906"></a>Tunnels File (Shell variable TEXAS set in /etc/shorewall/params)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY ZONE PORT
|
||||
gre net $TEXAS
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Actions"></a>Actions File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION
|
||||
DropSMB #Silently Drops Microsoft SMB Traffic
|
||||
RejectSMB #Silently Reject Microsoft SMB Traffic
|
||||
DropUPnP #Silently Drop UPnP Probes
|
||||
RejectAuth #Silently Reject Auth
|
||||
DropPing #Silently Drop Ping
|
||||
DropDNSrep #Silently Drop DNS Replies
|
||||
AllowPing #Accept Ping
|
||||
|
||||
Mirrors #Accept traffic from the Shorewall Mirror sites
|
||||
|
||||
MyDrop:DROP #My DROP common action
|
||||
MyReject:REJECT #My REJECT common action
|
||||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809963"></a>action.Mirrors File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>The $MIRRORS variable expands to a list of approximately 10 IP
|
||||
addresses. So moving these checks into a separate chain reduces the
|
||||
number of rules that most net->dmz traffic needs to traverse.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
|
||||
# PORT PORT(S) DEST LIMIT
|
||||
ACCEPT $MIRRORS
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809999"></a>action.MyDrop</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This is my common action for the DROP policy. It is like the
|
||||
standard <span class="bold"><b>Reject</b></span> action except that it
|
||||
allows “<span class="quote">Ping</span>”.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
|
||||
# PORT(S) PORT(S) LIMIT GROUP
|
||||
RejectAuth
|
||||
AllowPing
|
||||
dropBcast
|
||||
DropSMB
|
||||
DropUPnP
|
||||
dropNonSyn
|
||||
DropDNSrep</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810040"></a>action.MyReject</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This is my common action for the REJECT policy. It is like the
|
||||
standard <span class="bold"><b>Drop</b></span> action except that it
|
||||
allows “<span class="quote">Ping</span>”.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
|
||||
# PORT(S) PORT(S) LIMIT GROUP
|
||||
RejectAuth
|
||||
AllowPing
|
||||
dropBcast
|
||||
RejectSMB
|
||||
DropUPnP
|
||||
dropNonSyn
|
||||
DropDNSrep
|
||||
DROP loc:eth2:!192.168.1.0/24 #So that my braindead Windows[tm] XP system doesn't flood my log
|
||||
#with NTP requests with a source address in 16.0.0.0/8 (address of
|
||||
#its PPTP tunnel to HP).</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810089"></a>Rules File (The shell variables are set in /etc/shorewall/params)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">###############################################################################################################################################################################
|
||||
#RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT ORIGINAL RATE USER
|
||||
# PORT(S) DEST:SNAT SET
|
||||
###############################################################################################################################################################################
|
||||
# Local Network to Internet - Reject attempts by Trojans to call home
|
||||
#
|
||||
REJECT:$LOG loc net tcp 6667
|
||||
#
|
||||
# Stop NETBIOS crap since our policy is ACCEPT
|
||||
#
|
||||
REJECT loc net tcp 137,445
|
||||
REJECT loc net udp 137:139
|
||||
#
|
||||
DROP loc:!192.168.1.0/24 net
|
||||
|
||||
QUEUE loc net udp
|
||||
QUEUE loc fw udp
|
||||
QUEUE loc net tcp
|
||||
###############################################################################################################################################################################
|
||||
# Local Network to Firewall
|
||||
#
|
||||
DROP loc:!192.168.1.0/24 fw
|
||||
ACCEPT loc fw tcp ssh,time,10000,swat,137,139,445
|
||||
ACCEPT loc fw udp snmp,ntp,445
|
||||
ACCEPT loc fw udp 137:139
|
||||
ACCEPT loc fw udp 1024: 137
|
||||
###############################################################################################################################################################################
|
||||
# Local Network to DMZ
|
||||
#
|
||||
DROP loc:!192.168.1.0/24 dmz
|
||||
REJECT loc dmz tcp 465
|
||||
ACCEPT loc dmz udp domain,xdmcp
|
||||
ACCEPT loc dmz tcp www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,10027,pop3 -
|
||||
###############################################################################################################################################################################
|
||||
# Internet to DMZ
|
||||
#
|
||||
DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.179,206.124.146.178
|
||||
ACCEPT net dmz tcp smtp,www,ftp,imaps,domain,cvspserver,https -
|
||||
ACCEPT net dmz udp domain
|
||||
ACCEPT net dmz udp 33434:33436
|
||||
Mirrors net dmz tcp rsync
|
||||
#ACCEPT:$LOG net dmz tcp 32768:61000 20
|
||||
###############################################################################################################################################################################
|
||||
#
|
||||
# Net to Local
|
||||
#
|
||||
# When I'm "on the road", the following two rules allow me VPN access back home.
|
||||
#
|
||||
ACCEPT net loc:192.168.1.5 tcp 1723
|
||||
ACCEPT net loc:192.168.1.5 gre
|
||||
#
|
||||
# ICQ
|
||||
#
|
||||
ACCEPT net loc:192.168.1.5 tcp 4000:4100
|
||||
#
|
||||
# Real Audio
|
||||
#
|
||||
ACCEPT net loc:192.168.1.5 udp 6970:7170
|
||||
#
|
||||
# Overnet
|
||||
#
|
||||
#ACCEPT net loc:192.168.1.5 tcp 4662
|
||||
#ACCEPT net loc:192.168.1.5 udp 12112
|
||||
###############################################################################################################################################################################
|
||||
# DMZ to Internet
|
||||
#
|
||||
ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,8080
|
||||
ACCEPT dmz net udp domain
|
||||
ACCEPT dmz net:$POPSERVERS tcp pop3
|
||||
#ACCEPT dmz net:206.191.151.2 tcp pop3
|
||||
#ACCEPT dmz net:66.216.26.115 tcp pop3
|
||||
#
|
||||
# Something is wrong with the FTP connection tracking code or there is some client out there
|
||||
# that is sending a PORT command which that code doesn't understand. Either way,
|
||||
# the following works around the problem.
|
||||
#
|
||||
ACCEPT:$LOG dmz net tcp 1024: 20
|
||||
###############################################################################################################################################################################
|
||||
# DMZ to Firewall -- ntp & snmp, Silently reject Auth
|
||||
#
|
||||
ACCEPT dmz fw udp ntp ntp
|
||||
ACCEPT dmz fw tcp snmp,ssh
|
||||
ACCEPT dmz fw udp snmp
|
||||
REJECT dmz fw tcp auth
|
||||
###############################################################################################################################################################################
|
||||
# DMZ to Internet
|
||||
#
|
||||
ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,8080
|
||||
ACCEPT dmz net udp domain
|
||||
ACCEPT dmz net:$POPSERVERS tcp pop3
|
||||
#ACCEPT dmz net:206.191.151.2 tcp pop3
|
||||
#ACCEPT dmz net:66.216.26.115 tcp pop3
|
||||
#
|
||||
# Something is wrong with the FTP connection tracking code or there is some client out there
|
||||
# that is sending a PORT command which that code doesn't understand. Either way,
|
||||
# the following works around the problem.
|
||||
#
|
||||
ACCEPT:$LOG dmz net tcp 1024: 20
|
||||
###############################################################################################################################################################################
|
||||
# DMZ to Firewall -- ntp & snmp, Silently reject Auth
|
||||
#
|
||||
ACCEPT dmz fw udp ntp ntp
|
||||
ACCEPT dmz fw tcp snmp,ssh
|
||||
ACCEPT dmz fw udp snmp
|
||||
REJECT dmz fw tcp auth
|
||||
###############################################################################################################################################################################
|
||||
#
|
||||
# DMZ to Local Network
|
||||
#
|
||||
ACCEPT dmz loc tcp smtp,6001:6010
|
||||
ACCEPT dmz loc tcp 111
|
||||
ACCEPT dmz loc udp
|
||||
###############################################################################################################################################################################
|
||||
# Internet to Firewall
|
||||
#
|
||||
REJECT net fw tcp www
|
||||
ACCEPT net dmz udp 33434:33435
|
||||
###############################################################################################################################################################################
|
||||
# WIFI to Firewall
|
||||
#
|
||||
ACCEPT WiFi fw tcp ssh,137,139,445
|
||||
ACCEPT WiFi fw udp 137:139,445
|
||||
ACCEPT WiFi fw udp 1024: 137
|
||||
ACCEPT WiFi fw udp ntp ntp
|
||||
###############################################################################################################################################################################
|
||||
# Firewall to WIFI
|
||||
#
|
||||
ACCEPT fw WiFi tcp 137,139,445
|
||||
ACCEPT fw WiFi udp 137:139,445
|
||||
ACCEPT fw WiFi udp 1024: 137
|
||||
ACCEPT fw WiFi udp ntp ntp
|
||||
##############################################################################################################################################################################
|
||||
# WIFI to DMZ
|
||||
#
|
||||
DNAT- WiFi dmz:206.124.146.177 all - - 192.168.1.193
|
||||
ACCEPT WiFi dmz tcp smtp,www,ftp,imaps,domain,https,ssh,8080 -
|
||||
ACCEPT WiFi dmz udp domain
|
||||
##############################################################################################################################################################################
|
||||
# WIFI to loc
|
||||
#
|
||||
ACCEPT WiFi loc udp 137:139
|
||||
ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389
|
||||
ACCEPT WiFi loc udp 1024: 137
|
||||
ACCEPT WiFi loc udp 177
|
||||
##############################################################################################################################################################################
|
||||
# loc to WiFi
|
||||
#
|
||||
ACCEPT loc WiFi udp 137:139
|
||||
ACCEPT loc WiFi tcp 137,139,445
|
||||
ACCEPT loc WiFi udp 1024: 137
|
||||
ACCEPT loc WiFi tcp 6000:6010
|
||||
###############################################################################################################################################################################
|
||||
# Firewall to Internet
|
||||
#
|
||||
ACCEPT fw net:$NTPSERVERS udp ntp ntp
|
||||
#ACCEPT fw net:$POPSERVERS tcp pop3
|
||||
ACCEPT fw net udp domain
|
||||
ACCEPT fw net tcp domain,www,https,ssh,1723,whois,1863,ftp,2702,2703,7
|
||||
ACCEPT fw net udp 33435:33535
|
||||
ACCEPT fw net icmp
|
||||
###############################################################################################################################################################################
|
||||
# Firewall to DMZ
|
||||
#
|
||||
ACCEPT fw dmz tcp www,ftp,ssh,smtp
|
||||
ACCEPT fw dmz udp domain
|
||||
REJECT fw dmz udp 137:139
|
||||
###############################################################################################################################################################################
|
||||
# Ping
|
||||
#
|
||||
ACCEPT all all icmp 8
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810110"></a>/etc/network/interfaces</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This file is Debian specific. My additional entry (which is
|
||||
displayed in <span class="bold"><b>bold type</b></span>) adds a route
|
||||
to my DMZ server when eth1 is brought up. It allows me to enter
|
||||
“<span class="quote">Yes</span>” in the HAVEROUTE column of <a href="#ProxyARP" title="Proxy ARP File">my
|
||||
Proxy ARP file</a>.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">...
|
||||
auto eth1
|
||||
iface eth1 inet static
|
||||
address 206.124.146.176
|
||||
netmask 255.255.255.255
|
||||
broadcast 0.0.0.0
|
||||
<span class="bold"><b>up ip route add 206.124.146.177 dev eth1
|
||||
</b></span>...</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Dhcpd"></a>/etc/dhcpd.conf (MAC Addresses Omitted)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>While this is a little off-topic, I've included it to show
|
||||
how to set up DHCP on two interfaces.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">default-lease-time 67200; max-lease-time 67200;
|
||||
get-lease-hostnames on;
|
||||
|
||||
group {
|
||||
option subnet-mask 255.255.255.0;
|
||||
option broadcast-address 192.168.1.255;
|
||||
option routers 192.168.1.254;
|
||||
option ntp-servers 192.168.1.254;
|
||||
option domain-name-servers 192.168.1.193;
|
||||
option netbios-name-servers 192.168.1.254;
|
||||
option domain-name "shorewall.net";
|
||||
option netbios-dd-server 192.168.1.254;
|
||||
option netbios-node-type 8;
|
||||
option netbios-scope "";
|
||||
|
||||
subnet 192.168.1.0 netmask 255.255.255.0 {
|
||||
range 192.168.1.11 192.168.1.20;
|
||||
}
|
||||
|
||||
host ursa.shorewall.net {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.1.5;
|
||||
}
|
||||
|
||||
host eastept1 {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.1.7;
|
||||
}
|
||||
|
||||
host tarry {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.1.4;
|
||||
}
|
||||
|
||||
host wookie.shorewall.net {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.1.3;
|
||||
}
|
||||
|
||||
host testws.shorewall.net {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.1.6;
|
||||
}
|
||||
|
||||
host printer.shorewall.net {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.1.10;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
group {
|
||||
option subnet-mask 255.255.255.0;
|
||||
option broadcast-address 192.168.3.255;
|
||||
option routers 192.168.3.254;
|
||||
option ntp-servers 192.168.3.254;
|
||||
option domain-name-servers 206.124.146.177;
|
||||
option netbios-name-servers 192.168.3.254;
|
||||
option domain-name "shorewall.net";
|
||||
option netbios-dd-server 192.168.3.254;
|
||||
option netbios-node-type 8;
|
||||
option netbios-scope "";
|
||||
|
||||
subnet 192.168.3.0 netmask 255.255.255.0 {
|
||||
range 192.168.3.11 192.168.3.20;
|
||||
}
|
||||
|
||||
host easteplaptop {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.3.7;
|
||||
}
|
||||
|
||||
host tipper.shorewall.net {
|
||||
hardware ethernet …;
|
||||
fixed-address 192.168.3.8;
|
||||
}</pre></td></tr></table></blockquote></div></div></div></div></body></html>
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-14</pubdate>
|
||||
<pubdate>2004-03-16</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -47,37 +47,37 @@
|
||||
|
||||
<caution>
|
||||
<para>The configuration shown here corresponds to Shorewall version
|
||||
2.0.0-Beta2. It may use features not available in earlier Shorewall
|
||||
releases.</para>
|
||||
2.0.1 (that's right -- I am running a version of Shorewall that is
|
||||
not yet released). My configuration uses features not available in
|
||||
earlier Shorewall releases.</para>
|
||||
</caution>
|
||||
|
||||
<para>I have DSL service and have 5 static IP addresses
|
||||
(206.124.146.176-180). My DSL <quote>modem</quote> (Fujitsu Speedport) is
|
||||
connected to eth0. I have a local network connected to eth2 (subnet
|
||||
192.168.1.0/24), a DMZ connected to eth1 (206.124.146.176/32) and a
|
||||
Wireless network connected to eth3 (192.168.3.0/24). Note that the IP
|
||||
address of eth1 is a duplicate of one on eth0.</para>
|
||||
192.168.1.0/24) and a DMZ connected to eth1 (206.124.146.176/32). Note
|
||||
that the IP address of eth1 is a duplicate of one on eth0.</para>
|
||||
|
||||
<para>I use:</para>
|
||||
<para>In this configuration:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>One-to-one NAT for Ursa (my personal system that dual-boots
|
||||
Mandrake 9.2 and Windows XP) - Internal address 192.168.1.5 and
|
||||
external address 206.124.146.178.</para>
|
||||
<para>I use one-to-one NAT for Ursa (my personal system that
|
||||
dual-boots Mandrake 9.2 and Windows XP) - Internal address 192.168.1.5
|
||||
and external address 206.124.146.178.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>One-to-one NAT for EastepLaptop (My work system -- Windows XP
|
||||
SP2). Internal address 192.168.1.7 and external address
|
||||
<para>I use one-to-one NAT for EastepLaptop (My work system -- Windows
|
||||
XP SP2). Internal address 192.168.1.7 and external address
|
||||
206.124.146.180.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>SNAT through 206.124.146.179 for  my SuSE 9.0 Linux
|
||||
<para>I use SNAT through 206.124.146.179 for  my SuSE 9.0 Linux
|
||||
system (Wookie), my Wife's Windows XP system (Tarry), and
|
||||
our  Windows XP laptop (Tipper) which connects through the
|
||||
Wireless Access Point (wap) via a Wireless Bridge (bridge).<note><para>While
|
||||
Wireless Access Point (wap) via a Wireless Bridge (wet).<note><para>While
|
||||
the distance between the WAP and where I usually use the laptop
|
||||
isn't very far (25 feet or so), using a WAC11 (CardBus wireless
|
||||
card) has proved very unsatisfactory (lots of lost connections). By
|
||||
@ -89,17 +89,24 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>I have Wookie (193.168.1.3) configured as a 3-port bridge. Squid
|
||||
runs on this system and is configured as a transparent proxy.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The firewall runs on a 256MB PII/233 with Debian Sarge (Testing).</para>
|
||||
|
||||
<para>Wookie, Ursa and the Firewall all run Samba and the Firewall acts as
|
||||
a WINS server.</para>
|
||||
<para>Wookie and Ursa run Samba and the Wookie acts as a WINS server.</para>
|
||||
|
||||
<para>The wireless network connects to eth3 via a LinkSys WAP11. 
|
||||
In additional to using the rather weak WEP 40-bit encryption (64-bit with
|
||||
the 24-bit preamble), I use <ulink url="MAC_Validation.html">MAC
|
||||
verification</ulink>. This is still a weak combination and if I lived near
|
||||
a wireless <quote>hot spot</quote>, I would probably add IPSEC or
|
||||
something similar to my WiFi->local connections.</para>
|
||||
<para>The wireless network connects to Wookie's eth2 via a LinkSys
|
||||
WAP11.  In additional to using the rather weak WEP 40-bit
|
||||
encryption (64-bit with the 24-bit preamble), I use <ulink
|
||||
url="MAC_Validation.html">MAC verification</ulink>. This is still a weak
|
||||
combination and if I lived near a wireless <quote>hot spot</quote>, I
|
||||
would probably add IPSEC or something similar to my WiFi->local
|
||||
connections.</para>
|
||||
|
||||
<para>The single system in the DMZ (address 206.124.146.177) runs postfix,
|
||||
Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP
|
||||
@ -130,6 +137,10 @@
|
||||
|
||||
<para>Ursa (192.168.1.5 A.K.A. 206.124.146.178) runs a PPTP server for
|
||||
Road Warrior access.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Firewall Configuration</title>
|
||||
|
||||
<section>
|
||||
<title>Shorewall.conf</title>
|
||||
@ -187,7 +198,6 @@ LOG=info</programlisting></para>
|
||||
<blockquote>
|
||||
<programlisting>#ZONE DISPLAY COMMENTS
|
||||
net Internet Internet
|
||||
WiFi Wireless Wireless Network on eth3
|
||||
dmz DMZ Demilitarized zone
|
||||
loc Local Local networks
|
||||
tx Texas Peer Network in Dallas
|
||||
@ -206,7 +216,6 @@ tx Texas Peer Network in Dallas
|
||||
net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags,nosmurfs
|
||||
loc eth2 192.168.1.255 dhcp,detectnets
|
||||
dmz eth1 -
|
||||
WiFi eth3 192.168.3.255 dhcp,maclist,detectnets
|
||||
- texas 192.168.9.255
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
@ -229,7 +238,6 @@ tx         

|
||||
<programlisting>#INTERFACE HOST(S)
|
||||
eth1 206.124.146.177
|
||||
eth2 -
|
||||
eth3 192.168.3.0/24
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
@ -262,6 +270,7 @@ eth3 192.168.3.0/24
|
||||
<programlisting>#ADDRESS/SUBNET PROTOCOL PORT
|
||||
0.0.0.0/0 udp 1434
|
||||
0.0.0.0/0 tcp 1433
|
||||
0.0.0.0/0 tcp 3127
|
||||
0.0.0.0/0 tcp 8081
|
||||
0.0.0.0/0 tcp 57
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
|
||||
@ -279,7 +288,6 @@ $FW loc ACCEPT # Allo
|
||||
$FW tx ACCEPT # Allow firewall access to texas
|
||||
loc tx ACCEPT # Allow local net access to texas
|
||||
loc fw REJECT $LOG # Reject loc->fw and log
|
||||
WiFi net ACCEPT # Allow internet access from wirless
|
||||
net all DROP $LOG 10/sec:40 # Rate limit and
|
||||
# DROP net->all
|
||||
all all REJECT $LOG # Reject and log the rest
|
||||
@ -293,12 +301,11 @@ all all REJECT $LOG # Reje
|
||||
<blockquote>
|
||||
<para>Although most of our internal systems use one-to-one NAT, my
|
||||
wife's system (192.168.1.4) uses IP Masquerading (actually SNAT)
|
||||
as does my SuSE system (192.168.1.3), our laptop (192.168.3.8) and
|
||||
as do my SuSE system (192.168.1.3), our laptop (192.168.3.8) and
|
||||
visitors with laptops.</para>
|
||||
|
||||
<programlisting>#INTERFACE SUBNET ADDRESS
|
||||
eth0:2 eth2 206.124.146.179
|
||||
eth0 eth3 206.124.146.179
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||||
</programlisting>
|
||||
</blockquote>
|
||||
@ -428,23 +435,17 @@ REJECT:$LOG loc net tcp
|
||||
REJECT loc net tcp 137,445
|
||||
REJECT loc net udp 137:139
|
||||
#
|
||||
DROP loc:!192.168.1.0/24 net
|
||||
|
||||
QUEUE loc net udp
|
||||
QUEUE loc fw udp
|
||||
QUEUE loc net tcp
|
||||
###############################################################################################################################################################################
|
||||
# Local Network to Firewall
|
||||
#
|
||||
DROP loc:!192.168.1.0/24 fw
|
||||
ACCEPT loc fw tcp ssh,time,10000,swat,137,139,445
|
||||
ACCEPT loc fw udp snmp,ntp,445
|
||||
ACCEPT loc fw udp 137:139
|
||||
ACCEPT loc fw udp 1024: 137
|
||||
ACCEPT loc fw tcp ssh,time
|
||||
ACCEPT loc fw udp snmp,ntp
|
||||
###############################################################################################################################################################################
|
||||
# Local Network to DMZ
|
||||
#
|
||||
DROP loc:!192.168.1.0/24 dmz
|
||||
REJECT loc dmz tcp 465
|
||||
ACCEPT loc dmz udp domain,xdmcp
|
||||
ACCEPT loc dmz tcp www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,10027,pop3 -
|
||||
@ -500,72 +501,17 @@ ACCEPT dmz fw tcp
|
||||
ACCEPT dmz fw udp snmp
|
||||
REJECT dmz fw tcp auth
|
||||
###############################################################################################################################################################################
|
||||
# DMZ to Internet
|
||||
#
|
||||
ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,8080
|
||||
ACCEPT dmz net udp domain
|
||||
ACCEPT dmz net:$POPSERVERS tcp pop3
|
||||
#ACCEPT dmz net:206.191.151.2 tcp pop3
|
||||
#ACCEPT dmz net:66.216.26.115 tcp pop3
|
||||
#
|
||||
# Something is wrong with the FTP connection tracking code or there is some client out there
|
||||
# that is sending a PORT command which that code doesn't understand. Either way,
|
||||
# the following works around the problem.
|
||||
#
|
||||
ACCEPT:$LOG dmz net tcp 1024: 20
|
||||
###############################################################################################################################################################################
|
||||
# DMZ to Firewall -- ntp & snmp, Silently reject Auth
|
||||
#
|
||||
ACCEPT dmz fw udp ntp ntp
|
||||
ACCEPT dmz fw tcp snmp,ssh
|
||||
ACCEPT dmz fw udp snmp
|
||||
REJECT dmz fw tcp auth
|
||||
###############################################################################################################################################################################
|
||||
#
|
||||
# DMZ to Local Network
|
||||
#
|
||||
ACCEPT dmz loc tcp smtp,6001:6010
|
||||
ACCEPT dmz loc tcp 111
|
||||
ACCEPT dmz loc udp
|
||||
ACCEPT dmz:206.124.146.177 loc:192.168.1.3 tcp 111
|
||||
ACCEPT dmz:206.124.146.177 loc:192.168.1.3 udp
|
||||
###############################################################################################################################################################################
|
||||
# Internet to Firewall
|
||||
#
|
||||
REJECT net fw tcp www
|
||||
ACCEPT net dmz udp 33434:33435
|
||||
###############################################################################################################################################################################
|
||||
# WIFI to Firewall
|
||||
#
|
||||
ACCEPT WiFi fw tcp ssh,137,139,445
|
||||
ACCEPT WiFi fw udp 137:139,445
|
||||
ACCEPT WiFi fw udp 1024: 137
|
||||
ACCEPT WiFi fw udp ntp ntp
|
||||
###############################################################################################################################################################################
|
||||
# Firewall to WIFI
|
||||
#
|
||||
ACCEPT fw WiFi tcp 137,139,445
|
||||
ACCEPT fw WiFi udp 137:139,445
|
||||
ACCEPT fw WiFi udp 1024: 137
|
||||
ACCEPT fw WiFi udp ntp ntp
|
||||
##############################################################################################################################################################################
|
||||
# WIFI to DMZ
|
||||
#
|
||||
DNAT- WiFi dmz:206.124.146.177 all - - 192.168.1.193
|
||||
ACCEPT WiFi dmz tcp smtp,www,ftp,imaps,domain,https,ssh,8080 -
|
||||
ACCEPT WiFi dmz udp domain
|
||||
##############################################################################################################################################################################
|
||||
# WIFI to loc
|
||||
#
|
||||
ACCEPT WiFi loc udp 137:139
|
||||
ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389
|
||||
ACCEPT WiFi loc udp 1024: 137
|
||||
ACCEPT WiFi loc udp 177
|
||||
##############################################################################################################################################################################
|
||||
# loc to WiFi
|
||||
#
|
||||
ACCEPT loc WiFi udp 137:139
|
||||
ACCEPT loc WiFi tcp 137,139,445
|
||||
ACCEPT loc WiFi udp 1024: 137
|
||||
ACCEPT loc WiFi tcp 6000:6010
|
||||
|
||||
###############################################################################################################################################################################
|
||||
# Firewall to Internet
|
||||
#
|
||||
@ -694,4 +640,241 @@ group {
|
||||
</blockquote>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Bridge (Wookie) Configuration</title>
|
||||
|
||||
<para>As mentioned above, Wookie acts as a bridge. It's view of the
|
||||
network is diagrammed in the following figure.</para>
|
||||
|
||||
<graphic fileref="images/network1.png" />
|
||||
|
||||
<para>I've included the files that I used to configure that system --
|
||||
some of them are SuSE-specific.</para>
|
||||
|
||||
<para>The configuration on Wookie can be modified to test various bridging
|
||||
features -- otherwise, it serves to isolate the Wireless network from the
|
||||
rest of our systems.</para>
|
||||
|
||||
<section>
|
||||
<title>shorewall.conf</title>
|
||||
|
||||
<blockquote>
|
||||
<para>Only the changes from the defaults are shown.</para>
|
||||
|
||||
<programlisting>BRIDGING=Yes</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>zones</title>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#ZONE DISPLAY COMMENTS
|
||||
net Net Internet
|
||||
loc Local Local networks
|
||||
WiFi WireLess Wireless Network
|
||||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
|
||||
</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>policy</title>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#SOURCE DEST POLICY LOG LIMIT:BURST
|
||||
fw fw ACCEPT
|
||||
loc net ACCEPT
|
||||
net loc ACCEPT
|
||||
net fw ACCEPT
|
||||
loc fw ACCEPT
|
||||
loc WiFi ACCEPT
|
||||
fw WiFi ACCEPT
|
||||
fw net ACCEPT
|
||||
fw loc ACCEPT
|
||||
#
|
||||
# THE FOLLOWING POLICY MUST BE LAST
|
||||
#
|
||||
all all REJECT info
|
||||
#LAST LINE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>interfaces</title>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||||
- br0 192.168.1.255
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>hosts</title>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#ZONE HOST(S) OPTIONS
|
||||
net br0:eth1
|
||||
loc br0:eth0
|
||||
WiFi br0:eth2 maclist
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>rules</title>
|
||||
|
||||
<blockquote>
|
||||
<para>The first rule allows a transparent WWW proxy (Squid) to run on
|
||||
my bridge/firewall. Squid listens on port 3128.</para>
|
||||
|
||||
<para>The remaining rules protect the local systems and bridge from
|
||||
the WiFi network. Note that we don't restrict WiFi→net traffic
|
||||
since the only directly-accessible system in the net zone is the
|
||||
firewall (Wookie and the Firewall are connected by a cross-over
|
||||
cable).</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
|
||||
# PORT PORT(S) DEST
|
||||
REDIRECT loc 3128 tcp www - !192.168.1.0/24
|
||||
|
||||
ACCEPT WiFi loc udp 137:139
|
||||
ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389
|
||||
ACCEPT WiFi loc udp 1024: 137
|
||||
ACCEPT WiFi loc udp 177
|
||||
|
||||
ACCEPT loc WiFi udp 137:139
|
||||
ACCEPT loc WiFi tcp 137,139,445
|
||||
ACCEPT loc WiFi udp 1024: 137
|
||||
ACCEPT loc WiFi tcp 6000:6010
|
||||
|
||||
ACCEPT WiFi fw tcp ssh,137,139,445
|
||||
ACCEPT WiFi fw udp 137:139,445
|
||||
ACCEPT WiFi fw udp 1024: 137
|
||||
ACCEPT WiFi fw udp ntp
|
||||
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>routestopped</title>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#INTERFACE HOST(S) OPTIONS
|
||||
br0 0.0.0.0/0 routeback
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>maclist</title>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#INTERFACE MAC IP ADDRESSES (Optional)
|
||||
br0:eth2 00:A0:1C:DB:0C:A0 192.168.1.7 #Work Laptop
|
||||
br0:eth2 00:04:59:0e:85:b9 #WAP11
|
||||
br0:eth2 00:06:D5:45:33:3c #WET11
|
||||
br0:eth2 00:0b:c1:53:cc:97 192.168.1.8 #TIPPER
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>/etc/init.d/bridge</title>
|
||||
|
||||
<blockquote>
|
||||
<para>This file is SuSE-specific and creates the bridge device
|
||||
<filename class="devicefile">br0</filename>. A script for other
|
||||
disbributions would be similar.</para>
|
||||
|
||||
<programlisting>#!/bin/sh
|
||||
################################################################################
|
||||
# Script to create a bridge between eth0, eth1 and eth2
|
||||
#
|
||||
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
|
||||
#
|
||||
# (c) 2004 - Tom Eastep (teastep@shorewall.net)
|
||||
#
|
||||
# Modify the following variables to match your configuration
|
||||
#
|
||||
# chkconfig: 2345 05 89
|
||||
# description: Layer 2 Bridge
|
||||
#
|
||||
################################################################################
|
||||
|
||||
PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
|
||||
|
||||
do_stop() {
|
||||
echo "Stopping Bridge"
|
||||
brctl delbr br0
|
||||
ip link set eth0 down
|
||||
ip link set eth1 down
|
||||
ip link set eth2 down
|
||||
}
|
||||
|
||||
do_start() {
|
||||
|
||||
echo "Starting Bridge"
|
||||
ip link set eth0 up
|
||||
ip link set eth1 up
|
||||
ip link set eth2 up
|
||||
brctl addbr br0
|
||||
brctl addif br0 eth0
|
||||
brctl addif br0 eth1
|
||||
brctl addif br0 eth2
|
||||
}
|
||||
|
||||
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>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>/etc/sysconfig/network/ifcfg-br0</title>
|
||||
|
||||
<blockquote>
|
||||
<para>This file is SuSE-specific</para>
|
||||
|
||||
<programlisting>BOOTPROTO='static'
|
||||
BROADCAST='192.168.1.255'
|
||||
IPADDR='192.168.1.3'
|
||||
NETWORK='192.168.1.0'
|
||||
NETMASK='255.255.255.0'
|
||||
REMOTE_IPADDR=''
|
||||
STARTMODE='onboot'
|
||||
UNIQUE='3hqH.MjuOqWfSZ+C'
|
||||
WIRELESS='no'
|
||||
MTU=''</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>/etc/sysconfig/network/routes</title>
|
||||
|
||||
<blockquote>
|
||||
<para>This file is SuSE-specific</para>
|
||||
|
||||
<programlisting>192.168.1.0 - 255.255.255.0 br0
|
||||
default 192.168.1.254 - -</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
</section>
|
||||
</article>
|
||||
@ -1,75 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Ports Required for Various Services/Applications</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /><meta name="description" content="In addition to those applications described in the /etc/shorewall/rules documentation, here are some other services/applications that you may need to configure your firewall to accommodate." /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="id2590562"></a>Ports Required for Various Services/Applications</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2002, 2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>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
|
||||
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-12</p></div><div><div class="abstract"><p class="title"><b>Abstract</b></p><p>In addition to those applications described in the
|
||||
/etc/shorewall/rules documentation, here are some other
|
||||
services/applications that you may need to configure your firewall to
|
||||
accommodate.</p></div></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807696">Auth (identd)</a></span></dt><dt><span class="section"><a href="#id2807721">DNS</a></span></dt><dt><span class="section"><a href="#id2807755">FTP</a></span></dt><dt><span class="section"><a href="#id2807785">ICQ</a></span></dt><dt><span class="section"><a href="#id2807824">IMAP</a></span></dt><dt><span class="section"><a href="#id2807860">IPSEC</a></span></dt><dt><span class="section"><a href="#id2805799">NFS</a></span></dt><dt><span class="section"><a href="#id2805858">NTP (Network Time Protocol)</a></span></dt><dt><span class="section"><a href="#id2805883">PCAnywhere</a></span></dt><dt><span class="section"><a href="#id2810144">Pop3</a></span></dt><dt><span class="section"><a href="#id2810185">PPTP</a></span></dt><dt><span class="section"><a href="#id2810236">rdate</a></span></dt><dt><span class="section"><a href="#id2810261">SSH</a></span></dt><dt><span class="section"><a href="#id2810287">SMB/NMB (Samba/Windows Browsing/File Sharing)</a></span></dt><dt><span class="section"><a href="#id2859431">SMTP</a></span></dt><dt><span class="section"><a href="#id2859455">Telnet</a></span></dt><dt><span class="section"><a href="#id2859481">Traceroute</a></span></dt><dt><span class="section"><a href="#id2859520">Usenet (NNTP)</a></span></dt><dt><span class="section"><a href="#id2859550">VNC</a></span></dt><dt><span class="section"><a href="#id2859615">Web Access</a></span></dt><dt><span class="section"><a href="#id2809845">Other Source of Port Information</a></span></dt><dt><span class="appendix"><a href="#id2809872">A. Revision History</a></span></dt></dl></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Beginning with Shorewall 2.0.0, the Shorewall distribution contains
|
||||
a library of user-defined actions that allow for easily allowing or
|
||||
blocking a particular application. Check your <tt class="filename">/etc/shorewall/actions.std</tt>
|
||||
file for a list of the actions in your distribution. If you find what you
|
||||
need, you simply use the action in a rule. For example, to allow DNS
|
||||
queries from the <span class="bold"><b>dmz</b></span> zone to the
|
||||
<span class="bold"><b>net</b></span> zone:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION
|
||||
AllowPing dmz net</pre></td></tr></table></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>In the rules that are shown in this document, the ACTION is shown as
|
||||
ACCEPT. You may need to use DNAT (see <a href="FAQ.htm#faq30" target="_self">FAQ 30</a>)
|
||||
or you may want DROP or REJECT if you are trying to block the application.</p><p>Example: You want to port forward FTP from the net to your server at
|
||||
192.168.1.4 in your DMZ. The FTP section below gives you:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 21</pre></td></tr></table><p>You would code your rule as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
DNAT net dmz:192.168.1.4 tcp 21</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807696"></a>Auth (identd)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 113</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807721"></a>DNS</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> udp 53
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 53</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807755"></a>FTP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 21</pre></td></tr></table><p>Look <a href="FTP.html" target="_self">here</a> for much more information.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807785"></a>ICQ</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> udp 4000
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 4000:4100</pre></td></tr></table><p>UDP Port 4000. You will also need to open a range of TCP ports which
|
||||
you can specify to your ICQ client. By default, clients use 4000-4100.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807824"></a>IMAP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 143 #Unsecure IMAP
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 993 #Secure IMAP</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807860"></a>IPSEC</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em> <destination></em></span> 50
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em> <destination></em></span> 51
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em> <destination></em></span> udp 500
|
||||
ACCEPT <span class="emphasis"><em><destination></em></span> <span class="emphasis"><em><source></em></span> 50
|
||||
ACCEPT <span class="emphasis"><em><destination></em></span> <span class="emphasis"><em><source></em></span> 51
|
||||
ACCEPT <span class="emphasis"><em><destination></em></span> <span class="emphasis"><em><source></em></span> udp 500</pre></td></tr></table><p>Lots more information <a href="IPSEC.htm" target="_self">here</a> and <a href="VPN.htm" target="_self">here</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2805799"></a>NFS</h2></div></div><div></div></div><p>I personally use the following rules for opening access from zone z1
|
||||
to a server with IP address a.b.c.d in zone z2. I have found though that
|
||||
different distributions behave differently so your milage may vary.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><z1></em></span> <span class="emphasis"><em> <z2></em></span>:a.b.c.d tcp 111
|
||||
ACCEPT <span class="emphasis"><em><z1></em></span> <span class="emphasis"><em> <z2></em></span>:a.b.c.d udp 111
|
||||
ACCEPT <span class="emphasis"><em><z1></em></span> <span class="emphasis"><em> <z2></em></span>:a.b.c.d udp 2049
|
||||
ACCEPT <span class="emphasis"><em><z1></em></span> <span class="emphasis"><em> <z2></em></span>:a.b.c.d udp 32700:</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2805858"></a>NTP (Network Time Protocol)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> udp 123</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2805883"></a><span class="trademark">PCAnywhere</span>™</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> udp 5632
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 5631</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810144"></a>Pop3</h2></div></div><div></div></div><p>TCP Port 110 (Secure Pop3 is TCP Port 995)</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 110 #Unsecure Pop3
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 995 #Secure Pop3</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810185"></a>PPTP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> 47
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 1723</pre></td></tr></table><p>Lots more information <a href="PPTP.htm" target="_self">here</a> and <a href="VPN.htm" target="_self">here</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810236"></a>rdate</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 37</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810261"></a>SSH</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 22</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810287"></a>SMB/NMB (Samba/Windows Browsing/File Sharing)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em> <destination></em></span> tcp 137,139,445
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em> <destination></em></span> udp 137:139
|
||||
ACCEPT <span class="emphasis"><em><destination></em></span> <span class="emphasis"><em><source></em></span> tcp 137,139,445
|
||||
ACCEPT <span class="emphasis"><em><destination></em></span> <span class="emphasis"><em><source></em></span> udp 137:139</pre></td></tr></table><p>Also, see <a href="samba.htm" target="_self">this page</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859431"></a>SMTP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 25</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859455"></a>Telnet</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 23</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859481"></a>Traceroute</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> udp 33434:33443 #Good for 10 hops
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> icmp 8</pre></td></tr></table><p>UDP traceroute uses ports 33434 through 33434+<max number of
|
||||
hops>-1</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859520"></a>Usenet (NNTP)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 119</pre></td></tr></table><p>TCP Port 119</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859550"></a>VNC</h2></div></div><div></div></div><p>Vncviewer to Vncserver -- TCP port 5900 + <display number>.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 5901 #Display Number 1
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 5902 #Display Number 2
|
||||
...</pre></td></tr></table><p>Vncserver to Vncviewer in listen mode -- TCP port 5500.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 5500</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859615"></a>Web Access</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 80 #Insecure HTTP
|
||||
ACCEPT <span class="emphasis"><em><source></em></span> <span class="emphasis"><em><destination></em></span> tcp 443 #Secure HTTP</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2809845"></a>Other Source of Port Information</h2></div></div><div></div></div><p>Didn't find what you are looking for -- have you looked in your
|
||||
own /etc/services file?</p><p>Still looking? Try <a href="http://www.networkice.com/advice/Exploits/Ports" target="_self">http://www.networkice.com/advice/Exploits/Ports</a></p></div><div class="appendix" lang="en" xml:lang="en"><h2 class="title" style="clear: both"><a id="id2809872"></a>A. Revision History</h2><div class="revhistory"><table border="0" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1.6</td><td align="left">2004-01-26</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
|
||||
PCAnywhere.</td></tr><tr><td align="left">Revision 1.5</td><td align="left">2004-02-05</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
|
||||
information about VNC viewers in listen mode.</td></tr><tr><td align="left">Revision 1.4</td><td align="left">2004-01-26</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Correct
|
||||
ICQ.</td></tr><tr><td align="left">Revision 1.3</td><td align="left">2004-01-04</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Alphabetize</td></tr><tr><td align="left">Revision 1.2</td><td align="left">2004-01-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
|
||||
rules file entries.</td></tr><tr><td align="left">Revision 1.1</td><td align="left">2002-07-30</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Initial
|
||||
version converted to Docbook XML</td></tr></table></div></div></div></body></html>
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-12</pubdate>
|
||||
<pubdate>2004-02-18</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2002</year>
|
||||
@ -131,15 +131,9 @@ ACCEPT <emphasis><destination></emphasis> <emphasis><source>
|
||||
<section>
|
||||
<title>NFS</title>
|
||||
|
||||
<para>I personally use the following rules for opening access from zone z1
|
||||
to a server with IP address a.b.c.d in zone z2. I have found though that
|
||||
different distributions behave differently so your milage may vary.</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <emphasis><z1></emphasis> <emphasis> <z2></emphasis>:a.b.c.d tcp 111
|
||||
ACCEPT <emphasis><z1></emphasis> <emphasis> <z2></emphasis>:a.b.c.d udp 111
|
||||
ACCEPT <emphasis><z1></emphasis> <emphasis> <z2></emphasis>:a.b.c.d udp 2049
|
||||
ACCEPT <emphasis><z1></emphasis> <emphasis> <z2></emphasis>:a.b.c.d udp 32700:</programlisting>
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <emphasis><z1></emphasis>:<list of client IPs> <emphasis> <z2></emphasis>:a.b.c.d tcp 111
|
||||
ACCEPT <emphasis><z1></emphasis>:<list of client IPs> <emphasis> <z2></emphasis>:a.b.c.d udp</programlisting>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -275,7 +269,8 @@ ACCEPT <emphasis><source></emphasis> <emphasis><destination>
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.6</revnumber><date>2004-01-26</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
<para><revhistory><revision><revnumber>1.7</revnumber><date>2004-02-18</date><authorinitials>TE</authorinitials><revremark>Make
|
||||
NFS work for everyone.</revremark></revision><revision><revnumber>1.6</revnumber><date>2004-02-14</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
PCAnywhere.</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-02-05</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
information about VNC viewers in listen mode.</revremark></revision><revision><revnumber>1.4</revnumber><date>2004-01-26</date><authorinitials>TE</authorinitials><revremark>Correct
|
||||
ICQ.</revremark></revision><revision><revnumber>1.3</revnumber><date>2004-01-04</date><authorinitials>TE</authorinitials><revremark>Alphabetize</revremark></revision><revision><revnumber>1.2</revnumber><date>2004-01-03</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-05</pubdate>
|
||||
<pubdate>2004-02-16</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2002-2004</year>
|
||||
@ -261,9 +261,11 @@ all all REJECT info</programlisting>
|
||||
<tip>
|
||||
<para>If you specify <emphasis>norfc1918</emphasis> for your external
|
||||
interface, you will want to check the <ulink url="errata.htm">Shorewall
|
||||
Errata</ulink> periodically for updates to the <filename>/etc/shorewall/rfc1918
|
||||
file</filename>. Alternatively, you can <ulink url="myfiles.htm#RFC1918">strip
|
||||
down your <filename>/etc/shorewall/rfc1918</filename> file as I do</ulink>.</para>
|
||||
Errata</ulink> periodically for updates to the <filename>/usr/share/shorewall/rfc1918
|
||||
file</filename>. Alternatively, you can copy <filename>/usr/share/shorewall/rfc1918</filename>
|
||||
to <filename>/etc/shorewall/rfc1918</filename> then <ulink
|
||||
url="myfiles.htm#RFC1918">strip down your <filename>/etc/shorewall/rfc1918</filename>
|
||||
file as I do</ulink>.</para>
|
||||
</tip>
|
||||
</section>
|
||||
|
||||
@ -300,8 +302,7 @@ all all REJECT info</programlisting>
|
||||
actions included in your version of Shorewall in the file
|
||||
<filename>/etc/shorewall/actions.std</filename>.</para>
|
||||
|
||||
<para>Those actions that allow a connection begin with <quote>Allow</quote>.
|
||||
</para>
|
||||
<para>Those actions that allow a connection begin with <quote>Allow</quote>.</para>
|
||||
|
||||
<para>If you wish to enable connections from the internet to your firewall
|
||||
and you find an appropriate <quote>Allow</quote> action in
|
||||
@ -406,7 +407,8 @@ AllowSSH net fw </programlisting>
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.6</revnumber><date>2004-02-05</date><authorinitials>TE</authorinitials><revremark>Update
|
||||
<para><revhistory><revision><revnumber>1.7</revnumber><date>2004-02-16</date><authorinitials>TE</authorinitials><revremark>Move
|
||||
/etc/shorewall/rfc1918 to /usr/share/shorewall.</revremark></revision><revision><revnumber>1.6</revnumber><date>2004-02-05</date><authorinitials>TE</authorinitials><revremark>Update
|
||||
for Shorewall 2.0</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-01-05</date><authorinitials>TE</authorinitials><revremark>Standards
|
||||
Changes</revremark></revision><revision><revnumber>1.4</revnumber><date>2003-12-30</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
tip about /etc/shorewall/rfc1918 updates.</revremark></revision><revision><revnumber>1.3</revnumber><date>2003-11-15</date><authorinitials>TE</authorinitials><revremark>Initial
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-01-01</pubdate>
|
||||
<pubdate>2004-03-15</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -121,6 +121,12 @@
|
||||
questions but we can't do your job for you.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Please do NOT include the output of <command>iptables -L</command>
|
||||
— the output of <emphasis role="bold">shorewall show</emphasis> or
|
||||
<command>shorewall status</command> is much more useful.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>When reporting a problem, <emphasis role="bold">ALWAYS</emphasis>
|
||||
include this information:</para>
|
||||
@ -254,11 +260,6 @@
|
||||
please post your question or problem to <ulink
|
||||
url="mailto:leaf-user@lists.sourceforge.net">the LEAF Users mailing list</ulink>.</para>
|
||||
|
||||
<para><emphasis role="bold">If you are new to Shorewall and have a
|
||||
question or need help with a problem</emphasis>, please post to the <ulink
|
||||
url="mailto:shorewall-newbies@lists.shorewall.net">Shorewall Newbies
|
||||
mailing list</ulink>.</para>
|
||||
|
||||
<para><emphasis role="bold">If you run Shorewall under MandrakeSoft Multi
|
||||
Network Firewall (MNF) and you have not purchased an MNF license from
|
||||
MandrakeSoft then you can post non MNF-specific Shorewall questions to the
|
||||
@ -272,13 +273,6 @@
|
||||
included in any replies.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Subscribing to the Newbies Mailing List</title>
|
||||
|
||||
<para>To Subscribe to the mailing list go to <ulink
|
||||
url="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">https://lists.shorewall.net/mailman/listinfo/shorewall-newbies</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Subscribing to the Users Mailing List</title>
|
||||
|
||||
@ -296,7 +290,9 @@
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.2</revnumber><date>2003-01-01</date><authorinitials>TE</authorinitials><revremark>Removed
|
||||
<para><revhistory><revision><revnumber>1.4</revnumber><date>2003-03-15</date><authorinitials>TE</authorinitials><revremark>Remove
|
||||
Newbies Mailing List.</revremark></revision><revision><revnumber>1.3</revnumber><date>2003-02-19</date><authorinitials>TE</authorinitials><revremark>Admonish
|
||||
against including "iptables -L" output.</revremark></revision><revision><revnumber>1.2</revnumber><date>2003-01-01</date><authorinitials>TE</authorinitials><revremark>Removed
|
||||
.GIF and moved note about unsupported releases. Move Revision History to
|
||||
this Appendix.</revremark></revision><revision><revnumber>1.1</revnumber><date>2003-12-19</date><authorinitials>TE</authorinitials><revremark>Corrected
|
||||
URL for Newbies List</revremark></revision></revhistory></para>
|
||||
|
||||
@ -1,342 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Three-Interface Firewall</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="three-interface"></a>Three-Interface Firewall</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2002-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>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
|
||||
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-12</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2803947">Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#id2807729">Requirements</a></span></dt><dt><span class="section"><a href="#id2807804">Before you start</a></span></dt><dt><span class="section"><a href="#id2810224">Conventions</a></span></dt></dl></dd><dt><span class="section"><a href="#id2810263">PPTP/ADSL</a></span></dt><dt><span class="section"><a href="#id2810295">Shorewall Concepts</a></span></dt><dt><span class="section"><a href="#id2859594">Network Interfaces</a></span></dt><dt><span class="section"><a href="#id2859977">IP Addresses</a></span></dt><dt><span class="section"><a href="#id2806632">IP Masquerading (SNAT)</a></span></dt><dt><span class="section"><a href="#id2806881">Port Forwarding (DNAT)</a></span></dt><dt><span class="section"><a href="#id2865302">Domain Name Server (DNS)</a></span></dt><dt><span class="section"><a href="#id2865536">Other Connections</a></span></dt><dt><span class="section"><a href="#id2865767">Starting and Stopping Your Firewall</a></span></dt><dt><span class="section"><a href="#id2865997">Additional Recommended Reading</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2803947"></a>Introduction</h2></div></div><div></div></div><p>Setting up a Linux system as a firewall for a small network with DMZ
|
||||
is a fairly straight-forward task if you understand the basics and follow
|
||||
the documentation.</p><p>This guide doesn't attempt to acquaint you with all of the
|
||||
features of Shorewall. It rather focuses on what is required to configure
|
||||
Shorewall in one of its more popular configurations:</p><div class="itemizedlist"><ul type="disc"><li><p>Linux system used as a firewall/router for a small local
|
||||
network.</p></li><li><p>Single public IP address.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you have more than one public IP address, this is not the
|
||||
guide you want -- see the <a href="shorewall_setup_guide.htm" target="_self">Shorewall
|
||||
Setup Guide</a> instead.</p></div></li><li><p>DMZ connected to a separate ethernet interface.</p></li><li><p>Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up,
|
||||
...</p></li></ul></div><p>Here is a schematic of a typical installation.</p><div class="figure"><a id="id2807700"></a><p class="title"><b>Figure 1. schematic of a typical installation</b></p><div class="mediaobject" align="center"><img src="images/dmz1.png" align="middle" alt="schematic of a typical installation" /></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807729"></a>Requirements</h3></div></div><div></div></div><p>Shorewall requires that you have the <span><b class="command">iproute</b></span>/<span><b class="command">iproute2</b></span>
|
||||
package installed (on <span class="trademark">RedHat</span>™, the package is
|
||||
called <span><b class="command">iproute</b></span>). You can tell if this package is
|
||||
installed by the presence of an <span><b class="command">ip</b></span> program on your
|
||||
firewall system. As <tt class="systemitem">root</tt>, you
|
||||
can use the <span><b class="command">which</b></span> command to check for this program:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">[root@gateway root]# <span><b class="command">which ip</b></span>
|
||||
/sbin/ip
|
||||
[root@gateway root]#</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807804"></a>Before you start</h3></div></div><div></div></div><p>I recommend that you first read through the guide to familiarize
|
||||
yourself with what's involved then go back through it again making
|
||||
your configuration changes.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>If you edit your configuration files on a
|
||||
<span class="trademark">Windows</span>™ system, you must save them as
|
||||
<span class="trademark">Unix</span>™ files if your editor supports that option
|
||||
or you must run them through <span><b class="command">dos2unix</b></span> before trying
|
||||
to use them. Similarly, if you copy a configuration file from your
|
||||
<span class="trademark">Windows</span>™ hard drive to a floppy disk, you must
|
||||
run <span><b class="command">dos2unix</b></span> against the copy before using it with
|
||||
Shorewall.</p><div class="itemizedlist"><ul type="disc"><li><p><a href="http://www.simtel.net/pub/pd/51438.html" target="_self">Windows
|
||||
Version of dos2unix</a></p></li><li><p><a href="http://www.megaloman.com/%7Ehany/software/hd2u/" target="_self">Linux
|
||||
Version of dos2unix</a></p></li></ul></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810224"></a>Conventions</h3></div></div><div></div></div><p>Points at which configuration changes are recommended are flagged
|
||||
with <img src="images/BD21298_.gif" />.</p><p>Configuration notes that are unique to LEAF/Bering are marked with
|
||||
<img src="images/leaflogo.gif" />.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810263"></a>PPTP/ADSL</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>If you have an ADSL Modem and you use PPTP to communicate with a
|
||||
server in that modem, you must make the <a href="PPTP.htm#PPTP_ADSL" target="_self">changes
|
||||
recommended here</a> in addition to those detailed below. ADSL with
|
||||
PPTP is most commonly found in Europe, notably in Austria.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810295"></a>Shorewall Concepts</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>The configuration files for Shorewall are contained in the directory
|
||||
<tt class="filename">/etc/shorewall</tt> -- for simple setups, you will only
|
||||
need to deal with a few of these as described in this guide. After you
|
||||
have installed Shorewall, download the three-interface sample, un-tar it (<span><b class="command">tar
|
||||
<tt class="option">-zxvf</tt> <tt class="filename">three-interfaces.tgz</tt></b></span>)
|
||||
and and copy the files to <tt class="filename">/etc/shorewall</tt> (the files
|
||||
will replace files with the same names that were placed in
|
||||
<tt class="filename">/etc/shorewall</tt> when Shorewall was installed).</p><p>As each file is introduced, I suggest that you look through the
|
||||
actual file on your system -- each file contains detailed configuration
|
||||
instructions and default entries.</p><p>Shorewall views the network where it is running as being composed of
|
||||
a set of zones. In the three-interface sample configuration, the following
|
||||
zone names are used:</p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><thead valign="middle"><tr><th align="center">Name</th><th align="center">Description</th></tr></thead><tbody><tr><td align="left">net</td><td align="left">The Internet</td></tr><tr><td align="left">loc</td><td align="left">Your Local Network</td></tr><tr><td align="left">dmz</td><td align="left">Demilitarized Zone</td></tr></tbody></table></div><p>Zone names are defined in <tt class="filename">/etc/shorewall/zones</tt>.</p><p>Shorewall also recognizes the firewall system as its own zone - by
|
||||
default, the firewall itself is known as <tt class="varname">fw</tt>.</p><p>Rules about what traffic to allow and what traffic to deny are
|
||||
expressed in terms of zones.</p><div class="itemizedlist"><ul type="disc"><li><p>You express your default policy for connections from one zone to
|
||||
another zone in the <tt class="filename">/etc/shorewall/policy</tt> file.</p></li><li><p>You define exceptions to those default policies in the
|
||||
<tt class="filename">/etc/shorewall/rules</tt> file.</p></li></ul></div><p>For each connection request entering the firewall, the request is
|
||||
first checked against the <tt class="filename">/etc/shorewall/rules</tt> file.
|
||||
If no rule in that file matches the connection request then the first
|
||||
policy in <tt class="filename">/etc/shorewall/policy</tt> that matches the
|
||||
request is applied. If that policy is REJECT or DROP the request is first
|
||||
checked against the rules in <tt class="filename">/etc/shorewall/common</tt> if
|
||||
that file exists; otherwise the file <tt class="filename">/etc/shorewall/common.def</tt>
|
||||
is checked</p><p>The <tt class="filename">/etc/shorewall/policy</tt> file included with
|
||||
the three-interface sample has the following policies:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||||
loc net ACCEPT
|
||||
net all DROP info
|
||||
all all REJECT info</pre></td></tr></table><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>In the three-interface sample, the line below is included but
|
||||
commented out. If you want your firewall system to have full access to
|
||||
servers on the internet, uncomment that line.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||||
fw net ACCEPT</pre></td></tr></table></div><p>The above policy will:</p><div class="orderedlist"><ol type="1"><li><p>allow all connection requests from your local network to the
|
||||
internet</p></li><li><p>drop (ignore) all connection requests from the internet to your
|
||||
firewall or local network</p></li><li><p>optionally accept all connection requests from the firewall to
|
||||
the internet (if you uncomment the additional policy)</p></li><li><p>reject all other connection requests.</p></li></ol></div><p><img src="images/BD21298_.gif" /></p><p>At this point, edit your <tt class="filename">/etc/shorewall/policy</tt>
|
||||
file and make any changes that you wish.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859594"></a>Network Interfaces</h2></div></div><div></div></div><div class="figure"><a id="id2859601"></a><p class="title"><b>Figure 2. DMZ</b></p><div class="mediaobject" align="center"><img src="images/dmz1.png" align="middle" alt="DMZ" /></div></div><p>The firewall has three network interfaces. Where Internet
|
||||
connectivity is through a cable or DSL “<span class="quote">Modem</span>”, the External
|
||||
Interface will be the ethernet adapter that is connected to that
|
||||
“<span class="quote">Modem</span>” (e.g., <tt class="filename">eth0</tt>)
|
||||
unless you connect via <span class="emphasis"><em>Point-to-Point Protocol</em></span> over
|
||||
Ethernet (PPPoE) or <span class="emphasis"><em>Point-to-Point Tunneling Protocol</em></span>
|
||||
(PPTP) in which case the External Interface will be a <tt class="literal">ppp</tt>
|
||||
interface (e.g., <tt class="filename">ppp0</tt>). If you
|
||||
connect via a regular modem, your External Interface will also be
|
||||
<tt class="filename">ppp0</tt>. If you connect using ISDN,
|
||||
you external interface will be <tt class="filename">ippp0</tt>.</p><p><img src="images/BD21298_.gif" /></p><p>If your external interface is <tt class="filename">ppp0</tt>
|
||||
or <tt class="filename">ippp0</tt> then you will want to set
|
||||
<tt class="varname">CLAMPMSS=yes</tt> in <tt class="filename">/etc/shorewall/shorewall.conf</tt>.</p><p>Your Local Interface will be an ethernet adapter (<tt class="filename">eth0</tt>, <tt class="filename">eth1</tt>
|
||||
or <tt class="filename">eth2</tt>) and will be connected to
|
||||
a hub or switch. Your local computers will be connected to the same switch
|
||||
(note: If you have only a single local system, you can connect the
|
||||
firewall directly to the computer using a cross-over cable).</p><p>Your DMZ Interface will also be an ethernet adapter (<tt class="filename">eth0</tt>, <tt class="filename">eth1</tt>
|
||||
or <tt class="filename">eth2</tt>) and will be connected to
|
||||
a hub or switch. Your DMZ computers will be connected to the same switch
|
||||
(note: If you have only a single DMZ system, you can connect the firewall
|
||||
directly to the computer using a cross-over cable).</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>Do not connect the internal and external interface to the same hub
|
||||
or switch except for testing AND you are running Shorewall version 1.4.7
|
||||
or later. When using these recent versions, you can test using this kind
|
||||
of configuration if you specify the arp_filter option in
|
||||
<tt class="filename">/etc/shorewall/interfaces</tt> for all interfaces
|
||||
connected to the common hub/switch. Using such a setup with a production
|
||||
firewall is strongly recommended against.</p></div><p><img src="images/BD21298_.gif" /></p><p>The Shorewall three-interface sample configuration assumes that the
|
||||
external interface is <tt class="filename">eth0</tt>, the
|
||||
local interface is <tt class="filename">eth1</tt> and the
|
||||
DMZ interface is <tt class="filename">eth2</tt>. If your
|
||||
configuration is different, you will have to modify the sample
|
||||
<tt class="filename">/etc/shorewall/interfaces</tt> file accordingly. While you
|
||||
are there, you may wish to review the list of options that are specified
|
||||
for the interfaces. Some hints:</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>If your external interface is <tt class="filename">ppp0</tt>
|
||||
or <tt class="filename">ippp0</tt>, you can replace the
|
||||
“<span class="quote">detect</span>” in the second column with “<span class="quote">-</span>”
|
||||
(without the quotes).</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>If your external interface is <tt class="filename">ppp0</tt>
|
||||
or <tt class="filename">ippp0</tt> or if you have a static
|
||||
IP address, you can remove “<span class="quote">dhcp</span>” from the option list.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859977"></a>IP Addresses</h2></div></div><div></div></div><p>Before going further, we should say a few words about Internet
|
||||
Protocol (IP) addresses. Normally, your ISP will assign you a single
|
||||
Public IP address. This address may be assigned via the Dynamic Host
|
||||
Configuration Protocol (DHCP) or as part of establishing your connection
|
||||
when you dial in (standard modem) or establish your PPP connection. In
|
||||
rare cases, your ISP may assign you a static IP address; that means that
|
||||
you configure your firewall's external interface to use that address
|
||||
permanently. Regardless of how the address is assigned, it will be shared
|
||||
by all of your systems when you access the Internet. You will have to
|
||||
assign your own addresses for your internal network (the local and DMZ
|
||||
Interfaces on your firewall plus your other computers). RFC 1918 reserves
|
||||
several Private IP address ranges for this purpose:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">10.0.0.0 - 10.255.255.255
|
||||
172.16.0.0 - 172.31.255.255
|
||||
192.168.0.0 - 192.168.255.255</pre></td></tr></table><p><img src="images/BD21298_.gif" /></p><p>Before starting Shorewall, you should look at the IP address of your
|
||||
external interface and if it is one of the above ranges, you should remove
|
||||
the <tt class="varname">norfc1918</tt> option from the external interface's
|
||||
entry in <tt class="filename">/etc/shorewall/interfaces</tt>.</p><p>You will want to assign your local addresses from one sub-network or
|
||||
subnet and your DMZ addresses from another subnet. For our purposes, we
|
||||
can consider a subnet to consists of a range of addresses <tt class="systemitem">x.y.z.0</tt> - <tt class="systemitem">x.y.z.255</tt>.
|
||||
Such a subnet will have a Subnet Mask of <tt class="systemitem">255.255.255.0</tt>.
|
||||
The address <tt class="systemitem">x.y.z.0</tt> is reserved
|
||||
as the Subnet Address and <tt class="systemitem">x.y.z.255</tt>
|
||||
is reserved as the Subnet Broadcast Address. In Shorewall, a subnet is
|
||||
described using Classless InterDomain Routing (CIDR) notation with
|
||||
consists of the subnet address followed by <tt class="varname">/24</tt>. The
|
||||
<tt class="varname">24</tt> refers to the number of consecutive “<span class="quote">1</span>”
|
||||
bits from the left of the subnet mask.</p><div class="table"><a id="id2809952"></a><p class="title"><b>Table 1. Example sub-network</b></p><table summary="Example sub-network" border="1"><colgroup><col align="left" /><col /></colgroup><tbody><tr><td align="left">Range:</td><td><tt class="systemitem">10.10.10.0</tt> -
|
||||
<tt class="systemitem">10.10.10.255</tt></td></tr><tr><td align="left">Subnet Address:</td><td><tt class="systemitem">10.10.10.0</tt></td></tr><tr><td align="left">Broadcast Address:</td><td><tt class="systemitem">10.10.10.255</tt></td></tr><tr><td align="left">CIDR Notation:</td><td><tt class="systemitem">10.10.10.0/24</tt></td></tr></tbody></table></div><p>It is conventional to assign the internal interface either the first
|
||||
usable address in the subnet (<tt class="systemitem">10.10.10.1</tt>
|
||||
in the above example) or the last usable address (<tt class="systemitem">10.10.10.254</tt>).</p><p>One of the purposes of subnetting is to allow all computers in the
|
||||
subnet to understand which other computers can be communicated with
|
||||
directly. To communicate with systems outside of the subnetwork, systems
|
||||
send packets through a gateway (router).</p><p><img src="images/BD21298_.gif" /></p><p>Your local computers (Local Computers 1 & 2) should be
|
||||
configured with their default gateway set to the IP address of the
|
||||
firewall's internal interface and your DMZ computers (DMZ Computers 1
|
||||
& 2) should be configured with their default gateway set to the IP
|
||||
address of the firewall's DMZ interface.</p><p>The foregoing short discussion barely scratches the surface
|
||||
regarding subnetting and routing. If you are interested in learning more
|
||||
about IP addressing and routing, I highly recommend “<span class="quote">IP
|
||||
Fundamentals: What Everyone Needs to Know about Addressing & Routing</span>”,
|
||||
Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p><p>The remainder of this quide will assume that you have configured
|
||||
your network as shown here:</p><div class="figure"><a id="id2810143"></a><p class="title"><b>Figure 3. DMZ</b></p><div class="mediaobject"><img src="images/dmz2.png" alt="DMZ" /><div class="caption"><p>The default gateway for the DMZ computers would be <tt class="systemitem">10.10.11.254</tt> and the default gateway
|
||||
for the Local computers would be <tt class="systemitem">10.10.10.254</tt>.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Your ISP might assign your external interface an RFC 1918
|
||||
address. If that address is in the <tt class="systemitem">10.10.10.0/24</tt>
|
||||
subnet then you will need to select a DIFFERENT RFC 1918 subnet
|
||||
for your local network and if it is in the <tt class="systemitem">10.10.11.0/24</tt> subnet then you will
|
||||
need to select a different RFC 1918 subnet for your DMZ.</p></div></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806632"></a>IP Masquerading (SNAT)</h2></div></div><div></div></div><p>The addresses reserved by RFC 1918 are sometimes referred to as
|
||||
non-routable because the Internet backbone routers don't forward
|
||||
packets which have an RFC-1918 destination address. When one of your local
|
||||
systems (let's assume local computer 1) sends a connection request to
|
||||
an internet host, the firewall must perform Network Address Translation
|
||||
(NAT). The firewall rewrites the source address in the packet to be the
|
||||
address of the firewall's external interface; in other words, the
|
||||
firewall makes it look as if the firewall itself is initiating the
|
||||
connection. This is necessary so that the destination host will be able to
|
||||
route return packets back to the firewall (remember that packets whose
|
||||
destination address is reserved by RFC 1918 can't be routed accross
|
||||
the internet). When the firewall receives a return packet, it rewrites the
|
||||
destination address back to 10.10.10.1 and forwards the packet on to local
|
||||
computer 1.</p><p>On Linux systems, the above process is often referred to as IP
|
||||
Masquerading and you will also see the term Source Network Address
|
||||
Translation (SNAT) used. Shorewall follows the convention used with
|
||||
Netfilter: </p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Masquerade</em></span>
|
||||
describes the case where you let your firewall system automatically detect
|
||||
the external interface address.</p></li><li><p><span class="emphasis"><em>SNAT</em></span>
|
||||
refers to the case when you explicitly specify the source address that you
|
||||
want outbound packets from your local network to use.</p></li></ul></div><p>
|
||||
In Shorewall, both Masquerading and SNAT are configured with entries in
|
||||
the <tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
|
||||
file.</p><p><img src="images/BD21298_.gif" /></p><p>If your external firewall interface is <tt class="filename">eth0</tt>,
|
||||
your local interface <tt class="filename">eth1</tt> and your
|
||||
DMZ interface is <tt class="filename">eth2</tt> then you do
|
||||
not need to modify the file provided with the sample. Otherwise, edit
|
||||
<tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
|
||||
and change it to match your configuration.</p><p>If, despite all advice to the contrary, you are using this guide and
|
||||
want to use one-to-one NAT or Proxy ARP for your DMZ, remove the entry for
|
||||
eth2 from <tt class="filename">/etc/shorewall/masq</tt>.</p><p><img src="images/BD21298_.gif" /></p><p>If your external IP is static, you can enter it in the third column
|
||||
in the <tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
|
||||
entry if you like although your firewall will work fine if you leave that
|
||||
column empty. Entering your static IP in column 3 makes processing
|
||||
outgoing packets a little more efficient.</p><p><img src="images/BD21298_.gif" /></p><p>If you are using the Debian package, please check your
|
||||
<tt class="filename">shorewall.conf</tt> file to ensure that the following are
|
||||
set correctly; if they are not, change them appropriately:
|
||||
</p><div class="itemizedlist"><ul type="disc"><li><p><tt class="varname">NAT_ENABLED=Yes</tt>
|
||||
(Shorewall versions earlier than 1.4.6)</p></li><li><p><tt class="varname">IP_FORWARDING=On</tt></p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806881"></a>Port Forwarding (DNAT)</h2></div></div><div></div></div><p>One of your goals will be to run one or more servers on your DMZ
|
||||
computers. Because these computers have RFC-1918 addresses, it is not
|
||||
possible for clients on the internet to connect directly to them. It is
|
||||
rather necessary for those clients to address their connection requests to
|
||||
your firewall who rewrites the destination address to the address of your
|
||||
server and forwards the packet to that server. When your server responds,
|
||||
the firewall automatically performs SNAT to rewrite the source address in
|
||||
the response.</p><p>The above process is called <span class="emphasis"><em>Port Forwarding</em></span> or
|
||||
<span class="emphasis"><em>Destination Network Address Translation</em></span> (DNAT). You
|
||||
configure port forwarding using DNAT rules in the <tt class="filename">/etc/shorewall/</tt><tt class="filename">rules</tt>
|
||||
file.</p><p>The general form of a simple port forwarding rule in <tt class="filename">/etc/shorewall/</tt><tt class="filename">rules</tt> is:
|
||||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
DNAT net dmz:<span class="emphasis"><em><server local ip address></em></span>[:<span class="emphasis"><em><server port></em></span>] <span class="emphasis"><em><protocol></em></span> <span class="emphasis"><em><port></em></span></pre></td></tr></table><p>
|
||||
If you don't specify the <span class="emphasis"><em><tt class="varname"><server port></tt></em></span>,
|
||||
it is assumed to be the same as <span class="emphasis"><em><tt class="varname"><port></tt></em></span>.</p><div class="example"><a id="id2807001"></a><p class="title"><b>Example 1. You run a Web Server on DMZ Computer 2 and you want to forward
|
||||
incoming TCP port 80 to that system</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
DNAT net dmz:10.10.11.2 tcp 80
|
||||
ACCEPT loc dmz:10.10.11.2 tcp 80</pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Entry
|
||||
1 forwards port 80 from the Internet.</p></li><li><p>Entry
|
||||
2 allows connections from the local network.</p></li></ul></div><p>
|
||||
Several important points to keep in mind:</p><div class="itemizedlist"><ul type="disc"><li><p>When
|
||||
you are connecting to your server from your local systems, you must use
|
||||
the server's internal IP address (<tt class="systemitem">10.10.11.2</tt>).</p></li><li><p>Many
|
||||
ISPs block incoming connection requests to port 80. If you have problems
|
||||
connecting to your web server, try the following rule and try connecting
|
||||
to port 5000 (e.g., connect to <tt class="literal">http://w.x.y.z:5000 where
|
||||
w.x.y.z</tt> is your external IP).</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE
|
||||
# PORT(S)
|
||||
DNAT net dmz:10.10.11.2:80 tcp 80 5000</pre></td></tr></table></li><li><p>If
|
||||
you want to be able to access your server from the local network using
|
||||
your external address, then if you have a static external IP you can
|
||||
replace the loc->dmz rule above with:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
DNAT loc dmz:10.10.11.2 tcp 80 - <span class="emphasis"><em><external ip></em></span></pre></td></tr></table><p>If
|
||||
you have a dynamic ip then you must ensure that your external interface
|
||||
is up before starting Shorewall and you must take steps as follows
|
||||
(assume that your external interface is <tt class="filename">eth0</tt>):</p><div class="orderedlist"><ol type="1"><li><p>Include
|
||||
the following in /etc/shorewall/params:</p><p><span><b class="command">ETH0_IP=$(find_interface_address
|
||||
eth0)</b></span></p></li><li><p>Make your
|
||||
<tt class="literal">loc->dmz</tt> rule: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
DNAT loc dmz:10.10.11.2 tcp 80 - $ETH0_IP</pre></td></tr></table></li></ol></div></li><li><p>If
|
||||
you want to access your server from the DMZ using your external IP
|
||||
address, see <a href="FAQ.htm#faq2a" target="_self">FAQ 2a</a>.</p></li></ul></div></div><p><img src="images/BD21298_.gif" /></p><p>At this point, add the DNAT and ACCEPT rules for your servers.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865302"></a>Domain Name Server (DNS)</h2></div></div><div></div></div><p>Normally, when you connect to your ISP, as part of getting an IP
|
||||
address your firewall's <span class="emphasis"><em>Domain Name Service</em></span> (DNS)
|
||||
resolver will be automatically configured (e.g., the <tt class="filename">/etc/resolv.conf</tt>
|
||||
file will be written). Alternatively, your ISP may have given you the IP
|
||||
address of a pair of DNS name servers for you to manually configure as
|
||||
your primary and secondary name servers. It is your responsibility to
|
||||
configure the resolver in your internal systems. You can take one of two
|
||||
approaches: </p><div class="itemizedlist"><ul type="disc"><li><p>You can configure your internal
|
||||
systems to use your ISP's name servers. If you ISP gave you the
|
||||
addresses of their servers or if those addresses are available on their
|
||||
web site, you can configure your internal systems to use those addresses.
|
||||
If that information isn't available, look in <tt class="filename">/etc/resolv.conf</tt>
|
||||
on your firewall system -- the name servers are given in “<span class="quote">nameserver</span>”
|
||||
records in that file.</p></li><li><p><img src="images/BD21298_.gif" /></p><p>You can
|
||||
configure a <span class="emphasis"><em>Caching Name Server</em></span> on your firewall or
|
||||
in your DMZ. <span class="trademark">Red Hat</span>™ has an RPM for a caching name
|
||||
server (which also requires the '<span><b class="command">bind</b></span>' RPM) and
|
||||
for Bering users, there is <tt class="filename">dnscache.lrp</tt>. If you take
|
||||
this approach, you configure your internal systems to use the caching name
|
||||
server as their primary (and only) name server. You use the internal IP
|
||||
address of the firewall (<tt class="systemitem">10.10.10.254</tt>
|
||||
in the example above) for the name server address if you choose to run the
|
||||
name server on your firewall. To allow your local systems to talk to your
|
||||
caching name server, you must open port 53 (both UDP and TCP) from the
|
||||
local network to the server; you do that by adding the rules in
|
||||
<tt class="filename">/etc/shorewall/rules</tt>.</p></li></ul></div><p>
|
||||
If you run the name server on the firewall:
|
||||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
AllowDNS loc fw
|
||||
AllowDNS dmz fw </pre></td></tr></table><p> Run name server on DMZ
|
||||
computer 1: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
AllowDNS loc dmz:10.10.11.1
|
||||
AllowDNS fw dmz:10.10.11.1 </pre></td></tr></table><p>In the rules shown above, “<span class="quote">AllowDNS</span>” is an example of a
|
||||
<span class="emphasis"><em>defined action</em></span>. Shorewall includes a number of
|
||||
defined actions and <a href="User_defined_Actions.html" target="_self">you can add
|
||||
your own</a>. To see the list of actions included with your version of
|
||||
Shorewall, look in the file <tt class="filename">/etc/shorewall/actions.std</tt>.
|
||||
Those actions that accept connection requests have names that begin with
|
||||
“<span class="quote">Allow</span>”.</p><p>You don't have to use defined actions when coding a rule in
|
||||
<tt class="filename">/etc/shorewall/rules</tt>; the generated Netfilter ruleset
|
||||
is slightly more efficient if you code your rules directly rather than
|
||||
using defined actions. The first example above (name server on the
|
||||
firewall) could also have been coded as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT loc fw tcp 53
|
||||
ACCEPT loc fw udp 53
|
||||
ACCEPT dmz fw tcp 53
|
||||
ACCEPT dmz fw udp 53 </pre></td></tr></table><p>In cases where Shorewall doesn't include a defined action to
|
||||
meet your needs, you can either define the action yourself or you can
|
||||
simply code the appropriate rules directly.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865536"></a>Other Connections</h2></div></div><div></div></div><p>The three-interface sample includes the following rule:
|
||||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
AllowDNS fw net </pre></td></tr></table><p>That rule allow DNS access from
|
||||
your firewall and may be removed if you commented out the line in
|
||||
<tt class="filename">/etc/shorewall/policy</tt> allowing all connections from
|
||||
the firewall to the internet.</p><p>The sample also includes: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
AllowSSH loc fw
|
||||
AllowSSH loc dmz </pre></td></tr></table><p>Those rules allow you to run
|
||||
an SSH server on your firewall and in each of your DMZ systems and to
|
||||
connect to those servers from your local systems.</p><p>If you wish to enable other connections between your systems, the
|
||||
general format for using a defined action is:
|
||||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
<<span class="emphasis"><em>action</em></span>> <span class="emphasis"><em><source zone> <destination zone></em></span></pre></td></tr></table><p>The general format when not using a defined action is:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT <span class="emphasis"><em><source zone> <destination zone> <protocol> <port> </em></span></pre></td></tr></table><div class="example"><a id="id2865625"></a><p class="title"><b>Example 2. You want to run a publicly-available DNS server on your firewall
|
||||
system</b></p><p>Using defined actions:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
AllowDNS net fw</pre></td></tr></table><p>Not using defined actions:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT net fw tcp 53
|
||||
ACCEPT net fw udp 53 </pre></td></tr></table><p>Those rules would of course be in addition to the rules listed
|
||||
above under "If you run the name server on your firewall".</p></div><p>If you don't know what port and protocol a particular
|
||||
application uses, <a href="ports.htm" target="_self">look here</a>.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>I don't recommend enabling telnet to/from the internet because
|
||||
it uses clear text (even for login!). If you want shell access to your
|
||||
firewall from the internet, use SSH: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
AllowSSH net fw</pre></td></tr></table></div><p><img src="images/leaflogo.gif" /> Bering
|
||||
users will want to add the following two rules to be compatible with
|
||||
Jacques's Shorewall configuration: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT loc fw udp 53
|
||||
ACCEPT net fw tcp 80 </pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Entry
|
||||
1 allows the DNS Cache to be used.</p></li><li><p>Entry
|
||||
2 allows the “<span class="quote">weblet</span>” to work.</p></li></ul></div><p><img src="images/BD21298_.gif" /></p><p>Now modify <tt class="filename">/etc/shorewall/rules</tt> to add or
|
||||
remove other connections as required.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865767"></a>Starting and Stopping Your Firewall</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>The <a href="Install.htm" target="_self">installation procedure</a>
|
||||
configures your system to start Shorewall at system boot but beginning
|
||||
with Shorewall version 1.3.9 startup is disabled so that your system
|
||||
won't try to start Shorewall before configuration is complete. Once
|
||||
you have completed configuration of your firewall, you can enable
|
||||
Shorewall startup by removing the file <tt class="filename">/etc/shorewall/startup_disabled</tt>.
|
||||
</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>Users of the <tt class="filename">.deb</tt> package must edit
|
||||
<tt class="filename">/etc/default/shorewall</tt> and set <tt class="varname">startup=1</tt>.</p></div><p>
|
||||
The firewall is started using the <span><b class="command">shorewall start</b></span>
|
||||
command and stopped using <span><b class="command">shorewall stop</b></span>. When the
|
||||
firewall is stopped, routing is enabled on those hosts that have an entry
|
||||
in <a href="Documentation.htm#Routestopped" target="_self"><tt class="filename">/etc/shorewall/routestopped</tt></a>.
|
||||
A running firewall may be restarted using the <span><b class="command">shorewall restart</b></span>
|
||||
command. If you want to totally remove any trace of Shorewall from your
|
||||
Netfilter configuration, use <span><b class="command">shorewall clear</b></span>.</p><p><img src="images/BD21298_.gif" /></p><p>The three-interface sample assumes that you want to enable routing
|
||||
to/from <tt class="filename">eth1</tt> (your local network)
|
||||
and <tt class="filename">eth2</tt> (DMZ) when Shorewall is
|
||||
stopped. If these two interfaces don't connect to your local network
|
||||
and DMZ or if you want to enable a different set of hosts, modify
|
||||
<tt class="filename">/etc/shorewall/routestopped</tt> accordingly.
|
||||
</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you are connected to your firewall from the internet, do
|
||||
not issue a <span><b class="command">shorewall stop</b></span> command unless you have
|
||||
added an entry for the IP address that you are connected from to <a href="Documentation.htm#Routestopped" target="_self"><tt class="filename">/etc/shorewall/routestopped</tt></a>.
|
||||
Also, I don't recommend using <span><b class="command">shorewall restart</b></span>; it
|
||||
is better to create an <a href="configuration_file_basics.htm#Levels" target="_self">alternate
|
||||
configuration</a> and test it using the <a href="starting_and_stopping_shorewall.htm" target="_self"><span><b class="command">shorewall try</b></span>
|
||||
command</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865997"></a>Additional Recommended Reading</h2></div></div><div></div></div><p>I highly recommend that you review the <a href="configuration_file_basics.htm" target="_self">Common Configuration File Features</a>
|
||||
page -- it contains helpful tips about Shorewall features than make
|
||||
administering your firewall easier.</p></div></div></body></html>
|
||||
@ -357,6 +357,16 @@ fw net ACCEPT</programlisting>
|
||||
or <filename class="devicefile">ippp0</filename> or if you have a static
|
||||
IP address, you can remove <quote>dhcp</quote> from the option list.</para>
|
||||
</tip>
|
||||
|
||||
<tip>
|
||||
<para>If you specify <emphasis>norfc1918</emphasis> for your external
|
||||
interface, you will want to check the <ulink url="errata.htm">Shorewall
|
||||
Errata</ulink> periodically for updates to the <filename>/usr/share/shorewall/rfc1918
|
||||
file</filename>. Alternatively, you can copy <filename>/usr/share/shorewall/rfc1918</filename>
|
||||
to <filename>/etc/shorewall/rfc1918</filename> then <ulink
|
||||
url="myfiles.htm#RFC1918">strip down your <filename>/etc/shorewall/rfc1918</filename>
|
||||
file as I do</ulink>.</para>
|
||||
</tip>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2004-01-06</pubdate>
|
||||
<pubdate>2004-02-02</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -119,6 +119,50 @@ iptables: No chain/target/match by that name
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Some Things to Keep in Mind</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">You cannot test your firewall from the
|
||||
inside</emphasis>. Just because you send requests to your firewall
|
||||
external IP address does not mean that the request will be associated
|
||||
with the external interface or the <quote>net</quote> zone. Any
|
||||
traffic that you generate from the local network will be associated
|
||||
with your local interface and will be treated as loc->fw traffic.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">IP addresses are properties of systems,
|
||||
not of interfaces</emphasis>. It is a mistake to believe that your
|
||||
firewall is able to forward packets just because you can ping the IP
|
||||
address of all of the firewall's interfaces from the local
|
||||
network. The only conclusion you can draw from such pinging success is
|
||||
that the link between the local system and the firewall works and that
|
||||
you probably have the local system's default gateway set
|
||||
correctly.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Reply packets do NOT automatically follow
|
||||
the reverse path of the one taken by the original request</emphasis>.
|
||||
All packets are routed according to the routing table of the host at
|
||||
each step of the way. This issue commonly comes up when people install
|
||||
a Shorewall firewall parallel to an existing gateway and try to use
|
||||
DNAT through Shorewall without changing the default gateway of the
|
||||
system receiving the forwarded requests. Requests come in through the
|
||||
Shorewall firewall where the destination IP address gets rewritten but
|
||||
replies go out unmodified through the old gateway.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Shorewall itself has no notion of inside
|
||||
or outside</emphasis>. These concepts are embodied in how Shorewall is
|
||||
configured. </para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Your Network Environment</title>
|
||||
|
||||
@ -355,7 +399,8 @@ DROP net fw icmp echo-request</programlist
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.6</revnumber><date>2005-01-06</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
<para><revhistory><revision><revnumber>1.7</revnumber><date>2005-02-02</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
hint about testing from inside the firewall.</revremark></revision><revision><revnumber>1.6</revnumber><date>2005-01-06</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
pointer to Site and Mailing List Archives Searches.</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-01-01</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
information about eliminating ping-generated log messages.</revremark></revision><revision><revnumber>1.4</revnumber><date>2003-12-22</date><authorinitials>TE</authorinitials><revremark>Initial
|
||||
Docbook Conversion</revremark></revision></revhistory></para>
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2003-02-08</pubdate>
|
||||
<pubdate>2003-03-16</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2002</year>
|
||||
@ -83,14 +83,15 @@
|
||||
<varname>loc</varname>). We therefore recommend that once you have set up
|
||||
this sharing that you uninstall the <trademark>Mandrake</trademark>
|
||||
Shorewall RPM and install the one from the <ulink url="download.htm">download</ulink>
|
||||
page then follow the instructions in this Guide.</para></tip>
|
||||
<caution><para>If you edit your configuration files on a
|
||||
<trademark>Windows</trademark> system, you must save them as
|
||||
<trademark>Unix</trademark> files if your editor supports that option or
|
||||
you must run them through <command>dos2unix</command> before trying to use
|
||||
them. Similarly, if you copy a configuration file from your
|
||||
<trademark>Windows</trademark> hard drive to a floppy disk, you must run
|
||||
<command>dos2unix</command> against the copy before using it with
|
||||
page then follow the instructions in this Guide.</para></tip><note><para><emphasis
|
||||
role="bold">The above Shorewall Issue is corrected in Mandrake 10.0 and
|
||||
later.</emphasis></para></note> <caution><para>If you edit your
|
||||
configuration files on a <trademark>Windows</trademark> system, you must
|
||||
save them as <trademark>Unix</trademark> files if your editor supports
|
||||
that option or you must run them through <command>dos2unix</command>
|
||||
before trying to use them. Similarly, if you copy a configuration file
|
||||
from your <trademark>Windows</trademark> hard drive to a floppy disk, you
|
||||
must run <command>dos2unix</command> against the copy before using it with
|
||||
Shorewall. <itemizedlist><listitem><para><ulink
|
||||
url="http://www.simtel.net/pub/pd/51438.html"><trademark>Windows</trademark>
|
||||
Version of <command>dos2unix</command></ulink></para></listitem><listitem><para><ulink
|
||||
@ -262,15 +263,24 @@ fw net ACCEPT</programlisting> The above policy will:
|
||||
your configuration is different, you will have to modify the sample
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||||
file accordingly. While you are there, you may wish to review the list of
|
||||
options that are specified for the interfaces. Some hints: <itemizedlist
|
||||
spacing="compact"><listitem><para>If your external interface is <filename
|
||||
class="devicefile">ppp0</filename> or <filename class="devicefile">ippp0</filename>,
|
||||
you can replace the <varname>detect</varname> in the second column with a
|
||||
<quote>-</quote> (minus the quotes).</para></listitem><listitem><para>If
|
||||
options that are specified for the interfaces. Some hints: <tip><para>If
|
||||
your external interface is <filename class="devicefile">ppp0</filename> or
|
||||
<filename class="devicefile">ippp0</filename> or if you have a static
|
||||
<filename class="devicefile">ippp0</filename>, you can replace the
|
||||
<varname>detect</varname> in the second column with a <quote>-</quote>
|
||||
(minus the quotes).</para></tip><tip><para>If your external interface is
|
||||
<filename class="devicefile">ppp0</filename> or <filename
|
||||
class="devicefile">ippp0</filename> or if you have a static
|
||||
<acronym>IP</acronym> address, you can remove <varname>dhcp</varname> from
|
||||
the option list.</para></listitem></itemizedlist></para>
|
||||
the option list.</para></tip><tip><para>If your internal interface is a
|
||||
bridge create using the <command>brctl</command> utility then you must add
|
||||
the <varname>routeback</varname> option to the option list.</para></tip><tip><para>If
|
||||
you specify <emphasis>norfc1918</emphasis> for your external interface,
|
||||
you will want to check the <ulink url="errata.htm">Shorewall Errata</ulink>
|
||||
periodically for updates to the <filename>/usr/share/shorewall/rfc1918
|
||||
file</filename>. Alternatively, you can copy <filename>/usr/share/shorewall/rfc1918</filename>
|
||||
to <filename>/etc/shorewall/rfc1918</filename> then <ulink
|
||||
url="myfiles.htm#RFC1918">strip down your <filename>/etc/shorewall/rfc1918</filename>
|
||||
file as I do</ulink>.</para></tip></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -659,7 +669,7 @@ ACCEPT loc fw tcp 80 #Allow Weblet to work</progra
|
||||
traffic may flow freely between the local wired network and the wireless
|
||||
network.</para>
|
||||
|
||||
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /> </para>
|
||||
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
||||
|
||||
<para>There are only two changes that need to be made to the Shorewall
|
||||
configuration:</para>
|
||||
@ -701,6 +711,6 @@ eth0 wlan0</programlisting>
|
||||
either a WINS server or a PDC. I personally use Samba configured as a WINS
|
||||
server running on my firewall. Running a WINS server on your firewall
|
||||
requires the rules listed in the <ulink url="samba.htm">Shorewall/Samba
|
||||
documentation</ulink>. </para>
|
||||
documentation</ulink>.</para>
|
||||
</section>
|
||||
</article>
|
||||
Loading…
Reference in New Issue
Block a user