WordPress Admin Paneli Değiştirme (wp-admin gizleme)

 

 

WordPress Admin URL Değiştirme

 

WodPress varsayılan olarak Yönetici / Administrator paneli için wp-login.php URL’sini kullanır ve wp-admin dosyası yine bu URL’ye yönlenir; wp-signup.php ve wp-activate.php de wp-login.php URL’sine yönlendirilir. Sıradan WordPress rehberlerinde ise, htaccess dosyası üzerinde wp-login.php için URL yeniden yazılmaya zorlanarak; oluşturulan bir URL’ye yönlendirilir. Sıradan WordPress rehberlerinde kullanılan htacces kodu:

 

Aşağıdaki htaccess tanımı bu işlem için yanlıştır ve amatör WordPress anlatımlarına örnek olarak gösterildi


 

Öncelikle Apache Server’da, RewriteRule modülü; istenen URL’yi yeniden yazar ve bu URL’yi başka bir URL’ye yönlendirir. Bu modül, -başta Arama Motorları olmak üzere- URL adresini sunucu üzerinde okunacak tabana dönüştürmek için kullanılan bir tekniktir. WordPress’deki Ayarlar / Kalıcı bağlantılar panelinde bulunan Kalıcı bağlantı ayarları bir RewriteRule kuralıdır. Kısaca RewriteRule URL yazma motorudur… Bu kural da bir URL’yi temelde değiştirmez; istenilen URL’yi varsayılan URL tabanına yazar. Sonuç olarak istenilen URL, varsayılan URL’yi de korur. WordPress Ayarlar / Kalıcı bağlantılar sekmesinde Kalıcı bağlantı ayarlarını önce Düz olarak yazdıktan sonra bu düz URL tabanını bir yere kaydedin ve daha sonra Yazı ismi olarak değiştirin. WordPress sitenizdeki URL tabanı Yazı ismi olarak yazıldığında yine id numarasını kullanan URL tabanının geçerliliğini koruduğunu izleyeceksiniz.


 

wp-admin değiştirme

Genellikle WordPress yönetici panelini gizlemek / değiştirmek için eklentiler kullanılır. Üçüncü parti eklenti kullanımı; eğer düzgün kapatılmış ve esnek yapılandırılmış ise WordPress sistemine fazladan yük bindirmez ve böyle bir eklenti çakışmalara da neden olmaz. Kısaca temada yerleşik çalışan kodlardan farksızdır. Ama eklentilerin bir dezavantajı ise sürekli güncellenen WordPress sistemi ile birlikte güncelleme gereksinimleri duyabilmeleri ve böylelikle de çalışmalarını durdurabilmeleri ya da bazı çakışmalara neden olabilmeleridir.

 

Bu da son aşamada web sitesinin stabillik garantisi olmadığını gösterir. Popüler ve kullanıcıları yüksek olan eklentiler ise, bir ekip tarafından kontrol edilerek güncellendiği için; -genellikle- bu tür sorunlara yol açmaz ya da çok geçmeden düzeltilir. Ancak söz konusu bu fonksiyonlar niteliğindeki hazır paket uygulamalarına dönüştürülmüş eklentilerin ileride çalışmayı durdurabilmeleri de stabillik için ön görülmelidir. Ayrıca hazır paketler haline getirilmiş olan kodların (eklentilerin) SQL Injection potansiyelleri de göz önüne alınmalıdır.

 

 

wp-admin URL’sini functions.php ile kontrol edin

Tema klasörünüzün ana dizininde yer alan functions.php dosyası üzerindeki bu düzenleme; wp-admin ve wp-login.php ile birlikte aynı dosyaya yönlendirilen wp-signup.php ve wp-activate.php dosyalarını da PHP için kalıcı yönlendirme işlevini kullanarak erişimini engelleyecek ve yalnızca istenilen URL’yi döndürecektir.

 

Bu işlem sonrası WordPress giriş bilgileri yanlış girildiği taktirde yine 404’e yönlendirilecektir; yönetici URL’si taranmış olsa bile parola denemesine izin vermeyecektir. Kod’daki ozel-bir-anahtar-olusturun pasajını silin, türkçe karakter kullanmadan bitişik – karmaşık bir anahtar oluşturun. Ardından wp-login.php? parametresini oluşturulan bu anahtarla birleştirin. Örnek: example.com/wp-login.php?anahtarx1x1zx0 (Karmaşık anahtar oluşturulması da tersine mühendislik kullanan yazılımlar tarafından bulunmasını önleyecektir) Kod Referans

Geri Bildirimler için yapılan düzeltme – 06.06.2020

Başlamadan önce htaccess dosyanızda özel sorgu dizelerini kaldıran bir tanımlama olmadığından emin olun ya da wp-admin /  wp-login.php ve index.php için yeniden yazma kuralını kullanın. Sunucu’da ya da Tema’da özel sorgu dizelerini kaldıran bir tanımlama varsa aşağıda yönetici için başvurulan özel sorgu da sıfırlanacak ve wp-login.php çalışmayacak. Bu durumda htaccess üzerinde aşağıdaki tanımın kullanılması gerektiğini not edin; example.com’u alan adınızla değiştirin:

 

# Developed by wpenvolay.com
# # Remove and rewrite custom query strings
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteCond %{QUERY_STRING} !^(s|p)=.*
RewriteCond %{REQUEST_URI} !.*wp-login.*
RewriteCond %{REQUEST_URI} !.*wp-admin.*
RewriteCond %{REQUEST_URI} !.*index.php
RewriteRule .* http://example.com%{REQUEST_URI}? [R=301,L]
</IfModule>


 



 

 

wp-admin çapraz URL

WordPress yönetici URL yalnızca kök dizinde bulunmaz; wp-admin klasöründeki install.php / upgrade.php ve setup-config.php dosyaları da dolaylı olarak yönetici paneline bir kapı aralar. Örnek: example.com/wp-admin/install.php Her ne kadar yukarıdaki PHP Yönlendirme işleminden sonra dolaylı yönlendirmeler de dahil devre dışı kalsa da bu dosyalardan ileride yararlanılamayacağı anlamına gelmez. Ayrıca bu dosyalar WordPress sisteminizin sürümleri hakkında da bazı bilgiler sızdırırlar; WordPress sisteminizin sürümü, bir hacking senaryosunda kullanışlı bir bilgidir. Bir önceki sürümde taranmış açıklar son sürümde kapatılmış olabilir ve dolayısıyla WordPress’in sürümünü öğrenmek girişimde bulunulmaya kestirme bir yol açabilir.

 

Aşağıdaki kod sunucu yönetimi için kullanılan htaccess  tanımlarıdır. Tanımları bir not defteri açarak yapıştırın ve .htaccess formatı ile kaydettikten sonra kök dizinde yer alan public_html/wp-admin klasörü içine bırakın; zaten bir htaccess dosyanız varsa aynı dosyada yer açın; indir: wpenvolay.com/other/htaccess.7z  –  Referans

 


 

 

wp-admin yolu neden değiştirilmeli?

WordPress yönetici giriş paneli, WordPress sisteminde ya da kullanılan temada olası bir güvenlik açığı tespit edilene kadar veya başarılı bir SQL Injection girişimine kadar oldukça güvenli ve birçok uygulamanın aksine varsayılan’da bile karmaşık parolalar ürettiğinden -herhangi bir deneme yanılma yöntemi ile aşılması- ya da tahmin edilmesi çok zordur. Ama WordPress sistemindeki parolanız bir MySQL sorgusudur… MySQL atakları WordPress sisteminizdeki parolanın bypass edilmesine neden olabilir. Bu MySQL Veritabanı güvenliği başta kontrol panellerinin (cPanel gibi) / Hosting Yönetim Yazılımlarının sürümleri ve yine barındırma şirketlerinin güvenlik yapılandırmalarına emanettir. Güncellenen WordPress sisteminizde bir güvenlik zaafı bulunmasa bile paylaşılan barındırmada sunucunun yazılım ve yapılandırmasını denetleme izniniz kısıtlıdır. Dolayısıyla yayın yaptığınız sunucunun güveliğinden tam olarak emin olma şansınız yoktur.

 

SQL Inhection girişimlerinde web sitesi ve sunucudaki güvenlik açıklarını taramak için Acunetix ve Burp Suite gibi yazılımlardan yararlanılabileceği gibi, MySQL Veritabanı Adının – Tablo Ön Ekinin  ve Server IP adresinin belirlenmesiyle birlikte yalnızca URL parametrelerinden de yararlanılabilir. Bu anlamda DDoS için bir güvenlik duvarı oluştururken; sunucunun CloudFlare ya da benzer servisler tarafından Proxy üzerinden geçirilmesi de aynı zamanda Server IP adresinin tespit edilmesinin önüne geçtiği için sıkı bir güvenlik tedbiridir. Server IP ve kayıtlarına ulaşmanın daha ileri teknikleri olsa da (proxy üzerinden geçtiğinde bile) securitytrails adresinden de temel bir tarama yapılabilir. (Profesyonel tarama işleminde proxy arkasındaki web sitesinin trafiği izlenir)

 

İkinci senaryo ise parola ataktır. Bu girişim, Brute Force – Kaba Kuvvet Saldırısı olarak isimlendirilir; büyük keyword listelerinden yararlanılarak parolaların deneme – yanılma yöntemi ile bulunmaya çalışılmasıdır. Tersine mühendislik kullanan işletim sistemi (Linux Backtrack gibi) veya uygulamaları bir web sitesindeki Kullanıcı / Yönetici giriş parolasını Random değerler üreterek bulmaya çalışır. WordPress bu ataklara karşı karmaşık parola koşullandırması getiriyor olsa bile sabırlı bir girişimde parolaların yakalanma ihtimalleri; parolaların karmaşıklığına göre azalır ya da artar. Bu tür bot ataklara karşı üretilen Google reCAPTCHA ise bunun önüne geçebilir ve WordPress giriş panelinde de bir reCAPTCHA uygulaması iyi bir önlem olabilir…

 

Google reCAPTCHA’nın da karanlık bir tarafı olduğu Cornell Üniversitesi’ndeki Bilgisayar Bilimi bölümünde doktora yapan bir öğrenci tarafından iddia edilmiştir ve bu iddiaya göre de reCAPTCHA V2 ve V3 uygulaması Google çerezlerine bakmaktadır; eğer ki istek -Google çerezleri bulunan tarayıcıdan geliyorsa- daha az riskli olarak puanlanmaktadır. Bu iddianın vereceği fikir; reCAPTCHA uygulamasının bir açığı bulunamayacağı ve hiçbir şekilde bypass edilemeyeceğini düşünmemektir. Bir giriş formu kullanmanız zorunlu değilse ve kritik olabilecek bir form özelliği de taşıyorsa; bu URL / bu Form girişi üçüncü şahısların erişimine kapatılmalıdır.

 

 

Htaccess yapılandırmayı genişletmek için şunu da incelemenizde yarar var: WordPress Htaccess Yapılandırma

 

 

(2188)


2.19K
Görünüm

7 yorum

  • Avatar
    Burak

    Süper bir anlatım teşekkürler

  • Avatar
    tayfun

    function phpyi hangi programla düzenleyebiliriz ?

    • WPEnvolay
      WPEnvolay

      Merhaba! Bunu basit bir not defteri kullanarak da düzenleyebilirsin; dosyayı not defterine sürükle ve bırak, hepsi bu kadar. Gelişmiş bir deneyim için de, Visual Studio Code / Brackets / Sublime Text / Notepad++ gibi kod editörlerini de kullanabilirsin. Kodu, functions.php dosyasında son satıra ekle.

  • Avatar
    Peace

    Merhaba,
    example.com/wp-admin/install.php
    setup-config.php
    upgrade.php

    Buraları direk 403 forbidden yerine, nasıl 404’e yönlendirebilirim? ya da wp-admin dizinindeki tüm dosyalara erişimi nasıl 404 verdirebilirim? WPS-Hide login ile wp-login ile wp-admin erişimini kısıtlıyorum ancak dosyalara hala erişim olabilir yazıda dediğiniz gibi.

    • WPEnvolay
      WPEnvolay

      merhaba. yorumda dosya ve alan adı formatı kullandığınız için güvenlik; yorumu askıya aldı, bu nedenle geç fark edildi. güvenlik için soruyorsanız bu dosyalar için bir şaşırtma olmayacak; bu dosyaların 403 olduğu, yani sunucuda çalıştığı bilinir. belki eklenti dosyalarını bulmakta ip ucu toplanmasının direncini kırabilir. birkaç çeşit yol var: kök izni varsa httpd ya da htaccess ile ve php ile de yönlendirilebilir. sunucudaki bu dosyaların; dosya adları bozulmadan, html kodlarında 403 yerine 404 yazılarak bir hile de yapılabilir… yanıtı kısa yoldan htaccess’de bulacaksınız: (htaccess dosyanıza ekleyin – html & shtml) ErrorDocument 403 /404.shtml

  • Avatar
    Peace

    Yanıtınız işin teşekkür ederim ancak şöyle bir şey yaptım, .htaccess üzerinden bu dosyalara erişimi engelledim, plesk üzerinden 403 olan forbidden sayfasını da 404’e yanıltma olarak yönlendirdim, yani sunucu bu dosyalara 403 veriyor ama 404 sayfasına yönlendiriyor. Bu işlem mantıklı mıdır?

    • WPEnvolay
      WPEnvolay

      bu bir 404 hilesi ve sakıncası yok. bu da istemciden doğru hata kodunu gizler.

Avatar

Şu HTML niteliklerini kullanabilirsin: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">