[Server-devel] IP Address Pools for XOs, known clients, and unknown clients on XS 0.6

[Anna]

I like to leave the AP open on my test XS 0.6 at home, but ran into an issue
with that yesterday.  I noticed the lights on my router blinking like crazy,
so I did a live tail on the squid access log to see what was going on.

tail -f /var/log/squid/access.log

And oh, my goodness.  One of my neighbors was on there checking his
Facebook, setting up his fantasy basketball team, and, ahem, looking at
copious amounts of adult material.  First I checked to see if I knew who it
was via the Facebook user id I found in the squid log.  No, I had never met
him, but Mr. Frank <redacted> strikes quite the caricature of a aging
redneck fratboy.  In typical passive aggressive Southern lady style, I'm
going to teach him a lesson.

I don't want to put encryption on the AP or fool around with content
filtering, so I'm going to use some dhcp tweaks and iptables to put up an
obstacle to web browsing by unknown clients.

Edits for /etc/sysconfig/olpc-scripts/dhcpd.conf.1

Under the subnet declaration, I added a class definition for the XOs.  This
works for the two XO 1.5 units I've got as well, but I'd verify the MAC on
any of those just to be sure.

subnet 172.18.96.0 netmask 255.255.224.0 {

    class "xo" {
        match if substring (hardware,1,3) = 00:17:c4;
    }

Since I'm going to separate things into pools by range, I comment out this
line:

#range 172.18.96.2 172.18.125.254;

Beneath the lease times, I add my pools.  Adjust your ranges as needed.

    # Address pool for just XOs
    pool {
        allow members of "xo";
        range 172.18.96.2 172.18.123.254;
    }
    # Address Pool for unknown clients
    pool {
        range 172.18.124.2 172.18.124.254;
        deny members of "xo";
        deny known-clients;
        allow unknown-clients;
    }
    # Address pool for known clients
    pool {
        range 172.18.125.2 172.18.125.254;
        deny members of "xo";
        deny unknown-clients;
    }

Make sure all that is within the ending bracket of the subnet.

At the very bottom of the file, below everything else, I add the known
clients.

# Non-XO stuff on dynamic range 172.18.125.0/24
host anna-eeepc-1 {hardware ethernet 00:15:af:ec:9e:46;}
host anna-eeepc-2 {hardware ethernet 00:22:43:2e:fe:79;}
host tyler-eeepc {hardware ethernet 00:15:af:ec:96:1f;}

And because I'm ticked off, and inspired by
http://www.ex-parrot.com/pete/upside-down-ternet.html, it's time for some
fun with iptables.  In /etc/sysconfig/olpc-scripts/iptables-xs.in I add a
couple of lines like so:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -s 172.18.124.0/24 -p tcp --dport 80 -j DNAT --to
205.196.209.62
@@SQUID@@
-A POSTROUTING -o @@WAN@@ -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -s 172.18.124.0/24 -p tcp --dport 443 -j DROP
COMMIT

Restart dhcpd and iptables:
service dhcpd restart
service iptables restart

Now all unknown clients will have http traffic redirected to
http://kittenwar.com and their https traffic is dropped.

Obviously this isn't a deterrent to someone who can use an ssh proxy for
browsing, and it doesn't block traffic on other ports or protocols, but most
of my neighbors aren't of the networking savvy sort (particularly the
grotesque rednecks) and will likely conclude "this darn internet ain't
workin' no more."  If I lived near MIT, this would not be an acceptable
solution.  But I'm not terribly concerned many folks around here know much
about packet sniffing or MAC spoofing.

When guests come over and want to look at something other than pictures of
kittens, all I have to do is add the MAC to the list of known clients,
restart dhcpd, and tell them to renew their IP.

At the very least, now I know how to keep XOs and non-XO clients on
different IP ranges.

Anna Schoolfield
Birmingham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/server-devel/attachments/20110112/08dcf017/attachment-0001.htm