VPS Security Model

Virtual Private Servers (VPS) on tasmanian.cloud provide customers with isolated compute resources. This document outlines the security model, threat boundaries, and protections in place for VPS instances.

---

Security Goals

The VPS security model aims to provide:

• Isolation — Complete separation between customer VMs and the hypervisor/other tenants
• Confidentiality — Customer data within VMs cannot be accessed by other tenants or infrastructure operators
• Integrity — VM state cannot be tampered with by unauthorized parties
• Availability — VMs remain accessible via VPN and console even under attack
• Sovereignty — Customer data remains within Tasmanian jurisdiction

---

Threat Model

In Scope (Threats We Protect Against)

• VM escape attempts — Malicious code attempting to break out of the VM to the hypervisor
• Side-channel attacks — Spectre, Meltdown, and similar CPU vulnerabilities between tenants
• Network eavesdropping — Interception of traffic between VMs on the same host
• Resource exhaustion — DoS attacks consuming CPU, memory, or disk resources
• Snapshot tampering — Unauthorized modification of VM snapshots
• Live migration attacks — Interception or manipulation of VM migration traffic
• Console access abuse — Unauthorized access to VNC/SPICE consoles
• Metadata service exploitation — Attacks against cloud-init metadata endpoints
• Neighbor noise — Performance impact from "noisy neighbor" VMs

Out of Scope (Threats We Do Not Protect Against)

• Guest OS compromise — If the customer's OS is compromised, we cannot protect the VM
• Application-level vulnerabilities — SQL injection, XSS, etc. in customer applications
• Weak customer credentials — Brute force of SSH passwords or leaked keys
• Customer data exposure — Misconfigured services exposing data on private networks
• Physical hardware attacks — Cold boot attacks, physical access to servers
• Supply chain attacks on guest images — Compromised OS images uploaded by customers
• Cryptographic breaks — Failure of VM encryption or TLS
• Insider threats with hypervisor access — Root access to Proxmox bypasses VM isolation
• Network attacks outside our infrastructure — Compromise of customer's VPN endpoint

---

External Threat Overview

Architecture Components

┌─────────────────────────────────────────────────────────────────┐
│                    Proxmox Hypervisor                           │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                    KVM/QEMU                             │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐     │   │
│  │  │   VM 1      │  │   VM 2      │  │   VM 3      │     │   │
│  │  │ (Customer A)│  │ (Customer B)│  │ (Customer C)│     │   │
│  │  │ 10.0.40.10  │  │ 10.0.40.20  │  │ 10.0.40.30  │     │   │
│  │  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘     │   │
│  │         │                │                │             │   │
│  │  ┌──────▼────────────────▼────────────────▼──────┐     │   │
│  │  │         Virtual Switch (OVS/VLAN)             │     │   │
│  │  │    VLAN 40: Customer Network (isolated)       │     │   │
│  │  └──────┬────────────────────────────────────────┘     │   │
│  └─────────┼───────────────────────────────────────────────┘   │
│            │                                                    │
│  ┌─────────▼───────────────────────────────────────────────┐   │
│  │              Network Bridge (vmbr40)                     │   │
│  │         Physical NIC with VLAN tagging                   │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
            │
            ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Core Switch                                │
│         Routes between VLANs, applies ACLs                      │
└─────────────────────────────────────────────────────────────────┘

Trust Boundaries

Untrusted:

• Customer VMs (guest operating systems)
• Customer applications and data
• Customer network traffic

Semi-Trusted:

• Proxmox hypervisor (access limited to operators)
• Virtual switches (isolated per customer)

Trusted:

• Physical network infrastructure
• Ceph storage cluster (encrypted)

Isolation Mechanisms

1. Hypervisor Isolation (KVM)

KVM provides hardware-assisted virtualization with:

• Intel VT-x/AMD-V — CPU virtualization extensions
• EPT/NPT — Extended Page Tables for memory isolation
• IOMMU/VT-d — Device isolation and DMA protection
• sVirt — SELinux for VM separation

┌─────────────────────────────────────────────────────────────┐
│                    Host Kernel (Trusted)                    │
├─────────────────────────────────────────────────────────────┤
│  KVM Module                                                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  vCPU 0-3   │  │  vCPU 0-1   │  │  vCPU 0-7   │         │
│  │  VM A       │  │  VM B       │  │  VM C       │         │
│  │  4GB RAM    │  │  2GB RAM    │  │  16GB RAM   │         │
│  │  EPT tables │  │  EPT tables │  │  EPT tables │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                                                             │
│  Memory: Each VM has isolated EPT (Extended Page Tables)    │
│  CPU: vCPUs scheduled independently, no shared state        │
└─────────────────────────────────────────────────────────────┘

2. Network Isolation

No inter-VM communication between customers:

# PFsense rule - drop traffic between customer VLANs
block in log quick on vlan40 from 10.0.40.0/22 to 10.0.40.0/22 \
  where source != destination

3. Storage Isolation

• Each VM disk is a separate RBD image in Ceph
• Images encrypted with LUKS (customer-managed keys available)
• No deduplication across customers (prevents side channels)

---

Internal Threat Overview

VM Lifecycle Security

1. Creation

When a VM is created via O2S:

1. Image verification — Cloud image checksum validated
2. SSH key injection — Only customer-provided keys (no passwords)
3. Network assignment — Dedicated MAC address, VLAN tag
4. Resource limits — cgroup limits enforced (CPU, memory, disk I/O)
5. Cloud-init — Metadata served over TLS with token authentication

2. Runtime

During VM operation:

• Watchdog monitoring — Automatic restart on kernel panic
• Resource quotas — Hard limits prevent DoS to other tenants
• Live migration — Encrypted with TLS 1.3 if host maintenance required
• Snapshot integrity — Checksums verified on every read

3. Destruction

When a VM is deleted:

1. Immediate termination — SIGTERM, then SIGKILL after grace period
2. Memory wipe — RAM zeroed before reallocation
3. Disk secure erase — Cryptographic erase (discard LUKS key)
4. Network cleanup — MAC address removed from ARP tables

Metadata Service Security

The cloud-init metadata service provides VM configuration:

┌─────────────────────────────────────────────────────────────┐
│                    Metadata Service                         │
│                                                             │
│  Request: GET /metadata/instance                            │
│  Headers:                                                   │
│    X-Metadata-Token: <short-lived-token>                    │
│    X-Forwarded-For: <VM IP> (enforced by firewall)          │
│                                                             │
│  Response:                                                  │
│    {                                                        │
│      "instance-id": "i-abc123",                             │
│      "hostname": "my-vm",                                   │
│      "public-keys": ["ssh-ed25519 AAA..."],                 │
│      "network": {                                           │
│        "private_ip": "10.0.40.10"                           │
│      }                                                      │
│    }                                                        │
└─────────────────────────────────────────────────────────────┘

Security controls:

• Token expires after 10 minutes
• IP-based access control (only VM can access its own metadata)
• No sensitive data in metadata (no passwords, only SSH keys)

Console Access (VNC/SPICE)

Web console access for emergency recovery:

Snapshot and Backup Security

---

Attack Scenarios and Mitigations

Scenario 1: VM Escape Attempt

Attack: Malicious customer tries to exploit KVM vulnerability to access hypervisor.

Mitigations:

• KVM is minimal attack surface (no userspace components in host)
• sVirt SELinux policies restrict VM capabilities
• Live patching for known CVEs within 24 hours
• Monitoring for suspicious hypervisor syscalls

Scenario 2: Side-Channel Attack (Spectre/Meltdown)

Attack: Attacker tries to extract data from other VMs via CPU side channels.

Mitigations:

• Microcode updates applied within 48 hours of release
• Kernel mitigations enabled (IBPB, IBRS, STIBP)
• L1TF mitigation: L1D flush on VM entry
• Consideration: Performance impact accepted for security

Scenario 3: Network Sniffing

Attack: Attacker tries to capture traffic from other VMs on same host.

Mitigations:

• Virtual switches don't forward traffic to unrelated MACs
• VLAN isolation prevents L2 communication
• ARP spoofing detection and prevention
• No promiscuous mode for customer VMs

Scenario 4: Resource Exhaustion

Attack: Attacker consumes all host resources to DoS other tenants.

Mitigations:

• Hard resource limits (CPU, memory, disk I/O, network)
• Fair queuing for shared resources
• Automatic throttling of abusive VMs
• Burst limits prevent short-term exhaustion

---

Security Controls Summary

---

Compliance and Certifications

---

Related Documentation

• O2S Threat Model
• Netbird VPN Threat Model
• TWN Stack Security
• Proxmox Security Guide