> Today, if you don't specify a zone, then it means 'all zones'. So if my
> blacklist has three 'all' entries followed by one for zone 'z', followed
> by three more 'all' entries, I would presume that you would want the 7
> entries applied in sequence for zone 'z', would you not?
Yes, that's right - I see what you mean now, but see below.
> So, in effect,
> that means that every zone might need two blacklist chains - one for
> 'src' and one for 'dst'.
>
Yes, that is correct - would this be a problem for shorewall?
> It is way too ugly to generate the code for a zone test inside of the
> blacklist chains because zones can be rather complicated things.
You are doing this even now - shorewall inserts "blacklst" chain in all
zones with the blacklist option and if there is also at least one entry
present with the "src" option. Similarly, shorewall inserts a "blackout"
chain for each zone with "blacklist" option where there is at least one
entry with "dst" option specified, isn't that the case?
Granted, with the new arrangement there may be 2 blacklist chains for
each defined zone, but why is that a problem for shorewall? I see it as
a benefit, because one could trace blacklisted packets for each
individual zone (and do the appropriate accounting, if needed) instead
of having them lumped together as is the case now, wouldn't you agree?
> The
> code to do that is implemented in the function
> Shorewall::Misc::generate_matrix() and close friends and I want to keep
> it that way. That means that 'all-zone' blacklist rules need to be
> inserted into each appropriate 'zX2zY' chain with the zone-specific
> rules interspersed among them.
>
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.
What shorewall does now is it uses a single blacklst and blackout chains
where all rules in the blacklist file are generated. I don't see a
problem if each zone has its own blacklst and blackout chains. 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.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
