> 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.
>> Yes and no. When a zone is specified - either as a column entry (come to
>> think of it, I think this might be a better way, otherwise someone may
>> specify more than one zone by mistake. It will also help if you wish to
>> expand the blacklist to cover inter-zonal blacklisting at a later
>> stage), or in the options section, shorewall then:
>>
>> 1. Does some basic sanity checks to see whether that zone contains the
>> "blacklist" option (either issue a warning and ignore the whole line or
>> an error and stop processing);
>>
>> 2. Parses the "src", "dst" and, optionally the zone options, to figure
>> out which direction - and therefore chain - this entry must go to. In
>> other words, if it is "src,dst,vpn" then there need to be 2 entries
>> generated - one for vpn2fw's *own* "blacklst" chain (you can call it,
>> say, "vpn_blacklst") and one for fw2vpn's *own* "blackout" chain (say
>> "vpn_blackout").
>>
>> Alternatively, there could be a separate column for the zone - this will
>> prevent users from specifying more than one ("src,dst,vpn,net" for
>> example) if this is going to mess up the parsing. If there is no zone
>> specified, then, as you rightly pointed out, "all" is assumed and this
>> entry gets generated for all applicable "<zone>_blacklst" and
>> "<zone>_blackout" chains where the "blacklist" option for those zones is
>> specified.
>>
>
> 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).
>> 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?
------------------------------------------------------------------------------
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
