Sunucu güvenliği katman katman: Imunify360, CPGuard ve cxs nerede duruyor

Güvenlik ürünü seçerken çoğu kişi yanlış soruyu soruyor: "Imunify360 mu alsam, CPGuard mı?" Doğru soru şu: sunucumda şu anda hangi katman açık?

Bir saldırı tek kapıdan girmez. Önce paket olarak gelir, sonra HTTP isteğine dönüşür, sonra PHP olarak çalışır, en sonunda diske dosya olarak yazılır ve aylarca orada sessizce durur. Her aşamayı bambaşka bir teknoloji durdurur. Tek bir ürünün bu zincirin tamamını kapattığı iddiası ürün sayfası dilidir; gerçekte üçünün de kör noktası var.

Bir saldırının geçtiği katmanlar

• Ağ katmanı. Paket seviyesinde filtreleme, kapalı portlar, brute-force kilidi, ülke/ASN engelleme. Araçlar: nftables/iptables, CSF + lfd ya da ürünün kendi güvenlik duvarı modülü.
• İstek katmanı (WAF). İstek PHP'ye ulaşmadan içeriğine bakılır: injection denemesi, dosya yükleme, bilinen exploit imzası. Motor genelde ModSecurity'dir; ürünler arasındaki fark motorda değil, kural setinde ve arkasındaki itibar veritabanındadır.
• Çalışma anı katmanı. Filtreleri geçen kod PHP olarak çalışmaya başladığında ne oluyor? eval içine verilen base64 bloğu, system() çağrısı, hesabın kendi dizininin dışına çıkma denemesi.
• Dosya katmanı. Diske çoktan yazılmış shell, wp-config.php başına enjekte edilen satır, .htaccess içine gömülü yönlendirme. Tarama, karantina, dosya bütünlüğü.
• Yama katmanı. Çekirdek ve kütüphane açıkları. Üstteki dört katman kusursuz olsa bile aylardır yamalanmamış bir çekirdeğin üstünde hepsi dekordur.
• Geri dönüş katmanı. Yedek. Güvenlik ürünü değil ama tartışmasız bir güvenlik katmanı: temizliğin tutmadığı yerde kullandığınız şey budur.

Üç ürünü şimdi bu listeye oturtalım.

Imunify360 hangi katmanlara dokunuyor

Tek üründe en geniş kapsamı hedefleyen seçenek bu. Kendi güvenlik duvarı var (merkezî bir IP itibar veritabanından besleniyor, gri listeye düşen ziyaretçiye doğrudan blok yerine captcha çıkarıyor), ModSecurity üzerinde çalışan kendi WAF kural seti var, malware tarayıcısı var. Diğer ikisinde doğrudan karşılığı olmayan parçası ise Proactive Defense: PHP'ye yüklenen bir eklenti, kodu diskteki imzasına değil çalışırken davranışına bakarak yakalıyor. Dün yazılmış, imzası hiçbir veritabanında olmayan bir shell'i durduran katman budur.

Yani Imunify360 tek başına ağ, istek, çalışma anı ve dosya katmanlarına dokunuyor. Dokunmadığı katmanlar: yama ve yedek.

Zayıf tarafları da net söylemek gerekir:

• Kaynak tüketir. Tam bir /home taraması, RAM'i dar bir sunucuda hissedilir. Tarama yoğunluğunu kısabilirsiniz, ama kısınca tarama uzar; ikisini birden kazanmıyorsunuz.
• False positive üretir. Özellikle obfuscate edilmiş ama meşru eklentiler ve lisans kontrolü yapan ticari temalar. Otomatik temizliği ilk günden açarsanız çalışan bir siteyi kendi elinizle bozarsınız.
• Lisans durumunu izlemek size kalır. Sunucuyu yeni bir IP'ye taşıdıysanız ya da lisans süresi bittiyse ajan imza güncellemesi almayı bırakır. Kurulumdan sonra lisans durumunu düzenli kontrol edin.

CPGuard hangi katmanlara dokunuyor

CPGuard aynı ana katmanları hedefliyor: güvenlik duvarı yönetimi, ModSecurity kural yönetimi, brute-force koruması, malware taraması ve CMS zafiyet taraması. cPanel dışında DirectAdmin ve CyberPanel gibi panellerde de kullanılıyor; kendi panelinizin ve sürümünüzün desteklendiğini kurulumdan önce doğrulayın.

Pratikte iki yerde ayrışıyor. Birincisi kaynak tarafı: daha hafif bir ajan hedefleniyor. Bunu iddia olarak değil ölçüm olarak alın — kendi sunucunuzda bir hafta top ve iotop ile izleyin, cevabı sizin iş yükünüz verir. İkincisi kapsam: PHP çalışma anına giren bir katmanı yok. İmzasız, yepyeni bir shell diske düştüyse onu bir sonraki taramada yakalarsınız, çalıştığı anda değil.

RAM'in sınırlı olduğu VPS'lerde ve orta yoğunluklu sunucularda bu makul bir takas. Yüzlerce WordPress barındıran paylaşımlı bir sunucuda çalışma anı katmanının yokluğu daha çok hissedilir.

cxs neyi kapatır, neyi kapatmaz

cxs tamamen farklı bir araç. Güvenlik duvarı değil, WAF değil, arayüzü de yok denecek kadar az. Yaptığı tek iş dosya katmanı — ama orayı çok iyi yapıyor.

İki tarama modu, bir de web sunucusu entegrasyonu var. Birincisi on-demand tarama; cron'a koyabileceğiniz bir komut:

cxs --user musteri --quarantine /home/quarantine

Hangi testlerin çalışacağını --options harfleri belirler. Bu harfler sürüme göre değişir; internette bulduğunuz örnek satırı kopyalamak yerine kendi sunucunuzda cxs --help çıktısına bakın.

İkincisi gerçek zamanlı izleme: cxswatch, inotify ile /home, /tmp ve upload dizinlerini dinler, dosya diske yazıldığı anda tarar. FTP ya da SFTP ile bırakılan bir shell'i yakalayan katman budur — müşterinin kendi bilgisayarındaki bir zararlı FTP şifresini çalıp dosya yüklediğinde bunu hiçbir WAF görmez, izleme görür.

Üçüncüsü ve pratikte en kıymetlisi ModSecurity entegrasyonu: web üzerinden gelen dosya yüklemelerini, dosya kalıcı olarak yerine taşınmadan önce tarar. Zafiyetli bir eklentinin upload ucundan gelen shell burada durur. Paylaşımlı hostingde olayların büyük kısmı tam olarak bu iki yoldan başlar.

Kör noktaları:

• Ağ katmanına hiç dokunmaz; istek katmanında da yalnızca yüklenen dosyaya bakar, bir WAF kural seti sunmaz. "cxs kurdum, sunucu güvende" diyen kişi kapıyı açık bırakıp odayı süpürüyordur.
• İzleme moduna geçmeden önce sysctl fs.inotify.max_user_watches değerine bakın. Yüzlerce hesaplı bir sunucuda varsayılan değer yetmeyebilir; sınır dolduğunda bazı dizinler izlenmeden kalır ve bunu ancak logu okursanız fark edersiniz.
• Raporu okuyacak bir insan gerekir. Denetimsiz otomatik karantina, meşru bir dosyayı da alıp götürür.

Katman katman kim neyi kapatıyor

• Ağ: Imunify360 var · CPGuard var · cxs yok
• İstek (WAF): Imunify360 var · CPGuard var · cxs yalnızca yüklenen dosyayı tarar
• Çalışma anı: Imunify360 var · CPGuard yok · cxs yok
• Dosya: üçünde de var; cxs'te ayrıca gerçek zamanlı ve yükleme anında
• Yama: üçünde de yok
• Geri dönüş: üçünde de yok

Üçü birden gerekli mi? Hayır

Net cevap: Imunify360 ile CPGuard'ı aynı sunucuya kurmayın. Aynı katmanların büyük kısmını kapatıyorlar ve tam olarak aynı yerlerde çakışıyorlar. İki ajan da ModSecurity kural seti yüklerse aynı kural ID'si iki kez tanımlanır, ModSecurity yapılandırma hatası verir ve Apache açılmaz; ikisi de güvenlik duvarı zincirlerini yönetmeye kalkarsa bir süre sonra hangi kuralı kimin koyduğunu söyleyemezsiniz.

Mantıklı kombinasyonlar şunlar:

• Tek suite + yedek + yama. Sunucuların çoğu için doğru cevap bu. Bir suite seçin, üstüne yedek ve çekirdek yaması ekleyin.
• Suite + on-demand cxs. Suite gerçek zamanlı taramayı zaten yapıyorsa cxs'i saatlik cron taraması ve ModSecurity upload kancası olarak kullanın. cxswatch'ı da açarsanız aynı dosya iki ayrı ajan tarafından iki kez taranır; disk I/O'nuzu boşa yakarsınız.
• Sadece cxs + CSF. Müşteri yüklemesi olmayan, yalnızca kendi projelerinizin durduğu bir sunucuda fazlası gereksiz olabilir.

Kurulum sırası keyfi değil

• 1. Önce temel. SSH anahtarıyla giriş, root'a parolayla girişin kapalı olması, güncel paketler. Root parolası sızmış bir sunucuda üstüne kurulan hiçbir ürünün anlamı yok.
• 2. Yedek, tarayıcıdan önce. Güvenlik ajanları dosya karantinaya alır ve temizler; ilk false positive geldiğinde geri döneceğiniz bir yer olmalı. Kurup unutmayın, bir kez gerçekten restore deneyin.
• 3. Yama katmanı. Reboot beklemeden çekirdek yaması uygulayan bir çözüm, "bakım penceresinde yaparız" diye ertelenen yamayı ortadan kaldırır. Ertelenen yama, kapatılmamış açıktır.
• 4. İzolasyon. Paylaşımlı sunucuda CageFS türü hesap izolasyonu. Bunu tarayıcıdan önce yapın: izolasyon, tek hesabın ele geçmesini tüm sunucunun ele geçmesi olmaktan çıkarır.
• 5. Suite. Kurulum sunucuda tek komuttur; bash i360deploy.sh tarzı bir betik lisansı sunucunun IP'sinden bulur, elle anahtar girmezsiniz. Kurar kurmaz iki şey yapın: kendi yönetim IP'nizi beyaz listeye ekleyin (CSF kullanıyorsanız csf -a 1.2.3.4, kullanmıyorsanız ajanın kendi beyaz liste ekranından) ve CSF varsa /etc/csf/csf.conf içinde TESTING = 1 kaldıysa 0 yapın — testing modunda bir cron görevi kuralları düzenli olarak temizler ve lfd hiç başlamaz; korunduğunuzu sanırsınız, korunmuyorsunuzdur.
• 6. İlk hafta rapor modu. Malware aksiyonunu "temizle" değil "raporla" bırakın. Bir hafta false positive toplayın, gerçek istisnaları girin, sonra sıkın. Tersini yapan herkes ilk gün destek talebine boğulur.
• 7. En son cxs. Önce on-demand çalıştırın, raporu okuyun, ignore listesini kurun, ondan sonra izleme moduna alın.

WAF gerçek bir müşteriyi engellediğinde

Bu mutlaka olacak; genelde "yazımı kaydedemiyorum" diye gelir. 403'ü üreten kural ID'si ModSecurity denetim kaydında durur — cPanel/EasyApache 4'te varsayılan olarak /var/log/apache2/modsec_audit.log, dilerseniz WHM'deki ModSecurity araçlarının isabet listesinden de bakabilirsiniz. O ID'yi yalnızca o alan adı için kapatın. Daha hızlı diye tüm kural setini hesap genelinde kapatmak, sunucuların kâğıt üstünde korunup gerçekte çıplak kalmasının en sık yoludur.

Hiçbirinin çözmediği şeyler

• Zayıf WordPress admin parolası. Brute-force denemesi firewall'a takılabilir, ama parola sızmışsa saldırgan tek seferde ve geçerli kullanıcı olarak girer. Hiçbir katman bunu saldırı olarak görmez, çünkü teknik olarak saldırı değildir.
• Güncellenmemiş eklenti. Zafiyet müşterinin sitesindedir. Siz shell'i sonradan yakalarsınız, girişi değil.
• Nulled tema. Zararlı kodu müşteri kendi eliyle, kendi izniyle kurmuştur.
• Hacimsel DDoS. Sunucunun kendi güvenlik duvarı trafiği ancak sunucuya vardıktan sonra görür. O katman yukarıda, ağ tarafında çözülür.
• Veri sızıntısı. Meşru görünen bir SQL sorgusuyla tablo dışarı akıyorsa hiçbir imza bunu yakalamaz.

Katmanlı güvenlik "her şeyi durdururum" demek değil. Her riskin ayrı bir yerde, ayrı bir araçla ele alındığını bilmek demek — ve hangisinin hâlâ açık kaldığını dürüstçe söyleyebilmek.

Lisans tarafında pratik bir not

Bu üç ürünün lisansı da panelde sunucunun IP adresine bağlanır, anahtar dosyasına değil. Bunun günlük hayattaki karşılığı şu: sunucuyu yeni bir IP'ye taşıdığınızda ajan lisanssız kalır ve bunu genelde gürültü çıkarmadan, sadece imza güncellemelerini almayı bırakarak yapar. Taşımadan sonraki ilk iş IP'yi güncellemek olmalı; bunu panelden kendiniz yaparsınız, eski adres anında durur, yeni adres genelde bir dakika içinde çalışmaya başlar.

Imunify360, CPGuard ve cxs lisansları aynı panelden yönetiliyor; hangisini seçerseniz seçin sunucu güvenlik lisansları sayfasında yan yana duruyorlar. Yama katmanını da kapatmak isterseniz KernelCare aynı yerden eklenir.