forked from extern/shorewall_code
Update for Shorewall 2.2.0 Beta 4
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1756 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
60c9d48fda
commit
60c710d9f4
@ -111,18 +111,6 @@
|
||||
# your kernel and iptables must include policy
|
||||
# match support.
|
||||
#
|
||||
# Yes -- Only packets that will be encrypted using
|
||||
# an ipsec policy will have their source
|
||||
# address changed.
|
||||
#
|
||||
# No -- Only packets that will not be encrypted
|
||||
# using an ipsec policy will have their
|
||||
# source address changed.
|
||||
#
|
||||
# - or empty is the same as No providing that
|
||||
# your kernel and iptables contain policy match
|
||||
# support.
|
||||
#
|
||||
# Comma-separated list of options from the following.
|
||||
# Only packets that will be encrypted via an SA that
|
||||
# matches these options will have their source address
|
||||
|
||||
@ -72,7 +72,7 @@
|
||||
# DNAT:debug). This causes the packet to be
|
||||
# logged at the specified level.
|
||||
#
|
||||
# If the ACTION names an action devined in
|
||||
# If the ACTION names an action defined in
|
||||
# /etc/shorewall/actions or in
|
||||
# /usr/share/shorewall/actions.std then:
|
||||
#
|
||||
|
||||
@ -1,10 +1,11 @@
|
||||
#
|
||||
# Shorewall 2.2 /usr/share/shorewall/action.AllowNNTP
|
||||
#
|
||||
# This action accepts NNTP traffic (Usenet).
|
||||
# This action accepts NNTP traffic (Usenet) and encrypted NNTP (NNTPS)
|
||||
#
|
||||
######################################################################################
|
||||
#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
|
||||
# PORT PORT(S) LIMIT GROUP
|
||||
ACCEPT - - tcp 119
|
||||
ACCEPT - - tcp 563
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
#
|
||||
# Shorewall 2.0-- Bogons File
|
||||
# Shorewall 2.2-- Bogons File
|
||||
#
|
||||
# /etc/shorewall/bogons
|
||||
#
|
||||
@ -48,7 +48,6 @@
|
||||
42.0.0.0/8 logdrop # Reserved
|
||||
49.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98
|
||||
50.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98
|
||||
58.0.0.0/7 logdrop # Reserved
|
||||
73.0.0.0/8 logdrop # Reserved
|
||||
74.0.0.0/7 logdrop # Reserved
|
||||
76.0.0.0/6 logdrop # Reserved
|
||||
|
||||
@ -1749,6 +1749,7 @@ setup_tunnels() # $1 = name of tunnels file
|
||||
# Process the ipsec file
|
||||
#
|
||||
setup_ipsec() {
|
||||
local zone
|
||||
#
|
||||
# Add a --set-mss rule to the passed chain
|
||||
#
|
||||
@ -6642,18 +6643,21 @@ add_to_zone() # $1 = <interface>[:<hosts>] $2 = zone
|
||||
#
|
||||
validate_interfaces_file
|
||||
#
|
||||
# Validate IPSec File
|
||||
#
|
||||
f=$(find_file ipsec)
|
||||
|
||||
if [ -f $f ]; then
|
||||
progress_message "Processing $f..."
|
||||
setup_ipsec $f
|
||||
fi
|
||||
#
|
||||
# Validate Zone
|
||||
#
|
||||
zone=$2
|
||||
|
||||
validate_zone $zone || startup_error "Unknown zone: $zone"
|
||||
|
||||
f=$(find_file ipsec)
|
||||
if [ -f $f ]; then
|
||||
progress_message "Processing $f..."
|
||||
setup_ipsec $f
|
||||
fi
|
||||
|
||||
[ "$zone" = $FW ] && startup_error "Can't add $1 to firewall zone"
|
||||
|
||||
eval is_ipsec=\$${zone}_is_ipsec
|
||||
|
||||
@ -1 +1 @@
|
||||
2.2.0-Beta3
|
||||
2.2.0-Beta4
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
<!--$Id$-->
|
||||
|
||||
<articleinfo>
|
||||
<title>Shorewall 2.0 Reference</title>
|
||||
<title>Shorewall 2.x Reference</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-10-25</pubdate>
|
||||
<pubdate>2004-11-18</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -181,6 +181,16 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><link linkend="Ipsec">ipsec</link></term>
|
||||
|
||||
<listitem>
|
||||
<para>a parameter file installed in <filename
|
||||
class="directory">/etc/shorewall</filename> and used to describe
|
||||
ipsec policies associated with zones.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><link linkend="Maclist">maclist</link></term>
|
||||
|
||||
@ -1625,7 +1635,11 @@ ACCEPT<emphasis role="bold">:info</emphasis> - - tc
|
||||
|
||||
<listitem>
|
||||
<para>refers to a connection request from any host in the
|
||||
specified subnet (example net:155.186.235.0/24).</para>
|
||||
specified subnet (example net:155.186.235.0/24). Beginning
|
||||
with Shorewall 2.1.0, IP address ranges of the form
|
||||
<<emphasis>first address</emphasis>>-<<emphasis>last
|
||||
address</emphasis>> may be specified. This requires that
|
||||
your kernel and iptables have iprange match support.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@ -1674,7 +1688,7 @@ ACCEPT<emphasis role="bold">:info</emphasis> - - tc
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Unlike in the SOURCE column, a range of IP addresses may be
|
||||
<para>Like in the SOURCE column, a range of IP addresses may be
|
||||
specified in the DEST column as <<emphasis>first
|
||||
address</emphasis>>-<<emphasis>last address</emphasis>>.
|
||||
When the ACTION is DNAT or DNAT-, connections will be assigned to
|
||||
@ -2566,7 +2580,7 @@ eth0 eth1 206.124.146.176</programlisting>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Example: Using the default LOGFORMAT, the log prefix for
|
||||
logging from the nat table's PREROUTING chain is: </para>
|
||||
logging from the nat table's PREROUTING chain is:</para>
|
||||
|
||||
<programlisting>Shorewall:nat:PREROUTING</programlisting>
|
||||
|
||||
@ -2934,7 +2948,7 @@ eth0 eth1 206.124.146.176</programlisting>
|
||||
enable martian logging for all interfaces, you may still enable it
|
||||
for individual interfaces using the <emphasis
|
||||
role="bold">logmartians</emphasis> interface option in <link
|
||||
linkend="Interfaces">/etc/shorewall/interfaces</link>. </para>
|
||||
linkend="Interfaces">/etc/shorewall/interfaces</link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-11-03</pubdate>
|
||||
<pubdate>2004-11-18</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -23,7 +23,7 @@
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
<edition>2.2.0 Beta 2</edition>
|
||||
<edition>2.2.0 Beta 4</edition>
|
||||
|
||||
<legalnotice>
|
||||
<para>Permission is granted to copy, distribute and/or modify this
|
||||
@ -275,6 +275,10 @@
|
||||
<listitem>
|
||||
<para><ulink url="Documentation.htm#Netmap">netmap</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="Documentation.htm#Ipsec">ipsec</ulink></para>
|
||||
</listitem>
|
||||
</itemizedlist></para>
|
||||
</listitem>
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-11-05</pubdate>
|
||||
<pubdate>2004-11-18</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -1966,12 +1966,53 @@ REJECT fw net:216.239.39.99 all</programlisting>Given that
|
||||
then be accurately parsed and decisions can be made based on the
|
||||
result.</para>
|
||||
</section>
|
||||
|
||||
<section id="faq42">
|
||||
<title>(FAQ 42) How can I tell which features my kernel and iptables
|
||||
support?</title>
|
||||
|
||||
<para>Answer: At a root prompt, enter the command <command>shorewall
|
||||
check</command>. There is a section near the top of the resulting output
|
||||
that gives you a synopsis of your kernel/iptables capabilities.</para>
|
||||
|
||||
<programlisting>gateway:/etc/shorewall # shorewall check
|
||||
Loading /usr/share/shorewall/functions...
|
||||
Processing /etc/shorewall/params ...
|
||||
Processing /etc/shorewall/shorewall.conf...
|
||||
Loading Modules...
|
||||
|
||||
Notice: The 'check' command is unsupported and problem
|
||||
reports complaining about errors that it didn't catch
|
||||
will not be accepted
|
||||
|
||||
Shorewall has detected the following iptables/netfilter capabilities:
|
||||
NAT: Available
|
||||
Packet Mangling: Available
|
||||
Multi-port Match: Available
|
||||
Connection Tracking Match: Available
|
||||
Packet Type Match: Not available
|
||||
Policy Match: Available
|
||||
Physdev Match: Available
|
||||
IP range Match: Available
|
||||
Verifying Configuration...
|
||||
...</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory>
|
||||
<revision>
|
||||
<revnumber>1.38</revnumber>
|
||||
|
||||
<date>2004-11-18</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Added FAQ 42.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.37</revnumber>
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2004-07-10</pubdate>
|
||||
<pubdate>2004-11-18</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003-2004</year>
|
||||
@ -27,14 +27,15 @@
|
||||
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 type="" url="Copyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||
<quote><ulink type="" url="Copyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<section>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>The information in this document applies only to 2.0.x releases of
|
||||
<para>The information in this document applies only to 2.x releases of
|
||||
Shorewall.</para>
|
||||
|
||||
<section>
|
||||
@ -43,7 +44,8 @@
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><ulink url="http://www.netfilter.org">Netfilter</ulink> - the
|
||||
packet filter facility built into the 2.4 and later Linux kernels.</para>
|
||||
packet filter facility built into the 2.4 and later Linux
|
||||
kernels.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -65,19 +67,19 @@
|
||||
<section>
|
||||
<title>What is Shorewall?</title>
|
||||
|
||||
<para>The Shoreline Firewall, more commonly known as <quote>Shorewall</quote>,
|
||||
is high-level tool for configuring Netfilter. You describe your
|
||||
firewall/gateway requirements using entries in a set of configuration
|
||||
files. Shorewall reads those configuration files and with the help of
|
||||
the iptables utility, Shorewall configures Netfilter to match your
|
||||
requirements. Shorewall can be used on a dedicated firewall system, a
|
||||
multi-function gateway/router/server or on a standalone GNU/Linux
|
||||
system. Shorewall does not use Netfilter's ipchains compatibility
|
||||
mode and can thus take advantage of Netfilter's connection state
|
||||
tracking capabilities.</para>
|
||||
<para>The Shoreline Firewall, more commonly known as
|
||||
<quote>Shorewall</quote>, is high-level tool for configuring Netfilter.
|
||||
You describe your firewall/gateway requirements using entries in a set
|
||||
of configuration files. Shorewall reads those configuration files and
|
||||
with the help of the iptables utility, Shorewall configures Netfilter to
|
||||
match your requirements. Shorewall can be used on a dedicated firewall
|
||||
system, a multi-function gateway/router/server or on a standalone
|
||||
GNU/Linux system. Shorewall does not use Netfilter's ipchains
|
||||
compatibility mode and can thus take advantage of Netfilter's connection
|
||||
state tracking capabilities.</para>
|
||||
|
||||
<para>Shorewall is not a daemon. Once Shorewall has configured
|
||||
Netfilter, it's job is complete and there is no <quote>Shorewall
|
||||
Netfilter, it's job is complete and there is no <quote>Shorewall
|
||||
process</quote> left running in your system. The <ulink
|
||||
url="starting_and_stopping_shorewall.htm">/sbin/shorewall program can be
|
||||
used at any time to monitor the Netfilter firewall</ulink>.</para>
|
||||
@ -92,54 +94,109 @@
|
||||
setups, you will only need to deal with a few of them.</para>
|
||||
|
||||
<para>Shorewall views the network where it is running as being composed of
|
||||
a set of zones. In the <ulink url="three-interface.htm">three-interface
|
||||
sample configuration</ulink> for example, the following zone names are
|
||||
used: <informaltable frame="all" pgwide="0"><tgroup align="left" cols="2"><thead
|
||||
valign="middle"><row valign="middle"><entry align="left">Name</entry><entry
|
||||
align="left">Description</entry></row></thead><tbody valign="middle"><row
|
||||
valign="middle"><entry align="left"><varname>net</varname></entry><entry
|
||||
align="left">The Internet</entry></row><row valign="middle"><entry
|
||||
align="left"><varname>loc</varname></entry><entry align="left">Your Local
|
||||
Network</entry></row><row valign="middle"><entry align="left"><varname>dmz</varname></entry><entry
|
||||
align="left">Demilitarized Zone</entry></row></tbody></tgroup></informaltable>Zones
|
||||
are defined in the <ulink url="Documentation.htm#Zones"><filename
|
||||
a set of <firstterm>zones</firstterm>. In the <ulink
|
||||
url="three-interface.htm">three-interface sample configuration</ulink> for
|
||||
example, the following zone names are used: <informaltable frame="all"
|
||||
pgwide="0">
|
||||
<tgroup align="left" cols="2">
|
||||
<thead valign="middle">
|
||||
<row valign="middle">
|
||||
<entry align="left">Name</entry>
|
||||
|
||||
<entry align="left">Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody valign="middle">
|
||||
<row valign="middle">
|
||||
<entry align="left"><varname>net</varname></entry>
|
||||
|
||||
<entry align="left">The Internet</entry>
|
||||
</row>
|
||||
|
||||
<row valign="middle">
|
||||
<entry align="left"><varname>loc</varname></entry>
|
||||
|
||||
<entry align="left">Your Local Network</entry>
|
||||
</row>
|
||||
|
||||
<row valign="middle">
|
||||
<entry align="left"><varname>dmz</varname></entry>
|
||||
|
||||
<entry align="left">Demilitarized Zone</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>Zones are defined in the <ulink
|
||||
url="Documentation.htm#Zones"><filename
|
||||
class="directory">/etc/shorewall/</filename><filename>zones</filename></ulink>
|
||||
file.</para>
|
||||
|
||||
<para>Shorewall also recognizes the firewall system as its own zone - by
|
||||
default, the firewall itself is known as <emphasis role="bold"><varname>fw</varname></emphasis>.</para>
|
||||
default, the firewall itself is known as <emphasis
|
||||
role="bold"><varname>fw</varname></emphasis>.</para>
|
||||
|
||||
<para>Rules about what traffic to allow and what traffic to deny are
|
||||
expressed in terms of zones. <itemizedlist spacing="compact"><listitem><para>You
|
||||
express your default policy for connections from one zone to another zone
|
||||
in the <ulink url="Documentation.htm#Policy"><filename class="directory">/etc/shorewall/</filename><filename>policy</filename></ulink>
|
||||
file. The choices for policy are:</para><itemizedlist><listitem><para>ACCEPT
|
||||
- Accept the connection.</para></listitem><listitem><para>DROP - Ignore
|
||||
the connection request.</para></listitem><listitem><para>REJECT - Return
|
||||
an appropriate error to the connection request.</para></listitem></itemizedlist><para>Connection
|
||||
request logging may be specified as part of a policy and it is
|
||||
conventional to log DROP and REJECT policies.</para></listitem><listitem><para>You
|
||||
define exceptions to those default policies in the <ulink
|
||||
url="Documentation.htm#Rules"><filename class="directory">/etc/shorewall/</filename><filename>rules</filename></ulink>
|
||||
file.</para></listitem><listitem><para>You only need concern yourself with
|
||||
connection requests. You don't need to define rules for how traffic
|
||||
that is part of an established connection is handled and in most cases you
|
||||
don't have to worry about how related connections are handled (ICMP
|
||||
error packets and <ulink url="FTP.html">related TCP connection requests
|
||||
such as used by FTP</ulink>).</para></listitem></itemizedlist>For each
|
||||
connection request entering the firewall, the request is first checked
|
||||
against the <filename class="directory">/etc/shorewall/</filename><filename>rules</filename>
|
||||
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 (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>
|
||||
expressed in terms of zones. <itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>You express your default policy for connections from one zone
|
||||
to another zone in the <ulink
|
||||
url="Documentation.htm#Policy"><filename
|
||||
class="directory">/etc/shorewall/</filename><filename>policy</filename></ulink>
|
||||
file. The basic choices for policy are:</para>
|
||||
|
||||
<para>The <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>ACCEPT - Accept the connection.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>DROP - Ignore the connection request.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>REJECT - Return an appropriate error to the connection
|
||||
request.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Connection request logging may be specified as part of a
|
||||
policy and it is conventional to log DROP and REJECT
|
||||
policies.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>You define exceptions to these default policies in the <ulink
|
||||
url="Documentation.htm#Rules"><filename
|
||||
class="directory">/etc/shorewall/</filename><filename>rules</filename></ulink>
|
||||
file.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>You only need concern yourself with connection requests. You
|
||||
don't need to define rules for how traffic that is part of an
|
||||
established connection is handled and in most cases you don't have
|
||||
to worry about how related connections are handled (ICMP error
|
||||
packets and <ulink url="FTP.html">related TCP connection requests
|
||||
such as used by FTP</ulink>).</para>
|
||||
</listitem>
|
||||
</itemizedlist>For each connection request entering the firewall, the
|
||||
request is first checked against the <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>rules</filename>
|
||||
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 (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:
|
||||
<programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||||
loc net ACCEPT
|
||||
@ -149,18 +206,34 @@ all all REJECT info</programlisting>In the three-interface
|
||||
firewall system to have full access to servers on the internet, uncomment
|
||||
that line. <programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||||
fw net ACCEPT</programlisting> The above policy will:
|
||||
<itemizedlist><listitem><para>Allow all connection requests from your
|
||||
local network to the internet</para></listitem><listitem><para>Drop
|
||||
(ignore) all connection requests from the internet to your firewall or
|
||||
local network; these ignored connection requests will be logged using the
|
||||
<emphasis>info</emphasis> syslog priority (log level).</para></listitem><listitem><para>Optionally
|
||||
accept all connection requests from the firewall to the internet (if you
|
||||
uncomment the additional policy)</para></listitem><listitem><para>reject
|
||||
all other connection requests; these rejected connection requests will be
|
||||
logged using the <emphasis>info</emphasis> syslog priority (log level).</para></listitem></itemizedlist></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Allow all connection requests from your local network to the
|
||||
internet</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Drop (ignore) all connection requests from the internet to
|
||||
your firewall or local network; these ignored connection requests
|
||||
will be logged using the <emphasis>info</emphasis> syslog priority
|
||||
(log level).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Optionally accept all connection requests from the firewall to
|
||||
the internet (if you uncomment the additional policy)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>reject all other connection requests; these rejected
|
||||
connection requests will be logged using the
|
||||
<emphasis>info</emphasis> syslog priority (log level).</para>
|
||||
</listitem>
|
||||
</itemizedlist></para>
|
||||
|
||||
<para>The simplest way to define a zone is to associate the zone with a
|
||||
network interface using the <ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
|
||||
network interface using the <ulink
|
||||
url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
|
||||
file. In the three-interface sample, the three zones are defined using
|
||||
that file as follows:</para>
|
||||
|
||||
@ -194,16 +267,16 @@ ACCEPT net fw tcp 22</programlisting>
|
||||
<listitem>
|
||||
<para>The <ulink url="shorewall_quickstart_guide.htm">QuickStart
|
||||
guildes</ulink> provide links to download pre-populated files for use
|
||||
in common setups and the <ulink url="shorewall_setup_guide.htm">Shorewall
|
||||
Setup Guide</ulink> shows you examples for use with other more complex
|
||||
setups.</para>
|
||||
in common setups and the <ulink
|
||||
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink> shows
|
||||
you examples for use with other more complex setups.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>To keep your <ulink url="shorewall_logging.html">firewall log</ulink>
|
||||
from filling up with useless noise, Shorewall provides <ulink
|
||||
url="User_defined_Actions.html">common actions</ulink> that silently
|
||||
discard or reject such noise before it can be logged. As with
|
||||
<para>To keep your <ulink url="shorewall_logging.html">firewall
|
||||
log</ulink> from filling up with useless noise, Shorewall provides
|
||||
<ulink url="User_defined_Actions.html">common actions</ulink> that
|
||||
silently discard or reject such noise before it can be logged. As with
|
||||
everything in Shorewall, you can alter the behavior of these common
|
||||
actions (or do away with them entirely) as you see fit.</para>
|
||||
</listitem>
|
||||
@ -214,9 +287,10 @@ ACCEPT net fw tcp 22</programlisting>
|
||||
<title>License</title>
|
||||
|
||||
<para>This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of <ulink url="http://www.gnu.org/licenses/gpl.html">Version
|
||||
2 of the GNU General Public License</ulink> as published by the Free
|
||||
Software Foundation.</para>
|
||||
it under the terms of <ulink
|
||||
url="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU General
|
||||
Public License</ulink> as published by the Free Software
|
||||
Foundation.</para>
|
||||
|
||||
<para>This program is distributed in the hope that it will be useful, but
|
||||
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-08-10</pubdate>
|
||||
<pubdate>2004-11-16</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -29,7 +29,8 @@
|
||||
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>
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -37,9 +38,9 @@
|
||||
one network appear to be logically part of a different physical network
|
||||
connected to the same router/firewall. Typically it allows us to hide a
|
||||
machine with a public IP address on a private network behind a router, and
|
||||
still have the machine appear to be on the public network "in front
|
||||
of" the router. The router "proxys" ARP requests and all network
|
||||
traffic to and from the hidden machine to make this fiction possible.</para>
|
||||
still have the machine appear to be on the public network "in front of" the
|
||||
router. The router "proxys" ARP requests and all network traffic to and from
|
||||
the hidden machine to make this fiction possible.</para>
|
||||
|
||||
<para>Consider a router with two interface cards, one connected to a public
|
||||
network PUBNET and one connected to a private network PRIVNET. We want to
|
||||
@ -49,16 +50,16 @@
|
||||
behind the router.</para>
|
||||
|
||||
<para>By enabling proxy ARP on the router, any machine on the PUBNET network
|
||||
that issues an ARP "who has" request for the server's MAC
|
||||
address will get a proxy ARP reply from the router containing the
|
||||
router's MAC address. This tells machines on the PUBNET network that
|
||||
they should be sending packets destined for the server via the router. The
|
||||
router forwards the packets from the machines on the PUBNET network to the
|
||||
server on the PRIVNET network.</para>
|
||||
that issues an ARP "who has" request for the server's MAC address will get a
|
||||
proxy ARP reply from the router containing the router's MAC address. This
|
||||
tells machines on the PUBNET network that they should be sending packets
|
||||
destined for the server via the router. The router forwards the packets from
|
||||
the machines on the PUBNET network to the server on the PRIVNET
|
||||
network.</para>
|
||||
|
||||
<para>Similarly, when the server on the PRIVNET network issues a "who
|
||||
has" request for any machines on the PUBNET network, the router provides
|
||||
its own MAC address via proxy ARP. This tells the server to send packets for
|
||||
<para>Similarly, when the server on the PRIVNET network issues a "who has"
|
||||
request for any machines on the PUBNET network, the router provides its own
|
||||
MAC address via proxy ARP. This tells the server to send packets for
|
||||
machines on the PUBNET network via the router. The router forwards the
|
||||
packets from the server on the PRIVNET network to the machines on the PUBNET
|
||||
network.</para>
|
||||
@ -71,7 +72,8 @@
|
||||
hidden behind the router.</para>
|
||||
|
||||
<para>Before you try to use this technique, I strongly recommend that you
|
||||
read the <ulink url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink>.</para>
|
||||
read the <ulink url="shorewall_setup_guide.htm">Shorewall Setup
|
||||
Guide</ulink>.</para>
|
||||
|
||||
<section>
|
||||
<title>Example</title>
|
||||
@ -92,22 +94,22 @@
|
||||
|
||||
<para>Be sure that the internal systems (130.242.100.18 and 130.252.100.19
|
||||
in the above example) are not included in any specification in
|
||||
<filename>/etc/shorewall/masq</filename> or <filename>/etc/shorewall/nat</filename>.
|
||||
</para>
|
||||
<filename>/etc/shorewall/masq</filename> or
|
||||
<filename>/etc/shorewall/nat</filename>.</para>
|
||||
|
||||
<note>
|
||||
<para>I've used an RFC1918 IP address for eth1 - that IP address is
|
||||
<para>I've used an RFC1918 IP address for eth1 - that IP address is
|
||||
largely irrelevant (see below).</para>
|
||||
</note>
|
||||
|
||||
<para>The lower systems (130.252.100.18 and 130.252.100.19) should have
|
||||
their subnet mask and default gateway configured exactly the same way that
|
||||
the Firewall system's eth0 is configured. In other words, they should
|
||||
be configured just like they would be if they were parallel to the
|
||||
firewall rather than behind it. </para>
|
||||
the Firewall system's eth0 is configured. In other words, they should be
|
||||
configured just like they would be if they were parallel to the firewall
|
||||
rather than behind it.</para>
|
||||
|
||||
<warning>
|
||||
<para>Do not add the Proxy ARP'ed address(es) (130.252.100.18 and
|
||||
<para>Do not add the Proxy ARP'ed address(es) (130.252.100.18 and
|
||||
130.252.100.19 in the above example) to the external interface (eth0 in
|
||||
this example) of the firewall.</para>
|
||||
</warning>
|
||||
@ -132,22 +134,45 @@
|
||||
url="myfiles.htm">that I take with my DMZ</ulink>.</para>
|
||||
|
||||
<warning>
|
||||
<para>Your distribution's network configuration GUI may not be
|
||||
capable of configuring a device in this way. It may complain about the
|
||||
duplicate address or it may configure the address incorrectly. Here is
|
||||
what the above configuration should look like when viewed using
|
||||
<command>ip</command> (the part of the output that is in <emphasis
|
||||
role="bold">bold text</emphasis> is relevant):</para>
|
||||
<para>Your distribution's network configuration GUI may not be capable
|
||||
of configuring a device in this way. It may complain about the duplicate
|
||||
address or it may configure the address incorrectly. Here is what the
|
||||
above configuration should look like when viewed using
|
||||
<command>ip</command> (the line "inet 130.252.100.17/32 scope global
|
||||
eth1" is the most important):</para>
|
||||
|
||||
<programlisting>gateway:~# <command>ip addr ls eth1</command>
|
||||
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
|
||||
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
|
||||
link/ether 00:a0:cc:d1:db:12 brd ff:ff:ff:ff:ff:ff
|
||||
<emphasis role="bold">inet 130.252.100.17/32 scope global eth1</emphasis>
|
||||
gateway:~#</programlisting>
|
||||
|
||||
<para>Note in particular that there is no broadcast address. <ulink
|
||||
url="myfiles.htm#Interfaces">Here is how I configure a device in this
|
||||
way under Debian</ulink>.</para>
|
||||
<para>Note in particular that there is no broadcast address. Here is an
|
||||
<filename>ifcfg-eth-id-00:a0:cc:d1:db:12</filename> file from SuSE that
|
||||
produces this result (Note: SuSE ties the configuration file to the card
|
||||
by embedding the card's MAC address in the file name):</para>
|
||||
|
||||
<programlisting>BOOTPROTO='static'
|
||||
BROADCAST='130.252.100.17'
|
||||
IPADDR='130.252.100.17'
|
||||
MTU=''
|
||||
NETMASK='255.255.255.255'
|
||||
NETWORK='130.252.100.17'
|
||||
REMOTE_IPADDR=''
|
||||
STARTMODE='onboot'
|
||||
UNIQUE='8otl.IPwRm6bNMRD'
|
||||
_nm_name='bus-pci-0000:00:04.0'</programlisting>
|
||||
|
||||
<para>Here is an excerpt from a Debian /etc/shorewall/interfaces file
|
||||
that does the same thing:</para>
|
||||
|
||||
<programlisting>...
|
||||
auto eth1
|
||||
iface eth1 inet static
|
||||
address 130.252.100.17
|
||||
netmask 255.255.255.255
|
||||
broadcast 0.0.0.0
|
||||
...</programlisting>
|
||||
</warning>
|
||||
</section>
|
||||
|
||||
@ -163,11 +188,13 @@ gateway:~#</programlisting>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>A reading of <citetitle>TCP/IP Illustrated, Vol 1</citetitle> by
|
||||
Stevens reveals<footnote><para>Courtesy of Bradey Honsinger</para></footnote>
|
||||
that a <quote>gratuitous</quote> ARP packet should cause the ISP's
|
||||
router to refresh their ARP cache (section 4.7). A gratuitous ARP is
|
||||
simply a host requesting the MAC address for its own IP; in addition
|
||||
to ensuring that the IP address isn't a duplicate...</para>
|
||||
Stevens reveals<footnote>
|
||||
<para>Courtesy of Bradey Honsinger</para>
|
||||
</footnote> that a <quote>gratuitous</quote> ARP packet should cause
|
||||
the ISP's router to refresh their ARP cache (section 4.7). A
|
||||
gratuitous ARP is simply a host requesting the MAC address for its own
|
||||
IP; in addition to ensuring that the IP address isn't a
|
||||
duplicate...</para>
|
||||
|
||||
<blockquote>
|
||||
<para>if the host sending the gratuitous ARP has just changed its
|
||||
@ -179,15 +206,16 @@ gateway:~#</programlisting>
|
||||
<para>Which is, of course, exactly what you want to do when you switch
|
||||
a host from being exposed to the Internet to behind Shorewall using
|
||||
proxy ARP (or one-to-one NAT for that matter). Happily enough, recent
|
||||
versions of Redhat's iputils package include <quote>arping</quote>,
|
||||
versions of Redhat's iputils package include <quote>arping</quote>,
|
||||
whose <quote>-U</quote> flag does just that:</para>
|
||||
|
||||
<programlisting>arping -U -I <<emphasis>net if</emphasis>> <<emphasis>newly proxied IP</emphasis>>
|
||||
<programlisting>arping -U -I <<emphasis>net if</emphasis>> <<emphasis>newly proxied IP</emphasis>>
|
||||
arping -U -I eth0 66.58.99.83 # for example</programlisting>
|
||||
|
||||
<para>Stevens goes on to mention that not all systems respond
|
||||
correctly to gratuitous ARPs, but googling for <quote>arping -U</quote>
|
||||
seems to support the idea that it works most of the time.</para>
|
||||
correctly to gratuitous ARPs, but googling for <quote>arping
|
||||
-U</quote> seems to support the idea that it works most of the
|
||||
time.</para>
|
||||
|
||||
<para>To use arping with Proxy ARP in the above example, you would
|
||||
have to:</para>
|
||||
@ -204,32 +232,32 @@ shorewall start</programlisting>
|
||||
|
||||
<listitem>
|
||||
<para>You can call your ISP and ask them to purge the stale ARP cache
|
||||
entry but many either can't or won't purge individual entries.</para>
|
||||
entry but many either can't or won't purge individual entries.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>You can determine if your ISP's gateway ARP cache is stale using
|
||||
<para>You can determine if your ISP's gateway ARP cache is stale using
|
||||
ping and tcpdump. Suppose that we suspect that the gateway router has a
|
||||
stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as
|
||||
follows:</para>
|
||||
|
||||
<programlisting>tcpdump -nei eth0 icmp</programlisting>
|
||||
|
||||
<para>Now from 130.252.100.19, ping the ISP's gateway (which we will
|
||||
<para>Now from 130.252.100.19, ping the ISP's gateway (which we will
|
||||
assume is 130.252.100.254):</para>
|
||||
|
||||
<programlisting>ping 130.252.100.254</programlisting>
|
||||
|
||||
<para>We can now observe the tcpdump output:</para>
|
||||
|
||||
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
|
||||
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply</programlisting>
|
||||
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
|
||||
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply</programlisting>
|
||||
|
||||
<para>Notice that the source MAC address in the echo request is different
|
||||
from the destination MAC address in the echo reply!! In this case
|
||||
0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
|
||||
0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
|
||||
0:c0:a8:50:b2:57 was the MAC address of the system on the lower left. In
|
||||
other words, the gateway's ARP cache still associates 130.252.100.19
|
||||
with the NIC in that system rather than with the firewall's eth0.</para>
|
||||
other words, the gateway's ARP cache still associates 130.252.100.19 with
|
||||
the NIC in that system rather than with the firewall's eth0.</para>
|
||||
</section>
|
||||
</article>
|
||||
@ -13,7 +13,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2004-10-26</pubdate>
|
||||
<pubdate>2004-11-14</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
@ -91,8 +91,7 @@
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Shorewall generally does not contain any support for Netfilter
|
||||
<ulink
|
||||
url="http://www.netfilter.org/documentation/pomlist/pom-summary.html">Patch-O-Matic-ng</ulink>
|
||||
<ulink url="http://www.netfilter.org">Patch-O-Matic-ng</ulink>
|
||||
features or any other features that require kernel patching --
|
||||
Shorewall only supports features from released kernels except in
|
||||
unusual cases.</para>
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-10-25</pubdate>
|
||||
<pubdate>2004-11-12</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -69,11 +69,12 @@
|
||||
<para><ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/1.4.10/rfc1918">Here</ulink>
|
||||
is the most up to date version of the <ulink
|
||||
url="Documentation.htm#rfc1918">rfc1918 file</ulink>. This file only
|
||||
applies to Shorewall version 2.0.0 and its bugfix updates. In Shorewall
|
||||
2.0.1 and later releases, the <filename>bogons</filename> file lists IP
|
||||
ranges that are reserved by the IANA and the <filename>rfc1918</filename>
|
||||
file only lists those three ranges that are reserved by <ulink
|
||||
url="Documentation.htm#rfc1918">rfc1918 file</ulink>. <emphasis
|
||||
role="bold">This file only applies to Shorewall versions 1.4.* and 2.0.0
|
||||
and its bugfix updates</emphasis>. In Shorewall 2.0.1 and later releases,
|
||||
the <filename>bogons</filename> file lists IP ranges that are reserved by
|
||||
the IANA and the <filename>rfc1918</filename> file only lists those three
|
||||
ranges that are reserved by <ulink
|
||||
url="shorewall_setup_guide.htm#RFC1918">RFC 1918</ulink>.</para>
|
||||
</section>
|
||||
|
||||
@ -81,7 +82,7 @@
|
||||
<title>Bogons File</title>
|
||||
|
||||
<para><ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.8/bogons">Here</ulink>
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.10/bogons">Here</ulink>
|
||||
is the most up to date version of the <ulink
|
||||
url="Documentation.htm#Bogons">bogons file</ulink>.</para>
|
||||
</section>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-10-24</pubdate>
|
||||
<pubdate>2004-11-19</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -162,6 +162,17 @@
|
||||
<para>Zones are defined in the file <filename><ulink
|
||||
url="Documentation.htm#Zones"><filename>/etc/shorewall/zones</filename></ulink></filename>.</para>
|
||||
|
||||
<important>
|
||||
<para>Beginning with Shorewall 2.2.0, the
|
||||
<filename>/etc/shorewall/zones</filename> file included in the release
|
||||
is empty. You can create the above set of zones by copying and pasting
|
||||
the following into the file:</para>
|
||||
|
||||
<programlisting>net Net Internet
|
||||
loc Local Local networks
|
||||
dmz DMZ Demilitarized zone</programlisting>
|
||||
</important>
|
||||
|
||||
<para>Shorewall also recognizes the firewall system as its own zone - by
|
||||
default, the firewall itself is known as <emphasis
|
||||
role="bold">fw</emphasis> but that may be changed in the <ulink
|
||||
@ -280,6 +291,12 @@ all all REJECT info</programlisting>
|
||||
|
||||
<para>At this point, edit your <filename>/etc/shorewall/policy
|
||||
</filename>and make any changes that you wish.</para>
|
||||
|
||||
<important>
|
||||
<para>Beginning with Shorewall 2.2.0, the released policy file is empty.
|
||||
You can copy and paste the above entries to create a starting point from
|
||||
which to customize your policies.</para>
|
||||
</important>
|
||||
</section>
|
||||
|
||||
<section id="Interfaces">
|
||||
|
||||
@ -28,7 +28,7 @@
|
||||
# shown below. Simply run this script to revert to your prior version of
|
||||
# Shoreline Firewall.
|
||||
|
||||
VERSION=2.2.0-Beta3
|
||||
VERSION=2.2.0-Beta4
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA
|
||||
#
|
||||
|
||||
VERSION=2.2.0-Beta3
|
||||
VERSION=2.2.0-Beta4
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Shorewall 2.2.0-Beta3
|
||||
Shorewall 2.2.0-Beta4
|
||||
|
||||
----------------------------------------------------------------------
|
||||
Problems Corrected since 2.0.3
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
%define name shorewall
|
||||
%define version 2.2.0
|
||||
%define release 0Beta3
|
||||
%define release 0Beta4
|
||||
%define prefix /usr
|
||||
|
||||
Summary: Shoreline Firewall is an iptables-based firewall for Linux systems.
|
||||
@ -137,6 +137,8 @@ fi
|
||||
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
|
||||
|
||||
%changelog
|
||||
* Fri Nov 19 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated to 2.2.0-0Beta3
|
||||
* Tue Nov 09 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated to 2.2.0-0Beta3
|
||||
* Tue Nov 02 2004 Tom Eastep tom@shorewall.net
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
# You may only use this script to uninstall the version
|
||||
# shown below. Simply run this script to remove Seattle Firewall
|
||||
|
||||
VERSION=2.2.0-Beta3
|
||||
VERSION=2.2.0-Beta4
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
Loading…
Reference in New Issue
Block a user