Un servidor Linux recién instalado es funcional, pero no es seguro por defecto. El hardening (endurecimiento) consiste en reducir su superficie de exposición: quitar lo que sobra, cerrar lo que no se usa y vigilar lo que importa. Para una PYME puede ser la diferencia entre un incidente menor y una parada de servicio con fuga de datos. En este artículo repasamos las buenas prácticas que aplicamos cuando endurecemos infraestructura, sin entrar en recetas que sirvan de mapa a un atacante.
Empieza por lo básico: actualizaciones y parcheo
La mayoría de intrusiones no explotan vulnerabilidades sofisticadas, sino fallos conocidos y sin parchear. Mantener el sistema y sus paquetes al día es la medida con mejor relación coste-beneficio que existe. Conviene definir una política clara: parches de seguridad cuanto antes, actualizaciones funcionales con ventana planificada y prueba previa.
- Automatiza la instalación de parches de seguridad, pero revisa que no rompan servicios críticos.
- Lleva un inventario de versiones para saber qué tienes expuesto cuando aparece un CVE relevante.
- Retira paquetes, servicios y puertos que no uses: lo que no está instalado no se puede atacar.
Usuarios y acceso SSH: el punto de entrada que más se ataca
SSH es la puerta principal de un servidor Linux y, por tanto, el objetivo favorito de los ataques automatizados. Endurecerlo cierra la mayor parte de los intentos de fuerza bruta de un plumazo. Las prácticas asentadas son claras: desactivar el acceso directo del usuario root, autenticarse con claves criptográficas en lugar de contraseñas y dar a cada persona su propia cuenta nominal para que cada acción quede atribuida.
- Autenticación por clave en vez de contraseña, y deshabilitar el login por contraseña una vez verificado el acceso.
- Sin acceso directo de
root; se escala a privilegios solo cuando hace falta y de forma trazable. - Cuentas individuales, nunca compartidas, y revocación inmediata cuando alguien deja el proyecto.
- Doble factor donde la criticidad lo justifique.
Firewall y mitigación de ataques automatizados
El principio aquí es de denegación por defecto: solo se permite el tráfico estrictamente necesario y se cierra todo lo demás. Un firewall bien configurado deja expuestos únicamente los servicios que deben estarlo, y restringe el acceso administrativo a redes o IPs de confianza siempre que sea viable.
A esto se suman herramientas que detectan y bloquean comportamientos abusivos de forma automática, como los intentos repetidos de inicio de sesión fallidos. Bloquear temporalmente las direcciones que insisten reduce drásticamente el ruido y el riesgo de los ataques de fuerza bruta, sin intervención manual constante.
Mínimo privilegio: que cada cosa pueda hacer solo lo suyo
El principio de mínimo privilegio atraviesa todo el hardening: usuarios, servicios, procesos y aplicaciones deben tener exactamente los permisos que necesitan para su función, ni uno más. Cuando un componente se ve comprometido, lo que limita el daño es lo poco que ese componente podía hacer.
En la práctica esto significa servicios corriendo con cuentas dedicadas y sin privilegios, permisos de ficheros revisados, segmentación entre entornos y una revisión periódica de quién y qué tiene acceso a cada recurso. Los privilegios tienden a acumularse con el tiempo; auditarlos cada cierto tiempo evita que el servidor se convierta en un coladero por inercia.
Copias de seguridad y monitorización de cambios
Ningún sistema es invulnerable, así que el hardening incluye prepararse para cuando algo falle. Las copias de seguridad son la red de la que depende la recuperación: deben estar aisladas del propio servidor, cifradas y, sobre todo, probadas. Si estás montando un servidor desde cero, revisa antes los diez pasos que evitan los incidentes más comunes.
En paralelo, monitorizar el sistema permite detectar lo anómalo a tiempo: cambios inesperados en ficheros sensibles, accesos fuera de horario, picos de actividad o servicios que aparecen sin justificación. Conviene centralizar y proteger los registros (logs), porque son la fuente de verdad cuando hay que investigar un incidente. Esta vigilancia continua es justamente lo que ofrecen unos servidores gestionados frente a un servidor que solo se mira cuando ya hay un problema.
La seguridad es un proceso, no un proyecto cerrado
Endurecer un servidor una vez y olvidarse es uno de los errores más comunes. Aparecen vulnerabilidades nuevas, el software cambia, los equipos rotan y la configuración se va desviando. El hardening real es un ciclo: revisar, ajustar, parchear, auditar y volver a empezar.
Cuando la seguridad también genera incidentes
Las propias herramientas de seguridad, mal ajustadas, también causan incidentes. Dos casos reales de nuestro soporte (anonimizados):
Un EDR decidió aislar de la red un servidor de producción por un archivo temporal de 27 bytes que clasificó como sospechoso. El procedimiento correcto no fue «desactivar el antivirus»: se sacó el servidor del balanceador, se investigó el archivo, se confirmó el falso positivo y se reincorporó sin impacto para los usuarios. La herramienta hizo su trabajo; la operación alrededor es lo que evitó el susto.
En otro caso, un WAF bloqueó el callback de un servicio de firma electrónica y varias aplicaciones del mismo cliente dejaron de autenticarse entre sí. Protección al máximo sin entender los flujos de la aplicación acaba rompiendo la aplicación; aquello terminó, con buen criterio, en una revisión de arquitectura.
La lección de ambos: el hardening sin operación diaria detrás (alguien que interprete alertas, distinga falsos positivos y ajuste reglas) o se vuelve ruido o se vuelve un freno.
Asegura tu infraestructura con quien la gestiona a diario
El hardening efectivo exige criterio, mantenimiento constante y conocer bien el sistema que se protege. Si prefieres delegar esa vigilancia continua en un equipo especializado, en Elimática ayudamos a empresas a endurecer y mantener su infraestructura como parte de nuestros servidores gestionados. Cuéntanos tu caso y te orientamos sobre los siguientes pasos.