Overvåg filændringer og sårbarheder – opdag angreb i tide

Kort svar: Overvågning er forskellen på at opdage et angreb efter tre timer og efter tre måneder. To spørgsmål skal besvares løbende: „er der ændret filer, som ingen af os har ændret?“ (filintegritet – fx et ugentligt checksum-tjek) og „er der kendte huller i vores plugins?“ (sårbarhedsvarsler – en tjeneste, der matcher din plugin-liste mod sårbarhedsdatabaserne). Begge kan automatiseres på en time – og skal ende som mails, et menneske faktisk læser og handler på.

Fagligt gennemgået: 2. oktober 2026

De fleste kompromitterede WordPress-sites opdages ikke af ejeren, men af Google, en kunde eller en sortliste – ofte uger efter indbruddet. Ikke fordi sporene manglede: filændringerne lå der fra første time. Der var bare ingen, der kiggede.

Denne guide sætter de to kiggeposter op – filintegritet og sårbarhedsvarsler – og supplerer dem med det, filtjek ikke kan se: nye administratorer, mistænkelige planlagte opgaver og advarsler fra Google. Målet er, at opdagelsestiden falder fra måneder til timer, uden at du drukner i alarmer.

Før du ændrer noget: Tag en frisk backup af filer og database, og test nye cron-job og sikkerhedsplugins på staging, hvis du har det. Kør aldrig automatisk „reparation“ eller sletning af fundne filer, før du ved, hvad de er – en fil, der ser fremmed ud, kan være en del af et premium-plugin.

1. Kortlæg, hvad der skal overvåges

Før du vælger værktøj, så gør dig klart, hvor angreb typisk efterlader spor på et WordPress-site:

• WordPress-kernen (wp-admin, wp-includes og rodfilerne) – må aldrig ændres af andre end opdateringer.
• Plugins og temaer – ændres kun ved opdatering eller af jeres udvikler.
• Uploads (wp-content/uploads) – skal indeholde billeder og dokumenter, aldrig PHP-filer.
• mu-plugins – indlæses automatisk og er derfor et yndet gemmested.
• wp-config.php og .htaccess – små filer med stor magt, fx over omdirigeringer.
• Databasen – brugere, indstillinger og indhold, som filtjek slet ikke ser.

Skriv listen ned sammen med, hvem der må ændre hvad. Så ved du ved første alarm, om en ændring var forventet – og hvem du skal spørge.

2. Sæt filintegritet op

Kernen og plugins fra wordpress.org kan sammenlignes med officielle checksums – en slags facitliste over, hvordan hver fil skal se ud i netop din version. Med WP-CLI kører du tjekket sådan:

wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -type f -name "*.php"

Den første kommando melder ændrede kernefiler og filer, der ikke hører hjemme i kernemapperne. Den anden gør det samme for plugins fra wordpress.org-mappen. Den tredje finder PHP-filer i uploads, hvor de ikke har noget at gøre. Kør dem automatisk – fx ugentligt via cron eller hostingens planlagte opgaver – så du får besked i samme uge, noget ændres bag din ryg:

[email protected]
0 6 * * 1 cd /sti/til/sitet && wp core verify-checksums --quiet && wp plugin verify-checksums --all --quiet

Fejler et tjek, returnerer WP-CLI en fejlkode, og cron sender outputtet til adressen i MAILTO. Stien og adressen skal naturligvis tilpasses dit miljø.

To begrænsninger er vigtige at kende. Premium-plugins og egne plugins findes ikke i wordpress.org-mappen og kan derfor ikke checksummes på denne måde. Og temaer dækkes ikke af kommandoerne. Sikkerhedsplugins med filscanning tilbyder bredere dækning, fordi de sammenligner med en kendt tilstand og kigger efter nye filer på de klassiske gemmesteder. Vælg ÉN mekanisme som den primære, så du ikke får dobbelte alarmer – og sørg for, at den også kigger efter nye filer i uploads og mu-plugins. Får du fund, er det oprydningsguidens fase 2, der tager over.

3. Sæt sårbarhedsvarsler op

Når en sårbarhed offentliggøres i et udbredt plugin, begynder automatiseret udnyttelse ofte kort efter – kapløbet står mellem din opdatering og angribernes scannere. Varslingstjenester bygger på sårbarhedsdatabaser som WPScan, Patchstack og Wordfence Intelligence. De matcher din installerede plugin- og temaliste mod databaserne og mailer, NÅR et af DINE plugins rammes. Flere sikkerhedsplugins har funktionen indbygget.

Varsler er kun halvdelen. Den anden halvdel er at lukke hullet hurtigt:

• Automatiske opdateringer på alt ukritisk – WordPress har haft indbygget auto-opdatering af plugins og temaer siden version 5.5.
• Hurtig manuel håndtering af de store og forretningskritiske (WooCommerce, sidebyggere, betalingsmoduler) – test via staging, og opdatér samme dag ved alvorlige huller.
• Oprydning: hvert inaktivt plugin på disken er stadig angrebsflade uden funktion. Slet det, du ikke bruger.

En god opdateringspolitik beskriver, hvad der auto-opdateres, og hvad der testes først – så ingen skal træffe beslutningen fra bunden, når varslet kommer.

4. Overvåg også det, der ikke er filer

Rene database-angreb rører ingen filer: en ny administratorbruger, indsprøjtede links i indlæg eller en ondsindet planlagt opgave. Filintegritet fanger dem ikke, så tilføj tre enkle kontroller:

• Administratorlisten: wp user list --role=administrator viser alle administratorer. Kendte navne og ingen overraskelser er målet – gerne tjekket månedligt eller med en alarm ved nye administratorer.
• Planlagte opgaver: wp cron event list viser WordPress’ planlagte hændelser. Ukendte hook-navne, der ikke hører til dine plugins, skal undersøges.
• Google Search Console: rapporten om sikkerhedsproblemer og mails fra Search Console er ofte det første eksterne tegn på hacket indhold. Sørg for, at sitet er verificeret, og at mailen går til en, der læser den.

Et login-log for administratorer (hvem loggede ind hvornår og hvorfra) gør det desuden muligt at tidsfæste en hændelse bagefter. Sammen med totrinslogin lukker det de fleste veje ind via stjålne adgangskoder.

5. Indfør alarmdisciplin: signal frem for støj

Overvågning dør af støj: femten daglige mails om ingenting læres væk på en uge – og så drukner den ene vigtige. Indstil derfor hårdt:

• Filtjek som ugentlig rapport – og øjeblikkelig alarm KUN ved fund.
• Sårbarhedsvarsler øjeblikkeligt – de kræver altid handling.
• Login-notifikationer kun for administratorer fra nye enheder.
• Alt sendt til en adresse, et navngivet menneske ejer – ikke en gruppepostkasse, ingen tømmer.

Testen er enkel: kan du huske sidste alarm, og gjorde nogen noget ved den? Er svaret nej til det sidste, er indstillingen forkert – enten er alarmen ligegyldig, eller også mangler der en ansvarlig.

6. Reagér, når alarmen går

Hver alarmtype har sin første handling. Tabellen er udgangspunktet – din egen beredskabsplan bør have samme struktur.

Alarm	Første handling	Tidsramme
Sårbarhed i et af dine plugins	Opdatér – eller deaktivér pluginet, til en rettelse findes	Samme dag ved alvorlige huller
Ændret kernefil eller pluginfil	Tjek opdateringslog og tidsstempler: var det en opdatering eller en kollega?	Med det samme
PHP-fil i uploads	Behandl som mulig hændelse; flyt ikke filen, før den er dokumenteret	Med det samme
Ukendt administrator	Fjern rettighederne, skift adgangskoder, gennemgå login-log	Med det samme
Search Console melder hacket indhold	Følg akutguiden, ryd op, anmod om ny gennemgang	Samme dag

Sårbarheder i login-nære eller upload-nære plugins tåler ikke weekendventetid. Ved filfund afgør tidsstempler og opdateringsloggen typisk på minutter, om ændringen er forklarlig. Kan fundet ikke forklares, er det akutguiden og derefter oprydningen. Og uanset udfald: notér hændelsen. Mønstre på tværs af måneder er også signal.

7. Verificér, at overvågningen virker

En overvågning, der aldrig er testet, er et håb. Overvågningen virker, når:

• et kontrolleret testfund fanges – læg selv en harmløs testfil i uploads, og se alarmen komme (og slet filen bagefter);
• sårbarhedstjenesten kender din AKTUELLE plugin-liste, også efter nye installationer;
• rapporterne læses af en navngiven person med en stedfortræder i ferier;
• sidste kvartal viser mindst én håndteret alarm eller en bekræftet stille periode.

Overvågning, 2FA, opdateringer og testet backup er hele kvartetten: forebyg, opdag, begræns og gendan. Mangler én af dem, er de tre andre svagere.

Læs også

• Hub: WordPress sikkerhed og backup
• Malware-oprydning i WordPress trin for trin
• Hacket WordPress hjemmeside: hvad gør du?
• Opdateringspolitik: auto-opdatér det rigtige, test resten
• 9 tegn på at du mangler sikker hosting
• WordPress serviceaftale – løbende vedligeholdelse for 99 kr./md. for sites hostet andre steder, inkluderet i WordPress hosting fra WP StartUp

Ofte stillede spørgsmål om WordPress-overvågning

Er Site Health ikke nok?

Site Health er et øjebliksbillede, du selv skal åbne – overvågning er alarmer, der kommer til dig. Brug begge: Site Health til den månedlige gennemgang, automatikken til alt det, der ikke kan vente på den.

Fanger filovervågning alle hacks?

Nej – rene database-angreb (indsprøjtet indhold, falske brugere) rører ingen filer. Derfor suppleres med gennemgang af brugerlisten og sårbarhedsvarsler; sammen dækker de langt størstedelen af virkelighedens angreb.

Hvem skal have alarmerne på et lille site?

Den, der kan handle på dem – typisk dig selv eller jeres webpartner. Er svaret „ingen har tid“, er administreret vedligeholdelse den ærlige løsning: så bor både overvågningen og reaktionen samme sted.

Kan jeg checksum-tjekke premium-plugins?

Ikke med WP-CLI’s verify-checksums, som kun kender plugins fra wordpress.org-mappen. Premium- og egne plugins dækkes af et sikkerhedsplugin, der sammenligner med en kendt tilstand, eller af versionsstyring, hvor du kan se enhver afvigelse fra den seneste godkendte udgave.

Erstatter hostingens backup behovet for overvågning?

Nej. Backup hjælper dig tilbage, men fortæller ikke, at du er blevet ramt – og opdager du et indbrud sent, kan alle nyere backups være inficerede. Overvågning forkorter tiden til opdagelse, så du kan gendanne fra et rent punkt.