De første 90 minuttene etter et mulig WordPress-innbrudd

Kategori: Nettsikkerhet

En ukjent administrator, videresending til fremmede sider eller plutselige endringer i innholdet kan være tegn på at WordPress-nettstedet er kompromittert. Da er det lett å handle for raskt: oppdatere alt, slette mistenkelige filer eller gjenopprette en tilfeldig backup. Slike tiltak kan fjerne viktige spor uten å stenge inngangen angriperen brukte.

De første 90 minuttene bør derfor følge en avtalt rekkefølge. Målet er å begrense konsekvensene, bevare nødvendig informasjon og unngå at nettstedet åpnes igjen med samme sårbarhet. Planen under passer for vanlige bedriftsnettsteder, men må tilpasses virksomhetens tekniske løsning, databehandling og krav til varsling.

Før hendelsen: Avklar hvem som kan ta beslutninger

En hendelsesplan fungerer dårlig hvis ingen vet hvem som har myndighet til å stenge nettstedet eller kontakte driftsleverandøren. Utpek derfor en hendelsesansvarlig og en teknisk ansvarlig før noe skjer. For mindre virksomheter kan dette være daglig leder og webbyrået eller driftsleverandøren.

Planen bør inneholde kontaktinformasjon som er tilgjengelig utenfor WordPress. Den bør også beskrive hvor backup lagres, hvem som kontrollerer domenet, hvem som administrerer hosting, og hvilke eksterne tjenester nettstedet utveksler data med. Ikke legg den eneste kopien av planen i et system dere kan miste tilgang til.

Avklar også på forhånd hvem som kan beslutte følgende:

• Sette nettstedet i vedlikeholdsmodus eller stenge det midlertidig.
• Deaktivere brukerkontoer og integrasjoner.
• Bestille bistand og godkjenne kostnader.
• Informere kunder, ansatte og eventuelle berørte samarbeidspartnere.
• Vurdere om hendelsen omfatter personopplysninger eller andre beskyttelsesverdige data.

0–15 minutter: Bekreft signalet og opprett en hendelseslogg

Start med å registrere hva som ble oppdaget, tidspunktet og hvem som oppdaget det. Ta skjermbilder av synlige avvik, og noter hvilke sider, brukere eller funksjoner som er berørt. Opprett én felles hendelseslogg der alle tiltak føres fortløpende.

Ikke anta at alle avvik skyldes et innbrudd. En feilslått publisering, en utløpt integrasjon eller en konflikt etter en oppdatering kan gi lignende symptomer. Samtidig bør dere behandle situasjonen som reell inntil den er avklart.

Kontroller blant annet:

• Om nye administratorer eller andre ukjente brukere er opprettet.
• Om innhold, menyer, innstillinger eller sporingskoder er endret.
• Om besøkende sendes videre til andre sider.
• Om hosting, sikkerhetsverktøy eller overvåking har registrert uvanlige innlogginger eller filendringer.
• Om nettstedet sender unormalt mye e-post eller har fått plutselige driftsproblemer.

Unngå å gjøre omfattende endringer før dere har samlet grunnleggende informasjon. En masseoppdatering kan endre tidsstempler og filer som ellers kunne hjulpet med å forstå hendelsen.

15–30 minutter: Begrens skaden uten å ødelegge sporene

Når det er rimelig mistanke om kompromittering, må dere redusere angriperens handlingsrom. Hva som er riktig tiltak, avhenger av nettstedets betydning og hvilke funksjoner som er berørt.

Et ordinært informasjonsnettsted kan ofte settes i vedlikeholdsmodus mens undersøkelsen pågår. For en nettbutikk eller en selvbetjeningsløsning må dere vurdere risikoen ved fortsatt drift opp mot konsekvensene av nedetid. Hvis data kan bli lest, endret eller sendt til feil mottaker, bør hensynet til sikkerhet veie tyngre enn tilgjengelighet.

Bevar en kopi av den berørte løsningen før oppryddingen starter. Kopien bør omfatte filer, database og relevante logger. Den skal holdes adskilt fra en senere, ren produksjonsløsning. Dette er ikke det samme som å ta en vanlig driftsbackup for gjenoppretting; formålet er å bevare tilstanden slik den var da hendelsen ble oppdaget.

Ikke slett en ukjent administrator eller mistenkelig fil uten først å dokumentere funnet. Kontoen kan sperres, og tilgangen kan begrenses, men informasjon om opprettelsestidspunkt og aktivitet kan være viktig for å finne inngangen.

30–60 minutter: Steng tilganger i riktig rekkefølge

Et WordPress-nettsted styres gjennom flere lag. Det hjelper lite å bytte passord i WordPress hvis uvedkommende fortsatt har tilgang til hosting eller e-postkontoen som brukes til tilbakestilling.

Start med kontoene som kan kontrollere de andre. En hensiktsmessig rekkefølge er ofte:

1. Sikre e-postkontoene til administratorer og tekniske kontaktpersoner.
2. Sikre kontoene for hosting, domene og eventuell skytjeneste.
3. Bytte innloggingsopplysninger for WordPress-administratorer.
4. Bytte databasepassord, filoverføringstilganger og andre tekniske nøkler.
5. Tilbakekalle aktive økter, applikasjonspassord og nøkler til integrasjoner.

Bruk unike passord og flerfaktorautentisering der det er tilgjengelig. Hvis en administrator har brukt samme passord andre steder, må disse kontoene også håndteres. Opprett ikke nye permanente fellesbrukere som en snarvei under hendelsen. Hver person bør ha sin egen konto, også når tidspresset er stort.

Gjennomgå samtidig hvilke integrasjoner som kan ha blitt berørt. Et kontaktskjema kan sende data til et kundesystem, mens en nettbutikk kan være koblet til betaling, frakt, regnskap og e-postmarkedsføring. Nøkler og tilganger bør erstattes når det er mulig at de har vært eksponert.

60–90 minutter: Velg mellom rensing og gjenoppretting

Nå må dere ta stilling til hvordan nettstedet skal bringes tilbake. Det finnes to hovedalternativer: rense den eksisterende installasjonen eller bygge opp løsningen fra en kjent, ren tilstand.

Rensing kan være aktuelt når omfanget er lite, årsaken er tydelig og endringene kan identifiseres sikkert. Det krever likevel mer enn å fjerne én mistenkelig fil. WordPress-kjernen, temaer, utvidelser, opplastede filer, databaseinnhold, administratorer og planlagte oppgaver må undersøkes.

Gjenoppretting fra backup kan være tryggere når endringene er omfattende eller vanskelige å avgrense. Men backupens dato må sammenholdes med tidspunktet for innbruddet. En eldre sikkerhetskopi kan allerede inneholde bakdøren, mens en svært gammel kopi kan mangle viktige bestillinger, skjemaoppføringer eller innholdsendringer.

Før nettstedet åpnes igjen, må den opprinnelige inngangen være håndtert. Det kan bety å oppdatere en sårbar utvidelse, erstatte en utdatert komponent, fjerne en forlatt brukerkonto eller endre feilaktige serverinnstillinger. Hvis årsaken er ukjent, har dere heller ikke et godt grunnlag for å si at løsningen er trygg.

Oppdateringer skal lukke årsaken, ikke skjule den

Oppdateringer er en sentral del av oppryddingen, men tidspunktet er viktig. Først dokumenterer og sikrer dere tilstanden. Deretter oppdaterer dere WordPress, temaer og utvidelser i en kontrollert kopi eller et testmiljø.

Komponenter som ikke lenger vedlikeholdes, bør normalt erstattes i stedet for bare å aktiveres igjen. Det samme gjelder utvidelser dere ikke bruker. En deaktivert utvidelse kan fortsatt ha filer på serveren og bør fjernes dersom den ikke er nødvendig.

Kontroller at oppdateringen ikke ødelegger skjemaer, innlogging, betaling eller andre kritiske funksjoner. Målet er ikke bare å få et grønt oppdateringspanel, men å lukke sårbarheten uten å introdusere nye driftsfeil.

Kontroller før nettstedet åpnes

En teknisk tilgjengelig forside er ikke nok til å friskmelde nettstedet. Gjennomfør en kort, dokumentert kontroll av både sikkerhet og funksjon.

• Bekreft at bare godkjente brukere har administratorrettigheter.
• Kontroller at alle aktive komponenter er nødvendige og vedlikeholdte.
• Undersøk om ukjente filer, planlagte oppgaver eller kodeendringer gjenstår.
• Test skjemaer, søk, innlogging, utsendinger og eventuelle kjøpsløp.
• Kontroller at logger og overvåking fortsatt fungerer.
• Sjekk at ny backup blir tatt og kan leses av riktig system.

Åpne gjerne nettstedet trinnvis. Intern testing kan gjennomføres først, deretter begrenset produksjonsdrift med ekstra overvåking. Følg spesielt med på nye administratorer, mislykkede innlogginger, filendringer, uventet trafikk og utsending av e-post.

Etterarbeidet avgjør om hendelsen gjentar seg

Når driften er stabil, bør dere samle involverte til en kort gjennomgang. Beskriv hva som skjedde, hvordan det ble oppdaget, hvilke tiltak som virket, og hva som skapte forsinkelser. Skill mellom teknisk årsak og organisatoriske svakheter. En sårbar utvidelse er en teknisk årsak; manglende ansvar for oppdateringer er en organisatorisk svakhet.

Oppdater deretter rutinene for autentisering, tilgangsstyring, oppdateringer, backup og overvåking. Fjern gamle kontoer, reduser administratorrettigheter og bestem hvem som følger opp sikkerhetsvarsler. Avtal også hvor ofte gjenoppretting og hendelsesplan skal øves.

En god respons handler ikke om å gjøre flest mulig endringer på kortest mulig tid. Den handler om å arbeide i riktig rekkefølge: dokumentere, begrense, sikre tilganger, fjerne årsaken, kontrollere løsningen og følge opp. Da reduserer dere både nedetiden og risikoen for at samme inngang blir brukt på nytt.