Thread Starter
#1
Selam arkadaşlar,
Bir önceki yazıda genel adımları sizlerle paylaşmıştım. Bu sefer kripto uzantılı bir ESXi saldırısından sonraki kurtarma sürecinde yaşadığımız, arayınca kolay bulamayacağınız birkaç tuzağı paylaşmak istiyorum. Komutlarda govc kullandım; her şey API üzerinden çalışıyor, ESXi'de SSH açmanıza gerek kalmıyor.
1. Veri çoğu zaman yerinde duruyor
Bu saldırılar hız kazanmak için büyük disk dosyasının (-flat.vmdk) genellikle sadece bir kısmını şifreliyor. Küçük tanımlayıcı dosyası (.vmdk) ise tamamen şifreleniyor. Şifreli flat dosyasını gösteren yeni bir tanımlayıcı yazdığınızda disk büyük ölçüde geri geliyor. Tanımlayıcıdaki kritik satır şu; sektör sayısını flat dosyasının boyutunu 512'ye bölerek bulabilirsiniz:
2. Datastore tarayıcısı flat dosyalarını göstermiyor
En tehlikeli tuzak bu. Datastore'u listelediğinizde -flat.vmdk ve -sesparse.vmdk dosyaları görünmüyor. Biz de "şifreli dosyaların hiçbiri kullanılmıyor" diye düşünüp hepsini silme listesine almıştık. Son kontrolde listedeki 14 dosyanın çalışan sunucuların asıl veri diskleri olduğu ortaya çıktı. Silmeden önce mutlaka VM'in gerçekte hangi dosyaları kullandığına bakın; diskExtent olarak çıkan dosyalara dokunmayın:
3. Şifreli uzantıyı düzeltmek için VM'i kapatmak şart
Açık bir diskin dosyası kilitli olduğu için VM'i kapatmanız gerekiyor. Kapattıktan sonra flat dosyasının adını değiştirip tanımlayıcıdaki RW satırını güncellemek yetiyor. Bizde sunucu başına kesinti 1 dakika civarında oldu. Snapshot zinciri olan disklerde de aynı yöntem işe yarıyor: Zincirdeki diskler birbirine dosya adıyla değil tanımlayıcı adıyla bağlı olduğu için, her tanımlayıcının RW satırını ayrı ayrı düzeltirseniz zincir bozulmuyor.
4. Ping gitmiyor diye panik yapmayın
Windows Server ICMP'yi varsayılan olarak engelliyor. Sorunun ağda mı yoksa sunucuda mı olduğunu sanal switch'teki port sayaçlarıyla ayırt edebilirsiniz:
Ping atarken gelen paket sayısı artıyor ama giden sayısı artmıyorsa, paketler sunucuya ulaşıyor demektir. Bu durumda ağda bir sorun yok, cevabı Windows'un firewall'u vermiyor.
5. VM'i yeniden kaydetmek yedeklemeyi etkiliyor
vCenter olmayan bir ESXi'de klasör adını değiştirmek için VM'i envanterden çıkarıp tekrar kaydetmeniz gerekiyor. Bu işlem VM'e yeni bir kimlik numarası veriyor ve Veeam işi VM'i bulamıyor. VM'i işe yeniden eklemek gerekiyor, sonraki yedek de tam yedek oluyor. Açılışta ESXi "taşındı mı, kopyalandı mı" diye sorduğunda cevabı mutlaka "taşıdım" olarak verin; yoksa UUID ve MAC adresi değişebilir:
Son bir tavsiye: Yüzlerce dosyayı bir döngüyle iki saniyede silebilirsiniz ama yanlış bir dosyayı geri getirmenin yolu yok. Önce kontrol edin, sonra işlem yapın.
Bir önceki yazıda genel adımları sizlerle paylaşmıştım. Bu sefer kripto uzantılı bir ESXi saldırısından sonraki kurtarma sürecinde yaşadığımız, arayınca kolay bulamayacağınız birkaç tuzağı paylaşmak istiyorum. Komutlarda govc kullandım; her şey API üzerinden çalışıyor, ESXi'de SSH açmanıza gerek kalmıyor.
1. Veri çoğu zaman yerinde duruyor
Bu saldırılar hız kazanmak için büyük disk dosyasının (-flat.vmdk) genellikle sadece bir kısmını şifreliyor. Küçük tanımlayıcı dosyası (.vmdk) ise tamamen şifreleniyor. Şifreli flat dosyasını gösteren yeni bir tanımlayıcı yazdığınızda disk büyük ölçüde geri geliyor. Tanımlayıcıdaki kritik satır şu; sektör sayısını flat dosyasının boyutunu 512'ye bölerek bulabilirsiniz:
RW <sektör_sayısı> VMFS "<flat_dosyası>"2. Datastore tarayıcısı flat dosyalarını göstermiyor
En tehlikeli tuzak bu. Datastore'u listelediğinizde -flat.vmdk ve -sesparse.vmdk dosyaları görünmüyor. Biz de "şifreli dosyaların hiçbiri kullanılmıyor" diye düşünüp hepsini silme listesine almıştık. Son kontrolde listedeki 14 dosyanın çalışan sunucuların asıl veri diskleri olduğu ortaya çıktı. Silmeden önce mutlaka VM'in gerçekte hangi dosyaları kullandığına bakın; diskExtent olarak çıkan dosyalara dokunmayın:
govc vm.info -json "VM" | python3 -c 'import sys,json;d=json.load(sys.stdin);vm=(d.get("virtualMachines") or d.get("VirtualMachines"))[0];[print(f["type"],f["name"]) for f in vm["layoutEx"]["file"]]'
3. Şifreli uzantıyı düzeltmek için VM'i kapatmak şart
Açık bir diskin dosyası kilitli olduğu için VM'i kapatmanız gerekiyor. Kapattıktan sonra flat dosyasının adını değiştirip tanımlayıcıdaki RW satırını güncellemek yetiyor. Bizde sunucu başına kesinti 1 dakika civarında oldu. Snapshot zinciri olan disklerde de aynı yöntem işe yarıyor: Zincirdeki diskler birbirine dosya adıyla değil tanımlayıcı adıyla bağlı olduğu için, her tanımlayıcının RW satırını ayrı ayrı düzeltirseniz zincir bozulmuyor.
govc vm.power -s "VM"
govc datastore.mv -ds "$DS" "KLASOR/X-flat.vmdk.crYptA2" "KLASOR/X-kurtarma-flat.vmdk"
govc datastore.upload -ds "$DS" yeni.vmdk "KLASOR/X-kurtarma.vmdk"
govc vm.power -on "VM"4. Ping gitmiyor diye panik yapmayın
Windows Server ICMP'yi varsayılan olarak engelliyor. Sorunun ağda mı yoksa sunucuda mı olduğunu sanal switch'teki port sayaçlarıyla ayırt edebilirsiniz:
govc host.esxcli network vm list
govc host.esxcli network vm port list -w <WORLD_ID>
govc host.esxcli network port stats get -p <PORT_ID>Ping atarken gelen paket sayısı artıyor ama giden sayısı artmıyorsa, paketler sunucuya ulaşıyor demektir. Bu durumda ağda bir sorun yok, cevabı Windows'un firewall'u vermiyor.
5. VM'i yeniden kaydetmek yedeklemeyi etkiliyor
vCenter olmayan bir ESXi'de klasör adını değiştirmek için VM'i envanterden çıkarıp tekrar kaydetmeniz gerekiyor. Bu işlem VM'e yeni bir kimlik numarası veriyor ve Veeam işi VM'i bulamıyor. VM'i işe yeniden eklemek gerekiyor, sonraki yedek de tam yedek oluyor. Açılışta ESXi "taşındı mı, kopyalandı mı" diye sorduğunda cevabı mutlaka "taşıdım" olarak verin; yoksa UUID ve MAC adresi değişebilir:
govc vm.question -vm "VM" -answer 1Son bir tavsiye: Yüzlerce dosyayı bir döngüyle iki saniyede silebilirsiniz ama yanlış bir dosyayı geri getirmenin yolu yok. Önce kontrol edin, sonra işlem yapın.
