forked from extern/shorewall_code
Update News.htm
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1049 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
5b48fd2d57
commit
98660c3439
@ -18,9 +18,210 @@ Texts. A copy of the license is included in the section entitled “<span
|
|||||||
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
||||||
Documentation License</a></span>”.<br>
|
Documentation License</a></span>”.<br>
|
||||||
</p>
|
</p>
|
||||||
<p>2003-12-30<br>
|
<p>2003-12-31<br>
|
||||||
</p>
|
</p>
|
||||||
<hr style="width: 100%; height: 2px;">
|
<hr style="width: 100%; height: 2px;">
|
||||||
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b><b> </b></p>
|
||||||
|
<div style="margin-left: 40px;"><a
|
||||||
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||||||
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
||||||
|
</div>
|
||||||
|
<p>Problems Corrected since version 1.4.8:</p>
|
||||||
|
<ol>
|
||||||
|
<li>There has been a low continuing level of confusion over the
|
||||||
|
terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion,
|
||||||
|
all instances of "Static NAT" have been replaced with "One-to-one NAT"
|
||||||
|
in the documentation and configuration files.</li>
|
||||||
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
||||||
|
reworded for clarity.</li>
|
||||||
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
||||||
|
will no longer produce an error if they attempt to add a rule that
|
||||||
|
would override a NONE policy. The logic for expanding these wild-card
|
||||||
|
rules now simply skips those (SOURCE,DEST) pairs that have a NONE
|
||||||
|
policy.</li>
|
||||||
|
<li>DNAT rules that also specified SNAT now work reliably.
|
||||||
|
Previously, there were cases where the SNAT specification was
|
||||||
|
effectively ignored.<br>
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
<p>Migration Issues:</p>
|
||||||
|
<p> None.<br>
|
||||||
|
<br>
|
||||||
|
New Features: </p>
|
||||||
|
<ol>
|
||||||
|
<li>The documentation has been completely rebased to Docbook
|
||||||
|
XML. The documentation is now released as separate HTML and XML
|
||||||
|
packages.<br>
|
||||||
|
</li>
|
||||||
|
<li>To cut down on the number of "Why are these ports closed
|
||||||
|
rather than stealthed?" questions, the SMB-related rules in
|
||||||
|
/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.</li>
|
||||||
|
<li>For easier identification, packets logged under the
|
||||||
|
'norfc1918' interface option are now logged out of chains named
|
||||||
|
'rfc1918'. Previously, such packets were logged under chains named
|
||||||
|
'logdrop'.</li>
|
||||||
|
<li>Distributors and developers seem to be regularly inventing
|
||||||
|
new naming conventions for kernel modules. To avoid the need to change
|
||||||
|
Shorewall code for each new convention, the MODULE_SUFFIX option has
|
||||||
|
been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix
|
||||||
|
for module names in your particular distribution. If MODULE_SUFFIX is
|
||||||
|
not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
||||||
|
<br>
|
||||||
|
To see what suffix is used by your distribution:<br>
|
||||||
|
<br>
|
||||||
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
||||||
|
<br>
|
||||||
|
All of the files listed should have the same suffix (extension). Set
|
||||||
|
MODULE_SUFFIX to that suffix.<br>
|
||||||
|
<br>
|
||||||
|
Examples:<br>
|
||||||
|
<br>
|
||||||
|
If all files end in ".kzo" then set
|
||||||
|
MODULE_SUFFIX="kzo"<br>
|
||||||
|
If all files end in ".kz.o" then set
|
||||||
|
MODULE_SUFFIX="kz.o"</li>
|
||||||
|
<li>Support for user defined rule ACTIONS has been implemented
|
||||||
|
through two new files:<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
||||||
|
/etc/shorewall/action.template - For each user defined <action>,
|
||||||
|
copy this file to /etc/shorewall/action.<action> and add the
|
||||||
|
appropriate rules for that <action>. Once an <action> has
|
||||||
|
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
||||||
|
DROP, etc.) in /etc/shorewall/rules.<br>
|
||||||
|
<br>
|
||||||
|
Example: You want an action that logs a packet at the 'info' level and
|
||||||
|
accepts the connection.<br>
|
||||||
|
<br>
|
||||||
|
In /etc/shorewall/actions, you would add:<br>
|
||||||
|
<br>
|
||||||
|
LogAndAccept<br>
|
||||||
|
<br>
|
||||||
|
You would then copy /etc/shorewall/action.template to
|
||||||
|
/etc/shorewall/LogAndAccept and in that file, you would add the two
|
||||||
|
rules:<br>
|
||||||
|
LOG:info<br>
|
||||||
|
ACCEPT<br>
|
||||||
|
</li>
|
||||||
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
||||||
|
"Yes" (non-syn TCP packets that are not part of an existing connection
|
||||||
|
are filtered according to the rules and policies rather than being
|
||||||
|
dropped). I have made this change for two reasons:<br>
|
||||||
|
<br>
|
||||||
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
||||||
|
any timeout during TCP session tear down results in the firewall
|
||||||
|
dropping all of the retries.<br>
|
||||||
|
<br>
|
||||||
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
||||||
|
lots of confusing messages when a connection got "stuck". While I could
|
||||||
|
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
||||||
|
dislike defaults that silently throw away packets.<br>
|
||||||
|
<br>
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
<p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back
|
||||||
|
On-line</b><b> <br>
|
||||||
|
</b></p>
|
||||||
|
<p>Our high-capacity server has been restored to service --
|
||||||
|
please let <a href="mailto:webmaster@shorewall.net">us</a> know if you
|
||||||
|
find any problems.</p>
|
||||||
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 1</b><b> </b></p>
|
||||||
|
<div style="margin-left: 40px;"><a
|
||||||
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||||||
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
||||||
|
</div>
|
||||||
|
<p>Problems Corrected since version 1.4.8:</p>
|
||||||
|
<ol>
|
||||||
|
<li>There has been a low continuing level of confusion over the
|
||||||
|
terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion,
|
||||||
|
all instances of "Static NAT" have been replaced with "One-to-one NAT"
|
||||||
|
in the documentation and configuration files.</li>
|
||||||
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
||||||
|
reworded for clarity.</li>
|
||||||
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
||||||
|
will no longer produce an error if they attempt to add a rule that
|
||||||
|
would override a NONE policy. The logic for expanding these wild-card
|
||||||
|
rules now simply skips those (SOURCE,DEST) pairs that have a NONE
|
||||||
|
policy.</li>
|
||||||
|
</ol>
|
||||||
|
<p>Migration Issues:</p>
|
||||||
|
<p> None.<br>
|
||||||
|
<br>
|
||||||
|
New Features: </p>
|
||||||
|
<ol>
|
||||||
|
<li>To cut down on the number of "Why are these ports closed
|
||||||
|
rather than stealthed?" questions, the SMB-related rules in
|
||||||
|
/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.</li>
|
||||||
|
<li>For easier identification, packets logged under the
|
||||||
|
'norfc1918' interface option are now logged out of chains named
|
||||||
|
'rfc1918'. Previously, such packets were logged under chains named
|
||||||
|
'logdrop'.</li>
|
||||||
|
<li>Distributors and developers seem to be regularly inventing
|
||||||
|
new naming conventions for kernel modules. To avoid the need to change
|
||||||
|
Shorewall code for each new convention, the MODULE_SUFFIX option has
|
||||||
|
been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix
|
||||||
|
for module names in your particular distribution. If MODULE_SUFFIX is
|
||||||
|
not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
||||||
|
<br>
|
||||||
|
To see what suffix is used by your distribution:<br>
|
||||||
|
<br>
|
||||||
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
||||||
|
<br>
|
||||||
|
All of the files listed should have the same suffix (extension). Set
|
||||||
|
MODULE_SUFFIX to that suffix.<br>
|
||||||
|
<br>
|
||||||
|
Examples:<br>
|
||||||
|
<br>
|
||||||
|
If all files end in ".kzo" then set
|
||||||
|
MODULE_SUFFIX="kzo"<br>
|
||||||
|
If all files end in ".kz.o" then set
|
||||||
|
MODULE_SUFFIX="kz.o"</li>
|
||||||
|
<li>Support for user defined rule ACTIONS has been implemented
|
||||||
|
through two new files:<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
||||||
|
/etc/shorewall/action.template - For each user defined <action>,
|
||||||
|
copy this file to /etc/shorewall/action.<action> and add the
|
||||||
|
appropriate rules for that <action>. Once an <action> has
|
||||||
|
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
||||||
|
DROP, etc.) in /etc/shorewall/rules.<br>
|
||||||
|
<br>
|
||||||
|
Example: You want an action that logs a packet at the 'info' level and
|
||||||
|
accepts the connection.<br>
|
||||||
|
<br>
|
||||||
|
In /etc/shorewall/actions, you would add:<br>
|
||||||
|
<br>
|
||||||
|
LogAndAccept<br>
|
||||||
|
<br>
|
||||||
|
You would then copy /etc/shorewall/action.template to
|
||||||
|
/etc/shorewall/LogAndAccept and in that file, you would add the two
|
||||||
|
rules:<br>
|
||||||
|
LOG:info<br>
|
||||||
|
ACCEPT<br>
|
||||||
|
</li>
|
||||||
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
||||||
|
"Yes" (non-syn TCP packets that are not part of an existing connection
|
||||||
|
are filtered according to the rules and policies rather than being
|
||||||
|
dropped). I have made this change for two reasons:<br>
|
||||||
|
<br>
|
||||||
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
||||||
|
any timeout during TCP session tear down results in the firewall
|
||||||
|
dropping all of the retries.<br>
|
||||||
|
<br>
|
||||||
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
||||||
|
lots of confusing messages when a connection got "stuck". While I could
|
||||||
|
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
||||||
|
dislike defaults that silently throw away packets.</li>
|
||||||
|
</ol>
|
||||||
|
<p><b>12/03/2003 - Support Torch Passed</b></p>
|
||||||
|
Effective today, I am reducing my participation in the day-to-day
|
||||||
|
support of Shorewall. As part of this shift to community-based
|
||||||
|
Shorewall support a new <a
|
||||||
|
href="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">Shorewall
|
||||||
|
Newbies mailing list</a> has been established to field questions and
|
||||||
|
problems from new users. I will not monitor that list personally. I
|
||||||
|
will continue my active development of Shorewall and will be available
|
||||||
|
via the development list to handle development issues -- Tom.
|
||||||
<p><b>11/07/2003 - Shorewall 1.4.8<br>
|
<p><b>11/07/2003 - Shorewall 1.4.8<br>
|
||||||
<br>
|
<br>
|
||||||
</b>Problems Corrected since version 1.4.7:<br>
|
</b>Problems Corrected since version 1.4.7:<br>
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user