Cloudflare: real experience repelling a DDoS attack from russia

Introduction

When I bought a domain and decided to deploy a public site on my Raspberry Pi (this blog you are reading now) I knew that a DDoS attack would happen, for sure, but it was only a matter of time. That time has come. In this post, I’ll share my experience of how I fended off a DDoS attack with Cloudflare on a free plan. I will provide here the graphs and results of the work on the fact of the completion of the attack, but they will be quite informative for visual perception.

Preventive measures

I continue to study modern network capabilities, new technologies, understand settings and services. I currently have several web services installed on my server, but from a security point of view, I have restricted access from the Internet to only the local network. Such measures cannot apply to a public web resource – this blog. After writing about the 5th article, I thought about protection against DDoS attacks, and the first thing that came to mind was the Cloudflare service.

Cloudflare – is a powerful platform for ensuring security, optimizing performance and increasing the stability of web resources. Thanks to a global network of data centers, Cloudflare acts as an intermediate link between the site and the visitor: it caches content, blocks unwanted traffic and provides analytics.

At the entry level, I chose the free plan, which has some limitations unlike the commercial one, but it is quite enough for basic site protection needs. To start using Cloudflare, you need to follow a few simple steps:

• Sign up for Cloudflare
• In the admin panel of the domain registrar it is necessary to register the DNS records of the Cloudflare servers
• In the admin panel of Cloudflare add DNS records of your physical server

After making the changes, the reindexing of DNS records will begin, which can take up to 72 hours, but in my case it happened in less than a day. After that, I breathed a sigh of relief and started using the site fully relying on Cloudflare.

DDoS attack detection

I use Zabbix to monitor the resources of my local network. I usually monitor mail server activity, Raspberry Pi temperatures, and other metrics. Visually, I placed several widgets on the dashboard so that anomalies in the operation of services can be clearly and quickly identified

Normally the temperature is around 60 – 65°C, but I noticed an over temperature of almost 10 degrees, up to 70 – 75°C. At this time, I looked at the CPU load, and it was at the level of 50%, I immediately understood that something was wrong.

I looked at the server metrics and almost all of the graph values ​​indicated an emergency situation

Visual charts only show the big picture. Now my goal was to identify the root of the evil. To do this, I connected to the server and started viewing the status of processes and services. Unfortunately, I did not take screenshots during the diagnostics, but I copied the text from the console. I will try to reproduce the course of events based on the history of the teams.

CPU resource

With the first command, I identified the first 15 processes with high CPU consumption.

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -n 15

I got the following output:

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -n 15
    PID    PPID CMD                         %MEM %CPU
2366770 1943100 /usr/sbin/apache2 -k start   1.1 12.4
2373538 1943100 /usr/sbin/apache2 -k start   1.2 12.2
2374705 1943100 /usr/sbin/apache2 -k start   1.2 11.8
2374940 1943100 /usr/sbin/apache2 -k start   1.2 11.3
2376091 1943100 /usr/sbin/apache2 -k start   1.0 11.1
2370641 1943100 /usr/sbin/apache2 -k start   1.2 10.4
2355557 1943100 /usr/sbin/apache2 -k start   1.2 10.4
    709       1 /opt/networkoptix/mediaserv  5.7  9.6
2375784 1943100 /usr/sbin/apache2 -k start   1.0  9.3
2373539 1943100 /usr/sbin/apache2 -k start   1.2  7.8
2375416 1943100 /usr/sbin/apache2 -k start   1.2  7.1
2376564 1943100 /usr/sbin/apache2 -k start   0.8  6.9
2372672 1943100 /usr/sbin/apache2 -k start   1.2  6.9

Of course, the values ​​were 10-20% CPU per process, which in sum gave quite a large total load.

Traffic source

The second team had to determine which IPs generate a lot of traffic. This command displays the first 10 IP addresses based on the number of requests.

awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -n 10

I got the following output:

 118852 127.0.0.1
   7169 162.158.239.23
   7168 162.158.238.232
   6304 162.158.238.233
   5810 162.158.239.24
   5068 162.158.238.106
   4848 162.158.238.107
   3871 162.158.238.120
   3843 162.158.238.121
   2875 104.23.217.65

This information reflects local requests (127.0.0.1) – more than 118 thousand requests, that is, someone from the server actively requests the site. The pool of IP addresses 162.158.x.x and 104.23.x.x is owned by Cloudflare, as a proxy, so the real traffic is hidden behind Cloudflare and certain rules of my router are not working.

Virtual host involvement

The next step is to determine which site or virtual host is loading the server. To do this, we will analyze the first 100 lines of the log, however, for improved statistics, this number can be increased. Since I detected this attack at an early stage, 100 lines is enough.

sudo tail -n 100 /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -20

I got the following output:

29 /wp-login.php
22 /wp-admin/images/
7 /zabbix/zabbix.php?action=widget.item.view
4 /zabbix/zabbix.php?action=widget.svggraph.view
1 /wp-cron.php?doing_wp_cron=1748089832.8370869159698486328125
...

If you ignore requests to Zabbix, then the main requests go to WordPress. To summarize, the result of the diagnosis is as follows:

• apache2 – consumes more than all the resources of the processor
• local IP and Cloudflare IP – has the most requests
• requests to WordPress pages

At the first stage, these diagnostic data turned out to be sufficient to determine further actions.

Cloudflare Security Actions

I didn’t expect Cloudflare to be such a powerful tool, even in the free version. Many features are disabled by default and must be enabled manually for certain attacks, and it is recommended to deactivate these settings after the attack is over. The main mode is I’m under attack mode.

I’m under attack mode

I’m Under Attack Mode is a special Cloudflare feature designed for protection of websites from DDoS attacks, in particular at the level HTTP flood (e.g., bulk GET/POST attacks). The basic principle of operation of this mode is as follows:

• Before each visit to the site an intermediate verification page is displayed, which lasts a few seconds.
• Cloudflare does JavaScript challenge — that is, forces the browser to “prove” that it is not a bot.
• If the check is successful, the user gets to the site.
• Bots and simple scripts that cannot execute JS – automatically are sifted out.

This mode can be enabled in the Security -> Settings section, there is a switch I’m under attack mode, it must be activated, and the work of repelling the attack will begin immediately.

In the new interface, this item was moved to the All settings tab at the bottom, and named Security Level. When you click on Edit, you can enable or disable I’m under attack mode.

After activating this mode, a message will appear on the dashboard:

In this mode, there is a small delay with the check, which looks like this:

In the Security -> Events section, you can see records about the initiator of the requests, rather complete and organized information is displayed. In the new interface, the Events section has been moved to the Analytics menu and the Events tab has been created, where the information is structured in the same way.

Custom and IP access rules

Given that the DDoS attack occurred from a single IP address, rules can be applied to it.

• IP access rules – to block IP addresses individually or using a subnet mask
• Custom rules – more flexible setting of rules

First, I decided to create a rule that would block the attacking server by IP address, for this in the new interface you need to go to the Security -> Security rules -> IP access rules section and click on the +Create button. To create a rule, it is enough to fill in only 4 fields:

• IP, IP range, country name, or ASN – 194.67.196.50
• Action – Block
• Zone – This website
• Notes – Fucking russian hacker

From the very beginning, I wanted to block all of russia by geolocation, but in the free tariff plan, at the level it is not possible to do so, after applying this rule I see an error: Sorry, block by country is only available on the Enterprise plan.

It turns out that there is a geolocation filter in the free version, but it can be configured in the Custom rules section.

• Rule name (required) – Block_country_404
• Field – Country
• Operator – equals
• Value – russian federation
• Then take action – Block
• Place at – First

This way the rule will look like this

Reports

In the Security -> Overview section, you can see a graph of the ratio of restricted, Cloudflare-handled and server-handled traffic to the total number of requests. When Cloudflare is active, the value of the traffic limit (Mitigated) will increase, and the number of cached requests will also increase, because Cloudflare in this mode works without direct traffic and has a number of restrictions to prevent hacking, such as password selection by brute force.

Many useful graphs are displayed on the dashboard – Overview. I took several screenshots, at the beginning of the attack and at the end of it. The graph shows the last 24 hours of activity, so I’ve overlayed these two graphs to show you the big picture of activity. I marked the range of Cloudflare’s service from start to finish with a red rectangle.

The graphs are quite informative and setting up Cloudflare is easy. According to the schedule, the attack lasted 17 hours from the beginning, and thanks to my vigilance, at the beginning of the attack, at the 6th hour, I applied Cloudflare protection, and already in 11 hours the attack was stopped, I think because of its irrationality for the attacker.

After the attack was over, I turned off the I’m under attack mode and continue to monitor server activity to be ready to prevent repeated attacks at any time!

Conclusions

The experience of fighting a DDoS attack on my own server has shown that even with minimal resources – a Raspberry Pi, my own blog, and a free Cloudflare plan – you can effectively protect yourself from threats if you have a basic understanding of how the network, servers, and monitoring systems work.

I was convinced that:

• Preventive actions are important. Installing Cloudflare in advance allowed me to quickly enable protective mechanisms.
• Monitoring tools such as Zabbix help to quickly detect anomalies and localize the source of the problem.
• Cloudflare has proven to be extremely effective even in its free version, in particular thanks to the I’m Under Attack mode, which allows you to filter out malicious traffic before it even reaches the server.
• Openness to learning and log analysis is the key to a quick response. The ps, awk commands, and access.log analysis helped not only identify the source of the load, but also draw conclusions about the type of attack.

This case confirmed that reliable protection is not always expensive infrastructure, but primarily attentiveness, readiness to respond, and the ability to work with available tools.

My blog remained online, and this is the best indicator of the effectiveness of the solutions applied.