Finweblog - Matěj „Finwë“ Humpál

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 + mod_access 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 On

   SecAuditEngine RelevantOnly
   SecAuditLog logs/audit_log

   SecFilterDefaultAction "allow"

   SecFilterCheckUnicodeEncoding On

   SecFilterSelective "HTTP_REFERER" "(viagra|texas holdem|cials|drugs|insurance)" "deny,log,status:403"
   SecFilterSelective "POST_PAYLOAD" "(viagra|texas holdem|cials|drugs|insurance)" "deny,log,status: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,application/xml,application/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|drugs|insurance)" at HEADER("REFERER")
mod_security-action: 403

HTTP/1.1 403 Forbidden
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

Komentáře

RSS feed komentářů k tomuto článku