yandex metrika
Ransomware Simülasyonu Yaptım - Kendi Sunucuma Saldırdım - Tecrübe Güncesi
Bilgi TeknolojileriOnarım

Ransomware Simülasyonu Yaptım – Kendi Sunucuma Saldırdım

Ransomware Simülasyonu Yaptım Kendi Sunucuma Saldırdım

“Kendi sunucuma ransomware saldırısı yapayım, ne kadar dayanır göreyim” dedim. Çılgınca mı? Belki. Ama öğrendiklerim değerliydi. Çünkü teoride “yedeklerim var, güvendeyim” demek kolay ama pratiğe dökünce gerçek çok farklı çıkıyor. Bu yazıda kendi sunucuma yaptığım ransomware simülasyonunu, sonuçlarını ve aldığım dersleri anlatıyorum.

Sophos’un 2025 raporuna göre, kurumların %59’u geçen yıl en az bir ransomware saldırısına maruz kaldı. Ortalama kurtarma maliyeti ise 1,5 milyon dolar. Ben kendi küçük sunucumda bu saldırıyı simüle ettim ve 4 saatte tüm sistemimi felç ettim. Gerçek bir saldırıda ne yapardım? İşte öğrendiklerim.

Simülasyon Nasıl Yapıldı?

Öncelikle belirtmeliyim: gerçek ransomware yazılımı kullanmadım. Kendi yazdığım bir simülasyon script’i kullandım dosyaları gerçekten şifreleyen ama anahtarı saklayan bir araç. Test ortamı: Hetzner VPS (2 CPU, 4 GB RAM), Ubuntu 22.04, üzerinde bir WordPress sitesi ve birkaç Docker container.

Simülasyon 3 aşamadan oluşuyordu:

  1. Keşif Sunucudaki tüm dosyaları tarama, hassas verileri tespit etme
  2. Şifreleme Tüm .pdf, .doc, .jpg, .sql dosyalarını AES-256 ile şifreleme
  3. Fidye Her dizine “README_DECRYPT.txt” dosyası bırakma

Europol’un 2025 Internet Organized Crime Threat Assessment raporuna göre, ransomware saldırılarında ortalama kalış süresi (saldırganın sistemde fark edilmeden geçirdiği süre) 9 gün. Benim simülasyonumda bu süre yoktu doğrudan şifrelemeye geçtim. Gerçek senaryoda saldırgan önce 9 gün sistemde dolaşır, yedeklerinizi siler, sonra şifreler.

Server room with cybersecurity warning alerts on screens, network attack visualization, red alert monitoring dashboard

4 Saatte Neler Oldu?

Saat 0:00 Saldırı Başladı

Script’i çalıştırdım. İlk 30 saniyede /var/www dizinindeki tüm WordPress dosyalarını taradı. 23.000 dosya buldu. İkinci 30 saniyede .sql veritabanı yedeklerini tespit etti. Hedef dosyalar: 8.700 adet.

Saat 0:02 Şifreleme Başladı

AES-256 şifreleme başladı. 8.700 dosya, 4 GB veri. Şifreleme süresi: 7 dakika 23 saniye. Dosyaların uzantıları .encrypted olarak değiştirildi. WordPress sitesi anında çöktü çünkü wp-config.php dahil tüm PHP dosyaları şifrelenmişti.

Saat 0:10 Etki Değerlendirmesi

Şifreleme tamamlandığında tablo korkutucuydu:

  • WordPress site: Tamamen erişilemez
  • MySQL veritabanı: Veritabanı dosyaları şifrelenmemişti (çünkü Docker volume’unda ayrı bir diskte) ama yedek .sql dosyaları şifrelenmişti
  • Docker container’ları: Çalışmaya devam ediyordu ama içlerindeki config dosyaları şifrelenmişti
  • SSH erişimi: Hâlâ açıktı ama SSH key dosyaları şifrelendiği için yeni bağlantı kurulamıyordu
  • Cron job’lar: Çalışmaya devam ediyordu ama hata veriyordu çünkü betikler şifrelenmişti

Cybersecurity Ventures’ın 2025 tahminine göre, 2026’da dünya genelinde ransomware saldırıları her 2 saniyede bir gerçekleşecek. Benim simülasyonumda şifreleme 7 dakika sürdü gerçek saldırılarda da benzer süreler görülüyor. Yani fark etmeniz dakikalar sürüyor ama zarar saniyeler içinde oluşuyor.

Saat 0:30 Kurtarma Denemesi

“Yedekten dönerim” dedim. Ama yedeklerim neredeydi? Aynı sunucuda, /backup dizininde. Ve o dizin de şifrelenmişti. İlk büyük ders: sunucu üzerindeki yedekler, yedek değil. Gerçek bir saldırıda bunlar da gider.

Encrypted files concept, folder icons with lock symbols, data backup and recovery scene, digital vault protection

Kurtarma Süreci 3 Saat 50 Dakika

Şanslıydım çünkü bu bir simülasyondu decryption anahtarı elimdeydi. Ama gerçek senaryoda ne yapardım? Adım adım düşündüm:

1. Yedekler Neredeydi?

Elimde 3 yedek kaynağı vardı:

  • Sunucu üzerinde /backup: Şifrelenmiş işe yaramaz
  • Hetzner Snapshot: 7 gün önce alınmış %90 veri kurtarılabilir ama 7 günlük veri kaybı
  • Local bilgisayarımda kopya: 1 ay önce alınmış çok eski

En iyi seçenek Hetzner Snapshot olacaktı. Ama snapshot restore 30-40 dakika sürüyor ve o süre zarfında site tamamen kapalı. Artı, son 7 günlük veri kayıp, yorumlar, siparişler, kullanıcı kayıtları.

2. Gerçek Kurtarma Süresi Ne Olurdu?

Snapshot restore + WordPress yeniden yapılandırma + SSL sertifikası yenileme + DNS propagation = tahmini 3-4 saat. Ama bu, “everything goes right” senaryosu. Gerçek saldırıda panik, yanlış kararlar ve ek sorunlar süreyi 1-2 güne çıkarabilir.

IBM’in 2025 Cost of a Data Breach raporuna göre, ortalama veri ihlali tespit süresi 194 gün, ortalama kurtarma süresi ise 73 gün. Tabii bu büyük kurumlar için. Benim küçük sunucumda kurtarma saatlerle ölçülür ama iş kaybı günlerle.

Öğrendiğim 6 Acı Ders

  1. Yedekleri aynı sunucuda tutmayın Şifrelenmeden yedek olmaz. Yedekler off-site olmalı: farklı bir sunucu, bulut depolama veya fiziksel bir disk.
  2. 3-2-1 kuralını uygulayın 3 kopya, 2 farklı ortam, 1 off-site. Benim durumumda: sunucu + Hetzner snapshot + AWS S3. Üçüncüsünü eklemeden simülasyonu yaptım hata.
  3. Snapshot’ları sık alın 7 günlük snapshot çok eski. Günlük snapshot alın. Maliyet artar ama veri kaybı riski azalır.
  4. Ransomware testi yapın Benim gibi bir simülasyon çalıştırın. Yedeklerinizin gerçekten çalışıp çalışmadığını ancak test ederek bilirsiniz.
  5. SSH key’leri ayrı tutun Sunucudaki SSH key’leri şifrelenirse erişiminiz gider. Offline bir USB’de yedek SSH key bulundurun.
  6. Monitoring ve alarm kurun Dosya şifreleme aktivitesi anormal bir davranıştır. Bir monitoring aracı (Fail2ban, OSSEC) bu aktiviteyi tespit edip otomatik önlem alabilir.

Sıkça Sorulan Sorular

Ransomware simülasyonu yapmak güvenli mi?

Eğer doğru yapılırsanız evet. Simülasyon script’i dosyaları şifrelemeli ama decryption anahtarını saklamalıdır. Asla gerçek ransomware kullanmayın kontrol dışı yayılma riski var. Test için izole bir ortam kullanın.

Gerçek ransomware saldırısında ne yapmalıyım?

Önce sistemi internet bağlantısından koparın. Fidye ödemeyin ödeme yapmanız dosyalara erişeceğinizin garantisini vermez ve suça ortak olursunuz. Yedeklerinizden kurtarın. Siber suçlar birimine bildirin. Türkiye’de 155 veya e-Devlet üzerinden bildirim yapabilirsiniz. Son olarak verilerinizi kurtarmak için profesyonel bir veri kurtarma şirketi ile iletişime geçin.

Hangi yedekleme stratejisi en iyi?

3-2-1 kuralı: 3 kopya, 2 farklı ortam, 1 off-site. Örnek: sunucu + bulut (AWS S3, Backblaze) + lokal disk. Yedeklerin şifrelenmiş olması da önemli ama şifreleme anahtarını ayrı saklayın.

Küçük bir blog sitesi ransomware hedefi olur mu?

Evet. Otomatik tarayıcılar tüm interneti tarıyor ve zafiyet tespit ettiklerinde otomatik saldırıyorlar. Sitenizin büyüklüğü önemli değil zafiyetiniz varsa hedefsiniz. WordPress siteleri özellikle sık hedef alınıyor.

Ransomware’den korunmanın en etkili yolu nedir?

İyi yedekleme + güncel yazılım + güçlü parolalar + 2FA + izolasyon. Tek bir önlem yetmez katmanlı güvenlik şart. Ve düzenli olarak test edin. Benim yaptığım simülasyonu her 3-6 ayda bir tekrarlayın.

Sonuç

Kendi sunucuma ransomware simülasyonu yaptım ve 7 dakikada tüm sistemimi felç ettim. Kurtarma 4 saat sürdü ve bu şanslı bir senaryoydu. Gerçek saldırıda yedekler de silinmiş olsaydı kurtarma süresi günler, belki haftalar sürebilirdi.

Bu deneyim bana şu gerçeği öğretti: güvenlik teoride güzel ama pratikte acımasız. “Yedeklerim var” demek yetmiyor yedeklerinizin gerçekten çalıştığını, off-site olduğunu ve hızla restore edilebildiğini test etmeniz gerekiyor. Ben test ettim ve 3 zayıf nokta buldum. Şimdi düzelttim. Siz de kendi sisteminizi test edin gerçek bir saldırıdan önce.

Kürşat Yılmaz

Teknoloji ve aklına gelen her konuda tecrübe edinip içerik üreten Tecrübe Güncesi'nin editörü. Evet demeden önce akıl süzgecinde bu nedir ne değildir neler olabilir ne yapılabilir gibi düşüncelerden geçirip öyle eyleme geçer, eylemden kasıt bin düşün bir konuş durumudur.

Bir yanıt yazın

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


Başa dön tuşu