>> 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. > True (I actually haven't thought of that).
> 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. > What I have is one blacklst and one blackout chains and they are currently "jumped on" by the appropriate fw2XX and XX2fw chains - they are the first statements there before anything else goes, which is what I really wanted. I really don't know how shorewall organises interfaces with multiple zones, but I presume that for each zone there is fw2<zone> and <zone>2fw chain. If that is so, how are the blacklst and blackout chains referred to (or jumped to in iptables' terms) currently (genuine question)? Even if we assume that an interface has multiple zones, then what would be the problem of implementing various <zone>_blacklst and <zone>_blackout chains for that? I initially referred to "zones" as, from my own (probably selfish) perspective, the blacklist chains are the first statements where the zone-related iptables instructions are implemented, thus effectively acting as a first defence no matter what else is defined afterwards (in terms of macros, "rules" file statements, actions etc), which is how it should be. If there is a different way, which is easier to implement in shorewall without compromising this "first-line of defence" scenario (in either directions), then so be it. >> 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. > If you manage to somehow integrate BLACKLIST/WHITELIST statements in the rules file (and that includes the 3 sections mentioned above), then you have to get rid of the BLACKLISTNEWONLY (I think it was called) option in shorewall.conf. It is a bit tricky, because I can see massive duplication of blacklist statements for ESTABLISHED and RELATED (how the hell would I - the average n00b user - know what falls under "RELATED"?), so it is not as clear-cut just adding these two blacklist "ACTIONS" into the rules file. Not to mention that I have no idea how would I have what I currently have in the blacklist chains - every packed is checked regardless of its connection state? I'd rather they were separate - as is now in a "blacklist" file - and if the functionality is the same as in the rules file that would be great. >>> 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? > I am not sure to be honest! Now that you mention it, provided the blacklist chain (in whatever form you decide to change it/implement it to) is the first one to be checked for each interface - in either direction - than I don't really mind that at all, provided blacklist and whitelist functionality remains the same, that is. Are you thinking of dumping the blacklst and blackout chains in the INPUT, OUTPUT and FORWARD chains, filtering out just the interface? If so, that is what I proposed ages ago if you remember, when shorewall had just one blacklst chain and you declined that and opted to do it in the zones instead. ------------------------------------------------------------------------------ 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
