616 Angriffsversuche in 8 Tagen

Es gab keine echten Angriffe. Alle 616 registrierten externen Sicherheitsereignisse vom 7. bis 15. Juli erwiesen sich als automatisierter Bot-Rauschen – Scanner, die Tausende von Websites nach bekannten WordPress-Schwachstellen durchsuchen. Unsere Website basiert nicht auf WordPress, daher existierten die gesuchten Pfade nie, und jeder Versuch endete mit einer Blockierung oder einem 404-Fehler.

Zahlen

Was genau wurde gesucht – und warum das für ungeschützte Websites gefährlich ist

Die folgenden Pfade sind klassische WordPress-Ziele. In unserem Fall waren sie harmlos, da diese Dateien einfach nicht existieren, aber es lohnt sich zu verstehen, warum diese bestimmten Pfade überhaupt gesucht werden.

/wp-login.php – 273 Anfragen, 197 eindeutige IPs Dies ist das WordPress-Admin-Anmeldeformular. Bots versuchen Brute-Force-Angriffe – überprüfen automatisch Tausende von Benutzernamen- und Passwort-Kombinationen in der Hoffnung, gültige Anmeldedaten zu erraten. Wenn eine Website schwache Passwörter hat oder keinen Login-Versuch-Limiter implementiert, kann ein solcher Angriff mit vollständigem Administrator-Zugriff enden.

/xmlrpc.php – 255 Anfragen, 183 eindeutige IPs Eine alte WordPress-Schnittstellendatei für Remote-Publishing. Sie ist ein beliebtes Angriffsziel aus zwei Gründen: Sie kann für Passwort-Guessing viel schneller als das Standard-Login-Formular verwendet werden (hunderte Kombinationen in einer Anfrage), und sie kann in DDoS-Amplification-Angriffen gegen Dritte über die "Pingback"-Funktion missbraucht werden.

/en/wp-json/wp/v2/users/me – 23 Anfragen, 21 eindeutige IPs Ein WordPress-REST-API-Endpunkt, der standardmäßig gültige Benutzernamen offenlegen kann. An sich ist dies kein Angriff, aber ein Aufklärungsschritt – durch das Kennen echter Benutzernamen kann der Angreifer nachfolgende Brute-Force-Versuche gezielter ausrichten.

/.env – 14 Anfragen, 12 eindeutige IPs Dies ist das einzige Ziel in unserer Liste, das echtes Schadenpotenzial hatte. .env-Dateien enthalten normalerweise Datenbankpasswörter, API-Schlüssel und andere Geheimnisse. Wenn eine solche Datei von außen zugänglich ist (aufgrund von Fehlkonfiguration des Servers), könnte der Inhalt durchgesickert werden und eine vollständige Systemkompromittierung bedeuten – nicht nur die Website, sondern auch zugehörige Dienste. In unserem Fall serviert Next.js diese Datei nicht öffentlich, daher endeten alle Versuche mit einem 404 oder einer Blockierung.

/lv/wp-content/uploads – 7 Anfragen, 7 eindeutige IPs Ein WordPress-Upload-Verzeichnis. Wenn es falsch konfiguriert ist (z. B. erlaubt es, PHP-Dateien auszuführen), kann ein Angreifer, der bereits minimalen Zugriff hat, ein bösartiges Skript hochladen und die vollständige Kontrolle über den Server erlangen.

Wie unser Sicherheitsmonitoring funktioniert

Diese Daten stammen nicht aus gewöhnlichen Server-Protokollen – sie werden von unserem entwickelten KI-Sicherheitssystem analysiert, das den gesamten eingehenden Verkehr überwacht, jedes Ereignis nach Schweregrad klassifiziert und in Echtzeit Blockierungsentscheidungen trifft. Das System ist mit einem Discord-Benachrichtigungskanal verbunden, auf dem zweimal täglich eine Zusammenfassung veröffentlicht wird – wie viele Ereignisse es gab, wie viele blockiert wurden und ob es etwas gibt, das Aufmerksamkeit verdient.

Zusätzlich zu regulären Berichten hat das System auch einen sogenannten Page-Call-Mechanismus – eine direkte dringende Benachrichtigung an das Entwicklungsteam, die die übliche zweimal tägliche Zusammenfassung umgeht und das Team sofort warnt, wenn etwas passiert, das sofortige Maßnahmen erfordert. Im Gegensatz zu typischen Rausch-Protokollen (wo hunderte Bot-Anfragen einfach stillschweigend protokolliert und blockiert werden), ist Page Call für seltene, wirklich bedeutsame Fälle reserviert.

Praktisch sieht ein Page Call so aus: Das Telefon erhält einen direkten dringenden Anruf, der über das Geschehene informiert. Dieser Anruf kann nicht stummgeschaltet werden – um ihn zu stoppen, muss man aufstehen und sich im System anmelden. Sobald jemand aus dem Team sich angemeldet hat, wird der Page Call deaktiviert, und das System zeigt, wer genau die Incident-Behebung übernommen hat. Sobald das Problem behoben ist, überprüft das System automatisch den Code auf Fehler und Schwachstellen, bevor er freigegeben wird – zuerst in unserem privaten GitHub-Repository, dann auf dem Server und schließlich auf der Live-Website – um sicherzustellen, dass überall eine konsistente und behobene Version vorhanden ist.

In letzter Zeit funktionierte dieser Mechanismus zwei Mal:

• Versuch, auf die .env-Datei zuzugreifen – da diese Datei Datenbankpasswörter und API-Schlüssel enthalten kann, klassifizierte das System dies als Hochrisiko-Ereignis und warnte das Team sofort, obwohl die Anfrage automatisch blockiert wurde.

• gramatika.evoex.eu Nichtverfügbarkeit – als diese Subdomain-Website nicht erreichbar wurde, erkannte das System dies als Betriebsunterbrechung (nicht als Sicherheitsincident) und benachrichtigte das Team sofort, um schnell reagieren und den Dienst wiederherstellen zu können.

Dieser zweistufige Ansatz – stilles Protokollieren bei massivem Bot-Rauschen, aber sofortige Benachrichtigung in seltenen, wirklich wichtigen Fällen – ermöglicht es dem Entwicklungsteam, sich nicht auf hunderte harmlose Scan-Versuche zu konzentrieren, während gleichzeitig garantiert wird, dass ein wirklich wichtiges Ereignis nicht bis zum nächsten geplanten Bericht unbemerkt bleibt.

Herkunft

Der größte Teil des Verkehrs kam aus den USA (157), Frankreich (52), Großbritannien (48), Vietnam (46), Deutschland (39), Singapur (36) und Indien (32). Die User-Agent-Strings waren wie üblich als gängige Browser gefälscht – ein typisches Zeichen eines Botnetzes, das versucht, wie ein echter Besucher auszusehen.

Der Trend ist deutlich rückläufig

Ereignisanzahl pro Tag (07-07 bis 07-15): 148 → 137 → 75 → 61 → 110 → 41 → 38 → 13 → 1.

Der Rückgang fällt mit der ständigen Blockierung von 95 IP-Adressen zusammen – die Verteidigung funktioniert genau wie beabsichtigt.

Fazit

Es gab keine erfolgreichen Angriffe, keine Datenlecks, keine Form-Spam- oder Authentifizierungsfehler. Alle Versuche waren automatisierte WordPress-Scanner, die nach Zielen suchten, die es hier nicht gibt. Dies bedeutet nicht, dass Sicherheit überflüssig ist – im Gegenteil, es zeigt, dass eine korrekt konfigurierte, nicht-WordPress-Architektur und aktive IP-Blockierung sogar massive automatisierte Angriffe effektiv verhindern, bevor sie etwas Wertvolles erreichen können.