Snapshot ile Ransomware Koruması: Fidye Yazılımlarına Karşı Anlık Yedekleme Stratejileri

Tarafındankomut
0 Comments

Ransomware saldırıları artık sadece büyük şirketlerin değil, küçük işletmelerin ve hatta bireysel sistem yöneticilerinin de kabusuna girdi. Bir sabah işe geliyorsunuz, ekranınızda şifreli dosyalar ve bir fidye notu var. Bu noktada elinizde ne var? Eğer düzgün bir snapshot stratejiniz yoksa, cevap muhtemelen “hiçbir şey” oluyor. Bu yazıda snapshot teknolojisini ransomware koruması için nasıl kullanabileceğinizi, hangi tuzaklara düşmemeniz gerektiğini ve gerçek senaryolarda nasıl hayatta kalabileceğinizi anlatacağım.

Snapshot Nedir ve Ransomware’e Karşı Neden İşe Yarar?

Snapshot, bir sistemin veya diskin belirli bir andaki durumunun anlık fotoğrafıdır. Klasik yedeklemeden farkı şu: snapshot alındığında veri kopyalanmaz, sadece o anki blok haritası kaydedilir. Değişiklikler Copy-on-Write (CoW) mekanizmasıyla ayrı bir alanda tutulur. Bu yüzden snapshot almak genellikle saniyeler içinde tamamlanır.

Ransomware genellikle şu şekilde çalışır: sisteminize sızar, dosyalarınızı şifreler, orijinal dosyaları siler veya üstüne yazar. Eğer snapshot’larınız varsa ve saldırgan bunlara erişemediyse, sistemi birkaç dakika içinde temiz bir noktaya döndürebilirsiniz. Fidye ödemenize gerek kalmaz.

Ama burada kritik bir nokta var: snapshot tek başına yeterli değildir. Yanlış yapılandırılmış snapshot stratejisi sizi yanlış bir güvenlik hissiyle avutabilir. Gelin doğru nasıl yapılır, detaylıca bakalım.

ZFS Snapshot ile Temel Koruma

ZFS, snapshot konusunda en güçlü araçlardan birini sunar. Linux’ta OpenZFS ile çalışıyorsanız şu komutlarla başlayabilirsiniz:

# ZFS pool durumunu kontrol et
zpool status

# Manuel snapshot al
zfs snapshot tank/data@2024-01-15_manuel

# Tüm snapshot'ları listele
zfs list -t snapshot

# Snapshot boyutlarını göster
zfs list -t snapshot -o name,used,refer,creation

Otomatik snapshot için en yaygın kullanılan araç zfs-auto-snapshot‘tır:

# Ubuntu/Debian'da kur
apt install zfs-auto-snapshot

# Her 15 dakikada bir snapshot
zfs set com.sun:auto-snapshot=true tank/data
zfs set com.sun:auto-snapshot:frequent=true tank/data

# Cron ile özelleştirme
# /etc/cron.d/zfs-auto-snapshot dosyasını düzenle
*/15 * * * * root /usr/sbin/zfs-auto-snapshot -q -g --label=frequent --keep=4 //
0 * * * * root /usr/sbin/zfs-auto-snapshot -q -g --label=hourly --keep=24 //
0 0 * * * root /usr/sbin/zfs-auto-snapshot -q -g --label=daily --keep=31 //

Ransomware saldırısı durumunda geri dönmek:

# Hangi snapshot'ın temiz olduğunu kontrol et
zfs list -t snapshot -o name,creation tank/data

# Snapshot'a geri dön (dikkat: mevcut veriyi kaybedersiniz)
zfs rollback tank/data@2024-01-14_daily

# Alternatif: Snapshot'ı ayrı bir dizine mountla, dosyaları seçerek kurtarın
zfs clone tank/data@2024-01-14_daily tank/data_recovery
zfs set mountpoint=/mnt/recovery tank/data_recovery

LVM Snapshot: Çoğu Linux Sisteminde Hazır Geliyor

ZFS kullanmıyorsanız LVM snapshot büyük ihtimalle zaten elinizin altında. Production ortamda çok sık gözardı edilen bu özellik, kurumsal ortamlarda hayat kurtarır.

# Mevcut LVM yapısını gör
lvdisplay
vgdisplay

# /dev/vg0/data için snapshot al (%10 boyutunda başlangıç alanı)
lvcreate -L 10G -s -n data_snap_20240115 /dev/vg0/data

# Snapshot'ı mount et ve kontrol et
mkdir /mnt/snap_test
mount -o ro /dev/vg0/data_snap_20240115 /mnt/snap_test
ls /mnt/snap_test

# Snapshot doluluk oranını izle (100%'e ulaşırsa geçersiz olur!)
lvs -o name,lv_size,data_percent /dev/vg0/data_snap_20240115

LVM snapshot konusunda çok önemli bir uyarı: snapshot alanı dolduğunda snapshot otomatik olarak geçersiz hale gelir ve kurtarma şansınız sıfıra düşer. Bu yüzden snapshot boyutunu cömertçe belirleyin veya lvextend ile dinamik olarak büyütün:

# Snapshot dolmadan önce büyüt
lvextend -L +5G /dev/vg0/data_snap_20240115

# Geri yükleme işlemi (önce unmount edin)
umount /dev/vg0/data
lvconvert --merge /dev/vg0/data_snap_20240115
# Merge işlemi için sistemi yeniden başlatın veya
lvchange -a n /dev/vg0/data
lvchange -a y /dev/vg0/data

Btrfs Snapshot: Modern Linux Sistemler İçin

Btrfs kullanan sistemlerde (Fedora, openSUSE, bazı Ubuntu kurulumları) snapshot yönetimi için snapper aracını kullanabilirsiniz. Snapper, snapshot’ları otomatik olarak alır ve zaman bazlı temizlik yapar.

# Snapper kurulumu ve yapılandırma
apt install snapper
snapper -c root create-config /

# Mevcut konfigürasyonu görüntüle
snapper -c root get-config

# Manuel snapshot al
snapper -c root create --description "temiz_sistem_20240115"

# Snapshot listesi
snapper -c root list

# İki snapshot arasındaki farkı gör (ransomware sonrası çok kullanışlı)
snapper -c root diff 5..6

# Belirli bir snapshot'a dön
snapper -c root undochange 6..0

Snapper’ın en güzel özelliği, değişen dosyaları diff olarak gösterebilmesi. Ransomware saldırısı sonrasında hangi dosyaların şifrelendiğini tespit etmek için:

# Son iki snapshot arasında değişen tüm dosyaları listele
snapper -c root status 5..6 | grep "^c" | head -50

# Sadece belirli bir dizindeki değişiklikleri gör
snapper -c root diff 5..6 /var/www

Immutable Snapshot Stratejisi: Saldırgan Erişemez Hale Getirme

Klasik snapshot’ların büyük açığı şu: eğer saldırgan root erişimi aldıysa, snapshot’ları da silebilir. Bu yüzden immutable (değiştirilemez) snapshot stratejisi kritik önem taşır.

ZFS’te Snapshot Koruma

# Snapshot'ı silinmeden koruma altına al
zfs hold ransomware_protection tank/data@2024-01-15_critical

# Hold listesini gör
zfs holds tank/data@2024-01-15_critical

# Hold varken silmeye çalışırsan hata alırsın
# Hold kaldırmadan snapshot silinemez
zfs release ransomware_protection tank/data@2024-01-15_critical

Uzak Snapshot Replikasyonu

En güvenli yöntem, snapshot’ları ağdan izole edilmiş başka bir sisteme göndermek. Saldırgan birinci sisteme tam erişim sağlasa bile ikinci sisteme ulaşamazsa verileriniz güvende.

# ZFS send/receive ile uzak sisteme gönder
# İlk tam gönderim
zfs send tank/data@2024-01-15_base | 
  ssh backup-server "zfs receive backup_pool/data"

# Sonraki artımlı gönderimlerde
zfs send -i tank/data@2024-01-14_daily tank/data@2024-01-15_daily | 
  ssh backup-server "zfs receive backup_pool/data"

# Cron ile otomatikleştir (gece 2'de)
# /etc/cron.d/zfs-remote-backup
0 2 * * * root /usr/local/bin/zfs_remote_backup.sh >> /var/log/zfs_backup.log 2>&1

Backup sunucusunda ise snapshot’ların silinmesini kısıtlamak için:

# Backup sunucusunda sadece receive izni ver, delete izni verme
# ZFS delegation ile
zfs allow -u backupuser receive,create,mount backup_pool/data

# backupuser'ın destroy yetkisi OLMAMALI
# Bu sayede saldırgan backup'a yazsa bile silemez

Pratik Senaryo: Üretim Sunucusunda Ransomware Tespiti ve Kurtarma

Diyelim ki bir sabah web sunucunuzda dosyalar .locked uzantısıyla şifrelenmiş. Panik yapmadan adım adım ilerleyelim.

Adım 1: Sistemi İzole Et

# Önce ağ bağlantısını kes, yayılmayı durdur
iptables -I INPUT -j DROP
iptables -I OUTPUT -j DROP

# Veya daha hızlı
ip link set eth0 down

# Çalışan şüpheli süreçleri bul
ps auxf | grep -v grep | grep -E ".sh|python|perl|curl|wget" 
lsof -i | grep ESTABLISHED

Adım 2: Snapshot Durumunu Kontrol Et

# ZFS snapshot'lar sağlam mı?
zfs list -t snapshot -o name,creation,used | grep "^tank/data"

# Son temiz snapshot'ı belirle (şifreleme öncesi)
# Dosyaların creation timestamp'ine bak
stat /var/www/html/index.php.locked

# Bu timestamp'ten önceki son snapshot'ı bul
zfs list -t snapshot tank/data | awk '{print $1, $5}' | sort -k2

Adım 3: Kurtarma Öncesi Forensic Kopyası Al

# Delil için mevcut durumu koru (isteğe bağlı ama tavsiye edilir)
zfs snapshot tank/data@infected_20240115_forensic

# Ya da LVM ile
lvcreate -L 50G -s -n forensic_snapshot /dev/vg0/data

Adım 4: Geri Yükleme

# ZFS rollback ile geri dön
# -r parametresi daha yeni snapshot'ları siler
zfs rollback -r tank/data@2024-01-14_daily

# Geri yükleme sonrası dosya bütünlüğünü kontrol et
find /var/www -name "*.locked" | wc -l
# Sıfır çıkmalı

# Web servisini yeniden başlat
systemctl start nginx
systemctl start php8.1-fpm

Windows Ortamı: VSS ve Hyper-V Snapshot

Windows sunucular için Volume Shadow Copy Service (VSS) ve Hyper-V checkpoint’leri benzer imkanlar sunar. Ama burada kritik bir sorun var: modern ransomware’lerin büyük çoğunluğu ilk iş olarak VSS kopyalarını siler. Bu yüzden Windows ortamında snapshot koruması daha da kritik hale geliyor.

# Mevcut VSS kopyalarını listele
vssadmin list shadows

# VSS kopyası oluştur
$vss = (Get-WmiObject -List Win32_ShadowCopy).Create("C:","ClientAccessible")

# PowerShell ile düzenli VSS snapshot - Task Scheduler'a ekle
$action = New-ScheduledTaskAction -Execute "vssadmin" -Argument "create shadow /for=C:"
$trigger = New-ScheduledTaskTrigger -Daily -At "02:00"
Register-ScheduledTask -TaskName "DailyVSSSnapshot" -Action $action -Trigger $trigger -RunLevel Highest

# VSS korumasını güçlendirmek için storage'ı ayır
# Ayrı volume'da VSS snapshot'ı sakla
vssadmin resize shadowstorage /for=C: /on=D: /maxsize=50GB

VSS’yi ransomware’den korumak için en etkili yöntem, VSS komutlarını kısıtlamak:

# Sadece administratorların VSS silebilmesi için
# Group Policy: Computer Configuration > Windows Settings > 
# Security Settings > Local Policies > User Rights Assignment
# "Manage auditing and security log" yetkisini kısıtla

# Wmic ve vssadmin komutlarını izle
# Windows Defender ile vssadmin.exe'yi izle
Add-MpPreference -AttackSurfaceReductionRules_Ids "9e6c4e1f-7d60-472f-ba1a-a39ef669e4b0" `
                 -AttackSurfaceReductionRules_Actions Enabled

Monitoring: Snapshot’ların Sağlığını İzleme

Snapshot almak yetmez, düzenli olarak çalıştığını ve gerektiğinde geri döndürebildiğinizi test etmeniz gerekir. Bunun için basit bir monitoring scripti:

#!/bin/bash
# /usr/local/bin/snapshot_health_check.sh

ALERT_EMAIL="[email protected]"
MIN_SNAPSHOT_COUNT=3
DATASET="tank/data"

# Snapshot sayısını kontrol et
SNAP_COUNT=$(zfs list -t snapshot -o name $DATASET 2>/dev/null | grep -c "^$DATASET@")

if [ "$SNAP_COUNT" -lt "$MIN_SNAPSHOT_COUNT" ]; then
    echo "UYARI: $DATASET için sadece $SNAP_COUNT snapshot mevcut!" | 
    mail -s "[KRITIK] Snapshot Sayisi Dusuk - $(hostname)" $ALERT_EMAIL
fi

# En son snapshot yaşını kontrol et (24 saatten eskiyse alarm)
LATEST_SNAP=$(zfs list -t snapshot -o name,creation $DATASET | 
              sort -k2 | tail -1)
SNAP_DATE=$(echo $LATEST_SNAP | awk '{print $2, $3, $4, $5}')
SNAP_EPOCH=$(date -d "$SNAP_DATE" +%s 2>/dev/null)
NOW_EPOCH=$(date +%s)
AGE_HOURS=$(( (NOW_EPOCH - SNAP_EPOCH) / 3600 ))

if [ "$AGE_HOURS" -gt 24 ]; then
    echo "UYARI: Son snapshot $AGE_HOURS saat önce alındı!" | 
    mail -s "[UYARI] Snapshot Eskidi - $(hostname)" $ALERT_EMAIL
fi

echo "$(date): Snapshot kontrolü tamamlandı. Toplam: $SNAP_COUNT, Son: $AGE_HOURS saat önce" 
     >> /var/log/snapshot_health.log
# Bu scripti cron'a ekle
chmod +x /usr/local/bin/snapshot_health_check.sh
echo "0 */6 * * * root /usr/local/bin/snapshot_health_check.sh" > /etc/cron.d/snapshot-health

3-2-1-1 Kuralı: Modern Ransomware İçin Güncellenmiş Yaklaşım

Klasik 3-2-1 kuralını biliyorsunuzdur: 3 kopya, 2 farklı medya, 1 offsite. Ransomware çağında buna 1 tane daha ekledik: 1 adet immutable (değiştirilemez) kopya.

Pratikte bu nasıl görünür:

  • Kopya 1: Production sistemdeki ZFS/LVM snapshot’lar (hızlı kurtarma için)
  • Kopya 2: Yerel backup sunucusunda günlük snapshot replikasyonu
  • Kopya 3: Farklı lokasyonda veya bulutta offsite backup
  • Kopya 4 (Immutable): Object Lock aktif S3 bucket’ı veya WORM storage

S3 ile immutable backup için:

# AWS CLI ile Object Lock'lu bucket oluştur
aws s3api create-bucket --bucket sirket-immutable-backup 
    --region eu-central-1 
    --create-bucket-configuration LocationConstraint=eu-central-1

# Object Lock aktifleştir
aws s3api put-object-lock-configuration 
    --bucket sirket-immutable-backup 
    --object-lock-configuration 
    '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

# ZFS snapshot'ı S3'e gönder
zfs send tank/data@2024-01-15_daily | 
    gzip | 
    aws s3 cp - s3://sirket-immutable-backup/zfs/data_20240115.zfs.gz

Sık Yapılan Hatalar ve Tuzaklar

Yıllarca snapshot yönetimi yapan biri olarak en çok gördüğüm hataları paylaşayım:

  • Snapshot’ı aynı storage’da tutmak: Saldırgan storage’a erişirse hem production hem snapshot’lar gider. Hep offsite replikasyon zorunlu.
  • Test etmemek: Ayda bir snapshot’tan gerçek geri yükleme testi yapın. Pek çok ekip yıllarca snapshot aldı, pas günü geldiğinde restore edemedi.
  • Snapshot aralığını çok uzun tutmak: Günde bir snapshot, 8 saatlik veri kaybı demek. RPO gereksinimlerinize göre ayarlayın.
  • Ağ erişimini kısıtlamamak: Backup sunucusuna sadece tek yönlü yazma erişimi verin. Backup sunucusundan production’a SSH açmayın.
  • Monitoring yapmamak: Snapshot cron’u sessizce başarısız olabilir. Yukarıdaki gibi düzenli health check şart.
  • Snapshot’ı yeterince saklamamak: 7 günlük snapshot yeterli gibi görünür ama ransomware bazen sistemde haftalarca bekler. En az 30-90 günlük snapshot zinciri hedefleyin.

Sonuç

Ransomware korumasında snapshot, kalkanınızın en önemli katmanlarından biri. Ama sadece “snapshot alıyorum” demek yetmez. Doğru araç seçimi (ZFS, LVM, Btrfs), immutable kopya stratejisi, offsite replikasyon, düzenli test ve monitoring bir arada çalışmalı.

En önemli mesaj şu: restore etmediğiniz backup, backup değildir. Her ay, tercihen daha sık, gerçek bir restore testi yapın. Bunu bir tatbikat gibi düşünün. Gerçek kriz anında panik yapmak yerine kas hafızanıza güvenin.

Snapshot stratejinizi bugün gözden geçirin. Immutable kopyanız var mı? Backup sunucunuza production’dan tek yönlü erişim mi var, yoksa çift yönlü mü? Son restore testiniz ne zaman? Bu soruların cevapları net değilse, bir sonraki ransomware dalgasında kendinizi zor durumda bulabilirsiniz. Şimdi hazırlanmak, o fidye notunu görme ihtimalini dramatik şekilde düşürür.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir