WordPress Güvenlik Sertleştirme Kontrol Listesi: Dosya İzinleri, Salt Keys, XML-RPC, UFW/Fail2ban Nasıl Tatlı Tatlı Kurulur?

Ofiste Bir Alarm, wp-login ve Kahve: Güvenliği Neden Şimdi Konuşmalıyız?

Hiç böyle oldu mu? Sabah kahveyi yeni koymuşsun, bir bildirim düşüyor: Sunucuda olağan dışı trafik. Logu açınca bakıyorsun, aynı IP’ler dakikalarca wp-login.php ve xmlrpc.php kapısına vuruyor. Tam o sırada, ekibin içerikçisinden bir mesaj geliyor: “Site biraz yavaşladı sanki?” O an anlıyorsun, güvenlik sadece saldırıyı engellemek değil, performansı ve iç huzuru da korumak. Benim için de öyle olmuştu; ilk kez Fail2ban’ın o tatlı “ban” mesajını gördüğüm gün, kahvem bir tık daha lezzetli geldi.

Bugün sana, hepimize nefes aldıran pratik bir WordPress güvenlik sertleştirme kontrol listesi anlatacağım. Dosya izinlerinden başlayıp Salt Keys ile oturumları sağlamlaştıracağız, XML-RPC kapısını gerektiği kadar aralayacağız, sonra da sunucu tarafında UFW ve Fail2ban ile kapının kilidini iki kere kontrol edeceğiz. Mesela şöyle düşün: Ev kapın sağlam, anahtarın tekil, posta kutun gereksiz davetiyelerden arınmış ve apartman girişinde bir kamera var. İşte bu dördü, WordPress evimizin huzur reçetesi.

Yazı boyunca “şunu kapatalım” deyip geçmeyeceğiz; neden yaptığımızı, neleri etkilediğini, ne zaman esneklik gerektiğini konuşacağız. Arada küçük hikayeler, arada komut örnekleri… Çok teknik dile boğmadan, samimi bir yolculuk. Hazırsan, dizini kıralım; önce dosya izinlerinden başlayalım.

Dosya İzinleri Neden Bu Kadar Önemli? Küçük Bir Rakam, Büyük Bir Huzur

Görünmeyeni Düzeltmek: “777” Gibi Cazibeli Yanlışlar

Bir projemde, “dosya yüklenmiyor” paniğiyle karşılaşıp birinin “geçici olarak 777 verelim” dediğini duymuştum. O an, hızla çözülmüş gibi görünen sorun aslında davetiye çıkarıyordu. Çünkü 777 demek, herkesin her şeyi yapabilmesi demek. İyi niyetle açılan bir kapı, istemeden sürekli açık kalabiliyor. Sonra da ufak bir tema dosyası üzerinden şüpheli bir ekleme, ardı gelmeyen uykusuz bir geceye dönüşüyor.

WordPress’te dosya izinlerini şöyle düşünmek iyi geliyor: Sahibi güvende, grup gerektiği kadar, diğerleri ise sadece bakabilsin. Yani klasörler genelde 755, dosyalar 644 olmalı. wp-config.php gibi hassas dosyalar ise daha sıkı; genellikle 600 ya da 640 işini görür. Bunlar ezber değil, bir tür iyi yaşam alışkanlığı.

Adım Adım Düzeltme: Kırmadan, Dökmeyelim

Önce kullanıcı ve grup sahipliğini doğru kişiye verelim. Çalıştığın dağıtıma göre web sunucusu kullanıcısı www-data, nginx ya da apache olabilir. Kök dizinde (örn. /var/www/site) şu komut işi toparlar:

sudo chown -R www-data:www-data /var/www/site

Sonra klasör ve dosya izinlerini düzenleyelim. Şu ikili, karışıklığı tatlı bir şekilde toplar:

find /var/www/site -type d -exec chmod 755 {} ;
find /var/www/site -type f -exec chmod 644 {} ;

Ve wp-config.php için özel bir dokunuş:

chmod 600 /var/www/site/wp-config.php

“Peki ya güncelleme yaparken izin hatası alırsam?” dersen, önce owner ve group meselelerini netleştir. Genelde en büyük karışıklık burada oluyor. Bir de şunu unutma: Dosya düzenlemeyi WordPress panelinden kapatmak, kırılgan bir kapıyı daha sağlamlaştırır. wp-config.php’ye şu satırı eklemek yeterli:

define('DISALLOW_FILE_EDIT', true);

Bu ayar geliştiriciye “değişiklikleri versiyon kontrolünde yapalım” der, kötü niyetli birine de kontrol panelinden doğrudan dosya karıştırma şansı vermez. Hem güvenlik, hem düzen duygusu.

Salt Keys ve wp-config: Oturumları Taze Tut, Anahtarı Tekilleştir

Salt Keys Nedir, Neden Umursayalım?

Salt Keys, WordPress’in çerezi ve oturumlarını şifrelerken kullandığı güçlü anahtarlar. Mesela bir sitenin admin bilgisi herhangi bir şekilde sızsa bile, sağlam Salt anahtarları saldırganın işini epey zorlaştırır. Bir proje devraldığımda ilk baktığım şeylerden biri bu dosyanın taze olup olmadığıdır. Bazen yıllardır el değmemiş, bazen de üretim ortamına taşınırken rastgele bir değere bırakılmış olur.

Yenilemek basit. WordPress’in resmi salt anahtarları üreticisi bir tıkla yeni anahtarlar verir. Öncesinde bir yedek al, sonra wp-config.php içindeki mevcut SALT ve KEY satırlarını yeni üretilenlerle değiştir. Kaydedince mevcut oturumlar düşer; bu iyi bir şey. Çünkü herkes yeniden giriş yapar ve artık yeni anahtarlarla korunur.

wp-config’te Küçük Ama Etkili Dokunuşlar

Salt Keys’i tazeledikten sonra, birkaç küçük ayar daha güvenlik duvarını örer. Mesela yönetim panelinde SSL’i zorlamak:

define('FORCE_SSL_ADMIN', true);

Bir de dosya düzenlemeyi zaten kapatmıştık. Dilersen eklenti ve tema kurulumlarını da kontrol altında tutabilirsin. Burada sihir, panodan kontrol edilen kırılgan noktaları dışarıdan düzenlenen, takip edilebilir bir akışa çevirmek. Kendi deneyimimde, bu yaklaşım güncellemeleri daha güvenli kıldığı gibi, ekip içinde kim neyi ne zaman değiştirdi sorusunu da netleştiriyor.

Son bir ipucu: wp-config.php dosyasını web kökünün bir üstüne taşımayı düşünebilirsin. WordPress bunu destekliyor ve direkt web üzerinden erişilemeyen bir yerde tutmak içini rahatlatabilir. Yine de bu değişikliği yaptıktan sonra güncellemelerde gözünü açık tut; alışkanlıklar değişince ufak pürüzler çıkabilir.

XML-RPC: Tamamen Kapatmalı mıyız, Sadece Daraltmalı mıyız?

Kapıyı Tanıyalım: XML-RPC Ne İşe Yarar?

XML-RPC, eski ama bazı araçların hâlâ kullandığı bir kanal. Mobil uygulama ile giriş yapmak, bazı entegrasyonlar ya da pingback gibi özellikler buradan akar. Sorun şu: Saldırganlar da bu kapıyı sever. Çünkü tek bir istekle birden fazla parola denemesine yol açabilen yöntemler var; bu da kaba kuvvet denemelerini kolaylaştırır.

Mesela şöyle düşün: Herkesin geçtiği bir apartman girişin var. Kapıyı komple kaynakla kapatırsan, kuryen de giremez. Ama akıllı bir interkom koyarsan, tanıdığa açılır, tanımayana direnirsin. XML-RPC’de de aynısı. Eğer hiç kullanmıyorsan, kapat gitsin. Kullanıyorsan, sıkı bir denetim ve rate limit ile koru.

Nasıl Daraltır ya da Kapatırız?

Apache için basit bir kapama örneği, kök dizindeki .htaccess dosyasına eklenebilir:

<Files xmlrpc.php>
    Order allow,deny
    Deny from all
</Files>

Nginx tarafında lokasyon seviyesinde bir engelleme yapılabilir:

location = /xmlrpc.php {
    deny all;
}

“Ama Jetpack veya mobil uygulama kullanıyorum” diyenler için durum farklı. O zaman tamamen kapatmak yerine belli IP’lere izin verip, kalanını engellemek daha mantıklı olur. Ayrıca Fail2ban ile kombine bir koruma, hem denemeleri sınırlar hem de agresif IP’leri kısa sürede dışarıda bırakır. Bu konuda pratik bir yolculuk için şu rehber hoşuna gidebilir: Nginx rate limiting ve Fail2ban ile wp-login.php ve XML-RPC saldırılarını saksıya alma.

Bir not daha: Pingback’leri kapatmak çoğu blog için sorun yaratmaz ama saldırı yüzeyini küçültür. Yazı ayarlarında yorum ve ping seçeneklerini gözden geçirmek, hem moderasyonu hem de güvenliği rahatlatır.

UFW ve Fail2ban: Şehir Kapılarını, Devriye Saatlerini Güzelce Ayarlayalım

UFW ile Trafiği Sakinleştirmek

UFW’yi, şehir girişlerindeki bariyerler gibi düşün. Varsayılan olarak “içeri gelişlere kapalı, dışarı gidişlere açık” yaklaşımı işimizi görür. Sonra sadece ihtiyacın olan kapıları açarsın. Ben genelde şu akışla ilerliyorum:

sudo ufw default deny incoming
sudo ufw default allow outgoing

# Temel servisler
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# SSH için ya sabit bir port ya da sınırlama
sudo ufw limit 22/tcp

sudo ufw enable
sudo ufw status verbose

“limit” ifadesi, kısa sürede çok bağlantı denemesi olursa hız keser. SSH için minik bir nefes. Eğer yönetimi belirli IP’lerden yapıyorsan, 22’yi herkese açık bırakmak yerine sadece kendi IP aralığına aç. Unutma, netlik iyidir ama aşırı katılık günlük işini de zorlaştırabilir. Denge kuralı burada da geçerli.

Fail2ban ile Kötü Niyete Hızlı Refleks

Fail2ban, loglara bakar ve “Bu hareket kötüye işaret” dediği anda IP’yi banlar. En çok sevdiğim yönü, bariz saldırıları dakikalar içinde etkisiz hale getirmesi. Kurulum sonrası iki dosya aklımda: /etc/fail2ban/jail.local ve filtre tanımları. Basit bir SSH koruması için şuna benzer bir yapı iş görür:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h

WordPress içinse web sunucunun loglarına bakarız. Nginx örneği verelim; access.log ve error.log içindeki wp-login.php ve xmlrpc.php başarısız denemeleri yakalayacak bir filtre ve jail kuralı tatlı işler. Her yapının log formatı farklı olabilir, o yüzden üretime geçmeden küçük bir test turu yap. Ayrıntılar ve farklı senaryolar için Fail2ban proje belgeleri iyi bir pusula.

Burada küçük bir kişisel not: İlk kez agresif denemeleri banladığında, CPU grafiğinin nasıl sakinleştiğine şahit olmak hakikaten iyi hissettiriyor. Performans güvenliğin kuzeni; birini iyileştirdiğinde diğeri de rahatlıyor.

Günlük Bakım, Küçük Ritüeller ve İzleme: Güvenlik Bir Seferlik Değil

Güncellemeler, Az Eklenti ve Temiz Kullanıcılar

Güvenlik sadece duvar örmek değil; evi düzenli havalandırmak. Çekirdeği, temaları ve eklentileri makul aralıklarla güncelle. “Güncelleyeyim de kırılırsa ne olacak” endişesini de anlıyorum. Bunun için küçük bir önlem iş görüyor: Önemli güncellemelerden önce dosya ve veritabanı yedeği al, hatta mümkünse bir staging ortamında dene. Çatır çutur karmaşadan çok şey kurtarıyor.

Eklenti sayısını makul tutmak, saldırı yüzeyini küçültür. Kullanmadığın eklentiyi devre dışı bırakmak yetmez; kaldır. Kullanıcı tarafında da iki faktörlü doğrulama sunan eklentiler işini kolaylaştırır. Şifreler yerine U2F/FIDO2 gibi fiziksel anahtarlar da gönül rahatlığı sağlar; bu yolculuğa merakın varsa, sunucu girişleri açısından benzer bir yaklaşımı VPS’te SSH güvenliği ve FIDO2 anahtarları yazısında uzun uzun konuşmuştuk.

Logları Dinlemek ve Küçük Alarmlar Kurmak

Logları okumak, evin nabzını tutmak gibi. Nginx/Apache, PHP-FPM ve WordPress logları bir araya gelince resim netleşir. Bariz olmayan ama tekrarlayan hatalar, sık sık 403/404 veren noktalar, yanlış yapılandırılmış bir eklentinin ipuçları… Hepsi orada. Küçük bir alarm, gece yarısı telefonunu çaldırmaz ama sabah ilk kahveden önce bakıp rahatlamanı sağlar.

Üzerine bir de basit bir uptime izleme ve cevap süresi ölçümü eklediğinde, performans düşüşlerini güvenlikle ilişkilendirmen kolaylaşır. Güvenlik zayıflayınca performans da sızlanır; ikisini birlikte izlemek güzel bir alışkanlık. WordPress’in resmi gözünden önerileri gözden geçirmek istersen, WordPress’in resmi sertleştirme rehberi faydalı bir hatırlatma listesi sunar.

Kapanış: Kapıları Sağlamlaştır, Rutinini Kur, Rahat Uyu

Şöyle bağlayalım: Dosya izinleri düzgün olunca, kötü niyetli bir dokunuşun tutunacağı dal azalıyor. Salt Keys taze ve düzenliyse, sızmış bir oturum bile hızla geçersizleşiyor. XML-RPC’yi kapatmak ya da daraltmak, gereksiz kapıları kapatıp gerekli olanlara interkom takmak gibi; seçici bir huzur. UFW ve Fail2ban ise dışarıdaki gürültüyü içeri taşımadan sükuneti koruyor.

Pratik önerim şu: Bugün bir saatini ayır, dosya izinlerini ve wp-config.php ayarlarını gözden geçir. Sonra XML-RPC durumunu değerlendirmeye al; kullanmıyorsan kapat, kullanıyorsan sınırlandır. Akabinde UFW’yi devreye al, Fail2ban ile en azından SSH ve wp-login için temel kuralları etkinleştir. Son olarak küçük bir log alışkanlığı edin: Her gün birkaç dakikalık bir kontrol, geceleri daha rahat uyutuyor.

Umarım bu küçük yolculuk çantana yeni birkaç anahtar atmıştır. Takıldığın bir yer olursa, notlarını topla; birlikte bakarız. Bir dahaki yazıda belki de performansla güvenliğin o tatlı kesişiminde buluşuruz. Şimdilik kapı kilitleri yerinde, anahtarlar cebinde kalsın.