Authenticatiepogingen (vóór authenticatie)
Mislukte authenticatiepogingen worden per IP-adres van de client beperkt, voordat verzoeken worden verwerkt. Dit vormt de beveiliging tegen brute-forceaanvallen voor openbaar toegankelijke Gateways.- Alleen onjuiste aanmeldgegevens tellen mee. Ontbrekende aanmeldgegevens (een client die nooit een token heeft verzonden) en geslaagde authenticaties verbruiken geen budget; een geslaagde authenticatie stelt de teller voor dat IP-adres opnieuw in.
- Standaardwaarden: 10 mislukkingen per 60 seconden, gevolgd door een blokkering van 5 minuten voor dat IP-adres.
- Loopback (
127.0.0.1/::1) is standaard vrijgesteld, zodat lokale CLI-sessies niet kunnen worden geblokkeerd. - Tellers zijn per klasse van aanmeldgegevens afgebakend, zodat een stortvloed tegen het ene oppervlak een ander oppervlak niet verdringt. De bereiken omvatten het gedeelde Gateway- token/wachtwoord, apparaattokens, Node-koppeling, hernieuwde goedkeuring van gekoppelde Nodes, bootstrap-tokens voor apparaten en de uitgifte van watchOS-challenges.
gateway.auth.rateLimit in openclaw.json:
AUTH_RATE_LIMITED-vermeldingen in het Gateway-logboek betekenen dat iemand
aanmeldgegevens probeert te raden; zie het draaiboek voor blootstelling.
Verbindingen vanuit browsers
WebSocket-verbindingen die een browserheaderOrigin bevatten, gebruiken dezelfde
limieten, maar daarbij staat de loopbackvrijstelling altijd uit — een schadelijke pagina in
een lokale browser blijft een niet-vertrouwde client, dus localhost krijgt langs
dit pad geen vrijstelling. Wanneer zo’n verbinding vanaf een loopbackadres binnenkomt, worden de
mislukkingen gekoppeld aan de genormaliseerde paginaoorsprong (bijvoorbeeld
browser-origin:https://evil.example) in plaats van aan het gedeelde loopback-IP-adres,
zodat elke oorsprong een eigen bucket krijgt; vanaf niet-loopbackadressen blijft de sleutel
het IP-adres van de client. Dit is niet configureerbaar.
Webhooks
De HTTP-ingang/hooks heeft een eigen limiet voor mislukkingen: 20 mislukte
authenticaties per 60 seconden per IP-adres van de client, gevolgd door een blokkering van 60 seconden.
Loopback is niet vrijgesteld. Geslaagde hook-authenticatie stelt de teller opnieuw in. Beperkte
verzoeken ontvangen gewone HTTP 429 Too Many Requests met een header Retry-After
(seconden). De limieten liggen vast; als een legitieme integratie deze bereikt,
corrigeer dan de aanmeldgegevens in plaats van steeds agressiever opnieuw te proberen.
Schrijfbewerkingen van het besturingsvlak (vangnet na authenticatie)
Administratieve RPC’s die schrijven (config.apply, config.patch, plugins.install,
plugins.setEnabled, plugins.uninstall, update.run, worktrees.*,
gateway.restart.request, …) worden daarnaast na
autorisatie beperkt: 30 verzoeken per 60 seconden, per methode, per
deviceId+clientIp.
Dit is geen beveiligingsgrens — aanroepers beschikken al over operator.admin — maar
een vangnet dat uit de hand gelopen client- of agentlussen begrenst die kostbare
bewerkingen blijven bestoken. Interactief gebruik bereikt deze limiet nooit; elke methode heeft een eigen bucket, zodat
het in- of uitschakelen van een Plugin niet ten koste gaat van het budget voor configuratieschrijfbewerkingen.
Wanneer de limiet wordt overschreden, mislukt het verzoek met een fout die opnieuw kan worden geprobeerd:
retryAfterMs respecteren. De limiet ligt vast (niet configureerbaar);
buckets verlopen vanzelf en worden door Gateway-onderhoud opgeschoond.
ACP-sessieaanmaak
De ACP-translator beperkt de sessieaanmaak tot 120 nieuwe sessies per venster van 10 seconden per translator-instantie. Bij overschrijding mislukt het verzoek met een fout waarvan het bericht de wachttijd bevat (dit pad heeft geen gestructureerd veldretryAfterMs):
Afkoelperiode voor herstarts
Gateway-herstartverzoeken worden samengevoegd en hanteren vervolgens een afkoelperiode van 30 seconden tussen herstartcycli. Een herstart die tijdens de afkoelperiode wordt aangevraagd, wordt gepland nadat deze is verstreken, in plaats van afgewezen. Dit staat los van de limiet voor het besturingsvlak hierboven:gateway.restart.request verbruikt een budgetpositie van het besturingsvlak en
de resulterende herstart houdt zich aan de afkoelperiode.
Operationele opmerkingen
- Alle begrenzers bevinden zich in het geheugen en gelden per proces; meerdere Gateways delen geen status. Door het Gateway-proces te vervangen, worden de tellers die eigendom zijn van de Gateway gewist (authenticatieblokkeringen, Webhook-beperking, buckets van het besturingsvlak). De afkoelperiode voor herstarts blijft bewust behouden tijdens herstartcycli binnen hetzelfde proces — dat is precies wat deze beperkt — en wordt alleen samen met het proces opnieuw ingesteld. De ACP-sessielimiet behoort toe aan de translator-instantie en wordt opnieuw ingesteld wanneer die instantie opnieuw wordt aangemaakt, niet wanneer de Gateway opnieuw wordt gestart.
- Bucketmaps zijn begrensd (harde limieten voor het aantal vermeldingen plus periodieke opschoning), zodat een stortvloed aan unieke sleutels het geheugengebruik niet onbeperkt kan laten groeien.
- Wanneer een client zich achter een reverse proxy bevindt, is het effectieve IP-adres het vastgestelde IP-adres van de client; zie authenticatie via vertrouwde proxy’s voor hoe proxyheaders worden gevalideerd voordat ze dit kunnen beïnvloeden.
- De signalering voor opnieuw proberen verschilt per oppervlak: Gateway-RPC-begrenzers retourneren
retryable: trueplusretryAfterMs, de Webhook-ingang gebruikt HTTP 429 met een headerRetry-After, en ACP neemt de wachttijd op in het foutbericht. Wacht in alle gevallen gedurende de aangegeven tijd voordat je het opnieuw probeert, in plaats van het onmiddellijk opnieuw te proberen.