Què importa primer: El servidor pot deshabilitar HTTP, PHP, correu o tot el compte després de detectar malware, phishing, spam o abús de recursos. Les rutes de mostreig del proveïdor i data i hores són proves inicials, no un inventari complet.
Què indica realment aquest símptoma
Restaurar un lloc web d’una còpia de seguretat antiga pot sobreescriure registres útil o reintroduir el component vulnerable. Si us plau, editeu l’evidència, font neta i abast de tot el compte.
Recull proves abans de canviar res
- Sol· licita la raó exacta de detecció del proveïdor, rutes de mostreig i data i hores.
- Obté una còpia de seguretat completa del fitxer/base de dades i accés/corretge registres abans de l’eliminació.
- Inventari de cada lloc, subdomini, treball cron i usuari sota el compte servidoring.
- Identifica si la suspensió també bloqueja la base de dades, SFTP o el correu sortint.
Causes més habituals
- Fitxers maliciosos: Les signatures de l’escàner o comportament identifiquen petxes web, phishing o codi spam.
- Trànsit abusiu: El compte envia spam, atacs o peticions excessives.
- Desglossament per compte compartit: Un lloc compromès modifica els altres sota el mateix usuari.
- Punt d’entrada sense pegats: Un component vulnerable segueix instal· lat en les còpies de seguretat.
Seqüència segura de diagnòstic i reparació
- Treballar des d’una còpia conservada i paquets nets de confiança.
- Netegeu tots els llocs i la persistència a nivell de servidor en el compte.
- Gira el servidoring, SFTP, base de dades, WordPress i credencials de correu.
- Supresent l’evidència sol·licitada pel proveïdor i Mantén el monitoratge després de la reactivació.
Com distingir entre les causes probables
No tractis Fitxers maliciosos i Trànsit abusiu com a causes equivalents. Les signatures de l’escàner o el comportament identifiquen petxes web, phishing o codi spam. En canvi, el compte envia spam, atacs o peticions excessives. Per distingir- les, useu aquestes dues comprovacions: Sol· licita la raó exacta de detecció del proveïdor, rutes de mostreig i data i hores; i obtenir una còpia de seguretat completa de fitxer/base de dades i accés/correu registres abans de l’eliminació. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada -treballar des d’una còpia conservada i paquets nets de confiança- o si has de conservar l’estat actual i ampliar la recerca.
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 demani reactivació mentre els fitxers inexplicables, usuaris o paquets vulnerables romanen. Una segona suspensió pot arribar ràpidament i reduir la confiança del proveïdor.
Com verificar la reparació
- El proveïdor confirma que el compte està net i reactivat.
- Tots els llocs allotjats passen integritat i la revisió de l’usuari/cron.
- No es retorna cap senyal malware, spam o abús de recursos.
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
Restaurar un lloc web d’una còpia de seguretat antiga pot sobreescriure registres útil o reintroduir el component vulnerable. Si us plau, editeu l’evidència, font neta i abast de tot el compte.
- 1
Sol· licita la raó exacta de detecció del proveïdor, rutes de mostreig i data i hores.
- 2
Obté una còpia de seguretat completa del fitxer/base de dades i accés/corretge registres abans de l’eliminació.
- 3
Inventari de cada lloc, subdomini, treball cron i usuari sota el compte servidoring.
- 4
Identifica si la suspensió també bloqueja la base de dades, SFTP o el correu sortint.
Què ha de quedar verificat
- El proveïdor confirma que el compte està net i reactivat.
- Tots els llocs allotjats passen integritat i la revisió de l’usuari/cron.
- No es retorna cap senyal malware, spam o abús de recursos.
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.
He de restaurar el lloc des d’una antiga còpia de seguretat just després de la suspensió per tornar a estar en línia ràpidament?+
No immediatament. Restaura des d’una antiga còpia de seguretat podeu sobreescriure registres necessaris per identificar el punt d’entrada o reintroduir el mateix component vulnerable que va causar la suspensió en primer lloc, per la qual cosa l’evidència ha de ser preservada abans que passi qualsevol restauració.
És suficient per netejar l'únic lloc que l'amfitrió ha marcat com a maliciós?+
No. Les rutes de mostreig i marques de temps del proveïdor són un punt de partida, no un inventari complet, i d’altres llocs, subdominis, treballs de cron, o usuaris sota el mateix compte de hosting també poden veure' s compromesos o propagar la infecció.
Quan s'ha de demanar la reactivació després de netejar els fitxers marcats?+
Només després de confirmar que no hi ha fitxers inexplicables, usuaris o paquets vulnerables romanen enlloc del compte. La petició de reactivació mentre que qualsevol d'ells encara està present corre el risc que una segona suspensió arribi ràpidament, el que també redueix la confiança del proveïdor per a futurs incidents.
Una suspensió hosting sempre vol dir que s'han trobat fitxers maliciós, en comptes d’una cosa com enviar massa spam?+
No. Els amfitrions poden suspendre un compte per diverses raons diferents, incloent fitxers maliciosos, tràfic d'abús com spam o sol·licituds d'atac, o abús de recursos, i la raó exacta de detecció s’ha de sol·licitar al proveïdor en lloc de suposar.