Ransomware'a Karşı Sunucu Koruma: Katmanlı Savunma Rehberi

Ransomware'a Karşı Sunucu Koruma: Katmanlı Savunma Rehberi

Sunucunuz şifrelendi. Ekranda fidye notu var. İlk refleks panik — ama panikten önce şunu sorun: son 7 günlük yedeğiniz var mı? Ve o yedek immutable mi? Yanıt "evet" ise felaket kurtarılabilir. Yanıt "hayır" ise kayıp büyük ihtimalle telafi edilemez.

Ransomware, sunucu güvenliğinin en sert gerçeklik testidir. Saldırı tek bir açıktan girer, dakikalar içinde binlerce dosyayı şifreler, ardından fidye talep eder. Bu yazıda Buyukweb perspektifinden konuya bakıyoruz: hosting müşterisinde Imunify360 + ClamAV + JetBackup katmanı, VDS müşterisinde ise koruma ve yedekleme sorumluluğunun tamamen müşteride olduğu unmanaged yapı.

Buyukweb perspektifi: cPanel hosting paketlerimizde Imunify360 6.x + ClamAV + ModSecurity + CageFS izolasyonu + günlük JetBackup (harici sunucu) standart aktif. VDS unmanaged'dır — anti-ransomware tedbiri, yedekleme stratejisi ve incident response tamamen müşteri sorumluluğundadır. VDS için Veeam altyapısıyla günlük otomatik yedekleme de sunulur.

2024-2026 Ransomware Tehdit Tablosu

2024 ortasından 2026 başına kadar sunuculara yönelik ransomware saldırıları önemli bir dönüşüm geçirdi. Eski senaryo şuydu: kullanıcı phishing e-postasına tıklar, uç nokta şifrelenir. Bugünkü senaryo çok daha doğrudan.

Öne çıkan tehdit vektörleri (2024-2026):

• Exposed RDP / SSH brute-force: Açık portlarda zayıf kimlik bilgisi deneme saldırıları. Özellikle varsayılan port + şifre kombinasyonu hâlâ birincil giriş noktası.
• Unpatched uygulama zafiyeti: CVE'si yayımlanan ama yaması uygulanmayan web uygulamaları — CMS, kontrol paneli, API gateway — doğrudan hedef.
• Supply chain / eklenti zafiyeti: Güvenilir bir eklentinin veya bağımlılığının ele geçirilmesi. WordPress ekosisteminde sık rastlanıyor.
• Credential stuffing: Sızdırılmış kimlik bilgisi veritabanlarından otomatik deneme. MFA olmayan her hesap risk altında.
• Living off the land (LotL): Saldırgan sunucunun kendi araçlarını kullanır (cron, rsync, Python stdlib) — klasik imza tabanlı AV'nin gözden kaçırdığı teknik.

Linux sunucular da hedefte: "Linux şifrelenmiyor" miti tamamen yanlış. 2024 itibariyle Linux'u hedef alan ransomware ailelerinde belirgin artış var. ESXi/KVM hipervizör katmanını hedef alan varyantlar özellikle kritik — tek saldırıda onlarca VM şifrelenebiliyor.

Saldırı Yüzeyi: Linux ve Windows Sunucu

Vektör	Linux Sunucu	Windows Sunucu
SSH brute-force	Yüksek risk (açık 22/tcp)	Düşük (SSH varsayılan yok)
RDP brute-force	Yok	Yüksek risk (açık 3389/tcp)
Yama eksikliği	Orta (kernel, glibc, OpenSSL)	Yüksek (sık CVE akışı)
Web uygulama açığı	Yüksek (cPanel/PHP/CMS)	Yüksek (IIS/ASP.NET)
Şifrelenmiş ağ trafiği	Var (rsync over SSH, SFTP)	Var (SMB over TLS)
Yedek hedefleme	Var (bağlı NFS/SMB paylaşımı)	Var (bağlı ağ sürücüsü)

Önemli nokta: Yedek sunucu ağ üzerinden erişilebilir durumdaysa ransomware yedeği de şifreler. Bu yüzden sadece yedek almak yetmez; yedeğin immutable (write-once) olması şarttır.

Buyukweb Sunucu Katmanı: Imunify360 + ClamAV + CageFS

Buyukweb cPanel hosting paketlerinde uygulama katmanı zararlı yazılım koruma şöyle çalışır:

✓ Imunify360 6.x     — Gerçek zamanlı davranış analizi + ML tabanlı tehdit tespiti
✓ ClamAV 1.x         — Dosya sistemi imza taraması (yükleme anı + zamanlanmış)
✓ ModSecurity OWASP  — HTTP seviyesi exploit engelleme (web shell yükleme dahil)
✓ CageFS             — Kullanıcı başına izole dosya sistemi; bir hesap diğerini göremez
✓ CloudLinux LVE     — CPU/RAM/IO limiti; tek hesabın sunucuyu doyurması engeli
✓ CPHulk             — cPanel brute-force kilidi (5 deneme / 5 dakika penceresi)
✓ JetBackup (hosting) — Harici sunuculara günlük otomatik yedekleme

Imunify360 ransomware'ı tespit eder mi? Spesifik cevap: Imunify360, yükleme veya oluşturma anında bilinen ransomware imzalarını ve şüpheli dosya davranışlarını (toplu şifreleme, izin değişimi, C2 bağlantısı) tespit eder ve karantinaya alır. Bununla birlikte sıfır-gün (zero-day) varyantlar veya sunucu içinden meşru kimlik bilgileriyle başlatılan saldırılar Imunify360'ı atlayabilir. Bu yüzden Imunify360 tek başına yeterli değil; yedek + erişim kontrolü + monitoring şart.

Tercih etmeyin: "Imunify360 var, başka önlem gerekmez" tutumunu. Savunma katmanlarının birbirini tamamlaması gerekir.

VDS unmanaged: Imunify360 ve CageFS VDS'de standart gelmiyor. Anti-ransomware tedbiri (fail2ban, ClamAV, AppArmor/SELinux, RBAC, SSH key-only) tamamen müşterinin sorumluluğunda.

Uygulama İzolasyonu: CageFS ve Container

CageFS, paylaşımlı hosting ortamında bir kullanıcı hesabının ele geçirilmesinin diğer hesaplara yayılmasını engeller. Her hesap kendi sanal dosya sistemi görünümünde çalışır; /etc/passwd, sistem binary'leri ve diğer kullanıcıların dizinleri görünmez.

VDS ortamında benzer izolasyonu container (LXC/Docker) veya AppArmor / SELinux zorunlu erişim denetimi sağlar:

• AppArmor: Uygulama başına hangi dosyalara, ağ adreslerine ve sistem çağrılarına erişilebileceğini profillerle tanımlar. Nginx veya PHP-FPM için AppArmor profili, saldırganın web suncusu üzerinden /tmp veya /home dizinine yazmasını engeller.
• SELinux: RHEL/AlmaLinux/Rocky sistemlerde benzer zorunlu erişim denetimi. Varsayılan "enforcing" modda bırakın.
• RBAC (Role-Based Access Control): Uygulama hesaplarına en az yetki ilkesi. Web uygulaması hesabının /var/www'nin dışına erişim yetkisi olmamalı.

Erişim Kontrolü: MFA + RBAC + SSH Key

Ransomware'ın büyük çoğunluğu meşru kimlik bilgisiyle sisteme giriyor — kırılmış şifre, çalınmış session token veya sızdırılmış credential. Erişim kontrolü bu geçidi daraltır.

SSH sertleştirme (VDS/dedicated):

# /etc/ssh/sshd_config — temel güvenlik ayarları
Port 2222                     # Varsayılan 22 yerine (noise azaltır)
PermitRootLogin no            # Root doğrudan giriş kapalı
PasswordAuthentication no     # Sadece SSH anahtar çifti
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
AllowUsers deploy webadmin    # Sadece belirli kullanıcılar

# Yapılandırmayı yeniden yükle (sshd.service restart ETME — bağlantı kesilir)
systemctl reload sshd

MFA zorunluluğu: cPanel, Plesk ve SSH için TOTP tabanlı MFA (Google Authenticator / andOTP uyumlu) aktif edin. Credential stuffing saldırısı şifreyi bilse bile TOTP olmadan giremez.

Zero Trust prensibi: Her erişim isteği güvenilmez sayılır ve doğrulanır — ağ içinden gelen trafik bile. Minimal yetki + her erişim için kimlik doğrulama.

RBAC iyi pratikleri:

• Web uygulaması, veritabanı ve yedekleme için ayrı servis hesapları
• Her hesabın yalnızca ihtiyaç duyduğu dizine yazma yetkisi
• Root / sudo erişimini sadece yöneticilere, sadece gerektiğinde

Yedekleme Stratejisi: 3-2-1 Kuralı + Immutable + Off-site

Ransomware'a karşı en güçlü yanıt immutable yedektir. Saldırı her katmanı aşsa bile temiz bir yedekle sistemi kurtarabilirsiniz.

3-2-1 Kuralı

Kural	Açıklama	Uygulama
3 kopya	Verinin en az 3 kopyası	Üretim + yerel yedek + uzak yedek
2 farklı medya	Farklı depolama ortamları	Disk + obje depolama (S3-uyumlu)
1 off-site	En az 1 kopya fiziksel olarak farklı lokasyonda	Uzak veri merkezi / nesne depolama

Buyukweb yedekleme katmanları:

• Hosting + Reseller: JetBackup 5 ile günlük otomatik yedekleme — harici sunuculara
• VDS (E5-V4, E5-V2, Nested): Veeam altyapısıyla günlük otomatik yedekleme
• Her iki durumda da ek off-site + immutable yedek almanızı öneririz

Immutable Backup (Object Lock)

Immutable yedek; yazıldıktan sonra belirli bir süre boyunca silinemez ve değiştirilemez (write-once). S3-uyumlu obje depolama servislerindeki Object Lock özelliği bunu sağlar. Ransomware sistemde root yetkisi kazansa bile Object Lock süresi dolmadan yedeği şifreleyemez veya silemez.

# S3-uyumlu depolama — Object Lock (immutable backup) örneği
# Herhangi bir S3-uyumlu endpoint (s3cmd veya mc CLI ile)

# Bucket oluştururken Object Lock aktif et (sonradan etkinleştirilemez)
mc mb --with-lock s3compat/buyukweb-immutable-backup

# Varsayılan saklama politikası: 30 gün COMPLIANCE modu
mc retention set --default COMPLIANCE 30d s3compat/buyukweb-immutable-backup

# Restic ile immutable bucket'a şifreli yedekleme
export RESTIC_REPOSITORY="s3:https://s3endpoint/buyukweb-immutable-backup"
export RESTIC_PASSWORD="guclu-anahtar-buraya"

restic backup /var/www /etc/nginx /home \
  --tag "$(date +%F)" \
  --verbose

# Yedek bütünlüğü kontrolü
restic check
restic snapshots

Tercih etmeyin:

• Tek kopya yedek tutmayı — saldırı birincil yedeğe de bulaşır
• Yedeği aynı ağa bağlı sürücüde saklamayı — ransomware erişilebilir her paylaşımı şifreler
• Sadece anti-virüs ile korunmayı — imza tabanlı AV sıfır-gün varyantları yakamaz

Yedek test zorunluluğu: Ayda bir restore testi yapın. Restore edilemeyen yedek yok demektir.

Monitoring ve Log Analizi: Wazuh + fail2ban

Saldırı genelde anlamlı iz bırakır; izleme erken uyarı sağlar ve incident response süresini kısaltır.

fail2ban + ClamAV otomatik tepki

# fail2ban kurulum ve SSH + web için aktivasyon (Debian/Ubuntu)
apt install fail2ban clamav clamav-daemon -y

# /etc/fail2ban/jail.local
# [sshd]
# enabled  = true
# port     = 2222
# maxretry = 3
# bantime  = 86400   # 24 saat ban
# findtime = 600

# [nginx-http-auth]
# enabled  = true
# maxretry = 5
# bantime  = 3600

systemctl enable --now fail2ban clamav-daemon

# ClamAV imza güncelleme + manuel tarama
freshclam
clamscan -r --infected --remove=no --log=/var/log/clamav-scan.log /var/www

# Zamanlanmış tarama (her gece 02:00)
echo "0 2 * * * root clamscan -r --infected --log=/var/log/clamav-scan.log /var/www" \
  >> /etc/cron.d/clamav-daily

Wazuh SIEM — Agent Yapılandırması

Wazuh açık kaynaklı SIEM / EDR çözümüdür. Sunucu loglarını merkezi olarak toplar, dosya bütünlüğünü izler (FIM) ve şüpheli davranışı (toplu dosya şifreleme, yetki yükseltme, C2 bağlantısı) algılar.

# /var/ossec/etc/ossec.conf — Wazuh agent temel yapılandırması (kısa)
<ossec_config>
  <client>
    <server>
      <address>WAZUH_MANAGER_IP</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
  </client>

  <!-- Dosya Bütünlük İzleme (FIM) -->
  <syscheck>
    <frequency>3600</frequency>
    <directories check_all="yes" realtime="yes">/var/www,/etc,/bin,/sbin</directories>
    <ignore>/var/www/cache</ignore>
  </syscheck>

  <!-- Log izleme -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>
  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/nginx/access.log</location>
  </localfile>
</ossec_config>

Wazuh ne yakalar:

• Kısa sürede çok sayıda dosya değişikliği (ransomware şifreleme davranışı)
• Başarısız SSH giriş akışı (brute-force)
• /etc/shadow, /etc/passwd değişikliği (yetki yükseltme girişimi)
• Bilinen C2 IP adresiyle ağ bağlantısı

Buyukweb hosting paketlerinde Imunify360 bu izlemeyi uygulama katmanında yapar. VDS müşterisi Wazuh agent kurarak aynı görünürlüğü sağlayabilir.

Koruma Matrisi: 3 Katman

Katman	Hedef	Araç	Kim Sağlar
Önle	Yetkisiz erişimi engelle	MFA + SSH key + RBAC + fail2ban + port kısıtlama	VDS: müşteri / Hosting: Buyukweb (CPHulk + Imunify360)
Tespit et	Saldırıyı anında yakala	Imunify360 6.x + ClamAV 1.x + Wazuh SIEM + FIM	VDS: müşteri / Hosting: Buyukweb
Kurtar	Temiz sisteme dön	3-2-1 yedek + immutable backup + Object Lock	VDS: müşteri + Veeam / Hosting: JetBackup + müşteri off-site

Her katman bağımsız çalışır; birinin başarısız olması diğerini devreye sokar. Tek katman savunması yeterli değildir.

Incident Response: 5 Adım

Sunucunuzun şifrelendiğini fark ettiğinizde sıralı eylem planı:

Adım	Süre	Eylem
1. İzolasyon	0-15 dk	Sunucuyu ağdan izole edin (NIC kapat / firewall kural: tüm outbound DROP). Yayılımı durdurun. Buyukweb VDS için: kontrol panelinden ağ arayüzünü devre dışı bırakın.
2. Tespit	15 dk – 4 saat	Hangi ransomware ailesi? strings + file komutuyla şifreli dosya başlığını inceleyin. Şifreli dosya uzantısına bakın (.locked, .enc, .crypt). No More Ransom Project (nomoreransom.org) ücretsiz decryption tool listesi içerir.
3. Temiz sistem	4-24 saat	Etkilenen diski yeniden biçimlendirin. Saldırı vektörünü kapatmadan aynı sistemi geri açmayın — backdoor kalır, tekrar şifrelenir.
4. Restore	24-48 saat	En güncel immutable yedekten restore edin. Restore öncesi yedeğin bütünlüğünü doğrulayın (hash kontrolü). Veeam (VDS) veya JetBackup (hosting) üzerinden geri yükleme adımlarını izleyin.
5. Analiz + Sertleştirme	48-72 saat	Saldırı giriş noktasını belirleyin. Tüm kimlik bilgilerini rotasyona alın. Yama + güvenlik güncellemeleri. KVKK 12. madde: kişisel veri ihlali olduysa 72 saat içinde Kurul'a bildirim zorunlu.

Fidye Ödemesi: Yapmayın

Fidye ödeme kararı basit görünür. Gerçeklik çok farklı:

• Dosyaların geri gelmesi garanti değil. Saldırganların önemli bir kısmı ödeme sonrası decryption key göndermez.
• Tekrar hedef olursunuz. Ödediğinizi bilen grup veya sızdırılan hedef listesi sizi yeniden vurabilir.
• Yasal risk. Yaptırım listesindeki gruplara fidye ödemek bazı ülkelerde yasal sorun doğurur; Türkiye mevzuatı da bu yönde gelişiyor.

Alternatif: No More Ransom Project (nomoreransom.org) — Europol koordinasyonlu, 100'den fazla ücretsiz decryption tool barındıran platform. Şifreli dosya örneği yükleyin; varsa ücretsiz çözüm sunar.

Sık Sorulan Sorular

Linux sunucular ransomware'a maruz kalır mı?

Evet, kesinlikle. "Linux şifrelenmez" miti geçerliliğini çoktan yitirdi. 2024 itibariyle Linux'u hedef alan ransomware ailelerinde (özellikle ESXi/KVM hipervizör katmanını şifreleyen varyantlar) kayda değer artış gözlemlendi. SSH brute-force, yama eksikliği ve web uygulama zafiyeti Linux'ta da geçerli saldırı vektörleri.

Sadece anti-virüs ile korunmak yeterli mi?

Hayır. Anti-virüs imza tabanlı çalışır; sıfır-gün varyantları ve meşru araçları kullanan (LotL) saldırılar imza kütüphanesinde bulunmaz. Minimum 3 katman şart: erişim kontrolü (MFA + SSH key + RBAC) + tespit (Imunify360 / ClamAV + Wazuh FIM) + kurtarma (immutable off-site yedek).

Immutable backup tam olarak nedir?

Immutable backup, yazıldıktan sonra belirlenen süre boyunca silinemez ve değiştirilemez (write-once). S3-uyumlu obje depolama servislerinde Object Lock — COMPLIANCE modu bunu garanti eder. Root dahil hiçbir kullanıcı saklama süresi dolmadan nesneyi silemez. Bu yüzden ransomware sisteme tam erişim kazansa bile bu yedeğe dokunamaz.

Imunify360 ransomware'ı tespit eder mi? Ne kadar güvenilir?

Imunify360 6.x; bilinen ransomware imzalarını, toplu dosya şifreleme davranışını ve web shell yüklemelerini gerçek zamanlı olarak tespit eder ve karantinaya alır. Ancak sıfır-gün varyantlar veya sistemde meşru kimlik bilgisiyle çalışan saldırılar için ek katman (Wazuh FIM, log izleme, immutable yedek) zorunlu. Imunify360 önemli bir savunma katmanıdır; tek başına yeterli koruma değildir.

Yedek aldım ama immutable değil — ne yapmalıyım?

Mevcut yedeğinizi koruyun (silinmeden önce başka lokasyona kopyalayın) ve bir an önce S3-uyumlu obje depolama ile Object Lock yapılandırmasını kurun. BorgBackup veya restic kullanıyorsanız, hedef depoyu immutable backend'e (object lock aktif bucket) taşıyın. Eski klasik yedeği de tutun — iki katman olsun.

Saldırı sonrası KVKK bildirimi zorunlu mu?

Şifreli veriler arasında kişisel veri varsa (müşteri adı, e-posta, telefon, IP, ödeme bilgisi) KVKK 12. madde kapsamında 72 saat içinde Kişisel Verileri Koruma Kurulu'na bildirim zorunludur. Bildirimi geciktirmek ek idari yaptırım riski doğurur.

---

İlgili Büyükweb Hizmetleri

Sunucu güvenliği için Imunify360 + JetBackup standart gelen paketler ve VDS çözümleri:

• cPanel Web Hosting — Imunify360 + CageFS + JetBackup dahil
• VDS Sunucu — KVM, root erişim, Veeam yedekleme, DDoS korumalı
• Fiziksel Dedicated Sunucu — Tam donanım kontrolü, IPMI
• OpenVPN Paketleri — Güvenli uzak erişim
• Datacenter Proxy

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.