Ana içeriğe geç

Wallarm eBPF Tabanlı Çözüm (Beta Sürümü)

Wallarm, Linux çekirdeğinin gücünden yararlanan ve Kubernetes ortamlarıyla sorunsuz entegre olan eBPF tabanlı güvenlik çözümünün beta sürümünü sunar. Bu makale, çözümün Helm chart kullanılarak nasıl kullanılacağını ve dağıtılacağını açıklar.

4.10 sürümüyle sınırlıdır

Wallarm eBPF tabanlı çözüm, şu anda yalnızca Wallarm Node 4.10 ile sunulan özellikleri desteklemektedir.

Trafik akışı

Wallarm eBPF tabanlı çözüm ile trafik akışı:

eBPF trafik akışı

eBPF çözümü, aşağıdaki protokolleri kullanarak trafiği izlemek üzere tasarlanmıştır:

  • HTTP 1.x veya HTTP 2

  • Proxy v1 veya Proxy v2

Trafik TLS/SSL şifreleme veya düz metin veri transferi kullanabilir. SSL trafiğinin analizi, paylaşılan OpenSSL kütüphanesini kullanan sunucularla (ör. NGINX, HAProxy) sınırlıdır ve Envoy gibi diğer SSL uygulamalarını kullanan sunucular için mevcut değildir.

Nasıl çalışır

Linux işletim sistemi çekirdek ve kullanıcı alanından oluşur; çekirdek donanım kaynaklarını ve kritik görevleri yönetirken uygulamalar kullanıcı alanında çalışır. Bu ortamda eBPF (Extended Berkeley Packet Filter), güvenliğe odaklananlar da dahil olmak üzere özel programların Linux çekirdeğinde yürütülmesini sağlar. eBPF hakkında daha fazlasını okuyun

Kubernetes, süreç izolasyonu, kaynak yönetimi ve ağ oluşturma gibi kritik görevler için Linux çekirdeğinin yeteneklerinden yararlandığından, eBPF tabanlı güvenlik çözümlerinin entegrasyonu için elverişli bir ortam oluşturur. Bu doğrultuda Wallarm, çekirdeğin işlevselliklerinden yararlanarak Kubernetes ile sorunsuz entegre olan eBPF tabanlı bir güvenlik çözümü sunar.

Çözüm, bir trafik aynası üreten ve bunu Wallarm node’una ileten bir ajandan oluşur. Dağıtım sırasında, yansıtma seviyesini ad alanı (namespace) veya pod düzeyinde belirtebilirsiniz. Wallarm node’u, yansıtılan trafiği güvenlik tehditleri açısından inceler; kötü amaçlı etkinliği engellemez. Bunun yerine, tespit edilen etkinliği Wallarm Cloud’a kaydederek Wallarm Console UI üzerinden trafik güvenliğine görünürlük sağlar.

Aşağıdaki diyagram çözüm bileşenlerini göstermektedir:

eBPF bileşenleri

eBPF ajanı, her Kubernetes işçi (worker) düğümünde bir DaemonSet olarak dağıtılır. Doğru işlevselliği sağlamak için ajan konteynerinin ayrıcalıklı modda çalışması ve şu temel yeteneklere sahip olması gerekir: SYS_PTRACE ve SYS_ADMIN.

Ayrıca çözüm, yanıt kodlarını işler ve Wallarm’ın temel API Discovery modülünün API uç noktalarınızı tanımlamasına, API envanterinizi oluşturmasına ve güncel tutmasına olanak tanır.

Kullanım senaryoları

Desteklenen tüm Wallarm dağıtım seçenekleri arasında bu çözüm, out-of-band çalışma için önerilen seçenektir. Trafiğin içinde çalışmak yerine yansıtılmış bir kopyasını yakalayarak eBPF tabanlı çözüm kesintisiz trafik akışı sağlar. Bu yaklaşım, canlı trafik üzerindeki etkiyi en aza indirir ve gecikmeyi etkileyebilecek ek gecikmelerin önüne geçer.

Teknik gereksinimler

eBPF çözümünün başarıyla dağıtılması için aşağıdaki teknik önkoşulların karşılandığından emin olun:

  • Desteklenen Kubernetes sürümü:

    • AWS - Kubernetes 1.24 ve üzeri
    • Azure - Kubernetes 1.26 ve üzeri
    • GCP - herhangi bir Kubernetes sürümü
    • Bare-metal sunucu - Kubernetes 1.22 ve üzeri
  • Ajanın yakalanan trafiği güvenli bir şekilde Wallarm işleme düğümüne yansıtmasını sağlamak için cert-manager kurulmuş olmalıdır.

  • Helm v3 paket yöneticisi.

  • BTF (BPF Type Format) etkin 5.10 veya 5.15 Linux çekirdeği. Ubuntu, Debian, RedHat, Google COS veya Amazon Linux 2 üzerinde desteklenir.

  • x86_64 mimarisine sahip işlemci.

  • Çözüm beta aşamasında olduğundan, tüm Kubernetes kaynakları etkin biçimde yansıtılamayabilir. Bu nedenle trafiğin özellikle Kubernetes içindeki NGINX Ingress controller’ları, Kong Ingress controller’ları veya normal NGINX sunucuları için yansıtılmasını öneriyoruz.

  • Kullanıcı hesabınızın Wallarm Console üzerinde Administrator erişimi olmalıdır.

Kullanım senaryonuz listelenen gereksinimlerden farklıysa, özel ihtiyaçlarınızı karşılamak için yapılabilecek olası uyarlamaları değerlendirmek üzere ortamınız hakkında ayrıntılı teknik bilgiler vererek satış mühendislerimizle iletişime geçin.

Ağ erişimi

Sınırlı dışa giden trafik bulunan ortamlarda çözümün doğru çalışmasını sağlamak için, aşağıdaki harici kaynaklara erişime izin verecek şekilde ağ erişimini yapılandırın:

  • Wallarm Helm chart’larını eklemek için https://charts.wallarm.com.

  • Wallarm Docker imajlarını Docker Hub’dan çekmek için https://hub.docker.com/r/wallarm.

  • US Wallarm Cloud kullanıcıları https://us1.api.wallarm.com adresine erişmelidir. EU Wallarm Cloud kullanıcıları https://api.wallarm.com adresine erişmelidir.

  • Saldırı tespit kurallarına ve API spesifikasyonlarına yönelik güncellemeleri indirmek, ayrıca izinli, yasaklı veya gri listeye alınmış ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak için aşağıdaki IP adresleri.

    node-data0.us1.wallarm.com - 34.96.64.17
    node-data1.us1.wallarm.com - 34.110.183.149
    us1.api.wallarm.com - 35.235.66.155
    34.102.90.100
    34.94.156.115
    35.235.115.105
    
    node-data1.eu1.wallarm.com - 34.160.38.183
    node-data0.eu1.wallarm.com - 34.144.227.90
    api.wallarm.com - 34.90.110.226
    

Dağıtım

Wallarm eBPF çözümünü dağıtmak için:

  1. Wallarm node’unu oluşturun.

  2. Wallarm Helm chart’ını dağıtın.

  3. Trafik yansıtmayı etkinleştirin.

  4. Wallarm eBPF çalışmasını test edin.

Adım 1: Wallarm node’unu oluşturun

  1. Aşağıdaki bağlantı aracılığıyla Wallarm Console → Nodes bölümünü açın:

  2. Wallarm node türünde bir filtreleme düğümü oluşturun ve üretilen token’ı kopyalayın.

    !Bir Wallarm node'unun oluşturulması

Adım 2: Wallarm Helm chart’ını dağıtın

  1. Ortamınızın yukarıdaki gereksinimleri karşıladığından ve cert-manager kurulu olduğundan emin olun.

  2. Wallarm chart deposunu ekleyin:

    helm repo add wallarm https://charts.wallarm.com
    helm repo update wallarm
    

  3. Wallarm eBPF çözüm yapılandırması ile values.yaml dosyasını oluşturun.

    Minimum yapılandırmalı dosya örneği:

    config:
      api:
        token: "<NODE_TOKEN>"
        host: "us1.api.wallarm.com"
    
    config:
      api:
        token: "<NODE_TOKEN>"
    

    <NODE_TOKEN>, Kubernetes’te çalıştırılacak Wallarm node’unun token’ıdır.

    Using one token for several installations

    You can use one token in several installations regardless of the selected platform. It allows logical grouping of node instances in the Wallarm Console UI. Example: you deploy several Wallarm nodes to a development environment, each node is on its own machine owned by a certain developer.

  4. Wallarm Helm chart’ını dağıtın:

    helm install --version 0.10.28 <RELEASE_NAME> wallarm/wallarm-oob --wait -n wallarm-ebpf --create-namespace -f <PATH_TO_VALUES>
    
    • <RELEASE_NAME>, Wallarm eBPF chart’ının Helm sürümü için isimdir
    • wallarm-ebpf, Wallarm eBPF chart’ı ile Helm sürümünün dağıtılacağı yeni ad alanıdır; ayrı bir ad alanına dağıtılması önerilir
    • <PATH_TO_VALUES>, values.yaml dosyasının yoludur

Adım 3: Trafik yansıtmayı etkinleştirin

NGINX Ingress controller, Kong Ingress controller veya normal NGINX sunucuları için Wallarm eBPF tabanlı çözümden etkin şekilde yararlanmak amacıyla trafik yansıtmayı etkinleştirmenizi öneririz.

Varsayılan olarak, dağıtılan çözüm herhangi bir trafiği analiz etmez. Trafik analizini etkinleştirmek için, istediğiniz seviyede trafik yansıtmayı etkinleştirmeniz gerekir; seçenekler:

  • Bir ad alanı (namespace) için

  • Bir pod için

  • Bir düğüm adı veya bir konteyner için

Trafik yansıtmayı etkinleştirmenin iki yolu vardır: ad alanı etiketleri veya pod açıklamaları (annotation) olarak dinamik filtreler kullanmak ya da values.yaml dosyasındaki config.agent.mirror.filters bloğu üzerinden kontrol etmek. Bu yaklaşımları birleştirebilirsiniz. Daha fazla bilgi

Bir ad alanı için bir etiket kullanarak

Bir ad alanı için yansıtmayı etkinleştirmek üzere, ad alanı etiketi wallarm-mirror değerini enabled olarak ayarlayın:

kubectl label ns <NAMESPACE> wallarm-mirror=enabled

Bir pod için bir açıklama kullanarak

Bir pod için yansıtmayı etkinleştirmek üzere, mirror.wallarm.com/enabled açıklamasını true olarak ayarlayın:

kubectl patch deployment <DEPLOYMENT_NAME> -n <NAMESPACE> -p '{"spec": {"template":{"metadata":{"annotations":{"mirror.wallarm.com/enabled":"true"}}}} }'

values.yaml kullanarak ad alanı, pod, konteyner veya düğüm için

Daha ayrıntılı kontrol için, Wallarm eBPF’in values.yaml dosyasındaki config.agent.mirror.filters bloğunu kullanarak yansıtma seviyesini belirtebilirsiniz. Filtrelerin nasıl yapılandırılacağını ve Wallarm ad alanı etiketleri ile pod açıklamalarıyla nasıl etkileşime girdiğini anlatan makaleyi okuyun.

Adım 4: Wallarm eBPF çalışmasını test edin

Wallarm eBPF’in doğru çalıştığını test etmek için:

  1. Başarıyla başlatıldıklarını kontrol etmek üzere Wallarm pod ayrıntılarını alın:

    kubectl get pods -n <NAMESPACE> -l app.kubernetes.io/name=wallarm-oob
    

    Her pod aşağıdakileri göstermelidir: READY: N/N ve STATUS: Running, örn.:

    NAME                                                   READY   STATUS    RESTARTS   AGE
    wallarm-ebpf-wallarm-oob-agent-599xg                   1/1     Running   0          7m16s
    wallarm-ebpf-wallarm-oob-aggregation-f68959465-vchxb   4/4     Running   0          30m
    wallarm-ebpf-wallarm-oob-processing-694fcf9b47-rknx9   4/4     Running   0          30m
    
  2. Uygulamaya test Path Traversal saldırısını, <LOAD_BALANCER_IP_OR_HOSTNAME> değerini trafiği ona yönlendiren yük dengeleyicinin gerçek IP adresi veya DNS adıyla değiştirerek gönderin:

    curl https://<LOAD_BALANCER_IP_OR_HOSTNAME>/etc/passwd
    

    Wallarm eBPF çözümü out-of-band yaklaşımıyla çalıştığından saldırıları engellemez, yalnızca kaydeder.

    Saldırının kaydedildiğini doğrulamak için Wallarm Console → Events bölümüne gidin:

    !Arayüzde saldırılar

Sınırlamalar

  • Trafiği gerçek akıştan bağımsız analiz eden out-of-band (OOB) çalışma nedeniyle çözümün bazı doğal sınırlamaları vardır:

  • Sunucu yanıt gövdeleri yansıtılmadığından:

  • Çözüm beta aşamasında olduğundan, tüm Kubernetes kaynakları etkin biçimde yansıtılamayabilir. Bu nedenle trafiğin özellikle Kubernetes içindeki NGINX Ingress controller’ları, Kong Ingress controller’ları veya normal NGINX sunucuları için yansıtılmasını öneriyoruz.