Cómo detectar si tu servidor Linux tiene problemas de seguridad

Detectar si un servidor Linux tiene problemas de seguridad no depende de una sola herramienta. Requiere revisar actualizaciones, accesos, logs, servicios expuestos, usuarios, tareas programadas, archivos críticos, cambios inesperados y señales de comportamiento anormal.

Un servidor puede estar en riesgo aunque siga funcionando aparentemente bien. De hecho, muchas intrusiones no buscan “romper” el sistema de inmediato, sino mantener acceso, ocultar actividad, robar información, usar recursos del servidor o preparar movimientos posteriores.

Por eso, todo administrador debe tener una rutina básica de revisión. No se trata de entrar en pánico ante cualquier error del sistema, sino de aprender a distinguir entre fallos normales, malas configuraciones, intentos de ataque y señales reales de compromiso.

1. Revisa si el servidor está actualizado

Un servidor desactualizado es una de las causas más comunes de exposición. Las actualizaciones corrigen vulnerabilidades en el kernel, OpenSSH, OpenSSL, Apache, Nginx, PHP, bases de datos, librerías y herramientas del sistema.

En Debian, Ubuntu y derivados:

sudo apt update
apt list --upgradable

En Fedora, AlmaLinux, Rocky Linux o RHEL:

sudo dnf check-update

2. Revisa intentos fallidos de acceso SSH

SSH suele ser uno de los servicios más atacados en servidores Linux. No todo intento fallido significa compromiso, pero miles de intentos, usuarios inexistentes, accesos desde países inesperados o inicios exitosos fuera de horario deben investigarse.

En Ubuntu, Debian y Linux Mint:

sudo grep "Failed password" /var/log/auth.log | tail -50
sudo grep "Accepted" /var/log/auth.log | tail -50

En RHEL, Rocky Linux, AlmaLinux y CentOS:

sudo grep "Failed password" /var/log/secure | tail -50
sudo grep "Accepted" /var/log/secure | tail -50

Para ver últimos accesos:

last -a | head -30
sudo lastb -a | head -30

3. Revisa logs del sistema con journalctl

Los logs permiten detectar fallos, reinicios inesperados, errores de servicios, intentos de autenticación, problemas de permisos, bloqueos del kernel y actividad anormal.

sudo journalctl -p warning..alert -S today
sudo journalctl -p err -S "24 hours ago"
sudo journalctl -u ssh -S today
sudo journalctl -u sshd -S today

En servidores críticos, los logs deben estar protegidos contra eliminación o manipulación. Además, deben conservarse de acuerdo con las políticas de seguridad de la organización.

4. Identifica puertos y servicios expuestos

Todo servicio abierto aumenta la superficie de ataque. Un servidor web puede necesitar 80 y 443; un servidor administrado por SSH puede requerir 22 o un puerto controlado; pero bases de datos, paneles, Redis, Elasticsearch, Docker API o servicios internos no deberían estar expuestos sin control.

sudo ss -tulpen
sudo systemctl --type=service --state=running

5. Revisa el firewall y reglas de acceso

El firewall no reemplaza una buena configuración, pero ayuda a reducir exposición. Si el servidor no tiene reglas claras, servicios internos podrían quedar accesibles desde Internet.

Con UFW:

sudo ufw status verbose

Con firewalld:

sudo firewall-cmd --state
sudo firewall-cmd --list-all

Con nftables:

sudo nft list ruleset

6. Detecta usuarios sospechosos o privilegios excesivos

Una revisión básica de usuarios puede revelar cuentas antiguas, accesos de proveedores que ya no trabajan contigo, usuarios con UID 0, cuentas sin contraseña o miembros inesperados en grupos administrativos.

getent passwd
awk -F: '$3 == 0 {print}' /etc/passwd
getent group sudo
getent group wheel

Para revisar llaves SSH autorizadas:

sudo find /root /home -name authorized_keys -type f -exec ls -l {} \;

7. Revisa procesos con consumo anormal

Procesos desconocidos, alto consumo de CPU, uso inusual de red o binarios ejecutándose desde rutas temporales pueden indicar abuso de recursos, malware, criptominería, fuga de datos o servicios mal configurados.

top
ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20

También revisa servicios fallidos:

systemctl --failed

8. Revisa tareas programadas sospechosas

Los atacantes y también algunas malas configuraciones pueden usar cron o timers de systemd para ejecutar scripts de forma recurrente. Por eso conviene revisar tareas programadas de usuarios y del sistema.

crontab -l
sudo ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly
systemctl list-timers --all

Busca scripts desconocidos, rutas extrañas, descargas automáticas, tareas que ejecutan archivos desde /tmp, /var/tmp o directorios de usuarios sin justificación.

9. Comprueba la integridad de archivos críticos

Una buena práctica es monitorear cambios en archivos sensibles. AIDE crea una base de datos de archivos del sistema y luego la usa para verificar integridad y detectar modificaciones.

En Debian, Ubuntu y derivados:

sudo apt install aide
sudo aideinit
sudo aide --check

En Fedora, RHEL, AlmaLinux o Rocky Linux:

sudo dnf install aide
sudo aide --init
sudo aide --check

10. Usa Lynis para una auditoría rápida de seguridad

Lynis es una herramienta open source de auditoría y hardening para sistemas Linux, macOS y Unix. Realiza un escaneo amplio del sistema y entrega recomendaciones de mejora. Es útil para administradores, auditores y equipos que necesitan una primera visión del estado de seguridad.

sudo lynis audit system

No debes tomar el resultado de Lynis como una sentencia absoluta. Úsalo como una guía inicial para mejorar la postura de seguridad y documentar hallazgos.

11. Implementa monitoreo de integridad y alertas

Si el servidor es importante para una empresa, no basta con revisar manualmente. Debe existir monitoreo continuo, alertas y retención de logs.

Herramientas como Wazuh pueden ayudar con monitoreo de integridad de archivos, detección de cambios, alertas y visibilidad centralizada.

12. Señales claras de que hay un problema de seguridad

Qué hacer si sospechas que el servidor fue comprometido

Si encuentras señales fuertes de compromiso, evita actuar de forma improvisada. Un reinicio, limpieza rápida o eliminación de archivos puede destruir evidencias útiles para entender qué pasó.

En servidores críticos, la respuesta correcta suele ser reconstruir desde una imagen limpia, restaurar datos verificados y corregir la causa raíz, no simplemente “limpiar” el sistema comprometido.

Checklist rápido de revisión

Preguntas clave sobre seguridad en servidores Linux

Recomendamos

En resumen

Detectar problemas de seguridad en un servidor Linux exige revisar varias capas: actualizaciones, logs, SSH, usuarios, servicios, firewall, procesos, tareas programadas, integridad de archivos y alertas. Ningún comando aislado confirma todo, pero una revisión ordenada puede revelar señales tempranas de riesgo.

La prioridad debe ser construir visibilidad: logs completos, monitoreo, alertas, control de cambios, inventario de servicios y revisiones periódicas. Sin visibilidad, un servidor puede estar expuesto durante semanas sin que nadie lo note.

La seguridad real no termina cuando el servidor está instalado. Empieza después: actualizar, monitorear, auditar, corregir, documentar y responder a tiempo.