Konfiguracja Cloudflare dla witryn biznesowych: szybkość i bezpieczeństwo, krok po kroku

Cloudflare znajduje się pomiędzy odwiedzającymi a serwerem. Odwiedzający łączą się z pobliskim centrum danych Cloudflare, które bezpośrednio obsługuje pliki z pamięci podręcznej, filtruje wrogi ruch i przekazuje resztę na Twój serwer. Dla firmy oznacza to szybsze strony dla klientów oddalonych od lokalizacji hostingu, ochronę przed prostymi atakami typu „odmowa usługi” oraz możliwość egzekwowania zasad bezpieczeństwa bez zmiany kodu aplikacji. Wiele planów zaczyna się bezpłatnie, a plany płatne dodają funkcje, dlatego przed podjęciem decyzji sprawdź porównanie bieżących planów.

Nie zastępuje poprawionego oprogramowania i bezpiecznego kodu. Nasza lista kontrolna bezpieczeństwa PHP nadal obowiązuje. Pomyśl o Cloudflare jak o mocnych drzwiach wejściowych, a nie o zamienniku zamykania pomieszczeń w środku.

Zanim zaczniesz

• Zrób inwentaryzację swojego DNS. Eksportuj lub zrzut ekranu każdego rekordu u obecnego dostawcy DNS, w tym poczty (MX, SPF, DKIM, DMARC) i rekordów weryfikacyjnych. Pominięty rekord to klasyczny sposób na uszkodzenie poczty e-mail podczas migracji.
• Dowiedz się, kto jest właścicielem konta rejestratora domeny i upewnij się, że jest to konto firmowe z uwierzytelnianiem wieloskładnikowym. Tam zmienisz serwery nazw.
• Jeśli możesz, obniż TTL kluczowych rekordów z jednodniowym wyprzedzeniem, aby zmiany rozprzestrzeniały się szybciej.
• Wybierz spokojny moment i powiedz o tym zespołowi. Zaplanuj wycofanie: spisanie starych serwerów nazw.

Krok 1: dodaj witrynę i sprawdź DNS

Dodaj swoją domenę w panelu Cloudflare. Skanuje istniejące rekordy. Porównaj je ze swoim ekwipunkiem i napraw luki. Dla każdego rekordu wybierz jeden z dwóch trybów:

• Serwer proxy (pomarańczowa chmura): ruch przechodzi przez Cloudflare. Użyj dla nazw hostów swojej witryny i aplikacji internetowych.
• Tylko DNS (szara chmura): Cloudflare po prostu odpowiada na zapytanie DNS. Używaj do serwerów pocztowych, nazw hostów SSH lub FTP i wszystkiego, co nie jest ruchem HTTP lub HTTPS.

Następnie zaktualizuj serwery nazw u swojego rejestratora. Gdy witryna zostanie wyświetlona jako aktywna, sprawdź ją i wyślij testową wiadomość e-mail.

Krok 2: poprawnie skonfiguruj szyfrowanie

To ustawienie psuje większość witryn. Cloudflare ma kilka trybów SSL/TLS:

• Elastyczny: szyfruje gościa Cloudflare, ale wysyła ruch do Twojego serwera w formie niezaszyfrowanej. Wygląda na to, że to działa, ale druga część jest otwarta i często powoduje pętle przekierowań. Unikaj tego.
• Pełny: szyfruje obie części, ale nie weryfikuje certyfikatu serwera.
• Pełny (ścisły): szyfruje obie nogi i weryfikuje certyfikat na Twoim serwerze. To jest ten, którego należy używać.

Najpierw zainstaluj ważny certyfikat na swoim serwerze. Zarówno certyfikat Cloudflare Origin CA, jak i darmowy certyfikat Let's Encrypt działają. Następnie przejdź do opcji Pełny (ścisły), włącz Zawsze używaj HTTPS, ustaw minimalną wersję TLS na 1.2 i włącz HSTS dopiero wtedy, gdy wszystko będzie działać przez HTTPS, ponieważ HSTS każe przeglądarkom odrzucać zwykły HTTP przez długi czas.

Krok 3: uniemożliwić Cloudflare

Jeśli napastnicy znają prawdziwy adres IP Twojego serwera, mogą skierować ruch bezpośrednio na niego i pominąć każdą skonfigurowaną ochronę. Napraw to na dwa sposoby:

• Zezwalaj na ruch internetowy do swojego serwera tylko z opublikowanych zakresów adresów IP Cloudflare.
• Przywróć prawdziwy adres IP gościa na swoim serwerze internetowym, ponieważ w przeciwnym razie każde żądanie w Twoich dziennikach, limitach szybkości i analizach będzie wydawało się pochodzić z 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

Jeden ważny szczegół dla użytkowników Docker: porty publikowane przez Docker omijają reguły ufw. Powiąż kontenery z hostem lokalnym za odwrotnym proxy lub ogranicz dostęp w łańcuchu zapory Docker DOCKER-USER Dockera. Aby zapewnić lepszą izolację, Cloudflare Tunnel umożliwia Twojemu serwerowi nawiązywanie tylko połączeń wychodzących, więc nie potrzebuje w ogóle otwartych przychodzących portów internetowych. W przypadku webhooków płatności i innych integracji serwer-serwer upewnij się, że reguły IP nadal przepuszczają te żądania, jeśli nie przechodzą one przez Cloudflare.

Krok 4: reguły buforowania

Domyślnie Cloudflare buforuje pliki statyczne, takie jak obrazy, CSS i JavaScript, ale nie HTML. Rozsądna polityka dla typowej witryny PHP:

• Zasoby statyczne: pamięć podręczna przez długi czas (miesiąc lub dłużej). Użyj wersjonowanych nazw plików lub ciągu zapytania, takiego jak app.css?v=123, aby nowe wdrożenie zostało natychmiast podjęte.
• Publiczne strony HTML (strony marketingowe, blog): mogą być buforowane przez minuty lub godziny za pomocą reguły pamięci podręcznej. Przetestuj dokładnie.
• Nigdy nie buforuj: administratora, konta, koszyka, kasy, punktów końcowych API i dowolnej strony zależnej od pliku cookie logowania. Utwórz regułę obejścia dla tych ścieżek i żądań zawierających plik cookie sesji.

Automatyczne czyszczenie po każdym wdrożeniu, aby klienci nigdy nie widzieli nieaktualnych plików. Utwórz token API tylko z uprawnieniem „Cache Purge” dla tej strefy i wywołaj go ze swojego skryptu wdrażania:

# 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"]}'

Szybsze strony pomagają również w wyszukiwaniu i konwersjach. Zobacz nasz przewodnik Core Web Vitals dla witryn PHP, aby dowiedzieć się, co należy naprawić po stronie serwera po uruchomieniu sieci CDN.

Krok 5: zapora sieciowa, boty i ograniczenie szybkości

• Włącz zarządzane reguły WAF dostępne w Twoim planie. Blokują typowe wzorce ataków, zanim dotrą do Twojego kodu.
• Włącz ochronę przed botami dostosowaną do Twojego planu i obejrzyj analizy, zanim cokolwiek dokręcisz.
• Punkty końcowe wrażliwe na limit szybkości: logowanie, resetowanie hasła, rejestracja i realizacja transakcji. Celem ataków brute-force i testowania kart jest dokładnie to.
• Zwolnij ruch zaufanych maszyn: webhooki dostawców płatności, usługi monitorowania i Twoje własne integracje nie mogą być dotknięte wyzwaniami przeglądarki, ponieważ strona wyzwania zwrócona do webhooka wygląda na awarię.

# 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

Składnia reguły i dostępne pola różnią się w zależności od planu, dlatego traktuj je jako szablony i najpierw przetestuj w trybie „logowania”. Zachowaj także zabezpieczenia na poziomie aplikacji: sprawdzanie podpisów webhooków, jak opisano w naszym przewodniku po webhookach Stripe, nigdy nie zależy wyłącznie od reguł sieciowych.

Krok 6: sprawdź konfigurację

# 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

Sprawdź dwukrotnie plik statyczny: druga odpowiedź powinna pokazać cf-cache-status: HIT. Sprawdź logowanie, realizację transakcji i administrację w prawdziwej przeglądarce oraz wysyłaj i odbieraj testowe wiadomości e-mail.

Typowe błędy

• Elastyczny protokół SSL i następujące po nim pętle przekierowań.
• Serwer proxy dla nazwy hosta poczty (musi to być tylko DNS) lub zapomnienie rekordu poczty podczas przenoszenia.
• Buforowanie stron prywatnych, dzięki czemu jeden klient widzi stronę konta innego. Zawsze omijaj pamięć podręczną dla ruchu zalogowanego.
• Pozostawienie odsłoniętego pochodzenia: prawdziwy adres IP jest widoczny w starych rekordach DNS, nagłówkach wiadomości e-mail lub dziennikach certyfikatów. Ogranicz zaporę sieciową i rozważ zmianę adresu IP, jeśli wyciekł.
• Nie przywracanie prawdziwego adresu IP, co narusza limity szybkości, logi i kontrole oszustw.
• Wymagające webhooki i interfejsy API, co powoduje ciche awarie w płatnościach i integracjach.
• Limity rozmiaru żądań: żądania proxy mają maksymalny rozmiar treści w zależności od planu. Sprawdź aktualny limit, jeśli Twoja aplikacja akceptuje przesyłanie dużych plików.
• Zapominając o monitorowaniu. Dodaj alerty o wygaśnięciu certyfikatu i domeny oraz kontroluj czas działania, zgodnie z opisem w naszym przewodniku dotyczącym tworzenia kopii zapasowych i monitorowania.

Jednostronicowa lista kontrolna

1. Wyeksportowano spis DNS, zabezpieczono konto rejestratora.
2. Witryna dodana, rekordy sprawdzone, proxy tylko dla nazw hostów internetowych.
3. Zainstalowany certyfikat pochodzenia, tryb SSL pełny (ścisły), włączone zawsze używaj protokołu HTTPS.
4. Zapora sieciowa ograniczona do zakresów Cloudflare, przywrócone prawdziwe IP gościa.
5. Reguły pamięci podręcznej dla zasobów statycznych, omijanie ścieżek prywatnych, czyszczenie skryptu wdrażania.
6. Zarządzany WAF włączony, limity stawek za logowanie i realizację transakcji, wyłączone webhooki.
7. Uruchomione polecenia weryfikacyjne, skonfigurowane alerty, udokumentowane wycofanie.

Jak możemy pomóc

Konfigurujemy Cloudflare, hosting i potoki wdrożeniowe dla aplikacji PHP i podłączamy je do systemów płatności, CRM i przesyłania wiadomości. Przeczytaj o naszej usłudze integracji lub zarezerwuj krótką rozmowę, a my sprawdzimy Twoją konfigurację DNS, SSL i buforowania pod kątem tej listy kontrolnej.