DNS - The Internet's Phone Book

My earlier post about filtering Internet content for kids bringing home their school iPads may have created more questions than answers for some parents. The big confusion seems to step from what a Domain Name System (DNS) server is, and how it helps filter out objectionable content.

Let's go waaaaay back in time, back to the birth of the initial global network called ARPANET. Back in the day - and even now - you could reach a remote computer by using its numeric address. To connect to a remote computer, your machine may connect to "192.168.129.34" and send along some pretty data. Those numeric addresses could be a pain to remember however - so shortcuts were created that mapped a human-recognizable name (like "BubbaComp") to the numeric address (like "192.168.129.34"). Solutions were eventually engineered that let people share these lists... that way everyone could have this helpful list of shortcuts. This convention kept evolving as users continued to join the global network, up to today. Now when you type in "amazon.com" your computer is smart enough to look up this shortcut name and find out the numeric address is 176.32.98.166. Your computer always talks to 176.32.98.166, however you talk to your browser using https://amazon.com.

This operates just like a phone book. No one remembers people's phone numbers anymore... or at least I don't. Instead you look up a person's name in your personal address book or the big dead-tree phone book on your front stoop, then communicate using the phone number in the book. Connecting to sites over the Internet works in the very same way.

What if you didn't want your kids visiting certain sites? You could employ the same trick as you might to stop them from calling certain people over the phone - edit the phone book. If your kids can't look up a person's name and find their phone number, they can't call the person. If you edit the Internet's phone book and remove objectionable sites, your kids can't visit the objectionable site on their device of choice. That's exactly what OpenDNS allows you to do - use a phone book that only has acceptable web sites within it.

What if a kid memorizes a phone number tho? Your plan falls apart a bit in that case. DNS filtering has the same limitation - if your kids memorize the IP address of a site (or share an underground DNS server), then they can go directly to the site and bypass your sanctioned "phone book."

If your kids go to a site that has a wide variety of content (like YouTube), you can't filter out specific types of content within the site. Just like calling a party line on the phone... if you allow access to the party line, you can't control anything past the initial dial.

Hopefully that helps explain why OpenDNS is only your first line of filtering. Lemme know in the comments if I can clarify further!

Web Filtering at Home

[Updated to include an OpenDNS how-to]

Now that iPads are standard issue for a lot of schools, a few parents have asked me how they can block inappropriate material at home. While the schools themselves filter at the network level, as soon as the student comes home the network is wide open.

In all honesty, you can't filter out 100% of all objectionable content. It's hard to have software determine if a YouTube stream is showing questionable video. However, you can audit, track and block some obviously adult sites. The traditional options to perform web filtering include:

• Software applications or parental controls on the device itself
• Filtering devices on the router or wireless access point
• External Internet services that block DNS requests

Software applications give you the most control on a per-device level and can block errant applications as well (like anti-virus software), however you have to install them on each and every device. They also have the benefit of blocking things no matter what network they are attached to. They usually require a medium-level effort to circumvent, and it is sometimes hard to get a report on what the actual activity has been or if any sites had to be blocked.

Filtering devices provide filtering for the entire network and do not rely on software to be installed on the device, which is nice. This solution is the hardest to circumvent, so long as you properly lock down your wireless access point. This solution cares less about applications however, and can’t really tell how appropriate actual content on a site is. It also only controls those devices on your network, and often doesn’t have fine-grained controls.

External Internet services filter your entire network, just like a filtering device would, however it is hosted out on the Internet rather than being something installed or managed inside your house. This option often doesn’t give you much (if any) per-device controls, however they often do a great job of letting you pick what and how many sites to filter out. These solutions often provide reporting as well, letting you see what was viewed by devices on the network. This solution also can’t tell you about the actual content on the site, but just the URL that was visited. This solution is the easiest to circumvent, although this can be mitigated by locking users out of the administrative settings of a device (e.g. not letting users change network settings on an iPad).

What I chose for the house was an external Internet service via OpenDNS. This was easy to set up since I just had to create an account and make a few minor tweaks to our wireless access point, and it gives me some nice reporting on what was blocked. For example, lately I saw a lot of adult sites being blocked and found an iOS application was loading them in the background.

OpenDNS has a Getting Started Guide on their site, but here's an abbreviated version of the steps for setting up OpenDNS on your home network:

1. First, load up the settings console for your wireless router. Check your user guide for how to do this - usually it involves loading up a web page at http://192.168.1.1 and entering a username and password.
2. Next, find the "Internet" or "WAN" settings page within your wireless router. This is in your router's user guide as well. It may look something like:
   
3. Change the DNS Servers from the automatic settings to the values "208.67.222.222" and "208.67.220.220"
4. Click on "Apply" or "Save" or whatever floats your router's boat.
5. Create a new account at http://www.opendns.com/
6. Part of your account creation process will be linking your local network to your OpenDNS account. Once your local network joins OpenDNS, it will begin monitoring what sites are requested.
7. After you create your account, you will be taken to the OpenDNS dashboard. At that point you can decide how much filtering you want to apply to your network - from sites that are obviously adult-only to sites that are adult in theme (fashion magazines, for example).

I'll post a subsequent entry on what OpenDNS actually does in hopes of helping explain why this kind of filtering is useful and its limitations. While this might seem like rocket surgery at first, hopefully this helps you learn how to be a steward of your Internet connection... just like you have to monitor & maintain your sump pump before the basement floods.

Requiescat In Pace

It has been a fantastically horrible month in my real life. I'll just leave it at that. All my current projects, including the portal I was hoping to launch, are pretty much indefinitely on hold.

In other news, I've been trying to find a better way of connecting to my home network while abroad. I've been using SSH to connect and locally forward ports to the home network, but that meant every service had to be hard-coded. Instead I've been evaluating OpenVPN on OpenWRT. Both are amazing projects, and both worthy of considerable attention.

I haven't evaluated OpenWRT in nearly four years now... they had just started using a package manager when I last tried to flash my WRT54Gv2. It's in an amazingly well-adjusted and highly advanced state now... it was hard to believe how flexible the OS & utilities were. Everything worked out of the box with a minimum of hacking. Especially for someone like myself who used to construct Linux home firewalls out of old workstations, this fit my schema perfectly. I was a HyperWRT guy, but as that firmware grew stale I moved an entire distro-in-RAM.

OpenVPN is further evidence of why IPSec tunnels just never gained proper adoption in the roadwarrior market segment. They work fantastic when joining disparate networks through concentrators, but they just don't offer the flexibility, interoperability and ease-of-use that SSL tunnels do. I was an IPSec advocate in the days of FreeS/WAN, but once opportunistic encryption adoption didn't reach ubiquity they supposedly just closed up shop. PPTP offers good interoperability and ease-of-use, but was ultimately PPP with some wrappers around it. OpenVPN has proven itself to be a secure and flexible compromise between the two while still maintaining ease of use behind firewalls, proxies and NAT's. It may lack a certain "purity" of IPSec, but for roadwarrior and ad-hoc connections OpenVPN is indispensable.

Juniper Networks has a pretty good "Instant Virtual Extranet" platform that incorporates an SSL-based VPN solution which does a great job - it even supports Linux. I have to give a big tip o' the hat to Juniper Networks on that one - the actually developed a VPN client that works properly in Linux. Launch a Java Applet, grant it rights to install a client stub on your machine, then an SSL tun0 interface automagically pops up on your Linux box. Bravo.

But I digress.

The NetworkManager GUI within both Gnome and KDE has support for OpenVPN tunnels, so I decided to give it a try. At first I attempted the most simple case using a static key. For the life of me I couldn't get static key support to work with NetworkManager... it wouldn't even establish a connection despite the fact that it worked manually on the console. I gave up on static keys and instead created a public key infrastructure, issuing client keys when needed. This allowed me to establish a connection just fine, but it brought one critical bug to the surface: DNS resolution was subsequently borked, since NetworkManager wiped out resolv.conf once the tunnel was initialized. Fooey.

So instead I created a manual script that initiates the tunnel. That appears to be working pretty well now... no big worries. For now it's a straight UDP tunnel, but I might change it to TCP down the road.

The configuration wasn't too bad - I followed the HOWTO Quickstart pretty much by the letter by creating the keys, issuing them to clients then using their sample server and client config files. On OpenWRT, all I had to do was create an /etc/init.d/S50openvpn script to start OpenVPN on startup, then add the following firewall rules:
### OpenVPN traffic
## -- Permit initial negotiation
iptables -t nat -A prerouting_wan -p udp --dport 1194 -j ACCEPT
iptables -A input_wan -p udp --dport 1194 -j ACCEPT
## -- Permit tun interfaces
iptables -A forwarding_rule -i tun+ -j ACCEPT

Now I'm able to connect and browse at will. Not too shabby!

Amazing that you can build a VPN concentrator, WAP, firewall and management station for a little more than $50. Ultimately you end up with more usability than you could get with a $200 cheapo desktop.