Kort sagt: Når serveren sender spam, er der som regel en af tre årsager: et indsmuglet eller misbrugt PHP-script, en postkasse med stjålet adgangskode eller en forkert konfigureret mailserver. Sikr nogle af de ventende mails, læs deres headerlinjer og maillogget, så finder I i de fleste tilfælde kilden. Derefter stoppes afsendelsen, årsagen lukkes, og først derefter anmodes der om fjernelse fra blokeringslister.
Når kunder finder jeres fakturaer i spam-mappen
Det begynder sjældent med en sikkerhedsmeddelelse. Oftest henvender kunder sig, som ikke længere modtager jeres tilbud, eller postkassen fyldes med returmeddelelser på mails, som aldrig nogen har skrevet. Nogle gange spærrer hostingudbyderen afsendelsen og angiver påfaldende mailtrafik som årsag.
For virksomheden har det hurtigt mærkbare følger. Står serverens adresse på en blokeringsliste, afviser andre mailservere også jeres ægte mails: fakturaer, ordrebekræftelser, adgangskodelinks fra shoppen. Domænets omdømme lider, og skaden vokser for hver time, afsendelsen fortsætter.
Spamafsendelse hører til de kendte følger af en kompromittering. Efter PHP2Shell, sårbarhederne CVE-2026-109618 og CVE-2026-109619 med kodeudførelse uden login, er det en grund mere til at se nærmere efter. Et specifikt PHP2Shell-fingerpeg er spam dog ikke; bekræftede indicators of compromise findes ikke. Yderligere generelle tegn beskriver Er jeg allerede kompromitteret?.
Tre typiske årsager, når serveren sender spam
| Årsag | Typisk billede | Hvor I kigger |
|---|---|---|
| Indsmuglet PHP-script | mails uden login, leveret lokalt via sendmail |
headerlinjer, PHP-maillog, nye PHP-filer |
| Misbrugt formular | mails via en kontakt- eller anbefalingsformular til fremmede modtagere | formularens adgangslog, headerlinjer |
| Kapret postkasse | afsendelse med gyldigt login på mailserveren | maillog med loginnavn, loginsteder |
| Åben mailserver | fremmede afsendere bruger jeres server som videresendelse | mailserverens konfiguration, ekstern kontrol |
De to første årsager berører websitet, den tredje mailkontoene, den fjerde serverkonfigurationen. Skelnen er vigtig, fordi modforanstaltningerne er helt forskellige.
Læs mailkøen
På servere med Postfix viser køen, hvad der netop skal sendes. Følgende kommandoer læser kun:
# Vis køens indhold (svarer til mailq)
postqueue -p | tail -30
# Vis headerlinjerne for en enkelt mail (indsæt kø-ID fra listen)
sudo postcat -q -h QUEUE-ID
# Vellykkede logins på mailserveren med brugernavn
sudo grep 'sasl_username=' /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | sort | uniq -c | sort -rn | head
Headerlinjerne afslører ofte allerede kilden. Stammer mailen fra en indlogget postkasse, optræder loginnavnet i maillogget. Hober en enkelt konto sig dér op med logins fra fremmede lande, er denne postkasses adgangskode meget sandsynligt blevet kendt. Blev mailen derimod leveret lokalt, kommer den som regel fra et script på serveren.
Kører der en anden mailserver på jeres server, f.eks. Exim, hedder kommandoerne noget andet, men princippet er det samme: Se køen, læs headerlinjerne, tæl logins i loggen. Ved shared hosting uden shell-adgang beder I hostingudbyderen skriftligt om et udtræk af maillogget og nogle eksempelmails med fuldstændige headerlinjer. Mange hostingudbydere leverer disse oplysninger på forespørgsel, fordi de selv har en interesse i at få afsendelsen stoppet.
Sikr nogle fuldstændige mails, før I standser eller tømmer køen. De er beviser til den senere analyse og til samtaler med hostingudbyder eller operatører af blokeringslister.
Find det ansvarlige PHP-script
Kører afsendelsen via PHP, hjælper PHP's mailkonfiguration. Ifølge PHP-manualen logger mail.log hvert kald af mail()-funktionen med fuld scriptsti, linjenummer, modtager og headerlinjer. mail.add_x_header skriver desuden en headerlinje X-PHP-Originating-Script med bruger-id og filnavn i hver mail.
; I php.ini eller i FPM-poolen, genstart derefter alle workers
mail.add_x_header = On
mail.log = /var/log/php/mail.log
Logfilen skal være skrivbar for PHP-processen. Headerlinjen afslører et filnavn for modtagerne; slå den fra igen efter analysen, hvis I ikke vil have den varigt.
Findes der som afsender en ukendt fil, f.eks. i upload- eller cache-mappen, er det et fingerpeg om en webshell. Hvordan I vurderer sådanne filer, beskriver Genkend og fjern webshells. Er det derimod en kendt kontaktformular, er den sandsynligvis blevet misbrugt, f.eks. fordi modtager eller headerlinjer overtages fra formularindtastninger. Det er en fejl i koden, intet indbrud, men skal rettes lige så hurtigt.
Ikke al spam bruger mail()-funktionen. Skadelig kode kan også opbygge en forbindelse direkte til fremmede mailservere. Så optræder afsendelsen hverken i køen eller i PHP-maillogget, men derimod som udgående forbindelser på port 25. Hvordan I kontrollerer dem, står under Kontrollér en servers udgående forbindelser.
Stop afsendelsen og start rent op igen
Er kilden fundet, følger oprydningen i denne rækkefølge:
- Hold afsendelsen tilbage: Spær den berørte vej, altså deaktivér scriptet, spær postkassen, eller hold køen tilbage. Sikr ventende mails som bevis.
- Luk årsagen: Ved en webshell bringes PHP op på en rettet status (8.5.12, 8.4.27, 8.3.36, 8.2.35 eller bekræftet backport), alle workers genstartes, og websitet renses. Ved en formular rettes koden. Ved en postkasse ændres adgangskoden, og brugerens enhed kontrolleres.
- Søg yderligere spor: Den, der sender spam via en webshell, har ofte oprettet yderligere bagdøre.
- Begræns udgangen: Tillad udgående forbindelser på port 25 kun for mailserveren, ikke for webserverbrugeren.
- Ryd op på blokeringslisterne: Først nu anmodes der hos operatørerne af blokeringslisterne om fjernelse med en kort beskrivelse af, hvad der er rettet.
Kontrollér ved samme lejlighed SPF, DKIM og DMARC for jeres domæne. Disse DNS-poster fastlægger, hvilke servere der må sende i jeres domænes navn, og gør det sværere for fremmede at misbruge jeres afsenderadresse.
Hvordan hjælper PHP SOS konkret?
- Vi analyserer kø, headerlinjer og maillogs og finder ud af, om script, formular, postkasse eller konfiguration er årsagen.
- Vi stopper afsendelsen kontrolleret og sikrer beviser til hostingudbyder og blokeringslister.
- Vi renser websitet som led i malwarefjernelsen og lukker indgangen.
- Vi begrænser udgående mailtrafik på serverniveau og ledsager fjernelsen fra blokeringslister.
Ofte stillede spørgsmål
Hvordan opdager jeg, at min server sender spam?
Typisk er returmeddelelser på mails, som ingen har skrevet, henvendelser fra hostingudbyderen, en fyldt mailkø og kunder, der pludselig finder jeres mails i spam-mappen. Også poster for jeres serveradresse på offentlige blokeringslister er et tydeligt tegn.
Hvordan finder jeg det PHP-script, der sender spam?
PHP kan logge hvert kald af mail()-funktionen med scriptsti, hvis mail.log er sat. Med mail.add_x_header skriver PHP desuden scriptnavnet i hovedet på hver mail. I allerede afsendte eller ventende mails hjælper et kig i headerlinjerne.
Skal jeg tømme mailkøen med det samme?
Ikke før I har sikret nogle mails som bevis. Headerlinjerne viser ofte, hvilket script eller hvilken postkasse der har udløst afsendelsen. At holde tilbage er som regel bedre end at slette, indtil kilden er kendt.
Hvordan kommer jeg af blokeringslisterne igen?
Fjern først årsagen, og anmod derefter hos de pågældende blokeringslisters operatører om fjernelse. De fleste kræver en forklaring af, hvad der er rettet. Den, der anmoder for tidligt og fortsat sender spam, bliver opført igen.