holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Add Packet Handling Article

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1463 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2004-07-10 23:29:06 +00:00
parent da3e9e46db
commit 86bbae3111
7 changed files with 823 additions and 671 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Shorewall-docs2/Documentation_Index.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-07-03</pubdate>
<pubdate>2004-07-10</pubdate>
<copyright>
<year>2001-2004</year>
@ -256,6 +256,11 @@
Shorewall</ulink></para>
</listitem>
<listitem>
<para><ulink url="PacketHandling.html">Packet Processing in a
Shorewall-based Firewall</ulink></para>
</listitem>
<listitem>
<para><ulink url="ping.html">&#39;Ping&#39; Management</ulink></para>
</listitem>

67
Shorewall-docs2/Introduction.xml
View File

@ -13,7 +13,7 @@
<surname>Eastep</surname>
</author>
<pubdate>2004-02-17</pubdate>
<pubdate>2004-07-10</pubdate>
<copyright>
<year>2003-2004</year>
@ -77,25 +77,11 @@
tracking capabilities.</para>
<para>Shorewall is not a daemon. Once Shorewall has configured
Netfilter, it&#39;s job is complete although the <ulink
Netfilter, it&#39;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>
</section>
<section>
<title>Getting Started with Shorewall</title>
<para>New to Shorewall? Start by selecting the <ulink
url="shorewall_quickstart_guide.htm">QuickStart Guide</ulink> that most
closely match your environment and follow the step by step instructions.</para>
</section>
<section>
<title>Looking for Information?</title>
<para>The <ulink url="Documentation_Index.html">Documentation Index</ulink>
is a good place to start.</para>
</section>
</section>
<section>
@ -135,9 +121,14 @@
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></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.</para></listitem><listitem><para>You only need concern yourself with
connection requests. You don&#39;t need to define rules for how traffic
that is part of an established connection is handled and in most cases you
don&#39;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
@ -181,6 +172,42 @@ dmz eth2 detect</programlisting>
<para>The above file defines the net zone as all hosts interfacing to the
firewall through eth0, the loc zone as all hosts interfacing through eth1
and the dmz as all hosts interfacing through eth2.</para>
<para>To illustrate how rules provide exceptions to policies, suppose that
you have the polcies listed above but you want to be able to connect to
your firewall from the internet using Secure Shell (SSH). Recall that SSH
connects uses TCP port 22.</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT net fw tcp 22</programlisting>
<para>So although you have a policy of ignoring all connection attempts
from the net zone (from the internet), the above exception to that policy
allows you to connect to the SSH server running on your firewall.</para>
<para>Because Shorewall makes no assumptions about what traffic you want
accepted, there are certain rules (exceptions) that need to be added to
almost any configuration.</para>
<itemizedlist>
<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>
</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
everything in Shorewall, you can alter the behavior of these common
actions (or do away with them entirely) as you see fit.</para>
</listitem>
</itemizedlist>
</section>
<section>

316
Shorewall-docs2/PacketHandling.xml Executable file
View File

@ -0,0 +1,316 @@
<?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>Packet Handling</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-07-10</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>Introduction</title>
<para>This article will try to help you understand how packets pass
through a firewall configured by Shorewall. You may find it useful to have
a copy of the <ulink url="NetfilterOverview.html">Netfilter Overview</ulink>
handy to refer to.</para>
<para>The discussion that follows assumes that you are running a current
kernel (2.4.2n or 2.6.m) with the <ulink url="kernel.htm">recommended
options </ulink>included. Otherwise processing may be somewhat different
from described below depending on the features supported by your kernel.</para>
<para>Where a packet is covered by steps in more than one of the following
sections, processing occurs in the order in which the sections appear.</para>
</section>
<section>
<title>Packets Entering the Firewall from Outside</title>
<para>Certain processing occurs on packets entering the firewall from the
outside that don&#39;t occur for packets that originate on the firewall
itself.</para>
<itemizedlist>
<listitem>
<para>The TOS field in the packet is conditionally altered based on
the contents of your <filename>/etc/shorewall/tos</filename> file.
This occurs in the <emphasis role="bold">pretos</emphasis> chain of
the <emphasis>mangle</emphasis> table.</para>
</listitem>
<listitem>
<para>Packets are marked based on the contents of your
<filename>/etc/shorewall/tcrules</filename> file and the setting of
MARK_IN_FORWARD_CHAIN in <filename>/etc/shorewall/shorewall.conf</filename>.
This occurs in the <emphasis role="bold">tcpre</emphasis> chain of the
<emphasis>mangle</emphasis> table.</para>
</listitem>
<listitem>
<para>The destination IP address and/or port number are rewritten
according to DNAT[-] and REDIRECT[-] rules in <filename>/etc/shorewall/rules</filename>.
For new connection requests, this occurs in a chain in the
<emphasis>nat</emphasis> table called <emphasis role="bold"><emphasis>zone</emphasis>_dnat</emphasis>
where <emphasis>zone</emphasis> is the zone where the request
originated. For packets that are part of an already established
connection, the destination rewriting takes place without any
involvement of a netfilter rule.</para>
</listitem>
<listitem>
<para>If the destination was not rewritten in the previous step then
it may be rewritten based on entries in /etc/shorewall/nat. For new
connection requests, this occurs in a <emphasis>nat</emphasis> table
chain called <emphasis role="bold"><emphasis>interface</emphasis>_in</emphasis>
where <emphasis>interface</emphasis> is the interface on which the
packet entered the firewall. For packets that are part of an already
established connection, the destination rewriting takes place without
any involvement of a Netfilter rule.</para>
</listitem>
<listitem>
<para>The packet passes through the accounting rules defined in
<filename>/etc/shorewall/accounting</filename>.</para>
</listitem>
<listitem>
<para>If Netfilter doesn&#39;t know what to do with the packet
(connection state INVALID) and the protocol is not ICMP then the
packet is silently dropped.</para>
</listitem>
<listitem>
<para>The packet is processed according to your <ulink
url="blacklisting_support.htm">Blacklisting configuration</ulink>
(dynamic blacklist first). If BLACKLISTNEWONLY=Yes in
<filename>/etc/shorewall/shorewall.conf</filename> then only new
connection requests are processed. Processing occurs in the dynamic
and blacklst</para>
</listitem>
<listitem>
<para>If the interface on which the packet entered the firewall has
the <emphasis>nosmurfs</emphasis> option specified in
<filename>/etc/shorewall/interfaces</filename>, then if the packet is
a new connection request is checked for being a smurf in the
<emphasis>filter</emphasis> table&#39;s <emphasis role="bold">smurfs</emphasis>
chain.</para>
</listitem>
<listitem>
<para>If:</para>
<itemizedlist>
<listitem>
<para>the packet will be processed by the firewall itself</para>
</listitem>
<listitem>
<para>the interface on which the packet arrived has the
<emphasis>dhcp</emphasis> option in <filename>/etc/shorewall/interfaces</filename>.</para>
</listitem>
<listitem>
<para>packet&#39;s protocol is UDP with destination port 67 or 68.</para>
</listitem>
</itemizedlist>
<para>then the packet is ACCEPTed in the filter table&#39;s <emphasis
role="bold"><emphasis>interface</emphasis>_in</emphasis> chain (for
example, eth0_in).</para>
</listitem>
<listitem>
<para>If the interface on which the packet entered the firewall has
the <emphasis>norfc1918</emphasis> option specified in
<filename>/etc/shorewall/interfaces</filename>, then the packet is
processed against your rfc1918 file (normally <filename>/usr/share/shorewall/rfc1918</filename>
but that file may be copied to <filename>/etc/shorewall/rfc1918</filename>
and modified). This happens in the filter table&#39;s rfc1918 chain.</para>
</listitem>
<listitem>
<para>If the interface on which the packet entered the firewall has
the <emphasis>nobogons</emphasis> option specified in
<filename>/etc/shorewall/interfaces</filename>, then the packet is
processed against your bogons file (normally <filename>/usr/share/shorewall/bogons</filename>
but that file may be copied to <filename>/etc/shorewall/bogons</filename>
and modified).</para>
</listitem>
<listitem>
<para>If the interface on which the packet entered the firewall has
the <emphasis>tcpflags</emphasis> option specified in
<filename>/etc/shorewall/interfaces</filename> and the packet&#39;s
protocol is TCP then the TCP flags are checked by the <emphasis
role="bold">tcpflags</emphasis> chain (filter table).</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>All Packets</title>
<para>Regardless of whether the packet originated on the firewall or came
from outside, certain processing steps are common.</para>
<itemizedlist>
<listitem>
<para>Packets are marked based on the contents of your
<filename>/etc/shorewall/tcrules</filename> file and the setting of
MARK_IN_FORWARD_CHAIN in <filename>/etc/shorewall/shorewall.conf</filename>.
This occurs in the <emphasis role="bold">tcfor</emphasis> chain of the
<emphasis>mangle</emphasis> table.</para>
<para>The remaining processing in this list occurs in the
<emphasis>filter</emphasis> table.</para>
</listitem>
<listitem>
<para>If either the host sending the packet or the host to which the
packet is addressed is not in any defined zone then the all-&#62;all
policy is applied to the packet (including logging). This can occur in
the INPUT, FORWARD or OUTPUT chains.</para>
</listitem>
<listitem>
<para>If the packet is part of an established connection or is part of
a related connection then no further processing takes place in the
filter table (<emphasis>z</emphasis><emphasis role="bold"><emphasis>one1</emphasis>2<emphasis>zone2</emphasis></emphasis>
chain where <emphasis>zone1</emphasis> is the source zone and
<emphasis>zone2</emphasis> is the destination zone).</para>
</listitem>
<listitem>
<para>If NEWNOTSYN=Yes in /etc/shorewall/shorewall.conf then If the
packet&#39;s protocol is TCP and is not a syn packet then the packet
is processed by the <emphasis role="bold">newnotsyn</emphasis> chain.</para>
</listitem>
<listitem>
<para>The packet is processed according to your <filename>/etc/shorewall/rules</filename>
file. This happens in chains named <emphasis>z</emphasis><emphasis
role="bold"><emphasis>one1</emphasis>2<emphasis>zone2</emphasis></emphasis>
chain where <emphasis>zone1</emphasis> is the source zone and
<emphasis>zone2</emphasis> is the destination zone. Note that in the
presence of <ulink url="Documentation.htm#Nested">nested or
overlapping zones</ulink> and CONTINUE policies, a packet may go
through more than one of these chains.</para>
</listitem>
<listitem>
<para>Note: If the packet gets to this step, it did not match any
rule.</para>
<para>If the applicable policy has a <ulink
url="User_defined_Actions.html">common action</ulink> then that action
is applied (chain has the same name as the action).</para>
</listitem>
<listitem>
<para>If the applicable policy has logging specified, the packet is
logged.</para>
</listitem>
<listitem>
<para>The policy is applied (the packet is accepted, dropped or
rejected).</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Packets Leaving the Firewall</title>
<para>Packets being sent to another host undergo additional processing.</para>
<note>
<para>The source IP address only gets rewritten by the first matching
rule below.</para>
</note>
<itemizedlist>
<listitem>
<para>The source IP address may be rewritten according to DNAT rules
that specify SNAT. If this is a new connection request, then the
rewriting occurs in a <emphasis>nat</emphasis> table chain called
<emphasis role="bold"><emphasis>zone</emphasis>_snat</emphasis> where
<emphasis>zone</emphasis> is the destination zone. For packets that
are part of an already established connection, the destination
rewriting takes place without any involvement of a Netfilter rule.</para>
</listitem>
<listitem>
<para>The source IP address may be rewritten according to an entry in
the <filename>/etc/shorewall/nat</filename> file. If this is a new
connection request, then the rewriting occurs in a
<emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>interface</emphasis>_snat</emphasis>
where <emphasis>interface</emphasis> is the interface on which the
packet will be sent. For packets that are part of an already
established connection, the destination rewriting takes place without
any involvement of a Netfilter rule.</para>
</listitem>
<listitem>
<para>The source IP address may be rewritten according to an entry in
the <filename>/etc/shorewall/masq</filename> file. If this is a new
connection request, then the rewriting occurs in a
<emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>interface</emphasis>_masq</emphasis>
where <emphasis>interface</emphasis> is the interface on which the
packet will be sent. For packets that are part of an already
established connection, the destination rewriting takes place without
any involvement of a Netfilter rule.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Packets Originating on the Firewall</title>
<para>Just before being sent, packets that originated on the firewall
itself undergo additional processing.</para>
<itemizedlist>
<listitem>
<para>The TOS field in the packet is conditionally altered based on
the contents of your <filename>/etc/shorewall/tos</filename> file.
This occurs in the <emphasis role="bold">outtos</emphasis> chain of
the <emphasis>mangle</emphasis> table.</para>
</listitem>
<listitem>
<para>Packets are marked based on the contents of your
<filename>/etc/shorewall/tcrules</filename> file. This occurs in the
<emphasis role="bold">tcout</emphasis> chain of the
<emphasis>mangle</emphasis> table.</para>
</listitem>
</itemizedlist>
</section>
</article>

4
Shorewall-docs2/Shorewall_and_Aliased_Interfaces.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-06-29</pubdate>
<pubdate>2004-07-10</pubdate>
<copyright>
<year>2001-2004</year>
@ -252,7 +252,7 @@ loc Local Local Zone
<para>In <filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
log eth1 192.168.1.255,192.168.20.255 <emphasis role="bold">routeback</emphasis> </programlisting>
loc eth1 192.168.1.255,192.168.20.255 <emphasis role="bold">routeback</emphasis> </programlisting>
<para>In <filename>/etc/shorewall/rules</filename>, simply specify
ACCEPT rules for the traffic that you want to permit.</para>

4
Shorewall-docs2/template.xml
View File

@ -15,10 +15,10 @@
</author>
</authorgroup>
<pubdate>YYYY-MM-DD</pubdate>
<pubdate>2004-MM-DD</pubdate>
<copyright>
<year>2003</year>
<year>2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>

4
Shorewall-docs2/two-interface.xml
View File

@ -12,7 +12,7 @@
<surname>Eastep</surname>
</author>
<pubdate>2003-06-11</pubdate>
<pubdate>2003-07-10</pubdate>
<copyright>
<year>2002</year>
@ -548,7 +548,7 @@ AllowDNS fw net</programlisting>This rule allows <acronym>DNS</acronym>
<emphasis>defined action</emphasis>. Shorewall includes a number of
defined actions and <ulink url="User_defined_Actions.html">you can add
your own</ulink>. To see the list of actions included with your version of
Shorewall, look in the file <filename>/etc/shorewall/actions.std</filename>.
Shorewall, look in the file <filename>/usr/share/shorewall/actions.std</filename>.
Those actions that accept connection requests have names that begin with
<quote>Allow</quote>.</para>

1092
Shorewall-docs2/two-interface_fr.xml
View File

File diff suppressed because it is too large Load Diff