Wireshark ile Windows Sunucusunda Paket Analizi
Bir Windows sunucusunda ağ sorunu yaşandığında, ilk içgüdü genellikle ping atmak ya da netstat çıktısına bakmaktır. Ama bazen sorun o kadar derin bir yerdedir ki, paketlerin ta kendisine bakmak gerekir. İşte tam bu noktada Wireshark devreye girer. Yıllarca bu aracı hem üretim sunucularında hem de test ortamlarında kullandım; doğru kullanıldığında neredeyse her ağ probleminin kökünü bulduğunu söyleyebilirim.
Bu yazıda sizi teorik bir Wireshark turuna çıkarmayacağım. Gerçek senaryolar, gerçek filtreler ve gerçek çözümler üzerine konuşacağız.
Neden Wireshark, Neden Windows Sunucusunda?
Linux tarafında tcpdump her zaman yanınızdadır. Ama Windows Server ortamlarında, özellikle kurumsal altyapılarda, Wireshark hem GUI hem de komut satırı aracı olan tshark ile birlikte giderek standart bir araç haline geliyor. Üretim sunucusuna RDP bağlanıp GUI’yi açmak istemeyebilirsiniz; anlayışla karşılıyorum. Ama şunu söylemeliyim: Wireshark’ın Windows üzerindeki performansı son birkaç majör versiyonla ciddi şekilde iyileşti.
Şunu da ekleyeyim: Windows Server 2019 ve 2022’de gelen pktmon aracı bir alternatif olarak öne çıkıyor, ancak Wireshark’ın filtre dili ve analiz derinliğiyle kıyaslanamaz. O yüzden burada asıl odağımız Wireshark ve tshark olacak.
Kurulum ve İlk Yapılandırma
Wireshark’ı üretim sunucusuna kurarken dikkat etmeniz gereken birkaç nokta var. Kurulum sırasında size Npcap ya da WinPcap seçeneği sunulur. Kesinlikle Npcap tercih edin; WinPcap uzun süredir aktif geliştirilmiyor ve Windows 10/Server 2019 sonrası sistemlerde stabil değil.
Kurulum sırasında “Install Npcap in WinPcap API-compatible mode” seçeneğini işaretleyin. Bu, eski bazı araçlarla uyumluluğu korur.
Wireshark’ı GUI olmadan, sadece tshark ile kullanmak istiyorsanız, aşağıdaki PowerShell komutu ile sessiz kurulum yapabilirsiniz:
# Wireshark silent kurulum (tshark dahil)
winget install WiresharkFoundation.Wireshark --silent
# ya da MSI ile:
msiexec /i Wireshark-win64-4.x.x.msi /quiet INSTALL_TSHARK=1 INSTALL_WIRESHARK=1Kurulum sonrası tshark’ın PATH’e eklendiğini doğrulayın:
# PowerShell veya CMD
tshark --version
# Mevcut interface'leri listele
tshark -DBu komut size şuna benzer bir çıktı verir:
1. DeviceNPF_{GUID-1234...} (Ethernet0)
2. DeviceNPF_{GUID-5678...} (Local Area Connection)
3. DeviceNPF_Loopback (Adapter for loopback traffic capture)Interface adlarını not edin; filtreleme sırasında kullanacaksınız.
Temel Filtreleme Mantığını Anlamak
Wireshark’ın iki farklı filtre türü vardır ve bu ayrımı kafaya yerleştirmeden işe yarayana kadar çok vakit harcarsınız:
Capture Filter (Yakalama Filtresi): BPF (Berkeley Packet Filter) sözdizimiyle yazılır. Paketler yakalanmadan önce filtrelenir. Performans açısından kritik üretim ortamlarında tercih edilmeli.
Display Filter (Görüntüleme Filtresi): Wireshark’ın kendi filtre diliyle yazılır. Yakalanan paketler arasından görüntülenecekleri seçer. Daha zengin seçenekler sunar.
Örnek bir capture filter ile tshark başlatmak:
# Sadece belirli bir IP'den gelen/giden trafiği yakala
tshark -i "Ethernet0" -f "host 10.10.5.45" -w C:Capturesserver_traffic.pcap
# Sadece HTTP ve HTTPS trafiği
tshark -i "Ethernet0" -f "tcp port 80 or tcp port 443" -w C:Capturesweb_traffic.pcap
# Belirli bir subnet'ten gelen trafik
tshark -i "Ethernet0" -f "net 192.168.10.0/24" -w C:Capturessubnet_traffic.pcapDisplay filter örnekleri (pcap dosyasını analiz ederken):
# Belirli IP'yi filtrele
tshark -r C:Capturesserver_traffic.pcap -Y "ip.addr == 10.10.5.45"
# HTTP POST isteklerini bul
tshark -r C:Capturesweb_traffic.pcap -Y "http.request.method == POST"
# TCP yeniden iletimlerini (retransmission) bul - ağ kalite sorunlarının göstergesi
tshark -r C:Capturesserver_traffic.pcap -Y "tcp.analysis.retransmission"
# DNS sorgularını listele
tshark -r C:Capturesserver_traffic.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.nameGerçek Dünya Senaryosu 1: IIS Üzerinde Yavaş Sayfa Yüklemesi
Bir müşteri IIS sunucularında belirli saatlerde sayfa yükleme sürelerinin 8-10 saniyeye çıktığını bildirdi. Uygulama loglarında anlamlı bir hata yoktu, sunucu CPU ve RAM kullanımı normaldi. Klasik “uygulama mı, ağ mı?” sorusu.
Önce yoğun saatte tshark ile 5 dakikalık yakalama yaptık:
tshark -i "Ethernet0" -f "tcp port 80 or tcp port 443" -a duration:300 -w C:Capturesiis_slowness.pcapSonra Wireshark’ta pcap’i açıp TCP stream grafiğine baktık. Ama asıl altın bilgiyi şu tshark komutu verdi:
# TCP conversation istatistikleri - hangi bağlantıların en çok sürdüğünü göster
tshark -r C:Capturesiis_slowness.pcap -q -z conv,tcp
# TCP handshake sürelerini analiz et (SYN'den SYN-ACK'e kadar geçen süre)
tshark -r C:Capturesiis_slowness.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -T fields -e frame.time_relative -e ip.dst -e tcp.dstportSonuç ilginçti: Belirli bir backend sunucusuna giden bağlantılarda SYN’den SYN-ACK’e geçen süre 3 saniyenin üzerindeydi. Problem IIS’te değil, IIS’in bağlandığı SQL sunucusunun ağ yolundaydı. Araya giren bir switch’in auto-negotiation sorunu vardı.
Gerçek Dünya Senaryosu 2: SMB Bağlantı Sorunları
Windows ortamlarında SMB sorunları baş ağrısının tanımlı halidir. Kullanıcılar dosya sunucusuna bağlanamıyor ya da bağlantı kopuyor. Event Log’da 1026 hataları var ama neden?
SMB trafiğini izole etmek için:
# SMB ve SMB2 trafiğini yakala (445 portu)
tshark -i "Ethernet0" -f "tcp port 445" -w C:Capturessmb_traffic.pcap
# Yakalama sonrası SMB hata paketlerini filtrele
tshark -r C:Capturessmb_traffic.pcap -Y "smb2.nt_status != 0x00000000" -T fields -e ip.src -e ip.dst -e smb2.nt_status -e smb2.cmdBu komut size tam olarak hangi istemcinin, hangi SMB komutunda, hangi hata koduyla karşılaştığını gösterir. 0xC000006D hatası kimlik doğrulama sorununa, 0xC0000022 erişim reddine işaret eder.
Bir adım daha ileri gidelim; SMB oturumlarının toplam süresini çıkaralım:
# SMB session istatistikleri
tshark -r C:Capturessmb_traffic.pcap -q -z smb2,srtBu çıktıdaki “Max SRT” değerleri yüksekse, sorun ağdan değil depolama gecikmesinden kaynaklanıyor olabilir.
Gerçek Dünya Senaryosu 3: Güvenlik Analizi – Anormal Trafik Tespiti
Bir gün SOC ekibi Windows sunucularından birinin gece yarısı 3’te anormal dış trafik oluşturduğunu bildirdi. Firewall logları IP adresi veriyordu ama ne tür trafik olduğu belirsizdi.
# Gece 02:00 - 04:00 arası dışarı giden tüm trafiği yakala
# Önce sunucunun kendi IP'sini not et: 10.10.1.50
tshark -r C:Capturesnight_traffic.pcap -Y "ip.src == 10.10.1.50 && !ip.dst[0:1] == 0a" -T fields -e frame.time -e ip.dst -e tcp.dstport -e udp.dstport -e frame.len | head -100Daha okunabilir bir çıktı için:
# Dışarı giden bağlantıları destination IP ve port bazında grupla
tshark -r C:Capturesnight_traffic.pcap -Y "ip.src == 10.10.1.50" -T fields -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rnBu analizde ortaya çıkan şey, bir scheduled task üzerinden çalışan ve bilgi toplayan bir process’in 443 portunu kullanarak dışarı veri gönderdiğiydi. HTTPS olduğu için içeriği doğrudan okuyamazdık, ama hangi IP’ye, ne kadar veri gönderildiği ve bağlantı süreleri anomaliyi doğrulamak için yeterliydi.
tshark ile Otomatik Yakalama ve Rotasyon
Üretim sunucularında sürekli izleme yapmanız gerektiğinde, disk dolmaması için döngüsel yakalama (ring buffer) kullanın:
# 100MB'lık dosyalar halinde, maksimum 10 dosya tut (toplam 1GB)
# Yani en eski dosyayı silerek yenisini açar
tshark -i "Ethernet0" -b filesize:102400 -b files:10 -w C:Capturesrolling_capture.pcap
# Hem boyut hem zaman bazlı rotasyon (her 30 dakikada bir yeni dosya, max 48 dosya = 24 saat)
tshark -i "Ethernet0" -b duration:1800 -b files:48 -w C:Captureshourly_capture.pcap
# Belirli bir süre çalıştır ve dur (8 saat = 28800 saniye)
tshark -i "Ethernet0" -a duration:28800 -b filesize:51200 -b files:20 -w C:Capturesworkday_capture.pcapBu komutu bir Windows Service olarak ya da Task Scheduler üzerinden çalıştırabilirsiniz. Kritik sunucularda ben genellikle Task Scheduler’a “Sistem başlangıcında başlat” şeklinde tanımlarım ve düzenli olarak pcap dosyalarını inceleme alışkanlığı edinirim.
GUI Wireshark ile Derinlemesine Analiz
tshark güçlüdür ama bazı analizler için GUI kaçınılmaz. Uzak masaüstü üzerinden Wireshark çalıştırıyorsanız bile şu özelliklerden yararlanın:
IO Graphs: Zaman içindeki trafik yoğunluğunu görselleştirir. Ani spike’lar genellikle broadcast storm veya DDoS belirtisidir.
TCP Stream Graph: Tek bir TCP oturumunun yaşam döngüsünü gösterir. Burada saçma sequence number sıçramaları veya pencere boyutu sıfırlanmaları ağ tıkanıklığının net göstergesidir.
Follow TCP Stream: Bir TCP oturumunun tüm içeriğini ham metin olarak görürsünüz. HTTPS olmayan HTTP trafiğinde POST içeriklerini, kimlik bilgilerini veya uygulama hatalarını buradan okuyabilirsiniz.
Expert Information: Wireshark’ın otomatik olarak tespit ettiği anormallikleri listeler. Çok sayıda “TCP Retransmission” veya “TCP Window Full” uyarısı görüyorsanız, bant genişliği veya gecikme problemi var demektir.
Wireshark Filtrelerinde İleri Seviye Teknikler
Zaman içinde en çok işe yarayan filtreleri bir araya getireyim:
# Sadece yeniden iletimler ve sıra dışı paketler (ağ kalite analizi)
tshark -r capture.pcap -Y "tcp.analysis.flags && !tcp.analysis.ack_rtt"
# Büyük paketler - MTU sorunlarını tespit et (1500 baytın üzeri)
tshark -r capture.pcap -Y "frame.len > 1500"
# SYN flood tespiti - çok sayıda yarım açık bağlantı
tshark -r capture.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -T fields -e ip.src | sort | uniq -c | sort -rn | head -20
# HTTP 5xx hataları
tshark -r capture.pcap -Y "http.response.code >= 500"
# ICMP redirect mesajları - yanlış routing tespiti
tshark -r capture.pcap -Y "icmp.type == 5"
# ARP broadcast fazlalığı - ağ segmentasyon sorunları
tshark -r capture.pcap -Y "arp.opcode == 1" -T fields -e arp.src.proto_ipv4 | sort | uniq -c | sort -rnPerformans ve Dikkat Edilmesi Gerekenler
Üretim sunucusunda Wireshark/tshark çalıştırırken dikkatli olunması gereken birkaç nokta:
CPU kullanımı: tshark tek thread üzerinde çalışır. Yüksek trafikli (1Gbps+) bir interface’de paket kaybı yaşanabilir. Bu durumda capture filter kullanarak trafik miktarını önceden azaltın.
Disk I/O: Özellikle SSD olmayan sunucularda yüksek hızlı yakalama disk performansını etkileyebilir. Mümkünse pcap’i yerel diske değil, dedicated bir capture diskine yazın.
Promiscuous Mode: Wireshark varsayılan olarak promiscuous modda çalışır ve tüm ağ trafiğini yakalar, sadece kendi IP’sine geleni değil. Switch’ler üzerinde port mirroring yapılandırılmamışsa bu mod switch ortamında sadece broadcast trafiği ve kendi trafiğinizi gösterir. Spesifik bir sunucu arasındaki trafiği izlemek istiyorsanız, switch üzerinde SPAN (port mirroring) yapılandırmanız gerekebilir.
Güvenlik ve Uyumluluk: Ağ trafiğini yakalamak, içinde kimlik bilgileri veya hassas veri geçiyorsa ciddi bir güvenlik ve uyumluluk riski taşır. KVKK ve kurumsal güvenlik politikaları kapsamında bu işlemleri mutlaka belgelendirin ve yetkili kişilerden onay alın.
Yaygın Protokol Analizleri İçin Hazır Filtreler
DNS sorunları için:
# Yavaş DNS yanıtlarını bul (100ms üzeri)
tshark -r capture.pcap -Y "dns && dns.time > 0.1" -T fields -e dns.qry.name -e dns.time
# NXDOMAIN (bulunamayan domain) yanıtları
tshark -r capture.pcap -Y "dns.flags.rcode == 3" -T fields -e dns.qry.name -e ip.srcDHCP sorunları için:
# DHCP discover/offer/request/ack döngüsünü izle
tshark -r capture.pcap -Y "bootp" -T fields -e frame.time -e bootp.type -e bootp.hw.mac_addr -e bootp.ip.yourSonuç
Wireshark ve tshark, Windows Server ortamlarında kaçınılmaz birer araç. GUI’yi üretim sunucusunda açmaktan çekiniyor olabilirsiniz; haklısınız. Ama tshark komut satırında son derece güçlü ve kaynak dostu çalışıyor. Ring buffer özelliğiyle sürekli bir yakalama ortamı kurduğunuzda, “keşke o anki trafiği kaydetseydim” pişmanlığı yaşamazsınız.
En önemli tavsiyem şu: Wireshark’ı sorun çıktığında değil, her şey yolundayken öğrenin. Normal trafiğin nasıl göründüğünü bilirseniz, anormal olanı çok daha hızlı tespit edersiniz. Bir üretim ortamında baz çizgi (baseline) pcap’leri düzenli olarak alın ve karşılaştırma imkânı yaratın.
Ağ sorunları bazen sizi günlerce sürükler. Doğru araç ve doğru filtrelerle, aynı sorun çoğu zaman birkaç dakikalık analiz meselesidir.