Benaderbaarheid van Tweakers.net via TOR

[Brent]

Via TOR gebeurt het vrij regelmatig dat je tegen een 'Toegang geweigerd' aanloopt. Nu zullen daar bepaalde redenen voor zijn, maar toch is het gek dat ik het probleem hoofdzakelijk bij Tweakers heb, bijna geen andere site staat zo scherp afgesteld. Indien het mogelijk is hier iets aan te doen, dan zou ik dat waarderen. Een .onion URL zou ook leuk zijn

[Hackus]

Er komen steeds meer sites waar je geen gebruik van zult kunnen maken. oa je bank zal ook half werken of helemaal niet. Cookies toestaan om de site werkend te krijgen kan al helpen

[ Voor 20% gewijzigd door Hackus op 16-07-2019 13:12 ]

[Brent]

Cookies zijn het probleem niet, het is een IP ban. IP-range based blokkeren werkt natuurlijk (het zal wel om ranges van bepaalde blacklists gaan), maar is ook wat weinig elegant

[AW_Bos]

Is Tor trouwens ook niet de bron van oplichting in bijv. V&A? In dat geval kan ik me indenken dat ze een hoop nodes hebben geblokkeerd.

[ Voor 5% gewijzigd door AW_Bos op 16-07-2019 13:25 ]

[corset]

allemaal aannames, zullen we even feiten afwachten?

[ACM]

Brent schreef op dinsdag 16 juli 2019 @ 13:08:
Via TOR gebeurt het vrij regelmatig dat je tegen een 'Toegang geweigerd' aanloopt. Nu zullen daar bepaalde redenen voor zijn, maar toch is het gek dat ik het probleem hoofdzakelijk bij Tweakers heb, bijna geen andere site staat zo scherp afgesteld.

Wellicht zijn wij wat strenger omdat we twee interessante database hebben: de profielen (via /gallery) en de pricewatch.

Wij hebben daarom een paar geautomatiseerde processen die ip's die massaal onze site scrapen of security scans uitvoeren blokkeren.

En helaas wordt door dat soort partijen massaal misbruik gemaakt van Tor en VPN's.
Die worden in de praktijk dus relatief vaak geblokkeerd.

Het gaat dan overigens niet om een 'beetje' meer verkeer vanaf zo'n ip dan vanaf normale. Het is niet ongebruikelijk dat er meer dan 10.000 pageviews in een uur vanaf een specifiek ip komen.

Ik durf wel de weddenschap aan dat veel meer van het verkeer dat via Tor binnenkomt malafide is - meestal door dat soort bulk-partijen - dan legitiem

Indien het mogelijk is hier iets aan te doen, dan zou ik dat waarderen. Een .onion URL zou ook leuk zijn

Mede doordat er zoveel misbruik via Tor wordt gemaakt, zie ik dit niet echt gebeuren. Maar tegelijkertijd heb ik zelf nooit Tor gebruikt en kan ik ook niet op waarde schatten wat het nut van een .onion-versie van de site is en/of wat die zou moeten bieden (of is dat letterlijk alleen een andere url voor Tweakers?).

AW_Bos schreef op dinsdag 16 juli 2019 @ 13:25:
Is Tor trouwens ook niet de bron van oplichting in bijv. V&A? In dat geval kan ik me indenken dat ze een hoop nodes hebben geblokkeerd.

Ja, dat is het ook. Daarom mag je met Tor ook standaard veel minder dingen op de site, V&A-advertenties plaatsen wordt ook uitgesloten tenzij je inlogt en aan een paar criteria voldoet

[ACM]

Mocht je je afvragen wat we zoal tegen komen, deze melding kwam net binnen over het afgelopen uur.

Vanaf 1 tor-ip kwamen 1017 pageviews binnen, allemaal op de Pricewatch. Deze specifieke crawler is slim genoeg gemaakt om onze cookiewall te accepteren en doet daarna in rap tempo dit onderstaande soort requests.
In dit geval kreeg ie op 1009 van de requests een captcha, maar om ons extra te beschermen (onnodige belasting, etc) worden ip's die door blijven gaan alsnog in de firewall geplaatst.

16-07-2019 20:43:15	/pricewatch/1202841/epson-c13t944340.html
16-07-2019 20:43:14	/pricewatch/1274165/ross-le2sa200-ro.html
16-07-2019 20:43:14	/pricewatch/1366190/cocoon-tech-16-inch-zwart.html
16-07-2019 20:43:13	/pricewatch/1140649/rock-s3-23011-(galaxy-siii-i9300)-geel.html
16-07-2019 20:43:09	/pricewatch/1194533/oki-46490402.html
16-07-2019 20:43:08	/pricewatch/1283509/ricoh-842082.html
16-07-2019 20:43:08	/pricewatch/1098911/adata-premier-microsdhc-uhs-i-class-10-16gb.html
16-07-2019 20:43:07	/pricewatch/1368086/mantona-dolomit-2300.html
16-07-2019 20:43:07	/pricewatch/1127325/hp-procurve-switch-6600-24g-4xg-ww.html
16-07-2019 20:43:06	/pricewatch/1334780/incase-cl60684-grijs-zwart.html
16-07-2019 20:43:05	/pricewatch/125437/ag-neovo-f-417-zwart.html
16-07-2019 20:43:05	/pricewatch/1264805/pioneer-mvh-a200vbt.html
16-07-2019 20:43:04	/pricewatch/1219087/startech-punt-com-lange-micro-...
16-07-2019 20:43:04	/pricewatch/1107299/strong-srt-49fx4003-zwart.html
16-07-2019 20:43:03	/pricewatch/1121059/hp-zbook-17-g4-2zb75ea.html
16-07-2019 20:43:03	/pricewatch/1106495/eeconn-glasvezel-...
16-07-2019 20:43:02	/pricewatch/1318122/lederen-bookcase-hoesje-...
16-07-2019 20:43:02	/pricewatch/10907/toshiba-mk2016gap-20gb.html
16-07-2019 20:43:01	/pricewatch/1278861/philips-koffiezetapparaat-hd7435-20.html
16-07-2019 20:43:01	/pricewatch/1203815/gembird-3dp-pla175-01-cg.html

Zoals gezegd komen dit soort requests niet alleen van Tor-nodes, wat dat betreft maken we er geen onderscheid in. Maar Tor komt wel relatief veel voor en wordt door relatief veel Tweakers ook gebruikt; de meeste tweakers zullen niet via e.o.a. hoster in Brazilië of Israël of mobiele provider in Kenia onze site bezoeken.

[Brent]

Dank ACM, ik dacht wel dat jullie een goede reden zouden hebben. Het is als gebruiker echter jammer dat ik niet mijn login cookie kan gebruiken om te bewijzen dat ik geen bot ben. Is daar misschien iets mogelijk?

[Freeaqingme]

ACM schreef op dinsdag 16 juli 2019 @ 20:58:
In dit geval kreeg ie op 1009 van de requests een captcha, maar om ons extra te beschermen (onnodige belasting, etc) worden ip's die door blijven gaan alsnog in de firewall geplaatst.

Puur uit nieuwsgierigheid, leveren dit soort requests dan load op op de webservers? Wordt dit niet allemaal in ram gecached?

Verder snap ik de vraag van TS wel. Hoewel ik snap dat je bepaalde activiteiten voor bepaalde risicogebieden wat wil afschermen, is het natuurlijk wel fijn als je ook op vakantie vanuit bijv. China nog zo af en toe op GoT kan.

Bij Coudflare lossen ze dat op door een captcha te serveren als je de website opent (vanaf een 'risico-ip'). Als je die captcha succesvol doorloopt, dan krijg je een token waarmee je (bijv.) 100 pagina's kan opvragen. Daarna krijg je weer een captcha te zien. Om te snappen hoe gebruikers dit ervaren heeft Cloudflare op een gegeven moment hun kantoor ip ook als risico-ip aangemerkt, zodat werknemers in ieder geval wisten hoe deze gebruikers het internet zouden ervaren.

Blogpost van Cloudflare

[Brent]

Captcha + Privacy Pass is een oplossing idd, maar dan moet je die hele captcha santekraam weer optuigen. Al is het zeker ook waar ik aan dacht.

[ACM]

Brent schreef op dinsdag 16 juli 2019 @ 21:05:
Dank ACM, ik dacht wel dat jullie een goede reden zouden hebben. Het is als gebruiker echter jammer dat ik niet mijn login cookie kan gebruiken om te bewijzen dat ik geen bot ben. Is daar misschien iets mogelijk?

Voor de Captcha-variant wel.

Voor de uiteindelijke ip-ban is dat vooralsnog niet uitgewerkt en ook een stuk lastiger te integreren, omdat dat al bij de loadbalancers wordt afgewerkt ipv pas op de webservers die ook in de database (kunnen) kijken.

Freeaqingme schreef op dinsdag 16 juli 2019 @ 21:14:
Puur uit nieuwsgierigheid, leveren dit soort requests dan load op op de webservers?

Uiteraard. Het zijn niet onze zwaarste pagina's, maar ze doen wel erg veel requests. Het afgelopen uur werd zo'n 32% - zo'n 21k - van de pageviews op de prijspagina's in de Pricewatch door dergelijke bots gedaan.

Op zich geen load waar we heel erg van wakker liggen, maar ook weer niet iets waar we onze investeringen aan willen verspillen

Wordt dit niet allemaal in ram gecached?

Ja en nee. Er worden juist op de prijspagina's vrij veel gegevens bij elkaar gehaald. De individuele winkelprijzen worden elke 10 minuten ververst, dus caches zijn relatief inefficiënt daar.
Al met al hebben we vooral moeite gedaan om die pagina snel te maken, zonder helemaal alles in cache te proberen te stoppen.
Met caches heb je namelijk weer allerlei nieuwe problemen rond "cache invalidation" en is het moeilijker dingen op maat te maken (zoals verschillen in de verzendkosten-instellingen).

Verder snap ik de vraag van TS wel. Hoewel ik snap dat je bepaalde activiteiten voor bepaalde risicogebieden wat wil afschermen, is het natuurlijk wel fijn als je ook op vakantie vanuit bijv. China nog zo af en toe op GoT kan.

Dat kan ook, in principe worden de meeste (misschien wel alle, weet ik niet zeker ) van die extra beschermingen uitgeschakeld als je ingelogd bent als actieve gebruiker. Tenzij dus tegelijkertijd met 'risicogebied' ook nog een 'veelmisbruiker' datzelfde ip gebruikt

Bij Coudflare lossen ze dat op door een captcha te serveren als je de website opent (vanaf een 'risico-ip'). Als je die captcha succesvol doorloopt, dan krijg je een token waarmee je (bijv.) 100 pagina's kan opvragen. Daarna krijg je weer een captcha te zien. Om te snappen hoe gebruikers dit ervaren heeft Cloudflare op een gegeven moment hun kantoor ip ook als risico-ip aangemerkt, zodat werknemers in ieder geval wisten hoe deze gebruikers het internet zouden ervaren.

Wij hebben recent iets soortgelijks geïntroduceerd, maar (nog) niet de bijbehorende firewall-oplossing verwijderd. En bovendien hebben we het niet voor alle pagina's geplaatst, omdat het een relatief zware oplossing is en meestal onnodig is daar. Maar als we de firewall-oplossing zouden verwijderen, moeten we dat opnieuw inrichten.

Wat trouwens extra vervelend is, de crawler die ons nu lastig valt - aannemende dat er 1 partij achter zit - doet het vanaf duizenden verschillende ip's, dus 100 pagina's toelaten is al erg veel. Wat trouwens überhaupt de reden voor de ratelimit+captcha was, want de ipban-grenzen verlagen werd wel heel ongebruiksvriendelijk

Blogpost van Cloudflare

Wij hebben sowieso niet de luxe van heel veel servers en lagen die Cloudflare heeft. Effectief kunnen we dit soort dingen op 3 plekken doen:
- De botte bijl in onze network level firewall
- Een iets minder botte en slimmer inzetbare optie in onze loadbalancer (daarom krijg je iig nog een enigszins duidelijke melding), wat we in deze context meestal 'firewall' noemen
- Heel fine-graned in onze webservers, inclusief rate limiting en controle of je een betrouwbaar iemand bent (aka ingelogd bent )

Helaas schaalt dat ook in omgekeerde volgorde. De firewall kan veel 'goedkoper' bepalen dat verkeer vanaf een bepaald ip niet welkom is en blokkeren dan de laatste. Die is daar tenslotte voor gemaakt...

Bij de webserver is het generieke php-code (een andere taal maakt dit nauwelijks sneller). En tegen de tijd dat we deze controle goed en wel kunnen doen is een groot deel - ik gok de helft - van het werk van een prijspagina al gedaan.
Dat omvat dan o.a. het openen van een Apache-thread, starten van php, starten van het Symfony-framework en de juiste 'controller' daarin laden, het laden van je sessie en de rate-limiting data voor je ip inladen en nog aardig wat dingen.

[ACM]

Mocht iemand iets weten dat kan helpen om de impact op goedbedoelende bezoekers te beperken of een alternatieve wijze om de slechterikken te blokkeren, laat het vooral weten.

We staan open voor andere oplossingen, maar we hebben niet per se de capaciteit of mogelijkheden als een bedrijf als Cloudflare, dus we hebben vast ook niet alle mogelijkheden uitputtelijk bekeken (of geweten dat ze bestaan). Vergeet dan niet dat we ook als doel hebben om die malafide crawlers zoveel mogelijk buiten te sluiten.

[ Voor 21% gewijzigd door ACM op 16-07-2019 21:52 ]

[Freeaqingme]

Thanks voor de uitgebreide reactie. Zijn leuke inkijkjes hoe andere partijen dit soort problemen dit oplossen

Hoewel je bij een anti-abuse ding nooit 100% transparant wil zijn omdat kwaadwillenden daar dan weer sowieso misbruik van maken kan, zou dit tegelijkertijd zomaar een heel leuke .plan kunnen zijn waarin je iets dergelijks beschrijft.

Dat soort artikelen komen bij mij in het mapje van techblogs als Netflix, Github, Google & Facebook. Dat is wat dit betreft helemaal niet erg om in dat rijtje te staan

[Raven]

Freeaqingme schreef op dinsdag 16 juli 2019 @ 21:14:
Bij Coudflare lossen ze dat op door een captcha te serveren als je de website opent (vanaf een 'risico-ip'). Als je die captcha succesvol doorloopt, dan krijg je een token waarmee je (bijv.) 100 pagina's kan opvragen. Daarna krijg je weer een captcha te zien.

offtopic:
Daar ben ik helaas maar al te goed bekend mee , heb IPv6 uit moeten zetten omdat ik steeds meer websites tegen kwam waarbij ik tegen steeds maar terugkomende Cloudflare captcha's aanliep. Bij een enkeling (Adafruit) verscheen niet eens een captcha om er toch op te kunnen komen.
Cloudflare weigert mij vooralsnog te vertellen waarom, alleen dat het om "security events" vanaf mijn IPv6-addressen gaat.

[Brent]

ACM schreef op dinsdag 16 juli 2019 @ 21:39:
[...]

Dat kan ook, in principe worden de meeste (misschien wel alle, weet ik niet zeker ) van die extra beschermingen uitgeschakeld als je ingelogd bent als actieve gebruiker.

Dat is niet hoe het werkt bij Tweakers nu. TOR roeleert elke x minuten (5 oid?) van pad, dus IP. Je hebt dan dus elke 5 minuten kans weer tegen de IP-blokkade op te lopen, en dat ervaar ik ook. Cookies helpen daar niet bij. Je merkt het ook aan het opeens geen push-notificaties ontvangen bijvoorbeeld: het pad is geroeleert, kennelijk naar een bad-IP en dat heeft Tweakers.net verder niet door dat je toch een ingelogde gebruiker bent. De IP controle lijkt altijd voor cookie-controle te zitten. Een (soms twee/drie) keer de TOR route verversen en het werkt weer, zonder opnieuw inloggen oid.

ACM schreef op dinsdag 16 juli 2019 @ 21:51:
Mocht iemand iets weten dat kan helpen om de impact op goedbedoelende bezoekers te beperken of een alternatieve wijze om de slechterikken te blokkeren, laat het vooral weten.

Als de volgorde inderdaad IP, daarna cookie controle is, dan zou je deze kunnen omdraaien. Of anders uitleggen wat ik verkeerd doe, want ik ben weldegelijk ingelogd

[ Voor 26% gewijzigd door Brent op 17-07-2019 11:02 ]

[Hero of Time]

In plaats van het vanuit Tweakers op te lossen vraag ik mij eerder af wat de noodzaak is om Tweakers via TOR te benaderen. Welk voordeel denk je er überhaupt uit te halen? Je maakt het door de legitieme maatregelen jezelf alleen maar moeilijker.

[Brent]

Voorop gesteld dat het een persoonlijke keuze zou moeten zijn hoe je precies browsed, is Tweakers dus een van de weinige sites waarop TOR tot problemen leidt (sommige banksites zijn de andere groep, voor de rest loop ik eigenlijk hooguit soms tegen Cloudflare captcha-hell aan), wat jammer is voor een techsite Het zou mooi zijn als Tweakers hierin in elk geval niet achterloopt, uiteraard zonder in te boeten op bestrijding fraudeurs e.d. M.i. zou door in geval van twijfelachtig IP eerst op het cookie te controleren alvorens te blocken het probleem opgelost zijn. Ik begrijp dus nog niet helemaal of dat is wat ACM zegt al zou moeten gebeuren, in elk geval lijkt het er bij mij op dat dat niet zo is. Scheelt mij het circuit zo nu en dan handmatig updaten

Persoonlijk heb ik 2 redenen voor het gebruik:

1) Het maakt mij tracken moeilijker. Uiteraard met een login cookie voor Tweakers doe ik dat voor deze server teniet, maar dat is mijn keuze.

2) Door het legitieme TOR verkeer te vergroten, normaliseert het en wordt het bruikbaarder voor mensen die er om bepaalde redenen echt vanaf hangen. Dit is hoe ik praktisch die zaak help.

[ Voor 5% gewijzigd door Brent op 17-07-2019 12:30 ]

[Hero of Time]

Brent schreef op woensdag 17 juli 2019 @ 12:28:
Voorop gesteld dat het een persoonlijke keuze zou moeten zijn hoe je precies browsed,

Dat is tot een zeker punt het geval. Wil jij liever met Firefox 1.0 beta gaan browsen omdat het voor jou de ideale browser is, dan ga je tegen heel veel problemen aan lopen.

Hetzelfde als je veel liever Windows 98 wilt blijven gebruiken, want die is nog zo lekker ligt en snel.

Er is gewoon een grens tot waar je de gebruiker tegemoet komt.

is Tweakers dus een van de weinige sites waarop TOR tot problemen leidt (sommige banksites zijn de andere groep).

Dat je problemen hebt om gebruik te maken van internetbankieren is een logische stap. Het moet veilig zijn en blijven. TOR is echt een wespennest van rotzooi en je hebt geen idee wat een node allemaal met je verkeer kan doen. Het is daarom niet zo heel gek dat er partijen zijn die maatregelen nemen tegen TOR gebruik, om de veiligheid van de dienst te kunnen garanderen. Of in het geval van Tweakers, om gebruikers niet lastig te vallen met een tragere site door de vele crawlers die via TOR komen.

Het zou mooi zijn als Tweakers hierin in elk geval niet achterloopt,

Ik denk dat Tweakers hier eigenlijk vooruit loopt op andere, vergelijkbare sites. Als ze geen dienst als Cloudflare afnemen om dat te regelen.

uiteraard zonder in te boeten op bestrijding fraudeurs e.d.

Wat kan je op bijvoorbeeld Marktplaats allemaal via TOR? Wordt je daar ook maar enigszins beperkt?

M.i. zou door in geval van twijfelachtig IP eerst op het cookie te controleren alvorens te blocken het probleem opgelost zijn. Ik begrijp dus nog niet helemaal of dat is wat ACM zegt al zou moeten gebeuren, in elk geval lijkt het er bij mij op dat dat niet zo is. Scheelt mij het circuit zo nu en dan handmatig updaten

De TOR blokkade gebeurt op de 'firewall'. De loadbalancer houdt de meeste zooi tegen. Die kan geen cookies uitlezen voor je sessie, want die bestaat dan weer in de database en vereist code van de applicatie, welke op de webservers staat. Als je je sessiecookie wilt controleren, zit je al op het derde punt dat ACM uitlegde als potentiële plekken om verkeer tegen te houden. Er is dan al zo veel geladen, dat het qua load eigenlijk niet eens meer uitmaakt om het hele verzoek af te handelen en de pagina te serveren, of alsnog de boel af te kappen.


Note: bovenstaand is mijn eigen interpretatie van de gegeven informatie. Ik heb geen enkel inzicht in de systemen van Tweakers.

[Brent]

Hero of Time schreef op woensdag 17 juli 2019 @ 13:26:
[...]


Note: bovenstaand is mijn eigen interpretatie van de gegeven informatie. Ik heb geen enkel inzicht in de systemen van Tweakers.

Laten we daarom vooral niet teveel aannemen en @ACM aan het woord laten Dat het jouw usecase niet is, heb je duidelijk gemaakt, maar dat betekent niet dat we het daarbij hoeven laten. Gezien ACMs reacties staat hij er wel open voor. Ik werk/denk graag mee om legitiem gebruik wat te vergemakkelijken.

[Hero of Time]

Brent schreef op woensdag 17 juli 2019 @ 13:31:
[...]

Laten we daarom vooral niet teveel aannemen en @ACM aan het woord laten Dat het jouw usecase niet is, heb je duidelijk gemaakt, maar dat betekent niet dat we het daarbij hoeven laten. Gezien ACMs reacties staat hij er wel open voor. Ik werk/denk graag mee om legitiem gebruik wat te vergemakkelijken.

Zeker, maar als beheerder zelf kan ik wel wat extra uitleg geven dat het niet zo eenvoudig is om op te lossen. Het kost uiteindelijk ook tijd en dat kan uiteindelijk meer kosten dan het ongemak van een enkele/paar gebruiker(s). Wees er dus bewust van dat er geen garantie is dat er een positief antwoord komt.

[Brent]

Ik heb die garantie dan ook nergens aangetroffen bij het plaatsen van mijn post, dus dat al mijn wensen niet stante pede vervult worden: daar ben ik mij van bewust Toch dank dat je me er even op wijst; misschien kun je ook even alle andere feature request van een dergelijke toevoeging voorzien

[ACM]

Brent schreef op woensdag 17 juli 2019 @ 10:59:
Dat is niet hoe het werkt bij Tweakers nu.

Jawel. Zolang je niet een geblokkeerd ip hebt, wordt je account gebruikt voor om verdere controles te beperen.

De IP controle lijkt altijd voor cookie-controle te zitten.

In mijn beleving had ik dat ook verteld in de reacties hierboven... Althans, wellicht heb ik teveel aangenomen dat men hier weet in welke volgorde verkeer binnenkomt bij een webserver (firewall -> loadbalancer -> webserver).

Als de volgorde inderdaad IP, daarna cookie controle is, dan zou je deze kunnen omdraaien. Of anders uitleggen wat ik verkeerd doe, want ik ben weldegelijk ingelogd

Zie de opmerking over schaalbaarheid en netwerkvolgorde.

De firewall gaat eerst aan het werk, daarna komt de loadbalancer aan het werk en pas daarna de webserver. Eerst 'iets met cookies' doen, betekent dus effectief dat we de firewall en loadbalancer helemaal niks kunnen laten doen en alles bij de webservers terechtkomt. En dat maakt het 'zwaarder' en ons daarmee ook nog wat meer vatbaar voor DDoS-aanvallen.

Brent schreef op woensdag 17 juli 2019 @ 12:28:
Voorop gesteld dat het een persoonlijke keuze zou moeten zijn hoe je precies browsed, is Tweakers dus een van de weinige sites waarop TOR tot problemen leidt (sommige banksites zijn de andere groep, voor de rest loop ik eigenlijk hooguit soms tegen Cloudflare captcha-hell aan), wat jammer is voor een techsite Het zou mooi zijn als Tweakers hierin in elk geval niet achterloopt, uiteraard zonder in te boeten op bestrijding fraudeurs e.d. M.i. zou door in geval van twijfelachtig IP eerst op het cookie te controleren alvorens te blocken het probleem opgelost zijn. Ik begrijp dus nog niet helemaal of dat is wat ACM zegt al zou moeten gebeuren, in elk geval lijkt het er bij mij op dat dat niet zo is. Scheelt mij het circuit zo nu en dan handmatig updaten

Zie eerdere opmerkingen, maar "IP op cookie controleren" kan niet. Cookie is onderdeel van het HTTP-protocol iets dat bovenop het tcp/ip-protocol werkt. De firewall zelf werkt alleen met tcp/ip en kan dus niet 'iets' met cookies doen.
De firewall kan dus alleen bepalen dat "verkeer van/naar ip X en/of van/naar poort Y niet mag", wat effectief voor je browser betekent 'de website is onbereikbaar'.

Om die reden doen we daarom ook de meeste schifting pas op de loadbalancer, die kan je dan in ieder geval nog beantwoorden met "hey, [..uitleg..] je bent geblokkeerd".
Maar ook daar maken we niet voor iedere request verbinding met de database of andere geavanceerde controles. Wederom omdat dat relatief veel werk is om verkeer te blokkeren dat we niet willen ontvangen.

Het 'iets met cookies doen' kan dus pas als e.e.a. door die eerste twee barrières is gekomen. En dat zal ook zo blijven, om de genoemde technische redenen.

Brent schreef op woensdag 17 juli 2019 @ 13:31:
Laten we daarom vooral niet teveel aannemen en @ACM aan het woord laten Dat het jouw usecase niet is, heb je duidelijk gemaakt, maar dat betekent niet dat we het daarbij hoeven laten. Gezien ACMs reacties staat hij er wel open voor. Ik werk/denk graag mee om legitiem gebruik wat te vergemakkelijken.

We staan zeker open om dit te verbeteren. Maar we zijn tegelijkertijd ook gebonden aan de manier waarop netwerken werken en daarmee onze hardware-opstelling. Bovendien houden we ook de behoefte om e.e.a. zo efficiënt mogelijk te verwerken, wat dus betekent dat we zoveel mogelijk op de meest schaalbare plekken willen beperken (firewall, loadbalancer, dan pas webserver).

Onbewust en onbedoeld (neem ik in ieder geval aan ) vraag je effectief om Tor minder streng te behandelen dan 'de rest van de wereld'. En dat terwijl er juist vanaf Tor relatief veel misbruik komt.
Of natuurlijk om als geheel minder streng te zijn.

Dus er 'iets' aan doen, is wel erg lastig, zonder onze eisen als geheel te verslappen.

[Freeaqingme]

ACM schreef op woensdag 17 juli 2019 @ 20:32:
Zie eerdere opmerkingen, maar "IP op cookie controleren" kan niet. Cookie is onderdeel van het HTTP-protocol iets dat bovenop het tcp/ip-protocol werkt. De firewall zelf werkt alleen met tcp/ip en kan dus niet 'iets' met cookies doen.

Menig firewall werkt ook op layer 7, dus als je alleen zegt 'er staat een firewall voor' dan hoeft dat je niet te beperken tot l3/l4

In plaats van traffic op de firewall 100% te blokkeren zou je ook het destination ip kunnen rewriten. Dit stuur je dan naar een node die losstaat van de rest van de productie-website zodat je eventuele attacks in ieder geval hebt afgeschermd. Op die node zou je dan allemaal intelligente layer 7 magie (bijv. is user ingelogd en heeft 'ie een karma van >1000) kunnen uitvoeren zonder dat het de reguliere webservers belast. Is de traffic dan alsnog oke bevonden kan je het alsnog doorsturen naar die reguliere webservers.

Dat zou in php kunnen, maar ik zou 't zelf eerder in Varnish vmod, haproxy lua script of Go iets schrijven.

[ Voor 4% gewijzigd door Freeaqingme op 17-07-2019 21:31 ]

[ACM]

Freeaqingme schreef op woensdag 17 juli 2019 @ 20:56:
Menig firewall werkt ook op layer 7, dus als je alleen zegt 'er staat een firewall voor' dan hoeft dat je niet te beperken tot l3/l4

Onze Fortinets doen in ieder geval niet aan https decoderen... Geen idee of ze dat zouden kunnen, maar dat doen ze nu in ieder geval niet. Hoedanook doen we het meeste van dit werk op onze loadbalancers, die uiteraard wel https decoderen en ook daar al de meeste van de huidige beslissingen nemen.

In plaats van traffic op de firewall 100% te blokkeren zou je ook het destination ip kunnen rewriten. Dit stuur je dan naar een node die losstaat van de rest van de productie-website zodat je eventuele attacks in ieder geval hebt afgeschermd. Op die node zou je dan allemaal intelligente layer 7 magie (bijv. is user ingelogd en heeft 'ie een karma van >1000) kunnen uitvoeren zonder dat het de reguliere webservers belast. Is de traffic dan alsnog oke bevonden kan je het alsnog doorsturen naar die reguliere webservers.

Dat zou in php kunnen, maar ik zou 't zelf eerder in Varnish vmod, haproxy lua script of Go iets schrijven.

Interessant. Maar wel aardig wat werk, dus sowieso niet iets dat we 'even snel tussendoor' gaan kunnen fixen. En we moeten het dan ook beter uitdenken, want het zal tot op zekere hoogte de normale servers belasten; o.a. de database voor de user-check. De webservers zelf zijn niet per se degene die ontlast moeten worden.

Overgens is de belasting ook niet de enige (ik denk zelfs niet de belangrijkste) reden om de ip's helemaal te blokkeren. De captcha-oplossing met token bucket die we nu hebben laat alsnog wat verkeer door, waardoor een lange adem van zo'n partij alsnog tot op zekere hoogte effectief is

Al met al moeten we dus e.e.a. op een rijtje zetten en beter uitdenken voor we dingen kunnen/gaan wijzigen.
Inclusief ook nog een evaluatie van de nu gebruikte oplossingen, de captcha-oplossing die op de webservers pas wordt uitgevoerd is vrij nieuw en vooralsnog op een beperkt deel van de site ingezet; misschien moet dat wel de hoofdmanier worden.
Maar dat is niet iets dat we 'even' doen, dat moeten we beter uitdenken (inclusief een poging doen om de belastingcomponent ervan te beoordelen) en komt daardoor automatisch in competitie met de rest van onze backlog.

[Freeaqingme]

ACM schreef op woensdag 17 juli 2019 @ 21:58:

[...]

Interessant. Maar wel aardig wat werk, dus sowieso niet iets dat we 'even snel tussendoor' gaan kunnen fixen.

Eens. Het kan wellicht een leuk stageproject zijn, maar het is niet iets wat iemand in een half dagje er even bij doet.

ACM schreef op woensdag 17 juli 2019 @ 21:58:
En we moeten het dan ook beter uitdenken, want het zal tot op zekere hoogte de normale servers belasten; o.a. de database voor de user-check. De webservers zelf zijn niet per se degene die ontlast moeten worden.

Ja, snap ik. Ik ging daar bewust niet heel erg inhoudelijk op in omdat het natuurlijk heel domein-specifiek is. Wat je kan doen is een cookie 'is_loggedin' zetten die je hasht met het remote adres (of iets anders waarmee je de sessie kan identificeren) en versleutelt (of HMAC'ed) met een key die je iedere X uur rotate. Die key kan je perfect cachen, en dan hoef je niet naar de database om te verifieren dat iemand legit ingelogd was.

Opties te over, maar zoals gezegd niet iets wat je er even bij doet.

[Brent]

Klein kickje: Cloudflare heeft hier PrivacyPass voor ontworpen en vrij beschikbaar gesteld. Mocht hier ooit werk van gemaakt worden, is dit evt een oplossing die van de plank getrokken kan worden:

https://privacypass.github.io

[ACM]

Brent schreef op vrijdag 23 augustus 2019 @ 17:21:
Klein kickje: Cloudflare heeft hier PrivacyPass voor ontworpen en vrij beschikbaar gesteld. Mocht hier ooit werk van gemaakt worden, is dit evt een oplossing die van de plank getrokken kan worden:

https://privacypass.github.io

Heel tof dat ze zoiets doen.

Maar helaas is het - net als veel open source dingen - nogal onduidelijk hoe je dat dan precies moet toevoegen aan je server-stack. Er is een privacy pass server in Go; in die README leggen ze uit dat je json-requests kan doen, maar verder niet hoe je dit verwerkt in je loadbalance-laag. En bij de protocol-specificatie kom je ook niet verder dan 'client sends ... to edge' en 'edge sends ... to client'.

Wat ik o.a. (zo snel) niet kan vinden is wat voor header de client stuurt naar de 'edge' bij het eerste bezoek waar een captcha opgelost moet worden en hoe de edge daarop moet reageren. En daarnaast wat de client dan doorstuurt naar de edge als ie eenmaal die captcha heeft opgelost en hoe de edge dat dan moet controleren. En wat zelfs mist is hoe de privacy-pass server daar nou precies tussen zit.

Ironisch genoeg is er best veel documentatie. Maar ze leggen eigenlijk alleen maar meerdere keren uit hoe het protocol zelf werkt, niet hoe je het protocol moet gebruiken of hoe je hun voorbeeld server moet gebruiken.

Kortom, ik zie het met dat significante gebrek in de documentatie niet geïmplementeerd worden bij ons en in de rest van de wereld. En mochten ze dat oplossen; dan is het alsnog afwachten of het überhaupt is in te passen en hoe complex dat dan is om te implementeren.

[Verwijderd]

Zo gaat het bij alle goede ideeen van commerciële partijen. In de white papers staat uitgelegd wat je zelf ook had kunnen bedenken en de details zijn toegespitst op hun eigen product.