tp, 10 points award!

by mě zajímalo, jestli třeba takovýto příspěvek antispam pustí, zkratka+anglická slova, vykřičník, na to by už měl být nějaký bayes pomalu alergický ;-)

a rázem ukazuju, že jsem úplně mimo, protože po zmínce o sovách jsem se jal komentovat bez přečtení techniky antispamu :) sorry za spam..

Ach jo, tak jsem přišel pozdě a 10 bodů za DL nebude :-(
Třeba SwitchProxy rozšíření pro FF umí měnit proxy server po uplynutí nastavené doby, ale takových superparanoiků asi moc nebude.

[3] Tak, tak. IP adresa se může dynamicky měnit, ať už z jakýchkoli důvodů. Za pár vteřin je najednou dostupnější nějaký jiný proxy server a ejhle, stejný uživatel a jiná IP. Kdesi jsem o tom četl (v učitelských novinách to ale nebylo) a nemohu si vzpomenout kde jen to bylo.

Zkousel jsem radu zpusobu. Nejvice se mi osvedcila pouha zmena nazvu komentarovych poli (Bud ruco fuco (cca.5min)) a nebo skrz řadu WYSWYGu, ktere umozni nahradit dany vyraz, vyrazem urcenym...

Simple, ale funguje (delam to kazdy tyden a bez problemu:)

[4] to s tím střídáním proxyn mě taky napadlo, a snažím se o tom najít něco bližšího - ale přišlo mi absurdní, že by se střídaly tak rychle, že by to určitého uživatele úplně vyřadilo z možnosti komentování..

Ja jsem na to narazil pred casem taky - na tu rychlou zmenu IP adresy, delalo to nekterym uzivelum pripojeny pres dial-up a musel jsem prehodnotit system prihlasovani. Udelejte si test - ukladejte si cookie a IP adresu a uvidite jestli mate stejnou cookie pro ruzne IP rychle po sobe, Leo

Já mám ve formuláři skryté pole s názvem článku. Spamů mažu asi tak pět za měsíc - řekl bych, že ručně přidávaný.

S rychlou změnou IP by to byla pěkná patálie. Musel bych používat jiný vstup pro hashování (teď je to ip adresa). ID spotu nebo něco podobného by ale podle všeho mohlo stačit. Uvidím, na co příjdou další komentující.

My mame na skole proxy cache a ta zpusobuje ze tak co pul minuty menim IP, protoze proxy ma z nejakeho duvodu zvenku nekolik IP a mezi nimi uzivatele vicemene nahodne prepina. Takze i sluzby jako el. bankovnictvi jsou nepouzitelne, protoze jedna session je vzdy s jednim IP, a to tu vydrzi nekolik desitek sekund...

Pokud se nemylim, zkus se pripojit pres Eurotel a sleduj svou IP adresu.

Mozna souvislost s jejich transparentni cache... ale jsem laik, se v tom nevyznam, jen davam stripky co jsem tak poruznu zaslechl :)

Tak z notebooku, který mám připojený do sítě přes ten počítač ze kterého to nejde se komentář odeslat podařilo... To sem blázen.

Btw. sovy jsou z městečka Twin Peaks. :o)

Taky je možné pro hash zkombinovat název spotu s datumem. A pak testovat třeba proti několika dnům zpátky a doufat, že nikdo nebude posílat komentář později než týden od načtení formuláře.

Ráno mi přidávat komentáře nešly. Zkusím to tedy nyní znovu. Fajn, zabil to zdejší antispam. To se dalo čekat.

Jdeme dál. Vypínám Google Accelerator. Co teď? Zase odchyceno.

S vypnutým acceleratorem zkouším reload celé stránky.

Takže, jak se ukazuje, pes byl zakopán v Google Acceleratoru. Kdyžtak http://webaccelerator.google.com/ , zjisti si IP adresu, tuším, že tam byla nějaká sedmdesát dvojka.

Některé osobní firewally (třeba Kerio, ale záleží na nastavení) blokují proměnnou $REMOTE_ADDR a ta je pak prázdná. Nemůže to být ono?

Některé cache servery (i transparentní) používají více IP adres, kvůli rozkládání zátěže. Někde jsem četl o tom, že byla snaha, aby se pro jednoho uživatele používala stejná IP, ale to byl asi jen jeden produkt, evidentně to není všeobecný zvyk proxy serverů.

Rychle se IP adresa může měnit také při přidělování přes DHCP - tam se adresa přiděluje buď na hodně dlouho (v řádech desítek hodin až dní), aby měl počítač relativně stálou adresu, nebo na krátký čas (v minutách), aby se rychle vracely nepoužívané adresy. I když pokud má počítač přidělenu IP adresu, měl by při obnově dostat přednostně tu samou...

Takže bych to viděl nejspíš na ty proxy servery. Slušný proxy server by ale měl posílat hlavičku s původní IP adresou, což ale asi některé paranoidní proxy nedělají.

Ad [16] Kerio blokovat $REMOTE_ADDR nemůže, tu proměnnou si zjišťuje server na základě IP adresy, odkud přichází spojení (a to blokovat nelze, protože - zjednodušeně - jinak by server nevěděl, kam má odpovídat)

> Vycházel jsem z toho, že spamovací robot přistupuje do skriptu, který zpracovává komentáře, přímo bez toho, aby otvíral stránku s komentářovým formulářem.

Proč tedy hashovat právě $_SERVER['REMOTE_ADDR'] ($REMOTE_ADDR už prosím ne)? Vždyť můžu hashnout cokoliv. Například vygeneruju náhodné číslo, to vložím do "hidden" pole formuláře, dále k tomuto číslo připojím určitý řetězec (sůl), hashnu a dám do druhého "hidden". A pak jen porovnám.

Při připojování aktuálního dne / hodiny do hashe je třeba dávat pozor na to, že formulář mohu načíst např. v 15:59 a odeslat v 16:10

[18]
>Proč tedy hashovat právě $_SERVER['REMOTE_ADDR']
Protože jsem ten algoritmus převzal od kohosi chytrého (včera před psáním spotu jsem hledal zdroj, ale nenašel) a moc jsem nad tím nehloubal. Říkal jsem si, že chyba rychle vyplave. A ona mrška rychle nevyplavala.

> $REMOTE_ADDR už prosím ne
Rozkryjte mi (coby PHP laikovi) problém s $REMOTE_ADDR.

>Vždyť můžu hashnout cokoliv.
A tak to taky budu dělat. Prosolení je samozřejmost (i když pro tento účel možná nebude nutné).

[17] Opravdu jsou lidé, kteří $_SERVER['REMOTE_ADDR'] mají prostě prázdnou, já jsem kvůli tomu musel zrušit jedno ošetření proti spamu, které jsem také používal. Nevím přesně, co tuto proměnnou blokuje, ale vysledoval jsem, že právě lidé s firewaly ji nemají.
Jednoduše chci říci, že na základě $_SERVER['REMOTE_ADDR'] nelze stavět, musí se na to asi jinak.

[18] proto jsem psal o přidávání datumu, ne času. A pak to kontrolovat proti několika předchozím dnům.

Prostě aby formulář měl omezenou životnost - pokud by nějaký robot formulář načetl, tak aby ho po týdnu musel načíst znova.

[20] neverim, firewall nemuze zablokovat adresu, odkud prichazeji pakety, nepletes si to s HTTP_REFERER?

jinak zmenu IP muze zpusobovat DHCP, coz tu bylo zmineno (Leo a dalsi, jen *ta* zkratka chybi ;)

[22] resp takto, firewall u klienta nemuze zablokovat "prosaknuti" IP adresy v TCP/IP stacku na serveru z nejaky nizky urovne, kde se to spojuje na uroven vysokou do PHP engine.

[19] $REMOTE_ADDR je překonaný přístupu k vnějším proměnným. Doporučuje se používat $_SERVER['REMOTE_ADDR']. V současných verzích PHP už ve výchozím nastavení ani starý způsob nefunguje (je třeba manuálně změnit direktivu register_globals na on).

[24] Díky.

[25] jinak popsano ji to i treba tady: http://interval.cz/clanek.asp?article=2264

Takové průběžné změny IP adres klienta dělají i některé bránové routery, zpravidla u větších společností, pravděpodobně pro rozložení zátěže. Vím, že se přesně takhle chovaly (a možná ještě chovají?) přístupy z české pobočky IBM, kdy každý dotaz od stejného klienta šel z jiné IP adresy.

Jestli by nebylo lepší použít analogickou kontrolu předchozího zobrazení formuláře, ale nikoliv přes uchování hashe IP adresy, ale přes sessions (potažmo přes cookies). Sice by se tím odfiltrovali uživatelé bez cookies (dobře jim tak :), ale hlavně snad všichni roboti.

[27] testovat zobrazeni formulare

tak tohle jsem zavedl - do session jsem si ukladal cas zobrazeni a musel byt do 30 min od odeslani a spam to neomezilo, takze vetsina spam botu co chodila ke me tohle zmakla levou zadni