Qué importa primero: El servidor puede desactivar HTTP, PHP, correo o toda la cuenta después de detectar malware, phishing, spam o abuso de recursos. Las rutas de muestreo del proveedor y fecha y horas son pruebas iniciales, no un inventario completo.
Qué indica realmente este síntoma
Restaurar un sitio web de una copia de seguridad antigua puede sobrescribir logs útil o reintroducir el componente vulnerable. Coordine la evidencia, fuente limpia y alcance de toda la cuenta.
Recopila pruebas antes de cambiar nada
- Solicita la razón exacta de detección del proveedor, rutas de muestreo y fecha y horas.
- Obtener una copia de seguridad completa de archivo/base de datos y acceso/correo logs antes de la eliminación.
- Inventario de cada sitio, subdominio, trabajo cron y usuario bajo la cuenta servidoring.
- Identifica si la suspensión también bloquea la base de datos, SFTP o el correo saliente.
Causas más habituales
- Archivos maliciosos: Las firmas del escáner o el comportamiento identifican conchas web, phishing o código spam.
- Tráfico abusivo: La cuenta envía spam, ataques o peticiones excesivas.
- Desglose por cuenta compartida: Un sitio comprometido modifica a otros bajo el mismo usuario.
- Punto de entrada sin parches: Un componente vulnerable sigue instalado en las copias de seguridad.
Secuencia segura de diagnóstico y reparación
- Trabajar desde una copia conservada y paquetes limpios de confianza.
- Limpie todos los sitios y la persistencia a nivel de servidor en la cuenta.
- Rotar servidoring, SFTP, base de datos, WordPress y credenciales de correo.
- Presente la evidencia solicitada por el proveedor y Mantén el monitoreo después de la reactivación.
Cómo distinguir entre las causas probables
No trates Archivos maliciosos y Tráfico abusivo como causas equivalentes. Las firmas del escáner o el comportamiento identifican conchas web, phishing o código spam. En cambio, la cuenta envía spam, ataques o peticiones excesivas. Para distinguirlas, usa estas dos comprobaciones: Solicita la razón exacta de detección del proveedor, rutas de muestreo y fecha y horas; y obtener una copia de seguridad completa de archivo/base de datos y acceso/correo logs antes de la eliminación. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Trabajar desde una copia conservada y paquetes limpios de confianza— o si debes conservar el estado actual y ampliar la investigación.
En una web comprometida, contener y limpiar son decisiones distintas. Conserva el archivo sospechoso y los registros de acceso antes de eliminar la persistencia, y rota las credenciales solo después de cerrar la vía activa. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No pida reactivación mientras los archivos inexplicables, usuarios o paquetes vulnerables permanecen. Una segunda suspensión puede llegar rápidamente y reducir la confianza del proveedor.
Cómo verificar la reparación
- El proveedor confirma que la cuenta está limpia y reactivada.
- Todos los sitios alojados pasan integridad y la revisión del usuario/cron.
- No se devuelve ningúna señal malware, spam o de abuso de recursos.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.