WordPress Güvenlik Açıkları Nasıl Kapatılır? Adım Adım Rehber

WordPress'in kendisi güvensiz bir yazılım değildir; sorun neredeyse her zaman eski sürümler, terk edilmiş eklentiler, zayıf parolalar ve yanlış yapılandırmadan çıkar. Bir siteye giren saldırganların büyük çoğunluğu sıfırıncı gün açıklarını değil, aylardır güncellenmemiş bilinen zafiyetleri ve otomatik bot taramalarını kullanır. Bu da iyi haber: Açıkların çoğu, doğru katmanları üst üste koyduğunuzda kapanır.

Bu rehberde WordPress'i sertleştirmenin adımlarını sırayla anlatıyoruz. Her adım tek başına faydalı, ama asıl gücü hepsini birlikte uyguladığınızda ortaya çıkar. Amacımız "hackerdan tamamen korunmak" gibi gerçekçi olmayan bir vaat değil; saldırı yüzeyini o kadar daraltmak ki otomatik saldırılar tutmasın, hedefli bir saldırı da defalarca duvara toslasın.

Güncelleme Disiplinini Kurun

WordPress güvenliğinin tek en önemli adımı budur: Çekirdek, tüm eklentiler ve temalar her zaman güncel olmalı; güvenlik yaması çıkan bir bileşen 24 saat içinde güncellenmelidir. Saldırıların büyük bölümü, yayınlanmış ve yaması çıkmış ama sitede kurulmamış zafiyetleri hedefler — yani siz güncellemeyi ertelediğiniz her gün, herkese açık bir açığı sitenizde taşırsınız.

Güncellemeyi disipline bağlamanın pratik yolu, küçük güvenlik yamalarını otomatiğe almak, büyük sürüm atlamalarını ise bir test/staging ortamında denedikten sonra canlıya almaktır. wp-config.php üzerinden çekirdek küçük sürüm güncellemelerini açabilirsiniz:

// Çekirdek küçük (minor) güncellemeleri otomatik uygula
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Eklenti ve temalar için otomatik güncellemeyi yönetim panelinden veya wp-cli ile toplu açabilirsiniz:

# Tüm eklentileri güncelle
wp plugin update --all

# Tüm temaları güncelle
wp theme update --all

# Çekirdeği güncelle
wp core update

Otomatik güncellemenin riski, nadiren de olsa bir güncellemenin siteyi bozmasıdır; bu yüzden otomatik güncelleme ile birlikte çalışan bir yedek sistemi şart. Yedek yoksa otomatik güncelleme kumar olur. Düzenli, denetimli güncelleme akışını kurmakta zorlanıyorsanız bakım ve izleme hizmetimiz tam olarak bu işi üstlenir.

Kullanmadığınız Eklenti ve Temaları Kaldırın

Sitede duran her eklenti ve tema, çalışsa da çalışmasa da bir saldırı yüzeyidir; kullanmadığınız her bileşeni devre dışı bırakmakla kalmayıp tamamen silmelisiniz. Pasif bir eklentinin dosyaları sunucuda durmaya devam eder ve bilinen bir açığı varsa, eklenti aktif olmasa bile bazı durumlarda doğrudan dosyasına istek atılarak sömürülebilir.

Kural basit: "İleride lazım olur" diye tutulan eklenti yoktur. Kullanmıyorsanız silin, gerekince yeniden kurarsınız. Özellikle uzun süredir güncellenmemiş, geliştiricisi tarafından terk edilmiş eklentiler en tehlikeli gruptur. Bir eklentinin WordPress deposundan kaldırılmış olması genellikle çözülemeyen bir güvenlik sorunu anlamına gelir.

# Aktif olmayan eklentileri listele
wp plugin list --status=inactive

# Bir eklentiyi tamamen kaldır (dosyalarıyla birlikte)
wp plugin delete eklenti-adi

# Kullanılmayan temaları sil, sadece bir yedek tema bırakın
wp theme delete tema-adi

Tema tarafında da varsayılan bir WordPress teması (örneğin twentytwentyfour) yedek olarak kalsın; bir eklenti/tema çakışmasında siteyi kurtarmak için işe yarar. Gerisi gitsin.

Aynı mantık, eklentileri güvenilir kaynaklardan edinmek için de geçerlidir. Ücretli bir eklentiyi "nulled" (kırılmış, lisansı kaldırılmış) sürüm olarak korsan sitelerden indirmek, WordPress güvenliğinin en sık gözden kaçan açığıdır. Bu tür paketler neredeyse her zaman içine gizlenmiş arka kapı kodu barındırır; siz eklentiyi kurar kurmaz saldırgan sitenize erişim kazanır. Bir eklentiyi yalnızca resmi WordPress deposundan veya doğrudan geliştiricisinin sitesinden edinin; "bedava premium eklenti" vaadi, aslında en pahalı güvenlik hatasıdır.

Güçlü Kimlik Doğrulama ve İki Adımlı Doğrulama Kurun

Yönetici hesaplarına güçlü, benzersiz parolalar koyun ve mutlaka iki adımlı doğrulama (2FA) etkinleştirin; ayrıca "admin" gibi tahmin edilebilir kullanıcı adlarını kaldırın. Brute force saldırılarının işe yaramasının tek nedeni zayıf parolalardır — parola yeterince güçlü ve 2FA açıksa, doğru parolayı bilmeyen bir saldırgan ikinci faktörü de aşamaz ve giriş imkânsızlaşır.

Kullanıcı adı yönetimi için "admin", "administrator", "root" gibi adları kullanmayın. Var olan bir admin hesabının görünen adını (display name) da kullanıcı adından farklı tutun; aksi halde yazar arşivi URL'lerinden kullanıcı adı sızabilir. wp-cli ile yeni yönetici oluşturup eskisini devretmek en temiz yoldur:

# Yeni, güçlü parolalı yönetici oluştur
wp user create yonetici2026 [email protected] --role=administrator

# Eski admin hesabını sil, içeriğini yeni kullanıcıya devret
wp user delete admin --reassign=2

2FA için TOTP tabanlı (Google Authenticator, Authy vb.) bir çözüm kullanın; SMS tabanlı doğrulama SIM swap riskine açık olduğundan ikinci tercih olsun. En az tüm yönetici ve editör rollerinde 2FA zorunlu olmalı.

Dosya ve Dizin İzinlerini Doğru Ayarlayın

Dosya izinleri, bir saldırgan sunucuya kısmen sızsa bile hasarı sınırlayan kritik bir kattır: Dizinler 755, dosyalar 644 olmalı; wp-config.php ise 640 veya 600 gibi daha sıkı bir değere çekilmelidir. Yanlış izinler (örneğin 777) web sunucusunun herkese yazma hakkı verdiği anlamına gelir ve yüklenen bir web shell'in her yere yazmasına kapı açar.

# Tüm dizinleri 755 yap
find /var/www/site -type d -exec chmod 755 {} \;

# Tüm dosyaları 644 yap
find /var/www/site -type f -exec chmod 644 {} \;

# wp-config.php'yi sıkılaştır
chmod 640 /var/www/site/wp-config.php

Buna ek olarak, mümkünse wp-content/uploads dizininde PHP çalıştırmayı tamamen engelleyin. Saldırganların en sık kullandığı taktik, bir açıktan yararlanıp uploads klasörüne zararlı bir PHP dosyası yüklemektir. Sunucu bu klasörde PHP çalıştırmayı reddederse, dosya yüklense bile çalışmaz:

# wp-content/uploads/.htaccess içine
<Files *.php>
  Require all denied
</Files>

wp-config.php sertleştirmesinin ayrıntıları — anahtarların (salts) yenilenmesi, dosyanın kök dizin dışına taşınması, DISALLOW_FILE_EDIT — kendi başına önemli bir konu; bunları wp-config.php güvenliği yazımızda ayrıntılı ele aldık.

XML-RPC ve REST API'yi Sınırlayın

Kullanmıyorsanız XML-RPC'yi tamamen kapatın; REST API'yi ise kimliği doğrulanmamış kullanıcıların kullanıcı listesini çekmesine izin vermeyecek biçimde sınırlayın. XML-RPC, brute force saldırılarını system.multicall yöntemiyle tek istekte yüzlerce parola denemesine dönüştürebildiği ve pingback DDoS'una alet edilebildiği için, modern sitelerin çoğunda gereksiz bir risktir.

Çoğu site XML-RPC'ye ihtiyaç duymaz (Jetpack ve bazı mobil uygulamalar dışında). Sunucu düzeyinde tamamen kapatmak en sağlamıdır:

# .htaccess — xmlrpc.php'ye erişimi tümden kapat
<Files xmlrpc.php>
  Require all denied
</Files>

REST API tarafında /wp-json/wp/v2/users uç noktası, kimlik doğrulaması olmadan kullanıcı adlarını dışarı sızdırabilir. Kimliği doğrulanmamış isteklerde kullanıcı numaralandırmasını engelleyin:

// Giriş yapmamış kullanıcılar için users uç noktasını kapat
add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        unset( $endpoints['/wp/v2/users'] );
        unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    }
    return $endpoints;
} );

Bu, saldırganların önce geçerli kullanıcı adlarını toplayıp sonra o hesaplara odaklı brute force yapmasını zorlaştırır.

Giriş Ekranını Koruyun

wp-login.php sayfası botların bir numaralı hedefidir; bu yüzden giriş denemelerini sınırlayın, giriş URL'sini değiştirin ve mümkünse yönetim paneline erişimi IP veya sunucu düzeyinde daraltın. Başarısız giriş denemelerine sınır koymak, otomatik parola deneme saldırılarını daha ilk denemelerde durdurur.

Uygulanabilir katmanlar şunlardır:

• Deneme sınırı: Belirli sayıda başarısız denemeden sonra IP'yi geçici olarak engelleyin.
• Giriş URL'sini gizleme: /wp-admin ve /wp-login.php yerine tahmin edilemez bir yola taşıyın; bu botların büyük kısmını daha eşikte eler.
• Sunucu düzeyinde kısıtlama: Yönetici sabit bir IP'den giriyorsa, wp-login.php'yi yalnızca o IP'ye açın.

# wp-login.php'yi yalnızca belirli bir IP'ye aç
<Files wp-login.php>
  Require ip 203.0.113.10
</Files>

Giriş güvenliği ve brute force koruması başlı başına derin bir konu; katmanlarını brute force saldırısı nasıl önlenir yazımızda daha ayrıntılı ele aldık.

Bir Web Uygulama Güvenlik Duvarı (WAF) Devreye Alın

WAF, sitenize gelen istekleri WordPress'e ulaşmadan önce süzen ve bilinen saldırı desenlerini (SQL injection, XSS, zararlı dosya yükleme, bilinen eklenti açıkları) engelleyen bir kalkandır. Bir eklentide henüz yamalanmamış bir açık bile olsa, iyi bir WAF o açığı sömüren isteği tanıyıp bloklayarak size güncelleme için zaman kazandırır — buna "sanal yama" denir.

WAF iki katmanda çalışabilir: DNS/bulut düzeyinde (trafik sitenize ulaşmadan bulutta filtrelenir) veya sunucu/eklenti düzeyinde. Bulut tabanlı WAF, trafiği kaynağa gelmeden temizlediği için performans açısından da avantajlıdır ve DDoS'a karşı ek koruma sağlar. Sunucu düzeyinde ise ModSecurity gibi bir WAF, kendi VPS'inizde çalışır.

WAF'ın sınırını bilmek önemli: WAF, kötü yapılandırmayı ve güncellemesizliği örtmez. Zaten sızılmış bir siteyi de temizlemez; yalnızca dışarıdan gelen saldırıyı filtreler. Bu yüzden WAF, güncelleme disiplini ve sertleştirmenin yerine değil, üzerine gelir.

WAF kurulumunda ek bir kazanç, güvenlik başlıklarını (security headers) da devreye almaktır. Content-Security-Policy, X-Frame-Options, X-Content-Type-Options ve Strict-Transport-Security gibi başlıklar, tarayıcı düzeyinde XSS ve clickjacking gibi saldırıların etkisini sınırlar. Bunları sunucu yapılandırmanıza ekleyebilirsiniz:

# .htaccess — temel güvenlik başlıkları
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Bu başlıklar tek başına bir açığı kapatmaz ama saldırının başarı şansını düşüren düşük maliyetli bir katmandır.

Yedekleme ve İzlemeyi Kurun

Son katman, bir şey ters gittiğinde ayakta kalmanızı sağlar: Düzenli, otomatik ve site dışında saklanan yedekler ile dosya bütünlüğünü izleyen bir sistem. Yedek, hiçbir güvenlik önleminin garanti etmediği tek şeyi sağlar — geri dönebilme yeteneği. En kötü senaryoda temiz bir yedekten dönmek, günlerce süren temizlikten çok daha hızlıdır.

Doğru yedek stratejisinin özellikleri:

• Otomatik ve düzenli: Günlük veya trafiğe göre daha sık; elle alınan yedek er ya da geç unutulur.
• Site dışında: Yedek aynı sunucuda durursa, sunucu ele geçirildiğinde yedek de gider.
• Test edilmiş: Geri yüklenemeyen yedek, yedek değildir; ara ara geri yükleme denemesi yapın.

İzleme tarafında ise dosya değişikliklerini takip eden bir sistem, sitenize sızıldığı anda haber verir. Çekirdek dosyalarının bütünlüğünü wp-cli ile hızlıca doğrulayabilirsiniz:

# Çekirdek dosyaları resmi sürümle karşılaştır (değişmiş/eklenmiş dosyaları bulur)
wp core verify-checksums

Bu komut beklenmedik bir değişiklik bildiriyorsa, büyük olasılıkla bir dosyaya müdahale edilmiştir. Böyle bir durumda ne yapmanız gerektiğini sitem hacklendi ne yapmalıyım yazımızda anlattık; gizlenen zararlı kodları ararken de arka kapı (backdoor) bulma rehberimiz yol gösterir.

Sık Sorulan Sorular

Sadece güvenlik eklentisi kursam yeter mi?

Hayır. Güvenlik eklentileri değerli bir katmandır ama tek başına yeterli değildir. Eklenti, güncellenmemiş bir çekirdeği, zayıf bir parolayı veya yanlış dosya izinlerini düzeltmez. Gerçek güvenlik; güncelleme disiplini, doğru yapılandırma, sunucu katmanı ve eklentinin birlikte çalışmasıyla oluşur.

WordPress güncellemeleri sitemi bozar mı diye çekiniyorum, ne yapmalıyım?

Güncellemeyi ertelemek, açık bir zafiyeti taşımaktan çok daha risklidir. Çözüm, güncellemeden önce mutlaka yedek almak ve büyük sürüm atlamalarını önce bir test/staging ortamında denemektir. Küçük güvenlik yamalarını ise otomatiğe alabilirsiniz; bunlar nadiren sorun çıkarır.

XML-RPC'yi kapatırsam bir şey bozulur mu?

Çoğu modern sitede hiçbir şey bozulmaz. Yalnızca Jetpack'in bazı özellikleri, WordPress mobil uygulaması ve bazı uzaktan yayınlama araçları XML-RPC kullanır. Bunları kullanmıyorsanız kapatmak güvenlidir. Kullanıyorsanız, tümden kapatmak yerine XML-RPC'ye erişimi WAF veya deneme sınırıyla korumak daha uygundur.

Dosya izinlerini 777 yapmam gerektiği söyleniyor, doğru mu?

Kesinlikle hayır. 777 izni, dosyaya sunucudaki herkesin yazabilmesi demektir ve ciddi bir güvenlik açığıdır. Bir eklenti "çalışması için 777 gerekli" diyorsa, o eklenti ya da barındırma yapılandırması hatalıdır. Doğru değerler dizinler için 755, dosyalar için 644, wp-config.php için 640 veya 600'dür.

Sitem daha önce hacklendi, sertleştirme yaparsam temizlenir mi?

Hayır. Sertleştirme, gelecekteki saldırıları önler; hâlihazırda yerleşmiş bir zararlı yazılımı veya arka kapıyı temizlemez. Zaten sızılmış bir sitede önce kapsamlı bir temizlik yapılmalı, sonra bu sertleştirme adımları uygulanmalıdır. Aksi halde saldırgan bıraktığı arka kapıdan geri döner.

---

WordPress sitenizde bu adımların hangilerinin eksik olduğundan emin değilseniz, ücretsiz bir teşhis ile başlayalım: Sitenizi tarayıp açık kalan noktaları raporlayalım. Acil bir durumda 7/24 WhatsApp hattımızdan bize ulaşabilir, WordPress virüs temizleme ve bakım ve izleme hizmetlerimizle sitenizi hem temizleyip hem de kalıcı olarak koruma altına alabilirsiniz.