Paylaşımlı hosting, adı üstünde, tek bir fiziksel sunucuda yüzlerce hatta binlerce farklı müşterinin yan yana barınması demektir. Bu modelin ekonomisi harika: donanım maliyeti onlarca hesaba bölünür, fiyat aşağı iner. Ama aynı çatı altında oturmanın bir de gizli faturası vardır. Standart bir Linux kurulumunda tüm kullanıcılar aynı dosya sistemini görür; birinin /etc/passwd dosyasını okuması, /tmp içinde başka bir müşterinin bıraktığı oturum dosyasını fark etmesi ya da ps aux ile komşu hesabın çalıştırdığı süreçleri listelemesi teknik olarak mümkündür. Tek bir dikkatsiz izin, tek bir güvensiz PHP betiği koca bir sunucuyu domino taşı gibi devirebilir.
İşte CageFS tam olarak bu problemi çözmek için tasarlanmış bir sanallaştırılmış dosya sistemi katmanıdır. CloudLinux OS'un kalbinde yer alır ve her kullanıcıyı, sanki sunucuda yalnızca kendisi varmış gibi hisseden izole bir "kafese" (cage) kilitler. Kullanıcı kendi dosyalarını, kendi PHP sürümünü, kendi geçici dizinini görür; ama komşularının varlığından bile haberdar olamaz. Bu yazıda CageFS'in ne olduğunu, kullanıcıyı tam olarak nasıl hapsettiğini, symlink saldırıları gibi klasik paylaşımlı hosting tehditlerini nasıl etkisiz hâle getirdiğini ve CloudLinux ekosistemindeki yerini kıdemli bir sistem yöneticisinin gözünden anlatacağım.
CageFS Tam Olarak Nedir#
CageFS, CloudLinux OS ile birlikte gelen ve her kullanıcı için ayrı bir sanal dosya sistemi ortamı oluşturan bir izolasyon teknolojisidir. Teknik olarak bir konteyner değildir, tam bir sanal makine de değildir; daha çok her kullanıcının çevresinde çizilmiş, dikkatlice sınırlandırılmış bir görüş alanıdır. Kullanıcı SSH ile giriş yaptığında ya da PHP betiği bir işlem başlattığında, CageFS o sürecin gördüğü dosya sistemini kendi kafesiyle sınırlar.
Kafesin içinde kullanıcı yalnızca üç şeyi görebilir: kendi ana dizinini (/home/kullanici), çalışması için mutlaka gereken sistem araçlarının güvenli ve salt okunur kopyalarını, ve kendisine özel olarak oluşturulmuş sanal /tmp, /proc, /etc gibi dizinleri. Görmediği şeyler ise en az gördükleri kadar önemlidir: diğer kullanıcıların ana dizinleri, sunucudaki tüm hesapların listelendiği gerçek /etc/passwd, sistem yapılandırma dosyaları, sunucu genelindeki süreç tablosu ve yönetimsel araçlar.
Bunu somut bir örnekle anlatayım. Standart bir sunucuda bir kullanıcı cat /etc/passwd çalıştırdığında sunucudaki tüm hesapların kullanıcı adlarını, ana dizin yollarını ve UID değerlerini bir çırpıda öğrenir. Bu, bir saldırgan için altın değerinde bir keşif bilgisidir. CageFS altında aynı komut çalıştırıldığında kullanıcı yalnızca kendi hesabını ve sistemin çalışması için gereken birkaç servis hesabını içeren, budanmış bir passwd görür. Komşularının varlığı ekrandan tamamen silinmiştir. İzolasyonun temel felsefesi budur: "göremezsin, dolayısıyla saldıramazsın."
Paylaşımlı Sunucuda İzolasyonsuz Yaşamın Riskleri#
CageFS'in değerini gerçekten anlamak için, olmadığında neyin yanlış gidebileceğini görmek gerekir. İzolasyonsuz bir paylaşımlı sunucuda üç temel risk kategorisi vardır ve üçü de gerçek dünyada sürekli sömürülür.
Birincisi bilgi sızıntısıdır. Kötü yapılandırılmış birçok uygulama, veritabanı parolalarını, API anahtarlarını ve gizli tokenları düz metin yapılandırma dosyalarında saklar. WordPress'in wp-config.php dosyası bunun klasik örneğidir. Eğer bir dosyanın izinleri gevşekse (örneğin 644 ve okunabilir bir yolda), aynı sunucudaki başka bir kullanıcı basit bir PHP betiğiyle o dosyayı okumayı deneyebilir. İzolasyon olmadan bu bir "belki" değil, doğrudan bir "nasıl" sorusudur.
İkincisi süreç ve sistem keşfidir. ps aux, netstat, /proc dizini taraması gibi araçlarla bir kullanıcı, sunucuda hangi servislerin çalıştığını, hangi portların dinlendiğini ve diğer kullanıcıların komut satırı argümanlarını (ki bazen bunlarda parola geçer) görebilir. Bu, hedef seçmeyi ve saldırı yüzeyini haritalamayı kolaylaştırır.
Üçüncüsü ve en tehlikelisi symlink ve yarış koşulu saldırılarıdır. Bunları ayrı bir başlıkta detaylandıracağım çünkü CageFS'in en parlak savunma yaptığı alan tam olarak burasıdır. Aşağıdaki tablo, izolasyonlu ve izolasyonsuz bir sunucunun kabaca farkını özetliyor.
| Yetenek | İzolasyonsuz Sunucu | CageFS Altında |
|---|---|---|
Tüm hesapları listeleme (/etc/passwd) | Mümkün | Engellenir |
| Komşu ana dizinlere göz atma | İzinler gevşekse mümkün | Görünmez |
| Sunucu geneli süreç görüntüleme | Mümkün | Yalnızca kendi süreçleri |
Paylaşımlı /tmp üzerinden veri sızıntısı | Yüksek risk | Kullanıcıya özel /tmp |
| Symlink ile yetkisiz dosya okuma | Klasik saldırı vektörü | Büyük ölçüde engellenir |
| Sistem araçlarını kötüye kullanma | Tüm araçlar erişilebilir | Yalnızca güvenli araç seti |
Sunucu güvenliğinin genel prensiplerini derinlemesine merak ediyorsanız, sunucu güvenliğinin temelleri rehberimiz bu konuyu katman katman ele alıyor.
CageFS Kullanıcıyı Nasıl Hapseder#
Kafesin teknik mekanizması, Linux'un mount namespace özelliğine dayanır. Bir kullanıcının süreci başladığında, CageFS o sürece özel bir bağlama (mount) ad alanı oluşturur ve içine yalnızca izin verilen dizinleri "bind mount" yöntemiyle bağlar. Bu bağlamaların büyük çoğunluğu salt okunurdur; yani kullanıcı sistem ikili dosyalarını göremediği gibi değiştiremez de.
CageFS'in gördüğü dünyayı üç kaba katmana ayırabiliriz. İlki, kullanıcının kendi yazılabilir alanıdır: ana dizini ve kendisine özel geçici dizinler. İkincisi, ortak ama salt okunur sistem şablonudur: /usr/bin, /lib, PHP ikili dosyaları ve derleyiciler gibi çalışması için gereken ama değiştirilemeyen araçlar. Üçüncüsü ise sanallaştırılmış özel dosyalardır: her kullanıcıya kendi /etc/passwd, /etc/group, /proc görünümü sunulur.
Yapılandırma dosyası tarafında işler /etc/cagefs/ dizininde döner. Yöneticiler burada kullanıcıların kafes içinde hangi araçlara erişebileceğini belirler:
# Kullanıcıya kafes içinde görünmesini istediğiniz komutları
# tanımlamak için conf.d altında bir dosya oluşturulur
/etc/cagefs/conf.d/kendi-araclar.cfg
# Örnek içerik
[kendi-araclar]
comment=Özel yardımcı araçlar
paths=/usr/local/bin/benim-aracim,/opt/tools
Sanal /proc görünümü sayesinde kullanıcı ps çalıştırdığında yalnızca kendi UID'sine ait süreçleri görür. top ya da htop açtığında sunucunun geri kalanındaki yükü değil, sadece kendi kafesinin içindekini görür. Bu, hem güvenlik hem de gizlilik açısından devrimseldir: bir müşteri, yan komşusunun ne kadar CPU tükettiğini ya da hangi uygulamayı çalıştırdığını asla göremez.
Kritik bir ayrıntı da şudur: CageFS, kullanıcıya sistem araçlarının orijinallerini değil, güvenli kopyalarını ya da salt okunur bağlamalarını sunar. Yani bir saldırgan bir ikili dosyayı değiştirip arka kapı yerleştiremez, çünkü o dosya kafesin içinde yazılamaz. Bu "değişmez sistem tabanı" yaklaşımı, kalıcılık sağlamaya çalışan zararlı yazılımların en sevdiği tekniklerden birini daha en baştan bloke eder.
Symlink Saldırıları ve CageFS'in Savunması#
Symlink (sembolik bağlantı) saldırısı, paylaşımlı hosting dünyasının en eski ve en verimli saldırı biçimlerinden biridir. Mantığı sinsi biçimde basittir: bir saldırgan kendi ana dizininde, başka bir kullanıcının hassas dosyasına işaret eden bir sembolik bağlantı oluşturur.
# Saldırganın klasik hamlesi
ln -s /home/kurban/public_html/wp-config.php ./okunacak.txt
cat okunacak.txt
İzolasyonsuz bir sistemde, eğer web sunucusu ya da dosya izinleri yeterince sıkı değilse, bu bağlantı saldırganın kurbanın veritabanı parolasını okumasını sağlayabilir. Daha da tehlikelisi, saldırgan bu bağlantıyı web üzerinden erişilebilir bir dizine koyup, PHP yorumlayıcısının hedef dosyayı okumasını sağlayarak izin kontrollerini atlatabilir. Buna sıklıkla eşlik eden bir teknik de TOCTOU (Time-of-Check to Time-of-Use) yarış koşuludur: dosya kontrol edildiği an ile kullanıldığı an arasındaki minik boşlukta bağlantı hedefi değiştirilir.
CageFS bu saldırı sınıfını iki cepheden etkisiz hâle getirir. Birincisi, kullanıcı zaten komşularının ana dizinlerini kafesin içinde göremediği için, /home/kurban/ yolu onun dünyasında var olmaz; symlink boşluğa işaret eder ve okuma başarısız olur. İkincisi, CloudLinux çekirdeği symlink sahiplik korumasını (fs.protected_symlinks ve CloudLinux'a özgü ek kontroller) zorunlu kılar; yani bir sürecin, kendisine ait olmayan bir kullanıcının sahip olduğu symlink üzerinden dosya okuması engellenir.
# CloudLinux çekirdeğinde symlink koruması durumunu görmek için
sysctl fs.protected_symlinks
sysctl fs.protected_hardlinks
# Beklenen çıktı
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
Sonuç olarak, izolasyonsuz bir sunucuda dakikalar içinde çekilebilecek bir wp-config.php sızıntısı, CageFS altında ölü bir hamleye dönüşür. Bu tek özellik bile, birçok yönetici için CloudLinux lisansının bedelini fazlasıyla çıkarır. WordPress'e özel güvenlik kaygılarınız varsa, güçlendirilmiş WordPress hosting paketlerimiz bu izolasyon katmanını varsayılan olarak sunar.
CloudLinux Ekosisteminde CageFS'in Yeri#
CageFS tek başına çalışan bir araç değildir; CloudLinux OS'un üç ayaklı güvenlik ve kaynak yönetimi mimarisinin bir parçasıdır. Bu üçlüyü anlamak, neden CageFS'in modern paylaşımlı hostingin belkemiği hâline geldiğini açıklar.
İlk ayak LVE (Lightweight Virtual Environment)'dir. LVE, her kullanıcıya CPU, bellek, giriş/çıkış (I/O) ve eşzamanlı süreç limitleri koyar. Bir kullanıcının sitesi trafik patlaması ya da kötü yazılmış bir betik yüzünden kaynakları tüketmeye başladığında, LVE onu kendi kutusuna hapseder ve sunucunun geri kalanı etkilenmez. Buna "kötü komşu" probleminin çözümü de denir. Kaynak izolasyonu ile dosya sistemi izolasyonunun farkını merak ediyorsanız, paylaşımlı hosting ile VPS karşılaştırması yazımız bu iki dünyanın sınırlarını netleştiriyor.
İkinci ayak CageFS'in kendisidir; yani bu yazının konusu olan dosya sistemi izolasyonu. LVE kaynakları böler, CageFS ise görüşü ve erişimi böler. Bu ikisi bir araya geldiğinde, paylaşımlı bir sunucu hem performans hem güvenlik açısından adeta ayrı ayrı sanal makineler gibi davranmaya başlar; ama VPS'in ek maliyeti ve yönetim yükü olmadan.
Üçüncü ayak ise PHP Selector ve hardened PHP özellikleridir. CageFS sayesinde her kullanıcı, sunucu genelini etkilemeden kendi PHP sürümünü ve eklentilerini seçebilir. Bir müşteri PHP 8.3 çalıştırırken komşusu eski bir uygulama için PHP 7.4'te kalabilir ve bu tercihler birbirini asla etkilemez, çünkü her biri kendi kafesinde yaşar.
| Bileşen | İzole Ettiği Şey | Çözdüğü Problem |
|---|---|---|
| LVE | CPU, RAM, I/O, süreç sayısı | Kötü komşu, kaynak tükenmesi |
| CageFS | Dosya sistemi, süreçler, sistem bilgisi | Bilgi sızıntısı, symlink, keşif |
| PHP Selector | PHP sürümü ve modülleri | Sürüm çakışması, uyumluluk |
Bu mimari, tek başına Clou.TR gibi bir barındırma sağlayıcısının müşterilerine hem esneklik hem de kurumsal düzeyde güvenlik sunmasını mümkün kılar. Ek bir koruma katmanı isteyen projeler için bu tabanı WAF ve DDoS koruma çözümleriyle birleştirmek de mümkündür.
CageFS'i Yönetmek ve Yaygın Komutlar#
Bir sistem yöneticisi açısından CageFS'in en güzel taraflarından biri, günlük yönetiminin cagefsctl adlı tek bir aracın etrafında dönmesidir. Bu araç, kafesleri etkinleştirmek, devre dışı bırakmak, şablonu güncellemek ve sorun gidermek için kullanılır.
Yeni bir sunucuda CageFS'i tüm kullanıcılar için etkinleştirmek istediğinizde temel komut şudur:
# CageFS'i tüm mevcut ve yeni kullanıcılar için aç
cagefsctl --enable-all
# Tek bir kullanıcı için etkinleştir
cagefsctl --enable kullanici_adi
# Tek bir kullanıcıyı kafesten çıkar (dikkatli kullanın)
cagefsctl --disable kullanici_adi
Sisteme yeni bir yazılım paketi ya da PHP eklentisi kurduğunuzda, bu değişikliğin kafeslerin içinde görünmesi için şablonu yeniden inşa etmeniz gerekir. Bu, yöneticilerin en sık unuttuğu ve "kurdum ama kullanıcı göremiyor" şikâyetlerinin ana kaynağı olan adımdır:
# Şablonu yeniden oluştur (yeni araçlar kafeslere yansısın)
cagefsctl --force-update
# Yalnızca belirli kullanıcıların kafeslerini yenile
cagefsctl --remount-all
# Bir kullanıcının kafes durumunu kontrol et
cagefsctl --check-cagefs
Belirli bir kullanıcıyı test amaçlı ya da özel bir uygulama nedeniyle kafesin dışında tutmanız gerekebilir. Bunu yaparken riski bilerek yaptığınızdan emin olun, çünkü o kullanıcı artık izolasyonun sağladığı korumadan yararlanamaz:
# Bir kullanıcıyı kalıcı olarak izolasyon dışı bırak
cagefsctl --disable-cagefs kullanici_adi
# Kimlerin kafeste, kimlerin dışında olduğunu listele
cagefsctl --list-enabled
cagefsctl --list-disabled
Bir sorun giderme senaryosunda, örneğin bir müşteri "SSH'a bağlanıyorum ama bazı komutlar bulunamıyor" diyorsa, büyük ihtimalle o komut kafesin izin listesinde yoktur. Çözüm, komutu /etc/cagefs/conf.d/ altında tanımlayıp şablonu güncellemektir. Bu yönetim yükünü hiç almak istemeyen ekipler için yönetilen sunucu hizmetlerimiz tüm bu bakımı üstlenir; siz yalnızca uygulamanıza odaklanırsınız.
CageFS Ne Zaman Yeterli Değildir#
Dürüst olmak gerekirse, CageFS mükemmel bir teknoloji olsa da her senaryonun cevabı değildir. İyi bir sistem yöneticisi, aracın sınırlarını da bilir. CageFS, paylaşımlı bir sunucudaki kullanıcıları birbirinden izole eder; ancak hepsi hâlâ aynı çekirdeği, aynı fiziksel donanımı ve aynı ağ yığınını paylaşır. Bu, çoğu web sitesi için fazlasıyla yeterlidir, fakat bazı projeler daha güçlü sınırlar ister.
Root düzeyinde erişim gerektiren özel yapılandırmalar, kendi çekirdek modüllerini yüklemek isteyen uygulamalar, Docker gibi konteyner platformları çalıştırmak, ya da düzenlenmiş sektörlerde (finans, sağlık) tam altyapı kontrolü zorunluluğu olan işler, paylaşımlı bir kafesin sınırlarını aşar. Bu tür durumlarda dosya sistemi izolasyonu değil, gerçek sanallaştırma gerekir.
Bu noktada devreye sanal sunucu ve VDS çözümleri girer. Bir VPS ya da VDS'te kendi işletim sisteminize, kendi çekirdeğinize ve kendi kaynaklarınıza tam hâkim olursunuz; komşu kavramı tamamen ortadan kalkar. CageFS'in sağladığı izolasyon "aynı evde ayrı odalar" ise, VPS "ayrı bir daire", tam bir fiziksel sunucu ise "ayrı bir bina" gibidir.
Karar verirken pratik bir ölçüt şudur: eğer standart bir web sitesi, blog, kurumsal tanıtım sayfası ya da orta ölçekli bir e-ticaret çalıştırıyorsanız, CageFS izolasyonlu bir web hosting paketi hem güvenli hem ekonomiktir. Eğer özel yazılım, yüksek trafik ya da tam kontrol ihtiyacınız varsa VPS/VDS'e geçmenin zamanı gelmiştir. Var olan sitenizi taşımak isterseniz ücretsiz site taşıma hizmetimiz bu geçişi sizin yerinize sorunsuzca halleder.
Sıkça Sorulan Sorular#
CageFS güvenli olduğuma dair tam garanti verir mi#
CageFS güçlü bir izolasyon katmanıdır ama tek başına mutlak güvenlik garantisi değildir. Kullanıcılar arası bilgi sızıntısını, symlink saldırılarını ve sistem keşfini büyük ölçüde engeller; ancak sizin kendi uygulamanızın içindeki bir açık (örneğin güncellenmemiş bir eklenti ya da zayıf parola) hâlâ sizi hedef alabilir. Güvenlik katmanlı bir yaklaşımdır: CageFS altyapı tarafını korurken, siz de uygulamanızı güncel tutmalı, güçlü parolalar kullanmalı ve mümkünse SSL sertifikası ile trafiğinizi şifrelemelisiniz.
CageFS sitemin performansını yavaşlatır mı#
Pratikte hayır. CageFS, Linux çekirdeğinin yerel bağlama ad alanı özelliklerini kullandığı için ek yükü son derece düşüktür ve çoğu kullanıcı hiçbir yavaşlama fark etmez. İzolasyon işlemi, süreç başlarken bir kez kurulur ve ardından dosya erişimi doğrudan çekirdek seviyesinde gerçekleşir; araya yorumlayıcı bir katman girmez. Aksine, LVE ile birleştiğinde kötü komşuların kaynaklarınızı çalması engellendiği için, çoğu zaman performansınız daha kararlı hâle gelir.
CageFS ile kendi PHP sürümümü seçebilir miyim#
Evet, bu CloudLinux'un en sevilen özelliklerinden biridir ve doğrudan CageFS izolasyonu sayesinde mümkün olur. Her kullanıcı kendi kafesinde yaşadığı için, sizin seçtiğiniz PHP sürümü sunucunun geri kalanını etkilemez; komşunuz PHP 7.4 çalıştırırken siz PHP 8.3 kullanabilirsiniz. PHP Selector aracı üzerinden sürümü ve etkin modülleri kendiniz değiştirebilir, hatta her alt dizin için farklı ayarlar tanımlayabilirsiniz.
Kafesin içinde göremediğim bir komut var, ne yapmalıyım#
Bu son derece normaldir ve bir hata değil, tasarımın bir sonucudur. CageFS, güvenlik için yalnızca izin verilen araçları kafesin içinde gösterir; yönetici belirli bir komutu açıkça izin listesine eklemediyse o komut görünmez. Barındırma sağlayıcınıza ihtiyacınız olan aracı bildirin; yönetici bu komutu /etc/cagefs/conf.d/ altında tanımlayıp şablonu güncelleyerek kafesinize ekleyebilir. Clou.TR panelinden bir destek talebi ya da sunucu yönetim ekibiyle iletişim bu isteği hızla çözer.
Paylaşımlı hosting yerine doğrudan VPS mi almalıyım#
Bu tamamen ihtiyacınıza bağlıdır. Standart web siteleri, bloglar, kurumsal sayfalar ve orta ölçekli e-ticaret için CageFS izolasyonlu paylaşımlı hosting hem güvenli hem de bütçe dostudur; sunucu yönetimiyle uğraşmadan güçlü bir izolasyon elde edersiniz. Ancak root erişimi, özel çekirdek modülleri, Docker gibi konteynerler ya da tam altyapı kontrolü gerekiyorsa VPS veya VDS daha doğru bir tercihtir. Emin değilseniz genellikle en mantıklısı paylaşımlı planla başlayıp, siteniz büyüdükçe sanal sunuculara yükseltmektir.
CageFS düzenli yedek almamı gereksiz kılar mı#
Kesinlikle hayır. CageFS, kullanıcılar arası saldırılara karşı bir izolasyon katmanıdır; veri kaybına, insan hatasına, fidye yazılımına ya da hatalı bir güncellemeye karşı sizi korumaz. Bu tehditlerin tek gerçek panzehiri düzenli ve test edilmiş yedeklerdir. İzolasyon ile yedeklemeyi birbirinden ayrı iki temel güvenlik kolonu olarak düşünün; ikisi de ayrı görevler görür. Otomatik yedekleme çözümlerimiz bu ikinci kolonu sizin için ayakta tutar.
Kapanış#
CageFS, paylaşımlı hostingin en eski açmazına zarif bir cevaptır: aynı sunucuda binlerce yabancıyı barındırırken her birini sanki tek başınaymış gibi hissettirmek. Kullanıcıyı kendi sanal dosya sistemine kilitleyerek bilgi sızıntısını, symlink saldırılarını ve sistem keşfini büyük ölçüde etkisiz hâle getirir; LVE ve PHP Selector ile birleştiğinde ise paylaşımlı bir planı, VPS'in maliyeti olmadan neredeyse özel bir sunucu gibi güvenli kılar. Ama unutmayın: izolasyon güçlü bir kolon olsa da tek başına yeterli değildir. Güncel uygulamalar, güçlü parolalar, SSL ve düzenli yedekler bu temeli tamamlar.
Clou.TR olarak tüm paylaşımlı ve WordPress barındırma planlarımızı bu CloudLinux izolasyon mimarisi üzerine kuruyoruz; yani daha ilk günden komşularınızdan güvenle ayrılmış olursunuz. Sitenizi güvenli bir zemine taşımaya hazırsanız, ihtiyacınıza uygun bir hosting paketi seçerek ya da büyüyen projeleriniz için sanal sunucu çözümlerimizi inceleyerek başlayabilirsiniz. Doğru izolasyon, güvenli bir web varlığının görünmez ama vazgeçilmez temelidir.