Linux Process Hiyerarşisi ve Kaynak Yönetimi

Mahmut ATSIZ · @MAHMUT-ATSIZ

Melisa Kumral · @melisakumral

Bir terminal açıp ps aux yazdığınızda karşınıza dökülen o yüzlerce satır; kimi root’un başlattığı bir servis, kimi sizin tarayıcınız, kimi de gizemli bir kernel iş parçacığıdır. Ancak Linux’un altında dönen bu kalabalığı sadece 'listelemek' yetmez; asıl mesele bu süreçlerin dizginlerini elimizde tutabilmektir.

Bu yazıda, süreçlerin RAM ve PID hiyerarşisindeki temel taşlarından yola çıkarak; HTTP/2 Rapid Reset gibi modern siber saldırıların sistemimizi nasıl bir 'süreç krizine' sürükleyebileceğini ve bu kaosu cgroups gibi modern kaynak yönetimi araçlarıyla nasıl dizginleyebileceğimizi, canlı bir senaryo üzerinden inceleyeceğiz.

Process Nedir?

Sistemimizdeki programlar çalışma sürecine girdiklerinde artık bir process olur.

Burada önemli bir ayrım var: program diskteki dosyadır, process ise o programın çalışan bir örneğidir. Bir programın çalışabilmesi için bir kısmının ya da tamamının RAM’e gelmesi gerekmektedir. RAM’de tutulan process verileri dört ana bölüme ayrılır:

• Text Segment
• Data Segment
• Stack
• Heap

Text Segment

Programın çalıştırılabilir kodunu tutar. Yazdığınız kaynak kodu derleyiciden geçtiğinde bir “program” oluşur. Program çalıştırıldığında bu derlenmiş kod RAM’e yüklenir ve text segmenti meydana getirir.

Kısacası: text segment, “CPU’nun okuyup yürüteceği komutların bulunduğu raf”tır.

Data Segment

Herhangi bir fonksiyon içerisinde tanımlanmamış, global olarak her yerden erişilebilen değişkenler burada yer alır. Programın ömrü boyunca yaşayan veriler buraya konuşlanır.

Stack

Fonksiyonlar içerisinde oluşturulan, belirli bir kapsam (scope) içinde kalan, fonksiyon bittiğinde silinen değişkenler stack’te tutulur. Stack LIFO (Last In, First Out) mantığıyla çalışır — en son giren ilk çıkar.

Heap

Process’in çalışırken ihtiyaç duyduğu dinamik bellek alanları heap üzerinde tutulur. Boyutu önceden bilinmeyen, uzun ömürlü olması gereken veriler heap’e gider. C’deki malloc, C++'taki new gibi çağrılarla heap büyür.

Stack ve Heap Arasındaki Boşluk

Stack ve heap birbirine doğru büyür. Stack yukarıdan aşağıya, heap aşağıdan yukarıya… Eğer çarpışırlarsa karşımıza çıkan iki klasik hatayı tahmin edebilirsiniz: stack overflow veya out of memory.

Process ID (PID): Her Process’in Kimlik Numarası

Process’ler oluşturulduklarında her birine sistem tarafından bir kimlik numarası atanır. Bu numaraya Process ID (PID) denir.

Linux’ta PID 1 özel bir PID’dir. Sistem açılırken başlatılan ilk process olan systemd bu numarayı taşır. Tüm diğer process’lerin kökü, doğrudan ya da dolaylı olarak PID 1'e bağlanır.

# Sistemdeki tüm process’leri listele
ps aux
# Belirli bir PID’ye sahip process’i göster
ps -p <PID>

Görüldüğü gibi PID 1 systemd’ye ait — olarak tüm sürecin atası.

Process Yaşam Döngüsü

Bir process doğduğu andan öldüğü ana kadar farklı durumlardan geçer. Bu durumların her birine process state denir. Beş ana state vardır:

1. New (Created): Process’in ilk oluşturulma anıdır. Verilerin diskten okunması, RAM’e yazılması ve PID atanması gibi adımları kapsar.
2. Ready: Process oluşturulma sürecini tamamlamış, çalışmaya hazır şekilde sırasını bekliyor. CPU müsait olduğunda devreye girecek.
3. Running: İşletim sistemi tarafından CPU çekirdeğine getirilmiş ve aktif olarak çalışıyor.
4. Waiting: Klavye girişi, ağ yanıtı gibi bir olayı bekliyor. Beklerken CPU’da yer kaplamaz; sıra ona gelene kadar başka process’ler çalışır. Beklenen olay geldiğinde tekrar Ready state’ine döner.
5. Terminated: Süreç tamamlandı veya bir hata nedeniyle durduruldu. İşletim sistemi bu aşamada belleği ve diğer kaynakları geri alır.

Bu state geçişleri her saniye binlerce kez yaşanır — siz bu yazıyı okurken bile.

Thread Nedir?

Thread’ler, process’lerin içindeki alt iş parçacıkları olarak düşünülebilir. Bir process’in birim zamanda birden fazla görevi eş zamanlı yürütebilmesini sağlayan yapıdır.

Uygulamalar single-threaded veya multi-threaded olabilir. Aradaki fark somut bir örnekle çok daha net görünür:

• Diyelim ki 4 çekirdekli bir CPU’nuz var ve elinizde 4 birimlik bir iş.
• Single-threaded bir uygulama bu işi bitirmek için 4 tur atmak zorundadır, çünkü birim zamanda yalnızca bir çekirdek kullanabilir.
• Multi-threaded bir uygulama ise bu 4 birimlik işi 4 çekirdeğe paralel olarak dağıtır ve tek turda bitirir.

Yani thread’ler, bir process’in çok çekirdekli donanımı verimli kullanabilmesinin yoludur.

Process Tree

Linux’ta process’ler bir ağaç yapısında düzenlenir. Her process’in (PID 1 hariç) bir ebeveyni vardır.

Parent Process

Bir veya daha fazla alt süreç üreten process’e parent process denir. Bir process başka bir process’i başlattığında, başlatana parent, başlayana child denir. Parent ve child farklı PID’lere sahiptir ve eş zamanlı olarak çalışırlar.

Child Process

• Child process’ler kendilerine ait bellek ve kaynaklara sahiptir; parent’tan bağımsız çalışabilirler.
• Child process’ler yeni child process’ler üretebilir — ağaç yapısı böyle oluşur.
• Mevcut çalışma dizini ve ortam değişkenleri child’a parent’tan miras kalır.
• Pipe, socket, signal gibi inter-process communication (IPC) mekanizmalarıyla parent ve diğer child’larla iletişim kurabilirler.

Orphan (Yetim) Process

Bir child çalışırken, onu oluşturan parent beklenmedik bir sebeple sonlanırsa ortaya yetim bir süreç çıkar. Süreç hâlâ çalışıyordur ama parent’ı yoktur.

İşletim sistemi bu süreci sahipsiz bırakmaz; init veya systemd yetim süreci evlat edinir (adopt). Bu sayede ağaç yapısı kopuk kalmaz.

Zombie Process

Zombi süreç, çalışmayı bitirmiş ama parent’ı tarafından henüz “teslim alınmamış” bir süreçtir. Yani ölüdür ama kayıt defterinden silinmemiştir.

Zombiler bellek tüketmez fakat PID slotlarını işgal eder. Çok fazla zombi birikirse sistem yeni process üretemez hale gelir, PID slotları dolar.

# Hiyerarsik yapıyı agaç seklinde gösterir
pstree
# Detaylı liste: kullanıcı, CPU, RAM kullanım verileri ile birlikte
ps aux --forest
# Belirli bir PID için tam bilgi sağlar
ps -fp <PID>

Görselde örnek bir process tree görülmektedir. Burada systemd’nin tüm sistemin atası konumunda olduğu net şekilde görülmektedir.

Temel Sinyaller

Sistem sinyalleri, işletim sisteminin süreçleri yönetmek için kullandığı asenkron bildirim kodlarıdır. Yani süreçle iletişim kurmanın standartlaşmış bir dilidir.

Günlük hayatta en çok karşılaşacağınız sinyaller:

• SIGHUP (Sinyal 1) — Yeniden Yükleme: Kapanan bir terminalin altındaki süreçleri sonlandırmak veya arka plan servislerinin ayarlarını sıfırlamadan yeniden yüklemesi için kullanılır. Konfigürasyon değişikliklerini servisi durdurmadan uygulamak isteyenlerin dostudur.
• SIGINT (Sinyal 2) — Kesme: Klavyeden Ctrl+C ile gönderilir. “Bu süreci hemen durdur” demenin standart yoludur.
• SIGTERM (Sinyal 15) — Standart Kapanma: kill <PID> komutunun varsayılan davranışıdır. Süreçten nazikçe kapanmasını ister: “İşini topla, dosyalarını kaydet, çık.” Süreç bu sinyali yakalayıp kendi kapanma rutinini çalıştırabilir. Tam da bu yüzden zararlı yazılımlar SIGTERM’i kolayca reddedebilir.
• SIGTSTP (Sinyal 20) — Standart Duraklatma: Terminalde Ctrl+Z ile çalışan süreci duraklatmak için gönderilir. Süreç ölmez, “donar” sonra bg veya fg ile devam ettirebilirsiniz.
• SIGKILL (Sinyal 9) — Kesin İnfaz:

kill -9 <PID>

SIGKILL diğerlerinden farklı bir kategoride. Çünkü:

• Sürece iletilmez. Doğrudan işletim sistemi çekirdeğine verilen mutlak bir emirdir.
• Kernel, ilgili sürecin işlemci ve bellek ile olan fiziksel bağını anında koparır.
• Sürecin bu emre itiraz etme, direnme veya veri kaydetme şansı teknik olarak sıfırdır.

Bu yüzden SIGKILL son çare olmalıdır. Sürecin açık dosyalara veri yazma, bağlantıları nazikçe kapatma fırsatı kalmaz; tutarsız durumlar oluşabilir. Ama takılı kalmış, SIGTERM’e cevap vermeyen bir süreçten kurtulmanın garantili yolu da budur.

Arka Plan İşleri: Terminali Esir Almadan İş Yapmak

Terminalde bir komut çalıştırdığınızda terminal “kilitlenir” — komut bitene kadar yeni komut giremezsiniz. Uzun süren işlemlerde bu rahatsız edici. Linux bu sorunu arka plan iş yönetimi ile çözer.

& ile Komutu Doğrudan Arka Planda Başlatmak

Komutun sonuna “&” koyarsanız, komut arka planda başlar ve terminal serbest kalır.

# nmap -T2 <orneksite.com> > tarama_sonucu.txt 2>&1 &
[1] 78278

Kod bloğundaki nmap taraması sonuna eklediğimiz & sayesinde arkaplanda çalışmaya başlayacaktır. Çıktısında da hangi PID ile arkaplanda devam ettiği yazmatadır. Bu sayede terminalde bu komut çalışırken başka komutları da çalıştırabiliriz.

"jobs" Mevcut İşleri Listelemek

Duraklatılmış işler, arka planda çalışan işler ve toplamda kaç iş olduğu burada listelenir.

jobs
[1]  + suspended  nmap -T2 <orneksite.com> > tarama_sonucu.txt 2>&1
[2]  - running    sleep 500

“bg” Duraklatılmış İşi Arka Planda Devam Ettirmek

Ctrl+Z ile bir komutu duraklattıysanız, bg ile arka planda çalışmaya devam ettirebilirsiniz.

#1 job id'yi göstermektedir. Başlatılmak istenen job id yazılarak komut kullanılabilir.
bg %1

“fg” Arka Plandaki İşi Ön Plana Çekmek

fg komutu arka planda çalışan bir işlemi ön plana çekerek görünür kılar. Terminal artık o işle meşgul olur.

Bu üçlü — &, bg, fg — terminalde verimli çalışmanın bel kemiğidir. Uzun bir tarama, bir derleme veya bir indirme işi başlattığınızda terminali esir etmek zorunda kalmazsınız.

KAYNAK YÖNETİMİ

Kontrolden Çıkan Süreçler ve Modern Çözümler

İşletim sistemleri, binlerce sürecin (process) uyum içinde çalıştığı karmaşık bir orkestra gibidir; ancak her enstrüman her zaman notaya uygun çalmaz. Kaynak yönetiminin zayıf olduğu bir sistemde; zararlı yazılımlar, protokol zafiyetlerini sömüren saldırılar veya basit bir kod hatasından kaynaklanan sonsuz döngüler, tüm sistemi saniyeler içinde bir “darboğaza” (bottleneck) sürükleyebilir.

İşletim sisteminin derinliklerine indiğimizde bu kontrolden çıkan süreçlerin ayak izlerini net bir şekilde görebiliriz. Modern bir siber güvenlik uzmanı için mesele sadece bu kaosu izlemek değil; proaktif bir kaynak yönetimiyle bu tehditlerin etrafına aşılmaz duvarlar örebilmektir. Yazının bu bölümünde, sistem kaynaklarını sömüren bir kriz anında Linux çekirdeğinin sunduğu modern araçları kullanarak, kontrolden çıkan bir süreci canlı bir senaryo üzerinden nasıl dizginleyebileceğimizi adım adım inceleyeceğiz.

Olay Yeri İncelemesi: Krizin Başlaması ve htop

Bir sistemde ters giden bir şeyler olduğunu anlamanın en iyi yolu, sistemin nabzını tutmaktır. Bunun için sistemi canlı olarak inceleme aracımız olan htop'u açıyoruz. Normal şartlarda sakin seyreden işlemci (CPU) barları, sistem bir darboğaza girdiğinde bize anında kırmızı alarm verir.

Senaryomuzda, arka planda sonsuz bir döngüye girerek işlemciyi sömüren zararlı bir script (kriz.sh) olduğunu varsayalım. Bu, gerçek dünyada bir HTTP/2 Rapid Reset saldırısının sunucu işlemcisinde yarattığı darboğaz semptomunun basit bir simülasyonudur. Bu zararlı süreci doğrudan başıboş bırakmak yerine, onu Linux'un kontrol mekanizması olan systemd gözetiminde başlatıyoruz:

sudo systemd-run --scope --unit=analiz_operasyonu /tmp/kriz.sh &

Bu komutu çalıştırdıktan sonra htop ekranımızda bu süreci hemen yakalamalıyız. Bunun için klavyeden F3 tuşuna basarak (veya arama sekmesini kullanarak) yazdığımız dosya adını (kriz.sh) aratabiliriz.

Ancak burada bir sistem yöneticisinin en büyük yardımcısı F5 (Tree View — Ağaç Görünümü) tuşudur. F5'e bastığınızda süreçlerin karmaşık listesi bir soy ağacına dönüşür ve hangi sürecin kimi başlattığını (Parent-Child ilişkisini) net bir şekilde görürsünüz. İlerleyen aşamalarda strace veya lsof gibi dedektiflik araçlarını kullanırken, kancayı ana sürece (Parent) değil, doğrudan işlemciyi %100 sömüren ve ağacın en ucunda bulunan çocuk sürece (Child Process PID) atmamız gerektiğini unutmamalıyız. Aksi takdirde analiz araçlarımız yanlış süreci dinlediği için bize boş dönecektir.

Sürecimizi (doğru PID’yi) bulduğumuzda karşımızda yeşil renkle işaretlenmiş bir satır ve bir dizi sütun çıkacak. Peki, olay yerindeki bu “deliller” bize ne anlatıyor? İşte bir sistem yöneticisinin gözünden htop sütunlarının anlamları:

• PID (Process ID): Sistemin bu sürece atadığı benzersiz kimlik numarasıdır. Sürecin dijital parmak izidir.
• USER: Bu süreci kimin başlattığını gösterir. Biz komutu sudo ile çalıştırdığımız için burada yetkilerin zirvesi olan root kullanıcısını göreceğiz.
• PRI & NI (Priority & Nice): Sürecin işlemcideki öncelik durumunu belirtir. Eğer zararlı bir yazılım "Önce benim işimi yap!" diye sistemin önüne geçmeye çalışıyorsa, buradaki değerlere müdahale etmiş olabilir.
• VIRT, RES, SHR: Bellek (RAM) tüketim metrikleridir. (VIRT: Sanal bellek, RES: Fiziksel RAM). Bizim scriptimiz sadece işlemciye saldırdığı için bu değerler masum görünecektir; ancak sistemde bir Memory Leak (Bellek Sızıntısı) saldırısı olsaydı ilk inceleyeceğimiz yer burası olurdu.
• S (State - Durum): Sürecin o anki eylemidir. Bizim sonsuz döngümüz burada 'R' (Running) yani durmaksızın çalışıyor olarak görünecektir. Eğer uyuyan bir süreç olsaydı 'S' (Sleeping) harfini görecektik.
• CPU%: Krizin başrol oyuncusu! Bu sütunda, işlemcinin o çekirdeğinin nasıl %100 oranında sömürüldüğünü ve sistemin nasıl kilitlenme noktasına geldiğini canlı olarak görebilirsiniz.
• MEM%: Sistemin fiziksel belleğinin yüzde kaçının bu süreç tarafından işgal edildiğini gösterir.
• TIME+: Sürecin başladığı andan itibaren işlemciyi toplamda ne kadar süredir meşgul ettiğinin kronometresidir.
• Command: Sürecin tam olarak hangi komutla ve parametrelerle çalıştırıldığını gösterir (Örn: /bin/bash /tmp/kriz.sh).

systemd’nin Gizli Gücü: Neden Bu Komutu Kullandık?

Süreci nasıl dizginleyeceğimize geçmeden önce, onu neden bu şekilde başlattığımızı anlamamız gerekiyor. Çoğu kişi systemd'yi sadece bilgisayar açılırken servisleri başlatan standart bir araç sanır. Oysa systemd, modern Linux'un kaynak yönetim merkezidir. Az önce kullandığımız komuttaki --unit=analiz_operasyonu parametresiyle, aslında bu zararlı sürece bir kimlik atadık. Kalıcı bir ayar dosyası oluşturmadan, tamamen RAM üzerinde çalışan geçici bir "kontrol odası" (scope) yarattık. Yani karmaşık işlem numaraları (PID) bulmakla vakit kaybetmek yerine, adını kendi koyduğumuz ve sınırlarını bizim çizeceğimiz bir hedefimiz var. Şimdi bu odanın şartellerini indireceğiz.

Bu komutu çalıştırdığımız an, htop ekranında felaketi kendi gözlerimizle görürüz: İşlemci kullanımı aniden %100 seviyesine fırlar ve ilgili işlemci çekirdeği %100 kapasiteye ulaşır.

Artık elimizde kontrolden çıkmış, işlemciyi sonuna kadar sömüren ve sistemin geri kalanına nefes aldırmayan “analiz_operasyonu” adında bir kriz sürecimiz var. Peki, fişi çekip sistemi kapatmak yerine bir siber güvenlik uzmanı gibi bu süreci nasıl dizginleyeceğiz?

cgroups ile Görünmez Duvar Örmek

Sistem can çekişirken amatör bir refleksle kill -9 komutuna sarılıp süreci hemen öldürebiliriz. Ancak bir siber güvenlik uzmanı olarak analiz yapabilmek için süreci hayatta tutmalı, fakat sunucuya daha fazla zarar vermesini de engellemeliyiz.

İşte burada systemd ile kusursuz bir uyum içinde çalışan cgroups (Control Groups) limitleri devreye giriyor. Terminale şu komutu giriyoruz:

sudo systemctl set-property analiz_operasyonu.scope CPUQuota=20%

Ve sihir tam bu anda gerçekleşiyor: Bu komutu girdiğimiz saniye, htop ekranında %100 kapasitesine gelen o kıpkırmızı bar anında %20'ye düşüyor ve orada sabitleniyor!

İşletim sisteminin çekirdeği (Kernel) devreye girdi ve bu sürece “Artık işlemcinin sadece saniyenin beşte birini kullanabilirsin” dedi. Sürecin CPU kullanımı tek bir çekirdeğin %20'si ile sınırlandı ve işlemci rahatladı, sunucumuz donmaktan kurtuldu ve rahatça nefes almaya başladı.

Derinlemesine Sistem Analizi: lsof ve strace ile Süreç İzleme

Sistemi güvenli bir kota içine çektik ve sunucunun kilitlenmesini engelledik. Artık arka planda çalışan bu anomali gösteren kodun anatomisini güvenli ve izole bir ortamda inceleyebiliriz. Süreci tamamen sonlandırmadan önce, davranışsal bir analiz yapmak ve yazılımın hedeflerini anlamak için Linux sistem yönetiminin temel teşhis araçlarını devreye sokuyoruz.

1. lsof (List Open Files) ile Bağlantıları Ortaya Çıkarmak: Linux mimarisinde geçerli olan "Her şey bir dosyadır" prensibi gereği, bir süreç çalışırken arka planda sürekli dosya tanıtıcıları (file descriptors) açar ve ağ portlarına bağlanır. İncelediğimiz zararlı sürecin sistemde nerelere dokunduğunu haritalandırmak için lsof komutunu kullanırız.

Komutu çalıştırırken systemd ana sürecini değil, htop ağaç görünümünde (F5) tespit ettiğimiz ve işlemi asıl yürüten çocuk sürecin (child process) PID numarasını hedef almalıyız. Ana süreci taratırsak, asıl zararlı eylemleri gerçekleştiren sürecin dosya aktivitelerini tamamen gözden kaçırmış oluruz.

Doğru çocuk sürecin PID’sini belirledikten sonra, araya gereksiz sistem uyarılarının karışmasını engelleyerek tertemiz bir analiz tablosu almak için şu komutu çalıştırıyoruz:

sudo lsof -p <PID> 2>/dev/null

Bu komut bize sürecin o an açık tuttuğu tüm dosyaların ve kullandığı kütüphanelerin tam bir listesini verir. Eğer bu süreç dışarıya gizli bir veri sızdırıyor olsaydı, bunu lsof tablosunda suçüstü yakalamış olurduk.

2. strace ile Sistem Çağrılarını Dinlemek: Süreçler işletim sisteminin çekirdeğiyle konuşabilmek için "sistem çağrıları" (system calls) yapmak zorundadır. strace, çekirdekle süreç arasına girerek bu konuşmaları canlı olarak dinlememizi sağlar. Zararlı scriptimizin neden CPU'yu bu kadar yorduğunu görmek için sürece kanca atacağız. Ancak burada çok kritik bir detay var: Komutu çalıştırırken htop ekranında F5 (Ağaç Görünümü) ile tespit ettiğimiz ana süreci (parent) değil, ağacın en ucunda bulunan ve işlemciyi asıl sömüren çocuk sürecin (child process) PID numarasını kullanmalıyız. Eğer ana sürece bağlanırsak, o süreç sadece izleyici konumunda olduğu için strace bize hiçbir veri sunmadan boş bir ekranla bekleyecektir. Hedefimiz olan doğru çocuk sürecin PID'sini (örneğin 3835) belirledikten sonra şu komutla dinlemeye başlıyoruz:

sudo strace -p <PID> -c

-c parametresi sayesinde, sürecin hangi işlemi milyonlarca kez tekrarladığını gösteren bir özet tablosu elde ederiz. Eğer spesifik olarak nereye ne yazdığını anlık görmek istersek sudo strace -p <PID> -e write komutuyla fırlatılan her baytı izleyebiliriz. Artık düşmanımızın sadece adını değil, niyetini de biliyoruz.

Kontrollü Sonlandırma ve Sistem Temizliği

Analiz ve teşhis adımlarımız tamamlandığında, elde ettiğimiz veriler ışığında artık bu anomali gösteren sürecin fişini çekme vakti gelmiştir. Sistemde herhangi bir kalıntı veya zombi süreç bırakmamak için müdahalemizi iki aşamalı, profesyonel bir temizlik döngüsüyle sonlandırıyoruz:

1. Tehdidi Yok Etmek (kill -9): İlk olarak, Linux sistem yöneticilerinin en kesin ve tavizsiz aracı olan SIGKILL sinyalini göndererek, az önce htop üzerinde tespit ettiğimiz ve işlemciyi sömüren asıl çocuk süreci acımasızca sonlandırıyoruz:

sudo kill -9 <PID>

(Not: Buradaki <PID>, bizim süreci başlattıktan sonraki htop ekranında gördüğümüz çocuk sürecin PID'sidir.)

2. Karantina Odasını Kapatmak (systemctl stop): Süreci tamamen öldürdükten sonra, sunucuda yapılandırma kalıntısı bırakmamak esastır. Bu nedenle, zararlı betiği içine hapsettiğimiz geçici systemd izole ortamını (scope) tek bir komutla güvenli bir şekilde kapatıyor ve sistemden siliyoruz:

sudo systemctl stop analiz_operasyonu.scope

Bu iki aşamalı temizliğin ardından, htop ekranındaki işlemci barları anında standart seviyelerine geriler. Sistemin yeniden başlatılmasına (reboot) veya karmaşık çökme raporlarıyla uğraşmaya gerek kalmadan; tehdidi izole ettiğimiz, kısıtladığımız, analiz ettiğimiz ve sisteme tam yetkiyle profesyonelce hükmettiğimiz bu kriz yönetimi senaryosunu eksiksiz bir şekilde tamamlamış oluruz.

Gerçek Dünya Senaryoları: Kritik Zafiyetler (CVE) ve Sistem Üzerindeki Etkileri

Yazımızda kriz.sh isimli bir betik üzerinden işlemciyi sömüren bir darboğaz simüle ettik. Ancak gerçek dünyada bu senaryolar, global internet altyapısını sarsan resmi zafiyetler (CVE - Common Vulnerabilities and Exposures) olarak karşımıza çıkmaktadır. Terminalde uyguladığımız savunma taktiklerinin gerçek hayattaki karşılıklarını anlamak için yakın geçmişin en büyük iki krizine bakmamız yeterlidir:

• CVE-2023–44487 (HTTP/2 Rapid Reset): Yazımızın başından beri referans verdiğimiz bu zafiyet, tarihin en büyük DDoS saldırılarına kapı aralamıştır. Saldırganlar, HTTP/2 protokolünün esnekliğini suistimal ederek sunuculara anında iptal edilen milyonlarca istek gönderir. Bu durum, sunucu işlemcilerinde tıpkı bizim simülasyonumuzdaki gibi saniyeler içinde %100'lük bir kilitlenme yaratır. Doğru yapılandırılmış cgroups kotaları, bu tür anormalliklerde ana sistemin tamamen çökmesini engelleyen ve servisin ayakta kalmasını sağlayan önemli bir savunma katmanıdır.
• CVE-2024–3094 (XZ Utils Arka Kapısı): Yakın zamanda tüm Linux dünyasını şoka sokan bu karmaşık tedarik zinciri saldırısı, hedef sistemlere systemd entegrasyonu üzerinden sızmış ve doğrudan sshd (SSH servisi) sürecini enfekte etmiştir. Eğer uyanık bir sistem yöneticisi veya güvenlik uzmanı, şüpheli gördüğü bir SSH sürecini yazımızdaki lsof ve strace araçlarıyla inceleseydi, sürecin belleğe yüklediği o gizli ve zararlı kütüphane bağlantılarını suçüstü yakalayabilirdi. Bu kriz, süreç dedektifliğinin sadece bir teori değil, hayati bir savunma hattı olduğunu kanıtlamıştır.

İşletim sistemleri kusursuz değildir ve süreçler her zaman planlandığı gibi çalışmaz. Gerçek bir sistem yönetimi ve siber güvenlik uzmanlığı; sadece her şey yolundayken çalışan komutları ezberlemek değil, sistem alev aldığında o yangını proaktif bir şekilde, soğukkanlılıkla ve profesyonelce söndürebilmektir. Süreçleri izlemek, anlamak ve dizginlemek üzerine çıktığımız bu yolculukta umarım Linux çekirdeğinin o güçlü mimarisine farklı bir gözle bakmanızı sağlayabilmişizdir.