HTTP DoS aanval herkennen in webserverlogs

Een http dos aanval is een poging om een website of webapplicatie onbruikbaar traag te maken door HTTP-verzoeken te sturen die servercapaciteit, databasekracht of applicatielogica uitputten.

Een opvallend punt: zo’n aanval heeft niet altijd miljoenen pakketjes per seconde nodig. Een reeks van enkele honderden zware zoekopdrachten per minuut kan meer schade doen dan duizenden simpele aanvragen voor een klein plaatje, omdat de applicatie bij elke zoekopdracht meerdere lagen moet aanspreken.

Dit artikel legt uit hoe HTTP-gerichte overbelasting verschilt van gewone drukte, welke verzoeken het meeste kosten en welke sporen je terugziet in webserverlogs. Ook leer je welke maatregelen op applicatieniveau helpen, zodat je sneller het verschil ziet tussen populair verkeer en misbruik.

Wat maakt HTTP-misbruik anders dan gewone drukte?

HTTP-misbruik richt zich op het werk dat een webapplicatie per verzoek moet doen, terwijl gewone drukte meestal een logisch patroon volgt. Bij normale pieken stijgen paginaweergaven, statische bestanden en gebruikersacties vaak samen. Tijdens een HTTP DoS-aanval zie je juist één duur pad of één functie telkens terugkomen.

Een productpagina die plots duizenden keren per minuut wordt geladen, kan nog beheersbaar zijn als caching werkt. Een zoekpagina die enkele honderden keren per minuut draait met brede filters kan daarentegen databaseprocessen blokkeren. Daardoor telt niet alleen het aantal verzoeken, maar vooral de kosten per verzoek.

Het bredere verschil tussen dos en ddos aanvallen draait om bron en schaal; de technische basis daarvan staat in de uitleg over beschikbaarheidsaanvallen. Dit artikel zoomt smaller in op HTTP-verzoeken, webserverlogs en applicatielaagbelasting.

Praktische vuistregel: behandel één endpoint als verdacht wanneer het normaal maar een klein deel van je paginatypes vormt, maar tijdens een incident een groot deel van alle 5xx-fouten veroorzaakt.

Netwerkvolume tegenover applicatielaagbelasting

Netwerkvolume meet hoeveel verkeer je verbinding, firewall of load balancer bereikt. Applicatielaagbelasting meet hoeveel werk je webserver, runtime, database en externe koppelingen uitvoeren. Een simpele homepage kost soms enkele tientallen milliseconden, terwijl een rapportpagina meerdere seconden kan vragen.

Bij een klassieke volumepiek raakt de lijn vol of stijgt packet loss. Bij applicatielaagmisbruik blijft de bandbreedte soms relatief laag, maar CPU, geheugen of databasewachtrijen lopen op. Juist dat maakt een http dos aanval lastig te herkennen zonder goede logs.

Welke webverzoeken belasten server en applicatie het meest?

De zwaarste webverzoeken activeren vaak zoekfuncties, loginlogica, rapportages, winkelmandjes, uploadroutes of pagina’s zonder cache. Elk verzoek kan meerdere databasequeries, sessiecontroles en externe API-calls starten. Daardoor kan een klein aantal slimme aanvragen veel meer schade veroorzaken dan groot maar simpel verkeer.

Een herkenbaar scenario is een webshop met faceted search. Eén zoekopdracht op “alle producten”, gecombineerd met meerdere filters en sortering op populariteit, kan tientallen databasebewerkingen starten. Als een script dit herhaaldelijk per minuut doet, ontstaat vertraging zonder dat de access logs extreem groot lijken.

• Loginpogingen met wisselende gebruikersnamen en hetzelfde wachtwoordpatroon.
• Zoekopdrachten met lege termen, brede datumbereiken of veel filters.
• Herhaalde aanvragen voor rapporten, exports of PDF-generatie.
• Pagina’s met winkelmandjes, prijsberekening of voorraadchecks.
• POST-verzoeken met grote bodies, uploads of complexe formulierdata.
• Endpoints die cache omzeilen door unieke querystrings.

Let op: een klein verzoek kan duurder zijn dan een grotere download als het verzoek een trage query of externe controle start.

Verdachte HTTP-verzoeken lijken soms op normaal gebruik. Toch verraden ze zich door tempo, herhaling en gebrek aan menselijke variatie. Een echte bezoeker vraagt meestal HTML, CSS, scripts en afbeeldingen op; een aanval raakt vaak alleen het dure endpoint.

Waarom weinig zware verzoeken toch grote vertraging geven

Een webapplicatie werkt als een keten. De browser vraagt iets op, de webserver stuurt het door, de applicatie voert logica uit en de database levert data. Zodra één schakel volloopt, wachten alle andere verzoeken langer.

Neem een loginroute die per poging merkbare rekentijd aan wachtwoordhashing doet. Bij veel gelijktijdige pogingen kan dat veel rekentijd per ronde opleveren. Voeg daar sessieopslag en rate-limitcontroles aan toe, en gewone gebruikers merken vertraging bij het aanmelden.

Ook zoekfuncties veroorzaken vaak wachttijd. Een zoekopdracht zonder limiet kan duizenden records scannen, zeker wanneer indexen ontbreken. Daarom horen trage query’s, wachtrijen en 499-, 500-, 502- of 504-fouten altijd samen onderzocht te worden.

Welke DoS-patronen zie je bij een HTTP-aanval in webserverlogs?

Webserverlogs tonen HTTP DoS-patronen vooral via herhaling, timing, statuscodes, user-agents, querystrings en responstijden. Eén signaal bewijst zelden een aanval. Een combinatie van hoge responstijd, veel dezelfde endpoints en onnatuurlijk gedrag geeft veel sterkere aanwijzingen.

Een praktijkbeeld: tijdens gewone drukte zie je verspreide routes, zoals homepage, categoriepagina’s, afbeeldingen en API-calls. Tijdens applicatielaagmisbruik zie je bijvoorbeeld duizenden aanvragen op één zoekendpoint in korte tijd, met telkens andere querystrings maar hetzelfde gedrag. Logregels met responstijden van meerdere seconden verdienen dan direct aandacht.

Herkenbare HTTP DoS-logpatronen en eerste controles

Logsignaal	Mogelijke betekenis	Waarom verdacht	Eerste controle
Veel GET /zoeken	Zoekmisbruik	Hoge querytijd	Trage queries
Veel POST /login	Credential stuffing	Weinig sessievariatie	Foutcodes 401/403
Unieke querystrings	Cache-omzeiling	Geen cachehit	Cachelogs
Veel 499 of 504	Timeouts	Afgebroken verzoeken	Upstreamtijd
Zelfde user-agent	Scriptverkeer	Laag gedragspatroon	IP-spreiding
Pieken per seconde	Automatisering	Te regelmatig	Tijdstempels

Welke velden moet je samen bekijken?

Een access logregel geeft meestal methode, pad, statuscode, bytes, referrer, user-agent en soms verwerkingstijd. Voeg waar mogelijk upstream response time, request ID en cachestatus toe. Met een beperkt aantal goed gekozen velden kun je vaak al onderscheid maken tussen drukte en misbruik.

Een verdacht patroon ontstaat bijvoorbeeld wanneer een groot deel van de trage verzoeken naar één endpoint gaat. Ook valt op wanneer dezelfde route vooral POST-verzoeken krijgt zonder normale navigatie ervoor. Bij gespoofte of wisselende broninformatie helpt de uitleg over misleidende bronadressen om logging met meer nuance te beoordelen.

Een HTTP-aanval valt niet op door herrie op de lijn, maar door duur werk op de verkeerde plek.

Let bovendien op statuscodes per pad. Veel 200-codes kunnen alsnog verdacht zijn, omdat de server het dure werk succesvol uitvoert. Veel 429-codes tonen juist dat een limiter actief ingrijpt, terwijl 502 en 504 vaak wijzen op overbelaste achterliggende diensten.

Hoe loopt een aanval van botnet tot downtime?

Een HTTP-gerichte aanval verloopt vaak in stappen: verkenning, selectie van dure endpoints, geautomatiseerde herhaling en uiteindelijk vertraging of uitval. De aanval hoeft niet groot te beginnen. Vaak test de aanvaller eerst welke URL’s traag reageren.

Een botnet kan daarna vanaf honderden apparaten kleine aantallen verzoeken sturen. Als veel apparaten elk enkele dure aanvragen per minuut doen, lijkt elk afzonderlijk IP-adres redelijk rustig. Samen leveren ze al snel veel dure applicatieacties per minuut op, precies op het zwakste onderdeel.

De stroom ziet er in woorden zo uit: geïnfecteerde apparaten sturen HTTP-verzoeken, de load balancer laat ze door, de webserver opent workers, de applicatie start databasewerk en gebruikers wachten op vrije capaciteit. Zodra wachtrijen vollopen, stijgen responstijden van subsecondes naar meerdere seconden of meer.

Een netwerk van geïnfecteerde apparaten maakt herkomstanalyse moeilijker, omdat verzoeken van veel adressen komen. Toch blijven applicatiepatronen vaak herkenbaar. Dezelfde route, dezelfde volgorde en hetzelfde tempo zeggen meer dan één los IP-adres.

DoS versus DDoS bij HTTP-verkeer

Een DoS-aanval komt uit één of enkele bronnen, terwijl een DDoS-aanval veel bronnen gebruikt. Bij HTTP-verkeer kan het effect vergelijkbaar lijken, omdat beide vormen dezelfde dure functies raken. Het onderscheid helpt vooral bij blokkeren, forensisch onderzoek en capaciteitsplanning.

Verschillen tussen DoS en DDoS bij HTTP-gerichte overbelasting

Kenmerk	DoS via HTTP	DDoS via HTTP
Bronnen	1 tot enkele	Tientallen tot duizenden
Blokkeren	Relatief direct	Moeilijker per IP
Logbeeld	Herhaalde bron	Verspreide bronnen
Typische focus	Eén zwakke route	Meerdere routes mogelijk
Eerste reactie	Rate limit per bron	Gedragsregels per endpoint

Netwerklaagaanvallen werken anders. Een ICMP flood of UDP-piek probeert vooral capaciteit van netwerkapparatuur en verbindingen te vullen. Wie specifiek de udp betekenis bij ddos wil begrijpen, kan daarvoor UDP bij DDoS aanvallen begrijpelijk uitgelegd lezen; hier blijft de focus op HTTP en applicatielogica.

Welke maatregelen helpen tegen trage of dure verzoeken?

Bescherming tegen schadelijke HTTP-verzoeken werkt het best in lagen: beperk tempo, maak dure functies goedkoper, cache veilige antwoorden en monitor afwijkend gedrag. Eén filter lost zelden alles op. Goede maatregelen combineren technische drempels met duidelijke afspraken voor beheer en communicatie.

Begin bij endpoints die veel schade kunnen doen. Zet limieten op login, zoeken, export, rapportage en API-routes. Een limiet van bijvoorbeeld 10 loginpogingen per minuut per account en per IP-adres voorkomt geen complete aanval, maar verkleint wel de belasting en maakt misbruik zichtbaarder.

Rate limiting moet slim genoeg zijn om echte gebruikers niet onnodig te raken. Gebruik daarom combinaties van IP-adres, sessie, account, user-agent en route. Bij publieke API’s helpt een aparte limiet per sleutel, bijvoorbeeld 60 verzoeken per minuut voor normale acties en lager voor dure exports.

Veelgemaakte fout: teams blokkeren alleen IP-adressen en vergeten het endpoint zelf. Bij verspreid verkeer blijft de dure route dan open, ook als honderden adressen slechts 1 of 2 verzoeken per minuut sturen.

Technische maatregelen tegen DoS via HTTP-aanvallen

Maak dure acties voorspelbaar goedkoper. Beperk zoekresultaten tot bijvoorbeeld 50 of 100 items per pagina, stel timeouts in op trage queries en gebruik indexen voor velden waarop vaak wordt gefilterd. Ook helpt het om exports in een wachtrij te plaatsen in plaats van direct te genereren.

Cache kan veel druk wegnemen, maar cache helpt alleen bij veilige en herhaalbare antwoorden. Unieke querystrings kunnen caching omzeilen, dus normaliseer parameters waar dat veilig kan. Verwijder overbodige trackingparameters uit cachebeslissingen en blokkeer extreem lange querystrings.

Bij verdachte invoer moet je niet alleen aan beschikbaarheid denken. Zware HTTP-verzoeken kunnen ook samenhangen met misbruik van invoervelden, zoals onverwachte tekens of extreem lange parameters. Valideer invoer daarom vroeg, kort en streng.

Bestuurlijke acties die techniek ondersteunen

Een technische maatregel werkt beter met duidelijke eigenaars. Wijs vooraf aan wie loganalyse doet, wie firewallregels mag wijzigen en wie klanten informeert. Tijdens een incident kosten 15 minuten overleg vaak meer dan een vooraf vastgelegde beslisregel.

Leg ook drempelwaarden vast. Denk aan een alarm bij 3 keer normale responstijd gedurende 5 minuten, of bij meer dan 20% 5xx-fouten op één route. Zulke grenzen hoeven niet perfect te zijn, maar ze versnellen de eerste reactie.

Wat moet je doen als je een http dos aanval vermoedt?

Bij een vermoedelijke HTTP DoS-aanval moet je eerst schade beperken, daarna bewijs veiligstellen en pas daarna fijnmazig optimaliseren. Snel blokkeren zonder logkopie kan nuttige sporen wissen. Te lang analyseren zonder limiet kan juist de beschikbaarheid verder aantasten.

1. Noteer het tijdvenster waarin responstijden, foutcodes of klachten begonnen.
2. Filter logs op de langzaamste endpoints en sorteer op verwerkingstijd.
3. Vergelijk bron-IP’s, sessies, user-agents en querystrings per verdacht pad.
4. Zet een tijdelijke rate limit op het duurste endpoint of de zwaarste methode.
5. Schakel veilige caching in voor herhaalbare GET-verzoeken zonder privédata.
6. Blokkeer extreem lange parameters, lege zoekopdrachten en ongeldige methodes.
7. Leg de genomen maatregelen vast met tijdstip, regel en zichtbaar effect.

Een concreet rekenvoorbeeld helpt bij triage. Stel dat /zoeken normaal 200 milliseconden kost en tijdens een http dos aanval 4.000 milliseconden per verzoek. Bij 150 verzoeken per minuut vraagt die route dan ongeveer 600 seconden verwerking per minuut, dus 10 volledige serverseconden per echte seconde.

Deze rekensom toont waarom een kleine piek groot effect heeft. Als je applicatie 8 gelijktijdige workers heeft, ontstaat direct een wachtrij. Gewone pagina’s lijken dan ook traag, terwijl de oorzaak bij één duur endpoint ligt.

Voor voorbereiding buiten dit incidenttype, zoals monitoring, contactlijsten en besluitvorming, biedt een breder stappenplan houvast. Houd in dit onderzoek wel de focus op HTTP-logpatronen en applicatieroutes.

Conclusie: http dos aanval herkennen vraagt om kijken naar werk, niet alleen verkeer

Een http dos aanval herken je door te kijken naar de kosten per verzoek, niet alleen naar bandbreedte of aantallen bezoekers. Vooral loginroutes, zoekfuncties, rapportages en cache-omzeilende querystrings kunnen een website vertragen met relatief weinig verkeer.

De sterkste signalen staan vaak al in webserverlogs: herhaalde dure endpoints, hoge responstijden, opvallende statuscodes en onnatuurlijke patronen in user-agents of parameters. Combineer die signalen met applicatiemetrics, zodat je ziet waar wachtrijen ontstaan.

Goede bescherming begint bij limieten, caching, invoervalidatie, timeouts en duidelijke beheerafspraken. Wie deze maatregelen vooraf klaarzet, verkort de tijd tussen eerste vertraging en gerichte ingreep.

In onze ervaring draait de beste eerste beslissing niet om de vraag of iets “zeker een aanval” is. We kijken eerst welk endpoint de meeste schade veroorzaakt en zetten daar tijdelijk druk van af. Daarna volgt pas de fijnere analyse van bronnen en intentie, het team van Virus.NL.

Veelgestelde vragen

Deze korte antwoorden helpen bij snelle herkenning, triage en eerste bescherming tijdens een verdacht HTTP-incident.

Wat is een HTTP DoS-aanval?

Een HTTP DoS-aanval is een aanval waarbij HTTP-verzoeken een website of webapplicatie vertragen of onbereikbaar maken. De aanvaller richt zich op functies die veel rekentijd, databasewerk of sessieverwerking vragen. Daardoor kan een beperkt aantal verzoeken toch grote impact hebben.

Waarom kan een klein aantal zware verzoeken toch grote vertraging veroorzaken?

Een klein aantal zware verzoeken kan veel vertraging veroorzaken omdat elk verzoek meerdere systemen activeert. Denk aan wachtwoordcontrole, zoekindexen, databasefilters, voorraadchecks of PDF-generatie. Als die taken seconden duren, raken workers en wachtrijen snel vol.

Welke patronen zie je in webserverlogs bij applicatielaagmisbruik?

Bij applicatielaagmisbruik zie je vaak veel verzoeken naar één route, hoge responstijden, unieke querystrings en opvallende statuscodes zoals 429, 499, 502 of 504. Ook valt verkeer op dat geen normale browservolgorde volgt, bijvoorbeeld wel loginposts maar geen voorafgaande paginaweergaven.

Welke bescherming helpt tegen schadelijke HTTP-verzoeken?

Bescherming tegen schadelijke HTTP-verzoeken bestaat uit rate limiting, caching, invoervalidatie, querytimeouts en limieten op dure functies. Monitor daarnaast responstijd per endpoint. Zo grijp je gericht in wanneer één route de applicatie zwaarder belast dan normaal.

Is een HTTP DoS-aanval hetzelfde als een DDoS-aanval?

Een HTTP DoS-aanval beschrijft vooral de methode en de laag: HTTP-verzoeken tegen de applicatie. Een DDoS-aanval beschrijft vooral de herkomst: veel verspreide bronnen. Een http dos aanval kan dus zowel uit één bron als uit veel bronnen komen.

Wil je je voorbereiding breder maken dan loganalyse alleen, werk dan met een vast plan voor monitoring, rollen en noodmaatregelen. Bij een http dos aanval helpt zo’n plan om sneller te beslissen wie ingrijpt, welke route tijdelijk wordt beperkt en welke logs je veiligstelt.