Як захистити гаманець від DDoS-атак: ховаємо origin-сервер за Cloudflare

Архітектурний гайд з безпеки для фронтенд- і full-stack-розробників. Дізнайтеся, як уникнути непередбачуваних рахунків за хостинг через сплески шкідливого трафіку та приховати IP origin-сервера за допомогою безкоштовного тарифу Cloudflare.

Vladyslav Tsyvinda
Vladyslav Tsyvinda
·Оновлено
Обкладинка: Як захистити гаманець від DDoS-атак: ховаємо origin-сервер за Cloudflare

Як захистити гаманець від DDoS-атак: ховаємо origin-сервер за Cloudflare

Коли інженери говорять про DDoS-атаки (Distributed Denial of Service), вони зазвичай мають на увазі падіння серверів, простої сервісу та зіпсований користувацький досвід. Але якщо ви самі керуєте інфраструктурою, деплоїте застосунки на звичайний VPS чи розвиваєте техстартап, існує значно небезпечніша загроза: шок від рахунку (так звані Bill-DDoS або Wallet-DDoS атаки).

Більшість хмарних провайдерів беруть плату за вихідний (egress) трафік. Якщо шкідливий ботнет засипає ваш сервер гігабайтами сміттєвих запитів, застосунок, можливо, і переживе цей потоп, а от рахунок за хмарний хостинг — навряд чи. Розгляньмо, як відбувається Wallet-DDoS і як повністю безкоштовно захистити свій сервер — і свій банківський рахунок — за допомогою Cloudflare.


1. Анатомія Wallet-DDoS

Уявіть, що у вас є full-stack застосунок на Next.js або Node.js, розгорнутий на звичайному хмарному дроплеті чи VPS. Провайдер щедро надає 2 ТБ безкоштовного трафіку на місяць. За нормального використання ви рідко перевищуєте й 10% цього ліміту.

Однієї ночі зловмисник атакує ваш сервер звичайним HTTP flood, генеруючи 500 запитів на секунду. Навіть якщо ваш Nginx чи Node-рантайм успішно відхиляє ці запити з відповіддю 400 Bad Request або 403 Forbidden, сервер однаково мусить надіслати мережевий пакет у відповідь. За 48 годин такий обсяг може згенерувати кілька терабайтів мережевого трафіку. Хмарний провайдер зараховує це як вихідний трафік, і раптом ви отримуєте автоматичний рахунок на сотні або й тисячі доларів за перевищення ліміту.

Щоб цього уникнути, потрібно змінити фундаментальне правило мережевої маршрутизації: ніколи не відкривайте «голу» IP-адресу сервера в публічний інтернет.


2. На сцену виходить проксі Cloudflare («помаранчева хмаринка»)

Ключова можливість Cloudflare — reverse proxy. Коли ви пропускаєте домен через Cloudflare й вмикаєте знамениту іконку «Orange Cloud» у DNS-дашборді, ви активуєте архітектурний щит.

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

  • Клієнт під’єднується безпосередньо до найближчого edge-сервера Cloudflare.
  • Cloudflare аналізує структуру запиту, SSL-рукостискання та патерни трафіку.
  • Якщо запит чистий, Cloudflare отримує дані з вашого прихованого origin-сервера й повертає їх клієнту.
  • Якщо запит є частиною шкідливого ботнету чи DDoS-флуду, Cloudflare відкидає трафік прямо на edge.

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


3. Безпека крок за кроком: запобігаємо «обходу»

Просто ввімкнути проксі Cloudflare недостатньо. Якщо зловмисник дізнається чи вгадає справжню публічну IP-адресу вашого сервера (наприклад, зі старої історії DNS або з незамаскованого заголовка поштового сервера), він зможе надсилати трафік безпосередньо на ваш IP, повністю оминаючи Cloudflare.

Щоб гарантувати повну безпеку, потрібно встановити жорсткий мережевий периметр одним із двох способів:

Спосіб A: посилюємо файрвол (UFW / iptables)

Налаштуйте файрвол сервера так, щоб він відхиляв будь-які вхідні з’єднання на порти 80 і 443, якщо вони не надходять із перевірених IP-адрес Cloudflare. На сервері з Ubuntu це можна автоматизувати: отримати офіційний список IP Cloudflare й створити простий скрипт із правилами:

# Блокуємо весь стандартний вебтрафік за замовчуваннямsudo ufw default deny incoming# Дозволяємо трафік ЛИШЕ з IP Cloudflare (проходимо циклом по діапазонах IP Cloudflare)for ip in $(curl -s https://www.cloudflare.com/ips-v4); do sudo ufw allow from $ip to any port 443 proto tcp; done

Спосіб B: ідеальний сетап (Cloudflare Tunnels)

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

З тунелем ви можете повністю закрити всі вхідні порти на сервері. Вашому застосунку взагалі не потрібна публічна IP-адреса, відкрита в інтернет, — тож зловмисник фізично не зможе оминути Cloudflare й дістатися вашого origin.


4. Посилюємо захист на безкоштовному тарифі

Щойно origin-сервер успішно приховано, перейдіть у дашборд Cloudflare й увімкніть ці три інструменти безпеки, доступні на безкоштовному плані:

  • Under Attack Mode: якщо бачите сплеск трафіку в реальному часі, вмикайте цей режим. Cloudflare показуватиме відвідувачам короткий ненав’язливий криптографічний челендж, повністю відсіюючи автоматизовані браузерні скрипти.
  • Cloudflare Turnstile: замініть застарілі CAPTCHA на маршрутах автентифікації чи у формах на Turnstile — безкоштовний інструмент, орієнтований на приватність, який перевіряє справжніх користувачів, не змушуючи їх розв’язувати головоломки.
  • WAF Rate Limiting: налаштуйте безкоштовне правило Web Application Firewall, яке блокуватиме будь-яку IP-адресу, що звертається до ваших API-ендпоінтів понад 60 разів за хвилину.

Висновок

У сучасній веброзробці захищена інфраструктура так само критична, як і чистий код. Захист застосунку від шкідливого трафіку не повинен вимагати бюджету на безпеку корпоративного рівня. Використовуючи безкоштовний тариф Cloudflare, щоб приховати IP origin-сервера й фільтрувати вхідні запити, ви вбережете сервер від простоїв, а свою кредитку — від катастрофічних рахунків за перевищення ліміту.