⚙️ All in One WP Security: trinnvis wordpress-sikkerhetsoppsett i 16 trinn
Hver dag mottar et gjennomsnittlig WordPress-nettsted 200 til 500 ugyldige forespørsler til wp-login.php. Dette er ikke hackere i hettegensere, dette er skript. De gjennomsøker internett, finner standard innloggingsside og starter brute force-angrep: admin/123456, admin/qwerty, admin/passord_fra_lekket_database. Før eller siden knekker de det.
Hosting beskytter ikke mot dette. Serverbrannmuren ser en legitim POST-forespørsel til wp-login.php og slipper den gjennom, den kan ikke skille om det er du som skriver inn et passord eller en bot. WordPress-beskyttelse og serverbeskyttelse er to forskjellige lag, og du er ansvarlig for det første.
All-In-One Security (AIOS) fra UpdraftPlus-teamet dekker dette laget fullstendig. Én plugin i stedet for en pakke: brannmur, innloggingsbeskyttelse, filrevisjon, bot-blokkering og sikkerhetskopier. Én million installasjoner, 4,7 i vurdering på WordPress.org. Gratisversjonen er nok til å beskytte et gjennomsnittlig nettsted. Nedenfor følger et trinnvis oppsett, fra grunnleggende til konfigurasjonseksport.
💡 Rask oversikt:
- Vi skjuler innloggingssiden bak en tilpasset URL og aktiverer tofaktorautentisering. Brute force-angrep vil mislykkes umiddelbart.
- Vi konfigurerer tre brannmurlag: htaccess pluss PHP-regler pluss 6G-svarteliste. Lagdelt forespørselsfiltrering.
- Vi blokkerer tilgang til tjenestefiler, deaktiverer PHP-redigering fra adminpanelet og sjekker mappetillatelser.
- Vi aktiverer honeypot og 404-feildeteksjon. Botter filtreres ut før de lander, uten captcha for brukere.
- Vi lagrer den ferdige konfigurasjonen til en fil for overføring mellom nettsteder på ett minutt.
Trinn 1. Fjern WP generator-metadata
Det første som lekker WordPress-versjonen din er <meta name="generator" content="WordPress X.X.X">-taggen i <head> på hver side. En angriper får det nøyaktige versjonsnummeret og velger exploits for det på sekunder. AIOS fjerner denne taggen med én bryter.
Sti: WP Security → Settings → General Settings. Aktiver Remove WP Generator Meta Info og lagre. Sjekk kildekoden på startsiden din (Ctrl+U), linjen med generator skal forsvinne. I samme seksjon, deaktiver Enable Info Comments, AIOS legger som standard til HTML-kommentarer med tjenesteinformasjon, bedre å fjerne disse også.
Trinn 2. Blokker innloggingsforsøk
Brute force mot wp-login.php er angrep nummer én etter hyppighet. Botter prøver hundrevis av passord per minutt, noe som skaper belastning på server og database. Før eller siden knekkes et svakt passord, spesielt hvis en administrator- eller redaktørbruker bruker qwerty123.
Sti: WP Security → User Login → Login Lockdown. Aktiver Enable Login Lockdown og sett: maksimalt 5 forsøk, IP-blokkering i 60 minutter, telleren nullstilles etter 24 timer. For nettsteder med flere administratorer, aktiver Notify by Email, blokkeringsvarselet kommer umiddelbart. Hvis du ser hyppige varsler, endre innloggingssidens slug (trinn 14).
Trinn 3. Manuell godkjenning for nye registreringer
Hvis registrering er åpen på nettstedet ditt, vil enhver bot opprette en konto på sekunder uten denne innstillingen. Spamkontoer hoper seg opp i tusenvis, tetter igjen databasen og skaper angrepsflate gjennom rettighetseskalering.
Sti: WP Security → User Registration → Manual Approval. Aktiver Enable Manual Approval. Nå venter hver ny konto på administratorbekreftelse før aktivering. I samme seksjon, konfigurer captcha for registreringsskjemaer, en ekstra barriere som botter ikke kan passere.
Trinn 4. Endre databasetabellprefiks
wp_-prefikset er standard for alle WordPress-installasjoner. SQL-injeksjoner og massekompromitteringsskript retter seg spesifikt mot det: når en exploit kjenner tabellnavn (wp_users, wp_options), blir angrepet målrettet i stedet for blindt.
Sti: WP Security → Database → DB Prefix. Du ser det gjeldende prefikset. Hvis det er wp_, klikk Change DB Table Prefix. Pluginen vil foreslå en tilfeldig streng eller la deg angi din egen (4-6 tegn, kun latinske bokstaver og understreker). Før du kjører, må du absolutt ta en databasesikkerhetskopi (trinn 5). Prosessen tar 5-10 sekunder på et gjennomsnittlig nettsted, men tilbakerulling uten sikkerhetskopi er umulig.
Trinn 5. Databasesikkerhetskopi
Før eventuelle strukturelle endringer, prefiksendring, revisjonsopprydding, kjerneoppdatering, er sikkerhetskopi obligatorisk. AIOS er integrert med UpdraftPlus, sikkerhetskopiering startes fra samme grensesnitt.
Sti: WP Security → Database → Database Backup. Klikk Create Database Backup, filen lagres lokalt. Konfigurer automatisk skylasting via UpdraftPlus (Google Drive, Dropbox, S3) og daglig planlegging. Å gjenopprette et nettsted etter kompromittering uten sikkerhetskopi er praktisk talt umulig, og med AIOS + UpdraftPlus er det én knapp.
Trinn 6. Sjekk mappe- og filtillatelser
Feil tilgangstillatelser, 777 på wp-config.php, 666 på uploads-mappen, åpen skrivetilgang til wp-content, åpner en direkte vei for å skrive skadelig kode. Hvis en angriper får tilgang til et tema gjennom et sikkerhetshull, lar feil tillatelser dem endre systemfiler.
Sti: WP Security → Filesystem Security → File Permissions. Kjør skanningen. Alle linjer skal være grønne. Rød eller gul linje, klikk Set Recommended Permissions ved siden av den problematiske filen eller mappen. Etter å ha fikset, start skanningen på nytt, den skal være ren.
Trinn 7. Deaktiver PHP-redigering fra adminpanelet
Den innebygde tema- og plugin-editoren, wp-admin/theme-editor.php og wp-admin/plugin-editor.php, er en direkte vei til vilkårlig kjøring av kode. Hvis en angriper får tilgang til adminpanelet, lar editoren vedkommende legge til et PHP-skall i functions.php og få kontroll over serveren. En seriøs utvikler trenger ikke denne editoren, endringer gjøres via FTP/SFTP eller deployment.
Sti: WP Security → Filesystem Security → PHP File Editing. Aktiver Disable PHP File Editing. Etter lagring vil elementene «Theme Editor» og «Plugin Editor» forsvinne fra menyene «Appearance» og «Plugins». Hvis du trenger å gjøre endringer, kun via hostingens filbehandler eller SSH.
Trinn 8. Blokker tilgang til WordPress' servicefiler
readme.html, license.txt, wp-config-sample.php og debug.log avslører CMS-versjon, installasjonsstruktur og interne stier. debug.log er spesielt farlig: i WP_DEBUG-modus skriver den absolutte serverstier og feil-stacktraces med plugin-navn.
Sti: WP Security → Filesystem Security → WP Info Files. Kryss av for alle fire elementene: readme.html, license.txt, wp-config-sample.php, debug.log. Lagre. Nå vil serveren returnere 403 Forbidden ved direkte forespørsel til yoursite.com/readme.html. Dette er .htaccess-regler, de fungerer på Apache/Nginx-nivå før PHP starter.
Trinn 9. Grunnleggende brannmurfunksjoner
AIOS-brannmuren har tre beskyttelsesnivåer. .htaccess-regler blokkerer forespørsler før de sendes til PHP (det raskeste laget). PHP-regler filtrerer XSS-vektorer, deaktiverer XML-RPC og RSS-strømmer. Det tredje laget kutter av falske Google-boter basert på user-agent.
Sti: WP Security → Firewall → Basic Firewall. Aktiver:
- Enable Basic Firewall Protection, generell aktivering;
- Block Fake Googlebots, boter med falsk Googlebot
user-agentfiltreres; - Disable RSS and Atom Feeds, hvis nettstedet ikke bruker RSS, deaktiver (innholdsparsing);
- Disable Directory Listing, hindre Apache i å vise mappeinnhold uten
index.php.
Her deaktiverer du også XML-RPC hvis du ikke bruker WordPress-mobilappen, Jetpack eller trackbacks. For de fleste bloggnettsteder i 2026 er ikke XML-RPC nødvendig.
Steg 10. Ytterligere brannmurregler
Utvidede .htaccess-regler stenger flere angrepsvektorer: direkte nettlesertilgang til wp-config.php og .htaccess, grense for opplastet filstørrelse, deaktivering av serversignatur.
Sti: WP Security → Firewall → Additional Firewall. Aktiver:
- Deny Access to wp-config.php, nøkkelkonfigurasjon er utilgjengelig via HTTP;
- Deny Access to.htaccess, serverregelfilen er stengt for lesing;
- Disable Server Signature, Apache slutter å rapportere versjon i
Server-headere; - Limit File Upload Size, sett 10 MB (nok til bilder, ikke nok til å laste opp arkiv med skall).
Regler skrives direkte til .htaccess. Etter lagring, åpne nettstedet i et inkognitovindu og sjekk at alt fungerer.
Steg 11. 6G brannmur-svarteliste
6G Firewall fra Perishable Press er et strengt sett med .htaccess-regler som blokkerer ondsinnede mønstre i URL-er og spørrestrenger: SQL-injeksjoner, filinkluderingsforsøk (../../wp-config.php), XSS-vektorer og signaturer for sårbarhetsskannere. Reglene er statiske, krever ingen oppdateringer, angrepsmønstre har ikke endret seg på årevis.
Sti: WP Security → Firewall → 6G Blacklist. Aktiver Enable 6G Firewall Protection og lagre. Hvis en legitim plugin slutter å fungere etter aktivering (sjeldent, men skjer med plugin-er som har ikke-standard URL-mønstre), legg den til i hvitelisten: Firewall → Whitelist.
Steg 12. Forhindre bildelenking
Bildelenking er når et annet nettsted bygger inn bildet ditt via direkte URL (<img src="https://yoursite.com/uploads/photo.jpg">). Serveren din serverer bildet pliktoppfyllende, og bruker trafikk og CPU-ressurser, mens den besøkende ser innhold på andres nettsted. For nettsteder med originale skjermbilder og bilder er dette merkbart.
Sti: WP Security → Firewall → Prevent Hotlinks. Aktiver Prevent Hotlinking. Legg til unntaksdomener (google.com, facebook.com, twitter.com) slik at forhåndsvisninger i sosiale medier og søk fortsetter å fungere. AIOS skriver regler til .htaccess, som forbyr direkte bildeforespørsler med en Referer-header fra et annet domene.
Steg 13. Deteksjon av 404-feil
Massevis av 404-feil er et tegn på sårbarhetsskanning. En bot prøver /wp-admin/, /admin/, /backup.zip, /phpmyadmin/ og hundrevis av andre typiske stier for å sjekke angrepsflaten. AIOS sporer slike forespørsler, kobler dem til IP-er og blokkerer kilden.
Sti: WP Security → Scanner → 404 Detection. Aktiver Enable 404 Detection. Terskel: 20 feil på 15 minutter → midlertidig utestengelse i 30 minutter; 50 feil på 15 minutter → permanent utestengelse. Fanen Logged 404 Events vil vise en levende liste over mistenkelige forespørsler, nyttig for å forstå nøyaktig hva som skannes på nettstedet ditt.
Steg 14. Endre adressen til innloggingssiden
/wp-admin og /wp-login.php er standard inngangspunkter, kjent for enhver bot. Uten dette steget fungerer brute-force-beskyttelsen (steg 2), men angrep kommer fortsatt i tusentall, boter banker på en kjent dør. Å gi innloggingssiden nytt navn fjerner selve målet.
Sti: WP Security → Brute Force → Rename Login Page. Skriv inn en egendefinert slug: minst 4 tegn, ikke admin, login eller wp-*. Godt alternativ: manage- pluss 6 tilfeldige bokstaver, for eksempel manage-xk7qpd. Etter lagring, sjekk umiddelbart den nye URL-en og bokmerk den. Den standard wp-login.php vil bli deaktivert, hvis du glemmer slug-en, må du gjenopprette den via FTP (ved å slette eller gi nytt navn til plugin-en).
Steg 15. Honningfelle for boter
Honningfelle er et skjult felt i innloggingsskjemaet. Et menneske ser det ikke (CSS-regel display:none eller posisjonering utenfor skjermen), men en bot finner det gjennom HTML-markup-parsing og fyller det ut. AIOS ser det utfylte skjulte feltet og blokkerer forsøket som ikke-menneskelig. Ingen captcha, brukeren vet ikke engang om sjekken.
Sti: WP Security → Brute Force → Honeypot. Aktiver Enable Honeypot Protection. Feltet legges automatisk til i wp-login.php-skjemaet og fungerer stille i bakgrunnen. Ifølge Team Updraft filtrerer honningfellen ut det overveldende flertallet av automatiserte boter, de trenger ikke akkurat ditt adminpanel, de ser bare etter standardskjemaet og fyller ut alle felt i rekkefølge.
Steg 16. Forhindre innbygging av nettsted i rammer
Clickjacking er et angrep der nettstedet ditt lastes i en gjennomsiktig <iframe> over angriperens nettsted. Brukeren tror de klikker i grensesnittet, men samhandler faktisk med et annet nettsteds skjema. Headeren X-Frame-Options: SAMEORIGIN forhindrer innbygging.
Sti: WP Security → Firewall → Prevent Framing. Aktiver Prevent Your Site From Being Displayed in a Frame. AIOS legger til HTTP-headeren X-Frame-Options: SAMEORIGIN i alle serversvar. Sjekk: curl -I https://yoursite.com, headeren skal være i svaret. For nettsteder med innloggingsskjema, handlekurv eller adminpanel er dette steget kritisk.
Eksporter ferdig konfigurasjon for andre nettsteder
Hvis du administrerer flere nettsteder, sparer import-eksport timer. AIOS lagrer hele konfigurasjonen til en tekstfil som lastes på et annet nettsted med ett klikk.
Sti: WP Security → Settings → Import/Export. Klikk Export Settings, du får en .txt-fil med alle aktiverte alternativer og deres verdier. Filen kan redigeres før import på et annet nettsted: erstatt email for sikkerhetsvarsler og innloggingsside-slug med gjeldende for målnettstedet.
Import: WP Security → Settings → Import/Export → Import Settings → velg fil. Alle 16 steg vil bli brukt automatisk i løpet av et par sekunder, du trenger ikke gå gjennom hver skjerm på nytt.
⁉️🤔 Vanlige spørsmål
Er AIOS nødvendig hvis hostingen lover «full beskyttelse»?
Hosting beskytter serveren: OS-nivå, nettverksbrannmurer, DDoS-filtrering. AIOS beskytter WordPress-applikasjonen: brute-force mot adminpanelet, plugin-injeksjoner, sårbarheter i utdaterte temaer. Serverbrannmuren ser ikke at en bot brute-forcer passord mot
wp-login.php, den ser legitime POST-forespørsler. Lagene overlapper ikke, du trenger begge. Et nettsted på «beskyttet» hosting uten sikkerhetsplugin er fortsatt sårbart på CMS-nivå.
Vil AIOS komme i konflikt med Cloudflare eller en annen WAF?
Nei, de jobber på ulike nivåer. Cloudflare er lag 7 (HTTP-proxy), filtrerer trafikk før den når serveren. AIOS er applikasjonsnivå (PHP,
.htaccess), etter at forespørselen når WordPress. Eneste nyanse: når du bruker Cloudflare, aktiver Aktiver IP-deteksjon i AIOS, slik at plugin-en ser den besøkendes virkelige IP fraX-Forwarded-For-headeren, ikke proxy-IP-en.
Kan jeg fjerne AIOS etter oppsett, reglene forblir jo i.htaccess?
Nei.
.htaccess-reglene vil fysisk forbli i filen, men uten overvåking og oppdateringer blir de utdaterte. Verre: honeypot, omdøping av innloggingsside, blokkering av PHP-editor og tofaktorautentisering fungerer bare mens plugin-en er aktiv, dette er PHP-logikk, ikke statiske regler. Fjerner du plugin-en, åpner du standardwp-login.phpog deaktiverer all innloggingsbeskyttelse.
Vil nettstedet knekke hvis jeg aktiverer alle 16 stegene samtidig?
På det store flertallet av nettsteder, nei. Men anbefalingen for produksjon: aktiver i blokker på tre til fire steg, og sjekk at nettstedet fungerer etter hver blokk. Vær spesielt forsiktig med 6G-brannmur (steg 11) og endring av tabellprefiks (steg 4, backup er obligatorisk). Gjennom årene med plugin-en på én million installasjoner er det ikke registrert kritiske konflikter med populære temaer og plugin-er.
Hva tilbyr premiumversjonen av AIOS utover gratisversjonen?
Tre nøkkeltillegg: tofaktorautentisering med fleksible retningslinjer (obligatorisk TFA for administratorer etter N dager, konfigurering av frekvens for ny forespørsel), skanner for skadevare med varsler fra Googles svarteliste, og landblokkering (geo-IP-tilgangsnekt). Gratisversjonen er nok til å beskytte en blogg eller bedriftsside. En nettbutikk med konfidensielle kundedata bør skaffe seg Premium.
Hva gjør jeg hvis jeg har glemt den tilpassede URL-en for innloggingssiden?
Koble til serveren via FTP/SFTP, gå til
/wp-content/plugins/all-in-one-wp-security-and-firewall/og gi plugin-mappen et midlertidig nytt navn. Dette deaktiverer AIOS og gjenoppretter standardwp-login.php. Logg inn i adminpanelet, gi mappen det opprinnelige navnet tilbake, aktiver plugin-en og sett en ny slug. For å unngå å glemme, lagre URL-en i passordbehandleren din umiddelbart når du oppretter den.
Er det verdt å konfigurere AIOS i 2026, eller finnes det bedre alternativer?
År senere er AIOS fortsatt den mest balanserte gratis WordPress sikkerhetspluginen: én million installasjoner, aktiv utvikling, jevnlige oppdateringer for nye kjerneversjoner. Alternativer som Wordfence eller Solid Security er også sterke, men tyngre.
De 16 stegene over tar 15-20 minutter. Resultat: skjult innloggingsside, tre brannmurlag, usynlig honeypot og ferdig konfigurasjon for kloning til neste nettsted.
Minimumssettet uten hvilket beskyttelse ikke kan anses som komplett:
- Grunnleggende: steg 1, 2, 9, 14, versjonsmaskering, brute-force-beskyttelse, grunnleggende brannmur og skjult innloggingsside;
- Servernivå: steg 7, 8, 10, 11, forbud mot PHP-editor, blokkering av tjenestefiler, tilleggsregler og 6G;
- Dyp beskyttelse: steg 4, 6, 12, 15, tabellprefiks, tilgangstillatelser, anti-hotlink, honeypot;
- Perimeter: steg 3, 5, 13, 16, moderering av registrering, sikkerhetskopier, 404-deteksjon, beskyttelse mot clickjacking.
Konfigurer ett nettsted, eksporter konfigurasjonen og importer på andre i løpet av ett minutt. En gang i kvartalet, sjekk AIOS → Dashbord: sikkerhetstelleren vil vise om en innstilling har «falt av» etter en kjerneoppdatering.
Et profesjonelt team av forfattere og redaktører som spesialiserer seg på å lage kvalitetsinnhold.