Deploying the Phoenix: Cloud Infrastructure and OPSEC BPP Blog

This is part 11 of the Black Phoenix Protocol (BPP) engineering blog series. Start with Day Zero if you are new here.

Up until now, we have focused entirely on the software: the cryptography, the Go code, the network sockets, and the Vue.js dashboard. But software doesn't run in a vacuum. A circumvention tool is only as secure as the server it runs on.

In this post, we shift focus from programming to Operations Security (OPSEC) and infrastructure. How do we deploy a BPP relay node without getting it flagged, shut down, or fingerprinted by the hosting provider itself?

The Illusion of the "Anonymous VPS"

Many developers assume that if they pay for a Virtual Private Server (VPS) with cryptocurrency, they are anonymous. This is a dangerous misconception.

Hosting providers (AWS, DigitalOcean, Hetzner, Vultr) monitor their networks. They have automated systems looking for:

Continuous high bandwidth utilization.
Unusual port usage.
IP addresses associated with known proxy software (e.g., if you accidentally leak a default Shadowsocks response on a port).

Furthermore, state-level actors don't just passively monitor the border firewall. They actively purchase nodes in these data centers to map out the network or subpoena providers for server images.

Hardening the Relay Node

When deploying a BPP relay, the goal is to make the server look incredibly boring. It should look like a standard, uninteresting web server running a low-traffic personal blog.

1. SSH Obscurity and Access Control

Never leave SSH on Port 22. It will be brute-forced within seconds of the server coming online.

Move SSH to a random high port (e.g., 49152-65535).
Disable password authentication completely. Use ED25519 SSH keys exclusively.
Implement Port Knocking or Single Packet Authorization (SPA): Before the SSH port even opens, the firewall (iptables/nftables) requires a specific cryptographically signed packet. To anyone scanning, the server appears completely closed.

2. Egress Filtering

A compromised proxy node is often used to launch DDoS attacks or send spam. If your BPP node starts sending SMTP traffic (Port 25) or participating in a UDP amplification attack, your provider will suspend your account immediately.

Strict iptables rules: Deny all outbound traffic by default. Only allow outbound TCP on 80/443 (for the proxy to fetch the actual web content) and DNS (UDP 53) to a trusted resolver.

3. Memory Protections and "Ghost Mode"

As discussed in Part 05, BPP has built-in anti-forensics. But we must also harden the OS:

Disable Swap: If the OS pages memory to disk, encryption keys or plaintext traffic buffers might be written to the VPS's virtual hard drive. If the provider snapshots the server, those keys are compromised. swapoff -a is mandatory.
Kernel Hardening: Applying sysctl patches to prevent kernel pointer leaks and restrict dmesg access.

Burner Infrastructure: Infrastructure as Code

The lifespan of a proxy IP address in a heavily censored region is measured in days, sometimes hours. Once an IP is blacklisted by the GFW, the server is dead weight.

You cannot afford to manually SSH in, run apt-get install, configure iptables, and compile BPP every time you need a new node. You need Burner Infrastructure.

Using tools like Terraform and Ansible, I automated the entire deployment lifecycle:

Provisioning: Terraform API call to Vultr/DigitalOcean to spin up a Debian 12 instance in a random region.
Bootstrapping: Cloud-init runs a baseline script to disable swap, harden SSH, and set up iptables.
Deployment: Ansible pushes the compiled bpp-server binary, generates fresh Curve25519 keys, and starts the service.
Destruction: When the Command Center detects that the node's IP has been blocked (via localized ping tests), Terraform destroys the instance.

The entire process takes less than 60 seconds. The servers are ephemeral. They have no persistent state, no logs, and no long-term value.

The Human Element

Finally, OPSEC is about human behavior.

Never SSH into a BPP node from your home IP address. Always use a jump box or Tor.
Never use the same SSH key for BPP nodes as you do for your personal GitHub.
Assume the provider is hostile. Assume the server will be seized.

By treating the infrastructure as hostile and ephemeral, we ensure that even if a BPP node falls, the protocol and its users remain secure.

In Part 12, I'll take a step back and reflect on the psychological and architectural challenges of building something this complex entirely alone.