May 09 2013

digitalocean do it again

I can’t believe these guys. Not only do I get unlimited traffic on a 1 Gig network (now at three locations – I have a VPS in each of Amsterdam, New York and San Francisco) for peanuts, but they have just given me a $5.00 credit (i.e. one month free for one of the servers). Why? Simply because I pointed out that their email alert system was failing to add the required “Date: ” header.

Most ISPs would see that as a complaint and might, just might, get around to scheduling a fix. Not only did digitalocean fix the problem in short order, but they gave me a service credit saying:

Hi there –

Thanks for pointing this out to us! We thought we had this in place, but in reality our ticketing system was crafting email

differently than expected. We’ve added the header, and now it appears to be working. We’ve given you a credit in thanks.

Let us know if you need anything else.

Astonishing. Go buy their service.

Apr 29 2013

too close to the logo

I came across this entry on the blog of a company called Conformal today. The company purports to specialise in open source security products and the blog entry was about the logo for their secure online backup product called “cyphertite”. Apparently the marketing discussions concentrated on “artfully applied make-up, designer clothes, and a narrative to match. There was a lot of back and forth about layering, defense-in-depth and secure storage.” i.e. the usual type of meaningless fluff that is common to marketing meetings. But apparently nobody noticed the way the logo looked to an outsider.

I was reminded of the OGC Cockup in designing its logo back in 2008. No-one in the marketing team noticed the problem until they printed it on mouse mats and distributed them to staff.

Apr 27 2013

cool

I have just been notified that I am eligible for a Tor T shirt. How cool is that?

This is a Tor Weather Report.

Congratulations! The node 0xbaddad (id: C332 113D F99E 367E 4190 424C E825 057D 9133 7ADD) you’ve been

observing has been running for 61 days with an average bandwidth of 2278 KB/s,which makes the operator eligible to

receive an official Tor T-shirt! If you’re interested in claiming your shirt, please visit the following link for more information.

https://www.torproject.org/getinvolved/tshirt.html

My digital-ocean tor node has been running uninterrupted since early January and has been shovelling traffic at a consistent 30+ Mbit/s for the last couple of months.

bin-vnstat-april-2013

Not bad for $5.00 per month.

Apr 10 2013

this is not a political blog

but I cannot let her passing go unremarked.

Yesterday even the Guardian devoted 15 pages, plus the centre spread and a separate 16 page supplement to Margaret Thatcher. The usual suspects on the right wing tabloids were, predictably, particularly revisionist and swivel eyed. We are in danger of letting the death of one ex prime minister push real news analysis and comment onto the back burner. Worse, the revisionist theses may start to take root. A state funeral (which Thatcher herself apparently argued against) would only add to the lunacy.

I’m with Ken Loach who was quoted today as saying “How should we honour her? Let’s privatise her funeral. Put it out to competitive tender and accept the cheapest bid. It’s what she would have wanted.”

And let’s give management of the exercise to Capita and security control to G4S.

Everything will be fine.

Apr 01 2013

Debian iz free operatin sistem (OS) 4 ur computr

For a moment today I had the awful feeling that the debian website had been compromised by an illiterate 14 year old. The front page had been changed debian-01-04-13and contained such pearls as: “Debian providez moar than pure OS: it comez wif ovar 29000 packagez” and “Peeps hoo use sistems othr than Intel x86 shud check teh ports secshun.”

And then I realised the date.

(The Grauniad has a list of others here.)

Mar 27 2013

gchq recruitment site stores plaintext passwords

I can’t resist this. El Reg today points to a blog post by a guy called Dan Farrall who has commented on his experience of receiving a plain text reminder of his GCHQ recruitment site password by email after filling out its forgotten password form.

Farrall’s blog post is worth reading. Whilst he acknowledges that the recruitment site is likely to be run by a third party, he rightly points out that their security practices should still have been audited by GCHQ.

At the minimum, this is embarassing for the guys in the doughnut. You’d expect GCHQ to have higher standards than the BCS.

Mar 26 2013

using an ssh reverse tunnel to bypass NAT firewalls

There is usually more than one way to solve a problem.

Back in October last year I wrote about using OpenVPN to bypass NAT firewalls when access to the firewall configuration was not available. I have also written about using ssh to tunnel out to a tor proxy. What I haven’t previously commented on is the ability to use ssh to set up reverse tunnels. By this I mean the capability to set up an outbound connection from one machine to a remote machine which can then be used as a tunnel back from the remote machine to the original.

You might ask why on earth anyone would want to do that. In fact this is a very useful trick. If we think back to the problem outlined in my october post, we were faced with the requirement to connect from a client machine on one network to a remote host on another network which was behind two NAT firewalls. The scenario was as below:

openvpn-scenario

As I said in my previous post, ordinarily all we would have to do is run an SSH daemon (or indeed openVPN) on Host A and set up port forwarding rules on routers A and B to forward the connection to that host. But in the case we were considering, the owner of Host A was not able to set up the requisite port forwarding rules on the outermost router (because he didn’t own it). Indeed, this scenario is quite common in cases such as mobile data connections where the client device (say your smart phone or tablet) is given an RFC 1918 reserved address by the telco and is firewalled (often transparently) from the real internet by their NAT proxy.

We previously tackled this problem by setting up an intermediary openVPN server on a cheap VPS and using that as a relay between the two devices. However, ssh allows us to set up a reverse tunnel directly to the machine marked as “client” from the machine marked as “Host A” in the diagram above. We could, of course, also set up the tunnel to the VPS as an intermediate if we so desired. This might be necessary in cases where we don’t have access to router C for example and cannot configure inbound port forwarding there either.

Again, here’s how to accomplish what we want, this time using ssh.

On “client” (or the intermediary VPS) ensure that we have an unprivileged user such as “nobody” who has no login shell but does have a valid password. I set the shell on all unused accounts to /bin/false anyway, but you may choose otherwise. The sshd daemon itself uses /usr/sbin/nologin. The nobody account does not need a shell because we are only using it to set up the tunnel, not to actually login to the remote machine. Of course the “client” machine must have an ssh daemon listening on a port reachable by “Host A” or the initial tunnel connection will fail.

Host A must also have an ssh daemon listening in order to accept the back connection. Note that this latter daemon must be listening on “localhost” as well as the machine’s external IP address. This can most easily be accomplished by setting “ListenAddress 0.0.0.0″ (rather than say, “ListenAddress 192.168.3.12″) in Host A’s /etc/ssh/sshd_config file. Localhost is necessary because that is the address on which Host A will see the incoming connection over the tunnel when it is established

Now on “Host A” open the tunnel to “client” thus:

ssh -N -f -R 2020:localhost:222 nobody@client

Here -N means no command at the remote end, i.e we are simply tunnelling; -f means background the process; -R means remote (or reverse); then listen on port 2020 on localhost on the client and connect back to port 222 on Host A). Note that nowhere in this command do we specify the ssh port used by the daemon on “client”. That is taken care of by default by ssh itself (ssh will assume port 22 unless we have changed that behaviour by modifying the port for “client” in /etc/ssh/ssh_config or a local .ssh configuration). Alternatively we could add the -p switch, followed by the requisite port number, to the above command line. Port 222 is the port on which the ssh daemon on Host A listens. Port 2020 can actually be any port which is currently unused on the “client” machine. Pick a port above 1024 to avoid the need for root privileges.

On running the command above we should be prompted for “nobody’s” password on the machine “client”. After supplying the password we will be returned to the command line on Host A. Now we can check that we have actually opened a connection by running netstat where we should see an established connection to ssh on the remote machine.

On the remote machine called “client”, we should similarly see the established ssh connection from Host A, but we should also be able to see a new ssh process listening on port 2020 on localhost. It is this process listening on port 2020 that allows us to connect back to Host A.

Now that we have an open tunnel, we can connect from “client” to “Host A” thus:

ssh -p 2020 localhost

This will default to the user we are currently logged in as on “client” and we will be prompted for the password for that userid “@localhost” (actually, the password for that user on Host A). Of course, if we wish to specify a different user we could add the “-l userid” switch to the ssh command line. If the password is accepted we will now be logged in to “Host A” from “client” and we have completely bypassed the NAT firewalls.

I strongly recommend that you do not attempt to use this mechanism (or openVPN) to circumvent a corporate security policy unless you wish to jeopardise your career.

Mar 13 2013

impolite spam

Most blogs get hit by spammers aiming to get their URLs posted in the comments section. Like most wordpress based blogs, I use the default Akismet antispam plugin. I don’t like it, I don’t like the fact that it is shipped by default, I don’t like the fact that it is increasingly becoming non-free (as in beer), I don’t like the way my blog has to call home to Akismet servers. I particularly don’t like the way that all comments (including the genuine ones) are thus passed to Akismet servers, giving them the IP and email addresses of my commenters (which is another good reason for you to lie to me and use an anonymising service to mask your IP address. But Akismet has the one huge redeeming factor that it works. It stops a vast amount of crud from reaching my blog.

However, some still gets through and hits my moderation queue (I will never allow unfettered commentary on trivia). Most of the stuff that does get through has fooled the Akismet filters by using vaguely plausible (if usually ungrammatical) phrasing. Typical comments are bland, generic staments along the lines of “Nice blog, interesting discussion I have bookmarked this for later and will tell all my friends about you”. That comment will then have a URL somewhere which points to a site flogging knock-off chinese imitations of western luxury goods (or porn, though this is becoming less frequent).

I was therefore delighted to find the following in my queue a couple of days ago:

“The next time I read a weblog, I hope that it doesnt disappoint me as much as this one. I mean, I know it was my option to read, but I in fact thought youd have some thing fascinating to say. All I hear is really a bunch of whining about some thing that you could fix when you werent too busy seeking for attention.”

Way to go. Having managed to get through a spam filter and hit my moderation queue, the poster then shoots him or herself in the foot by insulting me.

No way will I post that……

Feb 28 2013

touching update

I have recently upgraded the internal disk on my main desktop from 1TB to 2TB. I find it vaguely astonishing that I should have needed to do that, but I do have a rather large store of MP4 videos, jpeg photos and audio files held locally. And disk prices are again coming down so the upgrade didn’t cost too much. One noticable improvement following the upgrade is the reduction in noise. The disk I chose is one of Western Digital’s “Green Desktop” range which is remarkably quiet. Thoroughly recommended. But the point of this post is the consequence of the upgrade.

In order to minimise disruption after installation of the new disk (and of course a fresh install of Mint) I simply slotted the new disk into a spare slot in the PC chassis and hooked it up to the SATA port used by the old disk. I then hooked the old disk up to a separate spare SATA port. (I could, of course, have changed the boot order in BIOS to achieve the same effect.) Having installed Mint, I then rebooted the machine from the old disk for one final check of my old configuration before copying my data from old-disk/home/mick to new-disk/home/mick. Despite the fact that my data occupied over 900GB, the copy went reasonably quickly and painlessly – one of the advantages of a disk to disk copy over SATA, even if it is only SATA 2.0 (3Gb/s) – (Note to self. Next build should include SATA 3.0).

However, what happened next certainly wasn’t quick. In my haste to copy my old data and get back to using my PC, I stupidly forgot to preserve the file attributes (-p or -a switch) in my recursive cp. This meant of couse that all my files on the new disk now had a current date attached to them. Worse, I didn’t immediately notice until I came to backup my desktop to my NAS. I do this routinely on a daily basis using rsync in a script like so:

/usr/bin/rsync -rLptgoDvz –stats –exclude-from=rsync-excludes /home/mick nas:/home/mick-backup

Guess what? Since all my desktop files now had a current modification time, rsync seemed to want to recopy them all to the NAS. This was going to take a /lot/ longer than a local cp. So I killed it so that I could figure out what had gone wrong (that didn’t take long when I spotted the file timestamps) and could find a simple fix (that took longer).

Now I had thought that rsync was smart enough to realise that the source and destination files were actually the same, regardless of the file timestamp change. Realising that I didn’t actually know what I thought I knew about rsync I explained to colleagues on the ALUG mailing list what I had done and sought advice. They didn’t laugh (well not publicly anyway) and a couple of them offered very helpful suggestions to sort my problem. Wayne Stallwood first pointed out that “the default behaviour for rsync is to only compute file differences via the checksums if the modification dates between source and destination indicate the file has changed (source is newer than the destination) So it’s not actually recopying everything (though if things like permissions have changed on the source files they will now overwrite those on the target and naturally the timestamps will be updated). Previously when you ran your backup it would have just skipped anything that had the same or older timestamp than the target.”

So, what I saw as a possibly very long re-copy exercise was actually rsync comparing files and computing checksums. Needless to say, that computation on a fairly low powered NAS was going to take a long time anyway. And besides, I didn’t /want/ the timestamps of my backups all changed to match the (now incorrect) timestamps on my desktop. I wanted the original timestamps restored.

Then Mike Dorrington suggested that I could simply reset the timestamps with a “find -exec touch” approach. As Mike pointed out, touch could be made to use the timestamp of one file (in this case my old original file on the 1TB disk) to update the timestamp of the target file without any need for copying whatsover. But I confess I couldn’t at first see how I could get touch to recurse down one filetree whilst find recursed down another. Mark Rogers put me out of my misery by suggesting the following:

cd /old-disk/home/mick

find . -exec touch /new-disk/home/mick/\{\} –reference=\{\} –no-dereference –no-create \;

I think this is rather elegant and it certainly would not have occurred to me without prompting.

Jan 25 2013

now that is what an isp should be like

In my post about the astonishing speed of the DigitalOcean network compared to the appalling service I was getting at ThrustVPS, I mentioned that the free bandwidth model didn’t look sustainable in the long run. Indeed, DigitalOcean told me themselves that they would move to a more normal commercial model when they had a better idea of their customer profile. So I was fully prepared to be told eventually that the good times were over and I should now expect to pay a lot more for my traffic. Regardless of that though, I intended to stay in Amsterdam because the network was so refreshingly fast.

Today I was delighted to receive an email from DigitalOcean telling me that as an early customer they had “grandfathered” me in to their new commercial arrangements on the same terms as I orginally signed up to – i.e. free bandwidth forever. Not quite believing my luck I asked for clarification – particularly whether that meant my account as a whole, or just the current VM. My reason for asking was that I am about to create two new VMs with them following their upgrade of the basic $5.00 pcm offering to 512MB RAM and 20 Gig of SSD disk space. I will use the first new VM to move my new tor node and the second to replace my tails mirror (which eats about 900 GiB pcm on the slow, unreliable Thrust network).

They replied:

It’s true, since you have an older account you have unlimited bandwidth for your full account, meaning every droplet you create is set to unlimited bandwidth too!

Now /that/ is what I call service. And a truly fantastic committment from DigitalOcean.

So, if you want a fast VM on a /really/ fast network. Take a look at DigitalOcean. Even without the bandwidth allowance I have, they are still astonishing value for money.

Jan 14 2013

a long time ago in a galaxy far far away

The ascii art in sl was quite cute, this is far more elaborate.

star-wars

To see it in action, telnet to towel.blinkenlights.nl.

Why waste your time browsing rubbish websites – fire up a terminal session and waste even more time with telnet. More fun places to try can be found at telnet.org.

Jan 13 2013

what a difference a gig makes

During the new year period when I was having a little local difficulty with thrustVPS, I started looking around for alternative providers. My first port of call was lowendbox. That site lists many VPS providers and is often used by suppliers to advertise “special deals” for short periods. Indeed, I think I intially found thrust (or damnvps as it then was) on that site. My criteria were: UK based, cheap, high bandwidth, with a choice of OS. I prefer debian but many providers offer only Centos or a limited choice of sometimes outdated distros (ubuntu 8.04 anyone?). Disk capacity is not an issue here – tor won’t use it and my tails mirror will only need enough storage for some recent .iso images.

I much prefer a virtualisation product which will allow me to fully update the OS (including kernel) so that means I tend also to look for Xen in preference to openVZ. Other than that the spec should include a minimum of 256 Meg of RAM (not shared or “burstable”) and a reasonable share of a decent processor. Even given that requirement, there is still a range of offerings around for anywhere from £5.00 to £10.00 pcm. Since I effectively give both services away, I’m prepared to pay a reasonable sum, but I like cheap :-)

Crucially however, the supplier must allow tor on his network. This tends to reduce the choice. Many ISPs don’t like tor, particularly if you operate an exit node. In my experience, it’s not the bandwidth consumption they object to, more the time they have to devote to answering dumb, often automated, “abuse” complaints from others. One of the main reasons I have tended to favour a UK operation is that they seem more tolerant (and understanding) of how tor operates than some competitors overseas. And I really don’t need the aggravation of dealing with a US based DMCA takedown complaint routed through a US provider.

But for the last six months or so, I’ve only operated a relay node. With no exit permitted, I can’t be implicated in any so-called abuse, so both my provider and I get a quieter life but I still provide resources to tor. This means that I could probably afford to look more widely and perhaps source a VPS in another country. The US is particularly well served with cheap offerings, but I still confess a prejudice towards european data centres. Since I already have three VPSs in the UK, perhaps one, or maybe two in mainland europe might be useful.

Whilst I was checking a variety of potential new suppliers, I also checked with the tor-relays mail list for recommendations. One of the suppliers I was pointed to was a relatively new startup called DigitalOcean. Their offering (256 Mb RAM, 1 core, 20 Gig disk, and totally free bandwidth on a 1 Gig network) seemed astonishingly good. One guy on the list reported that he had transitted 15 TiB in one month on a server on their network. Whilst they are US based, DigitalOcean also offer servers in Amsterdam, so of course I just had to try them out. Boy are they fast.

Although they offer you a free trial for a few hours, I figured I could afford $5.00 (or less than £3.20 at current exchange rates) for a month’s trial. At the time of writing (13 January) I have been up just over 12 days and have transitted 3.57 TiB through one of their cheapest servers. My vnstat stats today show:

vnstat-13-01-13

for a total of around 1200 established tor circuits. My top statistics report:

top-stats-13-01-13

So I am ticking over quite healthily and shipping a very useful traffic load at just under 25 Mbit/s. Astonishing.

For comparison, a few days ago (on the 4th of January during early testing) I took snapshots of both my existing tor server with thrust and the new one at digitalocean. The image below compares the iptraf stats for each server (digitalocean at the top).

vm-comparison-1

This second image compares the vnstat stats at the same time.

vm-comparison-2

Note that both vnstat and the iptraf snapshots show that the new server is handling around 20 times the traffic going through my thrust server.

However, there is a downside to “unlimited” bandwidth (and besides, it won’t really be unlimited forever). Tor is voracious and will happily use all available resource on a server which does not throttle its connection rate. In early testing I did not set any bandwidth limits on tor. After just a few days I was running at around 35 Mbit/s for over 1600 tor circuits and tor was complaining “Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy.” So I started to explore options which would give the maximum freedom to tor without overloading the VPS.

As an aside, I should say that the “MaxAdvertisedBandwidth config option” doesn’t actually do what the tor manual suggests it should, so setting it in the configuration file is practically useless. However, I found a useful post on the tor-relays archive which suggested that I should advertise a CPU limit (“NumCPU 1″) and set “MaxOnionsPending 250″ (up from the default 100) since this would reduce the load on my server of a backlog of “onionskin queue overflows” (apparently often caused by a tor node being temporarily chosen as the best route to a hidden service). For a while, this worked – well at least the log messages went away, which may not actually mean the same thing. A couple of days later however, tor died with no entry in the logfile to explain why.

On further exploration, I found entries in the kernel log of the form “tor invoked oom-killer” followed by details of processes which had been killed as a result, so clearly we were running out of memory. Eventually tor itself died. Time to start setting some bandwidth limits.

I started fairly high (BandwidthRate 4 MB with a burst capability to 4.2 MB) and gradually wound it down over a period of two or three days as I watched top stats and log files. Whilst the VPS eventually seemed able to handle a traffic load of around 2 MB (that is each direction) I finally settled on 1.5 MB with a burst capability of 1.8 MB in the interests of both long term stability and fairness on the VPS providers – after all, $5.00 a month is peanuts for a total traffic load of nearly 9 TiB for that same month.

When first signing up to the trial at digitalocean I had specifically asked if they were happy with a tor node. The answer I got suggested that they would be happy with a transit relay, but less happy with an exit node. Not an unusual response. Following my early testing I decided it might also be smart to ask them if they really didn’t mind my using all that bandwidth for only $5.00. After all, it would be better to find out their actual stance in advance if I were to contemplate a long term service arrangement. They were candid in their reply, which I can summarise as: “it’s OK at the moment, but we are just building our service and the free bandwidth model won’t last. We will be charging in future. We just don’t know details yet”.

So, I’ll stick with them during this phase and see what they come up with. Whatever it is, on a network that fast, and a VPS that cheap, it looks worthwhile my keeping a presence in Amsterdam.

Older posts «