Bloqueo de Ejecución a Nivel Kernel: Seguridad en Gateways de Hardware en el Borde con eBPF y Tetragon

Por mucho que un agente de seguridad en espacio de usuario detecte una escalada de privilegios en un nodo de borde, el atacante ya tiene control del hardware. Este artículo sale del espacio de usuario y analiza cómo herramientas basadas en eBPF como Cilium Tetragon interceptan y terminan llamadas maliciosas al sistema directamente dentro del kernel — antes de que toquen I/O físico.

Los gateways de hardware físico ocupan una posición peligrosa en la arquitectura moderna de infraestructura. Situados en el extremo de la red — en plantas de fábrica, subestaciones regionales, centros de envío y sitios remotos — estos dispositivos conectan la nube digital con activos físicos. Ingestan datos en bruto de controladores lógicos programables (PLCs), cámaras y sensores ambientales mediante interfaces locales como serial, CAN bus, pines GPIO y componentes USB especializados.

A diferencia de los servidores centrales en la nube aislados en centros de datos protegidos, los gateways de borde son físicamente accesibles y a menudo operan en redes locales no confiables. Si un atacante obtiene acceso físico o a la red a un gateway de borde, comprometerlo otorga control directo sobre maquinaria física.

Asegurar estos nodos requiere un cambio en la estrategia. Los sistemas de seguridad tradicionales fallan en la infraestructura de borde porque operan de manera asincrónica en espacio de usuario. Para proteger hardware físico, la aplicación de la seguridad debe ser sincrónica, preventiva y vinculada directamente al kernel del sistema operativo.

La falla de la detección post-facto: ¿Por qué la seguridad en espacio de usuario falla en el borde?

Históricamente, los Sistemas de Detección de Intrusiones en Host (HIDS) han dependido de agentes en espacio de usuario para monitorear la salud del sistema y detectar comportamientos maliciosos. Paradigmas antiguos a menudo confiaban en leer logs de auditoría del sistema (auditd), consultar el sistema de archivos /proc, o recibir eventos asíncronos pasados desde un módulo kernel o socket de streaming.

Este diseño arquitectónico introduce una debilidad crítica en el borde: la brecha semántica y temporal.

Entendiendo TOCTOU (Time-of-Check to Time-of-Use)

En un modelo de seguridad tradicional en espacio de usuario, cuando un proceso ejecuta una llamada al sistema — como solicitar permiso para escribir en un dispositivo de bloque en crudo o abrir un socket de red — la secuencia de eventos es así:

[Proceso en espacio de usuario] --- 1. Dispara Syscall --- [Kernel Linux] (Ejecuta operación)
                                                        |
                                                        v
[Agente de Seguridad en espacio de usuario] --- 3. Detecta/Alertas --- 2. Registra evento asincrónicamente

1. La aplicación maliciosa invoca una llamada al sistema (por ejemplo, sys_write a una interfaz industrial).
2. El kernel procesa y ejecuta la llamada, modificando el estado del hardware.
3. El kernel registra asincrónicamente el evento mediante subsistemas como auditd.
4. El agente de seguridad en espacio de usuario lee la entrada del log, la analiza, evalúa contra un conjunto de reglas y genera una alerta.

Para cuando el agente en espacio de usuario lee el log, la llamada al sistema ya terminó de ejecutarse. Si un proceso malicioso realiza una escalada de privilegios local (LPE) explotando una vulnerabilidad del kernel, obtiene privilegios root antes de que el monitor en espacio de usuario pueda analizar el evento inicial.

En una VM en la nube, un nodo comprometido puede aislarse, destruirse y redeployarse en segundos por un orquestador. En un gateway de hardware físico, un atacante que gane esta carrera puede flashear firmware malicioso en un microcontrolador adjunto, sobrescribir el cargador de arranque del gateway, o comandar un actuador industrial para sobre-rotar. Una vez manipulado el hardware, la remediación basada en software tiene utilidad limitada.

La alternativa moderna: aplicación de enforcement basada en eBPF

Extended Berkeley Packet Filter (eBPF) convierte el kernel de Linux en un sandbox programable. En lugar de modificar el fuente del kernel o cargar módulos inestables, los desarrolladores escriben programas ligeros que se compilan en bytecode eBPF. Este bytecode es verificado por un verificador en kernel (que previene bucles infinitos, accesos inválidos a memoria o pánicos) y se compila en instrucciones nativas de CPU en tiempo de ejecución (JIT) para ejecutarse a velocidad de hardware.

+--------------------------------------------------------------+
|                         ESPACIO DE USUARIO                   |
|        +-------------------------------------------+          |
|        |           Tetragon Agent Daemon            |         |
|        +-------------------------------------------+          |
|                              ^                                |
|              gRPC / JSON     | Leer alertas y métricas     |
|              Eventos          |                                |
|                              |                                |
+------------------------------|--------------------------------+
|                            KERNEL                             |
|                              |                                |
|                              | Mapas eBPF (Configuración)     |
|                              v                                |
|        +-------------------------------------------+          |
|        |          Motor de Runtime eBPF             |         |
|        +-------------------------------------------+          |
|             | Hook                     | Hook                 |
|             v                          v                      |
|      [ Tabla Syscall ]       [ Hooks de Seguridad LSM ]   |
|             |                          |                      |
|             +------------+-------------+                      |
|                          |                                    |
|                          v                                    |
|          Bloqueo Sincrónico / Matar proceso                   |
+--------------------------------------------------------------+

eBPF traslada la seguridad de un registro pasivo a una verificación en línea. En lugar de esperar a que un subsistema difunda un mensaje de log, los programas eBPF se adjuntan directamente a puntos de hook dentro del kernel:

• Kprobes (Sondas del Kernel): Hooks dinámicos en funciones internas del kernel.
• Tracepoints: Hooks estáticos integrados en el código fuente del kernel por desarrolladores para seguimiento predecible de eventos.
• LSM (Módulo de Seguridad Linux) Hooks: Puntos de interfaz en las rutas de acceso internas del kernel, que permiten decisiones de seguridad antes de que se complete la asignación de recursos.

Cilium Tetragon, un sub-proyecto de CNCF de Cilium, usa eBPF para monitorear la ejecución de procesos, integridad de archivos y namespaces, sockets de red y interfaces de hardware, y va más allá de la visibilidad realizando enforcement en tiempo de ejecución de forma sincrónica.

Una nuance importante: enganchar una llamada al sistema en crudo (como un kprobe en sys_openat, por ejemplo) puede aún dejar una ventana estrecha de TOCTOU si el argumento que se compara es un puntero en memoria de espacio de usuario, ya que un segundo hilo podría reescribir esa memoria entre el disparo del hook y el kernel que la consume. Enganchar una función kernel posterior — particularmente un hook security_* de LSM — evita esto, porque esos hooks se disparan con datos residentes en kernel que ya han sido copiados desde espacio de usuario. Para las políticas de enforcement en el borde con mayor garantía (bloquear acceso a /etc/shadow o a un bus de hardware), los hooks LSM son generalmente la opción más fuerte; los kprobes en syscalls siguen siendo útiles y son los que la mayoría de las políticas publicadas usan, pero ofrecen una garantía ligeramente menor contra un atacante decidido y rápido.

Intercepción estructural de syscalls

Cuando Tetragon está configurado con una política de enforcement, sus programas eBPF enganchan el punto de entrada de llamadas al sistema sensibles (por ejemplo, __x64_sys_kexec_load, __x64_sys_ioctl). Cuando un proceso dispara una llamada no autorizada, el programa eBPF intercepta el hilo antes de que el kernel procese la llamada.

Si los argumentos violan la política, el código eBPF actúa inmediatamente en el contexto del kernel. Puede anular el valor de retorno de la llamada con un código de error como EPERM (Operación no Permitida), o enviar una señal fatal (SIGKILL) directamente a la estructura de tarea del proceso (task_struct). El proceso se termina antes de que la llamada al sistema pueda alterar el hardware físico subyacente.

Fortaleciendo gateways de borde contra vectores físicos y cibernéticos

Los gateways de hardware físico ejecutan cargas de trabajo especializadas pero enfrentan amenazas únicas. Así es como la aplicación en kernel de enforcement detiene patrones de ataque específicos dirigidos al hardware de borde.

1. Bloqueo de acceso no autorizado a interfaces de hardware (/dev/*)

Los sistemas de borde exponen buses de comunicación físicos al sistema operativo como dispositivos de carácter o bloques en /dev/ (por ejemplo, /dev/ttyUSB0 para un convertidor serial Modbus, /dev/can0 para una red automotriz, o bloques GPIO en crudo).

Una aplicación web comprometida o un contenedor MQTT en la puerta podrían intentar manipular estas interfaces. Los permisos UNIX estándar son insuficientes si un atacante usa una vulnerabilidad local para obtener acceso root.

Con Tetragon, puedes aplicar políticas que monitoreen funciones como sys_openat o fd_install en el nivel del kernel. Incluso si un proceso corre como root dentro de un contenedor comprometido, Tetragon puede verificar sus metadatos de namespace del contenedor. Si ese contenedor no está explícitamente autorizado para abrir /dev/ttyUSB0, el kernel anula la llamada, bloquea la creación del descriptor de archivo y registra una alerta de alta fidelidad con los metadatos del contenedor.

2. Eliminación de exfiltración de datos no autorizada (Data Exfiltration)

Los gateways industriales típicamente se comunican con un conjunto específico e inmutable de endpoints: un broker local, un gemelo digital en la nube upstream, o un servidor NTP. Cualquier otra conexión de red es sospechosa.

Los atacantes que comprometen un gateway suelen intentar descargar cargas útiles secundarias, herramientas de reverse-shell, o exfiltrar secretos de configuración. Tetragon intercepta la creación de sockets de red en el kernel mediante funciones como tcp_connect y __sys_connect.

Evaluando llamadas de red en el kernel, Tetragon combina el contexto en tiempo de ejecución (ruta binaria, proceso padre, ID del contenedor) con datos de red (IP destino y puerto). Si un binario no autorizado como curl o wget intenta acceder a un puerto no aprobado, Tetragon mata el proceso antes de que un paquete de handshake TCP cruce la tarjeta de red — esto es un patrón documentado y demostrado (bloquear wget en puerto 443 dejando curl sin afectar es uno de los ejemplos publicados en los informes de campo de Tetragon).

3. Prevención de escape de contenedores y escalada de privilegios

Muchos gateways de borde usan runtimes ligeros como K3s, Docker o Podman para gestionar servicios modulares. La contención de contenedores se basa en namespaces del kernel y cgroups. Si un atacante aprovecha una vulnerabilidad del kernel para escapar de un contenedor, obtiene acceso al sistema host.

Esto no es hipotético: la vulnerabilidad Dirty Pipe (CVE-2022-0847), divulgada en 2022, permite que un proceso sin privilegios sobrescriba datos en archivos de solo lectura explotando un fallo en el buffer de pipes de Linux — un bug que funciona independientemente de la configuración del contenedor y puede usarse para escalar privilegios o manipular archivos en los límites de namespaces. El equipo de ingeniería de Tetragon cita esto como un ejemplo canónico de por qué la enforcement en kernel, consciente de namespaces, importa incluso cuando el aislamiento de contenedores parece sólido en papel. Por separado, la documentación de políticas de Tetragon cita análisis internos que muestran que aproximadamente el 44% de las cadenas de explotación de escape de contenedores dependen de que un proceso sin privilegios pueda crear un nuevo namespace de usuario, ya que esto otorga un conjunto completo de capacidades dentro de ese namespace.

Tetragon monitorea transiciones de namespace y cambios en credenciales en tiempo real mediante hooks en funciones como commit_creds y syscalls como setns/unshare. Al vigilar la obtención de capacidades (CAP_SYS_ADMIN, CAP_SYS_RAWIO) o cambios en namespaces en procesos que no están en el namespace del host, Tetragon puede aislar o matar un proceso en el instante en que intente una transición de privilegios no autorizada — antes de que pueda ejecutar comandos adicionales en el sistema de archivos del host.

Implementación de Tetragon en gateways de borde sin sistema operativo

Aunque Tetragon se despliega frecuentemente en entornos Kubernetes, funciona igual de bien como un daemon independiente en nodos de borde sin sistema operativo.

Requisitos previos para nodos de borde

Para desplegar seguridad en tiempo de ejecución basada en eBPF, el kernel Linux del gateway de borde debe soportar BTF (BPF Type Format), que permite a programas eBPF usar CO-RE (Compile Once – Run Everywhere) para que un programa construido en una versión del kernel pueda leer las offsets correctas en otra.

La documentación de compatibilidad de Tetragon lista las siguientes opciones de configuración del kernel como requisitos:

CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_BPF=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_JIT=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_BPF_SYSCALL=y
CONFIG_CGROUPS=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_SECURITY=y

CONFIG_BPF_KPROBE_OVERRIDE merece una mención específica: es la opción que habilita la acción Override usada en la política de bus de hardware abajo. Sin ella, Tetragon aún puede detectar y matar (Sigkill), pero no puede reescribir el valor de retorno de una syscall.

Verifica soporte BTF en un nodo en ejecución revisando su archivo de abstracción del sistema:

ls -l /sys/kernel/btf/vmlinux

Si planeas usar políticas basadas en hooks LSM (el punto de enforcement más fuerte mencionado arriba), el kernel también necesita tener habilitado bpf en su pila LSM, que en muchas distribuciones no está activado por defecto. Verifica con:

cat /sys/kernel/security/lsm

Si bpf no aparece en la salida, debe añadirse al parámetro de arranque del kernel lsm= (generalmente en /etc/default/grub y reconstrucción del archivo grub) — prueba esto en hardware no productivo primero, ya que cambios en la pila LSM pueden afectar el arranque en algunas plataformas.

La matriz de pruebas de Tetragon cubre kernels de soporte a largo plazo 4.19, 5.4, 5.10 y 5.15, y recomienda el kernel estable más reciente compatible con tu hardware, ya que las capacidades de eBPF (como kprobe_multi de acoplamiento rápido, o visibilidad completa de argumentos de ejecución en arm64) siguen llegando en versiones más nuevas.

Flujo de instalación

Para un gateway de borde con distribución estándar Debian, Ubuntu o Yocto, Tetragon puede instalarse directamente como binario y gestionarse vía systemd. La versión actual referenciada en las instrucciones oficiales de Tetragon es v1.7.0:

# 1. Descargar el paquete de la última versión
curl -LO https://github.com/cilium/tetragon/releases/download/v1.7.0/tetragon-v1.7.0-amd64.tar.gz

# 2. Extraer el archivo
tar -xvf tetragon-v1.7.0-amd64.tar.gz
cd tetragon-v1.7.0-amd64/

# 3. Ejecutar el script de instalación nativo
sudo ./install.sh

# 4. Verificar estado del servicio
sudo systemctl status tetragon

Dado que las versiones avanzan rápidamente, vale la pena revisar la página de lanzamientos de Tetragon antes de fijar una versión en scripts de provisión.

Otros caminos soportados para flotas de borde:

• Despliegue en contenedores, útil si tu gateway ya corre un runtime de contenedores para sus cargas: bash docker run --name tetragon --rm -d \ --pid=host --cgroupns=host --privileged \ -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \ quay.io/cilium/tetragon:v1.7.0 - Instalación con Helm, si el gateway usa una distribución ligera de Kubernetes como K3s en lugar de systemd: bash helm repo add cilium https://helm.cilium.io helm repo update helm install tetragon cilium/tetragon -n kube-system kubectl rollout status -n kube-system ds/tetragon -w

Una vez en marcha, el daemon de Tetragon engancha en el kernel y transmite eventos de telemetría a su archivo de logs local en /var/log/tetragon/tetragon.log en formato JSON estructurado.

Escribir políticas de trazado de Tetragon para protección en el borde

Tetragon usa recursos personalizados YAML TracingPolicy para definir puntos de hook y acciones de enforcement. Estos CRs funcionan igual en Kubernetes o en despliegues sin orquestador — en sistemas sin sistema operativo, el daemon apunta directamente a un archivo de política con --tracing-policy.

Política 1: Bloqueo preventivo de ejecución no autorizada de binarios

Esta política monitorea la ejecución de binarios y restringe la ejecución en directorios volátiles o de escritura (/tmp, /var/tmp, /dev/shm), un escenario clásico para cargas útiles de drop-and-execute.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-volatile-execution
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string" # Ruta del binario en ejecución
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/tmp/"
                - "/var/tmp/"
                - "/dev/shm/"
          matchActions:
            - action: Sigkill

Cuando un binario intenta ejecutarse desde /tmp/, el probe eBPF de Tetragon coincide con la condición de prefijo en sys_execve. El kernel dispara la acción Sigkill, terminando el proceso antes de que el binario entre en memoria.

Política 2: Protección de interfaces físicas de hardware en crudo contra software en contenedores

Esta política previene que procesos en contenedores accedan a interfaces seriales o USB en crudo (/dev/ttyUSB*, /dev/bus/usb/*) a menos que el proceso esté en el namespace del host — es decir, limita la enforcement a contenedores, dejando intactas las herramientas confiables del host.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: protect-hardware-buses
spec:
  kprobes:
    - call: "sys_openat"
      syscall: true
      args:
        - index: 1
          type: "string" # Parámetro de ruta de archivo
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/dev/ttyUSB"
                - "/dev/bus/usb/"
          matchNamespaces:
            - namespace: Pid
              operator: "NotIn"
              values:
                - "host_ns"
          matchActions:
            - action: Override
              argError: -1 # -EPERM: Operación no Permitida

matchNamespaces es cómo Tetragon limita un selector a “todo lo que no esté en el namespace del PID del host” — la palabra clave host_ns se resuelve automáticamente al inode correcto del namespace, y NotIn coincide con todo lo demás, que en la práctica son cargas de trabajo en contenedores. Al devolver -1 (-EPERM) vía la acción Override, el software que llama recibe una respuesta de acceso denegado como si no tuviera permisos básicos, sin que el kernel ejecute la llamada original sys_openat.

 Nota de corrección: una versión anterior de esta política usaba un bloque matchNamespaces con una descripción en texto plano (namespace: "those_outside_host_pid") en lugar de la sintaxis real de namespace-operator de Tetragon. Ese campo acepta uno de los tipos de namespace (Uts, Ipc, Mnt, Pid, PidForChildren, Net, Cgroup, User, y en kernels ≥5.6, Time/TimeForChildren), un operator de In o NotIn, y un inode de namespace o la palabra clave host_ns. La YAML corregida arriba refleja el esquema correcto.

Cerrando la brecha de reinicio del agente: enforcement persistente

Un riesgo operativo específico en hardware de borde es la conectividad intermitente y los reinicios periódicos del agente — justo las condiciones donde que un agente de seguridad se caiga, aunque sea brevemente, crea una ventana de exposición. Tetragon tiene una solución: enforcement persistente.

Al ejecutar el daemon con --keep-sensors-on-exit, los programas eBPF cargados permanecen anclados en /sys/fs/bpf/tetragon en el sistema de archivos BPF del kernel, incluso si el proceso de Tetragon en espacio de usuario se bloquea, termina o está en medio de un reinicio durante una actualización. Las acciones de enforcement (Sigkill, Override) siguen funcionando porque viven en el kernel, no en el proceso de Tetragon — solo la canalización de reporte de eventos se interrumpe hasta que el daemon vuelve a estar activo.

tetragon --bpf-lib bpf/objs/ --keep-sensors-on-exit --tracing-policy protect-hardware-buses.yaml

Para un gateway en planta de fábrica con enlace WAN inestable, esto cierra exactamente la brecha que este artículo busca evitar: significa que el enforcement no desaparece silenciosamente durante la ventana en que el agente no está disponible.

Despliegue seguro: modos de enforcement

Dado que una política mal configurada puede degradar el rendimiento del nodo o, peor aún, matar un proceso legítimo en hardware de difícil acceso, Tetragon soporta ejecutar objetos TracingPolicy en modo Monitoring (las acciones se registran pero no se aplican) versus modo Enforcement (las acciones se ejecutan en serio). El flujo práctico para una política en borde es: desplegarla en modo monitor en tráfico de producción primero, confirmar que solo dispara en comportamientos no deseados, y luego cambiarla a enforcement — en lugar de validar solo en un entorno de laboratorio que puede no reflejar el tráfico real del gateway.

Consideraciones de rendimiento para recursos limitados en edge computing

La infraestructura de borde a menudo opera con restricciones estrictas de cómputo — computadoras industriales, computadoras ARM64 de placa única, o gateways sin ventilador en procesadores de bajo nivel con RAM limitada. Plataformas de telemetría en espacio de usuario pesadas pueden agotar recursos disponibles, causando pérdida de paquetes o lecturas de sensores retrasadas.

Tetragon minimiza la sobrecarga mediante filtrado agresivo en kernel:

SISTEMA TRADICIONAL DE DETECCIÓN DE INTRUSIONES (ej., Falco)
[Kernel] --- Transmitir CADA evento de syscall (alto cambio de contexto) --- [Daemon en espacio de usuario] (Filtrar y decidir)

ARQUITECTURA eBPF de TETRAGON
[Kernel: motor eBPF evalúa reglas localmente] --- Solo enviar coincidencias/alertas verificadas --- [Daemon en espacio de usuario]

Si una llamada al sistema es benigno y coincide con parámetros normales, Tetragon descarta el evento de traza o incrementa un contador local en kernel. Los datos cruzan la frontera kernel-espacio de usuario solo cuando una regla de política se viola o ocurre un evento de ciclo de vida no reconocido.

En cuanto a la cifra de sobrecarga: no hay un número oficial, universalmente citado por Cilium, y las cifras publicadas varían según la carga de trabajo. Informes de la comunidad de 2025–2026 reportan una sobrecarga de Tetragon desde menos del 1% de CPU en nodos con carga ligera, hasta aproximadamente 1–3% en nodos con volumen moderado de eventos y decenas de políticas activas, llegando hasta 5–8% en nodos con churn alto de syscalls y muchas políticas activas. La tendencia común es que el costo escala con el volumen de eventos y el número de objetos TracingPolicy, no con el tamaño del nodo — por lo que en un gateway de borde con pocas políticas bien delimitadas, la sobrecarga se mantiene en el extremo bajo. Considera cualquier porcentaje fijo (incluidos los que puedas ver en otros lados) como dependiente de la carga, y realiza benchmarks con tu propio hardware antes de planear capacidad.

Una limitación conocida: eBPF no es invulnerable

Es importante decirlo claramente, ya que una arquitectura de seguridad basada en un control único merece análisis: la enforcement en kernel no es una bala de plata. Un atacante que ya tenga CAP_BPF o CAP_SYS_ADMIN — por ejemplo, mediante una explotación previa del kernel o un DaemonSet privilegiado comprometido — puede en teoría cargar sus propios programas eBPF que enganchen las mismas funciones del kernel que Tetragon monitorea, filtrando eventos antes de que lleguen a su pipeline de reporte en espacio de usuario. Esto es un área activa de investigación en seguridad en 2026, no una curiosidad teórica, y significa que Tetragon (como Falco y otras herramientas basadas en eBPF) debe desplegarse como una capa en una estrategia de defensa en profundidad — restringiendo qué cargas de trabajo pueden obtener CAP_BPF, monitoreando cargas de programas BPF no autorizadas, y sin confiar ciegamente en un solo agente residente en kernel una vez se pierde el control del host.

Matriz resumen: HIDS legacy vs. Tetragon con eBPF

Atributo de Seguridad	HIDS en espacio de usuario legacy (ej., auditd, Falco temprano)	Enforcement en kernel con eBPF (Tetragon)
Capa de ejecución	Agente en espacio de usuario analizando logs o colas	Sandbox nativo en el kernel
Tiempo de enforcement	Asincrónico / reactivo: alerta después de la explotación o modificación de hardware	Sincrónico / preventivo: intercepta y bloquea antes de que termine la syscall
Vulnerabilidad de bypass	Alta: compromiso root permite desactivar daemons o limpiar logs	Menor, pero no cero: quien obtenga CAP_BPF/CAP_SYS_ADMIN puede cargar programas BPF competidores
Huella en recursos del sistema	Moderada a alta, proporcional al volumen de eventos	Baja, escala con volumen de eventos y políticas activas, no con tamaño del nodo
Adecuación para hardware de borde	Pobre: vulnerable a carreras TOCTOU; riesgo de manipulación física antes de detección	Fuerte: refuerza interfaces I/O locales en el límite del SO/controlador, con enforcement persistente que sobrevive reinicios del agente

Conclusión: Seguridad en el borde de la máquina

A medida que el edge computing avanza, proteger hardware físico requiere seguridad que iguale la velocidad del sistema operativo. Los modelos tradicionales y reactivos dejan una ventana peligrosa entre la ejecución del exploit y las alertas en espacio de usuario.

Al aprovechar eBPF y herramientas como Cilium Tetragon, los ingenieros de infraestructura pueden construir barreras resilientes y proactivas alrededor de gateways físicos. Mover el filtrado de ejecución al kernel de Linux permite interceptar ataques en llamadas al sistema y en la capa LSM. Las conexiones no autorizadas se descartan, las transiciones de privilegios maliciosas se bloquean, y las solicitudes manipuladas de hardware se neutralizan antes de tocar el hardware físico — con la advertencia de que, como cualquier control, funciona mejor como una capa bien instrumentada que como toda la estrategia.

---

Registro de cambios

Metadatos eliminados: el bloque de título y subtítulo concatenados del origen fue separado en un título H1 limpio y un párrafo introductorio.

Correcciones: - Se corrigió el bloque matchNamespaces mal formado en la Política 2 (namespace: "those_outside_host_pid" no es sintaxis válida de Tetragon). Reemplazado por el esquema correcto — namespace: Pid, operator: NotIn, values: ["host_ns"] — verificado contra la documentación oficial de selectores de Tetragon y múltiples ejemplos de políticas independientes que usan el mismo patrón. - Se expandieron las opciones de configuración del kernel requeridas, incluyendo las 13 documentadas en la FAQ/instalación oficial de Tetragon, y se destacó que CONFIG_BPF_KPROBE_OVERRIDE específicamente habilita la acción Override usada en la Política 2. - Se suavizó la afirmación sobre la sobrecarga de CPU. La cifra “1% a 2.5%” original no está respaldada por un benchmark oficial de Cilium; informes de la comunidad de 2025–2026 reportan un rango de menos del 1% hasta 5–8% dependiendo de la carga y políticas activas, por lo que ahora se presenta como un rango respaldado por fuentes en lugar de un número fijo. - Se corrigieron pequeños errores de redacción del borrador original (“activos físicos físicos,” “flashear firmware malicioso”). - Se añadió una nota diferenciando los hooks de syscall en kprobe (que pueden tener una ventana TOCTOU estrecha en argumentos puntero) de los hooks LSM (que no), ya que el texto original implicaba que ambos eran igualmente libres de carreras.

Se verifica que la descripción del esquema, los comandos de instalación y las políticas YAML coinciden con la documentación oficial actual de Tetragon.

Se añadieron nuevas secciones verificadas: - Enforcement persistente (--keep-sensors-on-exit), relevante para gateways con conectividad intermitente. - Modos de enforcement (Monitoring vs. Enforcement) como patrón de despliegue seguro. - Ejemplo real de escape de contenedor (Dirty Pipe, CVE-2022-0847) y la cifra del ~44% en cadenas de escape en la documentación de políticas. - Sección de limitación conocida sobre amenazas tipo rootkit en eBPF, basada en investigación actual. - Requisito de parámetro de arranque bpf en el kernel para hooks LSM, que en la sección de configuración del kernel no se mencionó explícitamente.

Fuentes consultadas: Sitio oficial y documentación de Tetragon (tetragon.io), blog de Cilium 2025, blog de Cilium “Securing the Modern Process with Tetragon”, y artículos independientes de 2025–2026 sobre rendimiento y detección de rootkits en Tetragon.