ipset -R

When I execute 'ipset -R < some_file' ipset ignores lines with the '-D' option specified. Is that intentional?

I am trying to execute a script file creating 'pinholes' in (previously built) ipsets, but, as it stands, I have to execute a shell script containing 'ipset -D' for every pinhole/range I am interested in, which isn't very convenient. Ideally I'd like for ipset to honour the '-D' option in a restore file.

The reason I need this is because I am defining ipset ranges coming from the geoip database and later, with the '-D' option in a script, I am trying to create the pinholes - more convenient since ipset has a very nice feature to re-adjust the ipset ranges automatically after delete, instead of me using endless '-A' statements adding the resulting ipset sub-ranges.

The iptreemap type of ipset 4.x had the feature you are referring here.

The iptree and iptreemap types are not implemented in ipset 5.x. However you can achieve the same effect by using two sets, the first one for the pinholes and the second one for the networks.

Quoted 7 lines

The iptreemap type of ipset 4.x had the feature you are referring here.

The iptree and iptreemap types are not implemented in ipset 5.x. However you can achieve the same effect by using two sets, the first one for the pinholes and the second one for the networks.

It would be a bit cumbersome to achieve that.

I use the geoip database to construct, among other things, a permanent block lists (mainly based on country of origin, but there are other factors which I won't go in here) and these sets are only present in my block chains (there is also a bit of logic involved, but that is another set of issues altogether). I also have a separate list with host ip addresses/ranges (my 'whitelist' so to speak) against which I subsequently execute the delete statements to create the pinholes (another useful ipset feature is that it silently ignores delete requests if the ip address/range is not present in the set).

As you know the geoip database regularly changes (so does, albeit occasionally, the country of origin of various ip address ranges), so I normally execute an automated set of scripts to update the database, pick the right address ranges for blocking, construct-and-replace my ipsets in the 3 or so blocking chains I have on the main firewall and then apply the deletion statements to the same sets to create the pinholes.

The problem I see with your approach above is that I would have to explicitly grant some sort of access to my 'whitelist' addresses (those with which I create the pinholes), which isn't possible as I do not know which ports (or port ranges) would need to be enabled - that depends on various factors which I cannot always control. Besides, I would like the 'whitelist' addresses to be traversed further down the ip chain as there may be other rules which catch them. In other words, I cannot explicitly allow access to the whitelist addresses as you are suggesting above (so is my understanding).

The ideal scenario, as I pointed out above, would be to use the whitelist to create the pinholes (i.e. execute a deletion against already registered sets) without explicitly allowing access to those ip addresses/ranges.

Another pretty good alternative would be (if I am, somehow, able) to 'subtract' my whitelist members from the blacklisted ones and then use the resulting set (or sets), but as far as I know I can't do that in ipset, can I?

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

What if:

-m set ! --match-set $WHITELIST src -m set --match-set $BLACKLIST src -j DROP

The first -m set (with the "!") punches 'holes' into the 2nd. You can follow up with

-m set --match-set $WHITELIST src -j ACCEPT

Rgds,

Quoted 47 lines · Mr Dash Four

Quoted 7 lines

The iptreemap type of ipset 4.x had the feature you are referring here.

The iptree and iptreemap types are not implemented in ipset 5.x. However you can achieve the same effect by using two sets, the first one for the pinholes and the second one for the networks.

It would be a bit cumbersome to achieve that.

I use the geoip database to construct, among other things, a permanent block lists (mainly based on country of origin, but there are other factors which I won't go in here) and these sets are only present in my block chains (there is also a bit of logic involved, but that is another set of issues altogether). I also have a separate list with host ip addresses/ranges (my 'whitelist' so to speak) against which I subsequently execute the delete statements to create the pinholes (another useful ipset feature is that it silently ignores delete requests if the ip address/range is not present in the set).

As you know the geoip database regularly changes (so does, albeit occasionally, the country of origin of various ip address ranges), so I normally execute an automated set of scripts to update the database, pick the right address ranges for blocking, construct-and-replace my ipsets in the 3 or so blocking chains I have on the main firewall and then apply the deletion statements to the same sets to create the pinholes.

The problem I see with your approach above is that I would have to explicitly grant some sort of access to my 'whitelist' addresses (those with which I create the pinholes), which isn't possible as I do not know which ports (or port ranges) would need to be enabled - that depends on various factors which I cannot always control. Besides, I would like the 'whitelist' addresses to be traversed further down the ip chain as there may be other rules which catch them. In other words, I cannot explicitly allow access to the whitelist addresses as you are suggesting above (so is my understanding).

The ideal scenario, as I pointed out above, would be to use the whitelist to create the pinholes (i.e. execute a deletion against already registered sets) without explicitly allowing access to those ip addresses/ranges.

Another pretty good alternative would be (if I am, somehow, able) to 'subtract' my whitelist members from the blacklisted ones and then use the resulting set (or sets), but as far as I know I can't do that in ipset, can I?

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
--
Pandu E Poluan - IT Optimizer
My website: http://pandu.poluan.info/

What if:

-m set ! --match-set $WHITELIST src -m set --match-set $BLACKLIST src -j DROP

-m set --match-set $WHITELIST src -j ACCEPT

Jozsef, you mentioned yesterday that ipset 5.x (and I presume 6.0+ also) does not implement ip range 'readjustment' any more. If so, what happens when I list the set below:

ipset -F test
ipset -A test 10.1.1.0/24
ipset -D test 10.1.1.12
ipset -L test

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

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.

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.

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 3 lines

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):

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.

Quoted 9 lines

Quoted 9 lines

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

Quoted 5 lines

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.

10.1.1.12/32 is not an explicit member of the set above, therefore you cannot delete it.

At testing elements, the host addresses are a special case and checked from the kernel point of view. So *testing* 10.1.1.12 returns a true value. The reason for the exception is that the kernel at matching, deleting, adding entries works on host addresses and that way one can check the kernel view of the set from userspace.

Quoted 11 lines

Quoted 11 lines

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.

Quoted 4 lines

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'?

Not implemented, just thinking. If the feature were implemented then the testing in the set would return false for 10.1.1.12 and true for every other element from 10.1.1.0/24.

With first case you spare the iptables rules and the matchings in "whitelist".

Quoted 7 lines

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)?

No copying whatsoever: the member sets are referenced and pointed to. Please note, you cannot delete the member sets, however you can swap them anytime with another, same type of set.

Quoted 4 lines

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.

Quoted 15 lines

Quoted 14 lines

Quoted 7 lines

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.

Quoted 3 lines

10.1.1.12/32 is not an explicit member of the set above, therefore you cannot delete it.

Right, so the error message should probably say "Element cannot be deleted from the set: it's not *explicitly* added" as this makes it more clear as the element in question is clearly added, though implicitly, via the 10.1.1.0/24 route.

I know this might be interpreted as 'just semantics', but it would avoid any type of confusion and would have spared me the typing trying to ask for clarify as to what the above error message means.

Quoted 6 lines

At testing elements, the host addresses are a special case and checked from the kernel point of view. So *testing* 10.1.1.12 returns a true value. The reason for the exception is that the kernel at matching, deleting, adding entries works on host addresses and that way one can check the kernel view of the set from userspace.

I take it that was done differently in the same kernel modules for ipset 4.x, right?

Quoted 17 lines

Quoted 16 lines

Quoted 11 lines

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'?

Quoted 4 lines

Not implemented, just thinking. If the feature were implemented then the testing in the set would return false for 10.1.1.12 and true for every other element from 10.1.1.0/24.

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'?

Quoted 3 lines

With first case you spare the iptables rules and the matchings in "whitelist".

And, presumably, improve performance, right?

Quoted 7 lines

Quoted 6 lines

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)?

Quoted 4 lines

No copying whatsoever: the member sets are referenced and pointed to. Please note, you cannot delete the member sets, however you can swap them anytime with another, same type of set.

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?

Quoted 5 lines

Quoted 5 lines

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.

You didn't clarify this point - can I have different type sub-sets as part of a list set or do they have to be of the same type?

Quoted 6 lines

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

Quoted 5 lines

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.

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.

Quoted 8 lines

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.

Quoted 2 lines

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.

Quoted 8 lines

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):

(quoted diff) +0 -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.

I haven't perused netfilter code yet, so what I'll say is highly conjectural.

IMO, the single (1) rule will be a lot faster:
* Only 1 (one) check for whitelist
* x checks for blacklist-checks

Total checks (worst-case): 1+x (and if the negated result of whitelist check == false, no need for x blacklist-checks)

Best case: 1 check ( IP in whitelist, so ! whitelist == false, iptables' rule is short-circuited )

Rule (2):
* A total of x times ( whitelist check + blacklist-check )

Total checks (worst-case): x * 2

Best case: x * 1 ( only check against whitelist, but repeated for x rules )

IMO, iptables lookups are much more expensive than ipset lookups. ( IOW, n * iptables checks is much more expensive than 1 * iptables check against a setlist with n members ). So, the speedup of (1) against (2) will be even more significant.