On 9/16/10 4:24 PM, Mr Dash Four wrote: > >> 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.
That's the plan. > >> 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. It's a consequence of the order in which the ruleset is constructed. Interface-oriented filtering is generated well before zone-oriented filtering. During optimization, interface-oriented filtering can be moved to the front of a zone-oriented chain. It's something that could be overcome but it's not trivial. -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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
