Beskyt WordPress-login mod brute force – i fire lag

Kort svar: Brute force mod wp-login.php og xmlrpc.php rammer alle WordPress-sites – konstant og automatiseret. Forsvaret bygges i fire lag: stærke, unikke kodeord og 2FA (gør gætteri meningsløst), begrænsning af login-forsøg (gør det langsomt), blokering af xmlrpc, hvis den ikke bruges (lukker bagvejen), og rate limiting på kanten eller serveren, så støjen slet ikke når PHP. Målet er ikke nul forsøg i loggen – det er nul chance for indbrud og minimal serverbelastning.

Fagligt gennemgået: 2. oktober 2026

Åbn accessloggen på et hvilket som helst WordPress-site, og du finder dem: endeløse POST-forsøg mod login fra skiftende IP-adresser. Det er sjældent målrettet – det er internettets baggrundsstøj af botnet, der prøver kendte kodeord overalt.

Denne guide bygger forsvaret nedefra: først det, der gør angrebet nytteløst, så det, der gør det dyrt – og til sidst det, der fjerner støjen helt. Hvert lag kan indføres for sig, men det er kombinationen, der gør sitet roligt.

Før du ændrer noget: Sørg for, at du har en anden vej ind end wp-admin, før du slår login-begrænsning eller blokeringer til – fx SFTP- eller kontrolpaneladgang til at omdøbe et plugin. Notér dine egne faste IP-adresser, og test altid fra et privat vindue, mens du stadig er logget ind i et andet. Så kan en for stram regel rulles tilbage på få minutter.

Kend fjenden: sådan ser angrebet ud

To ting er værd at forstå. Angrebene kommer fra mange IP-adresser (botnet), så ren IP-blokering er et hamsterhjul. Og de gætter typisk kendte, lækkede kodeord og oplagte brugernavne (admin, firmanavnet, domænenavnet). Det dikterer forsvaret: gør gættene værdiløse først, og bekæmp derefter mængden.

Du kan selv se omfanget, hvis du har adgang til accessloggen via SFTP, kontrolpanel eller SSH. Denne kommando tæller POST-forsøg mod login og xmlrpc pr. IP-adresse og viser de 10 mest aktive:

grep -E '"POST /(wp-login|xmlrpc)\.php' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

Mønsteret er typisk mange adresser med få forsøg hver – ikke én adresse med tusindvis. Det er netop derfor, en IP-baseret låsning alene ikke er nok, og hvorfor lag 1 er det vigtigste. Ligger sitet bag Cloudflare, viser loggen Cloudflares adresser, medmindre serveren er sat op til at gendanne de rigtige IP-adresser.

1. Gør gætteri meningsløst

Fundamentet: unikke, lange kodeord fra en adgangskodehåndtering (aldrig genbrug fra andre tjenester – det er netop lækkede kodeord, botterne prøver), ingen konti med brugernavnet „admin“, og 2FA på alle med redaktør- eller administratoradgang. Med lag 1 alene er brute force reelt besejret – selv det rigtige kodeord åbner ikke døren uden den anden faktor. Resten af lagene handler om belastning og støj.

Brugernavne er ikke hemmelige

Mange tror, at et skjult brugernavn er en beskyttelse. Det er det kun i begrænset grad, fordi WordPress viser brugernavne flere steder som standard:

• /?author=1 omdirigerer til forfattersiden, hvor brugernavnet (slug) ofte står i URL’en.
• REST-endpointet /wp-json/wp/v2/users lister brugere, der har udgivet indhold.
• Standardfejlbeskeden ved login afslører, om brugernavnet findes, eller kun kodeordet er forkert.

Du kan begrænse det med et sikkerhedsplugin (generisk fejlbesked, blokering af forfatteroptælling) – men regn altid med, at brugernavnet er kendt. Sikkerheden skal ligge i kodeord og 2FA, ikke i navnet.

Applikationsadgangskoder går uden om 2FA

WordPress har siden version 5.6 haft applikationsadgangskoder, som eksterne tjenester bruger til REST API og XML-RPC. De er lange og tilfældigt genererede, så de kan ikke gættes – men de omgår 2FA, fordi de er beregnet til maskiner. Gennemgå derfor under hver brugers profil, hvilke applikationsadgangskoder der findes, og tilbagekald dem, der ikke længere bruges. Bruger ingen integration funktionen, kan mange sikkerhedsplugins slå den helt fra.

2. Begræns forsøgene

Et limit-login-plugin (eller sikkerhedspluginets modul) låser en IP ude efter fx fem fejlslagne forsøg med stigende karantæne. Det stopper de nærgående angreb fra få adresser og gør de store langsomme.

To indstillinger afgør kvaliteten. Karantænen skal være stigende (fx 5 minutter → 1 time → et døgn), og pluginet skal se de rigtige IP-adresser – bag Cloudflare uden IP-gendannelse låser du ellers proxyens adresser ude og dermed alle besøgende. Undgå permanent selvlåsning: whitelist dine egne faste IP-adresser, og hav nødudgangen i baghovedet.

Vælg ét værktøj til opgaven. To plugins, der begge tæller og låser, giver uforudsigelige karantæner og gør fejlfinding svær. Har du allerede et sikkerhedsplugin med login-beskyttelse, så brug det modul frem for at installere endnu et.

3. Luk xmlrpc-bagvejen

xmlrpc.php er et ældre API, der stadig svarer på login – og metoden system.multicall kan samle hundredvis af kodeordsforsøg i ét request, uden om en login-begrænsning, der kun tæller requests. Den klassiske bruger var Jetpack og ældre app-integrationer; moderne værktøjer bruger typisk REST API.

Tjek først accessloggen for legitime kald (fx fra en app, Jetpack eller en publiceringstjeneste). Bruger intet i din opsætning den, så blokér filen. Det kan gøres i sikkerhedspluginet, som en WAF-regel på kanten eller i .htaccess på Apache og LiteSpeed:

# Bloker xmlrpc.php (Apache 2.4-syntaks, læses også af LiteSpeed)
<Files xmlrpc.php>
    Require all denied
</Files>

Alternativet er filteret add_filter( 'xmlrpc_enabled', '__return_false' ); i et lille must-use-plugin. Vær opmærksom på, at det kun slår de metoder fra, der kræver login – filen svarer stadig, og pingbacks behandles fortsat i PHP. En blokering på server- eller kantniveau er derfor mere effektiv mod belastningen. Test integrationerne efter blokeringen.

4. Stop støjen på kanten

Lag 2 og 3 arbejder i PHP – hvert afvist forsøg koster stadig serverkraft. Kanten fjerner selv dén omkostning. En Cloudflare-regel med rate limiting eller Managed Challenge på login-stien stopper botterne, før de rammer serveren. Rate limiting-regler findes også på Cloudflares gratisplan i en begrænset udgave; antal regler og muligheder afhænger af planen. Challenge-guiden viser balancen, så mennesker ikke generes.

Uden Cloudflare kan beskyttelsen ligge på serveren, fx i webserverens eller firewallens egne regler. Spørg din hostingudbyder, hvad der er aktivt på serverniveau, og om du selv kan påvirke det. Effekten ses direkte i loggen: fra en lind strøm til næsten stilhed – og på travle sites også på svartiderne.

En god kantregel rammer kun POST-requests mod /wp-login.php og /xmlrpc.php. Undlad at udfordre hele /wp-admin/, da admin-ajax.php bruges af mange frontend-funktioner, fx formularer og WooCommerce.

Lagene samlet

Lag	Hvad det stopper	Hvor det virker	Typisk faldgrube
1. Kodeord og 2FA	Selve indbruddet	WordPress-brugerne	Gamle konti og applikationsadgangskoder uden 2FA
2. Login-begrænsning	Mange forsøg fra få adresser	PHP (plugin)	Ser proxyens IP i stedet for besøgendes
3. Blokering af xmlrpc	Multicall-forsøg og bagvejen	Server, plugin eller kant	Ødelægger en integration, der faktisk bruger den
4. Rate limiting på kanten	Belastningen fra botnet	Cloudflare eller server	Rammer admin-ajax eller rigtige brugere

Verifikation

Forsvaret står, når du kan sætte flueben ved disse punkter:

• Et testforsøg med forkert kodeord låses ude efter grænsen – fra en IP, der ikke er whitelistet.
• xmlrpc.php svarer 403 (eller er bevidst åben for en dokumenteret integration).
• Loggen viser markant færre forsøg efter kantreglerne.
• Du selv stadig kan logge ind fra både kontor og mobilnet, og 2FA bliver krævet.
• Ingen brugere har ubrugte applikationsadgangskoder.

Du kan teste xmlrpc-blokeringen med curl. Forventet svar er 403:

curl -s -o /dev/null -w "%{http_code}\n" -X POST https://ditdomæne.dk/xmlrpc.php

Kig i login-loggen månedligt. Et pludseligt mønsterskifte – fx mange forsøg på ét specifikt, eksisterende brugernavn – er signalet om et målrettet angreb. Så er det godt at vide, at lagene allerede står.

Læs også

• Hub: WordPress sikkerhed og backup
• Totrinslogin (2FA) i WordPress
• Stop spam-brugeroprettelser
• Rigtige IP-adresser bag Cloudflare
• Sikker hosting: krav og tjekliste
• WordPress login: find login-siden og log ind
• WordPress serviceaftale – opdateringer, backup og sikkerhedsscanning på abonnement

Ofte stillede spørgsmål om brute force

Skal jeg flytte login-URL’en?

Valgfrit – det reducerer støj, men stopper ikke målrettede angreb og skal huskes i alle undtagelser og guides. Lagene ovenfor virker uanset URL; flyt kun, hvis støjreduktionen er målet.

Er de mange forsøg i loggen tegn på, at vi er udvalgt?

Nej – det er baggrundsstøj, alle WordPress-sites får. Bekymringen gælder mønsterskift: mange forsøg på ét bestemt, eksisterende brugernavn eller forsøg parret med phishing mod teamet.

Kan hostingen ikke bare klare det hele?

Serverlaget, fx firewall og rate limiting, er hostingens del – spørg din udbyder, hvad der er aktivt. Men kodeord, 2FA og brugerdisciplin bor hos jer; ingen kant kan redde et genbrugt kodeord uden 2FA.

Hjælper en CAPTCHA på login-siden?

Den stopper en del simple botter, men ikke angreb via xmlrpc.php, og den kan genere rigtige brugere. Se den som et supplement til 2FA og login-begrænsning, ikke som en erstatning.

Skal jeg slå applikationsadgangskoder fra?

Hvis ingen integration bruger dem, ja – de omgår 2FA, fordi de er beregnet til maskiner. Bruges de, så giv hver integration sin egen adgangskode og tilbagekald den, når integrationen stopper.