Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Errors & Diagnosis

Hosting de WordPress suspès per malware: com recuperar la web sense perdre-la

Una suspensió servidoring és contenció per part del proveïdor. Preservar el compte, obtenir l’evidència i netejar cada lloc afectat abans de demanar la reactivació.

Una suspensió per malware canvia l’ordre de recuperació. El proveïdor ja ha contingut una part del risc, així que conserva el seu informe i prepara una base neta abans de demanar la reobertura del compte.

Recull evidència i abast del proveïdor

Guarda rutes marcades, hora de l’escaneig, motiu de la suspensió i dominis afectats. Determina si s’ha detectat un únic fitxer, un compromís de compte més ampli o abús de sortida.

Conserva una còpia recuperable abans de netejar

  • Fes una còpia offline o aïllada de fitxers i base de dades si el proveïdor ho permet.
  • Guarda mostres malicioses fora de rutes executables.
  • Registra versions de WordPress, PHP, plugins i tema.
  • Enumera altres webs que comparteixin compte o credencials.

Construeix el baseline net fora del trànsit públic

Reinstal·la core i components de confiança, classifica codi propi i elimina persistència confirmada. Contrasta canvis inesperats amb el triatge d’alertes d’integritat i el core amb checksums fiables de WordPress.

Tanca la via d’entrada abans de reactivar

  1. Actualitza o substitueix el component vulnerable.
  2. Rota credencials d’hosting, WordPress, SFTP, base de dades i APIs rellevants.
  3. Elimina administradors desconeguts i invalida sessions.
  4. Revisa permisos i directoris escrivibles.

Compleix explícitament els requisits de reescaneig

Una home que “es veu bé” no és suficient. L’escàner del proveïdor ja no ha de trobar els artefactes marcats i s’ha d’aturar qualsevol comportament de sortida abusiu.

No restauris un backup complet a cegues

Si la còpia ja conté el compromís, només tornes la incidència a un timestamp anterior.

Controls abans de tornar a servei

Reactiva quan el proveïdor accepti l’estat net, l’accés privilegiat estigui rotat, la integritat es mantingui estable i el trànsit normal no recreï els fitxers o comportaments que van provocar la suspensió.

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.

WP RepairModel de diagnòstic
1Desencadenant2Càrrega3Persistència4Via d’entrada
Segueix la cadena fins a trobar el primer punt que deixa de comportar-se com hauria de fer-ho.
  1. 1

    Sol· licita la raó exacta de detecció del proveïdor, rutes de mostreig i data i hores.

  2. 2

    Obté una còpia de seguretat completa del fitxer/base de dades i accés/corretge registres abans de l’eliminació.

  3. 3

    Inventari de cada lloc, subdomini, treball cron i usuari sota el compte servidoring.

  4. 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.

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.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència↗