Türkçe
Lokal bilgisayar ya da Grup politikasının "Advanced Audit Policy Configuration" kısmında "Object Access" altında "Audit Filtering Platform Packet Drop" özelliğini denetim kaydı tutacak şekilde ayarladıysanız şayet bir süre sonra Güvenlik olay kayıt dosyanızın ( Security Event Log ) sizi çıldırma noktasına getiren 5152 Olay numaralı ( Event ID ) "Filtering Platform Packet Drop" kategorisindeki olaylarla dolup taştığını görürsünüz. Kimi zaman engellenen trafikle ilgili olay kaydı detayında verilen bilgiler yani hedef-kaynak IP adresleri,port numaraları engellenmemesi gereken bir iletişimin parçasıdır.Anlatmak istediğim konu için oluşturduğum test ortamının kahramanları şöyle;
10.10.10.1 : istemci
10.10.10.4 : sunucu ( Windows 2008 R2 Ent. Server)
Sunucu üzerinde SSH portu ya da servisi kullanımda değil ama ben güvenlik duvarı etkin sunucunun 22 numaralı portuna erişmeye çalıştığımda almam gereken RST bayraklı cevap paketi almıyorum,aslına bakarsanız sunucudan hiç bir cevap almıyorum.( Resim 1 )
Resim 1
Windows güvenlik duvarını ( Microsoftun deyimiyle Advanced Firewall ) kapadığımda ise ( Firewall Off ) sunucu kendisinden beklenen ve portun kullanımda olmadığını belirten RST bayraklı paketleri gönderiyor ( Resim 2). Bu davranış da port taramanın temelini oluşturuyor zaten.
Resim 2
Normal şartlar altında bir işletim sistemi port kapalıysa yani portu kullanan bir hizmet,servis,uygulama yoksa bu porta erişmeye çalışan istemciyi portun kullanımda olmadığını RST bayraklı paketle cevaplayarak bildirir.
Aklınıza belki erişimin Windows güvenlik duvarındaki kurallar yüzünden engellendiği gelebilir. Resim 1'deki ekran görüntüsünü Windows güvenlik duvarında erişim sağlamaya çalıştığım istemciden sunucuya doğru tüm portlara izin veren Resim 3'deki kuralı tanımladıktan sonra aldım.
Resim 3
Özetlemek gerekirse sunucunun güvenlik duvarı etkin, istemciden sunucuya doğru tüm portlardan erişime izin veren bir kural var ama yine de sunucunun hizmet vermediği yani kapalı diyebileceğimiz 22 numaralı porta erişmeye çalıştığımızda sunucudan RST cevabı almıyoruz, SYN bayraklı paketlerimiz biryerlerde kayboluyor.
Tam bu sırada sunucunun denetim politikalarını etkinleştirdiğimiz aklımıza geliyor ve Güvenlik Olay kayıtlarına baktığımızda paketlerimizin engellendiğini görüyoruz ( Resim 4 ).
Resim 4
İşte bu yazıda cevap bulacağınız soru bu, Windows güvenlik duvarı tüm portlardan erişim izni verdiğim halde neden paketlerimizi blokluyor,kendini ne sanıyor bu?
Bildiğimiz ya da bilmiyorsak öğreneceğimiz gibi Microsoft Windows Vista ile birlikte işletim sisteminin ağ iletişimi katmanında ya da yığınında ( TCP/IP Stack ) ve Windows Firewall'da ciddi değişiklikler yaptı deyim yerindeyse bu bileşenler yeniden yazıldı. İşte çok sevgili masum paketlerimizin habersizce ortadan kaybolmasının daha doğrusu Windows'un gazabına uğramasının nedeni de yapılan bu geliştirmeler. Laf kalabalığından ziyade komut ve ekran görüntüsü görmekten hoşlanan teknik insanlar olduğumuz için çok uzatmadan paketlerin akibetini,neden bloklandıklarını anlatmaya başlıyorum.
"Neden" sorusunun cevabını bulmada işimize yarayacak ipucu olay kaydı detayındaki "Filter Run-Time ID" değeri ( Resim 4) yani 71354 . Bu sayı paketimizin bloklanmasına neden olan hain filtrenin numarası, biraz delikanlı olsaydı ismiyle cismiyle çıkardı karşımıza. Filtrenin kimliğini bulmak için yapmamız gereken
netsh wfp show state
komutunu çalıştırmak. Komut yukardaki haliyle çalıştırıldığında Windows Filtering Platform ( WFP ) un kullandığı mevcut layerları,filtreleri varsayılan olarak komutu çalıştırdığınız dizinde "wfpstate.xml" isimli bir dosyaya aktarıyor. Komutun parametreleriyle dosya ismini ve/veya yerini değiştirebilirsiniz.
Resim 5
XML dosyasını herhangi bir uygulamayla açtıktan sonra yapmanız gereken "Filter Run-Time ID" numarasını dosyada aratmak olmalı ( Resim 6).
Resim 6
Resim 6'daki ekran görüntüsü biraz zor anlaşılabilir, kolay anlaşılan tek yanı bu filtrenin port taramayı engelliyici "Port Scanning Prevention Filter" olduğu. Filtrenin "Action" kısmında da paketimize neden RST bayraklı cevap almadığımız anlaşılıyor çünkü WFP henüz transport katmanında iken paketimizi atıyor. Nedeni ise basit, işletim sisteminin bu porttan trafik ya da iletişim isteği dinlememesi ( Resim 7).
Resim 7
Kısaca özetlemek gerekirse "Port Scanning Prevention Filter" filtresi, hernekadar güvenlik duvarındaki kurallar vasıtasıyla erişim izni verilmiş olsa da bu portta dinleyen/çalışan/hizmet veren bir uygulama olmadığı için "sen benim dinlemeyen portuma nasıl erişmek istersin?" deyip bize Port Scanner muamelesi yaparak paketimizi engelliyor,düşürüyor "SILENT_DROP" olduğu için üstüne üstlük bize de iletişimi kestiğini bildirmiyor bir RST bayraklı paket göndermeyi çok görüyor. Artık kafalarınızda oluşturduğum sorunun cevabını biliyorsunuz, mutlu olduğunuzu umuyorum.
Firewall Audit kayıtlarını açma taraftarı değilseniz, benzer şekilde bir trafiğin neden engellendiği ya da neden izin verildiği sorusunun cevabını, Windows Filtering Platform ( güvenlik duvarının daha cafcaflı ismi ) olaylarını inceleyerek bulabilirsiniz. Bunun için yapmanız gereken engellenen yada izin verilen trafiği oluşturmadan önce WFP olaylarını kaydetmeye başlamak.
netsh wfp capture start
komutuyla olayları kayıt altına almaya başlayabilirsiniz, kayıt işlemini uzun tutmamaya çalışın bu hem performansı düşürür hem de incelemeniz gereken dosya boyutunu şişirir. Komutu yukardaki haliyle çalıştırırsanız yine varsayılan "wfpdiag.cab" isimli bir arşiv dosyası elde edersiniz. Sizi ilgilendiren bu arşivin içindeki xml dosyasıdır. Eğer kayıtları arşiv dosyasına değil de ayrı ayrı almak isterseniz Resim 8'deki gibi bir komut kullanabilirsiniz.Kayıt ( capture ) işlemini sonlandırmak için
netsh wfp capture stop
komutu yeterli.
Resim 8
Windows Filtreleme Platformunda gerçekleşen olayları kayıt altına aldıktan sonra xml dosyasını açarak hedef, kaynak ip adresleri gibi kriterleri aratarak ne tip olaylar gerçekleştiğini en ince detayına kadar öğrenebilirsiniz. Örnek senaryomuzun oluşturduğu WFP olayları kaydedilen dosyaya göre şöyle; WFP önce güvenlik duvarı kuralından ötürü erişime izin veriyor ( Resim 9 )
Resim 9
Güvenlik duvarı kuralını geçen iletişim isteğimiz daha sonra "Port Scanning Prevention Filter" filtresine takılıyor ( Resim 10 ), 71354 ID'si bu filtreye aitti hatırlayın.
Resim 10
Artık siz de Windows 2008-Windows 2008 R2 sunucularınızda trafiğin ve/veya paketlerin neden engellendiğini en ince detayına kadar öğrenmenize yardımcı olacak ve bu blog dışında kolay kolay bulamayacağınız,edinemeyeceğiniz bilgiye sahipsiniz. Anlam veremediğiniz kısaltmaları Microsoft MSDN sayfalarından aratmayı unutmayın.
Gördüğünüz gibi Windows Advanced Firewall alışılageldik kural temelli ( rule-based) güvenlik duvarlarının kabiliyetlerine ek olarak , çeşitli filtrelerle packet-inspection, traffic-anomaly detection gibi özellikler de sunuyor. Bunlar küçümsenmeyecek özellikler. Bunun tek olumsuz yanı ise bu yazının da konusunu oluşturan filtreler üzerinde çok fazla düzenleme hakkınızın yetkinizin bulunmaması. Yine de Windows Advanced Firewall gayet başarılı, Xmas Scan-Null Scan-FIN Scan gibi port tarama yöntemleri tarihe karışabilir. Siz de Windows Advanced Firewall'u etkin bir işletim sistemine karşı boşu boşuna bu yöntemlerle port taraması yapmaya kalkmayın.Blogun bundan sonraki yazılarında belki diğer filtreler hakkında da yazarım,belki de yazmam.
İlgili Yazılarım
Yeni Nesil Bilgisayar Zararlilariyla Mucadelede Windows Firewall'dan Yararlanma - Nass oluyor da oluyor?
helal olsun teşekkürler...
YanıtlaSil