Beta 3 is now available for testing.

Summary of Beta 3:

----------------------------------------------------------------------------
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E
----------------------------------------------------------------------------

All bug fixes from 4.4.19.1 - 4.4.19.4.

----------------------------------------------------------------------------
           I I.  K N O W N   P R O B L E M S   R E M A I N I N G
----------------------------------------------------------------------------

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

----------------------------------------------------------------------------
      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E
----------------------------------------------------------------------------

1)  The implementation of the environmental variables LIBEXEC and
    PERLLIB that was introduced in 4.4.19 has been changed
    slightly. The installers now allow absolute path names to be
    supplied so that the executables and/or Perl modules may be
    installed under a top-level directory other than /usr. The change
    is compatible with 4.4.19 in that if a relative path name is
    supplied, then '/usr/' is prepended to the name.

2)  A new ACCOUNTING_TABLE option has been added to shorewall.conf and
    shorwall6.conf. The setting determines the Netfilter table (filter
    or mangle) where accounting rules are created.

    When ACCOUNTING_TABLE=mangle, the allowable sections in the
    accounting file are as follows:

        PREROUTING
        INPUT
        OUTPUT
        FORWARD
        POSTROUTING

    Present sections must appear in that order.

3)  An NFLOG 'ACTION' has been added to the accounting file to allow
    sending matching packets (or the leading part of them) to backend
    accounting daemons via a netlink socket.

4)  A 'whitelist' option has been added to the blacklist file. When
    'whitelist' is specified, packets/connections matching the entry
    are not matched against the entries which follow. No logging of
    whitelisted packets/connections is performed.

5)  Support for the AUDIT target has been added. AUDIT is a feature of
    the 2.6.39 kernel and iptables 1.4.10 that allows security auditing
    of access decisions.

    The support involves the following:

    a)  A new "AUDIT Target" capability is added and is required for
        auditing support. To use AUDIT support with a capabilities
        file, that file must be generated using this or a later
        release.

        Use 'shorewall show capabilities' after installing this release
        to see if your kernel/iptables support the AUDIT target.

    b)  In /etc/shorewall/policy's POLICY column, the policy (and
        default action, if any) may be followed by ':audit' to cause
        application of the policy to be audited.

        Only ACCEPT, DROP and REJECT policies may be audited.

        Example:

        #SOURCE DEST    POLICY          LOG
        #                               LEVEL
        net     fw      DROP:audit

        It is allowed to also specify a log level on audited policies
        resulting in both auditing and logging.

    c)  Three new builtin actions that may be used in the rules file,
        in macros and in other actions.

        A_ACCEPT - Audits and accepts the connection request
        A_DROP   - Audits and drops the connection request
        A_REJECT - Audits and rejects

        A log level may be supplied with these actions to
        provide both auditing and logging.

        Example:

        A_ACCEPT:info   loc     net     ...

    d)  The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION and
        TCP_FLAGS_DISPOSITION options may be set as follows:

        BLACKLIST_DISPOSITION         A_DROP or A_REJECT
        MACLIST_DISPOSITION           A_DROP 
                                      A_REJECT, unless
                                               MACLIST_TABLE=mangle
        TCP_FLAGS_DISPOSITION         A_DROP or A_REJECT

    e)  A SMURF_DISPOSITION option has been added to
        shorewall.conf. The default value is DROP; if the option is set
        to A_DROP, then dropped smurfs are audited.

    f)  An 'audit' option has been added to the
        /etc/shorewall/blacklist file which causes the packets matching
        the entryto be audited. 'audit' may not be specified together
        with 'accept'.

    g)  The builtin actions (dropBroadcast, rejNonSyn, etc.) now support
        an 'audit' parameter which causes all ACCEPT, DROP and REJECTs
        performed by the action to be audited. This allows creation of
        audited versions of the Shorewall-provided default actions
        (action.Drop and action.Reject).

        Note: The builtin actions are those actions listed in the
        output of 'shorewall show actions' whose names begin with a
        lower-case letter.

Thank you for testing,
-Tom

Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________


Attachment: PGP.sig
Description: This is a digitally signed message part

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel

Reply via email to