Linux sunucularda WordPress güvenlik açıklarını kapatma rehberi

Linux sunucularda WordPress güvenlik açıklarını kapatma, tek bir yama uygulamaktan çok daha geniş bir bakım işidir; çekirdek, eklenti, tema, dosya izinleri, wp-config.php koruması ve güncelleme politikasını aynı sırada ele almanız gerekir. En güvenli başlangıç, canlı sitede çalışan sürümü, etkin eklentileri ve temaları tespit etmek; ardından WordPress çekirdeği ile eklentilerde bekleyen güvenlik güncellemelerini kapatmaktır. Sonra dosya sistemini dar izinlerle sınırlar, wp-config.php dosyasını gereksiz okunabilirlikten çıkarır, panel içi dosya düzenlemeyi kapatır ve checksum kontrolüyle beklenmedik değişiklik ararsınız. Bu yaklaşım, tek bir CVE’yi ezberletmez; Linux üzerindeki gerçek WordPress kurulumlarında en sık sömürülen yüzeyi küçültür. İşe başlamadan önce tam yedek, mümkünse snapshot ve kısa bir doğrulama planı hazır olmalıdır; aksi halde güvenliği artırırken erişimi kırabilirsiniz. En doğru uygulama, değişikliği staging’de test edip canlıda yalnızca doğrulanmış adımları uygulamaktır.

Risk özeti

Bu konuda ana risk, sertleştirme yaparken sitenin yazma ihtiyacını yanlış değerlendirmektir. Çok dar izinler medya yüklemelerini, eklenti güncellemelerini veya önbellek klasörlerini bozabilir; çok gevşek izinler ise kötü amaçlı dosya eklenmesine yol açabilir. Özellikle paylaşımlı hosting, ajans yönetimi veya eski taşıma işlemlerinde sahiplik zinciri hataları sık görülür. Bu yüzden değişikliği önce staging ortamında, aynı PHP sürümü ve aynı eklenti setiyle test etmek daha güvenlidir. Özel geliştirilmiş eklenti ve temalarda checksum doğrulaması her zaman tek başına yeterli olmayabilir; burada dosya bütünlüğünü Git geçmişi, paket kontrolü veya kurumsal dağıtım kaydıyla birlikte değerlendirin.

Riskin pratik karşılığı şudur: yönetici paneline giriş açık kalabilir ama arka planda yetkisiz dosya değişimi sürüyor olabilir. Bu nedenle yalnız “site açılıyor” kontrolü yeterli sayılmaz; dosya izinleri, bekleyen güncellemeler ve upload klasörü davranışı birlikte okunmalıdır. Güvenlik açığını kapatma işi, erişimi bozmadan saldırı yüzeyini daraltabildiğiniz noktada başarılı sayılır.

Önce hangi kurulumlar ele alınmalı?

Risk sırası her zaman aynı değildir. İnternete açık, uzun süredir güncellenmemiş, çok sayıda etkin eklenti taşıyan ve yazılabilir klasörleri gevşek bırakılan siteler önce kontrol edilmelidir. Ajans hesapları, çok kullanıcılı hosting kurulumları ve staging’den canlıya kopyalanmış dizinler, izin ve sahiplik hatalarını daha sık taşır.

Linux sunucularda WordPress güvenlik açıklarını kapatma için güvenli sıra

Daha güvenli yaklaşım, önce görünür envanteri çıkarmak, sonra güncelleme, ardından sertleştirme ve en son doğrulama yapmaktır. Canlı siteyi körlemesine değiştirmek yerine önce staging’de aynı PHP sürümü, aynı eklenti seti ve aynı tema ile deneme yapmak daha doğru olur. Versiyon kontrolüyle yönetilen kurulumlarda otomatik güncelleme davranışı farklılaşabileceği için, politikanızı paneldeki güncelleme ekranı ve WP-CLI çıktısıyla birlikte okuyun.

1. Bakım penceresi açın, tam yedek veya snapshot alın ve değişiklik notu tutun.
2. wp core version ve wp core check-update ile çekirdek durumunu çıkarın.
3. wp plugin list --status=active --fields=name,status,version,update,auto_update ile etkin eklentileri görün.
4. wp core update, ardından wp plugin update --all ve uygun durumlarda wp theme update --all çalıştırın.
5. Çekirdek dosyaları için checksum doğrulaması yapın; beklenmedik farkları normal kabul etmeyin.
6. Dosya izinlerini daraltın, ardından wp-config.php ve düzenleme yüzeyini sertleştirin.
7. Kullanılmayan eklenti ve temaları gerçekten kaldırın; devre dışı bırakmak tek başına yeterli olmayabilir.
8. Şüpheli oturum veya yönetici erişimi gördüyseniz güvenlik anahtarlarını ve salt değerlerini yenilemeyi planlayın.

wp core version
wp core check-update
wp plugin list --status=active --fields=name,status,version,update,auto_update
wp core update
wp plugin update --all
wp theme update --all

Beklediğiniz tablo şudur: wp core check-update boş veya güncel durumu gösterir, eklenti listesinde update sütunu mümkün olduğunca none kalır ve güncelleme komutları hata vermeden tamamlanır. wp core update sırasında Another update is currently in progress benzeri bir mesaj görürseniz, core_updater.lock dosyasını silmeden önce gerçekten çalışan bir güncelleme olmadığını doğrulayın.

Dosya izinleri ve wp-config.php için güvenli başlangıç

WordPress kurulumlarında dosya izinlerini aşırı gevşetmek yerine, önce sahiplik modelini düzeltmek gerekir. Çekirdek dosyalar çoğu kurulumda yalnızca kullanıcı hesabı tarafından yazılabilir olmalı, wp-content ise ihtiyaç halinde yazılabilir kalmalıdır. wp-config.php için 400 veya 440 izni, web sunucusunun kurulumla çalışmasını bozmayacak en dar seçeneklerden biridir. Dosyayı kurulum kökünün bir üst dizinine taşımak bazı düzenlerde ek koruma sağlar; ancak bu adım her hosting yapısında aynı sonucu vermez, bu yüzden önce staging üzerinde deneyin.

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
chmod 440 /path/to/wordpress/wp-config.php

Bu noktada başarı işareti izinleri daha da gevşetmek değil, sitenin yazma ihtiyacı olan yerleri doğru tanımlamaktır. Örneğin yükleme klasörlerine ihtiyaç yoksa onları genel yazıma açmak yerine sahipliği düzeltin. Bir eklenti veya tema sadece belirli bir klasöre yazıyorsa, o klasörü istisna olarak ele alın; tüm siteyi 777 gibi değerlerle açmayın.

define( 'DISALLOW_FILE_EDIT', true );

Bu sabit, yönetim panelindeki tema ve eklenti düzenleyicisini kapatır. FTP, SSH veya yapılandırma yönetimiyle yapılan meşru düzenlemeleri engellemez; yalnızca tarayıcıdan dosya düzenleme yüzeyini kapatır. Canlı ortamda küçük bir konfor kaybı yaratabilir, ama bir saldırı sonrası dosya değiştirme riskini belirgin biçimde düşürür.

Belirti ve tespit işaretleri

Kapatma işlemini yalnızca güncelleme olarak okumayın; tespit yüzeyini de daraltın. Aşağıdaki işaretler tek başına ispat değildir, fakat birlikte görüldüğünde daha derin inceleme gerektirir:

• wp core verify-checksums sonucu çekirdek dosyalarında fark gösteriyorsa
• Etkin olmayan ama hala kurulu duran çok sayıda eklenti ve tema varsa
• Yükleme klasöründe çalıştırılabilir dosyalar birikmişse
• Beklenmeyen yönetici hesabı, rol değişimi veya kullanıcı adı görünüyorsa
• Sitede ani yönlendirme, spam içerik veya sayfa bozulması oluştuysa
• Güncelleme geçmişi uzun süredir değişmemiş ve manuel bakım yapılmamışsa

wp core verify-checksums
wp plugin verify-checksums --all
find /path/to/wordpress/wp-content/uploads -type f ( -name '*.php' -o -name '*.phtml' -o -name '*.phar' )

Checksum doğrulamasında başarı beklediğiniz sonuç, çekirdek dosyaların beklenen sürümle uyuşmasıdır. wp plugin verify-checksums --all ise yalnız WordPress.org paketleri için anlamlıdır; özel geliştirilmiş eklentilerde bu yöntem yerine kurumsal paket bütünlüğü ya da Git tabanlı karşılaştırma gerekir. Yükleme dizininde PHP benzeri dosya görülmesi normal değildir; bu tür dosyaları hemen silmek yerine önce yalıtın ve neden orada olduklarını anlayın.

Doğrulama ve izleme

İşlem sonrası doğrulama, güvenlik işi kadar önemlidir. Çekirdek sürümünü, aktif eklentileri ve temaları tekrar kontrol edin; bekleyen güncelleme uyarısı kalmadığını görün. Yönetici listesi, son kullanıcı etkinliği ve dosya değişiklikleri, özellikle ilk 24 ila 72 saat içinde yeniden gözden geçirilmelidir. Bu pencere, pasif kalan arka kapıların veya gecikmiş görevlerin tekrar ortaya çıkabileceği dönemdir.

İzleme tarafında odak şuralarda olmalı: giriş hataları, yeni yönetici oluşturma denemeleri, beklenmeyen içerik değişiklikleri, dosya izinlerinin geri gevşemesi ve web sunucusu hata kayıtlarında artış. wp core update çıkışında yine bir kilit hatası görürseniz, çözümü otomatik komutla zorlamayın; önce gerçekten süren bir işlem olup olmadığını denetleyin. WordPress’i güncel tutarken Linux paketlerini de aynı bakım penceresine alın, fakat servis adı ve yeniden başlatma yöntemi dağıtıma göre değişebileceği için bunu kör komut olarak değil ortam doğrulamasıyla yapın.

İzleme için en basit test sayfası, giriş, form gönderimi, medya yükleme ve önbellekli bir sayfanın davranışıdır. Bu dört kontrol sorunsuzsa ve checksum kontrolü temiz dönüyorsa, sertleştirme adımları büyük olasılıkla doğru uygulanmıştır. Bir hata varsa, sorunu izole etmek için değişikliği tek tek geri alın; aynı anda çok sayıda ayarı gevşetmek teşhis kalitesini düşürür.

Sonraki aksiyon

İlk uygulama için tek hedef seçin: önce yedek alın, sonra staging üzerinde çekirdek ve eklenti güncellemesini deneyin, ardından canlıda izinleri ve DISALLOW_FILE_EDIT ayarını uygulayın. Değişiklikten sonra test sayfası açılmalı, yönetici girişi çalışmalı ve checksum kontrolü temiz dönmelidir. Eğer herhangi bir adım dosya yükleme, tema kaydı veya yönetici erişiminde hata üretirse, o değişikliği geri çekip sahiplik ve izin zincirini yeniden inceleyin. Güvenli sonuç, her şeyi sıkmak değil; işleyen minimum izinle güncel ve izlenen bir kurulum bırakmaktır.

Güvenli geri dönüş sınırı

Bir izin değişikliği siteyi açılmaz hale getirirse ilk geri dönüş noktası her zaman yedek veya snapshot olmalıdır. Dosya izinlerini genişletmek yerine, önce sahipliği ve yazma ihtiyacını yeniden kontrol edin. DISALLOW_FILE_EDIT nedeniyle acil bir bakım engellenirse, bunu kalıcı alışkanlığa dönüştürmeden geçici olarak yorum satırı haline getirin ve değişiklik kaydını bırakın. Güvenlik yüzeyini kapatırken amaç erişimi kırmadan saldırı alanını daraltmaktır; site çalışmıyorsa yaptığınız sertleştirme henüz doğru biçimde uygulanmamış demektir.

En doğru başarı işareti, yalnızca sitenin açılması değil; güncel çekirdek, temiz checksum, dar izinler, kapalı dosya editörü ve izleme altında sakin bir güncelleme kuyruğudur.