[isf-wifidog] Gateway development
acv
acv at miniguru.ca
Lun 14 Nov 18:01:16 EST 2011
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
-------------- 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/8100e263/attachment.pgp>
Plus d'informations sur la liste de diffusion WiFiDog