Post cover image

July 28, 2026

Kernel’in Görünmez Silahı: eBPF Tabanlı Telemetri Manipülasyonuna Karşı Nerede Duruyoruz?

SunnyDayBPF ve BPFDoor gibi araçların ortak paydası olan tekniği, kendi altyapımızda gerçek komutlarla test ettik

By Akın Farfar

4 min read

eBPF Neden Hem Bir Nimet Hem Bir Tehdit

eBPF (Extended Berkeley Packet Filter), Linux kernel'inin en önemli modern yeteneklerinden biri — kernel modülü yazmadan, kernel kaynak kodunu değiştirmeden, kernel içinde güvenli bir sandbox'ta çalışan küçük programlar çalıştırmanı sağlıyor. Bu yetenek, gözlemlenebilirlik (observability) dünyasını değiştirdi: Cilium, Falco, Tetragon, Wazuh'un kendi Syscollector'ı gibi araçların hepsi, sistem çağrılarını (syscall), ağ paketlerini, dosya erişimlerini kernel seviyesinde, düşük gecikmeyle izleyebiliyor — user-space'teki bir ajanın asla göremeyeceği bir netlikte.

Ama tam bu güç, saldırganların elinde bir silaha dönüşüyor. BPFDoor, Symbiote, ve daha yakın zamanda gündeme gelen SunnyDayBPF gibi araçlar, aynı mekanizmayı tersine çeviriyor: kernel'e yerleşip, güvenlik ajanlarının gördüğü veriyi kaynağında manipüle ediyorlar. Bu, klasik bir rootkit'ten farklı — dosya sistemini gizlemiyor, process listesini değiştirmiyor; bunun yerine, telemetri üretilmeden önce, henüz user-space'e ulaşmadan onu şekillendiriyor.

eBPF Tehdit Modeli: Saldırganlar Bunu Nasıl Kullanıyor

Bu araçların ortak tekniği, kabaca şöyle özetlenebilir:

  1. Yükleme: Saldırgan, ele geçirdiği bir sistemde (genelde root veya CAP_BPF/CAP_SYS_ADMIN yetkisiyle) kötü niyetli bir eBPF programı yükler — genellikle bir tracepoint, kprobe veya XDP hook'una bağlanır.
  2. Konumlandırma: Program, syscall'ların (örneğin read, write, execve) döngü noktalarına ya da ağ arayüzü paketleme katmanına yerleşir.
  3. Manipülasyon: Buradan, iki temel taktik uygular:
  • User-space buffer manipülasyonu: Bir güvenlik ajanının (Wazuh agent, Falco, auditd) okuduğu buffer'ın içeriğini, ajan onu okumadan hemen önce değiştirir — ajan "temiz" bir syscall görür, gerçekte olan farklıdır.
  • Filtreleme/gizleme: Belirli bir process ID'sinden veya belirli bir ağ portundan gelen trafiği, telemetri zincirine hiç girmeden düşürür — "sessizlik" üretir, sahte veri değil.
  1. Kalıcılık: eBPF programı, kernel'in kendi yapısında yaşadığı için, user-space'teki hiçbir antivirüs veya EDR onu normal bir dosya/process taraması ile göremez.

Bunun en tehlikeli yanı şu: user-space'teki güvenlik aracının kendisi hiçbir şekilde yanlış çalışmıyor — sadece ona ulaşan veri, kaynağında zaten kirletilmiş oluyor. Wazuh'un Syscollector'ı, auditd, hatta bir SIEM'e giden syslog akışı — hepsi, kernel'den çıkan veriye güveniyor. eBPF saldırısı, tam da bu güven noktasını hedef alıyor.

CloudTrail Benzeri Yaklaşımların Neden Yetersiz Kaldığı

Sık sorulan bir soru şu: "AWS CloudTrail gibi bir API-seviyesi denetim kaydı, buna karşı yeterli bir savunma olur mu?" Cevap kısa ve net: hayır, çünkü farklı bir katmanı izliyorlar.

CloudTrail (ve benzerleri), bulut kontrol düzlemini (control plane) izler — kim hangi API'yi çağırdı, hangi kaynak oluşturuldu/silindi. Bu, "kim bu VM'i kimin adına başlattı" sorusuna mükemmel cevap verir. Ama bir eBPF rootkit'i, VM içindeki işletim sistemi kernel'inde çalışır — CloudTrail'in hiçbir görüş alanı, bir Linux kernel'inin syscall tablosuna inmez. Bu, iki farklı savunma katmanı: biri "kim neyi kimden istedi" sorusuna, diğeri "kernel'in içinde gerçekte ne çalışıyor" sorusuna cevap verir. Birini kurup diğerini atlamak, sadece yarım bir görünürlük sağlar.

Buna karşı gerçek savunma, kernel'in kendi güvenlik mekanizmalarını (lockdown, imzalı modül zorunluluğu, BTF-doğrulamalı izleme araçları) devreye almaktan geçiyor — bir sonraki makalede bu adımları gerçekten uygulayıp belgeleyeceğiz.

Mevcut Altyapımızda Durum Nedir? (Doğrulanmış Bulgular)

Bu makaleyi yazmadan önce, iddiaya değil kanıta dayanmak istedik — üç sunucumuzda (T-Pot, Wazuh, MISP) gerçek komutlarla mevcut durumu tespit ettik.

ansible all -b -m ansible.builtin.shell -a "sysctl kernel.unprivileged_bpf_disabled"
misp-server: kernel.unprivileged_bpf_disabled = 2
wazuh-server: kernel.unprivileged_bpf_disabled = 2
tpot-server: kernel.unprivileged_bpf_disabled = 2

2 değeri, unprivileged (yetkisiz) BPF yüklemesinin sadece kapalı değil, kilitli olduğu anlamına geliyor — root bile bunu çalışma anında tekrar açamıyor, ancak reboot ile değiştirilebilir. Bunu biz ayarlamadık — bu, Ubuntu 22.04'ün 6.8.x kernel serisindeki fabrika varsayılanı. Yine de önemli bir taban çizgisi: bu spesifik saldırı yüzeyi, hiçbir ek iş yapmadan zaten kısmen kapalı.

ansible all -b -m ansible.builtin.shell -a "cat /sys/kernel/security/lockdown"
misp-server: [none] integrity confidentiality
wazuh-server: [none] integrity confidentiality
tpot-server: [none] integrity confidentiality

Burada gerçek bir açık var: kernel lockdown mekanizması mevcut, ama üç sunucuda da aktif mod none — yani hiçbir kısıtlama uygulanmıyor. integrity moduna geçilmesi, kernel belleğinin/modüllerinin root tarafından bile değiştirilmesini kısıtlar — eBPF tabanlı bir post-exploitation aracının manevra alanını daraltan somut bir adım. Bu, bir sonraki makalenin ilk maddesi.

ansible all -b -m ansible.builtin.shell -a "test -f /sys/kernel/btf/vmlinux && echo 'BTF present'"
misp-server: BTF present
wazuh-server: BTF present
tpot-server: BTF present

BTF (BPF Type Format) her üç sunucuda da mevcut — bu, Tetragon veya Tracee gibi CO-RE (Compile Once, Run Everywhere) tabanlı modern izleme araçlarının kernel header'larına bağımlı olmadan çalışabileceği anlamına geliyor. Teknik önkoşul zaten karşılanmış durumda.

ansible all -b -m ansible.builtin.shell -a "bpftool prog list"

Sonuç, filo genelinde tutarsız bir görünürlük ortaya çıkardı: misp-server'da bpftool kurulu bile değil — yani o sunucuda şu an hangi eBPF programlarının çalıştığını göremiyoruz. wazuh-server ve tpot-server'da ise bpftool çalıştı ve düzinelerce yüklü program listeledi — cgroup_device, cgroup_skb, hid_tail_call gibi. Bunları tek tek inceledik: hiçbiri kötü niyetli değil, hepsi Docker'ın kendi cgroup v2 device-filtering ve network-policy mekanizmasının normal ürünü. T-Pot'ta bu sayı özellikle yüksek ve zamana yayılmış — 35'ten fazla honeypot container'ının sürekli yeniden oluşturulması, her seferinde yeni bir eBPF programı tetikliyor.

Bu, aslında değerli bir yan ürün: artık "normal eBPF aktivitesi neye benzer" sorusunun gerçek bir taban çizgisi var. İleride bir izleme aracı kurduğumuzda, anomaliyi bu baseline'a göre tanımlayabileceğiz.

Mevcut Durum Özeti

None

Sonuç: Görünürlük, Varsayım Değil Kanıt Gerektirir

Bu analizin en önemli çıkarımı, bir "biz zaten güvendeyiz" ya da "biz tamamen açığız" cevabı değil — ikisinin arasında, kanıta dayalı bir ara durum. Unprivileged BPF zaten kilitli, ama bu bizim başarımız değil, dağıtımın lütfu. Lockdown mekanizması orada duruyor ama hiç kullanılmıyor. BTF önkoşulu hazır, ama üzerine inşa edilecek bir araç yok. Ve en çarpıcısı: filomuzun bir sunucusunda (misp-server), şu an kernel'de ne çalıştığını görebilecek en temel araç bile kurulu değil.

CloudTrail benzeri bir kontrol düzlemi denetimi, bu tabloya hiçbir katkı sağlamaz — çünkü sorduğu soru tamamen farklı bir katmana ait. Gerçek eBPF savunması, kontrol düzleminde değil, kernel'in kendi içinde başlar.

Bir sonraki makalede, bu tablodaki her ⚠️ ve 🔲 işaretini sırayla ele alacağız — kernel lockdown'ı integrity moduna çekmek, bpftool'u filo genelinde standartlaştırmak, ve mümkünse gerçek bir kernel-seviyesi izleme aracını (Tracee ya da Tetragon) kurup test etmek. O makale, bu analizin değil, gerçek aksiyonun kaydı olacak — Phase 1 ve Phase 2'de olduğu gibi, her adımın arkasında komut ve doğrulanmış çıktı olacak.