Cum banezi un IP pe un server? (…sau cum opresti spamul)

In ultima vreme am inceput sa fiu mai atent cu se intampla pe blogurile de pe server. Am constatat ca am un blog foarte citit, cu foarte multe hit-uri. Un exemplu evident, este in imaginea de mai jos :

Astfel de spam boti sunt foarte multi, si comentariile lor se aduna cu sutele in Akismet. Stiu ca in WordPress, exista optiunea sa blochezi un IP care vrea sa comenteze, dar acest lucru nu ajuta foarte mult, din doua motive.

1. IP-ul daca este blocat din WordPress –> Dashboard, ajunge la server si trafic exista.
2. Daca pe un server sunt 100 de bloguri… trebuie fiecare in parte sa blocheze acelasi IP. (dureri de cap)
3. De la acelasi IP poate incerca sa caute puncte se securitate vulnerabile, pe alte porturi deschise. (stiu ca am  spus doua motive. unu` e bonus)

O alta metoda de a bloca accesul unui IP pe un site, este editarea fisierului .htaccess, din folderu root, in care se gasesc fisierele site-ului (de regula public_html). Aveam fantezii de genul asta, prin iunie 2007, cand scriam postul “Deny Access to Spammer IP”.
Metoda cu blocarea IP-urilor din .htaccess, nu o recomand nimanui, dintr-un singur motiv: cu cat este mai incarcat fisierul .htaccess, cu atat timpul de incarcare al site-ului creste. Daca 100 de fisiere .htaccess, ar avea cate 50 de directive, pe Apache (HTTP Server), puteti sa puneti bomboane si doua lumanari :)

Cred ca a treia metoda este cea mai buna.. Blocarea IP-urilor la nivel de server, pe toate porturile, folosind iptables.
In imaginea de mai sus, este vazut IP-ul 194.8.74.158, incercand sa spameze unele pagini din blog. Blocarea lui, la nivel de server se face in felul urmator.

root@server [~]# /sbin/iptables -I INPUT -s 194.8.74.158 -j DROP
root@server [~]# /sbin/service iptables save
Saving firewall rules to /etc/sysconfig/iptables:          [  OK  ]
root@server [~]#

Bineinteles ca nu o sa blocam fiecare IP in parte. Din care am vazut, botii folosesc mai multe IP-uri din acelasi bloc. In cazul acesta exista, ARIN si RIPE. 

whois (ripe.net) : 194.8.74.158

inetnum:         194.8.74.0 - 194.8.75.255
netname:        DRAGONARA-NET
descr:             Dragonara Alliance Ltd
country:         GB

Ok. Daca IP-ul provine dintr-o regiune de unde sunt sigur ca nu doresc vizitatori pe server (fie prin web, fie prin mail), am la indemana optiunea sa blochez accesul a doua clase C (Class C subnet), care sa cuprinda toata plaja de IP-uri cuprinsa intre 194.8.74.0 si 194.8.75.255.

/sbin/iptables -I INPUT -s 194.8.74.0/24 -j DROP
/sbin/iptables -I INPUT -s 194.8.75.0/24 -j DROP
/sbin/service iptables save

iptables –L , sa vedeti lista de IP-uri  “Chain INPUT” .

Windows Live Writer / WordPress – Invalid Server Response (XMLRPC)

Incercand sa postez cateva articole pe un blog (platforma: WordPress) cu ajutorul Windows Live Writer, dupa ce am dat “Publish” , am intalnit in repetate raduri o eroare de genul :

“Invalid Server Response - The response to the metaWeblog.newPost method received from the weblog server was invalid: Invalid response document returned from XmlRpc server.” .

Eroarea de mai sus  apare in general, cand in post sunt inserate imagini de dimensiuni mari si pe serverul web (mai exact in Apache) este setat filtrul “SecFilterInheritance ON” .

Cea mai simpla rezolvare a problemei, este eliminarea acestui filtru pentru fisierul xmlrpc.php cu ajutorul .htaccess .

Adaugati in fisierul .htaccess urmatoarele linii si dati “save”

<Files xmlrpc.php>
SecFilterInheritance Off
</Files>

Dupa ce faceti aceasta simpla operatiune, nu vor mai fi probleme legate de XmlRpc. Rezolvarea de mai sus este valabila si in cazul erorii : "Windows Live Writer was not able to automatically detect your blog: Invalid Server Response - The response to the blogger.getUsersBlogs method received from the weblog server was invalid: Invalid response document returned from XmlRpc server", care apare cand doriti sa adaugati un nou cont de blog WordPress  in Windows Live Writer.

ModSecurity.org, explica directiva de securitate : SecFilterInheritance

Filter inheritance

Filters defined in parent folders are normally inherited by nested Apache configuration contexts. This is behaviour is acceptable (and required) in most cases, but not all the time. Sometimes you need to relax checks in some part of the site. By using the SecFilterInheritance directive:

SecFilterInheritance Off

you can instruct ModSecurity to disregard parent filters so that you can start with rules from the scratch. This directive affects rules only. The configuration is always inherited from the parent context but you can override it as you are pleased using the appropriate configuration directives.
Configuration and rule inheritance is always enabled by default. If you have a configuration context beneath one that has had inheritance disabled you will have to explicitly disable inheritance again if that is what you need.

Next Page »