Kort svar: Brute force mod wp-login.php og xmlrpc.php rammer alle WordPress-sites – konstant og automatiseret. Forsvaret bygges i lag: stærke, unikke kodeord + 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 (Cloudflare/server), så støjen slet ikke når PHP. Målet er ikke nul forsøg i loggen – det er nul chance og minimal serverbelastning.
Å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 ikke 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.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt med anonymiserede adresser.
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). Det dikterer forsvaret: gør gættene værdiløse først, og bekæmp derefter mængden.
Fundamentet: unikke, lange kodeord fra en adgangskodehåndtering (aldrig genbrug fra andre tjenester – det er LÆKKEDE kodeord, botterne prøver), ingen konti med brugernavnet “admin”, og 2FA på alle med adgang. Med lag 1 alene er brute force reelt besejret – selv det rigtige kodeord åbner ikke døren. Resten af lagene handler om belastning og støj.
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 (5 min → 1 time → døgn), og pluginet skal se de rigtige IP-adresser – bag Cloudflare uden IP-gendannelse banner du ellers proxyen og dermed alle. Undgå permanent selvlåsning: whitelist dine egne faste IP-adresser, og hav nødudgangen i baghovedet.
xmlrpc.php er et ældre API, der stadig svarer på login – og som kan multiplexe hundredvis af kodeordsforsøg i ÉT request, udenom login-begrænsningen. Bruger intet i din opsætning det (den klassiske bruger var Jetpack og ældre app-integrationer – moderne apps bruger REST), så blokér filen: via sikkerhedspluginet, en .htaccess-regel eller en WAF-regel på kanten. Tjek først accessloggen for legitime kald til den – og test integrationerne efter blokeringen.
Lag 2-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 (challenge-guiden viser balancen, så mennesker ikke generes) – og på serverniveau bidrager hostingens egen beskyttelse. Effekten ses direkte i loggen: fra en lind strøm til næsten stilhed – og på travle sites også på svartiderne.
Forsvaret står, når et testforsøg med forkert kodeord låses ude efter grænsen, xmlrpc.php svarer 403 (eller er bevidst åben for en dokumenteret integration), loggen viser markant færre forsøg efter kant-reglerne – og du selv stadig kan logge ind fra både kontor og mobilnet. Kig i login-loggen månedligt: et pludseligt mønsterskifte (forsøg på ÉT specifikt brugernavn) er signalet om målrettet angreb – og så er det godt at vide, at lagene allerede står.
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.
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.
Serverlaget (firewall, rate limiting) er hostingens del – og den står på Hostious. Men kodeord, 2FA og brugerdisciplin bor hos jer; ingen kant kan redde et genbrugt kodeord uden 2FA.
