Fundamentos para reforzar la seguridad de servidores Linux

Reforzar un servidor Linux consiste en reducir lo que un atacante puede alcanzar y en hacer más difícil el abuso de cada punto de entrada restante. Lo esencial es: usar llaves SSH y desactivar el acceso con contraseña y el acceso como root, aplicar actualizaciones de seguridad automáticamente, mantener un firewall que niegue todo por defecto y solo abra los puertos necesarios, proteger los servicios expuestos con fail2ban o una herramienta similar, eliminar el software que no necesita y conservar registros que realmente revise. Estos pasos aplican a Debian, Ubuntu, AlmaLinux, Rocky Linux y la mayoría de las distribuciones, con pequeñas diferencias.

Antes de cambiar algo en un servidor en producción, haga una instantánea o un respaldo y mantenga abierta una sesión SSH mientras prueba, para que un error no lo deje fuera.

1. Empiece con una instalación limpia y mínima

Cada paquete instalado es algo que hay que parchear. Instale solo lo que requiere la función del servidor y elimine lo sobrante:

• Liste los servicios que escuchan conexiones con ss -tulpn y cuestione cualquier cosa que no reconozca.
• Desactive los servicios innecesarios con systemctl disable --now <servicio>.
• Evite instalar entornos de escritorio o herramientas de desarrollo en servidores de producción.

2. Cree cuentas de administrador con nombre

No trabaje como root. Cree una cuenta con nombre para cada administrador, otorgue permisos elevados mediante sudo y elimine las cuentas que ya no se usan. Las cuentas con nombre hacen que los registros sean útiles: se puede ver quién hizo qué.

3. Refuerce SSH

SSH suele ser el servicio de administración más expuesto. Use autenticación con llaves, idealmente llaves Ed25519 protegidas con frase de contraseña, y luego ajuste la configuración del servicio. En distribuciones recientes puede colocar los cambios en un archivo dentro de /etc/ssh/sshd_config.d/. OpenSSH usa el primer valor que lee para cada parámetro, así que nombre el archivo para que se lea primero, por ejemplo 00-hardening.conf, y revise si hay archivos en conflicto dejados por imágenes de nube:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers alice bob
X11Forwarding no

Valide la configuración antes de recargar y pruebe un nuevo acceso desde una segunda terminal antes de cerrar la sesión actual:

sudo sshd -t
sudo sshd -T | grep -Ei 'passwordauth|permitroot'
sudo systemctl reload ssh    # Debian/Ubuntu
sudo systemctl reload sshd   # RHEL, AlmaLinux, Rocky

Cuando sea posible, limite SSH a una VPN o a direcciones IP conocidas de la oficina en el firewall. Cambiar el puerto de SSH reduce el ruido en los registros, pero no es un control de seguridad por sí solo.

4. Active un firewall que niegue todo por defecto

Permita solo lo que el servidor necesita y niegue todo lo demás en el tráfico entrante.

En Ubuntu o Debian con UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw allow 443/tcp
sudo ufw enable

En AlmaLinux o Rocky Linux, firewalld logra el mismo resultado mediante zonas y firewall-cmd. Reemplace la red de ejemplo por su propio rango de confianza. Si el servidor está en un proveedor de nube, use los grupos de seguridad o el firewall del proveedor como capa adicional.

5. Automatice las actualizaciones de seguridad

El software sin parches es una de las formas más comunes en que se comprometen los servidores.

Distribución	Herramienta de actualizaciones automáticas de seguridad
Debian, Ubuntu	unattended-upgrades
AlmaLinux, Rocky, RHEL	dnf-automatic

Las actualizaciones automáticas de seguridad son adecuadas para la mayoría de los servidores de pequeñas empresas. Para aplicaciones críticas, combínelas con monitoreo y un calendario para actualizaciones del kernel y reinicios, o use parches en vivo cuando su distribución lo permita.

6. Bloquee los intentos de fuerza bruta

Herramientas como fail2ban vigilan los archivos de registro y bloquean temporalmente las direcciones IP que fallan repetidamente al autenticarse. Active una regla para SSH y para cualquier acceso web, servicio de correo o panel de control expuesto. En servidores de hosting con cPanel y similares, herramientas como Imunify360 y CSF ofrecen una protección comparable integrada con el panel.

7. Proteja los datos y los permisos

• Mantenga permisos de archivo estrictos, sobre todo en archivos de configuración que contienen credenciales.
• Use usuarios de sistema separados para cada aplicación, para que el compromiso de una no exponga a las demás.
• Cifre los respaldos y guarde al menos una copia fuera del servidor.
• Mantenga activo SELinux (familia RHEL) o AppArmor (Ubuntu, Debian) en lugar de desactivarlo para que algo funcione.

8. Registre, monitoree y revise

• Asegúrese de que journald y syslog conserven suficiente historial, y reenvíe los registros a un sistema central si administra varios servidores.
• Active auditd en servidores que manejan datos sensibles.
• Monitoree el espacio en disco, los accesos fallidos y la aparición de nuevos puertos en escucha.
• Revise los registros según un calendario, no solo después de un incidente.

Nuestro servicio de instalación y reparación de servidores aplica estas bases a servidores nuevos y existentes, y nuestros servicios de ciberseguridad agregan monitoreo continuo y revisiones periódicas.

Preguntas frecuentes

¿Basta con cambiar el puerto de SSH para proteger un servidor?

No. Reduce el ruido automatizado en los registros, pero los atacantes decididos escanean todos los puertos. La autenticación solo con llaves, las restricciones del firewall y las actualizaciones son las que brindan protección real.

¿Las actualizaciones automáticas pueden afectar mis aplicaciones?

Las actualizaciones solo de seguridad rara vez causan problemas, pero puede ocurrir. Pruebe las actualizaciones mayores en un entorno de pruebas, monitoree después de actualizar y mantenga respaldos o instantáneas recientes para poder revertir.

¿Estos pasos aplican también a servidores en la nube?

Sí. Ya sea que el servidor funcione en AWS, Azure, Google Cloud, OVHcloud o en un host Proxmox en su oficina, el sistema operativo igual necesita refuerzo. Los firewalls de la nube agregan una capa, pero no reemplazan la configuración del servidor.

Siguiente paso

Max, nuestro fundador, administra servidores Linux y de hosting desde hace más de 20 años y cuenta con las certificaciones cPanel & WHM System Administrator e Imunify360. Solicite una evaluación de TI gratuita y revisaremos sus servidores con base en estos fundamentos.