Kurz gesagt: Ob DDoS oder Hackerangriff, zeigt sich an den Spuren. Ein DDoS erzeugt sehr viele Anfragen und macht die Website langsam oder unerreichbar, verändert aber nichts. Ein Exploit braucht oft nur wenige Anfragen und hinterlässt neue Dateien, Konten, Prozesse oder Verbindungen. Die richtige Einordnung entscheidet, ob Sie Last abwehren oder einen Vorfall eindämmen müssen.
Der Unterschied in einfachen Worten
Ein DDoS-Angriff (Distributed Denial of Service) ist wie eine Menschenmenge, die den Eingang eines Geschäfts blockiert. Niemand kommt hinein, aber im Laden wird nichts gestohlen. Ziel ist, Ihre Website oder Ihren Server zu überlasten, damit echte Kunden nicht mehr durchkommen.
Ein Exploit ist dagegen ein Einbruch durch eine offene Tür. Der Angreifer nutzt eine Schwachstelle, etwa in PHP, im CMS oder in einer Erweiterung, um Code auf Ihrem Server auszuführen. Das kann leise geschehen, ohne dass die Website langsamer wird. Die Folgen reichen von Spam-Seiten über Datendiebstahl bis zur Übernahme des Servers.
Für die Geschäftsführung ist der Unterschied entscheidend: Ein DDoS ist ein Verfügbarkeitsproblem, das mit dem Angriff endet. Ein erfolgreicher Exploit ist ein Sicherheitsvorfall, der bleibt, bis er gefunden, bereinigt und dokumentiert ist.
DDoS oder Hackerangriff: die Anzeichen im Vergleich
Die folgende Tabelle hilft bei der ersten Einordnung. Sie ersetzt keine Analyse, zeigt aber, wo Sie zuerst hinschauen sollten.
| Merkmal | Eher DDoS | Eher Exploit oder Einbruch |
|---|---|---|
| Erreichbarkeit | langsam oder ausgefallen | oft normal |
| Anfragen im Log | sehr viele, oft gleichförmig | wenige, gezielte Anfragen |
| Dateien | unverändert | neue oder veränderte PHP-Dateien |
| Konten | unverändert | neue Admins, geänderte Passwörter |
| Prozesse | Webserver und PHP unter Volllast | unbekannte Prozesse, Mining, Spam-Versand |
| Netzwerk | viel eingehender Verkehr | ungewöhnliche ausgehende Verbindungen |
| Nach dem Ende | alles wie vorher | Spuren bleiben bestehen |
Achtung bei Überschneidungen: Massenhaftes Scannen nach einer Lücke kann wie ein kleiner DDoS aussehen. Genau das war rund um PHP2Shell zu erwarten, als Angreifer nach verwundbaren Servern suchten. Hohe Last kann also auch bedeuten, dass jemand gerade versucht, einzubrechen.
Erste Prüfungen auf dem Server
Die folgenden Befehle ändern nichts am System und geben einen schnellen Überblick. Sichern Sie bei Verdacht auf einen Einbruch die Logs, bevor Sie größere Eingriffe vornehmen.
# Last und Laufzeit
uptime
# Verbindungen zusammengefasst und die häufigsten Gegenstellen
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Häufigste Client-Adressen im Access-Log (Pfad anpassen)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# PHP-Dateien, die in den letzten 7 Tagen geändert wurden
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Prozesse mit der höchsten CPU-Last
ps aux --sort=-%cpu | head -15
Bei der Verbindungsübersicht zeigt die vierte Spalte die Gegenstelle. Viele Verbindungen von wenigen Adressen oder ein Anstieg auf ein Vielfaches des Normalwerts deuten auf Überlastung. Neue PHP-Dateien in Upload- oder Cache-Verzeichnissen, Prozesse unter dem Webserver-Benutzer mit fremden Namen oder ausgehende Verbindungen zu unbekannten Zielen deuten eher auf einen Einbruch. Eine ausführliche Liste finden Sie unter Anzeichen einer Kompromittierung nach PHP2Shell.
Warum hohe Last auch ein Ablenkungsmanöver sein kann
Es kommt vor, dass Angreifer eine Überlastung erzeugen, während sie gleichzeitig gezielt einbrechen. Das Team ist dann mit der Erreichbarkeit beschäftigt, und die eigentlichen Spuren gehen im Lograuschen unter. Deshalb gilt: Auch wenn ein DDoS offensichtlich ist, prüfen Sie nach dessen Ende Dateien, Konten und ausgehende Verbindungen.
Im Fall von PHP2Shell kommt hinzu, dass es laut php.net und den Sicherheitsfirmen keine veröffentlichten, bestätigten Indicators of Compromise gibt. Die Erkennung beruht auf Verhaltensanalyse. Ein Server, der während des Scanning-Zeitraums ab Mitte Oktober ungepatcht war, sollte deshalb unabhängig von der beobachteten Last geprüft werden.
Eine weitere Variante sind Erpressungsmails, in denen mit einem DDoS-Angriff gedroht wird, falls nicht gezahlt wird. Bewahren Sie solche Nachrichten auf, zahlen Sie nicht ohne Abstimmung mit Fachleuten und prüfen Sie eine Anzeige bei der Zentralen Ansprechstelle Cybercrime. Informieren Sie parallel Ihren Hoster, damit Schutzmaßnahmen vorbereitet werden können. Wie Sie die Logs dafür auswerten, steht im Ratgeber Webserver-Logs nach einem Angriff auswerten.
Was Sie in den ersten Stunden tun sollten
Bei Verdacht auf DDoS:
- Hoster oder Rechenzentrum informieren; dort gibt es oft Filter vor dem Server.
- Einen vorgeschalteten Schutzdienst oder eine WAF mit virtuellem Patching aktivieren oder verschärfen.
- Rate-Limits im Webserver setzen und teure Seiten wie Suche oder Warenkorb besonders schützen.
- Logs aufbewahren, damit der Angriff später nachvollziehbar ist.
Bei Verdacht auf einen Einbruch:
- Nichts löschen und den Server nicht neu aufsetzen, bevor Logs und betroffene Dateien gesichert sind.
- PHP auf eine behobene Version aktualisieren und alle Worker neu starten, falls das noch nicht geschehen ist.
- Wenn das Update nicht sofort möglich ist, die Website vorübergehend vom Netz nehmen, wie es das BSI empfiehlt.
- Zugangsdaten von einem sauberen Gerät aus erneuern, nicht vom möglicherweise betroffenen Server.
- Prüfen lassen, ob personenbezogene Daten betroffen sein könnten; dann können Meldefristen laufen.
In beiden Fällen hilft eine kurze, sachliche Notiz für Hoster und Dienstleister: seit wann das Problem besteht, welche Websites betroffen sind, was Sie beobachtet haben und was bereits geändert wurde. Halten Sie außerdem fest, wer welche Entscheidung getroffen hat. Diese Zeitleiste spart in der Analyse Zeit und ist später für Versicherung, Datenschutz und interne Nachbereitung wertvoll. Ist unklar, ob überhaupt ein Angriff vorliegt, behandeln Sie die Lage vorsorglich als Vorfall, bis das Gegenteil belegt ist.
Wie hilft PHP SOS konkret?
- Wir ordnen die Lage remote anhand von Last, Logs, Dateien und Verbindungen ein und sagen Ihnen, womit Sie es wahrscheinlich zu tun haben.
- Bei Überlastung setzen wir Filter, Rate-Limits und vorgeschaltete Schutzregeln, bis der Angriff abklingt.
- Bei Einbruchsverdacht übernehmen wir die strukturierte Incident Response: sichern, eindämmen, Ursache finden, bereinigen.
- Am Ende dokumentieren wir, was passiert ist und welche Maßnahmen umgesetzt wurden, bis der Vorfall abgeschlossen ist.
Häufige Fragen
Kann ein DDoS-Angriff Daten stehlen?
Ein reiner DDoS-Angriff zielt auf die Erreichbarkeit, nicht auf Daten. Er verändert keine Dateien und liest keine Datenbanken. Er kann aber gleichzeitig mit einem Einbruchsversuch auftreten, deshalb lohnt sich trotzdem ein Blick auf Dateien und Konten.
Woran erkenne ich, dass meine Website gehackt wurde?
Typische Hinweise sind neue oder veränderte PHP-Dateien, unbekannte Admin-Konten, Weiterleitungen auf fremde Seiten, unerwartete ausgehende Verbindungen und Prozesse, die nicht zu Ihrer Anwendung passen. Ein einzelnes Anzeichen ist kein Beweis, mehrere zusammen sind ein ernstes Signal.
Hilft ein CDN oder eine WAF gegen beide Angriffsarten?
Gegen volumenbasierte Angriffe hilft ein vorgeschalteter Dienst meist gut. Gegen Exploits wirken Regeln nur, wenn sie das Muster erkennen. Bei PHP2Shell weist Cloudflare selbst darauf hin, dass Regeln anhand der Anfragedaten allein nicht genügen.
Muss ich einen DDoS-Angriff melden?
Das hängt vom Einzelfall und von Ihrer Branche ab. Ohne Zugriff auf personenbezogene Daten greift die DSGVO-Meldepflicht in der Regel nicht, branchenspezifische Pflichten können aber bestehen. Klären Sie das mit Ihrem Datenschutzbeauftragten oder einem Anwalt.