From 61e6aa2cbf6a3fe17578f6d623a98feb8c2f51a7 Mon Sep 17 00:00:00 2001 From: teastep Date: Wed, 26 Sep 2007 14:07:40 +0000 Subject: [PATCH] Back out 4.0.4 updates so judas_iscariote's cron job won't publish them prematurely git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@7391 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- web/News.htm | 380 +--------------------------------------- web/shorewall_index.htm | 108 ++++-------- 2 files changed, 46 insertions(+), 442 deletions(-) diff --git a/web/News.htm b/web/News.htm index b70e17abe..ccbd2fc05 100644 --- a/web/News.htm +++ b/web/News.htm @@ -1,13 +1,9 @@ - - - - - Shorewall News - + - + + + Shorewall News

Shorewall News and Announcements

Tom Eastep
@@ -19,369 +15,13 @@ under the terms of the GNU Free Documentation License, Version 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 “GNU Free Documentation +license is included in the section entitled “GNU Free Documentation License”.

August 10, 2007

-

2007-09-28 Shorewall 4.0.4

-
Problems Corrected in Shorewall 4.0.4
-
-1)  If no interface had the 'blacklist' option, then when using
-    Shorewall-perl, the 'start' and 'restart' command failed:
-
-        ERROR: No filter chain found with name blacklst
-
-    New Shorewall-perl 4.0.3 packages were released that corrected this
-    problem; it is included here for completeness.
-
-2)  If no interface had the 'blacklist' option, then when using
-    Shorewall-perl, the generated script would issue this harmless
-    message during 'shorewall refresh':
-
-        chainlist_reload: Not found
-
-3)  If /bin/sh was a light-weight shell such as ash or dash, then
-    'shorewall refresh' failed.
-
-4)  During start/restart, the script generated by Shorewall-perl was
-    clearing the proxy_arp flag on all interfaces; that is not the
-    documented behavior.
-
-5)  If the module-init-tools package was not installed and
-    /etc/shorewall/modules did not exist or was non-empty, then
-    Shorewall-perl would fail with the message:
-
-       ERROR: Can't run lsmod : /etc/shorewall/modules (line 0)
-
-6)  Shorewall-perl now makes a compile-time check to insure that
-    iptables-restore exists and is executable. This check is made when
-    the compiler is being run by root and the -e option is not
-    given.
-
-    Note that iptables-restore must reside in the same directory as the
-    iptables executable specified by IPTABLES in shorewall.conf or
-    located by the PATH in the event that IPTABLES is not specified.
-
-7)  When using Shorewall-perl, if an action was invoked with more than
-    10 different combinations of log-levels/tags, some of those
-    invocations would have incorrect logging.
-
-8)  Previously, when 'shorewall restore' was executed, the
-    iptables-restore utility was always located using the PATH setting
-    rather than the IPTABLES setting.
-
-    With Shorewall-perl, the IPTABLES setting is now used to locate
-    this utility during 'restore' as it is during the processing of
-    other commands.
-
-9)  Although the shorewall.conf manpage indicates that the value
-    'internal' is allowed for TC_ENABLED, that value was previously
-    rejected ('Internal' was accepted).
-
-10) The meaning of the 'loose' provider option was accidentally reversed
-    in Shorewall-perl. Rather than causing certain routing rules to be
-    omitted when specified, it actually caused them to be added (these
-    rules were omitted when the option was NOT specified).
-
-11) If the 'bridge' option was specified on an interface but there were
-    no bport zones, then traffic originating on the firewall was not
-    passed through the accounting chain.
-
-12) In commands such as:
-
-       shorewall compile <directory>
-       shorewall restart <directory>
-       shorewall check <directory>
-
-    if the name of the <directory> contained a period ("."), then
-    Shorewall-perl would incorrectly substitute the current working
-    directory for the name.
-
-13) Previously, if the following sequence of routing rules was
-    specified, then the first rule would always be omitted.
-
-    #SOURCE    DEST      PROVIDER     PRIORITY
-    $SRC_A     $DESTIP1  ISP1         1000
-    $SRC_A     $DESTIP2  SOMEISP      1000
-    $SRC_A     -         ISP2         1000
-
-    The reason for this omission was that Shorewall uses a
-    delete-before-add approach and attempting to delete the third rule
-    resulted in the deletion of the first one instead. 
-
-    This problem occurred with both compilers.
-
-14) When using Shorewall-shell, provider numbers were not recognized in
-    the PROVIDER column of /etc/shorewall/route_rules.
-
-15) An off-by-one problem in Shorewall-perl caused the value 255 to be
-    rejected in the MARK column of /etc/shorewall/tcclasses.
-
-16) When HIGH_ROUTE_MARKS=Yes, marks with values > 255 must be a
-    multiple of 256. That restriction was being enforced by
-    Shorewall-shell but not by Shorewall-perl. Shorewall-perl now also
-    enforces this restriction.
-
-17) Using REDIRECT with a parameterized macro (e.g., DNS/REDIRECT)
-    failed with an "Unknown interface" error when using Shorewall-perl.
-
-Other Changes in Shorewall 4.0.4
-
-1)  The detection of 'Repeat Match' has been improved. 'Repeat Match'
-    is not a match at all but rather is a feature of recent versions of
-    iptables that allows a particular match to be used multiple times
-    within a single rule.
-
-    Example:
-
-      -A foo -m physdev --physdev-in eth0 -m physdev --physdev-out ...
-
-    When using Shorewall-shell, the availability of 'Repeat Match' can
-    speed up compilation very slightly.
-
-2)  Apparently recent Fedora releases are broken. The
-    following sequence of commands demonstrates the problem:
-
-    ip rule add from 1.1.1.1 to 10.0.0.0/8 priority 1000 table 5
-    ip rule add from 1.1.1.1 to 0.0.0.0/0 priority 1000 table main
-    ip rule del from 1.1.1.1 to 0.0.0.0/0 priority 1000
-
-    The third command should fail but doesn't; instead, it incorrectly
-    removes the rule added by the first command.
-    To work around this issue, you can set DELETE_THEN_ADD=No in
-    shorewall.conf which prevents Shorewall from deleting ip rules
-    before attempting to add a similar rule.
-
-3)  When using Shorewall-perl, the following message is now issued if
-    the 'detectnets' option is specified in /etc/shorewall/interfaces:
-
-    WARNING: Support for the 'detectnets' option will be removed from
-    Shorewall-perl in version 4.0.5; better to use 'routefilter' and
-    'logmartians
-
-    The 'detect' options has always been rather silly. On input, it
-    duplicates the function of 'routefilter'. On output, it is a no-op
-    since traffic that doesn't match a route out of an interface won't
-    be sent through that interface (duh!).
-
-    Beginning with Shorewall 4.0.5, the warning message will read:
-
-    WARNING: Support for the 'detectnets' option has been removed
-
- -

2007-09-01 Shorewall 4.0.3

-
Problems Corrected in 4.0.3
-
-1) Using the LOG target in the rules file could result in two LOG
-   rules being generated by Shorewall-shell. Additionally, using an IP
-   address range in a rule that performed logging could result in an
-   invalid iptables command.
-
-2)  Shorewall now loads the act_police kernel module needed by traffic
-    shaping.
-
-3)  Previously, "shorewall show -f capabilities" and "shorecap" omitted
-    the "TCPMSS Match" capability. This made it appear to a compiler
-    using a capabilities file that the TCPMSS Match capability was not
-    available.
-
-4)  Previously, Shorewall would truncate long log prefixes to 29
-    characters. This resulted in there being no space between the log
-    prefix and the IN= part of the message.
-
-    Example: fw2net:LOG:HTTPSoutIN= OUT=eth0
-
-    Beginning with this release, Shorewall will truncate the prefix to
-    28 bytes and add a trailing space.
-
-    Example: fw2net:LOG:HTTPSou IN= OUT=eth0
-
-5)  Previously, if:
-
-    - FASTACCEPT=No
-    - The policy from Z1 to Z2 was CONTINUE
-    - Neither Z1 nor Z2 had parent zones
-    - There were no Z1->Z2 rules
-
-    then connections from Z2->Z1 would fail even if there were
-    rules/policies allowing them. This has been
-    corrected.
-
-6)  The 'shorewall add' and 'shorewall delete' command would fail when:
-
-    - The running configuration was compiled with Shorewall-perl.
-    - The name of the interface specified in the command contained an
-      embedded special character such as '.' or '-'.
-
-    This problem was the result of the change in Shorewall 4.0.2 that
-    removed the legacy mapping of interface names when embedding such
-    names in a Netfilter chain name. To correct the problem, the
-    pre-4.0.2 name mapping is restored when DYNAMIC_ZONES=Yes.
-
-5)  A bug in Shorewall-shell prevented proper handling of PREROUTING
-    marks when HIGH_ROUTE_MARKS=No and the track option was specified
-    in /etc/shorewall/providers.
-
-6)  With Shorewall-perl, if EXPORTPARAMS=Yes then INCLUDE directives in
-    the params file would fail at script execution time with "INCLUDE:
-    not found". This has been corrected.
-
-7)  Shorewall-perl was mis-sorting the zone list when zones were nested
-    more than one deep.
-
-8)  Stale references to http://www.shorewall.net/Documentation.htm have
-    been removed from the config files (including samples). That URL
-    has been replaced by the online manpages.
-
-Other Changes in 4.0.3
-
-1)  A script generated by Shorewall-perl now tries to modify/restore
-    /etc/iproute2/rt_tables only if the file is writable. This prevents
-    run-time errors when /etc is mounted read-only.
-  
-    A new KEEP_RT_TABLES option has been added to shorewall.conf. When
-    set to Yes, this option prevents Shorewall from altering the
-    /etc/iproute2/rt_tables database. The KEEP_RT_TABLES option is only
-    recognized by Shorewall-perl and is ignored by Shorewall-shell.
-
-2)  Shorewall-perl now requires the FindBin Perl module.
-
-3)  When an optional provider is not available, a script generated by
-    Shorewall-perl will no longer add the corresponding
-    routing rules.
-
-4)  A new 'isusable' extension script has been added. This script
-    allows you to extend the availability test that Shorewall performs
-    on optional providers.
-
-    Here's an example that uses ping to ensure that the default
-    gateways through eth0 and eth1 are reachable:
-
-    case $1 in
-        eth0)
-            ping -c 4 -I eth0 206.124.146.254 > /dev/null 2>&1
-            return
-           ;;
-        eth1)
-            ping -c 4 -I eth1 192.168.12.254 > /dev/null 2>&1
-            return
-            ;;
-        *)
-            # Assume we don't need to do any additional testing
-            # for this interface beyond Shorewall's
-            return 0
-            ;;
-    esac
-
-    Additional information is available at
-    http://www.shorewall.net/shorewall_extension_scripts.htm.
-
-5)  Processing of the message log in the 'show log', 'logwatch' and
-    'dump' commands has been speeded up thanks to a suggestion by
-    Andrew Suffield.
-
-6)  Beginning with Shorewall 4.0, the shorewall 'stop', and 'clear'
-    commands were processed by the generated script from the
-    last successful 'start', 'restart' or 'refresh' command. This had
-    the side effect that updates to the /etc/shorewall/routestopped
-    file did not take effect until one of those three commands was
-    successfully processed.
-
-    Beginning with Shorewall 4.0.3, the old 3.x behavior is restored as
-    the default and the 4.0 behavior is enabled using the '-f' command
-    option.
-
-    Example: shorewall stop -f
-
-    is only recognized by Shorewall-perl and causes Shorewall to set
-    the MSS field in forwarded TCP SYN packets going in or out the
-    interface to the value that you specify.
-
-    Example:
-
-    #ZONE       INTERFACE       BROADCAST       OPTIONS
-    vpn         ppp0            -               mss=1400
-
-    The mss option only affects incoming traffic that has not been
-    decrypted by IPSEC and outgoing traffic that will not subsequently
-    be encrypted by IPSEC. The MSS for IPSEC traffic is managed by the
-    'mss' option in /etc/shorewall/zones.
-
-8)  Shorewall now detects the presence of the 'hashlimit match'
-    capability. There is no builtin support yet for hashlimit but
-    detection allows extension scripts for user-supplied actions to
-    determine if the capability exists.
-
-    With Shorewall-shell, $HASHLIMIT_MATCH will be non-empty if the
-    capability exists.
-
-    With Shorewall-perl, $capabilities{HASHLIMIT_MATCH} will be true in
-    a boolean context if the capability exists. Shorewall-perl users
-    may also code the following in their extension script:
-
-    use Shorewall::Config;
-
-    require_capability( 'HASHLIMIT_MATCH',      #Capability
-                        'My hashlimit action' , #Feature requiring 
-                                                #capability
-                        's' );                  #Feature is singular
-                                                #(if plural, pass the
-                                                  empty string)
-
-    That call would procduce the following fatal error if the
-    capability isn't available:
-
-    ERROR: My hashlimit action requires the Hashlimit match capability
-           in your kernel and iptables
-
-9)  NFQUEUE support has been added to Shorewall-perl.
-
-    NFQUEUE may appear in actions, macros, rules and as a policy.
-    When NFQUEUE is used by itself, queue number zero is assumed. To
-    specify a queue number, follow NFQUEUE by a slash ("/") and the
-    queue number.
-
-    Examples (/etc/shorewall/rules):
-
-    NFQUEUE             loc     net     tcp #Queue number 0
-    NFQUEUE/22          loc     net     udp #Queue number 22
-    NFQUEUE/22:info     loc     net     gre #With logging
-
-    An NFQUEUE_DEFAULT option has been added to shorewall.conf for
-    specifying the default action to use with NFQUEUE policies.
-
-    Use of NFQUEUE requires the NFQUEUE Target capability in your
-    kernel/iptables. If you intend to use NFQUEUE with Shorewall-lite,
-    then you must install Shorewall-lite 4.0.3 in order to build a
-    capabilities file that includes NFQUEUE Target. If your
-    capabilities file was generated by a Shorewall/Shorewall-lite
-    version earlier that 4.0.3, you will receive a warning during
-    compilation.
-
-10) The 'refresh' command can now refresh chains other than 'blacklst'.
-
-    The syntax of the command is now:
-
-        shorewall refresh [ <chain> ... ]
-
-    If no <chain> is given then 'blacklst' is assumed. Otherwise, the
-    Shorewall-perl compiler compiles a script whose 'refresh' command
-    refreshes the listed <chain>(s).
-
-    The listed chains are assumed to be in the filter table. You can
-    refresh chains in other tables by prefixing the chain name with the
-    table name followed by ":" (e.g., nat:net_dnat). Chain names which
-    follow are assumed to be in that table until the end of the list or
-    until an entry in the list names another table.
-
-    This feature requires Shorewall-perl 4.0.3 as well as
-    Shorewall-common 4.0.3.
-
-

2007-08-19 Shorewall 3.4.6

Problems Corrected in 3.4.6.
 
@@ -1847,9 +1487,7 @@ Shorewall project.
 

Problems Corrected in 3.2.10

1)  Previously, if a 'start' or 'restart' command failed during the
    compilation step, /sbin/shorewall erroneously returned an exit
    status of zero.

2)  If IMPLICIT_CONTINUE=Yes was in effect, then sub-zones received the
    implicit CONTINUE policy for their intra-zone traffic (rather than
    the implicit ACCEPT policy for such traffic). This could cause
    intra-zone traffic to be rejected by rules in one of the parent
    zones.

3) The "shorewall-[lite] [re]start and stop" commands reset the
   proxy_arp flag on all interfaces on the system making it impossible
   to control proxy arp manually with Shorewall installed. With this
   change, shorewall will only clear proxy arp if there were entries in
   /etc/shorewall/proxyarp the last time that Shorewall was
   [re]started.
   
4)  The /usr/share/shorewall[-lite]/modules file has been updated for
    kernel 2.6.20.

5)  The /proc/net/ip_conntrack pseudo-file has been inexplicably
    renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
    library has been updated to look for both files.

6)  Tunnels of type 'ipsecnat' failed to work properly due to a missing
    rule.

7)  The 'shorecap' program was not loading modules correctly.
-2007-04-01 Shorewall 3.4.2
+2007-04-01 Shorewall 3.4.2
 
Problems corrected in Shorewall 3.4.2

1)  The /usr/share/shorewall[-lite]/modules file has been updated for
    kernel 2.6.20.

2)  The /proc/net/ip_conntrack pseudo-file has been inexplicably
    renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
    library has been updated to look for both files.

3)  Shoreall 3.4 was not consistent with respect to its treatment of
    log level 'none' and 'none!' and built-in actions. In particular,
    specifying 'none' with the Limit action produced a run-time error.
    Shorewall now correctly suppresses generation of log messages when
    a log level of 'none' or 'none!' is given to a built-in action.

4)  Tunnels of type 'ipsecnat' would sometimes fail to work because of
    a missing rule.
@@ -1864,6 +1502,6 @@ style="font-weight: bold;">2007-04-01 Shorewall 3.4.2
Shorewall 3.4.0

Release Highlights

1)  Shorewall can now be tailored to reduce its footprint on embedded
    systems. As part of this change, actions are now completely
    optional.

    See http://www.shorewall.net/Modularization.html for details.

2)  Exclusion is now possible in /etc/shorewall/hosts. This is required
    for bridge/firewalls under kernel 2.6.20 and later.

    See http://www.shorewall.net/NewBridge.html.

3)  Shorewall and Shorewall Lite now include man pages. There is a 
    man page for shorewall(8), one for shorewall-lite(8) and one for
    each configuration file. As part of this change, all documentation
    has been removed from Shorewall configuration files. This should
    make it easier from users to upgrade from one release to the next
    since the configuration files will only change when column is added
    or renamed.

    See http://www.shorewall.net/manpages/Manpages.html

4)  Shorewall now remembers the changes that it has made to routing as
    a result of entries in /etc/shorewall/providers and
    /etc/shorewall/route_rules and reverses those changes when
    appropriate.

Problems Corrected in 3.4.0 Final.

1)  In the rules file, following the action with "!" is supposed to
    exempt the rule from being suppressed by OPTIMIZE=1. That feature
    was not working.

2)  If both a macro body and a macro invocation contained an entry in the
    SOURCE or DEST column, then compilation failed with the error:

           merge_macro_source_dest: command not found

3)  An obscure bug in rule activation having to do with the new
    exclusion feature in /etc/shorewall/hosts has been corrected.

4) The "shorewall-[lite] [re]start and stop" commands reset the
   proxy_arp flag on all interfaces on the system making it impossible
   to control proxy arp manually with Shorewall installed. With this
   change, shorewall will only clear proxy arp if there were entries in
   /etc/shorewall/proxyarp the last time that Shorewall was
   [re]started.

New Features in Shorewall 3.4:

1)  In order to accomodate small embedded applications, Shorewall 3.4
    is now modularized. In addition to the base files, there are
    loadable "libraries" that may be included or omitted from an
    embedded system as required.

    Loadable Shorewall libraries reside in /usr/share/shorewall/ and
    have names that begin with "lib.". The following libraries are
    included in Shorewall 3.4:

    - lib.accounting. Must be available if you include entries in
      /etc/shorewall/accounting.

    - lib.actions. Must be available if you do not specify
      USE_ACTIONS=No in /etc/shorewall/shorewall.conf.

    - lib.base. The base Shorewall library required by all programs,
      including compiled firewall scripts. This library is also
      released as part of Shorewall Lite and is installed in
      /usr/share/shorewall-lite/.

    - lib.cli. Library containing the code common to /sbin/shorewall,
      /sbin/shorewall-lite. This library is also released as part of
      Shorewall Lite and is installed in /usr/share/shorewall-lite/.

    - lib.config. Library containing the code that is common to
      /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. 

    - lib.dynamiczones. Must be available if you specify
      DYNAMIC_ZONES=Yes in shorewall.conf.

    - lib.maclist. Must be available if you specify the 'maclist'
      option in /etc/shorewall/interfaces or /etc/shorewall/hosts.

    - lib.nat. Must be available if you have entries in
      /etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap
      or if you use DNAT or REDIRECT rules.

    - lib.providers. Must be available if you have entries in
      /etc/shorewall/providers.

    - lib.proxyarp. Must be available if you have entries in
      /etc/shorewall/proxyarp or if you specify the 'proxyarp' option
      in /etc/shorewall/interfaces.

    - lib.tc. Must be available if you have entries in
      /etc/shorewall/tcdevices and /etc/shorewall/tcclasses.

    - lib.tcrules. Must be available if you have entries in
      /etc/shorewall/tcrules.

    - lib.tunnels. Must be available if you have entries in
      /etc/shorewall/tunnels.

    Embedded applications can further decrease the size of the Shorewall
    footprint by:

    - Omitting the macro files.
    - Omitting all unused extension scripts.

    See http://www.shorewall.net/Modularization.html for additional
    details.

2)  As hinted in the previous bullet, there is a new USE_ACTIONS option
    in /etc/shorewall/shorewall.conf. Shorewall actions can be very
    powerful but they also require a lot of code to implement. Embedded
    applications can omit that code by setting
    USE_ACTIONS=No. Shorewall will ignore all action-related files
    including /usr/share/shorewall/actions.std and
    /etc/shorewall/actions. Builtin actions will still be available for
    use in rules and macros.

    The 'Limit' action has been converted to a builtin so that Limit is
    available even when USE_ACTIONS=No.

    See the next item for more information.

3)  Prior to Shorewall 3.4, default actions were specified in
    /usr/share/shorewall/actions.std or in /etc/shorewall/actions.

    This approach has two drawbacks:

    a) All DROP policies must use the same default action and all
       REJECT policies must use the same default action.

    b) Now that we have modularized action processing (see the New
       Features section below), we need a way to define default rules
       for a policy that does not involve actions.

    The solution is two-fold:

    - Four new options have been added to the
      /etc/shorewall/shorewall.conf file that allow specifying the
       default action for DROP, REJECT, ACCEPT and QUEUE.

       The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and
       QUEUE_DEFAULT.

       DROP_DEFAULT describes the rules to be applied before a
       connection request is dropped by a DROP policy; REJECT_DEFAULT
       describes the rules to be applied if a connection request is
       rejected by a REJECT policy. The other two are similar for
       ACCEPT and QUEUE policies.

       The value assigned to these may be:

        a) The name of an action.
        b) The name of a macro
        c) 'None' or 'none'

       The default values are:

        DROP_DEFAULT="Drop"
        REJECT_DEFAULT="Reject"
        ACCEPT_DEFAULT=none
        QUEUE_DEFAULT=none

       If USE_ACTIONS=Yes, then these values refer to action.Drop and
       action.Reject respectively. If USE_ACTIONS=No, then these values
       refer to macro.Drop and macro.Reject.

       If you set the value of either option to "None" then no default
       action will be used and the default action or macro (if any)
       must be specified in /etc/shorewall/policy

    - The POLICY column in /etc/shorewall/policy has been extended.

       In /etc/shorewall/policy, when the POLICY is DROP, REJECT,
       ACCEPT or QUEUE then the policy may be followed by ":" and one
       of the following:

        a) The word "None" or "none". This causes any default
           action defined in /etc/shorewall/shorewall.conf
           to be omitted for this policy.
        b) The name of an action (requires that USE_ACTIONS=Yes
           in shorewall.conf). That action will be invoked
           before the policy is enforced.
        c) The name of a macro. The rules in that macro will
           be applied before the policy is enforced. This
           does not require USE_ACTIONS=Yes.

    Example:

        #SOURCE         DEST            POLICY          LOG
        #                                               LEVEL
        loc             net             ACCEPT
        net             all             DROP:MyDrop     info
        #
        # THE FOLLOWING POLICY MUST BE LAST
        #
        all             all             REJECT:MyReject info

4)  For users whose kernel and iptables have Extended MARK Target
    support, it is now possible to logically AND or OR a value into the
    current packet mark by preceding the mark value (and optional mask)
    with an ampersand ("&") or vertical bar ("|") respectively.

    Example: To logically OR the value 4 into the mark value for
    packets from 192.168.1.1:

    #MARK   SOURCE
    |4      192.168.1.1

5)  Previously, zone names were restricted to five characters in
    length. That limit derives from the --log-prefix in Netfilter log
    messages which must be 29 bytes or less in length. With the
    standard Shorewall LOGFORMAT, that leaves 11 characters for the
    chain name; given that many chain names are of the form
    <zone1>2<zone2>, that gives a maximum zone name length of 5.

    Beginning with this release, the maximum length of a zone name is
    dependent on the LOGFORMAT (the maximum length may never be less
    than 5 but it may be greater than 5). For example, setting
    LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters.

6)  Netfilter provides support for attachment of comments to Netfilter
    rules. Comments can be up to 255 bytes in length and are visible
    using the "shorewall show <chain>", "shorewall show nat",
    "shorewall show mangle" and "shorewall dump" commands. Comments are
    delimited by '/* ... */" in the output.

    Beginning with Shorewall 3.4, you may place COMMENT lines in the
    /etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat
    and /etc/shorewall/masq files and in action files. The remainder of
    the line is treated as a comment and it will be attached as a
    Netfilter comment to the rule(s) generated by succeding entries
    in the file.

    Note: Do not prefix the comment with "#". Shorewall's two-pass
    compiler strips off "#" comments in the first pass and processes
    COMMENT lines in the second pass. Hence, by the time that COMMENT
    is processed, the "#" and everything following it has been removed
    (see example below).

    To stop the current comment from being attached to further
    rules, simply include COMMENT on a line by itself (so that the
    following rules will have no comment) or specify a new COMMENT.

    If you do not have Comment support in your iptables/kernel (see the
    output of "shorewall[-lite] show capabilities") then COMMENTS are
    ignored with this warning:

     COMMENT ignored --  requires comment support in iptables/Netfilter

    Example from my rules file:

            #SOURCE      SOURCE     DEST       PROTO DEST PORT(S)

            COMMENT Stop Microsoft Noise

            REJECT       loc        net        tcp   137,445
            REJECT       loc        net        udp   137:139

            COMMENT  # Stop comment from being attached to rules below

    The output of "shorewall show loc2net" includes (folded):

    0     0 reject     tcp  --  *      *       0.0.0.0/0
          0.0.0.0/0    multiport dports 137,445 /* Stop Microsoft Noise */
    0     0 reject     udp  --  *      *       0.0.0.0/0
          0.0.0.0/0    udp dpts:137:139 /* Stop Microsoft Noise */

7)  A new macro (macro.RDP) has been added for Microsoft Remote
    Desktop. This macro was contributed by Tuomo Soini.

8)  A new 'maclog' extension file has been added. This file is
    processed just before logging based on the setting of
    MACLIST_LOG_LEVEL is done. When the extension is invoked, the CHAIN
    variable will contain the name of the chain where rules should be
    inserted. Remember that if you have specified MACLIST_TABLE=mangle,
    then your run_iptables commands should include "-t mangle".

9)  The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to
    more accurately describe the contents of the column.

10) Previously, it was not possible to use exclusion in
    /etc/shorewall/hosts. Beginning with this release, you may now use
    exclusion lists in entries in this file. Exclusion lists are
    discussed at:

       http://www.shorewall.net/configuration_file_basics.htm#Exclusion.

    Example:

        loc     eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28

    In that example, the 'loc' zone is defined to be the subnet
    192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4
    and hosts in the sub-network 192.168.1.16/28.

11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing"
    commands have been added. The first produces the same output as "ip
    addr ls". The second produces a report about your routing rules and
    tables.

12) Beginning with this release, Shorewall and Shorewall Lite will
    share common change logs and release notes.

13) In Shorewall versions prior to 3.4, multiple jumps to a '2all'
    chain could be generated in succession.

    Example from an earlier shorewall version:

    gateway:~ # shorewall-lite show eth2_fwd
    Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006

    Counters reset Thu Oct 19 08:34:47 PDT 2006

    Chain eth2_fwd (1 references)
     pkts bytes target     prot opt in     out     source            destination
        0     0 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW
        0     0 wifi2all   all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
        0     0 wifi2all   all  --  *      br0     0.0.0.0/0            0.0.0.0/0
        0     0 wifi2all   all  --  *      eth3    0.0.0.0/0            0.0.0.0/0
        0     0 wifi2all   all  --  *      tun+    0.0.0.0/0            0.0.0.0/0
    gateway:~ #

    This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.

    gateway:~ # shorewall-lite show eth2_fwd
    Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006

    Counters reset Thu Oct 19 09:15:19 PDT 2006

    Chain eth2_fwd (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW
        0     0 wifi2all   all  --  *      *       0.0.0.0/0            0.0.0.0/0
    gateway:~ #

    Note that with OPTIMIZE=1, traffic destined for an
    interface/Address that falls outside of all defined zones may now
    be logged out of a '2all' chain rather than out of the FORWARD
    chain.

    The OPTIMIZE setting also controls the suppression of redundant
    wildcard rules (those specifying "all" in the SOURCE or DEST
    column). A wildcard rule is considered to be redundant when it
    has the same ACTION and Log Level as the applicable policy.

    Example:

        /etc/shorewall/policy

        #SOURCE         DEST            POLICY          LEVEL
        loc             net             ACCEPT

        /etc/shorewall/rules

        #ACTION         SOURCE          DEST    PROTO   DEST
        #                                               PORT(S)
        ...
        ACCEPT          all             all     icmp    8

    OPTIMIZE=0

    gateway:~ # shorewall show loc2net
    Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006

    Counters reset Thu Oct 26 07:54:58 PDT 2006

    Chain loc2net (1 references)
     pkts bytes target     prot opt in     out     source               destination
      ...
        0     0 DROP       all  --  *      *      !192.168.0.0/22       0.0.0.0/0
        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8
        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

    gateway:~

    OPTIMIZE=1

    gateway:~ # shorewall show loc2net
    Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006

    Counters reset Thu Oct 26 07:56:38 PDT 2006

    Chain loc2net (1 references)
     pkts bytes target     prot opt in     out     source               destination
      ...
        0     0 DROP       all  --  *      *      !192.168.0.0/22       0.0.0.0/0
        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

    gateway:~

    If you really want a rule that duplicates the policy, follow the
    action with "!":

        #ACTION         SOURCE          DEST    PROTO   DEST
        #                                               PORT(S)
        ...
        ACCEPT!         all             all     icmp    8

14) IP Address ranges are now allowed in the drop, reject, allow and
    logdrop shorewall[-lite] commands.

15) Previously, Shorewall has not attempted to undo the changes it has
    made to the firewall's routing as a result of entries in
    /etc/shorewall/providers and /etc/shorewall/routes. Beginning with
    this release, Shorewall will attempt to undo these changes.

    When Shorewall starts or is restarted and there are entries in
    /etc/shorewall/providers, Shorewall will capture the contents
    of /etc/shorewall/rt_tables and will restore that database when
    Shorewall is stopped or restarted. Similarly, the default route
    will be captured the first time that you [re]start Shorewall using
    this version and will be restored under the following conditions:

    a) shorewall stop
    b) shorewall clear
    c) shorewall restart or restore and there are no entries in
       /etc/shorewall/providers.

    Once the default route has been restored, Shorewall will delete
    the saved copy so that it will once again be captured at the next
    shorewall start or shorewall restore.

16) Shorewall no longer includes policy matches in its generated
    ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC
    networks are defined using the 'ipsec' option in
    /etc/shorewall/hosts).

17) The Makefile installed in /usr/share/shorewall/configfiles/ is now
    the same one mentioned at
    http://www.shorewall.net/CompiledPrograms.html.

    Once the file is copied into an export directory, you modify the
    setting of the HOST variable to match the name of the remote
    firewall.

    The default target is the "firewall" script so "make" compiles the
    firewall script if any of the configuration files have
    changed. "make install" builds "firewall" if necessary then
    installs it on the remote firewall. "make capabilities" will
    generate the "capabilities" file. "make save" will save the running
    configuration on the remote firewall.

18) Shorewall and Shorewall Lite now include the following manpages. 

              shorewall-accounting(5)
              shorewall-actions(5)
              shorewall-blacklist(5)
              shorewall.conf(5)
              shorewall-ecn(5)
              shorewall-exclusion(5)
              shorewall-hosts(5)
              shorewall-interfaces(5)
              shorewall-lite.conf(5)
              shorewall-lite(8)
              shorewall-maclist(5)
              shorewall-masq(5)
              shorewall-nat(5)
              shorewall-nesting(5)
              shorewall-netmap(5)
              shorewall-params(5)
              shorewall-policy(5)
              shorewall-providers(5)
              shorewall-proxyarp(5)
              shorewall-rfc1918(5)
              shorewall-route_rules(5)
              shorewall-routestopped(5)
              shorewall-rules(5)
              shorewall-tcclasses(5)
              shorewall-tcdevices(5)
              shorewall-tcrules(5)
              shorewall-template(5)
              shorewall-tos(5)
              shorewall-tunnels(5)
              shorewall(8)
              shorewall-zones(5)

    Now that the manpages are in place, command-specific help has been
    removed since it duplicates information in the man pages.

19) From the beginning, the Shorewall configuration files in
    /etc/shorewall/ have contained documentary comments. While these
    comments are useful, they present an upgrade problem. Beginning
    with this release, these comments are removed from the
    configuration files themselves and are replaced by the manpages
    described in the preceding release note entry.

20) Shorewall now uses tc fwmark filters to classify packets for
    traffic shaping when the DEVICE isn't an interface described in
    /etc/shorewall/interfaces. This is in preparation for the upcoming
    change to the way that --physdev-out works in iptables/Netfilter;
    that change is now scheduled for kernel 2.6.20.

21) If your kernel and iptables have extended multiport support, then
    Shorewall will use that support for the destination port when
    generating rules from entries in the /etc/shorewall/tcrules file.
22) The 'safe-start' and 'safe-restart' command have been
    improved. Both now accept an optional directory name; if supplied,
    Shorewall will look first in that directory for configuration
    files.

    The commands have also been enhanced to only restore the
    configuration once in the event of a failure. Previously, if there
    was a current 'save' command in effect, then that configuration
    would be restored on a failure and then the last-running
    configuration would be restored.

23) The 'try' command has been reimplemented with new semantics. 

    If Shorewall is started then the firewall state is saved to a
    temporary saved configuration (/var/lib/shorewall/.try). Next, if
    Shorewall is currently started then a restart command is issued;
    otherwise, a start command is performed. if an error occurs during
    the  compliation phase  of  the  restart or start, the command
    terminates without changing the Shorewall state. If an error occurs
    during the restart phase, then a 'shorewall restore' is performed
    using the saved configuration. If an error occurs during the start
    phase, then Shorewall is  cleared. If the start/restart succeeds
    and a timeout is specified then a 'clear' or 'restore' is performed
    after timeout seconds. 

24) The syntax of the 'export' command has been made slightly
    friendlier.

    The old syntax:

        export <directory1> [user@]system:[<directory2>]

    It is now:

        export <directory1> [user@]system[:<directory2>]

    In other words, if you don't need to specify <directory2>, you may
    omit the colon (":") following the system name.
    
    The old syntax is still accepted -- that is, you can still 
    type:

        export firewall2:

    which is equivalent to

        export firewall2

25) Shorewall commands may be speeded up slightly by using a
    'capabilities' file. The 'capabilities' file was originally
    designed for use with Shorewall Lite and records the
    iptables/Netfilter features available on the target system.

    To generate a capabilities file, execute the following command as
    root:

      shorewall show -f capabilities > /etc/shorewall/capabilities

    When you install a new kernel and/or iptables, be sure to generate
    a new capabilities file.
        
26) When syslogd is run with the -C option (which in some
    implementations causes syslogd to log to an in-memory circular
    buffer), /sbin/shorewall will now use the 'logread' command to read
    the log from that buffer. This is for combatibility with OpenWRT.

27) There is now a ":T" qualifier in /etc/shorewall/tcrules which
    causes the resulting rule to be inserted into the POSTROUTING
    chain.

28) The program /usr/share/shorewall/wait4ifup can be used to wait for
    a network device (such as a ppp device) to reach the UP state. 
    
        /usr/share/shorewall/wait4ifup <interface> [ <seconds> ]

    The program will wait for up to <seconds> seconds for the 
    named <interface> to reach the UP state. If <seconds> is not given,
    60 seconds is assumed.

    The exit status is zero if <interface> comes up within <seconds>
    seconds and non-zero otherwise.

29) Previously, 'ipsecnat' tunnels allowed AH traffic by default
    (unless 'isecnat:noah' was given). Given that AH is incompatible
    with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.

30) Shorewall now generates half as many rules as previously in the
    'blacklst' chain when BLACKLIST_LOGLEVEL is specified.

31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in
    shorewall.conf then Shorewall will not process
    /etc/shorewall/params when the compiled script is run. With
    EXPORTPARAMS=No, any shell variables needed at run-time must be set
    in /etc/shorewall/init.

    In a Shorewall/Shorewall Lite environment, this allows
    /etc/shorewall/params to be written to run exclusively
    on the administrative system while /etc/shorewall/init runs
    exclusively on the firewall system.

    So shell variables required at compile time may be set in
    /etc/shorewall/params and those required at run-time may be set in
    /etc/shorewall/init.

    Note 1: If you need shell variables values in your
    /etc/shorewall/stop or /etc/shorewall/stopped script, then you need
    to set their values in /etc/shorewall/stop. /etc/shorewall/init is
    not invoked during processing of the 'stop' and 'clear' commands.

    Note 2: EXPORTPARAMS was actually introduced in Shorewall version
    3.2.9. It is described here for the benefit of those who did not
    install that version.
-Old News here
- - +Old News here
+ + \ No newline at end of file diff --git a/web/shorewall_index.htm b/web/shorewall_index.htm index 3735d87a6..52fd90b61 100644 --- a/web/shorewall_index.htm +++ b/web/shorewall_index.htm @@ -1,15 +1,12 @@ - - - - Shoreline Firewall (Shorewall) 3.* - - - - + - + + Shoreline Firewall (Shorewall) 3.* + + + +

Shoreline Firewall (Shorewall)

Copyright © 2001-2007 Thomas M. Eastep

@@ -18,19 +15,16 @@ under the terms of the GNU Free Documentation License, Version 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 “GNU Free Documentation License”.

+license is included in the section entitled “GNU Free Documentation License”.

-

2007-09-28

+

2007-09-01

Table of Contents

-

Introduction to Shorewall

+

Introduction to Shorewall

-

Glossary
+

Glossary
What is Shorewall?
Current Shorewall Releases
Getting Started with Shorewall
@@ -46,8 +40,7 @@ Feature

Glossary