¿Cómo saber si alguien entró a tu servidor sin permiso?

Publicado el 2026-10-17 por frfrand

Señales de intrusión en Linux, cambios sospechosos, registros que revisar y qué hacer sin destruir evidencias.

Tu web sigue funcionando, el dominio abre y nadie se quejó. ¿Eso demuestra que tu servidor está seguro? No necesariamente. Algunas intrusiones interrumpen todo; otras intentan pasar desapercibidas.

Saber si alguien entró sin permiso consiste en buscar señales, contrastarlas y determinar qué sucedió. No existe un único comando que te garantice que el sistema nunca fue comprometido.

¿Cuáles son las señales más comunes?

Una de las primeras pistas son los accesos que nadie reconoce. Por ejemplo, una sesión administrativa iniciada desde una ubicación inesperada o en un horario en el que nadie del equipo estaba trabajando.

Otra pista son usuarios nuevos o permisos cambiados. Si aparece una cuenta que tu equipo no creó, o una aplicación obtiene permisos que no necesitaba, merece una revisión.

También pueden aparecer procesos desconocidos consumiendo CPU, conexiones salientes extrañas, tareas programadas nuevas, archivos modificados sin motivo o alertas de seguridad del proveedor.

Pero cuidado: cada una de esas señales tiene explicaciones legítimas. Un pico de CPU puede ser una copia de seguridad. Un acceso desde otra IP puede ser alguien utilizando una VPN. Lo importante es investigar, no asumir.

¿Por dónde empezar en Linux?

Si tenés una sospecha, lo primero es evitar cambios impulsivos. Antes de reiniciar o borrar archivos, reuní información sobre qué ocurrió y cuándo.

En un sistema con permisos adecuados, podés comenzar por preguntas como estas:

• ¿Qué personas deberían tener acceso administrativo?
• ¿Se crearon usuarios, claves SSH o tareas programadas recientemente?
• ¿Qué aplicaciones y procesos deberían estar activos?
• ¿Hay conexiones o destinos de red que el servicio no necesita?
• ¿Los registros muestran fallos repetidos de autenticación o inicios de sesión inesperados?

En Ubuntu, los registros de autenticación pueden aparecer en los archivos del sistema o en el journal, según la configuración. Herramientas como journalctl y last pueden ayudar a reconstruir actividad, pero no son una prueba definitiva. Un atacante con privilegios elevados podría haber manipulado registros locales.

Un ejemplo sencillo

Imaginá un VPS que ejecuta una web y una base de datos. De pronto, el procesador permanece al 100 % durante la madrugada y aparece un proceso con un nombre que el equipo desconoce.

No significa automáticamente que haya un atacante. Primero comparás el proceso con los despliegues recientes, las tareas programadas y el software instalado. Si no hay una explicación válida, investigás su origen y conexiones.

Si además encontrás una clave SSH desconocida añadida a una cuenta privilegiada, el nivel de sospecha aumenta mucho. Las señales combinadas suelen ser más útiles que una sola anomalía.

¿Qué hago si creo que el servidor está comprometido?

La prioridad es contener el riesgo sin destruir evidencias. Según el impacto, puede ser necesario aislar la máquina de ciertos accesos, preservar registros y capturar información útil antes de eliminar procesos.

En una empresa, lo adecuado es activar un plan de respuesta a incidentes o buscar ayuda especializada. Cambiar contraseñas desde un equipo posiblemente comprometido o restaurar sin investigar puede dejar el problema activo.

Después hay que revisar credenciales, tokens, claves de servicio, otros sistemas relacionados y posibles filtraciones. Una recuperación confiable puede exigir reconstruir la máquina desde una imagen limpia y restaurar datos verificados, no simplemente borrar un archivo sospechoso.

¿Cómo reducir la posibilidad de que vuelva a pasar?

Aplicá actualizaciones, limitá privilegios y accesos, utilizá autenticación fuerte, revisá servicios expuestos y mantené backups probados. También conviene centralizar registros importantes fuera de la propia máquina para que una intrusión no los borre fácilmente.

¿Cómo se relaciona con ArduMaker?

Los VPS administrados en ArduMaker también ejecutan procesos, cuentas y servicios que conviene supervisar. El panel puede facilitar la operación, pero no sustituye las buenas prácticas de acceso, revisión y respuesta a incidentes.

En una frase: para saber si alguien entró a tu servidor, necesitás comparar la actividad real con lo que debería estar ocurriendo. No se trata de buscar una pantalla roja que diga «hackeado», sino de investigar pruebas y actuar con orden.

Referencia: Guía de respuesta a ransomware de CISA.