Kurz gesagt: Automatisierte Angriffe auf Webserver laufen in Wellen: Programme durchsuchen das Internet nach erreichbaren Servern, ordnen sie anhand äusserer Merkmale ein und probieren bekannte Lücken wie PHP2Shell massenhaft aus. Die Grösse des Unternehmens spielt dabei keine Rolle. Schutz bieten ein gepatchtes PHP, eine kleine Angriffsfläche und eine Überwachung, die erfolgreiche Treffer schnell bemerkt.
Der Aufhänger: „Wer sollte sich für unsere Website interessieren?“
Diese Frage hören wir nach PHP2Shell oft, vor allem von kleineren Unternehmen. Die ehrliche Antwort: vermutlich niemand persönlich. Aber das ist bei Lücken dieser Art auch nicht nötig. Die Angriffe werden von Programmen ausgeführt, die nicht nach Namen suchen, sondern nach Gelegenheiten.
Das BSI rechnete bei PHP2Shell mit schneller, grossflächiger Ausnutzung. Cloudflare berichtete von Angriffsversuchen und davon, dass Angreifer ihre Muster veränderten, um Schutzregeln zu umgehen. Beides passt zu dem, was bei kritischen Lücken in weit verbreiteter Software regelmässig geschieht.
Wie automatisierte Angriffe auf Webserver ablaufen
Automatisierte Kampagnen folgen meist einem ähnlichen Muster. Die folgende Übersicht beschreibt die Phasen allgemein, ohne Angriffsdetails:
| Phase | Was passiert | Was dagegen hilft |
|---|---|---|
| Suchen | Programme prüfen grosse Adressbereiche oder öffentliche Verzeichnisse wie Zertifikatsprotokolle auf erreichbare Webserver | wenig öffentlich erreichbare Systeme, Inventar aller Adressen |
| Einordnen | Antworten werden ausgewertet: Webserver, PHP-Version, CMS, typische Pfade | Versionsangaben verbergen, unnötige Dateien entfernen |
| Ausprobieren | bekannte Lücken werden massenhaft getestet, oft ohne vorherige Einordnung | aktuelles PHP, Neustart, WAF als zusätzliche Schicht |
| Festsetzen | bei Erfolg wird eine Hintertür abgelegt, etwa eine Webshell oder ein Cronjob | eingeschränkte Schreibrechte, keine PHP-Ausführung in Upload-Ordnern |
| Verwerten | Server wird genutzt, etwa für Spam, Kryptomining, Weiterleitungen oder Datendiebstahl | Überwachung von Prozessen, Dateien und ausgehenden Verbindungen |
Wichtig ist die dritte Zeile. Viele Kampagnen machen sich gar nicht die Mühe, Server vorher genau einzuordnen. Sie probieren einfach alles aus, was erreichbar ist. Deshalb schützt Unauffälligkeit allein nicht.
Warum Angriffe in Wellen kommen
Automatisierte Kampagnen laufen selten einmal und dann nie wieder. Typisch ist ein Muster in Wellen. Die erste Welle folgt kurz nach dem Bekanntwerden einer Lücke, oft noch mit unausgereiften Werkzeugen. Weitere Wellen kommen, wenn Angreifer ihre Werkzeuge verbessern oder an Schutzregeln anpassen. Cloudflare hat bei PHP2Shell genau das beobachtet: veränderte Angriffsmuster, um die Regeln zu umgehen.
Für Sie bedeutet das: Ein Server, der die erste Welle unbeschadet überstanden hat, ist nicht dauerhaft sicher, solange er ungepatcht ist. Und ein neu aufgesetzter Server ist ab dem Moment Ziel, in dem er erreichbar ist. Wer etwa ein neues TLS-Zertifikat ausstellen lässt, macht den Namen in öffentlichen Zertifikatsprotokollen sichtbar, die auch Scanner auswerten. Ein neues System sollte deshalb erst ans Netz, wenn es bereits aktualisiert ist.
Warum kleine Firmen genauso betroffen sind
Für automatisierte Angriffe zählt nicht der Wert eines einzelnen Ziels, sondern die Menge. Ein Server eines kleinen Betriebs bietet Rechenleistung, eine Domain mit gutem Ruf, einen Mailversand und manchmal Kundendaten. Für Angreifer ist das genug.
Hinzu kommt: Kleinere Unternehmen haben oft keine eigene IT, die Updates sofort einspielt. Ihre Server bleiben länger verwundbar und landen deshalb häufiger in den Ergebnislisten der Scanner. Wer zuerst patcht, fällt aus diesen Listen heraus.
Ein weiterer Punkt ist die Lieferkette. Viele kleine Websites liegen auf Servern von Agenturen oder kleinen Hostern, auf denen Dutzende Kundenprojekte nebeneinander laufen. Für Angreifer ist ein solcher Server besonders lohnend, weil ein einziger Treffer viele Websites gleichzeitig betrifft. Ihr Risiko hängt dann nicht nur von Ihrer eigenen Sorgfalt ab, sondern auch von der Ihres Dienstleisters.
Scans in Ihren Logs sind normal und kein Beweis für einen Einbruch. Ein erfolgreicher Angriff zeigt sich an anderen Spuren: neue Dateien, fremde Prozesse, unbekannte Konten, ungewohnte ausgehende Verbindungen.
Was Sie selbst prüfen können
Ein Blick in die Logs zeigt, wie stark Ihr Server gescannt wird. Die folgenden Befehle lesen nur und verändern nichts:
# Die zehn Adressen mit den meisten Anfragen im aktuellen Zugriffslog
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Anfragen, die mit "nicht gefunden" beantwortet wurden, nach Häufigkeit
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Gibt der Server seine PHP-Version im Header preis?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Viele Anfragen auf nicht vorhandene Pfade sind typisches Scan-Rauschen. Aufmerksamer sollten Sie werden, wenn auf solche Anfragen plötzlich erfolgreiche Antworten folgen, wenn in Upload-Ordnern Dateien aufgerufen werden, die Sie nicht kennen, oder wenn der Webserver-Benutzer Prozesse startet, die er sonst nie startet. Bestätigte Erkennungsmerkmale speziell für PHP2Shell gibt es bisher nicht, die Einordnung beruht deshalb auf solchen Verhaltensauffälligkeiten. Wie Sie Logs gründlicher auswerten, beschreibt der Ratgeber Webserver-Logs auswerten. Zeigt die dritte Abfrage eine PHP-Version, lohnt die Einstellung expose_php = Off; Hintergründe stehen unter Versionsangaben verbergen.
Die Schutzschichten in der richtigen Reihenfolge
- PHP aktualisieren und neu starten: Ohne diesen Schritt bleiben alle anderen Massnahmen Flickwerk.
- Angriffsfläche verkleinern: nicht genutzte Websites, Testsysteme und alte Microsites abschalten oder hinter eine Anmeldung legen.
- Regeln am Rand: Eine Web Application Firewall mit gepflegtem Regelwerk, etwa dem OWASP Core Rule Set mit ModSecurity, fängt einen Teil der Versuche ab.
- Wiederholte Versuche bremsen: Werkzeuge wie Fail2ban sperren Adressen, die auffällig viele Fehler erzeugen. Gegen verteilte Scans hilft das nur begrenzt.
- Überwachen: Prozesse des Webserver-Benutzers, neue PHP-Dateien und ausgehende Verbindungen im Blick behalten, damit ein erfolgreicher Treffer nicht wochenlang unbemerkt bleibt.
Wie hilft PHP SOS konkret?
- Angriffsfläche erfassen: Wir ermitteln, welche Ihrer Systeme von aussen erreichbar sind und was sie über sich preisgeben.
- Patchen und härten: Wir aktualisieren PHP, starten neu und reduzieren Versionsangaben, Schreibrechte und unnötige Dienste.
- Regeln und Sperren: Wir richten WAF-Regeln und Sperrmechanismen passend zu Ihrer Anwendung ein.
- Laufende Überwachung: Wir melden auffällige Prozesse, Dateien und Verbindungen, bevor ein Treffer zum Vorfall wird.
Wie das im Dauerbetrieb aussieht, beschreibt Security-Monitoring für Webserver.
Fazit
Automatisierte Angriffe fragen nicht, wem ein Server gehört. Sie fragen nur, ob er verwundbar ist. Die beste Antwort darauf ist unspektakulär: schnell patchen, wenig anbieten, genau hinsehen. Wer das tut, wird weiter gescannt, aber nicht mehr gefunden.
Häufige Fragen
Sind kleine Unternehmen Ziel automatisierter Angriffe?
Ja. Automatisierte Scans prüfen erreichbare Server ohne Ansehen des Betreibers. Ob dahinter ein Konzern oder ein Handwerksbetrieb steht, spielt für die Software keine Rolle. Entscheidend ist, ob der Server verwundbar wirkt.
Woran erkenne ich Scans in meinen Logs?
Typisch sind viele Anfragen auf Pfade, die es auf Ihrer Website gar nicht gibt, oft von wechselnden Adressen und mit auffälligen Kennungen. Solche Einträge sind normal und noch kein Beleg für einen erfolgreichen Angriff, zeigen aber, dass Ihr Server geprüft wird.
Hilft es, die PHP-Version zu verbergen?
Es macht es Scannern etwas schwerer, Ihren Server gezielt einzuordnen, und ist eine sinnvolle Grundeinstellung. Es schützt aber nicht vor Angriffen, die einfach jeden Server ausprobieren. Das Update bleibt Pflicht.
Kann ich Scans komplett verhindern?
Nein. Jeder öffentlich erreichbare Server wird regelmässig gescannt. Ziel ist nicht, Scans zu verhindern, sondern dafür zu sorgen, dass sie nichts finden: aktuelle Software, wenig Angriffsfläche und eine Überwachung, die Auffälligkeiten meldet.