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

Yeni bir WordPress kurulumunda veritabanı bağlantısını hızla doğrulamak için yönetici hesabını kullanmak cazip gelebilir. Bir kurulumda bu geçici tercih kalıcı hale gelmiş, uygulama yapılandırmasında gereğinden geniş yetkili bir hesap bırakılmıştı. Site çalışıyordu; fakat uygulama ele geçirilirse aynı sunucudaki diğer veritabanları ve yönetim işlemleri de gereksiz biçimde risk altındaydı.

21-23 Temmuz 2026 arasında ele alınan çözümde WordPress’e özel veritabanı ve servis kimliği oluşturduk. Buradaki komutlar örnek adlar kullanır; gerçek parola, sunucu adresi veya topoloji içermez. Hedef yalnızca bağlantıyı çalıştırmak değil, hesabın nereden bağlanabileceğini ve hangi nesnede hangi işi yapabileceğini anlaşılır biçimde sınırlandırmaktır.

Sorunun ortaya çıkışı

WordPress kurulum ekranı veritabanına bağlanamıyor ve ekip farklı kullanıcılarla tekrar deniyordu. Root hesabıyla bağlantı sağlanınca sorun çözülmüş sayıldı. Oysa hata uygulama kullanıcısının yanlış host tanımı, eksik grant veya farklı kimlik doğrulama yöntemi olabilirdi. Geniş yetki kullanmak kök nedeni gizledi ve güvenlik borcu yarattı. Önce bağlantı kimliğinin tam olarak nasıl eşleştiğini anlamak gerekiyordu.

MySQL kullanıcıları yalnızca kullanıcı adından değil kullanıcı ve host birleşiminden oluşur. Aynı makinedeki `localhost`, bir konteyner ağı veya uzak uygulama sunucusu farklı hesap eşleşmeleri yaratabilir. Her yerden bağlantıya izin veren geniş host tanımı kolaylık sağlar; fakat ağ ve kimlik kısıtlarını zayıflatır. Uygulamanın gerçek çalışma konumuna uygun en dar kaynak seçilmeliydi.

İlk belirtiler ve yanlış varsayımlar

“Access denied” mesajı çoğu zaman yalnızca yanlış parola olarak yorumlanır. Gerçekte kullanıcı-host eşleşmesi, grant, parola eklentisi veya bağlantı soketi farklı olabilir. Diğer belirti komut satırından bağlantı başarılıyken WordPress’in başarısız olmasıydı. Test farklı işletim sistemi kullanıcısı, farklı host adı veya TCP yerine yerel soket kullanıyorsa uygulamanın yolunu temsil etmeyebilir.

Bir başka yanlış varsayım `GRANT ALL` ifadesinin sunucu genelinde verilmesi gerektiğiydi. WordPress kendi veritabanında kurulum ve güncelleme sırasında tablo yönetimi yapar; bunun için tüm MySQL sunucusunda yönetici olmasına gerek yoktur. Yetki kapsamı `uygulama_veritabani.*` ile sınırlandırılabilir. Üretim politikası daha sıkıysa eklenti ve çekirdek güncelleme yöntemi ayrıca planlanmalıdır.

Teknik analiz

Önce veritabanı adı, karakter seti ve collation seçimi doğrulandı. Ardından uygulamanın MySQL’e hangi host üzerinden bağlandığı belirlendi. Hesap yalnızca bu kaynaktan erişecek biçimde oluşturuldu ve yetkiler ilgili veritabanıyla sınırlandı. `SHOW GRANTS` çıktısı beklenen kapsamı doğrulamak için kullanıldı. Bağlantı testi WordPress servisinin kullandığı ağ yolu ve kimlikle yapıldı.

Hata incelemesinde uygulama logları geçici ve kontrollü biçimde etkinleştirildi; üretimde kullanıcıya ayrıntılı veritabanı hatası gösterilmedi. DNS, TCP bağlantısı, TLS gereksinimi, kullanıcı-host eşleşmesi ve veritabanı seçimi sırayla kontrol edildi. Başarılı testten sonra root kimliği yapılandırmadan çıkarıldı. Kullanılmayan deneme hesapları ve geniş grant’ler envanterden temizlendi.

-- Örnek adları ve güçlü parolayı kurumun secret süreciyle değiştirin.
CREATE DATABASE wp_app
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER 'wp_service'@'localhost'
  IDENTIFIED BY '<secret-manager-tarafindan-uretilen-parola>';

GRANT ALL PRIVILEGES ON wp_app.* TO 'wp_service'@'localhost';
SHOW GRANTS FOR 'wp_service'@'localhost';

-- FLUSH PRIVILEGES, CREATE USER ve GRANT ile yapılan modern değişikliklerde gerekmez.

Uygulanan çözüm veya önerilen mimari

Her WordPress örneği için ayrı veritabanı ve ayrı servis hesabı oluşturuldu. Hesap sunucu yönetimi, başka veritabanlarına erişim veya kullanıcı oluşturma yetkisi almadı. Uygulama ile veritabanı farklı sistemlerdeyse ağ güvenlik duvarı yalnızca gerekli kaynaktan veritabanı hizmetine erişime izin verdi. Veritabanı yönetim hesabı WordPress yapılandırmasında veya otomatik dağıtım çıktısında tutulmadı.

`wp-config.php` değerleri en dar dosya izinleriyle korundu ve dağıtım sürecinde gerçek sırların kaynak kod deposuna girmemesi sağlandı. Parola üretimi, dağıtımı, rotasyonu ve acil iptali için sahip belirlendi. Rotasyon çift hesap veya kontrollü bakım penceresiyle test edildi. Yedeklerin yapılandırma ve veritabanı sırlarını içerebileceği kabul edilerek aynı erişim standardı yedek ortamına uygulandı.

Alternatifler ve karar gerekçesi

Yerel MySQL aynı sunucuda basit işletim ve düşük ağ bağımlılığı sağlar; web sunucusu olayı veritabanı hizmetini de etkileyebilir. Ayrı veya yönetilen veritabanı yedekleme, ölçek ve görev ayrımı sunabilir; ağ, TLS, maliyet ve sağlayıcı işletimi getirir. Seçim site kritikliğine ve ekip kapasitesine bağlıdır. Her iki modelde de uygulamaya özel kimlik değişmeyen ilkedir.

WordPress’in çalışma zamanında daha dar SQL yetkileriyle işletilmesi teorik olarak saldırı yüzeyini azaltabilir. Ancak çekirdek ve eklenti güncellemeleri şema değişikliği gerektirdiğinde operasyon karmaşıklaşır. Kontrollü dağıtım hattı olan kurumlar kurulum ve runtime rollerini ayırabilir; küçük yapılarda ilgili tek veritabanıyla sınırlı yetki, güçlü dosya ve güncelleme kontrolleriyle daha sürdürülebilir olabilir.

Güvenlik ve operasyonel riskler

Parolanın terminal geçmişine, ticket’a, sohbet mesajına veya kaynak depoya yazılması en yaygın risklerdendir. Örnek komut gerçek sırla doğrudan ortak oturumda çalıştırılmamalı; kurumun güvenli secret yöntemi kullanılmalıdır. Hata ayıklama çıktıları bağlantı ayrıntısı gösterebilir ve iş bitince kapatılmalıdır. Veritabanı hizmeti gereksiz yere genel ağa açılmamalıdır.

Aşırı dar yetki güncelleme sırasında kesinti, aşırı geniş yetki ise olay etkisinin büyümesine yol açar. Değişiklikler test ortamında WordPress kurulum, eklenti güncelleme, medya kullanımı ve geri yükleme senaryolarıyla doğrulanmalıdır. Kullanılmayan hesaplar kapatılmalı, başarısız oturumlar izlenmeli ve yedekten dönüş düzenli denenmelidir. Hesap silmeden önce uygulama bağımlılığı envanterden kontrol edilmelidir.

Çıkarılan Dersler

Kontrol Listesi