mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-08 08:44:05 +01:00
Shorewall-2.0.2e
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1379 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
4eb0e261b9
commit
e874f12bda
@ -2496,8 +2496,9 @@ add_an_action()
|
||||
$(fix_bang $proto $sports $multiport $cli -d $srv $dports)
|
||||
fi
|
||||
|
||||
run_iptables2 -A $action $proto $multiport $cli $sports \
|
||||
-d $srv $dports $ratelimit $userandgroup -j $target
|
||||
[ "$logtarget" = LOG ] || \
|
||||
run_iptables2 -A $action $proto $multiport $cli $sports \
|
||||
-d $srv $dports $ratelimit $userandgroup -j $target
|
||||
done
|
||||
done
|
||||
else
|
||||
@ -2506,8 +2507,9 @@ add_an_action()
|
||||
$(fix_bang $proto $sports $multiport $cli $dports)
|
||||
fi
|
||||
|
||||
run_iptables2 -A $action $proto $multiport $cli $sports \
|
||||
$dports $ratelimit $userandgroup -j $target
|
||||
[ "$logtarget" = LOG ] || \
|
||||
run_iptables2 -A $action $proto $multiport $cli $sports \
|
||||
$dports $ratelimit $userandgroup -j $target
|
||||
fi
|
||||
fi
|
||||
}
|
||||
|
||||
@ -1 +1 @@
|
||||
2.0.2d
|
||||
2.0.2e
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-05-27</pubdate>
|
||||
<pubdate>2004-05-29</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -100,6 +100,9 @@
|
||||
<listitem>
|
||||
<para>"shorewall restore" and "shorewall -f start"
|
||||
do not load kernel modules.</para>
|
||||
|
||||
<para><emphasis role="bold">The above two problems are corrected in
|
||||
Shorewall 2.0.2a</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -110,11 +113,17 @@
|
||||
<listitem>
|
||||
<para>If <filename>/var/lib/shorewall</filename> does not exist,
|
||||
<command>shorewall start</command> fails.</para>
|
||||
|
||||
<para><emphasis role="bold">The above four problems are corrected in
|
||||
Shorewall 2.0.2b</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>DNAT rules work incorrectly with dynamic zones in that the
|
||||
source interface is not included in the nat table DNAT rule.</para>
|
||||
|
||||
<para><emphasis role="bold">The above five problems are corrected in
|
||||
Shorewall 2.0.2c</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -123,18 +132,26 @@
|
||||
autoloading is disabled, capabilities can be mis-detected during
|
||||
boot.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <emphasis>newnotsyn</emphasis> option in
|
||||
<filename>/etc/shorewall/hosts</filename> has no effect.</para>
|
||||
|
||||
<para><emphasis role="bold">The above seven problems are corrected
|
||||
in Shorewall 2.0.2d</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Use of the LOG target in an action results in two LOG or ULOG
|
||||
rules.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>These problems are corrected by the <filename>firewall</filename>
|
||||
<para>These problems are all corrected by the <filename>firewall</filename>
|
||||
and <filename>functions</filename> files in <ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.2">this directory</ulink>.
|
||||
Both files must be installed in <filename>/usr/share/shorewall/firewall</filename>
|
||||
Both files must be installed in <filename>/usr/share/shorewall/</filename>
|
||||
as described above.</para>
|
||||
|
||||
<para>The first two problems are also corrected in Shorewall version
|
||||
2.0.2a, the first four problems are corrected in 2.0.2b and the first
|
||||
five problems are corrected in 2.0.2c. All problems are corrected in
|
||||
Shorewall 2.0.2d.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-03-19</pubdate>
|
||||
<pubdate>2004-05-28</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
@ -38,8 +38,8 @@
|
||||
|
||||
<para>Network Mapping is most often used to resolve IP address conflicts.
|
||||
Suppose that two organizations, A and B, need to be linked and that both
|
||||
orginaztions have allocated the 192.168.1.0/24 subnetwork. There is a need
|
||||
to connect the two networks so that all systems in A can access the
|
||||
organizations have allocated the 192.168.1.0/24 subnetwork. There is a
|
||||
need to connect the two networks so that all systems in A can access the
|
||||
192.168.1.0/24 network in B and vice versa without any re-addressing.</para>
|
||||
</section>
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-05-09</pubdate>
|
||||
<pubdate>2004-05-28</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2002</year>
|
||||
@ -47,9 +47,9 @@
|
||||
<para>Beginning with Shorewall 2.0.0, the Shorewall distribution
|
||||
contains a library of user-defined actions that allow for easily
|
||||
allowing or blocking a particular application. Check your
|
||||
<filename>/etc/shorewall/actions.std</filename> file for a list of the
|
||||
actions in your distribution. If you find what you need, you simply use
|
||||
the action in a rule. For example, to allow DNS queries from the
|
||||
<filename>/usr/share/shorewall/actions.std</filename> file for a list of
|
||||
the actions in your distribution. If you find what you need, you simply
|
||||
use the action in a rule. For example, to allow DNS queries from the
|
||||
<emphasis role="bold">dmz</emphasis> zone to the <emphasis role="bold">net</emphasis>
|
||||
zone:</para>
|
||||
|
||||
@ -89,6 +89,26 @@ ACCEPT <emphasis><source></emphasis> <emphasis><destination>
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis><destination></emphasis> udp 53
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis><destination></emphasis> tcp 53</programlisting>
|
||||
|
||||
<para>Note that if you are setting up a DNS server that supports recursive
|
||||
resolution, the server is the <<emphasis>destination</emphasis>>
|
||||
for resolution requests (from clients) and is also the <<emphasis>source</emphasis>>
|
||||
of recursive resolution requests (usually to other servers in the
|
||||
'net' zone). So for example, if you have a public DNS server in
|
||||
your DMZ that supports recursive resolution for local clients then you
|
||||
would need:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT all dmz udp 53
|
||||
ACCEPT all dmz tcp 53
|
||||
ACCEPT dmz net udp 53
|
||||
ACCEPT dmz net tcp 53</programlisting>
|
||||
|
||||
<note>
|
||||
<para>Recursive Resolution means that if the server itself can't
|
||||
resolve the name presented to it, the server will attempt to resolve the
|
||||
name with the help of other servers. </para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -296,7 +316,8 @@ ACCEPT <emphasis><source></emphasis> <emphasis><destination>
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.10</revnumber><date>2004-05-09</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
<para><revhistory><revision><revnumber>1.11</revnumber><date>2004-05-28</date><authorinitials>TE</authorinitials><revremark>Corrected
|
||||
directory for actions.std and enhanced the DNS section.</revremark></revision><revision><revnumber>1.10</revnumber><date>2004-05-09</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
TFTP.</revremark></revision><revision><revnumber>1.9</revnumber><date>2004-04-24</date><authorinitials>TE</authorinitials><revremark>Revised
|
||||
ICQ/AIM.</revremark></revision><revision><revnumber>1.8</revnumber><date>2004-04-23</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
SNMP.</revremark></revision><revision><revnumber>1.7</revnumber><date>2004-02-18</date><authorinitials>TE</authorinitials><revremark>Make
|
||||
|
||||
Loading…
Reference in New Issue
Block a user