Cloudflare Güvenliği: Küçük İşletmeler İçin WAF ve Botlar

Küçük İşletmeler İçin Cloudflare Güvenliği Neden Kritik?

Web sitesi güvenliği yalnızca “güçlü şifre ve SSL sertifikası” ile sınırlı değildir. Oysa saldırı trafiği ile gerçek ziyaretçi trafiği artık iç içe geçmiş durumda: form dolduran, giriş yapmaya çalışan, arama yapan ya da ürün görüntüleyen her isteğin yanında; zafiyet tarayan botlar, brute-force saldırılar ve scraping botları da aynı IP havuzlarından gelebiliyor. İşte tam bu noktada Cloudflare gibi bir reverse proxy ve güvenlik katmanı, DCHost üzerindeki sunucunuz ile dış dünya arasında akıllı bir filtre görevi görüyor.

Cloudflare’ın sunduğu WAF (Web Application Firewall), rate limiting (oran sınırlama) ve bot koruması özelliklerinin kapsamı ve kullanılabilir ayarları plana göre değişir; yanlış kurgulanan kurallar gerçek müşterileri de engelleyebilir. Bu rehberde amacımız, DCHost altyapısı üzerinde çalışan sitenizi Cloudflare’ın bu üç ana özelliği ile nasıl dengeli, performanslı ve güvenli bir noktaya taşıyabileceğinizi adım adım göstermektir. Özellikle WordPress, WooCommerce, küçük SaaS panelleri ve kurumsal siteler için sitenizin trafiğine göre sınanması gereken eşik değerleri, kural örnekleri ve ayar önerileri paylaşacağız.

Cloudflare Güvenlik Mimarisi

Önce mimariyi kafada netleştirelim. DCHost’ta barındırılan web siteniz normalde doğrudan ziyaretçiye cevap verir. Web trafiği için Cloudflare proxy’sini etkinleştirdiğinizde ise akış şu şekilde değişir:

• Ziyaretçi DNS üzerinden alan adınızı çözer ve Cloudflare’ın IP’lerine ulaşır.
• Cloudflare; etkin WAF, bot koruması, rate limit ve cache kurallarını uygular.
• İzin verilen istekler, uygun bir yanıt önbellekten sunulamıyorsa DCHost üzerindeki origin sunucunuza iletilir.
• Sunucudan dönen yanıt tekrar Cloudflare üzerinden geçerek son kullanıcıya ulaşır.

Etkin kurallarla tespit edilip engellenen saldırı istekleri DCHost sunucunuza ulaşmadan Cloudflare katmanında durdurulabilir. HTTP güvenlik kurallarının önemli bir kısmı Cloudflare panelinden yönetilebilir; origin tarafındaki güncelleme ve erişim kontrolleri ayrıca sürdürülmelidir.

Cloudflare DNS ve Proxy (Turuncu Bulut) Mantığı

Cloudflare’da proxy desteği olan web DNS kayıtları için iki mod vardır:

• Proxy açık (turuncu bulut): Trafik Cloudflare üzerinden geçer, etkin WAF ve diğer güvenlik kuralları uygulanır.
• Sadece DNS (gri bulut): Cloudflare sadece DNS çözümlemesi yapar, güvenlik katmanı devrede değildir.

Cloudflare’ın HTTP(S) korumasını kullanacağınız web A/AAAA ve CNAME kayıtlarında proxy açık olmalıdır. Nameserver’ı değiştirmek tek başına yeterli değildir; e-posta veya alan adı doğrulaması için kullanılan kayıtları sırf güvenlik amacıyla proxy’ye almayın. Cloudflare DNS ve hosting DNS’i arasındaki nameserver seçimi rehberi bu ayrımı ayrıntılandırır.

Cloudflare + DCHost Altyapısını Birlikte Düşünmek

DCHost tarafında paylaşımlı hosting, VPS veya dedicated sunucu kullanıyor olabilirsiniz; Cloudflare bu katmanın önünde duran esnek bir güvenlik ve performans perdesi gibi davranır. Bizim önerimiz:

• Sunucu tarafında yönetim yetkiniz kapsamındaki güvenlik duvarı, güncelleme, PHP ve web sunucusu sertleştirme işlemlerini uygulamak; yetkiniz dışındaki işlemler için sorumluluk dağılımını belirlemek.
• Cloudflare tarafında ise WAF, bot koruması, rate limit, HTTP/2–HTTP/3 ve cache politikalarını ayarlamak.

Doğru yapılandırıldığında bu katmanlar, origin’e ulaşan saldırı yükünü azaltabilir; uygun içeriklerin önbellekten sunulması da yanıt sürelerini iyileştirebilir. Cloudflare hesabında iki faktörlü kimlik doğrulama kullanın, üyeleri gözden geçirin ve otomasyona yalnız gerekli yetkileri olan API token’ları verin. 2FA’yı etkinleştirmeden önce hesap e-posta adresinizi doğrulayın; aksi halde hesabınıza erişiminizi kaybedebilirsiniz. Google veya Apple gibi bir sosyal giriş sağlayıcısıyla kaydolduysanız önce parola sıfırlama işlemiyle Cloudflare hesabınıza parola belirleyin.

Origin bağlantısı: Full (strict) için sunucu 443 portunda HTTPS bağlantılarını kabul etmeli; süresi dolmamış, istenen veya hedef hostname ile eşleşen ve genel olarak güvenilen bir CA veya Cloudflare Origin CA tarafından verilmiş sertifika sunmalıdır. Modu değiştirmeden önce HTTPS erişimini, yönlendirmeleri ve sertifika yenilemeyi sınayın. Flexible, Cloudflare–origin bağlantısını şifrelemez; Full ise origin sertifikasını Full (strict) gibi doğrulamaz. Full modunda HTTPS ziyaretçi isteğinin origin bağlantısı şifrelenir, ancak HTTP ziyaretçi isteği origin’e açık HTTP ile gidebilir; modu seçmek tek başına HTTPS’ye yönlendirme sağlamaz. Origin erişimini yönetebiliyorsanız web portlarını Cloudflare’ın güncel IPv4/IPv6 ağları ve gerçekten gerekli diğer kaynaklarla sınırlandırın; yönetim, sağlık kontrolü ve sertifika yenileme yollarını önce sınayın. Sadece origin IP’sini gizlemek erişim kontrolü değildir. Authenticated Origin Pulls kullanıldığında origin’in istemci sertifikasını doğrulaması gerekir; ortak Cloudflare sertifikası yalnız Cloudflare ağını doğrular, kendi hesabınızı tek başına ayırt etmez. Paylaşımlı hostingde bu ayarlar için sorumluluk ve destek kapsamını belirleyin.

Cloudflare WAF Ayarları: Küçük İşletmeler İçin Pratik Profil

Cloudflare WAF, web uygulamanıza gelen istekleri analiz ederek SQL injection, XSS, LFI/RFI gibi saldırı girişimlerinin tespitine ve etkin kurallara göre engellenmesine yardımcı olan bir katmandır. WAF konusuna ilk defa giriyorsanız, kavramsal arka plan için web uygulama güvenlik duvarı (WAF) nedir ve Cloudflare WAF ile ModSecurity karşılaştırmasını anlattığımız yazıya da göz atabilirsiniz.

Managed Rulesets ile Hızlı Başlangıç

Güncel panelde Security → Settings altında web uygulaması korumalarını, Security → Security rules altında kural dağıtımlarını inceleyin; eski panelde bunlar WAF başlığı altında bulunabilir. Başlangıçta plan ayrımını netleştirin:

1. Free: Cloudflare Free Managed Ruleset, yüksek etkili ve yaygın sömürülen açıkların seçilmiş bir bölümünü kapsar. Tam Cloudflare Managed Ruleset ile aynı kapsam değildir.
2. Pro ve üstü: Cloudflare Managed Ruleset ve Cloudflare OWASP Core Ruleset kullanılabilir. WordPress gibi uygulamalara ait kurallar çoğunlukla ruleset içindeki etiketlerle seçilir; her uygulama için ayrı bir ürün bulunduğunu varsaymayın.
3. Dağıtım: Varsayılan eylem kurala göre değişir. Her kuralı Block yapmak veya kapalı tüm kuralları topluca açmak yerine ilgili etiketleri, mevcut eylemleri ve meşru giriş, sepet, ödeme ve API akışlarını inceleyin. Desteklenen dar kapsamla ilerleyin.

Bu managed kurallar, kapsamlarına ve seçilen eylemlere bağlı olarak OWASP Top 10 ile ilişkili bazı saldırı girişimlerini engellemeye yardımcı olabilir. WordPress ve WooCommerce sitelerinde bilinen zafiyetlere yönelik imzalar ek koruma sağlayabilir; ancak eski eklentilerin tüm açıklarını kapsamaz ve güncellemenin yerini tutmaz.

WordPress ve WooCommerce İçin Tipik WAF Kuralları

WordPress ve WooCommerce siteleri için değerlendirilebilecek WAF kural yaklaşımları şunlardır:

• Giriş: http.request.uri.path eq "/wp-login.php" gibi açık bir yol eşleşmesi kullanın. Gerekliyse tarayıcı girişine Managed Challenge ekleyin; bu eylem istek akışını keser, sessiz bir kayıt modu değildir.
• Yönetim: /wp-admin/ altındaki her isteği oturumsuz kabul etmeyin. admin-ajax.php ve admin-post.php herkese açık işlevler tarafından kullanılabilir; gerçek uygulama akışına göre ayrı kapsam belirleyin. Bir çerezin bulunması tek başına doğrulanmış oturum değildir.
• XML-RPC, API ve ödeme: /xmlrpc.php, JSON/AJAX, mobil istemci ve webhook yollarını envantere alın. HTML challenge sayfasını bu istemcilere doğrudan uygulamak entegrasyonu bozabilir; uygun kimlik doğrulama ve istemcinin işleyebileceği hız sınırı yanıtı kullanın.
• İstek sinyalleri: User-agent, ülke veya ASN tek başına kötü niyet kanıtı değildir. Başlıklar taklit edilebilir; müşteri, VPN, kurumsal proxy ve entegrasyon trafiğini ayrıca sınayın.

Bu konuyu özellikle WordPress ekseninde ayrıntılı anlattığımız Cloudflare WAF kuralları ve oran sınırlama ile WordPress’i botlardan koruma rehberinde gerçek kural örnekleriyle görebilirsiniz. Aynı mantığı kurumsal panel, SaaS uygulaması veya özel yazılımınızda da login, profil, ödeme gibi kritik uç noktalara uyarlayabilirsiniz.

False Positive’ler: Yanlış Pozitifleri Yönetmek

Her WAF’ta olduğu gibi, Cloudflare WAF’ın da zaman zaman “yanlış pozitif” üretmesi (yani aslında zararlı olmayan bir isteği şüpheli görmesi) mümkündür. Küçük işletme sitelerinde incelenebilecek olası yanlış pozitif senaryoları:

• Yönetim panelinde SQL benzeri sorgu parametreleri kullanan raporlama ekranları.
• URL parametresinde “select, union, insert” gibi kelimeler geçen sağlıklı istekler.
• Geliştirici araçlarıyla test edilen API uçları.

Yanlış pozitif doğrulandıktan sonra ilgili managed kural kimliğini bulun. Örneğin /admin/reports için yalnız yanlış pozitife yol açan kuralı, gerekiyorsa istek yöntemi ve doğrulanmış kaynak koşullarıyla daraltılmış bir istisnaya alın. Managed rules istisnasını atlanacak ruleset dağıtımından önce yerleştirin ve doğru hesap/zone kapsamında çalıştığını kontrol edin. Bu istisna tüm güvenlik katmanlarını atlamaz. Yalnız ofis IP’sine dayanan geniş bir Skip yerine gereken kuralı seçin; uygulama yetkilendirmesi ve diğer korumalar çalışmaya devam etmelidir.

Ülke Bazlı Engelleme ve Jeo-Filtreleme

Ülke veya ASN koşullarını, müşteri ve entegrasyon envanterinizle doğruladığınız dar yönetim yollarında değerlendirin. Yurt dışından gelen isteği kendiliğinden zararlı saymayın; seyahat eden kullanıcılar, VPN’ler, ödeme sağlayıcıları ve arama motorları farklı ağlardan gelebilir. Uygun tarayıcı akışında challenge veya açık erişim politikası için Block seçilebilir.

• Önce yönetim yolunu tam eşleşme veya sınırı belli bir önekle seçin.
• Ülke alanı için güncel ip.src.country alanını kullanın; ülke eşleşmesi kimlik doğrulaması değildir.
• Özel kuralın eylemini ayrıca seçin. Güncel WAF custom rules içinde eski Firewall Rules’taki genel Allow eylemini varsaymayın.

Örneğin yalnız Türkiye’den erişilmesi gereken WordPress yönetim ekranları için aşağıdaki custom rule ifadesi değerlendirilebilir. Eylem Block seçilirse TR dışındaki eşleşen istekler engellenir. İki ortak herkese açık handler bu örnekte ayrı bırakılır; sitenizin başka handler’ları varsa kapsamı uyarlayın:

((http.request.uri.path eq "/wp-admin" or starts_with(http.request.uri.path, "/wp-admin/"))
 and not http.request.uri.path in {"/wp-admin/admin-ajax.php" "/wp-admin/admin-post.php"}
 and ip.src.country ne "TR")

Bu ifade /wp-login.php yolunu kapsamaz ve çıkarılan handler’ları kimlik doğrulamalı hale getirmez. Ülke kodunu kendi erişim politikanıza göre değiştirin; IP/ülke kısıtı yüzünden meşru yönetici erişiminin kesilmediğini test edin.

Rate Limiting: Login, Arama ve API Uçlarını Sakinleştirmek

IP bazlı rate limiting, belirli bir süre aralığında bir IP’den gelen istek sayısına göre sınırlama uygulayarak brute-force, scraping ve bazı yüksek hacimli istek denemelerinin etkisini azaltmaya yardımcı olur. Küçük işletme sitelerinde değerlendirilebilecek üç temel alan şunlardır:

• Giriş (login) sayfaları
• Arama kutuları ve filtreleme sorguları
• API uç noktaları (mobil uygulama, entegrasyonlar vb.)

Hangi Endpoint’lere Rate Limit Koymalı?

Her endpoint için aynı rate limit politikasını uygulamak uygun değildir; sayfa görüntülemeleri ve statik içeriklerde fazla sıkı limitler gerçek kullanıcıları engelleyebilir. Öncelikle değerlendirilebilecek kullanım alanları:

• Login URL’leri: /wp-login.php, /login, /account/login vb.
• Yoğun sorgu üreten arama URL’leri: /search, /?s=, gelişmiş filtreleme sayfaları.
• Kritik API’ler: ödeme, sepet işlemleri, stok/ürün detay sorguları.

Statik dosyalara (CSS, JS, görseller) ya da tüm site geneline çok düşük limitler koymak, özellikle kampanya dönemlerinde ve mobil kullanıcı trafiğinde gereksiz hata sayfalarına yol açabilir.

Rate Limit Eşikleri İçin Örnek Başlangıç Değerleri

Güncel panelde Security → Security rules üzerinden Rate limiting rule oluşturun. Kural türünü custom rule ile karıştırmayın: normal bir WAF ifadesi kendi başına zaman aralığındaki istek sayısını tutmaz.

• Eşleşme: Örneğin http.request.uri.path eq "/wp-login.php". Bu alan sorgu dizgesini içermez; sonuna rastgele * eklemek tam eşleşmeyi önek eşleşmesine dönüştürmez.
• Sayaç: Başlangıçta IP başına sayım kullanın. Aynı NAT/proxy arkasındaki kullanıcılar aynı sayacı paylaşabilir; farklı IPv4/IPv6 adresleri ayrı kaynaklardır.
• Eşik ve ölçüm süresi: İstek sayısı ile bu sayının ölçüldüğü süreyi ayrı girin.
• Eylem ve uygulama süresi: Block veya desteklenen challenge eylemini seçin. Engelleme süresi, ölçüm süresiyle aynı şey değildir.
• Sayım koşulu: Varsayılan olarak eşleşen istekler sayılır. Desteklenen özel sayım ifadesi farklı bir kapsam oluşturabilir; otomatik olarak ana eşleşmeyle birleştiğini varsaymayın.

Aşağıdaki değerler trafik ölçümü sonucu değil, ayrı ayrı uyarlanacak örneklerdir. Free’de bir rate limiting kuralı ve 10 saniyelik ölçüm/engelleme seçenekleri bulunur; Pro’da iki, Business’ta beş kural vardır. Bu nedenle üç örneği Free hesabına birlikte kuramazsınız. Yetki, kural sayısı ve panelin kabul ettiği alanları kurulum sırasında kontrol edin.

Giriş örneği GET ve POST dahil bu yoldaki tüm yöntemleri sayar; başarısız parola denemelerini saydığı iddia edilmez. Rate limiting içinde yöntem alanı Business ve üstünde kullanılabildiğinden Free örneğine POST koşulu eklemeyin. WordPress’in /?s= araması /search yolu değildir: gerçek sorgu parametresini destekleyen bir plan/ifade veya uygulama tarafı sınırlama gerekir.

Pro/Business gibi bir planda giriş kuralını Managed Challenge ile kullanacaksanız sabit “5 dakika challenge” süresi vermeyin. Free/Pro/Business challenge eylemleri isteği kısıtlama davranışı kullanır: ziyaretçi doğrulamayı geçince sayaç sıfırlanır, eşik yeniden aşılırsa tekrar challenge gelir; API’de mitigation_timeout=0 kullanılır. Block örneklerindeki süre bu davranıştan farklıdır. Block’un varsayılan hız sınırı yanıtı 429’dur; özel JSON yanıtı Pro ve üstünde düzenlenebilir. API istemcisi bunu işlemeli ve kontrollü geri çekilme uygulamalıdır.

Önce normal istek dağılımını ölçün; giriş yenilemeleri, paylaşılan IP’ler, mobil bağlantı değişimleri ve kampanya yükünü hesaba katın. WAF custom rules için Log eylemi Enterprise’a aittir; diğer kural türlerinin kayıt seçeneklerini ayrıca doğrulayın. Log olmayan planda staging veya dar test kapsamıyla başlayın. Challenge bir simülasyon değildir. Cloudflare sayaçları tüm ağda tek bir küresel kota oluşturmaz; veri merkezi/ilgili coğrafi grup kapsamında tutulur ve sayaç güncellemesinde gecikme olabilir. Kesin hesap veya ödeme kotasını uygulamada da uygulayın.

Ödeme ve webhook’lar: Sepet/ödeme yolu tek sayfa görüntülemesinde çok sayıda AJAX isteği üretebilir. Başlangıç eşiğini ölçümden çıkarın; kimliği doğrulanmış sağlayıcı webhook’una HTML challenge göndermeyin. Sağlayıcının güncel resmi ağlarını gerekiyorsa yalnız ilgili yol/yöntem için dar istisnaya alın ve uygulamadaki imza doğrulamasını koruyun. Önbellekleme uygun genel verilerde yükü azaltabilir; kişiye özel sepet ve ödeme yanıtlarını ortak cache’e almayın.

Bot Koruması: İyi Botu Öldürmeden Kötü Botu Dışarıda Bırakmak

Cloudflare’ın bot koruma özellikleri, kaba kuvvet brute-force saldırılarından daha ince ayarlı tehditlerle de başa çıkmanızı sağlar: fiyat/ürün scraping’i yapan botlar, spam yorum gönderen script’ler, otomatik hesap açma denemeleri gibi. Burada kritik nokta, arama motoru botları gibi iyi botları rahatsız etmeden kötü botları filtreleyebilmektir.

Bot Fight Mode ve Dikkat Etmeniz Gerekenler

Bot Fight Mode ücretsiz, alan adı genelinde çalışan bir üründür. Bilinen bot örüntülerini belirler ve istemciye hesaplama maliyeti yükleyen challenge’lar uygulayabilir. Hangi tarayıcının ne kadar engelleneceği konusunda sonuç garantisi vermez. Güncel panelde Security → Settings sayfasını açın, Bot traffic filtresini seçin ve Bot fight mode ayarına gidin.

• Giriş ve scraping trafiğinin origin’e ulaşan istek sayısı ve kaynak tüketimi üzerindeki etkisini ölçün.
• API, mobil uygulama, uptime izleme ve ödeme entegrasyonlarını gerçek istemcileriyle test edin; bunlar da challenge’dan etkilenebilir.
• Bot Fight Mode’u yalnız user-agent’a göre seçilen bir JS Challenge kuralı gibi düşünmeyin; ürünün alan adı genelindeki davranışı custom rule ile yeniden ayarlanamaz.

Bot Fight Mode, WAF custom rule veya Page Rule ile Skip/Bypass edilemez. Entegrasyon bozulduğunda yalnız bir cf.client.bot koşulu eklemek bunu çözmez. Nedeni olay kaydında doğrulayın; gerekiyorsa Bot Fight Mode’u kapatıp kapsamı ayarlanabilir bir çözüm değerlendirin. Pro/Business ve Bot Management’sız Enterprise hesaplarında Super Bot Fight Mode, kategorilere göre eylem ve dar kapsamlı custom rule ile kendi aşamasını Skip etme imkânı sunar. Bu Skip diğer korumaları otomatik kaldırmaz. Pro’da Definitely automated ve Verified bots seçenekleri bulunur; Likely automated kategorisinin Pro’da bulunduğunu varsaymayın. Cloudflare Tunnel kullanıyorsanız resmi rehberdeki Definitely Automated=Allow koşulunu ayrıca kontrol edin. Bot Fight Mode’dan Super Bot Fight Mode’a geçerken eski modu kapatın.

Enterprise Bot Management ile Bot Skoru Kuralları

Sayısal cf.bot_management.score alanı Enterprise planı ve Bot Management eklentisi gerektirir; Free/Pro/Business bot ürünleri aynı alanı custom rule içinde kullanma yetkisi vermez. Değerlendirilen isteğin skoru 1–99’dur: 1 otomasyon için yüksek güven, 2–29 muhtemel otomasyon, 30–99 muhtemel insan grubudur. 0, isteğin değerlendirilmediğini gösterir; güvenli, insan veya en kötü bot anlamına gelmez. Bazı istekler Bot Management’tan önce başka bir özellikte sonuçlanabilir.

Gerekli yetkilere sahip bir hesapta yalnız tarayıcı giriş yolundaki değerlendirilmiş düşük skorlu ve doğrulanmış bot olmayan istekleri seçen custom rule örneği:

(http.request.uri.path eq "/wp-login.php"
 and cf.bot_management.score gt 0
 and cf.bot_management.score lt 30
 and not cf.client.bot)

Bu örneğin eylemi Managed Challenge olarak değerlendirilebilir; 30 evrensel bir güvenlik eşiği değil, belgelenen gruplamaya dayanan başlangıç ayrımıdır. API/AJAX yollarına aynı challenge’ı taşımayın. Arama yolunda düşük skor ile yüksek istek sayısını birleştirmek için ayrı bir rate limiting rule ve sayaç gerekir. Bot Management alanlarının bu kuralda kullanılabilmesi Enterprise Bot Management ile uygun rate limiting yetkisine bağlıdır. Gelişmiş sayaç anahtarları veya karmaşıklık sayımı isteniyorsa Advanced Rate Limiting kabiliyetlerini ayrıca doğrulayın; normal custom rule kendi başına yüksek istek sayısını ölçmez.

Bu yaklaşım, IP veya ülke temelli filtreleri tamamlayabilir. Ancak düşük bot skoru tek başına kötü niyet kanıtı değildir; özellikle API veya AJAX trafiğinde kuralların meşru istemcilere etkisini ölçmeden yanlış pozitiflerin azalacağını varsaymayın.

İyi Botları (SEO, Analiz vb.) Korumak

Arama görünürlüğü için izin verdiğiniz Google ve Bing botları ile kullandığınız güvenilir izleme ve uptime botlarının yanlışlıkla engellenmediğini kontrol edin. İstisnaları yalnızca ihtiyaç duyduğunuz botlarla sınırlandırın. Bunun için:

• cf.client.bot, Cloudflare’ın tanıdığı iyi bot/crawler bilgisidir; her gerekli üçüncü parti istemci bu sınıfta bulunmayabilir. User-agent metni tek başına kimlik kanıtı değildir.
• Bir kuralın ifadesine and not cf.client.bot eklemek yalnız o kuralın eşleşmesini daraltır; Bot Fight Mode’u veya tüm WAF katmanlarını atlatmaz.
• Super Bot Fight Mode için kendi aşamasını atlayan dar bir Skip; yanlış pozitif managed kural için yalnız o kuralı kapsayan istisna kullanın. Her istisnanın kapsamını ve gerekçesini kaydedin.

Sunucu tarafındaki tamamlayıcı katmanlar için Cloudflare, ModSecurity ve Fail2ban’ın birlikte kullanımı rehberine bakabilirsiniz. Arama motorunun tarama raporlarını da kontrol edin; bot korumasının SEO sonucunu yalnız güvenlik olayları üzerinden kesinleştirmeyin.

Cloudflare Güvenlik Ayarlarını Test Etme, İzleme ve Loglama

WAF, rate limit ve bot korumasının etkisini değerlendirmek için olay kayıtlarını ve uygulama davranışını izlemek gerekir. Küçük işletme sitelerinde de bu görünürlük, saldırıları ve yanlış pozitifleri fark etmeye yardımcı olur.

Security Events ve Security Analytics’i Birlikte Okumak

Güncel panelde Security → Analytics → Events sekmesi, güvenlik ürünlerinin işlem yaptığı veya işaretlediği olayları gösterir. Security Analytics genel gelen trafiği incelemek için kullanılır; Events bütün isteklerin eksiksiz erişim logu değildir. Free planda görünürlük sampled logs ile sınırlıdır; diğer planlarda da örnekleme görülebilir. Şunları inceleyin:

• Hangi kuralın kaç kez tetiklendiğini,
• Hangi IP, ülke veya user-agent’ların en çok engellendiğini,
• Gerçek kullanıcıların etkilenmiş olabileceğine dair işaretleri

İlk 24–48 saatte ve daha sonra trafik düzeninizin temsil edildiği süre boyunca olayları ve gerçek kullanıcı testlerini karşılaştırın. Bir istek birden fazla güvenlik olayı üretebilir; olay sayısını eşsiz saldırı veya ziyaretçi sayısı saymayın. Örnekleme nedeniyle kayıt bulunmaması, isteğin engellenmediğinin kanıtı değildir.

Sunucu Logları ile Birlikte Yorumlamak

Cloudflare sizin için trafiği filtrelese bile, DCHost üzerindeki sunucunuzun loglarını okumak hâlâ çok değerlidir. Özellikle:

• 4xx/5xx artışında uygulama ve Cloudflare kayıtlarını aynı zaman aralığı, yol, kural kimliği ve varsa Ray ID üzerinden karşılaştırın.
• Edge’de engellenen isteğin origin erişim loguna ulaşmasını beklemeyin. Gerçek ziyaretçi IP başlığını yalnız güvenilen Cloudflare proxy bağlantısından kabul edecek şekilde yapılandırın; aksi halde başlık taklit edilebilir.

Apache veya Nginx loglarını okumaya yeni başlıyorsanız, Apache ve Nginx ile 4xx–5xx hatalarını teşhis etmeyi anlattığımız log okuma rehberimizi özellikle tavsiye ederiz. Cloudflare ile birlikte okunduğunda, hangi hatanın uygulama, hangisinin güvenlik kuralı kaynaklı olduğunu çok daha net ayırt edebilirsiniz.

Test Ortamı, Staging ve Kademeli Yayına Alma

Eğer siteniz kritik işlem yapıyorsa (e-ticaret, B2B panel, SaaS vb.), güvenlik kurallarını tek seferde tüm canlı trafiğe uygulamak yerine kademeli ilerlemeniz daha sağlıklıdır:

• Mevcut kuralı ve geri dönüş adımını kaydedin; desteklenen Log eylemi varsa kullanın, yoksa staging veya dar test kapsamıyla başlayın.
• Giriş, arama, iletişim formu, sepet, ödeme, API, mobil istemci, webhook ve izleme servislerini test edin. Başarılı ve reddedilmesi gereken istekleri birlikte değerlendirin.
• Challenge’ın aktif müdahale olduğunu kabul edin; tarayıcı testinin API uyumluluğunu kanıtladığını varsaymayın.
• Meşru akışlar çalıştığında kapsamı kademeli genişletin. İşlem başarısı, hata oranı ve kullanıcı şikâyetlerini izleyin; sorunlu değişikliği geri alın.

Küçük İşletmeler İçin Önerilen Cloudflare Güvenlik Check-list’i

Küçük işletme siteleri için başlangıç noktası olarak kullanılabilecek kontrol listesini aşağıda özetleyelim:

• Hesap/DNS: 2FA, sınırlı API token’ları ve yalnız uygun web kayıtlarında proxy.
• Origin/TLS: Full (strict), doğru sertifika ve yetkiniz dâhilinde IPv4/IPv6 erişim kısıtları; yönetim ve yenileme akışını koruyun.
• Managed WAF: Free Managed Ruleset ile Pro+ kurallarını ayırın; uygun uygulama etiketlerini test edin.
• Özel kurallar: Yol ve eylemi açık seçin; oturum, ülke ve user-agent sinyallerini kimlik kanıtı saymayın.
• Rate limiting: Planın alan/kural/süre sınırlarına ve normal trafiğe göre eşik seçin; 429 ve challenge davranışını istemciye göre doğrulayın.
• Bot ürünü: Bot Fight Mode’un Skip desteklemediğini, Super Bot Fight Mode istisnasının yalnız seçilen aşamayı atladığını gözetin.
• Bot skoru: Yalnız Enterprise Bot Management yetkisiyle kullanın; 0’ı puanlanmış bot gibi sınıflandırmayın.
• SEO ve entegrasyonlar: Gerekli crawler, webhook ve izleme trafiğini gerçek istemciyle test edin; geniş Allow/Skip kullanmayın.
• Gözlem: Events, Analytics ve origin loglarını birlikte okuyun; örnekleme ve edge’de sonlanan istekleri hesaba katın.
• Bakım: Kural gerekçesini ve geri dönüşü belgeleyin. Büyük uygulama/kampanya değişiminde, olay sonrasında ve düzenli aralıklarla tekrar gözden geçirin.

Güvenlik katmanındaki sonuçları ölçtükten sonra uygulama ve veritabanı darboğazlarını ayrıca ele alın. WordPress veritabanı optimizasyon rehberi bu çalışmanın tamamlayıcısıdır; güvenlik kuralları tek başına performans iyileşmesi garantisi vermez.

Küçük İşletme İçin Sürdürülebilir Güvenlik Profili

Cloudflare’ın WAF, rate limiting ve bot özelliklerini işe yarar bir profile dönüştüren şey, desteklenen ürünü seçmek ve uygulamanın gerçek trafik akışını doğru tanımlamaktır. Bir giriş yolundan başlayın, meşru ve kötüye kullanılan istekleri ayırt eden ölçümleri toplayın ve kuralları kademeli genişletin. Plan yükseltmesi tek başına doğruluk sağlamaz; güncellemeler, güçlü kimlik doğrulama, erişim yetkileri ve sınanmış yedeklerden geri yükleme hâlâ gereklidir.

DCHost üzerindeki paylaşımlı hosting, VPS, dedicated sunucu veya colocation hizmetinizde origin tarafında hangi ayarları sizin, hangilerini hizmet sağlayıcının yönettiğini netleştirin. Destek talebine etkilenen hostname, zaman, kural kimliği ve varsa Ray ID eklemek incelemeyi kolaylaştırır; hassas kimlik bilgilerini paylaşmayın. Cloudflare zone yönetimi veya uygulama optimizasyonu desteğinin paketinize dahil olduğunu varsaymadan hizmet kapsamını doğrulayın.

Birincil Kaynaklar

• Cloudflare Managed Rules ve plan kapsamı
• Rate limiting kullanılabilirliği ve parametre/eylem davranışı
• Bot skorları ve Bot Fight Mode sınırları
• Super Bot Fight Mode istisnaları
• Challenge sayfaları ve istemci uyumluluğu