Налаштування Cloudflare для бізнес-сайту: швидкість та захист крок за кроком

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

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

Перед початком

• Зробіть опис DNS. Вивантажте або сфотографуйте всі записи у поточного провайдера DNS, включаючи поштові (MX, SPF, DKIM, DMARC) та записи підтвердження. Пропущений запис – класичний спосіб зламати пошту під час переїзду.
• З'ясуйте, хто володіє обліковим записом реєстратора домену, і переконайтеся, що це корпоративний обліковий запис з багатофакторною автентифікацією. Саме там ви зміните сервери назв.
• Зменшіть TTL ключових записів за день, якщо можливо, щоб зміни розповсюджувалися швидше.
• Виберіть тихий час та попередьте команду. Продумайте відкат: старі сервери імен, записані заздалегідь.

Крок 1: додайте сайт та перевірте DNS

Додайте домен у панелі Cloudflare. Він просканує наявні записи. Порівняйте їх з описом та закрийте пробіли. Для кожного запису виберіть один із двох режимів:

• Проксується (помаранчева хмара): трафік йде через Cloudflare. Використовуйте для сайту та хостів веб-програми.
• Тільки DNS (сіра хмара): Cloudflare просто відповідає на DNS-запит. Використовуйте для поштових серверів, хостів SSH та FTP та всього, що не є HTTP або HTTPS.

Потім змініть сервери назв у реєстратора. Коли сайт стане активним, перевірте його та надішліть тестовий лист.

Крок 2: правильно настройте шифрування

Саме це налаштування ламає найбільше сайтів. У Cloudflare кілька режимів SSL/TLS:

• Flexible: шифрує ділянку відвідувач - Cloudflare, але передає трафік на ваш сервер без шифрування. Виглядає робітником, але друга ділянка відкрита і часто викликає циклічні редиректи. Уникайте.
• Full: шифрує обидві ділянки, але не перевіряє сертифікат сервера.
• Full (strict): шифрує обидві ділянки та перевіряє сертифікат на вашому сервері. Використовуйте саме його.

Спочатку встановіть на сервер діючий сертифікат. Підійде сертифікат Cloudflare Origin CA або безкоштовний Let's Encrypt. Потім перейдіть на Full (strict), увімкніть Always Use HTTPS, задайте мінімальну версію TLS 1.2 і включайте HSTS тільки коли все працює по HTTPS, тому що HSTS на довгий час забороняє браузерам звичайний HTTP.

Крок 3: унеможливити обхід Cloudflare

Якщо атакуючі знають реальну IP-адресу вашого сервера, вони можуть надсилати трафік безпосередньо та обходити всі налаштовані захисту. Це вирішується двома способами:

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

#!/usr/bin/env bash
# /opt/cf/update_cloudflare_ips.sh - run weekly from cron
set -euo pipefail
IPS="$(curl -fsS https://www.cloudflare.com/ips-v4) $(curl -fsS https://www.cloudflare.com/ips-v6)"

# 1) real visitor IP for Nginx
OUT=/etc/nginx/conf.d/cloudflare_real_ip.conf
{
  for r in $IPS; do echo "set_real_ip_from $r;"; done
  echo "real_ip_header CF-Connecting-IP;"
} > "$OUT.tmp" && mv "$OUT.tmp" "$OUT"
nginx -t && nginx -s reload

# 2) firewall: allow HTTPS only from Cloudflare (remove any generic "allow 443" rule first)
for r in $IPS; do ufw allow proto tcp from "$r" to any port 443 comment 'cloudflare'; done

Важлива деталь для тих, хто використовує Docker: порти, опубліковані Docker, обходять правила ufw. Прив'язуйте контейнери до localhost за зворотним проксі або обмежуйте доступ у ланцюжку фаєрвола Docker DOCKER-USER. Для сильнішої ізоляції Cloudflare Tunnel дозволяє серверу встановлювати лише вихідне з'єднання, і тоді вхідні веб-порти взагалі не потрібні. Для платіжних веб-хуків та інших інтеграцій «сервер — сервер» переконайтеся, що правила по IP, як і раніше, пропускають ці запити, якщо вони йдуть не через Cloudflare.

Крок 4: правила кешування

За промовчанням Cloudflare кешує статичні файли – зображення, CSS та JavaScript, – але не HTML. Розумна політика для типового PHP-сайту:

• Статичні ресурси: кешувати надовго (місяць і більше). Використовуйте версійні імена файлів або параметр app.css?v=123, щоб новий деплой підхоплювався відразу.
• Публічні HTML-сторінки (маркетингові сторінки, блог): можна кешувати на хвилини чи години через Cache Rule. Тестуйте уважно.
• Ніколи не кешувати: адмінку, особистий кабінет, кошик, оформлення замовлення, API та будь-які сторінки, що залежать від cookie входу. Створіть правило обходу кешу для цих шляхів та для запитів з вашої сесійної cookie.

Скидайте кеш автоматично після кожного деплою, щоб клієнти не бачили застарілі файли. Створіть API-токен тільки з правом Cache Purge для цієї зони і викликайте його зі скрипта деплою:

# purge selected files after a deployment
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/css/app.css","https://example.com/js/app.js"]}'

Швидкі сторінки також допомагають пошуку та конверсії. У нашому посібнику Core Web Vitals для PHP-сайтів описано, що виправляти на стороні сервера після підключення CDN.

Крок 5: фаєрвол, боти та обмеження частоти

• Увімкніть керовані правила WAF, доступні на вашому тарифі. Вони блокують типові атаки до того, як вони дійдуть до вашого коду.
• Увімкніть захист від роботів, що підходить вашому тарифу, і дивіться аналітику, перш ніж щось посилювати.
• Обмежте частоту запитів до чутливих точок: вхід, скидання пароля, реєстрація та оформлення замовлення. Саме їх атакують перебором та перевіркою карт.
• Виключіть довірений машинний трафік: платіжні вебхуки, сервіси моніторингу та ваші інтеграції не повинні отримувати перевірки для браузерів, адже сторінка перевірки, повернена вебхуку, виглядає як збій.

# Custom rule 1: block probes for secrets and repositories (action: Block)
(http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git" or http.request.uri.path contains "wp-config")

# Custom rule 2: let payment webhooks through (action: Skip, security features)
(http.request.uri.path in {"/webhooks/stripe" "/webhooks/paypal"})

# Rate limiting rule: at most 10 login attempts per minute per IP
(http.request.uri.path eq "/login" and http.request.method eq "POST")  =>  10 requests / 1 minute / IP

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

Крок 6: перевірте налаштування

# is traffic going through Cloudflare?
curl -sI https://example.com | grep -iE "^(server|cf-cache-status|cf-ray)"

# does the origin refuse direct access? (replace with your server IP; expect a timeout or refusal)
curl -sI --max-time 8 https://203.0.113.10 -H "Host: example.com" -k

# are the nameservers and mail records right?
dig NS example.com +short
dig MX example.com +short
dig TXT example.com +short

Запитайте статичний файл двічі: друга відповідь має показати cf-cache-status: HIT. Перевірте вхід, оформлення замовлення та адмінку у справжньому браузері, надішліть та отримайте тестовий лист.

Часті помилки

• Flexible SSL та наступні циклічні редиректи.
• Проксіювання поштового хоста (він має бути «тільки DNS») або втрата поштового запису при переїзді.
• Кешування приватних сторінок, через що один клієнт бачить сторінку облікового запису іншого. Завжди обходьте кеш для авторизованого трафіку.
• Відкритий origin: реальний IP видно у старих DNS-записах, заголовках листів або логах сертифікатів. Обмежте фаєрвол і подумайте про зміну IP, якщо він утік.
• Невідновлений реальний IP, який ламає обмеження частоти, логи та антифрод.
• Перевірки для вебхуків та API, що викликають тихі збої у платежах та інтеграціях.
• Ліміти розміру запиту: у запитів, що проксуються, є максимальний розмір тіла, що залежить від тарифу. Перевірте актуальний ліміт, якщо програма приймає великі завантаження.
• Забутий моніторинг. Додайте алерти на термін дії сертифіката та домену та збережіть перевірки аптайму, як описано в нашому посібнику з бекапів та моніторингу.

Чекліст на одну сторінку

1. Опис DNS вивантажено, обліковий запис реєстратора захищений.
2. Сайт доданий, записи перевірені, проксуються лише веб-хости.
3. Сертифікат на origin встановлено, режим SSL Full (strict), Always Use HTTPS включений.
4. Файєрвол обмежений діапазонами Cloudflare, реальний IP відвідувача відновлено.
5. Правила кешу для статики, обхід для приватних шляхів, скидання кешу у скрипті деплою.
6. Керований WAF увімкнений, ліміти для входу та оплати, вебхуки виключені.
7. Команди перевірки виконані, алерти налаштовані, відкат задокументовано.

Чим ми можемо допомогти

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