[wd-isf] Captive DNS, and auth server bypass

Daniel Drouet daniel.drouet at sympatico.ca
Sun Feb 6 22:16:18 EST 2005


Mina Naguib wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hey
>
> There are 2 parts to this email
>
> Part 1: Captive DNS
> - -------------------
>
> I have just implemented a captive DNS server in WiFiDog.  It's currently
> in a new branch "CaptiveDNS" - you can check it out using:
> cvs co -r CaptiveDNS wifidog
>
> It works but obviously testing & comments are welcome.
>
> It's comprised mainly of a "dnsserver" thread that answers queries, and
> an iptables REDIRECT rule that sends queries to it.  This is the same
> logic done now for captive web.
>
> Here is the primary motive for this:
>
> Scenario: Internet connection is down, but router is up
>
> 1. Client enters hotspot.
> 2. Client associates with signal
> 3. Client sends DHCP request, receives lease
> 4. Client opens web browser, enters "www.homepage.com"
> 5. Browser makes DNS query to resolve www.homepage.com
> 6. Query reaches DNSMASQ, which relays it upstream
> 7. Times out since the "internet is down"
> 8. Client cannot resolve hostname, so never makes HTTP request - gets
> incomprehensible error from their web browser/OS
>
> The end result is that the hotspot appears "down" with no opportunity to
> interact with the user.
>
> The captive DNS addresses the above.
> 1. 2. 3. 4. 5. As above
> 6. Query is intercepted by firewall rule, redirected to port 5353 where
> fake dns server in wifidog is running
> 7. Fake DNS server replies with the hotspot's internal IP address
> 8. Web browser receives IP, makes HTTP call
> 9. HTTP call is intercepted by iptables via the existing HTTP captive 
> rules
>
> Now you may ask, what's the point of jumping through all these hoops if
> the internet is down anyways, we'll never get them to authenticate ?
>
> A commit I did a couple of days ago makes wifidog "online-aware" - that
> means that the 404 handler in the captive HTTP server now displays an
> apology to the user when it knows that the internet connection or the
> auth server is down.
>
> I think that alone is worth the extra effort.  It also opens the door
> for many "neato" fake servers built-into wifidog, such as pop3 server
> that delivers a message "Please use a web browser first to log in at
> http://foo.bar", etc...
>
> Cons:
> There are 2 main cons, both addressable, that appear from the captive 
> DNS:
>
> 1. Attempting to resolve anything will point back to the router until
> the user is authenticated.  This will definitely interfere with
> pass-through services like teliphone.
>
> Possible solution: "Adaptive" fake DNS where, for certain hostnames, it
> will reply with the real IP instead of the internal IP.  This is already
> done for the auth server hostname, so it's simple a matter of a config
> file section of "hostnames to be truly resolved" by the captive dns 
> server.
>
> 2. Once the user receives the IP of the router as the answer to
> www.homepage.com, they then make an http call http://x.x.y.y:80 - this
> call must then be intercepted by captive HTTP system instead of by any
> web server on the router.  In other words, a web server that runs on
> router (admin/config/etc) needs to run on a port different than port 80
>
> Solution. I moved the captive HTTP iptables redirect rule higher than
> the "allow all to router" rule.  That makes captive http work since
> otherwise the call goes to the normal web server on the router
>
> Basically, the above boils down to: As long as the router is up, we'll
> be able to interact with the user, independent of whether the internet
> is also up or not.
>
> Now, on to:
>
> Part 2: Auth server bypass
> - --------------------------
>
> Like I mentioned, wifidog now has the capability to detect whether the
> auth server is accessible or not.  With minor tuning, it can detect
> whether the internet is up but the auth server is down, or the internet
> is down.
>
> That means that we now, in combination with captive DNS, have the
> ability to make some cool decisions regarding re-direction to the auth
> server.
>
> This is open for discussion among all volunteers, but I thought it's
> better to pose the question here first:
>
> ~ * * * *
> If the internet is up but the auth server is down, should we offer a
> "disclaimer" screen and let the user access the internet with a
> restrictive firewall set ?
> ~ * * * *
>
> My $0.02 says "let them browse" and that's it.
>
> The ideal solution is to, of course, have multiple
> geographically-redundant auth servers so we'd never need this, but
> reality (as we've seen this morning) is not the case. And even if it is
> the case for ISF, it may not be the case for all wifidog adopters.
>
> Enough rambling. Let me know your thoughts.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD4DBQFCBmbceS99pGMif6wRAtS1AJUdKA48+1ts3dph+w4E16Q3qE82AJ4ptgeR
> FQlAbvs5sxJzLtyrfat2eQ==
> =OCZ1
> -----END PGP SIGNATURE-----
> _______________________________________________
> wifidog mailing list
> wifidog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog-listes.ilesansfil.org 
>
>
If this is what you call rambling, by all means, ramble on Mina! Great 
job extending Wifidog's functionality.
_______________________________________________
wifidog mailing list
wifidog at listes.ilesansfil.org
http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog-listes.ilesansfil.org




More information about the Wifidog mailing list