¿Qué es el hardening de servidores?
El hardening de servidores es reducir todo lo que un atacante puede usar en una máquina: apagar servicios que sobran, cerrar puertos, quitar las contraseñas del acceso remoto, aplicar parches a tiempo y dejar de anunciar versiones. Un servidor endurecido no es invulnerable, pero obliga al atacante a trabajar mucho más y deja rastro cuando lo intenta.
Aplica igual a un VPS, a una instancia EC2 o a un servidor físico. En la nube no cambia la regla: según el modelo de responsabilidad compartida de AWS, el sistema operativo de tus instancias y su firewall son tu responsabilidad, no del proveedor.
No hace falta inventar la lista. Los CIS Benchmarks son recomendaciones de configuración hechas por consenso, con versiones para cada distribución, como Ubuntu 24.04 LTS y 22.04 LTS, y se descargan gratis en PDF para uso no comercial desde la página de Ubuntu Linux del CIS. La guía NIST SP 800-123 es de 2008, pero sus principios siguen vigentes: planear, instalar lo mínimo, configurar con cuidado y mantener.
¿Qué incluye una checklist de hardening de servidores Linux?
Nueve puntos, del más urgente al que más se olvida. Revísalos en este orden.
1. Solo los servicios que necesitas
Cada servicio que escucha en la red es una puerta. Lista lo que está abierto con «ss -tulpn» y apaga lo que no usas con «systemctl disable --now nombre-del-servicio». Los clásicos que sobran: un servidor de correo que nadie configuró, una base de datos escuchando en todas las interfaces cuando solo la usa la misma máquina, paneles de administración olvidados.
2. Firewall que niega por defecto
La regla base es negar todo lo que entra y abrir solo lo necesario, normalmente 80 y 443. En Ubuntu, «ufw default deny incoming» y después «ufw allow» puerto por puerto. En AWS, los grupos de seguridad cumplen ese papel: ningún puerto de administración debería estar abierto a 0.0.0.0/0.
3. SSH con llaves, sin root y sin exponerlo a todo internet
En OpenSSH, según su documentación, «PermitRootLogin» viene por defecto en «prohibit-password» y «PasswordAuthentication» en «yes»: el acceso por contraseña está permitido si no lo cambias. Desactívalo, entra con llaves y con un usuario sin privilegios que use sudo.
PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes AllowUsers deploy
Una llave no basta si el puerto 22 sigue abierto a todo el mundo: recibe intentos todo el día y cualquier falla futura de SSH te alcanza. Restríngelo a tus IPs, a una VPN o a un bastión. Lo explicamos por capas en ¿aún tienes abierto el puerto 22?
4. Parches automáticos y reinicio de servicios
En Ubuntu, unattended-upgrades viene instalado y aplica las actualizaciones de seguridad una vez al día. Comprueba que siga activo en «/etc/apt/apt.conf.d/20auto-upgrades» y revisa su historial en «/var/log/unattended-upgrades». Ojo: un paquete actualizado no protege hasta que reinicias el proceso que lo usa. Pasó con PHP2Shell: sin reiniciar PHP-FPM, el parche no aplica. Y si tu rama ya no recibe parches, planea la migración a PHP 8.4.
5. PHP y el servidor web sin anunciar versión
Por defecto, PHP trae «expose_php» activado y agrega la cabecera «X-Powered-By» con su versión exacta. nginx publica su versión en la cabecera «Server» y en las páginas de error con «server_tokens on», y Apache usa «ServerTokens Full» por defecto. Es darle al atacante la lista de fallas que puede probar.
; php.ini expose_php = Off # nginx, bloque http server_tokens off; # Apache ServerTokens Prod ServerSignature Off
6. TLS actual y HTTPS obligatorio
Redirige todo HTTP a HTTPS, renueva certificados de forma automática y apaga los protocolos viejos. Como referencia, la NIST SP 800-52 Rev. 2 exige TLS 1.2 a los sistemas del gobierno de EUA y pide soporte de TLS 1.3. Suma cabeceras de seguridad como «Strict-Transport-Security».
7. Registros fuera del servidor
Si alguien obtiene root, lo primero que borra son los registros locales. Envía los registros de acceso, de SSH y de la aplicación a otro lugar, con retención definida, y que alguien revise las alertas. Un registro que nadie lee solo sirve para la autopsia.
8. Respaldos que se pueden restaurar
Fuera del servidor, cifrados, con una copia que el propio servidor no pueda borrar y con una restauración probada. En AWS, la auditoría de seguridad AWS revisa también la bóveda inmutable y la copia en otra región.
9. Mínimo privilegio
La aplicación corre con su propio usuario, nunca como root. El usuario del servidor web no puede escribir en el código. Los secretos, como el archivo «.env», viven fuera de la carpeta pública. Cada persona entra con su usuario, no con una cuenta compartida.
¿Cómo aplicar el hardening sin tumbar producción?
- Toma un snapshot o respaldo antes de tocar nada.
- Haz un cambio a la vez y valida la configuración antes de recargar: «sshd -t», «nginx -t» o «apachectl configtest».
- Al cambiar SSH, deja abierta una segunda sesión hasta comprobar que puedes volver a entrar.
- Anota cómo revertir cada cambio antes de aplicarlo.
- Mide el antes y el después con la misma revisión, para probar que el cambio cerró lo que tenía que cerrar.
¿Cómo revisa Security OS tus servidores?
El escáner de servidor de Security OS revisa desde fuera lo que cualquiera en internet puede ver de tu servidor, en nueve áreas: archivos expuestos, TLS y HTTPS, acceso SSH, firewall y red, actualizaciones, servicios y entornos, registros, respaldos y cabeceras de seguridad. Cada hallazgo llega priorizado, y el remediador prepara la corrección con su reversa. Nada se aplica sin tu autorización, y el mismo motor comprueba que quedó cerrado.
Security OS no es un SOC 24/7 ni hace pentest: audita, corrige con tu OK y lo prueba con evidencia antes y después. Para estar al día con las fallas que afectan servidores, revisa las alertas de la semana, o conoce Security OS completo.
Chequeo pasivo: solo lee la respuesta pública de tu portada, igual que un navegador. Úsalo con dominios que te pertenecen o que administras.
Revisar mi PHP gratisPreguntas frecuentes
¿Qué es el hardening de servidores?
Es reducir la superficie de ataque de un servidor: menos servicios, firewall que niega por defecto, SSH con llaves y sin root, parches al día, sin anunciar versiones y con respaldos probados.
¿Qué guía de hardening debo seguir?
Los CIS Benchmarks de tu distribución son el estándar más usado y se descargan gratis para uso no comercial. NIST SP 800-123 da los principios generales de seguridad de servidores.
¿Basta con usar llaves SSH?
No. Las llaves eliminan el robo de contraseñas, pero el puerto 22 abierto a todo internet sigue recibiendo ataques. Limítalo a tus IPs, a una VPN o a un bastión, y desactiva el acceso de root.
¿Ocultar la versión de PHP me protege?
Solo de los escaneos más automáticos. Un PHP vulnerable sigue siendo vulnerable aunque no anuncie su versión. Primero actualiza y reinicia PHP-FPM; después oculta la versión.
¿Las actualizaciones automáticas son seguras en producción?
Para parches de seguridad, en general sí: en Ubuntu, unattended-upgrades solo usa por defecto las fuentes de seguridad oficiales. Revisa sus registros y reinicia los servicios afectados.
¿En AWS también tengo que hacer hardening?
Sí. En EC2, el sistema operativo y su firewall son tu responsabilidad según el modelo de responsabilidad compartida. AWS protege la infraestructura, no tu servidor.
Fuentes
- CIS Benchmarks
- CIS Ubuntu Linux Benchmarks
- NIST SP 800-123: Guide to General Server Security (julio de 2008)
- NIST SP 800-52 Rev. 2: Guidelines for TLS Implementations (agosto de 2019)
- OpenSSH: sshd_config(5)
- Ubuntu Server: Automatic updates
- PHP: directivas del núcleo de php.ini (expose_php)
- nginx: server_tokens
- Apache HTTP Server 2.4: ServerTokens y ServerSignature
- AWS: Shared Responsibility Model
Escrita por Samuel Hinojosa y el equipo de seguridad de WITS · Actualizada el 25 oct 2026 · Markdown
