Sunt unii buți care pur și simplu omoară serverele slăbuțe. Ai cont shared de 50 de lei pe an, pe site-uri mici și chiar n-ai încotro și tragi de toate resursele posibile. Se întâmplă să fie domeniul mai scump decât găzduirea de multe ori.
Așadar, printre optimizările pe care le fac încerc să am statistici cât se poate de clare. Așa că îmi blochez gândacii care vor să vină peste mine, în fiecare zi.
Dacă ar veni și ei săptămânal, lunar… ar fi ceva, dar prea mult strică. 🙂
Așadar, sunt o grămadă de soluții pentru a bloca roboți precum ScoutJet, JamesBOT și așa mai departe.
Cea mai simplă metodă, pentru cei care au apache pe server(în general, mai toate shared-urile au așa ceva), este să vă instalați Spider Blocker. E gratuit și, practic, ai o interfață pentru htaccess.
Se mai poate bloca și cu ajutorul php sau nginx ori chiar robots.txt.
Teoretic, ar trebui să ușureze și munca Akismet.
Sunt multi de blocat pe WordPress: botii aia care fac brute-force pe WP login si XML-RPC sunt cei mai numerosi si agresivi. La fel si cei care incep sa-ti scaneze blogul cu Havij. Dintre astia, script kiddies sunt cei mai daunatori: daca nu sunt boti, vad ca i-ai blocat din .htaccess si dau in continuare in tine, sa-ti consume resursele. Nu neaparat cu gandul de a-ti face rau, insa nu stiu.
Si atunci trebuie sa apelezi la firma de hosting, daca esti pe shared, sa-i blocheze din hardware firewall. Degeaba pui tu restrictie in .htaccess, ca ei iti mananca in continuare resursele. E ca si cum cineva ti-ar da un pumn in nas si tu stingi lumina, fara a te misca de pe loc, sperand ca nu vei mai primi inca unul. Il vei lua la loc, chiar daca e intuneric.
shared? Mai bine OpenVZ la 2 euro, zic eu. 🙂
Corect. Marius, stii ce as face in locul tau?
As trece pe Cloudflare, as seta totul cum trebuie pe acolo, reguli pagini si asa mai departe, dupa care as permite inspre blog doar clasele de IP-uri Cloudflare si IP-ul tau de management, din iptables, in rest as da drop la toate conexiunile.
Foarte putini boti trec de Cloudflare. De exemplu, cand puteam sa-i folosesc, a trecut un singur mesaj de spam de ei, in cateva zile, desi dezactivasem Akismet. In plus, nu mai ai nevoie nici de plugin WordPress de cache. Si alte beneficii, ca timp de raspuns 1ms din 117 centre de date (si mai adauga) incarcare sub jumatate de secunda, din cache, de peste tot, si asa mai departe.
Eu mor de oftica pentru ca nu mai pot sa-i folosesc, mai mult de DNS autoritativ, ca acum, ca daca pornesc protectiile, apar erorile. Si stii cat am discutat cu suportul lor tehnic (ala slab) si cu firma de hosting. Domeniul meu a ramas agatat pe undeva pe la ei, la vechea firma de hosting din Luxemburg, si nu vor sa faca nimic.
Daca faci treburile astea, nu mai ai nevoie sa configurezi tot felul de lucruri la nivel de server, chestii care necesita timp. Stai ca un mic bossulica si iti vezi de scris pe blog si pe celelalte aproape 100 de site-uri pe care le ai, ca un magnat in zona asta a IT-ului. 🙂
Nu sunt la 100 încă. 🙂
Pe România n-am nevoie de cloudfire. Dar pe extern… o să fac asta.
Cloudflare permite single point of failure la nivel de DNS si e foarte riscant atunci cand n-ai control total asupra serverului de gazduire pentru ca un firewall prost configurat poate sa blocheze IP-uri sau subnet-uri intregi de la gateway-urile de la Cloudflare. Eu cat timp nu au capacitatea sa ofere redundanta la nivel de DNS nu-l recomand.
robots.txt e irelevant in 99% din cazuri pentru ca botii pot sa aleaga daca sa-l onoreze sau nu, iar aia malitiosi cu siguranta n-or sa aleaga sa onoreze directivele din robots.txt.
Apoi, daca esti pe VPS sau dedicat si ai acces la configuratia serverului web, cel mai OK e sa pui restrictii direct in configuratie pe care sa le incarce la pornire. In felul asta reduci volumul de stres de pe serverul web si-ti consuma mai putina memorie. Pentru a bloca user-agent e destul de eficient sa folosesti mod_access_compat sau mod_rewrite. (un sample ai aici)
Pe urma, chiar daca ii blochezi tot o sa ai belele cu resursele pentru ca blocarea botilor genereaza un status code 403 pe webserver, iar WordPress e facut (prost) ca sa redirectioneze acel 403 catre index.php, consumand resurse inutile. Asa ca ideal e sa definesti un ErrorDocument custom in .htaccess sau configuratia de Apache care sa duca requesturile blocate catre o pagina goala sau statica.
O alta solutie, ce presupune ceva munca si minime idei in domeniul vectorilor de atac, pentru ca genereaza si false positives daca e configurat prost e Crawl Protect.
nginx?
Ceva de genul asta si poti sa setezi o actiune pentru status code ala. Sau sa inlocuiesti 444 cu 403 si sa redirectionezi apoi catre o pagina goala.
redtube? 😀
Salut, am si eu o problema. Am un blog de 2 luni, insa pana acum nu am decat 2 url indexate, restul sunt blocate de robots, iar in sitemap nu pot sa trimit nimic. Nu stiu cum sa procedez, sa indexez site-ul. Orice sfat e binevenit. Multumesc!
Dacă vorbim de site-ul din semnătură, din ce văd eu e indexat. Problema este că e foarte jos în căutările de pe Google. 🙂