Beta 1 is now available for testing. New feature in this release:
1) The original static blacklisting implementation was
interface-oriented and only handled blacklisting by source
address. In Shorewall 4.4.12, the ability to blacklist by source
address was added and blacklisting could be specified as a ZONE
option. This change, plus additional changes in subsequent releases
has lead to an implementation that is complex and hard to extend.
In this release, a new static blacklisting facility has been
implemented. This facility is separate from the legacy facility, so
existing configurations will continue to work without change.
A BLACKLIST section has been added to the rules file. This section
is now the first section, having been added ahead of the ALL
section. The set of packets that are subject to blacklisting is
still governed by the setting of BLACKLISTNEWONLY in
shorewall.conf. The settings of BLACKLIST_LOGLEVEL and
BLACKLIST_DISPOSITION are not relevant to the new implementation.
Most of the actions available in other sections of the rules file
are available in the BLACKLIST section and logging is specified on
a rule-by-rule basis in the normal way.
In addition to the other actions available, a WHITELIST action has
been added which exempts matching packets from being passed to the
remaining rules in the section.
Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has
a companion blacklisting chain. The name of the blacklisting chain
is formed by appending "~" to the zone2zone chain. For example,
'net2fw' blacklist rules appear in the chain net2fw~.
There is a likelihood that multiple blacklisting chains will have
exactly the same rules. This is especially true when 'all' is used
as the zone name in the SOURCE and/or DEST columns. When
optimization level 8 is used, these identical chains are combined
into a single chain with the name ~blacklistN, where N is a number
(possibly with multiple digits).
The 'nosurfs' and 'tcpflags' interface options generate rules that
will be traversed prior to those in the BLACKLIST section. If you
want similar rules to be travered on packets that were not dropped
or rejected in the BLACKLIST chain, you can use the new
'DropSmurfs' and/or 'TCPFlags' standard actions.
The DropSmurfs action has a single parameter whose default value
is '-'. The action silently drops smurfs without auditing. If you
want to audit these drops, use DropSmurfs(audit). Logging can be
specified in the normal way (e.g., DropSmurfs:info).
The TCPFlags action has two parameters whose default values are
DROP and -. The first action determines what is to be done with
matching packets and can have the values DROP, REJECT or ACCEPT. If
you want the action to be audited, pass 'audit' in the second
parameter.
Example: TCPFlags(REJECT,audit)
Again, logging is specified in the normal way.
The 'maclist' interface option can also generate rules that are
traversed prior to those in the BLACKLIST section. If you want them
to come after the the blacklist rules, simply recode your maclist
rules in the NEW section of the rules file. The 'macipmap' ipset
type is ideally suited for this task.
Example: assumes the ipset name is macipmap and that the
zone to be verified is named wlan
/etc/shorewall/rules:
SECTION NEW
DROP:info wlan:!+macipmap all
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 \________________________________________________
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
