WordPress checksum doğrulama: değiştirilmiş çekirdek dosyalar

Bir saldırıdan şüpheleniyorsanız checksum (sağlama toplamı) doğrulaması yararlı bir ilk kontroldür, ama sızıntıyı sınırlamayı ve delilleri korumayı geciktirmemelidir. Tek bir komut, çekirdek dosyalarınızın resmî sürümle bayt bayt aynı olup olmadığını söyler. Resmî checksum listesinin kapsadığı dosyaların, sizin tam sürümünüzle ve dilinizle eşleşmesi gerekir. wp-config.php gibi siteye özgü dosyalar bu karşılaştırmanın dışında kalır. Her fark ya bildiğiniz yerel bir değişikliktir ya da bugün incelemeniz gereken bir şeydir.

Saldırıdan sonra WordPress çekirdek dosyaları neden değişir?

Çekirdek dosyalar iyi bir saklanma yeridir, çünkü kimse onları okumaz. Site sahipleri tema ve eklenti ayarlarına bakar. wp-includes/load.php dosyasını açan ya da wp-admin/includes içindeki dosyaları sayan hemen hiç kimse yoktur. Saldırgan, düzenli olarak yüklenen bir çekirdek dosyasına kod gizleyebilir ya da sonradan erişim için masum görünümlü bir dosya ekleyebilir. Eklenen bir dosya, yalnızca çekirdek klasöründe durduğu için çalışmaz.

Checksum'lar "iyi görünüyor" izlenimini kanıtlanabilir bir karşılaştırmaya çevirir. WordPress.org, her sürümün her çekirdek dosyası için bir MD5 özeti yayımlar. Siz de dosyalarınızı bu listeyle karşılaştırırsınız.

Yine de nedeni gözden kaçırmayın. Patchstack'in State of WordPress Security in 2026 raporu bir güvenlik firmasının raporudur. Rapor, 2025'te WordPress çekirdeğinde yalnızca 6 güvenlik açığı sayıyor ve hepsi düşük öncelikli. Bu sayı, saldırganın sitenize nasıl girdiğini söylemez. Değiştirilmiş çekirdek dosyaları, bir eklenti, bir tema ya da çalınmış kimlik bilgileri üzerinden yapılan bir sızmanın sonucu olabilir. Çekirdeği değiştirmek bu dosyaları onarır, ama giriş noktasını bulup kapatmanız gerekir.

WP-CLI ile WordPress checksum doğrulama

SSH ile bağlanın ve komutu WordPress kök dizininden çalıştırın:

cd /var/www/example.com
wp core verify-checksums

Başka bir dizindeyseniz --path=/var/www/example.com ekleyin. Komutu root olarak değil, site dosyalarının sahibi olan kullanıcıyla çalıştırın. WP-CLI, --allow-root eklemediğiniz sürece root olarak çalışmayı reddeder ve bu varsayılan davranış yerindedir. Root olarak çalıştırırsanız WordPress'in yüklediği her kötü amaçlı kod da root yetkisiyle çalışır.

WP-CLI varsayılan olarak sürümü wp-includes/version.php dosyasından okur. Ele geçirilmiş bir sitede bu dosya da değiştirilmiş olabilir. Hangi sürümü kurduğunuzu biliyorsanız sürümü sabitleyin. İngilizce olmayan kurulumlarda dil kodunu (locale) da belirtin:

wp core verify-checksums --version=6.8.3 --locale=de_DE

Kendi sürüm numaranızı kullanın. Temiz bir sitede tek satır görürsünüz:

Success: WordPress installation verifies against checksums.

Sorunlu bir sitede ise şuna benzer uyarılar çıkar:

Warning: File doesn't verify against checksum: wp-includes/functions.php
Warning: File should not exist: wp-includes/class-wp-cache-handler.php
Error: WordPress installation doesn't verify against checksums.

Sonuçları okumak: değiştirilmiş dosya mı, fazla dosya mı?

İki uyarı türü farklı anlamlara gelir ve farklı ele alınmalıdır.

Meşru bir yerel yama yaptığınızı bilmiyorsanız, değiştirilmiş bir dosyayı ciddiye alın. Böyle yamalar nadirdir ve yapan kişi bunu belgelemiş olmalıdır.

Fazla dosya o kadar net değildir. Bazı güncellemeler eski sürümlerden kalan dosyaları geride bırakır, dolayısıyla fazla dosya tek başına kötü amaçlı yazılım kanıtı sayılmaz. wp-includes içindeki rastgele adlı bir PHP dosyası ise okuyana kadar şüphelidir. Adı yalnızca çekirdek bir bileşeni andıran dosyalar için de aynısı geçerlidir.

Fazla dosyalar, komutu başarısız kılmadan uyarı olarak raporlanabilir. Yani File should not exist satırlarının ardından Success görebilirsiniz. Son satıra güvenmek yerine her uyarıyı okuyun.

Varsayılan olarak fazla dosya kontrolü wp-admin ve wp-includes dizinlerini kapsar. Bazı WP-CLI sürümleri kök dizini de kontrol edebilir. Sürümünüzde --include-root seçeneği olup olmadığını görmek için wp help core verify-checksums komutunu çalıştırın.

WP-CLI yok mu? WordPress.org checksum API'sini kullanın

Bazı barındırma firmaları SSH verir ama WP-CLI sunmaz. Bu durumda checksum API'sini doğrudan sorgulayın ve dosyaları md5sum ile karşılaştırın. curl ve jq gerekir:

cd /var/www/example.com
VER=6.8.3        # tam WordPress sürümünüz
LOC=en_US        # veya de_DE, fr_FR, ...
(
  set -e
  WORK=$(mktemp -d)
  trap 'rm -rf -- "$WORK"' EXIT
  curl -fsS "https://api.wordpress.org/core/checksums/1.0/?version=$VER&locale=$LOC" \
    -o "$WORK/response.json"
  jq -er '.checksums | select(type == "object" and length > 0) | to_entries[] | select(.key | startswith("wp-content/") | not) | "\(.value)  \(.key)"' \
    "$WORK/response.json" > "$WORK/core.md5"
  test -s "$WORK/core.md5"
  md5sum -c --quiet "$WORK/core.md5"
)

select filtresi, wp-content içindeki paketle gelen tema ve eklentileri atlar; bunları bilerek silmiş olabilirsiniz. --quiet ile md5sum yalnızca doğrulanamayan dosyaları yazar.

Çıktı yoksa ve çıkış durumu sıfırsa, filtrelenmiş checksum listesindeki dosyalar eşleşiyor demektir. İndirme, ayrıştırma ya da doğrulama hatası temiz sonuç sayılmaz. Alt kabuk özel bir geçici dizin kullanır ve önceki adımlardan biri başarısız olursa durur.

Bu yöntem fazla dosyaları tespit etmez. Onları bulmak için aynı sürümü indirin, örneğin https://wordpress.org/wordpress-6.8.3.zip. İngilizce olmayan kurulumlarda ilgili dil sitesini kullanın. Arşivi açın ve klasörleri karşılaştırın:

diff -rq wordpress/wp-includes /var/www/example.com/wp-includes
diff -rq wordpress/wp-admin /var/www/example.com/wp-admin

Only in /var/www/... satırları, kurulumda fazladan bulunan dosyaları gösterir. Only in wordpress/... satırları kurulumda eksik olan dosyaları, Files ... differ satırları ise içeriği farklı olan dosyaları gösterir. Beklenmedik dizinlere de bakın.

Eklentiler ve temalar: checksum'ın yetmediği yer

WP-CLI eklentileri de kontrol edebilir:

wp plugin verify-checksums --all

Bu yalnızca WordPress.org'da barındırılan eklentiler için çalışır, çünkü yayımlanmış checksum'ları yalnızca onların var. WordPress.org'da eşleşen bir checksum seti olmayan eklentiler bu yolla doğrulanamaz.

Crack'lenmiş (nulled) ya da kurcalanmış bir kopya, WordPress.org'daki bir eklentinin slug ve sürümünü taşıyorsa komut yine de karşılaştırma yapar ve değişen dosyaları işaretler. WP-CLI'da buna denk gelen, yerleşik bir tema checksum komutu yoktur.

Bu eklentiler ve temalar için kurulu sürümün aynısını resmî kaynağından ya da güvendiğiniz bir derleme arşivinden alın. Özel geliştirilmiş kodda, şüpheli siteden alınmış bir kopya değil, temiz olduğu bilinen bir sürüm paketi kullanın. Sonra kurulu kopyayla karşılaştırın:

diff -rq ~/clean/some-premium-plugin wp-content/plugins/some-premium-plugin

Kendi kurduğunuz hiçbir şeyle eşleştiremediğiniz eklenti klasörlerini de arayın. wp-content/plugins içinde tanımadığınız bir klasör tehlike işaretidir. Crack'lenmiş bir eklenti, diff ne gösterirse göstersin başlı başına bir sorundur. Crack'lenmiş ve terk edilmiş eklentilerin nasıl değiştirileceğini eklenti güvenlik açıkları rehberi anlatıyor.

WordPress çekirdeğini güvenle yeniden kurmak

Önce delilleri kaydedin ve tam bir yedek alın. Ardından çekirdeği aynı sürümün temiz bir kopyasıyla değiştirin:

wp core download --force --skip-content --version=6.8.3

Gerekirse --locale=de_DE ya da kendi dilinizi ekleyin. Komut çekirdek dosyaların üzerine yazar. Pakette wp-config.php olmadığı için ona dokunmaz. --skip-content ise wp-content dizinini olduğu gibi bırakır.

Komut fazla dosyaları silmez. wp-includes/class-wp-cache-handler.php gibi bir dosya yerinde kalır, çünkü indirme yalnızca resmî dosyaları yazar. Önce her fazla dosyayı kopyalayıp inceleyin. Sonra zararlı olanları ya da gereksizliğini doğruladıklarınızı silin. wp core verify-checksums komutunu yeniden çalıştırın ve açıklanamayan uyarı kalmadığından emin olun.

Temiz bir checksum sonucunun söylemedikleri

Yeşil sonuç yalnızca WordPress çekirdeğini kapsar. Şunlar hakkında hiçbir şey söylemez:

• wp-content: temalar, ücretli ve özel eklentiler, mu-plugins ve uploads
• Checksum listesinde bulunmayan wp-config.php ve .htaccess
• Veritabanı: enjekte edilmiş seçenekler, yazılardaki spam, sahte yönetici hesapları, zamanlanmış cron olayları
• WordPress dışındaki dosyalar: barındırma hesabındaki diğer PHP dosyaları ya da sunucu düzeyindeki yapılandırma

Saldırganlar hangi dosyaların kontrol edildiğini bilir. wp-content/uploads klasörünün web shell'ler için favori yer olmasının nedenlerinden biri budur. Kalan kontroller için saldırıya uğramış sitenin belirtileri yazısını izleyin. Yüklenen dosyalar için web shell rehberini kullanın.

Sürekli dosya bütünlüğü izleme

Tek seferlik kontrol olay sırasında işe yarar. Zamanlanmış bir kontrol, bir değişikliğin fark edilmeden kalma süresini kısaltabilir, ancak değişiklikler bir sonraki çalıştırmadan önce ziyaretçileri etkileyebilir. Cron ile çalışan küçük bir betik yeterlidir:

#!/bin/bash
cd /var/www/example.com || exit 1
OUT=$(/usr/local/bin/wp core verify-checksums 2>&1)
if [ $? -ne 0 ] || echo "$OUT" | grep -q "Warning:"; then
  echo "$OUT" | mail -s "Core checksum alert: example.com" admin@example.com
fi

Bunu root'un değil, site sahibinin crontab'ına ekleyin. Betik, sıfır olmayan çıkış kodunda ve raporlanan fazla dosyalar dahil her uyarıda alarm verir. Cron'un ortamı sınırlı olduğundan PATH değişkenini tanımlayın ya da çalıştırılabilir dosyaların tam yollarını kullanın. Alarmın gerçekten ulaştığını test edin; gerekirse mail yerine çalışan uyarı sisteminizi koyun.

wp-content için, bilinen temiz her güncellemeden sonra kendi referans kaydınızı (baseline) tutun:

find wp-content/plugins wp-content/themes -type f -exec sha256sum {} + > ~/baseline-$(date +%F).sha256

Referans kaydını web kök dizininin dışında, mümkünse sunucunun dışında saklayın. Değişiklikleri kontrol etmek için site kökünden bu kayda karşı sha256sum -c --quiet çalıştırın. Bu, değiştirilen ve silinen dosyaları yakalar, yeni dosyaları yakalamaz. Yeni dosyalar için güncel bir find dosya listesini referans kaydındaki listeyle karşılaştırın. Her meşru güncellemeden sonra yeni bir referans kaydı oluşturun; aksi halde bir sonraki kontrol kendi değişikliklerinizi işaretler.

Düzenli kontroller uyumluluğa da katkı sağlar. GDPR (AB Genel Veri Koruma Tüzüğü) md. 32(1)(d), güvenlik önlemlerinin etkinliğini düzenli olarak test etme, değerlendirme ve ölçme yönünde bir süreç öngörür. Sonuçları saklanan zamanlanmış bir bütünlük kontrolü, bu sürecin somut kanıtıdır. Daha geniş çerçeve için WordPress için GDPR md. 32 yazısına bakın.

Betik bakımıyla uğraşmak istemiyorsanız, secaudit.eu'nun Security Audit & Compliance eklentisi bir dosya bütünlüğü referans kaydı tutar, değişen dosyaları ve gizlenmiş (obfuscated) içeriği raporlar. Çekirdek checksum doğrulamasını da çalıştırır. Eklenti tespit eder ve raporlar; temizlik sizin ya da ajansınızın işi olarak kalır.

SSS

verify-checksums multisite ve İngilizce olmayan kurulumlarda çalışır mı?

Evet. Multisite ağı tek bir çekirdek dosya setini paylaşır; dolayısıyla tek bir çalıştırma tüm ağı kapsar. İngilizce olmayan kurulumlarda doğru --locale değerini verin, çünkü yerelleştirilmiş paketler en_US paketinden farklı olabilir.

"File should not exist" uyarısı her zaman kötü amaçlı yazılım mıdır?

Hayır. Eski WordPress sürümlerinden kalan dosyalar da bu uyarıyı tetikler. Dosyanın bir kopyasını alın ve inceleyin. Zararlıysa ya da gereksizliğini doğruladıysanız silin. Çekirdek klasöründeki açıklanamayan PHP kodu her zaman düzgünce incelenmelidir.

Ne sıklıkla çalıştırmalıyım?

Çoğu kurumsal site için cron ile günlük çalıştırmak makuldür. Ayrıca bir olaydan sonra, her çekirdek güncellemesinden sonra ve sunucuya yeni biri erişim kazandığında da çalıştırın.

Saldırgan checksum sonucunu taklit edebilir mi?

Checksum'ların kendisi WordPress.org'dan HTTPS üzerinden gelir. Ancak sunucunuzu ele geçiren bir saldırgan, WP-CLI dosyası ya da sistem ikili dosyaları gibi yerel araçları yine de kurcalayabilir. Şüphede kalırsanız site dosyalarını temiz bir makineye kopyalayın ve aynı sürümün yeni indirilmiş kopyasıyla orada karşılaştırın.