Zum Hauptinhalt springen
RefoundRefound
EN
Alle Artikel
securitywaflegacy systemscloudflare

Virtual Patching: Wie Sie vulnerable Altsysteme schützen, wenn Sie den Code nicht ändern können

Niclas Kusenbach

Sicherheits-Compliance-Checklisten und Schwachstellen-Scanner liefern immer denselben Ratschlag: „Aktualisieren Sie Ihre Abhängigkeiten. Patchen Sie Ihre Software. Beheben Sie den Code.“

Für ein mittelständisches Unternehmen, das ein geschäftskritisches Altsystem (Legacy-System) betreibt, geht dieser Ratschlag jedoch oft völlig an der Realität vorbei.

Wenn Ihre Anwendung auf PHP 5.6, klassischem ASP oder einer veralteten Java-Version läuft, kann das Upgrade einer einzigen Abhängigkeit eine Kaskade von Breaking Changes auslösen. Eine Behebung, die in einem Sicherheits-Scanner trivial aussieht, entwickelt sich so schnell zu einem 12-wöchigen Refactoring-Projekt.

In der Zwischenzeit ist die Schwachstelle öffentlich bekannt. Automatisierte Scanner hämmern täglich gegen Ihre Endpunkte. Sie sind schutzlos ausgeliefert.

Hier kommt Virtual Patching ins Spiel. Es handelt sich um einen pragmatischen Schutz auf Infrastrukturebene, der anfällige Anwendungen auf der Netzwerkschicht abschirmt und bösartigen Datenverkehr blockiert, bevor er überhaupt Ihren Server erreicht. Das verschafft Ihnen die nötige Zeit, um Ihren Code sicher zu modernisieren.

Was ist Virtual Patching?

Virtual Patching bezeichnet die Implementierung einer Sicherheitsregel auf Netzwerkebene – in der Regel an einer Web Application Firewall (WAF), einem Reverse-Proxy oder einem CDN-Edge –, die verhindert, dass ein Exploit eine bekannte Schwachstelle im Anwendungscode erreicht.

Im Gegensatz zu einem regulären Code-Patch behebt Virtual Patching nicht den zugrunde liegenden Fehler im Code. Stattdessen verhindert es, dass der Fehler getriggert (ausgelöst) werden kann.

[Angreifer] ──> [Exploit-Payload] ──> [ WAF / Proxy ] ── (Blockiert!) ──x [Legacy-App]
[Nutzer]    ──> [Legitime Anfrage] ──> [ WAF / Proxy ] ── (Erlaubt)    ───> [Legacy-App]

Durch das Abfangen eingehender Anfragen prüft die Firewall Parameter, Header und Request-Bodies auf bekannte Angriffssignaturen, bekannte Exploits oder ungültige Eingabemuster und verwirft diese direkt am Edge.

Wann man Virtual Patching einsetzt

Virtual Patching ist kein dauerhafter Ersatz für Code-Refactoring, aber es ist ein unverzichtbares Werkzeug in folgenden Szenarien:

  1. Der Code ist schwer wartbar: Der ursprüngliche Entwickler hat das Unternehmen vor Jahren verlassen, es gibt keine Unit-Tests und jede Änderung am Code birgt ein hohes Risiko, das Geschäft zu beeinträchtigen.
  2. Eingestellter Support durch Drittanbieter: Die Anwendung basiert auf einem kommerziellen Paket oder einer Bibliothek, die vom Hersteller nicht mehr unterstützt wird. Es wird also nie wieder ein offizieller Sicherheitspatch erscheinen.
  3. Der „Upgrade-Sturm“: Das Beheben einer Sicherheitslücke in einer Bibliothek erfordert das Upgrade des Frameworks, was wiederum das Upgrade der Runtime (z. B. PHP oder Node.js) erfordert – wodurch 40 % Ihres restlichen Codes brechen würden.
  4. Sofortige Notfallreaktion: Eine Zero-Day-Schwachstelle wird bekannt und Ihre Entwickler benötigen Wochen, um einen Code-Fix zu implementieren und zu testen. Ein virtueller Patch kann in wenigen Minuten bereitgestellt werden.

So implementieren Sie Virtual Patching

Sie können virtuelle Patches an verschiedenen Stellen Ihrer Infrastruktur einrichten. Sehen wir uns die zwei gängigsten und effektivsten Implementierungspunkte an: den CDN-Edge (mit Cloudflare) und den Webserver (mit Nginx und ModSecurity).

1. Virtual Patching auf Edge-Ebene (Cloudflare WAF)

Wenn Sie Cloudflare nutzen, können Sie Angriffs-Payloads blockieren, bevor sie überhaupt Ihren Origin-Server erreichen. Dies minimiert die Ressourcenauslastung des Servers und verbirgt die tatsächliche Verwundbarkeit Ihrer Anwendung.

Angenommen, ein Audit deckt eine ungeschützte SQL-Injection-Schwachstelle in einem alten Such-Endpunkt /search.php über den Query-Parameter q auf:

// Vulnerabler Legacy-Code
$searchTerm = $_GET['q'];
$result = mysql_query("SELECT * FROM products WHERE name LIKE '%" . $searchTerm . "%'");

Während Sie die Behebung der Abfrage per Prepared Statements einplanen, können Sie eine benutzerdefinierte Cloudflare WAF-Regel einrichten, um gängige SQL-Injection-Payloads auf /search.php zu blockieren.

So sieht diese WAF-Regel in der Expression Language von Cloudflare aus:

(http.request.uri.path eq "/search.php" and 
 (http.request.uri.query contains "union" or 
  http.request.uri.query contains "select" or 
  http.request.uri.query contains "char" or 
  http.request.uri.query contains "concat" or 
  http.request.uri.query contains "'" or 
  http.request.uri.query contains "--"))

Aktion: Blockieren (Block)

Für komplexere Szenarien können Sie einen Cloudflare Worker schreiben, der Request-Payloads analysiert, Parameter bereinigt und schädliche Skripte (XSS) oder SQL-Syntax herausfiltert, bevor die Anfrage an Ihr Altsystem weitergeleitet wird.

2. Virtual Patching auf Webserver-Ebene (Nginx + ModSecurity)

Wenn Sie Ihre Anwendung selbst hosten oder kein Edge-Netzwerk verwenden, können Sie virtuelle Patches direkt in Nginx mithilfe von ModSecurity ausführen, der quelloffenen Web Application Firewall-Engine.

Nehmen wir an, Sie haben ein altes Administrations-Panel unter /admin, das für einen bekannten Path-Traversal-Exploit anfällig ist oder eine fehlerhafte Session-Handhabung aufweist. Sie möchten den Zugriff auf bestimmte IP-Adressen beschränken und gleichzeitig Directory-Traversal-Zeichen wie ../ blockieren.

Sie können Ihrer ModSecurity-Konfiguration (/etc/nginx/modsec/main.conf) eine benutzerdefinierte Regel hinzufügen:

# Blockiert Directory-Traversal-Versuche auf /admin
SecRule REQUEST_URI "@startsWith /admin" "id:10001,phase:2,deny,status:403,log,msg:'Block directory traversal on admin panel',chain"
SecRule ARGS "@rx \.\./"

Diese Regel prüft, ob die URI mit /admin beginnt. Wenn dies zutrifft, prüft sie, ob Argumente ../ enthalten. Sind beide Bedingungen erfüllt, wird sofort eine 403 Forbidden-Antwort zurückgegeben, um Ihre zugrunde liegende Dateistruktur zu schützen.

Die Grenzen: Warum es ein Schild ist und kein Heilmittel

Virtual Patching ist ein extrem mächtiges Werkzeug, aber Sie müssen die Grenzen kennen. Sich dauerhaft darauf zu verlassen, ist ein gefährliches Spiel.

  • Umgehung und Verschleierung (Obfuscation): Angreifer sind Experten darin, WAF-Signaturen zu umgehen. Durch unterschiedliche Zeichenkodierungen (z. B. URL-Encoding, Hex-Encoding, Unicode-Normalisierung) können sie einfache Signaturprüfungen oft austricksen und die Schwachstelle auf Ihrem Backend dennoch triggern.
  • Kein Kontext zur Geschäftslogik: Eine WAF weiß nicht, ob Benutzer A berechtigt ist, die Rechnungen von Benutzer B einzusehen. Sie kann fehlerhafte Zugriffskontrollen (Broken Access Control — OWASP A01) nicht einfach virtuell patchen. Wenn Ihrer Anwendung diese Berechtigungsprüfung im Code fehlt, kann eine WAF nicht ohne Weiteres den Datenbankstatus prüfen, um die Anfrage zu autorisieren.
  • Performance-Overhead: Die Durchführung von Deep Packet Inspection, Regex-Matching und das Parsen von Request-Bodies für jede einzelne Anfrage erhöht die Latenz und die CPU-Last auf Ihrem Proxy- oder Webserver.
  • Wartung der Regeln: Sobald neue Exploits entdeckt werden, müssen die Regeln aktualisiert werden. Mit der Zeit wird Ihre Firewall-Konfiguration zu einem komplexen, undokumentierten Regel-Dschungel, an den sich Entwickler kaum noch herantrauen.

Der Weg nach vorn: Die Brücke zur Modernisierung

Virtual Patching ist eine Brücke, kein Ziel. Es verschafft Ihnen die Zeit, die Sie für einen sauberen, strukturierten Modernisierungsplan benötigen, ohne den Stress eines aktiven, ungeschützten Sicherheitsrisikos im Nacken.

Der empfohlene Ablauf sieht wie folgt aus:

  1. Audit: Führen Sie ein gründliches Codebase-Health-Audit durch, um Schwachstellen, End-of-Life-Abhängigkeiten und Architekturrisiken genau zu lokalisieren.
  2. Abschirmen (Shield): Richten Sie sofort virtuelle Patches (WAF-Regeln, Proxy-Filter) ein, um aktive Angriffe auf kritische Sicherheitslücken zu blockieren.
  3. Refactoring: Planen und implementieren Sie eine inkrementelle Modernisierung des Codes (z. B. nach dem bewährten Strangler-Fig-Pattern), um die Sicherheitsprobleme an der Quelle zu beheben.
  4. Bereinigen: Sobald der refaktorierte Code stabil in der Produktion läuft, entfernen Sie die WAF-Regeln wieder, um Ihre Infrastruktur schlank und wartbar zu halten.

Wenn Ihr Unternehmen veraltete Software betreibt und Sie besorgt über Sicherheitsrisiken sind oder ein Compliance-Audit bevorsteht, lassen Sie uns sprechen. Wir unterstützen Unternehmen dabei, ihre Legacy-Codebasen zu prüfen, sofortige Sicherheits-Schilde einzurichten und eine reibungslose Modernisierung ohne Ausfallzeiten umzusetzen.