Настройка 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 і кэшавання з гэтым чэклістам.