Windows Event Forwarding, Windows tabanlı sistemlerde yerel olarak desteklenen günlük merkezileştirme özellikleri sağlar. Microsoft, sunucular üzerindeki logların tek bir yerde toplanması WEF mimarisi ile sağlamaktadır. Elinizde milyonlarca log var ise, WEF ile bu logları yönetmek oldukça kolaylaşmaktadır. WEF, kuruluşunuzdaki, tüm işletimsel ve yönetimsel event logları okur ve seçtiğiniz eventleri bir WEC(Windows Event Collector) e iletir. Topladığı eventleri merkezi olarak saklayabilir. Herhangi bir ek yazılım kurulumu yapmadan kullanmanın yanı sıra WEF’i kullanmanın diğer avantajlarını ve özelliklerini şu şekilde sıralayabiliriz;
SIEM’e logu sadece almak yetmemektedir. Aynı zamanda doğru logları almak, doğru alarmları set etmek ve düzgün dashboardlar tasarlamak SIEM performansı açısından oldukça kritik bir öneme sahiptir. Endpoint kaynaklardan log almak ve SIEM’e gereksiz olan logları azaltarak aktarmak oldukça yorucu ve karmaşık bir iştir. Özellikle de SIEM ürününüzde storage alanının ne kadar önemli olduğunu anlatmaya gerek yoktur. Yapınızda bulunan çok fazla Windows Endpoint loglarını toplamak, filtrelendirmek ve yönetmek için WEF biçilmiş bir kaftan durumundadır. Üstelik Windows içerisinde yerleşik bir yapıda bulunduğu için ek bir yazılıma gerek duymadan çalışmaktadır.
Windows için tüm security loglarını almak yukarıda da bahsettiğimiz gibi hem SIEM storage alanını zorlar hem de doğru bir adım değildir. Üstelik Windows içerisinde sadece security logları olmadığı için işin içerisine Powershell, Advanced Audit Policy Configuration, Process Creation, File Audit logları girdiği zaman, log yönetimi oldukça zorlaşacaktır. WEF üzerinde gerçekleştirilebilen suppress etme özelliği ile bir nevi filter out işlemi de gerçekleştirilebilmektedir.
Öncelikle WEF i kurmak için bazı önkoşullar bulunmaktadır. Bu önkoşullar; sunucu ve GPO yapılandırmasıdır. WEF, client-server mantığıyla çalışmaktadır. Cilent sistemler, logların toplandığı sistemler, server ise logları topladığımız sistemlerdir. GPO ile yapılandırıldığı için bir Active Directory’e sahip olmamız gerekmektedir. Windows Event Forwarding, WS-Management standardını temel alır ve olayları bir Windows event collector’e iletmek için, Windows Uzaktan Yönetim (WinRM) servisini kullanır. Domainde bulunan tüm istemciler ile iletişim WinRM servisi gerçekleştirir. WEF’in özelliklerini saydığımız zaman, “push ve pull” modu ile çalıştığından söz etmiştik. Her iki modu açıklayarak konumuza devam edelim.
Pull modunda, log toplama işlemini kaynak yani WEF başlatmaktadır. Yani Server, her istemciye bağlanarak logları çekmektedir. Ancak toplayıcı tarafı yeni eventler olmasa bile tüm cihazlarla iletişim kurması gerektiğinden dolayı bu yöntem çok kullanışlı değildir ve performansı düşürmektedir. Push modunda ise, her aygıtın yalnızca toplayıcı değil GPO ile yapılandırılması gerekmektedir. Burada, client cihazlar loglarını WinRM servisi aracılığı ile http TCP 5985 ve https 5986 portuna göndermektedir. Bir nevi syslog connectorlerin 514 portunu dinlemesi gibi düşünülebilir. Bu modda eforu sarf eden istemciler olduğu için Server tarafında performans açısından bir düşüklük yaşanmayacaktır. Burada istemciler, WEF özelliklerinde de bahsettiğimiz gibi kerberos authentication ile WEF Server a register olmaktadırlar.
WEF mimarisini yukarıdaki şekildeki gibi düşünebiliriz. Şekilde bulunan diyagramda push moduna göre WEF’e iletilen logların yapılandırılması anlatılmaktadır. Aynı ağda bulunan kaynaklar, belirli bir porta (5985,5986) loglarını ileterek, WEF collectore aktarmaktadırlar.
Hangi logların aktarılacağını ve hangi sistemlerden alınacağını belirlemek için subscription(aboneler) oluşturulur. Subscriptionların oluşturulması ile bilgisayar hesaplarından gelen logları kabul etmiş olup, Security Filtering uygulayabiliriz.
Windows Event Forwarding, güvenlik alt yapısının önemli bir parçasıdır ve lokal olarak desteklenmektedir. Bir sistemde hiçbir event forwarding ayarlanmadığı zaman yöneticiler event viewer günlüklerinde neler olduğuna dair birçok önemli detayı kaçırabilmektedir. Yöneticiler, potansiyel sorunları, kalıpları ve daha fazlasını analiz etmek için olayları filtrelemeye çalışırken, hiç bitmeyen bir sistem günlükleri akışına ayak uydurmanın zorlukları ile karşı karşıya kalmaktadırlar. Bu nedenle WEF ile olay iletme kullanılarak bu tür sorunlara çözüm bulmuş olacaklardır.
WEF, Windows sistemlerinde yerleşik ve kullanıma hazır olarak geldiği için, 3rd. Party uygulamalara ihtiyaç duyulmadan, olayların iletilmesinde ve merkezi olarak kontrolün sağlanmasında daha güvenli bir limandır.
BT operasyonları ve endpoint yönetimi ekipleri, sorun giderme konusunda yardımcı olabilecek hataları ve diğer olayları toplayarak WEF’ten yararlanabilir.
WEF için birden fazla subscription oluşturulabileceği için, eventleri farklı günlüklere ayırabiliriz.
WEF Server da toplanan loglar, Splunk, Arcsight gibi SIEM çözümlerine iletilerek, Windows eventleriyle ilgili gerekli korelasyonlar yapılabilir.
WEF, birçok ortamda kullanışlı bir araçtır. Bir veya daha fazla etki alanı içeren ağırlıklı olarak Windows tabanlı bir mimariyle çalışıyorsanız, eventleri merkezileştirmek için etkili bir yöntemdir.
Yalnızca Windows olaylarını analiz etmek istiyorsanız WEF oldukça kullanışlı yöntemdir. Splunk Forwarder ise son derece yapılandırılabilir ve ölçeklenebilir bir makine veri ileticisidir. Yani, Splunk Forwarder ile, düz dosya, Windows olayları, kayıt defteri, PowerShell dahil olmak üzere her türlü makine verisini toplayabilir ve ilgili yerlere iletebilir.
Peki her ikisi ne yapabilir?
Hem WEF hem de Splunk Forwarder’ın ortak özellikleri;
gibi ortak özellikleri bulunmaktadır.
Her ikisi de oldukça kullanışlıdır. Splunk Forwarder ile, verilerin ağ üzerinden gönderilme hızını ayarlayabiliriz. Verilerin Splunk’a iletildiği saniye başına kilobayt değerini belirleyebilmemizi sağlar. Splunk Forwarder, WEF’e göre birkaç adımda daha çok öne çıkmaktadır.
Özelleştirme: Kaynakları, ana bilgisayar adına, IP’ye ve işletim sistemlerine göre kolayca gruplandırabilirsiniz. WEF’te ise bu işlemler için ayrı ayrı GPO’lar uygulanmalıdır.
Granulailty: Eventleri hem WEF’te hem de Splunk Forwarder’da filtreleyebilmekteyiz. Splunk Forwarder kullanarak, beyaz liste, kara liste veya normal ifade kullanarak olaylara filtre uygulayabiliriz.
Gerçek Zamanlı: Bir diğer farklı ve ayırt edici özelliklerden birisi de, tarihi ve gerçek zamanlı eventler toplamak istediğimizde WEF kullanarak yalnızca event forwarding subscription başlatıldığı andan itibaren olaylar yönlendirilmeye başlanacaktır. Splunk Forwarder da ise ana bilgisayarda var olan tüm günlükleri toplayabilme özelliğine sahiptir.
Yukarıda görünen tasarım, küçük ve orta büyüklükte kullanım için örnek bir yapılandırma sağlar. Tek bir event collector’e bağlanan 100.000’e kadar kaynak bilgisayarı destekler.
Bu yapıda, event collectorlerin ölçeklenebilirlik özelliklerinden dolayı, sınırsız sayıda kaynak bilgisayarı barındırmak için kullanılmaktadır. WAN ve ağ segmentasyonunu barındırır. Bu yapının eksi yönlerinden birisi, WAN için güvenlik duvarı yapılandırması gerekmektedir.
WEF Mimarisi ve Yapılandırılması
Windows Event Forwarding ile verilen bilgileri daha iyi anlayabilmek için kendi lab ortamımızda bir WEF yapısı oluşturabiliriz. WEF çalışma mantığı olarak client-server sistemi ile çalışmaktadır. Lab ortamını oluştururken de bu şekilde yapılandırabiliriz. İhtiyacımız olan bir sunucu, client cihazı ve GPO yapılandırmasıdır. Microsoft Exchange, Domain Controller veya Endpoint sistemlerinde üreyen tüm logları WEF vasıtası ile WEF Server’a iletiriz. Yapacağımız lab uygulamasında, DC cihazını WEF Server olarak belirleyip, client cihazın loglarını WEF yöntemi ile okumasını gerçekleştireceğiz.
WEF yapısında iki mod kullanarak logların toplanabildiğini belirtmiştik. Uygulama da “Computer initiated” yöntemi kullanarak, client cihazının loglarını 5985 portuna bırakıp WEF Server a iletmesini sağlayacağız.
Öncelikle, Active Directory yapısında , Organizational Unit oluşturup, client cihazlarını OU’ya assign ederek GPO oluşturmak faydalı olmaktadır. Birden fazla client olduğu durumlarda OU mutlaka kullanılmalıdır.
“TEST” adında OU oluşturup, içerisine “Computer” ve “Group” adında iki OU eklenir. Computer grubunun içerisine, client cihazı eklenmelidir.
Wef sunucusunda, Windows Powershell’i admin mod ile açarak WinRM servisini “winrm qc” ile aktif hale getirilir. Log toplaması için gerekli “Event Log Collector” servisi “wecutil qc” komutu ile ayağa kaldırılır. Bu işlemi Windows servisler bölümünden de gerçekleştirebilirsiniz.
WEF Clientlar TCP 5985 ve 5986 portu üzerinden loglarını bize gönderecekleri için, bu iki portu dinlememiz gerekmektedir. “winrm enumerate winrm/config/listener” komutu ile listenerları açabiliriz. Bu portlar üzerinden kerberos authentication kullanarak loglarını WEF sunucularına aktaracaklardır. Portların açık olup olmadığını “netstat -an | grep “598” komutu ile kontrol edebilirsiniz.
GPO Tanımlanması
WinRM servisi konfigürasyonları tamamlandıktan sonra, oluşturduğumuz OU yapısına Group Policy Management konsolu içerisinden yeni bir group policy basmamız gerekmektedir.
“TEST” içerisine sağ tıklayarak “Create a New Group Policy” seçeneğiyle birlikte “WEF Client” adında bir Group Policy oluşturulur.
WinRM servisini otomatik olarak çalışmasını istediğimiz için, WEF Client GPO’su içerisinden, oklarla işaretli alanlar takip edilerek gerekli düzenlemeler yapılıp kaydedilir.
En kritik bölüm, logların yönlendirilmesi için “subscription manager” oluşturulmasıdır. Yine WEF Client GPO su seçilip edit ile düzenlenerek, Computer Configuration > Administrative Templates > Windows Components > Event Forwarding seçilir. Burada, Subcription manager konfigürasyonu “enabled” durumuna getirilir ve content içerisine “Server=http://test.WEF.local:5985/wsman/SubscriptionManager/WEC” bilgisi eklenmelidir. Burada http:// ifadesinden sonra yer alan “test”, sunucunun fqdn bilgisidir.
Oluşturulan GPO, loglarını toplayacağımız log kaynaklarının bulunduğu OU’ya linklenir. Değişikliklerin sağlanması için cmd konsol ekranı üzerinden “gpupdate /force” yapabileceğimiz gibi, OU içerisinde yer alan “Computer” grubuna sağ tıklayarak “Group Policy Update” edilebilir.
WEF sunucusu üzerinden olay kayıtlarını yönlendirebilmek için, subscription tanımlaması yapmamız gerekmektedir. Bu işlem, Event Viewer içerisinden Subscription alanından “Create Subscription” dan yapılır. Bu sayede, log kaynaklarından gelen kayıtların yönlendirilmesi sağlanabilir.
WEF in özelliklerinden birisinin de filtreleme yapmak olduğunu belirtmiştik. WEF sunucusu üzerinde security filtering, application filtering gibi işlemler burada gerçekleşmektedir. Subscription oluşturduktan sonra bir isim verilir. Client cihazların loglarını 5985 portuna bırakacağı için “source computer initiated” seçeneği seçilir ve burada hangi kaynaklardan logların alınacağı “select computer groups” içerisinden ayarlayabiliriz.
OU içerisinde bulunan “Group” u seçerek, logların alınacağı kaynaklar seçilir.
SIEM e gönderilecek loglarda, her olay kaydının alınması yerine ihtiyaç duyulan kayıtların filtrelenerek alınması, SIEM sisteminin performansı açısından tercih edilen bir yöntemdir. İlgili alana, alınması gereken kritik loglar yazılarak filtreleme yapılır.
Ağ kaynak kullanımını en iyi şekilde gerçekleştirmek için “Minimize Latency” seçeneği seçilir ve adımlar tamamlanır.
Subscription oluşturduktan sonra aktif edebilmek için “wecutil gr “subscriptionID” ve “wecutil gs “subscriptionID” komutları cmd konsolu üzerinden koşulur. Görüldüğü gibi yapılan filtreleme işlemleri, Query şeklinde konsol ekranında gösterilmektedir.
Group Policy Management alanına gidip, TEST OU içerisinde tekrar “group policy update” diyerek GPO’yu alması sağlanmalıdır. Görüldüğü WIN-Client cihazı başarılı bir şekilde register olmuştur.
WEF Server içerisinde Event Viewer alanında Forwarder Events bölümünü görüntülediğimiz zaman, Client loglarının “forwarder events” bölümünde listelendiği görülmektedir. Aynı zamanda gelen loglar, filtrelenmiş bir şekilde listelenmektedir.
Kurumlarda lab uygulamasında yapıldığı gibi tek bir cihaz için WEF kurulumu gerçekleştirilmez. WEF için geniş yapılar daha kullanışlıdır. Örneğin 100 client barındıran bir kurumda Windows Exchange, Domain Controller, SQL Server ve bazı Endpoint ürünleri gibi, sistemlerden üreyen logların toplanması işlemi oldukça zahmetli ve performans açısından da efektif olmamaktadır. Burada WEF ile operasyonel olarak mükemmel basitlikten söz edilebilir. ArcSight Native SmartConnector kurup, logları toplanacak sistemleri tek tek girmek yerine, tüm sistemlerden logları toplayan bir WEF Server kurulumu yapılıp bu wef server içerisinden loglar smartconnectorler ile okunabilir.
WEF Sınırlılıkları
Bu yazının son bölümünde, WEF’in sınırlılıklarından bahsedeceğim. WEF’in inanılmaz basitlik sağlarken, aynı zamanda bir takım sınırlılıkları da mevcuttur. Kuruluşunuz için bir WEF dağıtımını değerlendirirken bu sınırlamalar dikkate alınmalıdır.
Veri keşfi konusu 7 Nisan 2016 tarihinde yürürlüğe giren 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) ile hayatımıza girdi. Bu kanunla beraber bu zamana kadar dağınık olan verilerimizin nerede tutulduğunun ve ne derece kritik olduğunun önemi giderek artmaktadır.
Happy Place to Work tarafından gerçekleştirilen uluslararası standartlara uygun değerlendirme sonrası sektöründe “En Mutlu İşyeri” seçilmiş olmamız başarımızı taçlandıran bir ödül oldu. Ofisimizde düzenlediğimiz bir etkinlik ile ödülümüzü alırken, değerlendirmeye katılan ve bizi bu ödüle layık gören ekip arkadaşlarımızla kutlama yaptık.
SIEM ürünlerinin en önemli özelliği korelasyon yapabilmesidir. ESM de correlation engine sayesinde verileri işler ve korelasyon yapabilme yeteneği kazanır.
Full Stabil yapılardan söz etmek mümkün mü? Dosya içeriği değişmiyor belki ama dosya sistemi, formatı ihtiyaçlarla paralel olarak değişebiliyor. Neden bu konuya girdim peki? Çünkü alışkın olduğumuz FAT32 ya da NTFS dosya sistemlerinin yanında artık sıklıkla duyulmaya başlanan ReFS dosya sistemi de yerini almaya başladı.
