Re: ipset -R

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




What if:

-m set ! --match-set $WHITELIST src -m set --match-set $BLACKLIST src -j DROP
Yeah, never thought of that before, thanks, though this would increase processing time as I have to include that extra 'whitelist' non-match in every iptables '--match-set' statement I have where my blacklist sets are involved (and I have quite a lot of them!). It would be better if I just delete the whitelist members permanently once at the beginning and just forget about it (though as Jozsef hinted yesterday that may not work in 5.x and 6 any more - see below).

The second statement (in both of your posts) won't be needed as I simply propagate the resulting non-match throughout the ip chain (the packets therefore could be dropped for a variety of other reasons regardless of whether they belong to the 'whitelist' or not, which is what I wanted to have in a first place).

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

-m set --match-set $WHITELIST src -j ACCEPT
That won't be needed as I simply want the packet to be propagated down the ip chain as normal (the packet could be dropped for other reasons and the fact that it belongs to the whitelist won't matter - its sole purpose is for punching holes in my blacklist, then it should be treated as any other packet).

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


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux