Si sospechas que tu servidor VPS fue hackeado, lo primero que debes hacer es aislarlo de Internet inmediatamente y no reiniciarlo — reiniciar borra evidencia crítica que necesitarás para entender cómo entraron y evitar que vuelva a pasar.
Esta guía te lleva por cada etapa de la respuesta al incidente: desde el momento en que detectas el problema hasta devolver el servidor a producción con la seguridad reforzada.
Señales de que tu VPS puede estar comprometido
Antes de entrar en pánico, confirma que realmente hay un compromiso. Las señales más comunes son:
- CPU o RAM disparadas sin causa aparente (minería de criptomonedas es el culpable más frecuente).
- Tráfico saliente inusual en horas de poca actividad.
- Usuarios o procesos desconocidos en
w,whoops aux. - Archivos modificados recientemente en directorios web (
find /var/www -newer /etc/passwd -type f). - Alertas del proveedor sobre spam o tráfico abusivo saliente.
- Contraseñas de SSH que ya no funcionan.
Si encuentras dos o más de estas señales simultáneamente, trata el servidor como comprometido y actúa.
Paso 1 — Aislar el servidor sin apagarlo
El objetivo es cortar el acceso del atacante sin destruir la evidencia forense que vive en la memoria RAM y en los archivos de log.
Desde el panel de tu proveedor VPS, activa el firewall de emergencia bloqueando todo el tráfico entrante y saliente excepto tu IP. Alternativas equivalentes:
- Bloquear todo con
iptables -I INPUT 1 -j DROP; iptables -I OUTPUT 1 -j DROPexcepto tu propia conexión SSH activa. - Poner el servidor en modo de red privada desde el panel del proveedor (opción disponible en la mayoría de las plataformas cloud).
No hagas esto:
- No reinicies el servidor — perderás procesos en memoria que revelan el ataque.
- No elimines archivos sospechosos todavía — son evidencia.
- No cambies contraseñas desde el servidor comprometido — el keylogger del atacante las capturaría.
Paso 2 — Recopilar evidencia forense
Con el servidor aislado pero encendido, documenta el estado actual. Guarda las salidas en un archivo local en tu máquina (no en el servidor comprometido).
# Procesos activos
ps auxf > procesos.txt
# Conexiones de red abiertas
ss -tulpn > conexiones.txt
# Usuarios con sesión activa
w > sesiones.txt
# Cron jobs de todos los usuarios
for u in $(cut -f1 -d: /etc/passwd); do crontab -u $u -l 2>/dev/null; done > crontabs.txt
# Archivos modificados en las últimas 24 horas
find / -not -path /proc -not -path /sys -newer /proc/1 -type f 2>/dev/null > modificados.txt
# Logs de autenticación
cp /var/log/auth.log auth.log
cp /var/log/secure secure.log
Estos datos te permitirán identificar el vector de entrada y entender el alcance del daño.
Paso 3 — Identificar el vector de ataque
Saber cómo entraron es esencial para no repetir el error en el servidor limpio. Los vectores más comunes en VPS son:
| Vector | Cómo detectarlo |
|---|---|
| Contraseña SSH débil (fuerza bruta) | Miles de intentos fallidos en auth.log seguidos de un login exitoso |
| Plugin o CMS desactualizado | Archivos PHP con shells web en directorios de uploads o plugins |
| Clave SSH comprometida | Login exitoso desde IP desconocida con clave pública |
| Software del servidor sin parche | Exploit contra versión vulnerable de Apache/Nginx/PHP visible en logs |
| Credenciales de base de datos expuestas | Acceso a MySQL desde IPs externas en el log general de MySQL |
Busca específicamente shells web con grep -r "eval(base64" /var/www y grep -r "system($_" /var/www.
Paso 4 — Decisión crítica: limpiar o reconstruir
En la mayoría de los casos, la respuesta correcta es reconstruir desde una imagen limpia, no limpiar el servidor comprometido. Las razones son técnicas:
- Un atacante hábil instala rootkits que ocultan procesos y archivos — nunca puedes estar seguro de haber eliminado todo.
- Las puertas traseras pueden estar en lugares inesperados:
cron, módulos del kernel,.bashrc, scripts de inicio. - Limpiar lleva más tiempo que reconstruir si tienes tus datos en backups.
Cuándo limpiar en lugar de reconstruir: si el ataque fue superficial (una shell web en un plugin), está claramente contenido y tienes certeza de su alcance. Incluso en ese caso, valida con un escáner como ClamAV o rkhunter antes de dar el servidor por limpio.
Si no tienes backups recientes, consulta con elenlace.com sobre las opciones de recuperación disponibles antes de tomar decisiones irreversibles.
Paso 5 — Reconstruir y endurecer la seguridad
Una vez que tienes una imagen limpia del OS y has restaurado tus datos desde el último backup verificado, aplica estas medidas antes de volver a poner el servidor en producción:
SSH
- Deshabilita la autenticación por contraseña:
PasswordAuthentication noensshd_config. - Cambia el puerto SSH del 22 a uno no estándar (reduce el ruido de bots, no es seguridad real).
- Genera un nuevo par de claves SSH — las anteriores pueden estar comprometidas.
- Activa
fail2bancon un umbral de 5 intentos fallidos y ban de 1 hora.
Firewall
- Política por defecto DROP en INPUT; abre solo los puertos que necesitas.
- Limita las conexiones SSH a rangos IP conocidos cuando sea posible.
Actualizaciones
- Actualiza el OS completo antes de instalar cualquier cosa.
- Activa actualizaciones de seguridad automáticas (
unattended-upgradesen Debian/Ubuntu,dnf-automaticen RHEL). - Actualiza todos los CMS, plugins y dependencias de aplicación.
Monitoreo post-recuperación
Instala un monitor de integridad de archivos como AIDE o Tripwire para detectar cambios no autorizados en el futuro. Consulta más recursos en nuestra sección de servidores VPS.
Conclusiones clave
- Aisla el servidor inmediatamente pero no lo reinicies — la RAM contiene evidencia vital.
- Documenta todo antes de modificar nada: procesos, conexiones, archivos recientes, logs.
- Identifica el vector de entrada antes de reconstruir para no repetir el mismo error.
- En la mayoría de los casos, reconstruir desde imagen limpia es más seguro y rápido que limpiar.
- Endurece SSH, firewall y actualizaciones automáticas antes de volver a producción.
- Los backups regulares son la diferencia entre horas de recuperación y días de pérdida.
¿Tu servidor fue comprometido y no sabes por dónde empezar? El equipo de elenlace.com ofrece asistencia de respuesta a incidentes — contáctanos y te ayudamos a recuperar el control.
Preguntas frecuentes
¿Debo notificar a mis usuarios si mi VPS fue hackeado?
Si el servidor almacenaba datos personales de usuarios (nombres, emails, contraseñas, datos de pago), la respuesta es sí — en México, la Ley Federal de Protección de Datos Personales (LFPDPPP) obliga a notificar a los titulares afectados en casos de vulneración de seguridad.
¿Cuánto tiempo tarda la recuperación de un VPS comprometido?
Con backups recientes y una imagen del OS disponible, entre 2 y 6 horas para un servidor típico. Sin backups, el proceso puede tomar días y los datos pueden no ser recuperables en su totalidad.
¿Sirve de algo instalar un antivirus en el VPS limpio?
Para servidores web, ClamAV es útil para escanear archivos subidos por usuarios. Sin embargo, no reemplaza las medidas estructurales: SSH por clave, firewall restrictivo, actualizaciones automáticas y monitoreo de integridad de archivos.
¿El proveedor de VPS puede ayudarme si fui hackeado?
La mayoría de los proveedores puede ofrecer una consola fuera de banda (acceso KVM/IPMI) cuando SSH no responde, y algunos tienen snapshots automáticos que puedes restaurar. Sin embargo, la investigación forense y el endurecimiento de seguridad son responsabilidad del administrador del VPS.
Recursos útiles
Otros proveedores y guías que vale la pena comparar:
