ROOT Cloud
Host Spotlight: Hypervisor
Virtualisation Overview
libvirt/KVM — Isolated Workloads on a Controlled Compute Host
This host provides dedicated compute for isolated workloads using KVM with libvirt orchestration. Virtual networking is managed via an internal bridge, allowing explicit segmentation between guest services while keeping management access controlled and auditable.
- Workload isolation: services run in separate guests to reduce blast radius and simplify lifecycle management.
- Virtual switching: a libvirt-managed bridge provides consistent L2 connectivity between guests where required.
- Out-of-band remote access and recovery: Hypervisor-level console access preserves administrative control independent of guest networking, firewall state, or virtual switch configuration.
- Explicit trust boundaries: routing and exposure are intentional (no “accidental public services”).
- Operational clarity: each VM has a single primary purpose with focused configuration.
Hypervisor Design & Security Controls
Host-Level Design Decisions
- VPN-bound service exposure: All host-level services are strictly bound to the WireGuard interface. The hypervisor functions purely as backbone compute within the private VPN fabric and does not expose management or application services on public interfaces.
- Minimal host footprint: The hypervisor is intentionally kept simple, running only the services required for virtualisation and orchestration. Complexity and application logic reside within guests, reducing host attack surface and simplifying auditing.
- Out-of-band management plane: Hypervisor-level console access (QEMU VNC) is bound to localhost and accessible exclusively via SSH tunnelling, ensuring recoverability even during guest networking or bridge failure.
- Controlled VM lifecycle: Guest autostart behaviour is explicitly managed, ensuring predictable initialisation order and reducing the risk of dependency-related failure during host reboots or maintenance windows.
- File integrity monitoring: A minimal, high-signal Tripwire policy monitors critical host configuration paths to detect accidental or malicious modification, with alerts integrated into the central monitoring stack.
Guest Workloads
GPG/SMB Backup Vault
Staged backup intake over SMB with immediate encryption-at-rest and off-host key custody.
Designed to protect backup confidentiality and reduce risk from partial writes and staging failures.
SMB Intake
GPG Vaulting
Integrity Controls
Bastion Server
Reverse proxy and authenticated ingress choke point for internal services.
Centralises boundary logging and provides a controlled entry layer rather than exposing services directly.
Reverse Proxy
Boundary Logging
Choke Point
Windows Server Lab
Isolated Windows Server environment used to maintain hands-on competency across AD/DNS/GPO and
validate cross-platform integration patterns without impacting production services.
AD/DNS/GPO
Integration Lab
Non-Prod
OpenBSD Gateway
Layered egress gateway enforcing PF firewall policy and NAT for selected traffic paths.
Provides a second enforcement layer separate from the host and supports ingress/egress separation patterns.
PF Firewall
NAT Egress
Defence-in-Depth
Notes/evidence
GPG Backup Script
The script shown above processes backups written to the SMB staging inbox and encrypts them using GPG before transferring them into the vault for long-term storage.
Extensive logging is intentionally built into the workflow. Each stage of the encryption and file handling process emits structured log entries, which are monitored by Zabbix to provide deterministic alerting on both success and failure conditions.
Only the public GPG key is present on the backup VM, allowing encryption but not decryption. The corresponding private key is stored entirely off-host. As a result, even a full compromise of the backup virtual machine would not grant access to backup contents.
Raw backup files exist in the staging inbox only briefly. A systemd timer executes every minute to detect and process new entries, ensuring that unencrypted backups remain on disk for a minimal window of time before being vaulted in encrypted form.
OpenBSD PF Config
The image above shows the in-progress pf.conf configuration for the OpenBSD gateway firewall. The rule set is actively being refined; for example, SSH access is currently permitted via both WG0 and WG1 for testing purposes, but in production will be restricted exclusively to WG0.
The firewall operates on a default-deny posture, dropping traffic unless explicitly permitted. It leverages PF’s stateful inspection capabilities to track established connections, allowing the rule base to remain concise while still enforcing strict traffic control.
Bastion Server choke point and log aggregation
The image above illustrates a dashboard segment designed to visualise the choke-point effect provided by the Bastion server. It centralises web server logs and connection telemetry into a single, easily digestible view, enabling rapid situational awareness. The screenshot reflects a period of inactivity.
The Bastion currently operates an Nginx reverse proxy protected by fail2ban-enforced HTTP authentication and also functions as a DNS forwarder to the authoritative Pi-hole instance hosted on ROOT. It resides one DNS tier below ROOT and intentionally blackholes queries for sensitive internal domains associated with key services. This reduces the effectiveness of reconnaissance via DNS enumeration and limits information exposure at the boundary.