Bezoekers via een proxy blokkeren

[aKeY]

Op mijn website heb ik last van verbannen leden die telkens een nieuw account registeren via diverse anonieme proxy servers. Aangezien het een enorme klus is om deze servers handmatig op een blacklist te zetten (b.v. in een .htaccess bestand) zit ik eraan te denken om iedereen die via een proxy mijn site bezoekt geen toegang te geven tot de content.

Middels de volgende code wil ik dat voor elkaar krijgen:

PHP:

<?php if(@fsockopen($_SERVER['REMOTE_ADDR'], 80, $errstr, $errno, 1)) die("Proxy access not allowed"); ?>

Buitenom het feit dat ik nu ook bezoekers raak die via een legitieme proxy mijn site bezoeken, kan deze code verder nadelige gevolgen hebben? (B.v. google zoek resulaten, etc?)

edit: oeps.. ik denk ik het verkeerde forum geplaatst

[ Voor 4% gewijzigd door aKeY op 19-05-2017 14:10 ]

[DennusB]

Ik snap niet helemaal waarom je bovenstaande code daarvoor wil gebruiken? Hoe zo zou het resultaat uit die IF betekenen dat het om een proxy gaat?

[CodeCaster]

Het helpt altijd om de gedachte achter code uit te leggen, zodat de lezer niet de code hoeft te interpreteren en terug te herleiden welk probleem de schrijver denkt dat die code oplost.

De code die je post, blokkeert een verzoek als jouw server binnen één milliseconde een verbinding kan maken op poort 80 naar het IP van de bezoeker.

Dat is een bijzonder naïeve manier om proxies te herkennen. Afgezien van het feit dat een proxy niet op poort 80 hóeft te draaien, als de bezoeker nu van een adres komt waarop een publiek toegankelijke webserver draait, kan deze jouw site niet meer bezoeken. Laat staan zoekmachines, het schijnt namelijk dat Google een website heeft (al zal die niet op dezelfde IP's draaien als de crawlers).

[ Voor 18% gewijzigd door CodeCaster op 19-05-2017 14:19 ]

[aKeY]

CodeCaster schreef op vrijdag 19 mei 2017 @ 14:15:
Het helpt altijd om de gedachte achter code uit te leggen, zodat de lezer niet de code hoeft te interpreteren en terug te herleiden welk probleem de schrijver denkt dat die code oplost.

De code die je post, blokkeert een verzoek als jouw server binnen één milliseconde een verbinding kan maken op poort 80 naar het IP van de bezoeker.

Dat is een bijzonder naïeve manier om proxies te herkennen. Afgezien van het feit dat een proxy niet op poort 80 hóeft te draaien, als de bezoeker nu van een adres komt waarop een publiek toegankelijke webserver draait, kan deze jouw site niet meer bezoeken. Laat staan zoekmachines, het schijnt namelijk dat Google een website heeft (al zal die niet op dezelfde IP's draaien als de crawlers).

De gedachte achter de code, mee eens, mijn excuses

Ik heb de code van een andere website, en deze is van mening dat dit 1 van de betere manieren is.. vandaar mijn topic

[CodeCaster]

aKeY schreef op vrijdag 19 mei 2017 @ 14:24:
[...]
Ik heb de code van een andere website, en deze is van mening dat dit 1 van de betere manieren is.. vandaar mijn topic

Dat is het probleem met blogs en snippetsharingsites. De auteur vindt zijn eigen code altijd geweldig, en "it works, I've tried it!", en er is geen mogelijkheid voor anderen om feedback te leveren.

Zie bijvoorbeeld Detect clients with Proxy Servers via PHP, waar die aanpak ook gesuggereerd wordt, en waar wél diverse comments staan waarom het niet werkt. Je server heeft door deze "broken by design"-aanpak ook praktisch gezien ineens maar de helft van z'n capaciteit over (elk request kost twee sockets).

Kortom: proxies detecteren is geen eenvoudige opgave.

[DukeBox]

Is het een internationale site ? Zo nee kan je evt. met geo blocking werken aangezien de meeste proxy's buiten NL staan.

[aKeY]

Thanks @CodeCaster voor de heldere uitleg

@DukeBox nee, het is een NL site en heb inderdaad ook aan geo blocking gedacht, alleen bij de eerste de beste anonieme proxy die ik tegenkwam kon je ook een NL locatie kiezen. Dat is de reden waarom ik voor een andere oplossing wil gaan.

[DukeBox]

@aKeY Die paar NL kan je toch wel dan apart blocken ?

[aKeY]

@DukeBox Je hebt een punt, thanks die neem ik mee in mn overweging. Mijn dev team zit alleen wel in het buitenland, maargoed die kan ik op een whitelist toevoegen.

[DukeBox]

aKeY schreef op vrijdag 19 mei 2017 @ 14:38:
@DukeBox Je hebt een punt, thanks die neem ik mee in mn overweging. Mijn dev team zit alleen wel in het buitenland, maargoed die kan ik op een whitelist toevoegen.

Je kan ook vragen om een wachtwoord voor alles buiten je geo locatie.. dan kan iedereen die het wachtwoord weet zoals je development team er wel gewoon bij als het moet. Ook voor jezelf als je toevallig een keer in het buitenland bent of zo. Zo hebben we het hier ook opgelost.

[Room42]

aKeY schreef op vrijdag 19 mei 2017 @ 14:38:
@DukeBox Je hebt een punt, thanks die neem ik mee in mn overweging. Mijn dev team zit alleen wel in het buitenland, maargoed die kan ik op een whitelist toevoegen.

Of een VPN-verbinding geven.

[DukeBox]

^ ook een prima oplossing echter hangen die bij ons niet achter een vpn mogelijkheid.

[RocketKoen]

Overigens zou ik die maatregelen alleen gebruiken op de pagina om een nieuwe account aan te maken.
Soms zitten je gewone gebruikers namelijk ook achter een proxy zonder dat ze dat weten. Gratis WiFi in de trein/bus enz.
Dan hoef je ook niet bang te zijn dat zoekmachines je niet meer kunnen vinden. Want die krijgen hooguit alleen de inlog pagina niet te zien.

[Verwijderd]

aKeY schreef op vrijdag 19 mei 2017 @ 14:08:
Op mijn website heb ik last van verbannen leden die telkens een nieuw account registeren via diverse anonieme proxy servers.

Kan je niet van andere oplossingen gebruik maken? Fingerprinting van browser en OS bijvoorbeeld?

[aKeY]

RocketKoen schreef op vrijdag 19 mei 2017 @ 14:48:
Overigens zou ik die maatregelen alleen gebruiken op de pagina om een nieuwe account aan te maken.

Goed punt!

[aKeY]

Verwijderd schreef op vrijdag 19 mei 2017 @ 14:54:
[...]

Kan je niet van andere oplossingen gebruik maken? Fingerprinting van browser en OS bijvoorbeeld?

Klinkt als een aardig complexe oplossing? (die wellicht goed werkt? )

[Verwijderd]

aKeY schreef op vrijdag 19 mei 2017 @ 15:06:
Klinkt als een aardig complexe oplossing? (die wellicht goed werkt? )

Waarschijnlijk wel complexer, maar ik zou zelf zoeken naar een oplossing die legitieme gebruikers zo min mogelijk raakt. Ongewenste figuren doen al genoeg schade, dat hoeft niet nog erger gemaakt te worden.

[GrooV]

Betere oplossing is het gebruik van een fatsoenlijke registratie controle. Een nieuw ip heb je zo, via een proxy, vpn, wifi hotspot, tor of 4g verbinding. Dat houdt je proxy script niet tegen.

[RiDo78]

Je kunt overwegen om een set van maatregelen te nemen. Bijvoorbeeld:

• Geef een userid-cookie aan elke browser waarmee een user inlogt
• Geef een anoniem-cookie aan elke bezoeker die (nog) niet inlogt
• Detecteer bezoekers die niet eerder zijn langs geweest en wel meteen (binnen x-aantal pageviews) willen registreren.
• Sta per emailadres maar 1 registratie toe
• Zoals al geopperd, doe aan browser-profiling, gebruik onder andere get-browser()
• Probeer dmv. clientside javascript het werkelijke IP-adres van de bezoeker te achterhalen
• Maak een ajax-query en laat de client de headers controleren op de aanwezigheid van proxy-headers
• Sla de verkregen IP-adressen gehashed op

Zo kun je nog wel een aantal verzinnen.

Een aantal van de bovenstaande punten spreken voor zich en kun je direct implementeren, zoals 1 registratie per emailadres. Maar met een aantal anderen moet je opletten. Zeker wat betreft de IP-adressen. Die kun je beter toepassen door per check een aantal punten toe te kennen en dan met een bepaalde threshold te gaan werken. Wie teveel checks 'triggered' en dus teveel punten heeft, kan zich niet registreren. Bij twijfel kunnen ze registreren, maar bijvoorbeeld een maximaal aantal posts doen voordat ze door een admin of mod geverifieerd zijn. Twijfelachtige accounts kun je dan ook nog blokkeren als blijkt dat ze veel IP-adressen van een geblokkeerd account gebruiken of per ongeluk proberen in te loggen op browser waar een cookie van een geblokkeerde gebruiker aanwezig is.

Dus bij registratie en hervalidatie:
ALS aantal punten < twijfel threshold DAN volledige toegang
ALS aantal punten tussen twijfel en kritieke threshold DAN beperkte toegang
ALS aantal punten >= kritieke DAN registratie blokkeren

Bij inloggen:
ALS account volledige toegang heeft DAN inloggen
ALS account beperkte toegang heeft DAN opnieuw via (onzichtbare) hervalidatie-pagina

Overigens is mijn ervaring met geblokkeerde users dat ze vooral hun ei kwijt willen. Zeker als ze zich benadeeld voelen. Dus vergeet niet om hun wel (beperkt) de mogelijkheid te bieden een modje aan te spreken voor tekst en uitleg en zijn/haar kant van de medaille te vertellen. Daar voorkom je al heel wat ellende mee.

[ Voor 7% gewijzigd door RiDo78 op 22-05-2017 19:10 ]

[Hydra]

RiDo78 schreef op maandag 22 mei 2017 @ 19:07:
Zo kun je nog wel een aantal verzinnen.

Je kunt van alles verzinnen maar je gaat mensen die vernuftig genoeg zijn een proxy te gebruiken hier echt niet mee buiten de deur houden. En de kans dat je false positives krijgt wordt steeds hoger. Dus je hindert op den duur meer je gewone gebruikers dan de vervelende types. Je bent een bizar complex systeem aan het bedenken dat eigenlijk niks oplost.

Zorg gewoon dat je relschoppers makkelijk en snel kunt bannen.

[ Voor 7% gewijzigd door Hydra op 23-05-2017 08:43 ]

[MSalters]

"Gwoon" bannen is bekend niet effectief. Stealth banning (gebande user kan nog wel inloggen, maar heeft z'n eigen sandbox) of hell banning (gebande users komen samen in 1 sandbox) is effectiever.

[aKeY]

Bedankt allemaal voor het meedenken! Een hoop nuttige tips, dank daarvoor!

@RiDo78 Klopt wat je zegt over de mogelijkheid om een modje aan te spreken. Ik ontvang soms een mail waarin men hun hart lucht, maar ik voorkom lange discussies. Soms geef ik leden 1 kans om hun leven te beteren. Vaak (of zeg maar bijna altijd) leest men het beleid niet van de website, dus ja, dan ga je soms snel de mist in.

Middels de de tip van @DukeBox heb ik nu een GEOIP module voor apache geïnstalleerd en de tip van @RocketKoen opgevolgt door op de registratiepagina een php scriptje te includen die controleert of iemand uit NL of BE komt. Zoniet, mag er niet geregistreerd worden.

Verder heb ik uiteraard de standaard checks in m'n site zitten (1 mail per registratie, etc). Indien een lid wordt geband, dan krijgen ze een eigen sandbox (i.v.v. alle rechten worden ontnomen), wordt het emailadres op een blacklist gezet, de username mag niet meer worden geregistreerd (helaas voor de nieuwe leden) en het ip-adres geblokkeerd.

Nu nog ffe die paar anonieme NL en BE proxies in een bestand gooien en ik kan voorlopig vooruit. De meeste relschoppers zijn heet hoofden die niet verder komen dan het gebruiken van een anonieme proxy.. echte kwaadwillende weten vast een andere manier om alsnog een account te registreren.. maar dat heb ik (gelukkig) nog niet meegemaakt..

[ Voor 4% gewijzigd door aKeY op 23-05-2017 20:37 ]

[igmar]

aKeY schreef op vrijdag 19 mei 2017 @ 14:08:
Op mijn website heb ik last van verbannen leden die telkens een nieuw account registeren via diverse anonieme proxy servers. Aangezien het een enorme klus is om deze servers handmatig op een blacklist te zetten (b.v. in een .htaccess bestand) zit ik eraan te denken om iedereen die via een proxy mijn site bezoekt geen toegang te geven tot de content.

Middels de volgende code wil ik dat voor elkaar krijgen:

PHP:

<?php if(@fsockopen($_SERVER['REMOTE_ADDR'], 80, $errstr, $errno, 1)) die("Proxy access not allowed"); ?>

Dan zul je niet veel bezoeker meer krijgen : Deze code opent een connectie naar poort 80. Bij het merendeel van de gebruikers zal ie dichtstaan. Bij een goed geconfigureerde proxy ook.

Je bent beter af door een lijst met bekende proxies te gebruiken, en voor de zekerheid ook op X-Forwarded-For te controleren.