> 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 concur! Also, you could always add support (if it doesn't already exist - I am no Shorewall expert) to include individual interfaces from each zone, like "net:eth1" for example.
> 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. > Makes sense and it was the way I preferred - it makes it consistent with the rest (rules etc). > 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. > So, if I specify 'blacklist' in my net zone then it would automatically be bidirectional provided I have "+backlist-nets src,dst" in my blacklist file, right? If so, that would be perfect. > 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. > Is there any reason for this? For me it would not make sense to do ANY processing (ddos etc) if this packet is/has failed the blacklist test. ------------------------------------------------------------------------------ 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
