Fidye Yazılımı Yedeğimi de Şifreledi: Kurtarılabilir Yedek Nasıl Tutulur?

Sabah sunucuya bağlandınız; site açılmıyor, /var/www altındaki her dosyanın sonuna tanımadığınız bir uzantı eklenmiş ve her klasörde aynı metin dosyası duruyor. İlk refleksiniz doğru olan: "yedek var". /mnt/backup dizinine geçiyorsunuz ve orada da aynı manzara — dünkü .tar.gz arşivinin adı yedek-2026-08-17.tar.gz.locked. Aynı dakika içinde ikinci bir şey daha fark ediyorsunuz: panelde duran snapshot listesi boşalmış, çünkü paneldeki API anahtarı da sunucunun içindeki bir .env dosyasındaydı.

Bu tablo bir yedekleme eksikliği değil, bir yedek mimarisi hatasıdır. Yedek almıştınız; ama yedeği, şifrelenen makinenin yazma yetkisi olan bir yere koymuştunuz. Fidye yazılımının çalıştırdığı ilk rutinlerden biri tam olarak budur: bağlı disk ve paylaşımları taramak, gölge kopyaları ve snapshot'ları silmek, sunucuda bulduğu kimlik bilgileriyle erişilebilen bulut kovalarını boşaltmak. Şifreleme başlamadan önce kurtarma ihtimalinizi ortadan kaldırmak, saldırının ayrı bir aşamasıdır.

Bu yazı fidye yazılımının ne olduğunu anlatmıyor; onun için fidye yazılımının bulaşma yolları ve genel korunma rehberi var. Burada tek bir soruya odaklanıyoruz: yedek, saldırgan sunucuda root olduğunda bile hayatta kalacak şekilde nasıl kurulur? Önce ilk şifrelenen yedek konumlarını tek tek sayacağız, sonra çeken mimari, append-only depo ve object lock ile kurulumu göstereceğiz. En sonda da neredeyse hiç konuşulmayan ikinci tuzağı ele alacağız: elinizde çalışan bir yedek olsa bile, yanlış yedeği geri yüklerseniz zararlıyı da geri getirirsiniz.

Yedeğiniz Neden Şifrelendi: Erişilebilen Yedek, Yedek Değildir#

Yedeklemeyi çoğu kişi "verinin ikinci kopyası" olarak tanımlar. Fidye yazılımı bu tanımı geçersiz kılar, çünkü tehdit veriyi kaybetmek değil, veriyi yazabilen bir sürecin ele geçirilmesidir. Kopyanın varlığı değil, o kopyaya kimin yazabildiği belirleyicidir.

Buradan tek cümlelik bir kural çıkar ve bütün yazının omurgası budur: üretim sunucusunun silme veya üzerine yazma yetkisi olan hiçbir konum, fidye yazılımına karşı yedek sayılmaz. Sunucudan rm -rf ile silinebilen bir arşiv, sunucudaki bir anahtarla silinebilen bir bulut nesnesi ve sunucudaki bir API tokenıyla silinebilen bir snapshot arasında güvenlik açısından hiçbir fark yoktur.

Bu, klasik yedekleme mantığının neden yetmediğini de açıklar. Disk arızasına karşı ikinci kopya yeterlidir; çünkü disk sizden nefret etmez, sizi aramaz. Saldırgan arar.

İlk Şifrelenen Beş Yedek Konumu#

Aşağıdaki liste, olay müdahalesinde en sık karşılaşılan sıralamadır. Kendi kurulumunuzu bu tabloya göre işaretleyin.

Son satır özellikle yanıltıcıdır, çünkü snapshot almak bir tıklamadır ve panel "başarıyla oluşturuldu" der. Ancak snapshot verinin ikinci kopyası değil, aynı depolamada duran bir katmandır; bu ayrımı snapshot yedek midir yazısında ayrıntılı ele aldık. Fidye senaryosunda ek bir sorun daha vardır: snapshot silme yetkisi genellikle sunucunun kendisinde duran otomasyon anahtarındadır.

Bir de kimsenin listeye almadığı bir altıncı konum var: yedek betiğinin kendisi. /usr/local/bin/yedek.sh içindeki düz metin parola veya ~/.restic-pass dosyası, saldırgana yalnızca depoyu bulmakla kalmayıp içeriğini silme yetkisi de verir. Betiği okuyan, deponun adresini de öğrenir.

Yedeği Kim Başlatıyor: İten Mimari mi, Çeken Mimari mi?#

Kurulumların büyük çoğunluğu iten (push) mimaridir: üretim sunucusundaki bir cron görevi yedeği alır ve uzak depoya gönderir. Bu, tanımı gereği üretim sunucusuna depo üzerinde yazma — çoğu zaman silme — yetkisi verir. Sunucu ele geçtiğinde bu yetki de ele geçer.

Çeken (pull) mimaride yön terstir: ayrı bir yedek sunucusu, üretim sunucusuna kısıtlı bir SSH anahtarıyla bağlanır, veriyi okur ve kendi deposuna yazar. Üretim sunucusunun yedek sunucusuna hiçbir erişimi yoktur; adresini bile bilmesi gerekmez. Saldırgan üretim sunucusunda root olsa dahi yedek deposuna giden bir yol bulamaz.

Çeken mimaride üretim tarafındaki anahtar salt okunur olmalıdır:

# ÜRETİM sunucusunda /root/.ssh/authorized_keys
# Yedek sunucusu yalnızca bu tek komutu çalıştırabilir, kabuk açamaz
command="/usr/local/bin/yedek-oku.sh",no-port-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3Nza... yedek01

#!/bin/bash
# /usr/local/bin/yedek-oku.sh  (üretim sunucusunda, 0750)
set -euo pipefail
case "${SSH_ORIGINAL_COMMAND:-}" in
  "db")   exec mysqldump --single-transaction --quick --all-databases ;;
  "web")  exec tar -C /var/www -cf - . ;;
  *)      echo "izin verilmeyen komut" >&2; exit 1 ;;
esac

Yedek sunucusu tarafında akış basittir ve depo hiçbir zaman üretim tarafına açılmaz:

# YEDEK sunucusunda
ssh -i /root/.ssh/web01_ro [email protected] db \
  | restic -r /depo/web01 backup --stdin --stdin-filename db-full.sql

Bu tek değişiklik, "yedeğim de şifrelendi" vakalarının önemli bir kısmını tek başına ortadan kaldırır.

Append-Only Depo: Restic ve Borg Tarafında Uygulama#

Çeken mimariyi kuramadığınız durumlar vardır — örneğin yönetilen bir ortamda yalnızca üretim sunucusuna erişiminiz olabilir. O zaman ikinci savunma katmanı devreye girer: depo, istemcinin yalnızca ekleme yapabildiği bir moda alınır.

Restic tarafında bunun doğru yolu, depoyu doğrudan diske veya S3'e değil, rest-server üzerinden sunmaktır:

# YEDEK sunucusunda
rest-server \
  --path /srv/restic \
  --listen 127.0.0.1:8000 \
  --append-only \
  --htpasswd-file /srv/restic/.htpasswd

# ÜRETİM sunucusunda
export RESTIC_REPOSITORY="rest:http://web01:[email protected]:8000/web01"
restic backup /var/www /etc --exclude-caches

--append-only açıkken üretim sunucusundaki restic forget --prune komutu reddedilir. Saklama politikasını yedek sunucusunda, doğrudan depo yolu üzerinden ayrı bir zamanlanmış görevle çalıştırırsınız. Restic'in genel kullanımına yeniyseniz önce Restic ile şifreli yedekleme rehberine bakın; buradaki fark yalnızca deponun sunulma biçimidir.

Borg tarafında karşılığı SSH anahtarına gömülen kısıtlı bir servis komutudur:

# YEDEK sunucusunda /home/borg/.ssh/authorized_keys
command="borg serve --append-only --restrict-to-repository /depo/web01",restrict ssh-ed25519 AAAAC3Nza... web01

Borg'un append-only modunda dürüst olunması gereken bir ayrıntı vardır: istemci borg delete çalıştırdığında işlem mantıksal olarak kabul edilir, ancak bir sonraki normal (append-only olmayan) erişimde işlem geri alınabilir. Yani veri anında yok olmaz, ama depoyu eski hâline döndürmek transactions dosyasına elle müdahale gerektirir. Bu yüzden append-only'yi tek savunma olarak değil, çeken mimarinin veya object lock'ın yanında ikinci katman olarak konumlandırın. Borg'un temel kullanımı için BorgBackup rehberi yeterlidir.

Nesne Depolamada Sürümleme ve Object Lock#

Bulut nesne depolama kullanıyorsanız iki ayarın birlikte açık olması gerekir: versioning (sürümleme) ve object lock (nesne kilidi). Sürümleme, bir nesnenin üzerine yazılması ya da silinmesi durumunda eski sürümün korunmasını sağlar; object lock ise belirlenen süre boyunca sürümün silinmesini engeller. İkisinden biri eksikse koruma yoktur: sürümleme tek başına açıkken saldırgan sürümleri de silebilir.

Sık yapılan bir yanlış, "silme yetkisi olmayan bir IAM politikası yazarım, yeter" varsayımıdır. Pratikte bu, restic ve benzeri araçlarda depoyu kullanılamaz hâle getirir: restic her işlemde bir kilit nesnesi oluşturur ve işlem bitince onu siler. DeleteObject tamamen kapalıysa depo, ilk yedekten sonra kalıcı kilitli hâle gelir. Doğru yaklaşım, silmeye izin verip silmenin gerçek etkisini object lock ile ortadan kaldırmaktır:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::web01-yedek", "arn:aws:s3:::web01-yedek/*"]
    },
    {
      "Effect": "Deny",
      "Action": ["s3:DeleteObjectVersion", "s3:PutBucketVersioning", "s3:PutObjectRetention"],
      "Resource": ["arn:aws:s3:::web01-yedek", "arn:aws:s3:::web01-yedek/*"]
    }
  ]
}

Buradaki asıl koruma ikinci bloktur: sunucudaki kimlik bilgisi bir sürümü kalıcı silemez, kova sürümlemesini kapatamaz ve kilit süresini kısaltamaz. Saldırganın yaptığı "silme", yalnızca bir silme işaretçisi bırakır; asıl nesne kilit süresi boyunca yerinde durur. Kilit süresini saklama politikanızdan kısa seçmeyin — 30 günlük yedek tutuyorsanız 35 gün mantıklı bir başlangıçtır.

3-2-1-1-0 Kuralı: "1 Değiştirilemez, 0 Hata" Kısmı#

Klasik 3-2-1 kuralı (3 kopya, 2 farklı ortam, 1 offsite) disk arızası ve yangın için tasarlanmıştı. Fidye yazılımı çağında iki hane daha eklendi:

Sondaki sıfır, en çok atlanan hanedir ve tam olarak bu yüzden en pahalıya patlayan hanedir. Yedek işi "başarılı" dönmüş olabilir; bu, arşivin okunabildiği anlamına gelmez. Bütünlüğü düzenli doğrulayın:

# Restic: metadata kontrolü + verinin rastgele %10'unun gerçekten okunması
restic -r /depo/web01 check --read-data-subset=10%

# Borg: arşiv ve veri bütünlüğü
borg check --verify-data /depo/web01

Bütünlük kontrolü de yeterli değildir; bozulmamış bir arşivden çalışan bir sistem çıkmayabilir. Ayda bir kez rastgele bir yedeği boş bir makineye geri yükleyip veritabanının açıldığını ve sitenin ayağa kalktığını doğrulayın. Sıklık ve saklama planını nasıl kuracağınız ne sıklıkta yedek alınmalı yazısında ayrıntılı anlatılıyor.

Kimsenin Anlatmadığı İkinci Tuzak: Temiz Yedeği Seçmek#

Diyelim ki her şeyi doğru yaptınız: append-only depo şifrelenmedi, elinizde 30 günlük yedek var. Buradaki refleks neredeyse herkeste aynıdır — "en son yedeği geri yükleyeyim, en az veri kaybederim". Bu refleks, vakaların önemli bir kısmında saldırıyı ikinci kez yaşatır.

Nedeni şudur: fidye yazılımı, sisteme girdiği gün şifrelemeye başlamaz. Saldırgan genellikle günler, çoğu zaman haftalar boyunca içeride kalır; yetki yükseltir, yan sistemlere yayılır, veri sızdırır ve ancak sonunda şifrelemeyi tetikler. Şifrelemenin görüldüğü an, bulaşmanın son anıdır, ilk anı değil. Dolayısıyla dünkü yedeğinizde web kabuğu, sonradan eklenmiş bir SSH anahtarı, bozulmuş bir cron görevi veya zehirlenmiş bir systemd servis dosyası büyük olasılıkla zaten vardır.

Doğru sıra tersine çevrilmiştir: önce bulaşma tarihini tespit edin, sonra o tarihten önceki en yeni yedeği seçin. Aradaki fark bazen bir hafta, bazen bir aydır ve bu farkı bilmeden yapılan geri yükleme, birkaç gün sonra ikinci şifrelemeyle sonuçlanır.

Bulaşma Tarihini Tespit Etme Komutları#

Şifrelenmiş makineyi kapatmadan önce disk imajını veya bir snapshot'ı saklayın; aşağıdaki analizi kopya üzerinde yapın. Zaman damgalarında mtime yerine ctime tercih edin: mtime touch ile geriye alınabilir, ctime normal yollarla ayarlanamaz.

# 1) Şifrelemenin başladığı an (bulaşma değil, sonuç)
find /var/www -name '*.locked' -printf '%T+ %p\n' | sort | head -5

# 2) Belirli bir tarihten sonra metadata'sı değişen dosyalar
find /var/www /etc /usr/local/bin -type f -newerct '2026-07-15' \
     -printf '%Tc  %p\n' 2>/dev/null | sort | head -60

# 3) Dağıtım paketlerinin bozulup bozulmadığı
debsums -c 2>/dev/null          # Debian / Ubuntu
rpm -Va --nomtime 2>/dev/null   # RHEL / AlmaLinux

# 4) Oturum açma geçmişi ve başarılı SSH girişleri
last -Fwa | head -40
grep -hE 'Accepted (password|publickey)' /var/log/auth.log* | tail -50

# 5) Sonradan eklenmiş yetkili anahtarlar
find /root /home -name authorized_keys -printf '%Tc  %p\n' 2>/dev/null

# 6) Yeni veya değiştirilmiş zamanlanmış görevler
find /etc/cron* /var/spool/cron -newerct '2026-07-15' -type f 2>/dev/null

Bu altı çıktının en eski tarihi, aramanız gereken sınırdır. Zamanlanmış görevlerde ne aradığınızı zararlı cron görevi tespiti yazısında örnekleriyle bulabilirsiniz.

Sınırı belirledikten sonra aday yedeği doğrudan üretime değil, ağdan yalıtılmış bir karantina dizinine açın ve orada tarayın:

restic -r /depo/web01 restore 8f3c1a2b --target /srv/karantina
clamscan -ri --exclude-dir='^/sys' /srv/karantina
grep -rEl 'eval\(base64_decode|assert\(\$_(POST|GET|REQUEST)|\bshell_exec\(' \
     /srv/karantina --include='*.php' | head -30

Otomatik tarayıcının bulamadığı el yapımı kabuklar olabileceği için sonuçları malware tarama ve temizleme yazısındaki manuel kontrollerle birleştirin.

Geri Yükleme Sırası: Veriyi Getirin, Sistemi Yeniden Kurun#

Ele geçirilmiş bir sistemi "temizleyerek" kullanmaya devam etmek, kalıcılık mekanizmalarının tamamını bulduğunuza dair bir bahistir. Pratikte kazanılması zor bir bahistir. Doğru akış şudur:

1. Eski makineyi dondurun. Kapatın veya ağdan koparın, ama silmeyin; imajı adli inceleme ve sigorta için saklayın.
2. Sıfırdan kurun. Yeni bir sunucuya işletim sistemini ve uygulama bileşenlerini dağıtım paketlerinden kurun. İkili dosyaları yedekten geri getirmeyin.
3. Yalnızca veriyi geri yükleyin. Veritabanı dökümü, yüklenen dosyalar, statik içerik. Yapılandırma dosyalarını satır satır gözden geçirerek taşıyın.
4. Tüm kimlik bilgilerini değiştirin. Veritabanı parolaları, panel şifreleri, SSH anahtarları, API tokenları, bulut anahtarları — hepsi sızmış kabul edilmelidir.
5. Giriş noktasını kapatın. Bulaşma tarihinde açık olan güncelleme eksiğini, zayıf parolayı veya açık portu düzeltmeden yayına almayın.
6. Yedek mimarisini bu yazıdaki hâline getirin. Aksi hâlde ikinci olayda aynı yerde duracaksınız.

Kurumsal bir ortamda 4. maddeyi geniş tutmak gerekir: sunucuda saklanan üçüncü taraf entegrasyon anahtarları da (ödeme sağlayıcı, e-posta servisi, CDN) yenilenmelidir.

Sıkça Sorulan Sorular#

Fidye yazılımı bulut yedeklerimi de şifreleyebilir mi?#

Sunucuda o bulut hesabına ait bir kimlik bilgisi duruyorsa evet. Fidye yazılımları rclone.conf, ~/.aws/credentials, .env ve yedek betiklerini arar; bulduğu anahtarla kovadaki nesneleri siler veya üzerine yazar. Korunmanın yolu bulutu kullanmak değil, kovada sürümleme ile object lock'ı birlikte açmak ve sunucudaki kimliğe sürüm silme yetkisi vermemektir.

Snapshot almak fidye yazılımına karşı yeterli mi?#

Hayır. Snapshot aynı depolama üzerinde duran bir katmandır ve silme yetkisi genellikle sunucudaki otomasyon anahtarındadır. Saldırganların standart adımlarından biri, şifrelemeden hemen önce mevcut anlık görüntüleri silmektir. Snapshot hızlı geri alma için değerlidir, yedek yerine geçmez; ayrımı ayrı bir yazıda ayrıntılı ele aldık.

Append-only depoda eski yedekleri nasıl silerim, disk dolmaz mı?#

Saklama politikasını istemciden değil, deponun bulunduğu tarafta çalıştırırsınız. Yedek sunucusunda doğrudan depo yolunu kullanan ayrı bir zamanlanmış görev forget --prune veya borg prune işini yapar. Üretim sunucusundaki kimlik silmeye yetkili olmadığı için ele geçirilse bile bu görevi tetikleyemez.

Hangi kadar geriye giden yedek tutmalıyım?#

Fidye vakalarında belirleyici ölçü disk maliyeti değil, saldırganın sistemde kalma süresidir; bu süre çoğu olayda haftalarla ölçülür. Bu yüzden yalnızca son birkaç günü tutan bir plan yetersizdir. Pratik bir taban çizgisi günlük 14, haftalık 8 ve aylık 6 kopyadır; tekilleştirmeli araçlarda bu, tam yedek maliyetinin çok altında yer kaplar.

Harici diske alınan yedek gerçekten air-gap sayılır mı?#

Yedek alındıktan sonra disk fiziksel olarak çıkarılıyor ve başka bir yere kaldırılıyorsa evet, bu gerçek bir hava boşluğudur ve son derece etkilidir. Ancak disk sürekli takılı kalıyorsa hiçbir koruma sağlamaz; işletim sistemi onu sıradan bir bağlama noktası olarak görür ve şifreleme rutini de öyle görür.

Yedekten geri yükleyince zararlı tekrar gelir mi?#

Bulaşma tarihini belirlemeden en son yedeği geri yüklerseniz büyük olasılıkla evet. Web kabukları, ek SSH anahtarları ve zararlı cron görevleri şifrelemeden günler önce yerleştirilmiş olur ve yedeğe de girer. Bu yüzden önce izlerden bulaşma tarihini tespit edin, o tarihten önceki yedeği seçin ve geri yüklemeden önce yalıtılmış bir dizinde tarayın.