Italiano
Español
РусскийDezactivarea funcției de autentificare în WordPress
În timpul unui atac masiv de tip brute force, aș dori să dezactivez complet posibilitatea de autentificare în WordPress. Singurul cont de pe site este al meu, așa că nu există niciun motiv pentru vizitatori să se autentifice și nu le-ar afecta experiența pe site.
Când am nevoie să mă autentific, pot elimina codul. Alternativ, pot limita autentificările doar la adresa mea IP.
Încerc să realizez acest lucru prin interceptarea unei încercări de autentificare cât mai devreme posibil cu următorul cod:
if (isset($_POST['pwd']) || isset($_GET['pwd'])) {
header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found");
echo 'autentificările pe site sunt dezactivate';
die();
}
Această metodă este rudimentară, dar ar trebui să funcționeze. Cu toate acestea, încă există unele încercări de autentificare care reușesc să treacă și nu știu de unde ar putea veni.
În ce alte moduri acceptă WordPress autentificări, dacă nu prin câmpul 'pwd'?
Există o convenție existentă pentru blocarea autentificărilor?
Edit: Pe lângă blocarea wp-login.php, am șters xmlrpc.php care era folosit ca o altă intrare pentru atacurile brute force. Configurația mea actuală nu are nevoie de el, dar a ta s-ar putea să aibă. Asigură-te că nu ai nevoie de el înainte să îl dezactivezi.
Acest lucru este util, dar caut o modalitate de a scurta circuitul procesului de autentificare de la început. Am Sucuri și un alt plugin instalat care mă alertează în cazul atacurilor brute force. Sunt îngrijorat că această metodă ar putea totuși declanșa acțiunile acestor plugin-uri.
Michael Khalili
@MichaelKhalili, nu poți face asta în mod realist, deoarece încercările de autentificare pot proveni din diverse surse. Dacă ești interesat să blochezi doar wp-login.php sau xmlrpc.php, ar trebui să faci asta la nivelul de configurare al serverului web (htaccess în Apache poate rezolva problema) și să nu lași PHP să ruleze deloc. Singurul cod PHP comparabil (din punct de vedere al performanței) va necesita o modificare a wp-config.php, un fișier pe care ar trebui să-l eviți să-l modifici cât posibil. Orice altă soluție bazată pe PHP nu va fi mai bună din punct de vedere al performanței decât răspunsul oferit.
Mark Kaplun
Am rezolvat această problemă de când am postat întrebarea și am actualizat postarea mea. Pot pune codul care caută $_POST['pwd'] într-un plugin obligatoriu (mu-plugins) și pot dezactiva xmlrpc.php. Se pare că asta funcționează. Am oprit majoritatea atacurilor cu $_POST['pwd'], iar restul au fost oprite după ce am dezactivat xmlrpc.php.
Michael Khalili
Problema cu ștergerea fișierelor este că vor reapărea la actualizare. Mai bine să le blochezi în htaccess dacă nu folosești xmlrpc
Mark Kaplun
Foarte bun punct, Mark. Cred că există și o setare pentru a dezactiva suportul xmlrpc în WordPress. Trebuie să aloc timp să testez asta, totuși. Nici măcar nu sunt sigur care este mecanismul de autentificare în acel fișier.
Michael Khalili
Îmi pare rău, dar este o idee foarte proastă să pui codul în fișierul wp-config.php. De asemenea, nu văd cum diferă codul tău de cel din celelalte răspunsuri?
Johansson
Răspunsul anterior al lui Mark K a fost actualizat de tine, Jack, ieri, corectând greșeala de tipar pe care eu o corectasem.
Este o idee proastă să pui cod în wp-config, acest lucru a fost într-un scenariu de urgență pentru cineva care știe ce face. Cu cât intervenim mai devreme, cu atât mai puține resurse are nevoie WP pentru a încărca și bloca autentificările.
Branndon
Oricine ia în considerare acest lucru ar trebui să-și amintească că cererile publice ajax sunt încă făcute către directorul wp-admin. Dacă site-ul tău folosește ajax, ar trebui să deblochezi calea către admin-ajax.php
Michael Khalili
Și cum WordPress folosește AJAX în nucleu, acest lucru nu ar trebui făcut nicăieri.
kaiser
Sunt de acord că nu este soluția de a "dezactiva" înregistrarea/utilizatorii autentificare, care este întrebarea aici. Dar @kaiser, de ce spui că acest lucru nu ar trebui făcut? Eu fac asta pe două site-uri pe care le administrez personal, unde nu este activată înregistrarea utilizatorilor. De asemenea, folosesc protecție prin parolă .htaccess pentru fișierul wp-login.php. Dacă este configurat corect, cererile Ajax și alte elemente din wp-admin (JS, CSS, imagini) nu sunt o problemă deloc și poate reduce drastic șansele de succes ale atacurilor brute force.
cybmeta
@cybmeta ai redenumit wp-admin?
kaiser
Nu, nu am făcut asta. Aceasta este o altă opțiune dar este mai puțin sigură, URL-ul de admin al site-ului poate fi descoperit cu ușurință, indiferent de ce nume ai dat. Oricum, asta nu explică de ce blocarea accesului la acea locație nu ar trebui făcută deloc. De asemenea, nu văd cum schimbarea numelui este mai bună decât blocarea accesului la o anumită locație. Rețineți că contextul este că nimeni în afară de tine nu va accesa acolo, de ce blocarea accesului pentru oricine altcineva este rea?. În prezent, în cazul în care numai tu ești autorizat să accesezi wp-admin, aș bloca wp-admin cu .htaccess chiar dacă numele este schimbat.
cybmeta