ipset "contains" question

ipset "contains" question

[Ed W]

Hi Jozsef,

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?

Thanks for any tips?

Ed W

Re: ipset "contains" question

[Jozsef Kadlecsik]

Hi,

On Mon, 25 Jul 2011, Ed W wrote:

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

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

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset "contains" question

[Ed W]

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

Re: ipset "contains" question

[Jozsef Kadlecsik]

On Tue, 26 Jul 2011, Ed W wrote:

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

You can add rules which allow the unauthenticated traffic, because 
the destination is well defined: the DHCP server, web server, etc.
 
> (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?

There's a strict input checking in ipset core, which does not allow to 
call the set types with insufficient data. That disables "looking up" just 
the IP address in a bitmap:ip,mac type. Accidentally, it *could* be 
relaxed for the bitmap types, but that'd require adding an exception to 
the core, and adding a new handler code to the type functions.
 
> 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..?)

ipset is not a general solution, which replaces everything else :-).
The mark values are already stored in the skbuff, so there's no point in 
storing them again; for flow rates, time you have other matches.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary