Una força bruta és també un problema de capacitat: milers d’intents contra wp-login.php, xmlrpc.php o una ruta de login pròpia consumeixen workers PHP i consultes encara que cap contrasenya sigui correcta.
Mesura l’atac abans de bloquejar IPs una per una
Compta peticions per ruta, xarxa d’origen i franja temporal. Un atac distribuït pot canviar d’IP constantment, de manera que una llista manual de bloquejos acostuma a arribar tard.
Separa login normal, XML-RPC i trànsit legítim
- Volum i temps de resposta de
wp-login.php. - Peticions a
xmlrpc.phpi mètodes utilitzats. - Saturació de PHP-FPM i càrrega de base de dades.
- Usuaris objectiu i qualsevol autenticació que hagi acabat amb èxit.
Distribució de contrasenyes o amplificació via XML-RPC?
Moltes IPs provant credencials apunten a credential stuffing. En canvi, system.multicall pot concentrar molts intents dins de menys peticions XML-RPC. El control s’ha d’aplicar on es genera el cost.
Contén a la capa més barata possible
- Rate-limit o challenge al CDN, proxy o servidor web.
- Limita o desactiva mètodes XML-RPC que la web no necessita.
- Exigeix MFA i contrasenyes robustes als comptes privilegiats.
- Revisa logins correctes, invalida sessions i rota credencials exposades.
Comprova si l’atac va arribar a comprometre un compte
Si XML-RPC concentra la càrrega, continua amb l’anàlisi de mètodes XML-RPC abusats. Si hi ha un login correcte o canvis de fitxers durant l’incident, afegeix una verificació d’integritat del core.
No confiïs només en amagar la URL de login
Els bots poden descobrir rutes i les integracions legítimes poden trencar-se. Reduir el risc de credencials requereix controls d’autenticació i rate limiting.
Verificació després de contenir
La CPU i els workers han de mantenir-se estables sota trànsit hostil, els administradors legítims han de poder entrar i no ha de quedar cap sessió, canvi de rol o accés no autoritzat.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
Bloqueja una IP rara vegada és suficient perquè els atacs es distribueixen. Les taxes de sol· licitud, els noms d’usuari específics i els costos de resposta mostren on aplicar els controls.
- 1
Mesura el volum de sol· licitud, rutes, xarxes d’origen i agents d’usuari.
- 2
Separar wp-registrein.php, xmlrpc.php i trànsit normal en registres.
- 3
Comprova la saturació de PHP-FPM i les consultes de la base de dades durant l’atac.
- 4
Confirma si algun accés ha tingut èxit o si els comptes han canviat.
Què ha de quedar verificat
- La CPU i l’ús del treballador PHP romanen estables sota el tràfic d'atac.
- Els administradors legítims poden autenticar-se de manera fiable.
- No hi ha accés exitós no autoritzat, canvi de rol o nous restos de sessió.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
El bloqueig de l'IP que m'està desconnectant la meva pàgina d'inici de sessió aturarà el pic de CPU?+
Normalment, no per molt temps, perquè les campanyes de força bruta i de rebliment de credencials es distribueixen típicament a través de moltes IPs en comptes de venir d’una sola font. Limitar la velocitat o desafiar la ruta d’accés en el nivell CDN, intermediari o servidor web es dirigeix al patró en comptes de perseguir adreces individuals.
Oculta o reanomena el wp-inici de sessió.php URL soluciona el risc subjacent?+
No, això està explícitament assenyalat com insuficient. Els bots encara poden descobrir un inici de sessió reubicat URL, i ocultar-lo pot trencar integracions legítimes sense reduir en realitat el risc de credencial que va causar l’atac en primer lloc.
Poden els intents d'inici de sessió fallits per si sols causar problemes de rendiment reals, o només brechas reeixides?+
Fins i tot els intents fallits consumeixen recursos reals de la web i PHP, i part de la càrrega prové de les pròpies defenses del lloc: registre pesat, recerques de geolocalització o treball de base de dades desencadenat en cada intent pot fer cada sol·licitud més costosa del que el propi atac pretén.
Com és el forçament brut basat en XML-RC diferent del forçament brut normal de pàgina d’accés?+
L’amplificació XML-RPC usa el mètode system.multicall per empaquetar molts intents d’accés en una sola petició, de manera que pot generar molts més intents d’autenticació per petició que colpejar wp-inici de sessió.php directament. Deshabilita els mètodes XML-RPC no utilitzats o l’endpoint en si mateix és un control diferent de limitar la velocitat de la pàgina d’accés.