Video summary
Bu video sunumunda Red Hat Advanced Cluster Security (ACS) platformunun, çalışan bir konteyner içinde şüpheli faaliyetleri gerçek zamanlı olarak nasıl tespit ettiğini ve durdurduğunu gösteren bir demo anlatılmaktadır. Senaryoda, Q2O uygulamasına sahip test bir küme ortamı hazırlanmış ve burada hem uygulama pod'ları hem de veritabanı pod'u izlenmektedir. Sunucu sahibi, saldırganın bir konteynera shell erişimi kazandığını varsayarak bu saldırının nasıl algılanacağını simüle etmeye başlar; saldırgan ilk olarak kimlik doğrulama ve işletim sistemi gibi bilgileri toplayan bir keşif aşamasına girer. ACS ise, katmanlı sıfır güven (zero trust) geçerli desenleri ile varsayılan olarak etkinleştirilmiş özel güvenlik politikaları sayesinde konteyner içindeki her bir süreci sürekli izleyerek bu tür tehditlere karşı hazırdır.
Saldırı simülasyonu sırasında saldırganın şüpheli komutlar, örneğin ağ tarama araçları çalıştırması gibi faaliyetler gerçekleştirmesi durumunda ACS sisteminin anında tepki vermesi gösterilmektedir. Saldırgan bir konteyner içinde zararlı işlem başlattığında, sistem bu durumu varsayılan güvenlik politikalarıyla eşleştirir ve bağlantıyı keserek ilgili pod'u otomatik olarak öldürür. Bu süreç tamamen otomatiktir ve insan müdahalesi gerektirmemektedir; saldırının tespiti ile birlikte saldırganın erişimi anında sona erdirilirken, ACS bu olayı ihlal kayıtları bölümünde detaylı bir şekilde kaydeder. Kaydedilen veriler arasında çalıştırılan ikili dosya adı (binary), kullanılan argümanlar, konteyner kimliği ve saldırının gerçekleştiği tam zaman gibi forensik analiz için gerekli tüm kanıtlar yer alır.
Saldırı durdurulduktan sonra Kubernetes altyapısının kendini nasıl toparladığı da izlenmektedir; Q2O uygulaması bir deployment olarak çalıştığı için, saldırganın erişimi kesildiği anda otomatik olarak temiz ve yeni bir pod başlatılarak hizmet tekrar sağlanır. Bu mekanizma sayesinde uygulama kullanıcı taleplerini almaya devam ederken saldırı araçları silinmiş olur ve güvenlik ekibi ACS üzerindeki tam denetim izi aracılığıyla olaya dair tüm bilgileri elde etmiş bulunur. Sonuç olarak, ağ politikaları ile sınırları daraltmak, ACS'nin saldırganlığı tespit edip durdurması ve Kubernetes'in otomatik iyileşme yeteneği bir araya gelerek çok katmanlı bir savunma derinliği oluşturur; bu yaklaşım özellikle yeni açıkların yamalarından daha hızlı ortaya çıktığı modern dünyada güvenlik için kritik öneme sahiptir.
Read the full video transcript
Hi.
In this demo, I will show how Red Hat
Advanced Cluster Security detects and
stops suspicious activity inside a
running container in a real time.
On the screen,
you see a test cluster with Q to do
application.
Here's our application pods
and
Q to do database pod.
On the right, I will monitor
running pods in the Q to do namespace.
Now, imagine
an attacker gains shell access to one of
your pods.
This could happen through vulnerability,
a compromised CI pipeline, or even
stolen credentials.
I will connect to the Q to do container.
Okay, done.
Now, the attacker starts with
reconnaissance.
Who am I?
What operating system is this?
Are there any interesting environmental
variables or service accounts tokens?
They are building a picture of what they
can do, what they can exploit.
Like this.
Okay.
What is the operating system?
Enterprise Linux Red Hat 10.
Maybe secret service accounts.
Yep.
ACS is watching every process that
executes inside the container.
Here's our
ACS security custom policy enabled by
default in a layered zero trust
validated pattern.
There we go.
Here we are
having our policy management view
with four [snorts] custom policies and
two related to the runtime monitoring
prevent
runtime privilege escalation and stop
suspicious
um activities.
Let's for example take a look
on this one.
We're having here our policy criteria.
What binaries execution are monitoring?
What
other
binary
are also monitored?
Container escapes indicators.
And
our cute to do application in the scope
of this
policy.
So,
let's get back to our test cluster.
Now,
in the container that I'm
testing right now,
I will run
suspicious command.
Let's imagine that right now attacker
runs on suspicious command inside this
container. Like for example, network
scanning tools.
This crosses the line from recognized to
active attack.
Uh for this demo purpose, I will just
trigger a help
page for the pass w command. It's
enough.
Let's see
what happens now.
Monitor the right side of the screen.
And there is it.
The connection dropped. ACS detected the
suspicious process.
Match it against the runtime policy and
killed the pod.
The entire response was automatic. No
human interventions needed at all.
Let's get back to ACS and see how it's
recorded.
If you go to violations,
let's wait when the screen is
refreshed.
There we go.
We have our event.
Binary executed.
What was the container ID?
What was the argument used?
When exactly that happened?
Last time.
This is the
time when I first time executed this
demo test.
So,
here
we have full evidence.
These violations shows everything
that we need for full forensic context
for incident response.
If we get back to our
cluster,
what was already visible
immediately after I triggered the
suspicious command.
Because the Kube to do
runs as a deployment, Kubernetes
automatically start a new clean pod.
The application is already serving
requests again.
The attacker session is gone.
Their tools are gone, and the security
team has a complete audit trail right
now available in ACS.
This is what continuous monitoring
looks like in the zero trust
architecture.
Network policies contain the blast
radius.
ACS detects and stops the attack.
Kubernetes
recovers automatically.
Together, they give you a defense in
depth.
Because in our
world where new vulnerabilities appears
faster than patches,
we need multiple layer of protections.
Thank you for watching.