Site açılmıyor, ana sayfada tanımadığınız bir mesaj var ya da arama sonuçlarında sitenizin altında bir uyarı beliriyor. Bu anda verilen en pahalı karar, panikle her şeyi silmektir. Aşağıdaki sıra hem siteyi geri getirir hem de aynı kapının ikinci kez kullanılmasını engeller.
İlk 60 dakika: önce ne yapmayacağınıza karar verin
Sık görülen refleks, FTP'ye bağlanıp şüpheli dosyaları tek tek silmektir. Bu üç sorun yaratır: kanıtı yok edersiniz, gözden kaçan bir arka kapı ile aynı gece tekrar girilir, neyin değiştiğini kimse bilemez. Bunun yerine:
- Siteyi kapatmadan önce anlık bir kopya alın: dosya sistemi ve veritabanı, olduğu haliyle. Kopyayı sitenin sunucusundan başka bir yere koyun.
- Sunucu ve uygulama kayıtlarını ayrı bir yere indirin: nginx/Apache erişim ve hata logları, PHP-FPM logu, uygulamanın kendi kaydı. Varsayılan logrotate ayarlarında bu dosyalar günlük döner, yani bir gün beklerseniz kanıt gider.
- Kimin ne zaman ne yaptığını yazacağınız bir zaman çizelgesi açın; kriz sonrası en çok bu belge işinize yarar.
Adım 1: Yayını durdurun, sunucuyu kapatmayın
Ziyaretçiye zarar veren bir sayfa yayında kalmamalı. Doğrusu, siteyi bakım moduna alıp geçici olarak 503 durum kodu döndürmek ve yanına Retry-After başlığı koymaktır; bu, arama motorlarına sayfaların kalıcı olarak kaybolmadığını söyler. Ödeme alan bir siteyseniz sağlayıcınızla iletişime geçip şüpheli süredeki işlemleri işaretleyin. Sunucuyu tamamen kapatmayın; çalışan süreçler ve dönmemiş loglar hâlâ inceleyeceğiniz canlı veridir.
Adım 2: Giriş noktasını bulun
Bu adımı atlarsanız yaptığınız her şey geçici olur. İzlenecek beş yol:
- Zaman ekseninden gidin. Sitenin bozulduğu saati tespit edin, o tarihten sonra değişen dosyaları listeleyin: find /var/www/site -type f -newermt "2026-08-20". Beklenmedik bir zamanda değişmiş çekirdek dosyaları en güçlü ipucudur.
- Yükleme klasörlerine bakın. Görsel klasöründe .php, .phtml ya da .phar uzantılı bir dosya varsa giriş noktası büyük olasılıkla oradadır.
- Erişim kayıtlarını tarayın. Şüpheli dosyaya yapılan ilk POST isteğini bulun: grep "shell.php" access.log | head. O isteğin IP'siyle geriye doğru gidip aynı IP'nin hangi sayfadan yükleme yaptığını çıkarabilirsiniz.
- Şüpheli kod desenlerini arayın. Uzun base64 blokları, iç içe geçmiş çözme fonksiyonları, dinamik fonksiyon çağrıları ve tek satıra sıkıştırılmış devasa dosyalar tipik işaretlerdir. Hızlı bir tarama: grep -rEl "base64_decode|gzinflate|assert" /var/www/site.
- Yönetici hesaplarını sayın. Yeni eklenmiş bir yönetici ya da e-postası değiştirilmiş bir hesap, girişin panelden yapıldığını gösterir. Kullanıcı tablosunda oluşturma tarihine göre sıralayıp son bir ayı gözden geçirin.
Bulduğunuz her ipucunu zaman çizelgesine yazın. Genellikle üç ihtimalden birine varırsınız: güncellenmemiş bir bileşen, sızmış bir yönetici parolası, korumasız bir yükleme alanı.
Adım 3: Temizlemeyin, temiz kurun
Bulaşmış bir kod tabanını el yordamıyla temizlemek, gizli arka kapıların yaşamasına izin verir. Doğru yaklaşım şudur:
- Uygulamanın çekirdek dosyalarını, temayı ve eklentileri orijinal kaynağından yeniden kurun; sürümleri de güncel olanla değiştirin.
- Eski kurulumdan sadece iki şeyi taşıyın: kullanıcı yükleme klasörü ve veritabanı. İkisini de taşımadan önce inceleyin.
- Yükleme klasöründe yalnızca beklediğiniz uzantılara izin verin, geri kalanı silin; klasörde PHP çalıştırmayı sunucu düzeyinde kapatın.
- Veritabanında içerik alanlarını script etiketi, iframe ve gizli bağlantı açısından tarayın. Enjekte spam bağlantıları çoğunlukla yazı, sayfa ve ayar tablolarında saklanır.
- Zamanlanmış görevleri kontrol edin: crontab -l, sistem cron dizinleri ve uygulamanın kendi görev tablosu. Oraya eklenmiş tek bir satır, siz temizledikten sonra zararlı dosyayı geri getirir.
Adım 4: Bütün sırları değiştirin
Saldırgan yapılandırma dosyanızı okuduysa elindeki her anahtar hâlâ geçerlidir. Sırayla döndürün:
- Veritabanı kullanıcı parolası ve mümkünse kullanıcı adı
- Bütün yönetici parolaları ve varsa API anahtarları
- SMTP bilgileri; sitenizden spam gönderilmesinin en yaygın yolu budur
- Ödeme sağlayıcı ve kargo entegrasyonu anahtarları
- Oturum/şifreleme anahtarı; değiştirdiğinizde tüm açık oturumlar düşer, bu istediğiniz sonuçtur
- Hosting paneli, FTP ve SSH erişimleri; SSH'ta parolayla girişi kapatıp anahtara geçin
Adım 5: Yeniden açılış ve sonrası
| Zaman | Yapılacak | Yapılmayacak |
|---|---|---|
| İlk saat | Kopya al, logları indir, bakım moduna geç | Dosya silmek |
| 1-4 saat | Giriş noktasını bul, zaman çizelgesini yaz | Yedeği hemen geri yüklemek |
| 4-12 saat | Temiz kurulum, veri taşıma, sır döndürme | Eski eklentileri aynı sürümle geri koymak |
| Açılış günü | 2FA kur, hız sınırı ekle, izlemeyi aç | Bakım modunu kanıtlamadan kaldırmak |
| İlk hafta | Arama motoru araçlarında uyarı takibi, log gözden geçirme | Olayı belgelemeden kapatmak |
Yeniden açmadan önce şu kontrol listesini işaretleyin: giriş noktası yazılı olarak belirlendi mi, çekirdek dosyalar orijinal kaynaktan mı kuruldu, yükleme klasöründe PHP çalışması kapatıldı mı, altı sır kalemi de döndürüldü mü, yönetici hesaplarında 2FA açık mı, giriş ekranında deneme sınırı var mı, dosya değişikliklerini haber veren bir izleme kuruldu mu. Açtıktan sonra arama motoru yönetim araçlarında güvenlik bildirimi olup olmadığını kontrol edin ve varsa inceleme talebi gönderin. Saldırganın ürettiği spam adresleri hâlâ dizinlerdeyse bunları 410 durum koduyla kapatmak, 404'e göre daha net bir sinyal verir.
KVKK tarafını atlamayın
Sızan verilerin arasında müşteri adı, telefonu, adresi ya da sipariş bilgisi varsa bu bir veri ihlalidir ve teknik bir konu olmaktan çıkar. Kişisel Verileri Koruma Kurulunun ihlal bildirimine ilişkin ilke kararı, veri sorumlusunun ihlali öğrendiği andan itibaren gecikmeksizin ve en geç 72 saat içinde Kurula bildirmesini, ilgili kişilere de makul olan en kısa sürede haber verilmesini öngörür. Süre ve form güncellenebildiği için bildirimden önce Kurumun yayımladığı güncel metni teyit edin. Pratikte hazır olmanız gereken dört başlık şudur: hangi verinin etkilendiği, kaç kişiyi ilgilendirdiği, ihlalin ne zaman gerçekleştiği ve hangi önlemleri aldığınız. Bunları olay sırasında not aldıysanız bildirim birkaç saatlik iştir; almadıysanız günlerce sürer.
Sık yapılan hatalar
- Yedeği geri yükleyip işi bitmiş saymak. Açık kapatılmadıysa aynı yedek aynı şekilde ele geçirilir.
- Hangi tarihteki yedeğin temiz olduğunu bilmemek; bulaşma çoğu zaman fark edilmesinden çok önce başlar, birkaç kuşak geriye bakın.
- Yedekleri sitenin kendi sunucusunda tutmak. Saldırgan orayı da siler.
- Sadece dosyaları temizleyip veritabanındaki enjekte edilmiş içeriği atlamak.
- Müşterilere hiçbir şey söylememek. Sessizlik, ihlal başka bir yerden duyulduğunda güveni tamamen bitirir.
- Olay bittikten sonra hiçbir şey değiştirmemek: ne 2FA, ne güncelleme takvimi, ne izleme.
Özet
- Silmeden önce kopya alın ve logları güvenli bir yere indirin.
- Giriş noktasını bulmadan yeniden yayına almayın.
- Temizlemek yerine temiz kurun; sadece yükleme klasörünü ve veritabanını, kontrol ederek taşıyın.
- Veritabanından SMTP'ye kadar bütün sırları değiştirin, oturumları düşürün.
- Kişisel veri etkilendiyse bildirimi hazırlayın ve olayı yazılı olarak belgeleyin.
