In de moderne API-architectuur is rate-limit een cruciale techniek om de stabiliteit en veiligheid van systemen te waarborgen. Zonder effectieve rate-limiting kunnen API’s overbelast raken, wat leidt tot verminderde prestaties en mogelijke uitval van diensten.
Orks en White Walkers
Wat nu weer? Orks en White Walkers? Yes, hackers met kwade bedoelingen vergelijk ik graag met deze twee vijanden. Ze hebben, naast het feit dat ze lelijk zijn, een goede vergelijking met elkaar: ze komen graag met ontzettend veel en het liefst tegelijk. Na het lezen van mijn blog snap je de metafoor en ben je er van overtuigd dat we meer security maatregelen moeten treffen dan enkel rate-limit. Maar let op, rate-limit maakt het hackers wel lastiger met minimale effort!
Disclaimer: deze blog gaat niet in op API trottling.
The battle of Helm’s Deep
In de film The Lord of the Rings: The Two Towers wordt er gevochten voor de poort van Helm’s Deep tussen mensen en Orks. Hoe kunnen we de verdediging van Helm’s Deep vergelijken met rate-limit? Waarom lijken de Orks op de hackers van tegenwoordig? Daar kom je nu achter…
Voorafgaand aan het gevecht zie je een groot leger van Orks van zo’n 1000 voetbalvelden groot in de stromende regen wachten op het teken om aan te vallen. De grote hoeveelheden Orks symboliseren de grote getallen aanvallen die een hacker in zeer korte tijd kan uitvoeren.
Helm’s Deep heeft maar één toegangspoort die via een smalle oversteek te bereiken is. Hierdoor worden de aanvallen als een soort trechter geminimaliseerd. Het effect van de trechter past mooi in het effect van rate-limit. Door een maximum aantal requests per seconden in te stellen, is het niet mogelijk om op grote schaal aan te vallen.
Na verloop van tijd lukt het de Orks toch door de eerste verdediging heen te komen. Ze ontdekten een vulnerability in de afwatering/riool van het fort waarmee de verdedigingsmuur doorbroken werd. We moeten dus meer maatregelen treffen dan enkel rate-limit.
Gelukkig worden onze helden geholpen door “levende geesten” 🙂 .
The Wall in Winterfell
Heb je de serie Game Of Thrones gezien? Ja? Dan ken je de White Walkers wel en ook zeker de imposante muur in het noorden van de Seven Kingdoms. Heb je hem niet gezien? Geen probleem ook hier spreekt de vergelijking boekdelen.
The Wall is een imposante hoge, 482.8 kilometers lange en sterke muur met als doel om de White Walkers tegen te houden. Ook hier maak ik een vergelijking tussen de White Walkers en hackers. De muur heeft maar één ingang in de vorm van een lange tunnel door de muur. Het idee van een trechter, lees rate-limit, is weer van toepassing. Grote getallen van White Walkers worden terug gebracht naar een minimale verkeersstroom.
Helaas voor de mensheid heeft de Night King de beschikking over draak Viserion en schiet enkel rate-limit weer te kort. Maar de rate-limit heeft 8000 jaar stand gehouden (van horen zeggen)!
ACTIE: rate-limit toepassen op alle API’s
Het doel van de twee bovenstaande voorbeelden zijn inmiddels duidelijk: pas rate-limit toe op alle bestaande en nieuwe API’s. Waarom zou je rate-limit niet toepassen? Het is eenvoudig en effectief. Ik ga je, in dit stukje van mijn blog, vertellen hoe je rate-limit het beste kan configureren binnen Azure API Management (APIM).
Het effect en noodzaak (belangrijk)
Voordat we policy’s gaan toepassen nog eerst even de nut en noodzaak. De aanvallen van de Orks en White Walkers symboliseren brute force, zoals DDOS, en web scraper aanvallen. Het zijn aanvallen die op grote schaal ingezet kunnen worden en het kost de hacker weinig moeite. Sterker nog, jij kant het ook.
Het effect? Zodra de rate-limit bereikt is ontvangt de consumer, waarschijnlijk de hacker, een 429 Too Many Requests response status code. Het doet hopelijk iets met de motivatie van een hacker… Hopelijk is belangrijk in deze context, het kan een hacker ook motiveren en daarom zijn extra lagen van security noodzakelijk.
Scope van de policy bepalen
We weten inmiddels dat we rate-limit willen toepassen op alle, dus ook toekomstige/nieuwe, API’s. We zullen dus een policy moeten toepassen op het hoogste niveau binnen APIM.
- Selecteer links in de blade “APIs“;
- Selecteer “All APIs” waarmee de design mogelijkheden zichtbaar worden;
- Klik op het code icoontje “</>” waarmee we policy’s op het hoogste niveau kunnen toepassen.
Hieronder de drietal acties weergegeven binnen de Azure portal | API Management.
Rate-limit policy op het juiste moment toepassen
In mijn blogpost over kwetsbare API’s ging ik kort in op de vier momenten waarin we een API call kunnen controleren. De rate-limit policy moeten we enkel toepassen op de inbound sectie van de API request. Zie hieronder de code die je direct kan toevoegen aan de xml code waarmee de policy’s geconfigureerd kunnen worden.
<policies>
<inbound>
<rate-limit-by-key calls="500" renewal-period="5" />
</inbound>
<backend>
</backend>
<outbound />
<on-error />
</policies>In het voorbeeld hierboven worden alle requests boven de 500 binnen 5 seconden tegen gehouden. Dit is wel het minste wat we moeten doen om aanvallen op grote schaal tegen te gaan.
Binnen enterprise omgevingen, waar het normaal is dat er veel API verkeer is, pas ik rate-limit toe op basis van IP-adressen. De inbound regel ziet er dan als volgt uit: “<rate-limit-by-key calls=”500″ renewal-period=”5” counter-key=”@(context.Request.IpAddress)” />”
Ben je op zoek naar meer controle op het gebied van rate-limit policy’s? Pak dan vooral de Microsoft documentatie erbij en zie welke attributen je nog meer kan toepassen binnen rate-limit.
Tot slot het minste wat je moet doen
Door middel van de twee gevechten tussen de mensheid en Orks/White Walkers heb je gevoel gekregen bij het effect van rate-limit security. Hopelijk ben je gemotiveerd tot het gebruik van rate-limit policy’s. Het effect is ontzettend groot bij een minimale inspanning/configuratie binnen APIM. Voor iedereen die nog geen rate-limit toepast: ga vandaag nog al je API’s beschermen door de extra security maatregel (rate-limit) toe te passen binnen APIM (of een andere API Gateway).
2 Comments