DDoS beskyttelse med Cloudflare: opsætning og tips

Kort svar: Cloudflare beskytter automatisk mod DDoS-angreb på alle planer, også den gratis, men kun for trafik, der går gennem Cloudflare (orange sky). Det vigtigste er derfor at proxy alle webrecords, skjule og låse din servers rigtige IP-adresse, og have rate limiting på login-sider. Under et angreb aktiverer du Under Attack Mode, finder mønstret i Security Analytics og blokerer eller udfordrer trafikken med WAF custom rules.

Fagligt gennemgået: 2. oktober 2026

Bliver dit website pludselig oversvømmet af en enorm mængde trafik, kan det være et DDoS-angreb (Distributed Denial of Service). Sådanne angreb kan gøre websitet utilgængeligt for rigtige brugere og koste både salg og tillid. Ved du, hvordan du forsvarer sitet med Cloudflare, kan du holde det oppe under pres.

Denne guide gennemgår, hvordan DDoS-angreb virker, hvordan du genkender dem, hvordan du sætter Cloudflares beskyttelse rigtigt op, og hvad du gør, når et angreb står på. Har du ikke koblet dit WordPress-site på Cloudflare endnu, så start med Cloudflare-indstillinger til WordPress.

1. Forstå DDoS-angreb, og lær at genkende dem

Hvad er et DDoS-angreb?

Et DDoS-angreb er et forsøg på at forstyrre en server, tjeneste eller et netværk ved at overbelaste det med en flod af trafik. Angrebet sendes fra mange kompromitterede enheder på én gang – computere, servere og ofte IoT-enheder som kameraer og routere.

Hvordan fungerer et DDoS-angreb?

Et DDoS-angreb bruger et netværk af overtagne enheder, et såkaldt botnet. Hver enhed er typisk inficeret med malware og fjernstyres af angriberen.

Enhederne sender store mængder forespørgsler mod målet – et website, en server eller et netværk. Målet er at sende så mange forespørgsler, at systemet ikke kan følge med, så det bliver langsomt eller helt lukker ned for rigtige brugere.

Tænk på det som en stor flok mennesker, der på én gang mases ind i en lille butik. Butikken bliver så fyldt, at de rigtige kunder hverken kan komme ind eller få betjening. På samme måde når legitim trafik ikke frem, fordi vejen er blokeret af ondsindet trafik.

Typer af DDoS-angreb og deres virkninger

DDoS-angreb inddeles typisk i tre typer efter, hvilket lag de rammer. Alle kan gøre et website langsomt eller utilgængeligt.

Volumetriske angreb forsøger at opbruge båndbredden til målet eller mellem målet og resten af internettet.

Eksempel: UDP-flood. Angriberen sender store mængder UDP-pakker (User Datagram Protocol) til tilfældige porte. Serveren tjekker, om et program lytter på porten, og svarer med en ICMP-pakke “Destination Unreachable”, når der ikke gør. Processen bruger serverens ressourcer og kan til sidst gøre den ude af stand til at svare på legitim trafik. Amplification-angreb, hvor små forespørgsler til fx DNS-servere giver store svar sendt mod målet, hører også til denne gruppe.

Protokolangreb opbruger ressourcer i selve serveren eller i udstyr imellem, som firewalls og load balancere.

Eksempel: SYN-flood. Angrebet udnytter håndtrykket, der starter en TCP-forbindelse. Angriberen sender en byge af forbindelsesanmodninger, men fuldfører aldrig håndtrykket. Hver halvåben forbindelse optager ressourcer, indtil serveren ikke kan tage imod flere. Det svarer til gentagne gange at ringe til et nummer og lægge røret på, før samtalen begynder, så linjen hele tiden er optaget.

Angreb på applikationslaget (lag 7) rammer selve webapplikationen. De kræver færre forespørgsler og er sværere at opdage, fordi hver forespørgsel ligner almindelig trafik.

Eksempel: HTTP-flood. Angrebet rammer det lag, hvor serveren genererer websider som svar på HTTP-forespørgsler. Det kan være så simpelt som at genindlæse en side igen og igen eller så komplekst som gentagne søgninger og formularindsendelser. For WordPress er det især dyrt, fordi ucachede sider, søgning, wp-login.php og xmlrpc.php kræver PHP og database ved hver forespørgsel. En HTTP-flood svarer til hundredvis af kunder, der går ind i butikken og hver stiller et kompliceret spørgsmål.

Hvordan genkender du et DDoS-angreb?

Disse tegn tyder på, at dit website kan være under angreb:

• Pludselig stigning i trafikken: en uventet og unormal stigning uden en kampagne eller anden forklaring.
• Trafik fra ensartede kilder: mange forespørgsler fra de samme IP-adresser, IP-områder, lande, netværk (ASN) eller med samme user agent.
• Flere fejl og timeouts: hyppige fejl som 503 Service Unavailable, 504 eller Cloudflare-fejl som 521 og 522, fordi serveren ikke kan følge med.
• Langsom hjemmeside: markant langsommere svartider uden en tilsvarende stigning i rigtige besøgende i din webanalyse.
• Uregelmæssige mønstre: trafikspidser på usædvanlige tidspunkter eller mønstre, der ikke ligner normal brugeradfærd.
• Gentagne hits på samme URL: fx tusindvis af forespørgsler på forsiden, søgesiden, wp-login.php eller xmlrpc.php på kort tid.

Det svære er at skelne angrebstrafik fra legitim trafik. Under en produktlancering eller efter en nyhedsbrevsudsendelse forventer du flere besøgende. Men stiger trafikken markant fra få kilder eller i mønstre, der ikke ligner rigtige brugere, bør du reagere.

DDoS-angreb spænder fra simple angreb fra én kilde til komplekse angreb, der rammer flere lag samtidig. Et effektivt forsvar er derfor lagdelt og tilpasses løbende. For aggressive regler kan blokere rigtige kunder, så reaktionen skal være præcis.

2. Sådan sætter du Cloudflares DDoS-beskyttelse op

Cloudflares DDoS-beskyttelse er slået til automatisk og uden trafikgrænse på alle planer, også den gratis. Den virker dog kun for trafik, der går gennem Cloudflare. Grundopsætningen handler derfor mest om at sikre, at angriberne ikke kan gå udenom.

Vigtigt: Cloudflare flytter jævnligt rundt på menuerne, og det nye dashboard samler mange sikkerhedsindstillinger under Security → Settings. Kan du ikke finde en indstilling under det navn, der står her, så brug søgefeltet i dashboardet.

2.1 Proxy alle webrecords

Gå til DNS → Records, og sørg for, at alle records, der peger på din webserver (A, AAAA og CNAME for roddomænet, www og eventuelle subdomæner), står som Proxied med orange sky. En grå sky betyder, at trafikken går direkte til serveren uden beskyttelse. Mail-records skal dog stå som DNS only. Se hvornår skyen skal være orange eller grå.

2.2 Skjul og lås din servers IP-adresse

Kender angriberen din servers rigtige IP-adresse (origin-IP), kan Cloudflare springes over helt. Typiske læk er en grå record som ftp eller mail, der peger på samme server som websitet, gamle DNS-historikdatabaser fra før du tog Cloudflare i brug, og mails sendt direkte fra webserveren, hvor IP’en står i headeren.

Lås derfor serveren, så den kun tager imod webtrafik fra Cloudflares IP-adresser, som Cloudflare offentliggør på cloudflare.com/ips. Det gøres i serverens firewall eller hos din host. Er IP’en allerede lækket, kan det være nødvendigt at skifte den.

2.3 Find DDoS-indstillingerne

Åbn dit domæne i Cloudflare-dashboardet, og find indstillingerne for DDoS protection under sikkerhedsmenuen. Her ligger HTTP DDoS attack protection, som er Cloudflares administrerede regelsæt for angreb på applikationslaget.

2.4 Opret en DDoS-tilsidesættelse (override)

Standardindstillingerne passer til de fleste sites. Vil du ændre, hvor følsomt regelsættet reagerer, eller hvad der sker med trafikken, klikker du på Deploy a DDoS override under HTTP DDoS attack protection.

2.5 Konfigurer reglerne

Vælg, om tilsidesættelsen skal gælde hele regelsættet eller bestemte regler, og justér sensitivity level og action. Højere følsomhed fanger mere, men øger risikoen for at ramme rigtige brugere. Ret kun i følsomheden, hvis du ser, at angreb slipper igennem, eller at legitim trafik bliver blokeret.

Klik på Save eller Deploy for at aktivere ændringerne.

2.6 Bekræft, at beskyttelsen er aktiv

Når du har gemt, vender Cloudflare tilbage til oversigten over DDoS-beskyttelse. Kontrollér, at din tilsidesættelse står som aktiv, og at reglerne virker efter hensigten.

2.7 Tilføj rate limiting på login-sider

DDoS-reglerne er gode til store angreb, men små, vedvarende angreb mod login-siden slipper ofte under radaren. Opret en rate limiting rule, der begrænser antallet af forespørgsler pr. IP mod /wp-login.php og /xmlrpc.php. Den gratis plan indeholder en enkelt rate limiting-regel, hvilket er nok til at beskytte login-siden. Bruger du ikke XML-RPC, kan du blokere /xmlrpc.php helt med en WAF custom rule. Læs mere i Beskyt WordPress-login mod brute force.

2.8 Overvåg og justér

Beskyttelsen skal justeres i takt med nye trusler og ændringer i din trafik. Kig jævnligt i Security Analytics og Security Events for at se, hvad der bliver blokeret, og om rigtige brugere rammes.

3. Sådan analyserer og afværger du et DDoS-angreb (avanceret)

Dette afsnit er til dig, der står midt i et angreb af mellem til høj kompleksitet. Du behøver ikke være ekspert, men det hjælper at kende Cloudflare-dashboardet. Du lærer at læse angrebets mønster og bygge regler, der stopper det uden at ramme rigtige kunder.

Trin 1: Genkend angrebet

Bliver dit website pludselig langsomt eller utilgængeligt, og ser du usædvanlige trafikspidser, er det sandsynligvis et angreb. Jo hurtigere du opdager det, desto hurtigere kan du reagere. Uptime-overvågning med alarmer hjælper dig med at opdage det, også uden for arbejdstid – se Uptime-overvågning.

Trin 2: Aktivér Under Attack Mode

Aktivér Under Attack Mode fra domænets oversigtsside eller under sikkerhedsindstillingerne. Tilstanden viser en udfordring til alle besøgende, før de får adgang, så automatiseret trafik filtreres fra, mens rigtige browsere typisk kommer igennem efter få sekunder.

OBS: Under Attack Mode udfordrer også maskiner, der skal have adgang: betalings-callbacks, webhooks, API-kald, overvågning og RSS-læsere. Har du en webshop, så opret en WAF-regel, der springer udfordringen over for de stier, din betalingsudbyder kalder, og slå tilstanden fra igen, når angrebet er overstået. Se Bot Fight Mode blokerer betalings-callbacks og overvågning.

Trin 3: Analysér angrebet og formulér et svar

Løser Under Attack Mode problemet, bør sitet hurtigt vende tilbage til normalen. Fortsætter problemerne, eller vil du ikke udfordre alle rigtige brugere, skal du analysere trafikken og lave mere præcise regler.

Analyse af trafikken:

1. Se efter trafikspidser i Analytics: En markant stigning i forespørgsler bekræfter, at der er tale om et angreb.

2. Se, hvor trafikken kommer fra: Kig efter koncentrationer i bestemte lande, netværk (ASN) eller IP-områder under fordelingen af forespørgsler i Analytics.

3. Vurdér forespørgslernes mønster: Hvilke URL’er rammes, er det GET eller POST, hvilken HTTP-version bruges, og går de samme user agents igen?

Byg dine regler ud fra analysen:

• Geografi: Kommer angrebet primært fra lande, du ikke sælger til, kan du udfordre trafik derfra med en managed challenge i stedet for at blokere den helt.
• Kilde og mønster: Udfordr eller bloker de IP-områder eller netværk (ASN), der står for angrebet, eller de konkrete URL’er, der rammes.
• User agent: Bloker forældede eller tydeligt falske user agents, der står for en uforholdsmæssig stor del af trafikken.
• Cache: Rammer angrebet sider, der burde kunne caches, så sørg for, at de faktisk leveres fra cache, og at angriberne ikke kan omgå cachen med tilfældige query-strenge.

Reglerne oprettes som WAF custom rules under sikkerhedsmenuen. Brug handlingen Managed Challenge, når du er i tvivl, og Block, når du er sikker på, at trafikken er ondsindet.

Trin 4: Implementér og overvåg reglerne

• Følg effekten af dine regler i Security Events, hvor du kan se, hvilke forespørgsler der rammer hvilken regel.
• Justér reglerne løbende, efterhånden som angrebet ændrer karakter. Angribere skifter ofte IP-områder og mønstre, når de bliver blokeret.
• Hold øje med, at rigtige kunder ikke rammes – fx ved at teste kurv og checkout fra en almindelig browser.

4. Efter angrebet

Når trafikken er normal igen, så brug et øjeblik på at blive bedre forberedt til næste gang:

• Slå Under Attack Mode fra, så rigtige brugere og callbacks ikke udfordres unødigt.
• Gennemgå dine midlertidige regler, og fjern dem, der kan ramme legitim trafik.
• Tjek, om origin-IP’en er lækket, hvis angrebet ramte serveren direkte uden om Cloudflare.
• Notér forløbet: hvornår det startede, hvad der virkede, og hvem der gjorde hvad. Se Efter nedbruddet: post mortem.
• Lav en plan for næste gang med kontaktpersoner hos host, bureau og betalingsudbyder – se nedbrudsplanen.

Hosting og DDoS-beskyttelse hænger sammen

Cloudflare beskytter kanten, men det, der slipper igennem, skal din server håndtere. En server med effektiv page cache, LiteSpeed og nok ressourcer tåler mere, før den går i knæ, og en host, der kan låse serveren til Cloudflares IP-adresser og hjælpe under et angreb, gør en reel forskel.

Hos Hostious kører WordPress hosting og WooCommerce hosting på LiteSpeed og NVMe på servere i Europa, og du kan bruge Cloudflare foran dit site. Du får daglig og manuel backup med selvbetjent gendannelse og dansk support døgnet rundt, hvis du har brug for hjælp under et angreb.

Læs også

• Hub: Cloudflare til WordPress – alle guides om Cloudflare samlet ét sted
• Cloudflare-indstillinger til WordPress: sikker basisopsætning
• Rigtige besøgende møder captcha eller challenge
• Cloudflare Error 1020: find WAF-reglen, der blokerer
• 429 Too Many Requests – hvorfor serveren siger stop
• WordPress hosting hos Hostious – LiteSpeed, NVMe og dansk support døgnet rundt

Ofte stillede spørgsmål om DDoS-beskyttelse med Cloudflare

Hvad er Cloudflares Under Attack Mode, og hvornår skal jeg bruge den?

Under Attack Mode er en sikkerhedstilstand, der viser en udfordring til alle besøgende, før de får adgang, så automatiseret angrebstrafik filtreres fra. Brug den, når sitet er under et aktivt angreb og bliver langsomt eller utilgængeligt, og slå den fra igen bagefter, da den også kan blokere callbacks og API-kald.

Hvordan kan jeg skelne mellem en legitim trafikstigning og et DDoS-angreb?

En legitim stigning hænger typisk sammen med en kampagne, et nyhedsbrev eller en omtale og kommer fra mange forskellige kilder, der opfører sig som rigtige brugere. Angrebstrafik kommer ofte fra ensartede IP-områder, netværk eller lande, rammer de samme URL’er igen og igen og følger unaturlige mønstre. Cloudflares Analytics og Security Events viser, hvor trafikken kommer fra.

Hvad er de almindelige tegn på et DDoS-angreb?

Pludselig langsomhed eller nedetid, trafikspidser uden forklaring, flere 503- og timeout-fejl, trafik fra ensartede IP-adresser eller regioner og gentagne hits på samme URL på kort tid.

Kan Cloudflare automatisk afværge alle typer DDoS-angreb?

Cloudflare afværger automatisk de fleste angreb, især volumetriske angreb og protokolangreb, for trafik der går gennem netværket. Avancerede angreb på applikationslaget kan kræve egne WAF-regler og rate limiting, og intet hjælper, hvis angriberen kender og rammer din servers IP-adresse direkte.

Hvad gør jeg, hvis siden stadig har problemer bagefter?

Tjek, at alle webrecords er proxied, og at serveren kun tager imod trafik fra Cloudflare. Gennemgå Security Events for mønstre, stram dine WAF-regler og rate limiting, og kontakt din host, så I kan se, om trafikken rammer serveren uden om Cloudflare.