9 Min. Tiempo de lectura<\/p>\n
Los atacantes estuvieron en los cl\u00fasteres de Kubernetes alemanes en 2025 m\u00e1s tiempo del que el mediano de los CISO de DACH est\u00e1 dispuesto a admitir. Sysdig ha documentado en su Informe de Amenazas 2026 que el tiempo promedio de permanencia de un intruso en un contenedor es de 196 horas, mientras que el informe M-Trends de Mandiant llega a 21 d\u00edas. La brecha entre la realidad del cl\u00faster y el campo de visi\u00f3n del EDR es amplia y estructural. La detecci\u00f3n cl\u00e1sica de puntos finales funciona a nivel de host y no ve la mayor\u00eda de las actividades relevantes en un contenedor. Con eBPF y las herramientas de c\u00f3digo abierto Falco y Tetragon, esta brecha se cierra en 2026. Black Hat USA 2026 ha elevado a eBPF a un seguimiento oficial, lo que configura el mercado de ingenier\u00eda de detecci\u00f3n para los pr\u00f3ximos doce meses.<\/strong><\/p>\n Relacionado<\/span>Ingenier\u00eda de detecci\u00f3n sin bloqueo de proveedor<\/a> \/<\/span> Autorreplicaci\u00f3n: Agentes de IA<\/a><\/p>\n La detecci\u00f3n y respuesta de puntos finales (EDR) se dise\u00f1\u00f3 para configuraciones cl\u00e1sicas de servidores y estaciones de trabajo. Un agente de EDR se ejecuta en el host, observa la genealog\u00eda de procesos, las operaciones de archivos, las conexiones de red y responde a anomal\u00edas predefinidas. En un entorno de Kubernetes, este modelo falla por tres razones.<\/p>\n Primero: Los contenedores son ef\u00edmeros. Un pod que solo vive 90 segundos deja como m\u00e1ximo una huella en el EDR del host que cae bajo el muestreo de telemetr\u00eda. La l\u00f3gica de detecci\u00f3n asume procesos de minutos de duraci\u00f3n, cuando en realidad son segundos. Quien observa las cargas de trabajo de contenedores con granularidad de host no ve el 70 al 80 por ciento de los eventos relevantes.<\/p>\n Segundo: Ejecuci\u00f3n en memoria. Las cadenas de herramientas de atacantes modernos para contenedores utilizan cargadores que solo residen en memoria y nunca escriben un archivo en disco. La detecci\u00f3n cl\u00e1sica de EDR, que se basa en eventos del sistema de archivos, es conceptualmente ciega aqu\u00ed. eBPF, por otro lado, ve las llamadas al sistema subyacentes porque deben pasar por el kernel.<\/p>\n Tercero: Arquitecturas de sidecar y service mesh. Si un solo pod tiene cinco contenedores y siete conexiones de red que se ejecutan internamente a trav\u00e9s de mTLS, un EDR de host ve principalmente paquetes de red poco claros. La capa sem\u00e1ntica falta. eBPF puede enriquecer esta telemetr\u00eda a nivel de carga de trabajo porque proviene del kernel, antes de que se aplique mTLS.<\/p>\n Ambas herramientas se basan en eBPF, pero se diferencian en su enfoque y nivel de madurez. Falco es el proyecto m\u00e1s antiguo, graduado en CNCF, proporciona una biblioteca de reglas establecida e integra perfectamente con Prometheus, Loki y pipelines SIEM. Su fortaleza radica en su amplitud y madurez: un conjunto de reglas est\u00e1ndar de Falco detecta entre el 60 y el 80 por ciento de las t\u00e9cnicas MITRE-ATT&CK-for-Container en su primera versi\u00f3n.<\/p>\n Tetragon proviene del ecosistema Cilium, est\u00e1 estrechamente vinculado a Cilium CNI y aporta dos caracter\u00edsticas que Falco no proporciona en esta profundidad: primero, una genealog\u00eda de procesos completa, es decir, el \u00e1rbol geneal\u00f3gico padre-hijo de cada actividad de contenedor; segundo, una capa de aplicaci\u00f3n en tiempo real. Tetragon no solo puede detectar que un proceso llama a un syscall prohibido, sino que tambi\u00e9n puede bloquear la llamada directamente en el kernel.<\/p>\n Para 2026, la pila pragm\u00e1tica en los operadores de cl\u00fasteres DACH m\u00e1s grandes suele verse as\u00ed: Falco como detector de base amplio con biblioteca de reglas e integraci\u00f3n SIEM, Tetragon complementario para la genealog\u00eda de procesos en namespaces especialmente sensibles y para la aplicaci\u00f3n selectiva en tiempo de ejecuci\u00f3n. Quien quiera utilizar solo uno de los dos en 2026, comienza con Falco, porque la curva de aprendizaje es m\u00e1s plana y la integraci\u00f3n del operador es m\u00e1s amplia.<\/p>\n Alcance de la telemetr\u00eda en 2026<\/p>\n Informe de amenazas de Sysdig 2026: el 73 por ciento de las intrusiones de contenedores permanecieron sin detectar en hosts con telemetr\u00eda EDR pura, el 11 por ciento en cl\u00fasteres con detecci\u00f3n basada en Falco. Black Hat USA 2026 tiene a eBPF en la selecci\u00f3n de ponencias con 9 charlas – tantas como nunca.<\/strong><\/p>\n<\/div>\n Tres patrones de ejemplo que han aumentado mensuradamente en cl\u00fasteres DACH en 2026 y que se vuelven tangibles con telemetr\u00eda eBPF.<\/p>\n Cargador Memfd y ejecuci\u00f3n sin archivo.<\/strong> Los atacantes crean un descriptor de archivo de memoria an\u00f3nimo a trav\u00e9s de memfd_create, escriben c\u00f3digo en \u00e9l y lo ejecutan sin rastros de disco. Regla de Falco patr\u00f3n: alerta en memfd_create seguida de execveat dentro del mismo grupo de procesos en un namespace productivo. El EDR del host no ve aqu\u00ed ning\u00fan archivo, eBPF ve las dos llamadas al sistema.<\/p>\n Escape de contenedor a trav\u00e9s de la escalada de privilegios cap_sys_admin.<\/strong> Patr\u00f3n de escape cl\u00e1sico que vuelve a aparecer con m\u00e1s frecuencia en los registros de Honeypot en 2025\/2026. Pol\u00edtica de rastreo de Tetragon alerta en cambio de capacidad dentro de un contenedor que no comienza en el namespace privilegiado. El EDR del host solo ve el contenedor como un proceso gen\u00e9rico del runtime del contenedor, el cambio de privilegios permanece invisible.<\/p>\n Rootkits basados en eBPF.<\/strong> Los atacantes cargan sus propios programas eBPF que parchean llamadas al sistema y ocultan actividad de herramientas cl\u00e1sicas. Alerta del plugin de Falco ebpf-program-loaded en bpf_prog_load en un namespace no liberado. Aqu\u00ed solo ayuda la telemetr\u00eda del propio kernel, porque la vista del espacio de usuario es manipulada por el rootkit.<\/p>\n A favor de Falco<\/p>\n En contra de Falco<\/p>\n A favor de Tetragon<\/p>\n En contra de Tetragon<\/p>\n Rollout de detecci\u00f3n con eBPF en cuatro oleadas<\/p>\n Semana 1 a 4.<\/strong> Operador de Falco en dos cl\u00fasteres piloto (Staging, un namespace productivo), habilitar reglas est\u00e1ndar, transmitir telemetr\u00eda a Loki y al SIEM. Objetivo: l\u00ednea de base para el volumen de alertas y la tasa de falsos positivos.<\/p>\n Semana 5 a 12.<\/strong> Construir biblioteca de reglas personalizadas, utilizar MITRE-ATT&CK-for-Container como mapeo, priorizar tres a cinco riesgos principales (escalada de privilegios, cargador Memfd, miner\u00eda de criptomonedas, shell inverso, carga de programa eBPF).<\/p>\n Semana 13 a 20.<\/strong> Introducir Tetragon en paralelo en los namespaces m\u00e1s sensibles, inicialmente solo rastreo, sin aplicaci\u00f3n. Genealog\u00eda de procesos como complemento a la telemetr\u00eda de Falco en el SIEM.<\/p>\n A partir de la semana 21.<\/strong> Aplicaci\u00f3n selectiva de Tetragon para patrones anti claros definidos (por ejemplo, fork-exec desde un contenedor Init, escalada de capacidades en el namespace de carga de trabajo). Control de cambios cuidadoso con los propietarios de la carga de trabajo.<\/p>\n<\/div>\n Es importante no considerar el rollout como la introducci\u00f3n de una herramienta, sino como un programa de ingenier\u00eda de detecci\u00f3n. Una canalizaci\u00f3n basada en eBPF sin reglas documentadas, sin pruebas de CI para la l\u00f3gica de detecci\u00f3n y sin una rutina de clasificaci\u00f3n de alertas en las capas de SOC produce datos sin efecto. Quien quiera utilizar Falco y Tetragon de manera seria, planea para 2026 con dos o tres FTE de ingenier\u00eda de detecci\u00f3n que no sean absorbidos por el trabajo diario normal del SOC.<\/p>\n Tres puntos abiertos acompa\u00f1an la tendencia de eBPF en 2026 y deber\u00edan estar reflejados en cada concepto. Primero: deriva de la versi\u00f3n del kernel. Los programas eBPF est\u00e1n estrechamente vinculados a la interfaz del kernel, que puede cambiar entre versiones del kernel. Quien apuesta por nodos de trabajo de larga duraci\u00f3n debe tomar en serio CO-RE (compilar una vez, ejecutar en todas partes), de lo contrario, cada actualizaci\u00f3n del kernel destrozar\u00e1 la canalizaci\u00f3n de detecci\u00f3n.<\/p>\n Segundo: sobrecarga de rendimiento en cl\u00fasteres densos. Falco con reglas moderadas cuesta entre el 1 y el 3 por ciento de CPU de trabajador bajo carga normal, pero puede ser significativamente mayor en cl\u00fasteres densos de varios inquilinos. Los perfiles de rendimiento de reglas cuidadosas y filtros dirigidos son obligatorios en 2026, de lo contrario, comenzar\u00e1n las discusiones de FinOps que ponen en peligro el programa.<\/p>\n Tercero: Kubernetes gestionado en la nube con ciclos de vida de bloqueo. AWS EKS, GKE y AKS ahora permiten programas eBPF, pero con diferentes restricciones. Quien opera K8s en varias nubes debe construir una estrategia de detecci\u00f3n coherente en todas las plataformas, no en cada cl\u00faster por separado.<\/p>\n No. La EDR cl\u00e1sica sigue siendo relevante para el nivel de host y el compromiso de nodos de trabajo. Las herramientas basadas en eBPF cierran la brecha de visibilidad de los contenedores y ampl\u00edan la pila. Una detecci\u00f3n de cl\u00faster moderna en 2026 combina EDR en el nivel de trabajador con Falco o Tetragon en el nivel de pod y con detecci\u00f3n de red en el nivel de malla.<\/p>\n Con reglas moderadas, la sobrecarga de CPU por nodo de trabajo suele estar entre el 1 y el 3 por ciento. En cl\u00fasteres densos de varios inquilinos con reglas agresivas, pueden aparecer entre el 5 y el 8 por ciento. Quien mantiene activamente los perfiles de rendimiento de reglas mantiene la sobrecarga en un solo d\u00edgito porcentual.<\/p>\n Real\u00edsticamente, de dos a cuatro semanas para Falco hasta el cuidado de reglas productivas, de cuatro a ocho semanas para Tetragon. M\u00e1s importante que la profundizaci\u00f3n en la herramienta es la pr\u00e1ctica de ingenier\u00eda de detecci\u00f3n: mapeo MITRE-ATT&CK, CI para reglas, bucles de triage de alertas. Sin esta pr\u00e1ctica, eBPF sigue siendo una fuente de telemetr\u00eda costosa.<\/p>\n En grandes cl\u00fasteres de m\u00e1s de veinte nodos de trabajo y varios espacios de nombres sensibles, vale la pena operar en paralelo. Falco aporta una amplia cobertura y conexi\u00f3n SIEM, Tetragon profundiza en la genealog\u00eda de procesos y proporciona aplicaci\u00f3n. En configuraciones m\u00e1s peque\u00f1as, normalmente basta con Falco solo.<\/p>\n Positivo. Los obligados a NIS2 deben demostrar capacidades de detecci\u00f3n y respuesta. La telemetr\u00eda basada en eBPF mejora significativamente la calidad del rastro de auditor\u00eda, porque las llamadas al sistema del kernel son la fuente m\u00e1s fiable para la forense. Quien en 2026 tiene que actualizar su conjunto de NIS2 de todos modos, deber\u00eda incluir la cobertura de eBPF como argumento.<\/p>\n M\u00e1s del network de MBF Media<\/p>\n cloudmagazin<\/span>Multi-cl\u00faster sin nuevo silo de operaciones: qu\u00e9 equipos resuelven mal<\/a><\/p>\n MyBusinessFuture<\/span>Los costos de la nube son asunto de jefes: cuando CFO y CIO ya no calculan uno al lado del otro<\/a><\/p>\nLo m\u00e1s importante en resumen<\/h2>\n
\n
Por qu\u00e9 el EDR cl\u00e1sico no es suficiente en el cl\u00faster<\/h2>\n
C\u00f3mo trabajan Falco y Tetragon concretamente<\/h2>\n
Ejemplos concretos de detecci\u00f3n de amenazas en memoria<\/h2>\n
Ventajas y desventajas de las dos herramientas<\/h2>\n
\n
\n
\n
\n
C\u00f3mo se ve un rollout realista en 2026<\/h2>\n
D\u00f3nde la disciplina 2026 todav\u00eda flaquea<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfReemplaza la detecci\u00f3n de eBPF la EDR cl\u00e1sica en el cl\u00faster?<\/h3>\n
\u00bfCu\u00e1nto es el sobrecarga de rendimiento de Falco en producci\u00f3n?<\/h3>\n
\u00bfQu\u00e9 curva de aprendizaje deben planificar los equipos de SOC para eBPF?<\/h3>\n
\u00bfDeber\u00eda utilizarse Falco y Tetragon simult\u00e1neamente?<\/h3>\n
\u00bfC\u00f3mo cambia eBPF la discusi\u00f3n de cumplimiento de NIS2?<\/h3>\n
Consejos de lectura de la redacci\u00f3n<\/h2>\n
\n