eBPF ile Linux Runtime Güvenliği: Falco ve Tetragon Uygulama Rehberi

eBPF, Linux çekirdeğinde olayları düşük gecikmeyle gözlemlemek ve belirli koşullarda güvenlik politikası uygulamak için kullanılan programlanabilir bir altyapıdır. Güvenlik ekipleri eBPF sayesinde süreç çalıştırma, dosya erişimi, ağ bağlantısı, yetki değişimi ve container davranışını yalnız uygulama loglarına bağlı kalmadan çekirdek seviyesinde izleyebilir.

Bu rehber iki yaygın açık kaynak yaklaşımı karşılaştırır: Falco, kernel olaylarını kurallarla değerlendirip uyarı üretmeye odaklanır; Tetragon ise eBPF tabanlı gözlemin yanında kernel içinde filtreleme ve belirli olaylarda enforcement uygulayabilir. İki araç aynı görünse de veri modeli, politika dili ve operasyonel riskleri farklıdır.

Amaç “her syscall'ı toplayıp SIEM'e göndermek” değildir. Üretim ortamında değerli sinyalleri seçmek, gürültüyü ölçmek, kuralları sürümlemek ve engelleme davranışını önce yalnız izleme modunda doğrulamak gerekir.

eBPF runtime güvenliği nedir?

Runtime güvenliği, iş yükü çalışırken ortaya çıkan gerçek davranışı izler. Bir container imajı taramada temiz görünebilir; fakat başlatıldıktan sonra shell açabilir, hassas dosya okuyabilir, beklenmeyen bir adrese bağlanabilir veya yeni bir binary çalıştırabilir. eBPF sensörleri bu eylemlere yakın çekirdek kancalarında görünürlük sağlayabilir.

Katman	Gördüğü bilgi	Örnek güvenlik sorusu
İmaj / paket tarama	Dosya ve bağımlılık durumu	Bilinen zafiyetli paket var mı?
Kubernetes audit logu	API isteği ve nesne değişikliği	Deployment'ı kim değiştirdi?
Uygulama logu	Uygulamanın yazdığı olay	Hangi kullanıcı hatalı istek yaptı?
eBPF runtime sensörü	Süreç, dosya, ağ ve kernel olayı	Pod içinde kim shell çalıştırdı?
SIEM / korelasyon	Çoklu kaynağın zaman çizelgesi	Bu olay diğer sinyallerle ilişkili mi?

eBPF görünürlüğü diğer katmanların yerine geçmez. İmaj taraması önleme ve tedarik zinciri riskini, Kubernetes audit logu kontrol düzlemini, EDR ise uç nokta bağlamını sağlar. Runtime sensörü bu verileri davranış kanıtıyla tamamlar.

Falco ve Tetragon arasındaki temel fark

Falco, kernel modülü veya modern eBPF probe üzerinden sistem çağrısı olaylarını alır; koşul, makro ve listelerden oluşan YAML kurallarıyla değerlendirir ve eşleşmede uyarı üretir. Modern eBPF probe Falco ikilisinin içine gömülüdür ve CO-RE yaklaşımıyla farklı kernel sürümlerinde taşınabilirliği kolaylaştırır.

Tetragon, kprobe, tracepoint, uprobe ve desteklenen LSM hook noktalarını TracingPolicy kaynaklarıyla izleyebilir. Seçiciler, pod etiketi, namespace, container alanı veya syscall argümanı gibi bağlamlarla olayları kernel içinde filtreleyebilir. Uygun politika ve kernel yetenekleriyle dönüş değerini değiştirme veya sürece sinyal gönderme gibi enforcement eylemleri de uygulanabilir.

Ölçüt	Falco	Tetragon
Ana yaklaşım	Davranışsal algılama ve uyarı	Gözlemlenebilirlik ve isteğe bağlı enforcement
Politika biçimi	Falco rule, macro ve list YAML'i	TracingPolicy / TracingPolicyNamespaced CRD
Yaygın veri	Syscall olayları ve eklenti kaynakları	Süreç, dosya, ağ, kprobe/tracepoint/uprobe/LSM
Kubernetes bağlamı	Container ve orkestrasyon meta verisiyle zenginleştirme	Namespace, pod etiketi ve container seçicilerini kernel filtresine taşıma
Tepki modeli	Öncelikle uyarı ve harici entegrasyon	İzleme, sinyal veya uygun hook'ta inline engelleme
Operasyonel risk	Gürültü ve olay kaybı	Yanlış policy ile iş yükünü durdurma veya kernel uyumsuzluğu

Araç seçimi “hangisi daha güçlü?” sorusundan çok kullanım amacına bağlıdır. Hızlı davranışsal algılama ve zengin hazır kural ekosistemi için Falco; düşük seviyeli özel gözlem ve kontrollü inline enforcement için Tetragon uygun olabilir. Aynı ortamda ikisini birlikte çalıştırmak da mümkündür, ancak çift telemetri maliyeti ölçülmelidir.

eBPF güvenli mi?

eBPF programları çekirdek bağlamında çalıştığı için Linux verifier tarafından yükleme öncesi denetlenir. Verifier bellek erişimi, kontrol akışı ve program güvenliği gibi kuralları kontrol eder. Bu mekanizma güçlüdür fakat “eBPF kullanan her ürün otomatik olarak güvenlidir” anlamına gelmez.

Sensör yüksek ayrıcalık ve kernel yetenekleri gerektirebilir.
Yanlış veya aşırı geniş kanca seçimi performans maliyeti oluşturabilir.
Ürün ve kernel sürümü uyumsuzluğu veri kaybına veya sensörün başlamamasına yol açabilir.
Politika yönetim arayüzü ele geçirilirse görünürlük veya enforcement kötüye kullanılabilir.
Olay çıktısı komut satırı, dosya yolu ve kullanıcı bilgisi gibi hassas veri içerebilir.

Bu nedenle sensör imajı, Helm chart, kural deposu ve yönetim API'si tedarik zinciri kontrollerine dâhil edilmelidir. İmzalı artefakt, sabit sürüm, image digest ve değişiklik incelemesi kullanılmalıdır.

Falco modern eBPF probe mimarisi

Falco'nun kernel event source'u, sistem çağrılarını kullanıcı alanına taşır. Modern eBPF probe varsayılan sürücülerden biridir ve CO-RE, BPF ring buffer gibi çekirdek özelliklerinden yararlanır. Güncel Falco belgeleri, modern eBPF motorunun engine.kind: modern_ebpf ile seçilebildiğini belirtir.

CODE TERMINAL

engine:
  kind: modern_ebpf

rules_files:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/falco_rules.local.yaml
  - /etc/falco/rules.d

Kurulum yöntemi ve yapılandırma anahtarı kullanılan Falco sürümüyle doğrulanmalıdır. Falco 0.44.0 sürümü legacy eBPF probe, gVisor engine ve eski gRPC output/server bileşenlerini kaldırmıştır. Eski blog veya değer dosyalarını kopyalamak, yeni sürümde başarısız kurulum yaratabilir.

Falco'da ilk özel kural

Bir Falco kuralı; benzersiz ad, açıklama, koşul, çıktı ve öncelik alanlarından oluşur. Aşağıdaki örnek, container içinde shell başlatılmasını görünür kılar:

CODE TERMINAL

- rule: Interactive Shell in Production Container
  desc: Üretim namespace'inde beklenmeyen shell çalıştırılmasını izler
  condition: >
    container.id != host and
    evt.type in (execve, execveat) and
    proc.name in (bash, sh, zsh, dash) and
    k8s.ns.name = "production"
  output: >
    Container shell detected |
    user=%user.name command=%proc.cmdline
    container=%container.name image=%container.image.repository
    namespace=%k8s.ns.name pod=%k8s.pod.name
  priority: WARNING
  tags: [container, execution, mitre_execution]

Alanların kullanılabilirliği olay kaynağına, Falco sürümüne ve metadata zenginleştirmesine bağlıdır. Kuralı canlıya almadan önce falco --list-fields ve güncel alan referansıyla doğrulayın.

Falco kuralında gürültü nasıl azaltılır?

“Container içinde shell” güçlü bir sinyaldir; ancak bakım işleri, debug sidecar'ları, init container'lar ve yönetim ajanları meşru shell çalıştırabilir. Kuralı tamamen kapatmak yerine istisnayı dar bağlamla tanımlayın.

İmaj adını değil mümkünse image digest veya doğrulanmış repository+tag politikasını kullanın.
Tek başına process adına güvenmeyin; parent process, namespace, kullanıcı ve terminal bağlamını ekleyin.
İstisnayı bütün cluster yerine belirli workload ve bakım kimliğiyle sınırlandırın.
Kural eşleşme sayısını namespace ve workload bazında ölçün.
İstisnaya sahip, son kullanım tarihi ve gözden geçirme zamanı ekleyin.

Falco'nun güncel override yapısı append ve replace davranışlarını açıkça belirtir. Eski append: true örnekleri kullanım dışına çıkarılmaktadır; yeni kural dosyalarında override bölümü tercih edilmelidir.

CODE TERMINAL

- list: trusted_debug_images
  items: [registry.example/debug-tool]
  override:
    items: append

Kural dosyalarının yüklenme sırası önemlidir. Yerel override dosyası varsayılan listeden önce yüklenirse değişiklik beklenen sonucu vermeyebilir.

Falco olayını SIEM'e hazırlama

Uyarı metni yalnız insan için okunabilir olmamalı; korelasyon için kararlı alanlar taşımalıdır:

Kural adı ve sürümü
Öncelik ve etiketler
Node, namespace, pod, container ve image digest
Kullanıcı, UID, süreç, parent process ve komut satırı
Dosya veya ağ hedefi
Olay zamanı ve benzersiz olay kimliği

Komut satırında parola veya token bulunabileceği için SIEM'e gönderilen alanlar veri minimizasyonu politikasına tabi olmalıdır. Gerekirse secret pattern redaction, erişim kontrolü ve kısa saklama süresi uygulanmalıdır.

Tetragon TracingPolicy nasıl çalışır?

Tetragon politikası bir veya daha fazla hook noktası, argüman tanımı, seçici ve eylem içerir. Kubernetes'te TracingPolicy cluster kapsamlı, TracingPolicyNamespaced ise namespace kapsamlı kullanılabilir.

Aşağıdaki örnek yalnız gözlem amaçlı basitleştirilmiş bir dosya açma politikasıdır:

CODE TERMINAL

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
  name: observe-sensitive-file-open
  namespace: production
spec:
  options:
    - name: policy-mode
      value: monitor
  lsmhooks:
    - hook: file_open
      args:
        - index: 0
          type: file
      selectors:
        - matchArgs:
            - index: 0
              operator: Prefix
              values:
                - /etc/

Bu örnek kavramsaldır. Kullanılan hook, argüman indeksi, operator ve kernel LSM BPF desteği güncel Tetragon referansı ve laboratuvar ortamıyla doğrulanmalıdır. Düşük seviyeli policy kopyalayıp doğrudan üretimde çalıştırılmamalıdır.

Hook seçimi ve TOCTOU riski

Tetragon belgeleri, kullanıcı alanı belleğine işaret eden syscall argümanlarının time-of-check to time-of-use (TOCTOU) riski taşıyabileceğine dikkat çeker. Kullanıcı alanı değerini bir kprobe anında okumak, çekirdeğin gerçekten kullandığı son değerle her zaman aynı olmayabilir.

Dosya güvenlik kararlarında daha geç çalışan bir Linux Security Module hook'u, veri çekirdek belleğine kopyalandıktan sonra gözlem yaptığı için daha güvenilir olabilir. Ancak LSM BPF desteği, kernel yapılandırması ve dağıtım politikası ön koşuldur.

Hook türü	Güçlü yanı	Dikkat edilmesi gereken
kprobe	Çok sayıda kernel fonksiyonunu izleyebilir	Kernel sürümüne ve fonksiyon imzasına bağımlı olabilir
tracepoint	Daha kararlı olay sözleşmesi	Her gereken ayrıntı için tracepoint olmayabilir
uprobe	Kullanıcı alanı fonksiyonunu izler	Binary sürümü, sembol ve offset değişebilir
LSM hook	Güvenlik karar noktasına yakın gözlem/enforcement	Kernel LSM BPF desteği ve yüksek etki riski

Tetragon enforcement güvenli nasıl açılır?

Tetragon politikaları monitoring, enforcement ve monitor_only modlarıyla yönetilebilir. Enforcement, bir fonksiyon dönüşünü değiştirme veya sürece sinyal gönderme gibi sonuçlar doğurabilir. Yanlış eşleşme üretim uygulamasını anında durdurabileceği için aşamalı geçiş zorunludur.

Politikayı önce monitor modunda çalıştırın.
En az bir normal iş yükü döngüsü boyunca eşleşme hacmini ölçün.
Bakım, dağıtım, health check ve autoscaling davranışlarını test edin.
Namespace, pod label ve container selector ile kapsamı daraltın.
Canary node veya sınırlı workload üzerinde enforcement açın.
Rollback komutunu ve erişim kanalını önceden doğrulayın.
Yanlış pozitif ve kaçırılan olaylar kabul eşiğine geldiğinde kapsamı büyütün.

Sürece SIGKILL göndermek işlemi sonlandırır; ancak çağrının yan etkisinin hiç gerçekleşmediğini her durumda garanti etmez. Tetragon belgeleri, kesin engelleme gereken durumlarda uygun hook ve Override davranışının değerlendirilmesini önerir.

Kubernetes kimlik farkındalığı

Tetragon, namespace, pod etiketi ve container alanlarını kernel içi filtrelemeye taşıyabilir. Bu yaklaşım, yalnız ilgili olayların kullanıcı alanına gönderilmesiyle telemetri hacmini azaltır ve enforcement kararını olay sonrasında değil çekirdek içinde uygular.

Namespace adı tek başına güven sınırı değildir; namespace oluşturma yetkisini kontrol edin.
Pod label değiştirme yetkisi, politikanın hangi iş yüküne uygulanacağını etkileyebilir.
Node label düzenleyebilen kullanıcı, nodeSelector kapsamını değiştirebilir.
OCI runtime hook kullanılmıyorsa yeni container başlangıcında metadata ilişkilendirmesi gecikebilir.
Host workload ve container kapsamlarını ayrı policy ile yönetin.

Etiket yönetişimi güvenlik politikasının parçasıdır. “security=protected” etiketiyle policy seçiliyorsa bu etiketi kimlerin değiştirebildiği en az policy içeriği kadar önemlidir.

Falco mu Tetragon mu?

İhtiyaç	Önerilen başlangıç
Hazır davranışsal kural ve hızlı uyarı	Falco
Syscall tabanlı container tehdit tespiti	Falco
Özel kernel fonksiyonu veya LSM hook gözlemi	Tetragon
Kernel içinde seçici filtre ve inline tepki	Tetragon
SOC için geniş kural topluluğu	Falco
Cilium tabanlı Kubernetes bağlamıyla derin izleme	Tetragon
Engelleme öncesi bağımsız algılama katmanı	Falco veya iki aracın kontrollü birlikte kullanımı

Araç seçimi pilot ölçümle yapılmalıdır. Aynı olayın iki sensörde farklı ad, zaman ve süreç ağacıyla görünmesi korelasyon maliyeti yaratabilir. Çift kurulumda hangi aracın hangi güvenlik sorusunun sahibi olduğu belirlenmelidir.

Performans ve olay kaybı

eBPF “sıfır maliyetli” değildir. Her hook, veri kopyalama, ring buffer, zenginleştirme ve çıktı işlemi CPU ile bellek tüketir. Aşırı geniş politika hem iş yükünü hem de güvenlik boru hattını zorlayabilir.

Olay/saniye, düşürülen olay, ring buffer doluluğu ve sensör CPU'sunu izleyin.
Komut satırı ve tam path gibi pahalı alanları yalnız gerekli kurallarda toplayın.
Kernel içinde filtrelemeyi mümkün olduğunda workload bağlamıyla daraltın.
Yük testi sırasında deploy, autoscaling ve incident senaryolarını birlikte ölçün.
SIEM kesintisinde yerel buffer ve yeniden deneme davranışını test edin.
Sensör sağlığını ayrı bir alarm olarak yönetin; “uyarı yok” durumunu sağlıklı kabul etmeyin.

Falco'da supported events listesi, sürücülerin hangi syscall ve metaevent türlerini sağlayabildiğini gösterir. Her olay varsayılan olarak toplanmayabilir; -A gibi tüm olayları açan seçenekler üretimde hacmi ciddi biçimde artırabilir.

Üretim mimarisi

Sağlam bir dağıtımda sensör, politika, çıktı ve doğrulama zinciri ayrılır:

Sensör katmanı: Node üzerinde Falco veya Tetragon, imzalı ve sabitlenmiş sürümle çalışır.
Politika katmanı: Kural ve TracingPolicy dosyaları Git üzerinde kod incelemeden geçer.
Dağıtım katmanı: Helm/Argo CD gibi araçlar kontrollü canary dağıtımı yapar.
Çıktı katmanı: Olaylar TLS korumalı bir kolektör veya mesaj kuyruğuna gider.
Korelasyon katmanı: SIEM, Kubernetes audit, identity, network ve EDR sinyallerini birleştirir.
Doğrulama katmanı: Güvenli test olayları kuralın gerçekten çalıştığını periyodik olarak kanıtlar.

Policy-as-code yalnız YAML'i depolamak değildir. Şema doğrulama, test olayı, beklenen çıktı, sürüm uyumluluğu ve rollback bilgisi aynı değişiklik paketinde tutulmalıdır.

Test stratejisi

Bir runtime güvenlik kuralı için en az üç test gerekir:

Test	Amaç	Başarı ölçütü
Pozitif test	Tehdit davranışının yakalandığını kanıtlar	Beklenen tek uyarı doğru alanlarla üretilir
Negatif test	Normal davranışın sustuğunu kanıtlar	Meşru iş yükü alarm üretmez
Hacim testi	Ölçek altında dayanıklılığı ölçer	Olay kaybı, CPU ve gecikme eşik içinde kalır

Enforcement politikasında dördüncü test rollback'tir. Policy silme, mod değiştirme veya sensör yeniden başlatma sırasında korumanın ve iş yükünün nasıl davrandığı önceden ölçülmelidir.

Gizlilik ve veri güvenliği

Runtime telemetrisi kişisel veri ve sır içerebilir. Komut satırı argümanında token, dosya yolunda kullanıcı adı veya ağ olayında hassas iç IP bulunabilir.

Toplanan her alan için güvenlik amacı ve saklama süresi tanımlayın.
Ham olay erişimini SOC rolüyle sınırlayın.
Komut satırındaki bilinen secret biçimlerini maskeleyin.
Test ortamında gerçek müşteri verisi kullanmayın.
Olay aktarımını TLS ile şifreleyin ve alıcı kimliğini doğrulayın.
Kural çıktısına gereksiz environment variable veya tam payload eklemeyin.

Üretime geçiş kontrol listesi

İzlenecek tehdit davranışlarını MITRE tekniği veya kurum use-case'iyle eşleyin.
Kernel, dağıtım ve container runtime uyumluluğunu doğrulayın.
Falco/Tetragon sürümünü ve image digest'ini sabitleyin.
Gerekli capability ve privileged izinlerini en aza indirin.
Varsayılan kuralları ölçmeden topluca açmayın.
Özel kuralları pozitif, negatif ve hacim testinden geçirin.
Kubernetes label ve namespace değiştirme yetkilerini denetleyin.
Enforcement'ı önce monitor modunda ve canary kapsamda çalıştırın.
Olay kaybı, sensör sağlığı, CPU ve buffer metriklerine alarm kurun.
SIEM şemasında workload kimliği ve image digest alanlarını koruyun.
Kural değişiklikleri için sahip, son gözden geçirme tarihi ve rollback kaydı tutun.
Üç ayda bir sahte pozitif, sessiz kural ve kullanılmayan istisnaları temizleyin.

Sık sorulan sorular

eBPF bir EDR midir?

Hayır. eBPF bir çekirdek programlama ve gözlem altyapısıdır. Falco ve Tetragon gibi araçlar bu altyapıyı güvenlik için kullanır; varlık envanteri, olay müdahalesi, tehdit istihbaratı ve merkezi yönetim gibi EDR işlevlerinin tamamını tek başına sağlamaz.

Falco saldırıyı otomatik engeller mi?

Falco'nun ana modeli algılama ve uyarıdır. Harici tepki sistemleriyle süreç sonlandırma veya izolasyon kurgulanabilir; ancak güvenli yetkilendirme, idempotency ve yanlış pozitif kontrolü gerekir.

Tetragon her Linux sisteminde enforcement yapabilir mi?

Hayır. Kullanılan hook ve eylem kernel özelliklerine, BPF/LSM yapılandırmasına ve yetkilere bağlıdır. tetra probe ile özellikler kontrol edilmeli ve laboratuvarda doğrulanmalıdır.

İki araç birlikte kurulmalı mı?

Yalnız ayrı ve ölçülebilir use-case'ler varsa. Aynı syscall olayını iki kez toplamak CPU, ağ ve SIEM maliyetini artırabilir. Sahiplik ve veri kapsamı ayrılmadan çift kurulum önerilmez.

Runtime güvenliği imaj taramasının yerini alır mı?

Hayır. İmaj tarama dağıtım öncesi riskleri, runtime sensörü ise çalışırken oluşan davranışı görür. En iyi sonuç iki katmanın birlikte kullanılmasıdır.

Sonuç

eBPF tabanlı runtime güvenliği, Linux ve Kubernetes ortamında süreç, dosya ve ağ davranışını çekirdeğe yakın noktada görünür kılar. Falco, kurala dayalı algılama ve uyarı için güçlü bir başlangıç sunarken Tetragon düşük seviyeli gözlem, kernel içi filtreleme ve kontrollü enforcement sağlar.

Başarılı uygulama teknoloji kurmakla bitmez. Dar kapsamlı use-case, sürüm uyumluluğu, policy-as-code, pozitif/negatif test, olay kaybı izlemesi, gizlilik ve aşamalı enforcement birlikte ele alınmalıdır. En güvenli başlangıç; önce görünürlük, sonra ölçüm, en son geri dönüşü kanıtlanmış engellemedir.

Kaynaklar

TR Siber Ekibi Yazar · X

Kaynak bağlantısı ← Ana sayfaya dön