On Fri, 2011-09-30 at 11:43 +0100, Mr Dash Four wrote: > > Yes. Traditionally, blacklisting has been done ahead of interface filters > > such as tcpflags, surfs, etc. > And this is absolutely right - nothing should come before blacklisting. > > > Given that all 'src' blacklists are the same currently, a jump to the > > 'blacklst' chain can simply be moved to the interface input and forward > > chains. That isn't possible when there are multiple such blacklist rulesets. > > > Why not? To use my example, the first rule (and jump) in the fw2vpn > chain is to a separately-created chain called "blackout". Granted, this > chain is "shared" among all fw2XX chains, but I can't see why would that > be any different if that jump is to a separate chain called, say, > vpn_blackout? In my "start" file, for that chain I have done exactly > that and I have been running this configuration successfully for quite > some time.
I assume, then, that you have no interfaces that support multiple zones. In that case, the jumps for checking tcpflags, smurfs, etc. are in the interface input and forward chains; the jumps to the blacklst chain are promoted from the zone-specific chains to the interface chains. Again, that works now because there is only one blacklst chain. > > >> > > All of that makes me think again of the rules file. My problem is that if > > these rules are placed in the rules file, they will come after tcpflags, > > surfs, etc. > > > I take it the only reason that blacklist statements/rules may be placed > (in iptables) after tcpflags etc is because of the time shorewall > processes the "rules" file, right? If that is the case, then I'd leave > them in the blacklist file - nothing should come before blacklist > processing! > > I agree though, this "new" format is emerging to be similar to the rules > file where the "ACTION" column would consists of either "BLACKLIST" or > "WHITELIST", though I am not sure how would you process the "NEW", > "ESTABLISHED" and "RELATED" sections if they were to contain > blacklist/whitelist statements (that is provided the blacklist > statements go into the "rules" file, which I am not sure is wise). The question of what to do about the sections is indeed a stumbling block to adding BLACKLIST and WHITELIST statements to the rules file. Which is what I really prefer to do. > > >> When > >> shorewall parses the blacklist file it generate rules for each > >> individual chain which has the "blacklist" option specified. > >> > >> 3. Scans for the "whitelist" option to determine the nature of the entry > >> - "DROP" if there isn't a "whitelist" option specified, "RETURN" if it is. > >> > >> 4. Generates the iptables code needed to be inserted later. > >> > >> One thing I did not account for here is inter-zone blacklists (say > >> vpn2net etc), but to my knowledge this is not currently implemented in > >> shorewall is it? If you do plan implementing that at a later stage, then > >> you may wish to scrap "src" and "dst" options and introduce two separate > >> columns for "SOURCE" and "DESTINATION" so that you determine where this > >> blacklist entry goes to - in a similar fashion as shorewall currently > >> does with the "rules" file. > >> > > > > I frankly wish I had taken a different approach when you talked me into the > > last set of blacklist changes. I don't want to compound that felony. > > > I still can't see what the problem is? I mean, really, instead of > lumping all blacklisted statements into two shorewall-created chains > (blacklst and blackout) you will do it in separate, zone-independent > ones, and all the jumps to blacklst and blackout would be to > <zone>_blacklst and <zone>_blackout instead. Why is that not possible to > implement? Am I missing something obvious here? See my first comment above. Do you *really* need a zone name in the blacklist file, or would specifying an interface meet your needs? -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: This is a digitally signed message part
------------------------------------------------------------------------------ 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
