DDoS (Gedistribueerde denial of service) en DoS (Weigering van service) aanvallen kunnen grofweg in drie categorieën worden ingedeeld, afhankelijk van de lagen van het OSI-model waarop zij zijn gericht: Netwerk laag (Laag 3), transporlaag (Laag 4), en toepassingslaag (Laag 7).

Laag 3 en Laag 4 aanvallen zijn meestal minder complex–hoewel ze misschien erg moeilijk te mitigeren zijn–en omvatten het overspoelen van het netwerk en de transportlaag met verkeer, waardoor de middelen van het doelsysteem overbelast raken en het onbeschikbaar wordt voor legitieme gebruikers. Dit soort aanvallen kan worden uitgevoerd met verschillende technieken zoals ICMP-floods, TCP SYN-floods, of UDP-floods.

Een ICMP-flood bijvoorbeeld, is een Laag 3 aanval waarbij een groot aantal ICMP-pakketten naar het doelsysteem wordt gestuurd, waardoor het niet meer reageert. Een TCP SYN-flood, aan de andere kant, is een laag 4 aanval die misbruik maakt van de manier waarop TCP-verbindingen tot stand worden gebracht.

Bij een SYN-flood-aanval, stuurt de aanvaller veel SYN-pakketten naar het doelsysteem, maar stuurt nooit een ACK-pakket om de verbinding te voltooien. Dit veroorzaakt dat het systeem middelen toewijst voor elke verbinding poging, wat uiteindelijk het systeem overbelast en het onbeschikbaar maakt voor legitieme gebruikers. Een UDP-flood stuurt een groot aantal UDP-pakketten naar een doelsysteem, waardoor de middelen ervan worden gebruikt en het niet meer reageert.

DDoS-aanvallen op de applicatielaag

Applicatielaag-aanvallen zijn complexer en moeilijker te verhelpen dan laag 3 en laag 4 aanvallen. Deze aanvallen richten zich op de applicatielaag (laag 7) van het doelsysteem en maken misbruik van kwetsbaarheden in de applicatie zelf. Laag 7 aanvallen kunnen meer schade aanrichten omdat ze direct invloed kunnen hebben op applicaties en onderliggende infrastructuur. Je zult laag 7 DDoS-aanvallen met laag 3 of laag 4 tools zoals met netwerkfirewalls.

HTTP-flutingen, Slowloris-aanvallen, en DNS-amplificatie-aanvallen zijn Laag 7 denial-of-service-aanvallen. Deze aanvallen vereisen verfijndere verdedigingsmaatregelen zoals applicatie-laag firewalls, intrusion prevention systemen, en CDN (content delivery netwerken).

HTTP-flutingen

HTTP-flutingsaanvallen worden uitgevoerd met GET- of POST-verzoeken om de doelserver te overweldigen. Flood-aanvallen met GET-verzoeken zijn meestal eenvoudiger en vereisen minder middelen omdat ze alleen om informatie van de server vragen. POST-verzoeken, aan de andere kant, vereisen doorgaans het verzenden van grote hoeveelheden gegevens.

One of the reasons HTTP flood attacks are difficult to mitigate is that they are often launched from a large number of sources, making it difficult to identify and block all malicious traffic. Additionally, attackers can use techniques such as IP spoofing to disguise their true identities and make it even more difficult to trace the source of their attacks.

Defending against HTTP flood attacks can be complicated. Different types of attacks require different mitigation strategies. Common defenses against HTTP flood attacks include rate limiting, blacklisting, and web application firewalls. Echter, these techniques can be resource-intensive and may not be sufficient to thwart more sophisticated attacks.

Slowloris-aanvallen

Slowloris is a type of flooding attack in which the way web servers handle client connections is targeted. Deze aanval werkt door een groot aantal verbindingen met de server te openen, maar de verzoeken langzaam te verzenden, elke verbinding zo lang mogelijk open te houden. Dit type aanval kan alle beschikbare bronnen van de server verbruiken en stelt aanvallers in staat om CPU, geheugen, of netwerkbandbreedte, enz.. te verbruiken zonder zelfs de typische snelheidslimieten en verkeersfiltermechanismen te activeren die gewoonlijk worden gebruikt om andere soorten DDoS-aanvallen te detecteren en te blokkeren.

Om een Slowloris-aanval uit te voeren, gebruiken aanvallers meestal scripts of tools die HTTP-verzoeken naar een server sturen, maar opzettelijk het verzenden van volgende verzoeken vertragen. Het verzoek is ontworpen om eruit te zien als een legitiem verzoek, maar met een onvolledige header die de verbinding voor onbepaalde tijd open houdt. In de loop van de tijd, de server zal veel open verbindingen hebben die wachten op extra gegevens van de cliënt, waardoor de server stopt met reageren op legitiem verkeer.

Slowloris-aanvallen kunnen moeilijk te detecteren zijn vanwege hun verborgen ontwerp en relatief lage bandbreedte. Dit maakt het een effectief hulpmiddel voor aanvallers die hun servers willen saboteren zonder waarschuwingen te activeren of achterdocht te wekken. Om zich te verdedigen tegen Slowloris-aanvallen, kunnen webservers verschillende tegenmaatregelen implementeren. Bijvoorbeeld, beperk het aantal verbindingen die vanaf één IP-adres kunnen worden opgezet of stel een time-out in voor onvolledige verzoeken. Sommige webapplicatie-firewalls en DDoS-mitigatiediensten hebben ingebouwde bescherming tegen Slowloris-aanvallen, met gebruik van algoritmen die dergelijk verkeer in real-time kunnen detecteren en blokkeren.

Laag 7 DDoS-mitigaties

Snelheidslimitering

Rate limiting houdt in dat er een drempel wordt ingesteld voor het aantal aanvragen dat kan worden gedaan vanaf een specifiek IP-adres of gebruikersagent in een specifieke periode. Het concept is zeer vergelijkbaar met rate limiting op laag 3 maar het moet worden geïmplementeerd op laag 7.

Het doel van rate limiting is te voorkomen dat een aanvaller de webapplicatie overbelast met een groot aantal aanvragen, waardoor serverstoringen ontstaan. Rate limiting kan worden geïmplementeerd op verschillende lagen van de architectuur van uw webapplicatie, op een webserver, load balancer, of applicatiefirewall. Implementaties houden doorgaans in dat het aantal aanvragen door een bepaald IP-adres of gebruikersagent wordt bijgehouden en verdere aanvragen worden geblokkeerd zodra een vooraf gedefinieerde drempel is bereikt.

A common approach for implementing rate limiting in web applications is to use middle-ware or plugins that track the number of requests made by each client and block further requests when the threshold is exceeded. is to These plugins can be configured to apply different rate limiting policies based on factors such as the type of request, user agent, or client IP address.

Bijvoorbeeld, a simple rate limiting policy can limit requests from a single IP address to a maximum of 10 requests per minute. If a client exceeds this threshold, subsequent requests are blocked until the period expires.

Application-layer rate limiting products are available for popular web servers and cloud services, including:

Apache

Apache has several modules that can be used for rate limiting, such as mod_limitipconn, wat het aantal gelijktijdige verbindingen vanaf een bepaald IP-adres beperkt, en mod_qos, dat verschillende kwaliteitscontrolefuncties biedt, waaronder snelheidsbeperking.

Verder, ModSecurity Web Application Firewall heeft een functie voor snelheidsbeperking die clients kan blokkeren die een gedefinieerde drempel overschrijden. Naast de hierboven genoemde modules, biedt Apache ook mod_evasive. Dit is een module die gebruikt kan worden om clients te beperken en te blokkeren die een gedefinieerde drempel overschrijden. Detecteer en blokkeer kwaadaardige clients met behulp van verschillende technieken, inclusief IP- en user-agent-tracking.

Nginx

Nginx biedt ngx_http_limit_req-module. Dit kan worden gebruikt om het verzoektempo van bepaalde clients te beperken op basis van IP-adres of andere factoren. Deze module gebruikt een tokenbucket-algoritme om tokens toe te wijzen aan elke client op basis van een snelheidsbeperkingsbeleid. Naast de ngx_http_limit_req-module, Biedt Nginx ook de ngx_http_limit_conn-module. Deze kan worden gebruikt om het aantal verbindingen van specifieke clients of IP-adressen te beperken. Deze module gebruikt een tokenbucket-algoritme om tokens toe te wijzen op basis van snelheidsbeperkingsbeleid.

IIS

Microsoft’s Internet Information Services (IIS) bevat een dynamische IP-beperkingsmodule die kan worden gebruikt voor snelheidsbeperking. Deze module kan worden geconfigureerd om verzoeken van IP-adressen die vooraf gedefinieerde drempels overschrijden te blokkeren en kan ook waarschuwingen en logs voor monitoring bieden. Naast de Dynamic IP Limiting-module, IIS biedt ook een Request Filtering-module die kan worden gebruikt om het verzoektempo van specifieke klanten te beperken op basis van verschillende criteria, zoals IP-adres, user agent, en verzoekmethode.

AWS

Amazon Web Services (AWS) biedt verschillende diensten die kunnen worden gebruikt voor rate limiting, including AWS WAF met rate limiting als functie.

AWS Shield biedt DDoS-bescherming inclusief regels op basis van rate die verzoeken van IP-adressen boven een bepaalde drempel kunnen blokkeren. Naast AWS WAF en AWS Shield, biedt AWS ook AWS Elastic Load Balancer. Het bevat verschillende rate limiting-beleidsregels die kunnen worden geconfigureerd om klanten boven vooraf gedefinieerde drempels te blokkeren.

Azure

Microsoft Azure biedt verschillende diensten die kunnen worden gebruikt voor rate limiting, inclusief Azure Application Gateways. Het bevat een webapplicatie-firewall die kan worden geconfigureerd om het tempo van inkomende verzoeken te beperken. Additionally, Azure Front Door biedt een functie voor het beperken van het aantal verzoeken die verzoeken van IP-adressen boven een vooraf gedefinieerde drempel kan blokkeren. Naast Azure Application Gateway en Azure Front Door, biedt Azure ook Azure Firewall. Dit kan worden gebruikt om het tempo te beperken en cliënten die een gedefinieerde drempel overschrijden te blokkeren.

GCP

Google Cloud Platform (GCP) biedt Cloud Armor, een webapplicatie-firewall met functies voor het beperken van het aantal verzoeken die verzoeken van cliënten kan blokkeren die een gedefinieerde drempel overschrijden.

Deze producten voor het beperken van het aantal verzoeken op applicatielaag kunnen effectief HTTP-floodaanvallen beperken door het aantal verzoeken van kwaadaardige cliënten te beperken. Echter, het is belangrijk dat ze correct zijn geconfigureerd zodat legitiem verkeer niet wordt geblokkeerd en in combinatie met andere beveiligingsmaatregelen zoals firewalls en DDoS-mitigatiediensten worden gebruikt om volledige bescherming tegen DDoS-aanvallen te bieden.

Time-outs voor onvolledige verzoeken

Hieronder staan enkele Slowloris-mitigatiemethoden op applicatielaag die worden vermeld voor Apache, Nginx, en IIS-webservers, en load-balancers en aanvullende functies voor AWS, Azure, en GCP-diensten:

Apache

Naast de hierboven genoemde modules, Apache biedt ook een module, mod_reqtimeout, die kan worden gebruikt om een time-out voor binnenkomende verzoeken in te stellen. Als de client een verzoek indient dat langer duurt dan de opgegeven time-out, zal de server de verbinding sluiten. Dit zal Slowloris-aanvallen voorkomen.

Nginx

Naast de ngx_http_limit_conn-module en de ngx_http_limit_req-module, biedt Nginx ook zijn ngx_http_request-module. Dit kan worden gebruikt om de tijd te beperken die de upstream-server nodig heeft om het verzoek te verwerken. Als de upstream-server er langer over doet dan de opgegeven time-out, Nginx zal de verbinding sluiten.

IIS

Aanvullend op de modules Dynamische IP-beperkingen en verzoekfiltering, IIS biedt ook een stuurprogramma voor de kernelmodus HTTP.sys. Hiermee kunt u een time-out instellen voor inkomende verzoeken. Als de client een verzoek indient dat langer duurt dan de opgegeven time-out, zal de server de verbinding sluiten.

AWS

Naast AWS WAF en AWS Shield, AWS geeft bovendien Elastic Load Balancer, die tal van time-outregels voor verbindingen bevat die kunnen worden geconfigureerd om verbindingen te sluiten die langer duren dan een vooraf gedefinieerde drempel.

Azure

Naast Azure Application Gateway en Azure Front Door, Azure geeft bovendien Azure Load Balancer, die een configureerbare time-outkarakteristiek voor inactiviteit bevat die kan worden gebruikt om verbindingen te sluiten die mogelijk gedurende een vooraf gedefinieerde periode inactief zijn.

GCP

Google Cloud Platform (GCP) biedt tal van alternatieven voor time-out van verbindingen voor zijn diensten, waaronder Cloud Load Balancing, dat een configureerbare time-outfunctie bevat die kan worden gebruikt om verbindingen te sluiten die langer duren dan een vooraf bepaalde drempel.

Conclusie

Samenvattend, DDoS- en DoS-aanvallen kunnen worden geclassificeerd op basis van de lagen van het OSI-model waarop ze gericht zijn, zoals de netwerklaag (Laag 3), transporlaag (Laag 4), en toepassingslaag (Laag 7).

Terwijl laag 3 en laag 4 aanvallen de netwerk- en transportlagen overspoelen met verkeer, laag 7 aanvallen zijn complexer en maken gebruik van kwetsbaarheden in de applicaties zelf. HTTP-floods en Slowloris-aanvallen zijn voorbeelden van laag 7 denial-of-service-aanvallen. Tegenmaatregelen tegen deze aanvallen omvatten snelheidsbeperkingen, blacklisting, and web application firewalls. Het identificeren en inperken van aanvallen in realtime vereist een uitgebreide, meerlaagse verdedigingsstrategie die monitoring, detectie, en reactiemogelijkheden omvat.

Additionally, Aanvallers kunnen hun technieken aanpassen en hun aanvallen afstemmen om detectie en beveiligingsmaatregelen te omzeilen. Daarom, Het is van groot belang dat organisaties een uitgebreide, meerlaagse verdedigingsstrategie die monitoring, detectie, en responsmogelijkheden implementeren om aanvallen in real-time snel te identificeren en in te dammen. Dit kan het gebruik van geavanceerde machine learning-algoritmen en gedragsanalyses omvatten om kwaadaardige verkeerspatronen te detecteren en te blokkeren.