E-ticaret siteleri için Cloudflare kurulum ve güvenlik rehberi

İlk uygulamayı tek mağazada ve düşük trafik saatinde yapın. Aynı anda DNS, SSL, önbellek ve bütün güvenlik seçeneklerini değiştirmeyin. Her adımın önceki değerini not edin; değişikliğin etkisini ayırt edebilmek için bir sonraki adıma ancak kontrol sonrası geçin.

• Alan adı kayıt kuruluşu, Cloudflare ve hosting erişimleri; hesaplarda iki aşamalı doğrulama.
• Mevcut DNS bölgesinin dışa aktarımı veya bütün kayıtları içeren yedek. Web sitesi dosya ve veritabanı yedeği.
• Hostingden doğrulanmış web sunucusu IP’si; e-posta sağlayıcısından doğrulanmış MX hedefi, mail sunucusu ve SPF/DKIM/DMARC kayıtları.
• Mağazanın gerçek sepet, ödeme, hesabım ve giriş adresleri; ödeme eklentisinin adı ve sürümü.
• Ödeme sağlayıcısının bildirim/dönüş adresleri; pazaryeri, ERP, mobil uygulama, kargo ve stok entegrasyonlarının kullandığı uç noktalar.
• Test hesabı ve kullanılacak ödeme test yöntemi. API parolalarını, kart bilgilerini veya şifre sıfırlama anahtarlarını ekran görüntülerinde paylaşmayın.

Menü: Cloudflare → alan adı → DNS → Records. Cloudflare’ın otomatik bulduğu kayıtları hosting ve e-posta sağlayıcısındaki listeyle karşılaştırın; otomatik taramanın eksiksiz olduğunu varsaymayın.

• Ana alan adı ve www: Standart web sitesi kurulumunda, sağlayıcının desteklediği A/AAAA/CNAME kayıtlarını Proxied (turuncu bulut) yapın. Kullanılmayan veya eski sunucuya giden AAAA kaydı bırakmayın.
• mail, smtp, imap, pop ve ftp: Kullanılıyorsa DNS only (gri bulut) tutun. Standart Cloudflare web proxy’si e-posta protokolleri için kullanılmaz.
• cpanel, whm, webmail, webdisk, autoconfig, autodiscover ve takvim/rehber servisleri: İlk geçişte mevcut sağlayıcı yapılandırmasını koruyun; genellikle DNS only ile başlayın. Bazı web yönetim portları proxy desteklese de bütün bu servisleri topluca turuncuya çevirmeyin.
• MX, TXT ve SRV: Kayıtların değerlerini koruyun. Bu kayıt türlerinde web proxy’si uygulanmaz. MX ve SRV kayıtlarının işaret ettiği hedef adları da inceleyin.

Yerel posta sunucusu örneği: Sağlayıcı e-postanın aynı hostingde olduğunu doğruladıysa mail için gerçek posta IP’sine giden DNS-only A kaydı oluşturun; MX hedefini bu posta adına ayarlayın. MX hedefi IP adresi değil, alan adıdır. CNAME alanına IP yazılmaz. Aşağıdaki belge IP’sini gerçek kurulumda kullanmayın.

A      mail    192.0.2.10           DNS only   (örnek IP; değiştirin)
MX     @       mail.example.com    Sağlayıcının önceliği
A      @       WEB_SUNUCUSU_IP      Proxied
CNAME  www     example.com         Proxied

Google Workspace, Microsoft 365 veya başka bir harici posta hizmeti kullanıyorsanız MX’i hostingdeki mail adresine çevirmeyin. Sağlayıcının MX hedeflerini ve önceliklerini aynen kullanın. Hostingde görünen paylaşılan IP, tek başına posta sunucusunun da aynı IP’de olduğunu kanıtlamaz.

SPF, DKIM ve DMARC: Aynı alan adında birden fazla SPF kaydı oluşturmayın; yeni gönderim servisini mevcut SPF politikasına uygun biçimde ekleyin. DKIM’in tam değerini karşılaştırın. DMARC p=none izleme politikasıdır; tek başına sahte e-postaların reddedildiği anlamına gelmez. Göndericiler doğrulanmadan politikayı sertleştirmeyin. cPanel Email Deliverability ekranı yardımcı kontroldür; geçiş sonrası gerçek alım/gönderim testi yine gerekir. Cloudflare DNS proxy sınırları.

Cloudflare’da alan adını ekleyin ve DNS incelemesini bitirin. Kayıt kuruluşunda yalnızca Cloudflare’ın bu alan adı için verdiği nameserver’ları kullanın; başka müşterinin nameserver değerlerini kopyalamayın. Hosting dosyalarını veya Woventico ürünlerini bu işlem taşımaz.

DNSSEC daha önce etkinse mevcut DS kaydının geçiş planını sağlayıcınızla kontrol edin. Standart geçişte eski sağlayıcıya ait DNSSEC/DS yapılandırması Cloudflare’a geçmeden önce uygun şekilde kaldırılır; Cloudflare aktif olduktan sonra yeni DNSSEC bilgileri kayıt kuruluşunda tanımlanır. Eski DS kaydıyla yeni nameserver’ları birleştirmek DNS çözümlemesini bozabilir. Özel DNSSEC geçişleri uzman tarafından planlanmalıdır.

Cloudflare alan adı durumunun Active olduğunu doğrulayın. DNS yayılımı boyunca eski DNS bölgesini erişilebilir tutun; web, yönetim ve e-postayı farklı bağlantılardan kontrol edin. Turuncu bulutu görmek tek başına tamamlanmış geçiş kanıtı değildir. Resmî nameserver geçiş adımları.

Önce hosting: cPanel → SSL/TLS Status bölümünde ana alan adı ve www için sertifika geçerliliğini, bitiş tarihini ve otomatik yenilemeyi kontrol edin. Cloudflare Full (strict), sunucunun geçerli ve istenen alan adıyla eşleşen sertifika sunmasını gerektirir.

• Cloudflare → SSL/TLS → Overview → Configure bölümünde Full (strict) seçin.
• Gizli sekmede ana sayfayı, ürün sayfasını ve sepeti açın. 526 hatası varsa sunucu sertifikasını kontrol edin; alışveriş kesildiyse önceki çalışan Full ayarına geçici dönüp sertifikayı düzeltin. Flexible’a geçerek kalıcı çözüm aramayın.
• SSL/TLS → Edge Certificates → Always Use HTTPS seçeneğini HTTPS düzgün çalıştıktan sonra açın.
• http:// ile siteyi açın; https:// adresine geçmeli ve yönlendirme döngüsü oluşmamalı. Ödeme sağlayıcısında kayıtlı dönüş adreslerinin de HTTPS olduğundan emin olun.
• HSTS’yi başlangıçta ayrıca etkinleştirmeyin. Bütün ilgili alan adlarında HTTPS ve sertifika yenilemesi doğrulandıktan sonra değerlendirin.

Full (strict) şifreleme ve sertifika doğrulamasıdır; saldırı filtreleme kuralı değildir. Always Use HTTPS de yönlendirmedir. Full (strict) · Always Use HTTPS.

Menü: Security → Settings. Yeni arayüzde özellikler DDoS attacks, Bot traffic ve Web application exploits gibi filtrelerle listelenebilir. Planınızda görünmeyen bir ayarı varmış gibi uygulamayın.

• DDoS korumaları: HTTP, ağ ve SSL/TLS korumalarının durumunu kontrol edin; Always active olarak görünenleri koruyun.
• Managed rules: Planınızda mevcut yönetilen kuralları etkin tutun. Custom rules ekranında özel kural olmaması, bütün yönetilen korumaların kapalı olduğu anlamına gelmez.
• Security level: Güncel arayüzde otomatik / always protected görülebilir. Eski rehberlerdeki Low–High seçeneklerini zorunlu bir adım saymayın.
• Browser Integrity Check: Etkinse işlev testleriyle izleyin. API istemcilerine yanlış pozitif uyguluyorsa Events kaydıyla hangi isteğin etkilendiğini belirleyin; gerekirse yalnızca o trafik için uygun istisna hazırlayın.
• Bot Fight Mode: Ödeme, API ve mobil uygulama entegrasyonları olan mağazalarda başlangıçta kapalı bırakıp kontrollü test sonrası değerlendirin. Ücretsiz Bot Fight Mode, WAF Skip kuralıyla atlanamaz.
• Under Attack Mode: Sürekli kullanılan standart mağaza ayarı yapmayın. Yoğun saldırıda geçici ve mümkün olduğunca hedefli kullanın; ödeme ve entegrasyon akışlarını ayrıca kontrol edin.

Cloudflare doğrulama sayfaları tarayıcıya yöneliktir; bir ödeme bildirimi veya otomatik API istemcisi bu sayfayı tamamlayamayabilir. Bot Fight Mode sınırları · Browser Integrity Check · Security level.

ABD veya başka bir ülkeden gelen yüksek istek sayısı tek başına saldırı kanıtı değildir. Arama motorları, reklam sistemleri, sosyal ağ tarayıcıları ve gerçek müşteriler de bu ülkelerden gelebilir. Her HTTP isteği ayrı ziyaretçi veya sipariş değildir.

• Security → Analytics / Events bölümünü açın; önce son 24 saat, değişiklik sonrası için son 15 dakika gibi uygun aralığı seçin.
• Country filtresini uygulayın. Bu filtre yalnızca raporu daraltır; trafiği engellemez.
• Sampled logs içinden bir isteği açın. Path, Method, User Agent, ASN, ülke, bot kategorisi, Action ve Service alanlarını birlikte okuyun.
• Aynı adrese yoğun ve tekrarlı erişim varsa hosting CPU/yük ve erişim kayıtlarıyla karşılaştırın. Örneklenmiş kayıtların bütün trafiği göstermediğini unutmayın.
• Events sayacını tek başına saldırı sayısı saymayın. Managed Challenge, doğrulama uygulandığını gösterir; Block ile aynı sonuç değildir. Kural editöründeki geçmiş eşleşme önizlemesi de engelleme sayısı değildir.

Kural eklemeden önce formun görünen sayfasını değil, isteğin gerçekten gönderildiği adresi kontrol edin. Tema ve eklenti sürümleri bu adresleri değiştirebilir. İncelenen Woventico Theme V1 kodunda müşteri giriş/kayıt formları /wp-admin/admin-post.php kullanır. Woventico Core yönetici girişi de aynı işlem adresini kullanabilir. Bu bulgu bütün sürümler için otomatik garanti değildir.

/wp-login.php için genel doğrulama eklemek bazı temalarda müşteri girişini, WordPress şifre sıfırlama bağlantılarını veya entegrasyonları etkileyebilir. Öte yandan formlar admin-post.php kullanıyorsa yalnızca wp-login.php kuralı bu formlardaki giriş denemelerini korumaz. /wp-admin/*, /wp-json/* ve bütün POST isteklerini topluca engellemeyin.

Tosla İşim 3.0.0 örneği: İncelenen kurulum paketinde ödeme dönüş adresi WordPress site adresinin sonuna aşağıdaki bölüm eklenerek oluşturuluyor. İşleyici POST verisini alıyor, hash kontrolü ve Tosla işlem sorgusu sonrası başarılı siparişi güncelliyor.

/?wc-api=wc_toslaisim

Bu paket taksit/komisyon işlemleri için /wp-admin/admin-ajax.php de kullanıyor. Bu adreslere tarayıcı doğrulaması uygulanmamalı. Diğer Tosla sürümlerinde veya başka ödeme eklentilerinde dönüş adresini kaynak koddan ya da sağlayıcıdan yeniden doğrulayın. Bu kod incelemesi bir güvenlik denetimi veya canlı ödeme testi yerine geçmez.

Dönüş URL’sini bilen herkes istek gönderebilir; bu yüzden yalnızca URL’ye bakıp bütün güvenlik katmanlarını atlayan geniş bir Skip kuralı oluşturmayın. Öncelikle yeni ülke kuralının kapsamını ödeme akışını içermeyecek şekilde daraltın. Başka bir koruma ödeme isteğini engelliyorsa ilgili olay kaydına göre ayrı ve sınırlı istisna hazırlayın.

Menü: Security → Security rules → Custom rules → Create rule → Edit expression. Aşağıdaki iki kural isteğe bağlı örneklerdir; trafik kayıtları ihtiyacı göstermeden bütün müşterilere otomatik dağıtılmamalıdır. Önce gerçek alan adını ve sepet yolunu doğrulayın.

Örnek A — Meta yapay zekâ tarayıcısının sepet isteğini engelleme. Logs içinde meta-externalagent görülüyorsa ve sepet taramasını istemiyorsanız kullanılabilir. Kural adı: Meta sepet taramasini engelle. Action: Block.

(http.host in {"example.com" "www.example.com"}
 and http.user_agent contains "meta-externalagent"
 and http.request.uri.path in {"/sepet" "/sepet/"}
 and http.request.method in {"GET" "HEAD"})

Bu, Meta’nın bütün servislerini veya bütün botları engellemez. User Agent taklit edilebilir veya değiştirilebilir; örnek yalnızca bu kimlikle gelen belirli istekleri hedefler. Sepet yolunuz /cart/ ise iki yolu da ona göre değiştirin.

Örnek B — Türkiye dışı ana sayfa/sepet ziyaretlerinde doğrulama. Türkiye odaklı mağazada, yabancı ziyaretçilere ek doğrulama uygulanması kabul ediliyorsa kullanın. Kural adı: Yurt disi ana sayfa ve sepet kontrolu. Action: Managed Challenge.

(http.host in {"example.com" "www.example.com"}
 and ip.src.country ne "TR"
 and not cf.client.bot
 and http.request.method in {"GET" "HEAD"}
 and http.request.uri.path in {"/" "/sepet" "/sepet/"}
 and http.request.uri.query eq "")

Sınırlar: Bu kural yalnızca belirtilen alan adlarında, Türkiye dışından gelen, Cloudflare’ın doğrulanmış bot olarak tanımadığı, sorgu parametresiz GET/HEAD isteklerini kapsar. Ürün sayfaları, başka yollar, POST istekleri ve ?utm_source=... gibi herhangi bir parametre içeren istekler kapsam dışındadır. Bir saldırgan da parametre ekleyerek bu özel kuralın dışında kalabilir. Dolayısıyla bu örnek, site genelinde saldırı koruması yerine geçen bir çözüm değildir.

Tosla’nın yukarıdaki POST dönüşü bu kuralın kapsamına girmez; fakat diğer Cloudflare özellikleri yine uygulanabilir. Yurt dışındaki gerçek müşteriler ve yurt dışı VPN kullanan Türkiye’deki kişiler doğrulama görebilir. Ülke, kişinin uyruğunu değil bağlantının IP konumunu ifade eder.

Meta engelleme kuralını önce, ülke doğrulamasını sonra yerleştirin; Active olarak kaydedin. Googlebot gibi doğrulanmış botları ülke kuralından not cf.client.bot ile ayırın. Geniş bir “tüm güvenliği atla” kuralı eklemeyin. Doğrulanmış botları ayırma örneği.

Giriş hız sınırı: Gerçek giriş işlem adresi, normal deneme yoğunluğu ve planın desteklediği eşleştirme alanları belirlendikten sonra ayrı uygulanmalıdır. Bütün admin-post.php isteklerine aynı sınırı koymak kayıt, şifre sıfırlama ve diğer formları etkileyebilir. POST gövdesindeki action alanını plan desteklemiyorsa URL sorgusu sanarak eşleştirmeyin; uygulama tarafında işlem özelinde sınırlama değerlendirin. Hız sınırlama yaklaşımı.

Güvenlik kurulumu sırasında bütün siteye Cache Everything uygulamayın. Sepet, ödeme, hesabım, oturum açmış kullanıcı içeriği ve ödeme bildirimleri kişiye/işleme özeldir. Mevcut Cache Rules, WordPress önbellek eklentisi ve varsa APO ayarlarını birlikte kontrol edin.

Özel HTML önbelleği kullanılıyorsa gerçek sepet/ödeme/hesap yolları, oturum çerezleri ve Woventico dinamik istekleri uygun biçimde önbellek dışında tutulmalıdır. Bir müşterinin sepeti veya hesap bilgisi başka müşteriye görünmemelidir. Güvenlikte Skip ile önbellekte Bypass farklı işlemlerdir. İki ayrı gizli oturumla farklı sepetler oluşturarak kontrol edin. Resmî e-ticaret önbellek rehberi.

Sonuçları tarih, değiştirilen ayar ve varsa Cloudflare Ray ID ile kaydedin. Kart bilgilerini veya gizli ödeme parametrelerini kayıt notlarına eklemeyin. Aşağıdaki kontroller birbirinin yerine geçmez.

• Türkiye bağlantısı: Ana sayfa ve ürün açılışı, arama, sepete ekleme, miktar değiştirme, kupon ve ödeme sayfası.
• Üyelik: Yeni kayıt, giriş, çıkış, şifremi unuttum e-postası ve e-postadaki bağlantıdan yeni şifre belirleme.
• Yurt dışı bağlantısı: Yeni gizli oturum ve yurt dışı VPN ile parametresiz ana sayfayı açın. Gerekiyorsa doğrulamayı tamamlayın; sepet ve ödeme sayfasına ilerleyin. Doğrulama sürekli tekrarlamamalı.
• Olay doğrulaması: Security Events içinden kuralı filtreleyin. Test zamanı, ülke, yol, eylem ve Rule ID’yi karşılaştırın. Ekranda doğrulama görmek tek başına hangi özelliğin tetiklediğini kanıtlamaz.
• Ödeme: Sağlayıcının desteklediği test ortamında veya işletmenin onayladığı kontrollü gerçek işlemle 3D Secure, siteye dönüş, işlem numarası ve sipariş durumunu kontrol edin. Başarısız/iptal işlem de yanlışlıkla ödenmiş olmamalı.
• Durum: Ödenmiş fiziksel ürün siparişinin İşleniyor olması normal olabilir; her başarılı ödemenin Tamamlandı olması gerekmez. Sağlayıcıdaki tahsilatı Woventico ödeme kaydıyla eşleştirin.
• E-posta: Harici hesaba gönderim, dışarıdan alım, sipariş ve şifre sıfırlama e-postası. Kimlik doğrulama sonuçlarını e-posta başlıklarında inceleyin.
• Entegrasyon: Stok/sipariş senkronizasyonu, kargo, mobil uygulama, zamanlanmış işler ve yönetici erişimi.

Kabul ölçütü: Ödeme sayfasının açılması, paranın tahsil edildiğini veya ödeme bildiriminin ulaştığını kanıtlamaz. Test erteleniyorsa kurulum kaydına “temel koruma aktif; gerçek ödeme dönüşü bekliyor” yazın.

• 526: Hosting SSL sertifikasının geçerliliği ve alan adı eşleşmesini inceleyin; Full (strict) öncesi çalışan ayara gerekirse geçici dönün. Sertifikayı düzeltip strict’i yeniden test edin.
• Yönlendirme döngüsü: WordPress site URL’leri, sunucu yönlendirmeleri ve Cloudflare yönlendirmelerini karşılaştırın. En son eklenen yönlendirmeyi geri alın.
• Giriş veya ödeme ekranında doğrulama: Events kaydından tetikleyen özelliği bulun. Yeni özel kural sorumluysa yalnızca o kuralı Disabled yapın. Bot Fight Mode sorumluysa WAF Skip eklemek çözüm değildir.
• Para çekildi, sipariş bekliyor: Tekrar ödeme istemeden önce sağlayıcı işlem kaydı ve Woventico sipariş notlarını inceleyin. Dönüş isteğinin engellenip engellenmediğini araştırın; tahsilat doğrulanmadan siparişi elle ödenmiş saymayın.
• E-posta kesildi: MX hedefi, hedefin A/AAAA kayıtları, proxy durumu ve sağlayıcının yönlendirmesini kontrol edin. SPF/DKIM değişikliği, hatalı MX hedefini düzeltmez.
• Yanlış veya eski sepet: Cache Rules ve WordPress önbellek istisnalarını kontrol edin; etkilenen önbelleği temizleyip ayrı oturumlarla yeniden deneyin.

Bütün korumaları kapatmak veya nameserver’ları aceleyle geri değiştirmek yerine, sorunla ilişkili son değişikliği geri alın. DNS geri dönüşü de yayılım süresine tabidir. Her geri alma sonrası aynı başarısız senaryoyu tekrar test edin.

Web sunucusunun gerçek IP’sine doğrudan erişilebiliyorsa saldırgan Cloudflare’ı atlayabilir. Hosting sağlayıcısıyla web portlarında yalnızca Cloudflare kaynaklarını kabul etme, Authenticated Origin Pulls veya uygun bir Tunnel mimarisini değerlendirin. Paylaşımlı hostingde bunu tek müşteri hesabından uygulamak mümkün olmayabilir.

Bu çalışma e-posta, SSH/FTP, yönetim paneli, sertifika yenileme ve izleme servisleri için ayrı erişim planı gerektirir. IPv4 ve IPv6’yı birlikte değerlendirin; bütün sunucu portlarını tek kuralla kapatmayın. DNS-only posta kaydı aynı IP’yi gösteriyorsa sunucu IP’si görünür kalabilir. Origin sunucusunu koruma.

İlk gün Events kayıtlarını ve sipariş akışını izleyin; yeni şikâyet veya engellenen entegrasyon varsa ilgili olayı araştırın. Sonrasında düzenli olarak kural eşleşmeleri, sertifika yenilemesi, WordPress/eklenti güncellemeleri ve yedekten geri dönüş kapasitesini kontrol edin. Kuralları başka mağazaya kopyalamadan önce alan adını, sayfa yollarını, ödeme sağlayıcısını ve sürümleri yeniden doğrulayın.