Kayıt ol

Tovala Akıllı Fırın Deneyimi: Paket Servisten Daha İyi mi?FortiMail'de Kritik Zero-Day Açığı Aktif Saldırılarda Kullanılıyor Meadow: Sosyal Medyasız Minimalist Telefon Deneyimi California'da Gizli Kayıt Yapan Akıllı Gözlük Yasasına Veto Hello Robot Stretch 4, TechCrunch Disrupt 2026'da Canlı Tanıtılacak

JavaScript devre dışı. Daha iyi bir deneyim için, önce lütfen tarayıcınızda JavaScript'i etkinleştirin.

WordPress Yönetim Paneli Güvenliği: Uygulanabilir 10 Önlem

Mesaj: <blockquote data-quote="Admin" data-source="post: 12819" data-attributes="member: 1"><p><h2>WordPress Yönetim Paneli Güvenliği: Uygulanabilir 10 Önlem</h2><p>WordPress sitenizde tanımadığınız bir yönetici hesabı oluştuğunu veya ziyaretçilerin başka adreslere yönlendirildiğini düşünün. Böyle bir olayda sorun yalnızca birkaç sayfanın değişmesi değildir. İçerikler, müşteri bilgileri ve sitenin erişim bilgileri de tehlikeye girebilir.</p><p>Yönetim panelini korumak için güçlü bir parola kullanmak iyi bir başlangıçtır. Ancak güvenlik; hesap yetkileri, güncellemeler, sunucu ayarları ve yedekleme düzeniyle birlikte ele alınmalıdır. Üstelik bazı saldırılar yönetici hesabına giriş yapmadan, doğrudan bir yazılım açığından yararlanabilir.</p><p>Bu rehberde, WordPress güvenliğini güçlendirmek için uygulanabilecek 10 önlemi ve bir sorun yaşandığında izlenecek adımları bulabilirsiniz.</p><h2>1. Her Hesap İçin Güçlü ve Benzersiz Parola Kullanın</h2><p>WordPress parolanızın başka bir sitede de kullanılması, o hizmette yaşanan veri sızıntısını sizin siteniz için de tehlikeye dönüştürebilir.</p><p>Parola seçerken şu alışkanlıkları edinin:</p><ul> <li data-xf-list-type="ul">Parola yöneticisiyle uzun ve rastgele bir parola oluşturun.</li> <li data-xf-list-type="ul">Aynı parolayı WordPress, hosting ve e-posta hesaplarında kullanmayın.</li> <li data-xf-list-type="ul">Site adı, doğum tarihi ve telefon numarası gibi tahmin edilebilir bilgilerden kaçının.</li> <li data-xf-list-type="ul">Ortak yönetici hesabı yerine herkese ayrı hesap açın.</li> </ul><p>Kullanıcı adının <code class="bbCodeInline">admin</code> olmaması bazı otomatik denemeleri azaltabilir. Ancak kullanıcı adınızı gizli bir bilgi olarak kabul etmeyin. Güvenlik düzeniniz, saldırgan kullanıcı adını öğrense de hesabı koruyabilmelidir.</p><p>WordPress’in parola gücü göstergesini dikkate alın; özellikle yönetici hesaplarında kolay hatırlanan kısa parolalar yerine parola yöneticisinden yararlanın.</p><h2>2. İki Faktörlü Doğrulamayı Etkinleştirin</h2><p>İki faktörlü doğrulama, giriş sırasında parolaya ek bir doğrulama ister. Böylece yalnızca parolanın ele geçirilmesi hesabı açmak için yeterli olmayabilir.</p><p>WordPress kurulumuna bu özellik uygun bir eklenti veya kimlik sağlayıcısı üzerinden eklenebilir. Örneğin Two Factor eklentisi, doğrulama uygulamalarının ürettiği TOTP kodlarını ve kurtarma kodlarını destekler.</p><p>Kurulum sırasında:</p><ul> <li data-xf-list-type="ul">Öncelikle tüm yönetici hesaplarında 2FA kullanın.</li> <li data-xf-list-type="ul">İçerik yönetiminde kritik yetkileri olan diğer hesapları da kapsayın.</li> <li data-xf-list-type="ul">Kurtarma kodlarını güvenli bir yerde saklayın.</li> <li data-xf-list-type="ul">Telefon kaybında hesabın nasıl kurtarılacağını önceden belirleyin.</li> <li data-xf-list-type="ul">Çıkış yapıp yeniden giriş yaparak doğrulamanın çalıştığını test edin.</li> </ul><p>Desteklenen yapılarda WebAuthn tabanlı passkey veya güvenlik anahtarları, kimlik avına dayanıklı giriş sağlayabilir. Passkey yalnızca fiziksel USB anahtarı anlamına gelmez; uygun cihazın biyometrik doğrulamasıyla da kullanılabilir.</p><h2>3. Yönetici Yetkisini Gerektiği Kadar Dağıtın</h2><p>Sadece yazı yayımlayan bir kullanıcıya yönetici yetkisi vermek, o hesabın ele geçirilmesi halinde oluşabilecek zararı büyütür.</p><p>Standart WordPress rollerini görevlerine göre değerlendirin:</p><p></p><table style='width: 100%'><tr><th>Rol</th><th>Genel kullanım</th></tr><tr><td>Yönetici</td><td>Site ayarları, kullanıcılar ve yazılım yönetimi</td></tr><tr><td>Editör</td><td>Kendisinin ve diğer kullanıcıların içeriklerini yönetme</td></tr><tr><td>Yazar</td><td>Kendi yazılarını oluşturma ve yayımlama</td></tr><tr><td>Katkıda bulunan</td><td>İçerik hazırlama, yayımlama için onay bekleme</td></tr><tr><td>Abone</td><td>Sınırlı hesap ve profil işlemleri</td></tr></table><p></p><p><strong>Editörler varsayılan olarak eklenti kuramaz veya tema dosyalarını düzenleyemez.</strong> Özel rol eklentileriyle bu yetkiler değiştirilebildiğinden, yalnızca rol adına bakmak yerine gerçek izinleri de kontrol edin.</p><p>İşi biten geliştiricilerin ve eski çalışanların erişimlerini kaldırın. Geçici destek hesaplarını sürekli açık bırakmayın.</p><h3>Kullanıcı adlarını gizlemek ne kadar önemli?</h3><p>Yazar arşivleri ve REST API üzerinden bazı herkese açık yazar bilgileri görülebilir. Bu, bütün özel hesap bilgilerinin açık olduğu anlamına gelmez. WordPress, alanları ve işlemleri erişim bağlamına göre sınırlar.</p><p>Gereksiz bilgi paylaşımını azaltabilirsiniz. Ancak kullanıcı listesini gizlemek, güçlü parola ve 2FA’nın yerini tutmaz. REST API’yi tamamen kapatmadan önce editör ve eklenti ihtiyaçlarını değerlendirin.</p><h2>4. Giriş Denemelerini Sınırlayın</h2><p>Otomatik saldırılar kısa sürede çok sayıda parola deneyebilir. Başarısız girişleri sınırlamak, bu denemeleri yavaşlatır ve sunucu üzerindeki yükü azaltabilir.</p><p>Uygulanabilecek yöntemler:</p><ul> <li data-xf-list-type="ul">Tekrarlanan başarısız denemelerden sonra geçici bekleme koymak.</li> <li data-xf-list-type="ul">Şüpheli girişlerde CAPTCHA veya benzeri doğrulama kullanmak.</li> <li data-xf-list-type="ul">Başarısız giriş kayıtlarını takip etmek.</li> <li data-xf-list-type="ul">Yoğun saldırılarda sunucu veya WAF üzerinden hız sınırlaması uygulamak.</li> </ul><p>Tek bir IP adresini engellemek, farklı adreslerden gelen saldırıları tamamen durdurmaz. Ayrıca aşırı katı kurallar, aynı ofis bağlantısını kullanan gerçek kullanıcıları da kilitleyebilir.</p><p>Mümkün olduğunda trafiği WordPress çalışmadan önce sınırlamak yararlıdır. Uygulama içindeki giriş koruması ise PHP kaynaklarını kullanmaya devam edebilir.</p><h2>5. Yönetim Erişimini İhtiyaca Göre Kısıtlayın</h2><p>Giriş adresini değiştirmek, standart adresleri tarayan bazı botların trafiğini azaltabilir. Fakat adresin bilinmemesine dayanan bu yöntem, tek başına hesap güvenliği sağlamaz.</p><p>Giriş adresini değiştiren bir eklenti kullanıyorsanız yeni adresi güvenli şekilde kaydedin. Parola sıfırlama, üyelik ve diğer giriş akışlarının çalıştığını da kontrol edin.</p><p>Sabit IP veya kurumsal VPN kullanan ekiplerde, yönetim erişimini belirli bağlantılarla sınırlandırmak değerlendirilebilir. Burada kuralın kapsamı önemlidir: <code class="bbCodeInline">/wp-admin/</code> altındaki her isteği engellemek, ziyaretçilerin kullandığı <code class="bbCodeInline">admin-ajax.php</code> işlemlerini de bozabilir.</p><p>Mobil bağlantıyla çalışan ekipler için değişken IP adreslerini hesaba katın. Her kısıtlamada alternatif erişim ve kurtarma yolu bulunmalıdır.</p><h2>6. Güncellemeleri Ertelemeyin</h2><p>WordPress çekirdeği, temalar ve eklentiler zaman içinde güvenlik düzeltmeleri alır. Bir sürümün uzun süredir sorunsuz çalışması, güvenlik açısından güncel olduğu anlamına gelmez.</p><p>Pratik bir güncelleme düzeni oluşturun:</p><ol> <li data-xf-list-type="ol">Güncelleme bildirimlerini düzenli takip edin.</li> <li data-xf-list-type="ol">İşlem öncesinde dosya ve veritabanı yedeği alın.</li> <li data-xf-list-type="ol">Büyük değişiklikleri mümkünse staging ortamında deneyin.</li> <li data-xf-list-type="ol">Güncelleme sonrasında giriş, form ve ödeme işlemlerini kontrol edin.</li> </ol><p>WordPress’in otomatik güncelleme mekanizması bulunur. Bunun sitenizde etkin ve çalışır durumda olduğunu doğrulayın.</p><p>Kritik bir güvenlik düzeltmesini haftalarca bekletmeyin. Yama bulunmayan riskli bir eklentide ise geçici olarak işlevi kapatmak veya eklentiyi değiştirmek gerekebilir.</p><h2>7. Kullanılmayan Tema ve Eklentileri Temizleyin</h2><p>Her eklenti, bakımını üstlenmeniz gereken yeni bir yazılım bileşenidir. Aynı işi yapan birkaç eklentiyi birlikte kullanmak çoğu zaman yönetimi zorlaştırır.</p><p>Düzenli olarak şu kontrolleri yapın:</p><ul> <li data-xf-list-type="ul">Kullanılmayan eklentileri kaldırın.</li> <li data-xf-list-type="ul">Gereksiz temaları silin; kurtarma için tutulan temayı güncel bırakın.</li> <li data-xf-list-type="ul">Yazılımları güvenilir kaynaklardan indirin.</li> <li data-xf-list-type="ul">Kaynağı belirsiz değiştirilmiş paketlerden uzak durun.</li> <li data-xf-list-type="ul">Bakımı sona eren ürünler için alternatif planlayın.</li> </ul><p>Devre dışı bırakılan bir eklentinin dosyaları sunucuda kalır. Bazı açıklar bu dosyalara doğrudan erişilerek kullanılabildiğinden, artık ihtiyaç olmayan eklentiyi silmek daha sağlıklıdır. WordPress’in güvenlik rehberi de kullanılmayan eklentilerin kaldırılmasını önerir.</p><p>Bir eklentinin güvenilirliğini yalnızca son güncelleme tarihiyle değerlendirmeyin. Uyumluluk, geliştirici desteği ve bilinen güvenlik sorunları da önemlidir.</p><h2>8. Yapılandırma Dosyalarını ve İzinleri Kontrol Edin</h2><p><code class="bbCodeInline">wp-config.php</code>, veritabanı erişim bilgileri ve güvenlik anahtarları içerir. Bu dosyanın korunması kadar, sunucuda bırakılan yedek ve hata kayıtlarının erişilebilir olmaması da önemlidir.</p><h3>Paneldeki dosya editörünü kapatın</h3><p>Aşağıdaki satırı <code class="bbCodeInline">wp-config.php</code> dosyasındaki WordPress yükleme satırından önce ekleyebilirsiniz. Sabit zaten tanımlıysa mevcut tanımı düzenleyin:</p><p><code class="bbCodeInline">define( 'DISALLOW_FILE_EDIT', true );</code></p><p>Bu ayar, paneldeki tema ve eklenti dosya editörlerini kapatır. Ancak eklenti kurulumu veya başka bir açık üzerinden kod çalıştırılmasını bütünüyle engellemez.</p><p><code class="bbCodeInline">DISALLOW_FILE_MODS</code> daha kapsamlıdır; kurulum ve güncelleme işlemlerini de etkiler. Alternatif bir güncelleme süreci kurmadan kullanmayın.</p><h3>HTTPS üzerinden yönetim sağlayın</h3><p>Geçerli sertifika ve çalışan HTTPS yapılandırması hazırsa şu ayar kullanılabilir:</p><p><code class="bbCodeInline">define( 'FORCE_SSL_ADMIN', true );</code></p><p>Bu satır sertifika oluşturmaz. Proxy veya CDN kullanılan ortamlarda HTTPS’in doğru algılanması gerekir; aksi halde yönlendirme döngüsü oluşabilir.</p><h3>Dosya izinlerini sunucuya göre belirleyin</h3><p>Yaygın başlangıç değerleri klasörlerde <code class="bbCodeInline">755</code>, dosyalarda <code class="bbCodeInline">644</code> olsa da doğru izinler sahiplik ve PHP’nin hangi kullanıcıyla çalıştığına bağlıdır.</p><p><code class="bbCodeInline">wp-config.php</code> için daha dar izinler kullanılabilir; fakat PHP’nin dosyayı okuyabildiği doğrulanmalıdır. İzin sorununu bütün klasörlere <code class="bbCodeInline">777</code> vererek çözmeye çalışmayın.</p><h2>9. WAF, Tarama ve Kayıt Takibini Birlikte Kullanın</h2><p>Web uygulama güvenlik duvarı, gelen istekleri kurallara göre değerlendirir. Belirli saldırı desenlerini engellemek ve şüpheli trafiği sınırlandırmak için ek koruma sağlar.</p><p>Ancak WAF’ın etkisi kullanılan kurallara, kapsama ve yapılandırmaya bağlıdır. Varlığı, bütün açıkların engellendiği anlamına gelmez.</p><p>Güvenlik takibinde yalnızca dosya taramasına bakmayın. Beklenmedik yönetici hesaplarını, yetki değişikliklerini ve şüpheli girişleri de inceleyin.</p><p>Hosting hesabınız, yönetici e-postanız ve kullandığınız bilgisayar da bu düzenin parçasıdır. WordPress hesabının parolası, ele geçirilmiş bir e-posta hesabı üzerinden sıfırlanabilir.</p><p>API kullanan uygulamaların erişimlerini ayrıca kontrol edin. Kullanılmayan uygulama parolalarını iptal edin; tarayıcı girişinde etkin olan 2FA’nın her entegrasyonu otomatik koruduğunu varsaymayın.</p><h2>10. Yedek Alın ve Geri Yüklemeyi Deneyin</h2><p>Yedekleme saldırıyı önlemez; hasar sonrasında toparlanmayı mümkün kılar.</p><p>Tam bir WordPress yedeği hem dosyaları hem veritabanını kapsamalıdır. Yalnızca site klasörünü indirmek, yazıları ve kullanıcı kayıtlarını içeren veritabanını yedeklemez.</p><p>Yedekleme sıklığını sitenin hareketliliğine göre belirleyin. Az değişen bir blog ile sürekli sipariş alan bir mağazanın ihtiyaçları farklıdır.</p><p>Sağlam bir düzen için:</p><ul> <li data-xf-list-type="ul">Birden fazla tarihli yedek saklayın.</li> <li data-xf-list-type="ul">En az bir kopyayı üretim sunucusundan ayrı tutun.</li> <li data-xf-list-type="ul">Yedeklere erişimi sınırlandırın.</li> <li data-xf-list-type="ul">Geri yüklemeyi test ortamında deneyin.</li> <li data-xf-list-type="ul">Kabul edilebilir veri kaybını ve kesinti süresini belirleyin.</li> </ul><p>Son yedek her zaman temiz olmayabilir. Saldırı günler sonra fark edildiğinde, daha eski kopyalara ihtiyaç duyulabilir.</p><h2>Site Ele Geçirilirse Ne Yapılmalı?</h2><p>Şüpheli durumda yalnızca görünen zararlı dosyayı silip siteyi açmak yeterli olmayabilir. Genel müdahale sırası şöyle planlanabilir:</p><ol> <li data-xf-list-type="ol"><strong>Erişimi sınırlandırın:</strong> Hosting sağlayıcısıyla birlikte zararın devamını durdurun.</li> <li data-xf-list-type="ol"><strong>Bulguları kaydedin:</strong> Belirtileri, zamanları ve mevcut kayıtları temizlikten önce koruyun.</li> <li data-xf-list-type="ol"><strong>Erişimleri güvenceye alın:</strong> Güvenilir bir cihazdan ilgili parolaları değiştirin, şüpheli hesapları ve entegrasyonları iptal edin.</li> <li data-xf-list-type="ol"><strong>Temiz bir duruma dönün:</strong> Doğrulanmış yedek veya güvenilir yazılım paketleriyle dosya ve veritabanını inceleyin.</li> <li data-xf-list-type="ol"><strong>Giriş noktasını kapatın:</strong> Açık, zararlı yazılım veya çalınmış erişim sorununu giderin.</li> <li data-xf-list-type="ol"><strong>Temizlik sonrası tekrar doğrulayın:</strong> Parolaları yeniden değiştirin, oturumları geçersiz kılın ve siteyi izleyin.</li> </ol><p>WordPress’in olay sonrası rehberi de yerel cihazın kontrolünü, hosting sağlayıcısıyla koordinasyonu ve temizlikten sonra parolaların yeniden değiştirilmesini önerir. Kurtarma süresi olayın kapsamına bağlıdır.</p><h2>Sıkça Sorulan Sorular</h2><h3>Giriş adresini değiştirmek yeterli mi?</h3><p>Hayır. Bazı otomatik istekleri azaltabilir; yazılım açıklarını ve çalınmış erişimleri ortadan kaldırmaz.</p><h3><code class="bbCodeInline">admin</code> kullanıcı adı varsa site güvensiz midir?</h3><p>Tek başına böyle bir sonuç çıkarılamaz. Güçlü parola, 2FA, güncellemeler ve doğru yetkiler birlikte değerlendirilmelidir.</p><h3>SSL sertifikası saldırıları engeller mi?</h3><p>HTTPS bağlantıyı şifreler. Açıklı eklentiyi düzeltmez veya sunucudaki zararlı dosyayı temizlemez.</p><h3>Birkaç güvenlik eklentisi kurmak daha iyi midir?</h3><p>Aynı işlevleri yapan eklentiler çakışabilir. İhtiyaç duyulan korumaları belirleyip uyumlu ve bakımlı araçlarla uygulamak daha sağlıklıdır.</p><h3>Önce hangi işlemleri yapmalıyım?</h3><p>Yönetici hesaplarını kontrol edin, benzersiz parolalar ve 2FA kullanın, güncellemeleri uygulayın ve yedeğinizin geri yüklenebildiğini doğrulayın. Ardından giriş sınırlaması ve sunucu korumalarını sitenizin ihtiyaçlarına göre düzenleyin.</p></blockquote><p></p>