PCAP Konuşmaları

Elinize hiçbir bağlam olmadan bir capture geçtiğinde, ne olduğunu en hızlı anlamanın yolu endpoint ve pair özetleridir. PCAP veya PCAPNG yükleyin; en çok konuşan endpoint’leri ve en yoğun pair’ları paket/byte sayıları ve protokol etiketleriyle, JSON olarak indirilebilir biçimde alın.

Endpoint satırı, flow satırından farklı bir soruyu yanıtlar. Endpoint size bir adresin katıldığı bütün konuşmalar boyunca toplamda ne kadar iş yaptığını söyler; flow ise tek bir konuşmanın ne taşıdığını. Tanımadığınız bir capture’da önce endpoint’lere bakılır — on beş satır genellikle bu dosyanın aslında hangi birkaç makineyle ilgili olduğunu ortaya koyar — sonrası detaya inmektir. Hangi çiftle ilgilendiğinizi zaten biliyorsanız flow çıktısı daha iyi bir başlangıçtır.

Yorum mutlak değil karşılaştırmalıdır. Byte listesinin tepesindeki bir iş istasyonu ancak orada olmaması gerekiyorsa ilginçtir: yedekleme penceresinde çalışan bir yedek istemcisi normaldir, aynı istemcinin pazar sabahı 03:00’te aynı yerde olması değil. Büyüklük kadar biçime de bakın. Tek bir adresin byte’ta baskın olması genelde transfer demektir. Tek bir adresin çok sayıda farklı karşı tarafa dokunması genelde tarama, proxy veya mail sunucusu demektir. Küçük ve birbirine yakın sayılardan oluşan uzun bir kuyruk ise çoğunlukla broadcast/multicast gürültüsüdür — ARP, mDNS, SSDP, NetBIOS — ve bunu tanımak, görmezden gelebilmek için gereklidir.

Pair’lar komşuluk bilgisini verir: hangi endpoint kiminle konuşmuş. Segmentasyon sorunları burada gözle görünür hâle gelir. Bir kullanıcı iş istasyonunun on iki başka iş istasyonuyla doğrudan SMB konuşması yapması düzgün segmente edilmiş bir ağın davranışı değildir ve bilinen bir yanal hareket (lateral movement) örüntüsüdür. Bir firewall kuralının diyagramda yazdığı işi yapmadığını kanıtlamanın da en hızlı yolu budur; çünkü izole olması gereken iki segment arasındaki trafiği sayılarıyla birlikte görürsünüz.

“Sadece IP ile grupla” seçeneği çözünürlüğü değiştirir. Makine düzeyinde bir sayım istiyorsanız açık bırakın; portlar orada yalnızca gürültüdür, çünkü tarayıcının seçtiği geçici kaynak portunu bilmek işinize yaramaz. Portun kendisi konunun özüyse kapatın: bir host’un 443 trafiğini 22 trafiğinden ayırmak, kimsenin onaylamadığı bir portta dinleyen servisi yakalamak veya bir uygulama sunucusunun API yerine doğrudan veritabanına gidip gitmediğini kontrol etmek için. Kapalıyken liste belirgin biçimde uzar, çünkü istemci tarafındaki geçici portlar her host’u birçok satıra böler.

Display filter kapsamı toplamadan önce daraltır ve BPF değil Wireshark display filter söz dizimini kullanır. Sık kullanılan kalıplar: UDP gürültüsünü atmak için tcp, tek bir segmente bakmak için ip.addr == 192.168.10.0/24, keşif trafiğini temizlemek için !(arp || mdns || ssdp) ve multicast’i çıkarmak için not ip.dst == 224.0.0.0/4. Önce filtrelemek top-N listesini de anlamlı kılar; aksi hâlde bir avuç gürültülü protokol ilgilendiğiniz her şeyi listeden dışarı iter.

Çıktının CSV değil JSON olmasının nedeni, endpoint’lerin doğal olarak bir sonraki işlemin girdisi olmasıdır. Adresler doğrudan bir ASN veya WHOIS sorgusuna beslenebilir, envanterle IP üzerinden eşleştirilebilir ya da bir değişiklik öncesi ve sonrası alınmış iki capture arasında diff alınarak hangi konuşmaların ortaya çıktığı görülebilir. Adres, port, protokol, paket ve byte alanlarından oluşan düz bir yapı jq ile veya birkaç satırlık bir script ile işlenebilir; bu da aynı analizi elle tekrarlamaktan çok daha hızlıdır.

Açıkça söylenmesi gereken sınırlar var. Endpoint toplamları capture noktası kadar dürüsttür: NAT ya da proxy arkasında bütün iç host’lar tek bir adrese saklanır ve mirror/SPAN olmadan alınan bir capture segmentin ancak bir kısmını görür. Pair satırlarındaki yön, o çift için görülen ilk pakete göre belirlenir; konuşma başladıktan sonra başlayan bir capture istemci ile sunucuyu ters etiketleyebilir. Ve hiçbir özet neyin aktarıldığını söylemez — kimin, ne kadar ve hangi protokolle konuştuğunu söyler. Dosya yalnızca JSON’u üretmek için işlenir ve saklanmaz.