>> Can I specify the zone(s) to which that whitelist applies (vpn in
>> my example above) or is it just user id/owner?
>>
>
> Just userid/owner at this point. To allow zone names, the implementation
> of blacklisting will have to change rather dramatically (no blacklist
> chains at all with the possible exception of 'blacklog').
>
Fair enough, though I am intrigued - what is the cause/obstacle(s) for
not implementing it at this stage? What sort of big change in the
blacklisting needs to happen in order for this to be implemented?
I only used the zone names in my example as I thought together with the
specified direction ("src" or "dst") it gives a "unique" reference as to
where to include the whitelist (or blacklist for that matter, as this
can also be implemented for blacklists as well).
For example, "src,vpn,whitelist" uniquely identifies this, I think, as a
"RETURN" condition in the blackout chain name (or whatever name you
decide to call this) to be included/added in the fw2vpn chain.
Similarly, "src,vpn" would identify a "DROP" condition for the blackout
chain to be included on the fw2vpn chain - the same principle applies. I
am, obviously, simplifying this (and there are probably more complex
scenarios than that), but this is to clarify that the inclusion of a
zone name is only for the purpose of identifying where this
whitelist/blacklist condition goes. If there is another - easier - way,
that so be it.
------------------------------------------------------------------------------
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
