Ransomware Saldırısı Sonrası Kurtarma Planı

Tarafındankomut
0 Comments

Sabah 07:30’da ofise giriyorsunuz, kahvenizi masanıza koyuyorsunuz ve ekrana bakıyorsunuz. Her şey kırmızı. Sunucularınızda dosya uzantıları değişmiş, her klasörde “HOW_TO_DECRYPT.txt” dosyaları var ve ağınızdaki makinelerin yarısı yanıt vermiyor. Tebrikler, bir ransomware saldırısıyla karşı karşıyasınız.

Bu senaryoyu yaşayan onlarca sysadmin’le konuştum. Kimisi panikleyerek yanlış adımlar attı ve durumu daha da kötüleştirdi, kimisi sakin kalarak sistematik bir şekilde kurtarma sürecini yönetti. Aradaki fark her zaman tek şeydi: önceden hazırlanmış ve test edilmiş bir kurtarma planı.

Bu yazıda, ransomware sonrası kurtarma sürecinin her adımını, gerçek komutlarla ve gerçek senaryolarla ele alacağım.

İlk Anlar: Paniklemeden Önce Yapmanız Gerekenler

Ransomware saldırısını fark ettiğiniz ilk dakikalarda adrenalin devreye girer ve insanlar genellikle birini aramak ya da “belki şifreyi çözebiliriz” diye Google’a gitmek ister. İkisi de yanlış. İlk 15 dakika kritik.

Sistemi İzole Edin

İlk ve en önemli adım, etkilenen sistemleri ağdan koparmaktır. Ransomware yayılmaya devam ediyor olabilir.

# Etkilenen Linux sunucusunu ağdan izole et
# Tüm ağ arayüzlerini kapat (lo hariç)
for iface in $(ip link show | grep -v lo | grep 'state UP' | awk -F: '{print $2}' | tr -d ' '); do
    ip link set $iface down
    echo "$(date): $iface kapatıldı" >> /var/log/incident_response.log
done

# Alternatif olarak iptables ile tüm trafiği kes ama loglama devam etsin
iptables -I INPUT 1 -j DROP
iptables -I OUTPUT 1 -j DROP
iptables -I FORWARD 1 -j DROP

Windows tarafında PowerShell ile:

# Tüm ağ adaptörlerini devre dışı bırak
Get-NetAdapter | Where-Object {$_.Status -eq "Up"} | Disable-NetAdapter -Confirm:$false

# Etkilenen makinelerin listesini kaydet
$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm"
Get-ADComputer -Filter {Enabled -eq $true} | 
    Select-Object Name, DistinguishedName | 
    Export-Csv "C:IRaffected_systems_$timestamp.csv" -NoTypeInformation

Olayı Belgeleyin

Sistemi izole ettikten sonra her şeyi kayıt altına alın. Sigorta şirketi, yetkililer veya post-mortem analiz için bu kayıtlar altın değerinde olacak.

# Olay başlangıç belgesi oluştur
mkdir -p /tmp/incident_$(date +%Y%m%d)
cd /tmp/incident_$(date +%Y%m%d)

# Sistem durumu snapshot'ı al
date > incident_start.txt
hostname >> incident_start.txt
uptime >> incident_start.txt
who >> incident_start.txt
last -20 >> incident_start.txt
ps aux >> running_processes.txt
netstat -tulpn >> network_connections.txt
ss -tulpn >> socket_connections.txt

# Şüpheli dosyaları listele (son 24 saatte değişenler)
find / -newer /var/log/lastlog -not -path "/proc/*" 
    -not -path "/sys/*" -ls 2>/dev/null > recently_modified_files.txt

echo "Belgeleme tamamlandı: $(date)" >> incident_start.txt

Kapsamı Belirleme: Ne Kadarı Etkilendi?

İzolasyon tamamlandıktan sonra saldırının kapsamını anlamanız gerekiyor. Bu adımı atlayanlar, kurtarma sırasında süpriz sürprizlerle karşılaşıyor.

Etkilenen Sistemleri Tespit Edin

# Ağ taraması ile yanıt vermeyen veya anormal davranış gösteren sistemleri bul
# Bu taramayı izole bir management ağından yapın
nmap -sn 192.168.1.0/24 -oN /tmp/network_scan_$(date +%Y%m%d).txt

# Ransomware'in bıraktığı karakteristik dosyaları ara
# Örnek: LockBit için *.lockbit, REvil için *.revil uzantıları
find /mnt/shares -name "*.locked" -o 
    -name "*.encrypted" -o 
    -name "HOW_TO_DECRYPT*" 
    -o -name "README_FOR_DECRYPT*" 2>/dev/null | 
    tee /tmp/ransomware_files.txt | wc -l

Yedek Sistemlerin Sağlığını Kontrol Edin

Kurtarmanın temeli yedekleriniz. Ama önce yedeklerin de etkilenip etkilenmediğini doğrulamanız şart. Bir çok ransomware, shadow copy’leri ve yedek sunucularını hedef alır.

# Veeam yedek sunucusuna bağlanarak son yedeklerin durumunu kontrol et
# Bu adımı izole management ağından yapın
veeam -c list backups

# Restic ile yedek bütünlüğünü doğrula
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/backup-bucket"
export RESTIC_PASSWORD="backup_password"

restic check --read-data-subset=10%
restic snapshots --last 10

# Bareos ile son job'ların durumuna bak
echo "list jobs last=10 joberrors" | bconsole

Windows VSS shadow copy durumu:

# Shadow copy'lerin hala var olup olmadığını kontrol et
Get-WmiObject Win32_ShadowCopy | 
    Select-Object InstallDate, VolumeName, ID | 
    Sort-Object InstallDate -Descending

# Eğer shadow copy'ler silindiyse bu ransomware'in bir işareti
# REvil ve LockBit genellikle şunu çalıştırır:
# vssadmin delete shadows /all /quiet

Kurtarma Stratejisi Seçimi

Kapsamı belirledikten sonra hangi stratejiyle devam edeceğinize karar vermeniz gerekiyor. Birkaç seçeneğiniz var:

  • Tam sistem yedeğinden geri yükleme: En temiz yöntem, en uzun süren
  • Dosya düzeyinde geri yükleme: Belirli verileri kurtarmak için
  • Sıfırdan kurulum + veri geri yükleme: OS etkilendiyse tercih edilmeli
  • Şifre çözme: Nadiren mümkün, ama kontrol edilmeli

Önemli not: Fidye ödemeyi düşünüyorsanız, bu kararı tek başınıza vermeyin. Hukuki, sigorta ve yönetim ekibini dahil edin.

Şifre Çözme Seçeneğini Kontrol Edin

# No More Ransom projesi veritabanını kontrol et
# Önce ransomware türünü tespit et
# Şifreli dosyadan örnek al
sha256sum /path/to/encrypted_file.locked

# ID Ransomware servisi için örnek gönder (çevrimiçi)
# https://id-ransomware.malwarehunterteam.com/
# Veya yerel analiz için strings komutunu kullan
strings /path/to/ransomware_binary | grep -iE "email|contact|decrypt"

Temiz Ortam Hazırlama

Asla etkilenen sistemler üzerine doğrudan geri yükleme yapmayın. Temiz bir ortam hazırlayın.

Yeni Sunucu Altyapısını Hızlıca Ayağa Kaldırın

# Terraform ile acil durum altyapısı deploy et
# Bu şablonu önceden hazır tutmanız gerekiyor
terraform init -backend-config="bucket=emergency-tfstate"
terraform plan -var="environment=disaster_recovery" -out=dr_plan.tfplan
terraform apply dr_plan.tfplan

# Ansible ile temel güvenlik yapılandırmasını uygula
ansible-playbook -i inventory/dr_hosts 
    --vault-password-file ~/.vault_pass 
    playbooks/base_hardening.yml 
    playbooks/monitoring_setup.yml

Ağ Segmentasyonu Uygulayın

# Kurtarma ortamı için izole VLAN oluştur
# Bu komutlar Cisco switch üzerinde (expect script ile)
cat << 'EOF' > /tmp/vlan_setup.expect
#!/usr/bin/expect
spawn ssh [email protected]
expect "Password:"
send "your_passwordn"
expect "#"
send "conf tn"
expect "#"
send "vlan 999n"
send "name DR_RECOVERYn"
send "exitn"
send "write memoryn"
EOF

chmod +x /tmp/vlan_setup.expect
/tmp/vlan_setup.expect

Geri Yükleme Süreci

Temiz ortam hazır. Artık geri yüklemeye başlayabilirsiniz. Hangi yedek çözümünü kullandığınıza göre süreç değişir.

Restic ile Geri Yükleme

# Kullanılabilir snapshot'ları listele
restic snapshots --repo s3:s3.amazonaws.com/backup-bucket

# Belirli bir snapshot'tan geri yükle
# Saldırıdan önceki en son temiz yedeği seç
CLEAN_SNAPSHOT="abc12345"  # Tespit ettiğiniz temiz snapshot ID

restic restore $CLEAN_SNAPSHOT 
    --target /mnt/restore 
    --repo s3:s3.amazonaws.com/backup-bucket 
    --verbose

# Geri yüklenen dosyaların bütünlüğünü doğrula
restic check --repo s3:s3.amazonaws.com/backup-bucket

# Kritik dizinleri önce geri yükle
restic restore $CLEAN_SNAPSHOT 
    --target /mnt/restore 
    --include /etc 
    --include /var/www 
    --include /home 
    --repo s3:s3.amazonaws.com/backup-bucket

Veeam ile Bare Metal Recovery

# Veeam PowerShell modülü ile otomatik restore
Add-PSSnapin VeeamPSSnapIn

# Mevcut restore point'leri listele
$backupJob = Get-VBRBackup -Name "Production_Servers_Daily"
$restorePoints = Get-VBRRestorePoint -Backup $backupJob | 
    Where-Object {$_.CreationTime -lt (Get-Date).AddDays(-1)} |
    Sort-Object CreationTime -Descending

# En son temiz restore point'i seç
$cleanRP = $restorePoints | Select-Object -First 1
Write-Host "Restore point: $($cleanRP.CreationTime)"

# Instant VM Recovery başlat
Start-VBRInstantVMRecovery -RestorePoint $cleanRP -RunAsync

Veritabanı Kurtarma

Veritabanları genellikle en kritik bileşendir ve özel dikkat gerektirir.

# MySQL/MariaDB yedeğinden geri yükleme
# Önce yedeğin tarihini doğrula
ls -la /backup/mysql/ | tail -20

# Seçilen yedeği geri yükle
BACKUP_FILE="/backup/mysql/production_20241115_0200.sql.gz"
RESTORE_TARGET="production_restored"

mysql -u root -p -e "CREATE DATABASE $RESTORE_TARGET;"

gunzip -c $BACKUP_FILE | mysql -u root -p $RESTORE_TARGET

# Binary log ile point-in-time recovery (saldırıdan hemen öncesine kadar)
# Saldırı zamanı: 2024-11-20 07:15:00 olarak tespit edildi
mysqlbinlog --start-datetime="2024-11-15 02:00:00" 
    --stop-datetime="2024-11-20 07:14:59" 
    /var/lib/mysql/mysql-bin.* | mysql -u root -p $RESTORE_TARGET

echo "Veritabanı kurtarma tamamlandı: $(date)"

Güvenlik Açığını Kapatın

Sistemi geri yükledikten sonra aynı saldırının tekrarlanmaması için güvenlik açığını bulup kapatmanız şart. Bunu yapmadan sistemi production’a almak, yangın söndürüldükten sonra kıvılcımı içeride bırakmak gibi.

# Sistemdeki tüm kullanıcı hesaplarını denetle
# Şüpheli yeni hesaplar veya yetki değişiklikleri ara
awk -F: '$3 >= 1000 {print $1, $3, $6}' /etc/passwd > /tmp/user_audit.txt

# Son 30 günde oluşturulan dosyaları tara
find / -newer /tmp/30days_ago -not -path "/proc/*" 
    -not -path "/sys/*" -not -path "/run/*" 
    -type f -ls 2>/dev/null > /tmp/new_files_audit.txt

# Cron job'ları denetle
for user in $(cut -f1 -d: /etc/passwd); do
    crontab -u $user -l 2>/dev/null | grep -v "^#" | 
    while read line; do
        echo "$user: $line"
    done
done > /tmp/cron_audit.txt

# Açık port ve servisleri listele
ss -tulpn > /tmp/open_ports.txt
systemctl list-units --type=service --state=running > /tmp/running_services.txt

Yama ve Hardening

# Sistemi güncel hale getir
apt update && apt upgrade -y  # Debian/Ubuntu
yum update -y                  # RHEL/CentOS

# SSH hardening kontrolü
grep -E "PermitRootLogin|PasswordAuthentication|PubkeyAuthentication" /etc/ssh/sshd_config

# Fail2ban kurulu ve aktif mi?
systemctl status fail2ban
fail2ban-client status

# SELinux durumu
getenforce

# Firewall kurallarını sıfırla ve yeniden yapılandır
iptables -F
iptables -X
# Güvenli kurallar ekle
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -j DROP
iptables-save > /etc/iptables/rules.v4

Doğrulama ve Test

Sistemi production’a almadan önce kapsamlı testler yapın. “Sanırım çalışıyor” kabul edilemez.

#!/bin/bash
# dr_validation.sh - Kurtarma doğrulama scripti

LOGFILE="/var/log/dr_validation_$(date +%Y%m%d_%H%M).log"
ERRORS=0

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOGFILE
}

check_service() {
    local service=$1
    if systemctl is-active --quiet $service; then
        log "OK: $service servisi çalışıyor"
    else
        log "HATA: $service servisi çalışmıyor"
        ((ERRORS++))
    fi
}

# Kritik servisleri kontrol et
for service in nginx mysql redis-server; do
    check_service $service
done

# Veritabanı bağlantısını test et
if mysql -u app_user -p$DB_PASS -e "SELECT 1;" app_database &>/dev/null; then
    log "OK: Veritabanı bağlantısı başarılı"
else
    log "HATA: Veritabanı bağlantısı başarısız"
    ((ERRORS++))
fi

# Web uygulaması yanıt veriyor mu?
HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://localhost/health)
if [ "$HTTP_STATUS" = "200" ]; then
    log "OK: Web uygulaması yanıt veriyor (HTTP $HTTP_STATUS)"
else
    log "HATA: Web uygulaması yanıt vermiyor (HTTP $HTTP_STATUS)"
    ((ERRORS++))
fi

# Kritik dosyaların varlığını doğrula
for file in /etc/nginx/nginx.conf /var/www/html/index.php /etc/ssl/certs/site.crt; do
    if [ -f "$file" ]; then
        log "OK: $file mevcut"
    else
        log "HATA: $file bulunamadı"
        ((ERRORS++))
    fi
done

log "Doğrulama tamamlandı. Toplam hata: $ERRORS"
exit $ERRORS

Gelecek Saldırılara Karşı Hazırlık

Kurtarma sürecinden sonra öğrendiklerinizi sistemleştirmeniz gerekiyor. Bu deneyim çok pahalıya patladıysa, bir dahaki sefere daha ucuza kurtulmak için şimdi yatırım yapın.

Immutable Backup Stratejisi

# AWS S3 Object Lock ile immutable backup
aws s3api put-object-lock-configuration 
    --bucket your-backup-bucket 
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }'

# Rclone ile 3-2-1 yedek stratejisi için otomatik script
cat << 'EOF' > /usr/local/bin/backup_321.sh
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
SOURCE="/var/www /etc /home"

# Yerel disk (1. kopya)
restic backup $SOURCE --repo /backup/local --tag "daily"

# Uzak NAS (2. kopya, farklı medya)
restic backup $SOURCE --repo sftp:nas-server:/backup --tag "daily"

# Cloud (3. kopya, offsite)
restic backup $SOURCE 
    --repo s3:s3.amazonaws.com/backup-immutable-bucket 
    --tag "daily"

# 30 günden eski yedekleri temizle (sadece yerel)
restic forget --repo /backup/local --keep-daily 30 --prune

echo "Yedekleme tamamlandı: $DATE"
EOF

chmod +x /usr/local/bin/backup_321.sh

Düzenli DR Testi

En iyi plan test edilmemiş plandır diye bir şey yoktur. Ayda en az bir kez, yılda en az bir kez tam DR testi yapın.

# dr_test.sh - Aylık DR test scripti
#!/bin/bash

TEST_ENV="dr-test-$(date +%Y%m)"
REPORT="/var/log/dr_test_$TEST_ENV.txt"

echo "DR Test Başladı: $(date)" > $REPORT

# Test VM'i başlat
virsh start dr-test-vm
sleep 30

# Test ortamına yedekten geri yükle
restic restore latest 
    --target /mnt/dr-test 
    --repo s3:s3.amazonaws.com/backup-bucket 
    --tag "weekly" >> $REPORT 2>&1

# Uygulama testlerini çalıştır
./dr_validation.sh >> $REPORT 2>&1

# RTO hesapla
echo "Test Bitti: $(date)" >> $REPORT
echo "Rapor: $REPORT"

# Test VM'i kapat
virsh shutdown dr-test-vm

Monitoring ve Erken Uyarı

# Honeypot dosya değişiklik izleme
# Ransomware genellikle toplu dosya değişikliği yapar
cat << 'EOF' > /etc/audit/rules.d/ransomware_detection.rules
# Kritik dizinlerdeki toplu yazma işlemlerini izle
-w /var/www/html -p wa -k web_content_write
-w /home -p wa -k home_write
-w /etc -p wa -k etc_write

# Shadow copy silme girişimlerini izle
-a always,exit -F arch=b64 -S execve 
    -F cmdline~vssadmin -k vss_delete_attempt
EOF

augenrules --load

# AIDE ile dosya bütünlüğü izleme
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Günlük bütünlük kontrolü için cron
echo "0 6 * * * root /usr/bin/aide --check | mail -s 'AIDE Report' [email protected]" 
    >> /etc/cron.d/aide-check

Sonuç

Ransomware saldırısından kurtulmak maraton, sprint değil. Paniğin en büyük düşmanınız olduğunu unutmayın.

Bu yazıda anlattığım sürecin özeti şu: izole et, belgele, kapsam belirle, temiz ortam kur, yedekten geri yükle, güvenlik açığını kapat, doğrula ve öğren. Her adım bir öncekine bağlı, birini atladığınızda süreç çöküyor.

Gerçekte en kritik fark, olaydan önce yapılanlarla yapılmayanlar arasındadır. Testini yapmadığınız yedek, olmayan yedektir. Offsite’a kopyalamadığınız yedek, ransomware’in silebileceği bir yedektir. Playbook’u yazmadığınız senaryo, o karanlık sabah 07:30’da boş bakacağınız senaryodur.

Şu anda sisteminiz sağlıklıyken yapmanız gereken üç şey: yedek stratejinizi 3-2-1 kuralına göre düzenleyin, immutable backup kullanın ve yılda en az iki kez tam DR testi yapın. Bunların maliyeti, bir ransomware saldırısından kurtulmanın maliyetinin onda biri bile değil.

Umarım bu yazıyı tatbikat olarak okursunuz, canlı kriz yönetimi sırasında değil.

Bir yanıt yazın

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