mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-25 09:03:30 +01:00
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
parent
2b6a9bb843
commit
5371bba9e3
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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'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'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'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'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'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'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'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->all
|
||||
packet is addressed is not in any defined zone then the all->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'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,29 +300,32 @@
|
||||
<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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user