Bu makalede8 bölüm
- Teknoloji
- Veeam Backup & Replication, Linux, XFS reflink, chattr/lsattr, ufw, chrony
- Konu
- Sertleştirilmiş Linux yedek deposunun kurulumu ve sıkılaştırılması
- Seviye
- Orta–ileri
- Ön koşullar
- Çalışan bir Veeam Backup & Replication kurulumu
- Temel Linux yönetim bilgisi
- Depo için ayrılmış fiziksel sunucu
Veeam Hardened Repository sihirbazı yeşil tikle biter ve çoğu ekip işin orada bittiğini düşünür. Bitmez. Depo sunucusunun root hesabı, yönetim kartı, SSH ve saat kaynağı açık kaldıkça saldırganın değiştirilemezliği aşma yolu da açık kalır. Aşağıdaki adımlar donanım seçiminden XFS hazırlığına, tek kullanımlık kimlik bilgisiyle eklemeden sunucu sıkılaştırmasına kadar kurulumu sırasıyla ve her aşamanın doğrulama testiyle veriyor.
Hardened repository’nin koruma modeli
Model üç fikre dayanır. Birincisi, yedek sunucusu depoya root ya da kalıcı bir yönetici kimliğiyle bağlanmaz. Depo yalnızca kurulumda kullanılan ve Veeam Backup & Replication veritabanına yazılmayan tek kullanımlık kimlik bilgisiyle eklenir; sonrasında iletişim, depoya kurulan Veeam Data Mover servisiyle sertifika tabanlı bağlantı üzerinden yürür. İkincisi, yazılan yedek dosyalarına Linux’un immutable (i) özniteliği konur. Bu öznitelik dosyanın silinmesini, yeniden adlandırılmasını ve üzerine yazılmasını root dahil herkes için engeller; özniteliği yalnızca CAP_LINUX_IMMUTABLE yetkisine sahip bir süreç, pratikte root, kaldırabilir. Üçüncüsü, özniteliği koyan ve süre dolunca kaldıran bileşen depo sunucusunda yerel çalışır; konsoldan gelen silme isteği süre dolmadan yerine getirilmez.
Modelin kapattığı risk, yedek konsolunun veya yedek sunucusunun ele geçirilmesidir. Kapatmadığı risk, depo sunucusunda root’a ulaşılmasıdır. Root, chattr -i ile özniteliği kaldırabilir, dosya sistemini biçimlendirebilir ya da sistem saatini ileri alıp sürenin dolmuş gibi görünmesini sağlayabilir. Bu yüzden aşağıdaki sıkılaştırma adımlarının hepsi tek hedefe çalışır. Root’a giden her yolu kapatmak. Teknolojinin diğer seçeneklerle karşılaştırması için değiştirilemez yedek seçenekleri yazısına bakabilirsiniz.
Donanım ve işletim sistemi gereksinimleri
Depo sunucusu tek amaçlı olmalı: üzerinde başka uygulama, paylaşım, izleme ajanı veya yönetim aracı olmamalı. Her ek servis root’a giden yeni bir kapıdır.
| Bileşen | Önerilen | Kaçınılacak |
|---|---|---|
| Sunucu tipi | Fiziksel sunucu | Üretim hipervizöründe sanal makine |
| Depolama | Yerel disk veya doğrudan bağlı (DAS) disk kabini | Başka sistemlerin yönetebildiği SAN/NAS hacmi |
| RAID | Önbellekli, pil/flash korumalı donanım RAID | Önbelleksiz yazılım RAID ile yoğun yazma |
| İşletim sistemi | Veeam’in desteklediği güncel 64 bit dağıtım | Destek listesinde olmayan veya ömrü dolmuş sürüm |
| Yönetim kartı | Ayrı ağda, yerel güçlü parolalı iLO/iDRAC/IPMI | Üretim ağında, domain kimliğiyle erişilen kart |
Desteklenen dağıtım ve sürüm listesi Veeam sürümüne göre değişir; kurulumdan önce kullandığınız Veeam Backup & Replication sürümünün sistem gereksinimleri sayfasını kontrol edin. Veeam ayrıca sertleştirilmiş depo için hazır, ISO tabanlı bir kurulum seçeneği sunuyor; bu yolu seçecekseniz destek durumunu ve sınırlamalarını güncel dokümantasyondan doğrulayın. Sanal makine kaçınılmazsa, depoyu barındıran hipervizör de ayrı kimlikle yönetilen, üretimden bağımsız bir sistem olmalı. Aksi halde hipervizör yöneticisi sanal diski siler ve koruma biter.
Disk, XFS ve kullanıcı hazırlığı
Fast clone (blok klonlama) için yedek hacmi XFS ile ve reflink açık olarak biçimlendirilmelidir. Reflink dosya sistemi oluşturulurken belirlenir. Sonradan açılmaz. Örnekte yedek diski /dev/sdb varsayıldı; komutu çalıştırmadan önce lsblk ile doğru diski seçtiğinizden emin olun, yanlış diske mkfs sahada en pahalı hatalardan biridir.
# Bölüm ve dosya sistemi
sudo parted -s /dev/sdb mklabel gpt mkpart primary xfs 0% 100%
sudo mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb1
# Kalıcı bağlama
sudo mkdir -p /mnt/veeam
echo "UUID=$(sudo blkid -s UUID -o value /dev/sdb1) /mnt/veeam xfs defaults 0 0" | sudo tee -a /etc/fstab
sudo mount -a
xfs_info /mnt/veeam | grep reflink # reflink=1 görülmeli
# Depo kullanıcısı ve klasör
sudo useradd -m -s /bin/bash veeamrepo
sudo passwd veeamrepo
sudo mkdir -p /mnt/veeam/backups
sudo chown veeamrepo:veeamrepo /mnt/veeam/backups
sudo chmod 700 /mnt/veeam/backups
Depo kullanıcısı root olmamalı. Veeam, depoyu eklerken bu kullanıcının geçici olarak yükseltilmiş yetkiye ihtiyacını sudo üzerinden karşılar. Ubuntu’da kullanıcıyı geçici olarak sudo grubuna ekleyin; ekleme bittiğinde bu yetkiyi geri alacaksınız:
sudo usermod -aG sudo veeamrepo # yalnızca depo ekleme süresince
# ... depo eklendikten sonra:
sudo gpasswd -d veeamrepo sudo
id veeamrepo # sudo grubu listede olmamalı
Tek kullanımlık kimlik bilgisiyle ekleme
Yedek konsolunda Backup Infrastructure altından yeni Linux sunucusu eklerken kimlik bilgisi türü olarak tek kullanımlık (single-use) kimlik bilgisini seçin. Girilen kullanıcı adı ve parola yalnızca Data Mover kurulumu ve sertifika alışverişi için kullanılır, veritabanına yazılmaz. Sihirbazda yetkinin otomatik yükseltilmesi seçeneği işaretli olmalı; kullanıcı sudo grubundan çıkarıldığında bu seçeneğin işlevi kalmaz.
Sunucu eklendikten sonra Backup Repository sihirbazında “Hardened Repository” türünü seçin, yol olarak /mnt/veeam/backups gösterin ve fast clone seçeneğinin etkin olduğunu kontrol edin. Sihirbaz XFS reflink desteğini görmüyorsa disk hazırlığına dönün; aksi halde sentetik tam yedekler tam boyutlu kopya olarak yazılır ve kapasite planı birkaç hafta içinde çöker.
- Linux sunucusunu tek kullanımlık kimlik bilgisiyle ekleyin.
- Hardened Repository türünde depoyu oluşturun, değiştirilemezlik süresini girin.
- Depo kullanıcısını sudo grubundan çıkarın, parolasını değiştirip güvenli şekilde kayda alın.
- SSH servisini kapatın (aşağıdaki sıkılaştırma bölümü).
- Konsolda depo durumunun sağlıklı göründüğünü ve bir test işinin başarıyla bittiğini doğrulayın.
Değiştirilemezlik ayarı ve doğrulama
Depo ayarlarındaki “son yedekleri belirtilen gün kadar değiştirilemez yap” seçeneği, her yeni yedek dosyasının en az bu süre kilitli kalmasını sağlar. Veeam, zincirin geri yüklenebilir kalması için tam yedeği, ona bağlı en yeni artımlı yedeğin süresi bitene kadar kilitli tutar. Fiili kilit süresi çoğu zaman ayardaki değerden uzundur ve kapasite hesabı buna göre yapılmalıdır. Değiştirilemez depoda işler ileri artımlı (forward incremental) yöntemle ve periyodik sentetik ya da aktif tam yedekle çalışmalıdır; ters artımlı (reverse incremental) yöntem bu depoyla kullanılamaz.
Süreyi yalnız kapasiteye bakarak belirlemeyin. Süre, saldırının fark edilmesine ve temiz bir kurtarma noktasının geriye doğru aranmasına yetmeli. Bu arama sürecini temiz kurtarma noktası seçimi yazısı ayrıntılı anlatıyor.
İlk iş tamamlanınca korumayı yerinde test edin. Testi sunucunun yerel konsolundan yapın; SSH’ı yalnız bu test için açmayın.
# Özniteliği kontrol et: bayrak alanında "i" görülmeli (ör. ----i---------e-------)
sudo lsattr -R /mnt/veeam/backups | grep -E "\.(vbk|vib)$"
# Depo kullanıcısıyla silme denemesi: reddedilmeli
sudo -u veeamrepo rm /mnt/veeam/backups/<iş-klasörü>/<dosya>.vbk
# rm: cannot remove '...': Operation not permitted
# root ile de silme reddedilmeli; önce chattr -i gerekir (bu yüzden root korunmalı)
sudo rm /mnt/veeam/backups/<iş-klasörü>/<dosya>.vbk
Ardından konsoldan, süresi dolmamış bir yedeği “Delete from disk” ile silmeyi deneyin; işlem değiştirilemezlik nedeniyle başarısız olmalı. Bu iki test korumanın hem işletim sistemi hem konsol düzeyinde çalıştığını gösterir. Çıktıları denetim kanıtı olarak saklayın. Test edilmemiş koruma, varsayımdır.
Sunucu sıkılaştırması: SSH, yerel erişim, zaman kaynağı
SSH ve ağ erişimi
Günlük işletimde yedek sunucusu depoyla Data Mover üzerinden konuşur, SSH’a ihtiyaç duymaz. Depo eklendikten sonra SSH’ı kapatın ve yerel güvenlik duvarında yalnızca Veeam trafiğine, yalnızca gerekli kaynaklardan izin verin. Veeam’in Linux bileşenleri Data Mover kontrol bağlantısı için TCP 6162, veri aktarımı için TCP 2500–3300 aralığını kullanır; ortamınızdaki listeyi sürümünüzün port referansından doğrulayın.
sudo systemctl disable --now ssh
sudo systemctl disable --now ssh.socket # Ubuntu 22.10+ soket etkinleştirmesi kullanıyorsa
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 10.20.30.10 to any port 6162 proto tcp # yedek sunucusu
sudo ufw allow from 10.20.30.0/28 to any port 2500:3300 proto tcp # proxy sunucuları
sudo ufw enable
sudo ufw status verbose
Data Mover güncellemesi veya sunucunun yeniden eklenmesi gibi durumlarda SSH ve sudo yetkisinin geçici olarak açılması gerekebilir. Bunu değişiklik kaydıyla, iki kişinin bilgisi dahilinde yapın; iş bitince ikisini de geri kapatın. “Sonra kapatırım” diye açık kalan SSH, sahada en sık bulduğumuz açıktır.
Yerel erişim ve yönetim kartı
SSH kapandığında root’a giden yollar yerel konsol ve yönetim kartıdır. Yönetim kartını (iLO, iDRAC, IPMI) üretim ağından ayrı bir yönetim ağına alın, domain kimliğiyle değil yerel ve güçlü parolalı bir hesapla yönetin, ihtiyaç yoksa sanal medya ve uzak konsolu kapatın. BIOS/UEFI parolası koyun, harici medyadan önyüklemeyi kapatın, GRUB’a parola tanımlayın; aksi halde tek kullanıcı moduna geçilip root parolası sıfırlanır. Root ve depo kullanıcısı parolaları, günlük kullanılan bir kasada değil, erişimi kayda alınan ayrı bir kasada durmalı.
Zaman kaynağı
Değiştirilemezlik süresi sistem saatine göre hesaplanır. Saati ileri alabilen biri sürenin dolduğu izlenimini yaratır. Sunucuyu yalnızca güvendiğiniz, saldırganın etkileyemeyeceği iç NTP kaynaklarına bağlayın ve büyük saat sıçramalarını izleyin. chrony kullanıyorsanız chronyc tracking ve chronyc sources -v çıktılarıyla kaynağı ve sapmayı düzenli kontrol edin. Domain denetleyicisini tek zaman kaynağı yapmak, domain düştüğünde depoyu da etkilenir hale getirir.
Güncelleme
Depo sunucusu güvenlik güncellemelerini almaya devam etmeli. Otomatik güvenlik güncellemeleri açılabilir; çekirdek güncellemesi sonrası yeniden başlatma planlı yapılmalı, ardından depo durumu ve öznitelikler kontrol edilmeli. Sunucu tarafındaki genel sıkılaştırma yaklaşımı sistem ve sunucu sıkılaştırma çalışmasının parçasıdır.
Sık hatalar ve kontrol listesi
Sahada en sık karşılaştığımız tablo, kurulumun teknik olarak başarılı ama kurumsal siber güvenlik açısından korumanın fiilen zayıf kaldığı durumdur:
- Depo kullanıcısının sudo grubunda kalması: Data Mover’ı ele geçiren veya kullanıcının parolasını bilen biri root olur.
- SSH’ın açık bırakılması: Parola tabanlı SSH, depoyu kaba kuvvet ve kimlik bilgisi tekrarı saldırılarına açar.
- Reflink’siz XFS: Sentetik tam yedekler tam boyut yazılır, kapasite planlanandan çok hızlı tükenir; çözüm hacmi yeniden biçimlendirmektir.
- Yönetim kartının üretim ağında olması: Uzak konsoldan önyükleme müdahalesiyle root parolası sıfırlanabilir.
- Kısa değiştirilemezlik süresi: Fark edilmeden ortamda kalan saldırgan, kilidin dolmasını bekleyip yedekleri konsoldan siler.
- Testin yapılmaması: Özniteliğin gerçekten konduğu hiç doğrulanmamıştır.
Kurulum sonrası kontrol listesi:
- Sunucu fiziksel, tek amaçlı ve domain’e üye değil.
xfs_infoçıktısındareflink=1görülüyor.- Depo kullanıcısı root değil ve sudo grubunda değil.
- Depo tek kullanımlık kimlik bilgisiyle eklendi; yedek sunucusunda depo için saklanan kimlik bilgisi yok.
- SSH kapalı; yerel güvenlik duvarı yalnızca yedek sunucusu ve proxy’lerden gelen Veeam portlarına izin veriyor.
- Yönetim kartı ayrı ağda, yerel hesapla korunuyor; BIOS ve GRUB parolalı.
- NTP kaynağı güvenilir, saat sapması izleniyor.
lsattrileiözniteliği ve silme denemesinin reddi doğrulandı, sonuç kayıtta.
Depoyu sıkılaştırmak işin bir parçası; yedek sunucusunun kendisinin de domain’den ve üretim kimliklerinden ayrılması gerekir. Bu tasarım yedek altyapısında kimlik izolasyonu yazısında. Mevcut depolarınızı bu liste üzerinden birlikte gözden geçirmek, yedekleme güvenliği ve fidye yazılımına hazırlık çalışmamızın kapsamındadır. Ürüne özgü ayrıntılar için birincil kaynak Veeam Hardened Repository dokümantasyonudur.
Sık sorulan sorular
Hardened repository sanal makine olarak kurulabilir mi?
Teknik olarak çalışır ama koruma modeli zayıflar. Hipervizör yöneticisi sanal diski silebilir, snapshot’tan eski bir duruma dönebilir veya konsoldan root parolasını sıfırlayabilir. Değiştirilemezliğin anlamlı olması için yerel diskli, ayrı yönetilen fiziksel bir sunucu tercih edin.
Depoyu ekledikten sonra SSH tamamen kapatılabilir mi?
Evet, günlük işletimde SSH gerekmez; yedek sunucusu Data Mover servisiyle sertifika tabanlı bağlantı üzerinden konuşur. Data Mover güncellemesi veya kimlik bilgisinin yeniden girilmesi gerektiğinde SSH’ı geçici olarak açmanız gerekebilir. Bu ihtiyaç sürüme göre değiştiği için kendi sürümünüzün dokümantasyonuna bakın.
Değiştirilemezlik süresi dolmadan yedek dosyası silinebilir mi?
Konsoldan ve depo kullanıcısıyla silinemez; dosyalarda Linux immutable özniteliği vardır. Root’a ulaşan biri özniteliği kaldırabilir. Korumanın gücü, root hesabının, yerel konsolun ve yönetim kartının ne kadar iyi korunduğuna bağlıdır.
Fast clone için neden XFS reflink zorunlu tutuluyor?
Reflink, sentetik tam yedeklerin değişmeyen blokları kopyalamak yerine mevcut blokları referansla paylaşmasını sağlar. Bu hem sentetik tam yedek süresini kısaltır hem de uzun süre kilitli kalan zincirlerin kapasite tüketimini düşürür. Reflink dosya sistemi oluşturulurken açılmalıdır; sonradan eklenemez.
- Teknoloji
- Veeam Backup & Replication, Linux, XFS reflink, chattr/lsattr, ufw, chrony
- Konu
- Sertleştirilmiş Linux yedek deposunun kurulumu ve sıkılaştırılması
- Seviye
- Orta–ileri
- Ön koşullar
- Çalışan bir Veeam Backup & Replication kurulumu
- Temel Linux yönetim bilgisi
- Depo için ayrılmış fiziksel sunucu
Veri ve Yedekleme