wp-config.php sertleştirme: kontrol edilecek 10 ayar

wp-config.php dosyası veritabanı parolanızı, her oturum çerezini imzalayan anahtarları ve hataların ziyaretçilere gösterilip gösterilmeyeceğini belirleyen ayarları barındırır. Çoğu site sahibi bu dosyayı hiç açmamıştır. Bu wp-config.php sertleştirme rehberi, tek bir dosya için hazırlanmış on maddelik bir denetimdir. Her kontrol için tam satırı, canlı ortam değerini, nasıl doğrulayacağınızı ve ilgili ayarın neye karşı koruma sağlamadığını bulacaksınız.

wp-config.php neyi yönetir ve beyaz ekran görmeden nasıl düzenlenir

Dosyada üç tür içerik vardır. Birincisi veritabanı kimlik bilgileri. İkincisi sekiz güvenlik anahtarı ve salt değeri. Üçüncüsü WordPress'in davranışını değiştiren sabitler. Dosyayı okuyabilen herkes veritabanınıza girebilir. Dosyaya yazabilen herkes her sayfa yüklemesinde kod çalıştırabilir.

Aynı zamanda bozulması en kolay dosyadır. Eksik tek bir noktalı virgül, tüm ziyaretçiler için beyaz ekrana ya da ölümcül hataya yol açar. Her seferinde şu akışı izleyin:

1. Mevcut dosyanın bir kopyasını bilgisayarınıza indirin.
2. Dosyayı tarayıcı tabanlı bir dosya yöneticisinde ya da eklentide değil, SFTP veya SSH üzerinden düzenleyin.
3. Kabuk (shell) erişiminiz varsa php -l wp-config.php komutunu çalıştırın. Çıktı "No syntax errors detected" olmalıdır.
4. Ön yüzü ve /wp-admin/ sayfasını gizli bir pencerede yeniden yükleyin.
5. Bir şey bozulursa kendi kopyanızı geri yükleyin. Düzenlemeyi sonra sakin sakin düzeltirsiniz.
6. Her şey çalışıyorsa sunucuda oluşturduğunuz geçici kopyaları (örneğin wp-config.php.bak) silin. Bilgisayarınızdaki kopyayı saklayın.

Yerleşim önemlidir. Dosyanın altına yakın bir yerde /* That's all, stop editing! Happy publishing. */ yorumunu ve ardından require_once ABSPATH . 'wp-settings.php'; satırını görürsünüz. Bu satırdan sonra tanımlanan sabitler çoğu ayar için çok geç kalır. Yeni her define() satırını bu yorumun üstüne ekleyin. Resmî kaynak, WordPress geliştirici belgelerindeki wp-config.php sayfasıdır.

Gizli değerler: veritabanı kimlik bilgileri ile benzersiz güvenlik anahtarları ve salt değerleri

Kontrol 1: veritabanı kimlik bilgileri. DB_USER, yalnızca bu site için var olan ve uzun, rastgele bir parolası olan bir veritabanı kullanıcısı olmalıdır. Üç site tek bir veritabanı kullanıcısını paylaşıyorsa, birinden sızan bilgi üçünü de açığa çıkarır. Buraya hosting panelinizin ya da kontrol panelinizin parolasını asla yazmayın. Saldırgan sunucuda zaten kod çalıştırıyorsa bu kontrol işe yaramaz, çünkü dosyayı yine okuyabilir.

Kontrol 2: anahtarlar ve salt değerleri. Sekiz tanedir: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY ve bunlara karşılık gelen dört _SALT sabiti. Uzun, rastgele ve bu siteye özgü olmalıdırlar. Herhangi birinde hâlâ put your unique phrase here yazıyorsa bugün düzeltin. Yeni bir set oluşturmak için api.wordpress.org/secret-key/1.1/salt/ adresini kullanıp eski bloğun üzerine yapıştırabilirsiniz. WP-CLI ile tek komut yeterlidir:

wp config shuffle-salts

Salt değerlerini bir saldırıdan sonra, dosya erişimi olan bir yönetici ya da ajans ayrıldığında veya dosya herhangi bir şekilde açığa çıktıysa yenileyin.

Bir ihlalden sonra bu gizli değerleri yenilemek, daha geniş bir temizliğin yalnızca bir adımıdır. Doğru sıra için WordPress zararlı yazılım temizliği yazısına bakın.

Canlı ortam için hata ayıklama ayarları: WP_DEBUG, WP_DEBUG_DISPLAY ve WP_DEBUG_LOG

Kontrol 3: WP_DEBUG. Yayındaki bir sitede bu değer false olmalıdır. Ekranda gösterilen hatalar sunucu yollarını, eklenti adlarını ve bazen sorgu parçalarını ortaya çıkarır. Saldırgan bunu hedef seçmek için kullanabilir.

define( 'WP_DEBUG', false );

WP_DEBUG değerinin false olması, PHP'nin kendi display_errors ayarını kapatmaz. Hosting sağlayıcınızda bu ayar açıksa uyarılar yine sayfada görünebilir. Sağlayıcınıza sorun ya da kendi sunucunuzu yönetiyorsanız PHP yapılandırmasını kontrol edin.

Kontrol 4: günlük gerekiyorsa, gizleyin ve taşıyın. Bazen canlı ortamda hata ayıklamanız gerekir. Bu durumda hataları asla sayfada göstermeyin ve varsayılan günlük konumunu kullanmayın. WP_DEBUG_LOG değeri true olduğunda günlük wp-content/debug.log dosyasına yazılır ve bu dosya çoğu zaman herkese açık biçimde indirilebilir. Bunun yerine web kök dizininin dışında bir dosya yolu verin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

Dizin mevcut olmalı ve PHP kullanıcısı tarafından yazılabilir olmalıdır. Ardından eski bir günlüğün hâlâ herkese açık olmadığını doğrulayın:

curl -I https://example.com/wp-content/debug.log

403 veya 404 görmelisiniz. 200 ise herkes günlüğü okuyabilir demektir. Dosyayı silin.

Günlükler çoğu zaman e-posta adreslerini, IP adreslerini ve form gönderimlerini içerir; bu da onları kişisel veri yapar. İşiniz bitince günlüğü yeniden kapatın, eski günlük dosyalarını silin ya da döndürün. Her sabitin ayrıntısı WordPress hata ayıklama belgelerinde yer alır.

HTTPS ve ortam türü: FORCE_SSL_ADMIN ve WP_ENVIRONMENT_TYPE

Kontrol 5: FORCE_SSL_ADMIN. Bu ayar giriş sayfasını, yönetim panelini ve yönetici çerezlerini HTTPS üzerinde tutar:

define( 'FORCE_SSL_ADMIN', true );

Yalnızca yönetim alanını ve girişleri kapsar. Sunucu düzeyindeki, site genelinde HTTP'den HTTPS'e yönlendirmenin yerini tutmaz ve HSTS değildir.

Kontrol 6: WP_ENVIRONMENT_TYPE. Bu ayar, WordPress'e ve eklentilere nasıl bir sitede çalıştıklarını bildirir. Geçerli değerler production, staging, development ve local değerleridir. Varsayılan production değeridir.

define( 'WP_ENVIRONMENT_TYPE', 'production' );

Ayarın gerçek etkileri vardır. Çekirdekte, siz WP_DEBUG değerini kendiniz tanımlamadıysanız development ortamı onu açar. Bazı eklentiler ve hosting sağlayıcıları, canlı olmayan sitelerde giden e-postayı durdurmak ya da önbelleği değiştirmek için bu değeri okur. Asıl önemli nokta etiketlemedir. Bir staging kopyası genellikle gerçek müşteri ve sipariş verilerinin tam bir kopyasını taşır. Onu staging olarak işaretleyin ve HTTP kimlik doğrulaması ya da IP kısıtlamasıyla koruyun. Proje bitince silin. Geçen yılın müşteri veritabanını içeren unutulmuş bir staging alt alan adı, veri sızıntılarının sık görülen kaynaklarından biridir.

Dosya düzenleyici ve dosya değişiklikleri: DISALLOW_FILE_EDIT ve DISALLOW_FILE_MODS

Kontrol 7: Bu satırı her siteye ekleyin:

define( 'DISALLOW_FILE_EDIT', true );

Yönetim panelindeki Tema ve Eklenti dosya düzenleyicilerini kaldırır. Böylece çalınmış bir yönetici girişi, birkaç tıkla çalışan koda dönüştürülemez. Eklenti yükleyebilen bir saldırganı durdurmaz.

Kontrol 8: DISALLOW_FILE_MODS daha da ileri gider. Yönetim panelinden eklenti ve tema kurmayı ve güncellemeyi de engeller, otomatik arka plan güncellemelerini kapatır. Bunu yalnızca başka bir güncelleme yolunuz olduğunda (WP-CLI, dağıtım hattı ya da hosting tarafından yönetilen güncellemeler gibi) etkinleştirin. Aksi hâlde siteyi bugünkü açıklı sürümlerde dondurmuş olursunuz. Her iki ayar ve güncelleme akışı DISALLOW_FILE_EDIT: WordPress dosya düzenleyicisini kapatma yazısında ele alınıyor.

Dosya izinleri, konum ve wp-config.php'nin artık kopyaları

Kontrol 9: izinler. Doğru değer, PHP'nin hangi kullanıcıyla çalıştığına bağlıdır:

• 400 veya 440: dosya sahibi PHP'den farklı bir kullanıcıysa kullanın. Grup PHP kullanıcısını içermelidir; bu kullanıcının yalnızca okuma erişimi yeterlidir.
• 600: PHP dosya sahibi olarak çalışıyorsa kullanın. Hesap başına PHP-FPM havuzlarında bu yaygındır.

Paylaşımlı hostingte 644'ten kaçının, çünkü aynı sunucudaki diğer hesaplar dosyayı okuyabilir. 777'yi asla kullanmayın.

ls -l wp-config.php
chmod 440 wp-config.php

Kurulumun geri kalanındaki sahiplik ve izinler için web shell'ler ve dosya izinleri yazısına bakın.

Dosyayı taşımak: wp-config.php dosyasını web kök dizininin bir üst klasörüne almak mümkündür. Üst klasörde kendi WordPress kurulumu yoksa WordPress dosyayı orada otomatik olarak arar. Fayda küçüktür. Yalnızca PHP çalışmayı bıraktığında ve sunucu .php dosyalarını düz metin olarak sunduğunda işe yarar. Kolaysa yapın, ama bunu bir çözüm olarak saymayın.

Kontrol 10: artık kopyalar. Asıl büyük ve daha yaygın risk budur. wp-config.php.bak, wp-config.php.old, wp-config.php.save, wp-config.php~ gibi dosyalar ya da .wp-config.php.swp gibi bir editör takas dosyası .php ile bitmez. Web sunucusu bunları, veritabanı parolası dahil, düz metin olarak sunabilir. Bulmak için:

find /var/www/example -name '*wp-config*' -type f

Yalnızca wp-config.php ve zararsız wp-config-sample.php kalmalıdır. Gerisini silin. Yeniden adlandırmak işe yaramaz. Bir kopya web üzerinden erişilebilir durumdaysa veritabanı parolasını ve salt değerlerini de yenileyin.

10 maddelik wp-config.php kontrolü tek tabloda

Buradaki temiz bir sonuç; açıklı eklentiler, zayıf yönetici parolaları ya da eski bir PHP sürümü hakkında hiçbir şey söylemez. Bunlar için WordPress güvenlik kontrol listesini kullanın.

secaudit.eu'nun Security Audit & Compliance eklentisi bir sertleştirme ve yapılandırma taraması içerir; açıkta kalan gizli değerleri ve artık yedekler gibi dosyaları kontrol eder. Ayrıca yönetim panelindeki dosya düzenleyicilerini kapatmak için isteğe bağlı bir anahtarı vardır → secaudit.eu

Sonraki adımınız: wp-config.php dosyasının bir kopyasını şimdi indirin ve artık kopyalar için find komutunu çalıştırın. İki dakika sürer ve en sık gözden kaçan riski kapatır.

SSS

Salt değerlerini değiştirmek sitemi bozar mı?

Hayır. İçerik, ayarlar ve parolalar olduğu gibi kalır. Oturum açmış her kullanıcının oturumu kapanır ve yeniden giriş yapması gerekir; bu yüzden önce editörlerinizi ve mağaza müşterilerinizi uyarın.

Mevcut bir sitede tablo önekini değiştirmeli miyim?

Genellikle hayır. Özel bir önek gerçek anlamda çok az koruma sağlar; canlı bir sitede değiştirmek ise tabloları yeniden adlandırmayı ve options ile usermeta tablolarındaki kayıtları güncellemeyi gerektirir. Bir hata tüm kullanıcıları dışarıda bırakabilir. Siteyi zaten baştan kurmuyorsanız dokunmayın.

Bir eklenti wp-config.php dosyasını benim yerime yönetebilir mi?

Bazıları yönetebilir. Ancak wp-config.php dosyasına yazabilen bir eklentinin kendisi de risktir; içindeki bir açık, en hassas dosyanıza yazma erişimine dönüşür. SFTP veya SSH üzerinden elle düzenlemeyi tercih edin ve son çalışan sürümün bir kopyasını saklayın.