PHP2Shell: Präventiver Schutz mit Airlock

Am 21. Oktober wurden die technischen Details zu zwei kritischen PHP-Schwachstellen unter dem Namen PHP2Shell veröffentlicht. Bereits am selben Tag wurden erste Exploit-Versuche beobachtet. Der Vorfall zeigt, wie schnell Angriffe nach der Veröffentlichung beginnen können und wie wichtig eine zuverlässige WAF ist, die präventiv schützt. 

Airlock ist nicht betroffen

Airlock Gateway, Microgateway und IAM waren selbst nicht betroffen, da sie kein PHP einsetzen. Unser Fokus galt deshalb dem Schutz der PHP-Backends unserer Kunden.

Wie schützt Airlock PHP-Backends?

Unsere Tests zeigten: Airlock Gateway und Microgateway blockierten die getesteten Angriffe bereits in der Default-Konfiguration. Mehr als ein halbes Dutzend unabhängiger Schutzmechanismen – darunter Deny Rules, Limits und Parameter Normalization – griffen. Dafür waren keine spezifischen PHP2Shell-Regeln nötig.

Airlock bietet Defense in Depth: Viele Angriffe werden vollständig blockiert, bei anderen kann wertvolle Zeit für Sicherheitsupdates gewonnen werden. Präventiver Schutz ist gerade jetzt wichtig. Denn reaktive Schutzmassnahmen kommen möglicherweise zu spät, wenn Angriffe bereits unmittelbar nach oder sogar vor der Veröffentlichung einer Schwachstelle beginnen.

KI verschärft diese Lage zusätzlich: Sie beschleunigt sowohl die Entwicklung von Exploits als auch das Auffinden von Schwachstellen.

Warum Airlock auch spezifische Schutzregeln bereitstellt

Bei PHP2Shell bleibt trotz wirksamer WAF-Mitigationen ein Restrisiko durch bislang unbekannte Exploit-Varianten. Deshalb müssen die Schwachstellen durch PHP-Updates behoben werden.

Um das Restrisiko bis dahin weiter zu senken, haben wir unseren Kunden spezifische PHP2Shell-Schutzregeln für das Virtual Patching mit Airlock zur Verfügung gestellt.