Folosesc modulul All in One WP Security & Firewall de ceva timp, timp în care am dibuit cam ce ştie să facă.
Aseară, de curiozitate, am intrat la 404 detection, o pagină în care sunt afişate adresele de pe blog ce au fost accesate şi nu s-a ajuns nicăieri + IP-ul de pe care a fost făcut asta. Când, ce să vezi, erau 20 de pagini cu legături 404. 😐
Toate erau aşa: /astabasta/?action=jetpack-sso&site_id=62102823 &sso_nonce= ××××××××××××××××××××, unde ×××××××××××××××××××× era un „cârd” de litere şi cifre ce semăna cu un text în base64, „cârd” diferit de fiecare dată.
Din fericire, pagina de autentificare pe blog nu mai este astabasta. Am redenumit-o de curând. Din fericire, iarăşi, Jetpack Single Sign On este inactiv pe blog. Nu am nevoie să mă loghez folosind contul de WordPress.
Acum urmează să fac ceva pentru a împiedica aşa ceva să se repete, căci nu mai vreau încă 1998 de rezultate 404 – pagina nu a fost găsită. 🙂
Griji cu securitatea nea Vasile
Sunt safe. 🙂
Safe nu esti niciodată 😀
Ştiu…
La cat mai multe incercari! Sa ne gasim la anul cu 2016.
Bată-te peste tastatură. 🙂
La mine attack attempts astea au avut un efect atat de spurcat incat aproape mi-au pus serverele in *cur*. Am intrat intr-o dimineata pe unul si aveam load de 3000 de doar cu reboot am scapat. De atunci m-am invatat minte si am restrictionat accesul pe WP admin doar din reteaua ISP-ului meu si am redirectionat toate erorile 401, 403 si 404 pe un link de CPA. De atunci am doi an de liniste in care serverul e super stabil si-si ia reboot doar la update-urile de kernel.
Eu folosesc Cloudflare şi am setat nivelul de securitate înalt pentru panoul de administrare, inclusiv pagina de logare. Poate nu vor fi probleme…
Eu am incercat sa evit Cloudflare deocamdata fiindca avand mai multe domenii (cateva sute) si separate pe diverse servere si conturi de hosting shared si reseller atunci cand unul are probleme mi-e mai simplu sa-i verific DNS-ul sa vad unde are IP-ul si sa stiu imediat ce panou de control sa accesez.
Oricum Cloudflare face de obicei o treaba buna in ceea ce priveste atacurile, dar ii mai scapa uneori cateva. Problema la WordPress e ca redirectioneaza toate erorile 4xx catre index.php si pe site-uri cu baze de date relativ mari, cu mult trafic toata treaba asta deschide conexiuni inutile pe MySQL si in functie de configuratia de MySQL poate cauza latenta sau mai rau load mare pe server. De asta am redirectionat toate erorile 4xx catre CPA si pe anumite site-uri catre un fisier HTML care aproape ca nu consuma resurse.
Probabil voi face şi eu un redirect pentru 404, chiar dacă nu le mai contorizez. Sau să pun un wp_die() cu un counter imagine extern, să ştiu ce adrese au returnat 404.
Merge si asa si e o idee chiar buna, eu aproape ca nu contorizez nimic deocamdata fiindca mai toate site-urile sunt in curs de dezvoltare si pana la retusul final n-are rost 😀
Baftă şi să le duci pe culmile succesului cu bine!
Multumesc 😀 din pacate imi lipseste tare mult timpul sa le dezvolt mai repede fiindca uneori lucrez si 10 ore pe zi si trag sa mai si profit de timpul liber. Dar atat timp cat inca nu cer de mancare e ok 😉