Trafic de bots après les frappes sur des data centers Yandex
Observation qualitative de nos opérateurs, pas une mesure. Après les frappes signalées sur des data centers Yandex, les personnes qui lisent les logs des serveurs DCXV ont eu l'impression que le trafic de certains réseaux de fermes de bots s'était réduit : moins de requêtes automatisées, moins de tentatives de force brute, moins de requêtes HTTP POST suspectes. Nous ne publions ni chiffres, ni pourcentages, ni graphiques, ni débits, car nous n'avons mené aucune comparaison contrôlée. L'article explique ce que nous regardons, à quoi ressemblent ces types de trafic dans les logs, comment durcir un serveur quelle que soit la source et comment tester l'affirmation vous-même.
Ce qui a été signalé
Début octobre, Reuters a rapporté que des drones avaient touché des data centers de Yandex deux jours de suite, et Yandex a indiqué que plusieurs modules de son site de la région de Kalouga étaient hors service et que certains services pouvaient être perturbés (article de Reuters sur The Star). Nous n'avons pas confirmé ces événements nous-mêmes et ne prenons pas position sur les responsabilités. Cet article ne traite que du trafic et de l'hygiène des serveurs. Pour le risque côté fournisseur, voir hébergement chez Yandex et dans les régions à haut risque.
Ce que nous avons regardé
Les opérateurs de DCXV lisent quatre sources : les logs du serveur web et du WAF, les logs d'authentification SSH, les accès à nos propres chemins honeypot (des URL qu'aucun vrai visiteur n'ouvre) et le journal des erreurs HTTP. Ils les suivent dans la durée, dans le cadre du travail normal. Il n'y avait ni fenêtre avant et après fixée, ni référence, ni groupe témoin. Ce qui suit est l'impression de personnes qui savent à quoi ressemblent d'habitude ces logs, rien de plus fort.
À quoi ressemblent ces types de trafic dans les logs
Trois motifs comptent. Tous les exemples ci-dessous sont illustratifs : les adresses viennent de plages réservées à la documentation et les horodatages sont des espaces réservés.
- Requêtes automatisées - les mêmes chemins à un rythme très régulier avec un user agent générique ou vide, souvent à la recherche de panneaux d'administration et de vieux scripts.
- Tentatives de force brute - de nombreuses connexions échouées avec des noms différents depuis une source, ou un nom essayé depuis de nombreuses sources.
- Requêtes POST suspectes - des POST répétés vers la connexion, XML-RPC ou des formulaires, en général avec une réponse 200 ou 401 et sans consultation de page avant.
Exemples de lignes (illustratifs, pas du trafic réel) :
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"
Checklist de durcissement valable pour toute source
Aucune étape ne dépend de l'origine du client. Suivez cet ordre et gardez une seconde session SSH ouverte pendant que vous modifiez sshd, pour qu'une faute de frappe ne vous enferme pas dehors. Plus sur les clés dans notre guide SSH pour un nouveau serveur cloud.
1. SSH par clé uniquement. Désactivez les mots de passe et la connexion root par mot de passe, puis testez la configuration avant de recharger :
# /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 pour sshd. Bannissez une source après quelques échecs :
# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h
3. Limite de débit sur les points de connexion dans nginx. Ralentissez un script sans gêner une personne :
# 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;
}
- Règles WAF - bloquez les chemins de sondage connus et les corps POST trop gros ou mal formés ; commencez en mode journal seul, puis appliquez.
- Protection des points POST - exigez un jeton CSRF, limitez la taille du corps, renvoyez la même erreur pour un mauvais utilisateur et un mauvais mot de passe.
- CAPTCHA ou défi - ne l'affichez qu'après quelques échecs, pas à chaque visiteur.
- Surveillance et alertes - alertez sur un bond des connexions échouées ou des 4xx sur POST, et examinez chaque semaine les principales sources.
Pourquoi bloquer un pays est un contrôle faible à lui seul
La géolocalisation IP est une estimation. Les VPN, proxys et serveurs loués placent un bot dans n'importe quel pays, et un botnet de routeurs domestiques détournés se trouve là où sont ces routeurs. Un blocage par pays arrête aussi de vrais clients, des voyageurs et des partenaires. Il peut être une couche peu coûteuse parmi d'autres, mais il ne remplace ni le SSH par clé, ni les limites de débit, ni un WAF, et vieillit mal quand le trafic passe par d'autres réseaux.
Comment tester l'affirmation sur vos propres serveurs
Si vous voulez des preuves plutôt que des impressions, fixez les règles avant de regarder les données :
- Fixez les fenêtres - choisissez des périodes avant et après de même durée, avec les mêmes jours de la semaine, avant d'ouvrir un log.
- Filtres identiques - mêmes fichiers de log, même règle de comptage, mêmes bannissements et limites sur les deux périodes.
- Prenez une référence - comparez à une plus longue période calme, car les campagnes vont et viennent sans événement extérieur.
- Groupez par réseau, pas par pays - comptez par réseau source et notez à part les plages louées ou de proxy.
- Notez vos propres changements - une nouvelle règle de pare-feu ou un site déplacé peut ressembler à une tendance.
Deux points de départ à exécuter sur chaque fenêtre avec les mêmes filtres :
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
Limites de notre observation
Lisez ceci comme l'hypothèse d'un opérateur, pas comme un constat :
- Corrélation n'est pas causalité - deux faits proches dans le temps ne sont pas forcément liés.
- L'attribution est imparfaite - la géolocalisation IP et les données ASN confondent VPN, proxys, infrastructure louée et botnets d'autres pays.
- Le trafic se déplace - les bots peuvent être passés par d'autres réseaux ; moins depuis un endroit ne veut pas dire moins au total.
- Un réseau n'est pas internet - nous ne voyons que ce qui atteint nos serveurs.
- Cela peut être temporaire, et d'autres causes sont possibles : blocages ailleurs, saisonnalité, campagnes terminées ou notre propre filtrage.
Prochaines étapes
Commencez par le SSH par clé et une limite de débit sur la connexion : quelques minutes, utile contre toute source. Pour un serveur propre où appliquer cette checklist, voyez nos serveurs cloud à Prague et à Covilhã, et la checklist d'essai pour en tester un correctement. Questions ou observations personnelles : sales@dcxv.com.
