Bot Traffic After the Reported Yandex Data Center Strikes
Our operators' qualitative observation, not a measurement. After the reported strikes on Yandex data centers, the people who read DCXV server logs felt that traffic from some bot-farm networks had thinned out: fewer automated requests, fewer brute-force attempts, fewer suspicious HTTP POST requests. We publish no counts, percentages, graphs or rates, because we ran no controlled comparison. This post covers what we look at, what these traffic types look like, how to harden a server whatever the source, and how to test the claim yourself.
What was reported
In early October, Reuters reported that drones hit Yandex data centers on two consecutive days, and Yandex said several modules at its Kaluga site were disabled and some services might be disrupted (Reuters report via The Star). We have not confirmed these events ourselves, and we take no position on who was responsible. This post is about traffic and server hygiene only. For the provider-risk side, see hosting with Yandex and in high-risk regions.
What we looked at
DCXV operators read four things: web server and WAF logs, SSH authentication logs, hits on our own honeypot paths (URLs no real visitor opens), and the HTTP error log. They watch them over time as part of normal work. There was no fixed before and after window, no baseline and no control group. What follows is an impression from people who know what these logs usually look like, nothing stronger.
What these traffic types look like in logs
Three patterns matter here. All examples below are illustrative: addresses come from the documentation ranges and timestamps are placeholders.
- Automated requests - the same paths fetched in a tight rhythm with a generic or empty user agent, often probing for admin panels and old scripts.
- Brute-force attempts - many failed logins for different user names from one source, or one user name tried from many sources.
- Suspicious POST requests - repeated POST to login, XML-RPC or form endpoints, usually with a 200 or 401 answer and no earlier page view.
Example lines (illustrative, not real 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"
Hardening checklist that works for any source
None of these steps depends on where a client comes from. Do them in this order and keep a second SSH session open while you change sshd, so a typo cannot lock you out. More on keys in our SSH guide for a new cloud server.
1. Key-only SSH. Disable passwords and root password login, then test the config before reload:
# /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 for sshd. Ban a source after a few failures:
# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h
3. Rate limit login endpoints in nginx. Slow a script down without hurting a human:
# 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 rules - block known probe paths and oversized or malformed POST bodies; start in log-only mode, then enforce.
- POST endpoint protection - require a CSRF token, cap body size, return the same error for a wrong user and a wrong password.
- CAPTCHA or challenge - show it only after a few failures, not to every visitor.
- Monitoring and alerting - alert on a jump in failed logins or 4xx on POST, and review the top sources weekly.
Why blocking a country is a weak control on its own
IP geolocation is a best guess. VPNs, proxies and rented servers move a bot to any country, and a botnet made of hijacked home routers sits wherever those routers are. A country block also stops real customers, travelers and partners. It can be one cheap layer among others, but it will not replace key-only SSH, rate limits and a WAF, and it can age badly when traffic moves to other networks.
How to test the claim on your own servers
If you want evidence instead of impressions, set the rules before you look at the data:
- Fix the windows - choose equal before and after periods, including the same weekdays, before you open any log.
- Keep filters identical - same log files, same counting rules, same bans and rate limits in both periods.
- Take a baseline - compare with a longer quiet stretch, because campaigns come and go without any outside event.
- Group by network, not by country - count by source network, and note rented or proxy ranges separately.
- Write down your own changes - a new firewall rule or a moved site can look like a trend.
Two starting points, to run over each window with the same filters:
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
Limits of our observation
Please read this as a hypothesis from one operator, not a finding:
- Correlation is not causation - two things happening near each other does not link them.
- Attribution is imperfect - IP geolocation and ASN data mislabel VPNs, proxies, rented infrastructure and foreign botnets.
- Traffic shifts - bots may have moved to other networks, so less from one place is not less overall.
- One network is not the internet - our view is limited to what reaches our servers.
- It may be temporary, and other causes are possible: blocking elsewhere, seasonality, ended campaigns or our own filtering.
Next steps
Start with key-only SSH and a login rate limit; they take minutes and help against every source. If you need a clean server to apply this checklist, see our cloud servers in Prague and Covilhã, and use the trial checklist to test one properly. Questions or your own observations: sales@dcxv.com.
