Lecciones de una intrusión real en servidores: 8 hábitos que protegen la infraestructura de hosting
Hace poco investigamos una intrusión en la infraestructura de gestión de una empresa de hosting. No tuvo nada de exótico: ningún exploit de día cero, ninguna herramienta de nivel estatal. Fue una cadena de hábitos corrientes, cada uno inofensivo por sí solo, que en conjunto dieron a un atacante acceso silencioso durante más de una semana. Aquí explicamos cómo se desarrolló, qué lo delató finalmente y los ocho hábitos que lo habrían detenido en casi todos los pasos.
Cómo se desarrolló la intrusión
- Una contraseña de root compartida. Varios servidores, entre ellos un servidor de gestión y un servidor de salto (jump host), usaban la misma contraseña de root, y se permitía el inicio de sesión SSH con contraseña.
- Un primer inicio de sesión silencioso. El atacante inició sesión una vez con esa contraseña y dejó abierto un túnel SSH. Un túnel no abre ninguna terminal, así que nunca apareció en
who. Permaneció abierto durante nueve días. - Una segunda fase ruidosa. Más de una semana después, varias IP iniciaron sesión con la misma contraseña, añadieron sus propias claves SSH, crearon servicios systemd y tareas cron, y dejaron una web shell en el sitio web.
- Rastros ocultos. El atacante retrasó una semana la fecha de modificación de los archivos para que los nuevos parecieran antiguos, usó una web shell de un solo uso que se borraba a sí misma y dejó un archivo PHP oculto en
/tmp. - El descubrimiento. Se detectó porque el propietario pidió una revisión de seguridad rutinaria y el registro de inicios de sesión mostró accesos de root con contraseña desde IP que nadie reconocía.
8 hábitos que rompen la cadena
1. Solo claves, y ninguna contraseña reutilizada
Desactive el inicio de sesión SSH con contraseña y dé a cada persona su propia clave. Así, una contraseña filtrada no sirve de nada y una credencial robada nunca abre todas las máquinas. Consulte configurar el inicio de sesión SSH con clave.
2. Trate los servidores de salto y de gestión como las joyas de la corona
Un servidor de salto o de gestión puede llegar a todo lo demás, lo que lo convierte en el objetivo más valioso. Asígnele credenciales propias, el firewall más estricto y la vigilancia más cercana. Si alguna vez se ve comprometido, reconstrúyalo en lugar de limpiarlo.
3. Reciba una alerta por cada inicio de sesión
El túnel estuvo activo nueve días porque nadie fue avisado del inicio de sesión. Un mensaje de Telegram por cada inicio de sesión en SSH y en el panel hace que una IP desconocida destaque al instante. Configurarlo lleva unos diez minutos: auditar los inicios de sesión con alertas de Telegram.
4. Busque conexiones, no solo sesiones
Revise ss -tnp en busca de conexiones SSH de larga duración desde IP desconocidas, no solo who. Los túneles y las sesiones SFTP son invisibles para los comandos habituales.
5. Autenticación de dos factores en todos los paneles
Los paneles de hosting, los sistemas de facturación y los paneles de control de servidores guardan las llaves de todo. Active la verificación en dos pasos y limite las páginas de administración a IP conocidas cuando sea posible. Para aaPanel, consulte la guía de seguridad de aaPanel.
6. No confíe en las fechas de los archivos
Las fechas de modificación son fáciles de falsificar. Cuando busque archivos plantados, use la fecha de cambio (change) y la fecha de creación (birth), que un proceso normal en espacio de usuario no puede retroceder:
find /var/www /tmp /dev/shm -newerct "-14 days" -type f 2>/dev/null
stat /path/to/suspicious.php # compare Modify with Change and Birth7. Cierre lo que no necesita estar abierto
Los puertos de bases de datos, los puertos de paneles y las rutas de administración no deberían estar expuestos a todo internet. Permita solo sus propias IP, ponga los sitios web detrás de un proxy que oculte el origen y mantenga la política predeterminada del firewall en denegar. Consulte ocultar la IP de origen con Cloudflare.
8. Tras un incidente, renueve todo y conserve las pruebas
Detenga las sesiones activas, pero copie los registros y los archivos sospechosos a un lugar seguro antes de borrar nada. Después renueve todas las contraseñas, claves y tokens de API a los que tenían acceso las máquinas comprometidas, incluidas las credenciales de bases de datos y de pasarelas de pago. Encontrará una lista completa de limpieza en cómo comprobar si un servidor Linux ha sido hackeado.
Lo que le ofrece una buena infraestructura cuando algo sale mal
La contención depende del control que tenga antes de que algo salga mal. En los servidores dedicados de IMIDC puede acceder a la pantalla del servidor mediante la consola VNC incluso después de bloquear todo lo demás con el firewall, arrancar un sistema de rescate para inspeccionar los discos sin conexión y reinstalar un servidor en el que ya no confía, todo usted mismo desde el área de clientes (consulte la guía del panel de control del servidor dedicado). Nuestro equipo de soporte 24/7 le ayuda con la revisión de registros y la limpieza cuando necesita una segunda opinión.
Autocomprobación en 10 minutos
grep "Accepted password" /var/log/auth.log* | tail # any password logins?
ssh-keygen -lf /root/.ssh/authorized_keys # do you know every key?
ss -tnp | grep sshd # unknown long-lived connections?
crontab -l; ls /etc/cron.d /etc/systemd/system # anything you did not add?
find /tmp /var/tmp /dev/shm -name ".*" -type f # hidden files in temp dirs?Si algo le resulta desconocido, deténgase e investigue antes de seguir cambiando cosas. Abra un ticket y el equipo de IMIDC le ayudará a resolverlo.