WordPress güvenlik problemleri

WordPress güvenlik problemleri: “wordpress hacklendi”, “siteye spam düştü”, “malware wordpress” vakalarında doğru sıra ile teşhis ve kalıcı çözüm

WordPress tarafında “wordpress hacklendi”, “siteye spam düştü”, “malware wordpress” gibi aramalar genelde panikle başlar. Panik anlaşılır ama çözüm üretmez. Bu işte doğru yaklaşım nettir: önce hasarı durdur, sonra delili kaybetmeden teşhis et, ardından sistematik şekilde temizle ve en son kalıcı sertleştirmeyi uygula. “Bir dosyayı sildim geçti” yaklaşımıyla uğraşırsan, aynı vaka farklı kılıkta geri gelir.

Gerçek tabloyu açık söyleyelim: açıkların ezici çoğunluğu WordPress çekirdeğinden değil; üçüncü taraf eklenti/tema ekosisteminden, kötü bakım disiplininden ve gevşek yapılandırmadan çıkar. Çekirdek hatasız değildir ama çekirdek, eklenti pazarının karmaşasıyla kıyaslanınca çok daha sıkı denetlenir. Bu yüzden suçluyu doğru yerde aramak zorundasın.

Bu makale, pratik bir “olay müdahale” rehberidir. Ayrıca performans tarafında şu gerçeği unutmayacağız: doğru yapılan Web Site Hızlandırma saldırı yüzeyini küçültür; yanlış yapılan Web Site Hızlandırma ise güvenliği zayıflatır. Yani hız ve güvenlik kavga etmek zorunda değil, ama disiplinsiz kurulum ikisini de bozar.

Belirtiler: Hack, spam ve yönlendirme (redirect) nasıl anlaşılır?

Hack belirtileri

Admin paneline girememe, şifrelerin kendi kendine değişmesi, bilmediğin kullanıcıların türemesi, eklenti/tema listesinde “senin kurmadığın” parçalar, sunucu CPU/RAM kullanımında ani artış, dosya tarihleri ile oynanması, beklenmedik 500 hataları, wp-admin içinde garip uyarılar… Bunların her biri “olay var” demektir.

Spam belirtileri (SEO spam, gizli sayfalar, pharma/casino)

Google’da site adınla arayınca alakasız başlıkların çıkması, arama sonuçlarında “casino/pharma” gibi kelimelerin görünmesi, site içinde görünmeyen ama indekslenen sayfalar, sitemap içine spam URL’lerin karışması, içeriklerin altına gizli link eklenmesi… Bu vakalarda saldırı bazen dosyada değil veritabanında saklanır.

Yönlendirme (redirect) belirtileri

Kullanıcı siteye girince başka bir domaine atması, sadece mobilde yönlendirme olması, yalnızca Google’dan gelen trafikte redirect görülmesi, belirli ülkelerden gelenlerde farklı davranması… Bu tip saldırılar “koşullu” çalışır. Sen test ederken görmeyebilirsin; bot gibi test etmen gerekir.

En kritik kural: Doğru sırayı uygula (önce durdur, sonra temizle, en son güçlendir)

Bu kısım “işin eskiden beri doğru yapılış şekli”dir ve hâlâ en güvenilir yöntem budur. Sıra bozulursa hem zaman kaybedersin hem de yanlış temizlikle izleri silersin.

Adım 1: Hasarı durdur (izinsiz erişimi kes, yayılmayı engelle)

Önce admin parolalarını değiştir, mümkünse tüm yönetici hesaplarda 2FA zorunlu kıl, şüpheli oturumları sonlandır. Şüpheli eklentileri kapatmadan önce bir yedek al (delil için), sonra saldırıyı yaymayı engelle. Eğer saldırı aktif spam üretip siteyi zehirliyorsa geçici bakım modu kullanmak mantıklıdır.

Adım 2: Şüpheli admin kullanıcıları (ilk kontrol)

“İlk kontrol” dediğin yerde en hızlı sonuç şurada çıkar: kullanıcı listesi. Bilmediğin bir admin hesabı varsa, bu genellikle “kalıcılık” kapısıdır. Saldırganlar çoğu zaman kendilerine admin açar; adı “support”, “manager”, “wpadmin” gibi masum durur. Burada romantizm yok: kimseyi tanımıyorsan o hesap şüphelidir.

WP-CLI kullanıyorsan yöneticileri listelemek çok hızlıdır:

wp user list --role=administrator

Şüpheli kullanıcıyı silerken içeriği kime devredeceğini belirle (aksi halde içerik sahipsiz kalır):

wp user delete KULLANICI_ID --reassign=MEVCUT_ADMIN_ID

WP-CLI yoksa panelden kontrol yap, ama mutlaka şu üç detayı incele: e-posta adresi, kayıt tarihi, son giriş izi (varsa). Şüpheli admin “hemen” pasife alınmalı.

Adım 3: Dosya bütünlüğü (çekirdek ve kritik dosyalar değişmiş mi?)

Dosya bütünlüğü kontrolü sana şunu söyler: bulaşma çekirdeğe kadar inmiş mi, yoksa wp-content altında mı kalmış? Çekirdek dosyalar değişmişse iş ciddidir; temiz kaynakla çekirdeği yenilemek gerekir.

WP-CLI ile çekirdek checksum doğrulaması:

wp core verify-checksums

Uyumsuzluk varsa çekirdeği yeniden indirmek daha sağlamdır:

wp core download --force

Bu adım, “tek tek dosya ayıklama”dan daha güvenilirdir. Çünkü saldırgan çoğu zaman birden fazla noktaya tutunur.

Adım 4: Güncelleme/patch disiplini (asıl zayıf halka burada çıkar)

WordPress güvenliği pratikte “patch disiplini”dir. Güncellenmeyen eklenti/tema, saldırgan için davetiyedir. Bu yüzden üç liste çıkar:

1) Uzun süredir güncellenmeyen eklentiler

2) Kullanılmayan ama sistemde duran eklentiler (pasif olanlar dahil)

3) Tema/child tema içinde override edilen parçalar

Pasif eklenti “zararsız” değildir. Dosya sisteminde duruyorsa hedef olur. Gereksiz olanı kaldırmak gerekir. Hem güvenlik hem Web Site Hızlandırma için en temiz başlangıç budur: az eklenti, az risk, az yük.

Eklenti listesini hızlı görmek:

wp plugin list

Gereksiz eklentiyi tamamen kaldırmak:

wp plugin delete eklenti-slug

Temizleme: Malware nerede saklanır ve nasıl bulunur?

1) En sık saklanma bölgeleri

Şu klasörlere “özellikle” bakılır: wp-content/uploads, wp-content/mu-plugins, wp-content/plugins, tema klasörü, wp-includes içine kaçak eklenen dosyalar, wp-config.php ve .htaccess. uploads içinde PHP dosyası görmek çoğu vakada kötüye işarettir.

2) Şüpheli kod kalıpları (klasik imzalar)

Tek başına kesin hüküm değildir ama güçlü sinyaldir: eval(, base64_decode(, gzinflate(, str_rot13(, çok uzun tek satır kodlar, anlamsız değişken isimleri, beklenmedik dış URL çağrıları…

Sunucuda hızlı tarama (örnek):

grep -R "base64_decode(" -n wp-content | head -n 50
grep -R "eval(" -n wp-content | head -n 50
grep -R "gzinflate(" -n wp-content | head -n 50

Bulduğun her eşleşme “kesin malware” değildir; fakat dosyanın konumu ve bağlamı her şeyi değiştirir. Tema functions.php içinde bir iki base64 kullanımını görüp hemen panik yapma; ama uploads içinde rastgele bir PHP dosyasında görüyorsan, bu çoğunlukla temizlenmesi gereken bir bulaşmadır.

3) uploads içinde PHP çalışmasını engelle (sert ama etkili)

uploads klasörü medya içindir; PHP çalışması orada genellikle istenmez. Apache kullanıyorsan uploads içine .htaccess ile engel koyabilirsin:

<FilesMatch "\.php$">
  Deny from all
</FilesMatch>

Nginx tarafında bunun karşılığı farklıdır (server block içinde location kuralı), ama mantık aynı: uploads altında PHP execute kapanmalı. Bu tek hamle bile birçok “tekrar bulaşma” senaryosunu keser.

Veritabanı tarafı: Spam içerik ve gizli link enjeksiyonlarını temizleme

1) Spam sayfalar (wp_posts) taraması

SEO spam çoğu zaman wp_posts içinde binlerce içerik üretir veya mevcut yazılara gizli link basar. Aranacak kelimeler duruma göre değişir ama genelde “casino”, “viagra”, “pharma”, “bahis” gibi alakasız anahtarlar çıkar. Veritabanı sorgusu teşhis içindir; silme kısmında dikkatli ol.

wp db query "SELECT ID, post_title, post_status FROM wp_posts WHERE post_content LIKE '%casino%' LIMIT 50;"

Tablo prefix’in wp_ olmak zorunda değildir. Sorguyu kendi prefix’ine göre uyarlarsın. Bulgu varsa önce kaynak üreteni (plugin/tema/malware) kesmeden toplu silmeye kalkma; yoksa saldırı tekrar yazar.

2) options tablosunda gizli yönlendirmeler

Bazı bulaşmalar site URL’sini, home URL’yi veya autoload edilen option’ları manipüle eder. Ayrıca “site_transient” gibi alanlarda gizli scriptler saklanabilir. options tablosunda şüpheli dış URL’ler, uzun base64 blokları, anlamsız option adları aranır.

Yönlendirme (redirect) vakalarında kritik kontrol: .htaccess, wp-config.php, mu-plugins

.htaccess içinde koşullu yönlendirmeler

Redirect malware bazen .htaccess içine “Google’dan gelene farklı davran” gibi kurallar yazar. Bu yüzden .htaccess dosyasını satır satır kontrol etmek gerekir. Anlamadığın koşul bloğu varsa, özellikle RewriteCond ile user-agent/referrer kontrol eden satırlara bak.

wp-config.php içine eklenen include/require tuzakları

wp-config.php içine bazen tek satırlık bir include gizlenir ve saldırgan asıl kodu başka bir yerde tutar. wp-config.php normalde kısa ve nettir; “uzayan” bir wp-config genelde şüphelidir.

mu-plugins (çok kişinin bakmadığı yer)

mu-plugins, otomatik yüklenen eklentilerdir. Birçok kişi burayı kontrol etmez. Saldırgan için güzel saklanma noktasıdır. mu-plugins altında tanımadığın bir dosya varsa, incelemeden geçme.

Temizlikten sonra en büyük hata: Aynı kapıyı açık bırakmak

“Temizledim” deyip bırakan, tekrar bulaşmayı davet eder. Kalıcı çözüm sertleştirmedir. Burada yine doğru sıra var: erişim, yetki, güncelleme disiplini, izleme.

1) En az yetki prensibi (admin sayısını azalt)

Herkese admin vermek kötü alışkanlıktır. Editör editör olsun, mağaza yöneticisi kendi rolünde kalsın. Admin sayısı azaldıkça saldırganın hedefi küçülür.

2) Yönetim panelinde dosya düzenlemeyi kapat

Saldırgan admin ele geçirirse “Tema Düzenleyici” üzerinden dosya basmak ister. Bunu kapatmak basit ama etkili bir kilittir. wp-config.php içine ekle:

<?php
define('DISALLOW_FILE_EDIT', true);

3) Güvenlik anahtarlarını (SALT) yenile

Bir olay yaşandıysa SALT yenilemek, eski oturumları geçersiz kılar. Bu adım “temizlik sonrası” yapılır; yoksa saldırganın cookie/oturum kalıntıları devam edebilir.

4) Dosya izinleri ve sahipliği

Klasik, sağlam ayar: dosyalar 644, klasörler 755, wp-config.php daha sıkı olabilir. En büyük hata, her şeyi 777 yapmak. Bu, saldırgana “buyur” demektir.

5) XML-RPC ve gereksiz giriş yüzeyini azalt

XML-RPC kullanmıyorsan kapatmak çoğu projede mantıklıdır. Bruteforce ve pingback istismarları burada döner. Kullandığın sistemlere göre karar ver; ama gereksizse kapat, yüzeyi küçült.

İzleme ve disiplin: Olay olunca değil, olmadan önce kontrol

1) Giriş denemesi ve kullanıcı etkinliği kayıtları

Login denemelerini, başarısız girişleri, yeni kullanıcı açılışlarını kaydeden bir sistem, “olayı erken yakalama” demektir. Olayı erken yakalarsan hasar küçülür.

2) Dosya değişim izleme

Tema ve eklenti dosyalarında beklenmedik değişiklik oluyorsa bunu bilmek zorundasın. Aksi halde saldırı “sessiz” kalır, sen de aylar sonra fark edersin.

3) Yedek: Sadece almak yetmez, geri yüklemeyi test et

Yedek almak, geri dönmeyi garanti etmez. Yedekten dönüş test edilmemişse, kriz anında yedeğin bozuk olduğunu öğrenirsin. Sağlam yaklaşım şudur: düzenli yedek + staging’de geri yükleme testi.

Performans notu: Güvenliği bozmayan Web Site Hızlandırma yaklaşımı

Birçok kişi güvenlik ve hız arasında yanlış bir tercih yapıyor. Doğru kurguda ikisi aynı hedefe hizmet eder: gereksiz parçaları azaltmak. Gereksiz eklentileri kaldırmak hem güvenliği artırır hem Web Site Hızlandırma sağlar. Ağır, bakımsız bir tema hem açık üretir hem performansı düşürür. Bu yüzden en pratik yol şudur: sadeleştir, güncel tut, izle.

Yanlış yapılan Web Site Hızlandırma ise şunlarla gelir: “her şeyi minify ettim”, “admin’e de cache yaptım”, “giriş sayfasını CDN’ye verdim” gibi düşüncesiz hamleler. Hız için güvenliği ve yönetilebilirliği feda etme. Sağlam sistem, önce güvenli çalışır; hız optimizasyonu bunun üstüne oturur.

Uygulama sırası: Tek sayfada operasyon planı

1) Şüpheli admin kullanıcılarını tespit et, pasife al/sil, tüm admin şifrelerini değiştir

2) Çekirdek dosya bütünlüğünü kontrol et, gerekiyorsa temiz kaynakla çekirdeği yenile

3) Eklenti/tema envanteri çıkar: gereksizleri kaldır, güncellemeleri uygula

4) wp-content altında şüpheli imza taraması yap (eval/base64/gzinflate vb.)

5) uploads altında PHP çalışmasını kapat, mu-plugins ve wp-config/.htaccess’i kontrol et

6) Veritabanında spam izlerini ara, önce kaynağı kes, sonra temizle

7) SALT yenile, DISALLOW_FILE_EDIT aç, dosya izinlerini sıkılaştır

8) İzleme kur: login log, dosya değişim takibi, düzenli yedek ve geri yükleme testi

9) Gereksiz yükleri azaltarak kontrollü Web Site Hızlandırma uygula

Bu sıra bozulmaz. Çünkü doğru iş sırası, doğru sonuç getirir. “wordpress hacklendi” paniğini kalıcı olarak bitiren şey, bir defalık temizlik değil; düzenli bakım ve sertleştirme disiplinidir.