Temiz yedek ile bulaşmış yedek nasıl ayırt edilir?

Temiz yedek ile bulaşmış yedek, yalnızca dosya adı, oluşturulma tarihi veya tek bir antivirüs taramasıyla kesin olarak ayırt edilemez. Güvenilir karar; yedeğin alındığı zamandaki olay kayıtları, dosya bütünlüğü, kötü amaçlı yazılım taraması, veritabanı incelemesi ve yedeği üretimden izole bir ortamda çalıştırma sonuçlarının birlikte değerlendirilmesiyle verilir. Yedek temiz görünse bile, belgelenmiş bütünlük, tarama ve izole geri yükleme değerlendirmesi yapılmadan canlı siteye geri yüklenmemelidir.

Temiz ve bulaşmış yedek ne demektir?​

Temiz yedek, alındığı sırada sisteme bulaşmış dosya, veritabanı içeriği, kullanıcı hesabı veya kalıcı saldırı mekanizması taşımadığına dair yeterli kanıt bulunan ve izole geri yükleme testini geçen yedektir. Bulaşmış yedek ise web kabuğu, gizli yönetici hesabı, değiştirilmiş eklenti, zararlı JavaScript, spam içeriği, şüpheli zamanlanmış görev veya veritabanına eklenmiş kalıcılık verisi gibi saldırı izlerini içerir.

Bir dosyanın adının ve tarihinin normal görünmesi güvenli olduğunu kanıtlamaz. Örneğin saldırgan, sıradan adlı bir PHP dosyasına ek kod yerleştirmiş olabilir. Uygulama dosyalarını aynı sürümün güvenilir dağıtımı ve doğrulanmış bütünlük kayıtlarıyla karşılaştırın; özelleştirmelerin meşru kaynağını ayrıca inceleyin. Benzer şekilde SHA-256 gibi bir özet yalnızca yedeğin sonradan değişip değişmediğini gösterir; yedeğin alındığı anda zaten bulaşmış olup olmadığını göstermez.

Uygulanabilir ayırt etme süreci​

Önce yedeği üretim sunucusundan ayrı, dışarıya açık olmayan bir inceleme ortamına kopyalayın. Asıl yedeği değiştirmeden, erişimi kısıtlı ve mümkünse salt okunur biçimde koruyun; incelemeyi özetini kaydettiğiniz çalışma kopyasında yapın. Arşivi güvenli açma araçlarıyla web kökü dışına çıkarın; arşiv yollarının inceleme dizini dışına yazmasına izin vermeyin. İnceleme ortamından üretim ağına ve internete çıkışı varsayılan olarak engelleyin. Özellikle e-posta, ödeme ve harici API kimlik bilgilerini etkinleştirmeyin. Şüpheli kodu kişisel bilgisayarınızda veya canlı sunucuda çalıştırmayın.

1. Yedeğin kaynağını ve zamanını belirleyin. Yedek alma görevi, sunucu erişim kayıtları, dosya değişiklik zamanları ve saldırının fark edildiği an ile karşılaştırılmalıdır. Saldırının başladıktan sonraki yedekleri otomatik olarak güvenli kabul etmeyin.
2. Yedeğin bütünlüğünü kontrol edin. Arşiv bozuk mu, beklenmeyen dosyalar eklenmiş mi ve yedek alınırken kullanılan doğrulama özetiyle mevcut özet aynı mı bakın. Bu kontrol, zararlı içeriği değil yalnızca aktarım veya sonradan değişiklik sorununu tespit eder.
3. Dosyaları ve yapılandırmayı tarayın. Web kökünde beklenmeyen çalıştırılabilir dosyaları, sonradan değişen çekirdek veya eklenti dosyalarını, gizli dosyaları, şüpheli kodlanmış içerikleri ve yazma izni gerekmeyen dizinlerdeki yeni dosyaları inceleyin. Taramayı mümkünse iki farklı yöntemle destekleyin; tek aracın temiz sonucu yeterli kanıt değildir.
4. Veritabanını ayrıca inceleyin. Bilinmeyen yönetici hesapları, değişmiş kullanıcı e-postaları, içerik içine eklenmiş script veya iframe'ler, beklenmeyen görev kayıtları ve sonradan eklenmiş yapılandırma değerleri arayın.
5. Yedeği izole ortamda geri yükleyin. Siteyi yalnızca yerel veya erişimi kısıtlı bir adresten açın; yönetim paneli, dosya yükleme, e-posta gönderimi ve dış servislere çağrı gibi işlevleri önce kapalı tutun.
6. Geri yüklenen sistemi gözlemleyin. Başlangıçta olmayan dosyalar oluşuyor mu, bilinmeyen süreç veya zamanlanmış görev çalışıyor mu, tarayıcı beklenmeyen adrese yönleniyor mu ve uygulama dış servislere şüpheli bağlantı kuruyor mu kontrol edin.
7. Şüphe giderilemiyorsa yedeği temiz kabul etmeyin. Daha eski bir yedeği aynı süreçten geçirin veya yalnızca doğrulanmış dosyaları yeni, güncel ve temiz bir kurulum üzerine kontrollü biçimde taşıyın.

Kanıtları nasıl yorumlamalı?​

Aşağıdaki bulgular tek başına kesin karar değildir; birlikte değerlendirilmelidir.


Örneğin saldırı pazartesi günü fark edilmiş, pazar gecesi alınan yedekte bilinmeyen bir yönetici hesabı ve yükleme dizininde yeni bir PHP dosyası bulunmuşsa bu yedek doğrudan canlıya yüklenmemelidir; bulguların kaynağı araştırılmalıdır. Cumartesi yedeği taramadan geçmiş olsa bile, izole geri yüklemede aynı dosya yeniden oluşuyorsa bulaşma veya geri yükleme sürecinin zararlı bir kaynağı vardır. Buna karşılık saldırıdan önce alınmış, kayıtları tutarlı, taramalarda şüpheli bulgu vermeyen ve izole ortamda beklenmeyen davranış göstermeyen yedek daha güçlü adaydır; yine de canlıya geçiş kademeli yapılmalıdır.

Temiz bir yedeğe dönmek ilk giriş açığını kapatmaz. Canlıya geçmeden önce uygulama ve bağımlılıkları güvenilir kaynaklardan güncelleyin, başlangıçtaki açığı giderin ve ele geçirilmiş olabilecek parolalarla erişim anahtarlarını temiz bir ortamdan yenileyin. Eski oturumları ve kalıcılık yollarını ayrıca değerlendirin. İnceleme kayıtlarını ve olay kanıtlarını erişimi kısıtlı biçimde saklayın.

Sık yapılan hatalar​

Yalnızca yedek tarihine güvenmek: Saldırganın sisteme ne zaman girdiği bilinmiyorsa tarih tek başına güvenlik göstergesi değildir.

Tek tarama sonucunu kesin kabul etmek: Yeni, gizlenmiş veya uygulamaya özel zararlı içerik her araç tarafından yakalanmayabilir.

Yedeği doğrudan canlıya açmak: Bulaşmış yedek, saldırganın erişimini yeniden etkinleştirebilir veya ziyaretçilere zararlı içerik sunabilir.

Yalnızca dosyaları incelemek: Yönetici hesapları, veritabanı kayıtları, görevler ve yapılandırma değerleri de saldırının parçası olabilir.

Kaynaklar​

• Canadian Centre for Cyber Security: zararlı yazılımdan kurtarma
• ASD: güvenlik olaylarına müdahale

Sık sorulan sorular​

Yedek parola korumalıysa temiz sayılır mı?​

Parola veya şifreleme, yedeğin yetkisiz kişilerce okunmasını ve değiştirilmesini zorlaştırır; içindeki zararlı içeriği temizlemez. İçerik yine inceleme ve izole geri yükleme sürecinden geçmelidir.

Yedeğin tarihini değiştirmek bulaşmayı gizler mi?​

Dosya tarihleri kopyalama, arşivleme veya geri yükleme sırasında değişebilir ve tek başına güvenilir kanıt değildir. Yedek alma görevinin kendi kayıtları, sunucu olayları ve dosya bütünlüğü kayıtları birlikte incelenmelidir.

Temiz yedek bulunamazsa ne yapılmalı?​

Bulaşmış olabilecek yedekten tüm sistemi geri yüklemek yerine, yeni ve güncel bir uygulama kurulumu hazırlayıp yalnızca doğrulanmış kullanıcı verilerini ve içerikleri tek tek taşımak daha güvenli yaklaşımdır. Taşınan her dosya ve veritabanı bölümü ayrıca incelenmelidir.

önce saldırının yaklaşık tarihini bulmak lazım log ve dosya değişiklik tarihlerine bakarak sonra o tarihten önceki yedeği ayrı bir ortamda açıp wp core dosyalarını orijinalle karşılaştırıyorum uploads içinde php dosyası var mı base64 eval gibi kod geçiyor mu diye tarıyorum temiz çıkanı geri yükleyip şifreleri değiştiriyorum