How we keep your VPS isolated
The firewall that sits in front of every VPSNine server, what it stops your neighbours from doing, and what we still have to test.
On a VPS you share a physical machine with strangers. KVM keeps your memory and disk to yourself. The network is a different story, and it's where cheap hosting tends to cut corners.
This post covers what sits between your server and the others on the same machine, and the parts we haven't proven yet.
The problem
Every VM on a host plugs into the same virtual network. Out of the box, a VM can do some rude things there. It can send packets claiming to be from someone else's IP address. It can announce itself as an IPv6 router, so its neighbours send their traffic through it. It can talk directly to the VM next door at layer 2, below anything your own firewall sees.
None of that needs a clever exploit. A few lines of config will do it, or a compromised server that someone else forgot to patch.
What we do about it
Each VM gets its own firewall rules on the host, outside the VM, where nothing inside it can switch them off.
Spoofed addresses
The rules pin each VM to its MAC address, its IPv4 address and its IPv6 address. Packets claiming to come from anything else are dropped before they leave the host. So nobody can spoof your IP, and you can't spoof theirs.
Fake IPv6 routers
IPv6 has a few message types that let a machine say "I'm the router" or "that address is me". On a shared network those are an invitation to hijack someone's traffic. We drop router announcements from VMs entirely, and neighbour announcements for any address that isn't theirs. That includes the sneakier fragmented versions some filters miss.
Layer 2
VMs can't see each other at layer 2. Each VM's port on the virtual bridge is isolated. Traffic between two customers on the same machine has to go through the host's routing, like traffic from anywhere else, rather than straight across.
Unknown ports
If a VM's network port isn't one the firewall knows about, its traffic is dropped.
Port 25
Outbound port 25 is closed unless we've opened it for your server after a review. That's the spam rule; Sending email: port 25 explains it.
Boot order
A firewall that loads a few seconds late is a firewall with a gap in it. When a host reboots, its VMs come back up automatically. If they start before the rules are in place, there's a moment with no protection at all.
So the rules load at boot before any VM is restored. They load again when our agent starts, and again before every single VM start. If the rules can't be loaded, VMs don't start. We'd take a few minutes of downtime over running your server next to an unfiltered neighbour, which you'd never notice.
What we haven't tested yet
The rules and the boot ordering are checked by automated tests on our development machines. That's not the same as real packets on real hardware.
Before we take a single order, we'll test the firewall with actual traffic between VMs on our first real server, reboot it with VMs on it to watch the ordering, and try the spoofing tricks above ourselves to make sure they fail.
There was also one gap we knew about: if the firewall was reloaded on the host itself, our rules could drop out until the next VM start or agent restart. The agent now checks every minute that its rules are still loaded, and loads them again if they aren't.
What's still your job
All of this protects you from your neighbours, and them from you. It doesn't protect your server from the internet. You still want a firewall inside your VM, SSH keys instead of passwords, and updates switched on. The first-hour checklist covers that in about an hour.