Seguridad Zero Trust en servidores bare metal

Por qué la seguridad perimetral tradicional falla en infraestructuras dedicadas

Un servidor dedicado típico se encuentra detrás de un firewall que permite el tráfico desde puertos específicos. Una vez que el tráfico llega al servidor, los servicios internos suelen comunicarse entre sí sin necesidad de autenticación adicional. MySQL escucha en el puerto 3306 y acepta conexiones desde la red local. Redis es accesible para cualquier proceso que se ejecute en el servidor. El código de la aplicación se ejecuta con amplios permisos del sistema de archivos.

Esto funciona bien hasta que algo dentro del perímetro se ve comprometido. Un shell web cargado a través de un WordPress vulnerable WordPress ahora puede acceder directamente a MySQL. Un proceso de aplicación comprometido puede leer archivos que pertenecen a otras aplicaciones. El perímetro se mantuvo; el interior, no.

El modelo Zero Trust aborda este problema eliminando por completo el concepto de «interno de confianza». Todas las solicitudes de acceso, ya sean de usuarios externos o de servicios internos, se autentican, autorizan y registran.

Control de acceso basado en la identidad para servicios

La base del modelo Zero Trust a nivel de servicio es garantizar que los servicios se autentiquen entre sí, y no solo ante los usuarios externos.

Acceso a la base de datos: MySQL no debe aceptar conexiones desde 127.0.0.1 sin credenciales con los permisos mínimos necesarios. Crea usuarios de base de datos específicos para la aplicación en lugar de utilizar root:

— Crea un usuario para la aplicación con solo los privilegios necesarios.

CREAR USUARIO «appname»@«127.0.0.1» IDENTIFICADO POR «strong_random_password»;

GRANT SELECT, INSERT, UPDATE, DELETE ON appname_db.* TO ‘appname’@’127.0.0.1’;

VACIAR PRIVILEGIOS;

— Verificar privilegios

MOSTRAR SUBVENCIONES PARA «appname»@«127.0.0.1»;

La aplicación web se conecta como appname y solo puede acceder a appname_db. Incluso si se expone esta credencial, el radio de impacto se limita a una base de datos.

Acceso a Redis: Por defecto, Redis acepta todas las conexiones sin autenticación en localhost. Habilita la autenticación en /etc/redis/redis.conf:

requiere tu contraseña segura de Redis

enlazar 127.0.0.1

Con una contraseña segura y vinculada únicamente al bucle de retorno, las conexiones Redis requieren tanto proximidad de red como las credenciales correctas.

Segmentación de red con espacios de nombres y VLAN

Para entornos con múltiples aplicaciones en un único servidor dedicado, los espacios de nombres de red de Linux proporcionan aislamiento de red a nivel de aplicación sin necesidad de hardware independiente:

# Create an isolated network namespace for an application

ip netns add appname_ns

# Create a veth pair (virtual ethernet cable)

ip link add veth0 type veth peer name veth1

# Move one end into the namespace

ip link set veth1 netns appname_ns

# Configure addressing

ip addr add 192.168.100.1/30 dev veth0

ip netns exec appname_ns ip addr add 192.168.100.2/30 dev veth1

# Bring interfaces up

ip link set veth0 up

ip netns exec appname_ns ip link set veth1 up

Los procesos que se ejecutan dentro del espacio de nombres solo pueden acceder a las direcciones de red configuradas explícitamente para ellos. No pueden acceder directamente a bases de datos o servicios vinculados a la red del host sin pasar por una puerta de enlace controlada.

Para simplificar el aislamiento multitenant, las reglas nftables pueden aplicar políticas de comunicación entre aplicaciones en el mismo servidor:

# Only allow MySQL connections from the application's specific process user (via UID match)

nft add rule inet filter output skuid 1001 tcp dport 3306 accept

nft add rule inet filter output tcp dport 3306 drop

Esto permite que solo los procesos que se ejecutan como UID 1001 (el usuario de la aplicación) se conecten a MySQL; todos los demás procesos se bloquean a nivel del núcleo.

Microsegmentación para el tráfico dentro del servidor

AppArmor (Ubuntu/Debian) y SELinux (RHEL/AlmaLinux/Rocky Linux) proporcionan un control de acceso obligatorio a nivel del núcleo, restringiendo los archivos, los recursos de red y las llamadas al sistema a los que puede acceder un proceso, independientemente de los permisos de Unix.

Un perfil AppArmor para Nginx lo restringe únicamente a los recursos que necesita:

/etc/apparmor.d/usr.sbin.nginx:

#include <tunables/global>

/usr/sbin/nginx {

  #include <abstractions/base>

  #include <abstractions/nameservice>

  capability net_bind_service,

  capability setuid,

  capability setgid,

  /var/www/** r,

  /etc/nginx/** r,

  /var/log/nginx/** w,

  /run/nginx.pid rw,

  # Deny everything else

  deny /home/** rwx,

  deny /root/** rwx,

  deny /etc/shadow r,

}

Con este perfil aplicado, incluso si un atacante logra ejecutar código dentro del Nginx , no podrá leer /etc/shadow, acceder a los directorios de inicio de los usuarios ni escribir fuera denginx/. El kernel aplica estas restricciones independientemente de lo que intente el código del atacante.

La documentación de AppArmor cubre el desarrollo de perfiles y los modos de aplicación. Comienza en modo de advertencia (registrando las infracciones sin bloquear) para verificar tu perfil antes de pasar al modo de aplicación.

Acceso de confianza cero para el acceso administrativo

Aplicar el modelo de confianza cero al acceso SSH significa sustituir las credenciales estáticas por certificados de corta duración y con identidad verificada.

La autoridad de certificación SSH de HashiCorp Vault emite certificados SSH que caducan tras un periodo de tiempo configurable: 30 minutos, 1 hora u 8 horas. Un ingeniero se autentica en Vault con sus credenciales de identidad, recibe un certificado SSH de corta duración y lo utiliza para conectarse al servidor. Si el certificado es robado, caduca en poco tiempo. Si el ingeniero abandona la organización, la revocación de su acceso a Vault pone fin inmediatamente a su capacidad para obtener nuevos certificados.

La documentación del motor de secretos SSH de Vault cubre la configuración tanto para la verificación del lado del servidor como para la emisión de certificados de cliente.

Para los equipos que no están preparados para implementar Vault, una mejora más sencilla de confianza cero para SSH es la lista de direcciones IP permitidas combinada con la rotación de certificados:

# In /etc/ssh/sshd_config

# Match only connections from corporate VPN or jump host IP

Match Address 10.0.0.0/8

  PasswordAuthentication no

  PubkeyAuthentication yes

Match Address *

  DenyUsers *

Registro y verificación continua

La confianza cero sin registro es solo una esperanza. Cada decisión de acceso necesita un registro de auditoría. Para un servidor dedicado:

Registro de acceso SSH: Confirma los registros sshd en /var/log/auth.log (Debian) o /var/log/secure (RHEL). Cada intento de inicio de sesión, ya sea exitoso o fallido, con la IP de origen y el nombre de usuario.

Registro de auditoría a nivel de aplicación: asegúrate de que tu aplicación registre las acciones de los usuarios autenticados, no solo las solicitudes. Registra la identidad de quién realizó cada operación, no solo que la operación se llevó a cabo.

Envío centralizado de registros: los datos de registro almacenados únicamente en el servidor comprometido pueden ser eliminados por un atacante. Envía los registros a un receptor syslog remoto o a un servicio de registro en la nube en el que el servidor no pueda escribir ni eliminar.

Revisión periódica del acceso: revisión mensual de todas las claves SSH activas en /root/.ssh/authorized_keys y en ~/.ssh/authorized_keys de cada usuario. Eliminar las claves que pertenezcan a antiguos empleados, antiguos contratistas o sistemas que ya no necesiten acceso.

El modelo Zero Trust es un proceso continuo, no una implementación

Las organizaciones con la postura de seguridad más sólida en infraestructura dedicada no implementaron el modelo Zero Trust en un fin de semana. Comenzaron por las rutas de acceso de mayor riesgo (SSH, conexiones a bases de datos) y añadieron primero la verificación de identidad y el registro. A continuación, avanzaron hacia el interior, reforzando la comunicación entre servicios y los controles de acceso a nivel de procesos.

El servicio gestionado Premier Care de InMotion incluye la configuración de seguridad básica adecuada para un servidor dedicado de producción. Los equipos que operan bajo estrictos requisitos de cumplimiento o modelos de amenazas (servicios financieros, atención sanitaria, datos regulados) suelen añadir controles adicionales de confianza cero a esa base.

Lectura relacionada: Mejores prácticas para el refuerzo de servidores | Estrategias de protección contra DDoS para infraestructuras dedicadas