All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed W <lists@wildgooses.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: ipset "contains" question
Date: Tue, 26 Jul 2011 11:24:21 +0100	[thread overview]
Message-ID: <4E2E95D5.1040408@wildgooses.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1107261151210.20945@blackhole.kfki.hu>

Hi

>> Many thanks for ipset.  Quick question please: I'm implementing a
>> captive portal and I have an ipset (CP) containing bitmap:ip,mac.  How
>> should I best implement rules to:
>>
>> - Drop packets from same IP, different MAC
>>
>> I might be missing the obvious, but how do I query to match on IP, then
>> drop IP with a mismatching MAC (in the bitmap ipset)? Can this be done
>> without a second ipset tracking only IP?
> 
> At a first glance I'd allow packets from (IP, MAC) and drop everything 
> else, i.e. (same IP, different MAC) and (different IP, same MAC), etc.

Thanks - I think it's important to separate the traffic, not block it
for my situation. You need to login to the captive portal, so some
traffic needs to flow without being authenticated. I think you can very,
very nearly have a clean split between auth/non auth users, but for
flexibility my idea was to add some specific blocks/drops to classes of
users who were clearly trying to cheat

(And yes I do get that "auth" based on IP/Mac has some significant
limitations...)


> If you want to match the IP address only, too, then a single set is not 
> sufficient, unfortunately.

That's fine.  Do you think it's a sensible feature request that has a
use elsewhere? ie given a bitmap:ip,mac, does it make sense to want to
search it for just IP or Mac?

Additionally it would have been very useful to use an ipset to assign a
packet mark, ie the "result" of an ipset is also stored in the ipset.
Do you think this is a reasonable feature request..? (what other
"parameters" do people want to lookup, flow rates, marks, last seen,
time constraints..?)

Thanks for creating ipsets - very helpful!

Ed W

  reply	other threads:[~2011-07-26 10:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-25 22:25 ipset "contains" question Ed W
2011-07-26  9:55 ` Jozsef Kadlecsik
2011-07-26 10:24   ` Ed W [this message]
2011-07-27  7:17     ` Jozsef Kadlecsik

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=4E2E95D5.1040408@wildgooses.com \
    --to=lists@wildgooses.com \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=netfilter-devel@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.