Call be dumb, but I still fail to see what is the sense in implementing the
above, or are you suggesting that the above would create a pinhole with the
"--nomatch" option instead of deleting the element itself and therefore remove
the need for a 'whitelist'?
Yes, that is what I'm thinking. One could just punch holes into networks,
even stacked, i.e.
ipset -A test 10.1.1.0/24
ipset -A test 10.1.1.64/26 --nomatch
ipset -A test 10.1.1.80/28
would mean a match for the elements in the inclusive ranges
10.1.1.0-10.1.1.63,10.1.1.80-10.1.1.95,10.1.1.128-10.1.1.255
I see! Yes, I think that is a very good idea (you could also introduce a
separate ipset option to only list '--nomatch' elements, something like
'ipset -L --nomatch test' for example), though I have to admit I am
coming round to the idea of using my whitelist as a separate set - I
think this is a much cleaner solution and it also gives me a greater
deal of flexibility as I can easily see the whitelist members and employ
them freely anywhere in the ip chains.
Please clarify - can I remove elements of a set, i.e. execute "ipset -D
blacklist-2 <blacklist-2 member(s)>", if blacklist-2 is part (i.e. a member)
of a list set called blacklist-all, or do you mean that I cannot remove
blacklist-2 from blacklist-all once added?
You can add, delete, even flush the entries from a member set, that's not
problem. But it's not possible to delete the set while it's the member of
another set.
Makes perfect sense. I also take it since the subsets are referenced as
soon as a particular subset is changed that change is 'automatically'
applied to every list set this subset belongs to, right?
Yes, you can have different types as subsets, even different dimensions of
set types. But the dimension of the matching plays an important role: lets
assume you have got the following sets
ipset create a hash:ip,port,ip
ipset create b hash:ip,port
ipset create c hash:ip
ipset create d list:set
ispet add d a
ipset add d b
ipset add d c
then when called from the rule
-m set --match-set d dst,dst
then the first subset "a" is always skipped, because the matching
dimension is smaller than the dimension of the set.
However if you have got the rule
-m set --match-set d dst,dst,src
then all subsets are tried in order until a match is found.
That's brilliant - I avoided using list sets as, to be honest, I was
unclear as to how the matching is performed (particularly with different
subset types), but the above clarifies matters for me completely.
Have you considered using the subsets in a given list set as a
mathematical entities and applying the usual (mathematical) set
operations (like intersection, union, complement etc)? Currently, you
are applying a union of all subsets when they are registered in a list
set, but this could be expanded as I see the list set as a potentially
very powerful tool.
For example I could define the whitelist as a set and then register it
together with all of my blacklist-x in a new list set and then say
'apply (blacklist-1 + blacklist-2 + ... blacklist-x) - whitelist' (in
other words, build a union of all blacklist-x subsets and then subtract
the whitelist subset from that resulting union). I don't know how easy
this would be to implement though!
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
