All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: "'netfilter@vger.kernel.org'" <netfilter@vger.kernel.org>
Subject: Re: ipset -R
Date: Wed, 23 Feb 2011 22:58:10 +0000	[thread overview]
Message-ID: <4D659102.8090501@googlemail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1102232009001.16917@blackhole.kfki.hu>


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


  reply	other threads:[~2011-02-23 22:58 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 [this message]
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
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=4D659102.8090501@googlemail.com \
    --to=mr.dash.four@googlemail.com \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=netfilter@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.