# Bulaşmış bir siteyi temizlemek: yöntem, ve geri yüklemenin neden her zaman yetmediği

> Bir yedeği yeniden kurmak en hızlı çözüm gibi görünür, ama bu hız ancak yedek gerçekten temizse bir işe yarar. İşte hedefli manuel temizlik ile geri yükleme arasında nasıl karar verileceği, ve eski bir bulaşmanın bu kararı neden göründüğünden daha zor kıldığı.

- Source canonique : [https://allaux.fr/tr/securite/nettoyer-un-site-infecte](https://allaux.fr/tr/securite/nettoyer-un-site-infecte)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Karar önce şu soruya bağlıdır: bulaşma ne zamandan beri aktif, ve bu tarihten kesinlikle önceki bir yedek var mı? Net bir yanıt yoksa, dosyaların ve veritabanının hedefli manuel temizliği, sorunu bir gecikmeyle yeniden kurabilecek bir geri yüklemeden daha güvenilir kalır.

## İki yaklaşım, önce karara bağlanması gereken tek bir soru

Bir yedeği geri yüklemek, siteyi belirli bir tarihteki tam hâline döndürür. Bu hızlıdır, ama yalnızca bu tarih bulaşmanın gerçek başlangıcından önceyse işe yarar, sorunun fark edildiği andan önce olması yetmez: bunlar neredeyse her zaman birbirinden farklı iki tarihtir.

Hedefli manuel temizlik, enjekte edilen kodu ve saldırganın eklediği hesap veya erişimleri tam olarak tespit edip, sıfırdan başlamadan bunları kaldırmak anlamına gelir. Daha fazla inceleme süresi gerektirir, ama temiz bir yedeğin var olup olmamasına bağlı değildir.

Bu iki yaklaşım her zaman birbirine zıt değildir: eski ve güvenilir bir yedek, siteyi yeniden yayına almak için olduğu gibi kullanılmasa bile, dosyaları karşılaştırmak için bir referans olarak kullanılabilir.

## Açık ile keşif arasındaki farkı gösteren belgelenmiş bir örnek

2014 yılında Sucuri, WordPress için Slider Revolution eklentisindeki bir açıkla bağlantılı SoakSoak adıyla bilinen kampanyayı belgeledi. Düzeltme, geliştirici tarafından zaten Şubat 2014’te yayınlanmıştı, ancak bu açığın kitlesel istismarı ancak aynı yılın Eylül ile Aralık ayları arasında gözlemlendi; özellikle site sahibinin bilgisi dışında eklentinin eski bir kopyasını içeren temalar üzerinden.

Bu örnek basit bir noktayı gösteriyor: bir bulaşmanın fark edildiği an, gerçekten ne zaman başladığı hakkında hiçbir şey söylemez. Bu nedenle haftalarca, hatta aylarca eski bir yedek, etkinleşene kadar sessiz kalmış kötü amaçlı kodu zaten içeriyor olabilir.

## Kısmi geri yükleme tuzağı

> Bir bulaşma hem dosyalarda, enjekte edilmiş kod veya eklenmiş bir dosya olarak, hem de veritabanında, CMS’e göre içerik veya yapılandırma alanlarında yer alabilir. Sorunu çözdüğünü düşünerek yalnızca dosyaları veya yalnızca veritabanını geri yüklemek en sık yapılan hatalardan biridir: geri yüklenmeyen taraf, site yeniden yayına alınır alınmaz bulaşmayı diğer tarafa yeniden bulaştırmaya yetebilir.

## Basit bir dosya karşılaştırmasının kapsamadığı bir yer

PrestaShop’ta, çekirdek dosyaları aynı sürümün temiz bir kurulumuyla karşılaştırmak, değiştirilmiş çekirdek dosyalarını ortaya çıkarır. Ancak bir sınıfı veya denetleyiciyi orijinal dosyaya dokunmadan meşru şekilde genişletmeyi sağlayan override sistemi, bu otomatik karşılaştırmanın dışında kalır: override/ içine yerleştirilen bir dosyanın özel kod içermesi zaten beklenir, bu yüzden kötü amaçlı bir override belirgin bir fark yaratmadan içine karışır. Bu klasör, yalnızca otomatik bir karşılaştırmayı değil, satır satır bir incelemeyi hak eder.

## Adım adım yöntem

- **Sitenin hâlâ ele geçirilmiş olup olmadığını denetlemek** — Temizliği bitmiş saymadan önce, bulaşmanın gerçekten gidip gitmediğini söyleyen kontroller. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Temizlikten önce, ilk iki saat** — Bir ele geçirilme doğrulandığında izlenecek ilk adımların tam sırası. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))
- **Temizlikten sonra, neyin değişmesi gerektiği** — Kısa vadede tekrarını önleyen yapısal alışkanlıklar. ([/securite/se-proteger-apres-un-nettoyage](/securite/se-proteger-apres-un-nettoyage))

## FAQ

### Aylar önce alınmış bir yedek otomatik olarak güvenilir midir?

Hayır. Yalnızca bulaşmanın gerçek başlangıcından önceyse güvenilirdir, bu da nadiren kesin olarak bilinir. Bir yedeğin eski olması bir ipucudur, garanti değildir.

### Önce dosyaları mı yoksa veritabanını mı geri yüklemeliyim?

İkisinden hiçbiri tek başına yeterli değildir. Her ikisini de etkileyen bir bulaşma, yalnızca bir tarafı düzeltilirse ortadan kalkmaz: dosyalar ve veritabanı birlikte kontrol edilmeli ve gerekirse birlikte geri yüklenmelidir.

### Sitemin ne zamandan beri bulaşmış olduğunu nasıl anlarım?

Dosya değiştirilme tarihleri ilk bir ipucu verir, ancak değiştirilebilecekleri için dikkatle ele alınmalıdır; buna mevcut yedeklerin geçmişi, saklanmışsa erişim günlükleri ve ilk belirtilerin müşteriler veya Google tarafından ne zaman bildirildiği de eklenir.

### Manuel temizlik kod bilmeyi gerektirir mi?

Evet, özellikle özel kod içermesi beklenen override/ gibi bir klasörde, meşru kodu enjekte edilmiş koddan kesin olarak ayırt edebilmek için. Bu yüzden bu adım genellikle tek başına otomatik bir temizlik aracına değil, bir geliştiriciye düşer.

### Otomatik bir temizlik tarayıcısı manuel temizliğin yerini tutabilir mi?

Zaten bilinen kötü amaçlı yazılım imzalarını kaldırabilir, ama özel yazılmış kodu veya kötüye kullanılmış meşru bir override’ı çoğu zaman kaçırır. Manuel bir kontrolün yerine değil, yanında faydalıdır.