[GLLUG] Server in London

Andy Smith andy at bitfolk.com
Fri Oct 11 08:19:38 UTC 2019


Hi Axel,

I run a hosting company that has already been mentioned in this
thread, so there may be bias, but I will try to be objective.

The main issues with colocation in your situation are:

- It's overkill for your needs. You can't easily rent less than 1
  rack unit (https://en.wikipedia.org/wiki/Rack_unit) but the amount
  of compute that you can fit into 1RU is immensely more than what
  you need based on your comments here. That makes it a waste of
  money and power.

- It leaves you with some hardware whose life cycle you need to
  manage. That is, it can break, it will become obsolete after less
  than 10 years, so you've got to replace it or bits of it, which
  needs human interaction, which is expensive.

- Maybe the physical management of pieces of computer hardware at a
  distance is a new skill you'll need to learn, which possibly won't
  be that useful for any other area of your life.

You say that you need the hardware to be in London, but almost
anywhere in Western Europe is only a few ms away from London, and
even East coast USA is only 60–70ms (round trip time).

I love London, I live in London, I run a hosting company based in
London, but London is not necessarily always the best place to host
servers in. It's expensive compared to a lot of other places, and
Brexit may leave you in a difficult position with regard to the
storage of personal data.

So, first of all I would never recommend colo for your uses. You are
too small a player for it to make sense. You should only do it if
you need absolute control over the specification and ownership of
the hardware, and possibly if you have some security objections to
the other options.

Renting the hardware from the hosting company will be a lot cheaper,
gets around several of the issues above, and may be viable for what
you want. This is called a "dedicated server". You could rent one in
Germany from the likes of Hetzner, and that would be astoundingly
cheap, and I expect it would work fine for you from anywhere in
Western Europe. Hetzner has a bit of a spam problem so if you intend
to send email to third parties then you may wish to rethink that
one due to aggressive blocking.

It may be tempting to go even cheaper and rent from the likes of OVH
(probably have a location in London, certainly multiple in Europe).
Unfortunately OVH have a huge spam problem that they don't appear to
be bothered about, so this is anti-recommendation for OVH for any
purpose, for this reason. If you don't care that they deliberately
choose to not tackle their spammer problem, and you yourself don't
need to send email, they will probably work out just fine for you.

I know that Mythic Beasts is a good quality hosting company based in
Cambridge but hosting out of London for a good while now. They'll
sell you colo or dedicated servers or virtual servers but it won't
be bargain basement.

Virtual servers could be just what you need. You get full control of
your OS, but you're sharing hardware and the hardware is someone
else's problem.

Good London-based virtual server providers include Mythic Beasts and
Portfast. I'd have previously included Bytemark, but they were
recently sold to iomart group. I have no personal experience of any
of those, that's just what I've heard from others.

Linode is a really big name in virtual servers and they have a
datacentre in London. If they do what you want then they are a
decent offering, but you will be one customer amongst millions so
the customer service can sometimes be lacking. That is from personal
experience as despite them being a competitor to me, I do use Linode
for some out-of-UK things.

Digital Ocean is also a big name in virtual servers and likewise
have a London datacentre, I also have to give an anti-recommendation
here though, as they too have a huge spammer problem that they have
no interest in resolving.

You hint at not wanting to go the virtual server route because of
concern for the safety of your data. I think that looking at it this
way is a bit of a mistake; the correct response to concern over your
data is to have good backups of your data.

If your data is on a physical machine that you own, it can still be
stolen or destroyed. You can make an error, your software can make
an error, the hosting company can make an error, it can all go up
in flames. The hosting company can go bankrupt and leave you with no
easy physical access to your property. That would get resolved
eventually, but that would be small comfort in the intervening time.

No, even with colo, you need good off-site backups. Treat that as an
absolute requirement and then it influences your other choices.

As far as security goes, there are some weaknesses with dedicated
servers and with virtual servers.

With dedicated servers, since it's not your hardware you don't know
if it has some malicious gadget attached to it that allows someone
to snoop on your data. Of course, technically you don't know if the
hardware you buy off the shelf has that either, since so much of the
innards are black boxes. It's a question of probability. If you're
just some random person it's very unlikely that there's any spy
gadgets in hardware that you buy, and it's still really unlikely
that there are any spy gadgets in hardware you rent. If you are
Edward Snowden then maybe the odds change.

Note that if a malicious actor with sufficient resources has
physical access to your hardware then they will eventually get
access to your data. This is harder with bare metal hardware that
you own, but it can still be done.

With virtual machines, someone who is root on the real hardware can
read your memory and block storage without you knowing. So that's
staff of the hosting provider, legal orders to the hosting provider,
and those who may compromise the hosting provider.

Encrypting the storage goes a long way (e.g. with LUKS as is common
on Linux). If the hardware then gets seized, the attacker can't just
read your data. Technically an attacker with access to the memory of
the machine can read the LUKS key out of kernel memory and access
the data.

This has been done with real hardware by reading the memory DIMMs
but it's really very tricky so unless you feel you are the target of
state-level actors who are going to burst into a machine room, throw
your RAM sticks in a freezer and then try to read data back off them
in the limited time before the traces fade, owning your own hardware
is very good protection here. For example there are countless
activist orgs who have had their servers seized by US three letter
agencies yet are confident that the servers just sit powered off
with no way for those agencies to access the data.

Encrypting the storage of a virtual machine still does go some way,
but as mentioned the hosting company staff can technically read the
LUKS key out of your virtual machine's memory and then use it on a
snapshot of your block device at their leisure. Exploits have been
shown for KVM, and they probably exist for Xen too though the Xen
developers I have spoken to about this claim to have never seen one
(they don't deny it's possible).

With virtual machines, if your storage isn't encrypted then hosting
company staff or anyone operating at their privilege level can look
through it without your knowledge. Without disk encryption you rely
on the policies of the hosting company to stop their staff from
doing this. I have received requests from the security services to
send them snapshots of customer disks for this purpose. If they had
sent me a court order then I would have had to do that, without
notifying the customer, as that is the law. So far, they have all
gone away when the need for a court order was mentioned, but I'm
sure it happens every day and I'm sure that most hosting companies
do not insist upon court order. Any of the ones I've mentioned I
would trust to protect you to the full extent of UK law.

Some companies employ "warrant canaries"
(https://en.wikipedia.org/wiki/Warrant_canary) to re-assure you that
they haven't been the subject of a secret order. I don't think these
would be workable under UK law, but to produce a legal opinion on
that would require either original research (costs £££) or else
direct experience of being prosecuted for trying, which would be
Exciting, and personally I am not up for that level of expense or
Excitement.

I haven't yet said anything about the various CPU speculation
security bugs like Meltdown (
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) ),
Spectre (
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) ) and
related. Since with virtual hosting you have multiple different orgs
executing code on the same CPU, there is particular worry for the
virtual server world.

My view is that it shouldn't really turn people away from virtual
servers unless their security needs are very high, in which case
you'd have to question if they should be on any kind of public
platform at all.

Most of these class of bugs don't have exploits that are publicly
known, some don't even really have strong proofs of concept.
Certainly it is for the hosting company to be aware of and keep up
to date with mitigations and new CPU firmware. We (hosting
companies) might have to give up on simultaneous multithreading
(Intelspeak: hyperthreads) for the foreseeable future as OpenBSD
have done
(https://undeadly.org/cgi?action=article;sid=20180620110722). As
long as the hosting company is on top of it I don't think it's
really for end users to worry about beyond keeping their own
software updated.

So, hopefully that was some useful information which you can
incorporate to help make your choice. In your position I would go
with a virtual server perhaps from one of the companies mentioned by
me or others. If I had to rule out VMs for some reason then I'd
probably rent a cheap dedicated server from Hetzner.

I don't think colo is a good idea for you, but if you had to do that
then there's my current supplier Jump Networks:

    http://www.jump.net.uk/colo

or Mythic Beasts again.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



More information about the GLLUG mailing list