TR / EN

Cloudflare WAF Kullanırken Origin Sunucuyu Nasıl Korursunuz?

Bir web sitesinin DNS kaydı proxy arkasına alındığında trafik WAF üzerinden geçiyor ve ilk bakışta origin sunucu görünmez hale geliyor. Ancak daha önceki DNS kayıtları, e-posta başlıkları, sertifika geçmişi veya başka bir servis aynı adresi işaret ediyorsa origin bulunabilir. Güvenlik duvarı herkesten web trafiği kabul ediyorsa saldırgan WAF denetimlerini atlayarak doğrudan uygulamaya ulaşabilir.

Temmuz 2026 tarihli değerlendirmede WordPress benzeri bir kurumsal siteyi yalnızca ön katmanda değil, origin sınırında da koruyacak yaklaşımı ele aldık. Gerçek alan adı, ağ adresi ve kural ayrıntıları bu anlatımda yoktur. Amaç belirli bir üreticiyi koşulsuz önermek değil; CDN/WAF ile sunucu güvenliği arasındaki paylaşılan sorumluluğu doğru kurmaktır.

Sorunun ortaya çıkışı

Site Cloudflare proxy arkasında ve WAF kuralları aktifti. Buna rağmen origin erişim kayıtlarında beklenmeyen doğrudan istekler görülüyordu. İnceleme, web sunucusunun genel internetten bağlantı kabul ettiğini gösterdi. WAF yalnızca kendi üzerinden geçen trafiği değerlendirebildiği için doğrudan bağlantıların hız sınırlama, bot yönetimi ve uygulama kurallarından geçmediği anlaşıldı.

Yönetim erişimi ile yayın trafiği de aynı ağ yolunu kullanıyordu. Sunucuya bakım yapmak için geniş izin bırakılmış, bu izin zaman içinde kalıcı hale gelmişti. Ayrıca TLS ayarı ziyaretçi ile edge arasını koruyor, edge ile origin arasındaki doğrulama yeterince güçlü değildi. Sorunu tek bir firewall kuralıyla değil, trafik türlerini ve güven sınırlarını yeniden tanımlayarak çözmek gerekiyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım turuncu proxy simgesinin origin adresini kalıcı olarak gizlediğiydi. DNS değişikliği gelecekteki sorguları etkiler; geçmiş kayıtları veya aynı altyapıdaki başka servisleri silemez. İkinci varsayım yalnızca Host başlığını kontrol etmenin yeterli olduğuydu. Bu başlık istemci tarafından üretilebilir ve tek başına isteğin güvenilir proxy katmanından geldiğini kanıtlamaz.

Doğrudan origin denemesinde sitenin açılması önemli belirtiydi, fakat test kontrollü ve yetkili biçimde yapılmalıdır. Yanlış teşhislerden biri bütün bilinmeyen trafiği uygulama katmanında engellemenin yeterli sayılmasıdır. Ağ sınırında kısıtlama yoksa sunucu yine bağlantı yükünü taşır. Diğeri ise yönetim panelini WAF arkasına koymanın güçlü kimlik ve ayrı yönetim politikası ihtiyacını kaldırdığı düşüncesidir.

Teknik analiz

Trafiği ziyaretçi-edge, edge-origin ve yönetici-origin olarak üç akışa ayırdık. Yayın portlarında origin güvenlik duvarının yalnızca hizmet sağlayıcının yayımladığı ve otomatik güncellenen ağ aralıklarını kabul etmesi hedeflendi. Bu liste sabit bir blog yazısından kopyalanmadı; resmi kaynaktan doğrulanan değişiklik süreciyle yönetildi. IPv4 ve IPv6, yük dengeleyici ve sağlık kontrolü ihtiyaçları birlikte ele alındı.

TLS modu edge ile origin arasında şifreleme ve sertifika doğrulaması sağlayacak şekilde seçildi. Buna ek olarak authenticated origin pull veya eşdeğer karşılıklı doğrulama seçeneği değerlendirildi. Uygulamanın gerçek istemci adresini yalnızca güvenilir proxy başlığından alması, diğer kaynakların gönderdiği benzer başlıkları kabul etmemesi sağlandı. Erişim kayıtlarında edge kimliği ile origin isteği ilişkilendirildi.

# Dağıtıma özel adres veya kural vermeyen örnek politika mantığı:
# 1. Resmi sağlayıcı ağ listesini doğrulanmış kaynaktan alın.
# 2. Geçici bir yönetim oturumuyla erişimi kaybetmeye karşı geri dönüş hazırlayın.
# 3. Yayın portlarında yalnızca proxy ve gerekli sağlık kontrolü kaynaklarını kabul edin.
# 4. Yönetim erişimini ayrı VPN/zero-trust yoluna taşıyın.
# 5. Yetkili dış noktadan doğrudan origin erişiminin reddedildiğini doğrulayın.

Uygulanan çözüm veya önerilen mimari

Yayın trafiği Cloudflare edge üzerinden origin’e ulaştı; origin güvenlik duvarı web bağlantılarını doğrulanmış proxy kaynaklarıyla sınırladı. Uçtan uca doğrulanan TLS kullanıldı ve mümkün olan ortamda origin bağlantısı ek sertifika doğrulamasıyla güçlendirildi. Sunucunun varsayılan sanal host’u bilinmeyen alan adlarına içerik sunmadı. DNS kayıtları aynı origin’i gösteren gereksiz servisler açısından temizlendi.

Yönetim paneli ve sunucu bakımı yayın yolundan ayrıldı. Yönetici erişimi kimlik tabanlı özel erişim, MFA ve sınırlı yetkiyle sağlandı; genel internete yönetim servisi açılmadı. WAF kuralı, WordPress güvenliği, eklenti güncellemeleri ve yedekleme devam etti. Origin kısıtlamasının uygulama yamalarının veya güçlü kimlik doğrulamanın yerine geçmediği özellikle dokümante edildi.

Alternatifler ve karar gerekçesi

Yalnızca sağlayıcı IP aralıklarına izin vermek basit ve güçlü bir ağ kontrolüdür; ancak liste değişiklikleri, sağlık kontrolleri ve çoklu sağlayıcı kullanımı operasyon gerektirir. Tünel tabanlı bağlantı origin’de genel giriş ihtiyacını azaltabilir ve adres gizliliğini güçlendirebilir, buna karşılık ek agent, bağımlılık ve kapasite planı getirir. Mevcut işletim yetkinliğine göre iki yaklaşım da geçerli olabilir.

mTLS veya authenticated origin pull, kaynak doğrulamasını IP listesinin ötesine taşır; sertifika yaşam döngüsü dikkatli yönetilmezse kesinti yaratabilir. Uygulama başlığına dayalı gizli değer kolay uygulanır fakat sızma ve yanlış yapılandırma riski nedeniyle tek kontrol olmamalıdır. Katmanlı modelde ağ kısıtı, TLS doğrulama ve uygulama sertleştirme birbirini tamamladığı için tercih edildi.

Güvenlik ve operasyonel riskler

Yanlış firewall değişikliği gerçek kullanıcı trafiğini veya yönetim erişimini kesebilir. Kurallar aşamalı uygulanmalı, resmi kaynak listeleri doğrulanmalı, IPv6 unutulmamalı ve geri dönüş yöntemi değişiklikten önce test edilmelidir. Sağlayıcı durumunda sorun olduğunda origin’i geçici olarak herkese açmak hızlı görünse de WAF bypass riskini büyütür; önceden tanımlı süreli acil durum prosedürü kullanılmalıdır.

Origin adresinin geçmişte açığa çıkmış olabileceği kabul edilmelidir. Adres değişikliği yardımcı olabilir fakat kalıcı kontrol değildir. Loglar gerçek istemci verisi içerebileceği için erişim ve saklama sınırlandırılmalıdır. WAF olayları ile origin günlükleri birlikte izlenmeli; proxy dışı reddedilen isteklerdeki artış araştırılmalıdır. Yedek origin veya felaket kurtarma uç noktası da aynı koruma standardına dahil edilmelidir.

Çıkarılan Dersler

Kontrol Listesi