WAF Nedir? Cloudflare ve ModSecurity Rehberi

Web siteniz ister küçük bir kurumsal tanıtım sayfası, ister yoğun trafikli bir e‑ticaret ya da SaaS uygulaması olsun; artık hepsi aynı ortak riskle karşı karşıya: HTTP üzerinden çalışan web uygulamalarına yönelik otomatik ve hedefli saldırılar. Örneğin, sunucu tarafında temel güvenlik duvarı (firewall), güncel bir işletim sistemi ve SSL/TLS bulunmasına rağmen uygulama katmanını filtreleyen bir Web Uygulama Güvenlik Duvarı (WAF) olmayabilir. Bu önlemler tek başına SQL injection, XSS, brute‑force, spam bot ve L7 DDoS gibi uygulama katmanı saldırılarına karşı yeterli koruma sağlamaz.

Bu rehberde WAF nedir, neyi çözer, neyi çözmez sorularını ele alacağız. Cloudflare WAF ile ağın kenarında, ModSecurity ile web sunucusunda uygulanabilecek kontrolleri karşılaştırıp paylaşımlı hosting, VPS ve dedicated sunucu için katmanlı savunma seçeneklerini inceleyeceğiz. DCHost üzerinde uygulanacak kurulumda paket desteği, yönetim yetkileri ve bakım sorumluluğu ayrıca doğrulanmalıdır.

Web Uygulama Güvenlik Duvarı (WAF) Nedir?

Web Uygulama Güvenlik Duvarı, kısaca WAF, HTTP/HTTPS trafiğini inceleyerek zararlı isteklerin uygulamanıza ulaşmasını engellemeye yardımcı olan bir güvenlik katmanıdır. Geleneksel firewall’lar genellikle IP, port ve protokol seviyesinde karar verirken; WAF, URL, parametre, header, cookie, body içeriği gibi uygulama katmanı (Layer 7) detaylarına bakar. Örneğin bir saldırgan /product?id=1;DROP TABLE users gibi bir istek gönderdiğinde, yalnız IP/port denetimi yapan bir güvenlik duvarı içeriği değerlendirmez; uygun WAF kuralı ise SQL injection örüntüsünü yakalayabilir. İnceleme, HTTPS’in çözüldüğü noktaya, etkin kurallara ve gövde boyutu/biçimi sınırlarına bağlıdır.

Geleneksel güvenlik duvarından farkı

• Odak noktası: Ağ güvenlik duvarı servis erişimini; WAF, web uygulamasına gelen HTTP isteklerini denetler. Gelişmiş ürünlerin yetenekleri örtüşebilir.
• Detay seviyesi: Temel ağ kuralları IP, port ve protokole; WAF kuralları yol, parametre, cookie ve gövde gibi uygulama verilerine bakar.
• Kural seti: WAF, saldırı örüntülerini tanıyan kurallar ve beklenen girdiyi sınırlayan politikalar kullanabilir. Davranış analizi ve bot puanlama her üründe veya planda bulunmaz.
• Yerleşim: Ağ güvenlik duvarı ağ kenarında veya sunucuda; WAF ise reverse proxy üzerinde ya da ModSecurity gibi bir motorla web sunucusuna yakın konumlanabilir.

WAF hangi saldırı türlerine karşı koruma sağlayabilir?

Doğru yapılandırılmış bir WAF, aşağıdaki saldırıların bir bölümünü tespit edip engellemeye yardımcı olabilir. Bu, OWASP Top 10 kapsamındaki tüm riskleri gidermez; güvenli kodlama, erişim denetimi ve güncellemelerin yerini tutmaz. Brute‑force, bot istismarı ve L7 DDoS için ayrıca oran sınırlama, bot yönetimi ve DDoS önlemleri gerekebilir:

• SQL Injection: URL parametreleri veya form alanları üzerinden veritabanına zararlı sorgu enjekte edilmesi.
• Cross‑Site Scripting (XSS): Ziyaretçinin tarayıcısında çalışacak zararlı JavaScript kodlarının siteye enjekte edilmesi.
• Remote File Inclusion / Local File Inclusion (RFI/LFI): Uygulamanın harici ya da yerel dosyaları kontrolsüz şekilde include etmesi.
• Komut enjeksiyonu: Uygulamanın çalıştırdığı komutlara saldırgan girdisi eklenmesi; uzaktan kod çalıştırmaya (RCE) yol açabilir.
• Brute‑force ve kimlik bilgisi doldurma (credential stuffing): Giriş formlarında çok sayıda kullanıcı adı/şifre denemesi.
• L7 DDoS: Dağıtık kaynaklardan HTTP istekleri göndererek uygulama kaynaklarını tüketmeye ve hizmeti aksatmaya yönelik saldırılar.
• Spam bot ve form istismarı: İletişim formları, yorum alanları, arama kutuları üzerinden otomatik spam akışları.

WAF Neden Bu Kadar Kritik Hale Geldi?

Bugünün web uygulamaları; WordPress gibi içerik yönetim sistemleri, Laravel gibi framework’ler veya Node.js gibi çalışma ortamları üzerine kurulu, çok sayıda eklenti ve entegrasyon içeren karmaşık sistemler olabilir. Her eklentinin, her API entegrasyonunun kendi zafiyet riski var. Uygulamanızı tamamen hatasız geliştirdiğinizi varsaysak bile, üçüncü parti bileşenlerden gelecek açıkların riskini de yönetmeniz gerekiyor.

KVKK, GDPR ve PCI DSS aynı tür yükümlülükler değildir. KVKK madde 12 uygun teknik ve idari tedbirleri, GDPR madde 32 ise riske uygun güvenlik önlemlerini ister; bunlar her site için belirli bir WAF ürününü zorunlu kılan hükümler değildir. Ödeme kartı sektörünün standardı olan PCI DSS’de kapsam ayrıca belirlenir: 31 Mart 2025’ten beri geçerli 6.4.2, kapsam içindeki halka açık web uygulamalarında web saldırılarını tespit edip önleyen otomatik teknik çözüm ister. WAF seçimi tek başına uyumluluk sağlamaz. PCI SSC’nin güncel gereklilik açıklamasını ve WooCommerce ve e-ticaret hosting için PCI DSS rehberini birlikte değerlendirin.

Cloudflare WAF ile Perimetre Güvenliği

Cloudflare WAF, Cloudflare’ın reverse proxy ağı üzerinden geçen web trafiğini denetler. Cloudflare’da etkin alanın uygun A/AAAA/CNAME web kaydı Proxied olmalıdır; yalnız nameserver değiştirmek yeterli değildir. DNS-only web kaydı normalde origin adresini döndürür ve istek bu WAF yolundan geçmez. Proxied web trafiği desteklenen HTTP(S) bağlantılarında önce Cloudflare edge’ine gelir; burada etkin WAF ve diğer uygun güvenlik/önbellek özellikleri uygulanır, ardından kuralların izin verdiği ve önbellekten karşılanmayan istekler asıl origin sunucunuza (örneğin DCHost üzerindeki VPS veya dedicated sunucunuza) iletilir.

Cloudflare mimarisinde WAF nereye oturur?

Cloudflare kullanırken genellikle domain’inizin nameserver’larını Cloudflare’a yönlendirirsiniz. Bu mimariyi ve hosting tarafındaki DNS seçeneklerini detaylandırdığımız Cloudflare DNS mi, hosting DNS’i mi sorusunu ele aldığımız yazıyı da okumanızı öneririz. Nameserver değişikliğinden sonra proxy durumunu da kontrol edin; posta için kullanılan MX/TXT kayıtları web proxy’si değildir. Cloudflare proxy durumu belgesindeki koşullara uygun web trafiğinde akış şöyledir:

• Proxied web kaydının DNS yanıtı kullanıcıyı Cloudflare IP’lerine yönlendirir.
• HTTP(S) isteği Cloudflare edge’ine gelir; planda bulunan ve etkinleştirilmiş WAF, oran sınırlama, bot ve önbellek kontrolleri kendi kapsamlarında çalışır. Bir isteği sonlandıran kural, sonraki aşamalara geçilmesini durdurabilir.
• Cloudflare, kuralların izin verdiği ve önbellekten karşılanmayan istekleri origin sunucunuza iletir.

Böylece WAF’ın tespit edip engellediği istekler sunucuya gelmeden, ağın kenarında durdurulur. Bu, saldırıların origin üzerindeki kaynak tüketimini azaltabilir.

Managed kurallar ile yaygın saldırılara karşı koruma

Cloudflare WAF, hazır kural setleri (Managed Rules) sağlar. Free Managed Ruleset tüm planlarda bulunur; daha kapsamlı Cloudflare Managed Ruleset ve Cloudflare OWASP Core Ruleset, Pro ve üstü planlarda sunulur. Bunlar aynı kural seti değildir ve OWASP Top 10’un tüm risklerini gidermez. Ürün güncellemeleri ve kullanılabilir ayarlar için resmî Managed Rules belgesini kontrol edin. Kural seçiminin yanı sıra, meşru isteklerin yanlışlıkla engellenip engellenmediğini izlemek ve gerektiğinde dar kapsamlı istisnalar tanımlamak da gerekir.

Örneğin:

• Uygun plandaki OWASP kuralları SQL injection, XSS ve dosya dahil etme gibi saldırı örüntülerini hedefler; Cloudflare’ın skor ve hassasiyet ayarları doğrudan sunucudaki CRS varsayılanlarıyla eşit kabul edilmez.
• Cloudflare Managed Ruleset içindeki WordPress gibi etiketli kural gruplarını ihtiyaca göre inceleyebilirsiniz. Bu, her CMS için ayrı bir ürün veya her açığa karşı koruma bulunduğu anlamına gelmez.
• Bot kontrolleri ayrı yeteneklerdir: Free planda Bot Fight Mode, Pro planda Super Bot Fight Mode bulunur; ayrıntılı bot score alanları için Enterprise Bot Management eklentisi gerekir. User-Agent tek başına bot kimliğini kanıtlamaz.

Özel Cloudflare WAF kuralları oluşturma

Özel WAF kuralları, tek bir isteğin alanlarını koşulla eşleştirip Block veya Managed Challenge gibi bir eylem uygular. İstek sayısını zaman penceresinde takip eden oran sınırlama kuralları ayrı yapılandırılır. Kullanılabilir alan, eylem ve kural sayıları plana bağlıdır; Cloudflare özel kurallarında Log eylemi Enterprise ile sınırlıdır. Özel kural koşullarına örnekler:

• URL yolu: Örneğin /wp-login.php veya /xmlrpc.php için tam yol eşleşmesi.
• HTTP metodu: İlgili uç noktada yalnız POST isteklerine uygulanan özel kural.
• Ülke / ASN: Erişim politikasına uymayan istekleri engellemek veya tarayıcı akışında Managed Challenge kullanmak. Ülke, yetkili kullanıcı kimliği değildir.
• Header / cookie: Beklenen bir alanı denetlemek. Sadece alanın varlığı güvenilir oturum veya yetki doğrulamasının yerini tutmaz.
• IP / IP aralığı: Yönetim erişimini doğrulanmış ofis/VPN IP’lerine sınırlandırmak; dar erişim istisnasının diğer WAF denetimlerini topluca atlamamasını sağlamak.

Örneğin, WordPress giriş sayfanız için aşağıdaki stratejiyi kurabilirsiniz:

• /wp-login.php için önce normal giriş yoğunluğunu ölçün; ardından planın desteklediği zaman penceresi, eşik ve eylemle ayrı bir oran sınırlama kuralı oluşturun. IP başına dakikada 5 istek gibi bir değer hazır güvenli varsayılan değildir; ortak IP kullanan ziyaretçileri engelleyebilir.
• Yönetici erişimini dar yol eşleşmesi ve gerekirse ofis/VPN IP’leriyle sınırlayın. /wp-admin/admin-ajax.php ve /wp-admin/admin-post.php herkese açık ön yüz işlemlerinde kullanılabilir. Gerekli tam yolları yalnız yönetici erişim kısıtından ayırın; kendi WAF, kimlik/yetki ve kötüye kullanım kontrollerini koruyun. Ülke bazlı toplu engel bu akışları ve seyahat eden yöneticileri bozabilir.
• Başarısız girişleri uygulamanın doğrulanmış sonuçlarıyla izleyin; istek sayısı başarısız giriş sayısı değildir. Bu sonuçların oran sayacına alınması plan ve güvenilir sinyal gerektirir. Eski Security Level threat score artık doldurulmaz; giriş başarısız oldukça otomatik düşen bir IP güven skoru varsaymayın. Bu eski skor, OWASP kural setinin işlem puanı veya Bot Management bot score ile aynı değildir.

Bu konuyu özellikle WordPress özelinde daha derin anlattığımız Cloudflare WAF kuralları ve oran sınırlama rehberine mutlaka göz atmanızı öneririz.

Oran sınırlama (Rate Limiting) ve L7 DDoS savunması

Rate Limiting, tanımlanan eşleşmeye göre istekleri sayar; otomatik L7 DDoS koruması ayrı bir katmandır. Sayım süresi, alanlar, anahtar ve engel süresi plana göre değişir. Free planda 60 saniyelik pencere varsaymayın: belgelenen sayım ve azaltım süreleri 10 saniyedir. Güncel oran sınırlama tablosuna göre yapılandırılabilecek örnekler:

• Destekleyen bir planda, belirli uç nokta için aynı IP’den 60 saniyede 60 istek eşiği ve 600 saniyelik Block eylemi seçilebilir. Bu yalnız bir tasarım örneğidir; eşiği normal yük, ortak IP’ler, API istemcileri ve ödeme/webhook akışlarıyla test edin. Sayaç güncellemelerindeki gecikme nedeniyle bu, origin’e ulaşan istek sayısının kesin üst sınırı değildir.
• Tarayıcı akışları için Cloudflare’ın önerdiği Managed Challenge değerlendirilebilir; her ziyaretçiye CAPTCHA gösterilmesi demek değildir. Free/Pro/Business planlarında challenge eylemleri sabit 10 dakikalık süreyle değil, istek kısıtlama davranışıyla çalışır; API’de mitigation_timeout=0 gerekir. İstemci challenge’ı geçince ilgili sayaç sıfırlanır. İstekler kuyrukta bekletilip geciktirilmez; seçilen kurala göre challenge uygulanır veya engellenir. HTML challenge sayfası API/AJAX/webhook yanıtlarını bozabilir.

Böylece brute‑force saldırılarının ve yoğun bot trafiğinin bir bölümünü edge seviyesinde azaltabilirsiniz; bu önlemler uygulamadaki kimlik doğrulama ve kötüye kullanım denetimlerinin yerini tutmaz.

WordPress ve PHP siteler için pratik Cloudflare WAF ayarları

WordPress ve PHP tabanlı siteler için değerlendirilebilecek Cloudflare WAF önlemlerinden bazıları şunlar:

• Giriş koruması: /wp-login.php ve yönetici yollarını ayrı değerlendirin; gerekli public AJAX/form uç noktalarını yönetici kısıtına dahil etmeyin. Giriş, sepet, ödeme, form ve webhook akışlarını test edin.
• XML-RPC: /xmlrpc.php kullanımını ve uzaktan yayın/entegrasyon bağımlılıklarını doğrulayın. Kullanılmıyorsa engelleyin; gerekiyorsa ölçülmüş oran ve erişim kontrolleri uygulayın.
• Yönetim erişimi: Doğrulanmış ofis/VPN IP kısıtını uygulama düzeyinde 2FA ve kurtarma erişimiyle birlikte tasarlayın.
• Bot yönetimi: Arama motorları için sahte bir User-Agent değerini değil doğrulanmış bot kimliğini esas alın; istisnayı gereken kontrolle sınırlayın. Yanlış bot/rate kuralı arama motorlarının taramasını da etkileyebilir.
• Security Level: Eski Low/Medium/High ayarlarıyla reçete oluşturmayın. Eski panelde Always protected değeri değiştirilemez; yeni panel/API’de Security Level, Under Attack Mode’u açıp kapatır. Bu mod ek Managed Challenge uygular. DDoS saldırısı sırasında gerekirse dar kapsamda kullanın ve API etkisini kontrol edin.

Cloudflare WAF, özellikle paylaşımlı hosting veya tek VPS üzerinde birden fazla site barındırdığınız senaryolarda, merkezi kural yönetimi sunar. Uygulamaya özel eşleşmeleri, public uç noktaları ve challenge uyumluluğunu yine test etmek gerekir.

Sunucu Tarafında WAF: ModSecurity

Cloudflare gibi edge tabanlı çözümler, trafiği perimetrede filtrelemek için harika; ancak bazı durumlarda uygulamaya çok yakın, sunucu içinde çalışan bir WAF katmanına da ihtiyaç duyarsınız. İşte burada devreye ModSecurity giriyor.

ModSecurity nedir, nasıl çalışır?

ModSecurity, uygun web sunucusu entegrasyonu/bağlayıcısı ile çalışan açık kaynaklı bir WAF motorudur. Apache veya Nginx kurulumu için motor, bağlayıcı ve kural sürümlerinin uyumluluğu doğrulanmalıdır. İstekler yapılandırılan kapsamda şu veriler üzerinden incelenebilir:

• URL yolu
• Query string
• Header ve cookie’ler
• POST body ve dosya yüklemeleri

Gövde denetimi açık olmalı ve uygun ayrıştırıcıyla boyut sınırları yapılandırılmalıdır; sınırı aşan veya kısmen işlenen içerik bütünüyle incelenmiş sayılmaz. Yanıt gövdesi incelemesi de ayrı etkinleştirme, MIME türü ve boyut koşullarına bağlıdır. Kurallar ve motor modu, isteğin engellenmesini veya yalnız kayda alınmasını belirler. DetectionOnly engelleyici eylemleri uygulamaz; bunu mevcut canlı korumanın yerine topluca açmayın.

OWASP Core Rule Set (CRS) ile standart koruma

OWASP Core Rule Set (CRS), ModSecurity motorundan ayrı kurulan ve güncellenen bir kural kümesidir. SQLi, XSS ve dosya dahil etme gibi saldırı örüntülerini hedefler; uygulamanın yetkilendirme ve iş mantığı kontrollerinin yerine geçmez. Anomali puanlamasında istek puanı engelleme eşiğine eşit olduğunda veya aştığında ilgili engelleme değerlendirmesi devreye girer. CRS ile:

• SQLi, XSS, RFI/LFI, RCE gibi klasik web saldırılarına karşı geniş bir imza tabanı elde edersiniz.
• Bilinen exploit pattern’lerine ve şüpheli istek davranışlarına göre filtreleme yaparsınız.
• Kural güncellemeleri yeni örüntüler için kapsamı geliştirebilir; tüm yeni açıkları yakalama garantisi vermez. Güncellemeyi uygulayıp meşru iş akışlarıyla test etmek gerekir.

ModSecurity ve OWASP CRS’in pratikte nasıl uysallaştırılacağını, yanlış pozitiflerin nasıl azaltılacağını detaylı anlattığımız ModSecurity ve OWASP CRS rehberimize mutlaka göz atın; bu yazıda daha çok genel stratejiye odaklanacağız.

Yanlış pozitiflerle başa çıkma ve tuning süreci

Yanlış pozitif, meşru isteğin saldırı gibi işaretlenmesi ve etkin eyleme göre engellenmesi veya kayda alınmasıdır. Yüksek CRS paranoia seviyesi daha fazla kuralı çalıştırabilir; yönetim paneli, API ve arama girdilerinde ek istisna ihtiyacı doğabilir. Paranoia seviyesi ile engelleme puan eşiği ayrı ayarlardır.

Pratik bir tuning süreci genellikle şöyle işler:

1. Yeni kuralları kontrollü değerlendirin: Önce staging ortamında temsilî trafiği test edin. DetectionOnly gerekiyorsa yalnız değerlendirme kapsamına uygulayın; mevcut çalışan korumaları kaldırmayın.
2. Logları analiz edin: Tetiklenen kuralı, uç noktayı, parametreyi ve gerçek uygulama sonucunu ilişkilendirerek yanlış pozitifi doğrulayın.
3. Dar istisna tanımlayın: Belirli kural ID’sini yalnız gerekli parametre ve yol için hariç tutun. Dağıtılan CRS dosyalarını doğrudan değiştirmeyin; ayrı istisna dosyaları kullanın. Yönetici yolunun tümünü WAF dışına çıkarmayın.
4. Engellemeyi kademeli etkinleştirin: Giriş, form, dosya yükleme, ödeme ve API akışlarını yeniden test edin; hata, gecikme ve yanlış pozitifleri izleyin. Geri dönüş planını hazır tutun.

Bu süreci bir kerelik değil, sürekli bir iyileştirme döngüsü olarak görmek önemli. Uygulamanız geliştikçe, yeni endpoint’ler ve özellikler geldikçe WAF tarafını da güncellemek gerekiyor.

Performans etkisi ve ölçeklendirme

ModSecurity incelemesi CPU, bellek ve gecikme maliyeti oluşturabilir. Etki; istek gövdesine, kurallara, bağlayıcıya ve gerçek yük profiline bağlıdır. Karşılaştırmayı aynı iş yükünde p95/p99 yanıt süresi, hata oranı ve kaynak kullanımıyla yapın:

• Basit sitelerde bile gecikme etkisini ölçün; önbellek kazancını WAF inceleme maliyetinden ayırın.
• Yoğun trafikte pahalı kuralı ve ilgili girdiyi saptayın; önce dar tuning ve kapasite seçeneklerini değerlendirin. Kural kaldırmanın açacağı tespit boşluğunu ölçmeden korumayı azaltmayın.
• Sunucu kaynaklarını sınırlı kullanan paylaşımlı hosting senaryolarında, kaynak sınırlarını ve WAF ayar yetkisini sağlayıcıyla doğrulamak gerekir. Bu ortamlar için paylaşımlı hosting’de WordPress güvenliği rehberimizde pratik öneriler bulabilirsiniz.

Cloudflare WAF ve ModSecurity’yi Birlikte Kullanmak

En sağlıklı yaklaşım, güvenlikte tek bir sihirli mermi aramamak. Cloudflare WAF ve ModSecurity’yi birlikte kullanarak, hem perimetrede hem de sunucu tarafında katmanlı bir savunma kurabilirsiniz.

Katmanlı savunma mimarisi örneği

VPS veya dedicated sunucuda gerekli yönetim yetkisi ve uyumluluk varsa aşağıdaki örnek mimari değerlendirilebilir:

1. DNS ve edge: Web kayıtlarını Proxied yapın, etkin WAF kural setini kontrol edin; oran sınırlama ve bot kontrollerini planınızın desteklediği kapsamda seçin.
2. Origin: Uyumlu web sunucusu, ModSecurity ve CRS kurulumunu test edin. Public web portlarını güncel Cloudflare IPv4/IPv6 ağlarına ve gerekli doğrulanmış entegrasyonlara sınırlayın; SSH ve diğer servisleri ayrı yönetin. Değişiklik öncesi kurtarma erişimini ve sağlık kontrollerini doğrulayın.
3. Origin kimlik doğrulaması: Full (strict), Cloudflare’ın origin sertifikasını doğrular; origin’e gelen istemciyi doğrulayan Authenticated Origin Pulls (AOP) ayrı kontroldür. Paylaşılan Cloudflare AOP sertifikası yalnız Cloudflare ağını kanıtlar; kendi hesaba özgü güven gerekiyorsa uygun özel sertifikayı iki tarafta yapılandırın. Gizli sanılan origin IP’sine tek başına güvenmeyin.
4. Sunucu kontrolleri: nftables/iptables ile gerekli servis erişimini sınırlayın; Fail2ban’ı gerçek log ve servis kuralına göre yapılandırın. Proxy arkasında istemci IP başlıklarına yalnız güvenilir proxy’den gelen bağlantıda güvenin.

Bu yaklaşımda:

• Cloudflare’da gerçekten engellenen web istekleri origin’e ulaşmaz; bot ve DDoS yetenekleri kendi ayar ve plan kapsamlarında çalışır.
• ModSecurity, origin’e ulaşan istekleri yerel kurallarla yeniden değerlendirebilir. Cloudflare yalnız basit, ModSecurity yalnız gelişmiş saldırıları yakalar şeklinde bir görev ayrımı yoktur.
• Sunucu güvenlik duvarı diğer servislerin erişimini sınırlar; Fail2ban, yapılandırılmış log filtrelerinin saptadığı tekrarları hedefler. Her servisi otomatik koruduğu varsayılmaz.

WAF ve bot korumasının birlikte nasıl orkestre edilebileceğini ele aldığımız Cloudflare, ModSecurity ve Fail2ban’ı aynı masada barıştırma yazımıza da mutlaka zaman ayırın.

Loglama ve olay takibi

WAF’ı kurmak işin yarısı, ne yaptığını izlemek ise diğer yarısı. Aksi halde gerçek saldırılarla yanlış pozitifleri ayırt edemez, kural setinizi iyileştiremezsiniz. Önerdiğimiz pratikler:

• Cloudflare güvenlik olaylarında etkin kuralları, eylemleri ve meşru istek etkisini inceleyin; olay görünürlüğü ve saklama kapsamını planınızla doğrulayın.
• ModSecurity olaylarını Loki veya ELK gibi merkezi sisteme aktaracaksanız önce gerekli alanları seçin. Gövde ve sorgular parola, token, kart verisi veya kişisel veri içerebilir; gereksiz hassas alanları kaydetmeyin, erişimi ve saklama süresini sınırlayın.
• Sık tetiklenen kural ID’sini yol, parametre ve uygulama sonucu ile ilişkilendirin. Yüksek sayaç tek başına saldırı veya başarılı savunma kanıtı değildir.
• Olağan dışı artış, hata oranı ve kritik işlem başarısızlığı için anlamlı alarmlar kurun; bildirimlerin doğru kişiye ulaştığını test edin.

Birden fazla sunucuda log yönetimini nasıl merkezi hale getirebileceğinizi merak ediyorsanız, ELK ve Loki stack ile merkezi loglama rehberimize mutlaka göz atın.

DCHost Üzerinde WAF Stratejisi Nasıl Kurulur?

Hosting seçimi kadar ayar yetkisi ve bakım sorumluluğu da önemlidir. Seçtiğiniz DCHost paketinde WAF motoru/kural seti, istisna yönetimi, log erişimi ve destek kapsamını doğrulayarak şu yol haritasını uyarlayın.

Paylaşımlı hosting kullananlar için

• Cloudflare Free Managed Ruleset ve uygun temel edge kontrolleri başlangıç olabilir; Proxied web kaydını ve gerçek ihtiyacınızı doğrulayın. Free planı tam Managed/OWASP seti veya Enterprise bot puanlama ile eşitlemeyin.
• Hosting panelinde ModSecurity sunuluyorsa mevcut korumayı koruyun; log ve dar istisna yetkisi yoksa sağlayıcıdan ilgili kural/yol için destek isteyin. Paylaşımlı hosting kullanıcısının motor kurma yetkisi olduğu varsayılmaz.
• CMS ve eklentileri güncel tutun; güvenlik eklentisinin oturum, 2FA veya kötüye kullanım kontrollerini WAF ile birlikte test edin.

VPS ve dedicated sunucu kullananlar için

Daha yüksek trafik alan, kritik veriler işleyen veya özel geliştirilmiş uygulamalar barındıran yapılar için önerimiz:

• Public web uygulamasını Cloudflare arkasına alacaksanız proxy ve origin erişim kısıtlarını birlikte doğrulayın.
• Uyumlu ModSecurity + OWASP CRS kurulumunda yeni kuralları staging veya dar değerlendirme kapsamında test edin; mevcut engellemeyi topluca kapatmayın.
• SSH, panel ve diğer yönetim arayüzleri için uygun IP/VPN kısıtı, desteklenen 2FA ve acil erişim planı uygulayın.
• nftables/iptables ve Fail2ban’ı gerekli servis/log akışlarına göre yapılandırın; yanlış IP yorumunun Cloudflare ağlarını veya meşru kullanıcıları engellemediğini test edin.

VPS güvenliğini bütüncül olarak ele almak isterseniz, VPS sunucu güvenliği rehberimizde kapıyı açık bırakmadan yaşamanın pratik yollarını detaylı anlattık.

WAF, SSL/TLS ve HTTP güvenlik başlıkları birlikte düşünülmeli

WAF tek başına yeterli değildir; mutlaka güçlü bir SSL/TLS yapılandırması ve doğru HTTP güvenlik başlıkları ile desteklenmelidir. Güvenli kodlama, parametreli veritabanı sorguları, çıktı kodlama, yetkilendirme, güncellemeler ve geri yüklemesi sınanmış yedekler de gereklidir:

• SSL/TLS: Modern protokoller (TLS 1.2/1.3), güçlü şifre kümeleri, doğru sertifika yönetimi. Bu konuda modern HTTPS için net yol haritası yazımız size iyi bir çerçeve sunar.
• HTTP Security Headers: HSTS, CSP, X‑Frame‑Options, Referrer‑Policy gibi başlıklarla tarayıcı tarafında ek koruma katmanları oluşturmak. Bunun için de HTTP güvenlik başlıkları rehberimizi inceleyebilirsiniz.

WAF Stratejisini İşletmek

Küçük bir blog da otomatik web saldırılarının hedefi olabilir. WAF ihtiyacını uygulamanın veri ve erişim riskine, mevcut korumalara ve ekibin sürdürebileceği işletim yüküne göre değerlendirin. Kurulumun başarılı olması, giriş, form, ödeme ve API akışlarının doğru çalışmasıyla birlikte ölçülmelidir.

Cloudflare WAF, ModSecurity veya ikisini birlikte kullanmak ek savunma sağlayabilir; iki katman daha fazla kural, log ve tuning sorumluluğu da getirir. Riskin ne kadar azaldığını varsaymak yerine engellenen istekleri, yanlış pozitifleri, gecikmeyi ve kritik işlemleri izleyin. Güncellemeler, güçlü kimlik/yetki kontrolleri, TLS, güvenlik başlıkları ve yedekleme bu düzenin diğer parçalarıdır.

DCHost ile mimariyi değerlendirirken mevcut sunucu/paneli, trafik profilini, korunacak yolları ve gerekli yönetim yetkilerini paylaşın. WAF kurulumu, istisna yönetimi, izleme ve olay müdahalesinin kimde olacağını ve hizmet kapsamını netleştirin; uygulanacak planı bu bilgilerle oluşturun.