WordPress Hacklendi Temizleme aramasında doğru cevap tek bir paket veya tek komut değildir. İlk hedef saldırganı 'kovalamak' değil kanıtı korumak, sistemi izole etmek, etki alanını belirlemek ve temiz bir yedek/known-good kaynakla karşılaştırmaktır. Bu rehber; karar kriterlerini, production öncesi kontrolleri, güvenlik sınırlarını, kapasite sinyallerini ve geri dönüş planını aynı sayfada toplar.
İlk adım mevcut durumu ölçmektir: plugin/theme/core bütünlüğü. İlk hedef saldırganı 'kovalamak' değil kanıtı korumak, sistemi izole etmek, etki alanını belirlemek ve temiz bir yedek/known-good kaynakla karşılaştırmaktır. Değişiklik öncesinde yedek/rollback, erişim yolu ve test kriterlerini yazılı hale getirin; ardından küçük kapsamlı doğrulama yapıp production'a geçin.
Aynı wordpress hacklendi temizleme ihtiyacı test, orta ölçekli production ve kritik/HA ortamında farklı topoloji gerektirir. Kaynak planını kullanım sınıfıyla eşleyin.
Envanter → test → değişiklik → doğrulama → gözlem → rollback kararı zinciri, özellikle stateful veya müşteri trafiği taşıyan sistemlerde hatayı erken sınırlar.
İlk hedef saldırganı 'kovalamak' değil kanıtı korumak, sistemi izole etmek, etki alanını belirlemek ve temiz bir yedek/known-good kaynakla karşılaştırmaktır. Değişikliği hızlandırmak için gözlem, backup veya access kontrolünü atlamak çoğu zaman toplam kesinti süresini büyütür.
Kontrol listesinin amacı 'kuruldu' demek değil, plugin/theme/core bütünlüğü sinyalinin beklenen aralıkta olduğunu ve geri dönüş yolunun çalıştığını göstermektir.
Aşağıdaki komutlar mümkün olduğunca durum/sağlık okumaya yöneliktir. Çıktıdaki IP, kullanıcı, token, domain ve secret değerlerini destek talebine eklemeden önce maskeleyin.
find . -type f -mtime -7 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r | head -n 80find . -type f \( -name '*.php' -o -name '*.js' \) -size +0 -print | head -n 80wp core verify-checksums 2>/dev/null || truewp plugin list 2>/dev/null || trueBu sıra kritik sistemlerde change record/runbook olarak kullanılabilir; her adıma sorumlu kişi, zaman penceresi ve başarı kriteri ekleyin.
İlk hedef saldırganı 'kovalamak' değil kanıtı korumak, sistemi izole etmek, etki alanını belirlemek ve temiz bir yedek/known-good kaynakla karşılaştırmaktır.
Temizlik sonrası Search Console, access/error logs, WAF ve file-integrity monitoring ile en az birkaç gün tekrar belirti arayın.
İnceleme sonucunda 'hangi IP girdi' her zaman tek cevaplı değildir; proxy/CDN, stolen credentials, web exploit ve lateral movement log zincirini değiştirebilir.
İzolasyon öncesi kritik volatile bilgileri kaydetmek gerekebilir; ancak canlı sistemde agresif tarama/silme kanıt ve uptime'ı bozabilir.
Dosya mtime tek başına kanıt değildir; deploy, cache ve backup restore aynı zamanı değiştirebilir. Hash, owner, path, web log ve package integrity ile çapraz kontrol yapın.
Saldırganın persistence yöntemi temizlenmeden yalnız görünür spam/shell dosyasını silmek tekrar bulaşmayı engellemez.
Tek sabit değer yoktur. plugin/theme/core bütünlüğü ölçülmeden yalnız RAM/vCPU sayısıyla production kapasitesi seçmek sağlıklı değildir.
Backup gereklidir ancak restore testi, rollback süresi ve state tutarlılığı doğrulanmadan tek başına recovery garantisi değildir.
Mevcut sürüm/topoloji, plugin/theme/core bütünlüğü, hata/log örneği, peak kullanım zamanı, veri boyutu ve hedeflenen kesinti penceresini iletin; secret/parolaları paylaşmayın.
Staging veya sınırlı pilot, gözlenebilir metrikler, küçük değişiklik kapsamı ve test edilmiş rollback yolu en güvenli genel yaklaşımdır.
Mevcut topoloji, kullanıcı/traffic yükü, plugin/theme/core bütünlüğü, veri boyutu ve hedefinizi iletin; teknik ekip doğru VPS/VDS/Dedicated veya migration planını çıkarsın.