Hardening de Linux: una base segura que el equipo pueda mantener

Endurecer un servidor Linux no consiste en ejecutar una colección de comandos encontrada en Internet. Una configuración puede ser adecuada para un servidor web y bloquear una tarea legítima en otro entorno. El trabajo empieza por definir qué debe hacer la máquina y qué accesos necesita. A partir de ahí se retira lo innecesario, se limita lo permitido y se comprueba que la operación continúa siendo recuperable.

Definir una base por función

Documenta distribución, versión, paquetes principales y finalidad del servidor. Identifica quién administra el sistema y quién mantiene la aplicación. El mantenimiento del sistema operativo no garantiza que todos los componentes instalados manualmente reciban actualizaciones. Una base bien definida permite distinguir los cambios necesarios de los añadidos accidentales y facilita reconstruir la máquina si aparece un problema grave.

Revisa servicios activos y puertos en escucha junto con sus responsables. No desactives algo solo porque su nombre resulte desconocido: puede sostener supervisión, sincronización horaria o copias. Confirma su función y prueba la retirada en un entorno adecuado. El resultado deseable es una lista pequeña de servicios justificados, con configuración conocida y un proceso para evaluar futuras incorporaciones.

Asegurar la administración remota

SSH necesita tanto autenticación sólida como control de origen y permisos. Utiliza cuentas individuales y limita la elevación a las tareas necesarias. Antes de cambiar la configuración, valida su sintaxis y mantén una sesión autorizada de recuperación. Comprueba desde otra conexión que el acceso previsto funciona. Un endurecimiento que bloquea a todos los administradores puede provocar decisiones de emergencia menos seguras.

La documentación de OpenSSH de la distribución debe ser la referencia para opciones y ubicación de archivos. Evita copiar parámetros sin comprobar cómo interactúan con fragmentos de configuración y políticas de la plataforma. Si deshabilitas un método de autenticación, verifica antes que todas las personas y automatizaciones disponen de una alternativa aprobada y que la recuperación está documentada.

Limitar el poder de cada proceso

Una aplicación no necesita ejecutarse como administrador para escuchar detrás de un proxy o escribir en su directorio de trabajo. Revisa usuarios de servicio, permisos de archivos y acceso a secretos. Separar identidades permite atribuir actividad y reducir el alcance de un fallo. Comprueba especialmente directorios compartidos y scripts que se ejecutan automáticamente con privilegios elevados.

• Mantén cuentas nominativas y registra las acciones administrativas relevantes.
• Elimina servicios y paquetes que no respondan a una necesidad documentada.
• Restringe permisos de escritura y acceso a credenciales por aplicación.
• Valida la conectividad necesaria y bloquea entradas no justificadas en el nivel apropiado.

Conservar las capas de aislamiento

AppArmor permite restringir capacidades de aplicaciones mediante perfiles y forma parte de la base de Ubuntu. En otras distribuciones pueden existir mecanismos distintos, como SELinux. Si una aplicación falla por una política, investiga el bloqueo y ajusta el permiso necesario. Desactivar globalmente la protección puede resolver el síntoma mientras elimina una barrera importante para todos los procesos.

Trabaja con un cambio concreto y reversible. Reproduce la operación legítima, revisa el registro y confirma qué recurso necesita la aplicación. Después prueba tanto esa operación como otras funciones críticas. No conviertas cada bloqueo en una autorización automática: algunos eventos pueden revelar una ruta inesperada o una configuración de la aplicación que merece corregirse en su origen.

Preparar la observación y la recuperación

Centraliza eventos que ayuden a detectar accesos y cambios relevantes. Comprueba sincronización horaria, espacio disponible y rotación de registros. Si el disco se llena por un error de configuración, la pérdida de disponibilidad puede ocultar otros problemas. La supervisión debe avisar de fallos de envío o almacenamiento, porque una consola sin eventos puede significar silencio de la fuente y no ausencia de actividad.

Antes de cambios importantes, conserva configuración y medios de recuperación de acuerdo con el procedimiento del entorno. Para un servidor remoto, confirma cómo acceder a la consola cuando la red no responde. La prueba de recuperación no necesita ser destructiva: puede consistir en verificar credenciales, permisos y disponibilidad del canal alternativo dentro de una ventana planificada.

Detectar la deriva con el tiempo

Una configuración segura se degrada si cada incidencia añade permisos sin revisión. Compara periódicamente la base esperada con el estado real y registra las excepciones. Cuando un ajuste sea necesario de forma permanente, incorpóralo a la documentación y al mecanismo de despliegue. Así, la siguiente máquina no comienza de cero y el conocimiento no queda escondido en el historial de una terminal o en la memoria de quien hizo el último cambio.