netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Pandu Poluan <pandu@poluan.info>,
	"netfilter@vger.kernel.org" <netfilter@vger.kernel.org>
Subject: Re: ipset -R
Date: Fri, 25 Feb 2011 13:27:08 +0000	[thread overview]
Message-ID: <4D67AE2C.3010902@googlemail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1102250915200.20179@blackhole.kfki.hu>


> However with hash:net type
>
> # ipset -N test hash:net
> # ipset -A test 10.1.1.0/24
> # ipset -D test 10.1.1.12
> ipset v6.0: Element cannot be deleted from the set: it's not added
>   
Well, that's plain wrong, isn't it? The 'element' 10.1.1.12 does exist 
and it is added (albeit implicitly as part of 10.1.1.0/24). I also 
presume 'ipset -T test 10.1.1.12' will return a positive result, so 
there is something which isn't quite right.

> and that's also right, because the hash types do not magically figure out 
> overlapping ranges and collapse those or break up ranges into parts when 
> deleting intersecting elements.
>   
I do not know the reasons for removing this as it was a nice 'feature' 
though I now understand the 'deletion' part even if I do not agree with it.

> The hash:*net* types could be extended to store non-matching elements, 
> something like this:
>
> # ipset -N test hash:net
> # ipset -A test 10.1.1.0/24
> # ipset -A test 10.1.1.12 --nomatch
>
> That way overlapping entries with different "access right" could be stored 
> in a single set. But any coding needs time and testing.
>   
I am not sure I understand the above - is this already implemented (in 
6.0?) or is this on the 'drawing board' so to speak? What do you mean by 
'access right'?

On a separate query relating to my initial post of this thread - Pandu 
Poluan proposed a nice 'get-out-of-jail' solution to my problem, which I 
already found a way to optimise a little, but need to make sure I am 
doing the right thing: if I have my whitelist, blacklist-1, blacklist-2 
... blacklist-x sets registered and they have (quite a lot of) members 
can I then do this:

ipset -N list blacklist-all
ipset -A blacklist-all blacklist-1
...
ipset -A blacklist-all blacklist-x

and then add my iptables statement:

(1) -m set ! --match-set whitelist src -m set --match-set blacklist-all 
src -j DROP

Would that be the equivalent of (2):

-m set ! --match-set whitelist src -m set --match-set blacklist-1 src -j 
DROP
...
-m set ! --match-set whitelist src -m set --match-set blacklist-x src -j 
DROP

In other words, I combine all of my blacklisted sets into one of type 
'list' where I assume 1) that all sub-set elements of the 'list' set are 
queried for a match; and 2) executing one iptables statement with a set 
match/mismatch (i.e. 1 above) is better, performance-wise, than 
(potentially) traversing through multiple iptables statements with a set 
match/mismatch (as shown on 2 above)?

If so, how is the blacklist-all set stored - do you copy all the 
elements of all the sets into a separate memory space or do you just 
reference the set (which means that if I alter, say, blacklist-2, the 
changes are 'automatically' applied to blacklist-all as well)?

I can't combine all elements of my blacklist-x sets into one big one 
because 1) I use separate blacklist-x sets elsewhere in my ip chains; 
and 2) my blacklist-x sets are not of the same type.


  reply	other threads:[~2011-02-25 13:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-23  0:58 ipset -R Mr Dash Four
2011-02-23 19:20 ` Jozsef Kadlecsik
2011-02-23 22:58   ` Mr Dash Four
2011-02-24  0:05     ` Pandu Poluan
2011-02-24  5:16       ` Pandu Poluan
2011-02-24 12:18       ` Mr Dash Four
2011-02-25  8:38         ` Jozsef Kadlecsik
2011-02-25 13:27           ` Mr Dash Four [this message]
2011-02-25 14:06             ` Jozsef Kadlecsik
2011-02-25 16:13               ` Mr Dash Four
2011-02-25 22:22                 ` Jozsef Kadlecsik
2011-02-26 13:35                   ` Mr Dash Four
2011-02-25 14:19             ` Pandu Poluan
2011-02-25 16:27               ` Mr Dash Four

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D67AE2C.3010902@googlemail.com \
    --to=mr.dash.four@googlemail.com \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=netfilter@vger.kernel.org \
    --cc=pandu@poluan.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).