Tutoriales de VPS
VPS comprometido: lista de respuesta de las primeras 24 horas (2026): ¿desconectar primero o preservar pruebas primero?
Cuando muchas personas sospechan que su VPS ha sido comprometido, su primera reacción es apagarlo, reiniciarlo o cambiar contraseñas. Pero el verdadero peligro a menudo no es actuar demasiado lento, sino hacerlo en el orden equivocado. Centrado en la pregunta clave de "¿desconectar primero o preservar pruebas primero?", este artículo ofrece una lista de respuesta para las primeras 24 horas más adecuada para escenarios Linux/VPS, que te ayuda a detener la hemorragia primero, preservar pruebas después y luego decidir si reconstruir o restaurar.
Cuando muchas personas sospechan por primera vez que su VPS puede haber sido comprometido, solo les quedan dos pensamientos en la cabeza:
- Apagarlo de inmediato
- Cambiar las contraseñas de inmediato
Ambas acciones suenan razonables, pero cuando estás realmente en la escena del incidente, equivocarte en el orden es más peligroso que no hacer nada.
Porque en las primeras 24 horas tras un compromiso, lo más difícil no es "saber qué hacer", sino juzgar:
- ¿Debo desconectar la red de inmediato?
- ¿Puedo reiniciar directamente?
- ¿Debo preservar pruebas primero o restaurar el negocio primero?
- ¿Cambiar las contraseñas cuanto antes es mejor?
- ¿Se puede seguir confiando en esta máquina?
Este artículo está dedicado a resolver estas preguntas.
No te daré una respuesta de una sola línea como "reinstala el sistema en cuanto notes algo anormal". En su lugar, te daré una lista de respuesta para las primeras 24 horas más adecuada para escenarios de VPS / servidor Linux: controlar el riesgo primero, preservar pruebas después y luego decidir si reconstruir o restaurar.
Si solo recuerdas una frase, recuerda esta:
Tras sospechar un compromiso del VPS, prioriza aislar la red en lugar de reiniciar o apagar de inmediato.
¿Por qué?
Porque una vez que directamente:
- Apagas
- Reinicias
- Matas procesos a la fuerza
- Eliminas archivos de inmediato
Puedes perder simultáneamente varios de los tipos de pruebas más críticos:
- Procesos maliciosos en memoria
- Conexiones de red actuales
- Estado de la sesión del atacante
- Claves temporales, tokens, información de descifrado
Por otro lado, si no haces nada y dejas el servidor en línea, el atacante puede seguir:
- Moviéndose lateralmente
- Llamando de vuelta continuamente
- Borrando registros
- Robando más datos
Así que el enfoque correcto normalmente no es una elección binaria de "apagar o no", sino:
- Aislar la red primero
- Luego preservar pruebas clave
- Luego juzgar si es contención a corto plazo, investigación a largo plazo o reconstrucción directa
Esta es la pregunta más importante de todo el artículo.
Para la mayoría de los incidentes de VPS, el orden más seguro es:
- Primero cortar el acceso a la red pública
- Pero intentar mantener el sistema encendido y sin reiniciar
Esto significa que lo que deberías hacer se parece más a:
- Ajustar temporalmente los grupos de seguridad / firewalls en la consola del proveedor de la nube
- Bloquear nuevo acceso entrante
- Cortar las conexiones salientes sospechosas tanto como sea posible
- Si es necesario, desconectar la instancia de la red pública
En lugar de directamente:
rebootshutdown now
Si ya ves las siguientes señales, aislar la red tiene prioridad sobre todo:
- Envío continuo de paquetes salientes, sospecha de atacar a otros
- Exfiltración de datos a gran escala en curso
- Escaneo lateral de la red interna
- Uso como proxy, phishing o nodo de spam
- Actividad de intrusión continua obvia en el negocio
En este punto, sin aislamiento, el daño solo seguirá expandiéndose.
Si te enfrentas a:
- Una investigación de cumplimiento
- Filtración de datos de clientes
- Necesidad de rastrear la ruta del ataque
- Sospecha de una puerta trasera persistente o intrusión avanzada
Entonces deberías contener aún más el impulso de "reiniciar de inmediato".
Porque una vez que se corta la energía, muchas pruebas volátiles desaparecen.
- Causando daño continuo → aislar la red primero
- Necesidad de preservar valor forense → no apresurarse a apagar/reiniciar
- Ambos importan → aislar la red primero, luego preservar la escena
Esta es la fase de contención más crítica.
Primero anota:
- La hora de la anomalía
- La fuente que activó la alerta
- Qué servicio es anormal
- Qué cuentas/puertos/procesos son sospechosos
Este paso parece simple, pero es muy importante después para la revisión, la comunicación y el juicio de la línea de tiempo.
Prioriza usar:
- Firewall del proveedor de la nube
- Grupos de seguridad
- Reglas de red de la consola
El objetivo es:
- Bloquear que el atacante siga conectándose
- Bloquear el tráfico saliente sospechoso
- Evitar dañar la escena tanto como sea posible
Debes contenerte en este paso.
No hagas de inmediato estas cosas por pánico:
- Antivirus de un clic
- Scripts de reparación automática
- Vaciar
/tmp - Eliminar cron
- Directamente
apt upgrade
Todos estos pueden contaminar la escena, haciendo imposible que rastrees la causa después o confirmes el alcance del impacto.
Si este VPS está ejecutando negocio de producción, debes tomar una decisión en los primeros 15 minutos:
- ¿Debe esta máquina desconectarse de inmediato?
- ¿Hay un nodo de reserva o una página de degradación estática?
- ¿Necesitas conmutar el tráfico a una máquina de respaldo?
No dejes "la continuidad del negocio" para recordarla una hora después.
Si ya sospechas que root, usuarios sudo, cuentas de despliegue o cuentas del panel están comprometidas, pausa el uso de estas cuentas para seguir operando, para evitar expandir la contaminación y evitar que el atacante use tus propias operaciones para encubrir sus rastros.
Se recomienda abrir de inmediato un registro de incidente separado:
- Quién hizo qué y cuándo
- Qué regla se cambió
- Qué registros se exportaron
- Qué anomalías se vieron
Agradecerás mucho este paso más adelante.
En escenarios Linux / VPS, lo más valioso en la primera hora no es "arreglar rápido", sino "preservar primero la escena clave".
- Lista de procesos actual
- Conexiones de red actuales
- Sesiones de inicio de sesión y actividad de usuarios
- Registros clave del sistema
- Tareas programadas, elementos de inicio, claves SSH, cambios de configuración de sudo
- Registros del servicio web, base de datos, panel, contenedores
- ¿Hay nombres de procesos anormales?
- ¿Hay relaciones sospechosas entre procesos padre e hijo?
- ¿Hay puertos en escucha desconocidos?
- ¿Hay conexiones salientes a IP desconocidas?
- ¿Hay cuentas recién creadas / claves SSH recién añadidas?
- ¿Hay tareas programadas / servicios systemd modificados?
Porque muchos comportamientos clave del atacante solo viven en el "estado de ejecución actual":
- Conexiones de llamada de vuelta
- Malware residente en memoria / código malicioso sin archivo
- Tokens temporales
- Sesiones de shell
Una vez que reinicias, estos pueden desaparecer directamente.
5. Primeras 4 horas: no te apresures a cambiar contraseñas, primero confirma "quién puede ya no ser confiable"
Cuando muchas personas descubren una intrusión, su primera reacción es:
- Cambiar la contraseña de root
- Cambiar la contraseña de la base de datos
- Cambiar la contraseña del proveedor de la nube
Esto no está mal, pero el orden puede estar mal.
Si el atacante todavía está en la máquina, o hay una puerta trasera persistente, entonces las nuevas contraseñas, tokens y claves que acabas de cambiar pueden ser obtenidas de nuevo por el atacante pronto.
Así que el orden más seguro suele ser:
- Aislar el acceso primero
- Confirmar el alcance del impacto
- Invalidar sesiones / tokens / claves primero
- Luego rotar credenciales en masa
- Contraseñas de usuarios root / sudo
- Claves SSH
- Cuentas del panel
- Cuentas de base de datos
- Credenciales de la máquina de despliegue
- Claves API / Access Tokens
- Claves de almacenamiento de objetos
- Secretos de CI/CD
Si este VPS tiene:
.env- Scripts de despliegue
- Herramientas de automatización
- GitHub Actions / GitLab Runner / webhook
Entonces lo que se filtra a menudo no es solo este servidor en sí, sino toda una cadena de credenciales aguas arriba y aguas abajo.
6. Primeras 8 horas: primero juzga "si todavía se puede arreglar" o si debería reconstruirse directamente
Este es otro punto de decisión clave.
En las siguientes situaciones, normalmente deberías tratar "reconstruir" como la ruta principal por defecto:
- root ha sido tomado
- El punto de entrada y la duración del ataque son inciertos
- Hay rastros obvios de persistencia
- Se sospechan puertas traseras a nivel de kernel / de altos privilegios
- El negocio permite la recuperación mediante copia de seguridad
- Es imposible confirmar si el sistema sigue siendo confiable
¿Por qué?
Porque la limpieza no equivale a una recuperación confiable.
Eliminar un programa de minería no significa que no haya una segunda puerta trasera; arreglar un cron no significa que no haya persistencia en systemd; restaurar un archivo no significa que el atacante no haya modificado otra cosa.
Solo cuando las siguientes condiciones son relativamente claras deberías apenas considerarlo:
- El alcance del impacto es muy pequeño
- La ruta de intrusión es clara
- No hay persistencia de altos privilegios
- Tienes suficiente confianza de que la limpieza está completa
- El negocio no se puede reconstruir a corto plazo
Aun así, es más recomendable migrar a una nueva instancia lo antes posible.
Muchos equipos piensan que "volver a levantar el sitio web" cuenta como recuperación, pero en realidad está lejos de ser suficiente.
Si la vulnerabilidad sigue ahí, los puertos siguen abiertos y los permisos no se han ajustado, el atacante solo necesita unos minutos para volver.
Restauraste la máquina, pero las claves antiguas siguen siendo válidas; eso no es muy diferente de no haber restaurado nada.
3. Olvidar limpiar en sincronía el almacenamiento de objetos, CDN y las cadenas de copia de seguridad
Los archivos maliciosos, scripts de puerta trasera y copias de seguridad contaminadas a veces no están solo en el host.
Esta es una de las ubicaciones de persistencia más comunes en VPS Linux.
Si no refuerzas la monitorización dentro de una hora después de la recuperación, entonces en realidad no sabes si el atacante ha vuelto.
Para facilitar la ejecución, puedes dividir las primeras 24 horas en los siguientes 4 segmentos.
- Registrar la fuente de la anomalía
- Aislar la red a nivel del panel de control
- Decidir si conmutar tráfico/degradar
- No reiniciar, no limpiar la escena
- Exportar registros
- Revisar procesos, puertos, conexiones
- Registrar cambios de cuentas, programación de tareas, servicios
- Conservar copias de pruebas clave
- Juzgar el alcance del impacto
- Invalidar sesiones y tokens
- Rotar credenciales de alto riesgo
- Juzgar si reconstruir directamente
- Restaurar desde copias de seguridad confiables a un nuevo entorno
- Endurecer parches, permisos, MFA, políticas de red
- Activar monitorización de alta frecuencia
- Registrar la causa raíz, la línea de tiempo y las acciones pendientes
9. Si solo tienes un VPS y no tienes un equipo de seguridad profesional, ¿cuál es el enfoque más realista?
Para la mayoría de webmasters individuales, equipos pequeños y sitios de herramientas, la ruta más realista normalmente no es "construir un laboratorio forense completo", sino:
- Aislar la red primero
- Preservar pruebas básicas tanto como sea posible
- Exportar registros y configuraciones clave
- Rotar todas las credenciales clave
- Reconstruir una nueva instancia con copias de seguridad confiables
- Mantener la máquina antigua solo como muestra de investigación, sin restaurarla directamente a producción
Este es el enfoque más equilibrado entre coste y seguridad.
Si ya tienes copias de seguridad, instantáneas y procesos de recuperación, esto será mucho más fácil. Si no, puedes leer primero estos dos artículos:
- ¿Cuál es la diferencia entre instantáneas, copias de seguridad e imágenes de VPS (2026)? No las mezcles al restaurar
- Soluciones de copia de seguridad automática de VPS (2025): protege tus datos de daños a nivel de desastre
Normalmente no se recomienda el apagado directo. La acción predeterminada más segura es aislar la red primero para evitar más daños, preservando al mismo tiempo pruebas volátiles como memoria, conexiones y sesiones tanto como sea posible.
En la mayoría de los casos, desconectar la red / aislar el acceso tiene prioridad. Porque si el atacante sigue en línea, la nueva contraseña también puede filtrarse de nuevo pronto.
Si ya están involucrados altos privilegios, persistencia o un alcance de impacto poco claro, normalmente es más recomendable reconstruir una nueva instancia en lugar de seguir confiando en el sistema antiguo.
Entonces deberías aferrarte aún más al enfoque de "aislar primero, preservar pruebas básicas, luego reconstruir". No arregles con pánico mientras destruyes toda la escena.
En las primeras 24 horas tras un compromiso del VPS, lo más peligroso no es "actuar demasiado lento", sino equivocarse en el orden.
El enfoque verdaderamente estable suele ser:
- Aislar la red primero para evitar más daños
- Preservar pruebas tanto como sea posible, no apresurarse a reiniciar
- Juzgar primero el límite de confianza, luego rotar credenciales
- Reconstruir si se puede, no creer demasiado en "ya está limpio"
En una frase:
Contener primero, luego recopilar pruebas, luego recuperar; no trates "probar a reiniciar" como respuesta a incidentes.
Si tu VPS aún no ha sido comprometido, la parte más valiosa de este artículo no es en realidad "qué hacer después", sino recordarte que te prepares con antelación:
- Copias de seguridad
- Instantáneas
- Registros
- MFA
- Runbook de recuperación
Porque cuando algo realmente sucede, lo que más te falta nunca son comandos, sino tiempo.