NetFlow ve Zeek kayıtlarının mantığı

Önceki derslerde gördüğün Wireshark ve tshark paketin kendisini tutar. Bu ayrıntı zengindir ama pahalıdır. Büyük bir kurumsal ağda her paketi saklamak hem disk hem gizlilik açısından sürdürülemez.

Akış kayıtları farklı bir yol seçer: yükü hiç tutmaz, yalnız bir konuşmanın özetini kaydeder. Bu derste iki özet biçimini, NetFlow ve Zeek'i, aynı sorularla sınayacaksın: kim kiminle konuştu, ne kadar sürdü, bağlantı nasıl bitti, örüntü olağan mı. Paket elinde olmasa bile bu sorulara cevap verebilmek, gerçek bir soruşturmada çoğu zaman en sık kullandığın beceri olur.

Akış (flow), ortak özellikleri olan ve bir ağ cihazından geçen tek yönlü paket dizisidir. Akışı anahtar alanlar tanımlar: kaynak IP, hedef IP, kaynak port, hedef port ve protokol. Klasik uygulamalarda hizmet türü (ToS) ve giriş arayüzü de anahtara girer. Kayıt ayrıca paket sayısını, toplam baytı, başlangıç ve bitiş zamanını ve görülen TCP bayraklarının birleşimini taşır.

HTTP başlığı ya da DNS sorgusunun adı akışta yer almaz. Yönlendirici ve anahtarlar akışı kendileri üretir, yani dışa aktarıcı (exporter) olur ve kayıtları bir toplayıcıya (collector) yollar. Bu sadelik, yüz binlerce bağlantıyı küçük bir dosyada tutmayı mümkün kılar.

Tek yönlülük önemli bir ayrıntıdır. Wireshark'taki tcp.stream bir bağlantının iki yönünü tek akışta toplar. NetFlow ise aynı bağlantıyı iki kayda böler: istemciden sunucuya giden paketler bir kayıt, sunucudan dönenler başka bir kayıt olur. Bir web isteğinde istemci yönü birkaç kilobayt, sunucu yönü megabaytlar taşır.

İki kaydı eşleştirmeden okursan yönü ve hacmi yanlış yorumlarsın. Bazı toplayıcılar iki yönü çift yönlü akış (biflow) olarak birleştirir; IPFIX için bu biçim RFC 5103'te tanımlıdır. Kaydı okumadan önce aracının hangi biçimi kullandığını öğren.

NetFlow sürümleri kayıt biçiminde ayrılır. NetFlow v5 sabit alanlıdır: her kayıt aynı sırada aynı alanları taşır ve yalnız IPv4'ü destekler. NetFlow v9 (RFC 3954) şablon (template) mantığını getirdi.

Dışa aktarıcı önce hangi alanları hangi sırayla göndereceğini bir şablonla bildirir, ardından veriyi bu şablona göre yollar. Böylece IPv6 ve yeni alanlar eklemek kolaylaşır. IPFIX (RFC 7011) v9 üstüne kurulan IETF standardıdır ve alanlarını IANA'nın bilgi öğesi (information element) kaydından alır.

Toplayıcı şablonu kaçırırsa veriyi çözemez, bu yüzden şablonlar düzenli aralıklarla yeniden gönderilir. Bulut sağlayıcılarının sanal ağ akış kayıtları da aynı özet mantığını izler.

Dışa aktarıcı bir akışı ne zaman bitmiş sayar? RFC 3954 dört durum tanımlar. TCP'de FIN ya da RST görülürse kayıt gönderilir.

Akışta bir süre hiç paket görülmezse pasif (inactive) zaman aşımı dolar. Uzun süren akışlar aktif (active) zaman aşımıyla düzenli aralıklarla dışa aktarılır. Cihazın belleği dolarsa kayıt erken kapanabilir.

Aktif zaman aşımının sonucu şudur: iki saat süren bir bağlantı, aktif zaman aşımı 30 dakikaysa her yönde dört kayda bölünür. Yoğun hatlarda örnekleme (sampling) de kullanılır. 1:1000 örneklemede cihaz her bin paketten yalnız birini sayar; büyük akışlar görünür ama tek SYN'lik kısa denemeler kayda hiç girmeyebilir.

Zeek (eski adıyla Bro) farklı bir katmana oturur. Paketi işler ama sonucu tek bir sayaç yerine protokole özel zengin kayıtlara yazar. Canlı arayüzde de, kayıt dosyasında da çalışır: zeek -r olay.pcap komutu bulunduğun klasöre birkaç .log dosyası bırakır. conn.log her bağlantıyı bir satırda özetler.

dns.log sorguları ve cevapları, http.log istek yöntemini, adresi ve kullanıcı aracısını tutar. ssl.log TLS el sıkışmasındaki sunucu adını ve sürümü yazar. files.log aktarılan dosyaları, weird.log ise protokol kurallarına uymayan tuhaflıkları kaydeder. Hangi dosyaların oluşacağı trafikte görülen protokollere bağlıdır.

conn.log'u ham hâliyle okumak zordur, çünkü sekmeyle ayrılmış onlarca sütun vardır. zeek-cut istediğin sütunları seçer ve gerisini atar. Temel alanlar şunlardır: ts zaman damgası, uid bağlantının benzersiz kimliği, id.orig_h ve id.orig_p başlatanın adresi ve portu, id.resp_h ve id.resp_p yanıtlayanın adresi ve portu.

proto taşıma protokolünü, service Zeek'in tanıdığı uygulama protokolünü, duration süreyi gösterir. orig_bytes ve resp_bytes iki yönün uygulama yükünü sayar; IP başlıkları dahil sayım orig_ip_bytes ve resp_ip_bytes alanlarındadır. conn_state ve history ise bağlantının nasıl geliştiğini anlatır.

uid, bir bağlantıyı bütün Zeek kayıtlarında izlemeye yarayan anahtardır. conn.log'da şüpheli bir satır bulduğunda aynı uid'i http.log, dns.log ya da ssl.log içinde ararsın ve o bağlantının istek adresine, sorgusuna ya da sunucu adına geçersin. Farklı araçlar arasında aynı işi Community ID görür.

Community ID, bağlantının adreslerinden, portlarından ve protokolünden yön gözetmeden bir SHA1 özeti üretir ve başına sürüm için 1: ekler. Zeek, Suricata ve Wireshark aynı bağlantı için aynı değeri hesaplar. Zeek'te alan, ilgili politika betiği yüklenince conn.log'a eklenir. Böylece bir Suricata alarmından Zeek kaydına tek bir metin eşleşmesiyle geçersin.

conn_state alanı bağlantının nasıl bittiğini kısa bir kodla yazar. Zeek her bağlantının bayrak dizisini izler ve onu tek bir sonuç koduna indirger. Kodların tam listesi aşağıda.

Analist için bu kodlar üç gruba ayrılır. S0, REJ, RSTOS0 ve SH'de el sıkışma tamamlanmamıştır. Tek bir kaynaktan gelen çok sayıda böyle kod tarama izidir.

SF, S1, S2, S3 ve RSTO'da bağlantı kurulmuştur; RSTR'de yanıtlayan bağlantıyı RST ile keser. RSTRH, SHR ve OTH'de ise Zeek başlatanın SYN paketini hiç görmemiştir. Bu grup çoğu zaman yakalamanın bir bağlantının ortasından başladığını gösterir.

S0      Bağlantı denemesi görüldü, cevap yok
S1      Bağlantı kuruldu, henüz kapanmadı
SF      Olağan açılış ve kapanış
REJ     Bağlantı denemesi reddedildi
S2      Kuruldu; başlatan kapatmak istedi, yanıtlayan cevap vermedi
S3      Kuruldu; yanıtlayan kapatmak istedi, başlatan cevap vermedi
RSTO    Kuruldu, başlatan RST ile kesti
RSTR    Yanıtlayan RST gönderdi
RSTOS0  Başlatan SYN'den sonra RST gönderdi, SYN-ACK görülmedi
RSTRH   Yanıtlayan SYN-ACK'ten sonra RST gönderdi, SYN görülmedi
SH      Başlatan SYN'den sonra FIN gönderdi, SYN-ACK görülmedi
SHR     Yanıtlayan SYN-ACK'ten sonra FIN gönderdi, SYN görülmedi
OTH     SYN görülmedi, yalnız bağlantının ortası yakalandı

history alanı aynı hikâyeyi harf harf anlatır. Büyük harf başlatanın, küçük harf yanıtlayanın yaptığı işi gösterir. S SYN, h SYN-ACK, A yalın ACK, D veri taşıyan paket, F FIN, R RST demektir. ShADadFf, üçlü el sıkışmayla açılan, iki yönde veri taşıyan ve iki taraftan FIN ile kapanan tam bir bağlantıdır; conn_state'i SF olur.

Tek başına S, cevapsız kalan bir SYN'dir ve S0'a karşılık gelir. Sr, SYN'e RST ile cevap verildiğini gösterir; kapalı bir portun REJ kaydıdır. Aşağıdaki çıktıda 192.168.1.66'nın 192.168.1.50'nin 22, 445 ve 3389 portlarına yaptığı üç denemenin hiçbiri tamamlanmamış.

$ zeek -r olay.pcap
$ zeek-cut id.orig_h id.resp_h id.resp_p proto conn_state history < conn.log
192.168.1.20	203.0.113.10	80	tcp	SF	ShADadFf
192.168.1.20	203.0.113.21	21	tcp	SF	ShAdDaFf
192.168.1.20	198.51.100.44	9001	tcp	SF	ShADadFf
192.168.1.20	192.168.1.1	53	udp	SF	Dd
192.168.1.66	192.168.1.50	22	tcp	S0	S
192.168.1.66	192.168.1.50	445	tcp	REJ	Sr
192.168.1.66	192.168.1.50	3389	tcp	S0	S

Sık yapılan hata, orig ve resp'i istemci ve sunucu sanmaktır. Zeek çoğu durumda bağlantının ilk paketini göndereni başlatan sayar. Yakalama bir bağlantının ortasından başladıysa ilk görülen paket sunucudan gelebilir ve roller ters görünür.

Zeek bunu bazı durumlarda düzeltir: ilk paketin kaynak portu bilinen bir sunucu portuysa rolleri çevirir ve history alanına ^ işareti ekler. conn_state OTH ise ya da history ^ taşıyorsa, yönü paketlerden doğrulamadan "veriyi kim gönderdi" sorusuna cevap verme.

Akış kayıtlarını sorgulamanın yaygın açık kaynak araçlarından biri nfdump'tır. nfcapd toplayıcısı NetFlow v5, v9 ve IPFIX kayıtlarını alır ve dönemlik dosyalara yazar, nfdump bu dosyaları okur. -r bir dosya ya da bütün bir klasör alır. -s bir istatistik üretir: srcip/bytes kaynak adreslere göre gruplar ve bayta göre sıralar.

-n kaç satır gösterileceğini belirler. Filtre söz dizimi BPF'ye benzer, örneğin 'proto tcp and dst port 443'. Eski rehberlerde geçen -R bayrağı belgede eski uyumluluk seçeneği olarak durur; klasör okumak için -r yeterlidir.

$ nfdump -r /veri/akislar/2026/09/13/ -s srcip/bytes -n 5
Top 5 Src IP Addr ordered by bytes:
Date first seen             Duration     Proto       Src IP Addr    Flows(%)     Packets(%)       Bytes(%)         pps      bps   bpp
2026-09-13 00:00:04.112     23:59:51.200 any           10.0.6.21      412( 0.3)    1.9 M(11.2)    2.6 G(38.5)       21   240765  1368
2026-09-13 00:00:01.870     23:59:58.010 any           10.0.5.10    18230(12.2)    6.1 M(35.9)    1.9 G(28.1)       70   175929   311
2026-09-13 00:00:07.455     23:58:12.004 any           10.0.5.20     9100( 6.1)    1.1 M( 6.5)  402.5 M( 6.0)       12    37315   365
2026-09-13 02:14:33.020     00:42:10.500 any           10.0.7.18       96( 0.1)   212000( 1.2)  310.0 M( 4.6)       83   980043  1462
2026-09-13 00:19:40.301     23:40:02.310 any           10.0.6.30     5300( 3.5)   880000( 5.2)  290.1 M( 4.3)       10    27238   329

Tabloyu sütun sütun oku. 10.0.6.21 yalnız 412 akışla günün baytının yüzde 38,5'ini göndermiş. Paket başına ortalama 1368 bayt (bpp) düşüyor, yani dolu paketler.

Az akış, çok bayt ve büyük paket, tek yönlü büyük aktarımın imzasıdır. Bu makine yedekleme sunucusuysa olağandır, bir iş istasyonuysa değildir. 10.0.5.10 ise 18230 akış ve küçük paketlerle çok konuşan bir sunucuya benzer.

Dördüncü satır göze batar: 10.0.7.18 gün boyu değil, 02:14'te başlayan 42 dakikada 96 akışla 310 megabayt göndermiş. Mesai dışı, kısa ve yoğun bir aktarım. Sıradaki sorgu bu kaynağın hedeflerini çıkarır: 'src ip 10.0.7.18' filtresi ve -s dstip/bytes.

Akış kayıtları iki sinsi örüntüyü de yakalar. Birincisi uzun süreli, düşük baytlı bağlantılardır. Saatlerce açık kalan ve dakikada birkaç yüz bayt taşıyan bir bağlantı, komuta sunucusuna bağlı bir zararlının düzenli yoklaması olabilir.

İkincisi alışılmadık hedef portlardır, örneğin bir iş istasyonundan dışarıya 4444 ya da 9001'e giden akışlar. Taramanın izi de akışta bellidir. conn_state yoktur, ama aynı kaynaktan kısa sürede birçok hedef porta giden bir iki paketlik akışlar aynı örüntüyü taşır.

Ölçüt, bir zaman penceresinde kaynak başına benzersiz hedef port sayısıdır. SiLK gibi araç takımları aynı sorguları büyük ölçekte çalıştırır: rwfilter akışları süzer, rwstats en çok konuşanları çıkarır.

Akış kaydının değeri saklama süresine bağlıdır. Tam paket birkaç gün tutulurken akış özetleri aylarca tutulabilir. Bir sızıntı haftalar sonra fark edildiğinde elindeki tek kanıt çoğu zaman akış kaydıdır.

Akışları ve Zeek kayıtlarını SIEM'e aktarırsın; tarama, sızdırma ve olağandışı port kuralları orada otomatik çalışır. Böylece paket yokken bile "bu makine geçen ay kiminle konuştu" sorusuna cevap veren bir akış envanteri kurarsın. Saklama süresini belirlerken KVKK'nın ölçülülük ve gerekli süre kadar saklama ilkesini de uygula. Akış kaydı da kimin kiminle konuştuğunu gösteren kişisel veridir.

Akışın sınırını da bil. NetFlow yükü tutmaz; hangi sayfaya gidildiğini ya da hangi dosyanın indirildiğini söylemez. Zeek bu boşluğun bir kısmını uygulama kayıtlarıyla doldurur, ama varsayılan hâliyle o da içeriğin kendisini saklamaz. Üç katman birlikte çalışır.

Akış kaydında şüpheliyi bulursun. Zeek kayıtlarında uid ile bağlamı çıkarırsın. Elinde tam yakalama varsa Follow Stream ile içeriğe inersin. Sıradaki modülde bu kayıtları güvenlik duvarı ve saldırı tespit kurallarına bağlayacaksın.