As I announced yesterday on the Development List, I've concluded that the direction in which blacklisting has been going since 4.4.12 is not appropriate. The current plan for 4.4.13 is to return blacklisting to the way it was in 4.4.11; basically, support for the OPTIONS column will be removed.
As I've thought more about this issue, I have realized that the
fundamental problem with extending the 4.4.11 support is that while
blacklisting is a security-related concept, in 4.4.11 and earlier
blacklisting support has been associated with interfaces or host groups.
A much more natural approach is to associate blacklisting with zones.
I have prototyped the following proposal and it seems to work correctly.
1) The OPTIONS column of the blacklist file will be restored to the way
that it has been in the recent 4.4.13 Betas. The preferred keywords
are 'src' and 'dst' rather than 'from' and 'to' although the latter
would also be supported. Duplicates ignored with a warning.
1) Allow 'blacklist' in the OPTIONS, IN_OPTIONS and OUT_OPTIONS columns
of the zones file.
Specifying 'blacklist' in OPTIONS, is equivalent to specifying
it in both IN_OPTIONS and OUT_OPTIONS.
No warning if 'blacklist' appears in OPTIONS as well as in one
of the other columns.
2) 'blacklist' in the IN_OPTIONS column indicates that all traffic from
this zone should be passed against the 'src' entries in the
blacklist file.
3) 'blacklist' in the OUT_OPTIONS column indicates that traffic to this
zone should be passed against the 'dst' entries in the blacklist
file.
4) In the interfaces file:
If 'blacklist' is specified with no ZONE, a warning is given
and the option is ignored.
If 'blacklist' is specified with a ZONE, it is equivalent to
specifying 'blacklist' in the IN_OPTIONS column of the
corresponding entry in the zones file.
Currently, incoming blacklisting is performed as a first step
on incoming packets on those interfaces having the 'blacklist'
option. With the new approach, blacklisting would occur after
the packet has been processed against the interface-related
options such as 'nosmurfs', 'tcpflags', etc.
5) In the hosts file, the 'blacklist' option will be ignored with a
warning.
Comments and suggestions are welcome.
-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: OpenPGP digital signature
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
