Workshop: Protect your (Ubuntu) laptop in one hour

This post started off in my head as a guide to firewalling your home server, but it gradually evolved, mentally, into a workshop for securing the information on your Linux laptop with GRUB, KeePass and Truecrypt. Click the (awesome Hackers) image below to RSVP your place for this once-off workshop!

Devil’s Advocate: The Microsoft Kinect Hacks

One of the sexist hardware hacking projects in the recent past has been the effort to open up Microsoft’s Kinect sensor bar to allow its control via USB from your personal computer. On November 7, a hacker claimed the USD $2,000 bounty for an open-sourced driver. It’s all standard (albeit cool) stuff. Microsoft’s reactions to the hacks and the community’s reaction to Microsoft’s reactions to the hacks where what caught my real attention. Shortly after the driver was announced, Microsoft made the following terse statement to CNET:

“Microsoft does not condone the modification of its products. With Kinect, Microsoft built in numerous hardware and software safeguards designed to reduce the chances of product tampering. Microsoft will continue to make advances in these types of safeguards and work closely with law enforcement and product safety groups to keep Kinect tamper-resistant.”

On every site I frequent for my technology news, the bias against Microsoft for this statement ran toward loud scoffing. Because, obviously, the software giant was making noise about the horse bolting after the fact. There were winks, nudges, grins (of the smug and shit-eating varieties), outright smirks, sly smiles, laughter, chuckles, mocker, derision, insults, and some spots of outright abuse. I at least hope to think that I took Microsoft’s initial hard stance a little more seriously, and I want to play devil’s advocate for a few minutes while I relate what I perceive as their reasons:

  1. Liability

    Every single piece of hardware that you purchase today has one of the below statements either stickered on the back or boldly noted in the accompanying documentation:

    No user serviceable parts within.
    Warranty void if tampered.
    Caution! Risk of electrical shock!

    Why? It isn’t just the cost of replacing user-destroyed hardware that might otherwise arise. No, it is Little Johnny Hacker who takes his brand-new Kinect home from the store, pops it open to see what is inside; in the process of applying solder to wires he somehow, tragically electrocutes himself. The headlines are going to read nothing but, “Microsoft’s Kinect killed poor Johnny Hacker!” The publicity stinks, but Microsoft can very fairly say that it wasn’t their responsibility.

  2. Intellectual Property.

    Maybe the more pressing reason. Microsoft has created custom hardware and software that, shocker, remains the property of Microsoft. When hackers crack open their Kinect they are potentially stealing this property and disseminating it. Yes, you can be prosecuted and yes, you can go to jail or be massively fined, jurisdiction dependent. At a really-guys-we-are-serious-about-this level, Microsoft doesn’t care all that much if people pirate Office or Windows 7 because it keeps them within the Microsoft ecosystem. If, however, they started trafficking in the source code for these products, Microsoft’s very own trade secrets are being opened up for all the world. People could conceivably use this to create a competitor product or (worse) open up Microsoft to liability from within and without.

  3. Creative control.

    This is the reason I most personally associate with, as a content (photography) producer myself: When you do Other Things to your Kinect, you aren’t receiving the full and intended Kinect experience. This is hugely important. To offer you a living example:

    I have found my Creative Commons-licensed images pop up in many strange and uniqe places, places that include in one example an fundamentalist Islamic prayer group. They were, thankfully, fundamentalist in the sense that they wanted to return to Muhammad’s original message, instead of blowing up the infidels. However, for a very long while before I received an authoritative clarification, I was honestly uncomfortable with my image being used on their website because:

    I’m irreligious; I don’t want to appear to be tacitly endorsing any faith.
    They are possibly militantly extremist; what might befall me if they should come to light in a negative manner?

    Microsoft’s fears are parallel to what mine were: If people begin to modify their Kinect hardware, it could potentially be embarrassing for the company as a whole. Home-made, three-dimensional, motion-captured porn, coming soon to a torrent near you courtesy of Kinect. It isn’t the end of the would, but it could be a true egg-on-your-face moment.

It isn’t all bad. On Friday ( November 19), a second statement from Microsoft’s Kinect developers demonstrated a remarkable change in outlook:

“Kinect was not actually hacked. Hacking would mean that someone got to our algorithms that sit inside of the Xbox and was able to actually use them. Which hasn’t happened. Or, it means that you put a device between the sensor and the Xbox for means of cheating, which also has not happened. That’s what we call hacking, and that’s what we put a ton of work and effort in to make sure doesn’t actually occur.

“What has happened is someone wrote a open source driver for PCs, which essentially opens the USB connection, which we didn’t protect by design, and reads the inputs from the sensor.”

My guess is that between the first and second statements Microsoft very intensively looked at what their liability might be, and what the intellectual property loss might be, in relation to the Kinect hacks.

So, there you go. Five minutes of devil’s advocacy on the hacks.

Open source is amazing

One of the most beautiful things about free and open source software is the native freedom to alter, extend, adapt, trim, reduce, repackage and reuse the code as I see fit, within the terms of the license. Sometimes – as is the case of the of Canonical and Ubuntu who began their work with a simple bundling of Debian’s package software (as an aside, Ubuntu and Debian are still fairly compatible, to the point that, if you feel brave, you can use one’s repositories with the other’s distribution) – these changes are huge and massively sweeping. And at others, it is the freedom to change three lines to grant a new set of defaults.

/wonder

Build a(n Ubuntu) home server in one hour…

Tux!

…and secure it too.

When Aaron, Matthew and I incepted our Linux classes, we did so with a nebulous aim of offering a course of comprehensive beginner material, with our ultimate, nebulous goal being to offer “more advanced stuff”. Well, here we are. I dove into the basics of manipulating the Bash shell, simple scripting, SSH, and confidently administering a headless system as root. In the midst of my preparations for these classes, I had a theatric lightbulb-over-head moment: How hard would it be, really, to turn a desktop into a basic home server? Set aside performance and security concerns for a moment and just consider accessibility and turnaround time to live access on the Internet.

As it turns out, this takes about one hour. Maybe two if you are installing Linux from scratch. All you need to begin is a method to connect your dynamic home IP to a static domain and then a method to remotely access your home server:


apt-get update
apt-get upgrade
apt-get install openssh-server openssh-client

Sign up for a free DynDNS account and domain (remember to complete checkout!).


apt-get install ddclient

Populate three lines in /etc/ddclient/ddclient.conf with:

  1. Your DynDNS user name.
  2. Your DynDNS password.
  3. Your DynDNS domain.


/etc/init.d/ddclient restart
/etc/init.d/ssh start

Now give DynDNS and ddclient about five minutes (on the safe side) to update. Congratulations, you have a live Internet server for your file-access, media streaming, jerking-around-while-at-work, and general geek needs.

Now, we have a server. Locking down its Internet connection? Mmm, ten minutes. It was actually over an hour for me because I was engrossed in crash-learning netfilter/iptables syntax from scratch.


#/bin/sh

# Clear all existing iptable rules.
iptables -F
iptables -X

# Drop all incoming, outgoing and forwarded packets.
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Permit loopback activity (client and server programs on this machine).
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Permit TCP connections to and from this machine on port 22 (SSH).
iptables -A INPUT -p tcp -dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp -sport 22 -j ACCEPT

You’ll eventually need to open up ports for NTP, mail, DNS and others, but really: This is all there is to it. And because I am awesome, I wrote all of this up on Google Docs and made it freely available for download. Any notes suggesting alterations, additions or deletions can be made directly on the document, or by email to me directly.

Your Home Server and You