Cloudflare: реальний досвід відбиття DDoS атаки з росії

1

Вступ

Коли я купив домен і прийняв рішення на своїй Raspberry Pi розгорнути публічний сайт (цей блог, який ви зараз читаєте) я знав, що DDoS-атака відбудеться, обов’язково, але це було питання часу. Цей час настав. В цьому дописі я поділюся своїм досвідом, як я відбив DDoS-атаку за допомогою Cloudflare на безкоштовному тарифі. Я тут надам графіки та результати роботи по факту завершення атаки, проте вони будуть доволі інформативними для візуального сприйняття.

Превентивні заходи

Я продовжую вивчати сучасні мережеві можливості, нові технології, розбираюся в налаштуваннях та сервісах. На моєму сервері наразі встановлено декілька веб сервісів, але з точки зору безпеки, я для них обмежив доступ із інтернету, залишивши лише локальну мережу. Такі заходи не можуть стосуватися публічного веб ресурсу – цього блогу. Після написання десь 5ї статті я подумав про захист від DDoS-атак, і перше що прийшло на думку це був сервіс Cloudflare.

Cloudflare – це потужна платформа для забезпечення безпеки, оптимізації швидкодії та підвищення стабільності веб ресурсів. Завдяки глобальній мережі дата-центрів Cloudflare діє як проміжна ланка між сайтом і відвідувачем: кешує контент, блокує небажаний трафік і надає аналітику.

На початковому рівні я вибрав безкоштовний тарифний план, який має певні обмеженні на відміну від комерційного, проте цього цілком достатньо для базових потреб захисту сайту. Щоб почати користуватися Cloudflare необхідно виконати декілька простих кроків:

  • Зареєструватися на Cloudflare
  • В адмін панелі реєстратора домена необхідно прописати DNS записи серверів Cloudflare
  • В адмін панелі Cloudflare додати DNS записи свого фізичного сервера

Після внесення змін почнеться переіндексація DNS записів яка може тривати до 72 годин, проте в моєму випадку це сталося менше ніж за добу. Після цього я видихнув і почав вже користуватися сайтом повноцінно покладаючись на Cloudflare.

Визначення DDoS атаки

Для моніторингу ресурсів своєї локальної мережі я використовую Zabbix. Зазвичай я відслідковую активність поштового серверу, температури Raspberry Pi та інші метрики. Візуально на дашборді розмістив декілька віджетів, щоб наглядно і швидко можна було визначати аномалії в роботі сервісів.

Зазвичай температура становить приблизно 60 – 65°C, проте я звернув увагу на завищену температуру на майже 10 градусів, до 70 – 75°C. В цей час я перевів погляд на навантаження ЦП, і він був на рівні 50%, я відразу зрозумів що щось коїться не те.

Я передивився метрики сервера і майже всі значення графіків свідчили про позаштатну ситуацію

Візуальні графіки показують лише загальну картину. Тепер моя мета була визначити корінь зла. Для цього я підключився до сервера, та почав переглядати стан процесів та роботи сервісів. На жаль під час діагностики я не зробив скріншотів проте скопіював текст з консолі. По історії команд спробую відтворити хід подій.

Ресурс CPU

Першою командою я визначив перші 15 процесів із високим споживанням ресурсу CPU.

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

Я отримав таку видачу:

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

Звісно значення були по 10-20% CPU на процес, що в сумі давало доволі велику сумарну навантаженість.

Джерело трафіку

Другою командою треба було визначити, які IP генерують багато трафіку. Цією командою виводиться перші 10 IP адрес по кількості запитів.

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

Я отримав таку видачу:

 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

Ця інформація відображає локальні запити (127.0.0.1) – понад 118 тис. звернень, тобто хтось із самого сервера активно запитує сайт. Пул IP-адрес 162.158.x.x і 104.23.x.x – належить Cloudflare, як проксі, отже, реальний трафік прихований за Cloudflare і певні правила мого роутера не працюють.

В мене додатково на роутері вже налаштована гео-фільтрація трафіку, яка виключає будь який трафік з росії та білорусі.

Причетність віртуального хоста

Наступним етапом можна визначити який саме сайт або віртуальний хост грузить сервер. Для цього проаналізуємо перші 100 рядків логу, проте для покращеної статистики можна це число збільшити. Оскільки я цю атаку визначив на ранній стадії, то 100 рядків достатньо.

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

Я отримав таку видачу:

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
...

Можна знехтувати зверненнями до zabbix, адже основні запити йдуть на WordPress. Якщо підсумувати, то результат діагностики наступний:

  • apache2 – споживає більш за всізх ресурсу процесора
  • локальне IP та IP Cloudflare – має найбільшу кількість запитів
  • запити до сторінок WordPress

На першому етапі цих діагностичних даних виявилося достатньо для визначення подальших дій.

Безпекові дії на Cloudflare

Я не очікував, що Cloudflare настільки потужний інструмент, навіть в безкоштовній версії. За замовчанням багато функцій вимкнуто, і при певних атаках їх треба активувати вручну, а по завершенні атаки рекомендується деактивувати ці налаштування. Основним режимом є I’m under attack mode.

I’m under attack mode

I’m Under Attack Mode – це спеціальна функція Cloudflare, призначена для захисту веб сайтів від DDoS-атак, зокрема на рівні HTTP-флуду (наприклад, атаки через масове надсилання GET/POST-запитів). Основний принцип дії цього режиму наступний:

  • Перед кожним візитом до сайту відображається проміжна сторінка перевірки, яка триває кілька секунд.
  • Cloudflare виконує JavaScript-челендж — тобто змушує браузер «довести», що він не є ботом.
  • Якщо перевірка проходить успішно — користувач потрапляє на сайт.
  • Боти та прості скрипти, які не можуть виконати JS — автоматично відсіюються.

Цей режим можна включити в розділі Security -> Settings, там є перемикач I’m under attack mode, його треба активувати, і робота відбиття атаки почнеться негайно.

В новому інтерфейсі, цей пункт перенесли на вкладку All settings в самий низ, і назвали Security Level. При натисканні на Edit можна включити або виключити режим I’m under attack mode.

Після активації цього режиму на дашборді з’явиться повідомлення:

Under Attack Mode is active
Under Attack mode is used when a website is under a DDoS attack. All visitors will be shown an interstitial page for a short duration.

В такому режимі відбувається невеличка затримка із перевіркою, яка має такий вигляд:

В розділі Security -> Events можна побачити записи про ініціатора запитів, відображається доволі вичерпана та впорядкована інформація. В новому інтерфейсі розділ Events перенесено в меню Analytics та створено закладку Events де інформація так само структурована.

Custom та IP access rules

Враховуючи, що DDoS атака відбулася з однієї IP адреси, то можна для неї застосувати правила.

  • IP access rules – для блокування IP адрес поодиноко чи використовуючи маску підмережі
  • Custom rules – більш гнучке налаштування правил

Спочатку я вирішив створити правило яке б блокувало атакуючий сервер по IP адресі, для цього в новому інтерфейсі треба перейти в розділ Security -> Security rules -> IP access rules та натиснути на кнопку +Create. Для створення правила достатньо заповнити лише 4 поля:

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

З самого початку я хотів заблокувати взагалі всю росію по геолокації, але в безкоштовному тарифному плані, на рівні IP access rules так реалізув не можна, після застосування цього правила я бачу помилку: Sorry, block by country is only available on the Enterprise plan.

Виявляється, в безкоштовній версії існує фільтр по геолокації, проте його можна налаштувати в розділі Custom rules.

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

Таким чином правило буде виглядати так

Звіти

В розділі Security -> Overview можна побачити графік співвідношення – обмеженого, обробленого Cloudflare та оброблено сервером трафіка, до загальної кількості запитів. При активній роботі Cloudflare, значення обмеження трафіку (Mitigated) буде збільшуватися, також буде збільшуватись кількість кешованих запитів, адже Cloudflare в такому режимі працює без прямого трафіку і має ряд обмежень, для запобігання хакерських дій, по типу підбору пароля брутфорсом.

На дашборді – Overview відображено багато корисних графіків. Я зробив кілька скріншотів, на початку атаки та під її завершення. Графік відображає останні 24 години активності, тому я наклав ці два графіки, щоб показати вам загальну картину активності. Червоним прямокутником я позначив діапазон роботи сервісу Cloudflare від початку до кінця.

Графіки доволі інформативні, а налаштування Cloudflare не викликає труднощів. Згідно із графіком атака тривала 17 годин від початку, а завдяки моїй пильності, на початку атаки, на 6й годині я застосував засоби захисту Cloudflare, та вже за 11 годин атака була припинена, думаю через її нераціональність для зловмисника.

Після завершення атаки я вимкнув режим I’m under attack mode та продовжую моніторинг активності сервера, щоб бути готовим в будь який час запобігти повторним викликам!

Висновки

Досвід боротьби з DDoS-атакою на власному сервері показав, що навіть з мінімальними ресурсами — Raspberry Pi, власний блог і безкоштовний тариф Cloudflare — можна ефективно захищатися від загроз, якщо мати базове розуміння роботи мережі, серверів і систем моніторингу.

Я переконався, що:

  • Превентивні дії важливі. Встановлення Cloudflare заздалегідь дозволило оперативно увімкнути захисні механізми.
  • Засоби моніторингу, такі як Zabbix, допомагають швидко виявити аномалії і локалізувати джерело проблеми.
  • Cloudflare виявився надзвичайно ефективним навіть у безкоштовному варіанті, зокрема завдяки режиму I’m Under Attack, який дозволяє відсіяти шкідливий трафік ще до потрапляння на сервер.
  • Відкритість до навчання та аналізу логів — ключ до швидкої реакції. Команди ps, awk, аналіз access.log допомогли не лише виявити джерело навантаження, а й зробити висновки щодо типу атаки.

Цей випадок підтвердив, що надійний захист — це не завжди дорога інфраструктура, а в першу чергу уважність, готовність до реагування та вміння працювати з доступними інструментами.

Мій блог залишився онлайн, і це найкращий показник ефективності застосованих рішень.

, ,