From 88c2361323ab39c78f7e753c61033ea7e47dca8d Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 1 Jan 2009 17:28:55 +0000 Subject: [PATCH] Update News again git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9231 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- web/News.htm | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/web/News.htm b/web/News.htm index a0dbc2175..5e8254489 100644 --- a/web/News.htm +++ b/web/News.htm @@ -32,9 +32,13 @@ License".

2008-12-31 Shorewall 4.2.4

1) In 4.2.4, two new packages are included:

   a) Shorewall6 - analagous to Shorewall-common but handles IPv6
      rather than IPv4.

   b) Shorewall6-lite - analagous to Shorewall-lite but handles IPv6
      rather than IPv4.

   The packages store their configurations in /etc/shorewall6/ and
   /etc/shorewall6-lite/ respectively.  

   The fact that the packages are separate from their IPv4 counterparts
   means that you control IPv4 and IPv6 traffic separately (the same
   way that Netfilter does). Starting/Stopping the firewall for one
   address family has no effect on the other address family.

   For additional information, see
   http://www.shorewall.net/IPV6Support.html.

   Other features of Shorewall6 are:

   a) There is no NAT of any kind (most people see this as a giant step
      forward). When an ISP assigns you a public IPv6 address, you are
      actually assigned an IPv6 'prefix' which is like an IPv4
      subnet. A 64-bit prefix allows 4 billion squared individual hosts
      (the size of the current IPv4 address space squared).

   b) The default zone type is ipv6.

   c) The currently-supported interface options in Shorewall6 are:

        blacklist
        bridge
        dhcp
        nosmurfs (traps multicast and Subnet-router anycast addresses
        used as the packet source address).
        optional
        routeback
        sourceroute
        tcpflags

   Other features of Shorewall6 are:

   a) There is no NAT of any kind (most people see this as a giant step
      forward). When an ISP assigns you a public IPv6 address, you are
      actually assigned an IPv6 'prefix' which is like an IPv4
      subnet. A 64-bit prefix allows 4 billion squared individual hosts
      (the size of the current IPv4 address space squared).

   b) The default zone type is ipv6.

   c) The currently-supported interface options in Shorewall6 are:

        blacklist
        bridge
        dhcp
        nosmurfs (traps multicast and Subnet-router anycast addresses
        used as the packet source address).
        optional
        routeback
        sourceroute
        tcpflags
        mss
        forward (setting it to 0 makes the router behave like a host
                 on that interface rather than like a router).

   d)  The currently-supported host options in Shorewall6 are:

        blacklist
        routeback
        tcpflags

   e)  Traffic Shaping is disabled by default. The tcdevices and
       tcclasses files are address-family independent so
       to use the Shorewall builtin Traffic Shaper, TC_ENABLED=Internal
       should be specified in Shorewall or in Shorewall6 but not in
       both. In the configuration where the internal traffic shaper is
       not enabled, CLEAR_TC=No should be specified.

       tcfilters are not available in Shorewall6.

   f)  When both an interface and an address or address list need to
       be specified in a rule, the address or list must be enclosed in
       angle brackets. Example:

        #ACTION      SOURCE                                     DEST
        ACCEPT       net:eth0:<2001:19f0:feee::dead:beef:cafe>  dmz

       Note that this includes MAC addresses as well as IPv6 addresses.

       The HOSTS column in /etc/shorewall6/hosts also uses this
       convention:

           #ZONE      HOSTS                                     OPTIONS
           chat6      eth0:<2001:19f0:feee::dead:beef:cafe>

       Even when an interface is not specified, it is permitted to
       enclose addresses in <> to improve readability. Example:

           #ACTION      SOURCE          DEST
           ACCEPT       net:<2001:1::1> $FW

   g)  The options available in shorewall6.conf are a subset of those
       available in shorewall.conf.

   h)  The Socket6.pm Perl module is required if you include DNS names
       in your Shorewall6 configuration. Note that it is loaded the
       first time that a DNS name is encountered so if it is missing,
       you get a message similar to this one:

       ...
       Checking /etc/shorewall6/rules...
       Can't locate Socket6.pm in @INC (@INC contains: /root ...
       teastep@ursa:~/Configs/standalone6$
+

2008-12-16 Shorewall 4.2.3

+

+
Problems corrected in Shorewall 4.2.3

1)  Previously, Shorewall would allow compilation for export of a
    script named 'shorewall' with the unfortunate side effect that
    the 'shorewall.conf' file was overwritten. Scripts named
    'shorewall' now cause a fatal error to be raised.

2)  Previously, Shorewall-perl attempted to do Shell variable
    substitution on the first line in /etc/shorewall/compile.

3)  Following the Netfilter tradition, the IPP2P maintainer has made an
    incompatible syntax change (the --ipp2p option has been
    removed). Shorewall has always used "-m ipp2p --ipp2p" when
    detecting the presence of IPP2P support.

    Shorewall-common and Shorewall-perl have been modified to use
    "-m ipp2p --edk" instead.

4)  When Extended Conntrack Match support was available, Shorewall-perl
    would create invalid iptables-restore input for certain DNAT rules.

5)  An optimization in all Shorewall-perl 4.2 versions could  cause
    undesirable side effects. The optimization deleted the
    <interface>_in and <interface>_fwd chains and moved their rules
    to the appropriate rules chain (a <zone>2<xxx> chain).

    This worked badly in cases where a zone was associated with more
    than one interface. Rules could be duplicated or, worse, a rule
    that was intended for only input from one of the interfaces would
    be applied to input from all of the zone's interfaces.

    This problem has been corrected so that an interface-related
    chains is only deleted if:

    a) the chain has no rules in it; or
    b) the interface is associated with only one zone and that zone is
       associated with only that interface in which case it is safe to
       move the rules.

Other changes in Shorewall 4.2.3

1)  Except with the -e option is specified, the Shorewall-perl compiler
    now verifies user/group names appearing in the USER/GROUP column of
    the rules file.

2)  The output of 'shorewall dump' now includes the output from
    'netstat -tunap'.

3)  Shorewall-perl now accepts '+' as an interface name in
    /etc/shorewall/interfaces. That name matches any interface and is
    useful for defining a zone that will match any interface that might
    be added after Shorewall is started.

    A couple of words of caution are in order.

    a) Because '+' matches any interface name, Shorewall cannot
       verify interface names appearing in other files when '+' is
       defined in /etc/shorewall/interfaces.

    b) The zone assigned to '+' must be the last one defined in
       /etc/shorewall/zones.

4)  Shorewall-perl now uses the iptables --goto parameter in obvious
    cases.

5)  The 'reset' command now allows you to reset the packet and byte
    counter on individual chains:

            shorewall reset chain1 chain2 ...
            shorewall-lite reset chain1 chain2 ...

2008-11-20 Shorewall 4.2.2

-
Problems corrected in Shorewall 4.2.2

1)  Shorewall-perl now insures that each line copied from a
    configuration file or user exit is terminated with a newline
    character.

2) When ipranges were used to define zones, Shorewall-perl could
   generate invalid iptables-restore input if 'Repeat Match' was not
   available. Repeat Match is not a true match -- it rather is a
   feature of recent iptables releases that allows a match to be
   repeated within a rule.

3)  With Shorewall-perl, if a destination port list had exactly 16
    ports, where a port-range counts as two ports, then Shorewall-perl
    would fail to split the rule into multiple rules and an
    iptables-restore error would result.

4)  The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1
    compatibility contained a typo that prevented it from working
    correctly.

5)  If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP
    address and no zone name in the DEST column, Shorewall-perl would
    reject the rule. If a zone name was specified, Shorewall-perl 
    would issue a Warning message.

6)  Previously, if Extended conntrack match support was available, a
    DNAT rule that specified a server port but no destination port 
    would generate invalid iptables-restore input.     

Other changes in Shorewall 4.2.2

1)  A macro supporting JAP (anonymization protocol) has been added.
    It can be used as any other macro (e.g., JAP/ACCEPT) in the rules
    file.

2)  A macro supporting DAAP (Digital Audio Access Protocol) has been added.
    It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules
    file.

3)  A macro supporting DCC (Distributed Checksum Clearinghouse) has been
    added.  It can be used as any other macro (e.g., DCCP/ACCEPT) in the
    rules file.

4)  A macro supporting GNUnet (secure peer-to-peer networking) has been
    added.  It can be used as any other macro (e.g., GNUnet/ACCEPT) in the
    rules file.

5)  In 4.2.1, a single capability ("Extended conntrack match support")
    was used both to control the use of --ctorigport and to trigger use
    of the new syntax for inversion of --ctorigdst (e.g., "!
    --ctorigdst ..."). In 4.2.2, these are controlled by two separate
    capabilities. If you use a capabilities file when compiling your
    configuration, be sure to generate a new one after installing
    4.2.2.
+Problems corrected in Shorewall 4.2.2 +

1)  Shorewall-perl now insures that each line copied from a
    configuration file or user exit is terminated with a newline
    character.

2) When ipranges were used to define zones, Shorewall-perl could
   generate invalid iptables-restore input if 'Repeat Match' was not
   available. Repeat Match is not a true match -- it rather is a
   feature of recent iptables releases that allows a match to be
   repeated within a rule.

3)  With Shorewall-perl, if a destination port list had exactly 16
    ports, where a port-range counts as two ports, then Shorewall-perl
    would fail to split the rule into multiple rules and an
    iptables-restore error would result.

4)  The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1
    compatibility contained a typo that prevented it from working
    correctly.

5)  If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP
    address and no zone name in the DEST column, Shorewall-perl would
    reject the rule. If a zone name was specified, Shorewall-perl 
    would issue a Warning message.

6)  Previously, if Extended conntrack match support was available, a
    DNAT rule that specified a server port but no destination port 
    would generate invalid iptables-restore input.     

Other changes in Shorewall 4.2.2

1)  A macro supporting JAP (anonymization protocol) has been added.
    It can be used as any other macro (e.g., JAP/ACCEPT) in the rules
    file.

2)  A macro supporting DAAP (Digital Audio Access Protocol) has been added.
    It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules
    file.

3)  A macro supporting DCC (Distributed Checksum Clearinghouse) has been
    added.  It can be used as any other macro (e.g., DCCP/ACCEPT) in the
    rules file.

4)  A macro supporting GNUnet (secure peer-to-peer networking) has been
    added.  It can be used as any other macro (e.g., GNUnet/ACCEPT) in the
    rules file.

5)  In 4.2.1, a single capability ("Extended conntrack match support")
    was used both to control the use of --ctorigport and to trigger use
    of the new syntax for inversion of --ctorigdst (e.g., "!
    --ctorigdst ..."). In 4.2.2, these are controlled by two separate
    capabilities. If you use a capabilities file when compiling your
    configuration, be sure to generate a new one after installing
    4.2.2.

2008-10-25 Shorewall 4.2.1

Problems corrected in Shorewall 4.2.1

1)  A description of the CONNBYTES column has been added to
    shorewall-tcrules(5).

2)  Previously, Shorewall-perl would accept zero as the <max> value in
    the CONNBYTES column of tcrules even when the <min> field was
    non-zero. A value of zero for <max> was equivalent to omitting
    <max>.

3)  iptables 1.4.1 discontinued support of syntax generated by
    shorewall in some cases. Shorewall now detects when the new syntax
    is required and uses it instead.

4)  The Shorewall-perl implementation of the LENGTH column in
    /etc/shorewall/tcrules was incomplete with the result that 
    all LENGTH rules matched. Thanks to Lennart Sorensen for the patch.

5)  The 'export' command no longer fails with the error:

    /sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi")

Other changes in Shorewall 4.2.1

1)  With the recent renewed interest in DOS attacks, it seems
    appropriate to have connection limiting support in Shorewall. To
    that end, a CONNLIMIT column has been added to both the policy and
    rules files.

    The content of these columns is of the format

        [!] <limit>[:<mask>]

    where

        <limit> is the limit on simultaneous TCP connections.

        <mask>  specifies the size of the network to which
                the limit applies and is specified as a
                CIDR mask length. The default value for
                <mask> is 32 which means that each remote
                IP address can have <limit> TCP connections
                active at once.

        !       Not allowed in the policy file. In the rules file, it
                causes connections to match when the number of
                current connections exceeds <limit>.
    
    When specified in the policy file, the limit is enforced on all
    connections that are subject to the given policy (just like
    LIMIT:BURST). The limit is checked on new connections before the
    connection is passed through the rules in the NEW section of the
    rules file.

    It is important to note that while the limit is only checked for
    those destinations specified in the DEST column, the number of
    current connections is calculated over all destinations and not
    just the destination specified in the DEST column.

    Use of this feature requires the connlimit match capability in your
    kernel and iptables. If you use a capabilities file when compiling
    your Shorewall configuration(s), then you need to regenerate the
    file using Shorewall or Shorewall-lite 4.2.1.

2)  Shorewall now supports time/date restrictions on entries in the 
    rules file via a new TIME column.

    The contents of this column is a series of one or more "time
    elements" separated by apersands ("&"). Possible time elements are:

    utc         Times are expressed in Greenwich Mean Time.
    localtz     Times are expressed in local civil time (default)
    timestart=hh:mm[:ss]
    timestop=hh:mm[:ss]   Start and stop time of day for rule
    weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or
                          Sun
    monthdays=dd[,dd]...  where dd is an ordinal day of the month.
    datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
    datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
                          where       yyyy = Year
                                first mm   = Month
                                      dd   = Day
                                      hh   = Hour
                                  2nd mm   = Minute
                                      ss   = Second

    Examples:

    1)  utc&timestart=10:00&timestop=12:00

        Between 10am and 12 noon each day, GMT

    2)  datestart=2008-11-01T12:00

        Beginning November 1, 2008 at noon LCT.

    Use of this feature requires the time match capability in your
    kernel and iptables. If you use a capabilities file when compiling
    your Shorewall configuration(s), then you need to regenerate the
    file using Shorewall or Shorewall-lite 4.2.1.