Zo stuur je bots naar de strafbank

Liam Crilly

Liam Crilly is Director of Product Management bij NGINX, F5 Networks

Bij connected experiences zoals websites of applicaties zijn een goede responstijd en schaalbaarheid cruciaal. Maar zelfs vandaag de dag - nu rekenkracht dankzij de elastische cloud in realtime naar wens uitgebreid kan worden - is het vaak nog moeilijk om hoge performances te garanderen wanneer menselijke kliks vervangen worden door toenaderingspogingen door bots. Hoe kun je hier het beste mee omgaan? 

Bots zijn natuurlijk geen nieuw fenomeen. De eerste bots doken rond 1988 op binnen Internet Relay Chat (IRC). Binnen slechts enkele jaren werden ze een integraal onderdeel van het internet, omdat zoekmachines ze inzetten om websites te indexeren. In 1995 nam AOL de applicatie WebCrawler in gebruik en in 1996 creëerde Google zijn search bot, die oorspronkelijk BackRub heette. Maar ook in de begindagen waren er al bots die niet direct het algemeen belang dienden. Sub7 en Pretty Park bijvoorbeeld, respectievelijk een Trojaans paard en een worm, zijn in 1999 in IRC losgelaten, met als doel om zichzelf in het geheim te installeren op machines die waren aangesloten op een specifiek IRC-kanaal en vervolgens te luisteren naar de opdrachten die via die verbinding verstuurd werden.

Botnets

Terwijl de bot-code steeds geavanceerder werd, werd de toepassing van sommige bots steeds gehaaider. De code werd soms geïnstalleerd in software of aangeboden als applicatie (zoals GTbot). Hackers verbonden bots met elkaar en creëerden zo ‘botnets’ die als een entiteit konden worden bestuurd en op specifieke netwerkbronnen konden worden gericht, zodat deze door de vele nepverzoeken onbenaderbaar werden voor ander verkeer. In 2007 infecteerde een van de grootste botnets, Storm, ongeveer 50 miljoen computers en baande daarmee de weg voor verschillende misdaden, zoals fraude met aandelenkoersen en identiteitsdiefstal. En je kunt niet over bots en botnets praten zonder de meest gehate geautomatiseerde bot-activiteit te vermelden: spam. In 2009 werd botnet Cutwail gebruikt om 74 miljard e-mails per dag te versturen. 

Net als bij mensen geldt ook bij bots dat er goede en slechte zijn. En hun ‘karakter’ wordt bepaald door de manier waarop ze worden gebruikt; immers, bots zijn gewoon slimme programma's die repetitieve taken automatiseren. Wanneer bots gebruikt worden om websites uit te lezen ten behoeve van zoekmachines, zijn ze natuurlijk enorm nuttig. Anders zou je namelijk handmatig website na website moeten bezoeken om alle pagina's te indexeren en in een database op te nemen zodat je ze kunt doorzoeken. Of het web raadplegen zonder zoekmachine. 

Onbedoeld schadelijk

Maar waarschijnlijk kun je je ook wel voorstellen dat sommige bots niet ontwikkeld zijn om schade te berokkenen, maar dat wel doen. Bijvoorbeeld bots die gegevens van webpagina’s scrapen, oftewel kopiëren. De bot heeft niet tot doel de website die hij ‘scrapet’ uit de lucht te halen, maar verbruikt bij zijn actie wel zodanig veel resources dat de responsiviteit en de schaalbaarheid voor menselijke gebruikers aanzienlijk slechter worden. Een ander voorbeeld: als een website of app is ontworpen om flexibel te schalen, bijvoorbeeld door automatisch resources aan te spreken bij een cloud service als Amazon Web Services, kan een bot die webpagina’s kopieert en daarmee de snelheid eruit haalt financieel gezien negatieve impact hebben. 

Internetproviders, content delivery-netwerken en IT-afdelingen hebben verschillende acties ondernomen om de invloed van bots te beperken. Zo zijn er netwerkoperators die het bot-verkeer detecteren en proberen lam te leggen door bijvoorbeeld 400 antwoorden terug te sturen op verzoeken om resources. Maar veel bots zullen zich hierdoor niet laten afschrikken, en zullen bijvoorbeeld in realtime van IP-adres wisselen om de blokkade te omzeilen. Doorgaans is weerstand dan ook zinloos als het om bots gaat. Bots zullen altijd een manier vinden om de benodigde resources aan te spreken, en daarmee de eindgebruiker benadelen. 

Bandbreedtebeperking

Hoewel er geen oplossingen zijn die bot-verkeer 100% kunnen tegenhouden, zijn er wel degelijk maatregelen die de ongemakken enorm kunnen beperken, bijvoorbeeld bandbreedtebeperking. Veel netwerkoperators onderwerpen bots aan rate limiting, hetgeen inhoudt dat bepaald wordt dat slechts een bepaald aantal aanvragen vanuit een specifiek IP-adres mag komen. Maar bots reageren daarop door andere mogelijkheden in te zetten om bij de gewenste resources te komen. Rate limiting – feitelijk dus ‘snelheidsbeperking’ - wordt helaas heel gemakkelijk gedetecteerd door bots. Beter is het om aan bandbreedtebeperking te doen, een strategie die veel lastiger te detecteren is. 

Bandbreedtebeperking houdt in dat bots gewoon heel weinig ruimte krijgen om ‘door de lijn‘ te komen, ongeacht hoeveel verzoeken ze doen. In dit scenario wordt het IP-adres waar het bot-verkeer vandaan komt als het ware naar de strafbank verbannen. De bot kan zoveel aanvragen indienen als hij wil, maar hij ontvangt een veel langzamere reactie dan gewoonlijk. 

De British Library is een goed praktijkvoorbeeld van hoe NGINX druk bot-verkeer weet af te weren. De British Library handelt 11 miljoen browser requests per dag af, en zo’n 7.000 zoekopdrachten per uur. De organisatie was zich ervan bewust dat er een oplossing nodig was voor het toenemende spider-, crawler- en ander bot-verkeer, dat meer dan 10% van de totale website-aanvragen voor zijn rekening nam. NGINX kwam met een oplossing om de impact van bot-verkeer te verminderen en de ervaring van menselijke bezoekers te optimaliseren. 

Drie componenten

Bandbreedtebeperking is overigens slechts een gedeelte van de NGINX-oplossing voor het beheersen van bot-verkeer. De twee andere componenten zijn monitoring en synchronisatie. Met de monitoring-component kunnen NGINX-gebruikers zien wie er op de strafbank zit en hoeveel aanvragen en IP-adressen in quarantaine zijn geplaatst. Het doorzoeken van logbestanden behoort daarmee tot het verleden. 

En de derde component, gegevenssynchronisatie, geeft de NGINX-gebruiker extra slagkracht in de strijd tegen bots. Het bot-verkeer op NGINX-installaties dat in quarantaine geplaatst is, wordt namelijk gedeeld met alle andere NGINX-gebruikers, waardoor het een wereldwijd anti-botnet ontstaat. Waarmee het bot-probleem proactief aangepakt wordt in plaats van achteraf. 

Het bot-probleem zal waarschijnlijk steeds uitdagender worden. Maar in plaats van een probleem proberen op te lossen dat eigenlijk niet op te lossen is, kunnen DevOps en netwerkbeheerders beter naar oplossingen kijken als bandbreedtebeperking, en daarmee de ervaring van hun menselijke gebruikers optimaliseren.