Cloudflare beállítása üzleti webhelyekhez: sebesség és biztonság lépésről lépésre

Cloudflare a látogatói és a szervere között helyezkedik el. A látogatók csatlakoznak Cloudflare közeli adatközpontjához, amely közvetlenül szolgálja ki a gyorsítótárazott fájlokat, szűri az ellenséges forgalmat, a többit pedig továbbítja a szerverére. Egy vállalkozás számára ez gyorsabb oldalakat jelent a tárhelytől távol eső ügyfelek számára, védelmet az egyszerű szolgáltatásmegtagadási árvizek ellen, valamint egy helyet, ahol az alkalmazáskód megváltoztatása nélkül érvényesíthetik a biztonsági szabályokat. Sok csomag ingyenesen indul, és a fizetős csomagok további funkciókat is tartalmaznak, ezért a döntés előtt ellenőrizze az aktuális csomag-összehasonlítást.

Nem helyettesíti a javított szoftvereket és a biztonságos kódot. PHP biztonsági ellenőrző listánk továbbra is érvényes. Gondoljon Cloudflare re úgy, mint egy erős bejárati ajtóra, nem pedig a szobák belső zárásának helyettesítésére.

Mielőtt elkezdené

• Készítsen leltárt a DNS-ről. Exportáljon vagy készítsen képernyőképet a jelenlegi DNS-szolgáltatójánál minden rekordot, beleértve a leveleket (MX, SPF, DKIM, DMARC) és az ellenőrző rekordokat. Az elmulasztott rekord az e-mailek megszakításának klasszikus módja a migráció során.
• Tudja meg, kinek a tulajdonosa a domain regisztrátor fiókja, és győződjön meg arról, hogy többtényezős hitelesítéssel rendelkező vállalati fiók. Ott megváltoztatod a névszervereket.
• Csökkentse kulcsrekordjainak TTL-jét egy nappal előre, ha teheti, így a változások gyorsabban terjednek.
• Válassz egy csendes időpontot, és mondd el a csapatnak. Tervezze meg a visszaállítást: a régi névszerverek, leírva.

1. lépés: adja hozzá a webhelyet, és ellenőrizze a DNS-t

Adja hozzá domainjét a Cloudflare irányítópultján. Beolvassa a meglévő rekordokat. Hasonlítsa össze őket a készletével, és javítsa ki a hiányosságokat. Minden rekordhoz válasszon két mód közül:

• Meghatalmazott (narancssárga felhő): a forgalom Cloudflare keresztül halad. Használja webhelye és webalkalmazása gazdagépnevéhez.
• Csak DNS (szürke felhő): Cloudflare csak a DNS-lekérdezésre válaszol. Használja levelezőszerverekhez, SSH- vagy FTP-állomásnevekhez, és bármihez, ami nem HTTP- vagy HTTPS-forgalom.

Ezután frissítse a névszervereket a regisztrátornál. Ha a webhely aktívként jelenik meg, ellenőrizze webhelyét, és küldjön teszt e-mailt.

2. lépés: állítsa be megfelelően a titkosítást

Ez az a beállítás, amely a legtöbb webhelyet megszakítja. Cloudflare számos SSL/TLS móddal rendelkezik:

• Rugalmas: titkosítja a látogatót Cloudflare, de titkosítatlanul továbbítja a forgalmat a szerverére. Úgy tűnik, működik, de a második láb nyitva van, és gyakran átirányítási hurkokat okoz. Kerüld el.
• Teljes: mindkét ágat titkosítja, de nem ellenőrzi a szerver tanúsítványát.
• Teljes (szigorú): titkosítja mindkét ágat, és ellenőrzi a tanúsítványt a szerveren. Ezt kell használni.

Először telepítsen egy érvényes tanúsítványt a szerverére. A Cloudflare Origin CA tanúsítvány vagy az ingyenes Let's Encrypt tanúsítvány egyaránt működik. Ezután váltson Full (szigorú) beállításra, kapcsolja be a Mindig használ HTTPS-t, állítsa be a minimális TLS-verziót 1.2-re, és csak akkor engedélyezze a HSTS-t, ha minden HTTPS-en keresztül működik, mert a HSTS arra utasítja a böngészőket, hogy sokáig utasítsák el a sima HTTP-t.

3. lépés: tegye lehetetlenné Cloudflare megkerülését

Ha a támadók ismerik a szerver valódi IP-címét, akkor közvetlenül arra küldhetik a forgalmat, és kihagyhatnak minden konfigurált védelmet. Javítsa meg ezt kétféleképpen:

• Csak Cloudflare közzétett IP-tartományairól engedélyezze a webes forgalmat a szerverére.
• Állítsa vissza a valódi látogatói IP-címet a webszerverén, mert különben úgy tűnik, hogy minden kérés a naplókban, sebességkorlátokban és elemzésekben Cloudflare től érkezik.

#!/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

Egy fontos részlet Docker felhasználók számára: Docker által közzétett portok megkerülik az ufw szabályokat. Kösd össze a tárolókat a localhosttal egy fordított proxy mögött, vagy korlátozd a hozzáférést Docker DOCKER-USER tűzfalláncában. Az erősebb elszigeteltség érdekében Cloudflare Tunnel lehetővé teszi, hogy a szerver csak kimenő kapcsolatot létesítsen, így nincs szüksége nyitott bejövő webportokra. Fizetési webhookok és egyéb szerverek közötti integrációk esetén győződjön meg arról, hogy az IP-szabályok továbbra is átengedik ezeket a kéréseket, ha azok nem Cloudflare keresztül mennek.

4. lépés: gyorsítótárazási szabályok

Alapértelmezés szerint Cloudflare a statikus fájlokat, például a képeket, a CSS-t és a JavaScriptet gyorsítótárazza, a HTML-t azonban nem. Egy ésszerű szabályzat egy tipikus PHP webhelyhez:

• Statikus eszközök: gyorsítótár hosszú ideig (egy hónapig vagy tovább). Használjon verziószámmal ellátott fájlneveket vagy lekérdezési karakterláncot, például app.css?v=123, hogy az új központi telepítést azonnal felvegye.
• Nyilvános HTML oldalak (marketing oldalak, blog): percekig vagy órákig gyorsítótárban tárolhatók egy gyorsítótári szabállyal. Gondosan tesztelje.
• Soha ne tároljon gyorsítótárat: adminisztrátor, fiók, kosár, pénztár, API-végpontok és minden olyan oldal, amely egy bejelentkezési cookie-tól függ. Hozzon létre egy megkerülési szabályt ezekhez az elérési utakhoz és a munkamenet cookie-ját hordozó kérésekhez.

Minden egyes telepítés után automatikusan törlődik, hogy az ügyfelek soha ne lássák az elavult fájlokat. Hozzon létre egy API-jogkivonatot csak a „Gyorsítótár-tisztítás” engedéllyel ehhez a zónához, és hívja meg a telepítési szkriptből:

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

A gyorsabb oldalak a keresést és a konverziót is segítik. Tekintse meg PHP webhelyekre vonatkozó Core Web Vitals útmutatónkban, hogy mit kell javítani a szerver oldalon, ha a CDN a helyére került.

5. lépés: tűzfal, robotok és sebességkorlátozás

• Kapcsolja be a tervben elérhető kezelt WAF-szabályokat. Blokkolja a gyakori támadási mintákat, mielőtt elérnék a kódot.
• Engedélyezze a tervének megfelelő botvédelmet, és nézze meg az elemzést, mielőtt bármit megfeszítene.
• Díjkorlátozásra érzékeny végpontok: bejelentkezés, jelszó-visszaállítás, regisztráció és fizetés. A brute-force és a kártyatesztelő támadások pontosan ezeket célozzák.
• Mentes a megbízható gépforgalom: a fizetési szolgáltató webhookjait, a felügyeleti szolgáltatásokat és a saját integrációkat nem érhetik böngésző kihívások, hiszen a webhookba visszaküldött kihívásoldal kudarcnak tűnik.

# 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

A szabály szintaxisa és a rendelkezésre álló mezők a tervektől függően változnak, ezért kezelje ezeket sablonként, és először "napló" módban tesztelje. Tartsa meg az alkalmazásszintű védelmet is: a webhook-aláírás-ellenőrzések, mint Stripe webhooks-útmutatónkban, soha nem függenek pusztán a hálózati szabályoktól.

6. lépés: ellenőrizze a beállítást

# 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

Ellenőrizze kétszer a statikus fájlt: a második válasznak cf-cache-status: HIT. Ellenőrizze a bejelentkezési, fizetési és adminisztrációs folyamatokat egy valódi böngészővel, és küldjön és fogadjon teszt e-mailt.

Gyakori hibák

• Rugalmas SSL és az azt követő átirányítási hurkok.
• A levelezési gazdagépnév proxyzása (csak DNS-nek kell lennie), vagy egy levélrekord elfelejtése az áthelyezés során.
• Privát oldalak gyorsítótárazása, így az egyik ügyfél egy másik fiókoldalát látja. Mindig kerülje ki a gyorsítótárat a bejelentkezett forgalomhoz.
• Az eredetet szabadon hagyva: a valódi IP látható a régi DNS-rekordokban, e-mailek fejléceiben vagy tanúsítványnaplóiban. Korlátozza a tűzfalat, és fontolja meg az IP-cím megváltoztatását, ha kiszivárgott.
• Nem állítja vissza a valódi IP-t, ami áttöri a sebességkorlátokat, a naplókat és a csalásellenőrzéseket.
• Kihívást jelentő webhookok és API-k, amelyek csendes hibákat okoznak a fizetésekben és az integrációkban.
• Kérelem mérethatárai: a proxy kérések maximális törzsmérettel rendelkeznek a tervtől függően. Ellenőrizze az aktuális korlátot, ha az alkalmazás nagy feltöltéseket fogad el.
• A figyelést elfelejtve. Figyelmeztetések hozzáadása a tanúsítvány és a tartomány lejáratára vonatkozóan, és ellenőrizze az üzemidőt a biztonsági mentési és felügyeleti útmutatóban leírtak szerint.

Egy oldalas ellenőrző lista

1. DNS-készlet exportálva, regisztrátor fiókja biztosított.
2. A webhely hozzáadva, a rekordok felülvizsgálva, csak a webgazdanevekhez proxyzott.
3. Eredeti tanúsítvány telepítve, SSL mód Teljes (szigorú), mindig használja a HTTPS-t.
4. A tűzfal Cloudflare tartományokra korlátozódik, a valódi látogatói IP-cím visszaállítva.
5. A statikus eszközök gyorsítótárának szabályai, a privát útvonalak megkerülése, a telepítési parancsfájl törlése.
6. Felügyelt WAF bekapcsolva, díjkorlátok a bejelentkezésnél és a fizetésnél, a webhookok mentesek.
7. Ellenőrző parancsok futnak, riasztások konfigurálva, visszaállítás dokumentálva.

Hogyan segíthetünk

Konfiguráljuk Cloudflare, a tárhely- és telepítési folyamatokat PHP alkalmazásokhoz, és összekapcsoljuk azokat fizetési, CRM- és üzenetküldő rendszerekkel. Olvasson integrációs szolgáltatásunkról, vagy foglaljon egy rövid hívást, és megvizsgáljuk DNS-, SSL- és gyorsítótárbeállításait ezen ellenőrzőlista alapján.