Konteyner Kaçış Saldırılarının Tespiti ve Önlenmesi

Ana Sayfa » Python » Konteyner Kaçış Saldırılarının Tespiti ve Önlenmesi

Konteyner kaçışı, bulut ve platform ekiplerini geceleri uyutmayan konulardan biri haline geldi Çünkü yanlış yapılandırılmış tek bir pod veya güncel olmayan bir çekirdek, izole bir iş yükünü altta yatan ana bilgisayara doğrudan bir köprüye dönüştürebilir. Bu gerçekleştiğinde, saldırgan artık tek bir kapsayıcıya hapsedilmiş olmaz: düğümler arasında hareket edebilir, diğer kiracıların verilerine erişebilir ve hatta tüm kümeyi ele geçirebilir.

Konteyner kaçışlarının gerçekte nasıl çalıştığını anlamak (Linux iç bileşenlerinden çalışma zamanı sinyallerine ve EDR tespitlerine kadar) korkutucu bir moda sözcük ile gerçekten yönetebileceğiniz bir risk arasındaki farktırBu kılavuzda, işletim sistemi düzeyinde bir konteynerin ne olduğunu, kaçışların pratikte nasıl gerçekleştiğini, doğada görülen başlıca istismar tekniklerini ve bunların yetenek izleme, Falco kuralları, CNAPP platformları ve eski usul güçlendirme ve segmentasyon ile nasıl tespit edilip önleneceğini ele alacağız.

Konteyner kaçışı nedir ve neden önemlidir?

Bir saldırgan, bir konteyneri ana bilgisayardan ve diğer konteynerlerden ayırması gereken mantıksal izolasyonu kırmayı başardığında konteyner kaçışı meydana gelirSaldırgan, kendi ad alanları ve cgruplarıyla sınırlı kalmak yerine, genellikle yüksek veya tam ayrıcalıklarla ana bilgisayar düzeyinde bağlamla kod çalıştırma yeteneği kazanır.

Konteynerler sanal makinelerden önemli bir noktada farklılık gösterir: hepsi aynı ana çekirdeği paylaşırLinux ad alanları (PID, bağlama, ağ, vb.), cgroup'lar ve yetenekler gibi teknolojiler, bu çekirdeği birçok izole görünüme böler; ancak bir güvenlik açığı veya yanlış yapılandırma bir saldırganın bu sınırları aşmasına izin verirse, ihlal ilk olarak saldırıya uğrayan konteynerin çok ötesine yayılabilir.

İş açısından bakıldığında, başarılı bir kaçışın patlama yarıçapı onu bu kadar tehlikeli yapan şeydirİnternete bakan tek bir savunmasız konteyner, hassas verilerin çalınmasına, kripto madencilerinin büyük ölçekte konuşlandırılmasına, kritik hizmetlerin kesintiye uğramasına ve çok kiracılı veya düzenlenmiş ortamlarda büyük uyumluluk sorunlarına yol açabilir.

Saldırganlar genellikle konteyner kaçışını daha geniş bir saldırı zincirinin bir adımı olarak kullanırlar: düşük ayrıcalıklı bir konteynera inerler (uygulama hataları, zayıf kimlik bilgileri veya bir tedarik zinciri sorunu nedeniyle), konteyner içindeki ayrıcalıkları yükseltirler, ardından yatay olarak eksen kaydırmak, kimlik bilgilerini toplamak veya çekirdek düzeyinde bir kök araç takımı gibi kalıcı kalıcılık oluşturmak için ana bilgisayara geçerler.

Konteynerler perde arkasında nasıl çalışır?

Kaçış tekniklerini gerçekten kavramak için öncelikle Linux kapsayıcılarının süreçleri nasıl izole ettiğine dair zihinsel bir modele ihtiyacınız varBir konteyner, esasen nitelikleri (ad alanları, yetenekler, cgroup'lar, seccomp profili vb.) containerd, Docker veya CRI-O gibi bir konteyner çalışma zamanı ve daha geniş kapsamlı olarak değiştirilmiş bir işlem ağacıdır. konteynerizasyon teknolojileri.

Bir konteyner başlatıldığında, çalışma zamanı bir işlem başlatır ve onu kendi küçük evreninin "init" işlemine dönüştürür: Çekirdek tarafından zorunlu kılınan kendi PID ad alanını, bağlama ad alanını, ağ ad alanını ve daha fazlasını alır. Bu işlem daha sonra görüntü yapılandırmasında tanımlanan komutu (örneğin, Dockerfile'ın ENTRYPOINT/CMD'si) çalıştırır.

Yetenekler, Linux'un geleneksel çok güçlü kökü daha küçük izin parçalarına ayırma yoludur"Kök her şeyi yapabilir" yerine, çekirdek şu gibi bayrakları tanımlar: CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG ve onlarcası daha. Her iş parçacığı, hangi ayrıcalıklı işlemleri gerçekleştirebileceğini tanımlayan yetenek kümeleri (izin verilen, etkili, devralınabilir) taşır.

Ad alanları, "Bir süreç yetkilerini nerede kullanabilir?" sorusuna yanıt verir.Örneğin, PID ad alanı, kapsayıcı içindeki PID 1'i ana bilgisayardaki PID 1'den bağımsız hale getirir ve bağlama ad alanı, kapsayıcıya kendi dosya sistemi görünümünü verir. Bir işlemin aşağıdaki gibi bir yeteneği olsa bile: CAP_KILL, sınırlı bir PID ad alanında yalnızca o ad alanında var olan işlemleri öldürebilir.

Cgrupları, bir konteynerin ne kadar kaynak yakabileceğini kontrol ederek bu izolasyonu tamamlar – CPU paylaşımları, bellek sınırları, G/Ç ve daha fazlası. Seccomp filtreleri (sistem çağrısı izin/reddetme listeleri) ve AppArmor veya SELinux gibi LSM'lerle birleştirildiğinde, modern konteyner güvenliğinin dayandığı katmanlı izolasyona sahip olursunuz.

Saldırganlar neden konteynerlerden kaçmaya çalışır?

Bir düşman bir konteyneri tehlikeye attığında, içindeki yaşamın oldukça kısıtlı olduğunu hemen keşfeder: sınırlı dosya sistemi, kısıtlı ağ görünümü, belki kök dışı ve genellikle diğer iş yüklerine doğrudan erişim yok.

Ev sahibine kaçmak, o bariyerleri ortadan kaldırırEğer ana bilgisayarın başlangıç ​​ad alanlarında komutları çalıştırabiliyorlarsa, tüm işlemleri görebilir, herhangi bir dosya sistemini bağlayabilir, aşağıdaki gibi yerlerden kimlik bilgilerini toplayabilirler: /root/.ssh veya bulut meta veri aracılarını kullanın ve diğer kapsayıcılara veya sanal makinelere geçiş yapın.

Kaçışlar aynı zamanda ortadan kaldırılması zor olan ısrarcılığı da mümkün kılarBir saldırgan, yalnızca geçici bir konteynere arka kapı bırakmak yerine, bir çekirdek modülü yükleyebilir, runc veya containerd gibi konteyner çalışma zamanlarını bozabilir veya arka kapılı bir pod'un bir Kubernetes kümesindeki her düğümde çalışmasını sağlayan bir daemonset dağıtabilir.

Algılama açısından bakıldığında, konteyner kaçışına dair birçok belirgin sinyal, klasik ayrıcalık yükseltme ve yanal hareket davranışlarıyla örtüşmektedir – çekirdek modülü yükleniyor, şüpheli mount/unshare/setns kullanım, çalışma zamanı soketlerine doğrudan erişim, SUID istismarı ve konteynerlerin içinde açığa çıkan ana bilgisayar yollarına anormal dosya erişimleri.

Konteyner kaçışının ana yolları: güvenlik açıkları, ayrıcalıklar ve yanlış yapılandırmalar

Gerçek dünyadaki konteyner kaçış senaryolarının çoğu üç geniş kategoriye ayrılır: güvenlik açıklarından (çekirdek veya çalışma zamanı) faydalanmak, aşırı ayrıcalıklı kapsayıcıları kötüye kullanmak veya tehlikeli bağlantılar ve açıkta kalan soketler gibi yanlış yapılandırmalardan yararlanmak.

Çekirdek ve kapsayıcı çalışma zamanı güvenlik açıkları

Her kapsayıcı ana çekirdeği paylaştığı için, tek bir çekirdek hatası doğrudan kaçış yolu sunabilirDirty COW (CVE‑2016‑5195) ve Dirty Pipe (CVE‑2022‑0847) gibi bilinen sorunlar, saldırganların salt okunur eşlemelere ve keyfi dosyalara yazmasına olanak tanıyan yerel ayrıcalık yükseltme hatalarıdır ve bu da genellikle bir kapsayıcının içinden ana bilgisayar ikili dosyalarına veya yapılandırmasına müdahale etmelerine olanak tanır.

Özellikle kritik bir konteynere özgü hata runc'deki CVE-2019-5736'ydıBir konteynerdeki bir işlemin, konteyner başlatıldığında veya çalıştırıldığında ana bilgisayardaki runc ikili dosyasının üzerine yazmasına ve saldırgana ana bilgisayar düzeyinde kod yürütme olanağı sağlamasına olanak tanıyordu. Runc, Docker, Kubernetes ve diğer platformların temelini oluşturduğundan, etkisi geniş kapsamlıydı.

Daha yakın zamanda, "Sızdıran Kaplar" (örneğin, CVE‑2024‑21626) gibi açıklamalar, yapı sistemlerinin ve başlangıç ​​yollarının da verimli bir zemin olduğunu gösterdiBuildKit veya runc başlatma mantığındaki güvenlik açıkları, saldırganların diğer savunmalar tam olarak uygulanmadan önce görüntü oluşturma veya erken konteyner başlatma sırasında sızmasına olanak tanır.

containerd, Docker Engine veya CRI‑O gibi konteyner çalışma zamanı daemon'larının kendi hataları vardıÖrneğin, containerd'nin CRI eklentisindeki CVE‑2022‑23648, konteyner oluşturabilen saldırganların hassas ana bilgisayar yollarını (örneğin) bağlamasına izin verdi. /root/.ssh) bir kaba koyup asla görmemeleri gereken verileri okuyarak tam kaçışa giden yolu açıyorlar.

Önemli konteyner kaçış CVE'leri ve bunların nasıl azaltılacağı

• CVE‑2019‑5736 (runc): ana bilgisayarın runc ikili dosyasının bir konteynerden yeniden yazılmasına izin verildiDocker, Kubernetes ve diğer runc tabanlı yığınları etkileyen güvenlik önlemleri arasında agresif yamalama, istismar araçları için görüntü tarama ve runc ikili değişikliklerinin çalışma zamanında izlenmesi yer alır.

• CVE‑2016‑5195 (Kirli İNEK): salt okunur eşlemelere ayrıcalıksız işlemlerin yazma erişimi elde etmesine izin veren, yazma sırasında kopyalamada bir yarış koşuluBir konteynerin içinden, bağlamalar yoluyla açığa çıkarılmışsa ana bilgisayar dosyalarını değiştirmek için kötüye kullanılabilir.

• CVE‑2022‑0847 (Kirli Boru): kapsayıcılara salt okunur olarak bağlanmış olanlar da dahil olmak üzere dosyalara yetkisiz yazmalara olanak tanıyan başka bir çekirdek hatasıOtomatik olarak bir kaçış izni vermez ancak ayrıcalıklı bağlamalar veya çalışma zamanı yanlış yapılandırmalarıyla güzel bir şekilde zincirlenir.

• CVE‑2024‑21626 ve ilgili "Sızdıran Kaplar" sorunları: Görüntü derleme veya kapsayıcı başlatma sırasında ana bilgisayar kaynaklarını açığa çıkaran BuildKit ve runc'taki kusurlar, yapı hattının kendisinin saldırı yüzeyinin bir parçası olabileceğini kanıtlıyor.

Bu tür sorunların tamamına yönelik hafifletmeler, yama hijyeni ve mimari seçimler etrafında döner: Ana bilgisayar çekirdeklerini yamalı tutun, saldırı yüzeyini küçültmek için minimum veya dağıtımı olmayan temel imajlar kullanın, yüksek hassasiyetli iş yükleri için korumalı veya VM destekli çalışma zamanlarını tercih edin ve çekirdek istismar girişimlerine benzeyen şüpheli sistem çağrılarını ve dosya yazmalarını sürekli olarak izleyin.

Aşırı yetenekler ve ayrıcalıklı kapsayıcılar

Kökün gücünü azaltmak için yetenekler icat edildi, ancak pratikte "küçük parçalar" genellikle tekrar bir araya getiriliyor"Sadece çalışmasını sağla" baskısı altındaki geliştiriciler sıklıkla CAP_SYS_ADMIN veya konteynerleri basitçe şu şekilde çalıştırın: --privileged, kabın içindeki kök benzeri gücü etkili bir şekilde geri kazandırır.

CAP_SYS_ADMIN kötü şöhretli bir şekilde aşırı güçlüdür: dosya sistemlerinin bağlanmasına, ad alanlarının oluşturulmasına veya birleştirilmesine olanak tanır (unshare, setns), cgroup'ları ve daha fazlasını ayarlama. Doğru bağlama ve ad alanı kombinasyonuyla, bu yeteneğe sahip bir saldırgan, ana bilgisayarın ilk ad alanına yönelebilir ve küresel görünürlük elde edebilir.

CAP_NET_ADMIN ağ oluşturma perspektifinden de benzer şekilde geniştirArayüzleri yeniden yapılandırmak, iptables kurallarını değiştirmek ve karışık modu etkinleştirmek için kullanılabilir. Bir kaçış zincirinde, trafiği koklamak, ağ politikalarını atlatmak veya segmentasyonun etrafından dolaşmak için kötüye kullanılabilir.

Bir konteyneri tam ayrıcalıklı modda çalıştırmak temelde "bunu ana bilgisayarın bir parçası olarak ele al" demektirTüm yeteneklere sahip olur, ana bilgisayar cihazlarına erişebilir ve genellikle seccomp profillerini atlayabilir. Birçok saldırı zinciri için en zor adım, yanlış yapılandırılmış bir konteyner bulup onu bir fırlatma rampası olarak kullanmaktır.

Falco gibi modern araçlar, tespit için iş parçacığı düzeyinde yetenekleri ortaya çıkarmaya başladıArtık şu gibi alanları inceleyebilirsiniz: thread.cap_effective, thread.cap_permitted hem de thread.cap_inheritable çalışma zamanında ve riskli yeteneklere sahip bir işlem şüpheli eylemler gerçekleştirdiğinde uyarıları tetikler.

Yanlış yapılandırmalar: bağlar, soketler ve günlük hileleri

Konteyner kaçışlarının şaşırtıcı derecede büyük bir kısmı egzotik 0-günlere değil, düpedüz yanlış yapılandırmalara dayanıyorOperatörler hassas ana bilgisayar yollarını konteynerlere bağladığında veya dahili Unix soketlerini açığa çıkardığında, saldırganlar genellikle doğrudan bunların içinden geçebilirler.

Tehlikeli hostPath veya birim bağlamaları klasik bir örnektirBir konteyner, aşağıdaki gibi dizinlere okuma-yazma erişimi alırsa /etc, /proc, /sys or /var/run Ev sahibinden, izolasyon modeli büyük ölçüde çöker. /proc/sys veya sysfs çekirdek parametrelerini değiştirebilir; ana bilgisayar yapılandırma dosyalarına erişim gibi /etc/shadow kimlik bilgilerini sızdırabilir.

Docker soketi (/var/run/docker.sock) ve diğer çalışma zamanı soketleri başka bir acı verici yanlış yapılandırmadırBunu bir konteynerin içine monte etmek, konteyneri kontrol eden kişiye Docker daemon'unun neredeyse tam kontrolünü verir. Basit bir şekilde curl --unix-socket Çağrılar sırasında saldırgan kapsayıcıları listeleyebilir, ana bilgisayar kökünü bağlayan yeni bir ayrıcalıklı kapsayıcı oluşturabilir ve bu yardımcı kapsayıcıdan kaçabilir.

Kubernetes'te, Kubelet'in günlük işleme ve ana bilgisayar günlük bağlama işlemleri de kötüye kullanıldıEğer bir bakla, konakçının /var/log bind-mounted ve bir saldırgan günlük sembolik bağlantılarını değiştirebilir ve API aracılığıyla günlükleri okuyabilir, bir günlük sembolik bağlantısını keyfi ana bilgisayar dosyalarına yönlendirebilir ve kubelet'i örneğin şunu döndürmesi için kandırabilir: /etc/shadow içeriği.

Görünüşte basit olan SUID davranışı bile bir rol oynayabilirKonteynerin kullanıcı ad alanını ana bilgisayarla paylaştığı ortamlarda, konteynerin içinden paylaşılan bir dizindeki ikili dosyada SUID bitini ayarlamak, daha sonra düşük ayrıcalıklı bir ana bilgisayar kullanıcısı tarafından ana bilgisayarda kök ayrıcalıklarıyla o programı çalıştırmak için kullanılabilir.

Doğada görülen beton konteyner kaçış teknikleri

Kategorilerden belirli tekniklere yakınlaştırma yapmak, telemetri ve tehdit raporlarındaki kalıpları tanımanıza yardımcı olurBirçok yöntem ailesi araştırmacılar tarafından defalarca gösterilmiş ve penetrasyon testlerinde veya gerçek saldırılarda kullanılmıştır.

Kullanıcı modu yardımcıları ve release_agent hile

Linux çekirdeği bir işlevi açığa çıkarır, call_usermodehelperçekirdek alanı olaylarına yanıt olarak yükseltilmiş ayrıcalıklara sahip kullanıcı alanı programlarını başlatmak içinDoğru koşullar altında, kullanıcı tarafından kontrol edilen dosyalar hangi programın yürütüleceğini etkileyebilir ve meşru bir mekanizmayı bir kaçış vektörüne dönüştürebilir.

Cgroups v1'ler release_agent bu modelin en bilinen örneğidirBir cgroup boşaldığında ve notify_on_release etkinleştirildiğinde, çekirdek, tarafından işaret edilen ikili dosyayı çalıştırır release_agent Dosya. Bir kapsayıcının içindeki bir saldırgan, yeterli ayrıcalıkla cgroup dosya sistemini bağlayıp değiştirebilirse, release_agent ana bilgisayardaki keyfi bir yürütülebilir dosyada.

Tipik bir istismar dizisi aşağı yukarı şöyledir:: bir cgroup dizini oluştur ve bağla, etkinleştir notify_on_release, ayarla release_agent Ana bilgisayar ad alanındaki kötü amaçlı bir betiğin yoluna gidin ve ardından cgroup'un işlem listesini boşaltın. Çekirdek, saldırganın betiğini ana bilgisayarda kök benzeri ayrıcalıklarla çalıştırır.

Algılama, hem kullanıcı modu yardımcı yollarının anlamsal olarak anlaşılmasını hem de değişikliklerin nereden kaynaklandığına dair bağlamı gerektirirSağlam bir yaklaşım her şeyi haritalandırır call_usermodehelper Siteleri çağırır, kullanıcı modu dosyalarından etkilenebilecekleri belirler ve ardından bu dosyalara konteynerlerden kaynaklandığında yapılan yazmaları izleyerek şüpheli değişiklikleri işaretler.

SUID bitleri aracılığıyla ana bilgisayara ayrıcalık yükseltme

SUID tekniği, saldırganın zaten bir miktar ana bilgisayara erişimi olduğunu varsaydığı için "saf" bir kapsayıcı kaçışı değildir, ancak kısıtlı ana bilgisayar kullanıcılarından köke atlamak için sıklıkla konteyner erişimiyle zincirlenir.

İşin püf noktası, ana bilgisayar ile kapsayıcı arasında paylaşılan dizinlere ve paylaşılan bir kullanıcı ad alanına dayanıyor. Bir saldırgan, kök olarak çalışan bir konteynerin içinden, her iki tarafta da görülebilen bir dizine (örneğin, paylaşılan bir birim) bir yürütülebilir dosya bırakır ve SUID bitini ayarlar chmod u+s.

Daha sonra, ana bilgisayardaki kök olmayan bir kullanıcı bu ikili dosyayı yürütür ve ana bilgisayarda kök ayrıcalıklarına sahip olurÇünkü SUID biti ana bilgisayar bağlamında yorumlanır. Kapsayıcı, söz konusu ana bilgisayar kullanıcısı için mevcut olabilecek kısıtlamalar olmadan SUID yükünü hazırlamak için kullanışlı bir yer olarak kullanılır.

SUID istismarına ilişkin görünürlük üç ana odaklanıyor: Paylaşılan bir yolda yürütülebilir bir dosyanın oluşturulması, bir kapsayıcıdan SUID/SGID bitlerinin ayarlanması ve bu dosyanın ana bilgisayarda kök olmayan bir hesap tarafından yürütülmesi. EDR ve çalışma zamanı güvenlik araçları, yüksek doğrulukta uyarılar oluşturmak için bu adımları ilişkilendirebilir.

Çalışma zamanı soketi kötüye kullanımı: Docker ve containerd

Konteyner ortamları genellikle CLI araçlarının veya düzenleyicilerinin Unix soketleri aracılığıyla daemon'larla iletişim kurduğu bir istemci/sunucu mimarisine dayanır. Örnekler: /var/run/docker.sock Docker veya /run/containerd/containerd.sock konteyner için.

Bu soket dosyaları bir kapsayıcının içine monte edilirse, bu kapsayıcı etkili bir şekilde bir yönetici istemcisi olarak işlev görebilirKonteyneri tehlikeye atan bir saldırgan, API isteklerini doğrudan çalışma zamanına gönderebilir, konteynerleri listeleyebilir, iş yüklerini başlatabilir ve durdurabilir veya ana bilgisayar bağlantılarıyla yepyeni, ayrıcalıklı bir konteyner oluşturabilir.

Gibi genel bir araç kullanarak curl, Unix soketi üzerinden Docker uzak API'sine erişmek çok kolaydır: sorgu /containers/json konteynerleri numaralandırmak, göndermek /containers/create ayrıcalıklı bir yardımcı oluşturmak için bir JSON tanımıyla, ardından çağırın /containers/{id}/start başlatmak için. Bu yardımcı kapsayıcı, ana bilgisayar kök dosya sistemini bağlayabilir ve saldırgana etkileşimli erişim sağlayabilir.

Savunmacılar bunu çeşitli yollarla avlayabilirler: Konteynerleştirilmiş süreçlerden çalışma zamanı Unix soketlerine erişimi izleme, şüpheli erişimleri tespit etme curl --unix-socket veya bu soketleri hedefleyen ve alışılmadık kapsayıcı oluşturma kalıpları hakkında uyarı veren çalışma zamanı CLI çağrıları (örneğin, hostPath'e bağlanır) /, --privileged (Kubernetes özelliklerinde).

Kubernetes'e özgü püf noktaları: günlük bağlamaları ve pod kaçışları

Kubernetes'te bazı saldırılar, ham Docker kavramları yerine Kubelet davranışlarını ve Kubernetes soyutlamalarını hedef alıyor. Ana bilgisayar dizinlerini şu şekilde bağlayan podlar: /var/log or /var/lib/docker özellikle rakipler için ilgi çekicidir.

Kubelet'in günlükleri döndürürken sembolik bağlantıları nasıl çözdüğünü gösteren bir yöntem kötüye kullanılıyorHer pod'un altında bir günlük dosyası bulunur /var/log konteynerin dizinine sembolik bağlantı veren /var/lib/docker/containersBir saldırgan sembolik bağlantıları oluşturabilir veya değiştirebilirse /var/log hostPath bağlantısı aracılığıyla, bir "günlüğü" keyfi bir dosyayı işaret edecek şekilde yeniden yönlendirebilirler (örneğin, /etc/shadow).

Günlük okuma izinlerine sahip bir kullanıcı veya hizmet hesabı aradığında kubectl logs veya karşılık gelen API, kubelet sembolik bağlantıyı takip eder ve o hedefin içeriğini döndürürBiraz yaratıcılıkla, saldırgan, bir dizi sembolik bağlantılı "günlük" aracılığıyla ana bilgisayar dosya sisteminin büyük bölümlerini açığa çıkarabilir.

Buradaki tespitler ağ ve dosya sistemi merceklerini birleştiriyor: Kubernetes günlük okuma HTTP isteklerini anormal yol kalıpları açısından izleyin ve aynı anda ana bilgisayarda sembolik bağlantı oluşturulmasını veya değiştirilmesini izleyin /var/log konteynerleştirilmiş süreçlerden kaynaklananlar.

Hassas ana bilgisayar bağlantıları ve doğrudan veri hırsızlığı

Bazen bir kaçış, ana bilgisayar düzeyinde kod çalıştırmadan yalnızca bir konteynerin içinden ana bilgisayar verilerini okumak veya değiştirmekten oluşurHassas dizinleri açığa çıkaran yanlış yapılandırılmış bağlamalar ciddi etki yaratmaya yeter.

Örneğin, bir konteyner aşağıdaki gibi bir bağlama sahip olabilir: /host_etc ev sahibinin işaret ettiği /etc rehberBu yola tökezleyen bir saldırgan, basitçe açabilir /host_etc/passwd or /host_etc/shadow ve bunlar konteynerin içinden ana bilgisayar kimlik doğrulama dosyalarını etkili bir şekilde okuyorlar.

Bu tür bağlamaların kötüye kullanımının tespiti zordur çünkü birçok erişim modeli normal dosya işlemlerine benzer görünürSadece izleyemezsin /etc/shadow Konteynerlerin içinde, çünkü bu genellikle ana bilgisayarın değil, konteynerin kendi dosyasını ifade eder. Her bir bağlantı için "konteyner yolunu" "temel ana bilgisayar yoluna" dönüştüren bir eşleme katmanına ihtiyacınız var.

Gelişmiş EDR ve CNAPP araçları, ana bilgisayar tarafındaki yola dayalı olarak bağlantı noktalarını çözerek ve erişimleri izleyerek bu sorunu çözerBu şekilde, konteynerin içindeki zararsız görünen bir yol üzerinden bile olsa, nihayetinde ana bilgisayara duyarlı bir dosyaya dokunan herhangi bir okuma veya yazma gerçek zamanlı olarak işaretlenebilir.

Çalışma zamanında konteyner kaçış girişimlerini algılama

Önleyici sertleştirme esastır, ancak konteynerler çalışırken neler olduğunu iyi görebilmeniz de gerekirModern saldırılar genellikle birden fazla adımı zincirler ve güçlü çalışma zamanı izleme, saldırının ana bilgisayara ulaşmadan önce yakalanmasına olanak tanır.

Son teknoloji algılama, genellikle düşük seviyeli telemetriyi (örneğin, eBPF tabanlı sistem çağrısı izleri) davranışsal analiz ve bulut bağlamıyla birleştirirHam sinyaller sistem çağrılarından, dosya işlemlerinden, işlem ağaçlarından ve soket etkinliğinden gelir; analitik katmanı bunları kimlikler, ağ görünürlüğü ve bulut varlıklarıyla ilişkilendirerek iyi niyetli yönetici eylemlerini gerçek kaçış girişimlerinden ayırır.

Temel sistem çağrısı düzeyindeki göstergeler

Bazı sistem çağrıları, sınırları aşan faaliyetlerle güçlü bir şekilde ilişkilidir ve konteynerler tarafından çağrıldığında ekstra incelemeye tabi tutulmalıdır:

• mount, umount, pivot_root – dosya sistemi bağlantılarını değiştirmek veya kök dizinleri döndürmek, genellikle ana bilgisayar yollarını bir kapsayıcıya birleştirmek veya chroot'lardan kaçmak için kullanılır.

• setns, unshare – ana bilgisayarın ilk ad alanına atlayan tekniklerin temel bir adımı olan yeni ad alanlarına katılma veya yeni ad alanları oluşturma.

• ptrace – diğer süreçlere hata ayıklama veya enjekte etme; konteyner sınırlarını aştığında veya sistem daemon'larını hedef aldığında şüpheli.

• capset – yeteneklerin çalışma zamanında değiştirilmesi, potansiyel olarak yürütme sırasında yeni güçlü bayraklar kazanmak için kullanılır.

• init_module, finit_module – Çekirdek modüllerini bir konteynerden yüklemek, meşru iş yüklerinde nadiren ihtiyaç duyulan yüksek riskli bir davranıştır.

Falco gibi kural motorları, algılama mantığını bu sistem çağrıları üzerinden kapsayıcıya duyarlı bir şekilde ifade etmenize olanak tanırÖrneğin, konteynerleştirilmiş bir işlem olduğunda uyarı verebilirsiniz CAP_SYS_ADMIN adlı bir dosya açar release_agent Yazma için, kullanıcı modu yardımcı tabanlı kaçış girişiminin son derece güçlü bir göstergesidir.

Şüpheli dosya erişim kalıpları

Dosya bütünlüğü ve erişim izleme, bir saldırganın tam olarak hangi yollara dokunduğunu göstererek sistem çağrılarını tamamlarKonteyner/ana bilgisayar eşlemesi merceğinden bakıldığında, bu güçlü bir kaçış dedektörü haline gelir.

• Şuraya yazıyor: /proc/sys or /sys Bir konteyner sinyalinden çekirdek parametrelerini veya aygıt ayarlarını değiştirmeye çalışır.

• Aşağıdaki gibi konteyner çalışma zamanı soketlerine erişim: /var/run/docker.sock or /run/containerd/containerd.sock Genel uygulama kapsayıcılarından geldiğinde kırmızı bayraktır.

• Değişiklikler /etc/passwd, /etc/shadow or /etc/sudoers ana bilgisayarda kapsayıcı tarafından görülebilen yollar aracılığıyla ayrıcalık yükseltme ve kalıcılık adımlarına benziyor.

• Şuradan okur: /proc/*/environ or /proc/*/cmdline ad alanları arasında Konteynerin kendi işlem ağacının ötesinde işlem numaralandırmasını ve kimlik bilgisi toplamasını gösterebilir.

En güvenilir uyarılar birden fazla faktörü birleştirir: yol, sistem çağrısı, yetenekler ve kapsayıcı meta verileri. Örneğin, bir mount yönetici olmayan, internete açık bir uygulama konteynerinden kaynaklanan sistem çağrısı CAP_SYS_ADMIN ve hedefleme /proc/sys bilinen ayrıcalıklı bir bakım işinden aynı işlemin yapılmasından çok daha endişe vericidir.

Süreç düzeyinde ve davranışsal sinyaller

Ham sistem çağrıları ve dosya olaylarının ötesinde, daha üst düzey işlem davranışı, neler olup bittiğine dair bir hikaye çizerBazı aktiviteler normal mikroservislerde son derece nadir görülürken, istismar sonrası aşamalarda yaygındır.

• Etkileşimli olmayan kapsayıcılardan oluşturulan etkileşimli kabuklar (Örneğin, /bin/bash (bir web sunucusu işlemi altında görünen) uygulamalı klavye aktivitesini önerir.

• Ayrıcalık yükseltme araçlarının kullanımı gibi sudo, su or newgrp konteynerlerin içindeÖzellikle etkileşimli kullanıma yönelik olmayanlar oldukça şüphelidir.

• Ağ taraması, yanal hareket araçları ve alışılmadık giden bağlantılar Sadece küçük bir servis kümesiyle konuşması gereken konteynerlerden keşif veya yayılma girişimleri gösterilir.

• Kripto madenci imzaları, beklenmedik şekilde uzun süre çalışan CPU'ya bağlı işlemler veya GPU kullanımındaki ani artışlar saldırganın, kaynakları paraya çevirmek için ana bilgisayar düzeyindeki erişimini zaten kullandığını ortaya çıkarabilir.

"Nedensellik zinciri" (soy ve çevre ile süreç ağacı) sürdüren EDR ve CNAPP platformları burada öne çıkıyorAnalistlerin şüpheli işlemleri kaynak konteyner görüntüsüne, Kubernetes iş yüküne, bulut hesabına veya CI/CD işlem hattına kadar izlemesine olanak tanır, böylece kök neden analizi ve uzun vadeli düzeltmeler daha etkili hale gelir.

Konteyner kaçışlarını önleme: derinlemesine savunma

Hiçbir tek kontrol, konteyner kaçış girişimiyle asla karşılaşmayacağınızı garanti edemez, bu nedenle koddan buluta kadar katmanlı savunmalara ihtiyacınız vardırBunlara görüntü hijyeni, en az ayrıcalık, güçlendirilmiş yapılandırmalar, ağ kontrolleri ve güçlü çalışma zamanı koruması dahildir.

En az ayrıcalıkla konteynerleri çalıştırın

Gereksiz ayrıcalıkları konteynerlerden acımasızca kaldırarak başlayınÇok nadir ve sıkı bir şekilde kontrol edilen durumlar haricinde ayrıcalıklı moddan kaçının ve "root inside" ifadesinin ana bilgisayardaki ayrıcalıksız bir kullanıcıya eşlenmesi için köksüz kapsayıcıları veya kullanıcı ad alanlarını tercih edin.

Kubernetes'te securityContext ayarlarını akıllıca kullanın sevmek runAsNonRoot, runAsUser, allowPrivilegeEscalation: false hem de readOnlyRootFilesystem: trueBu kısıtlamalar, bir saldırganın uygulama çalışma zamanını tamamen tehlikeye atsa bile yapabileceklerini sınırlar.

Yetenekler sıkı bir şekilde kapsamlandırılmalıdır: Varsayılan olarak her şeyi bırakın ve yalnızca iş yükü için gereken minimum kümeyi ekleyin. Bir konteynerin gerçekten ihtiyacı varsa CAP_SYS_ADMIN or CAP_NET_ADMIN, bunu yüksek riskli bir varlık olarak ele alın ve ekstra izleme ve ağ izolasyonuyla çevreleyin.

Falco'nun yetenek alanlarından yararlanan tespit kuralları, gözden kaçan yanlış yapılandırmalar için bir güvenlik ağı görevi görebilirÖrneğin, bir kural, kapsayıcı bir iş parçacığının her çalıştırıldığında tetiklenebilir. CAP_SYS_ADMIN hem de CAP_DAC_OVERRIDE adlı bir dosyaya yazar release_agent, çok düşük gürültüyle çok sayıda kaçış girişimini yakalıyor.

Konteyner tedarik zincirini güvence altına alın

Çoğu ihlal, çalışma zamanından önce, savunmasız veya değiştirilmiş görüntüler biçiminde başlarGüçlü görüntü güvenliği, saldırganların ilk etapta güvenilir bir dayanak noktası elde etmesini zorlaştırır.

Güvenilir kayıt defterlerinden güçlendirilmiş, minimum temel görüntüleri kullanın ve bunları güncel tutunDaha az paket içeren daha küçük görüntüler, istismar edilebilir CVE'ler içerebilecek daha az kütüphane anlamına gelir ve Wiz veya dağıtım yöneticileri gibi satıcılar artık yalnızca kesinlikle gerekli olanlarla "dağıtımsız" tabanlar sağlar.

Güvenlik açığı taramasını ve Yazılım Malzeme Listelerini (SBOM'ler) CI/CD'ye entegre edinHer derleme, bir kayıt defterine gönderilmeden önce taranmalı ve maruz kalma durumları ve ayrıcalıklarıyla ilgili yamalanmamış yüksek veya kritik öneme sahip hatalar içeren görüntülerin dağıtımı engellenmelidir.

Görüntü güven politikaları döngüyü kapatırGörüntüleri kriptografik olarak imzalayın, imzalanmamış veya güvenilmeyen görüntüleri reddedecek şekilde kabul denetleyicilerini yapılandırın ve zaman içinde kümeler halinde hangi görüntülerin gerçekten çalıştığını görünür kılın, böylece riskli eserleri hemen emekliye ayırabilirsiniz.

Son olarak, iyileştirmeyi ham CVE sayılarına göre değil, gerçek riske göre önceliklendirinEk yetenekler olmadan çalışan, hareketsiz, ağa bağlı olmayan bir toplu işteki kritik bir güvenlik açığı, hassas verileri işleyen, internete bakan, ayrıcalıklı bir bölmedeki "orta" bir hatadan daha az acildir.

Ağ segmentasyonu ve çalışma zamanı koruması

Bir saldırgan tek bir konteynere ulaşsa bile, akıllı ağ tasarımı bunu tam bir küme ihlaline dönüştürmesini engelleyebilirAyrıntılı ağ politikaları, güvenlik duvarları ve hizmet ağları, yanal hareketi sınırlamaya yardımcı olur.

İzin listesi tarzı ağ politikalarını uygulayın Kubernetes'te, pod'ların yalnızca gerçekten ihtiyaç duydukları hizmetlerle iletişim kurabilmesini sağlar. Bu, bir saldırganın kümeyi taramasını veya Docker soketi ya da Kubernetes API sunucusu gibi dahili yönetim API'lerini çağırmasını sınırlar.

Çalışma zamanı koruma sistemleri gerçek zamanlı frenleri eklerBir konteyner kaçışıyla tutarlı bir davranış tespit ettiklerinde (örneğin, şüpheli nsenter kullanım, hostPath'e bağlanır / (veya konteyner soketi kurcalama) işlemleri engelleyebilir veya sonlandırabilir, konteynerleri izole edebilir veya tam bir adli iz ile olayları otomatik olarak açabilirler.

Wiz CNAPP gibi platformlar, bu çalışma zamanı tespitlerini bulut bağlamı ve bir güvenlik grafiğiyle birleştirirKonteynerler, ana bilgisayarlar, kimlikler ve veri depoları arasındaki ilişkileri haritalayarak, yalnızca bir kaçışın gerçekleştiğini değil, aynı zamanda patlama yarıçapında hangi hassas varlıkların bulunduğunu da göstererek ekiplerin müdahaleye öncelik vermesini sağlarlar.

Sürekli izleme ve olay hazırlığı

Konteynerler kısa ömürlüdür, bu da klasik adli tıp ve günlük analizini daha zor hale getirirEğer bunu önceden planlamazsanız, kaçışı anlamak için ihtiyaç duyduğunuz kanıtlar, kapsül yeniden planlandığında ortadan kaybolabilir.

Konteyner çalışma zamanları, düzenleyiciler ve ana bilgisayarlar için merkezi günlük kaydı ve ölçüm toplama oluşturunELK, Prometheus ve bulut tabanlı günlük hizmetleri gibi araçlar, işlem etkinliğinin, güvenlik olaylarının ve yapılandırma değişikliklerinin kısa süreli iş yükleri için bile yakalanmasını sağlar.

Konteyner kaçış senaryolarına özel oyun kitapları oluşturunBunlar, bir kaçış veya ana bilgisayar düzeyinde bir tehlikeden şüphelendiğinizde düğümleri nasıl hızlı bir şekilde kordon altına alacağınızı, disklerin anlık görüntüsünü nasıl alacağınızı, kapsayıcı meta verilerini nasıl toplayacağınızı ve bulut sağlayıcıları veya olay müdahale ekipleriyle nasıl koordine olacağınızı tanımlamalıdır.

Palo Alto Networks (Cortex XDR, Prisma Cloud) ve diğerleri gibi satıcılar, burada açıklanan teknikler etrafında kapsamlı tespit içeriği oluşturdularKullanıcı modu yardımcısının kötüye kullanımından çalışma zamanı soket istismarına ve hassas bağlama erişimine kadar, savunuculara genel "şüpheli etkinlik" gürültüsü yerine eyleme geçirilebilir, yüksek bağlamlı uyarılar sağlar.

Tüm bu parçaları bir araya getirmek – sağlam Linux izolasyon temelleri, sıkı ayrıcalıklar, güçlendirilmiş görüntüler, ağ kontrolleri ve derin çalışma zamanı görünürlüğü – konteyner kaçışını varoluşsal bir tehditten, ekibinizin erken tespit edebileceği, etkili bir şekilde kontrol altına alabileceği ve zamanla bulut tabanlı güvenlik duruşunuzu daha da güçlendirmek için ders çıkarabileceği yönetilebilir bir riske dönüştürür.