wp-config.php Güvenliği: İzinler, Salt Anahtarları ve Sızıntı Riskleri

wp-config.php, WordPress kurulumunuzun en değerli dosyasıdır: veritabanı parolanız, kimlik doğrulama anahtarlarınız ve sitenin temel güvenlik ayarları burada durur. Bu dosyayı okuyabilen biri sitenizin tamamını ele geçirebilir — veritabanına bağlanır, kendine yönetici açar, dilediği içeriği basar. Buna rağmen müdahale ettiğimiz vakalarda en sık gördüğümüz zafiyetlerden bazıları tam da bu dosyayla ilgilidir: herkese okunabilir izinler, yıllardır değişmemiş salt anahtarları ve sunucuda unutulmuş wp-config.php.bak kopyaları. Bu yazıda dosyayı adım adım sertleştiriyoruz.

Dosya İzinleri: İlk ve En Ucuz Önlem

wp-config.php yalnızca web sunucusu kullanıcısı tarafından okunabilmelidir. Mevcut durumu kontrol edin:

ls -l wp-config.php

-rw-r--r-- (644) görüyorsanız dosya sunucudaki tüm kullanıcılar tarafından okunabilir durumdadır. Paylaşımlı hosting'de bu, aynı sunucudaki başka bir müşterinin (veya ele geçirilmiş komşu bir sitenin) veritabanı parolanızı okuyabilmesi anlamına gelebilir. Sıkılaştırın:

chmod 600 wp-config.php

600 bazı hosting yapılandırmalarında (PHP'nin farklı kullanıcıyla çalıştığı durumlarda) siteyi bozarsa 640 deneyin; 644te bırakmayı son çare olarak görün. Ek bir katman olarak dosyaya web üzerinden doğrudan erişimi de kapatın. Apache için .htaccesse:

<Files wp-config.php>
    Require all denied
</Files>

Nginx kullanıyorsanız sunucu bloğuna:

location = /wp-config.php { deny all; }

Normalde PHP dosyası kaynak kodunu dışarı vermez; ama PHP'nin devre dışı kaldığı bir bakım anında veya yanlış yapılandırmada bu kural sizi kurtarır.

Salt Anahtarları: Oturum Güvenliğinin Temeli

Dosyadaki AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY ve dört SALT sabiti, WordPress'in oturum çerezlerini imzalamak için kullanılır. İki yaygın sorun görürüz:

1. Varsayılan değerler: bazı elle kurulumlarda anahtarlar put your unique phrase here olarak bırakılır. Bu durumda çerezleriniz tahmin edilebilir şekilde imzalanır.
2. Sızmış anahtarlar: site daha önce hacklendiyse saldırgan bu anahtarları okumuştur ve parola değişse bile geçerli oturum çerezi üretebilir.

Yeni anahtarları WordPress'in resmi servisinden alın:

curl -s https://api.wordpress.org/secret-key/1.1/salt/

Çıktıyı wp-config.phpteki eski sekiz satırın yerine yapıştırın. WP-CLI ile tek komut:

wp config shuffle-salts

Anahtarları değiştirdiğiniz anda tüm kullanıcıların oturumları kapanır — bu bir hata değil, özelliktir. Şüpheli bir durumda (hack sonrası, ayrılan bir çalışan, parola sızıntısı) parola değişikliğiyle birlikte salt yenilemek standart prosedürümüzdür. Hack sonrası atılacak adımların tamamı için hacklenme belirtileri ve acil adımlar yazımıza bakın.

Tablo Öneki: Sınırlı Ama Bedava Bir Katman

Varsayılan wp_ öneki yerine özel bir önek kullanmak (wp_users yerine k7x_users gibi), tablo adlarını körlemesine hedefleyen otomatik SQL enjeksiyon betiklerinin bir kısmını boşa düşürür:

$table_prefix = 'k7x_';

Dürüst olalım: bu bir güvenlik duvarı değildir. Enjeksiyon açığı bulan hedefli bir saldırgan tablo adlarını information_schema üzerinden zaten öğrenir. Yine de yeni kurulumda maliyeti sıfır olduğu için öneririz. Çalışan bir sitede öneki değiştirmek ise tablo adlarının ve wp_options ile wp_usermeta içindeki önekli kayıtların birlikte güncellenmesini gerektirir; yedeksiz denemeyin.

Veritabanı Kimlik Bilgileri: Az Yetki, Ayrı Kullanıcı

wp-config.php'nin koruduğu asıl sır veritabanı erişimidir; o yüzden erişimin kendisi de dar tutulmalıdır:

• Her siteye ayrı veritabanı ve ayrı kullanıcı. Aynı sunucuda beş site tek veritabanı kullanıcısını paylaşıyorsa, bir sitenin ele geçirilmesi beşinin de veritabanını açar. Müdahale ettiğimiz çoklu-site vakalarında enfeksiyonun siteden siteye bu yoldan yayıldığını sık görürüz.
• root asla. DB_USER satırında root görüyorsanız bugün değiştirin; WordPress kullanıcısının yalnızca kendi veritabanında SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP yetkilerine ihtiyacı vardır.
• DB_HOST localhost kalsın. Veritabanı aynı sunucudaysa MySQL'in dışarıya açık bir portta dinlemesine gerek yoktur; bind-address = 127.0.0.1 ile dış erişimi tamamen kapatın.

Parolanın kendisi de uzun ve rastgele olmalıdır — sitenin adından türetilmiş, başka yerde de kullanılan parolalar sızıntı listelerinde ilk denenendir:

openssl rand -base64 24

DISALLOW_FILE_EDIT: Paneldeki Kod Editörünü Kilitleyin

WordPress panelindeki Görünüm → Tema Dosyası Düzenleyicisi, yönetici oturumu ele geçiren bir saldırgan için hazır bir web shell'dir: tarayıcıdan functions.php'ye üç satır ekleyerek tam kontrol sağlar. Müdahale ettiğimiz vakalarda saldırganların en sık kullandığı yollardan biri budur. Kapatın:

define('DISALLOW_FILE_EDIT', true);

Bir adım ileri gitmek isterseniz panelden eklenti/tema kurulumu ve güncellemeyi de kapatabilirsiniz:

define('DISALLOW_FILE_MODS', true);

DISALLOW_FILE_MODS güncellemeleri de engellediği için yalnızca dağıtımı Git/WP-CLI ile yapılan, yönetilen sitelere uygundur. Hangi modelin size uyduğundan emin değilseniz bakım ve izleme hizmetimiz kapsamında bu kararları sizin adınıza veriyor ve güncellemeleri kontrollü şekilde biz uyguluyoruz.

Debug Ayarları: Bilgi Sızıntısını Kapatın

WP_DEBUG açık unutulmuş bir üretim sitesi, hata mesajlarıyla birlikte dosya yollarını, veritabanı sorgularını ve bazen kullanıcı verilerini ziyaretçiye döker. Doğru üretim yapılandırması:

define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);

Bir sorunu ayıklamanız gerekiyorsa logu açın ama ekrana basmayın:

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);

Kritik ayrıntı: WP_DEBUG_LOG varsayılan olarak wp-content/debug.log dosyasına yazar ve bu dosya web üzerinden herkese açıktır. siteniz.com/wp-content/debug.log adresini tarayıcıdan deneyin; açılıyorsa kapatın ya da logu web kökü dışına yönlendirin:

define('WP_DEBUG_LOG', '/var/log/wp/debug.log');

Yedek Dosya Sızıntısı: wp-config.php.bak Tuzağı

En sinsi risklerden biri budur. Bir düzenleme öncesi "tedbir" olarak alınan kopyalar — wp-config.php.bak, wp-config.php.old, wp-config.php~, wp-config.txt, wp-config.php.save — felaket kapısıdır. Neden? Çünkü sunucu .bak, .old, .txt ve ~ uzantılı dosyaları PHP olarak çalıştırmaz, düz metin olarak sunar. Yani siteniz.com/wp-config.php.bak adresini bilen herkes veritabanı parolanız dahil dosyanın tamamını okur. Otomatik tarayıcılar bu adları her gün, her sitede dener.

Sunucunuzda bu tür kalıntıları arayın:

find /var/www -maxdepth 2 -type f \( -name "wp-config*" ! -name "wp-config.php" ! -name "wp-config-sample.php" \)

Bulduklarınızı silin. Ayrıca editörlerin bıraktığı geçici kopyaları (.swp, ~) ve sürüm dizinlerini (.git/ web kökünde açıksa config dosyası okunabilir) da kontrol edin. Kalıcı çözüm olarak yedeklerinizi web kökünün tamamen dışında tutun ve sunucu tarafında bu uzantılara erişimi kapatın:

<FilesMatch "\.(bak|old|save|swp|orig|txt)$">
    Require all denied
</FilesMatch>

Ek Sertleştirmeler

Aynı dosyada birkaç faydalı satır daha:

define('FORCE_SSL_ADMIN', true);      // Panel her zaman HTTPS üzerinden
define('WP_AUTO_UPDATE_CORE', 'minor'); // Güvenlik yamaları otomatik gelsin
define('WP_POST_REVISIONS', 10);      // Revizyon şişmesini sınırla

Bir hatırlatma: wp-config.php'yi web kökünün bir üst dizinine taşımak da yaygın bir tavsiyedir; WordPress dosyayı orada otomatik bulur. Kazandırdığı, kök dizini düz metin olarak ifşa eden yanlış yapılandırma senaryolarına karşı ek bir katmandır — izinler ve erişim kurallarıyla birlikte düşünülmelidir, onların yerine değil.

Son olarak: wp-config sertleştirmesi bütünün bir parçasıdır. Giriş sayfanız kaba kuvvet saldırısına açıksa (Fail2ban kurulumu bu konuda iyi bir başlangıçtır) veya sunucunuzda başka zafiyetler varsa tek dosyayı kilitlemek yetmez. Sitenizin ve sunucunuzun genel durumunu görmek için sunucu güvenlik kontrolü hizmetimize göz atabilirsiniz.

Sık Sorulan Sorular

wp-config.php için en doğru izin değeri nedir?

Hedef 600dür (yalnızca dosya sahibi okur-yazar). PHP'nin dosya sahibinden farklı bir kullanıcıyla çalıştığı yapılandırmalarda 640 gerekir. 644 ancak son çare olmalıdır; 777 hiçbir koşulda kabul edilemez.

Salt anahtarlarını değiştirirsem sitede bir şey bozulur mu?

Hayır. Tek etkisi, aranızda siz de dahil tüm kullanıcıların oturumlarının kapanması ve yeniden giriş yapılmasıdır. İçerik, ayarlar ve parolalar etkilenmez. Hack şüphesinde bu zaten istediğiniz sonuçtur.

Sitem zaten hacklendiyse bu ayarlar işe yarar mı?

Sıralama önemli: önce temizlik, sonra sertleştirme. Sistemde arka kapı varken yapılan her ayar, saldırgan tarafından geri alınabilir. Önce arka kapı taraması ve tam temizlik, ardından bu yazıdaki adımlar uygulanmalıdır.

wp-config.php.bak dosyam olup olmadığını dışarıdan nasıl anlarım?

Tarayıcıya siteniz.com/wp-config.php.bak (ve .old, .txt, .save varyasyonlarını) yazın. Dosya içeriği görünüyorsa acil durumdasınız: dosyayı hemen silin, veritabanı parolanızı ve salt anahtarlarınızı değiştirin.

---

wp-config dosyanızın ve genel kurulumunuzun ne durumda olduğundan emin değilseniz, ücretsiz ön teşhisle sitenizi kontrol edelim; bulguları yorumsuz bir raporla paylaşırız. Sertleştirme ve düzenli takibi üstlenmemizi isterseniz bakım ve izleme hizmetimize bakın; şüpheli bir durum varsa WhatsApp üzerinden 7/24 acil müdahale ekibimize ulaşabilirsiniz.