Rense hacket WordPress: fjerning av malware, sikkerhetskopi og herding

Les mer om tjenesten WordPress sikkerhetsrevisjon fra WPPoland.

Denne veiledningen går trinn for trinn gjennom oppryddingen av en infisert WordPress-installasjon. Den bruker kommandolinjeverktøy (SSH, WP-CLI) fordi de er raskere og grundigere enn noen utvidelse. Skannere i form av utvidelser kommer lenger ned, i delen om dokumentasjonen fra WordPress.org.

#Tegn på at WordPress er hacket

Før du begynner å rydde, bekreft at nettstedet faktisk er kompromittert. De vanligste tegnene:

• Uønskede omdirigeringer: Besøkende sendes videre til spam-, apotek- eller kasinosider
• Injisert spaminnhold: Sider med japansk eller kinesisk tekst eller lenker til skadelige nettsteder
• Ukjente administratorbrukere: Nye administratorkontoer du ikke har opprettet
• Nylig endrede filer: Kjerne-, tema- eller utvidelsesfiler endret uten at du vet om det
• Advarsler fra Google: en advarselsetikett i søkeresultatene eller en advarselsside i nettleseren før siden åpnes
• Fall i organisk trafikk: Google har nedgradert nettstedet eller fjernet det fra indeksen
• Utsendt spam-e-post: Serveren din sender uønsket e-post
• Dårligere ytelse: Nettstedet har blitt merkbart tregere

Hvis det første tegnet var japanske sider i Google og ikke noe synlig på nettstedet, har du sannsynligvis den skjulte varianten, som krever et annet første steg. Les om japansk nøkkelord-hack før du sletter noe.

#Hvordan angripere kommer seg inn på et WordPress-nettsted

Skadelige boter tråler nettet etter kjente sårbarheter, prøver administratorpassord med brute force og utnytter feilkonfigurerte servere. For å rydde opp i et nettsted må du først forstå hvordan angriperen fikk tilgang.

#Sårbarheter i utdaterte utvidelser og temaer

Sårbarheter som SQL-injeksjon (SQLi), Local File Inclusion (LFI) og Remote Code Execution (RCE) dukker ofte opp i utdaterte utvidelser. Angripere bruker automatiske verktøy for å finne kjente sårbare versjoner og kjøre koden sin. To klasser sårbarheter er spesielt farlige:

• PHP Object Injection (deserialisering): Oppstår når brukerdata går rett inn i PHP-funksjonen unserialize(). Hvis koden inneholder hjelpeklasser som kan fungere som en “POP chain”, kan angriperen opprette vilkårlige PHP-objekter, kjøre kode og skrive filer til filsystemet.
• Ubegrenset filopplasting: Hvis en utvidelse ikke validerer filer fra egne skjemaer ordentlig (for eksempel sjekker filendelsen bare i nettleseren og ikke på serveren), kan angriperen laste opp et webskall forkledd som bilde, lagre det i /wp-content/uploads/ og kjøre det med en direkte HTTP-forespørsel.

#Svake passord og brute force-angrep

Boter hamrer uten pause på /wp-login.php og /xmlrpc.php med lister over vanlige passord. Bruker administratorkontoen et svakt passord, blir den kompromittert før eller senere.

#Hvordan angripere misbruker xmlrpc.php

Den eldre filen xmlrpc.php lar deg kommunisere med WordPress-API-et via XML. Fordi den støtter multicall-forespørsler, kan en angriper prøve hundrevis av passordkombinasjoner i én enkelt HTTP-forespørsel og omgå de vanlige grensene for innlogging.

#Infeksjon fra andre nettsteder på delt hosting

Ligger nettstedet ditt på en delt server, kan en sårbarhet på naboens nettsted gi angriperen mulighet til å skrive filer i katalogtreet og infisere de rene filene dine.

#Hva WordPress.org anbefaler å gjøre først når et nettsted er hacket

Supportartikkelen fra WordPress.org FAQ My site was hacked behandler den første timen som dokumentasjonsarbeid, ikke opprydding. Det første konkrete steget er å notere hva du ser, når du la merke til det (med tidssone) og hva som nylig ble endret: en ny utvidelse, en temaendring, en endring i en widget. Notatet er grunnlaget for hendelsesrapporten, enten du rydder nettstedet selv eller overlater det til noen andre.

Den samme artikkelen lister opp tegn som peker på et faktisk hack og ikke et utfall: nettstedet står på en svarteliste hos Google eller Bing, vertsleverandøren har deaktivert det, det er merket for å spre skadevare, de besøkendes antivirus blokkerer det, noen melder at det angriper andre nettsteder, eller det dukker opp brukere som ingen har opprettet.

For skanning kombinerer artikkelen skannere på applikasjonsnivå (utvidelsene Wordfence, Sucuri, Quttera og GOTMLS) med eksterne skannere som VirusTotal og Sucuri SiteCheck, fordi hver type rapporterer ulike ting.

Fire punkter fra artikkelen glemmes lett under press:

• Skann din egen datamaskin også. Artikkelen påpeker at mange infeksjoner starter på eierens maskin, der en trojaner fanger opp FTP- og wp-admin-pålogginger. Nye passord skrevet inn på en infisert bærbar PC havner rett hos angriperen.
• Snakk tidlig med vertsleverandøren. På delt hosting kan hacket ramme mer enn ett nettsted, og et nettsted som brukes til å sende spam, kan få serverens IP-adresse inn på e-postsvartelister, noe som rammer e-post sendt fra samme server.
• Installer samme versjon på nytt, og ikke fra wp-admin. Artikkelen fraråder reinstallasjonsvalgene i kontrollpanelet fordi disse installasjonsprogrammene ofte bare overskriver eksisterende filer, mens hack legger til nye filer. Den nevner /wp-admin og /wp-includes som mappene som trygt kan erstattes.
• Bytt passordene to ganger. En gang når du oppdager hacket, og en gang til når nettstedet er bekreftet rent, på alle tilgangspunkter: SFTP, wp-admin, kontrollpanelet hos vertsleverandøren og MySQL. Artikkelen foreslår også å bytte brukernavn og passord for databasen og oppdatere wp-config.php deretter.

Den nevner også filene som fortjener en manuell gjennomgang uansett type infeksjon, fordi en endring i dem påvirker alle forespørsler: .htaccess (i rotmappen og i alle undermapper som har en), index.php og temafilene header.php, footer.php og functions.php.

#Hvordan ta et hacket WordPress offline under oppryddingen

Googles veiledning Quarantine your site anbefaler å ta det hackede nettstedet offline slik at det slutter å levere innhold til brukerne, og å svare med statuskode 503, som signaliserer et midlertidig utfall. For WordPress betyr to detaljer mye:

• Lever 503 fra utenfor det kompromitterte katalogtreet, for eksempel fra konfigurasjonen til webserveren eller proxyen som vertsleverandøren styrer. En vedlikeholdsutvidelse eller en PHP-fil inne i den infiserte installasjonen kjører side om side med skadevaren.
• Et 4xx- eller 5xx-svar alene er ikke nok, fordi “skadelig innhold fortsatt kan leveres til brukere med disse statuskodene” (Google, Quarantine your site, egen oversettelse). En disallow i robots.txt er heller ikke nok: den blokkerer bare søkemotorenes crawlere, ikke de besøkende.

Veiledningen sier at det neppe vil påvirke fremtidig rangering å ta nettstedet midlertidig offline under gjenopprettingen. De to andre stegene samsvarer med WordPress.org: varsle vertsleverandøren, gå gjennom brukerlisten, slette kontoer angriperen har opprettet og bytte alle passord (FTP, database, systemadministrator og CMS).

Sett nettstedet online igjen før du ber Google om en ny vurdering, fordi vurderingen trenger sider som Googlebot kan gjennomsøke.

#Hvordan ta sikkerhetskopi av et hacket WordPress

Før du endrer noe, lag en fullstendig sikkerhetskopi av den infiserte tilstanden. Det er viktig av to grunner: (1) går noe galt under oppryddingen, kan du gjenopprette, og (2) du kan analysere skadevaren senere for å forstå hvordan bruddet skjedde.

# Ta sikkerhetskopi av filsystemet
tar -czf /tmp/compromised-files-$(date +%Y%m%d).tar.gz -C /var/www/html .

# Eksporter databasen
wp db export /tmp/compromised-db-$(date +%Y%m%d).sql --path=/var/www/html

#Hvordan gå gjennom tilgangsloggene til WordPress via SSH

For å finne inngangspunktet og tidspunktet for hacket, gå gjennom tilgangsloggene til webserveren med SSH-kommandoer. Slik finner du skadelige POST-forespørsler som stemmer med endringsdatoene til filene.

# IP-adresser med mange POST-forespørsler mot innlogging eller XML-RPC
grep -h "POST /wp-login.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20
grep -h "POST /xmlrpc.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20

# Forsøk på utnyttelse mot kjente stier
grep -E "wp-config\.php|\.env|eval\(|union\+select" /var/log/nginx/access.log

# Forespørsler fra en IP-adresse som endret filer i angrepsvinduet
grep "192.168.1.100" /var/log/nginx/access.log | grep -E "POST|PUT"

Når du kjenner kilde-IP-en og det nøyaktige skriptet som behandlet forespørselen, ser du hvilken utvidelse eller hvilket tema som ble utnyttet, og kan rette sårbarheten.

#Hvordan finne skadevare i et hacket WordPress

#Hvordan finne mistenkelige PHP-filer

Bruk grep og find for å søke etter vanlige mønstre for skadevare og endrede filer:

# Søk etter vanlige tilsløringsfunksjoner
grep -rn "eval(" /var/www/html/wp-content/ --include="*.php"
grep -rn "base64_decode" /var/www/html/wp-content/ --include="*.php"
grep -rn "str_rot13" /var/www/html/wp-content/ --include="*.php"
grep -rn "gzinflate" /var/www/html/wp-content/ --include="*.php"

# Finn PHP-filer i uploads (det skal ikke finnes noen)
find /var/www/html/wp-content/uploads/ -type f -name "*.php"

# Vis PHP-filer endret de siste 7 dagene
find /var/www/html/ -type f -name "*.php" -mtime -7

#Hvordan sjekke administratorer i databasen

-- Finn mistenkelige administratorer
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE ID IN (
    SELECT user_id FROM wp_usermeta
    WHERE meta_key = 'wp_capabilities'
    AND meta_value LIKE '%administrator%'
);

#De vanligste typene WordPress-hack i 2026

#Hvordan erstatte WordPress-kjernen etter et hack

Ikke stol på virusskannere for kjernefiler. Den tryggeste metoden er å erstatte alle kjernefilene med rene versjoner uten å røre innholdsmappen wp-content/:

# Last ned ren kjerne uten å røre wp-content
wp core download --force --skip-content --path=/var/www/html

# Kontroller integriteten mot offisielle sjekksummer
wp core verify-checksums --path=/var/www/html

Dette erstatter wp-admin/, wp-includes/ og alle kjernefilene i rotmappen med originalversjonene, og fjerner dermed skadelige endringer i disse filene.

#Hvordan tolke wp core verify-checksums og kontrollen av utvidelser

wp core verify-checksums laster ned md5-sjekksummene for den installerte versjonen fra WordPress.org og sammenligner dem med filene på disken. Ifølge kommandoreferansen skjer det uten å laste WordPress, noe som er viktig på et nettsted der lasting av WordPress kjører skadevaren.

En ren kjerne avsluttes med Success: WordPress installation verifies against checksums. Hver endrede fil gir en linje som Warning: File doesn't verify against checksum: wp-includes/version.php, og kjøringen avsluttes med Error: WordPress installation doesn't verify against checksums.

Nyttige valg etter et hack:

• --include-root sjekker også rotmappen og advarer om elementer som ikke hører til WordPress. Det er der lastere lagt ved siden av wp-load.php dukker opp.
• --version=<version> og --locale=<locale> sammenligner med en bestemt versjon og et bestemt språk.
• --format=json gir maskinlesbar utdata for et skript eller en hendelsessak.
• --insecure prøver nedlastingen på nytt uten sertifikatvalidering. Referansen advarer om at forespørselen da blir sårbar for et mellommannsangrep, så ikke bruk det på en kompromittert server.

wp core download --force overskriver bare eksisterende filer, ifølge referansen for nedlasting. Filer angriperen har lagt til i wp-admin/ eller wp-includes/ kan overleve. Den tryggere rekkefølgen er å slette disse to mappene, som FAQ-en fra WordPress.org regner som trygge å erstatte, og deretter laste ned og kontrollere.

For utvidelser kontrollerer wp plugin verify-checksums --all filene mot sjekksummene fra WordPress.org, og --strict lar også “myke endringer”, som redigeringer av readme.txt, feile (referanse). Siden sjekksummene kommer fra WordPress.org, dekker kommandoen utvidelser fra katalogen på WordPress.org. Premium- og egenutviklede utvidelser trenger en fersk pakke fra leverandøren eller fra ditt eget repository.

wp core verify-checksums --include-root --path=/var/www/html
wp plugin verify-checksums --all --strict --path=/var/www/html

#Hvordan rense wp-content i et infisert WordPress

#Hvordan installere utvidelser på nytt etter et hack

Den tryggeste måten er å slette og installere alle utvidelser på nytt, slik at ingen skjulte bakdører blir liggende igjen:

# Vis aktive utvidelser
wp plugin list --status=active --path=/var/www/html

# Installer hver utvidelse på nytt fra katalogen
wp plugin install utvidelsens-navn --force --path=/var/www/html

For premiumutvidelser laster du ned ferske versjoner fra den opprinnelige leverandøren.

#Hva du gjør med temaene etter et hack

Slett alle temaer unntatt det aktive. For det aktive temaet sammenligner du filene linje for linje med originalversjonen.

#Hvordan fjerne PHP-filer fra uploads-mappen

Uploads-mappen skal ALDRI inneholde PHP-filer. Slett alle du finner:

find /var/www/html/wp-content/uploads/ -name "*.php" -delete
find /var/www/html/wp-content/uploads/ -name "*.phtml" -delete
# .htaccess bare listes og kontrolleres, ikke slettes: WooCommerce beskytter woocommerce_uploads/ med sin egen .htaccess
find /var/www/html/wp-content/uploads/ -name ".htaccess"

#Hvordan rense databasen til et hacket WordPress

Angripere legger ofte inn egne administratorkontoer, omdirigeringsskript og SEO-spam direkte i databasetabellene.

#Hvordan slette falske administratorer

-- Slett mistenkelige brukere (kontroller ID-ene først)
DELETE FROM wp_users WHERE ID IN (liste_over_mistenkelige_ider);
DELETE FROM wp_usermeta WHERE user_id IN (liste_over_mistenkelige_ider);

#Hvordan finne injiserte skript i wp_posts og wp_options

Typiske angrep som Japanese Keyword Hack skriver tusenvis av spamlenker rett inn i innleggsfeltene:

-- Søk etter injiserte skript i innlegg
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
OR post_content LIKE '%eval(%';

-- Søk etter mistenkelige alternativer
SELECT option_name, option_value
FROM wp_options
WHERE option_name LIKE '%hack%'
OR option_name LIKE '%inject%'
OR option_value LIKE '%base64_decode%';

#Hvordan fjerne bakdører i cron og i WordPress-konfigurasjonen

Skadevare planlegger ofte cron-oppgaver som infiserer rensede filer på nytt. Derfor kan nettstedet bli infisert igjen i løpet av få timer, selv om du har erstattet alle systemfilene.

#Hvordan sjekke cron-oppgaver i WordPress

Alle planlagte oppgaver lagres som serialiserte matriser i tabellen wp_options, i alternativet cron. Med denne WP-CLI-kommandoen ser du de planlagte hendelsene:

# Vis alle planlagte cron-hendelser
wp cron event list --path=/var/www/html

#Hvordan slette en skadelig cron-hendelse med PHP

Finner du en ukjent cron-hook (for eksempel wp_update_system_cache som peker på dynamisk kode), fjerner dette PHP-skriptet den:

declare(strict_types=1);

namespace WPPoland\Security\Cron;

/**
 * Fjerner skadelige cron-hooks fra tidsplanen.
 */
function remove_malicious_cron_event(): void {
    $target_hook = 'wp_update_system_cache';

    // Fjern hooken hvis den er planlagt
    $timestamp = wp_next_scheduled( $target_hook );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, $target_hook );
        error_log( sprintf( 'Security Action: Unscheduled backdoor hook "%s".', $target_hook ) );
    }
}
add_action( 'init', __NAMESPACE__ . '\\remove_malicious_cron_event' );

#Hvordan finne bakdører i .user.ini og .htaccess

En vanlig mekanisme for å holde seg inne er å injisere .user.ini- eller .htaccess-filer i rotmappen. Angriperen setter PHP-direktiver som auto_prepend_file for å kjøre et skadelig skript før noen WordPress-kode lastes:

; Skadelig direktiv i .user.ini
auto_prepend_file = "/var/www/html/wp-content/uploads/2026/06/backdoor.jpg"

Fordi denne filen virker globalt, kjører hver PHP-forespørsel bakdøren, også innloggingsskjermen. Se etter endringer i .user.ini og .htaccess i rotmappen og kontroller at ingen uautoriserte skript legges til foran eller bak.

#Hvordan herde WordPress etter fjerning av skadevare

Etter oppryddingen må du styrke nettstedet mot fremtidige angrep:

#Hvordan bytte administratorpassord og salt-nøkler

# Bytt administratorpassord
wp user update admin --user_pass="nytt-sterkt-passord" --path=/var/www/html

# Generer nye salt-nøkler (logger ut alle aktive økter)
wp config shuffle-salts --path=/var/www/html

Ved å rulle sikkerhetsnøklene (salts) gjøres alle aktive innlogginger og informasjonskapsler ugyldige umiddelbart.

#Hvilke beskyttelser som hører hjemme i wp-config.php

// Deaktiver innebygd filredigering for tema og utvidelser
define( 'DISALLOW_FILE_EDIT', true );

// Blokker installasjon og oppdatering av utvidelser via dashbordet
define( 'DISALLOW_FILE_MODS', true );

// Krev sikker HTTPS-tilkobling for administrasjon
define( 'FORCE_SSL_ADMIN', true );

#Hvilke filrettigheter WordPress bør ha

# Mapper: 755
find /var/www/html/ -type d -exec chmod 755 {} \;

# Filer: 644
find /var/www/html/ -type f -exec chmod 644 {} \;

# wp-config.php: 400 (bare lesetilgang)
chmod 400 /var/www/html/wp-config.php

#Hvem som bør eie WordPress-filene

I tillegg til rettighetene må du se på eierskapet. Webserverprosessen (for eksempel www-data eller apache) bør ikke eie PHP-filene til WordPress. Sett en egen distribusjonsbruker (for eksempel wp-user) som eier og www-data som gruppe. Da kan en kompromittert webserverprosess verken skrive til eller endre systemfilene med .php-endelse:

# Skille eierskap: wp-user eier filer, www-data er gruppe
chown -R wp-user:www-data /var/www/html/

# Gi kun webserveren skrivetilgang til uploads-mappen
chown -R www-data:www-data /var/www/html/wp-content/uploads/

#Skrivebeskyttet filsystem for WordPress i Docker

Den offisielle dokumentasjonen for bildet (docker-library/docs) beskriver en statisk distribusjon: bygg et eget bilde med koden i /usr/src/wordpress og kjør det skrivebeskyttet, med skrivbar lagring bare for /tmp, /run og eventuelt wp-content/uploads. Som standard legger bildet WordPress i et skrivbart volum /var/www/html og oppdaterer det der, så read_only: true på standardbildet gir ikke denne beskyttelsen.

FROM wordpress:apache
WORKDIR /usr/src/wordpress
RUN set -eux; \
	find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e "s!/var/www/html!$PWD!g" -e "s!Directory /var/www/!Directory $PWD!g" '{}' +; \
	cp -s wp-config-docker.php wp-config.php
COPY custom-theme/ ./wp-content/themes/custom-theme/
COPY custom-plugin/ ./wp-content/plugins/custom-plugin/

# docker-compose.yml: eget bilde, skrivebeskyttet
services:
  wordpress:
    image: custom-wordpress:tag
    read_only: true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - ./uploads:/usr/src/wordpress/wp-content/uploads

Når kodelaget er forseglet, når en feil som tillater filskriving bare uploads-volumet. Derfor er kontrollene av uploads i denne veiledningen fortsatt nødvendige. Å oppdatere betyr å bygge bildet på nytt og distribuere det igjen, og dokumentasjonen minner om å gjøre det jevnlig for å få sikkerhetsoppdateringene til WordPress.

#Hva herdingsveiledningen for WordPress legger til etter en opprydding

Veiledningen Hardening WordPress setter wp-config.php til 400 eller 440, slik at bare du og webserveren kan lese filen. Om DISALLOW_FILE_EDIT står det at innstillingen “ikke vil hindre en angriper i å laste opp skadelige filer til nettstedet ditt, men den kan stoppe noen angrep” (WordPress.org, Hardening WordPress, egen oversettelse). For databasebrukeren holder lese- og skriverettigheter i normal drift, men veiledningen fraråder å fjerne strukturelle rettigheter som ALTER, fordi enkelte oppdateringer og utvidelser endrer skjemaet. Om overvåking anbefaler den å kjøre filkontrollen som root slik at angriperen ikke enkelt kan slå den av, å overvåke bare kjørbare filtyper som .php for å redusere støyen, og å ta jevnlige kopier slik at du har versjoner fra før og etter et innbrudd.

#Hvordan bekrefte at skadevaren i WordPress er fjernet

#Sjekkliste etter fjerning av skadevare

• WordPress-kjernen kontrollert med sjekksummer
• Alle utvidelser installert på nytt fra rene kilder
• PHP-filer fjernet fra uploads
• Falske administratorbrukere slettet
• Passord byttet for alle brukere
• Salt-nøkler generert på nytt
• Filrettigheter rettet
• DISALLOW_FILE_EDIT aktivert
• XML-RPC deaktivert hvis det ikke trengs
• Sikkerhetsutvidelse installert (Wordfence, Sucuri)
• Automatiske sikkerhetskopier satt opp

#Hvordan Google melder fra om et hacket nettsted og hvor lang tid vurderingen tar

Googles funn vises i Search Console, i rapporten om sikkerhetsproblemer (Search Console-hjelp). Berørte sider kan vise en advarselsetikett i søkeresultatene eller en advarselsside i nettleseren. Rapporten bruker fire kategorier for hacking:

Den samme siden setter tre regler. Rett problemet på hele nettstedet, fordi det å rette bare noen sider ikke delvis gir nettstedet tilbake i søkeresultatene. Klikk på Request Review først når alle problemene i rapporten er rettet på alle sider. Ikke send inn forespørselen på nytt mens en annen er under behandling. En god forespørsel forklarer det nøyaktige problemet, beskriver stegene som er tatt for å rette det, og dokumenterer resultatet.

Googles veiledning Request a review legger til forutsetningene: bekreftet eierskap i Search Console, et rent nettsted, en rettet sårbarhet og et nettsted som er online igjen slik at Googlebot kan gjennomsøke det. Sjekk forsiden og en URL som angriperen endret med cURL eller Wget før du sender inn. En forespørsel sendt mens problemet fortsatt finnes, forlenger tiden nettstedet forblir merket.

Hvis Google vurderer nettstedet som rent, fjernes advarslene i nettleser og søk innen 72 timer. Hvis ikke, kan rapporten vise flere eksempel-URL-er, og advarslene blir stående. Google er ikke den eneste listen: FAQ-en fra WordPress.org anbefaler å registrere nettstedet også i Bing Webmaster Tools, Yandex Webmaster og Norton Safe Web, fordi besøkende kan bruke hvilken som helst av dem.

Google kunngjorde 20. oktober 2026 at Chrome deler Safe Browsing-advarslene om nettsteder i to nivåer for brukere som har slått på utvidet beskyttelse: mistenkelige nettsteder (en vurdering med lavere sikkerhet, mulig risiko for brukeren) og farlige nettsteder (en vurdering med høy sikkerhet, høy risiko for brukeren) (Google, 20. oktober 2026). Farlige nettsteder får fortsatt den røde advarselssiden som fyller hele skjermen. Advarselen om mistenkelige nettsteder har et annet format, ikon, farge og tekst, og Google viser den når en side har villedende mønstre som ofte henger sammen med kjente ondsinnede nettsteder.

#Hvordan hindre at WordPress blir hacket igjen

Det beste forsvaret er forebygging:

• Oppdater alltid: kjerne, utvidelser og temaer, automatisk hvis mulig
• Bruk sterke passord: minst 16 tegn, unike for hver konto
• Innfør 2FA: tofaktorautentisering for alle administratorkontoer
• Sikker hosting: VPS med brannmur, ikke delt hosting
• Daglige sikkerhetskopier: automatiserte og lagret eksternt
• Kontinuerlig overvåking: varsler ved filendringer og mistenkelig aktivitet

#Hvordan en 90 dagers sikkerhetsplan for WordPress ser ut

• Dag 1 til 30 (umiddelbar triage): full kontroll av filintegriteten med WP-CLI for å finne endrede kjernefiler. Bytt databasepassordene, root-påloggingen til databasen og SSH- og SFTP-nøklene. Bytt salts i wp-config.php for å avslutte aktive økter, og slå av direkte redigering av temaer og utvidelser med DISALLOW_FILE_EDIT.
• Dag 31 til 60 (forensikk og brannmur): gå gjennom aktive cron-oppgaver for å bekrefte at ingen skadelige funksjoner fortsatt er planlagt. Analyser webserverloggene for unormal atferd, topper i POST mot XML-RPC eller LFI-mønstre. Sett opp en brannmur for webapplikasjoner (WAF) på serveren eller en omvendt proxy (for eksempel Cloudflare) for å blokkere SQLi- og XSS-forsøk i kanten av nettet.
• Dag 61 til 90 (herding og revisjon): sett opp automatiske eksterne sikkerhetskopier til WORM-lagring (skriv én gang, les mange ganger). Gjennomfør statisk kodeanalyse og penetrasjonstester av egne temaer og skreddersydde utvidelser. Planlegg kvartalsvise sikkerhetsskanninger og lag en rutine for hendelseshåndtering for teamet.

Se våre tjenester for WordPress sikkerhetsrevisjon og vedlikehold av WordPress for å beskytte nettstedet ditt profesjonelt, eller ta gjerne kontakt med oss.