[isf-wifidog] Gateway development
acv
acv at miniguru.ca
Lun 14 Nov 18:06:36 EST 2011
Did you get my off-list email?
Alex
On Mon, Nov 14, 2011 at 04:01:18PM -0700, Andrew Niemantsverdriet wrote:
> Date: Mon, 14 Nov 2011 16:01:18 -0700
> From: Andrew Niemantsverdriet <andrewniemants at gmail.com>
> To: WiFiDog Captive Portal <wifidog at listes.ilesansfil.org>
> Subject: Re: [isf-wifidog] Gateway development
>
> Cool, thanks!
>
> Looking forward to the new stuff. Let me know if you want somebody to test it.
>
> On Mon, Nov 14, 2011 at 4:01 PM, acv <acv at miniguru.ca> wrote:
> > On Mon, Nov 14, 2011 at 02:52:14PM -0700, Andrew Niemantsverdriet wrote:
> >>
> >> I can confirm that the use of DNS works in iptables. For example:
> >> iptables -t nat -I WalledGarden -m state --state
> >> NEW,ESTABLISHED,RELATED,INVALID -d "www.google.com" -j ACCEPT --p tcp
> >> -dport 80
> >>
> >> Allows everything on tcp port 80 to www.google.com which is more than
> >> 1 ip address.
> >
> > I know that works. I'm more worried about the configuration parser in the
> > gateway expecting numeric IPs only... I could totally have coded that:
> >
> > for (i = 0; *(mask + i) != '\0'; i++)
> > if (!isdigit((unsigned char)*(mask + i)) && (*(mask + i) != '.')
> > && (*(mask + i) != '/'))
> > all_nums = 0; /*< No longer only digits */
> > if (!all_nums) {
> > debug(LOG_ERR, "Invalid mask %s", mask);
> > return -3; /*< Fail */
> > }
> >
> > Which would force numeric IPs only in the firewall rules... Incidentally,
> > that's the code I used to parse firewall rules (see conf.c).
> >
> > So I'll apologize for that code ;-). I'll have to refactor that to detect
> > hostname (maybe resolved them to validate them) and store the hostname in the
> > rule.
> >
> >> This is a hack that I used before implementing a full blown proxy
> >> server and moving the wifidog gateway to a central box. I had a script
> >> run via cron that used wget to get a list of iptables rules for the
> >> walled garden and then applied them to the wifidog gateway. It was a
> >> fragile process at best but did work.
> >>
> >> I agree that it should be the service providers who decide to enable
> >> mac white listing, if you were very concerned about security a hotspot
> >> controller of any type would not be what you rely on for access
> >> control. 802.1x would be what you would use. The reason why
> >> browserless (tokenless) logins are appealing is we are seeing more and
> >> more mobile devices that use wifi. Our users like to complain that it
> >> is a big pain to have to open up a web browser on their [phone,
> >> tablet, nook, kindle] to get internet access. I do see their point
> >> everybody is expecting always connected wifi everywhere around campus.
> >> I think this problem is only going to worsen into the future so it
> >> might be wise to address it now.
> >
> > Yep. Added it to my todo list for version 2.0.
> >
> > Alex
> >
> >>
> >> Thanks,
> >> _
> >> /-\ ndrew
> >>
> >>
> >>
> >> On Mon, Nov 14, 2011 at 1:21 PM, acv <acv at miniguru.ca> wrote:
> >> > On Mon, Nov 14, 2011 at 12:17:31PM -0700, Andrew Niemantsverdriet wrote:
> >> >>
> >> >> Yes, you can kinda have a walled garden working. However it is a huge
> >> >> pain in the butt to do, since it is done in the conf file that means
> >> >> each AP has to be touched. Also the conf file does not play nice with
> >> >> domain names (even though iptables can) so for example allowing a
> >> >> walled garden entry of google.com would involve adding 20 IP's that
> >> >> change depending geographic location and loads on each server. This is
> >> >> not practical at all. What I am proposing is a mechanism to allow the
> >> >> server to keep a central central list of URL's that is used by the
> >> >> gateway to determine if a URL should be allowed or not.
> >> >
> >> > That should be addressable in two parts. One for downloading some
> >> > of the config from the auth server and the other to make sure use of DNS
> >> > in iptables works. At the moment, I'm keeping this out of my scope for the
> >> > "1.5" protocol but that's in the plan for the next step. Remotely managed
> >> > configuration is one of the desired "2.0" feature.
> >> >
> >> >> For browser-less authentication there has been some talk about it here:
> >> >>
> >> >> http://dev.wifidog.org/wiki/doc/developer/SupportingDevicesWithNoWebBrowser
> >> >>
> >> >> At the bottom it mentions v2 of the protocol. What I want to see is a
> >> >> way for the Wifidog server be able to maintain a whitelist of MAC's
> >> >> that are allowed to connect. That along with the walled garden
> >> >> approach above would eliminate many of the problems I am seeing with
> >> >> things like xbox's and nintendo's trying to connect up wireless and
> >> >> being unable to.
> >> >
> >> > What I don't like about most of these is the reliance on a MAC address
> >> > whitelist. Or worse, a "white range". But that's for the service provider (i.e.:
> >> > you) to decide if that's an acceptable security stance. What would be needed to
> >> > get on-demand MAC based auth going would be to use DHCP to drive a login event
> >> > and forgo the token altogether. So yeah, "2.0" feasible although it would be
> >> > significant which dhcpd is used and how it's configured.
> >> >
> >> > Alex
> >> >
> >> >>
> >> >> Thanks,
> >> >> _
> >> >> /-\ ndrew
> >> >>
> >> >> On Mon, Nov 14, 2011 at 11:38 AM, acv <acv at miniguru.ca> wrote:
> >> >> > On Mon, Nov 14, 2011 at 11:16:09AM -0700, Andrew Niemantsverdriet wrote:
> >> >> >>
> >> >> >> I have looked over the new protocol and am liking what I see. Some
> >> >> >> things that I would like to see implemented is walled gardens and a
> >> >> >> sane way to handle clients that don't have a browser.
> >> >> >
> >> >> > The lack of browser I am not sure... This falls a bit out of the bound of your
> >> >> > typical captive portal. I might need help to see a scenario where the gateway
> >> >> > can do /anything/.
> >> >> >
> >> >> > For the walled garden, can you flesh out the ideal use case for me? There is
> >> >> > already some support for that in terms of the different user classes and the
> >> >> > configurable firewall rules. The protocol is already able to handle that case
> >> >> > although admittedly this might not be properly configurable. With a better
> >> >> > use case I'd be able to better see what gateway side improvement might be
> >> >> > needed.
> >> >> >
> >> >> > Alex
> >> >> >
> >> >> >> I can offer my network for testing. It is not huge but big enough... I
> >> >> >> have 27 access points and max out at 200 on at one time. The average
> >> >> >> is lower but I don't know what that is since I don't have any metrics
> >> >> >> for that. Contact me off list if you are interested.
> >> >> >>
> >> >> >> Thanks,
> >> >> >> _
> >> >> >> /-\ ndrew
> >> >> >>
> >> >> >> On Thu, Nov 10, 2011 at 7:45 PM, acv <acv at miniguru.ca> wrote:
> >> >> >> > Hi All,
> >> >> >> >
> >> >> >> > I have been spending a bit more time working on the gateway and I have drafted a
> >> >> >> > proposal for a protocol to replace the current ad-hoc protocol. This first proposal
> >> >> >> > is more of an interim protocol to pave the way for new features since it doesn't
> >> >> >> > implement any truly "new" functionalities but it is readily extensible.
> >> >> >> >
> >> >> >> > Specifications can be found here:
> >> >> >> >
> >> >> >> > https://bitbucket.org/acv/wifidog-ng/wiki/ProtocolV1.5
> >> >> >> >
> >> >> >> > I believe anyone should be able to edit this wiki page (may need a free bitbucket
> >> >> >> > account).
> >> >> >> >
> >> >> >> > I figure I could have this implemented by Christmas or so given my current spare time.
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> >
> >> >> >> > Alexandre
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > WiFiDog mailing list
> >> >> >> > WiFiDog at listes.ilesansfil.org
> >> >> >> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >> >> >> >
> >> >> >> _______________________________________________
> >> >> >> WiFiDog mailing list
> >> >> >> WiFiDog at listes.ilesansfil.org
> >> >> >> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >> >> >
> >> >> > _______________________________________________
> >> >> > WiFiDog mailing list
> >> >> > WiFiDog at listes.ilesansfil.org
> >> >> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >> >> >
> >> >> _______________________________________________
> >> >> WiFiDog mailing list
> >> >> WiFiDog at listes.ilesansfil.org
> >> >> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >> >
> >> > _______________________________________________
> >> > WiFiDog mailing list
> >> > WiFiDog at listes.ilesansfil.org
> >> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >> >
> >> _______________________________________________
> >> WiFiDog mailing list
> >> WiFiDog at listes.ilesansfil.org
> >> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >
> > _______________________________________________
> > WiFiDog mailing list
> > WiFiDog at listes.ilesansfil.org
> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 195 octets
Desc: non disponible
URL: <http://listes.ilesansfil.org/pipermail/wifidog/attachments/20111114/fb5f689a/attachment-0001.pgp>
Plus d'informations sur la liste de diffusion WiFiDog