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

[Mina Naguib]

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