Virtualmin ile Çok Siteli Sunucu Yönetimi: İzolasyon ve Yedek

Tek bir Linux sunucuda yirmi site çalışıyor ve bunlardan birinde eski bir eklenti açığı var. Doğru kurulmuş bir Virtualmin sunucusunda zarar o sitenin ev dizininde kalır; kötü kurulmuş birinde saldırgan diğer on dokuz sitenin dosyalarına da erişir. Virtualmin, çok sayıda web sitesini, alan adını, veritabanını ve e-posta hesabını tek panelden yöneten açık kaynaklı bir Webmin modülüdür. Kurulumu kolaydır ama bu kolaylık, sitelerin zamanla birbirine bağımlı ve kırılgan hale gelmesini de kolaylaştırır: bir sitenin trafik sıçraması tüm sunucuyu yavaşlatır, yedekler alınır ama hiç geri yüklenmez. Aşağıda izolasyon, kaynak kontrolü, yedekleme ve panel güvenliği için sahada uyguladığımız düzeni anlatıyoruz.

Virtualmin’in yapı taşları

Virtualmin’i doğru yönetmek için panelin arka planda neyi yapılandırdığını bilmeniz gerekir. Panel kendi başına bir web sunucusu değildir; Apache veya Nginx, PHP-FPM, MariaDB/MySQL, BIND, Postfix ve Dovecot gibi standart servislerin yapılandırma dosyalarını sizin yerinize üretir. Panel arızalandığında elinizde kalan bu dosyalardır.

Kavram	Arka plandaki karşılığı
Sanal sunucu (virtual server)	Bir Unix kullanıcı ve grubu, ev dizini, web sunucusu sanal host tanımı, isteğe bağlı DNS bölgesi, veritabanı ve posta alanı
Alt sunucu (sub-server)	Aynı sahibin altında, ayrı alan adı ama aynı Unix kullanıcısı
Takma ad (alias)	Başka bir alan adını mevcut siteye yönlendiren tanım
Hesap planı ve şablon	Yeni sanal sunucuların hangi özelliklerle ve hangi varsayılan ayarlarla açılacağı

İzolasyon açısından belirleyici ayrım şudur: alt sunucular üst sunucunun Unix kullanıcısıyla çalışır. Aynı müşteriye veya aynı ekibe ait sitelerde alt sunucu pratik olabilir. Ancak birbirinden bağımsız olması gereken siteler (ör. kurumsal site ile ayrı bir kampanya sitesi, iki farklı birimin uygulaması) her zaman ayrı üst düzey sanal sunucu olarak açılmalı. Sahada en sık gördüğümüz yapısal hata, “hızlı olsun” diye her şeyin tek sanal sunucunun altına alt sunucu olarak eklenmesidir.

Panelin değişiklikleri standart dosyalara yazılır; bu dosyaları elle düzenleyebilirsiniz. Ama Virtualmin bazı ayar değişikliklerinde bu dosyaları yeniden üretebilir ve elle yaptığınız satır kaybolur. Elle yapılan değişiklikleri belgeleyin, mümkünse şablon düzeyinde yapın. Mevcut yapılandırmanın tutarlılığını komut satırından düzenli kontrol edin:

virtualmin check-config
virtualmin list-domains --multiline | less
virtualmin validate-domains --all-domains --all-features

validate-domains, her sanal sunucunun yapılandırmasının (web, DNS, veritabanı, posta) Virtualmin’in beklediği durumla tutarlı olup olmadığını denetler. Elle yapılmış ve unutulmuş değişiklikleri bulmanın en kısa yolu budur.

Sanal sunucu başına izolasyon

Çok siteli sunucunun temel güvenlik kuralı: bir sitenin ele geçirilmesi diğerlerine sıçramamalı. Bu kural tek bir ayarla değil, birkaç katmanla sağlanır:

• Dosya sahipliği: Her sanal sunucunun dosyaları kendi Unix kullanıcısına aittir ve ev dizini diğer kullanıcılara kapalıdır. Tüm sitelerin dosyaları web sunucusu kullanıcısına (www-data, apache) aitse, izolasyon kâğıt üzerindedir.
• PHP’nin site kullanıcısıyla çalışması: PHP-FPM havuzu her sanal sunucu için ayrı tanımlanır ve o sitenin kullanıcısıyla çalışır. Bir sitedeki zararlı kod yalnız o kullanıcının yazabildiği dosyalara dokunabilir.
• Veritabanı kullanıcıları: Her site kendi veritabanı kullanıcısını kullanır ve bu kullanıcının yalnız kendi veritabanına yetkisi olur. Uygulamada MariaDB root hesabı kullanılmaz.
• Ortak dizinler: /tmp gibi paylaşılan dizinlerde oturum ve yükleme dosyalarını diğer siteler okuyamasın diye PHP’nin oturum ve geçici dizinlerini sanal sunucu başına ayırın.

Devraldığınız bir sunucuda izolasyonu hızlıca kontrol etmek için ev dizini izinlerini ve PHP süreçlerinin hangi kullanıcıyla çalıştığını listelemek yeterli bir başlangıçtır:

ls -ld /home/*/
ps -eo user,cmd | grep '[p]hp-fpm: pool' | sort | uniq -c

Tüm havuzlar aynı kullanıcıyla çalışıyorsa, PHP yürütme modu sanal sunucu başına FPM’e çevrilmemiş demektir. İzolasyon yok.

PHP-FPM havuzları ve sürüm yönetimi

Virtualmin, sanal sunucu başına PHP yürütme modunu (FPM, FCGId, CGI) ve PHP sürümünü seçmeye izin verir. Sunucuda birden fazla PHP sürümü kuruluysa (Debian/Ubuntu’da php8.1-fpm, php8.3-fpm gibi paketler) her site kendi sürümünü kullanabilir. Havuz dosyaları ilgili sürümün pool.d dizininde, genellikle sanal sunucunun kimlik numarasıyla adlandırılmış olarak durur.

Bir dizinin kullandığı PHP sürümünü komut satırından görebilir ve değiştirebilirsiniz:

virtualmin list-php-directories --domain ornek.com.tr
virtualmin set-php-directory --domain ornek.com.tr \
    --dir /home/ornek/public_html --version 8.3

Sürüm değişikliği yalnız tek siteyi etkilediği için kademeli geçişe uygun bir mekanizmadır; ama uyumluluk testi yapmadan üretim sitesinde sürüm değiştirmek risklidir. Geçiş planlamasını ve uyumluluk taramasını PHP sürüm geçişi yazısında ayrıntılı anlattık. Havuzların pm.max_children gibi performans ayarları PHP-FPM ve MariaDB performans sorunları yazısının konusu; burada bilmeniz gereken, her havuzun kendi üst sınırı olması gerektiğidir.

Kaynak limitleri ve kota

Bir sitenin diğerlerini etkilemesinin en yaygın yolu kaynak tüketimidir: kontrolsüz tarayıcı trafiği, sonsuz döngüye giren bir eklenti, dolan bir disk. Virtualmin’de üç düzeyde sınır koyabilirsiniz:

1. Disk kotası: Sanal sunucu başına kota, dosya sisteminde kota desteğinin (usrquota, grpquota bağlama seçenekleri) etkin olmasını gerektirir. Kota yoksa bir sitenin log veya yedek dosyaları tüm diski doldurabilir.
2. Süreç ve bellek sınırları: Virtualmin’in kaynak limitleri ekranı, sanal sunucu kullanıcısının çalıştırabileceği süreç sayısı ve süreç başına bellek gibi sınırları tanımlar. Bu sınırlar özellikle cron ve SSH ile çalışan işler için anlamlıdır.
3. PHP-FPM havuz sınırı: Web trafiği açısından en etkili sınır pm.max_children değeridir. Tüm havuzların bu değerlerinin toplamı, havuz başına bellek tüketimiyle çarpıldığında fiziksel belleği aşmamalıdır. Bütün havuzlara cömert bir değer verilirse eş zamanlı yükte sunucu takasa (swap) girer ve her site birlikte yavaşlar.

Örnek hesap: 8 GB belleğe sahip bir sunucuda işletim sistemi, MariaDB ve web sunucusu için 3 GB ayrıldığını, ortalama PHP sürecinin 80 MB kullandığını varsayalım. Kalan yaklaşık 5 GB (5.120 MB ÷ 80 MB ≈ 64), bellek parçalanması ve ani sıçramalar için pay bırakıldığında toplamda en fazla 60 civarı eş zamanlı PHP sürecine yeter. Bu kapasiteyi sitelerin trafiğine ve önemine göre havuzlara paylaştırın; kritik site daha yüksek, düşük trafikli tanıtım siteleri daha düşük sınır alır. Ortalama süreç belleğini kendi sunucunuzda ölçün ve hesabı ona göre güncelleyin.

Yedekleme ve geri yükleme testi

Virtualmin’in yerleşik yedekleme aracı, sanal sunucu başına web dosyalarını, veritabanlarını, posta kutularını ve Virtualmin yapılandırmasını tek arşivde toplar. Zamanlanmış yedekler panelden tanımlanır; yerel dizin, SSH/SFTP sunucusu ve S3 uyumlu nesne depolama gibi hedefler desteklenir. Aynı işlem komut satırından da yapılır:

# Tüm sanal sunucuları, her biri ayrı arşiv olacak şekilde yedekle
virtualmin backup-domain --all-domains --all-features \
    --newformat --dest /backup/virtualmin/%Y-%m-%d --strftime

# Tek bir sanal sunucuyu geri yükle
virtualmin restore-domain --source /backup/virtualmin/2026-11-09/ornek.com.tr.tar.gz \
    --domain ornek.com.tr --all-features

Sunucunun kendi diskinde duran yedek, tek başına yedek değildir. Disk arızası, sunucunun ele geçirilmesi veya fidye yazılımı yedeği de götürür. En az bir kopya sunucu dışında, tercihen değiştirilemez (immutable) bir depoda durmalı. Bu ilkenin genel çerçevesini 3-2-1-1-0 yedekleme kuralı yazısı anlatıyor.

Eksik halka neredeyse her zaman geri yükleme testidir. Yedek test edilmeden yedek değildir. Düzenli bir test şu adımları içerir:

• Ayrı bir test sunucusuna (üretim sunucusuna değil) Virtualmin kurulur ve seçilen bir sanal sunucunun yedeği geri yüklenir.
• Sitenin açıldığı, veritabanı bağlantısının çalıştığı ve son içeriklerin yedekte bulunduğu kontrol edilir.
• Geri yükleme süresi not edilir ve kabul edilebilir kesinti süresiyle karşılaştırılır.
• Testin tarihi, kapsamı ve sonucu kayıt altına alınır.

Bu döngüyü en az birkaç ayda bir, sunucuda önemli bir değişiklik (sürüm yükseltme, yeni yedek hedefi) yapıldığında ise hemen tekrarlayın.

Panel erişimi ve güncelleme kontrol listesi

Virtualmin paneli sunucudaki tüm siteler üzerinde tam yetkiye sahiptir; panele erişim, tek bir sitenin yönetici paneline erişimden çok daha büyük risktir. Panel düşerse sunucu düşer. Webmin/Virtualmin varsayılan olarak 10000 numaralı TCP portunda çalışır ve bu port internete açık bırakılmamalıdır. Sertifika tarafında Virtualmin’in Let’s Encrypt entegrasyonu sanal sunucu başına sertifika alıp yenilemeyi otomatikleştirir; doğrulama yöntemlerini ve yenileme hatalarının takibini Let’s Encrypt sertifika otomasyonu yazısında anlattık.

Periyodik kontrol listesi:

• Panel portuna erişim güvenlik duvarında yalnızca yönetim ağına veya VPN’e açık mı?
• Yönetici hesaplarında iki faktörlü doğrulama etkin mi?
• Sanal sunucu sahiplerine verilen panel yetkileri ihtiyaçla sınırlı mı?
• Her bağımsız site ayrı üst düzey sanal sunucu olarak mı açılmış?
• Tüm PHP havuzları site kullanıcısıyla mı çalışıyor ve her birinin pm.max_children sınırı belirlenmiş mi?
• Disk kotaları etkin mi ve disk doluluk uyarısı tanımlı mı?
• Zamanlanmış yedekler sunucu dışına gidiyor mu ve son geri yükleme testinin tarihi belli mi?
• İşletim sistemi, Webmin/Virtualmin ve PHP paketleri düzenli güncelleniyor mu? Güncellemeden önce yapılandırma ve sistem yedeği alınıyor mu?
• Kullanılmayan sanal sunucular, eski PHP sürümleri ve terk edilmiş veritabanları temizleniyor mu?
• Her sitenin logları rotasyona dahil mi? Ayrıntılar için web sunucusu log yönetimi yazısına bakın.

Komut satırı araçlarının tam listesi ve parametreleri için Virtualmin dokümantasyonu başvuru kaynağıdır. Çok siteli sunucunun izolasyon ve yedekleme düzenini baştan kurgulamak veya devraldığınız bir sunucuyu denetletmek isterseniz, Linux VPS, Virtualmin ve hosting yönetimi kapsamında bu kontrolleri birlikte ele alıyoruz.

Sık sorulan sorular

Alt sunucu mu, ayrı sanal sunucu mu açmalıyım?

Alt sunucular üst sunucunun Unix kullanıcısıyla çalışır; aralarında dosya düzeyinde izolasyon yoktur. Aynı sahibe ait, birlikte yönetilen siteler için alt sunucu pratik olabilir. Birbirinden bağımsız olması gereken siteleri ayrı üst düzey sanal sunucu olarak açın.

Virtualmin’de her site farklı PHP sürümü kullanabilir mi?

Evet. Sunucuda birden fazla PHP-FPM sürümü kuruluysa sanal sunucu veya dizin bazında sürüm seçilebilir. Dikkat: her sürümün eklentileri ayrıca kurulur ve komut satırındaki php komutu varsayılan sürümü kullanır; cron işleri farklı sürümle çalışabilir.

Virtualmin yedeği tek başına yeterli mi?

Virtualmin yedeği site dosyalarını, veritabanlarını ve panel yapılandırmasını kapsar. Ama yedek aynı sunucuda duruyorsa disk arızasında veya saldırıda onunla birlikte kaybolur. En az bir kopyayı sunucu dışında, tercihen değiştirilemez bir depoda tutun ve geri yüklemeyi ayrı bir sunucuda düzenli test edin.

Webmin panel portunu değiştirmek güvenliği artırır mı?

Port değiştirmek otomatik taramaların gürültüsünü azaltır, gerçek koruma sağlamaz. Asıl önlem panel erişimini güvenlik duvarında yönetim ağı veya VPN ile sınırlamak, iki faktörlü doğrulamayı açmak ve paneli güncel tutmaktır.