Yandex Outage: Data Shows That Instead Of Going Dark, Malicious Bots Moved

Welcome back to Self-Hosted Tech. If you’ve been running a homelab or self-hosting your applications for any amount of time, you already know that the internet is a constant, invisible warzone. Every second, automated scripts are scanning IP addresses, probing ports, and trying to brute-force their way into your Nextcloud, Vaultwarden, or Home Assistant instances.

Recently, the cybersecurity world observed a fascinating phenomenon during a major Yandex outage. Yandex, often referred to as the “Google of Russia,” provides a massive array of cloud and infrastructure services. When their infrastructure went dark, security researchers tracking global botnet activity noticed something incredibly interesting: the malicious bots that were routing their traffic through Yandex’s network didn’t just give up and go offline.

Instead, the data showed that they moved.

In this article, we’re going to break down exactly how and why botnets migrate their infrastructure during an outage, what this means for your self-hosted services, and most importantly, how you can set up practical defenses to protect your homelab when the bot tide comes knocking at your door.

The Great Bot Migration: What Actually Happened?

When we think of an outage, we usually think of it from a user’s perspective. If Gmail goes down, you can’t send an email. If Yandex goes down, people can’t search the web or access their cloud storage. But for cybercriminals, an outage is a logistical nightmare.

A massive percentage of global malicious traffic doesn’t come directly from a hacker’s basement. It comes from compromised servers, residential proxies, and cloud hosting providers. Yandex Cloud and their associated network ranges have historically been a popular target for threat actors to spin up proxy nodes or host command-and-control (C2) servers.

When Yandex’s infrastructure dropped, the scripts powering these botnets hit a wall. Their primary proxy pools were suddenly unreachable. But here’s the thing about modern botnet architecture: it’s built for resilience.

How Bots Failover

Modern botnets don’t rely on a single point of failure. They use dynamic routing and fallback lists. If a bot script tries to route its attack or scraping request through a Yandex IP and receives a timeout, it doesn’t crash. Instead, it catches the error and pivots.

Data from the Yandex outage showed a near-immediate spike in malicious traffic originating from other cloud providers—specifically AWS, DigitalOcean, and Oracle Cloud. The bots simply moved to their backup proxy pools.

It’s the cyber equivalent of a highway closure. When the main road is blocked, all the traffic spills over onto the side streets. And in this analogy, your self-hosted homelab is a quiet little cul-de-sac that is suddenly dealing with a massive influx of angry, lost drivers.

Why This Matters for Your Homelab

You might be thinking, “I’m just a homelabber. I run a media server and a few Docker containers. Why would I be a target for migrating botnets?”

The truth is, bots don’t care how big you are. They operate on pure automation. When botnets migrate to new IP ranges, they immediately start scanning those ranges for vulnerabilities.

Here is what happens when a bot migration occurs and hits your public-facing services:

• Log Spam: Your Nginx or Traefik logs will suddenly fill up with 404 and 403 errors as bots look for exposed .env files, phpMyAdmin dashboards, or WordPress login pages.
• Resource Exhaustion: Bots hammering your server with HTTP requests can consume your CPU and RAM. If you are running local AI models on the same hardware, a sudden flood of malicious requests can cause your containers to crash due to out-of-memory (OOM) errors.
• Brute-Force Attacks: If you expose a login portal (like Guacamole, Nextcloud, or a reverse proxy with basic auth), migrating bots will immediately start throwing dictionary attacks at it.

So, how do we fight back? We can’t stop the bots from migrating, but we can ensure our homelab doors are locked, bolted, and guarded by an automated bouncer.

Practical Walkthrough: Tracking and Blocking Bots with CrowdSec

If you are still using Fail2Ban to protect your self-hosted services, it might be time for an upgrade. While Fail2Ban is a classic, it operates in a vacuum. It only knows what happens on your server.

To defend against migrating botnets, we need a collaborative approach. We need CrowdSec.

CrowdSec is a modern, open-source Intrusion Prevention System (IPS). It reads your logs, detects malicious behavior, and blocks the IP. But here’s the magic: when it blocks an IP on your server, it shares that IP with the global CrowdSec community. In return, your server downloads a constantly updated blocklist of IPs that have been caught acting maliciously on other people’s servers.

If a botnet migrates to a new AWS IP and attacks someone else’s server, CrowdSec will block that IP on your server before the bot even gets a chance to scan you.

Let’s walk through setting up CrowdSec on a typical Linux homelab server.

Step 1: Install CrowdSec

Installing CrowdSec is incredibly straightforward. You can run their automated bash script, which will detect your operating system and install the necessary repositories.

Fire up your terminal and run:

1
2
3

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt update
sudo apt install crowdsec -y

During the installation, CrowdSec will automatically detect common services running on your machine (like Nginx, Apache, or SSH) and install the corresponding “parsers” to read their logs.

Step 2: Install a Bouncer

CrowdSec has two main components: the agent (which reads logs and makes decisions) and the bouncer (which actually blocks the traffic at the firewall or application level).

If you are using Nginx as your reverse proxy, the easiest bouncer to start with is the Nginx bouncer.

1

sudo apt install crowdsec-nginx-bouncer -y

Note: If you use Traefik, you can use the Traefik bouncer plugin, which integrates beautifully via Docker labels. We’ll cover a Docker-specific setup in a future article, but for this walkthrough, we will focus on the system-level Nginx integration.

Once installed, restart Nginx to apply the changes:

1

sudo systemctl restart nginx

Step 3: Verify the Community Blocklist is Working

By default, CrowdSec is subscribed to the community blocklist. This means your server is already protected by the collective knowledge of thousands of other CrowdSec users.

To see the IPs currently blocked on your system, run:

1

sudo cscli decisions list

You will likely see a massive list of IPs. These aren’t IPs that attacked you specifically; these are IPs that have been flagged globally. If a botnet just migrated to a new DigitalOcean IP and attacked a CrowdSec node in Germany, that IP is now blocked on your homelab in real-time.

Step 4: Monitor Your Own Metrics

To see what CrowdSec is doing on your specific machine, check out the metrics:

1

sudo cscli metrics

This command will show you how many log lines were parsed, how many scenarios were triggered, and what IPs were caught trying to attack your server. If you see a sudden spike in local decisions, it means a bot has found your IP and is actively trying to break in.

Alternative Defense: Manual Rate Limiting in Nginx

While CrowdSec is the best overall solution, sometimes you just want a quick, native fix to stop bots from hammering your endpoints. Rate limiting in Nginx is a fantastic way to tell aggressive bots to slow down.

Let’s say you have a self-hosted AI endpoint (like a local LLM API) and you don’t want a bot to spam it with requests and eat up your GPU resources.

First, define a rate limit zone in your nginx.conf file (usually located in /etc/nginx/nginx.conf). Place this inside the http {} block:

1
2
3
4
5
6

http {
    # Define a zone called "ai_limit" that allows 5 requests per second per IP
    limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=5r/s;
    
    # ... rest of your nginx config ...
}

Next, apply this zone to your specific server block or location. Open your site configuration file (e.g., /etc/nginx/sites-available/your-ai-app.conf):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

server {
    listen 80;
    server_name ai.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        
        # Apply the rate limit. burst=10 allows sudden spikes, nodelay means process them immediately
        limit_req zone=ai_limit burst=10 nodelay;
        
        # Return a 429 Too Many Requests status when the limit is hit
        limit_req_status 429;
    }
}

Test your configuration and restart Nginx:

1
2

sudo nginx -t
sudo systemctl restart nginx

Now, if a migrating bot decides to slam your AI endpoint with hundreds of requests a second, Nginx will immediately start returning 429 Too Many Requests errors, protecting your hardware and keeping your service responsive for legitimate users.

Keeping an Eye on the Logs

When major outages happen—whether it’s Yandex, AWS, or Cloudflare—it’s always a good idea to keep an eye on your reverse proxy logs. You can often spot a bot migration in real-time.

If you use Docker and Traefik, you can watch your access logs with:

1

docker logs -f traefik

If you use Nginx:

1

sudo tail -f /var/log/nginx/access.log

If you suddenly see a flood of requests from IP addresses you don’t recognize, all looking for /wp-admin or /.env, you know a botnet has migrated into your IP neighborhood.

Summary

The recent Yandex outage provided a rare, real-time look into the resilient architecture of modern botnets. When their primary infrastructure went dark, they didn’t stop their malicious activities—they simply pivoted to new cloud providers and proxy networks. For self-hosters and homelab enthusiasts, these migrations mean sudden spikes in scanning, scraping, and brute-force attempts against our public-facing services.

To protect your homelab from migrating bots:

1. Understand the threat: Bots are automated and resilient. They will find your IP.
2. Use collaborative defense: Install CrowdSec to benefit from a global blocklist that adapts in real-time to bot migrations.
3. Implement rate limiting: Use native Nginx or Traefik rate limiting to protect your hardware resources from being exhausted by HTTP floods.
4. Monitor your logs: Keep an eye on your access logs during major internet outages so you can react quickly if your server becomes a target.

Call to Action

Have you noticed an uptick in bot traffic on your homelab recently? Are you using CrowdSec, Fail2Ban, or something else to keep the bad actors out? Let us know in the comments below!

If you found this tutorial helpful, make sure to hit that like button, subscribe to the Self-Hosted Tech YouTube channel, and check out our blog for more guides on securing your homelab, running local AI, and taking back control of your data. Until next time, stay secure and keep self-hosting!