Arquitectura Charantej: Laboratorio de Staging de Contenedores Hardened y Telemetría de Llamadas al Sistema

Un marco de trabajo empresarial de defensa en profundidad para la contención de contenedores y telemetría de seguridad en tiempo de ejecución. Diseñado desde la perspectiva de un Arquitecto Líder de Ciberseguridad en Cisco, la Arquitectura Charantej aísla los entornos de staging, restringe las superficies de llamadas al sistema e instrumenta telemetría del kernel en tiempo real mediante auditoría a nivel de host para asegurar implementaciones modernas de contenedores Linux.

Diseño de Alto Nivel (HLD)

La Arquitectura Charantej impone aislamiento, contención de mínimo privilegio y monitoreo fuera de banda para garantizar que los límites de seguridad permanezcan resilientes frente a vectores de compromiso del kernel del host.

flowchart TD
    subgraph HostOS ["Host OS (Nodo Linux Asegurado)"]
        subgraph Docker ["Entorno de Ejecución Docker"]
            App["Espacio de Nombres de Aplicación Auditada"]
        end
        
        subgraph Auditor ["Auditor del Host (Motor Falco)"]
            eBPF["Sondas eBPF"]
        end
        
        Kernel["Kernel Linux del Host"]
    end
    
    SIEM["SIEM / Repositorio de Logs"]

    App -->|Llamadas al Sistema| Kernel
    Kernel -->|Eventos de Traza| eBPF
    eBPF --> Auditor
    Auditor -->|Logs de Telemetría| SIEM
    
    style HostOS fill:#1e1e1e,stroke:#333,stroke-width:2px
    style Docker fill:#2a2a2a,stroke:#007bff,stroke-width:2px
    style Auditor fill:#2a2a2a,stroke:#dc3545,stroke-width:2px
    style Kernel fill:#333,stroke:#ffc107,stroke-width:2px
    style SIEM fill:#1e1e1e,stroke:#28a745,stroke-width:2px,stroke-dasharray: 5 5

Límites de Confianza

1. Entorno Aislado del Contenedor: El espacio de nombres del contenedor se ejecuta estrictamente como un usuario sin privilegios, eliminando todas las capacidades predeterminadas de Linux (CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, etc.) para bloquear manipulaciones de red a nivel de sistema.
2. Lista Blanca de Llamadas al Sistema: Un perfil de Modo de Computación Seguro (seccomp) personalizado actúa como guardián entre los procesos del contenedor y el kernel del host, impidiendo el acceso a llamadas al sistema peligrosas de socket o alteración de espacios de nombres.
3. Instrumentación Fuera de Banda: La auditoría de eventos se ejecuta fuera de banda a nivel de host mediante sondas de rastreo eBPF. Esto asegura que, incluso si el entorno de ejecución del contenedor se ve comprometido, los logs de telemetría no pueden ser alterados ni deshabilitados desde el contexto del contenedor.

Diseño de Bajo Nivel (LLD)

El Diseño de Bajo Nivel define la lógica operativa de validación de llamadas al sistema, las rutas de filtro y los puntos de monitoreo dentro del límite del kernel.

flowchart TD
    subgraph ContainerSpace ["Espacio de Nombres del Contenedor (Espacio de Usuario)"]
        App["Proceso Auditado"]
    end

    subgraph SeccompBoundary ["Límite del Filtro Seccomp"]
        Syscall["Invocación de Llamada al Sistema"]
        Filter{"¿Llamada en Lista Blanca?"}
        Block["SCMP_ACT_ERRNO (Bloquear y Fallar)"]
        Allow["Permitir y Pasar"]
    end

    subgraph KernelSpace ["Espacio del Kernel Linux del Host"]
        Handler["Manejador de Llamadas al Sistema"]
        Subsystem["Subsistema Destino (ej. Red/Memoria)"]
    end

    subgraph TelemetryLayer ["Capa de Auditoría del Host"]
        eBPF["Instrumentación de Sonda eBPF"]
        Falco{"¿El Evento Coincide con una Regla?"}
        Alert["Registrar en syslog / Alarma SIEM"]
    end

    App -->|1. Invoca Llamada| Syscall
    Syscall --> Filter
    Filter -->|No: ej. setsockopt/socket| Block
    Filter -->|Sí: ej. read/write| Allow
    Allow --> Handler
    Handler --> Subsystem
    Handler -->|2. Traza Ejecución| eBPF
    eBPF --> Falco
    Falco -->|Sí| Alert

La Arquitectura Charantej se compone de tres capas de configuración interconectadas para hacer cumplir los límites de seguridad.

1. Staging de Contenedores Hardened (Entorno de Ejecución del Contenedor)

La configuración de orquestación implementa los siguientes controles de seguridad directamente mediante flags de ejecución:

• --cap-drop=ALL: Elimina todas las capacidades predeterminadas del kernel Linux, impidiendo que el contenedor obtenga privilegios administrativos de bajo nivel.
• --security-opt no-new-privileges:true: Evita que los procesos hijos obtengan más privilegios que su proceso padre mediante binarios setuid o setgid.
• --security-opt seccomp=seccomp-profile.json: Implementa un filtrado de llamadas al sistema basado en lista blanca.

2. Guardián de Lista Blanca de Llamadas al Sistema (seccomp-profile.json)

Por defecto, el filtro seccomp de Docker permite una lista amplia de llamadas al sistema. La Arquitectura Charantej restringe esto al mínimo absoluto necesario para la ejecución básica de procesos:

• Acción Predeterminada (SCMP_ACT_ERRNO): Bloquea todas las llamadas al sistema a menos que estén explícitamente en la lista blanca del perfil.
• Llamadas Permitidas: Solo permite primitivas operativas fundamentales (como read, write, exit, exit_group, futex, nanosleep, mmap, munmap, mprotect y close).
• Vectores Bloqueados: Bloquea explícitamente manipulaciones de socket, cambios de red mediante setsockopt, uniones a espacios de nombres (setns) y conjuntos de capacidades (), neutralizando intentos de escalada de privilegios locales (LPE) no autorizados.

3. Rastreo de Telemetría eBPF (Conceptual)

Las reglas de rastreo a nivel de host monitorean conceptualmente los límites de procesos y llamadas al sistema:

• Det_Anomalous_Networking: Audita opciones de socket y marca una ALERTA CRÍTICA inmediata si algún proceso del contenedor intenta modificar protocolos de capa superior o propiedades ULP (optname TCP_ULP).
• Container_Privilege_Escalation_Attempt: Alerta sobre intentos no autorizados de unirse a espacios de nombres (setns) o modificar conjuntos de capacidades (capset).

Demostración de Exploit en Vivo (CVE-2026-46300 "Fragnesia")

Este repositorio incluye una simulación de exploit en vivo para CVE-2026-46300 con el fin de demostrar prácticamente la efectividad de la Arquitectura Charantej. El exploit intenta dos vectores:

1. Escape de Espacio de Nombres: Intenta secuestrar el espacio de nombres de montaje del host usando setns().
2. Corrupción ULP del Kernel: Intenta manipulación no autorizada de la memoria ULP del kernel mediante setsockopt(TCP_ULP).

Ejecutar la Prueba del Exploit

Se proporciona un script auxiliar para construir automáticamente el exploit y ejecutarlo contra un contenedor sin mitigaciones (que representa un sistema vulnerable) y contra el contenedor asegurado con Charantej.

1. Asegúrese de que Docker esté en ejecución.
2. Ejecute el script de prueba:
   root@kitploit:~

   bash run_exploit.sh
   

Resultados Esperados

1. Entorno Sin Mitigaciones (Etapa de Exploit)

El exploit ejecutará exitosamente tanto setns() como setsockopt(), reportando un estado "VULNERABLE".

sequenceDiagram
    participant App as Aplicación Sin Privilegios (Payload Fragnesia)
    participant Cap as Verificación de Capacidad (Kernel)
    participant NS as /proc/self/ns/mnt (Espacio de Nombres del Host)
    participant Sys as Interfaz de Llamadas al Sistema
    participant ULP as Memoria ULP del Kernel

    Note over App,ULP: ETAPA 1: Secuestro de Espacio de Nombres
    App->>Cap: 1. setns(FD, 0)
    Cap-->>App: Permitido (Sin cap_drop)
    App->>NS: Secuestrar Espacio de Nombres del Host
    NS-->>App: ÉXITO: Aislamiento del Contenedor Evadido

    Note over App,ULP: ETAPA 2: Corrupción de Memoria ULP (CVE-2026-46300)
    App->>Sys: 2. socket(AF_INET, SOCK_STREAM, 0)
    Sys-->>App: FD asignado
    
    App->>ULP: 3. setsockopt(FD, IPPROTO_TCP, TCP_ULP, "tls")
    Note right of ULP: Intenta modificación de memoria no autorizada
    ULP-->>App: ÉXITO: Payload malicioso inyectado
    Note over App,ULP: IMPACTO: ¡Memoria del Kernel del Host Comprometida!

2. Entorno Asegurado con Charantej (Etapa de Mitigación)

El exploit es interceptado. setns() es bloqueado por la eliminación de capacidades (EPERM), y socket() / setsockopt() son neutralizados explícitamente por el límite del filtro Seccomp (o por la eliminación de capacidades dependiendo del perfil de ejecución), reportando un estado "BLOQUEADO". Esto confirma que incluso si el payload Fragnesia se ejecuta, la arquitectura Charantej aísla de forma segura el host del exploit.

sequenceDiagram
    participant App as Aplicación Sin Privilegios (Payload Fragnesia)
    participant Cap as Eliminación de Capacidades (ALL)
    participant NS as /proc/self/ns/mnt (Espacio de Nombres del Host)
    participant Sec as Límite del Filtro Seccomp
    participant ULP as Memoria ULP del Kernel

    Note over App,ULP: ETAPA 1: Intento de Secuestro de Espacio de Nombres
    App->>Cap: 1. setns(FD, 0)
    Cap-->>App: BLOQUEADO (EPERM - Operación no permitida)
    Note left of Cap: Defensa Activada: Escape de espacio de nombres neutralizado
    
    Cap-xNS: No puede alcanzar el Espacio de Nombres del Host

    Note over App,ULP: ETAPA 2: Intento de Corrupción de Memoria ULP
    App->>Sec: 2. socket() / setsockopt(TCP_ULP)
    Sec-->>App: BLOQUEADO (EPERM - Operación no permitida)
    Note left of Sec: Defensa Activada: Operaciones de socket neutralizadas
    
    Sec-xULP: No puede alcanzar el Contexto ULP del Kernel
    
    Note over App,ULP: IMPACTO: Exploit completamente contenido. ¡El Host está Seguro!