Què importa primer: Una campanya de rebliment amb força bruta o credencial envia grans volums a wp-registrein.php, XML-RPC o rutes d’accés personalitzades. Fins i tot els intents fallits consumeixen recursos web i PHP.
Què indica realment aquest símptoma
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.
Recull proves abans de canviar res
- Mesura el volum de sol· licitud, rutes, xarxes d’origen i agents d’usuari.
- Separar wp-registrein.php, xmlrpc.php i trànsit normal en registres.
- Comprova la saturació de PHP-FPM i les consultes de la base de dades durant l’atac.
- Confirma si algun accés ha tingut èxit o si els comptes han canviat.
Causes més habituals
- Atac de contrasenya distribuït: Moltes IP intenten credencials comunes o filtrades.
- Amplificació XML-RPC: system.multicall envolta molts intents en menys sol·licituds.
- Bypass del bot: Els atacants roten agents, adreces galetes o IPv6.
- Maneig cost de la seguretat: Cada intent desencadena un treball pesat de registre, geolocalització o base de dades.
Seqüència segura de diagnòstic i reparació
- Limitar o desafiar la ruta d’accés a nivell CDN, intermediari o servidor web.
- Deshabilita els mètodes XML-RPC no utilitzats o el punt final quan el lloc no ho necessiti.
- Neceswebu contrasenyes fortes i MFA per a comptes privilegiats.
- Revisar els inicis de sessió amb èxit, rotar les credencials exposades i invalidar sessions.
Com distingir entre les causes probables
No tractis Atac de contrasenya distribuït i Amplificació XML-RC com a causes equivalents. Moltes IP intenten credencials comunes o filtrades. En canvi, system.multicall envolta molts intents en menys sol· licituds. Per a distingir- les, usa aquestes dues comprovacions: Mesura volum de sol· licitud, rutes, xarxes d’origen i agents d’usuari; i separar wp- registrein.php, xmlrpc.php i tràfic normal en registres. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada —Limitar o desafiar la ruta d’accés a nivell CDN, intermediari o servidor web — o si has de conservar l’estat actual i ampliar la investigació.
En una web compromesa, contenir i netejar són decisions diferents. Conserva el fitxer sospitós i els registres d’accés abans d’eliminar la persistència, i gira les credencials només després de tancar la via activa. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.
Què no has de fer
No ocultis la URL d’inici de sessió com l’única defensa. Els bots poden descobrir- ho, i les integracions legítimes poden trencar- se sense reduir el risc de credencial.
Com verificar la reparació
- 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ó.
Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.
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.