Настройка 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 режима:

• Гъвкав: криптира посетителя на Cloudflare, но изпраща трафик към вашия сървър некриптиран. Изглежда, че работи, но вторият крак е отворен и често причинява цикли за пренасочване. Избягвайте го.
• Пълно: криптира двата крака, но не проверява сертификата на вашия сървър.
• Пълен (строг): криптира двата крака и проверява сертификата на вашия сървър. Това е този, който трябва да използвате.

Първо инсталирайте валиден сертификат на вашия сървър. Cloudflare Origin CA сертификат или безплатен Let's Encrypt сертификат работят. След това превключете на Пълен (строг), включете Винаги използвайте 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-USER на Docker. За по-силна изолация Cloudflare Tunnel позволява на вашия сървър да осъществява само изходяща връзка, така че изобщо не се нуждае от отворени входящи уеб портове. За уеб кукички за плащания и други интеграции от сървър към сървър, уверете се, че IP правилата все още пропускат тези заявки, ако не преминават през Cloudflare.

Стъпка 4: правила за кеширане

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

• Статични активи: кеш за дълго време (месец или повече). Използвайте имена на файлове с версии или низ за заявка като app.css?v=123, така че ново внедряване да бъде взето незабавно.
• Публични HTML страници (маркетингови страници, блог): могат да бъдат кеширани за минути до часове с правило за кеширане. Тествайте внимателно.
• Никога не кеширайте: администратор, акаунт, количка, плащане, крайни точки на API и всяка страница, която зависи от бисквитка за влизане. Създайте правило за заобикаляне за тези пътища и за заявки, носещи вашата сесийна бисквитка.

Изчиствайте автоматично след всяко внедряване, така че клиентите никога да не виждат остарели файлове. Създайте 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

Синтаксисът на правилата и наличните полета варират в зависимост от плана, така че ги третирайте като шаблони и първо тествайте в режим "дневник". Поддържайте защитата и на ниво приложение: проверките на сигнатурата на webhook, както в нашето ръководство за webhooks 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. Проверете потоците за влизане, плащане и администриране с истински браузър и изпратете и получете тестов имейл.

Често срещани грешки

• Гъвкав SSL и циклите за пренасочване, които следват.
• Проксиране на името на хоста за поща (трябва да е само DNS) или забравяне на пощенски запис по време на преместването.
• Кеширане на частни страници, така че един клиент да вижда страницата на акаунта на друг. Винаги заобикаляйте кеша за влезли в системата трафик.
• Оставяне на източника открит: истинският IP се вижда в стари DNS записи, заглавки на имейли или регистрационни файлове на сертификати. Ограничете защитната стена и помислете за промяна на IP, ако е изтекъл.
• Не се възстановява истинският IP, което нарушава ограниченията на скоростта, регистрационните файлове и проверките за измами.
• Предизвикателни уебкукички и API, което причинява тихи грешки в плащанията и интеграциите.
• Ограничения за размера на заявките: прокси заявките имат максимален размер на тялото в зависимост от плана. Проверете текущото ограничение, ако вашето приложение приема големи качвания.
• Забравяне на мониторинга. Добавете предупреждения за изтичане на сертификата и домейна и поддържайте проверки за непрекъсната работа, както е описано в нашето ръководство за архивиране и наблюдение.

Контролен списък от една страница

1. DNS инвентарът е експортиран, акаунтът на регистратора е защитен.
2. Добавен сайт, прегледани записи, прокси само за имена на уеб хостове.
3. Инсталиран сертификат за произход, SSL режим Пълен (строг), Винаги използвай HTTPS включен.
4. Защитната стена е ограничена до диапазони Cloudflare, IP на реалния посетител е възстановен.
5. Кеш правила за статични активи, заобикаляне за частни пътеки, изчистване в скрипта за внедряване.
6. Управляваният WAF е включен, ограничения на скоростта за влизане и плащане, освободени уеб кукички.
7. Изпълняват се команди за проверка, конфигурират се предупреждения, документира се връщане назад.

Как можем да помогнем

Ние конфигурираме Cloudflare, хостинг и тръбопроводи за внедряване за PHP приложения и ги свързваме към системи за плащане, CRM и съобщения. Прочетете за нашата услуга за интегриране или резервирайте кратко обаждане и ние ще прегледаме вашите настройки за DNS, SSL и кеширане спрямо този контролен списък.