On 9/16/10 4:53 PM, Mr Dash Four wrote: > >>>> 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. >> > Bugger! I can see a potential for some really nasty stuff coming from > this. Is there absolutely no chance that the blacklist processing could > be moved forward, somehow?
I don't think that the consequences could be that dire (a blacklisted host could renew its DHCP lease is the only hole I can see), but it is not horribly difficult to remove this restriction. -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
