On Sep 29, 2011, at 3:12 PM, Mr Dash Four wrote:
>
>> 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?
Yes. Traditionally, blacklisting has been done ahead of interface filters such
as tcpflags, surfs, etc. 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.
>
>> 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?
Yes -- and it's all done currently in generate_matrix().
>
> 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.
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.
>
> 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.
That's because your viewpoint is very restricted.
> 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.
-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 \________________________________________________
------------------------------------------------------------------------------
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
