Un servidor Linux recién instalado no es inseguro, pero tampoco está preparado para estar expuesto a Internet. En cuanto tiene una IP pública, empieza a recibir intentos de acceso automatizados en cuestión de minutos. El bastionado (hardening) consiste en reducir su superficie de ataque y limitar el daño si algo falla.
Estas son las doce medidas que aplicamos como base antes de poner un servicio en producción. No sustituyen a una revisión completa, pero cubren la mayoría de los incidentes que vemos en la práctica.
1. Acceso SSH solo con claves
Desactiva el acceso por contraseña y el inicio de sesión directo como root. Usa claves y, si es posible, restringe desde qué direcciones se puede conectar.
# /etc/ssh/sshd_config.d/10-bastionado.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups ssh-admins
Para accesos administrativos desde fuera, es preferible pasar por una VPN o un bastión que exponer SSH directamente.
2. Actualizaciones de seguridad automáticas
Configura la instalación automática de parches de seguridad (unattended-upgrades en Debian y Ubuntu, dnf-automatic en la familia Red Hat) y planifica los reinicios que requieren los cambios de kernel.
3. Cortafuegos con política por defecto de denegación
Permite solo los puertos que el servicio necesita y deniega todo lo demás, tanto en el propio servidor (nftables, firewalld o ufw) como en el cortafuegos perimetral.
4. Solo los servicios imprescindibles
Revisa qué está escuchando y desinstala o desactiva lo que no se usa:
ss -tulpn
systemctl list-unit-files --state=enabled
Las bases de datos y paneles de administración nunca deberían escuchar en la interfaz pública.
5. Cuentas nominales y mínimo privilegio
Una cuenta por persona, sin cuentas compartidas. Concede sudo solo a quien lo necesita y, cuando sea posible, solo para los comandos necesarios. Revisa periódicamente las cuentas y claves autorizadas.
6. Protección frente a fuerza bruta
Herramientas como fail2ban bloquean temporalmente las direcciones que acumulan intentos fallidos contra SSH, el correo o las aplicaciones web. No sustituyen a las claves SSH, pero reducen ruido y riesgo.
7. SELinux o AppArmor activados
Muchos administradores los desactivan en cuanto dan el primer problema. Es preferible dejarlos en modo enforcing y ajustar las políticas: limitan lo que puede hacer un proceso comprometido.
8. Servicios con su propio usuario
Cada aplicación debe ejecutarse con un usuario sin privilegios y con permisos solo sobre sus ficheros. Las unidades de systemd ofrecen además opciones de aislamiento como ProtectSystem, PrivateTmp o NoNewPrivileges.
9. Registros centralizados y sincronización horaria
Envía los registros a un sistema externo al servidor: si alguien lo compromete, no podrá borrar su rastro. Mantén la hora sincronizada (chrony o systemd-timesyncd) para poder correlacionar eventos entre sistemas.
10. Auditoría de cambios
Activa auditd para registrar accesos a ficheros sensibles y cambios de configuración, y guarda la configuración del servidor en un repositorio versionado o en tu herramienta de automatización.
11. Copias de seguridad fuera del servidor
Incluye datos y configuración, guárdalas fuera del alcance del propio servidor y prueba periódicamente su restauración. Lo explicamos en detalle en copias de seguridad que de verdad se pueden restaurar.
12. Monitorización y alertas
Uso de disco, carga, servicios caídos, certificados a punto de caducar, intentos de acceso anómalos. Una alerta a tiempo evita la mayoría de las incidencias graves.
Automatiza el bastionado
Aplicar estas medidas a mano en cada servidor es lento y propenso a errores. Lo recomendable es definirlas como código (Ansible u otra herramienta de gestión de configuración) para que todos los servidores queden igual y cualquier desviación se detecte. Como referencia más exhaustiva, los CIS Benchmarks publican guías de bastionado por distribución.
En resumen
La mayoría de los incidentes en servidores Linux expuestos no se deben a vulnerabilidades sofisticadas, sino a contraseñas débiles, servicios innecesarios, parches pendientes y copias que no existen o no funcionan. Estas doce medidas cubren esa base; a partir de ahí, cada servicio necesita una revisión específica de su configuración y de sus dependencias.