Hopp til innhold
noen
Kontakt oss
Siden er treg eller ustabil

Roboter som hamrer på wp-login.php og xmlrpc.php

Automatiske innloggingsforsøk pågår døgnet rundt og kan gjøre siden treg og ustabil. Slik ser du dem i loggen, og slik stenger du dem ute.

Du trenger
Hostingpanel
Oppdatert

Alle WordPress-sider får automatiske innloggingsforsøk. Roboter prøver vanlige brukernavn, e-postadresser de har samlet inn fra kontaktsider, og lekkede passord på wp-login.php og xmlrpc.php. Brukernavnene kan de også hente fra WordPress selv, via forfatterarkivene (/?author=1) og REST API-et (/wp-json/wp/v2/users). Robotene kan sende flere forsøk i sekundet fra mange IP-adresser samtidig. Hvert forsøk laster WordPress og gjør et oppslag i databasen, så selv om ingen kommer inn, kan pågangen gjøre siden treg eller ustabil.

Med et sterkt passord kommer robotene neppe inn, men belastningen er et problem i seg selv. I tilgangsloggen ser du om siden din får slike forsøk. Jo tidligere du stopper dem, jo mindre arbeid får serveren.

Begrens antall forsøk med en utvidelse

En utvidelse som Limit Login Attempts Reloaded eller Wordfence blokkerer IP-adresser etter et visst antall mislykkede innlogginger. Limit Login Attempts Reloaded dekker både wp-login.php og XML-RPC.

  1. Installer en av dem under Utvidelser og aktiver den. Bruk bare én slik utvidelse om gangen.
  2. La standardinnstillingene stå til å begynne med.
  3. Gå til Brukere og sjekk at ingen administratorer har brukernavnet admin. Be også alle om å bruke sterke passord. Med Wordfence kan du i tillegg slå på totrinnsbekreftelse.
  4. Bruker du Wordfence, slår du på innstillingen under Brute Force Protection som hindrer at brukernavn hentes ut via /?author=N og REST API-et.

Utvidelsen stopper gjettingen, men serveren må fortsatt kjøre PHP for hver forespørsel. Når pågangen er stor, må du stoppe forespørslene før de når WordPress.

Steng xmlrpc.php

XML-RPC er et eldre grensesnitt for publisering fra apper og andre tjenester. Jetpack trenger det for å koble siden til WordPress.com. Hvis du ikke bruker Jetpack eller en annen tjeneste som kobler seg til via XML-RPC, kan du stenge filen helt.

Hvor du stenger filen, kommer an på hvilken webserver siden kjører på.

Legg dette øverst i .htaccess i rotmappen, der wp-config.php ligger:

<Files "xmlrpc.php">
    Require all denied
</Files>

Sjekk ved å åpne https://dittdomene.no/xmlrpc.php i nettleseren. Før endringen står det XML-RPC server accepts POST requests only. på siden, og etterpå får du en feilside om at tilgangen er nektet. Står teksten der fortsatt, virker ikke regelen på serveren din.

Mange guider anbefaler heller filteret xmlrpc_enabled. Filteret slår bare av XML-RPC-metodene som krever innlogging, og WordPress lastes fortsatt ved hver forespørsel.

Begrens tilgangen til wp-login.php

wp-login.php kan du ikke stenge, for det er der du logger inn. Har alle som skal logge inn, fast IP-adresse, kan du begrense tilgangen til de adressene. Bytt ut adressen i eksempelet med din egen. Ligger siden bak Cloudflare, må serveren være satt opp til å se den ekte IP-adressen, ellers stenger regelen ute alle, også deg.

Legg dette i .htaccess:

<Files "wp-login.php">
    Require ip 192.0.2.10
</Files>

Den dagen du bytter nett eller får ny IP-adresse, kommer du ikke inn før regelen er endret. Regelen stenger også ute alle andre som trenger wp-login.php: besøkende får ikke åpnet passordbeskyttede innlegg, og ingen kan tilbakestille passordet sitt fra en annen IP-adresse. Løsningen passer derfor bare når det er du og kollegene dine som logger inn, og ingen innlegg er passordbeskyttet.

Flytt innloggingssiden

Hvis du ikke har fast IP-adresse, kan du i stedet flytte innloggingssiden til en adresse robotene ikke kjenner, for eksempel med utvidelsen WPS Hide Login. Da får robotene en feilside når de åpner wp-login.php, og du logger inn på den nye adressen. Skriv ned adressen. Hvis du glemmer den, må du skru av utvidelsen via FTP for å komme inn igjen.

Se forsøkene i tilgangsloggen

Tilgangsloggen (access log) viser alle forespørsler til siden. Du laster den ned fra hostingpanelet.

  1. Last ned loggen for det siste døgnet.
  2. Søk etter POST /wp-login.php og POST /xmlrpc.php. Med SSH kan du telle linjene slik:
grep -c "POST /wp-login.php" access.log
grep -c "POST /xmlrpc.php" access.log
  1. Se på tidspunktene og IP-adressene. Hundrevis av slike linjer i timen som ikke kommer fra deg eller kollegene dine, er roboter.

Sammenlign tidspunktene med når siden har vært treg. Stemmer de overens, har du funnet årsaken.

Når tiltakene ikke strekker til

Kommer forsøkene fra tusenvis av adresser, eller er siden fortsatt treg med utvidelsen og tiltakene over på plass, må du stoppe trafikken før den når serveren. Det gjør du med en brannmur hos webhotellet eller en tjeneste som Cloudflare foran siden. Til det trenger du tilgang til hostingpanelet eller DNS. Be hostingleverandøren gå gjennom tilgangsloggen sammen med deg.

Med Cloudflare foran siden kan du lage en egendefinert WAF-regel som gir alle som åpner wp-login.php, en robotsjekk (Managed Challenge):

http.request.uri.path eq "/wp-login.php"

Da stopper Cloudflare robotene før de når serveren, mens du selv må gjennom sjekken før du logger inn.

Passer ikke svaret?

Beskriv problemet for Howdy, så finner du riktig artikkel.