Neden Varsayılan Olarak Her Müşteri Sunucusuna ModSecurity Kuruyorum
Reklam
OWASP Core Rule Set (CRS) ile güçlü bir şekilde eşleştirilmiş ModSecurity, üzerinde sonunda hangi uygulamanın çalışacağı hakkında hiçbir şey bilmesem bile kurduğum her bir sunucuya mutlaka girer.
Bu kulağa ters gelebilir. Kelimenin tam anlamıyla henüz ortada olmayan bir uygulama için bir web uygulaması güvenlik duvarını (WAF) nasıl yapılandırırsınız? Ama asıl mesele de tam olarak budur. CRS belirli bir uygulamaya göre ayarlanmamıştır (tuned). O, otomatik saldırıların bir yerlerde bir şeylerin onlara karşı savunmasız (vulnerable) olabileceğini varsayarak her sunucuya agresif bir şekilde gönderdiği o tam istek (request) türlerine göre katı bir şekilde ayarlanmıştır.
Gerçekte neyi yakalıyor?
Loglaması (günlük kaydı) sonuna kadar açılmış herhangi bir web sunucusunu çalıştırın ve asıl uygulamayla kesinlikle hiçbir ilgisi olmayan, sürekli ve devasa bir istek akışı göreceksiniz.
WordPress bile çalıştırmayan bir sunucuda /wp-admin'e erişmeye yönelik agresif girişimler göreceksiniz. Hiçbir sorgu parametresi (query parameter) almayan sayfaların parametrelerine sıkıştırılmış SQL injection yükleri göreceksiniz. Statik dosya yollarına şiddetle fırlatılan dizin atlama (path traversal - ../../etc/passwd) denemeleri göreceksiniz. Asla kurulmamış olan yazılımlardaki açıkları sömürmek (exploit) için özel olarak tasarlanmış payload'larla (yüklerle) tamamen doldurulmuş istekler göreceksiniz.
Bunların hiçbirinin sorun olmak için başarılı olmasına kesinlikle gerek yoktur. Bunlar en iyi ihtimalle ağır birer gürültüdür. En kötü ihtimalle ise, eğer kurulu tek bir yazılım bile onların agresif bir şekilde yokladığı (probing) şeyle eşleşirse, son derece gerçek bir risktir.
CRS, belirli uygulama açıklarını değil, kesin bir şekilde bunların arkasındaki örüntüleri (patterns) tanır. Bir SQL injection girişimi yapısal olarak tam bir SQL injection girişimi gibi görünür; ister tamamen özel (custom) bir PHP uygulamasına, ister rastgele bir WordPress eklentisine, isterse de hiçbir veritabanı olmayan statik bir siteye (ki zaten başarısız olacaktır ama kesinlikle bilinmeye değer kötü niyetli bir yoklama olmaya devam eder) yönelik olsun. İşte bu yapısal tanıma özelliği, hiçbir uygulamaya özel yapılandırma gerektirmeksizin onu inanılmaz derecede faydalı kılan şeydir.
Her zaman önce tespit (Detection) modu
İnsanların pes edip ModSecurity'yi tamamen kapatmalarının en yaygın nedeni, meşru (legitimate) trafiği şiddetle engelleyen bir "false positive" (yanlış alarm) durumudur. Bu genellikle, öfkeli bir müşterinin son derece normal bir girdisinin (input) tesadüfen bir kural kalıbıyla (rule pattern) eşleşmesi nedeniyle basit bir formu gönderememesiyle (submit) keşfedilir.
Bunun çözümü ModSecurity'yi devre dışı bırakmak değildir. Çözüm, onu ilk olarak katı bir şekilde tespit modunda (detection mode) devreye almaktır:
# modsecurity.conf
SecRuleEngine DetectionOnly
Bu modda ModSecurity, gerçekte hiçbir şeyi engellemeden sadece neyi engellemiş olacağını sessizce kaydeder. Gerçek, canlı trafiğe karşı bir veya iki hafta boyunca bu modda çalışmak, o spesifik uygulama için olası false positive'leri temiz bir şekilde yüzeye çıkarır. Bunlar daha sonra, engelleme moduna (blocking mode) geçmeden çok önce, son derece hedefe yönelik istisna (exclusion) kuralları ile özel olarak ele alınabilir:
SecRuleEngine On
Bu dikkatli, iki aşamalı devreye alma (rollout) süreci, "ModSecurity bir müşteriyi engelledi ve tamamen kapatılarak sunucuyu WAF'sız, tamamen çıplak bıraktı" ile "ModSecurity'nin ince ayarı yapılmış birkaç istisnası var ve geri kalan her şeyi aktif olarak engelliyor" arasındaki harfi harfine o devasa farktır.
İstisnaları (exclusions) ayarlamak bir başarısızlık değil, son derece normaldir
CRS bilinçli olarak bir "paranoya seviyesi" (paranoia level) ayarı ile gelir. Daha yüksek seviyeler agresif bir şekilde daha fazlasını yakalar, ancak önemli ölçüde daha fazla false positive üretir. Varsayılan seviye son derece mantıklı bir başlangıç noktasıdır.
Bunun ötesinde ihtiyaç duyulan herhangi bir istisna (exclusion), korumanın tüm geniş kategorilerini körü körüne devre dışı bırakmak yerine, genellikle spesifik bir kural ID'sine ve spesifik bir URL yoluna (path) yönelik son derece dar kapsamlı (narrowly scoped) olur:
SecRuleRemoveByIdWithMsg "rule message text" "specific-form-endpoint"
Bir uygulamanın kendine has özellikleri (örneğin, haklı olarak HTML benzeri içerik gönderen zengin bir metin düzenleyicisi - rich text editor) için bir avuç istisna tamamen normaldir. Bu, tüm sunucudaki diğer her şeyin korumasının altını kesinlikle oymaz. Asıl amaç sıfır istisna (zero exclusions) değildir; amaç, uygulamanın gerçekten ihtiyaç duyduğu tam ve az sayıdaki istisnayla, gerçekten açık olan ve aktif olarak engelleyen bir WAF elde etmektir.
Performans maliyeti, alternatifinden çok daha küçüktür
ModSecurity kesinlikle bir ek yük (overhead) getirir. Gelen her bir istek, uygulamaya ulaşmadan önce kural seti (rule set) üzerinden aktif olarak değerlendirilir.
Gerçek dünyadaki pratikte bu ek yük, çoğu istek için uygulamanın kendi işlem süresine (processing time) kıyasla inanılmaz derecede küçüktür. Dahası bu, uygulamanızın karmaşıklığıyla değil, katı bir şekilde kural setinin boyutuyla ölçeklenen (scales) bir ek yüktür. Acımasız alternatife—otomatik yoklamaların (automated probing) o sürekli, yıpratıcı temel düzeyine karşı kesinlikle sıfır jenerik koruması olan tamamen çıplak bir sunucuya—karşı tartıldığında, bu takas büyük, çok büyük bir farkla onun açık olmasından yanadır.
"Varsayılan olarak" (by default) olmak neden bu kadar önemlidir?
Bunun, uygulama henüz kararlaştırılmadan bile her bir sunucuya kurulmasının asıl nedeni, sunduğu jenerik korumanın uygulamayı bilmeye kesinlikle bağlı olmamasıdır.
Bir uygulama nihayet devreye alındığında ve resmi bir güvenlik incelemesi (security review) yapıldığında, hiçbir WAF'ı olmayan bir sunucu, genel (public) bir IP adresi aldığı o ilk saniyeden beri onu şiddetle yoklayan her ne varsa ona çoktan aktif olarak maruz kalmış demektir.
ModSecurity ile ilk günden itibaren tespit modunda (detection mode) başlamak ve uygulamanın belirli trafik kalıpları (traffic patterns) tam olarak anlaşıldığında güvenli bir şekilde engellemeye (blocking) geçmek, "sunucu var" ile "sunucunun güçlü bir temel koruması var" arasındaki o savunmasız (vulnerable) boşluğun fiilen sıfır olması demektir. Birinin onu en sonunda eklemeyi hatırlaması için gereken o uzun süreyi beklemez.
Reklam