Bu yazı, VMware’in Siber Güvenlik Farkındalık Ayı serisinin 22 bölümünden 12.’sinin Türkçe özeti. Konu: VM snapshot’ları.
Snapshot’lar, VMware Cloud Foundation’ın (VCF) belki de en hafife alınan güvenlik aracı. Bir hafta içi öğleden sonra misafir işletim sistemini nefesinizi tutmadan yamalayabilmenizin, ele geçirilmiş bir sistemin kanıtlarını kimse dokunmadan koruyabilmenizin ve vSAN data protection ile her şeyi silmiş bir fidye yazılımına karşı son savunma hattına sahip olmanızın nedeni onlar.
Ama yanlış da anlaşılıyorlar. VM snapshot’ları yedek değil; eski tip VMFS ve SparseSE snapshot’ları birikirse performansı düşürebiliyor; üstelik asıl veri kadar korunması gereken veri kopyaları tutuyorlar. Doğru kullanıldıklarında ise gerçekten en iyi dostunuz olabiliyorlar.
VM snapshot’ı neyi yakalar
Bir snapshot, sanal makinenin belirli bir andaki durumunu korur: ayarlarını, güç durumunu, disklerinin içeriğini ve isterseniz belleğinin içeriğini. Geleneksel VM snapshot’ları orijinal sanal diski dondurur ve yeni yazmaları bir delta diske yönlendirir; yani snapshot aslında dondurulmuş bir taban üzerine dizilmiş bir değişiklik zinciridir. Geri dönmek (revert) bu değişiklikleri atar, snapshot’ı silmek ise onları tabana geri birleştirir; buna consolidation denir.
vSAN Express Storage Architecture (ESA) farklı bir yaklaşım kullanıyor. Yerel snapshot’ları delta disk zincirleri yerine log yapılı bir tasarıma dayanıyor; bu da oluşturma ve silmeyi çok daha hızlı yapıyor ve snapshot varken performansı daha istikrarlı tutuyor (ayrıntılar).
Snapshot alırken iki seçim yapıyorsunuz:
- Bellekli ya da belleksiz: Belleği dahil etmek misafir sistemin çalışma durumunu yakalar; geri dönüldüğünde VM tam olarak bıraktığınız gibi çalışır halde gelir. Daha uzun sürer, VM’i kısa süreliğine duraklatabilir ve VM belleği büyüklüğünde bir dosya yazar. Bu özellik, “sadece bellekte yaşayan” saldırıları incelemeye çalışan güvenlik araştırmacıları için de değerli.
- Quiesce edilmiş ya da edilmemiş: Quiesce, VMware Tools’tan misafir sistemin dosya sistemi tamponlarını boşaltmasını ister, böylece diskler tutarlı olur. Windows tarafında bu genellikle VSS’nin çağrılmasını içerir. Ayrıca uygulamaya özel quiesce adımları için pre-freeze ve post-thaw betikleri kullanılabilir; bir yedekleme partnerinin çeşitli uygulama ve veritabanları için örnekleri burada. Bazı yedekleme yazılımları da uygulama farkındalıklı snapshot’tan önce kendi betikleriyle bu süreci kullanıyor.
Değişiklik yapmadan önce snapshot alın
Snapshot’ların en yaygın kullanımı hızlı bir geri dönüş yolu. Misafir işletim sistemini yamalamadan, bir uygulamayı yükseltmeden ya da tam emin olmadığınız bir ayarı değiştirmeden önce snapshot alın. Değişiklik kötü giderse geri dönün; saatler yerine dakikalar içinde başladığınız yere dönersiniz. Bu güvenlik ağı başlı başına bir güvenlik özelliği, çünkü bir şeyleri bozmaktan korkan ekipler daha seyrek yama yapıyor.
VCF de snapshot’ları bu şekilde kullanıyor. VCF 9.0’da fleet management yükseltme iş akışı, destekleyen yönetim bileşenlerinin yükseltmeden önce varsayılan olarak snapshot’ını alıyor (doküman). Bazı kurallar var:
- Her bileşen snapshot’ı desteklemiyor. Broadcom, NSX Manager ya da NSX Edge düğümlerinin snapshot’ını desteklemiyor; cluster kararsızlığına ya da veritabanı bozulmasına yol açabiliyorlar. Bunun yerine NSX dosya tabanlı yedeklerini kullanın (KB 433822).
- Cluster’lı appliance’lar için belgelenmiş prosedürü izleyin. Örneğin VCF Operations çevrimdışı alınmalı ve tüm düğümlerin snapshot’ı birlikte, belleksiz ve quiesce’siz alınmalı (doküman).
- Snapshot’ları kısa süreli geri dönüş için kullanın. Broadcom’un SDDC Manager rehberi snapshot’ların yedek olmadığını ve sadece geçici geri dönüş önlemi olarak kullanılması gerektiğini söylüyor (KB 432552). Yükseltmeden önce gerçek bir yedek de alın.
- İşiniz bitince snapshot’ı silin. Değişiklik sorunsuz olduğu kanıtlandıktan sonra kaldırın; bu zamanlanabilir de.
Delil korumak için VM snapshot’ları
Bir VM’in ele geçirildiğinden şüphelendiğinizde ilk refleks onu kapatmak oluyor. Durumunu yakalayana kadar bu refleksi bastırın. Bellek; çalışan süreçler, ağ bağlantıları, şifreleme anahtarları ve diske hiç dokunmayan zararlı yazılımlar gibi kapatınca kaybolan şeyleri tutuyor. NIST’in adli bilişim rehberi de uzun zamandır önce bu uçucu verinin toplanmasını öneriyor (NIST SP 800-86).
Belleği içeren VM snapshot’ları bunu yapmanın kolay bir yolu. Snapshot, kimse misafir sisteme giriş yapmadan belleği bir dosyaya yazıyor; bu da saldırganı uyarmaktan ya da kendi araçlarınızla kanıtın üzerine yazmaktan kaçınmanızı sağlıyor. Broadcom’un vmss2core aracı, bu bellek dosyasını yaygın bellek adli analiz araçlarının okuyabileceği bir dump’a dönüştürüyor (KB 323788). Snapshot’ı alın, dosyaları güvenli bir yere kopyalayın, sonra VM’i izole etmeye, bağlantısını kesmeye ya da kapatmaya karar verin. VM şifreleme kullanıyorsanız bellek dosyası da şifreli olacağı için müdahale ekibinizin analiz için onu nasıl çözeceğini önceden planlayın.
Son savunma hattı: immutable snapshot’lar
Fidye yazılımı grupları snapshot’ları biliyor ve siliyor. Tehdit araştırmacıları, vSphere’i hedef alan bir grubun herhangi bir şeyi şifrelemeden önce yedekleme işlerini, snapshot’ları ve yedek depolarını sildiğini anlatıyor (rapor). Immutable snapshot’lar tam bu an için var.
VCF’nin parçası olan vSAN data protection, vSAN ESA cluster’larındaki VM’lerin zamanlanmış, crash-consistent snapshot’larını alıyor ve belirlediğiniz saklama politikasına göre VM başına 200 snapshot’a kadar tutuyor (genel bakış). Bir protection group’u immutable olarak işaretlediğinizde snapshot’ları normal yönetim işlemleriyle silinemiyor; saklama süreleri dolunca kendiliğinden kalkıyorlar. Immutability bilerek geri alınması zor tasarlanmış; bir kez açıldığında yönetici Broadcom desteği olmadan kapatamıyor (KB 411539). Immutable snapshot’lar süreleri dolana kadar kapasite kullandığı için saklama sürelerini dikkatli seçin. VCF 9.1 ayrıca kilidi açılmış immutable bir protection group’u işaretleyen bir vSAN sağlık kontrolü ekliyor; bunun için alarm kurmaya değer (KB 450962).
Immutable snapshot’ları kullanmanın en iyi yolu replikasyonla birleştirmek. VMware Live Recovery, immutable snapshot’ları farklı bir vCenter’a ve farklı SSO/kimlik doğrulama kontrolüne sahip ikincil bir cluster’da (muhtemelen daha ucuz QLC flash cihazlarla) tutacak şekilde yapılandırılabiliyor. Sınırları da bilin: yerel vSAN snapshot’ları koruduğu VM’lerle aynı datastore’da duruyor; cluster’ı ya da datastore’u kaybederseniz işe yaramazlar. Onları başka yerde saklanan yedeklerin tamamlayıcısı olarak görün.
Snapshot’ları kısa ömürlü ve korumalı tutun
Geleneksel VMFS ve SparseSE snapshot’ları uzun süre kaldıklarında bir bedel ödetiyor: her yazma bir delta diske gidiyor, zincirler uzuyor ve büyüdükçe consolidation daha uzun sürüyor. Broadcom’un önerisi, 32’ye kadar desteklenmesine rağmen performans için zincirde sadece iki ya da üç snapshot kullanmak ve hiçbir snapshot’ı 72 saatten uzun tutmamak (KB 318825). Unutulmuş bir snapshot vCenter dosya tabanlı yedeklerinin başarısız olmasına bile yol açabiliyor (KB 441880). Bu öneriler vSAN ESA snapshot’ları için geçerli değil; vSAN data protection’da limitler de daha yüksek.
VM snapshot’ları aynı zamanda güvenlik açısından hassas birer varlık:
- Veri içeriyorlar. Bir snapshot VM’in o andaki disk içeriğini, bellek snapshot’ı ise bellekte ne varsa, kimlik bilgileri ve anahtarlar dahil, tutuyor. Datastore erişimini buna göre koruyun.
- Kimin alıp geri döndüğünü kontrol edin. vCenter’da snapshot oluşturma, silme ve geri dönme için ayrı yetkiler var (yetkiler); VM’lerle çalışan çoğu kişinin hepsine ihtiyacı yok.
- Eskimiş snapshot’ları kaldırın. NIST, saldırı yüzeyini azaltmak için eskimiş snapshot ve klonların kaldırılmasını öneriyor (NIST SP 800-209). VCF Operations’ın Reclaim özelliği inceleyip silebileceğiniz snapshot’ları listeliyor (doküman); vCenter’da da snapshot’ları otomatik silen zamanlanmış görev var.
- Domain controller’larda dikkatli olun. Active Directory’nin snapshot geri dönüşleri için korumaları var, ama Microsoft domain controller snapshot’larının yedek yerine kullanılmamasını öneriyor (Microsoft).
Snapshot’ları rutininizin parçası yapın
VM snapshot’ları sonradan akla gelen bir şey olarak değil, planın parçası olarak en iyi sonucu veriyor. Her riskli değişiklikten önce snapshot alın ve değişiklik kanıtlanınca silin. Ele geçirildiğinden şüphelendiğiniz bir VM’i kapatmadan önce belleğini yakalayın. Kaybetmeyi göze alamayacağınız iş yükleri için immutable snapshot’larla vSAN data protection kurun ve bunlardan geri yüklemeyi deneyin. Sonra da fazla uzun kalmış snapshot’ları arayıp bulun.
Yazı, snapshot’ları bir yedekleme aracı olarak değil, bir güvenlik aracı olarak ele alması açısından değerli. Özellikle iki önerinin altını çizmek isterim: şüpheli bir VM’i kapatmadan önce bellekli snapshot almak ve immutable snapshot’ları farklı bir vCenter ve kimlik doğrulama alanındaki ikincil cluster’a replike etmek. İkincisi, saldırganın yönetim katmanını ele geçirdiği senaryolarda gerçek fark yaratıyor. Kaynaktaki görsellerden biri yazarın sayfasında kırık olduğu için bu yazıya eklenemedi.
Kaynak: https://blogs.vmware.com/cloud-foundation/2026/10/16/snapshots-are-your-best-friend/
