Seguridad en servidores

Un servidor expuesto a internet recibe intentos de acceso no autorizado prácticamente desde el minuto en que se enciende. Escaneos automatizados, bots buscando puertos abiertos, intentos de fuerza bruta contra SSH... la superficie de ataque nunca descansa. La buena noticia es que la mayoría de esos intentos se pueden neutralizar aplicando un conjunto relativamente pequeño de medidas de seguridad bien conocidas.

En este artículo repasamos las prácticas fundamentales para asegurar un servidor, desde la configuración inicial hasta el mantenimiento continuo, pensado tanto para quien administra un VPS personal como para quien gestiona infraestructura de una empresa.

El concepto de hardening

El hardening (endurecimiento) de un servidor consiste en reducir su superficie de ataque: cerrar todo lo que no es estrictamente necesario, reforzar lo que sí lo es y limitar al máximo lo que un atacante podría hacer si consigue acceso parcial. No es una acción puntual, sino un proceso continuo que empieza en el momento de instalar el sistema operativo.

Acceso remoto: proteger SSH

SSH es la puerta de entrada habitual a un servidor Linux, y por eso es también uno de los objetivos favoritos de los atacantes. Algunas medidas imprescindibles:

• Desactivar el login como root. Usa una cuenta de usuario normal con sudo para tareas administrativas. Así, aunque alguien intente atacar la cuenta root, esta ni siquiera acepta conexión.

# /etc/ssh/sshd_config
PermitRootLogin no

• Usar autenticación por clave pública en lugar de contraseña. Es mucho más resistente a ataques de fuerza bruta.

PasswordAuthentication no
PubkeyAuthentication yes

• Cambiar el puerto por defecto (22). No detiene a un atacante decidido, pero reduce drásticamente el ruido de bots automatizados que escanean el puerto estándar.
• Limitar qué usuarios pueden conectarse por SSH con la directiva AllowUsers.
• Instalar fail2ban, que bloquea temporalmente direcciones IP tras varios intentos fallidos de login, mitigando ataques de fuerza bruta de forma automática.

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Firewalls: controlar qué entra y qué sale

Un firewall bien configurado es una de las defensas más efectivas y a la vez más sencillas de implementar. La regla general debe ser: denegar todo por defecto y permitir explícitamente solo lo necesario.

En sistemas Linux, herramientas como ufw (interfaz simplificada de iptables) facilitan mucho esta tarea:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp    # o el puerto SSH que uses
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Con esto, solo quedan abiertos los puertos estrictamente necesarios para que el servidor cumpla su función (por ejemplo, un servidor web solo necesita 80, 443 y el puerto de administración remota).

Actualizaciones y gestión de parches

Una gran parte de los ataques exitosos no explotan vulnerabilidades desconocidas ("zero-day"), sino fallos ya conocidos y parcheados que simplemente no se han aplicado. Mantener el sistema y los paquetes instalados al día es una de las medidas de seguridad con mejor relación esfuerzo-beneficio.

# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y
 
# Actualizaciones automáticas de seguridad
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Conviene diferenciar entre actualizaciones de seguridad (que suele ser razonable aplicar de forma automática) y actualizaciones mayores de versión (que es mejor probar antes en un entorno de pruebas, ya que pueden romper compatibilidad con tus aplicaciones).

Principio de mínimo privilegio

Cada servicio, usuario o proceso debe tener exactamente los permisos que necesita para funcionar, ni uno más. Algunas aplicaciones prácticas:

• Ejecutar servicios (como un servidor web o una base de datos) con usuarios dedicados sin privilegios administrativos, en lugar de con root.
• Restringir permisos de archivos y directorios sensibles con chmod y chown de forma precisa.
• Revisar periódicamente qué usuarios tienen acceso sudo y eliminar los que ya no lo necesitan.
• Usar herramientas como SELinux o AppArmor para confinar procesos y limitar lo que pueden hacer incluso si son comprometidos.

Monitorización y detección de intrusiones

La seguridad no termina en la prevención: hay que poder detectar cuando algo sospechoso ocurre. Algunas herramientas útiles:

• Fail2ban, ya mencionado, también sirve como capa de detección y respuesta automática.
• Auditd, que registra eventos del sistema relevantes para seguridad (cambios en archivos críticos, ejecuciones de comandos con privilegios, etc.).
• Sistemas de detección de intrusiones (IDS) como OSSEC o Wazuh, que analizan logs y comportamiento en busca de patrones anómalos.
• Revisión periódica de logs (/var/log/auth.log, /var/log/syslog) para detectar intentos de acceso sospechosos.

Buenas prácticas adicionales

• Cifrar las comunicaciones: usa siempre HTTPS/TLS para servicios web y evita protocolos sin cifrar como FTP o Telnet.
• Segmentar la red: separa servidores según su función (base de datos, aplicación, web) y limita la comunicación entre ellos a lo estrictamente necesario.
• Realizar copias de seguridad periódicas, almacenadas fuera del propio servidor, como última línea de defensa ante un incidente grave.
• Deshabilitar servicios innecesarios: cualquier servicio activo que no se usa es una puerta potencial de entrada.
• Usar autenticación multifactor siempre que sea posible, especialmente en paneles de administración expuestos a internet.

Gestión de certificados y cifrado TLS

Además de cifrar el acceso administrativo, cualquier servicio expuesto públicamente (paneles web, APIs, aplicaciones) debe viajar cifrado mediante TLS. Herramientas como Let's Encrypt, junto con clientes como Certbot, han eliminado la barrera del coste y la complejidad que antes suponía gestionar certificados SSL/TLS, permitiendo renovación automática sin intervención manual.

# Emisión y configuración automática de un certificado con Certbot y Nginx
sudo certbot --nginx -d midominio.com -d www.midominio.com

Conviene además revisar periódicamente la configuración TLS del servidor (versiones de protocolo permitidas, cifrados obsoletos deshabilitados) usando herramientas como SSL Labs, ya que una configuración desactualizada puede seguir siendo vulnerable aunque el certificado en sí sea válido.

Auditorías y pruebas de seguridad periódicas

Aplicar medidas de seguridad una vez no garantiza que sigan siendo efectivas con el tiempo: nuevas vulnerabilidades aparecen, configuraciones cambian y los servicios evolucionan. Por eso conviene incorporar auditorías periódicas a la rutina de mantenimiento:

• Escaneos de vulnerabilidades, con herramientas como OpenVAS o Nessus, que identifican puertos abiertos innecesarios, software desactualizado o configuraciones débiles.
• Revisión de la superficie expuesta, comprobando periódicamente qué puertos y servicios son visibles desde internet (por ejemplo con nmap desde fuera de la red).
• Pruebas de penetración (pentesting) puntuales, especialmente antes de lanzar servicios críticos o tras cambios importantes en la infraestructura.
• Revisión de dependencias y librerías usadas por las aplicaciones alojadas, ya que muchas vulnerabilidades no están en el servidor en sí, sino en el software que ejecuta. Estas auditorías no tienen por qué ser constantes ni exhaustivas todo el tiempo; incluso una revisión trimestral estructurada marca una diferencia notable frente a no auditar nunca la configuración de seguridad.

Errores habituales

Uno de los errores más comunes es confiar en la "seguridad por oscuridad" (por ejemplo, cambiar el puerto de SSH) como única medida, sin aplicar el resto de capas de protección. Otro fallo frecuente es dejar contraseñas o claves por defecto en paneles de administración, bases de datos o dispositivos de red recién instalados. También es habitual posponer las actualizaciones "porque el servidor está funcionando bien", lo cual acumula vulnerabilidades conocidas sin parchear.

Por último, muchos administradores no prueban sus propias medidas de seguridad: configuran un firewall o fail2ban y nunca verifican que realmente estén bloqueando lo que deberían.

Conclusión

La seguridad en servidores no depende de una sola herramienta milagrosa, sino de aplicar varias capas de protección de forma consistente: acceso remoto reforzado, firewall bien configurado, actualizaciones al día, mínimo privilegio y monitorización activa. Ninguna de estas medidas es especialmente compleja de implementar por separado, pero juntas reducen drásticamente el riesgo de que un servidor termine comprometido.

La clave está en tratar la seguridad como un proceso continuo, no como una tarea que se marca como completada una vez y se olvida. Revisar periódicamente la configuración, los logs y las actualizaciones pendientes debería formar parte de la rutina habitual de cualquier administrador de sistemas.