Tom Eastep
2017-01-24 23:04:48 UTC
Shorewall 5.1.1 RC 1 is now available for testing.
Problems Corrected since Beta 2:
2) Previously, expanded variables would be enclosed in single quotes
in ?ERROR, ?WARNING and ?INFO directive output. That has been
corrected.
3) The obsolete Drop and Reject macros have been removed (Drop and
Reject are now actions rather than macros).
4) A typo has been corrected in the parameter descriptions in
action.Drop and action.Reject.
New Features since Beta 2:
1) The effective setting of USE_DEFAULT_RT is now the default value
for BALANCE_PROVIDERS.
2) When using ipset-based dynamic blacklisting, it is now possible to
specify BLACKLIST in the POLICY column of policy files. When
BLACKLIST is specified, the source IP address is automatically
added to the dynamic blacklist ipset and then the packet is
dropped. This new policy adds BLACKLIST_DEFAULT to
shorewall[6].conf; the default setting is "Drop".
3) A BLACKLIST action has been added; the action adds the sender to
the dynamic blacklist IPSET.
BLACKLIST accepts two optional argument:
1 - Action to take after adding the sender to the ipset. Default is
DROP.
2 - specifies the timeout for the added/updated entry.
If no timeout is passed, the one specified in
DYNAMIC_BLACKLIST, if any, is used. Otherwise, the one specified
when the ipset was created, if any, is used.
4) Given that there was already a BLACKLIST macro which implemented
the BLACKLIST action in blrules, the preceding change required that
BLACKLIST behave differently when invoked from the blrules file and
when invoked from the rules file. Because BLACKLIST invoked from
the rules file normally generates two rules, an action (not
inlined) is more appropriate there than is a macro. When it is
invoked from the blrules file, it only generates a single rule so
the optimizer will inline it anyway.
For historical reasons, the compiler treats the blrules file as if
it were the section BLACKLIST in the rules file. So, to implement
this dual behavior in the BLACKLIST action, a new 'section' option
has been added in the action file. When 'section' is specified, the
name of the current section and a comma are prepended to the
argument list passed when invoking the action. The action.BLACKLIST
file then has the following structure:
?if @1 eq 'BLACKLIST'
<logic to generate rule from the blrules file>
?else
<logic to generate rules from the rules file>
?endif
5) There is now a 'show action <action>' command for Shorewall and
Shorewall6. The command displays the action file for the specified
<action>.
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 \________________________________________________
Problems Corrected since Beta 2:
2) Previously, expanded variables would be enclosed in single quotes
in ?ERROR, ?WARNING and ?INFO directive output. That has been
corrected.
3) The obsolete Drop and Reject macros have been removed (Drop and
Reject are now actions rather than macros).
4) A typo has been corrected in the parameter descriptions in
action.Drop and action.Reject.
New Features since Beta 2:
1) The effective setting of USE_DEFAULT_RT is now the default value
for BALANCE_PROVIDERS.
2) When using ipset-based dynamic blacklisting, it is now possible to
specify BLACKLIST in the POLICY column of policy files. When
BLACKLIST is specified, the source IP address is automatically
added to the dynamic blacklist ipset and then the packet is
dropped. This new policy adds BLACKLIST_DEFAULT to
shorewall[6].conf; the default setting is "Drop".
3) A BLACKLIST action has been added; the action adds the sender to
the dynamic blacklist IPSET.
BLACKLIST accepts two optional argument:
1 - Action to take after adding the sender to the ipset. Default is
DROP.
2 - specifies the timeout for the added/updated entry.
If no timeout is passed, the one specified in
DYNAMIC_BLACKLIST, if any, is used. Otherwise, the one specified
when the ipset was created, if any, is used.
4) Given that there was already a BLACKLIST macro which implemented
the BLACKLIST action in blrules, the preceding change required that
BLACKLIST behave differently when invoked from the blrules file and
when invoked from the rules file. Because BLACKLIST invoked from
the rules file normally generates two rules, an action (not
inlined) is more appropriate there than is a macro. When it is
invoked from the blrules file, it only generates a single rule so
the optimizer will inline it anyway.
For historical reasons, the compiler treats the blrules file as if
it were the section BLACKLIST in the rules file. So, to implement
this dual behavior in the BLACKLIST action, a new 'section' option
has been added in the action file. When 'section' is specified, the
name of the current section and a comma are prepended to the
argument list passed when invoking the action. The action.BLACKLIST
file then has the following structure:
?if @1 eq 'BLACKLIST'
<logic to generate rule from the blrules file>
?else
<logic to generate rules from the rules file>
?endif
5) There is now a 'show action <action>' command for Shorewall and
Shorewall6. The command displays the action file for the specified
<action>.
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 \________________________________________________