Bastionado de Infraestructura Linux para Sistemas en APAC

La mayoría de los sistemas Linux en producción operan más cerca de su configuración por defecto de lo que nadie quiere admitir. Los documentos de bastionado existen, a menudo escritos para una auditoría hace años, pero los servidores no se corresponden con ellos. En la brecha entre “línea base documentada” y “configuración real” es donde los atacantes viven con fiabilidad.

El bastionado (hardening) de Linux es la disciplina de cerrar esa brecha, y hacerlo de forma que sobreviva al siguiente despliegue.

Los valores por defecto son un punto de partida, no una postura #

Una instalación estándar de Linux prioriza la compatibilidad, no la seguridad. Trae servicios que no usa, funciones del kernel que no necesita y un registro adecuado para un escritorio pero no para un host de producción comprometido. El bastionado es el proceso de convertir esa máquina de propósito general en una construida para un propósito específico.

El trabajo pesado cae en unas pocas categorías:

• Ajustes de kernel y sysctl: protecciones de red (por ejemplo, ignorar redirecciones ICMP, activar filtrado de rutas fuente), restricciones del sistema de archivos y protecciones de memoria como la aleatorización del espacio de direcciones.
• Minimización de servicios: desactivar y eliminar lo que el host no ejecuta, de modo que no haya nada que explotar que no esté en uso.
• Control de acceso obligatorio (MAC): SELinux o AppArmor para restringir lo que un proceso puede hacer, incluso si está comprometido.
• Bastionado de systemd y contenedores: retirar capabilities, bloquear el acceso a raw sockets y restringir syscalls con perfiles seccomp.
• Auditoría y registro: capturar los eventos que importan y enviarlos fuera del host para que un atacante no pueda borrar sus propias huellas.

Los CIS Benchmarks siguen siendo la codificación más práctica y reconocida de estos controles, y OpenSCAP automatiza tanto aplicarlos como auditarlos.

Configuración como código, o no existe #

Una guía de bastionado que vive en una wiki es una lista de deseos. El bastionado que vive en código (un rol de Ansible, una imagen de Packer, una política de admisión de Kubernetes) es un hecho. Cuando la línea base es código, cambian tres cosas:

1. Es reproducible. Cada host nuevo hereda la línea base, no solo aquellos que alguien recordó configurar.
2. Es comprobable. Un escaneo de cumplimiento en CI rompe el build cuando una configuración deriva.
3. Es revisable. Un cambio en la línea base es un pull request, con la misma disciplina de revisión que el código de aplicación.

Esa es la diferencia entre el bastionado como evento anual y el bastionado como propiedad de la plataforma.

La inmutabilidad como estado final #

La conclusión lógica es la infraestructura inmutable: hosts y contenedores nunca se parchean en su sitio, solo se reemplazan. Una imagen nueva se construye, escanea y despliega; la vieja se destruye. La deriva de configuración se vuelve imposible porque no hay nada que derivar: el sistema en ejecución es un artefacto de build.

La infraestructura inmutable se empareja naturalmente con el bastionado como código. No mantiene una línea base; compila seguridad dentro de la imagen. Y cuando aparece una vulnerabilidad, la solución es un rebuild, no una sesión SSH a medianoche.

Más allá del host #

El bastionado no termina en el sistema operativo. La misma disciplina se extiende hacia afuera en varias direcciones, cada una con sus propios modos de fallo.

Los contenedores heredan todo y añaden sus propios riesgos. Una imagen de contenedor construida sobre una capa base sin endurecer arrastra cada debilidad a nivel de host a cada pod que la ejecuta. La solución está aguas arriba: imágenes base mínimas, escaneadas en CI, ejecutadas como non-root con sistemas de archivos de solo lectura, capabilities retiradas y perfiles seccomp que restringen las syscalls que el workload realmente necesita. El perfil seccomp por defecto bloquea bastante; un perfil ajustado al comportamiento syscall observado bloquea lo restante. Las políticas de admisión de Kubernetes lo imponen en toda la flota, así que un despliegue no conforme nunca llega a programarse.

Los entornos OT elevan las apuestas. En entornos industriales y de tecnología operacional, el bastionado choca con la disponibilidad de formas que la TI de oficina nunca ve. Un control CIS mal aplicado en un sistema de gestión de edificios, la red PLC de una línea de producción o un segmento de dispositivos hospitalarios no produce un hallazgo: produce tiempo de parada, a veces con consecuencias de seguridad física. Por eso el bastionado OT invierte la secuencia habitual: la monitorización pasiva y el inventario van primero, los cambios ocurren en ventanas de mantenimiento con planes de reversión, y los controles se pilotan sobre espejos de producción antes de tocar nada real. Donde la TI pregunta “¿está seguro este sistema?”, la OT debe preguntar “¿podemos asegurar esto sin detenerlo?”

La detección de derivas cierra el círculo. Las líneas base decaen por cambio rutinario: un ingeniero abre un puerto para depurar, un instalador reactiva un servicio, un hotfix nunca vuelve al código. Sin detección, el host endurecido de hoy es el blando del año que viene. El patrón que funciona: escaneos de configuración con calendario diario comparando hosts e imágenes vivos contra la línea base codificada, con hallazgos enrutados como alertas a sus responsables en lugar de archivados en un informe trimestral que nadie lee. La deriva detectada en un día es un ticket; la detectada en un año es una investigación de incidente.

Un host endurecido detrás de un rol IAM de nube demasiado permisivo, o dentro de un pipeline de contenedores sin escanear, sigue expuesto. La postura duradera trata la línea base del host, la cadena de construcción de contenedores, la configuración de nube y las fronteras de identidad como una superficie continua, monitorizada como tal.

Nuestro Bastionado Linux e Infraestructura entrega líneas base como código y detección automática de derivas, y nuestra Evaluación de Configuración y Arquitectura revisa la capa de nube e identidades alrededor del host. Para el panorama completo, reserve una sesión de ingeniería y scoping.