Operational Security is often misunderstood. Many setups claim to be “secure” while still exposing public IPs, leaking metadata, or relying on provider abstractions they do not control.
This article documents a server architecture designed around one core principle:
Assume that something will eventually leak – and design the system so it does not matter.
This is not about offensive security or illegal activity.
It is about defensive infrastructure design, minimizing attack surface and metadata exposure.
What OpSec Means in Practice
OpSec is not a single tool or configuration.
It is the result of multiple layers working together:
- Encryption at rest
- Strict network isolation
- Controlled ingress and egress
- Explicit trust boundaries
- Minimal metadata exposure
If any of these layers is missing, the system leaks information.
Threat Model
This setup is built for realistic scenarios encountered by administrators and operators:
- Accidental exposure of a server IP
- Service compromise on a single VM
- Provider access to powered-off hardware
- Physical seizure of a server
- Metadata analysis via storage or backups
This architecture does not attempt to defend against nation-state attackers or live memory forensics.
That requires a fundamentally different operational model.
Base System: Bare Metal and Manual Installation
The foundation is a dedicated bare metal server.
No VPS. No managed cloud layer.
Reasons:
- Full control over storage layout
- No hidden metadata services
- No provider snapshots
- Predictable hardware behavior
The operating system is installed manually using a standard Debian installer.
Full Disk Encryption with LUKS
The entire system disk is encrypted using LUKS at install time.
This includes:
- The operating system
- Proxmox installation
- VM disk storage
- Swap and temporary data
LUKS is not used to protect individual files.
It is used to protect the entire block device.
If the system is powered off:
No data, metadata or structure is readable without the encryption key.
Why Metadata Protection Matters
Without full disk encryption, an attacker or provider can still see:
- VM names and identifiers
- Disk sizes and allocation patterns
- Snapshot trees
- Backup schedules
- Usage timelines
Even if application data is encrypted, this metadata is often enough to profile workloads.
For this reason, the following are avoided:
- Directory-based VM storage
- ZFS outside of LUKS
- Provider-managed backups or snapshots
Storage Layout: LVM inside LUKS
VM disks are stored as logical volumes inside the encrypted container.
Benefits:
- All VM data is encrypted transparently
- No filesystem-level metadata leakage
- Simple and auditable layout
- Predictable performance
ZFS is intentionally not used in this design due to metadata visibility outside the encryption layer.
Proxmox as a Controlled Hypervisor
Proxmox is used as a local control plane, not as an automation layer.
Deliberately avoided features:
- Cloud-init templates
- Preconfigured images
- Automatic SSH key injection
- Provider-specific integrations
Every VM is installed from ISO.
If a service exists, it exists because it was explicitly created.
This reduces implicit trust and hidden configuration.
Network Architecture: Default Deny
The network is designed with a strict default-deny philosophy.
Core rules:
- No public IPs on service VMs
- No direct internet access to internal services
- No exposed management interfaces
The host firewall blocks all inbound traffic by default.
VPN Ingress VM
All access to the infrastructure happens through a single VPN ingress VM.
Characteristics:
- WireGuard-based
- Strong cryptographic authentication
- No password-based logins
- Minimal attack surface
Access flow:
Client → WireGuard → VPN VM → private VM network
There is no SSH access to the host from the internet.
Separation of Ingress and Egress
Ingress and egress are treated as separate concerns.
Ingress
- Authenticated VPN access
- Controlled entry point
- No service exposure
Egress
- Optional external VPN provider
- Prevents IP correlation
- Masks traffic origin
Even if the server IP becomes known, it is not the IP used by services.
Service VM Isolation
Each service runs in its own VM or container with:
- Private networking only
- Explicit firewall rules
- Minimal allowed egress
- No unnecessary inter-VM communication
If one service is compromised, lateral movement is limited by design.
Optional Hardening Measures
Depending on operational needs:
- Self-hosted DNS resolver
- Strict outbound firewalling
- Tor onion services instead of clearnet endpoints
- Edge DDoS protection if public access is required
- Minimal local-only logging
These measures enhance an already secure base but cannot compensate for poor architecture.
What This Architecture Does Not Solve
- Live RAM extraction
- Unlocked system forensics
- Hardware-level implants
Those scenarios require operational controls beyond infrastructure design.
Why This Works
This setup is effective because it is:
- Predictable
- Auditable
- Boring
- Hard to misuse
Most real-world security failures stem from convenience shortcuts.
This design removes the shortcuts entirely.
If something breaks, it breaks visibly.
If something is exposed, it was exposed intentionally.
This is defensive OpSec through architecture, not obscurity.