Bot-Traffic nach gemeldeten Yandex-Rechenzentrum-Angriffen
Qualitative Beobachtung unserer Betreiber, keine Messung. Nach den gemeldeten Angriffen auf Yandex-Rechenzentren hatten die Leute, die DCXV-Serverlogs lesen, den Eindruck, dass der Traffic aus einigen Botfarm-Netzen nachließ: weniger automatisierte Anfragen, weniger Brute-Force-Versuche, weniger verdächtige HTTP-POST-Anfragen. Wir veröffentlichen keine Zahlen, Prozente, Grafiken oder Raten, denn wir haben keinen kontrollierten Vergleich gemacht. Der Beitrag zeigt, worauf wir schauen, wie diese Traffic-Arten in Logs aussehen, wie Sie einen Server unabhängig von der Quelle härten und wie Sie die These selbst prüfen.
Was gemeldet wurde
Anfang Oktober meldete Reuters, Drohnen hätten an zwei aufeinanderfolgenden Tagen Yandex-Rechenzentren getroffen; Yandex erklärte, am Standort in der Region Kaluga seien mehrere Module ausgefallen und einige Dienste könnten gestört sein (Reuters-Meldung bei The Star). Wir haben diese Ereignisse nicht selbst bestätigt und nehmen keine Position dazu ein, wer verantwortlich ist. Dieser Beitrag behandelt nur Traffic und Server-Hygiene. Zur Anbieterseite siehe Hosting bei Yandex und in Hochrisikoregionen.
Worauf wir geschaut haben
DCXV-Betreiber lesen vier Quellen: Webserver- und WAF-Logs, SSH-Authentifizierungslogs, Zugriffe auf eigene Honeypot-Pfade (URLs, die kein echter Besucher öffnet) und das HTTP-Fehlerlog. Sie beobachten sie im Alltag über längere Zeit. Es gab kein festes Vorher-Nachher-Fenster, keine Baseline und keine Kontrollgruppe. Das Folgende ist der Eindruck von Menschen, die wissen, wie diese Logs normalerweise aussehen, mehr nicht.
Wie diese Traffic-Arten in Logs aussehen
Drei Muster zählen. Alle Beispiele sind illustrativ: Adressen stammen aus Dokumentationsbereichen, Zeitstempel sind Platzhalter.
- Automatisierte Anfragen - dieselben Pfade in engem Takt mit generischem oder leerem User-Agent, oft auf der Suche nach Admin-Oberflächen und alten Skripten.
- Brute-Force-Versuche - viele fehlgeschlagene Logins mit wechselnden Benutzernamen von einer Quelle oder ein Benutzername von vielen Quellen.
- Verdächtige POST-Anfragen - wiederholte POSTs auf Login-, XML-RPC- oder Formular-Endpunkte, meist mit Antwort 200 oder 401 und ohne vorherigen Seitenaufruf.
Beispielzeilen (illustrativ, kein echter Traffic):
sshd[1234]: Failed password for invalid user admin from 203.0.113.7 port 51234 ssh2
sshd[1235]: Failed password for invalid user test from 203.0.113.7 port 51240 ssh2
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /wp-login.php HTTP/1.1" 200 5120 "-" "Mozilla/5.0"
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /xmlrpc.php HTTP/1.1" 200 420 "-" "Mozilla/5.0"
Härtungs-Checkliste, die für jede Quelle funktioniert
Kein Schritt hängt davon ab, woher ein Client kommt. Gehen Sie in dieser Reihenfolge vor und halten Sie beim Ändern von sshd eine zweite SSH-Sitzung offen, damit ein Tippfehler Sie nicht aussperrt. Mehr zu Schlüsseln in unserer SSH-Anleitung für einen neuen Cloud-Server.
1. SSH nur mit Schlüssel. Passwörter und Root-Passwort-Login abschalten, die Konfiguration vor dem Reload prüfen:
# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 20
sudo sshd -t && sudo systemctl reload ssh
2. fail2ban für sshd. Eine Quelle nach wenigen Fehlversuchen sperren:
# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h
3. Rate Limit für Login-Endpunkte in nginx. Ein Skript bremsen, ohne Menschen zu stören:
# http {} context
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# server {} context
location = /login {
limit_req zone=login burst=5 nodelay;
limit_req_status 429;
proxy_pass http://127.0.0.1:3000;
}
- WAF-Regeln - bekannte Probe-Pfade sowie übergroße oder fehlerhafte POST-Bodys blocken; erst im reinen Log-Modus, dann durchsetzen.
- Schutz der POST-Endpunkte - CSRF-Token verlangen, Body-Größe begrenzen, für falschen Benutzer und falsches Passwort dieselbe Fehlermeldung liefern.
- CAPTCHA oder Challenge - erst nach einigen Fehlversuchen zeigen, nicht jedem Besucher.
- Monitoring und Alarme - bei einem Anstieg fehlgeschlagener Logins oder 4xx auf POST alarmieren und die Top-Quellen wöchentlich prüfen.
Warum eine Länder-Sperre allein eine schwache Kontrolle ist
IP-Geolokalisierung ist eine Schätzung. VPNs, Proxys und gemietete Server versetzen einen Bot in jedes Land, und ein Botnetz aus gekaperten Heimroutern sitzt dort, wo diese Router stehen. Eine Länder-Sperre trifft außerdem echte Kunden, Reisende und Partner. Sie kann eine billige Schicht unter mehreren sein, ersetzt aber weder SSH nur mit Schlüssel noch Rate Limits oder eine WAF und veraltet schnell, wenn der Traffic in andere Netze wandert.
So prüfen Sie die These auf Ihren eigenen Servern
Wer Belege statt Eindrücke will, legt die Regeln fest, bevor er auf die Daten schaut:
- Fenster festlegen - gleich lange Zeiträume davor und danach wählen, mit denselben Wochentagen, bevor Sie ein Log öffnen.
- Identische Filter - dieselben Logdateien, dieselbe Zählregel, dieselben Sperren und Limits in beiden Zeiträumen.
- Baseline erheben - mit einer längeren ruhigen Phase vergleichen, denn Kampagnen kommen und gehen ohne äußeren Anlass.
- Nach Netz gruppieren, nicht nach Land - nach Quellnetz zählen und gemietete oder Proxy-Bereiche getrennt notieren.
- Eigene Änderungen notieren - eine neue Firewall-Regel oder ein umgezogener Dienst kann wie ein Trend wirken.
Zwei Startpunkte, die Sie je Fenster mit denselben Filtern ausführen:
sudo journalctl -u ssh --since "24 hours ago" --no-pager | \
grep "Failed password" | \
awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
awk '$6 == "\"POST"' /var/log/nginx/access.log | \
awk '{print $7}' | sort | uniq -c | sort -rn | head
Grenzen unserer Beobachtung
Lesen Sie das bitte als Hypothese eines Betreibers, nicht als Befund:
- Korrelation ist keine Kausalität - zwei zeitnahe Ereignisse sind nicht automatisch verbunden.
- Zuordnung ist unvollkommen - IP-Geolokalisierung und ASN-Daten verwechseln VPNs, Proxys, gemietete Infrastruktur und ausländische Botnetze.
- Traffic wandert - Bots können in andere Netze gezogen sein, weniger von einem Ort heißt nicht weniger insgesamt.
- Ein Netz ist nicht das Internet - wir sehen nur, was unsere Server erreicht.
- Es kann vorübergehend sein, und andere Ursachen sind möglich: Sperren anderswo, Saisonalität, beendete Kampagnen oder unsere eigene Filterung.
Nächste Schritte
Beginnen Sie mit SSH nur per Schlüssel und einem Login-Rate-Limit; das dauert Minuten und hilft gegen jede Quelle. Für einen frischen Server zum Anwenden dieser Checkliste sehen Sie unsere Cloud-Server in Prag und Covilhã, und die Test-Checkliste hilft beim sauberen Ausprobieren. Fragen oder eigene Beobachtungen: sales@dcxv.com.
