diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index 0fc6c594d..7f0ff1866 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -18,9 +18,210 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

-

2003-12-30
+

2003-12-31

+

12/29/2003 - Shorewall 1.4.9 Beta 2

+
http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta +
+

Problems Corrected since version 1.4.8:

+
    +
  1. 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.
    2. +
  2. The description of NEWNOTSYN in shorewall.conf has been +reworded for clarity.
    3. +
  3. 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.
    4. +
  4. DNAT rules that also specified SNAT now work reliably. +Previously, there were cases where the SNAT specification was +effectively ignored.
    +
    5. +
+

Migration Issues:

+

    None.
+
+New Features:

+
    +
  1. The documentation has been completely rebased to Docbook +XML. The documentation is now released as separate HTML and XML +packages.
    +
    2. +
  2. 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'.
    3. +
  3. 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'.
    4. +
  4. 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".
    +
    +To see what suffix is used by your distribution:
    +
    +ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
    +
    +All of the files listed should have the same suffix (extension). Set +MODULE_SUFFIX to that suffix.
    +
    +Examples:
    +
    +     If all files end in ".kzo" then set +MODULE_SUFFIX="kzo"
    +     If all files end in ".kz.o" then set +MODULE_SUFFIX="kz.o"
    5. +
  5. Support for user defined rule ACTIONS has been implemented +through two new files:
    +
    +/etc/shorewall/actions - used to list the user-defined ACTIONS.
    +/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.
    +
    +Example: You want an action that logs a packet at the 'info' level and +accepts the connection.
    +
    +In /etc/shorewall/actions, you would add:
    +
    +     LogAndAccept
    +
    +You would then copy /etc/shorewall/action.template to +/etc/shorewall/LogAndAccept and in that file, you would add the two +rules:
    +        LOG:info
    +        ACCEPT
    +
    6. +
  6. 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:
    +
    +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.
    +
    +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.
    +
    +
    7. +
+

12/28/2003 - www.shorewall.net/ftp.shorewall.net Back +On-line
+

+

Our high-capacity server has been restored to service -- +please let us know if you +find any problems.

+

12/29/2003 - Shorewall 1.4.9 Beta 1

+
http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta +
+

Problems Corrected since version 1.4.8:

+
    +
  1. 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.
    2. +
  2. The description of NEWNOTSYN in shorewall.conf has been +reworded for clarity.
    3. +
  3. 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.
    4. +
+

Migration Issues:

+

    None.
+
+New Features:

+
    +
  1. 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'.
    2. +
  2. 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'.
    3. +
  3. 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".
    +
    +To see what suffix is used by your distribution:
    +
    +ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
    +
    +All of the files listed should have the same suffix (extension). Set +MODULE_SUFFIX to that suffix.
    +
    +Examples:
    +
    +     If all files end in ".kzo" then set +MODULE_SUFFIX="kzo"
    +     If all files end in ".kz.o" then set +MODULE_SUFFIX="kz.o"
    4. +
  4. Support for user defined rule ACTIONS has been implemented +through two new files:
    +
    +/etc/shorewall/actions - used to list the user-defined ACTIONS.
    +/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.
    +
    +Example: You want an action that logs a packet at the 'info' level and +accepts the connection.
    +
    +In /etc/shorewall/actions, you would add:
    +
    +     LogAndAccept
    +
    +You would then copy /etc/shorewall/action.template to +/etc/shorewall/LogAndAccept and in that file, you would add the two +rules:
    +        LOG:info
    +        ACCEPT
    +
    5. +
  5. 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:
    +
    +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.
    +
    +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.
    6. +
+

12/03/2003 - Support Torch Passed

+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 Shorewall +Newbies mailing list 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.

11/07/2003 - Shorewall 1.4.8

Problems Corrected since version 1.4.7: