BPF ahora puede enviar paquetes directamente: impacto en monitoreo y seguridad kernel

Introducción

Hasta ahora, las herramientas de seguridad basadas en BPF como Tetragon dependían de un proceso en user-space para leer eventos desde un ring buffer y reenviarlos a servidores centrales. Esto creaba un punto único de fallo: si un atacante mata ese proceso, los eventos críticos se pierden. En el Linux Storage, Filesystem, Memory-Management, and BPF Summit 2026, Song Liu, Mahé Tardy y Liam Wiseheart presentaron una solución que elimina esa dependencia. La clave es permitir que los programas BPF envíen paquetes de red directamente desde el kernel, sin pasar por el stack de red tradicional ni por procesos en user-space.

Qué ocurrió

El equipo propuso dos enfoques principales para enviar datos desde BPF:

1. Netpoll: Usa la infraestructura existente de netconsole para enviar paquetes UDP directamente desde cualquier contexto del kernel. Esto incluye dos nuevas kfuncs:

– bpf_netpoll_send_udp(): Envía paquetes UDP con datos arbitrarios.

Durante la demo, Tardy arrancó una VM, instaló un programa BPF que enviaba pings periódicos al host, y mostró que los mensajes continuaban llegando incluso después de matar el agente en user-space.

1. Sockets kernel UDP: Una versión posterior (publicada el 6 de julio de 2026) permite crear y usar sockets UDP directamente desde BPF, en lugar de depender de netpoll. Esto aborda el problema de compatibilidad con drivers de NIC que no soportan netpoll.

Contexto técnico y decisiones de diseño

El kernel ya permite interceptar paquetes entrantes con BPF, pero faltaba la capacidad de enviar datos directamente. La solución con netpoll fue inicialmente criticada porque:

• UDP es «evil»: Al evitar el stack de red, los paquetes no respetan límites de ancho de banda ni políticas de QoS. Starovoitov argumentó que netpoll usa una sola cola en el NIC, lo que minimiza el riesgo de starvation.
• Compatibilidad de drivers: Solo el ~10% de los drivers de NIC soportan netpoll correctamente (según Starovoitov). La mayoría lo deshabilitan o tienen bugs.

Discusión en el Summit

La audiencia debatió si TCP era mejor que UDP para este caso de uso. TCP:

• Permite usar el stack de red tradicional (con límites de ancho de banda, QoS, etc.).
• Pero no puede usarse en contextos atómicos (ej: en hooks de seguridad), porque requiere dormir.

Starovoitov defendió UDP por su simplicidad y por la existencia de netpoll en el kernel. Citó un caso real donde una tarjeta de red fallaba parcialmente: el stack de red colapsaba, pero netpoll seguía funcionando. Wiseheart destacó que, al evitar el stack de red, netpoll es más robusto frente a ataques que manipulen interfaces de red.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de seguridad (SOC, CISO)

• Reducción de puntos ciegos: Herramientas como Tetragon ya no dependen de procesos en user-space para reportar eventos. Si un atacante mata el agente, los eventos siguen enviándose.
• Resiliencia mejorada: Los eventos se envían incluso si el stack de red local está comprometido (ej: NIC rota, reglas de firewall corruptas).
• Limitaciones:

– UDP puede saturar ancho de banda si no se configuran límites (aunque netpoll usa una sola cola).

Para equipos de DevOps e infraestructura

• Automatización de alertas: Los programas BPF pueden enviar alertas directas a sistemas externos (ej: SIEM, syslog, metrics collectors) sin necesidad de procesos intermediarios.
• Monitoreo kernel-first: Ideal para entornos donde el user-space es un riesgo (ej: containers con privilegios reducidos, sistemas embebidos).
• Requisitos:

– Drivers de NIC compatibles con netpoll o uso de sockets kernel UDP.

Para equipos de cloud

• Seguridad en entornos multi-tenant: Al eliminar la dependencia de user-space, se reduce la superficie de ataque en sistemas compartidos.
• Costos de red: UDP es más eficiente que TCP para eventos pequeños, pero debe validarse que no genere tráfico excesivo en redes saturadas.

Detalles técnicos

Versiones afectadas y estado actual

1. Usando netpoll (en kernel 6.12)

#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>

SEC("xdp")
int send_packet(struct xdp_md *ctx) {
    char msg[] = "Hola desde BPF!";
    __u64 flags = 0;

    // Crear contexto netpoll
    int ret = bpf_netpoll_create(&netpoll_ctx, &flags);
    if (ret < 0) {
        bpf_printk("Error creando netpoll: %d", ret);
        return XDP_PASS;
    }

    // Enviar paquete UDP
    ret = bpf_netpoll_send_udp(&netpoll_ctx, "192.168.1.100", 514, msg, sizeof(msg));
    if (ret < 0) {
        bpf_printk("Error enviando paquete: %d", ret);
    }

    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

2. Usando sockets kernel UDP (patch set de julio 2026)

SEC("tracepoint/syscalls/sys_enter_execve")
int trace_exec(struct trace_event_raw_sys_enter *ctx) {
    struct bpf_sock *sk;
    int err;

    // Crear socket UDP
    sk = bpf_skc_lookup_udp(NULL, "192.168.1.100", 514, 0, 0);
    if (!sk) {
        bpf_printk("No se pudo crear socket");
        return 0;
    }

    // Enviar datos
    err = bpf_skc_send(sk, "Alerta: execve detectado", 22);
    bpf_sk_release(sk);
    if (err < 0) {
        bpf_printk("Error al enviar: %d", err);
    }

    return 0;
}

Vectores de ataque mitigados

1. Netpoll y drivers:

– Para otros drivers, usar sockets kernel UDP (en desarrollo).

1. Ancho de banda:

1. Contexto atómico:

– bpf_skc_send() requiere contexto que permita dormir (ej: no en un XDP program).

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar compatibilidad con su infraestructura

1. Verificar kernel mínimo: uname -r debe mostrar 6.12 o superior.
2. Listar drivers de NIC:

   ethtool -i <interfaz> | grep driver
   

– Si el driver está en esta lista, netpoll funcionará.

– Si no, probar con sockets kernel UDP (esperar patch set estable).

2. Actualizar herramientas que dependan de BPF

# Descargar versión con soporte para netpoll (v1.2.0+)
wget https://github.com/cilium/tetragon/releases/download/v1.2.0/tetragon-v1.2.0-x86_64.tar.gz
tar xzf tetragon-v1.2.0-x86_64.tar.gz
sudo ./tetragon --bpf-netpoll-mode

export:
  netpoll:
    enabled: true
    remote-address: "10.0.0.2"
    remote-port: 514
    source-address: "10.0.0.1"

3. Validar ancho de banda y políticas de QoS

# Ver tráfico netpoll (kernel 6.12+)
sudo bpftrace -e 'tracepoint:net:net_dev_queue { @[probe] = count(); }'

# Límites de ancho de banda por interfaz
sudo tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms

4. Implementar cifrado en el kernel (opcional)

Con netpoll, es posible combinar con APIs de criptografía del kernel:

#include <linux/crypto.h>
#include <linux/scatterlist.h>

SEC("xdp")
int send_encrypted(struct xdp_md *ctx) {
    struct crypto_aead *tfm;
    char key[] = "clave-secreta-32bytes";
    char iv[16] = {0};
    struct scatterlist sg;
    struct aead_request *req;
    char *plaintext = "Mensaje secreto";
    char ciphertext[100];
    int ret;

    tfm = crypto_alloc_aead("gcm(aes)", 0, 0);
    if (IS_ERR(tfm)) {
        bpf_printk("Error en crypto: %ld", PTR_ERR(tfm));
        return XDP_PASS;
    }

    req = aead_request_alloc(tfm, GFP_ATOMIC);
    if (!req) {
        crypto_free_aead(tfm);
        return XDP_PASS;
    }

    sg_init_one(&sg, plaintext, strlen(plaintext));
    aead_request_set_crypt(req, &sg, &sg, strlen(plaintext), iv);
    aead_request_set_ad(req, 0); // No datos adicionales

    ret = crypto_aead_encrypt(req);
    if (ret < 0) {
        bpf_printk("Cifrado fallido: %d", ret);
        goto out;
    }

    // Enviar ciphertext con netpoll
    ret = bpf_netpoll_send_udp(&netpoll_ctx, "192.168.1.100", 514, ciphertext, strlen(plaintext) + 16);

out:
    aead_request_free(req);
    crypto_free_aead(tfm);
    return XDP_PASS;
}

5. Documentar y probar en staging

• [ ] ¿Los eventos llegan al SIEM aún si el agente en user-space es matado?
• [ ] ¿El ancho de banda netpol no afecta otras aplicaciones críticas?
• [ ] ¿Los drivers de NIC soportan netpoll o sockets kernel?
• [ ] ¿Las políticas de firewall permiten tráfico UDP desde el kernel?

Conclusión

La capacidad de enviar paquetes directamente desde BPF marca un antes y después en el monitoreo de seguridad en Linux. Elimina un punto ciego crítico: la dependencia de procesos en user-space para reportar eventos. Aunque netpoll es la solución más madura, su adopción masiva depende de la compatibilidad con drivers de NIC. Para entornos donde la resiliencia es prioritaria (ej: sectores financiero, salud), esta funcionalidad es un must-have.

Los equipos de DevOps y seguridad deben:

1. Verificar compatibilidad con kernels ≥6.12 y drivers de NIC.
2. Actualizar herramientas como Tetragon a versiones que soporten netpoll o sockets kernel.
3. Validar que el ancho de banda y QoS no se vean afectados.

El desarrollo continúa: las kfuncs para sockets kernel UDP prometen mayor compatibilidad, pero aún están en fase experimental. Mantente atento a los patch sets en LKML y a las releases de Tetragon.

FIN