DDoS (distribueret denial of service) og DoS (Denial of Service) angreb kan groft klassificeres i tre kategorier baseret på lagene i OSI-modellen, de er målrettet mod: Netværkslag (Lag 3), transportlag (Lag 4), og applikationslag (Lag 7).

Lag 3 og lag 4 angreb er typisk mindre komplekse–selvom de kan være meget udfordrende at afbøde–og involverer oversvømmelse af netværks- og transportlaget med trafik, overbelastning af mål systemets ressourcer og gøre det utilgængeligt for legitime brugere. Disse typer angreb kan udføres ved hjælp af forskellige teknikker såsom ICMP-flod, TCP SYN-flod, eller UDP-flod.

Et ICMP-flod for eksempel, er et lag 3 angreb hvori et stort antal ICMP-pakker oversvømmer mål systemet, gør det uresponsivt. Et TCP SYN-flod, på den anden side, er et lag 4 angreb som udnytter måden TCP-forbindelser etableres på.

I et SYN-flod-angreb, sender angriberen mange SYN-pakker til mål systemet, men sender aldrig en ACK-pakke for at fuldføre forbindelsen. Dette får systemet til at tildele ressourcer til hver forbindelsesforsøg, hvilket til sidst overbelaster systemet og gør det utilgængeligt for legitime brugere. En UDP-flood sender et stort antal UDP-pakker til et målrettet system, hvilket bruger dets ressourcer og gør det uresponsivt.

DDoS-angreb på applikationslag

Angreb på applikationslaget er mere komplekse og sværere at afbøde end angreb på lag 3 og lag 4 angreb. Disse angreb retter sig mod applikationslaget (lag 7) i det målrettede system og udnytter sårbarheder i selve applikationen. Lag 7 angreb kan forårsage mere skade, fordi de kan påvirke applikationer og underliggende infrastruktur direkte. Du vil ikke være i stand til at afbøde lag 7 DDoS-angreb med lag 3 eller lag 4 værktøjer som f.eks. netværksfirewalls.

HTTP-floods, Slowloris-angreb, og DNS-forstærkningsangreb er lag 7 tjenestenægtelsesangreb. Disse angreb kræver mere sofistikerede forsvar såsom applikationslag-firewalls, intrusionsforebyggelsessystemer, og CDN (indholdsleveringsnetværk).

HTTP-floods

HTTP-floodangreb udføres ved hjælp af GET- eller POST-forespørgsler for at overvælde målserveren. Floodangreb med GET-forespørgsler er normalt enklere og kræver færre ressourcer, fordi de kun beder om information fra serveren. POST-forespørgsler, på den anden side, kræver typisk at sende store mængder data.

En af grundene til, at HTTP-floodangreb er svære at imødegå, er, at de ofte lanceres fra mange kilder, hvilket gør det svært at identificere og blokere al ondsindet trafik. Desuden, angribere kan bruge teknikker som IP-spoofing til at skjule deres sande identitet og gøre det endnu sværere at spore kilden til deres angreb.

At forsvare mod HTTP-flood angreb kan være kompliceret. Forskellige typer angreb kræver forskellige afbødningsstrategier. Almindelige forsvar mod HTTP-flood angreb inkluderer hastighedsbegrænsning, sortlistning, og webapplikations-firewalls. Dog, disse teknikker kan være ressourcekrævende og er muligvis ikke tilstrækkelige til at afværge mere sofistikerede angreb.

Slowloris-angreb

Slowloris er en type flooding-angreb, hvor måden webservere håndterer klientforbindelser på bliver målrettet. Dette angreb fungerer ved at åbne et stort antal forbindelser til serveren, men sende anmodningerne i et langsomt tempo, holde hver forbindelse åben så længe som muligt. This type of attack can consume all available resources of the server and allows attackers to consume CPU, memory, or network bandwidth, osv. without even triggering the typical rate limiting and traffic filtering mechanisms commonly used to detect and block other types of DDoS attacks.

To carry out a Slowloris attack, attackers typically use scripts or tools that send HTTP requests to a server, but deliberately delay sending subsequent requests. The request is designed to look like a legitimate request, but with an incomplete header that keeps the connection open indefinitely. Over time, the server will have many open connections waiting for additional data from the client, causing the server to stop responding to legitimate traffic.

Slowloris-angreb kan være svære at opdage på grund af deres skjulte design og relativt lave båndbredde.. Dette gør det til et effektivt værktøj for angribere, der ønsker at sabotere deres servere uden at udløse advarsler eller skabe mistanke. For at forsvare sig mod Slowloris-angreb, kan webservere implementere flere modforanstaltninger.. For eksempel, begrænse antallet af forbindelser, der kan etableres fra en enkelt IP-adresse, eller sætte en timeout for ufuldstændige forespørgsler.. Nogle webapplikations-firewalls og DDoS-afhjælpningstjenester har indbygget beskyttelse mod Slowloris-angreb., ved hjælp af algoritmer, der kan opdage og blokere sådan trafik i realtid..

Lag 7 DDoS-afhjælpning

Hastighedsbegrænsning

Ratebegrænsning involverer at sætte en grænse for antallet af forespørgsler, der kan foretages fra en specifik IP-adresse eller brugeragent inden for en bestemt periode. Konceptet er meget lig ratebegrænsning på lag 3 men det skal implementeres på lag 7.

Formålet med ratebegrænsning er at forhindre en angriber i at overbelaste webapplikationen med et stort antal forespørgsler, hvilket kan forårsage serverforstyrrelser. Ratebegrænsning kan implementeres på forskellige lag af din webapplikationsarkitektur, på en webserver, load balancer, eller applikationsfirewall. Implementeringer involverer typisk overvågning af antallet af forespørgsler foretaget af en bestemt IP-adresse eller brugeragent og blokering af yderligere forespørgsler, når en foruddefineret grænse er nået.

En almindelig tilgang til at implementere hastighedsbegrænsning i webapplikationer er at bruge middleware eller plugins, der sporer antallet af anmodninger lavet af hver klient og blokerer yderligere anmodninger, når tærsklen overskrides. er at disse plugins kan konfigureres til at anvende forskellige politikker for hastighedsbegrænsning baseret på faktorer såsom typen af anmodning, brugeragent, eller klientens IP-adresse.

For eksempel, en simpel politik for hastighedsbegrænsning kan begrænse anmodninger fra en enkelt IP-adresse til maksimalt 10 anmodninger pr. minut. Hvis en klient overskrider denne tærskel, blokeres efterfølgende anmodninger, indtil perioden udløber.

Produkter til hastighedsbegrænsning på applikationslaget er tilgængelige for populære webservere og cloud-tjenester, inklusive:

Apache

Apache har flere moduler, der kan bruges til hastighedsbegrænsning, såsom mod_limitipconn, som begrænser antallet af samtidige forbindelser fra en given IP-adresse, og mod_qos, som giver forskellige servicekvalitetskontroller, herunder hastighedsbegrænsning.

Desuden, ModSecurity Web Application Firewall har en hastighedsbegrænsende funktion, der kan blokere klienter, der overskrider en defineret tærskel. Ud over de moduler, der er nævnt ovenfor, Apache giver også mod_evasive. Dette er et modul, der kan bruges til at hastighedsbegrænse og blokere klienter, der overskrider en defineret tærskel. Registrer og bloker useriøse klienter ved hjælp af en række forskellige teknikker, herunder IP- og brugeragentsporing.

Nginx

Nginx leverer ngx_http_limit_req modul. Dette kan bruges til at begrænse anmodningsraten fra visse klienter baseret på IP-adresse eller andre faktorer. Denne modul bruger en token bucket-algoritme til at tildele tokens til hver klient baseret på en ratebegrænsningspolitik. Udover ngx_http_limit_req-modulet, Tilbyder Nginx også ngx_http_limit_conn-modulet. Dette kan bruges til at begrænse antallet af forbindelser fra specifikke klienter eller IP-adresser. Denne modul bruger en token bucket-algoritme til at tildele tokens baseret på ratebegrænsningspolitikker.

IIS

Microsofts Internet Information Services (IIS) inkluderer en dynamisk IP-begrænsningsmodul der kan bruges til ratebegrænsning. Denne modul kan konfigureres til at blokere anmodninger fra IP-adresser, der overskrider foruddefinerede grænser, og kan også give advarsler og logs til overvågning. Udover det Dynamiske IP-begrænsningsmodul, IIS leverer også et Request Filtering-modul, der kan bruges til at begrænse anmodningshastigheden for specifikke klienter baseret på forskellige kriterier såsom IP-adresse, brugeragent, og anmodningsmetode.

AWS

Amazon Web Services (AWS) tilbyder flere tjenester, der kan bruges til hastighedsbegrænsning, inklusive AWS WAF med hastighedsbegrænsning som en funktion.

AWS Shield tilbyder DDoS-beskyttelse, herunder hastighedsbaserede regler, der kan blokere anmodninger fra IP-adresser over en vis tærskel. Tillæg til AWS WAF og AWS Shield, AWS tilbyder også AWS Elastic Load Balancer. Den indeholder forskellige hastighedsbegrænsningspolitikker, der kan konfigureres til at blokere klienter over foruddefinerede tærskler.

Azure

Microsoft Azure tilbyder flere tjenester, der kan bruges til hastighedsbegrænsning, herunder Azure Application Gateways. Den indeholder en firewall for webprogrammer, der kan konfigureres til at begrænse antallet af indgående anmodninger. Desuden, Azure Front Door tilbyder en hastighedsbegrænsningsfunktion der kan blokere anmodninger fra IP-adresser over en foruddefineret tærskel. Ud over Azure Application Gateway og Azure Front Door, Azure tilbyder også Azure Firewall. Dette kan bruges til at begrænse hastigheden og blokere klienter, der overskrider en defineret tærskel.

GCP

Google Cloud Platform (GCP) tilbyder Cloud Armor, en webapplikationsfirewall med hastighedsbegrænsende funktioner, der kan blokere anmodninger fra klienter, der overskrider en defineret tærskel.

Disse applikationslagshastighedsbegrænsende produkter kan effektivt afbøde HTTP-oversvømmelsesangreb ved at begrænse antallet af anmodninger fra useriøse klienter. Dog, det er vigtigt, at de er korrekt konfigureret for ikke at blokere legitim trafik og bruges sammen med andre sikkerhedsforanstaltninger såsom firewalls og DDoS-mitigationstjenester for at give omfattende beskyttelse mod DDoS-angreb.

Timeouts for ufuldstændige forespørgsler

Nedenfor er nogle Slowloris-applikationslags-mitigationsmetoder, som er angivet for Apache, Nginx, og IIS-webservere, og load-balancere samt yderligere funktioner for AWS, Azure, og GCP-tjenester:

Apache

Ud over de moduler, der er nævnt ovenfor, Apache tilbyder også et modul, mod_reqtimeout, som kan bruges til at sætte en timeout for indkommende forespørgsler. Hvis klienten sender en forespørgsel, der tager længere tid end den angivne timeout, lukker serveren forbindelsen. Dette vil forhindre slowloris-angreb.

Nginx

Udover ngx_http_limit_conn-modulet og ngx_http_limit_req-modulet, tilbyder Nginx også hans ngx_http_request-modul. Dette kan bruges til at begrænse den tid, det tager for den upstream-server at behandle forespørgslen. Hvis den upstream-server tager længere tid end den angivne timeout, lukker Nginx forbindelsen.

IIS

Ud over Dynamic IP Restrictions- og Request Filtering-modulerne, Tilbyder IIS også en kernemode-driver HTTP.sys. Dette giver dig mulighed for at indstille en timeout for indkommende forespørgsler. Hvis klienten sender en forespørgsel, der tager længere tid end den angivne timeout, lukker serveren forbindelsen.

AWS

Ud over AWS WAF og AWS Shield, AWS giver desuden Elastic Load Balancer, som indeholder adskillige regler for forbindelsestimer, der kan konfigureres til at lukke forbindelser, der tager længere tid end en foruddefineret grænse.

Azure

Ud over Azure Application Gateway og Azure Front Door, Azure giver desuden Azure Load Balancer, som indeholder en konfigurerbar idle timeout-funktion, der kan bruges til at lukke forbindelser, som er inaktive i en foruddefineret periode.

GCP

Google Cloud Platform (GCP) giver adskillige alternativer til timeout-forbindelse for sine tjenester, som inkluderer Cloud Load Balancing, som indeholder en konfigurerbar timeout-karakteristik, der kan bruges til at lukke forbindelser, der tager længere tid end en foruddefineret tærskel.

Konklusion

Afslutningsvis, DDoS- og DoS-angreb kan klassificeres baseret på de lag i OSI-modellen, de er rettet mod, såsom netværkslaget (Lag 3), transportlag (Lag 4), og applikationslag (Lag 7).

Mens lag 3 og lag 4 angreb oversvømmer netværket og transportlagene med trafik, lag 7 angreb er mere komplekse og udnytter sårbarheder i selve applikationerne. HTTP-oversvømmelser og Slowloris-angreb er eksempler på lag 7 tjenestenægtelsesangreb. Modforanstaltninger mod disse angreb omfatter hastighedsbegrænsning, sortlistning, og webapplikations-firewalls. Identifikation og inddæmning af angreb i realtid kræver en omfattende, flerlags forsvarsstrategi, der inkluderer overvågning, detektion, og reaktionsmuligheder.

Desuden, angribere kan tilpasse deres teknikker og skræddersy deres angreb for at undgå opdagelse og undgå sikkerhedsforanstaltninger. Derfor, det er bydende nødvendigt, at organisationer implementerer en omfattende, flerlags forsvarsstrategi, der inkluderer overvågning, detektion, og responsfunktioner for hurtigt at identificere og inddæmme angreb i realtid. Dette kan omfatte brug af avancerede maskinlæringsalgoritmer og adfærdsanalyser til at opdage og blokere ondsindede trafikmønstre.