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
|
||||
Documentation License</a></span>”.<br>
|
||||
</p>
|
||||
<p>2003-12-30<br>
|
||||
<p>2003-12-31<br>
|
||||
</p>
|
||||
<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>
|
||||
<br>
|
||||
</b>Problems Corrected since version 1.4.7:<br>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user