WordPress-hjelp og akutt support

Kundene ringer, skjermen viser bare hvitt, og ingen på kontoret vet hvor man begynner. Ro først. Mye av den akutte WordPress-hjelpen vi gir starter dessverre etter at noen har gjort vondt verre — slettet filer på måfå eller lagt tilbake en gammel backup i blinde. Er siden hacket, kan den backupen skrive over akkurat de loggene som viser hvordan angriperen kom inn. La alt stå urørt.

God WordPress-support i en krise begynner med det kjedelige. Er domenet fornyet? Svarer hostingleverandøren i det hele tatt? Ta skjermbilder av det siden faktisk viser, og send oss alt sammen — en feilkode på et bilde sparer oss gjerne for en halvtimes gjetting i telefonen.

Ringer du oss, starter vi med triage. En senior-utvikler går rett i server- og feilloggene og finner ut hva som faktisk har skjedd, før noen får røre noe som helst. SLA-kunder får svar i løpet av minutter, døgnet rundt. Alle andre tar vi samme virkedag. En side som er nede går foran alt planlagt arbeid hos oss.

Og du slipper saksnummer-karusellen: personen som tar telefonen hos oss, er den samme som leser loggene dine etterpå, og den samme som skriver rapporten til slutt. Ikke et skjema, ikke en kø.

Den første innskytelsen når WordPress er hacket, er å slette alt som ser fremmed ut. Stå imot den. Vi gjør det motsatte: sikrer først en komplett kopi av filer og database, og leser deretter loggene til vi vet nøyaktig hvor angriperen kom seg inn. I ni av ti oppdrag ender sporet i en plugin som ikke har sett en sikkerhetsoppdatering på måneder.

Selve oppryddingen kjører vi med WP-CLI og bytter infiserte kjerne- og pluginfiler mot verifiserte originaler fra WordPress.org, i stedet for å flikke på dem. Så jakten på bakdører. En angriper som har vært inne, har lagt igjen en vei tilbake — en ekstra admin-bruker, en cron-jobb, en fil med et troskyldig navn. Hopper du over den jakten, er du hacket på nytt før måneden er omme.

Til slutt herder vi siden. Hvert eneste passord og hver API-nøkkel får nye verdier, sammen med salt-nøklene i wp-config.php, og tofaktorautentisering blir obligatorisk for administratorene. Konfigurasjonen strammer vi inn etter samme mal som i WordPress-sikkerhet-avtalene våre. Har Google rukket å svarteliste siden, ber vi om ny vurdering med en gang.

Rapporten du får etterpå er skrevet for mennesker, ikke for utviklere — den forteller hva angriperen gjorde, og hva som nå står i veien for en reprise. Kort nok til styremøtet.

Byrået som bygde siden har sluttet å svare på e-post. Kanskje konkurs, kanskje større kunder. Fakturaen kommer likevel hver måned, for noe ingen i bedriften lenger kan gjøre rede for, og dokumentasjon har ingen sett snurten av. Og admin-passordet forsvant ut døra med markedssjefen i fjor.

Sider andre har bygget tar vi over jevnlig, uten dokumentasjon og uten velvilje fra forrige leverandør. Eierskapet først. Du har krav på tilgang til din egen nettside selv når leverandøren tier, og vi kjenner prosedyrene hos Norid og hos norske hostingleverandører for å hente domene og innhold hjem.

Deretter åpner vi panseret. Hvilke plugins kjører, og hva er spesialbygget? Vi sjekker også om serveren står på PHP 8.4 eller på en versjon som sluttet å få sikkerhetsoppdateringer for flere år siden — det siste er regelen på sidene vi overtar, ikke unntaket. Du får en tilstandsrapport i klartekst. Trenger du noen til videreutviklingen etterpå, kan du leie en WordPress-utvikler på fast timebank.