Un servidor Linux puede estar funcionando aparentemente bien y, aun así, tener problemas de seguridad ocultos: servicios expuestos, usuarios innecesarios, paquetes sin actualizar, intentos de acceso por fuerza bruta, permisos débiles, procesos extraños, configuraciones inseguras o registros que muestran actividad anómala.
Detectar estos problemas a tiempo es clave para evitar incidentes mayores. No se trata solo de “instalar Linux y olvidarse”. Un servidor requiere monitoreo, revisión periódica, actualizaciones, análisis de logs, control de accesos, firewall, auditoría de configuración y una respuesta ordenada ante señales sospechosas.
Idea clave: un servidor Linux seguro no es el que “nunca falla”, sino el que se revisa, actualiza, monitorea y audita de forma constante. La seguridad se detecta en los detalles: logs, usuarios, puertos, procesos, permisos y cambios no autorizados.
Señales de alerta en un servidor Linux
Antes de ejecutar herramientas avanzadas, conviene observar señales básicas. Muchos incidentes comienzan con síntomas visibles: consumo anormal de CPU, reinicios inesperados, procesos desconocidos, lentitud repentina, conexiones de red extrañas o múltiples intentos fallidos de inicio de sesión.
Indicadores que debes revisar
- Intentos fallidos de acceso SSH repetidos.
- Usuarios nuevos que no reconoces.
- Procesos con nombres extraños o ubicados en carpetas temporales.
- Puertos abiertos que no deberían estar expuestos.
- Servicios activos que nadie usa.
- Consumo alto de CPU, RAM, disco o red sin explicación.
- Archivos modificados recientemente en rutas críticas.
- Mensajes de error frecuentes en logs del sistema.
- Paquetes sin actualizar o repositorios desconocidos.
- Reglas de firewall inexistentes o demasiado permisivas.
1. Revisa cuándo fue actualizado el servidor
Un servidor desactualizado es uno de los riesgos más comunes. Las actualizaciones corrigen vulnerabilidades en el kernel, servicios, librerías, OpenSSH, Apache, Nginx, PHP, bases de datos y otros componentes. Ubuntu, por ejemplo, documenta que unattended-upgrades puede aplicar actualizaciones de seguridad automáticamente y que, por defecto, puede ejecutarse una vez al día en sistemas configurados para ello.
En servidores críticos, las actualizaciones deben aplicarse con planificación, respaldo y ventana de mantenimiento. Pero no aplicarlas durante meses suele ser peor que el riesgo controlado de actualizar.
# Debian, Ubuntu y derivados sudo apt update apt list --upgradable # Ver actualizaciones de seguridad instaladas automáticamente ls -lah /var/log/unattended-upgrades/ # Red Hat, Rocky, AlmaLinux, Fedora sudo dnf check-update # openSUSE sudo zypper list-updates
Alerta: si el servidor lleva mucho tiempo sin actualizar, planifica una ventana de mantenimiento, realiza copia de seguridad y aplica parches. En muchos casos será necesario reiniciar para cargar un kernel actualizado.
2. Comprueba qué puertos están abiertos
Cada puerto abierto representa una posible superficie de exposición. Un servidor web puede necesitar 80 y 443; un servidor SSH puede necesitar 22 o un puerto administrado internamente; una base de datos no debería estar abierta a Internet salvo una arquitectura muy controlada.
Revisa los puertos en escucha y confirma que cada servicio tenga una razón de existir.
# Ver puertos TCP y UDP en escucha sudo ss -tulpen # Alternativa si tienes lsof sudo lsof -i -P -n | grep LISTEN
Puertos que merecen revisión especial
- 22: SSH. Debe estar protegido y monitoreado.
- 80 y 443: HTTP/HTTPS. Deben tener software actualizado.
- 3306: MySQL/MariaDB. Evita exposición pública innecesaria.
- 5432: PostgreSQL. Debe limitarse por firewall y configuración.
- 6379: Redis. No debería exponerse abiertamente.
- 9200: Elasticsearch. Requiere controles estrictos.
3. Verifica el firewall del servidor
Ubuntu documenta UFW como una herramienta sencilla para administrar un firewall basado en host. Un firewall local no reemplaza controles de red o reglas cloud, pero ayuda a reducir exposición y aplicar defensa en profundidad.
# Ver estado de UFW en Ubuntu/Debian sudo ufw status verbose # Ver reglas con numeración sudo ufw status numbered # Ver reglas nftables sudo nft list ruleset # Ver reglas iptables si el sistema aún las usa sudo iptables -S
Buena práctica: permite solo los puertos necesarios, limita administración por IP confiable cuando sea posible y evita exponer bases de datos o paneles internos directamente a Internet.
4. Revisa intentos fallidos de acceso
Los intentos fallidos de login son una de las señales más frecuentes en servidores expuestos. No siempre significan compromiso, pero sí indican que el servidor está siendo probado. Es común observar bots intentando usuarios como root, admin, test, ubuntu o nombres de servicios.
# Debian/Ubuntu: revisar accesos SSH fallidos sudo grep "Failed password" /var/log/auth.log | tail -50 # Red Hat/Rocky/AlmaLinux sudo grep "Failed password" /var/log/secure | tail -50 # Con systemd-journald sudo journalctl -u ssh --since "24 hours ago" sudo journalctl -u sshd --since "24 hours ago"
Señal de riesgo: si ves miles de intentos fallidos, usuarios desconocidos o accesos exitosos desde ubicaciones inesperadas, revisa inmediatamente cuentas, claves SSH, firewall y registros de sesión.
5. Identifica accesos exitosos y sesiones activas
No basta con revisar fallos. También debes revisar accesos exitosos, sesiones activas y últimos inicios de sesión. Un acceso exitoso desde una IP desconocida o en un horario extraño puede indicar uso indebido de credenciales.
# Usuarios conectados actualmente who w # Últimos inicios de sesión last -a | head -30 # Últimos intentos fallidos registrados lastb -a | head -30 # Ver último login por usuario lastlog
Alertas en accesos
- Accesos exitosos desde IPs que no reconoces.
- Usuarios administrativos conectados fuera de horario.
- Sesiones abiertas durante mucho tiempo sin explicación.
- Cuentas que no deberían existir.
- Uso directo de root por SSH.
6. Revisa usuarios, grupos y privilegios sudo
Un servidor puede tener problemas de seguridad si existen usuarios innecesarios, cuentas olvidadas, permisos administrativos excesivos o claves antiguas. La revisión de cuentas debe formar parte de cualquier auditoría básica.
# Ver usuarios locales
cut -d: -f1 /etc/passwd
# Ver usuarios con shell interactiva
awk -F: '$7 ~ /(bash|sh|zsh)$/ {print $1, $7}' /etc/passwd
# Ver miembros del grupo sudo en Debian/Ubuntu
getent group sudo
# Ver miembros del grupo wheel en Red Hat/Rocky/AlmaLinux/Fedora
getent group wheel
# Revisar configuración sudo
sudo -l
Buenas prácticas: elimina cuentas no usadas, bloquea usuarios innecesarios, usa claves SSH fuertes, evita acceso directo de root por SSH y otorga sudo solo a quienes realmente lo necesitan.
7. Revisa procesos activos y consumo de recursos
Procesos desconocidos, consumo anormal de CPU o servicios ejecutándose desde rutas temporales pueden indicar problemas de seguridad o mala configuración. No todo proceso extraño es malware, pero todo proceso desconocido en un servidor crítico debe investigarse.
# Ver procesos con mayor consumo top htop # Ver procesos ordenados por CPU ps aux --sort=-%cpu | head -20 # Ver procesos ordenados por memoria ps aux --sort=-%mem | head -20 # Ver árbol de procesos pstree -ap
Revisión clave: presta atención a procesos ejecutados desde /tmp, /var/tmp, carpetas ocultas o rutas que no correspondan a aplicaciones instaladas por paquetes oficiales.
8. Revisa servicios habilitados al inicio
Un servidor seguro debe ejecutar solo lo necesario. Servicios olvidados o instalados por pruebas pueden quedar activos, escuchando en red o consumiendo recursos.
# Ver servicios activos systemctl --type=service --state=running # Ver servicios habilitados al inicio systemctl list-unit-files --type=service --state=enabled # Revisar un servicio específico systemctl status nombre-del-servicio
Preguntas para cada servicio activo
- ¿Este servicio es necesario?
- ¿Quién lo instaló?
- ¿Está actualizado?
- ¿Escucha en red?
- ¿Tiene credenciales o archivos sensibles?
- ¿Está documentado en la arquitectura del servidor?
9. Revisa archivos modificados recientemente
Cambios inesperados en rutas sensibles pueden indicar una actualización legítima, una modificación administrativa o una alteración no autorizada. La clave es comparar cambios contra ventanas de mantenimiento, despliegues y registros de administración.
# Archivos modificados en /etc durante las últimas 24 horas sudo find /etc -type f -mtime -1 -ls # Archivos modificados recientemente en directorios temporales sudo find /tmp /var/tmp -type f -mtime -1 -ls # Archivos SUID que conviene revisar sudo find / -perm -4000 -type f 2>/dev/null
Importante: no borres archivos sospechosos sin análisis. Primero documenta ruta, propietario, permisos, hash, fecha de modificación y proceso asociado. En un incidente real, preservar evidencia puede ser crítico.
10. Usa auditd para rastrear eventos relevantes
Red Hat documenta que el sistema Linux Audit permite rastrear información relevante de seguridad mediante reglas preconfiguradas y generar registros sobre eventos del sistema. Es especialmente útil en servidores críticos, donde se necesita saber quién modificó archivos, ejecutó comandos administrativos o cambió configuraciones sensibles.
# Ver estado del servicio auditd sudo systemctl status auditd # Buscar eventos de auditoría sudo ausearch -m USER_LOGIN sudo ausearch -m USER_AUTH # Generar resumen sudo aureport
Uso recomendado: activa auditoría en servidores con información sensible, sistemas regulados, infraestructura crítica o entornos donde se requiere trazabilidad de cambios.
11. Ejecuta una auditoría con Lynis
Lynis es una herramienta open source para auditoría de seguridad, hardening y pruebas de cumplimiento en sistemas Linux, macOS y Unix. Realiza un escaneo amplio del sistema y entrega recomendaciones sobre configuración, servicios, permisos, kernel, autenticación, firewall, registros y otros componentes.
# Debian/Ubuntu sudo apt install lynis sudo lynis audit system # Red Hat/Rocky/AlmaLinux/Fedora sudo dnf install lynis sudo lynis audit system
Lynis no “arregla todo automáticamente”. Su valor está en mostrar hallazgos y recomendaciones para que el administrador evalúe qué aplicar según el contexto del servidor.
Consejo: guarda el reporte de Lynis, corrige hallazgos prioritarios y vuelve a ejecutarlo. La seguridad mejora cuando puedes medir antes y después.
12. Usa OpenSCAP para cumplimiento y configuración segura
OpenSCAP y SCAP Security Guide permiten realizar auditorías automatizadas de configuración y cumplimiento. OpenSCAP es especialmente útil cuando necesitas evaluar servidores contra perfiles de seguridad, políticas institucionales o guías de hardening.
Red Hat documenta el uso de OpenSCAP para escaneos de configuración y vulnerabilidades, y el proyecto SCAP Security Guide incluye reglas, descripciones y remediaciones para distintas políticas de seguridad.
OpenSCAP ayuda a revisar
- Configuración de cuentas y contraseñas.
- Permisos de archivos sensibles.
- Servicios innecesarios.
- Políticas de auditoría.
- Configuración de red.
- Controles de cumplimiento y hardening.
- Remediaciones alineadas a perfiles de seguridad.
13. Escanea malware con criterio
Linux no está libre de malware. En servidores de correo, archivos compartidos, hosting, paneles web o entornos mixtos, puede ser útil usar herramientas de análisis. ClamAV se presenta como un motor antivirus open source para detectar troyanos, virus, malware y otras amenazas.
# Debian/Ubuntu sudo apt install clamav clamav-daemon sudo freshclam # Escanear una ruta específica clamscan -r /ruta/a/revisar # Escanear y mostrar solo archivos infectados clamscan -r --infected /var/www
Lectura realista: un antivirus no reemplaza hardening, actualizaciones, control de accesos, monitoreo ni backups. Úsalo como una capa adicional, no como defensa única.
14. Revisa integridad de archivos críticos
Una buena práctica es contar con una línea base de integridad. Herramientas como AIDE permiten detectar cambios en archivos críticos comparando el estado actual contra una base conocida. Esto ayuda a identificar modificaciones no esperadas en configuraciones o binarios.
# Debian/Ubuntu sudo apt install aide # Inicializar base de datos sudo aideinit # Ejecutar verificación sudo aide --check
Mejor práctica: genera la base de integridad en un sistema limpio y protegido. Si la base se crea después de un compromiso, puede registrar como “normal” algo que ya fue alterado.
15. Revisa aplicaciones web y directorios públicos
En servidores web, muchos problemas de seguridad no nacen en Linux directamente, sino en aplicaciones: CMS desactualizados, plugins vulnerables, permisos incorrectos, archivos subidos por usuarios, backups públicos o paneles de administración expuestos.
# Revisar archivos modificados recientemente en un sitio web sudo find /var/www -type f -mtime -2 -ls # Buscar archivos PHP en carpetas de subida sudo find /var/www -path "*upload*" -name "*.php" -ls # Revisar permisos demasiado abiertos sudo find /var/www -type f -perm -o+w -ls sudo find /var/www -type d -perm -o+w -ls
Alerta web: archivos ejecutables en carpetas de subida, permisos 777, copias de seguridad públicas o plugins abandonados son señales comunes de riesgo en servidores de hosting.
Checklist rápido de diagnóstico
| Revisión | Comando o herramienta | Qué detectar |
|---|---|---|
| Actualizaciones | apt list --upgradable, dnf check-update |
Paquetes pendientes y parches críticos. |
| Puertos abiertos | ss -tulpen |
Servicios expuestos innecesarios. |
| Firewall | ufw status, nft list ruleset |
Reglas ausentes o demasiado permisivas. |
| Accesos SSH | journalctl, last, lastb |
Intentos fallidos o sesiones sospechosas. |
| Usuarios | /etc/passwd, getent group sudo |
Cuentas desconocidas o privilegios excesivos. |
| Auditoría | auditd, Lynis, OpenSCAP |
Debilidades de configuración y cumplimiento. |
Qué hacer si encuentras señales sospechosas
Si detectas actividad sospechosa, evita actuar impulsivamente. Apagar servicios, borrar archivos o reiniciar sin registrar información puede destruir evidencia útil. Lo más responsable es documentar, aislar de forma controlada y escalar el análisis.
Primeras acciones recomendadas
- Documenta fecha, hora, IPs, usuarios, procesos y archivos observados.
- Preserva logs relevantes antes de rotación o eliminación.
- Restringe accesos administrativos innecesarios.
- Revisa claves SSH y credenciales comprometidas.
- Aísla el servidor si hay evidencia fuerte de compromiso.
- Valida integridad desde backups o imágenes confiables.
- No borres evidencia sin análisis.
- Escala a un especialista si el servidor es crítico o maneja datos sensibles.
Enlaces internos recomendados de SomosLibres.org
- Qué es el kernel Linux y por qué es tan importante en servidores y dispositivos
- Qué es Docker y por qué se usa tanto junto con Linux
- Cómo proteger tu PC con Linux: guía básica de seguridad
- Herramientas gratuitas para saber si tus datos fueron filtrados
- Cifrado y encriptación en Linux: herramientas esenciales para proteger archivos, discos y backups
Conclusión
Detectar problemas de seguridad en un servidor Linux requiere método. No basta con mirar si el sitio web carga o si el servicio responde. Hay que revisar actualizaciones, puertos, firewall, accesos, usuarios, procesos, servicios, cambios de archivos, logs, integridad y configuración.
Herramientas como Lynis, OpenSCAP, auditd, ClamAV, UFW y verificaciones manuales con comandos básicos permiten construir una visión clara del estado de seguridad del servidor. Lo importante es no depender de una sola herramienta: la seguridad se confirma combinando evidencias.
Un servidor Linux bien administrado debe actualizarse, monitorearse y auditarse de forma periódica. Si detectas señales sospechosas, documenta, preserva evidencia y actúa con cuidado. En seguridad, detectar temprano puede marcar la diferencia entre una alerta menor y un incidente grave.
Resumen final
Para detectar si tu servidor Linux tiene problemas de seguridad, revisa actualizaciones pendientes, puertos abiertos, firewall, intentos fallidos de acceso, sesiones activas, usuarios con privilegios, procesos extraños, servicios habilitados, archivos modificados, logs del sistema y resultados de auditoría con Lynis, OpenSCAP o auditd. Si encuentras señales sospechosas, documenta primero, preserva evidencias, restringe accesos y escala el análisis antes de borrar archivos o reiniciar sin control.
