trivia

As a chartered member of the British Computer Society (BCS) I recently received through the post my voting forms for the 2008 AGM. The process gives me the option of voting electronically using a website run by Electoral Reform Services. My security codes (two separate numeric IDs, one of six characters, the other of four) were printed on my personalised letter from the Society. So far so dandy.

However, the following day I received an email from Electoral Reform Services giving me exactly the same information, together with the address of the webite where I may cast my votes.

Am I happy? Guess.

I have just built myself a new intel core 2 duo based machine to replace one of my older machines which was beginning to struggle under the load of video transcoding I was placing upon it. The new machine is based on an E8400 and is nice and shiny and fast. Because it is a new build, I decided to install the OS and all my preferred applications, tools and utilities from scratch. Yes, I could have just copied my old setup, or at the least, my home directory and system configuration from my older machine, but I chose to do a completely new clean build on top of a clean install of ubuntu 8.04. I did this largely because my older system has been upgraded and “tweaked” so often I am no longer sure exactly what is on there or why. I am sure that it contains a lot of unnecessary cruft and I felt it was time for a clear out. A new build should ensure that I only installed what I actually needed. Of course I copied over my mail, bookmarks and other personal data, but the applications themselves I simply installed from new and then configured to my preferred standard.

Like most modern linux distros, Ubuntu is pretty secure straight out of the box. Gone are the (good old, bad old) days when umpteen unnecessary services were fired up by init or run out of inetd by default. But old habits die hard and I still like to check things over and stop/remove stuff I don’t want, or don’t trust. I also like to check outbound connections because a lot of programs these days have a habit of “calling home” - a habit I dislike. I noticed and cleared up one or two oddities I’d forgotten about (Ubuntu uses ntpdate to call a canonical server if ntpd is not configured for example. Since I use my own internal ntp server, this was easy to sort). However, after clearing, or identifying all other connections I was left with one outbound http connection I didn’t recognise, and worse, it was to a network I know to be untrustworthy. The connection was to 66.235.133.2. This machine is on the omniture network. Omniture is notorious for running the deeply suspicious 2o7.net. Omniture market webanalytics services and are used by a whole range of (perfectly respectable) companies who pay them for web usage statistics. But omniture have never successfully explained why they choose to use a domain name which looks like, but isn’t, a local RFC 1918 address from the 16 bit block (e.g. 192.168.112.207). I don’t trust them, and I didn’t like the fact that my shiny new machine was connecting to them. So what was responsible? And what to do?

Well, the “what to do” bit is easy - just blackhole the whole 66.235.128.0 - 66.235.159.255 network at my firewall. But that feels a bit OTT, even for me. A bit of thought, and a bit of digging gave me a better solution, and one which incidentally solves a range of related problems. What I actually needed was a way of preventing oubound connections to any hosts I don’t like or don’t trust. So long as the IP addresses of the hosts are not hard coded in the application (as sometimes happens in trojans) the classic way to do this is to simply map the hostname to the local loopback address in your hosts file. But this can become tedious. Fortunately, it turns out that a guy called Dan Pollock maintains a pretty comprehensive hosts file on-line at someonewhocares.org. Result.

Because I run my own local DNS server (DNSmasq on one of the slugs) it was easy for me to add Dan’s host file to my central hosts file. So now all my machines will routinely bin any attempted outbound connection to adservers, porn sites, or whatever in the list. The downside, of course, is that this is a bit of blunt instrument and may cause some difficulty with some sites (ebay for example). But I’m prepared to put up with that whilst I fine tune the list. I can also pull the list regularly and automatically via cron so that I stay up to date (but of course I won’t just blindly update my DNS, I’ll pull the file in for inspection and manual substitution…..).

So what was making the connection? Well it looks to me as if adobe is the culprit. I had installed the acroreader plugin for firefox.

Silly me. Must remember to avoid proprietary software.

(Oh, and you just have to love omniture’s guidance on how to opt-out of their aggregation and analysis. You have to install an opt-out cookie. Oh yes, indeedy, I’ll do that.)

In an earlier post I speculated that the CherryPal PC might be a possible option for users considering replacements for the slug. But that device has still yet to hit the streets and is beginning to look suspiciously like vapourware. However, linuxdevices, the site devoted to linux on embedded devices, wrote about the interesting looking french made linutop some months back. The linutop site looks to me as if it is actually taking orders.

Now if they could just ship one with two ethernet ports, it might make a good base for a firewall.

Amidst all the hype and hullabaloo about Google’s chrome, el reg tells it like it is. Yes, “it’s a f***ing web browser”.

You just have to love the reg.

Have you ever wondered what was eating your network? Would you like to be able to check exactly which application was responsible for that sudden spike in outbound traffic? NetHogs might help. This neat little utility calls itself a “small ‘net top’ tool”, and that is exactly what it is. NetHogs groups bandwidth usage by PID so you can immediately see which application is responsible and take whatever action you deem appropriate.

Recommended.

(Oh, and if you want a nice graphical representation of the connections your PC is making whilst you are using it, I recommend you install etherape. It can be a highly educational (not to say scary) experience to leave etherape running whilst you fire up your browser. You will find that your PC is making HTTP connections all over the place. Now try leaving it running whilst you are not doing anything and watch what happens.)

Dan Kaminsky has (quite rightly) been hitting the press a lot in the weeks since 8 July when he announced the work done to fix a flaw he had discovered in DNS. The vulnerability itself was new, but its impact (cache poisoning) was not. Indeed, we’ve known about the dangers of poisoned DNS caches for some years now. Kaminsky originally took a lot of flak about his announcement, its timing (to coincide with Microsoft’s “patch tuesday”), his reluctance to discuss details (”trust me, it’s dangerous. I’ll tell you all about it later”) and his apparent willingness to “talk up” the issue with the non-specialist press. But all that aside, he deserves immense credit for highlighting the flaw and herding all the cats necessary to get vendors on board to create patches. He has also since been as good as his word and described the problem in detail.

However, I have a big problem with one of his blog entries: “Here comes the cavalry” where he says “Note, if you must forward, it’s most secure to do so to a name server that’s still on your network but happens to be patched — but in a pinch, you’re much better off forwarding to OpenDNS or another free and patched name service provider than going direct (and insecure).”

In my view, this is hugely ironic. Cache poisoning means that you cannot trust the answer your DNS server provides. I do not trust the answer OpenDNS provides. OpenDNS violates principles which in my view are essential to an open, transparent and trustworthy network. They hijack queries and give incorrect answers. For example, they do not reply with NXDOMAIN to a query for a non-existent host or domain. They also hijack queries aimed specifically at Google. See the dig queries below for examples.

I first came across OpenDNS when I installed packetprotector on an Asus wireless router I was playing with. OpenDNS servers were hardwired as the default DNS hosts in that package. I run my own dns internally using DNSmasq and the hosts file on that system contains the private addresses of my internal servers on my network. Imagine my surprise then, when during testing, I pinged one of my internal hosts from the Asus only to get a response back from a server with the address “208.69.34.132″. This should not happen. It is a bad thing (TM), regardless of how OpenDNS may attempt to portray this as “helping” the community.

In a discussion about Google’s toolbar, David Ulevitch of OpenDNS said, “The solution to this problem was to route Google requests through a machine we run to check if the request is a typo or one of your shortcuts. If it is a typo or shortcut then we do what we always do, just fix the typo or launch your shortcut and send you off on your way. If it’s not one of those two things, we pass it on to Google for them to give you search results. This solution provides the best of both worlds: OpenDNS users get back the features that they love and Google continues to operate without problems.”

Wrong. I do not want some third party fiddling with my DNS requests on the spurious grounds that I may have mistyped some hostname.

Make up your own mind. There is extensive discussion about OpenDNS on-line. See in particular the commentary at the scream and on wikipedia. Personally, I prefer to use my ISP’s DNS servers. I have a contractual relationship with them and I can therefore expect them to provide me with a service which works, and is trustworthy (for some definition of “trust”). Oh, and they patched their DNS servers very, very, quickly.

Now some sample dig results:

First using my default (DNSmasq forwarding to my ISP)

mick@slug:~$ dig www.google.com

; <<>> DiG 9.4.2-P1 <<>> www.google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47551
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 604798 IN CNAME www.l.google.com.
www.l.google.com. 299 IN A 216.239.59.104
www.l.google.com. 299 IN A 216.239.59.147
www.l.google.com. 299 IN A 216.239.59.99
www.l.google.com. 299 IN A 216.239.59.103

;; AUTHORITY SECTION:
l.google.com. 86397 IN NS e.l.google.com.
l.google.com. 86397 IN NS a.l.google.com.
l.google.com. 86397 IN NS c.l.google.com.
l.google.com. 86397 IN NS d.l.google.com.
l.google.com. 86397 IN NS b.l.google.com.
l.google.com. 86397 IN NS g.l.google.com.
l.google.com. 86397 IN NS f.l.google.com.

;; Query time: 30 msec
;; SERVER: 192.168.10.10#53(192.168.10.10)
;; WHEN: Sat Jul 26 18:03:08 2008
;; MSG SIZE rcvd: 228

Now use openDNS

mick@slug:~$ dig www.google.com @208.67.222.222

; <<>> DiG 9.4.2-P1 <<>> www.google.com @208.67.222.222
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40840
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 30 IN CNAME google.navigation.opendns.com.
google.navigation.opendns.com. 30 IN A 208.69.34.230
google.navigation.opendns.com. 30 IN A 208.69.34.231

;; Query time: 19 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Jul 26 18:04:54 2008
;; MSG SIZE rcvd: 104

Are you happy with that?

I noted in an earlier post that Linksys were ceasing production of the NSLU2. There are now a variety of NAS systems coming onto the market which might make good replacements - but most of them look expensive when compared to the slug. However I’ve just seen a review of a box which looks as if it might be just up my street - the oddly named CherryPal PC, based on Freescale’s MPC5121e mobileGT processor.

The specs look very interesting - indeed, if the press release at Marketwatch.com is to be believed, the box has “256GB of DDR2 DRAM” to go with the 800 MIPS Freescale’s MPC5121e processor.

Methinks this may be a typo.

An apt-get dist-upgrade (to bring the kernel up to date and install some new patches) on the slugs killed the webcam. Of course I should have remembered that the gspca module was built against the old kernel and might fail. One quick “m-a auto-install gspca” later and all is working again.

Of course the kernel update required a reboot so my uptime is now back to zero, but security is more important than a long running time.

Jim Buzbee, of batbox fame and one of the original NSLU2 hackers, apparently gave a presentation about the history of slug hacking at the Boulder Linux Users Group. A PDF copy of his presentation can be found on his batbox.org site.

Jim also notes that Linkys are ending production of the NSLU2 after four years of life. Better get your hands on a few now before they all disappear - or end up at twice the price on ebay.

You could regard this as another pointless entry to go alongside the webcam. But hey - so what.

I had cause to check the uptime on my slugs a little while ago now that they are largely stable and providing the services I want. After doing so I thought it would be good to be able to check this from a web page and a short search later came across Matthew Trent’s UD daemon. I’ve now made my webcam slug uptime public. Let’s see how high this will get.