Bir Blog Çöküşünün Anatomisi:
Bilişim dünyasında çok bilinen bir kural vardır: “Yedek almayanlar ve yedek aldığını sananlar.”
Ancak bazen öyle bir an gelir ki, aldığınız yedekler bile sunucu odalarındaki o görünmez kilitlerin arkasında esir kalır. Geçtiğimiz günlerde ademhelvaci.com üzerinde tam olarak bunu yaşadım. Gemini ile birlikte günlerce uykusuz kalarak, sunucu loglarının arasında adeta adli tıp uzmanı gibi iz sürdüğümüz, her aşamasında yeni bir barikatla karşılaştığımız siber mücadeleyi, bu dertten muzdarip olan herkese bir deniz feneri olması adına en ince ayrıntısına kadar kronolojik bir hikaye olarak kaleme aldım.
Her şey, 13 Mayıs tarihinde mail adresime sabahın 5 inde gelen ama benim uyandığımda gördüğüm şu mail ile başladı;
Her zamanki zararlı yazılım içerikli maillerden diye düşündüm ama birkaç saat sonra da bu sefer gmail hesabımdan şu uyarı geldi.
Bu noktadan sonra durumu daha ciddi ele alıp tüm hesapların tek tek kontrollerini yapmaya başladım ve aslında tüm haltı yiyenin ben olduğuma dair ciddi şüphelerim oldu zira birkaç gün önce aldığım şu şekilde bir uyarıyı dikkate almamıştım.
Bu yazı; sıradan bir “404 sayfa bulunamadı” hatasının değil, arka plana sinsice sızan bir zararlı yazılımın (malware) koca bir sistemi nasıl felç edebileceğinin ve o sistemin tırnaklarla kazınarak nasıl geri döndürüldüğünün hikayesidir.
Bölüm 1: Truva Atı Kapıda (9 Mayıs – Sinsice Atılan İlk Tohum)
Her şey 9 Mayıs tarihinde, sitenin ön yüzünde hiçbir anormallik yokken başladı. Saldırganların son dönemde en çok kullandığı ve son kullanıcının en kolay aldandığı yöntemlerden biri devreye sokulmuştu: Fake Captcha (Sahte Robot Doğrulama Sistemi).
Sitenin eklenti açıklarından veya temadaki zafiyetlerden sızan illegal bir script, sunucu seviyesinde kendini arka plana kopyaladı. Ziyaretçilere veya site yöneticisine çaktırmadan arka planda çalışan bu sistem, WordPress’in çekirdek yapısına müdahale etmeye başlamıştı bile. Zararlı yazılımın ilk hedefi sitenizi kapatmak veya indexlerinizi bozmak değildir; ilk hedef her zaman içeride kalıcılık sağlamaktır.
Bölüm 2: İlk Belirtiler ve Gizli Ortaklar (11 Mayıs)
Zararlı yazılım kuluçka süresini tamamladıktan tam iki gün sonra, 11 Mayıs’ta sitenin kimyasını değiştirmeye başladı. WordPress yönetim panelinde (wp-admin) normal şartlarda asla olmaması gereken, sistem tarafından tanınmayan yeni ve “Tam Yetkili” (Administrator) kullanıcılar belirdi.
Saldırganlar, oluşturdukları bu hayalet yöneticiler sayesinde WordPress veri tabanındaki wp_users ve wp_usermeta tablolarına kendi imza kodlarını attılar. Biz o sırada WordPress güvenlik uyarılarını ve DirectAdmin paneli üzerindeki anomalileri incelemeye başlarken, siber korsanlar sitenin kalbini çoktan avuçlarının içine almıştı.
Bölüm 3: Büyük Çöküş ve Sistem Kilitleri
O sinsice yürütülen operasyon nihayet meyvesini verdi ve site tamamen erişilemez hale geldi. Tarayıcıya ademhelvaci.com yazıldığında ne ana sayfa açılıyor ne de yönetim paneline ulaşılabiliyordu. Sistem tamamen karanlığa gömülmüştü.
İlk refleks olarak DirectAdmin paneline koşup kontrol sağladığımızda, sistemin üzerine adeta bir beton döküldüğünü gördük. Sorun sadece WordPress tabanlı değildi; sunucu katmanında da işler birbirine girmişti. Bir gün önce “nasılsa çalışıyor” diyerek göz ardı edilen o küçük uyarılar, o gün koca bir çığ olarak karşımıza dikildi.
Bölüm 4: Adli Tıp Başlıyor – Zararlıyı Nerede ve Nasıl Bulduk?
Birçok web yöneticisinin yaptığı en büyük hata, site çöktüğünde hemen “en son yedeği geri yükle” butonuna basmaktır. Oysa zararlı yazılım temizlenmeden yapılan geri yüklemeler, virüslü dosyayı tekrar tekrar döngüye sokmaktan başka bir işe yaramaz. Biz öyle yapmadık; kolları sıvadık ve sunucunun derinliklerine indik.
1. İz Sürme: Sunucu Loglarının Çözülmesi
İlk olarak DirectAdmin üzerinden sunucunun canlı hata günlüklerini (Error Logs) incelemeye aldık. Karşımıza çıkan tablo siber saldırının imza haritasıydı:
Plaintext
[ERROR] [HTAccess] Failed to open [.../public_html/.htaccess]: Permission denied
File not found [.../public_html/404.shtml]
Cannot found appropriate handler for [/404.shtml]
Bu log satırları bize çok kritik iki şey fısıldıyordu:
- Sitenin tüm URL yönlendirmelerini, kalıcı bağlantılarını ve güvenlik duvarını yöneten
.htaccessdosyası sunucu tarafından okunamaz hale getirilmişti. İzinleri (Permissions) tamamen kilitlenmişti. - Sitenin kendi içindeki
404.shtmlgibi temel hata sayfaları bile zararlı yazılım tarafından silinmiş veya konumu değiştirilmişti. Dışarıdan gelen botlar süreklixmlrpc.phpvewp-login.phpgibi kapıları zorlarken, sunucu bu isteklere yanıt verecek mekanizmayı bulamıyordu.
2. Saklanan Kodların Yuvası: O Zararlı Yazılımları ve Google Jetonlarını Nerede Yakaladık?
Birçok web yöneticisinin gözden kaçırdığı, “Sitem temizlendi ama Google aramalarında hâlâ garip sitelere yönleniyor” dediği asıl büyük tezgahı burada, hosting ekibiyle açtığımız o kritik destek talebinde (ticket) yakaladık. Saldırganlar sadece arka kapı bırakmamış, ademhelvaci.com’un Google arama motorundaki otoritesini tamamen sömürmek için Google Search Console sahipliğini ele geçirecek bir sistem kurmuşlardı.
İşte kök dizinden (public_html) kazıyarak temizlediğimiz o asıl suçlular:
public_html/goods.phpvepublic_html/shops.php(İllegal Galeri ve Yönlendirme Scriptleri): Doğrudan ana dizine bırakılan bu iki dosya, sitenizin SEO itibarını bitirmek üzere tasarlanmıştı. Siz fark etmeden arka planda botlar vasıtasıyla Google’a binlerce sahte ürün, illegal galeri ve bahis/alışveriş linki indexletiyorlardı. Bir ziyaretçi Google aramalarından sitenize gelmeye çalıştığında, bu iki dosya devreye girip trafiği korsanların kendi illegal ağlarına yönlendiriyordu.- Yabancı
.htmlDoğrulama Jetonları (Google Search Console Sahiplik Korsanlığı): Fark ettik kipublic_htmldizininin içinegoogle1234567890abcdef.htmlgibi rastgele isimlere sahip yabancı doğrulama dosyaları (jetonlar) bırakılmıştı. Saldırganlar bu dosyalar sayesinde Google’a “Bu sitenin sahibi benim” diyerek kendi Search Console hesaplarını siteye bağlamışlardı. Bu sayede sitenin tüm arama trafiğini, dizine ekleme (index) yetkilerini ve Google üzerindeki tüm kontrolünü kendi panellerine çekiyorlardı. Eğer bu.htmljetonlarını kök dizinden temizlemeseydik, dosyaları ne kadar silersek silelim Google gözünde siteyi asla geri kazanamayacaktık. public_html/wp-includes/wp-vcd.php(Sistemik Arka Kapı): WordPress’in çekirdek dosyalarının arasına gizlenen bu kod ise, yukarıdaki tüm bu yapay indexleme ve doğrulama süreçlerini yöneten, veri tabanında hayalet yöneticiler (Administrator) yaratan ana kumanda merkeziydi.
Bu hain planı; yani goods.php ve shops.php gibi sinsi yönlendirme dosyalarını kök dizinden silip, Google Search Console’u korsanların elinden kurtaran o yabancı .html doğrulama jetonlarını tek tek ayıklayarak bozduk. Ancak bu temizlikten sonra sunucu rahat bir nefes aldı ve dosya izinleri normale döndü.
Bölüm 5: Büyük Mücadele – Adım Adım Çözüm Yolu
Sorunun kaynağını, yerini ve boyutunu netleştirdikten sonra operasyonu başlattık. Eğer siteniz komple çöktüyse ve yedekleme sistemleriniz “kısmen tamamlandı” (partially completed) hatası veriyorsa, kurtuluş için uygulayacağınız altın reçete şudur:
Adım 1: Kaspersky ve SSL Barikatlarını Aşmak
DirectAdmin paneline erişmeye çalışırken Kaspersky gibi güçlü antivirüs yazılımları veya tarayıcılar, sunucunun SSL sertifikasındaki uyuşmazlıklar nedeniyle paneli tamamen bloklayabilir. Burada sakin kalıp yazılım üzerinden geçici istisna tanımlayarak panele güvenli erişimi sağladık. Sunucu sertifikasını Let’s Encrypt üzerinden panel portları (:2222) dahil olacak şekilde yeniden tetikleyip yeniledik.
Adım 2: Dosya İzinlerini ve Sahipliğini Sıfırlamak
Zararlı yazılımın dosya izinlerini 000 yapması veya kullanıcı sahipliğini (Owner) değiştirmesi nedeniyle Dosya Yöneticisi’nden işlem yapmak imkansızlaşabilir.
- Sitenin kök dizinindeki (
public_html) kilitleri açmak için DirectAdmin üzerinden toplu dosya izni sıfırlama (Reset Permissions) uyguladık. Klasörlerin755, dosyaların ise644izin koduna geri dönmesini sağladık. - Bu işlem, sunucunun yeniden
.htaccessve diğer çekirdek dosyaları okuyabilmesinin önünü açtı.
Adım 3: Kilitli .htaccess Dosyasını Manuel Sıfırlamak
Mevcut .htaccess dosyası o kadar deforme olmuştu ki, en temiz çözüm onu sistemden elemekti.
- Dosya Yöneticisi’ne girerek mevcut virüslü
.htaccessdosyasını tamamen sildik. (JetBackup’ın sistem güvenliği için kenara ayırdığı.htaccess.bkyedeğini ise referans olarak sakladık). - Yerine bomboş, temiz bir metin belgesi oluşturup adını
.htaccessyaptık ve izin kodunu644olarak atadık.
Adım 4: WordPress Kalıcı Bağlantılarını (Permalinks) Canlandırmak
Dosya kilitleri açılır açılmaz sitenin veri tabanı bağlantısı yerine geldi ve WordPress yönetim paneli (wp-admin) tekrar erişilebilir oldu. Panel açılır açılmaz ilk iş olarak Ayarlar -> Kalıcı Bağlantılar sekmesine girdik. Sayfada hiçbir ayarı değiştirmeden en alttaki “Değişiklikleri Kaydet” butonuna bastık. Bu hamle, WordPress’in az önce oluşturduğumuz o bomboş .htaccess dosyasının içerisine sıfır, temiz ve hatasız yönlendirme kodlarını yazmasını sağladı.
Adım 5: Veri Tabanı Motorunun Kontrolü
phpMyAdmin’e girerek wp_options tablosunu seçtik. Modern sistemlerde InnoDB motoru kullanıldığı için klasik “Tabloyu Onar” (Repair Table) komutunun bu motor tarafından desteklenmediğini gördük. Ancak dosya izinleri ve sahiplikleri (Ownership) bir önceki adımda başarıyla sıfırlandığı için, InnoDB motoru kendi içindeki otomatik kurtarma (Crash Recovery) mekanizmasını devreye soktu ve tabloyu el ile onarmaya gerek kalmadan sistem verileri eksiksiz şekilde okumayı başardı.
Sistem Nasıl Kurtuldu?
Bütün bu uykusuz gecelerin, log analizlerinin ve manuel müdahalelerin sonucunda; ademhelvaci.com üzerindeki 6 sayfalık konu başlığının tamamı, makalelerin içerisindeki tüm teknik görseller ve veri tabanındaki tüm kullanıcı yorumları tek bir veri kaybı bile yaşanmadan %100 oranında kurtarıldı.
Sitenin ön yüzü ve yönetim paneli stabil haline geri döndü. Sunucu loglarındaki o kırmızı alarm veren Permission denied hataları yerini temiz trafik akışına bıraktı.
Son Kullanıcıya Altın Değerinde Tavsiyeler (Bu Dersten Ne Çıkarmalıyız?)
Eğer bir gün sizin de web siteniz bu duruma düşerse veya düşmesini istemiyorsanız, bu mücadeleden çıkartacağınız hayati dersler şunlardır:
- Küçük Uyarıları Asla İhmal Etmeyin: Panelinizin köşesinde beliren “2 Yeni Uyarı” veya “SSL Sertifikası Uyuşmazlığı” gibi bildirimler, iki gün sonra gelecek olan büyük çöküşün ayak sesleridir. O uyarıyı ilk gördüğümüz gün üzerine gitseydik, kriz bu boyuta ulaşmayacaktı.
- Yedekleme Konumunu Sunucu Dışına Taşıyın: Yedeklerinizin sunucuyla aynı diskte durması büyük bir kumardır. Bizim yaşadığımız gibi dosya izinleri kilitlendiğinde, yedekleme eklentiniz (JetBackup vb.) kendi yedek dosyasına bile erişemez ve “kısmen tamamlandı” diyerek yarı yolda kalır. Yedeklerinizi mutlaka harici bir bulut depolamaya veya yerel bilgisayarınıza senkronize edin.
- Sadece Temizliğe Değil, Güvenliğe Odaklanın: Sitenizi kurtardıktan sonra mutlaka
xmlrpc.phpisteklerini kapatın, WordPress giriş yolunu (wp-login.php) değiştirin ve iki faktörlü doğrulamayı (2FA) aktif edin. Korsanların içeride bıraktığı hayalet yöneticileri temizlemek için veri tabanındakiwp_userstablosunu gözünüzle kontrol edin.
Unutmayın; siber dünyada mutlak güvenlik yoktur, ancak doğru teşhis, soğukkanlı lojistik ve doğru müdahale her zaman hayat kurtarır!
Ayrıca, web sitesinden 1 gram dahi anlamayan birisi olarak özellikle Yapay Zekâ faktörünün burada çok ciddi rol oynadığını hatta başrolün O olduğunu belirtmek isterim. Diğer yandan Güzel Hosnting ekibine de teşekkür ediyorum.
Sevgilerimle.