extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-28 18:43:30 +01:00
Code Issues Packages Projects Releases Wiki Activity

Deimplement original 'netnotsyn' handling

Browse Source 
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
Shorewall-docs2/Documentation.xml
View File

@ -15,7 +15,7 @@
</author> </author>
</authorgroup> </authorgroup>
<pubdate>2005-09-30</pubdate> <pubdate>2005-10-01</pubdate>
<copyright> <copyright>
<year>2001-2005</year> <year>2001-2005</year>
@ -649,18 +649,6 @@ NET_OPTIONS=blacklist,norfc1918</programlisting>
</listitem> </listitem>
</varlistentry> </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> <varlistentry>
<term>routeback</term> <term>routeback</term>
@ -3152,57 +3140,6 @@ eth0 eth1 206.124.146.176</programlisting>
</listitem> </listitem>
</varlistentry> </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> <varlistentry>
<term>LOG_MARTIANS</term> <term>LOG_MARTIANS</term>

21
Shorewall-docs2/FAQ.xml
View File

@ -17,7 +17,7 @@
</author> </author>
</authorgroup> </authorgroup>
<pubdate>2005-09-30</pubdate> <pubdate>2005-10-01</pubdate>
<copyright> <copyright>
<year>2001-2005</year> <year>2001-2005</year>
@ -997,21 +997,6 @@ LOGBURST=""</programlisting>
</listitem> </listitem>
</varlistentry> </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> <varlistentry>
<term>INPUT or FORWARD</term> <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 behind the firewall, I get <quote>operation not permitted</quote>. How
can I use nmap with Shorewall?"</title> can I use nmap with Shorewall?"</title>
<para>Edit /etc/shorewall/shorewall.conf and change <para>Temporarily remove and rejNotSyn, dropNotSyn and dropInvalid rules
<quote>NEWNOTSYN=No</quote> to <quote>NEWNOTSYN=Yes</quote> then restart from <filename>/etc/shorewall/rules</filename> and restart
Shorewall.</para> Shorewall.</para>
</section> </section>

7
Shorewall-docs2/Multiple_Zones.xml
View File

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

135
Shorewall-docs2/PacketHandling.xml
View File

@ -15,11 +15,13 @@
</author> </author>
</authorgroup> </authorgroup>
<pubdate>2004-07-13</pubdate> <pubdate>2005-10-01</pubdate>
<copyright> <copyright>
<year>2004</year> <year>2004</year>
<year>2005</year>
<holder>Thomas M. Eastep</holder> <holder>Thomas M. Eastep</holder>
</copyright> </copyright>
@ -29,7 +31,8 @@
1.2 or any later version published by the Free Software Foundation; with 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 no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled 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> </legalnotice>
</articleinfo> </articleinfo>
@ -38,23 +41,25 @@
<para>This article will try to help you understand how packets pass <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 through a firewall configured by Shorewall. You may find it useful to have
a copy of the <ulink url="NetfilterOverview.html">Netfilter Overview</ulink> a copy of the <ulink url="NetfilterOverview.html">Netfilter
handy to refer to.</para> Overview</ulink> handy to refer to.</para>
<para>The discussion that follows assumes that you are running a current <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 kernel (2.4.2n or 2.6.m) with the <ulink url="kernel.htm">recommended
options </ulink>included. Otherwise processing may be somewhat different 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 <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>
<section> <section>
<title>Packets Entering the Firewall from Outside</title> <title>Packets Entering the Firewall from Outside</title>
<para>Certain processing occurs on packets entering the firewall from the <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> itself.</para>
<itemizedlist> <itemizedlist>
@ -68,16 +73,18 @@
<listitem> <listitem>
<para>Packets are marked based on the contents of your <para>Packets are marked based on the contents of your
<filename>/etc/shorewall/tcrules</filename> file and the setting of <filename>/etc/shorewall/tcrules</filename> file and the setting of
MARK_IN_FORWARD_CHAIN in <filename>/etc/shorewall/shorewall.conf</filename>. MARK_IN_FORWARD_CHAIN in
This occurs in the <emphasis role="bold">tcpre</emphasis> chain of the <filename>/etc/shorewall/shorewall.conf</filename>. This occurs in the
<emphasis role="bold">tcpre</emphasis> chain of the
<emphasis>mangle</emphasis> table.</para> <emphasis>mangle</emphasis> table.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>The destination IP address and/or port number are rewritten <para>The destination IP address and/or port number are rewritten
according to DNAT[-] and REDIRECT[-] rules in <filename>/etc/shorewall/rules</filename>. according to DNAT[-] and REDIRECT[-] rules in
For new connection requests, this occurs in a chain in the <filename>/etc/shorewall/rules</filename>. For new connection
<emphasis>nat</emphasis> table called <emphasis role="bold"><emphasis>zone</emphasis>_dnat</emphasis> 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 where <emphasis>zone</emphasis> is the zone where the request
originated. For packets that are part of an already established originated. For packets that are part of an already established
connection, the destination rewriting takes place without any connection, the destination rewriting takes place without any
@ -88,9 +95,10 @@
<para>If the destination was not rewritten in the previous step then <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 it may be rewritten based on entries in /etc/shorewall/nat. For new
connection requests, this occurs in a <emphasis>nat</emphasis> table connection requests, this occurs in a <emphasis>nat</emphasis> table
chain called <emphasis role="bold"><emphasis>interface</emphasis>_in</emphasis> chain called <emphasis
where <emphasis>interface</emphasis> is the interface on which the role="bold"><emphasis>interface</emphasis>_in</emphasis> where
packet entered the firewall. For packets that are part of an already <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 established connection, the destination rewriting takes place without
any involvement of a Netfilter rule.</para> any involvement of a Netfilter rule.</para>
</listitem> </listitem>
@ -101,9 +109,9 @@
</listitem> </listitem>
<listitem> <listitem>
<para>If Netfilter doesn&#39;t know what to do with the packet <para>If Netfilter doesn't know what to do with the packet (connection
(connection state INVALID) and the protocol is not ICMP then the state INVALID) and the protocol is not ICMP then the packet is
packet is silently dropped.</para> silently dropped.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -120,8 +128,8 @@
the <emphasis>nosmurfs</emphasis> option specified in the <emphasis>nosmurfs</emphasis> option specified in
<filename>/etc/shorewall/interfaces</filename>, then if the packet is <filename>/etc/shorewall/interfaces</filename>, then if the packet is
a new connection request is checked for being a smurf in the a new connection request is checked for being a smurf in the
<emphasis>filter</emphasis> table&#39;s <emphasis role="bold">smurfs</emphasis> <emphasis>filter</emphasis> table's <emphasis
chain.</para> role="bold">smurfs</emphasis> chain.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -134,42 +142,47 @@
<listitem> <listitem>
<para>the interface on which the packet arrived has the <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>
<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> </listitem>
</itemizedlist> </itemizedlist>
<para>then the packet is ACCEPTed in the <emphasis>filter</emphasis> <para>then the packet is ACCEPTed in the <emphasis>filter</emphasis>
table&#39;s <emphasis role="bold"><emphasis>interface</emphasis>_in</emphasis> table's <emphasis
chain (for example, eth0_in).</para> role="bold"><emphasis>interface</emphasis>_in</emphasis> chain (for
example, eth0_in).</para>
</listitem> </listitem>
<listitem> <listitem>
<para>If the interface on which the packet entered the firewall has <para>If the interface on which the packet entered the firewall has
the <emphasis>norfc1918</emphasis> option specified in the <emphasis>norfc1918</emphasis> option specified in
<filename>/etc/shorewall/interfaces</filename>, then the packet is <filename>/etc/shorewall/interfaces</filename>, then the packet is
processed against your rfc1918 file (normally <filename>/usr/share/shorewall/rfc1918</filename> processed against your rfc1918 file (normally
but that file may be copied to <filename>/etc/shorewall/rfc1918</filename> <filename>/usr/share/shorewall/rfc1918</filename> but that file may be
and modified). This happens in the <emphasis>filter</emphasis> copied to <filename>/etc/shorewall/rfc1918</filename> and modified).
table&#39;s <emphasis role="bold">norfc1918</emphasis> chain.</para> This happens in the <emphasis>filter</emphasis> table's <emphasis
role="bold">norfc1918</emphasis> chain.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>If the interface on which the packet entered the firewall has <para>If the interface on which the packet entered the firewall has
the <emphasis>nobogons</emphasis> option specified in the <emphasis>nobogons</emphasis> option specified in
<filename>/etc/shorewall/interfaces</filename>, then the packet is <filename>/etc/shorewall/interfaces</filename>, then the packet is
processed against your bogons file (normally <filename>/usr/share/shorewall/bogons</filename> processed against your bogons file (normally
but that file may be copied to <filename>/etc/shorewall/bogons</filename> <filename>/usr/share/shorewall/bogons</filename> but that file may be
and modified).</para> copied to <filename>/etc/shorewall/bogons</filename> and
modified).</para>
</listitem> </listitem>
<listitem> <listitem>
<para>If the interface on which the packet entered the firewall has <para>If the interface on which the packet entered the firewall has
the <emphasis>tcpflags</emphasis> option specified in 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 protocol is TCP then the TCP flags are checked by the <emphasis
role="bold">tcpflags</emphasis> chain (<emphasis>filter</emphasis> role="bold">tcpflags</emphasis> chain (<emphasis>filter</emphasis>
table).</para> table).</para>
@ -187,8 +200,9 @@
<listitem> <listitem>
<para>Packets are marked based on the contents of your <para>Packets are marked based on the contents of your
<filename>/etc/shorewall/tcrules</filename> file and the setting of <filename>/etc/shorewall/tcrules</filename> file and the setting of
MARK_IN_FORWARD_CHAIN in <filename>/etc/shorewall/shorewall.conf</filename>. MARK_IN_FORWARD_CHAIN in
This occurs in the <emphasis role="bold">tcfor</emphasis> chain of the <filename>/etc/shorewall/shorewall.conf</filename>. This occurs in the
<emphasis role="bold">tcfor</emphasis> chain of the
<emphasis>mangle</emphasis> table.</para> <emphasis>mangle</emphasis> table.</para>
<para>The remaining processing in this list occurs in the <para>The remaining processing in this list occurs in the
@ -197,7 +211,7 @@
<listitem> <listitem>
<para>If either the host sending the packet or the host to which the <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 policy is applied to the packet (including logging). This can occur in
the INPUT, FORWARD or OUTPUT chains.</para> the INPUT, FORWARD or OUTPUT chains.</para>
</listitem> </listitem>
@ -205,20 +219,17 @@
<listitem> <listitem>
<para>If the packet is part of an established connection or is part of <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 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 chain where <emphasis>zone1</emphasis> is the source zone and
<emphasis>zone2</emphasis> is the destination zone).</para> <emphasis>zone2</emphasis> is the destination zone).</para>
</listitem> </listitem>
<listitem> <listitem>
<para>If NEWNOTSYN=Yes in /etc/shorewall/shorewall.conf then If the <para>The packet is processed according to your
packet&#39;s protocol is TCP and is not a syn packet then the packet <filename>/etc/shorewall/rules</filename> file. This happens in chains
is processed by the <emphasis role="bold">newnotsyn</emphasis> chain.</para> named <emphasis><emphasis
</listitem> role="bold"><emphasis>zone1</emphasis>2<emphasis>zone2</emphasis></emphasis></emphasis>
<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>
chain where <emphasis>zone1</emphasis> is the source zone and chain where <emphasis>zone1</emphasis> is the source zone and
<emphasis>zone2</emphasis> is the destination zone. Note that in the <emphasis>zone2</emphasis> is the destination zone. Note that in the
presence of <ulink url="Documentation.htm#Nested">nested or 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 <para>Note: If the packet gets to this step, it did not match any
rule.</para> rule.</para>
<para>If the applicable policy has a <ulink <para>If the applicable policy has a <ulink url="Actions.html">common
url="Actions.html">common action</ulink> then that action action</ulink> then that action is applied (chain has the same name as
is applied (chain has the same name as the action).</para> the action).</para>
</listitem> </listitem>
<listitem> <listitem>
@ -273,7 +284,8 @@
<section> <section>
<title>Packets Leaving the Firewall</title> <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> <note>
<para>The source IP address only gets rewritten by the first matching <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 role="bold"><emphasis>zone</emphasis>_snat</emphasis> where
<emphasis>zone</emphasis> is the destination zone. For packets that <emphasis>zone</emphasis> is the destination zone. For packets that
are part of an already established connection, the destination 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>
<listitem> <listitem>
<para>The source IP address may be rewritten according to an entry in <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 the <filename>/etc/shorewall/nat</filename> file. If this is a new
connection request, then the rewriting occurs in a connection request, then the rewriting occurs in a
<emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>interface</emphasis>_snat</emphasis> <emphasis>nat</emphasis> table chain called <emphasis
where <emphasis>interface</emphasis> is the interface on which the role="bold"><emphasis>interface</emphasis>_snat</emphasis> where
packet will be sent. For packets that are part of an already <emphasis>interface</emphasis> is the interface on which the packet
established connection, the destination rewriting takes place without will be sent. For packets that are part of an already established
any involvement of a Netfilter rule.</para> connection, the destination rewriting takes place without any
involvement of a Netfilter rule.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>The source IP address may be rewritten according to an entry in <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 the <filename>/etc/shorewall/masq</filename> file. If this is a new
connection request, then the rewriting occurs in a connection request, then the rewriting occurs in a
<emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>interface</emphasis>_masq</emphasis> <emphasis>nat</emphasis> table chain called <emphasis
where <emphasis>interface</emphasis> is the interface on which the role="bold"><emphasis>interface</emphasis>_masq</emphasis> where
packet will be sent. For packets that are part of an already <emphasis>interface</emphasis> is the interface on which the packet
established connection, the destination rewriting takes place without will be sent. For packets that are part of an already established
any involvement of a Netfilter rule.</para> connection, the destination rewriting takes place without any
involvement of a Netfilter rule.</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</section> </section>
</article> </article>

4
Shorewall-docs2/myfiles.xml
View File

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

3
Shorewall-docs2/shorewall_logging.xml
View File

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