[isf-wifidog] FirewallRuleSets & User Classes

[Benoit Grégoire]

On Wednesday 02 March 2005 13:48, Scott Tully wrote:
> >From what i have seen you guys have laid the foundation for building a
>
> user class system with your FirewallRuleSet. All that needs to be done
> is split "known-users" into a few not so "known" user classes or
> groups.
>
> For now, let's just say that i want to add one new class called
> "public-users" I am thinking that it would be be as simple as this:
>
>
> # add this to wifidog.conf
> FirewallRuleSet public-users {
>     FirewallRule block all port 25
>     FirewallRule block to 192.168.1.0/0
>     FirewallRule allow to 0.0.0.0/0
> }
>
> This would block port 25 and access to my LAN.
>
> Also creating the correct filter chains
>
> iptables_do_command("-t filter -A " TABLE_WIFIDOG_WIFI_TO_INTERNET "
> -m mark --mark 0x%u -j " TABLE_WIFIDOG_PUBLIC, FW_MARK_PUBLIC);
> iptables_load_ruleset("public-users", TABLE_WIFIDOG_PUBLIC);
>
> And add a new enumeration like FW_MARK_PUBLIC = 3
>
> When a user is validated, instead of setting
> "client->fw_connection_state = FW_MARK_KNOWN", i will set the
> fw_connection_state to what is returned with the authcode... a
> classcode i guess you could call it, more like
> client->fw_connection_state = authresponse.classcode.  The classcodes
> should match the marks used in the firewall. So in this case when the
> user has validated the authserver output would be similar to:
>
> Auth: 1
> Class: 3
> Messages:
>
> This should put the public user class through the correct filter
> chain... I think. I might, and probably do, have a few things wrong
> but something along this line should work. It won't be until i get in
> there that i find all the real problems... does anybody foresee any
> problems for me using this or a similar approach to implementing a
> user class system? If i am totally off just tell me, and i will go
> back to the code and read some more... no lengthy response is
> required.

I don't see any implementation problem with your approach. The following isn't 
at all meant to stop you from doing it this way.

If you gate access to your private network with wifidog, there are two 
reasonably easy way to attack it.

The easiest and most obvious one is to simply spoof the MAC adress of someone 
currently using the protected subnet.  That requires someone to be using the 
connection at the time of the attack.
   
The second is that using wifidog to gate a private subnet breaks one of the 
assumptions of our security architecture:  We assume that the worst that can 
happen if you trick the gateway is for someone to access the internet without 
control.  So to keep wifidog simple and really small the connection with the 
server isn't encrypted.  This wasn't a problem, since if you are in a 
position to do a man-in-the-middle attack you ALREADY have internet access.  
Now if you use it to gate a private subnet, that assumption is no longuer 
true.  It's not a terminal flaw since all wireless traffic is in the clear 
anyway, but it's something to keep in mind.

> BTW- Sorry if i am being too enthusiastic about your project.  I don't
> want to seem like a bully, or too aggressive... i just want to use the

Don't worry about that: overenthousiasm is good, constructive criticism even 
better!

> dog, and i can't in it's current state.  As you will soon find out, i
> am a bit of a work-o-holic :)

That's also good!
-- 
Benoit Grégoire, http://benoitg.coeus.ca/
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: non disponible
Url: http://listes.philippeapril.com/pipermail/wifidog/attachments/20050302/1c4b6f7b/attachment.pgp