Deimplement original 'netnotsyn' handling

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2767 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-10-01 16:17:30 +00:00
parent 2b6a9bb843
commit 5371bba9e3
6 changed files with 84 additions and 151 deletions

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-09-30</pubdate>
<pubdate>2005-10-01</pubdate>
<copyright>
<year>2001-2005</year>
@ -649,18 +649,6 @@ NET_OPTIONS=blacklist,norfc1918</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>newnotsyn</term>
<listitem>
<para>This option overrides <link
linkend="Conf">NEWNOTSYN=No</link> 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 <xref linkend="Conf" />.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>routeback</term>
@ -3152,57 +3140,6 @@ eth0 eth1 206.124.146.176</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>NEWNOTSYN</term>
<listitem>
<para>When set to <quote>Yes</quote> or <quote>yes</quote>,
Shorewall will filter TCP packets that are not part of an
established connection and that are not SYN packets (SYN flag on -
ACK flag off). If set to <quote>No</quote>, Shorewall will silently
drop such packets. If not set or set to the empty value (e.g.,
<quote>NEWNOTSYN=</quote>), NEWNOTSYN=No is assumed.</para>
<para>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.</para>
<note>
<para>I find that NEWNOTSYN=No tends to result in lots of "stuck"
connections because any network timeout during TCP session tear
down results in retries being dropped (Netfilter has removed the
connection from the conntrack table but the end-points haven't
completed shutting down the connection). I therefore have chosen
NEWNOTSYN=Yes as the default value and I advise caution in using
NEWNOTSYN=Yes.</para>
<para>If you are looking for a way to defeat "stealth TCP scans"
then I recommend the <emphasis role="bold">tcpflags</emphasis>
interface option in <link
linkend="Interfaces">/etc/shorewall/interfaces</link> rather than
NEWNOTSYN=No.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>LOGNEWNOTSYN</term>
<listitem>
<para>Shorewall can be configured to drop non-SYN TCP packets that
are not part of an existing connection (see NEWNOTSYN above). If you
would like to log these packets, set LOGNEWNOTSYN to the <ulink
url="shorewall_logging.html">syslog level</ulink> at which you want
the packets logged. Example: LOGNEWNOTSYN=ULOG|</para>
<note>
<para>Packets logged under this option are usually the result of a
"stuck" connection rather than as the result of an attempt to
breach your firewall.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>LOG_MARTIANS</term>

View File

@ -17,7 +17,7 @@
</author>
</authorgroup>
<pubdate>2005-09-30</pubdate>
<pubdate>2005-10-01</pubdate>
<copyright>
<year>2001-2005</year>
@ -997,21 +997,6 @@ LOGBURST=""</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>newnotsyn</term>
<listitem>
<para>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 <emphasis
role="bold">NEWNOTSYN</emphasis> and <emphasis
role="bold">LOGNEWNOTSYN</emphasis> in <ulink
url="Documentation.htm#Conf">
<filename>/etc/shorewall/shorewall.conf</filename>
</ulink>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>INPUT or FORWARD</term>
@ -1768,8 +1753,8 @@ eth0 eth1 # eth1 = interface to local netwo
behind the firewall, I get <quote>operation not permitted</quote>. How
can I use nmap with Shorewall?"</title>
<para>Edit /etc/shorewall/shorewall.conf and change
<quote>NEWNOTSYN=No</quote> to <quote>NEWNOTSYN=Yes</quote> then restart
<para>Temporarily remove and rejNotSyn, dropNotSyn and dropInvalid rules
from <filename>/etc/shorewall/rules</filename> and restart
Shorewall.</para>
</section>

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-09-30</pubdate>
<pubdate>2005-10-01</pubdate>
<copyright>
<year>2003-2005</year>
@ -157,9 +157,8 @@
</listitem>
<listitem>
<para>Set the <quote>routeback</quote> and <quote>newnotsyn</quote>
options for eth1 (the local firewall interface) in
/etc/shorewall/interfaces.</para>
<para>Set the <quote>routeback</quote> option for eth1 (the local
firewall interface) in /etc/shorewall/interfaces.</para>
</listitem>
<listitem>

View File

@ -15,11 +15,13 @@
</author>
</authorgroup>
<pubdate>2004-07-13</pubdate>
<pubdate>2005-10-01</pubdate>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -29,7 +31,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>
@ -38,23 +41,25 @@
<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>
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>
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>
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
outside that don't occur for packets that originate on the firewall
itself.</para>
<itemizedlist>
@ -68,16 +73,18 @@
<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
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>
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
@ -88,9 +95,10 @@
<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
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>
@ -101,9 +109,9 @@
</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>
<para>If Netfilter doesn'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>
@ -120,8 +128,8 @@
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>
<emphasis>filter</emphasis> table's <emphasis
role="bold">smurfs</emphasis> chain.</para>
</listitem>
<listitem>
@ -134,42 +142,47 @@
<listitem>
<para>the interface on which the packet arrived has the
<emphasis>dhcp</emphasis> option in <filename>/etc/shorewall/interfaces</filename>.</para>
<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>
<para>packet's protocol is UDP with destination port 67 or
68.</para>
</listitem>
</itemizedlist>
<para>then the packet is ACCEPTed in the <emphasis>filter</emphasis>
table&#39;s <emphasis role="bold"><emphasis>interface</emphasis>_in</emphasis>
chain (for example, eth0_in).</para>
table'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 <emphasis>filter</emphasis>
table&#39;s <emphasis role="bold">norfc1918</emphasis> chain.</para>
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 <emphasis>filter</emphasis> table's <emphasis
role="bold">norfc1918</emphasis> 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>
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
<filename>/etc/shorewall/interfaces</filename> and the packet's
protocol is TCP then the TCP flags are checked by the <emphasis
role="bold">tcpflags</emphasis> chain (<emphasis>filter</emphasis>
table).</para>
@ -187,8 +200,9 @@
<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
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
@ -197,7 +211,7 @@
<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
packet is addressed is not in any defined zone then the all-&gt;all
policy is applied to the packet (including logging). This can occur in
the INPUT, FORWARD or OUTPUT chains.</para>
</listitem>
@ -205,20 +219,17 @@
<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><emphasis>zone1</emphasis>2<emphasis>zone2</emphasis></emphasis>
filter table
(<emphasis><emphasis>zone1</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><emphasis role="bold"><emphasis>zone1</emphasis>2<emphasis>zone2</emphasis></emphasis></emphasis>
<para>The packet is processed according to your
<filename>/etc/shorewall/rules</filename> file. This happens in chains
named <emphasis><emphasis
role="bold"><emphasis>zone1</emphasis>2<emphasis>zone2</emphasis></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
@ -230,9 +241,9 @@
<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="Actions.html">common action</ulink> then that action
is applied (chain has the same name as the action).</para>
<para>If the applicable policy has a <ulink url="Actions.html">common
action</ulink> then that action is applied (chain has the same name as
the action).</para>
</listitem>
<listitem>
@ -273,7 +284,8 @@
<section>
<title>Packets Leaving the Firewall</title>
<para>Packets being sent to another host undergo additional processing.</para>
<para>Packets being sent to another host undergo additional
processing.</para>
<note>
<para>The source IP address only gets rewritten by the first matching
@ -288,30 +300,33 @@
<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>
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>
<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>
<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>
</article>
</article>

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-09-29</pubdate>
<pubdate>2005-10-01</pubdate>
<copyright>
<year>2001-2005</year>
@ -173,7 +173,6 @@ LOGRATE=
LOGBURST=
LOGALLNEW=
BLACKLIST_LOGLEVEL=
LOGNEWNOTSYN=$LOG
MACLIST_LOG_LEVEL=$LOG
TCP_FLAGS_LOG_LEVEL=$LOG
RFC1918_LOG_LEVEL=$LOG
@ -201,7 +200,6 @@ CLAMPMSS=Yes
ROUTE_FILTER=No
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
NEWNOTSYN=Yes
ADMINISABSENTMINDED=Yes
BLACKLISTNEWONLY=Yes
DELAYBLACKLISTLOAD=No

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-09-12</pubdate>
<pubdate>2005-10-01</pubdate>
<copyright>
<year>2001 - 2005</year>
@ -234,7 +234,6 @@ rules:ACCEPT:$LOG dmz net
rules:REJECT:$LOG $FW net udp 1025:1031
shorewall.conf:LOGFILE=/var/log/shorewall
shorewall.conf:LOGUNCLEAN=$LOG
shorewall.conf:LOGNEWNOTSYN=$LOG
shorewall.conf:MACLIST_LOG_LEVEL=$LOG
shorewall.conf:TCP_FLAGS_LOG_LEVEL=$LOG
shorewall.conf:RFC1918_LOG_LEVEL=$LOG