wp-config.php Guvenlik Ayarlari ve Sertlestirme

WordPress kurulumunuzdaki en değerli tek dosya wp-config.php'dir. Bu dosya, sitenizin veritabanına hangi kullanıcı adı ve şifreyle bağlandığını, oturum çerezlerini şifreleyen gizli anahtarları, tablo ön ekini ve WordPress'in çalışma biçimini belirleyen onlarca sabiti barındırır. Bir saldırgan bu dosyanın içeriğini okuyabilirse, veritabanınıza doğrudan erişim sağlayabilir; içeriğini değiştirebilirse, sitenize kalıcı bir arka kapı yerleştirebilir. Kısacası tema ya da eklenti dosyalarının çoğu kaybolsa siteyi yeniden kurabilirsiniz, ama wp-config.php ve veritabanı ele geçtiğinde işiniz gerçekten zorlaşır.

Buna rağmen çoğu WordPress kurulumu bu dosyayı kurulum sihirbazının bıraktığı varsayılan haliyle çalıştırmaya devam eder. Oysa birkaç satırlık ekleme ve doğru dosya izinleriyle, wp-config.php sitenizin en zayıf değil en sağlam noktalarından biri hâline gelebilir. Bu rehberde, kıdemli bir sistem yöneticisinin bir müşteriye anlatacağı sırayla ilerleyeceğiz: önce dosyanın neden bu kadar kritik olduğunu, sonra da güvenlik anahtarlarını yenilemekten dosyayı bir üst dizine taşımaya kadar uygulanabilir sertleştirme adımlarını tek tek göstereceğiz. Her adımda gerçek komutlar ve örnek yapılandırmalar bulacaksınız.

wp-config.php Neden Bu Kadar Kritik#

wp-config.php, WordPress kök dizininde bulunan ve PHP tarafından her istekte okunan bir yapılandırma dosyasıdır. İçinde en az şu hassas bilgiler yer alır: veritabanı adı (DB_NAME), veritabanı kullanıcısı (DB_USER), veritabanı şifresi (DB_PASSWORD), veritabanı sunucusu (DB_HOST), tablo ön eki ($table_prefix) ve sekiz adet güvenlik anahtarı (SALT). Bu değerlerin tamamı düz metin olarak durur; şifrelenmiş değildirler çünkü PHP'nin onları çalışma anında okuyup kullanması gerekir.

Tehlike şuradan gelir: yanlış yapılandırılmış bir web sunucusu, .php uzantılı bir dosyayı yorumlamak yerine kaynak kodunu tarayıcıya gönderebilir. Örneğin PHP işleyicisi çöktüğünde ya da bir yedekleme aracı wp-config.php.bak, wp-config.old gibi kopyalar bıraktığında, bu kopyalar .php olarak işlenmez ve içerikleri olduğu gibi indirilebilir hâle gelir. Bir saldırgan bu içeriği ele geçirdiğinde veritabanınıza dışarıdan bağlanmayı deneyebilir. Bu yüzden hem dosyanın kendisini hem de olası kopyalarını korumak gerekir.

Bir örnekle netleştirelim. Aşağıdaki gibi bir yedekleme kopyası kök dizinde durursa, bu dosya tarayıcıdan doğrudan okunabilir:

# Tehlikeli: bu dosyalar web'den indirilebilir
/var/www/site/wp-config.php.bak
/var/www/site/wp-config.old
/var/www/site/wp-config.txt

İlk kural bu tür kopyaları asla web kök dizininde bırakmamaktır. Sunucu tarafı yedeklemelerinizi web erişimine kapalı bir dizinde tutun; düzenli ve otomatik yedekler için yedekleme hizmetimize göz atabilirsiniz.

Güvenlik Anahtarlarını (SALT) Yenileme#

WordPress, oturum çerezlerini ve bazı geçici verileri şifrelemek için sekiz adet gizli anahtar kullanır: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY ve bunların _SALT karşılıkları. Bu değerler ne kadar uzun ve rastgele olursa, bir saldırganın çalınmış bir çerezi kaba kuvvetle çözmesi o kadar zorlaşır. Eski kurulumlarda ya da elle taşınmış sitelerde bu anahtarların hâlâ put your unique phrase here gibi varsayılan bir metin olduğunu görmek şaşırtıcı değildir.

WordPress'in kendi resmî üreteci güçlü değerler oluşturur, ama bunu sunucuda tek komutla da yapabilirsiniz. WP-CLI kuruluysa en pratik yol şudur:

# Mevcut anahtarları güvenli yenileriyle değiştirir
wp config shuffle-salts

WP-CLI yoksa anahtarları elle güncelleyebilirsiniz. wp-config.php içindeki define('AUTH_KEY', ...) satırlarını bularak her birini uzun, rastgele bir dizeyle değiştirin:

define('AUTH_KEY',         'k9#Lm2@vXq7!pR4$zT8wYb1&nH6dJ3fG');
define('SECURE_AUTH_KEY',  'Q2wE5rT8yU1iO4pA7sD0fG3hJ6kL9zX');
define('LOGGED_IN_KEY',    'zX9cV6bN3mK0lP7oI4uY1tR8eW5qA2sD');
define('NONCE_KEY',        'M1n2B3v4C5x6Z7l8K9j0H1g2F3d4S5a6');
define('AUTH_SALT',        'p0O9i8U7y6T5r4E3w2Q1a2S3d4F5g6H7');
define('SECURE_AUTH_SALT', 'L8k7J6h5G4f3D2s1A0z9X8c7V6b5N4m3');
define('LOGGED_IN_SALT',   'r5T4y3U2i1O0p9A8s7D6f5G4h3J2k1L0');
define('NONCE_SALT',       'v3B2n1M0k9L8j7H6g5F4d3S2a1Q0w9E8');

Anahtarları değiştirdiğiniz an tüm mevcut oturumlar geçersiz olur; siz ve tüm kullanıcılar yeniden giriş yapmak zorunda kalırsınız. Bu aslında bir özelliktir: bir hesabın ele geçirildiğinden şüpheleniyorsanız, anahtarları yenilemek çalınmış çerezleri anında kullanılamaz hâle getirir. Anahtarları en az yılda bir, güvenlik olayı yaşandığında ise hemen yenilemeyi alışkanlık hâline getirin.

Dosya Düzenleme Yetkisini Kapatma#

WordPress yönetim panelinde, Görünüm ve Eklentiler altında tema ile eklenti dosyalarını doğrudan tarayıcıdan düzenleyebileceğiniz bir editör bulunur. Kulağa pratik gelse de bu, güvenlik açısından ciddi bir risktir. Bir saldırgan yönetici hesabına erişebilirse, bu editörü kullanarak sunucuya tek satır kod yazmadan zararlı PHP yerleştirebilir; yani panel erişimi doğrudan sunucuda kod çalıştırma yetkisine dönüşür.

Bu editörü kapatmak için wp-config.php dosyanıza tek bir sabit eklemeniz yeterlidir:

// Panel içi dosya editörünü tamamen devre dışı bırakır
define('DISALLOW_FILE_EDIT', true);

Daha da ileri gitmek isterseniz, panel üzerinden eklenti/tema kurulumunu ve güncellemesini de engelleyebilirsiniz. Bu, dosyaları yalnızca SSH veya SFTP ile yönetmek istediğiniz sıkı ortamlar için uygundur:

// Panelden eklenti/tema yukleme, kurma ve guncellemeyi engeller
define('DISALLOW_FILE_MODS', true);

DISALLOW_FILE_MODS açıkken WordPress'in kendi güncellemelerini de panelden yapamayacağınızı unutmayın; güncellemeleri WP-CLI ya da sürüm yükseltme betikleriyle yönetmeniz gerekir. Çoğu kurulum için yalnızca DISALLOW_FILE_EDIT yeterli ve dengeli bir seçimdir. Bu ve benzeri sertleştirme başlıklarını bir arada ele alan WordPress güvenliği rehberimizi de incelemenizi öneririm.

SSL ve Yönetim Paneli Trafiğini Zorlama#

Yönetim paneline giriş yaparken kullanıcı adınız, şifreniz ve oturum çereziniz ağ üzerinden geçer. Bu trafik şifresizse, aynı ağda oturan biri bunları dinleyebilir. Bugün her ciddi sitenin HTTPS kullanması gerekir ve wp-config.php içindeki bir sabitle en azından panel trafiğini HTTPS'e zorlayabilirsiniz:

// Yonetim paneli ve giris ekranini HTTPS'e zorlar
define('FORCE_SSL_ADMIN', true);

Bir yük dengeleyici ya da ters vekil (reverse proxy) arkasındaysanız, WordPress isteğin aslında HTTPS ile geldiğini anlamayabilir. Bu durumda proxy'nin gönderdiği başlığı okuyacak bir kontrolü de eklemeniz gerekir. Bu satır, require_once çağrısından önce durmalıdır:

// Ters vekil arkasinda HTTPS'i dogru algilamak icin
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

SSL yapılandırmasının tamamlanması için elbette geçerli bir sertifikaya ihtiyacınız var. Sertifika kurulumu ve yenileme tarafını dert etmek istemiyorsanız SSL çözümlerimize bakabilir, ek katman olarak istekleri sunucuya ulaşmadan filtreleyen WAF hizmetimizi değerlendirebilirsiniz.

Tablo Ön Ekini Değiştirme#

WordPress varsayılan olarak tüm veritabanı tablolarını wp_ ön ekiyle oluşturur: wp_users, wp_posts, wp_options gibi. Saldırganların otomatik araçları çoğu zaman bu varsayılan ön eki hedefler; özellikle SQL enjeksiyonu denemelerinde tablo adlarının tahmin edilebilir olması işlerini kolaylaştırır. Ön eki rastgele bir değerle değiştirmek sihirli bir kalkan değildir ama saldırı yüzeyini ölçülebilir biçimde daraltan, düşük maliyetli bir önlemdir.

Yeni bir kurulumda bu değişikliği yapmak çok basittir; wp-config.php içindeki tek satırı düzenlemeniz yeterlidir:

// Varsayilan wp_ yerine tahmin edilmesi zor bir on ek
$table_prefix = 'x7k_';

Zaten çalışan bir sitede ön eki değiştirmek daha dikkat ister, çünkü hem tabloları hem de bazı kayıtların içindeki referansları güncellemeniz gerekir. WP-CLI bu işi güvenli biçimde otomatikleştirir:

# Mevcut sitede tablo on ekini guvenle degistirir
wp db export yedek-once.sql
wp config set table_prefix x7k_
wp db query "RENAME TABLE wp_users TO x7k_users, wp_posts TO x7k_posts;"

Elle yapıyorsanız, yalnızca tabloları yeniden adlandırmak yetmez; x7k_options içindeki wp_user_roles ve x7k_usermeta içindeki wp_capabilities, wp_user_level gibi anahtarları da yeni ön ekle güncellemeniz gerekir, yoksa kullanıcı yetkileri bozulur. Bu yüzden bu işlemi mutlaka tam bir yedek aldıktan sonra yapın. İşlem öncesi ve sonrası yedekler için otomatik yedekleme altyapımızdan yararlanabilirsiniz.

Doğru Dosya İzinleri (600 / 640)#

Bir dosyanın içeriğini kimin okuyabileceğini belirleyen şey, dosya izinleridir. wp-config.php gibi sırlar barındıran bir dosyanın herkes tarafından okunabilir olması (644 ya da daha geniş) kabul edilemez, çünkü aynı sunucudaki başka bir kullanıcı hesabı bu dosyayı okuyabilir. Amacınız, dosyayı yalnızca web sunucusunun çalıştığı kullanıcının okuyabilmesini sağlamaktır.

Tekil bir sunucuda tipik ve güvenli değerler şöyledir:

# Sadece sahibi okur/yazar; grup ve digerleri hicbir sey
chmod 600 wp-config.php
chown www-data:www-data wp-config.php

Web sunucusu ile dosya sahibinin farklı kullanıcılar olduğu ama aynı grupta bulunduğu kurulumlarda 640 daha uygundur; böylece sahip okuyup yazabilir, grup yalnızca okur, diğerleri hiçbir şey yapamaz:

# Sahip okur/yazar, grup okur, digerleri erisemez
chmod 640 wp-config.php

Aşağıdaki tablo, olası izin değerlerinin ne anlama geldiğini ve wp-config.php için uygunluğunu özetliyor:

İzinlerin mantığını daha derinlemesine anlamak için Linux dosya izinleri rehberimize göz atabilirsiniz. Genel WordPress dizin yapısında ise kural şudur: dizinler 755, dosyalar 644, ama wp-config.php bir istisna olarak 600 ya da 640 olmalıdır.

wp-config.php'yi Bir Üst Dizine Taşıma#

WordPress'in az bilinen ama güçlü bir davranışı vardır: eğer wp-config.php dosyasını web kök dizinde bulamazsa, bir üst dizine bakar ve orada bulursa yükler. Bu, dosyayı web sunucusunun servis ettiği alanın tamamen dışına taşımanızı sağlar; yani en kötü senaryoda bile dosya tarayıcıdan asla erişilemez hâle gelir.

Diyelim ki siteniz /var/www/site/public_html dizininde yayınlanıyor. wp-config.php dosyasını bir üst dizine taşımanız yeterlidir:

# Dosyayi web kokunun bir ustune tasi
mv /var/www/site/public_html/wp-config.php /var/www/site/wp-config.php
chmod 600 /var/www/site/wp-config.php

WordPress bu dosyayı otomatik olarak bulur; ek bir ayar gerekmez. Ancak bu yöntem yalnızca web kökünüzün gerçekten bir alt dizin olduğu kurulumlarda işe yarar. Paylaşımlı hostinglerde üst dizine erişiminiz olmayabilir; bu durumda dosyayı taşımak yerine web sunucusu kuralıyla erişimini engellemek daha uygundur.

Nginx kullanıyorsanız, dosyaya doğrudan erişimi şu kuralla kapatabilirsiniz:

# wp-config.php'ye dogrudan HTTP erisimini engelle
location = /wp-config.php {
    deny all;
    return 404;
}

Apache tarafında ise .htaccess dosyasına eklenecek şu blok aynı işi görür:

# wp-config.php ve yedek kopyalarina erisimi kapat
<FilesMatch "^wp-config\.(php|bak|old|txt)$">
    Require all denied
</FilesMatch>

Bu iki katmanı birlikte kullanmak en sağlıklısıdır: mümkünse dosyayı üst dizine taşıyın, taşıyamıyorsanız web sunucusu kuralıyla erişimi kesin. Yönetilen bir ortamda bu tür sunucu ayarlarıyla uğraşmak istemiyorsanız, WordPress'e özel hosting paketlerimiz bu sertleştirmelerin çoğunu hazır sunar; sunucu tarafını tümüyle bize bırakmak isterseniz sunucu yönetimi hizmetimiz devreye girer.

Ek Sertleştirme Sabitleri#

Yukarıdaki temel adımların ötesinde, wp-config.php'ye ekleyebileceğiniz birkaç sabit daha güvenliği somut biçimde artırır. Bunları ihtiyacınıza göre seçerek uygulayın. Örneğin sürüm yükseltmelerini otomatikleştirmek, hata ayıklama çıktısını üretimde kapatmak ve gereksiz sürüm bilgisini gizlemek çoğu site için mantıklıdır:

// Uretimde hata ciktisini asla ekranda gosterme
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

// Gerekiyorsa hatalari yalnizca dosyaya yaz
define('WP_DEBUG_LOG', true);

// Kucuk cekirdek guvenlik guncellemelerini otomatik uygula
define('WP_AUTO_UPDATE_CORE', 'minor');

// Cop kutusundaki icerigi 7 gunde bir temizle
define('EMPTY_TRASH_DAYS', 7);

WP_DEBUG_DISPLAY değerinin üretimde mutlaka false olması gerektiğinin altını çizmek isterim; aksi hâlde bir PHP hatası, dosya yollarını ve bazen veritabanı ayrıntılarını ziyaretçilere sızdırabilir. Hata kayıtlarını görmek istiyorsanız WP_DEBUG_LOG ile bunları web erişimine kapalı bir günlük dosyasına yönlendirin. Tüm bu bakım ve izleme süreçlerini sizin adınıza yürütmemizi isterseniz WordPress bakım hizmetimiz bu ayarların düzenli denetimini de kapsar.

Sıkça Sorulan Sorular#

wp-config.php'deki güvenlik anahtarlarını değiştirmek zararlı olur mu?#

Anahtarları değiştirmek sitenizin içeriğine ya da veritabanınıza hiçbir zarar vermez; yalnızca o an açık olan tüm oturumları geçersiz kılar. Yani siz ve tüm kullanıcılar bir kez yeniden giriş yapmak zorunda kalır, o kadar. Bu yüzden anahtar yenilemeyi düzenli bir güvenlik alışkanlığı hâline getirebilir, bir ihlal şüphesinde ise hiç tereddüt etmeden hemen uygulayabilirsiniz.

wp-config.php dosyasına 600 mü yoksa 640 izni mi vermeliyim?#

Web sunucusu süreciyle dosya sahibi aynı kullanıcıysa 600 en güvenli seçenektir, çünkü dosyayı yalnızca o kullanıcı okuyabilir. Web sunucusunun ayrı bir kullanıcı olarak çalıştığı ama dosya sahibiyle aynı grupta bulunduğu kurulumlarda ise 640 gerekir, aksi hâlde sunucu dosyayı okuyamaz ve site açılmaz. Doğru değeri seçmek için barındırma ortamınızın PHP'yi hangi kullanıcıyla çalıştırdığını öğrenin.

DISALLOW_FILE_EDIT ile DISALLOW_FILE_MODS arasındaki fark nedir?#

Bu iki sabit farklı kapsamlara sahiptir. DISALLOW_FILE_EDIT yalnızca panel içindeki tema ve eklenti kod editörünü kapatır; eklenti kurmaya ve güncellemeye devam edebilirsiniz. DISALLOW_FILE_MODS ise bunun ötesine geçer ve panelden yapılan tüm dosya değişikliklerini, yani eklenti/tema kurulumunu, silmeyi ve güncellemeyi de engeller. Çoğu site için yalnızca DISALLOW_FILE_EDIT dengeli bir tercihtir; sıkı yönetilen ortamlarda ise ikisini birlikte kullanmak mantıklıdır.

wp-config.php'yi üst dizine taşımak her sunucuda çalışır mı?#

Bu yöntem, web kökünüzün gerçekten bir alt dizin olduğu ve bir üst dizine yazma erişiminizin bulunduğu kurulumlarda sorunsuz çalışır. WordPress dosyayı bir üst dizinde otomatik olarak arar, bu yüzden ekstra bir ayar gerekmez. Ancak bazı paylaşımlı hostinglerde üst dizine erişemezsiniz; böyle durumlarda dosyayı taşımak yerine Nginx ya da Apache kuralıyla dosyaya doğrudan HTTP erişimini engellemek en pratik çözümdür.

Çalışan bir sitede tablo ön ekini güvenle değiştirebilir miyim?#

Evet, ancak bu işlem yalnızca tabloları yeniden adlandırmaktan ibaret değildir; options ve usermeta tablolarındaki bazı kayıtların da eski ön eke referans verdiğini unutmayın. Bu referanslar güncellenmezse kullanıcı yetkileri bozulabilir. En güvenli yol, önce tam bir veritabanı yedeği almak ve ardından WP-CLI'nin wp config set komutuyla değişikliği yönetmektir. Elle yapıyorsanız, yeniden adlandırma sonrası ilgili option ve usermeta anahtarlarını da mutlaka yeni ön ekle düzeltin.

wp-config.php'nin yedek kopyaları neden tehlikelidir?#

Yedek kopyalar tehlikelidir çünkü wp-config.php.bak ya da wp-config.old gibi dosyalar .php olarak işlenmez, dolayısıyla web sunucusu bunların içeriğini kaynak kod olarak değil düz metin olarak sunar. Bu da veritabanı şifreniz dâhil tüm sırların tarayıcıdan doğrudan indirilebilmesi anlamına gelir. Bu yüzden yedek kopyaları asla web kök dizininde bırakmayın ve sunucu yapılandırmanızda bu uzantılara erişimi kural bazında engelleyin.

Kapanış#

wp-config.php sertleştirmesi, tek bir büyük değişiklik değil; güçlü güvenlik anahtarları, kapalı dosya editörü, zorunlu HTTPS, tahmin edilemez tablo ön eki, sıkı dosya izinleri ve dosyanın web erişiminin dışına taşınması gibi küçük ama birbirini tamamlayan adımların toplamıdır. Bu adımların her biri tek başına saldırı yüzeyini biraz daraltır; birlikte uygulandığında ise sitenizin en kritik dosyasını gerçek anlamda savunulabilir hâle getirir. Yarım saatlik bir çalışmayla elde edeceğiniz koruma, olası bir ihlalin size maliyetinin yanında hiçbir şeydir.

Bu sertleştirmeleri sizin adınıza hazır sunan altyapılara geçmek isterseniz, WordPress'e özel hosting paketlerimize ya da genel web hosting çözümlerimize göz atabilirsiniz. Sunucu tarafını tümüyle uzmanlara bırakmak isteyenler için sunucu yönetimi ve düzenli WordPress bakım hizmetlerimiz, bu rehberdeki tüm adımların sürekli denetimini de üstlenir. Güvenli bir başlangıç, sitenizin en değerli dosyasını korumakla başlar.