Merhaba arkadaşlar,

Bugün sabah birçok vmware sunucusunda yaşanan sorunla alakalı genel bi bilgilendirme yapmak istedim. Sektörde geçmiştede yaşadığımız tecrübeler neticesinde aşağıdaki yol haritasını uygulayarak verilerinizi büyük oranda kurtarabilirsiniz.

Şuanda aktif olarak bir firmanın verilerini %90 oranda kurtardık ancak tek başıma herkese destek olamayacağım için nasıl yaptığımız aşağıda anlatıyorum.

Profesyonel destek almak isteyenler ulaşabilir yardımcı olmaya çalışırım. Aşağıya temizlik için örnek bir .py kodum kontrol edip çalıştırabilirsiniz.

https://drive.google.com/file/d/1LIS...ew?usp=sharing bu linkteki script benzeri bir script ile sunucu içerisinde temizlik yapın.

Panikle yapılan hatalar kurtarma şansını yok ediyor. Sırasıyla:

Ödeme yapmayın, saldırganla iletişime geçmeyin (en azından hukuki danışman devreye girmeden)
Datastore'a hiçbir şey yazmayın. Yeni VM oluşturma, dosya kopyalama, log yazma - hepsi kurtarılabilir alanın üstüne biner
Dosyaları rename etmeyin. .babyk uzantısını silmek hiçbir şeyi çözmez
Hâlâ çalışan VM varsa kapatmayın. İçindeki veriyi guest'ten dışarı kopyalamak mümkün olabilir; kapattığınız anda o şans biter
Host'u yeniden başlatmayın. Bellekte kalan bilgiler kaybolur

Bu kısım kritik: şifreleme bitmiş olsa bile saldırının altyapısı hâlâ çalışıyor olabilir.

Bizde /var/run/run.sh adında bir script vardı ve cron'a bağlanmıştı:

*/10 * * * * /bin/sh /var/run/run.sh >/dev/null 2>&1

Yani her 10 dakikada bir tetikleniyordu. Kontrol ettiğimizde dört kopya aynı anda çalışıyordu, hepsi sleep aşamasında bekliyordu.

Script'in yaptıkları:

esxcli system settings advanced set -o /User/execInstalledOnly -i 0 - ESXi'ın imzasız binary çalıştırma korumasını kapatıyor
/var/run/backup adlı binary'yi (asıl şifreleyici, "backup" adı verilmiş) çalıştırılabilir yapıyor
Tüm VM'leri zorla öldürüyor (vCenter hariç - onu ayakta tutuyor ki kurban durumu görebilsin)
Şifreleyiciyi /vmfs/volumes/ üzerine salıyor
esxcli system welcomemsg set ile giriş banner'ını fidye notuyla değiştiriyor
esxcli software vib remove -n vmware-fdm ile HA'yı devre dışı bırakıyor
Döngü halinde tekrar tekrar VM öldürüp şifreliyor

Bunları temizlemeden hiçbir kurtarma işlemine başlamayın. Aksi halde kurtardığınız veri ikinci kez şifrelenir.

Kurtarma stratejisi:

Şifreleyici hız için diski blok blok atlayarak şifreliyor. Ne kadarının vurulduğunu ölçmek için entropi analizi yaptım - dosyayı belirli aralıklarla örnekleyip Shannon entropisi hesaplayan basit bir Python scripti yeterli.

Bizim sonuçlarımız

Farklı VM'lerde şifreli oran:

VM Boyut Şifreli
A 160 GB %1.7
B 50 GB %3.2
C 100 GB %5.7
D 40 GB %6.2
E 250 GB %12.9

AG kontrolü nasıl yapılır

Önce ilk iki XFS superblock'un offsetini bulun (magic: XFSB, sektör hizalı). Aralarındaki fark AG boyutudur. Sonra basit bir döngüyle hepsini kontrol edin:

python
base = ILK_XFS_OFFSET
agsz = IKINCI_OFFSET - ILK_OFFSET
agn = AG_SAYISI # superblock'tan okunur

f = open(imaj, 'rb')
ok = 0
for n in range(agn):
f.seek(base + n * agsz)
if f.read(4) == b'XFSB':
ok += 1
print(f'Saglam: {ok}/{agn}')

Kabaca %70'i sağlamsa xfs_repair işi görür.

İmajı çıkarma

ESXi'da kurtarma araçları yok. Ham imajı bir Linux makineye almak gerekiyor:


ssh -C root@ESXI_IP "cat '/vmfs/volumes/DATASTORE/VM/VM-flat.vmdk.babyk'" > vm.raw

Not: ESXi'ın SSH'ında PasswordAuthentication no varsayılan geliyor ve eski sshd sürümü ed25519 anahtarlarını tanımıyor. RSA kullanın:


ssh-keygen -t rsa -b 4096
# public key'i ESXi'da /etc/ssh/keys-root/authorized_keys içine tek satır olarak yazın

Babuk footer'ını kırpın

truncate -s GERCEK_BOYUT vm.raw # sondaki 32 baytı at
Orijinale yazmadan çalışın

xfs_repair yıkıcı bir işlem. Device-mapper snapshot ile koruma katmanı kurun:

LOOP=$(losetup -r -f --show vm.raw)
truncate -s 40G cow.img
COW=$(losetup -f --show cow.img)
SZ=$(blockdev --getsz $LOOP)
echo "0 $SZ snapshot $LOOP $COW P 8" | dmsetup create rec

Artık /dev/mapper/rec yazılabilir, vm.raw dokunulmaz. Ters giderse:

dmsetup remove rec && rm cow.img

Bölüm tablosunu geri getirin

gdisk /dev/mapper/rec
# r → recovery menüsü
# b → yedek GPT'yi birincil yap
# w → yaz
LVM ve dosya sistemi

kpartx -av /dev/mapper/rec
pvscan --cache && vgscan && vgchange -ay
lvs

xfs_repair -n /dev/VG/root 2>&1 | tee repair_dry.log # önce kuru
xfs_repair -L /dev/VG/root 2>&1 | tee repair.log # sonra gerçek

mkdir -p /mnt/rec
mount -o ro,norecovery /dev/VG/root /mnt/rec

repair_dry.log dosyasını saklayın - hangi inode'ların bozuk olduğunu listeler, yani "hangi dosyalar gitti" listesi odur.

Veriyi çıkarın

rsync -av --info=progress2 /mnt/rec/home/ /kurtarilan/home/
rsync -av --info=progress2 /mnt/rec/var/lib/mysql/ /kurtarilan/mysql/
rsync -av --info=progress2 /mnt/rec/etc/ /kurtarilan/etc/

Okuma hatası veren dosyalar şifreli bloklara denk gelenlerdir.

Umarım herkes olabildiğince az zarar ile atlatır. Geçmiş olsun dileklerimle..