In einer Zeit, in der Server-Infrastrukturen zunehmend Ziel von Angriffen werden und Datenschutz immer wichtiger wird, ist perfekte OpSec (Operations Security) nicht mehr nur für Unternehmen relevant – auch für Privatpersonen und kleine Projekte wird sie zur Notwendigkeit.
OpSec bedeutet, dass deine Server-Infrastruktur selbst bei einem IP-Leak oder anderen Sicherheitsvorfällen unsichtbar bleibt und Angreifer keine Möglichkeit haben, deine Infrastruktur zu identifizieren oder zu kompromittieren.
In diesem umfassenden Guide zeige ich dir, wie du eine hochsichere Server-Infrastruktur aufbaust, die:
- ✅ Vollständig verschlüsselt ist (LUKS auf allen Ebenen)
- ✅ Virtuell isoliert ist (Proxmox mit LVM-Storage)
- ✅ Nur über VPN erreichbar ist (keine öffentlichen IPs)
- ✅ Bei IP-Leaks unsichtbar bleibt (VPN-Exit über Mullvad)
- ✅ Zusätzliche Anonymität bietet (Crypto-Zahlungen, DDoS-Guard)
Rechtlicher Hinweis
Dieser Artikel ist keine Anleitung für illegale Aktivitäten, sondern eine technische Darstellung bekannter IT-Sicherheits- und Hardening-Konzepte.
Ziel ist es, Administratoren, Entwickler:innen und Betreiber:innen beim Schutz ihrer eigenen Infrastruktur zu unterstützen.
Wir empfehlen ausdrücklich nicht, diese oder ähnliche Konzepte zur Begehung von Straftaten zu nutzen oder sich der Strafverfolgung zu entziehen.
Was ist OpSec und warum ist sie wichtig?
OpSec (Operations Security) ist die Praxis, Informationen über deine Infrastruktur, Prozesse und Aktivitäten zu schützen, um Angriffe zu verhindern. Im Kontext von Server-Infrastruktur bedeutet das:
- Unsichtbarkeit: Deine Server sollten nicht identifizierbar sein
- Isolation: Keine direkten Verbindungen zur Infrastruktur
- Verschlüsselung: Alle Daten sind verschlüsselt, auch bei physischem Zugriff
- Anonymität: Keine Verbindung zwischen deiner Identität und der Infrastruktur
Traditionelle Server-Setups haben mehrere Schwachstellen:
- Öffentliche IPs: Jeder kann deine Server-IPs sehen und scannen
- Direkte Verbindungen: SSH, HTTP, etc. sind direkt erreichbar
- IP-Leaks: Anwendungen können versehentlich echte IPs preisgeben
- Physischer Zugriff: Bei Beschlagnahmung sind Daten lesbar
- Identifizierbarkeit: Server können mit dir in Verbindung gebracht werden
Mit perfekter OpSec werden alle diese Schwachstellen eliminiert:
- ✅ Keine öffentlichen IPs → Server sind unsichtbar
- ✅ Nur VPN-Zugang → Keine direkten Verbindungen möglich
- ✅ VPN-Exit über Mullvad → IP-Leaks zeigen nur Mullvad-IPs
- ✅ LUKS-Verschlüsselung → Physischer Zugriff nutzlos
- ✅ Crypto-Zahlungen → Keine Verbindung zur Identität
Die Architektur: Drei Ebenen der Sicherheit
Die perfekte OpSec-Infrastruktur besteht aus drei Ebenen, die aufeinander aufbauen:
- Hardware-Ebene: Dedicated Server mit LUKS-Verschlüsselung
- Virtualisierungs-Ebene: Proxmox mit LVM-Storage (alles in LUKS)
- Netzwerk-Ebene: VPN-Isolation und Anonymität
Jede Ebene schützt die darunterliegenden Ebenen und schafft eine Defense-in-Depth-Strategie.
LUKS (Linux Unified Key Setup) verschlüsselt die Festplatte auf Hardware-Ebene. Selbst wenn jemand physischen Zugriff auf den Server hat, sind die Daten unlesbar ohne das Passwort.
Proxmox mit LVM-Storage bedeutet, dass alle VM-Festplatten innerhalb des verschlüsselten LUKS-Containers liegen. Selbst wenn eine VM kompromittiert wird, sind die Daten verschlüsselt.
VPN-Isolation bedeutet, dass es keine öffentlichen IPs gibt. Alle Verbindungen laufen über VPN, und der VPN-Exit erfolgt über Mullvad, sodass selbst bei IP-Leaks nur Mullvad-IPs sichtbar sind.
Schritt 1: Hardware-Auswahl und Vorbereitung
Für perfekte OpSec benötigst du einen Dedicated Server (kein VPS oder Cloud-Instance), der folgende Anforderungen erfüllt:
- ✅ IPMI/iDRAC/iLO: Remote-Management für Passwort-Eingabe bei Reboots
- ✅ USB-Port: Optional für LUKS-Key auf USB-Stick
- ✅ Root-Zugriff: Vollständige Kontrolle über Hardware
- ✅ Keine Cloud-Provider: Vermeide AWS, Azure, GCP (zu viele Metadaten)
Wichtig: Wähle einen Provider, der Kryptowährungen akzeptiert, um maximale Anonymität zu gewährleisten.
Empfohlene Provider:
- Hetzner: Gute Hardware, IPMI/LARA/USB-Stick verfügbar
- OVH: Gute Optionen, IPMI verfügbar
- Online.net: Gute Preise, IPMI verfügbar
Hinweis für anonyme Hosting-Optionen: Falls Hetzner/OVH/Online.net ohne Identifikation nicht verfügbar sind, findest du unter kycnot.me eine Übersicht über KYC-freundliche Hosting-Anbieter, die Kryptowährungen akzeptieren und keine Identitätsprüfung verlangen.
Du hast zwei Optionen für die LUKS-Passwort-Eingabe:
Option 1: IPMI (empfohlen)
- Remote-Konsole über IPMI/iDRAC/iLO
- Passwort-Eingabe bei jedem Reboot möglich
- Kein physischer Zugriff nötig
- Nachteil: IPMI muss sicher konfiguriert sein
Option 2: USB-Stick mit LUKS-Key
- LUKS-Key auf verschlüsseltem USB-Stick
- Automatische Entschlüsselung bei Reboot
- Nachteil: USB-Stick muss physisch verfügbar sein
Empfehlung: Nutze IPMI für maximale Flexibilität, aber stelle sicher, dass IPMI selbst gut abgesichert ist (starkes Passwort, VPN-Zugang nur).
Schritt 2: Debian-Installation mit LUKS und LVM
Wichtig: Du solltest keine vom Hosting-Provider bereitgestellten OS-Templates verwenden, weil Provider-Templates keine vollständige Kontrolle über die Installation erlauben und LUKS-Konfiguration oft nicht möglich ist.
Stattdessen: Installiere Debian über ein Rescue-System oder direkt über IPMI mit einer ISO-Datei, damit du vollständige Kontrolle über die Installation hast und LUKS manuell einrichten kannst.
Hinweis: Cloud-Init ist ein Thema für VMs innerhalb von Proxmox (siehe später im Artikel), nicht für den Dedicated Server selbst.
Debian ist die beste Wahl für dieses Setup, weil:
- ✅ Stabilität: Sehr stabile Basis für Proxmox
- ✅ LUKS-Unterstützung: Native Unterstützung während Installation
- ✅ LVM-Integration: Perfekte Integration mit LVM
- ✅ Minimal: Weniger Angriffsfläche als andere Distributionen
Wichtig: Du solltest keine vom Hosting-Provider bereitgestellten OS-Templates verwenden, weil:
- ❌ Provider-Templates erlauben keine vollständige Kontrolle über die Installation
- ❌ LUKS-Konfiguration ist oft nicht möglich oder eingeschränkt
- ❌ Vorkonfigurierte Images können Backdoors oder unerwünschte Software enthalten
- ❌ Keine Garantie, dass alle Daten verschlüsselt sind
Stattdessen: Installiere Debian über ein Rescue-System oder direkt über IPMI mit einer ISO-Datei, damit du:
- ✅ Vollständige Kontrolle über die Installation hast
- ✅ LUKS manuell einrichten kannst
- ✅ Während der Installation auf die Konsole zugreifen kannst
- ✅ Das Passwort bei jedem Reboot eingeben kannst
- ✅ Sicherstellen kannst, dass alles verschlüsselt ist
Während der Debian-Installation:
- Partitionierung wählen: “Manuelle Partitionierung”
- LUKS aktivieren: Wähle “Verschlüsselte Partition erstellen”
- LVM aktivieren: Erstelle LVM-Volumes innerhalb von LUKS
- Passwort setzen: Wähle ein starkes Passwort (mindestens 20 Zeichen)
Wichtig: Das Passwort musst du bei jedem Reboot eingeben können. Deshalb ist IPMI oder USB-Stick essentiell.
Nach der LUKS-Installation:
- LUKS-Container: Enthält alle Daten verschlüsselt
- LVM-Physical Volume / Volume Group / Logical Volumes: Dienen als flexible Schicht über der Verschlüsselung
Wichtig ist hier weniger die exakte Partitionierung als das Prinzip:
Alles, was später als Storage für Proxmox dient, liegt vollständig innerhalb des LUKS-Containers.
Schritt 3: Proxmox-Installation über LUKS
Nach der Debian-Installation mit LUKS installierst du Proxmox auf dieser verschlüsselten Basis.
Entscheidend ist dabei nicht der exakte Installationsbefehl, sondern das Architekturprinzip:
Proxmox sitzt vollständig auf der bereits verschlüsselten Debian-Installation, sodass alle Metadaten, Konfigurationen und späteren VM-Disks automatisch in der LUKS-Schicht verschwinden.
Kritisch: Du musst LVM als Storage verwenden, nicht ZFS oder Directory-Storage!
Warum LVM?
- ✅ LVM-Logical Volumes liegen innerhalb des LUKS-Containers
- ✅ Alle VM-Festplatten sind automatisch verschlüsselt
- ✅ Keine zusätzliche Verschlüsselung nötig
Warum nicht ZFS?
- ❌ ZFS erstellt eigene Datasets außerhalb von LUKS
- ❌ VM-Festplatten wären nicht verschlüsselt
- ❌ Zusätzliche Konfiguration nötig
Warum nicht Directory-Storage?
- ❌ Dateien liegen unverschlüsselt auf dem Dateisystem
- ❌ VM-Festplatten wären nicht verschlüsselt
In der Proxmox-Web-Oberfläche:
- Datacenter → Storage → Add → LVM
- Volume Group auswählen: Die LVM-Volume-Group aus dem LUKS-Container
- Name vergeben: z.B. “luks-storage”
- Content-Typen: Disk image, Container
Ergebnis: Alle VMs, die du erstellst, nutzen LVM-Logical Volumes, die innerhalb des LUKS-Containers liegen. Alle VM-Festplatten sind automatisch verschlüsselt.
Schritt 4: VM-Installation ohne Cloud-Init
Cloud-Init Images sind bequem, aber für OpSec problematisch, da automatische Konfiguration manuelle LUKS-Einrichtung verhindert und keine Konsole-Zugriff während Installation möglich ist.
Stattdessen: Installiere Betriebssysteme von ISO-Dateien, damit du während der Installation auf die Konsole zugreifen kannst und vollständige Kontrolle über die Installation hast.
Cloud-Init Images sind bequem, aber für OpSec problematisch:
- ❌ Automatische Konfiguration verhindert manuelle LUKS-Einrichtung
- ❌ Keine Konsole-Zugriff während Installation
- ❌ Vorkonfigurierte Images können Backdoors enthalten
Stattdessen: Installiere Betriebssysteme von ISO-Dateien, damit du:
- ✅ Während der Installation auf die Konsole zugreifen kannst
- ✅ LUKS in den VMs einrichten kannst (optional, aber empfohlen)
- ✅ Vollständige Kontrolle über die Installation hast
- ISO-Datei hochladen: In Proxmox Storage hochladen
- VM erstellen: Hardware-Konfiguration festlegen
- ISO als CD-ROM: ISO-Datei als CD-ROM einbinden
- Installation starten: VM starten und über Konsole installieren
- LUKS in VM: Optional LUKS auch in der VM einrichten
Wichtig: Nutze die Proxmox-Konsole für die Installation. Du kannst jederzeit auf die Konsole zugreifen, um das LUKS-Passwort einzugeben.
Schritt 5: VPN-Entry-VM einrichten
Die VPN-Entry-VM ist eine spezielle VM, die als einziger Zugangspunkt zur gesamten Proxmox-Infrastruktur dient. Sie übernimmt VPN-Server (WireGuard oder OpenVPN), Firewall-Regeln für Proxmox, Routing zwischen VPN und Proxmox-Netzwerk sowie Monitoring und Logging.
Aufgaben der VPN-Entry-VM:
- ✅ VPN-Server (WireGuard oder OpenVPN)
- ✅ Firewall-Regeln für Proxmox
- ✅ Routing zwischen VPN und Proxmox-Netzwerk
- ✅ Monitoring und Logging
WireGuard ist die beste Wahl für OpSec, weil es modern, schlank und kryptografisch sauber designt ist.
Wichtiger als die konkrete Konfiguration ist aber das Konzept:
Die VPN-Entry-VM stellt ein privates Overlay-Netz bereit, in dem sich Proxmox und alle VMs befinden. Nur Clients, die sich per VPN verbinden, sehen dieses Netz – das Internet sieht idealerweise nur den vorgeschalteten DDoS-Schutz bzw. HTTP-Proxy.
Die VPN-Entry-VM muss die gesamte Proxmox-Umgebung absichern.
Konzeptionell bedeutet das:
- Standardmäßig wird alles blockiert, was nicht aus dem VPN kommt
- Nur Verbindungen vom VPN in Richtung Proxmox-Netz sind erlaubt
- Das Internet sieht maximal die eine öffentliche Seite der VPN-Entry-VM oder des vorgeschalteten Proxys
Wie du das konkret mit iptables, nftables, einer Hardware-Firewall oder einer Cloud-Firewall umsetzt, ist zweitrangig – entscheidend ist die Einbahnstraßen-Logik: Rein geht nur, wer vorher durchs VPN kommt.
Schritt 6: Proxmox-Netzwerk absichern
In Proxmox selbst musst du auch Firewall-Regeln setzen, um sicherzustellen, dass VMs nur über VPN erreicht werden können, nicht direkt aus dem Internet.
In Proxmox selbst musst du auch Firewall-Regeln setzen:
- Datacenter → Firewall → Options
- Firewall aktivieren: Enable firewall
- Input Policy: DROP (alles blockieren)
- Output Policy: ACCEPT (ausgehende Verbindungen erlauben)
Für jede VM:
- VM → Firewall → Options
- Firewall aktivieren: Enable firewall
- Regeln hinzufügen: Nur erlaubte Verbindungen
Beispiel-Regel für Application-Server:
- Action: ACCEPT
- Source: VPN-Netzwerk (10.0.0.0/24)
- Destination: VM-IP
- Protocol: TCP
- Port: 80, 443 (HTTP/HTTPS)
Ergebnis: VMs können nur über VPN erreicht werden, nicht direkt aus dem Internet.
Schritt 7: VPN-Exit über Mullvad
Der gesamte ausgehende Traffic deiner Infrastruktur verlässt dein Rechenzentrum nicht direkt, sondern geht zunächst in einen VPN-Tunnel zu Mullvad. Selbst wenn eine Anwendung „nach draußen leakt”, sieht die Gegenstelle nur eine Mullvad-IP und niemals die reale Server-IP.
Mullvad ist ideal für OpSec, weil:
- ✅ Keine Logs: Mullvad speichert keine Logs
- ✅ Anonyme Zahlung: Kryptowährungen akzeptiert
- ✅ Keine Account-Registrierung: Account-Nummer statt E-Mail
- ✅ WireGuard-Unterstützung: Native WireGuard-Integration
- ✅ Multi-Hop: Optional Multi-Hop für zusätzliche Anonymität
Wichtiger als die genaue Konfigurations-Datei ist das Routing-Konzept:
Der gesamte ausgehende Traffic deiner Infrastruktur – oder zumindest der sicherheitskritischen VMs – verlässt dein Rechenzentrum nicht direkt, sondern geht zunächst in einen VPN-Tunnel zu Mullvad.
Selbst wenn eine Anwendung „nach draußen leakt”, sieht die Gegenstelle nur eine Mullvad-IP und niemals die reale Server-IP.
Egal, ob du das mit Policy-Routing, separaten Routing-Tabellen oder dedizierten Gateways löst: Das Muster bleibt gleich –
kein Paket darf ungefiltert und ungetunnelt das Proxmox-Netz verlassen.
Schritt 8: Zusätzliche Anonymität mit DDoS-Guard oder Cloudflare
Auch mit VPN-Isolation können Anwendungen IP-Leaks haben (WebRTC-Leaks, DNS-Leaks, HTTP-Header mit echten IPs).
Lösung: Zusätzliche Layer mit DDoS-Guard oder Cloudflare (oder einem Ingress-HTTP-Proxy über VPN).
Auch mit VPN-Isolation können Anwendungen IP-Leaks haben:
- ❌ WebRTC-Leaks in Browsern
- ❌ DNS-Leaks
- ❌ HTTP-Header mit echten IPs
- ❌ Logs mit echten IPs
Lösung: Zusätzliche Layer mit DDoS-Guard oder Cloudflare (oder einem Ingress-HTTP-Proxy über VPN).
Wenn du möchtest, dass deine Seite wirklich nicht sichtbar ist, kannst du zusätzlich zu all diesen Konzepten noch Tor Hidden Services (Onion-Services) verwenden.
Damit lassen sich Anwendungen erreichbar machen:
- ✅ Ohne öffentliche IP
- ✅ Ohne VPN-Verbindung für die Clients
- ✅ Ohne Portfreigaben oder Inbound-Firewall-Öffnungen
Tor Hidden Services sind besonders nützlich, um private Admin-Panel, interne Tools oder sensible Anwendungen erreichbar zu machen, ohne sie im klassischen Internet zu exponieren.
Die Kombination aus LUKS + Proxmox + VPN-Isolation + Mullvad-Exit + DDoS-Schutz + Tor-Onion-Ebene bewegt sich sehr nah an „unsichtbarer Infrastruktur“.
Der konkrete Aufbau von Tor Hidden Services in so einer Umgebung sprengt den Rahmen dieses Artikels – das behandeln wir in einem eigenen Blog-Beitrag.
Cloudflare bietet:
- ✅ DDoS-Schutz
- ✅ CDN-Funktionalität
- ✅ SSL/TLS-Terminierung
- ❌ Nachteil: Cloudflare kennt deine Domain (weniger anonym)
Setup:
- Domain bei Cloudflare registrieren (mit Crypto)
- DNS auf Cloudflare zeigen
- Cloudflare-Proxy aktivieren
- Origin-Server über VPN erreichbar machen
DDoS-Guard ist anonymitätsfreundlicher:
- ✅ Akzeptiert Kryptowährungen
- ✅ Weniger Metadaten
- ✅ DDoS-Schutz
- ✅ Gute Performance
Setup: Ähnlich wie Cloudflare, aber mit DDoS-Guard als Provider.
Eigener Proxy über VPN bietet maximale Kontrolle:
- ✅ Vollständige Kontrolle
- ✅ Keine Metadaten bei Drittanbietern
- ✅ Custom-Konfiguration
- ❌ Nachteil: Mehr Wartung
Setup:
- Separate VM als HTTP-Proxy (z.B. Nginx, Traefik)
- Proxy über VPN mit Application-Server verbinden
- Proxy auf Provider mit Crypto-Zahlung hosten
- Domain auf Proxy zeigen
Besonders für anonyme Hosting-Optionen:
Wenn Hetzner/OVH/Online.net ohne anonyme Daten nicht verfügbar sind, bietet sich SporeStack.com an:
Ein Vultr/DigitalOcean Reseller, der auf ein Token-Modell setzt – keine klassischen Zugangsdaten, aber eine gewisse Summe muss vorab aufgeladen werden. Ideal für HTTP-Proxy-Server, die maximale Anonymität benötigen.
Für eine umfassende Übersicht über KYC-freundliche Hosting-Anbieter, die Kryptowährungen akzeptieren und keine Identitätsprüfung verlangen, findest du unter kycnot.me eine detaillierte Liste mit Privacy- und Trust-Scores.
Empfehlung: Nutze DDoS-Guard oder einen eigenen Proxy für maximale Anonymität. Cloudflare ist bequem, aber weniger anonym.
Schritt 9: Keine öffentlichen IPs verwenden
Öffentliche IPs sind das größte OpSec-Risiko, da Server scannbar und identifizierbar sind.
Mit VPN-Isolation sind keine öffentlichen IPs nötig – Server sind unsichtbar und nur über VPN-Verbindungen erreichbar.
Öffentliche IPs sind das größte OpSec-Risiko:
- ❌ Server sind scannbar und identifizierbar
- ❌ IPs können mit dir in Verbindung gebracht werden
- ❌ Geolocation zeigt Server-Standort
- ❌ Provider kennt deine Identität
Mit VPN-Isolation:
- ✅ Keine öffentlichen IPs nötig
- ✅ Server sind unsichtbar
- ✅ Nur VPN-Verbindungen möglich
In Proxmox:
- Keine öffentlichen IPs zuweisen: Nur private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- NAT über VPN-Entry-VM: Alle ausgehenden Verbindungen über VPN
- Keine Port-Weiterleitungen: Keine direkten Verbindungen von außen
Netzwerk-Struktur:
Internet
└── Mullvad VPN (Exit)
└── VPN-Entry-VM (10.0.0.1)
└── Proxmox-Netzwerk (10.0.1.0/24)
├── Application-VM (10.0.1.10)
├── Database-VM (10.0.1.20)
└── Proxy-VM (10.0.1.30)Ergebnis: Keine öffentlichen IPs, alles über VPN.
Schritt 10: Crypto-Zahlungen für maximale Anonymität
Traditionelle Zahlungen (Kreditkarte, PayPal) hinterlassen Spuren, da Bank-Transaktionen nachverfolgbar sind und E-Mail/Name mit Zahlungen verknüpft werden.
Kryptowährungen bieten Anonymität ohne Bank-Transaktionen und E-Mail-Registrierung.
Traditionelle Zahlungen (Kreditkarte, PayPal) hinterlassen Spuren:
- ❌ Bank-Transaktionen sind nachverfolgbar
- ❌ PayPal verknüpft E-Mail mit Zahlung
- ❌ Kreditkarte verknüpft Name mit Zahlung
Kryptowährungen bieten Anonymität:
- ✅ Keine Bank-Transaktionen
- ✅ Keine E-Mail-Registrierung nötig
- ✅ Pseudonyme Zahlungen möglich
Empfohlene Kryptowährungen für OpSec:
- Monero (XMR): Maximale Anonymität, standardmäßig verschlüsselt
- Bitcoin (BTC): Weit verbreitet, aber weniger anonym (Nutze Mixer)
- Ethereum (ETH): Weit verbreitet, aber weniger anonym
Empfehlung: Nutze Monero für maximale Anonymität, oder Bitcoin mit CoinJoin/Mixer.
Server-Provider:
- Hetzner: Akzeptiert Bitcoin
- OVH: Akzeptiert Kryptowährungen
- Viele kleinere Provider akzeptieren Crypto
VPN-Provider:
- Mullvad: Akzeptiert Monero, Bitcoin
- Viele andere VPN-Provider akzeptieren Crypto
Domain-Registrare:
- Njalla: Akzeptiert Kryptowährungen, anonyme Registrierung
- Viele andere akzeptieren Crypto
Best Practices für perfekte OpSec
- LUKS auf allen Ebenen: Host-System und VMs verschlüsseln
- LVM-Storage in Proxmox: Alle VM-Festplatten in LUKS
- Keine Provider-Templates: Dedicated Server über Rescue-System oder IPMI installieren
- Keine Cloud-Init für VMs: Immer ISO-Installation für VMs für volle Kontrolle
- VPN-Isolation: Keine öffentlichen IPs, nur VPN-Zugang
- Eigene DNS-Server: Eigene Resolver (z. B. PowerDNS) betreiben, statt Provider-DNS zu nutzen
- Vertrauenswürdige DNS-Quellen: Root-Server direkt, DoH-Resolver oder alternative Roots wie OpenNIC verwenden
- Mullvad-Exit: Alle Verbindungen über Mullvad
- Tor Hidden Services ergänzen: Für maximale Unsichtbarkeit zusätzlich Tor-Onion-Services nutzen
- Crypto-Zahlungen: Monero oder Bitcoin mit Mixer
- Keine Logs: Logging minimieren, keine persönlichen Daten
- Regelmäßige Updates: Sicherheitsupdates sofort installieren
- Firewall-Regeln: Minimal notwendige Regeln, alles andere blockieren
- Monitoring: Nur interne Monitoring, keine externen Services
- Öffentliche IPs: Niemals öffentliche IPs verwenden
- Provider-Templates: Keine vorkonfigurierten OS-Templates vom Provider für den Dedicated Server nutzen
- Cloud-Init Images für VMs: Keine vorkonfigurierten Images für VMs nutzen
- ZFS oder Directory-Storage: Nur LVM-Storage in Proxmox
- Direkte Verbindungen: Keine SSH/HTTP ohne VPN
- Traditionelle Zahlungen: Keine Kreditkarten oder PayPal
- Externe Logging-Services: Keine Logs an Drittanbieter
- Personenbezogene Daten: Keine echten Namen oder E-Mails
- Unverschlüsselte Backups: Alle Backups verschlüsseln
- Schwache Passwörter: Mindestens 20 Zeichen, zufällig
- Fehlende Updates: Regelmäßige Sicherheitsupdates sind Pflicht
Sicherheits-Check: Denkmodelle statt To-do-Liste
Statt einer Schritt-für-Schritt-Checkliste geht es hier bewusst um Konzepte. Wenn du die folgenden Fragen klar beantworten kannst, bist du in Richtung „OpSec-fähige Architektur“ unterwegs:
- Hardware-Ebene: Liegen alle produktiven Daten physisch auf Medien, die ohne dein Zutun nicht entschlüsselbar sind?
- Virtualisierungs-Ebene: Gibt es eine klare Trennung zwischen Hypervisor, Storage und VMs – und liegen alle VM-Disks in einem verschlüsselten Pool?
- Netzwerk-Ebene: Existiert irgendwo eine Route von außen direkt in dein internes Proxmox- oder VM-Netz – oder geht alles zwingend über VPN und definierte Exit-Punkte?
- Anonymität: Kann ein Außenstehender aus Zahlungsströmen, Whois-Daten, IP-Geolocation oder BGP-Informationen auf dich als Person schließen?
- Betrieb: Was passiert bei einem Reboot, bei einer Beschlagnahme, bei einem IP-Leak in der Anwendung – bleibt die Architektur trotzdem robust?
Je mehr dieser Fragen du ehrlich mit „Ja, das ist berücksichtigt“ beantworten kannst, desto näher kommst du an eine echte OpSec-Infrastruktur.
Cyberbunker 2.0: Das Extreme-Ende der OpSec-Skala (theoretisch)
Am ganz rechten Ende der OpSec-Skala – und weit jenseits dessen, was die meisten Projekte jemals benötigen – steht das, was man salopp einen „Cyberbunker 2.0“ nennen könnte.
Hier reden wir nicht mehr über „sichere Infrastruktur“, sondern über ein Setup, das selbst unter massivem politischem, rechtlichem und technischem Druck schwer greifbar ist.
Ein häufig zitiertes, rein theoretisches Konzept sieht in etwa so aus:
- Briefkastenfirma in einem afrikanischen Staat: Die juristische Entity sitzt in einer Jurisdiktion, in der internationale Auskunftsersuchen schwer durchsetzbar sind.
- Eigener IPv4-Space über diese Firma: Der Provider weist IPv4-Netze dieser Firma zu; durch aktuelle Regulierungen wird das schwieriger, weil Hardware oft physisch vor Ort nachgewiesen werden muss.
- Manipulierte Geolocation-Einträge: In IP-Geolocation-Datenbanken wird als Standort etwa „Nordkorea“ oder ein anderer „exotischer“ Staat eingetragen – völlig unabhängig vom realen RZ-Standort.
- BGP-„Theater“ im eigenen Backbone: Innerhalb des eigenen AS oder bei befreundeten Upstreams werden BGP-Announcements so gestaltet, dass die Routen scheinbar über „bogus“ Nordkorea-Pfade laufen, obwohl der Traffic in Wahrheit in einem ganz anderen Land endet.
Damit entsteht von außen der Eindruck eines politisch hochsensiblen, schwer angreifbaren Standorts, während die reale Infrastruktur vielleicht in einem ganz normalen europäischen Rechenzentrum steht.
Ob und in welchem Rahmen so etwas rechtlich zulässig oder operativ verantwortbar ist, steht auf einem ganz anderen Blatt – hier geht es ausschließlich um das Konzept, wie weit man OpSec theoretisch treiben könnte.
Für 99,9 % aller Anwendungsfälle reicht das zuvor beschriebene Modell aus LUKS + Proxmox + VPN-Isolation + Mullvad-Exit + optionalem DDoS-Schutz vollkommen aus. Der „Cyberbunker 2.0“ ist eher ein Gedankenexperiment am Limit als eine echte Empfehlung.
Lernen aus realen OpSec-Fehlern
Perfekte OpSec entsteht nicht im luftleeren Raum, sondern aus Fehlern der Vergangenheit, die sehr teuer bezahlt wurden. Drei prominente Beispiele zeigen, was in der Praxis schiefgelaufen ist – und welche Designfehler du unbedingt vermeiden solltest.
Beim Cyberbunker wurden bei der Razzia unter anderem Excel-Listen mit Zugängen gefunden – Zugänge, die offenbar von vorinstallierten Systemen (Hosting-Images, IPMI/ILO/DRAC-Zugänge etc.) stammten und nie geändert worden waren.
Konsequenzen:
- Jeder, der diese Listen in die Hände bekam, hatte Vollzugriff auf kritische Systeme
- Vorkonfigurierte Accounts der Provider blieben aktiv
- Das gesamte OpSec-Narrativ kollabiert, wenn das Fundament aus Standard-Zugängen besteht
Lesson learned:
- Niemals ungeänderte Default-Zugänge verwenden – weder bei Betriebssystem-Images, noch bei IPMI/ILO/DRAC
- Alle Zugangsdaten gehören neu generiert, dokumentiert und regelmäßig rotiert
- Excel-Listen auf produktiven Systemen sind kein Passwort-Management, sondern ein Incident in Zeitlupe
Encrochat betrieb seine Infrastruktur u. a. bei OVH. Das Problem: Im Standard-OS-Image von OVH gab es eine Funktion, mit der sich das Root-Passwort zurücksetzen ließ – eine Art „Convenience-Backdoor“ für den Support und Kundenkomfort.
Über genau diesen Mechanismus wurde der Build-Server infiltriert:
- Der Provider-spezifische Root-Reset-Mechanismus blieb aktiv
- Angreifer (bzw. Ermittler) nutzten diese Funktion, um sich Zugriff zu verschaffen
- Ab diesem Zeitpunkt war die komplette Chain-of-Trust der Encrochat-Geräte kompromittiert
Unter Insidern kursiert zudem das Gerücht, dass nach Bekanntwerden der Infiltration nicht nur eine Warn-Nachricht an alle Nutzer gesendet wurde, sondern auch ein Brandanschlag auf ein OVH-Rechenzentrum verübt wurde, das anschließend komplett abbrannte – weniger als „Rache“, sondern eher als verzweifelter Versuch, nach Verlust des Zugriffs noch Daten zu vernichten.
Tatsache ist: In diesem Zeitraum ist tatsächlich ein großes OVH-Rechenzentrum abgebrannt – ob es jedoch einen direkten Zusammenhang zu Encrochat gab, ist nicht offiziell bestätigt und bleibt Spekulation.
Der vermeintliche „Brandanschlag im Encrochat-Kontext“ sollte daher als das behandelt werden, was er ist: eine Szene-Erzählung – unabhängig davon zeigt sie, wie extrem die Reaktionen ausfallen können, wenn OpSec-Versagen ganze Ökosysteme gefährdet.
Lesson learned:
- Niemals blind den Standard-Images der Provider vertrauen
- Rescue-System oder eigenes ISO-Image → volle Kontrolle über das OS
- Alle „Convenience-Features“ wie Passwort-Resets, Web-Installer oder Remote-Consoles kritisch prüfen und wo möglich deaktivieren
An0m war von Anfang an ein FBI-Setup. Im Hintergrund lief ein XMPP (Jabber) Server, der eine simple, aber effektive Konstruktion verwendete:
- Im Hintergrund wurde aus jedem normalen Chat faktisch ein Gruppenchat gemacht
- Unsichtbar im Raum: ein Bot, der alles mitlas
- Der Bot leitete sämtliche Nachrichten zentral weiter – jede „sichere“ Kommunikation landete direkt bei den Ermittlern
Lesson learned:
- Wenn du die Kommunikations-Infrastruktur nicht selbst kontrollierst, kann sie jederzeit gegen dich arbeiten
- Selbst das beste OpSec-Setup nützt nichts, wenn die Gegenstelle oder der Dienstleister (bewusst oder gezwungenermaßen) als Man-in-the-Middle fungiert
- Kritische Kommunikation gehört auf eigene, gehärtete Server (z. B. Matrix Secure Chat mit eigenem Hosting und optional Tor Hidden Service), nicht auf fremdkontrollierte Plattformen mit intransparenten Servern
Viele Darknet-Marktplätze und Hidden Services – aber auch „normale“ Sites, die nur hinter Cloudflare liegen – sind nicht an der Infrastruktur, sondern an schlecht geschriebener Software gescheitert:
- Ungefangene Exceptions mit Stack-Traces, die Datenbank-Host, User und Passwort im Klartext zeigen
- Fehlerseiten, die interne IPs, Docker-Hostnamen oder interne Service-URLs leaken
- Debug-Modi, die versehentlich in Produktion aktiv bleiben
Solche Leaks reichen oft für:
- Vollständige Datenbank-Kompromittierung
- IP-Leaks von eigentlich versteckten Services
- Pivot-Angriffe auf interne Infrastruktur
Lesson learned:
- Ein gutes Infrastruktur-Setup (LUKS, Proxmox, VPN, Tor, Cloudflare/DDoS-Guard) kann vieles abfangen – aber es kompensiert keine unsichere Applikation
- Zu echter OpSec gehört immer auch ein Software Security Audit: Code-Review, Logging/Stack-Trace-Review, Secret-Handling, Debug-Konfigurationen, Penetrationstests auf Applikationsebene
DNS ist oft ein blinder Fleck: Wer die DNS-Resolver kontrolliert, hat sehr viel Macht über das, was du im Netz siehst – oder eben nicht siehst.
Best Practices:
- Eigene DNS-Server betreiben: z. B. mit PowerDNS oder Unbound, idealerweise im eigenen, isolierten Proxmox-Netz
- Root-Hints selbst pflegen: Direkt mit den offiziellen DNS-Root-Servern sprechen, statt blind Provider-DNS zu vertrauen
- DoH-/DoT-Resolver nutzen: Wenn externe Resolver nötig sind, dann über verschlüsselte Protokolle (DoH/DoT) zu vertrauenswürdigen Anbietern
- Alternative, neutrale DNS-Roots: Projekte wie OpenNIC bieten zensurresistente, community-getragene DNS-Infrastruktur
So stellst du sicher, dass nicht dein ISP, ein Staat oder ein Drittanbieter still und leise entscheidet, welche Domains auflösbar sind – und welche nicht.
Häufige Fehler und wie man sie vermeidet
Problem: Cloud-Init Images für VMs verhindern manuelle LUKS-Konfiguration und bieten weniger Kontrolle.
Lösung: Immer ISO-Installation für VMs verwenden, auch wenn es länger dauert. Für den Dedicated Server selbst: Rescue-System oder IPMI statt Provider-Templates.
Problem: VM-Festplatten liegen außerhalb von LUKS und sind unverschlüsselt.
Lösung: Immer LVM-Storage verwenden, damit alle VM-Festplatten in LUKS liegen.
Problem: Server sind scannbar und identifizierbar.
Lösung: Keine öffentlichen IPs zuweisen, alles über VPN.
Problem: SSH/HTTP ohne VPN sind angreifbar.
Lösung: Firewall-Regeln setzen, nur VPN-Verbindungen erlauben.
Problem: Bank-Transaktionen sind nachverfolgbar.
Lösung: Kryptowährungen verwenden, bevorzugt Monero.
Fazit: Unsichtbare Infrastruktur durch perfekte OpSec
Mit diesem Setup hast du eine hochsichere Server-Infrastruktur, die:
- ✅ Vollständig verschlüsselt ist (LUKS auf allen Ebenen)
- ✅ Virtuell isoliert ist (Proxmox mit LVM-Storage)
- ✅ Nur über VPN erreichbar ist (keine öffentlichen IPs)
- ✅ Bei IP-Leaks unsichtbar bleibt (VPN-Exit über Mullvad)
- ✅ Maximale Anonymität bietet (Crypto-Zahlungen, keine Metadaten)
Die drei Ebenen der Sicherheit:
- Hardware-Ebene: LUKS-Verschlüsselung schützt vor physischem Zugriff
- Virtualisierungs-Ebene: Proxmox mit LVM isoliert VMs und verschlüsselt alle Daten
- Netzwerk-Ebene: VPN-Isolation und Mullvad-Exit machen Server unsichtbar
Wichtig: OpSec ist kein einmaliger Prozess, sondern eine kontinuierliche Praxis. Regelmäßige Updates, Monitoring und Anpassungen sind essentiell.
Die Frage ist nicht, ob deine Infrastruktur angegriffen wird, sondern ob sie darauf vorbereitet ist.
Mit diesem Setup bist du darauf vorbereitet – selbst bei IP-Leaks, physischem Zugriff oder anderen Sicherheitsvorfällen bleibt deine Infrastruktur unsichtbar und geschützt.
Professionelle Unterstützung: Egal wie sicher – wir sind der richtige Partner
Egal, wie sicher oder komplex deine IT-Infrastruktur werden soll – wir sind der perfekte Partner, um diese Konzepte in der Praxis sauber und nachhaltig umzusetzen.
Für Planung, Aufbau und Betrieb deiner Server- und Proxmox-Umgebung bieten wir dir unsere Systemadministration & Systemintegration an:
Von dedizierten Servern über Proxmox-Cluster bis hin zu Backup- und Monitoring-Konzepten bekommst du alles aus einer Hand.
Wenn du deine bestehende Infrastruktur professionell prüfen lassen möchtest, sind unsere IT-Infrastruktur Audits & Pentests die ideale Ergänzung:
Wir analysieren Architekturen, Konfigurationen und Netzwerke und überprüfen, ob deine OpSec-Ideen wirklich so funktionieren, wie sie gedacht sind.
Für wirklich vertrauliche Kommunikation – passend zu einer unsichtbaren Infrastruktur – empfehlen wir zusätzlich unseren Matrix Secure Chat:
Eigener, gehärteter Messenger-Stack, auf Wunsch kombiniert mit Krypto-Handys und Tor Hidden Services, damit nicht nur deine Server, sondern auch deine Kommunikation maximal geschützt ist.