Sikre WordPress med færre angrepsflater og tydelig ansvar

WordPress-sikkerhet er et løpende driftsansvar, ikke en plugin dere installerer én gang. Kjernen, temaer, plugins, PHP, webserver, database, brukerkontoer og leverandørtilganger må vedlikeholdes som én løsning.

Det første grepet er å vite hvem som eier hver oppgave, og hvordan dere oppdager at den ikke er gjort.

Fordel ansvaret

«Administrert WordPress» betyr ikke det samme hos alle leverandører. Skriv ned hvem som gjør hva før nettstedet lanseres.

1. Reduser mengden kode

Hver plugin og hvert tema er kode med egen leverandør, oppdateringsrytme og tilgang til WordPress-miljøet.

• Behold bare aktiv funksjonalitet virksomheten trenger.
• Slett inaktive plugins og temaer som ikke brukes til rollback.
• Bruk offisielle eller dokumenterte distribusjonskanaler.
• Kontroller utvikler, siste oppdatering, kompatibilitet og support før installasjon.
• Unngå «nulled» premiumkode og ukjente zip-filer.
• Dokumenter forretningsbehov og eier for hvert tillegg.
• Ha en erstatnings- eller avviklingsplan for kode som ikke lenger vedlikeholdes.

En sikkerhetsplugin kan gi WAF, rate limiting, 2FA, filkontroll eller logging, men den kjører også kode med høy tilgang. Velg funksjonene dere trenger, vurder leverandøren og unngå flere overlappende plugins som endrer de samme reglene.

2. Oppdater med en testet prosess

WordPress anbefaler å holde kjerne, plugins og temaer oppdatert. Automatisk oppdatering kan aktiveres per tema og plugin, men oppgaven er ikke ferdig før feilede oppdateringer varsles og siden verifiseres.

En praktisk prosess:

1. Følg sikkerhetsvarsler og kjenn alle installerte komponenter.
2. Ha en fersk, gjenopprettbar kopi av filer og database.
3. Test risikable endringer i et separat miljø.
4. Prioriter sikkerhetsrettinger etter eksponering og alvorlighet.
5. Oppdater én kontrollert gruppe om gangen.
6. Test innlogging, skjema, betaling, søk og redigering.
7. Kontroller logger og overvåking etter publisering.
8. Rull tilbake bare ved reell feil, og finn deretter en sikker oppgraderingsvei.

Automatikk passer godt for mange vedlikeholdte komponenter, men må kombineres med varsling og restore. WordPress dokumenterer hvordan auto-oppdateringer for plugins og temaer virker og at de kan feile hvis cron eller hostingoppsett ikke fungerer.

Bruk staging-guiden for endringer med høy konsekvens og PHP-guiden for kjøretidsmiljøet.

3. Beskytt alle privilegerte kontoer

Sikre ikke bare /wp-admin. En angriper kan overta nettstedet via hosting, DNS, registrar, e-post eller kildekodelager.

• Gi hver person en egen konto.
• Bruk en passordmanager og unike, tilfeldige passord.
• Krev MFA for administratorer og andre kontrollkontoer.
• Gi redaktører og skribenter minste nødvendige rolle.
• Fjern gamle brukere og leverandørtilganger raskt.
• Ha minst to kontrollerte gjenopprettingsansvarlige uten å dele konto.
• Beskytt e-postkontoen som mottar passordreset.

Et vanlig brukernavn som admin kan gi angriperen én kjent opplysning, men å bytte navnet kompenserer ikke for svakt passord eller manglende MFA. NSM anbefaler virksomheter å innføre flerfaktorautentisering der det er mulig .

Rate limiting kan redusere automatiserte innloggingsforsøk, men hard IP-låsing alene passer dårlig for delte nettverk og mobile brukere. Overvåk resultatet og ha en trygg recoveryvei.

4. Begrens hva en kompromittert konto kan gjøre

WordPress trenger skrivetilgang noen steder, men ikke overalt.

• La plugins og kjernefiler være skrivbare bare for nødvendig deploy- eller oppdateringsprosess.
• Begrens lesetilgang til wp-config.php og andre hemmeligheter.
• Ikke bruk tillatelsen 777 som generell feilretting.
• Gi databasebrukeren bare rettighetene installasjonen trenger.
• Bruk separate databasebrukere for uavhengige installasjoner.
• Bruk SFTP eller SSH, ikke ukryptert FTP.
• Skill produksjon, staging og lokale miljøer.

Hvis administratorer ikke skal redigere PHP fra dashbordet, kan filredigering deaktiveres:

define( 'DISALLOW_FILE_EDIT', true );

Dette stopper ikke en angriper som allerede kan laste opp eller endre filer på andre måter, men fjerner én enkel kodekjøringsvei. WordPress’ offisielle hardening-guide dekker filrettigheter, SFTP, konfigurasjon, logging og overvåking.

Endre ikke filrettigheter ukritisk fra en tilfeldig oppskrift. Riktig eier og tillatelse avhenger av hostingmodellen; be leverandøren dokumentere modellen.

5. Bruk HTTPS uten å overvurdere det

HTTPS beskytter trafikken mellom nettleser og tjenesten. Det hindrer ikke en sårbar plugin, stjålet administratorkonto, ondsinnet kode eller svak databasekonfigurasjon.

• Omdiriger HTTP direkte til riktig HTTPS-adresse.
• Bruk HTTPS i både offentlig side og administrasjon.
• Overvåk sertifikat og fornyelse utenfra.
• Fjern mixed content.
• Sett Secure, HttpOnly og passende SameSite på cookies etter funksjon.

Les hva SSL-sertifikatet faktisk beskytter og HSTS-guiden før en langvarig policy aktiveres.

6. Ta backup som kan gjenopprettes

En WordPress-kopi må normalt dekke både database og filer, blant annet uploads, plugins, temaer og relevant konfigurasjon. En ren database gir ikke nødvendigvis en komplett side.

• Definer RPO og RTO.
• Behold flere tidspunkter; kompromittering kan oppdages sent.
• Oppbevar minst én kopi isolert fra WordPress-kontoen.
• Krypter og tilgangsstyr kopier med personopplysninger.
• Test full restore i et separat miljø.
• Dokumenter DNS, secrets og tredjepartstjenester som backupen ikke inneholder.

Bruk WordPress-backupguiden for en full prosedyre.

7. Logg, overvåk og øv på hendelser

Overvåk minst:

• endringer i administratorer, plugins og temaer
• feilede og vellykkede privilegerte innlogginger
• uventede filendringer
• oppdateringer som feiler
• nye redirects, fremmed innhold og sikkerhetsvarsler
• oppetid, 5xx-feil og sertifikatutløp
• DNS- og registrarendringer

Logger må sendes eller beskyttes slik at en angriper ikke enkelt kan slette alle spor. Bestem hvem som mottar varsel, hva som er kritisk, og hvor raskt det skal håndteres.

Ved mistanke om kompromittering: isoler uten å ødelegge bevis, roter relevante tilganger, finn inngangsveien, bygg eller gjenopprett fra et verifisert rent grunnlag og vurder varslingsplikter. Følg hendelsesguiden for et hacket nettsted i stedet for å bare installere en skanner.

Tiltak som ikke kan bære sikkerheten

• Å skjule WordPress-versjonen hindrer ikke at sårbar kode kan prøves.
• Et annet databaseprefiks retter ikke SQL-injeksjon.
• Å flytte innloggings-URL-en stopper ikke andre inngangsveier.
• Flere sikkerhetsplugins betyr ikke automatisk flere uavhengige lag.
• Et grønt hengelåssymbol betyr ikke at applikasjonen er trygg.
• Backup uten testet restore er bare en antakelse.

Slike tiltak kan inngå i et lagdelt oppsett, men de må ikke erstatte patching, MFA, minste privilegium, isolasjon og overvåking.

WordPress og Vymo

Vymos standardtilbud er ikke WordPress-hosting og inkluderer ikke WordPress-kontrollpanel, plugins eller en dokumentert WordPress-vedlikeholdsavtale. Vymo setter opp og hoster én enkel bedriftsnettside som en administrert leveranse.

Trenger virksomheten WordPress, må hosting, oppdateringer, sikkerhet, backup, restore og hendelsesansvar avtales separat. Beskriv WordPress-løsningen og ansvaret dere ønsker , eller velg den enkle nettsiden dersom dere vil unngå eget WordPress-driftsansvar.