>>> 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?
------------------------------------------------------------------------------ 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
