ModSecurity Nedir? WAF Ne İşe Yarar, 403 Hatası Nasıl Çözülür?

ModSecurity nedir ve ne işe yarar?

ModSecurity, web sunucusuna bağlanıp gelen HTTP isteklerini kurallara göre denetleyen açık kaynaklı bir web uygulaması güvenlik duvarı (WAF) motorudur. Şüpheli isteği kayda alır ya da uygulamanıza ulaşmadan 403 ile durdurur. Böylece SQL enjeksiyonu denemesi gibi yaygın saldırılar sitenize varmadan takılır.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yazıdaki teknik anlatım resmi dokümana dayanır. Amacımız, sitenizde bir gün beklenmedik bir 403 hatası gördüğünüzde neyle karşılaştığınızı anlamanızı sağlamak.

Özellikle WordPress ve e-ticaret sitelerinde ModSecurity, "site çalışıyor ama formum kaydolmuyor" şikayetinin sessiz suçlusu olabilir. Bu rehberde kavramı, çalışma mantığını, yanlış pozitif yönetimini ve hosting sağlayıcınıza ne zaman devretmeniz gerektiğini adım adım anlatıyoruz.

ModSecurity nedir sorusunun kısa cevabını verdik. Şimdi isteğin yolculuğuna bakalım: ziyaretçi bir sayfa ister, istek önce web sunucusuna gelir, ModSecurity kuralları çalıştırır ve ancak izin çıkarsa istek uygulamanıza, örneğin WordPress'e ulaşır. Yani WAF, uygulamanın önünde duran bir kapıdır ve uygulamanın kendisi o karardan habersiz kalır.

WAF (web uygulama güvenlik duvarı) tam olarak ne yapar?

WAF, ağ seviyesinde çalışan klasik güvenlik duvarından farklı olarak HTTP trafiğinin içeriğine bakar. Klasik güvenlik duvarı hangi IP'nin hangi porta bağlanabileceğine karar verir. WAF ise isteğin adresine, parametrelerine, başlıklarına ve gövdesine bakıp "bu istek normal bir ziyaretçiye benziyor mu?" sorusunu sorar.

Bu fark önemlidir, çünkü saldırıların çoğu 80 ve 443 portlarından, yani tamamen meşru görünen bir kapıdan gelir. Port kapatmak bu kapıyı korumaz. WAF ise kapıdan giren isteğin içeriğini süzer. Üstelik kural setini güncellediğinizde, yeni bir saldırı sınıfına karşı uygulamanın kodunu değiştirmeden ek koruma kazanabilirsiniz.

WAF'ın üç temel işi vardır:

• İstekleri kural setiyle karşılaştırır ve eşleşmeleri puanlar.
• Eşiği aşan isteği engeller ya da yalnızca kayda geçirir.
• Her kararı denetim kaydına (audit log) yazar, böylece sonradan inceleyebilirsiniz.

WAF sihirli bir kalkan değildir. Güncel olmayan bir eklentideki açığı kapatmaz. Yalnızca o açığı sömürmeye çalışan bilinen kalıpların önüne geçmeye uğraşır.

ModSecurity nedir, motor ile kural seti arasında ne fark var?

Bu ayrım kafa karıştırır, çünkü insanlar iki şeye de "ModSecurity" der. Motor, kuralları okuyup isteklere uygulayan yazılımdır. Kural seti ise motora "neye bakacağını" söyleyen yönerge koleksiyonudur. Motor tek başına, kural olmadan hiçbir şeyi engellemez.

Resmi referans kılavuzuna göre motorun çalışma biçimini SecRuleEngine yönergesi seçer ve varsayılan değer kapalıdır. Yani motoru kurmak koruma sağlamaz. Kuralları yüklemeniz ve motoru açmanız gerekir.

Uygulamada şu üç katmanı görürsünüz:

• Motor: ModSecurity, Apache gibi web sunucusuna bağlanan modüldür.
• Kural seti: Genellikle OWASP Core Rule Set (CRS) ya da hosting sağlayıcınızın seçtiği ticari bir set.
• Özel kurallar: Sağlayıcınızın ya da sizin eklediğiniz istisnalar ve ek kurallar.

Sorun çıktığında hangi katmanda aradığınızı bilmek, kayıtları okumanızı çok kolaylaştırır. Örneğin motor kapalıysa kural setini suçlamanın anlamı kalmaz. Tersine, motor açıksa ve kural seti yüklüyse, kayıtta mutlaka bir kural kimliği görmeniz gerekir; görmüyorsanız sorunun başka bir yerde olma ihtimali yükselir.

ModSecurity nedir, ağ güvenlik duvarı ve IP engelleme araçlarından farkı nedir?

Sunucu güvenliğinde birkaç araç aynı amaca yakın görünür, ama farklı katmanlarda çalışır. Ağ güvenlik duvarı bağlantıya, yani IP ve porta bakar. Kayıt tabanlı IP engelleme araçları ise tekrarlanan başarısız denemeleri izleyip adresi geçici olarak dışarıda bırakır. ModSecurity ise bağlantı kurulduktan sonra isteğin içeriğine bakar.

Bu üç katman birbirinin yerini tutmaz. Örneğin ağ güvenlik duvarı, port 443 açıkken içerik hakkında hiçbir şey bilmez. WAF ise port ne olursa olsun yalnızca HTTP içeriğiyle ilgilenir.

Kısacası katmanları şöyle özetleyebilirsiniz:

• Ağ güvenlik duvarı: Kim, hangi kapıya bağlanabilir.
• IP engelleme araçları: Kim çok fazla hatalı deneme yaptı.
• WAF: Bu isteğin içeriği normal mi.

Diğer araçların ayrıntısı ayrı bir konudur. Bu yazıda yalnızca ModSecurity'ye odaklanıyoruz.

OWASP Core Rule Set neleri yakalamaya çalışır?

OWASP Core Rule Set, ModSecurity ve uyumlu motorlar için hazırlanmış genel amaçlı saldırı tespit kurallarıdır. Hedefi, OWASP Top 10 gibi yaygın risk sınıflarını, uygulamanıza özel kural yazmadan yakalamaktır.

Kural seti tek tek imzalara değil, kalıp ailelerine bakar. Örneğin şu sınıflara dair kurallar içerir:

• SQL enjeksiyonu ve komut enjeksiyonu denemeleri.
• Çapraz site betik (XSS) denemeleri.
• Dosya yolu gezme ve yerel dosya okuma girişimleri.
• Biçimi bozuk ya da protokole aykırı HTTP istekleri.
• Bilinen tarama ve saldırı araçlarının kullanıcı aracı (user agent) imzaları.

Bu yazıda saldırı imzalarını bilerek yazmıyoruz. Hem gereksiz bir ayrıntı hem de bazı sunucu güvenlik duvarlarının içerik kaydını engelleyebilecek bir risk. Kategorilerin adını bilmeniz, kararları anlamanız için yeterlidir. Ayrıca kural setinin genel amaçlı olduğunu unutmayın. Sizin uygulamanızın gerçek davranışını bilmez; bu yüzden kimi zaman meşru bir isteği şüpheli sayar.

Anomali puanlaması ile engelleme kararı nasıl çıkar?

CRS tek bir kural eşleşince hemen engellemez. Her eşleşen kural, önem derecesine göre isteğin anomali puanını artırır. Sonunda toplam puan eşiğe ulaşırsa istek reddedilir. CRS belgeleri bu yönteme "iş birliğine dayalı tespit" diyor.

Belgede verilen varsayılanlar şöyledir:

• Gelen istek (inbound) eşiği: 5.
• Giden yanıt (outbound) eşiği: 4.
• CRITICAL kural 5, ERROR 4, WARNING 3, NOTICE 2 puan ekler.

Dolayısıyla tek bir CRITICAL eşleşme, varsayılan eşiği tek başına aşar. Daha düşük önemdeki iki eşleşme ise birlikte eşiğe ulaşabilir. Karar sırası da belgede yazıyor. Önce istek kuralları çalışır ve eşik kontrolü yapılır. Ardından yanıt kuralları çalışır ve ikinci bir eşik kontrolü gelir.

Bu mantık yüzünden 403 aldığınızda şunu sormanız gerekir: tek bir kural mı yoksa birkaç küçük eşleşmenin toplamı mı engeli doğurdu?

Paranoya seviyeleri neden yanlış pozitifleri artırır?

CRS, kuralları dört paranoya seviyesine (PL) böler ve her seviye bir öncekinin üstüne kural ekler. Resmi tanıma göre PL 1 temel korumadır ve yanlış alarm ayıklama ihtiyacı en azdır. İkinci seviye, gerçek kullanıcı verisi olan siteler için daha uygundur. PL 3 bankacılık düzeyinde güvenlik sunar, ama çok sayıda yanlış alarm üretir. Dördüncü seviye ise en katı olandır.

Belge ayrıca bir uyarı yapar: ayar yapmadan yüksek paranoya seviyesini engelleme modunda çalıştırmak çok risklidir. PL 4 için ayar sürecinin haftalar sürebileceğini de belirtir.

Kısacası seviye yükseldikçe koruma artar, ama sizin sitenizin meşru istekleri de daha sık takılır.

Sağlayıcınızın hangi seviyeyi kullandığını sormak, sorun giderirken ilk sorularınızdan biri olmalı.

ModSecurity nedir, tespit modu (DetectionOnly) ile engelleme modu ne anlama gelir?

Motorun SecRuleEngine yönergesi üç değer alır. On kuralları işler ve engeller. Off kuralları hiç işlemez. DetectionOnly ise kuralları işler, ama resmi kılavuzun ifadesiyle engelleme, reddetme ya da yönlendirme gibi hiçbir bozucu eylemi yapmaz.

Yani DetectionOnly bir izleme modudur. Eşleşmeler kayda düşer, ziyaretçi hiçbir şey fark etmez. Bu mod, yeni bir kural setini devreye alırken en güvenli başlangıçtır. Çünkü meşru trafiği kesmeden hangi isteklerin takılacağını görürsünüz. ModSecurity nedir diye araştıran birçok site sahibi, bu modu "koruma kapalı" sanır; oysa kurallar çalışır, yalnızca karar uygulanmaz.

Mod seçimini kabaca şöyle düşünebilirsiniz:

• Yeni kurulum: DetectionOnly ile başlayın, kayıtları gözlemleyin.
• Ayar tamamlandı: Engelleme moduna (On) geçin.
• Sorun giderme: Motoru kapatmadan önce ilgili kuralı bulun.

Örnek bir yapılandırma satırı şöyle görünür:

SecRuleEngine DetectionOnly

Bu satırı yalnızca kendi sunucunuzu yönetiyorsanız değiştirirsiniz. Paylaşımlı hostingde bu karar sağlayıcınıza aittir.

ModSecurity nedir, cPanel'de neden hazır gelir?

Birçok hosting sağlayıcısı, güvenlik katmanı olarak ModSecurity'yi cPanel ortamına dahil eder. cPanel belgelerine göre kullanıcı arayüzünde tüm alan adları için ModSecurity'yi tek seferde açabilir, kapatabilir ya da her alan adını ayrı ayarlayabilirsiniz. Tek tek ayar yapmadan önce "Configure All Domains" bölümünde etkinleştirmeniz gerekir.

cPanel belgeleri, ModSecurity'yi tüm alan adlarında açık tutmanızı güçlü biçimde önerir. Yalnızca ModSecurity kaynaklı sorunları araştırırken kapatmanızı söyler. Arayüzü göremiyorsanız, belgeye göre sağlayıcının mod_security2 Apache modülünü kurması ve WHM'de ModSecurity Domain Manager özelliğini açması gerekir.

Yönetici tarafında (WHM) denetim kaydı seviyesi ve kural motoru gibi genel ayarlar yer alır. Bunlar sağlayıcının işidir. Sıradan bir hosting müşterisi o ekrana erişemez. Bu ayrım, sorun yaşadığınızda kimden ne isteyeceğinizi belirler: alan adı bazlı ayarı kendiniz değiştirebilir, kural düzeyindeki istisnayı ise sağlayıcıdan istersiniz.

Yanlış pozitif (false positive) nedir, nasıl anlarsınız?

CRS belgelerine göre meşru bir işlem yüzünden bir kural yanlışlıkla eşleşirse buna yanlış pozitif denir. Çözümü, kuralı silmek değil, o duruma özgü bir kural istisnası yazmaktır.

Yanlış pozitifi şu belirtilerden tanırsınız:

• Belirli bir formu gönderirken 403 Forbidden hatası çıkar.
• Aynı sayfa başka bir tarayıcıda ya da farklı içerikle sorunsuz çalışır.
• Yönetim panelinde bir ayarı kaydederken boş ya da hata sayfası gelir.
• Sorun yalnızca belirli bir işlemde, örneğin uzun bir ürün açıklaması kaydederken ortaya çıkar.

Dikkat edin: 403 yalnızca ModSecurity'den gelmez. Dosya izinleri, .htaccess kuralları ya da başka bir güvenlik eklentisi de 403 üretebilir. Bu yüzden önce hatanın kaynağını doğrulamanız gerekir.

Basit bir ön test işinize yarar: aynı işlemi farklı bir ağdan, örneğin telefonunuzun mobil verisiyle deneyin. Sonuç değişmiyorsa sorun büyük olasılıkla sizin ağınızda değil, sunucu tarafındadır.

Yanlış pozitifi kayıttan nasıl okursunuz?

Kayıt, sorunu çözmenin tek güvenilir yoludur. Resmi referansa göre SecAuditEngine değeri RelevantOnly ise motor yalnızca uyarı ya da hata üreten ve ilgili saydığı işlemleri kaydeder. Varsayılan değer ise kapalıdır. Kaydın hangi bölümleri içereceğini SecAuditLogParts seçer; varsayılan değeri ABCFHZ'dir.

Kayıtta aradığınız bilgiler şunlardır:

1. Tetikleyen kuralın kimliği (id).
2. Kuralın mesajı ve etiketleri.
3. Eşleşmeyi doğuran istek parçası, yani parametre ya da başlık.
4. İsteğin zamanı ve adresi.

Kural kimliği, istisna yazarken ihtiyacınız olan tek anahtardır. Kimlik olmadan hosting sağlayıcınızdan yardım almak da zorlaşır. Bu yüzden destek talebinde zaman damgasını ve adresi mutlaka verin.

Kayıt dosyasının yeri sağlayıcıya göre değişir. Paylaşımlı hostingde dosyaya erişiminiz olmayabilir. O durumda sağlayıcıdan ilgili kayıt satırını istemeniz gerekir.

Denetim kaydı kişisel veri taşır mı, nasıl korursunuz?

Taşıyabilir. Resmi kılavuzdaki bölüm harflerine göre denetim kaydı istek başlıklarını ve istek gövdesini de içerebilir. İstek gövdesi ise bir formdan gelen ad, e-posta ve benzeri alanları barındırabilir. Yani yanlış pozitif ararken açtığınız kayıt, ziyaretçilerinizin verisini de gösterebilir.

Bu yüzden şu alışkanlıkları öneriyoruz:

• Kayıtları yalnızca sorunu çözecek kişilerle paylaşın.
• Destek talebine kayıt satırını eklerken kişisel alanları karartın.
• Sağlayıcınıza kayıtların ne kadar süre saklandığını sorun.
• Gereksiz yere her işlemi kaydetmeyin; cPanel belgeleri de tüm işlemleri kaydetmeye karşı uyarır.

Kişisel veri yükümlülükleriniz varsa bu konuyu hukuk danışmanınızla da netleştirin. Biz burada hukuki görüş vermiyoruz; yalnızca kaydın bu veriyi taşıyabileceğini hatırlatıyoruz.

Kural istisnası nasıl yazılır?

İstisnanın iki yolu vardır. CRS belgeleri bunları yapılandırma zamanı ve çalışma zamanı istisnaları diye ayırır. Yapılandırma zamanında SecRuleRemoveById kuralı baştan kaldırır. Çalışma zamanında ctl:ruleRemoveById yalnızca belirli bir isteğe uygulanır.

Resmi kılavuza göre SecRuleRemoveById yönergesi, kapatacağı kuraldan sonra gelmelidir. Çalışma zamanı istisnaları ise tam tersine CRS yüklenmeden önce yer almalıdır, çünkü çalışmış bir kuralı sonradan değiştirmek etki etmez. Ayrıca ctl eylemi düzenli ifadeleri desteklemez.

Aşağıdaki örnek hesap yalnızca fikir vermek içindir. 920230 numarası CRS belgesinde örnek olarak geçen bir kural kimliğidir. Sizin kayıtlarınızdaki numara farklı olacaktır.

SecRule REQUEST_URI "@beginsWith /ornek-form/" "id:1000001,phase:1,pass,nolog,ctl:ruleRemoveById=920230"

Bu istisna yalnızca /ornek-form/ adresinde tek bir kuralı devre dışı bırakır. Kuralın tamamını kapatmaktan çok daha güvenlidir.

ModSecurity'yi tamamen kapatmak neden kötü fikirdir?

Hızlı çözüm gibi görünür, ama bedeli yüksektir. Kapattığınız anda sitenizdeki tüm istekler denetimsiz kalır. Üstelik sorunun gerçek nedenini de öğrenmezsiniz, çünkü sorun bir sonraki sefer başka bir yerde tekrar çıkar.

Bunun yerine şu sırayı izlemenizi öneriyoruz:

1. 403 hatasını yeniden üretin ve zamanını not edin.
2. Kayıttan tetikleyen kuralın kimliğini bulun.
3. O adres ya da o parametre için dar kapsamlı bir istisna isteyin ya da yazın.
4. İstisnadan sonra aynı işlemi tekrar deneyin ve kaydı doğrulayın.

cPanel belgeleri de aynı yönde öneri yapar: ModSecurity'yi yalnızca sorun giderme sırasında kapatın. Kapattıysanız, işiniz bitince hemen geri açın.

Kapatmanın tek makul kullanımı, sorunun gerçekten ModSecurity'den gelip gelmediğini anlamak için yapılan kısa bir testtir. Test bitince koruma yerine dönmelidir. Testin süresini önceden belirleyin ve bu süre içinde başka bir değişiklik yapmayın. Aksi halde sorunu neyin çözdüğünü anlayamazsınız.

WordPress sitelerinde 403 hatası neden çıkar?

WordPress, istek yapısı bakımından ModSecurity'ye yabancı olmayan ama sık takılan bir ortamdır. Yönetim paneli, eklentiler ve sayfa oluşturucular çok sayıda ayrıntılı istek gönderir. Bu isteklerin bir kısmı uzun parametreler ya da biçimlendirilmiş içerik taşır.

Örneğin sayfa oluşturucuyla kaydettiğiniz içerik, düzen bilgisini ve HTML parçalarını tek istekte gönderir. Kural seti bu gövdeyi şüpheli bulabilir. Aynı şekilde yönetim panelinin arka plan istekleri (admin-ajax gibi) sık sık takılan adreslerden biridir.

Takılma olasılığı yüksek durumlar şunlardır:

• Uzun içerik ya da HTML ile ürün açıklaması kaydetmek.
• Eklenti ayar sayfalarında çok alanlı formları göndermek.
• Tema ya da eklenti yüklerken büyük dosya göndermek.
• Arama kutusuna özel karakterler yazmak.

Çözüm yine aynıdır: kural kimliğini bulun, dar bir istisna isteyin. WordPress ile özel kodlama arasındaki farkı anlattığımız yazıda, eklenti bağımlılığının bakım yükünü neden artırdığını da bulabilirsiniz.

E-ticaret sitesinde ödeme dönüşleri ve bildirimler neden takılır?

E-ticarette en pahalı yanlış pozitif, ödeme sağlayıcısının sitenize gönderdiği bildirimin (webhook ya da geri dönüş adresi) engellenmesidir. Müşteri ödemeyi yapar, ama sipariş "ödenmedi" olarak kalır.

Bu tür istekler insan tarayıcısından gelmez. Başka bir sunucudan, çoğu zaman alışılmadık başlıklarla ve imzalı bir gövdeyle gelir. Kural seti bu istekleri otomatik araç trafiği sayarsa 403 döndürebilir.

Belirtiler şunlardır:

• Siparişler ödemeye rağmen "beklemede" kalır.
• Ödeme sağlayıcının panelinde bildirim hatası görünür.
• Sorun yalnızca ödeme sonrası adresinde ortaya çıkar.

Çözüm, o bildirim adresi için kural kimliği bazlı dar bir istisnadır. Tüm siteyi korumasız bırakmak çözüm değildir. Bildirim adresini her zaman ödeme sağlayıcısının kendi belgesine göre doğrulayın. Sayfa hızı ve dönüşüm ilişkisi için e-ticarette sayfa hızı satışları etkiler mi yazımıza da bakabilirsiniz.

Örnek senaryo: formu gönderince 403 alırsanız ne yaparsınız?

Aşağıdaki senaryo tamamen örnektir, gerçek bir müşteri vakası değildir. İletişim formunuzu gönderdiğinizde "403 Forbidden" sayfası geliyor, ama site geri kalanda sorunsuz çalışıyor diyelim.

İlk olarak formu kısa bir metinle deneyin. Kısa metin geçiyor, uzun metin takılıyorsa, içeriğin kendisi kuralı tetikliyor olabilir. Ardından aynı formu farklı bir ağdan gönderin. Sonuç değişmiyorsa sorun sizin ağınızda değildir.

Sonra şu adımları izleyin:

1. Hatanın saatini saniyesine yakın not edin.
2. Hangi adrese hangi yöntemle istek attığınızı yazın.
3. Kayda erişiminiz varsa kural kimliğini bulun; yoksa sağlayıcıdan isteyin.
4. Dar kapsamlı istisnayı talep edin ve formu yeniden deneyin.
5. Başka sayfaların etkilenmediğini kontrol edin.

Bu sırayı izlemeniz, "ModSecurity'yi kapatın" gibi geniş bir talebin yerine, çok daha hızlı ve güvenli bir çözüm getirir.

Hosting sağlayıcınıza hangi bilgilerle başvurmalısınız?

İyi hazırlanmış bir destek talebi, çözümü günlerden dakikalara indirir. Sağlayıcının işi kolaylaşır, çünkü ilgili kaydı doğrudan bulabilir.

Talebinize şunları ekleyin:

• Hatanın tam adresi (URL) ve kullandığınız yöntem, yani sayfa açma mı yoksa form gönderme mi.
• Hatanın oluştuğu tarih ve saat, saat dilimiyle birlikte.
• Kendi IP adresiniz; IP sorgulama aracımızla öğrenebilirsiniz.
• Ekran görüntüsü ve hata mesajının tam metni.
• Sorunun başladığı tarih ve o günden önce neyi değiştirdiğiniz.

Şunu da yazın: "Bu isteğin hangi ModSecurity kuralını tetiklediğini ve bu adres için dar kapsamlı bir istisna yapıp yapamayacağınızı öğrenmek istiyorum." Böylece sağlayıcı sizden kapatma talebi yerine doğru ayar beklediğinizi anlar. Talebi yazılı yapmanız da önemlidir, çünkü değişiklikten sonra neyin yapıldığını geriye dönüp kontrol edebilirsiniz.

Paylaşımlı hosting, VPS ve yönetilen hizmette ModSecurity'yi kim yönetir?

Sorumluluk dağılımı barındırma türüne göre değişir. Aşağıdaki tablo genel eğilimi gösterir. Kesin durum sağlayıcınızın koşullarına bağlıdır.

Hosting seçimi yaparken bu soruyu sormanız faydalıdır. Konuyu web sitesi için hosting nasıl seçilir rehberimizde ayrıca ele aldık. Orada WAF desteğinin de bir karşılaştırma ölçütü olduğunu görebilirsiniz.

Genel kural şudur: yönetimi size ait olmayan bir katmanı kurcalamak yerine, sağlayıcıya net bilgiyle başvurun. Panelsiz VPS kullanıyorsanız ise işin tamamı size düşer; bu durumda değişiklikten önce yedek almanız ve test ortamında denemeniz gerekir.

Kendi VPS'inizde ModSecurity'yi güvenli kurmanın yolu nedir?

Kendi VPS'inizi yönetiyorsanız izleyeceğiniz sıra bellidir. Burada tek tek komut vermiyoruz, çünkü paket adları ve dosya yolları dağıtıma göre değişir. Komutları her zaman dağıtımınızın resmi belgesinden ve CRS kurulum sayfasından doğrulayın.

Güvenli sıra şudur:

1. Dağıtımınızın resmi paketinden ModSecurity motorunu kurun.
2. CRS kural setini resmi kaynaktan edinin ve belgeye göre dahil edin.
3. SecRuleEngine değerini önce DetectionOnly olarak bırakın.
4. Denetim kaydını açın ve gerçek trafik üzerinde gözlem yapın.
5. Çıkan yanlış pozitifler için dar istisnalar yazın.
6. Kayıtlar sakinleşince engelleme moduna geçin ve izlemeye devam edin.

Bu sırayı atlayıp doğrudan engelleme modunda başlamak, müşterilerinizin ilk saatte 403 görmesine yol açabilir. Canlı siteye geçmeden önce küçük bir kopyada denemek de iyi bir alışkanlıktır. Değişiklikten önce de yedekleme stratejinizi mutlaka gözden geçirin.

WAF tek başına yeter mi, OWASP Top 10 ile ilişkisi nedir?

Hayır, yetmez. WAF bir savunma katmanıdır, uygulamanın kendi güvenliğinin yerini tutmaz. Güvenli yazılmış bir uygulama, WAF olmadan da açıklara karşı daha dayanıklıdır.

OWASP Top 10 rehberimizde anlattığımız risklerin kökü genellikle kodun ve yapılandırmanın kendisindedir. WAF bu risklerin sömürülmesini zorlaştırır, ama kaynağı onarmaz.

Güvenlik katmanlarını şöyle düşünün:

• Güncel yazılım, eklenti ve tema.
• Güçlü parola ve iki adımlı doğrulama.
• Doğru yapılandırdığınız SSL sertifikası ve HTTPS.
• Düzenli yedek.
• WAF olarak ModSecurity.

Bunların her biri farklı bir riske karşı çalışır. Birinin eksikliğini, diğerinin fazlalığı kapatmaz. Örneğin çok sıkı bir WAF, güncellenmemiş bir eklentinin açığını tamamen kapatamaz.

ModSecurity site hızını ve SEO'yu etkiler mi?

Her isteği kurallarla karşılaştırmak işlem yükü demektir. Etkinin büyüklüğü kural setine, paranoya seviyesine ve sunucu kaynaklarına bağlıdır. Elimizde genel geçer bir rakam yok, kaynağı olmayan sayı da vermiyoruz. Sitenizde fark edilir bir yavaşlık şüphesi varsa önce ölçüm yapın.

SEO tarafındaki asıl risk başka bir yerdedir. Arama motoru botu meşru bir sayfaya gelip 403 alırsa o sayfayı tarayamaz. Bu yüzden yanlış pozitifler yalnızca formları değil, taranabilirliği de etkileyebilir.

Önlem olarak şunları yapabilirsiniz:

• Önemli sayfaların farklı bir cihazdan ve farklı bir ağdan açıldığını kontrol edin.
• Yeni bir eklenti ya da kural değişikliğinden sonra kritik sayfaları yeniden deneyin.
• Tarama kısıtlarınızı robots.txt oluşturucu ile kontrol altında tutun.

Genel performans başlığı için site hızı SEO'yu nasıl etkiler yazımız iyi bir başlangıçtır.

Hangi durumda kendiniz yapmamalı, sağlayıcıya bırakmalısınız?

Dürüst cevap şu: çoğu web sitesi sahibi ModSecurity'ye hiç dokunmamalıdır. Önemli olan, sorunu doğru tanımlayıp doğru kişiye iletmektir. İyi bir tanım; ne zaman, nerede ve hangi işlemde hatayı gördüğünüzü içerir.

Şu durumlarda işi sağlayıcınıza bırakın:

• Paylaşımlı hosting kullanıyorsanız ve kural dosyalarına erişiminiz yoksa.
• Kural kimliğini bulamıyorsanız.
• Canlı bir e-ticaret sitesinde ödeme akışına dokunacaksanız.
• Yedeğiniz yoksa ya da geri dönüş planınız belli değilse.
• Sunucu yönetimi deneyiminiz yoksa.

Şu durumlarda kendiniz ilerleyebilirsiniz: kendi VPS'inizi yönetiyorsanız, bir test ortamınız varsa ve kayıtları okuyabiliyorsanız. Böyle olsa bile değişiklikleri küçük adımlarla yapın.

Sitenizin güvenliği, hızı ve altyapı kararları için birlikte düşünmek isterseniz web tasarım hizmetimizde bu konulara da yer veriyoruz. Alan adı ve DNS tarafı için DNS sorgulama aracı de işinize yarar.

ModSecurity nedir sorusundan sonra hangi adımlarla ilerlemelisiniz?

Özetle ModSecurity, sitenizin önünde duran ve istekleri puanlayan bir filtredir. Doğru ayarlandığında sessizce çalışır. Yanlış pozitif çıktığında ise ayar yaparak çözersiniz, kapatarak değil.

Pratik kontrol listeniz:

1. Sorunun gerçekten ModSecurity kaynaklı olduğunu doğrulayın.
2. Kayıttan kural kimliğini ve zamanı bulun.
3. Dar kapsamlı bir istisna isteyin ya da yazın.
4. Sonucu tekrar deneyerek doğrulayın.
5. Değişikliği not edin ve önemli sayfaları yeniden kontrol edin.

Sitenizin görünürlüğü ve dönüşümü bizim işimiz. Teknik altyapının arama sonuçlarını nasıl etkilediğini birlikte ele almak isterseniz SEO danışmanlığı ve e-ticaret danışmanlığı sayfalarımıza göz atın.

Kaynaklar: CRS anomali puanlaması, CRS paranoya seviyeleri, CRS yanlış pozitifler ve ayar, ModSecurity yapılandırma yönergeleri, cPanel ModSecurity belgesi, WHM ModSecurity ayarları.