Cloudflare'de CDN ve WAF'ı Birlikte Kurmak
Cloudflare'in temel çalışma modeli şudur: alan adınızın trafiği Cloudflare'in ters proxy (reverse proxy) katmanından geçer. Bu katman hem statik içeriği önbelleğe alıp CDN gibi davranır hem de istekleri WAF kurallarından geçirir. Yani CDN ve WAF ayrı ürünler değil, aynı proxy hattının iki işlevidir. Bu rehberde ikisini birlikte, çakışmadan nasıl yapılandıracağına odaklanıyoruz.
Hedef kitle orta seviye geliştiriciler. Önkoşul olarak alan adının Cloudflare'e eklenmiş (nameserver devri tamamlanmış) ve DNS kayıtlarının Cloudflare üzerinden yönetiliyor olması gerekir. Proxy durumu (turuncu bulut) CDN ve WAF'ın çalışması için şarttır; gri bulutlu kayıtlar bu katmandan geçmez.
Önbellekleme Davranışını Anlamak
Cloudflare'in önbelleği varsayılan olarak belirli dosya uzantılarına (.css, .js, .jpg, .png, .woff gibi) uygulanır. HTML yanıtları varsayılan olarak önbelleğe alınmaz. Bu, çoğu dinamik uygulama için doğru davranıştır; çünkü kullanıcıya özel HTML'i önbelleğe almak ciddi veri sızıntısına yol açar.
Önbellek davranışını iki yerden yönetirsin:
- Cache Rules (modern arayüz): URL, host, başlık gibi koşullara göre önbellek politikası tanımlar.
- Origin yanıt başlıkları:
Cache-Control,CDN-Cache-Control,Cloudflare-CDN-Cache-Control.
Origin tarafında doğru başlıkları göndermek en taşınabilir yaklaşımdır. Örneğin Express.js ile statik varlıklara uzun ömür, HTML'e ise no-store verilebilir:
// Express.js: statik varlıklar uzun süre önbelleklenir, HTML önbelleklenmez
app.use(
'/assets',
express.static('public/assets', {
maxAge: '1y',
immutable: true,
})
);
app.get('/', (req, res) => {
res.set('Cache-Control', 'no-store');
res.render('index');
});
immutable bayrağı, tarayıcıya "bu dosya içeriği değişmeyecek" der. Bu yüzden dosya adlarına içerik hash'i eklemek (örneğin app.a1b2c3.js) gerekir. Aksi halde kullanıcılar eski sürümü görmeye devam eder.
CDN-Cache-Control başlığı yalnızca CDN katmanını, Cache-Control ise hem tarayıcıyı hem CDN'i etkiler. İkisini ayırmak istediğinde bu ayrım işe yarar.
Önbelleği Temizleme (Purge)
Yanlış içerik önbelleğe alındığında üç seçeneğin var:
- Tek URL purge: yalnızca belirli bir kaynağı temizler.
- Tag purge (Enterprise):
Cache-Tagbaşlığıyla etiketlenmiş grupları temizler. - Full purge: tüm önbelleği boşaltır; ani yük artışına yol açabilir.
API üzerinden purge örneği:
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"files":["https://example.com/assets/app.a1b2c3.js"]}'
$CF_API_TOKEN yalnızca Zone.Cache Purge yetkisine sahip olmalı. Global API Key kullanmaktan kaçın; sızması durumunda tüm hesabı riske atar.
WAF'ı Katmanlı Kurmak
Cloudflare WAF üç katmandan oluşur:
- Managed Rulesets: Cloudflare'in sürekli güncellediği imza tabanlı kural setleri (OWASP Core Ruleset dahil). Kural setini "Log" modunda başlatıp yanlış pozitifleri gözlemlemek, doğrudan "Block" moduna almaktan çok daha güvenlidir.
- Custom Rules: Kendi ifadelerinizi yazdığınız kurallar.
- Rate Limiting: İstek hızı sınırlaması.
Custom Rule ifadeleri Cloudflare'in kendi ifade dilini kullanır:
# Yönetim paneline yalnızca belirli ülke ve IP aralığından erişim
(http.host eq "example.com" and starts_with(http.request.uri.path, "/admin"))
and not (ip.src in {203.0.113.0/24} and ip.geoip.country eq "TR")
Bu kural, koşula uyan istekleri bloklar. Yönetim yollarını IP kısıtıyla korumak, kimlik doğrulamayı tamamen ikame etmez; sadece saldırı yüzeyini daraltır. Uygulama tarafında oturum doğrulaması yine zorunludur.
Rate limiting için eşik seçerken gerçek trafiği referans al. Login ve şifre sıfırlama uçları için sıkı, genel API için gevşek limitler mantıklıdır.
Yaygın Hatalar
- Kullanıcıya özel HTML'i önbelleğe almak.
Cache-Control: privategöndermeyen origin, bir kullanıcının sayfasını diğerine servis edebilir. Oturum çerezine bağlı yanıtlardaVary: Cookieveyaprivatekullan. - WAF'ı doğrudan Block moduna almak. Managed Ruleset'ler meşru istekleri (özellikle form POST'larını ve API JSON gövdelerini) yanlış işaretleyebilir. Önce Log modunda çalıştır.
- Origin IP'sini gizlememek. Cloudflare arkasındayken origin sunucunun gerçek IP'si doğrudan erişilebilir olursa, saldırgan proxy'yi atlar. Origin güvenlik duvarını yalnızca Cloudflare IP aralıklarına aç ve doğrulama başlığını kontrol et.
- API token'ı geniş yetkiyle oluşturmak. Her otomasyon için yalnızca gereken izne sahip ayrı token üret.
immutableverip dosya adını değiştirmemek. Bu kombinasyon, kullanıcıları kalıcı olarak eski varlığa kilitler.
Origin Doğrulaması
İsteklerin gerçekten Cloudflare üzerinden geldiğini doğrulamak için origin'de CF-Connecting-IP başlığını ve Cloudflare'in yayınladığı IP aralıklarını kontrol edebilirsin. Nginx örneği:
# Cloudflare IP aralıkları dışından gelen istekleri reddet (örnek aralık)
set_real_ip_from 203.0.113.0/24;
real_ip_header CF-Connecting-IP;
# Uygulama tarafında gerçek istemci IP'si artık $remote_addr içinde
set_real_ip_from satırlarına Cloudflare'in güncel IP listesini yazmalısın; liste zaman zaman güncellenir, bu yüzden periyodik olarak kontrol et. Bu yapılandırma, uygulamanın log ve rate limit mantığının doğru istemci IP'sini görmesini sağlar.
Güvenlik Etkileri
CDN ve WAF birlikte kullanıldığında dikkat edilecek iki nokta var:
- Önbellek, güvenlik kuralını atlatabilir. Bir istek WAF'tan geçip önbelleğe alınırsa, sonraki aynı istekler origin'e hiç ulaşmadan önbellekten döner. Bu beklenen davranıştır; ancak önbelleğe alınan yanıtın kullanıcıya özel veri içermediğinden emin ol.
- WAF, uygulama düzeyi doğrulamanın yerini almaz. Yetkilendirme, oturum yönetimi ve girdi doğrulama uygulamada kalır. WAF bunları destekler, ikame etmez.
Sonuç
Cloudflare'de sağlam bir kurulum üç prensibe dayanır: origin'de doğru Cache-Control başlıkları, WAF kural setlerini önce log modunda gözlemleyip sonra sıkılaştırmak, ve origin IP'sini gizleyip yalnızca Cloudflare'den erişilebilir kılmak. Önbellek ve güvenlik kuralları aynı proxy hattında çalıştığı için ikisini birlikte test etmek, tek tek doğrulamaktan daha güvenilir sonuç verir.
