Referrer spam - jak se bránit?

Referrer spam je skrytější formou spamu, než třeba spam v mailech nebo komentářích. V předchozím článku, jehož téma byl komentářový spam jsem přislíbíl detailní popis, tož tady je.

Referrer. Adresa, ze které se nově příchozí dostal na naší stránku. Spammeři v tomto případě využívají stránek, které veřejně zobrazují příchozí referrery (ať už přímo na vlastním webu – podle Google je jich až dost – nebo ve statistikách přístupů – jeden příklad za všechny – povšimněte si nijak nemaskovaných adres XXX stránek, to je referrer spam).

Boj s referrerovým spamem je do jisté míry obtížnější, než se spamem komentářovým. Boj na aplikační úrovni je totiž náročný na prostředky serveru (kontrolovat referrer každého příchozího požadavku, parsovat jej, porovnávat s blacklistem…) a samotnou aplikaci znepřehledňuje, zvětšuje a zpomaluje. Proto tuto metodu nechám nerozvedenou a zaměřím se na boj na straně serveru. Konkrétně metody pomocí modulů serveru Apache: mod_rewrite, mod_setenvif

a modSecurity.

Nepoužitá metoda: mod_setenvif + mod_access

Tato metoda má nároky na specifické moduly serveru a navíc vyžaduje, aby měl provozovatel webu možnost tyto moduly konfigurovat. Její nevýhoda je také v tom, že musíme znát adresy (ať už IP či URI), odkud spammeři útočí.

Pomocí SetEnvIf (editací souboru .htaccess) se pro všechny referrery či adresy spamovacích robotů nastaví zvláštní prostředí (environment) (pro case insensitive procházení je třeba použít SetEnvIfNoCase)

SetEnvIf Referer .\.hold-em\.com. referrer_spam SetEnvIf Referer .\.penthermine\­.com. referrer_spam

Pokud se některý z regulárních výrazů shodne s URI referreu, přiřadí se mu proměnná prostředí referrer_spam. Pak o toto prostředí zakážeme pomocí mod_access přístup. Stejně tak jde zakázat přístup pro jednotlivé IP.

Order Allow,Deny Deny from env=referrer_spam Deny from 159.187.56.77
Výhody
zachyceným spammerům se zobrazí chyba 403,
z předchozího vyplývá, že existuje šance, že to spammeři vzdají,
pokud je „blacklist“ dostatečně rozsáhlý, pak je velká účinnost.
Nevýhody
neúčinné při malém „blacklistu“,
nutnost znát URI či IP spammera.

Nepoužitá metoda: modSecurity

modSecurity (aka mod_secure) je speciálním modulem pro server Apache. V základní distribuci není, je proto jej třeba zvlášť stahnout a nainstalovat. modSecurity pak, pokud se v nastavení Apache povolí, prochází všechny příchozí požadavky a zachází s nimi podle zadaných pravidel.

<IfModule mod_security.c>SecFilterEngine On
SecFilterScanPOST OnSecAuditEngine RelevantOnly
SecAuditLog logs/audit_logSecFilterDefau­ltAction „allow“SecFilterChec­kUnicodeEncoding OnSecFilterSelective „HTTP_REFERER“ „(viagra|texas holdem|cials|drug­s|insurance)“ „deny,log,sta­tus:403“
SecFilterSelective „POST_PAYLOAD“ „(viagra|texas holdem|cials|drug­s|insurance)“ „deny,log,sta­tus:403“</IfModule>

Takto nastavený mod_secure prochází referrery a POST požadavky, a pokud ty obsahují některé ze slov viagra|texas holdem|cials|drug­s|insurance, pak se místo požadované stránky zobrazí chyba 403, a přístup se zaloguje. Log záznam může vypadat např. takto:

==ed2ddf01===­========================­===Request: bobr.gfxs.cz 84.42.132.13 – – [28/Mar/2006:­21:28:21 +0200] „GET / HTTP/1.1“ 403 399 „http://bobr.gfxs­.cz/viagra.php“ „Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1“ – „-“GET / HTTP/1.1 Host: bobr.gfxs.cz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0­.1 Accept: text/xml,appli­cation/xml,ap­plication/xhtml+xml­,text/html;q=0­.9,text/plain;q=0­.8,image/png,/;q=0­.5 Accept-Language: cs,en-us;q=0.7,en;q=0­.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0­.7 Keep-Alive: 300 Connection: keep-alive Referer: http://bobr.gfxs.cz/viagra.php mod_security-message: Access denied with code 403. Pattern match „(viagra|texas holdem|cials|drug­s|insurance)“ at HEADER(„REFERER“) mod_security-action: 403HTTP/1.1 403 For­bidden Content-Length: 399 Connection: close Content-Type: text/html; charset=iso-8859–1 –ed2ddf01–

modSecurity umí spoustu kouzel – a to jak při zjišťování nekalých přístupů (celý požadavek, jen jeho část, GET, POST, IP atd.), tak při jejich zpracovávání (libovolná error message, přesměrování)…

Jako nevýhodu této metody bych uvedl, že pokud jsou daná pravidla vágní, nevyšperkovaná, pak může nadělat více škody, než užitku – zakazuje co nemá a podobně. Po nainstalování mi například nepovolil žádný požadavek POST a rovnou házel chybu 406 Not Acceptable. Přísná pravidla se také špatně nastavují globálně pro server – co vyhovuje na jednom místě, to nevyhovuje jinde. Proto je třeba, aby správci jednotlivých webů (pokud je na serveru samozřejmě více webů) měli možnost upravovat soubor .htaccess a měli znalost mod_secure, aby si mohli pravidla nastavovat sami.

Výhody
modSecurity je velmi široce konfigurovatelný – nastavit lze velká škála podmínek i akcí.
Nevýhody
Při nedokonalé konfiguraci působí víc škody, než užitku
modSecurity není v základní distribuci Apache, není tedy jistá jeho podpora hostingy,
náročné na budování blacklistu,
je potřeba vyznat se v konfiguraci m_s, která není jednoduchá.

Použitá metoda: mod_rewrite

Mod_rewrite hledá slova z blacklistu a pokud uspěje, přesměruje příchozí požadavek daným směrem (lze rovnou do )(, ale osobně používám stránku s českoanglickým textem, který upozorní případného uživatele, že má načíst stránku ručně znovu – tu je potom třeba nezahrnovat do statistik přístupů.)

RewriteCond %{HTTP_REFERER} (the-?discount-?store) [NC,OR] RewriteCond %{HTTP_REFERER} (phentermine) [NC,OR] RewriteCond %{HTTP_REFERER} (cameralover) [NC,OR] RewriteCond %{HTTP_USER_AGENT} (Program Shareware|Fetch API Request) [NC,OR] RewriteCond %{HTTP_USER_AGENT} (Microsoft URL Control) [NC] RewriteRule .* bad-referrer.php [R=403]

Opět platí, že se musí udržovat blacklist (můj má v současnosti 106 řádek). Když ale nejsou pravidla striktní, filtr neudělá to, co dělá modSecurity – nezakáže přístup člověku. Udělá „opak“ – propustí spammera (což je, imho, menší zlo, než když se mi na monitoru objeví chyba 406).

Výhody
mod_rewrite je na hostinzích celkem hojně podporován
celkem jednoduchá konfigurace
Nevýhody
(z neznámých důvodů) nezachytává všechny spammery

Computer$, (Web)design

Komentáře

Honza

29. 4. 2006, 3.06

ehm, a neni jednodusi rict vyhledavaci aby referery neindexoval? at uz nastavenim atributu no_follow refereru, nebo je nofollow komentarem, nebo (nejoskliveji) je dat do iframe a cilovou stranku zakazat… nofollow je nejelegantnesi metoda…ale resit to pres moduly apache je ‚kanon na vrabce‘ :)


Finwe

30. 4. 2006, 16.06

Nevím, jestli ti úplně rozumím. Nofollow atributem si nepomůžu, protože to spamovací roboty neodradí. Prostě budou web navštěvovat dál a dělat bordel ve statistikách – nemyslím si totiž, že by spammeři (a boti) rozlišovali, jestli se odkazy na referrery dělají s, nebo bez atributu nofollow.


Andrew

2. 5. 2006, 9.59

Já mám pocít, že Honza píše spíš o komentářovým spamu, takže se seknul o článek :) Navíc řeší následek a ne příčinu. Jestli ti nějakej bot vloží na blog 1000 komentářů s odkazama, tak už je celkem jedno, jestli jsou ty odkazy funkční nebo ne. Tady se řeší, jak to zařídit, aby se tam těch 1000 komentářů vůbec nedostalo. A tam ti iframe fakt nepomůže :D


makl

4. 12. 2006, 21.11

Nazdar Finwë, pouprav si ten tvůj blacklist, protože když se chce člověk dostat někam dále ze článku http://weblog&#… tak ho ten tvůj filtr nakrásně zachytí :)


Finwe

4. 12. 2006, 21.18

#4 – makl Dík za zprávu, o tom incidentu vím, hlásí mi ho pravidelně referrer-spam-filter-log, ale dosud jsem byl líný s tím něco dělat :)


Petr Vanek

8. 12. 2006, 11.19

Problém nemusí být ve zkreslených statistikách, jako třeba v zahlceném serveru – DDOS attack. I když řešení na straně web serveru mi přijde dost ošemetné, raději bych to filtroval již na IP úrovni.


Marek Lecián

23. 5. 2015, 16.25

Pokud si nechcete blokovat spam přes rewrite. Mám pro vás super nástroj, na pár kliku vám vloží aktuální spam filtry do Google Analytics. ;) http://mareklecian.cz/spamfilter/


Tomáš Lípa

15. 7. 2015, 23.11

Rozhodně k odstranění spamu doporučuji automatický postup od Marka Leciána – sám jsem své úspěchy a neúspěchy s odstraňováním refferer spamu shrnul v článku na svém blogu zde http://www.servistl.cz/…e-analytics/


Vložit komentář

K tomuto příspěvku není povoleno přidávat komentáře.