VPN — Schwachstellen, Angriffe & Insider-Wissen

Grundlagen — Tunneling, Verschlüsselung und Protokolle

Das Kernprinzip eines VPN ist das Tunneling: Originale Datenpakete (Payload) werden in ein zusätzliches Protokoll eingekapselt, kryptographisch verschlüsselt und über ein öffentliches Transportnetzwerk zum Zielpunkt übertragen. Dort erfolgt die Entkapselung und Entschlüsselung, woraufhin die Pakete in das lokale Zielnetzwerk eingespeist werden. Für Anwendungen und Benutzer erscheint es so, als befinde sich das Gerät direkt im entfernten Netzwerk — mit einer privaten IP-Adresse aus dem Ziel-Subnetz. Dieses Konzept wird als „virtuell“ bezeichnet, weil die Verbindung logisch über die physische Infrastruktur eines Drittanbieters (ISP) läuft, und als „privat“, weil die Verschlüsselung Vertraulichkeit gewährleistet.

Die Verschlüsselung bildet die Sicherheitsgrundlage jedes VPN. Moderne Protokolle setzen auf symmetrische Verfahren wie AES-256-GCM (Advanced Encryption Standard mit Galois/Counter Mode) oder ChaCha20-Poly1305, wobei Letzteres besonders auf mobilen Geräten ohne AES-NI-Hardwarebeschleunigung performanter ist. Der initiale Schlüsselaustausch erfolgt über asymmetrische Kryptographie — typischerweise Diffie-Hellman über elliptische Kurven (ECDH) mit Curve25519 oder P-384. Zusätzlich stellen Message Authentication Codes (HMAC-SHA256, Poly1305) die Integrität sicher: Selbst eine einzige geänderte Bitposition würde erkannt und das Paket verworfen. Perfect Forward Secrecy (PFS) sorgt dafür, dass ein kompromittierter Langzeitschlüssel keine bereits aufgezeichneten Sitzungen entschlüsselbar macht.

Beim Protokollvergleich dominieren vier Technologien den Markt: WireGuard besticht durch nur ~4.000 Zeilen Code, minimale Angriffsfläche und höchste Throughput-Performance (oft >1 Gbit/s auf moderner Hardware). IPsec/IKEv2 ist der Industriestandard mit nativer Unterstützung in allen Betriebssystemen und der MOBIKE-Erweiterung für nahtlosen Netzwerkwechsel auf Mobilgeräten. OpenVPN bietet maximale Flexibilität und kann über TCP Port 443 getunnelt werden, um restriktive Firewalls zu umgehen. Die Performance-Unterschiede sind signifikant: In Benchmarks erreicht WireGuard typischerweise 20–30 % höheren Durchsatz als IPsec und 50–60 % mehr als OpenVPN, bei gleichzeitig niedrigerer CPU-Auslastung und schnellerem Verbindungsaufbau (1–2 Round-Trip-Times gegenüber 4–6 bei IKEv2).

VPN-Architekturen im Überblick

Die Wahl der VPN-Architektur hängt von den spezifischen Anforderungen ab: Standortvernetzung, Homeoffice-Anbindung, Cloud-Konnektivität oder eine Kombination daraus. Jede Architektur hat eigene Stärken und Einsatzszenarien, die bei der Planung sorgfältig abgewogen werden müssen.

Die klassische Hub-and-Spoke-Topologie leitet sämtlichen Datenverkehr über einen zentralen Standort (Hub), der als VPN-Konzentrator fungiert. Alle Niederlassungen (Spokes) verbinden sich ausschließlich mit dem Hub, was die Verwaltung vereinfacht und zentrale Sicherheits-Policies ermöglicht. Der Nachteil ist das sogenannte Trombone-Routing: Kommunikation zwischen zwei Spokes muss immer über den Hub laufen, was Latenz erhöht und die Hub-Bandbreite belastet. Im Gegensatz dazu ermöglicht eine Full-Mesh-Topologie direkte Verbindungen zwischen allen Standorten, was die Latenz minimiert, aber den Verwaltungsaufwand mit n(n-1)/2 Tunneln exponentiell steigen lässt. Moderne SD-WAN-Lösungen lösen dieses Dilemma, indem sie dynamische Mesh-Tunnel bei Bedarf aufbauen und gleichzeitig zentrale Policy-Verwaltung beibehalten.

Für Remote-Access-Szenarien hat sich das Konzept des Always-On VPN als Best Practice etabliert. Dabei wird der VPN-Tunnel automatisch aufgebaut, sobald eine Netzwerkverbindung besteht — ohne Benutzerinteraktion. Microsofts Always-On VPN (Nachfolger von DirectAccess) unterstützt dabei einen Device Tunnel (Verbindung vor der Benutzeranmeldung für Gruppenrichtlinien und Maschinenauth.) und einen User Tunnel (benutzerspezifischer Zugriff nach Anmeldung). Beide Tunnel können parallel betrieben werden. Die Konfiguration über Microsoft Intune oder SCCM ermöglicht skalierbare Deployments für tausende Endgeräte.

• Site-to-Site VPN: Permanente Verbindung zwischen zwei oder mehr Standorten über dedizierte VPN-Gateways oder Firewalls. Transparent für Endgeräte — kein Client erforderlich. Typisch für Hauptsitz-Niederlassung-Szenarien mit IPsec oder WireGuard. Redundanz durch Dual-WAN und automatisches Failover.
• Remote Access VPN: Einzelne Benutzer verbinden sich von beliebigen Standorten per VPN-Client mit dem Unternehmensnetzwerk. Standardlösung für Homeoffice und mobiles Arbeiten. Unterstützt Multi-Faktor-Authentifizierung (MFA) und zertifikatsbasierte Authentisierung.
• Split-Tunneling vs. Full-Tunneling: Beim Split-Tunneling wird nur der Verkehr zum Unternehmensnetzwerk durch den VPN-Tunnel geleitet, während Internet-Zugriffe direkt erfolgen — ideal für Microsoft 365 und Cloud-Dienste. Full-Tunneling leitet sämtlichen Verkehr über das VPN und bietet maximale Kontrolle, erfordert aber mehr Bandbreite am Gateway.
• Client-to-Client VPN (Mesh): Direkte Peer-to-Peer-Verbindungen zwischen Endgeräten ohne zentralen Server. Lösungen wie Tailscale oder Nebula nutzen NAT-Traversal und Relay-Server als Fallback. Ideal für DevOps-Teams und verteilte Entwicklungsumgebungen.
• Cloud-VPN / SD-WAN Integration: Anbindung von On-Premises-Standorten an Cloud-Provider über verwaltete VPN-Gateways (Azure VPN Gateway, AWS Site-to-Site VPN). ExpressRoute und Direct Connect bieten dedizierte Verbindungen als höherwertige Alternative. SD-WAN orchestriert VPN-Tunnel, MPLS und Internet-Breakouts dynamisch basierend auf Application-Awareness.
• Hub-and-Spoke vs. Full Mesh: Hub-and-Spoke vereinfacht die Verwaltung, erzeugt aber Trombone-Routing. Full Mesh minimiert Latenz, skaliert aber schlecht (n*(n-1)/2 Tunnel). Dynamische Mesh-VPNs (DMVPN, ADVPN) und SD-WAN bieten den besten Kompromiss: zentrale Policy mit bedarfsgesteuertem Mesh.

VPN-Angriffsvektoren — warum VPNs das Primärziel für Ransomware sind

VPN-Appliances stehen direkt am Internet, lauschen auf bekannten Ports und sind oft der einzige Weg ins interne Netzwerk. Damit sind sie das perfekte Ziel für Angreifer: Eine einzige Schwachstelle öffnet die Tür zum gesamten Unternehmensnetzwerk. Die Liste kritischer VPN-CVEs der letzten 2 Jahre liest sich wie ein Horrorkatalog — und jede einzelne wurde aktiv von Ransomware-Gruppen ausgenutzt, bevor ein Patch verfügbar war.

• Die VPN-CVE-Epidemie 2024/2025: Fortinet FortiOS: CVE-2024-21762 (Pre-Auth RCE über SSL-VPN, CVSS 9.8), CVE-2023-27997 (Heap Overflow im SSL-VPN), CVE-2024-47575 (FortiManager „FortiJump“ — Zugriff auf alle verwalteten Firewalls). Ivanti Connect Secure (ehem. Pulse Secure): CVE-2024-21887 + CVE-2023-46805 (Auth Bypass + Command Injection — CISA Emergency Directive ED 24-01, erzwungener Disconnect aller Ivanti-VPNs in US-Behörden). Palo Alto GlobalProtect: CVE-2024-3400 (Pre-Auth RCE, CVSS 10.0 — Command Injection über den GlobalProtect-Service, aktiv ausgenutzt durch UTA0218). Insider-Wissen: Nach jeder CVE-Veröffentlichung scannen Angreifer innerhalb von 24–48 Stunden das gesamte Internet nach verwundbaren VPN-Appliances. Shodan/Censys indizieren VPN-Ports — die Angreifer müssen nicht mal selbst scannen.
• Pre-Auth vs. Post-Auth — warum Pre-Auth-RCE so gefährlich ist: Pre-Authentication RCE bedeutet: Der Angreifer kann Code auf der VPN-Appliance ausführen ohne gültige Credentials. Kein Benutzername, kein Passwort, kein MFA — nur eine HTTP-Anfrage an den VPN-Service genügt. Dies macht Patching zur absoluten Priorität: Innerhalb von 24 Stunden nach CVE-Veröffentlichung muss der Patch eingespielt oder der VPN-Dienst temporär deaktiviert werden. Incident Response nach CVE: Selbst nach dem Patchen muss die Appliance auf bereits eingesetzte Backdoors untersucht werden — Angreifer installieren Webshells und Persistence-Mechanismen innerhalb von Minuten nach dem initialen Exploit.
• VPN-Credential-Stuffing und Brute Force: Auch ohne Zero-Day-Exploits: VPN-Portale mit Benutzername/Passwort sind anfällig für Credential-Stuffing (Passwörter aus Data Breaches werden automatisiert getestet). Cisco Anyconnect und Fortinet SSL-VPN erlauben standardmäßig unbegrenzte Login-Versuche. Ransomware-Gruppe Akira nutzte 2024 systematisch Credential-Stuffing auf Cisco-VPNs. Fix: MFA für alle VPN-Logins (FIDO2 bevorzugt), Account Lockout nach 5 Fehlversuchen, GeoIP-Filtering (nur Logins aus DACH/EU erlauben), CAPTCHA nach 3 Fehlversuchen.
• VPN als Lateral-Movement-Enabler: Ein VPN gibt dem Benutzer typischerweise Zugriff auf das gesamte interne Netzwerk — als wäre er physisch vor Ort. Wenn ein Angreifer VPN-Credentials kompromittiert, hat er damit sofort Netzwerkzugriff auf alle internen Systeme. Im Gegensatz zu einem physischen Angreifer, der zuerst einen Weg ins Gebäude finden müsste, sitzt der VPN-Angreifer direkt im VLAN — neben den Domain Controllern, Fileservern und Datenbanken. Dies ist der fundamentale Designfehler klassischer VPNs — und der Hauptgrund für die ZTNA-Bewegung.

ZTNA vs. VPN — die Evolution des Fernzugriffs

Zero Trust Network Access (ZTNA) ist die Antwort auf die fundamentalen Schwachstellen klassischer VPNs. Statt dem Benutzer nach erfolgreicher Authentifizierung Netzwerkzugriff zu gewähren, bietet ZTNA Anwendungszugriff — der Benutzer sieht nur die Anwendungen, für die er autorisiert ist, ohne jemals ins Netzwerk zu gelangen.

• VPN = Netzwerkzugriff, ZTNA = Anwendungszugriff: Bei VPN: Authentifizierung → volles Layer-3-Netzwerk → Benutzer kann jedes System im Netzwerk scannen/kontaktieren. Bei ZTNA: Authentifizierung + Device-Compliance + Risiko-Bewertung → Zugriff auf genau eine Anwendung über einen Reverse-Proxy → kein Netzwerkzugriff, kein Lateral Movement möglich. Der Benutzer weiß nicht einmal, in welchem Netzwerksegment die Anwendung läuft.
• ZTNA-Produkte 2026: Microsoft Entra Private Access (ehem. Azure AD Application Proxy — ersetzt VPN für M365-Kunden), Zscaler Private Access (ZPA), Cloudflare Access, Palo Alto Prisma Access, Netskope Private Access. Insider-Tipp: Entra Private Access ist für Unternehmen mit Microsoft-365-E3/E5-Lizenz bereits inkludiert — viele zahlen unnötig für separate VPN-Appliances, obwohl die ZTNA-Lösung bereits lizenziert ist.
• Wann VPN weiterhin sinnvoll ist: VPN stirbt nicht — es hat weiterhin seinen Platz: Site-to-Site-Verbindungen (Standortvernetzung), Legacy-Anwendungen (die kein HTTP/HTTPS sprechen), Vollständiger Netzwerkzugriff für IT-Admins (mit PAW + MFA + Conditional Access), Backup-Zugang wenn ZTNA-Provider ausfällt. Die meisten Unternehmen werden in den nächsten 3–5 Jahren einen hybriden Ansatz fahren: ZTNA für Anwendungszugriff, VPN für Spezialszenarien.

Best Practices für sichere VPN-Infrastrukturen

Eine VPN-Infrastruktur ist nur so sicher wie ihre schwächste Komponente. Die richtige Protokollwahl, robustes Key Management und konsequentes Monitoring sind entscheidend, um die Vertraulichkeit und Integrität der übertragenen Daten zu gewährleisten. Insbesondere im Kontext von NIS2 und DSGVO müssen Unternehmen nachweisen, dass ihre Fernzugriffslösungen dem Stand der Technik entsprechen.

Die Protokollwahl sollte sich an den konkreten Anforderungen orientieren: WireGuard für maximale Performance und minimale Komplexität, IKEv2 für native Betriebssystem-Integration und MOBIKE-Support auf Mobilgeräten, OpenVPN für Legacy-Kompatibilität und Firewall-Umgehung über TCP 443. Von der Nutzung veralteter Protokolle wie PPTP (gebrochene MPPE-Verschlüsselung) oder L2TP ohne IPsec wird dringend abgeraten. Unabhängig vom Protokoll muss Perfect Forward Secrecy (PFS) aktiviert sein, damit ein kompromittierter Langzeitschlüssel keine vergangenen Sitzungen entschlüsselbar macht.

Ein häufig unterschätztes Risiko sind DNS Leaks: Selbst bei aktivem VPN-Tunnel können DNS-Anfragen außerhalb des Tunnels an den ISP-DNS gesendet werden, was die besuchten Domains offenlegt. Abhilfe schaffen eine erzwungene DNS-Konfiguration auf den VPN-eigenen DNS-Server, Firewall-Regeln, die DNS-Verkehr außerhalb des Tunnels blockieren, und regelmäßige Tests mit Tools wie dnsleaktest.com. Ein Kill Switch (Network Lock) stellt sicher, dass bei einem VPN-Verbindungsabbruch sämtlicher Netzwerkverkehr blockiert wird, bis der Tunnel wiederhergestellt ist.

• Zertifikatsbasierte Authentifizierung: Statt Pre-Shared Keys (PSK) sollte eine Public-Key-Infrastruktur (PKI) mit X.509-Zertifikaten eingesetzt werden. Zertifikate ermöglichen eindeutige Geräteidentifikation, automatische Rotation und Widerruf kompromittierter Identitäten über Certificate Revocation Lists (CRL) oder OCSP.
• Multi-Faktor-Authentifizierung (MFA): VPN-Logins müssen durch einen zweiten Faktor abgesichert werden — TOTP-Token (Google Authenticator, Microsoft Authenticator), FIDO2/WebAuthn-Hardware-Keys (YubiKey) oder Push-Benachrichtigungen. RADIUS-Integration mit NPS oder FreeRADIUS ermöglicht zentrale MFA-Enforcement.
• Kill Switch und DNS Leak Prevention: Ein Kill Switch blockiert sämtlichen Netzwerkverkehr bei VPN-Verbindungsabbruch. DNS-Anfragen müssen zwingend durch den VPN-Tunnel geleitet werden. Firewall-Regeln auf dem Client verhindern DNS-Leaks über alternative Interfaces (IPv6, WebRTC).
• Key Management und Rotation: Pre-Shared Keys (wenn unvermeidbar) müssen mindestens 32 Zeichen lang und kryptographisch zufällig sein. Automatisierte Schlüsselrotation (Rekeying) alle 1–8 Stunden begrenzt das Schadenspotenzial kompromittierter Sitzungsschlüssel. WireGuard rekeyed automatisch alle 2 Minuten.
• Monitoring und Logging: VPN-Verbindungen müssen zentral überwacht werden: Verbindungsaufbau/-abbau, Bandbreite pro Tunnel, Latenz und Paketverlust. Anomalie-Erkennung identifiziert ungewöhnliche Muster wie Verbindungen aus unerwarteten Regionen oder übermäßigen Datenabfluss. SIEM-Integration mit Syslog/CEF ist empfohlen.
• Segmentierung nach Tunnel: VPN-Benutzer sollten nicht pauschal Zugriff auf das gesamte interne Netz erhalten. Micro-Segmentation und rollenbasierte Zugriffssteuerung (RBAC) beschränken den Zugriff auf die tatsächlich benötigten Ressourcen — im Sinne des Zero-Trust-Prinzips „Never trust, always verify“.