# DDoS eller hackerangreb? Vurdér angreb rigtigt

> DDoS eller hackerangreb? Typiske tegn sammenlignet, første kontrolkommandoer til serveren, og hvad I konkret bør gøre i de første timer.

Kilde: https://phpsos.de/da/ratgeber/ddos-oder-exploit/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Om det er DDoS eller hackerangreb, viser sig på sporene. Et DDoS skaber meget mange forespørgsler og gør websitet langsomt eller utilgængeligt, men ændrer intet. En exploit kræver ofte kun få forespørgsler og efterlader nye filer, konti, processer eller forbindelser. Den rigtige vurdering afgør, om I skal afværge belastning eller inddæmme en hændelse.

## Forskellen i enkle ord

Et **DDoS-angreb** (Distributed Denial of Service) er som en menneskemængde, der blokerer indgangen til en forretning. Ingen kommer ind, men i butikken bliver intet stjålet. Målet er at overbelaste jeres website eller server, så rigtige kunder ikke længere kommer igennem.

En **exploit** er derimod et indbrud gennem en åben dør. Angriberen udnytter en svaghed, f.eks. i PHP, i CMS'et eller i en udvidelse, til at køre kode på jeres server. Det kan ske stille, uden at websitet bliver langsommere. Følgerne rækker fra spamsider over datatyveri til overtagelse af serveren.

For ledelsen er forskellen afgørende: Et DDoS er et tilgængelighedsproblem, der slutter med angrebet. En vellykket exploit er en sikkerhedshændelse, der består, til den er fundet, ryddet op og dokumenteret.

## DDoS eller hackerangreb: tegnene sammenlignet

Den følgende tabel hjælper ved den første vurdering. Den erstatter ingen analyse, men viser, hvor I bør se først.

| Kendetegn | Snarere DDoS | Snarere exploit eller indbrud |
|---|---|---|
| Tilgængelighed | langsom eller udfaldet | ofte normal |
| Forespørgsler i loggen | meget mange, ofte ensartede | få, målrettede forespørgsler |
| Filer | uændrede | nye eller ændrede PHP-filer |
| Konti | uændrede | nye admins, ændrede adgangskoder |
| Processer | webserver og PHP under fuld belastning | ukendte processer, mining, spamafsendelse |
| Netværk | meget indgående trafik | usædvanlige udgående forbindelser |
| Efter afslutningen | alt som før | spor består |

Vær opmærksom på overlapninger: Massescanning efter en sårbarhed kan ligne et lille DDoS. Netop det var at forvente omkring PHP2Shell, da angribere ledte efter sårbare servere. Høj belastning kan altså også betyde, at nogen netop forsøger at bryde ind.

## Første kontroller på serveren

De følgende kommandoer ændrer intet ved systemet og giver et hurtigt overblik. Sikr ved mistanke om et indbrud logs, før I foretager større indgreb.

```bash
# Belastning og køretid
uptime

# Forbindelser sammenfattet og de hyppigste modparter
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# Hyppigste klientadresser i access-loggen (tilpas stien)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# PHP-filer, der er ændret inden for de sidste 7 dage
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# Processer med den højeste CPU-belastning
ps aux --sort=-%cpu | head -15
```

I forbindelsesoversigten viser den fjerde kolonne modparten. Mange forbindelser fra få adresser eller en stigning til et mangedobbelt af normalværdien peger på overbelastning. Nye PHP-filer i upload- eller cachemapper, processer under webserverens bruger med fremmede navne eller udgående forbindelser til ukendte mål peger snarere på et indbrud. En udførlig liste finder I under [Tegn på kompromittering efter PHP2Shell](https://phpsos.de/da/php2shell/bin-ich-gehackt-anzeichen/).

## Hvorfor høj belastning også kan være et afledningsmanøvre

Det forekommer, at angribere skaber en overbelastning, mens de samtidig bryder målrettet ind. Teamet er så optaget af tilgængeligheden, og de egentlige spor forsvinder i logstøjen. Derfor gælder: Også når et DDoS er åbenlyst, så kontrollér efter dets afslutning filer, konti og udgående forbindelser.

I tilfældet PHP2Shell kommer det til, at der ifølge php.net og sikkerhedsfirmaerne ikke findes offentliggjorte, bekræftede Indicators of Compromise. Opdagelsen bygger på adfærdsanalyse. En server, der i scanningsperioden fra midten af oktober var upatchet, bør derfor kontrolleres uafhængigt af den observerede belastning.

En yderligere variant er afpresningsmails, hvori der trues med et DDoS-angreb, hvis der ikke betales. Gem sådanne meddelelser, betal ikke uden afstemning med fagfolk, og overvej en [anmeldelse til Zentrale Ansprechstelle Cybercrime (tysk politis centrale kontaktpunkt for cyberkriminalitet)](https://phpsos.de/da/compliance/anzeige-polizei-zac/). Underret samtidig jeres hoster, så beskyttelsesforanstaltninger kan forberedes. Hvordan I analyserer logs til det formål, står i vejledningen [Analysér weblogs efter et angreb](https://phpsos.de/da/ratgeber/logfiles-auswerten/).

## Hvad I bør gøre i de første timer

**Ved mistanke om DDoS:**

- Underret hoster eller datacenter; dér findes ofte filtre foran serveren.
- Aktivér eller skærp en foranliggende beskyttelsestjeneste eller en [WAF med virtuel patching](https://phpsos.de/da/leistungen/waf-virtuelles-patching/).
- Sæt rate limits i webserveren, og beskyt dyre sider som søgning eller indkøbskurv særligt.
- Gem logs, så angrebet senere kan spores.

**Ved mistanke om et indbrud:**

- Slet ikke noget, og opsæt ikke serveren på ny, før logs og berørte filer er sikret.
- Opdatér PHP til en rettet version, og genstart alle workere, hvis det ikke allerede er sket.
- Hvis opdateringen ikke er mulig med det samme, så tag websitet midlertidigt af nettet, som BSI anbefaler.
- Forny adgangsdata fra en ren enhed, ikke fra den muligvis berørte server.
- Lad kontrollere, om personoplysninger kan være berørt; så kan anmeldelsesfrister løbe.

I begge tilfælde hjælper en kort, saglig note til hoster og tjenesteudbydere: siden hvornår problemet består, hvilke websites der er berørt, hvad I har observeret, og hvad der allerede er ændret. Notér desuden, hvem der har truffet hvilken beslutning. Denne tidslinje sparer tid i analysen og er senere værdifuld for forsikring, databeskyttelse og intern opfølgning. Er det uklart, om der overhovedet foreligger et angreb, så behandl situationen forsigtigt som en hændelse, til det modsatte er dokumenteret.

## Hvordan hjælper PHP SOS konkret?

- Vi vurderer situationen på afstand ud fra belastning, logs, filer og forbindelser og fortæller jer, hvad I sandsynligvis har med at gøre.
- Ved overbelastning sætter vi filtre, rate limits og foranliggende beskyttelsesregler, til angrebet klinger af.
- Ved mistanke om indbrud overtager vi den strukturerede [Incident Response](https://phpsos.de/da/leistungen/incident-response/): sikre, inddæmme, finde årsagen, rydde op.
- Til sidst dokumenterer vi, hvad der er sket, og hvilke foranstaltninger der er gennemført, til hændelsen er afsluttet.


## Ofte stillede spørgsmål

**Kan et DDoS-angreb stjæle data?**  
Et rent DDoS-angreb sigter mod tilgængeligheden, ikke mod data. Det ændrer ingen filer og læser ingen databaser. Det kan dog optræde samtidig med et indbrudsforsøg, derfor betaler et blik på filer og konti sig alligevel.

**Hvordan kan jeg se, at mit website er hacket?**  
Typiske tegn er nye eller ændrede PHP-filer, ukendte admin-konti, omdirigeringer til fremmede sider, uventede udgående forbindelser og processer, der ikke passer til jeres applikation. Et enkelt tegn er intet bevis, flere sammen er et alvorligt signal.

**Hjælper et CDN eller en WAF mod begge angrebstyper?**  
Mod volumenbaserede angreb hjælper en foranliggende tjeneste som regel godt. Mod exploits virker regler kun, hvis de genkender mønstret. Ved PHP2Shell gør Cloudflare selv opmærksom på, at regler alene på grundlag af forespørgselsdata ikke er nok.

**Skal jeg anmelde et DDoS-angreb?**  
Det afhænger af det enkelte tilfælde og af jeres branche. Uden adgang til personoplysninger gælder GDPR-anmeldelsespligten som regel ikke, men branchespecifikke pligter kan bestå. Afklar det med jeres databeskyttelsesansvarlige eller en advokat.

## Kilder

- [BSI (det tyske forbundskontor for informationssikkerhed): lagebillede og anbefalinger](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)