A network going dark tells you nothing about the bots behind it

On 14 October 2026, Cloudflare published an analysis, built on Cloudflare Radar and Bot Management data, of what happened to Yandex's networks after reported strikes on Yandex data centers in Russia between 7 and 11 October 2026 hit three Yandex facilities progressively. According to Cloudflare, on 11 October traffic collapsed to 99% below baseline for Yandex Search (AS13238) and 90% below baseline for Yandex.Cloud (AS200350). Cloudflare reports that both networks stayed disrupted through 13 October, at 86-90% below normal baselines.

That is the news, and Cloudflare is the primary source for it. For anyone running a server, the outage itself is not the interesting part. The interesting part is what the bots did next. Cloudflare's own summary puts it in one line: "Physical infrastructure is static, but malicious automation is built to move."

The honest answer on how to block bot traffic

If you are trying to work out how to block bot traffic, the honest first answer is this: blocking by network does not hold up. The Yandex case shows why better than any theory could.

Cloudflare found that nearly all of Yandex.Cloud's bot requests were aimed at one gambling customer account. Immediately after the 8 October disruption, bot requests from Yandex.Cloud to that account dropped to zero. At the same time, identical requests started arriving from other Russian hosting ASNs, including Radist and Selectel.

"Identical" here is specific. Cloudflare reports that the arriving traffic kept the same JA4 TLS client fingerprint, the same uncommon request paths and HTTP headers, and the same custom User-Agent strings across providers. Russian bot traffic targeting gambling accounts, as measured on Cloudflare's network, stayed essentially flat across the week: 167.7 million requests before, 170.1 million during, a rise of 1.4%.

Think about what that means for a site owner. A block on AS200350 would have looked great on a dashboard for a short while. Then the same software would have arrived from a different address, and the block would have done nothing for the total.

Why a network is just a rented address

An autonomous system number (ASN) identifies a network, usually one company's. A hosting provider's ASN tells you where a virtual machine is rented. It does not tell you what runs on that machine, and Cloudflare itself makes the point that the origin of traffic does not tell you who is responsible for it.

Moving a bot workload is cheap. The operator keeps the scripts, the configuration and the target list, opens an account with another provider, starts a few servers and points the same code at the same targets. That is a job of hours, not weeks.

What does not change in a move is the code and its habits: how it negotiates TLS, which headers it sends, which paths it asks for and how fast. Those are the things you can actually filter on.

What actually dropped, and why it proves the point

The headline figures look like a huge fall in bot traffic. Look at what made them up and the picture changes.

According to Cloudflare's sampled requests, the Yandex Search drop consisted almost entirely of verified search crawlers: 78.1% were verified YandexBot, 11.5% YandexRenderResourcesBot and 1.9% YandexImages. Cloudflare reports the steepest industry drop was Publishing and Newspapers, where traffic from Yandex networks fell 44%. These are the crawlers that index pages so people can find them.

Cloudflare also notes that even before the event, 40.5% of its customers returned HTTP 403 to that crawler because the site owner had blocked it. When the network went offline, those sites simply saw less indexing. The most visible collapse was mostly lost indexing, not lost attackers.

Yandex.Cloud looked completely different. Cloudflare scored about 95.0% of its requests as bots, and none of the observed bot requests were verified. They behaved like ordinary software clients, some identifying themselves as JavaScript, Python or Go programs.

Cloudflare measured bot traffic from Yandex.Cloud falling about 40% during the event. Attack-like categories fell harder: WordPress plugin probing fell 90% and scanner-identified requests fell 93%. Customer WAF blocks on Yandex.Cloud traffic fell 70% over the same period.

Those drops describe one network, not the scanners themselves. Plugin probing and vulnerability scanning are the most portable automation there is, because a scanner needs only an address to run from and a list of paths to try. Cloudflare's data shows they stopped coming from Yandex.Cloud. It does not show they stopped existing.

Scale matters too. By Cloudflare's count, Yandex Search supplied about 7% of Russia-origin bot requests and 0.05% of the global total, and Yandex.Cloud about 2% and 0.01%. A drop from one small network is a lead worth checking, not a verdict, the same thinking behind treating an automated scan as a lead rather than a verdict.

What you can do on your own server this week

None of this needs an enterprise budget. It needs you to defend paths and patterns instead of address ranges.

1. Find the endpoints that actually get abused. On WordPress that is usually /wp-login.php and /xmlrpc.php. On Nextcloud it is the login and API routes. Contact forms, search pages and any API you expose belong on the list too. A quick count of your top requested paths shows you where the pressure is.

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

2. Rate limit and challenge those endpoints, not the whole site. In nginx, a small zone for login pages stops brute-force loops without touching normal visitors. Pair it with fail2ban or your application's own brute-force protection, and put a challenge in front of forms if you sit behind a proxy that offers one.

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
limit_req zone=login burst=5 nodelay;
# your usual PHP handling here
}

3. Keep logs long enough to compare weeks. Many default setups keep only a few days. Weekly rotation with eight copies (weekly and rotate 8 in logrotate) gives you two months to compare against.
4. Watch for repeated fingerprints from new addresses. If your CDN or reverse proxy exposes a JA4 fingerprint, log it. If not, the combination of User-Agent, Accept headers and requested paths is a rough fingerprint of its own. Add the extra headers to your log format so you can see them.

log_format botwatch '$remote_addr [$time_local] "$request" $status "$http_user_agent" "$http_accept" "$http_accept_language"';

5. Alarm when the same paths come back from a different network. A daily count per path is enough. If a path you just rate limited drops and then climbs back with a new set of source addresses, you are looking at a migration, not a fix.
6. Do not block whole hosting providers or whole countries. Your own users, your uptime monitor, your backup jobs and legitimate crawlers live on those networks too. A wide block mostly hurts them, while the automation you meant to stop simply rents somewhere else. Blocked software looks for another way out, a pattern that also shows up when you filter outbound traffic from self-hosted AI agents.

How to tell a real reduction from a migration

Measure requests to your own endpoints before and after any change. Then compare by path and by fingerprint, not by source address. A list of blocked IPs growing every day tells you very little. Requests per day to /xmlrpc.php tells you a lot.

A mitigation that works reduces requests to a path. One that only moves traffic leaves the per-path count flat while the addresses change, which is exactly what Cloudflare saw with the gambling account: per its data, about 167.7 million requests before and 170.1 million during, from different networks with the same fingerprint.

Cloudflare ran the same kind of check on claims that the strikes had crippled social media manipulation. It found no unexpected change, either from Russian-origin IPs (a 0.6% decrease in total traffic over the event period) or globally (a 1.2% increase). On the post, reply and like endpoints of a specific social media platform, it measured Russian-origin traffic down 5.7% and global traffic up 1.1%. Its conclusion was that the data does not appear to support those claims, "though without further analysis with data outside of Cloudflare, we cannot conclusively say there is no connection".

That hedge is worth copying in your own work. Every figure here was measured on Cloudflare's network only, not the whole internet. Before the event, Cloudflare counted automated requests at 36.1% of all HTTP traffic it observed globally and 35.8% of traffic from Russian IP addresses. Your server will have its own numbers, and the origin of a request still does not tell you who is responsible for it.

Cloudflare's own recommendation lines up with all of this. It calls client ASN traffic volume an unreliable proxy for interpreting automated bot behavior, and says defending against automated threats means inspecting request behavior: identifying shared JA4 fingerprints, monitoring anomalous request rates and applying WAF rules to sensitive endpoints, regardless of which network a request arrives from.

If you would rather have this set up for you

If you want someone to harden the server, set the rate limits and get the logging in place so you can compare weeks properly, take a look at the services page. You can also find me on Fiverr: hiteshsaini459 - Upwork: hiteshsaini25.