On Thu, Dec 28, 2023 at 08:53:23AM +0100, Martijn van de Streek wrote:
> Geert Stappers schreef op wo 27-12-2023 om 11:40 [+0100]:
> > Waar de "portier" op moet letten is vanaf waar een HTTP request komt.
> > En bij meer dan N verzoeken in tijdsbestek "tijd van alleen halen is
> > voorbij" antwoorden.
> >
> >
> > Welke richting zoek ik verder moeten zoeken?
>
> Optie 1: Authorisatie
>
> Authorisatie kun je heel groots aanpakken met een Keycloak of Ory
> server en dan elk request de OAuth2/OIDC tokens verifiëren, of heel
> simpel met HTTP Basic Authorization waarmee je voor elke legitieme
> gebruiker een gebruikersnaam + wachtwoord maakt (".htaccess" noemen
> sommige mensen dit nog, uit de tijd dat alle webservers Apache waren).
>
> OAuth2 vereist wel dat je API-servers of reverse proxy dit ook
> ondersteunen.
Oja, in eerste bericht niet vertelt wat er achter de reverse proxy zit.
Dat zijn zaken waar geen account voor nodig is,
bijvoorbeeld "apt install"
> Optie 2: Rate limiting
>
> Rate limiting kunnen de meeste reverse proxies op basis van allerlei
> criteria. De meeste reverse proxies ondersteunen dit:
>
> Nginx: https://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
> Traefik: https://doc.traefik.io/traefik/middlewares/http/ratelimit/
>
> Optie 3: Blokkeerlijst
>
> Je kunt ook een statische of dynamische blokkeerlijst bijhouden van IP-
> adressen van bekende misbruikers, en de reverse proxy zo instellen dat
> die áltijd een foutmelding krijgen.
>
> Met een programma als fail2ban kun je loganalyse doen en daarmee een
> dynamische blokkeerlijst maken (detecteer scrapen = 24 uur IP ban, dat
> idee).
Het nieuwe inzicht is dat ik vooral de webservice moet gaan bouwen
die ik zelf wil hebben. En _nu niet_ druk maken over free riders.
> Groeten,
> Martijn
Dank
Groeten
Geert Stappers
--
Silence is hard to parse
