> Okay -- then let's do this: > > a) Add DropSmurfs and TCPFlags actions that do the same thing as the > interface options 'nosmurfs' and 'TCPFlags' respectively. > b) Simply put your blacklist entries in the ALL section of the rules file. > > This way, you can have dozens of blacklists and invoke them as appropriate. > > You would implement each blacklist as an action, so that CONTINUE would work > like 'whitelist'. > > After all blacklist/whitelist processing, you could invoke DropSmurfs and/or > TCPFlags if desired. > > We don't need a 'maclist' action since maclist processing can be trivially > implemented in rules already. > I don't see why I should be mixing up blacklist/whitelist entries with what I have implemented in the rules file, let alone messing up with unnecessary actions, CONTINUEs and the like. For what? Who is going to maintain that - you, perhaps?
We've been through this before, haven't we - if you can't be arsed implementing a proper blacklist, then why didn't you just say so from the beginning (it is perfectly OK!), so that I don't continue wasting my time making "complex" requests or ask "difficult" questions? ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
