Reseller Hosting’de Müşteri İzolasyonu: Chroot, CageFS ve Ayrı PHP‑FPM Havuzları

Reseller Hosting’de Müşteri İzolasyonu Neden Bu Kadar Kritik?

Reseller hosting kullanıyorsanız aslında küçük bir hosting firması işletiyorsunuz demektir. Aynı fiziksel sunucuda, aynı işletim sistemi ve web sunucusu üzerinde birden fazla müşterinin sitesini barındırıyorsunuz. Bu yapı maliyet açısından çok avantajlıdır; ancak güvenlik, performans ve hukuki sorumluluk tarafında ciddi riskleri de beraberinde getirir. Bir müşterinin zafiyeti, yanlış yapılandırılmış bir PHP betiği veya yoğun trafikli bir kampanya, diğer tüm müşterilerin sitelerini etkileyebilir. İşte tam bu noktada müşteri izolasyonu hayat kurtarır.

cPanel ve DirectAdmin gibi paneller, reseller hesapların altına çok sayıda kullanıcı ve alan adı tanımlamaya izin verir. Fakat sadece panel üzerinden kullanıcı oluşturmak tek başına yeterli değildir. Dosya sistemi, PHP çalıştırma modeli, SSH erişimi, MySQL bağlantıları ve kaynak limitleri ayrı ayrı düşünülmelidir. Bu yazıda DCHost olarak günlük operasyonlarımızda da uyguladığımız yaklaşımla, chroot, CloudLinux CageFS ve ayrı PHP‑FPM havuzları kullanarak cPanel ve DirectAdmin ortamlarında pratik, güvenli ve sürdürülebilir müşteri izolasyonunun nasıl kurgulanacağını adım adım anlatacağız.

Yazıyı özellikle ajanslar, freelancer’lar ve 20+ site yöneten küçük hosting işleticileri için hazırladık. Eğer hâlihazırda bir reseller paketiniz varsa veya DCHost üzerinde yeni bir reseller / kurumsal hosting mimarisi planlıyorsanız, burada anlatacağımız prensiplerle hem kendi gecenizi rahat uyursunuz hem de müşterilerinize kurumsal seviyede bir güvenlik ve performans sunabilirsiniz.

Reseller Hosting Mimarisi ve Tipik Riskler

Reseller hesaplarda temel mimari genelde benzerdir: Aynı sunucuda onlarca, bazen yüzlerce cPanel veya DirectAdmin kullanıcısı bulunur. Tüm bu kullanıcılar aynı Linux çekirdeğini, aynı web sunucusunu (Apache, LiteSpeed, Nginx vb.) ve çoğu zaman aynı PHP motorunu paylaşırlar. Doğru izolasyon yoksa bir kullanıcının yaptığı hata, komşu hesapları doğrudan etkileyebilir.

Paylaşımlı Kaynaklar ve Gürültücü Komşu Problemi

Reseller ortamında sık gördüğümüz problemlerden bazıları şunlardır:

• Bir müşterinin yoğun trafiği CPU ve RAM’i tüketir, diğer siteler yavaşlar.
• Kötü yazılmış bir PHP script sonsuz döngüye girer, tüm PHP süreçlerini kitler.
• Yanlış CHMOD/CHOWN izinleri yüzünden başka kullanıcının dosyalarına erişim açılır.
• Paylaşılan PHP handler (örneğin mod_php veya tek bir FPM havuzu) altında tüm siteler aynı kullanıcı gibi görünür.

Bu senaryolar, sadece performans sorunlarına değil aynı zamanda veri sızıntısı, KVKK/GDPR ihlali ve marka itibar kaybı gibi çok daha kritik sonuçlara da yol açabilir. Özellikle veri mahremiyetine odaklanan yapılar için, daha önce anlattığımız SaaS uygulamalarında müşteri verisini ayrıştırma mimarileri ile reseller hosting mantığı birebir benzerlik taşır.

cPanel ve DirectAdmin’de Yapısal Farklar

cPanel tarafında genellikle her müşteri için ayrı bir cPanel hesabı oluşturmak en sağlıklı yaklaşımdır. Buna rağmen pratikte pek çok ajans, bir hesabın altında addon domain olarak onlarca site barındırmayı tercih ediyor. Bu, hem güvenlik hem de e-posta ve log yönetimi açısından risklidir. Bu konuyu detaylı olarak ayrı cPanel hesabı mı addon domain mi sorusunu incelediğimiz yazımızda ele almıştık.

DirectAdmin tarafında ise reseller hesabı altına her müşteri için ayrı User oluşturmak ve her alan adını o kullanıcının içine yerleştirmek benzer şekilde en güvenli yöntemdir. Her iki panelde de dosya sistemi, PHP çalıştırma modeli ve kernel düzeyindeki izolasyonun nasıl sağlandığına bakmadan, sadece panelde kullanıcı oluşturmakla yetinmek uzun vadede ciddi sorunlar doğurur.

Chroot ile Dosya Sistemi Seviyesinde İzolasyon

chroot (change root), bir sürecin gördüğü kök dizini (/) yapay olarak değiştirmeye yarayan klasik bir Unix mekaniğidir. Bir kullanıcıyı chroot içine aldığınızda, o kullanıcı için sistem / kökü aslında /home/kullanici gibi sınırlı bir dizinmiş gibi görünür. Böylece kullanıcı işletim sisteminin geri kalanını göremez, çoğu sistem dosyasına erişemez.

cPanel’de Jailed SSH ve Chroot Mantığı

cPanel ortamlarında chroot genellikle Jailed SSH ile karşımıza çıkar. Kullanıcıya normal shell yerine jailed shell verildiğinde, SSH ile bağlandığında kendi home dizini ve bir dizi güvenli sistem aracıyla sınırlandırılmış bir ortam görür. Bu şu avantajları getirir:

• Kullanıcı /etc/passwd, /var/log gibi hassas dizinleri doğrudan göremez.
• Sunucu üzerindeki diğer kullanıcıların home dizinlerine erişemez.
• Gereksiz sistem araçları (gcc, make vb.) ortamdan çıkarılarak exploit geliştirme ihtimali azaltılır.

Ancak chroot tek başına sihirli bir çözüm değildir. Kernel hâlâ ortaktır, bazı bilgilere dolaylı yollarla erişilebilir, yanlış yapılandırılmış izinler chroot’un dışına sızmaya izin verebilir. Ayrıca sadece SSH oturumlarını kapsar; web sunucusunun ürettiği PHP süreçleri için ayrı bir izolasyon katmanına ihtiyaç vardır.

DirectAdmin’de chroot Kullanımı

DirectAdmin’de de benzer şekilde kullanıcıya jailed shell vererek chroot tabanlı bir sınırlama uygulanabilir. Özellikle geliştirme yapan ama tam root erişimine ihtiyacı olmayan müşteriler için, komut satırı verilecekse her zaman jailed shell tercih edilmelidir. Normal /bin/bash gibi tam shell’ler, reseller ortamlarında kötü niyetli veya dikkatsiz bir kullanıcıya gereğinden fazla güç verir.

Özetle, chroot:

• SSH tarafında temel bir izolasyon sağlar,
• dosya sistemi görünürlüğünü sınırlar,
• ancak PHP, web sunucusu ve kütüphaneler düzeyinde daha gelişmiş bir çözüme ihtiyaç bırakır.

CloudLinux CageFS ile Gelişmiş Kullanıcı İzolasyonu

Pek çok modern hosting ortamında, özellikle de cPanel ve DirectAdmin üzerinde, CloudLinux işletim sistemi fiili bir standart hâline geldi. CloudLinux’un sunduğu en kritik özelliklerden biri de CageFS’tir. CageFS, her kullanıcıya sanal bir dosya sistemi sunan ve onu sistemin geri kalanından izole eden bir katmandır. Klasik chroot’un üzerine ek güvenlik katmanları ve kullanım kolaylığı eklenmiş geliştirilmiş bir yaklaşımdır.

CageFS Neyi Çözüyor?

CageFS etkinleştirildiğinde, her kullanıcı:

• Kendi izole edilmiş sanal dosya sisteminde çalışır.
• /proc, /etc gibi dizinleri sınırlı, güvenli bir şekilde görür.
• Sunucudaki diğer kullanıcıların süreçlerini, dosyalarını ve konfigürasyonlarını göremez.
• Simlink saldırıları ve bazı klasik paylaşımlı hosting exploit’lerine karşı korunur.

CageFS, PHP süreçleri dahil olmak üzere pek çok bileşenin bu sanal dosya sistemi içinde çalışmasını sağlar. Böylece sadece SSH değil, web üzerinden çalışan uygulamalar da daha sıkı izole edilir. CloudLinux’un genel çalışma mantığını merak ediyorsanız, detayları CloudLinux nedir yazımızda oldukça kapsamlı anlatmıştık.

CageFS ve LVE Kaynak Limitleri

CageFS genellikle CloudLinux’un LVE (Lightweight Virtual Environment) modülü ile birlikte kullanılır. LVE sayesinde her kullanıcı için ayrı CPU, RAM, IO ve Entry Processes limitleri tanımlanabilir. Bu, bir müşterinin ani trafik patlamasının tüm sunucuyu çökertmesini engeller. cPanel tarafında bu limitleri doğru tasarlamanın önemini cPanel reseller paketlerinde limit tasarımı rehberimizde detaylandırmıştık.

Sonuç olarak, reseller hosting tarafında CageFS + LVE kombinasyonu:

• Güvenlik (kullanıcıların birbirini görememesi),
• Performans (her müşterinin kaynaklarının sınırlandırılması),
• Öngörülebilirlik (noisy neighbor etkisinin kontrol altına alınması)

açısından neredeyse vazgeçilmez bir yapı taşıdır.

Ayrı PHP‑FPM Havuzları ile Uygulama Katmanı İzolasyonu

Dosya sistemi ve sistem çağrıları düzeyinde izolasyon kadar önemli bir diğer katman da PHP çalışma modelidir. Geleneksel mod_php veya tek bir global PHP‑FPM havuzu ile tüm siteleri aynı havuzda çalıştırmak, hem güvenlik hem de performans tarafında risklidir. Bu nedenle modern reseller mimarilerinde her kullanıcıya veya her alan adına ayrı PHP‑FPM havuzu atamak artık en iyi pratiklerden biri kabul ediliyor.

PHP‑FPM Havuzu Nedir?

PHP‑FPM, PHP süreçlerini havuzlar (pool) halinde yöneten bir servisdir. Her havuz için ayrı kullanıcı, grup, dizin, pm.max_children, pm.max_requests gibi parametreler tanımlanabilir. Bu sayede örneğin yoğun trafikli bir WooCommerce sitesi için daha agresif ayarlar kullanırken, küçük bir blog için daha mütevazı limitler belirleyebilirsiniz. Bu ayarların WordPress ve WooCommerce üzerindeki etkilerini PHP‑FPM ayarları rehberimizde adım adım anlatıyoruz.

Neden Her Müşteri İçin Ayrı FPM Havuzu?

Reseller hosting’te ayrı FPM havuzları şu faydaları sağlar:

• Güvenlik: Her havuz farklı Unix kullanıcısı ile çalıştırılırsa, bir sitedeki zafiyet diğer sitenin dosyalarına erişemez.
• Kaynak Kontrolü: Her müşteri için ayrı pm.max_children ve bellek limitleri tanımlanabilir. Böylece tek bir proje tüm FPM süreçlerini tüketemez.
• Log Ayrımı: Her havuzun ayrı slow log ve error log dosyaları olur, hata ayıklama çok daha kolaylaşır.
• Versiyon Esnekliği: cPanel ve DirectAdmin üzerinde çoklu PHP sürümleri ile her siteye farklı PHP versiyonu atanabilir.

Özellikle büyük WordPress, WooCommerce veya Laravel projelerinde, ayrı FPM havuzları olmadan sağlıklı bir ölçeklenme yakalamak zordur. Uygulama tarafı optimizasyonu ile ilgili daha ileri seviye ihtiyaçlarınız varsa, PHP session ve cache depolama stratejilerini anlattığımız yazıya da göz atmanızı öneririz.

cPanel’de Müşteri İzolasyonu İçin Önerilen Tasarım

DCHost’ta cPanel tabanlı reseller veya kurumsal hosting mimarisi tasarlarken izlediğimiz temel prensipleri sade bir checklist halinde özetleyelim. Bu prensipler, kendi sunucusunu yönetenler için de yol gösterici olacaktır.

1. Her Müşteri İçin Ayrı cPanel Hesabı

Tek bir cPanel hesabının altında addon domain olarak 10–20 site barındırmak kısa vadede pratik görünse de, şu sorunlar hemen ortaya çıkar:

• Dosya sistemi tamamen ortaktır; bir sitenin açığı diğer tüm siteleri etkileyebilir.
• SSH/SFTP erişimi verdiğinizde tüm siteleri tek kullanıcı üzerinden expose etmiş olursunuz.
• E-posta, log ve yedek yönetimi karışır; hangi dosyanın hangi müşteriye ait olduğu net değildir.

Bu yüzden her müşteri (ve mümkünse her marka) için ayrı cPanel hesabı açmak çok daha doğrudur. Detaylı artı-eksi analizi için ayrı cPanel hesabı mı addon domain mi rehberimizden yararlanabilirsiniz.

2. CloudLinux + CageFS + LVE Etkinleştirme

cPanel üzerinde CloudLinux çalışıyorsa, aşağıdaki kombinasyon neredeyse varsayılan güvenlik standardınız olmalı:

• Tüm hesaplar için CageFS aktif
• Kaynak limitleri (CPU, RAM, IO, EP) müşteri paketlerine göre tanımlanmış
• Jailed SSH dışında normal shell erişimi kapalı

Bu sayede hem dosya sistemi düzeyinde izolasyon hem de kaynak bazlı sınırlama aynı anda devreye girer. Kaynak limitlerini tasarlarken reseller hosting yönetimi ve limit tasarımı yazımızdaki pratik oranlardan faydalanabilirsiniz.

3. Her Site İçin Ayrı PHP‑FPM Havuzu

cPanel’in MultiPHP ve PHP‑FPM özellikleriyle her domain için ayrı havuz kullanmak mümkündür. İdeal senaryoda:

• Her cPanel hesabı kendi kullanıcı adıyla çalışan FPM havuzlarına sahiptir.
• Yoğun siteler için pm.max_children, pm.start_servers gibi parametreler özel ayarlanır.
• Slow log aktif edilerek PHP performans sorunları kolayca tespit edilir.

Bu yapı, WordPress ve WooCommerce sitelerinde Core Web Vitals metriklerini iyileştirirken arka planda istikrarlı bir PHP performansı sağlar. PHP tarafında versiyon geçişleri yaparken de PHP 8 geçiş rehberimizde anlattığımız uyumluluk test adımlarını atlamamak önemli.

4. cPanel Hesap Güvenliği ve Erişim

İzolasyon sadece sunucu tarafında değil, panel erişimi tarafında da düşünülmelidir. Her müşteri hesabı için:

• Giriş parolaları güçlü ve benzersiz olmalı,
• İki faktörlü kimlik doğrulama (2FA) etkinleştirilmeli,
• Gereksiz FTP hesapları ve eski SSH anahtarları periyodik olarak temizlenmeli.

Bu konuyu başlı başına ele aldığımız cPanel hesap güvenliği sertleştirme rehberindeki adımları uyguladığınızda, reseller altyapınızın sadece sunucu tarafı değil, panel tarafı da kurumsal seviyeye yaklaşacaktır.

DirectAdmin’de Müşteri İzolasyonu İçin Önerilen Tasarım

DirectAdmin kullanan reseller’lar için yaklaşım mantık olarak çok benzerdir; sadece panel terminolojisi ve bazı menü adları farklıdır. DCHost üzerinde DirectAdmin tercih eden ajans ve yazılım evlerinde yaygın olarak önerdiğimiz yapı şu şekildedir:

1. Her Müşteri İçin Ayrı User, Her Site İçin Ayrı Domain

DirectAdmin’de reseller hesabı altında birden fazla User oluşturabilirsiniz. En sağlıklı tasarım, her müşteriye özel bir User tanımlamak ve o müşteriye ait alan adlarını bu kullanıcı altında açmaktır. Böylece:

• Her müşterinin dosyaları, veritabanları ve e-posta kutuları mantıksal olarak ayrılır.
• Yedekleme ve geri yükleme işlemleri müşteri bazlı yapılabilir.
• SSH/SFTP erişimi verdiğinizde sadece o müşterinin alanları etkilenir.

2. CloudLinux Entegrasyonu ve CageFS

DirectAdmin de CloudLinux ile entegre çalışabilir. cPanel’de bahsettiğimiz CageFS ve LVE prensipleri burada da geçerlidir. Tüm kullanıcılar için CageFS’yi aktif edip LVE limitlerini reseller paketlerine göre tanımlamak, DirectAdmin tarafında da en temiz çözümdür. Bu sayede panel fark etmeksizin standart bir güvenlik ve kaynak yönetimi politikası uygulayabilirsiniz.

3. PHP‑FPM Havuzlarının Kullanıcı Bazlı Ayrılması

DirectAdmin’de de her kullanıcı veya her domain için ayrı PHP‑FPM havuzları tanımlamak mümkündür. Eğer LiteSpeed veya Nginx + PHP‑FPM kombinasyonu kullanıyorsanız:

• Her User için ayrı Unix kullanıcısı ve FPM havuzu kullanın.
• Yoğun siteler için havuz parametrelerini özelleştirin.
• Varsayılan php.ini ayarlarını müşterinin ihtiyacına göre ek konfigürasyon dosyaları ile genişletin.

Bu yapı, özellikle DirectAdmin üzerinde çok sayıda PHP tabanlı uygulama (WordPress, OpenCart, Laravel vb.) barındıran ajanslar için hem hata ayıklamayı hem de kapasite planlamasını çok kolaylaştırır.

Ajanslar, Freelancer’lar ve SaaS Geliştiricileri İçin Senaryolar

Teoriyi pratiğe dökmek için DCHost’ta sık karşılaştığımız birkaç gerçekçi senaryoyu paylaşmak işinizi kolaylaştıracaktır.

Senaryo 1: 30+ WordPress Sitesi Yöneten Ajans

Bir web ajansı düşünün; onlarca WordPress ve WooCommerce projesini tek bir reseller hesabı altında yönetiyor. Kısa vadede her şeyi tek bir cPanel hesabında addon domain olarak tutmak kolay görünüyor. Ancak bir sitede kullanılan zayıf bir eklenti üzerinden saldırı gerçekleştiğinde, saldırgan tüm dosya ağacına erişebiliyor. Ayrıca bir kampanya döneminde tek bir WooCommerce sitesine gelen trafik, tüm hesap için PHP süreçlerini tüketiyor ve ajansın diğer tüm projeleri yavaşlıyor.

Bu ajansla birlikte yaptığımız yeniden tasarımda:

• Her son müşteri için ayrı cPanel hesabı açtık.
• CageFS ve LVE limitleri müşteri paketlerine göre ayrıştırdık.
• Her domain için ayrı PHP‑FPM havuzu tanımladık.

Sonuç: Hem güvenlik olayları dar alanda kaldı hem de yoğun trafik dönemlerinde sadece ilgili müşterinin kaynakları tavan yaptı, diğer siteler stabil kaldı. Ajans ölçeklenme ihtiyacını artırdığında, reseller hosting mi VPS mi karar rehberini kullanarak bazı projeleri izole VPS üzerine taşıyarak daha da kontrollü bir mimariye geçti.

Senaryo 2: E‑Ticaret Ağı Yöneten Girişim

Bir başka örnekte, aynı ekip birden fazla niş e‑ticaret markasını tek çatı altında yönetiyordu. Farklı domain’ler, farklı kampanyalar ve farklı ödeme sağlayıcıları vardı. Burada hem güvenlik (özellikle ödeme sayfaları ve müşteri verisi) hem de KVKK/GDPR ve PCI‑DSS gibi regülasyonlara uyum kritik hâle geldi.

Bu yapıda; her marka için ayrı cPanel hesabı, her hesapta CageFS, LVE ve ayrı PHP‑FPM havuzları kullanıldı. Kart verisini sunucuya hiç dokundurmayan bir mimariyle, PCI‑DSS uyumlu e‑ticaret hosting prensiplerini uyguladık. Böylece bir sitedeki güvenlik açığı diğer markaları etkilemeden, dar bir alanda izole edilip düzeltilebildi.

Senaryo 3: Multi‑Tenant SaaS Uygulaması

SaaS geliştiricileri için de reseller / çoklu hosting ortamlarında izolasyon çok benzer şekilde çalışır. Tek bir kod tabanının altında birden fazla müşteriyi barındırırken, her müşterinin verisini ve alan adını doğru izole etmek gerekir. Bu noktada veritabanı şeması, dosya depolama ve SSL otomasyonu gibi konular devreye girer. Ayrıntılarını multi‑tenant veritabanı ve hosting rehberimizde anlattığımız bu yaklaşım, reseller hosting’te müşteri izolasyonu ile aynı felsefeyi paylaşır: Her müşterinin verisi, süreci ve kaynak kullanımı olabildiğince bağımsız olmalıdır.

DCHost’ta İzolasyon Standartlarımız

Biz DCHost olarak, reseller ve çoklu site barındırma senaryolarında varsayılan yaklaşımımızı şu şekilde özetliyoruz:

• Her son müşteri veya marka için ayrı kullanıcı hesabı (cPanel veya DirectAdmin User)
• CloudLinux üzerinde CageFS ve LVE ile kullanıcı bazlı izolasyon ve kaynak limitleri
• Her domain için ayrı PHP‑FPM havuzu ve projeye özel FPM ayarları
• Güçlü parola politikası, 2FA ve IP kısıtlamaları ile panel erişim sertleştirmesi
• Periyodik güvenlik taramaları, yama yönetimi ve log analizi

Bu mimari sayesinde bir müşteride yaşanan performans veya güvenlik sorunu, diğer müşterilere minimum etkiyle yönetilebilir hâle geliyor. Özellikle çok siteli WordPress ve WooCommerce ortamlarında, doğru izolasyon ve kaynak limitleri ile “Resource Limit Reached” gibi klasik paylaşımlı hosting hatalarını önemli ölçüde azaltmak mümkün oluyor.

Sonuç: Sağlam İzolasyon, Sürdürülebilir Reseller İş Modelinin Temeli

Reseller hosting, doğru kurulduğunda son derece kârlı ve yönetilebilir bir iş modelidir. Ancak temel taşlardan biri eksikse –müşteri izolasyonu– hem güvenlik olayları hem de performans problemleri kaçınılmaz hâle gelir. cPanel ve DirectAdmin üzerinde chroot, CloudLinux CageFS ve ayrı PHP‑FPM havuzlarını birlikte kullanmak; dosya sistemi, süreçler ve kaynaklar düzeyinde çok katmanlı bir koruma sağlar.

Özetle:

• chroot ve jailed shell, SSH tarafında temel görünürlük kısıtlamasını sağlar.
• CageFS, kullanıcıya izole bir sanal dosya sistemi sunarak paylaşımlı hosting’in klasik zafiyetlerini büyük ölçüde kapatır.
• Her kullanıcı veya domain için ayrı PHP‑FPM havuzları, hem güvenlik hem de performans tarafında ince ayar yapma imkânı verir.

Eğer halihazırda reseller kullanıyorsanız veya DCHost üzerinde böyle bir yapıya geçmeyi planlıyorsanız, altyapınızı bu prensiplerle gözden geçirmenizi öneririz. Panel tarafındaki tasarım, CloudLinux ve PHP‑FPM ayarları için daha teknik bir değerlendirmeye ihtiyaç duyuyorsanız, projelerinizin detayını bizimle paylaşarak size özel bir mimari öneri talep edebilirsiniz. Doğru izolasyon ile, hem müşterilerinizin güvenliğini ve performansını artırır hem de kendi hosting iş modelinizi uzun vadede sürdürülebilir hâle getirmiş olursunuz.