F5 LTM ile iAPP Template Kullanımı

F5 üzerinde bir yeni bir servis devreye almak istediğinizde aşağıdaki tabloda göreceğiniz tanımları tek tek yapmak çok fazla zamanınızı alabilir ve bununla beraber gözden kaçırabileceğiniz şeyler olabilir. F5 iApp template’ ler sayesinde bu işlemleri çok daha kısa bir sürede tek bir arayüzden hatasız bir şekilde hızlıca yapabilirsiniz.

F5 ekosisteminiz üzerinde virtual server’lara isim verip diğer gerekli olan tanımları tek tek yapmaktan hoşlanıyorsanız iApps size uygun olmayabilir 😊

iApp Yapısı

• Application bölümü TCL tabanlı tmsh kodlama dili ile yazılmıştır. Tmsh ile yapılabilecek her şey bir iApps şablonu ile yapılabilir.
• Presentation bölümü APL veya Application Presentation Language ile yazılmıştır, iApp şablonu için user interface’i oluşturur

İApps Kullanım Faydaları

• Özelleştirilebilir olması
• Konfigürasyonların editlenebilir olması
• Yeniden kullanabilme özelliği
• Gerekli her şeyi template üzerinden tanımlayabilme özelliği
• Yapılacak herhangi bir değişikliğe karşı koruma sağlayabilme özelliği ”editlemeyi kapatabilme” (bu özelliği dilerseniz devre dışı bırakabiliyorsunuz)
• Kopyalama, export ve import edebilme özelliği
• Manuel tanımlama esnasında bir hata yaptığınızda onlarca tanımı tekrar gözden geçirme durumunda kalmak yerine template sayesinde tek bir arayüzde tüm tanımların görülebilmesi ile daha hızlı problem çözümü imkanı

Download ve Import için: https://support.f5.com/csp/article/K98001873 linki üzerinden güncel template’ i download ederek nasıl import edebileceğinizi inceleyebilirsiniz.

iApp Yeni Servis Tanımlama:

Aşağıdaki link üzerinden  bir http application’ ın iApp ile nasıl tanımlanıp devreye alınabileceğini inceleyebilir, bununla beraber “oneconnect nedir, persistence nedir veya SSL Bridge, pass-through nedir, gibi”  kısa açıklamalar da bulabilirsiniz.

https://www.f5.com/content/dam/f5/corp/global/pdf/deployment-guides/iapp-http-dg.pdf

Download etmiş olduğunuz dosyasının içerisinde “iapps-1.0.0.562.0.zip” bir çok üreticiye ait templateler bulunmaktadır, kullanmak istediğiniz template’ i import edip yeni servislerinizi devreye almaya başlayabilirsiniz.

20’ den fazla iApp şablonu bulabilirsiniz, devcentral üzerinden de “https://devcentral.f5.com/” yayınlanmış olan harici template’ leri de download ederek kullanabilirsiniz.

Örnek :

Aşağıdaki örnekte tek sayfada hızlıca bir web servisi devreye alma aşamasını görebilirsiniz. Advance olarak ilerlemek isterseniz Basic seçeneğiini “aşağıdaki tablonun ilk aşamasında görebilirsiniz” Advance olarak değiştirebilirsiniz. Bu sayede daha detaylı tanımlama yapabilirsiniz.

Finished dedikten sonra hazırlamış olduğu component aşağıdaki gibi görünecektir. Tüm işlemleri sadece birkaç dakikada gerçekleştirebiliyorsunuz. Tanımla sonrası bir hata gözlemlerseniz aynı ekranda Reconfigure menüsünden tekrar düzenleme yapabilirsiniz.

Öneriler

• iApp template ile devreye aldığınız bir servis için manuel olarak düzenleme yapmanız gerektiğinde “örneğin bir profile özelinde değişiklik yapmak istediğinizde” strict updates kutucuğunu boş bırakmalısınız, sonrasında işlemlerinizi yapabilirsiniz. Önemli diğer bir konu ise, iApp template Reconfigure, manuel yapılan tüm değişiklikleri ezmektedir, Dolayısı ile yapmak istediğiniz değişikliği manuel yapmak yerine (reconfigure kısmında göremiyorsanız manuel değişiklik yapabilirsiniz) iApp Reconfigure ile gerçekleştirmenizi öneririz.

• Bir diğer konu ise template kullanmadan önce sertifikanızın import edilmesi. SSL ofload veya Bridge yapmak istediğinizde size hangi sertifikayı kullanmak istediğinizi soracaktır, sertifika template üzerinden import edilemediği için işlemlerinizi baştan yapmak durumunda kalabilirsiniz.

• Eğer F5’ in redirection yapmasını istiyorsanız, sunucu tarafında redirection olmadığından emin olmalısınız aksi halde erişimlerde problem yaşayabilirsiniz.

• Eğer client IP’ sini görebilmek için X-Forwarded for özelliğini aktif ettiyseniz, client tarafında da yapılması gereken işlemler olacaktır. Aşağıdaki linki inceleyebilirsiniz.

https://support.f5.com/csp/article/K4816

• iApp template default profile’ ları kullanarak yeni servis adına ayrı profiller yaratıyor, örneğin, cookie veya Persistence Encryption yapmak isterseniz manuel olarak ilgili web servis profile ayarlarında düzenleme yapmalısınız. Tanım için aşağıdaki linki inceleyebilirsiniz.

https://support.f5.com/csp/article/K14784

• Monitoring tanımlama aşamasında Uygulama sahibi ile birlikte tanımlamaları yapmanızı öneririz. Sunucuların monitor edilmesi aşaması için aşağıdaki linki inceleyebilirsiniz.

https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-monitors-reference-11-6-0/2.html

Kaynaklar

https://devcentral.f5.com/s/articles/getting-started-with-iapps-a-conceptual-overview-20524

https://www.f5.com/content/dam/f5/corp/global/pdf/deployment-guides/iapp-http-dg.pdf

Yüksel Karapınar

SIEM Projelerinde WEF’in Faydaları ve WEF Konfigürasyonu

WEF Nedir ?

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;

• Eventler, varsayılan olarak Kerberos ile şifrelenir.
• Wef, kaynaklardan önemli eventleri toplayıp daha sonra SIEM’e iletmek üzere ayarlanabilir.
• Eventleri basit bir şekilde filtreleyebilir.
• GPO ile yapılandırılır.
• Push ve pull modu ile çalıştırılır.
• Bant genişliği kontrolü gerçekleştirebilir.
• Domaine katıldıktan sonra, yeni kurulan makineler otomatik olarak WEF altyapısına kaydedilebilir.
• WEF, yalnızca Windows sistemlerinde çalışır. WEF üzerinden Windows tabanlı olmayan bir sunucuya iletmek pek mümkün değildir. Ancak bazı third party uygulamalar ile Linux platformlarında da ayarlamalar yapılabilmektedir.

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.

WEF’i SIEM Ürünleriyle Kullanmanın Avantajları

• WEF merkezi olarak yönetilebilme özelliğine sahiptir.
• WEF logların bir push veya pull mekanizmasıyla bir veya daha fazla merkezi WEC (Windows Event Collector) sunucusuna gönderilmesine izin verir.
• WEF logları toplamak ve daha sonra SIEM’e iletmek üzere ücretsiz olarak ayarlanabilir.
• Native .evtx log formatını kullanır.
• WEF filtreleme olaylarına izin verir. Bu sayede SIEM ürününüze kritik olmayan olayları göndermekten kaçınabilirsiniz.
• SIEM ürününüz WEF yapısında bulunan tüm makinalara connection açmak yerine, tek bir makinadan tüm sistemin loglarını toplayabilir. Bu sayede de fazla kaynak kullanımının önüne geçilmiş olur.

WEF Nasıl Çalışır?

Ö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.

WEF’e Neden İhtiyaç Duyulur?

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.

WEF vs. Splunk Forwarder

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;

• Windows olaylarını iletme,
• Şifreli bir kanal üzerinden veri gönderme (WEF için kerberos),
• Event filter yapabilme,
• Bant genişliği kontrolü sağlayabilme,

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.

Kuruluşlarda WEF Yapısı Senaryoları

1. Temel Event Yapılanması

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.

• Ölçekli Event Collector Yapılanması

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.

• WEF ile logları aldıktan sonra loadbalancer oldukça zorlaşır. Kerberos kullanırken, iletilen olayları birden çok düğüm arasında etkin bir şekilde dengelemek imkansız değilse de zordur.
• Aktif tanı ve sorun giderme sınırlıdır. Yani WEF başarısız olduğunda, nedenini teşhis etmek genellikle zordur.
• WEF sadece Windows cihazları ile yapılabilmektedir. Third Party uygulamalar ile bu sorun aşılabilirken, güvenlik sorunları da bununla beraber ortaya çıkabilir.

KAYNAKLAR

https://docs.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection

https://www.lepide.com/blog/understanding-windows-event-forwarding/

https://nxlog.co/windows-event-forwarding

https://hackernoon.com/the-windows-event-forwarding-survival-guide-2010db7a68c4

https://h41382.www4.hpe.com/gfs-shared/downloads-223.pdf

Cem Üstün

SPLUNK İLE UZAK ERİŞİM DASHBOARD’LARI OLUŞTURMA

Günümüzde tüm network cihazlarının, sunucuların, database ve firewall yapılarının loglarını takip etmek üzere log management yazılımları kullanılmaktadır. Bu ürünlerin bizlere sağladığı opsiyonlar değişmekle birlikte, çeşitlilik her geçen gün ivmeli bir biçimde artıyor. Log management ürünleri, yapılarına; mevcut ihtiyaçlar doğrultusunda çeşitli ilaveler yaparak, kullanışlılık paralelinde eş zamanlı takip konularını etüt etmeye devam ediyor. Örnek olarak son günlerde Splunk tarafından sağlanan uzak çalışma alanlarının takibi ile ilgili uygulamalardan birçoğumuz haberdarız. Bu çalışmaları inceleyerek geliştirmek ve kendi yapımıza entegre edebilmek için çeşitli değişiklikler yapmak üzere biraz zaman ayırabildiğimizde oldukça kullanışlı dashboardlar elde edebildiğimizi görebiliriz. Bu yazımda Splunk ürünü ve log takibi için sağlamış olduğu Appler bünyesinde yer alan Dashboard yapılarına ve Dashboard konfigürasyonlarına değineceğim.

Öncelikle Splunk yapısında yer alan kaynak bazlı applerden bahsederek giriş yapmakta fayda var. Akabinde bu appler ile hazır olarak elde edilen Dashboardlar bizlere neler sağlıyor ve sağladığımız faydayı optimize etmek adına neler yapabiliriz sorularına cevaplar arayacağız. Keyifli okumalar dilerim.

Splunk Apps

Splunk App yapısı, Splunk platformunda çalışmak üzere geliştirilen; farklı kaynak ve objelerden beslenerek, kullanıcı için çeşitli arayüzler, dashboardlar, hazır rapor ve saved searchler içeren uygulamalar bütünü olarak düşünülebilir. Özetle Splunk Appleri her yapı ve kişilerin değişken ihtiyaçları doğrultusunda, veri kaynaklarının analizini kolaylaştırmak için son kullanıcılara hazırlanmış hazır paketlerdir. Bu Appleri yapıya dahil etmek için ise aşağıda görülen “App Management” sekmesinden ilgili App dosyasını upload etmek yeterli olmaktadır. Akabinde ekstra konfigürasyonlar gerçekleştirilmek istenildiğinde yine Web UI ya da server üzerinde ilgili pathlerde yer alan config dosyaları editlenerek işlem gerçekleştirilebilmektedir.

Splunk Applerine https://splunkbase.splunk.com/ sitesi üzerinden erişim sağlanabilemektedir.

Yüzlerce App arasında, Dashboard yapılarını incelenebilmesi için herhangi bir ücrestiz App Splunk Enterprise ya da Splunk Cloud ortamına import edilerek etüt edilebilir. Dashboard yapılarını incelemek üzere son günlerde ilgi odağı haline gelmiş olan uzak çalışma alanlarının takibini kolaylaştırmak üzere oluşturulmuş “Remote Work Insight” ya da “Zoom App for Splunk” Appleri kullanılabilir. Bu iki App Splunk tarafından sağlanan ve Zoom Meeting, Office 365, Okta, VPN loglarına dair çeşitli Dashboardlar içermektedir.

Remote Work Insight App

Remote Work Insight App’i bünyesinde 4 ana Dashboard ile kullanıcılara uzak çalışma ortamının yönetimi ve takibi için kolaylık sağlaması amacıyla hazırlanmış bir pakettir. Söz konusu App farklı kaynaklardan gelen loglarla işlendiği için, bu kaynaklara ait product App ve Add-on ların da yapıya dahil edilmesi ile sourcetype ların doğru şekilde match edilebildiği teyit edilmelidir. Örnek olarak “Microsoft 365 App for Splunk”,  “Splunk Connect for Zoom” gösterilebilir. Ancak belli kaynak tiplerini baz alan Dashboardları kendi yapımıza entegre edebilmek için App üzerinde küçük değişiklikler yapmak gerekmektedir. App içeriğinde yer alan Dashboard ve panellere göz atıldığında tabloda yer alan başlıklar görülmektedir.

Yukarıda belirtilen Dashboard ve Paneller arka planda çalışan realtime searchler ile beslenerek dinamik bilgileri değişken görseller eşliğinde sunmaktadır. Dashboardları besleyen searchler datamodel ya da basic search stringleri ile konfigure edilebilmektedir. Söz konusu searchler için time range isteğe bağlı olarak realtime ya da belli bir zaman periyodunu baz alacak biçimde ayarlanabilmektedir. Bu sayede hem gerçek zamanlı olarak uzak çalışma alanlarına ait metrikler takip edilebilmekte, hem de belli bir zaman aralığı içerisindeki aktivite eğilimleri analiz edilebilmektedir.

Dashboardlar tüm kullanıcıların erişime açık biçimde konfigure edilebildiği gibi, çeşitli iş kolları arasındaki tasnife bağlı olarak erişim izinleri değiştirilebilmektedir. Appler ile gelen hazır Dashboardlar üzerinde konfigürasyon değişiklikleri yapılabildiği gibi, mevcut Applere ihtiyaçlar doğrultusunda sıfırdan konfigure edilen yeni dashboardlar da eklenebilmektedir.

Splunk App for Zoom

Uzak çalışma alanlarının yaygınlaşması ile değişen takip alanları çerçevesinde bir diğer App olarak “Splunk App for Zoom” ele alınabilir.  Söz konusu App aynı zamanda rwi bünyesinde yer alan “Video Conferencing” Dashboardlarını beslemesi açısından gerekli bir App olarak karşımıza çıkar. Splunk App for Zoom bünyesinde yer alan aşağıdaki başlıkları takip etme olanağı sağlanmaktadır.

Zoom uygulamasına ait aktivite loglarını eş zamanlı ve geçmişe dönük görselleştirmeyi sağlayan App arka planda uygulamaya ait logları bir diğer App olan “Connect for Zoom” ile sağlamaktadır. Görüldüğü gibi Appler arasında operasyonel bağlar bulunmaktadır. Bir App içerisinde yer alan Dashboardlar arka planda başka bir App ile log alımı sağlanan kaynaklardan beslenebilmektedir.  

“Splunk App for Zoom” için tanımlı zoom hesabı üzerinde çeşitli konfigürasyonlar yapılarak, “Connect for Zoom” Appi sayesinde uygulamaya ait loglar Splunk bünyesine aktarılabilmektedir. Cloud’dan alınan loglar sayesinde “Active Meetings”, “Number of Zoom Participants” ve birçok diğer Panel görsel takip olanağı sağlamaktadır.

CheckPoint VPN Dashboard

Splunk tarafından sağlanan “Remote Work Insight” ve “Splunk App for Zoom” Applerine genel bakış akabinde Applerde yer alan Dashboardlar üzerinde nasıl değişiklikler yapılabilir, ya da sıfırdan bir Dashboard nasıl oluşturulabilir konuları mercek altına alınabilir. Bu konuları dikte etmek adına örnek bir kaynak belirlemek, çalışma hatlarını netleştirmek için faydalı olacaktır. Örnek olarak CheckPoint ürününe ait Mobile Access logları aracılığı ile kullanıcıların VPN aktivitelerine focus olarak log almaya ve akabinde Dashboard oluşturmaya çalışabiliriz. 

CheckPoint tarafından gönderilen syslog 514 UDP paketlerinin Splunk bünyesine doğru sourcetype tanımlamaları ile alınabilmesi için öncellikle CheckPoint ürün App’inin sisteme import edilmesi gerekmektir. “Check Point App for Splunk” App’inin eklenmesinin akabinde yeni sourcetype olan “cp_log” tanımlaması otomatik olarak gelmektedir. Bu işlemden sonra “Data Input” bölümünden syslog input tanımlamaları aşağıdaki biçimde gerçekleştirilir.

Checkpoint loglarının Splunk ortamına aktarımı için gerekli konfigürasyonlar tamamlandıktan sonra rwi App’ine ilave Dashboard tanımlaması yapmak üzere ilgili App seçilerek devam edilir. Yeni bir Dashboard oluşturmak için aşağıda görülen “Others” sekmesinden Dashboard bölümüne gidilerek “New Dashboard” opsiyonu seçilir.

Dashboard için Title, ID ve Description; birden fazla Dashboard olduğu düşünülerek içeriğe uygun olarak set edilmelidir.

Örnek olarak Successful VPN Login aktivitlerini gösteren bir Panel oluşturulur. Bu işlem için kullanılacak olan search stringi Search ekranında test edilebilmektedir.

|stats komutu nedeniyle sonuçlar istatistik verileri şeklinde listelenmektedir. Bu veriler Visualization bölümünde seçilebilen opsiyonlar eşliğinde farklı biçimlerde görsel tablolara dönüştürülebilmektedir.

Search stringi “Search & Reporting” bölümünde test edildikten sonra tekrar ilgili App’e gidilerek yeni oluşturulmuş olan “CheckPoint VPN Activities” Dashboard’una Panel ekleme işlemine geçilir. Bu bölümde Dashboard Paneli için Title, time range ve search string tanımlamaları yapılarak “Add to Dashboard” seçilerek devam edilir.

Set edilmiş olan search seçilmiş olan zaman aralığı için arka planda çalışarak, seçilen Visualization biçiminde Dashboard üzerinde konumlanır.

Mevcut Dashboard üzerinde değişiklik yapmak istediğimizde sağ üstte yer alan “Edit” butonu seçilebilir. Bu kısımda mevcut Panel’e input ekleyebilme, mevcut panel görselini değiştirme, renkleri editleme, zaman aralığını ve search stringini değiştirme gibi birçok opsiyon yer almaktadır.

Örnek olarak Dashboard üzerinde “time range picker” butonu yer alması için “Data Input” alanında Time bölümü seçilir ve Dashboard üzerine belirlenen default değeri ile “time” butonu input olarak eklenebilir.

Örnek olarak “Select visualization” bölümünde başlangıçta Area Chart şeklinde oluşturulan Panel, Pie Chart, Bar Chart, Line Chart olarak değiştirilebilir.

Ek olarak Dashboardlarda kullanılan görsel konfigürasyonlar “Edit Dashboard > Source” alanından igili XML’e gidilerek burda gerçekleştirilen değişiklikler ile de sağlanabilir.

Örnek olarak, Pie Chart üzerinde renk değişikliği yapılmak istendiğinde “<option name=”charting.seriesColors”>[#7CFC00]</option>” bölümünü editlenebilmektedir.

Splunk üzerinde Default olarak gelen visualization methodları aşağıda görüldüğü gibidir. İlave opsiyonlar kullanabilmek için farklı Visualization App’leri kullanmak gerekebilir.

Örnek olarak Timeline opsiyonunu kullanabilmek için ilgili App’i splunkbase sitesinden temin ederek Splunk App bölümüne upload edebilmekteyiz. Diğer dashboardlarda kullanmak üzere ilave olarak “Sankey-Diagrams” ve “Semicircle donut” Applerini de indirerek yapıya dahil edebiliriz.

Örnek olarak timeline visualization kullanılarak hazırlanmış bir Panel örneği aşağıda görüldüğü şekildedir. Bu sayede kullanıcı ve tarih bazlı belirlenen zaman aralığındaki VPN login-logout eventleri görülebilmektedir.  

Kullanıcıların Login/Logout eventleri, VPN süreleri önemli olduğu gibi hangi lokasyonlardan VPN girişi yaptıklarını da gerçek zamanlı kontrol etmek istenebilir. Bu doğrultuda “iplocation” komutunun kullanılması gerekmektedir.

Bu işlevin enable hale gelmesi ve doğru verileri sağlaması için güncel olarak  http://dev.maxmind.com/geoip/geoip2/geolite2/ adresinden GeoLite2-City.mmdb kütüphanesinin temin edilerek Splunk sunucusu üzerinde $SPLUNK_HOME/share/ pathine import edilmesi gerekmektedir. Bu işlem gerçekleştirildikten sonra “|iplocation” komutu ile loglar içinde yer alan konum bilgilerine de erişim sağlanabilmektedir.

İlgili kütüphanenin indirilerek yapıya dahil edilmesi akabinde “VPN Login by City”, “VPN Login by Country” başlıklı Dashboard Panelleri de oluşturulabilir.  

Tüm bu konfigürasyonlar eşliğinde değişen ihtiyaçlarla paralel olarak Dashboard yapılarını değiştirebilmekte ve kendi Dashboardlarımızı oluşturabilmekteyiz. Son olarak “CheckPoint VPN Activities” ismiyle oluşturduğumuz Dashboardumuzda yer alan Panel başlıklarına göz atabiliriz.

Kaynaklar:

https://www.splunk.com/en_us/solutions/covid19-response-overview/remote-work-insights.html

http://dev.maxmind.com/geoip/geoip2/geolite2/

https://splunkbase.splunk.com/app/3120/

https://splunkbase.splunk.com/app/4378/

https://splunkbase.splunk.com/app/3112/

Eda Kaz

ARCSIGHT FLEXCONNECTOR VE PARSER YAZIMI

ArcSight FlexConnector Nedir?

FlexConnector ArcSight ürün ailesi içerisinde bulunan bir SmartConnector çeşididir. ArcSight ürün ailesinde tanımlı olarak gelen kaynaklar dışında bir kaynaktan log alınması gerektiği durumlarda FlexConnector kullanılmaktadır. FlexConnector sayesinde ArcSight tarafında desteği olmayan özel kaynaklardan log alımı Parser yazımı ile sağlanabilmektedir.

Parser nedir?

Genel anlamda Parser, gelen verinin parçalara ayrılıp bu ayrılmış parçaların anlamlandırılmasını sağlayan bir çeşit scripttir. ArcSight SmartConnector içerisinde desteği verilen ürünlerin parserları gömülü bir şekilde gelmektedir. Desteği verilmeyen log kaynaklarına Parser yazımı sağlayarak özel bir şekilde logları yorumlayabiliriz. Parser sayesinde log içerisinde ayrımı yapılan alanları ArcSight içerisindeki alanlara tanımlayarak okunurluğu arttırabiliriz.

ArcSight içerisinde parserları 3 ana başlığa ayırılabiliriz;

Regex: Regex ile loglardan alanları ayırarak kullandığımız parser.

Delimeter: Log içerisinde alan ayrımını sağlayan bir özel karakter (“;” “,” “:” gibi) kullanılan parser.

Database: Database tablosundaki alan adlarını kullanarak ayrım yaptığımız parser.

Şeklinde özetleyebiliriz.

Bu yazıda size elimizde bir text dosyasına log yazan bir uygulama olduğu bir senaryo için

FlexConnector kurulumunu Regex parser yazımını demo ile göstereceğim.

Demo içerisinde elimizde IBM ACE ürününe ait ArcSight tarafından henüz destek verilmeyen log kaynağından log alımın ve Logger üzerinde görüntülenmesini sağlanacaktır.

Log örneği dosyaya şu şekilde yazılmaktadır;

2020-03-25 03:48:41,229 INFO  [test] <HTTPInputHeader Host=”localhost:7080″ User-Agent=”Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0″ Accept=”text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8″ Accept-Language=”en-US,en;q=0.5″ Accept-Encoding=”gzip, deflate” Connection=”keep-alive” Upgrade-Insecure-Requests=”1″ X-Original-HTTP-Command=”GET http://localhost:7080/xxxxx HTTP/1.1″ X-Server-Name=”localhost” X-Server-Port=”7080″ X-Remote-Addr=”127.0.0.1″ X-Remote-Host=”localhost” X-Scheme=”http”></HTTPInputHeader>

Logger üzerinde logları okunaklı bir şekilde görüntüleyebilmemiz adına Parser yazımına ihtiyaç duyulacaktır.

Parser Yazımı

Öncelikle elimizdeki log örneğini alanlara bölebilmek için regex yazmamız gerekecek. Bu şekilde log içerisinde gelen bilgileri istediğimiz gibi gruplayabileceğiz. Regex yazımı için internet üzerinde birçok yardımcı site bulunmaktadır.

(Demo içerisinde Regex101 sitesi kullanılmaktadır).

Örnek logumuzu aşağıdaki “TEST STRING” bölgesine yapıştırdıktan sonra yukarıdaki “REGULAR EXPRESSION” alanından regex yazılır.

Regex yazımını tamamlandıktan sonra “MATCH INFORMATION” kısmından grupların doğruluğunu kontrol edilmelidir.

Sonrasında Parserı yazmak için bir text dokümanının içerisine “regex=” ibaresini yazarak regexi bu alana eklenir.

ArcSight ürün ailesinde “\” karakteri “Escape character” olarak tanımlandığı için regex connector tarafından sağlıklı bir şekilde tanımlanamayacaktır. Bunu engellemek ve tüm regex in tanımlanmasını sağlamak için “\” karakterini “\\” ile değiştirilmesi gerekmektedir.

Karakter değişimini tamamladıktan sonra “Tokenization” işlemi ile devam edilir.

TOKENIZATION

Regex içerinde gruplamış olduğumuz alanları tanımlayabilmek için token lara atanmalıdır. Token ları tanımlarken;

token[1].name=TOKEN İSMİ

token[1].type=TOKEN TİPİ (string,long,int,timestamp,ip vb.)

Şeklinde kullanmamız gerekmektedir. Tarih tipli tokenlarda ekstra olarak tarih formatını da token tanımlarken belirtilmesi gerekmektedir.

token[0].format=yyyy-MM-dd HH\:mm\:ss\,SSS

Tüm gruplar için token tanımlanması yapıldıktan sonra mapping aşaması ile devam edilir.

Bu aşamada dikkat edilmesi gereken önemli bir nokta ise token tipi alanında belirlenen tip ile log içerisinden regex ile alınan alanın tipinin aynı olması gerekmektedir. Örneğin tarih alanı belirtiliyorsa token[0].type=timestamp ,string, bir veri belirtiliyorsa token[0].type=string şeklinde belirtilmelidir.

Tokenization işlemi bittikten sonra aşağıdaki gibi bir doküman oluşacaktır.

MAPPING

Bu kısımda yapılmış olunan token tanımlamalarını kullanarak ArcSight içerisinde hangi alanda hangi token ın görülmek istenildiği belirtilecektir.

Tüm ArcSight alanlarını görebilmek için

“ArcSight FlexConnector Developer’s Guide” daki “ArcSight Built-in Event Field

Mappings” kısmındaki tablodan yararlanılabilir.

Mapleme işlemi yapılırken ArcSight Built-in Event Fields olarak belirlenmiş olan isim adlarının kullanılması gerekmektedir. Mapping işlemini;

event.”ArcSight-Field-İsmi”=”Token İsmi”

Şeklinde belirtilmesi gerekmektedir.

Demo üzerinde token tanımı yapılmış alanlardan;

Time alanını endTime alanına,

Log_Level alanını deviceEventCategory alanına,

Message alanını message alanına,

server_name ve device_version alanlarını da deviceCustomString alanlarına maplenmiştir.

Mappingini yaptığımız log un kolay anlaşılabilmesi için verilmiş olunan deviceCustomString alanlarının yanına deviceCustomStringLabel alanını  __stringConstant(“…”) kullanarak sabit bir açıklama eklenilebilir.

Son düzeltmelerimiz ardından aşağıdakine benzer bir doküman oluşacaktır.

Parser dosya yazımı bu adım ile birlikte tamamlanıyor. Parser dosyasını kaydederken isimlendirmesine dikkat etmek gerekir. Oluşturduğumuz parser regex olduğu için “isim.sdkrfilereader.properties” formatını kullanmalıyız.

Oluşturulan parser ı “test.sdkrfilereader.properties” olarak kaydediyoruz.

SmartConnector Kurulumu ve Konfigürasyonu

SmartConnector kurulumunda connector çeşidini seçildiği ekranda “ArcSight FlexConnector Regex File” seçilir.

connector tipini seçtikten sonrasında şu şekilde bir ekran çıkmaktadır.

Bu ekranda;

Log Unparsed Events kısmında connectore gelen logların parse edilememesi durumunda ham olarak hedefe gönderilmesi veya gönderilmemesini belirtilir.

Log File Name olarak belirtilen alanda kaynaktan almak istediğimiz log dosyasının yerini belirtiyoruz. Yanda bulunan “…” tuşuna tıklayarak dosya konumunu gösterilmelidir.

Configuration file alanında ise isimlendirmiş olduğumuz Parser dosyamızın sadece ilk noktaya kadar olan kısmının yazılması gerekmektedir.

Connector kurulumunun sonraki adımında ise hedef belirtilmesi gerekmektedir.

Hedef ile ilgili bilgilerde girildikten sonra servis kurulumunu sayfası gelmektedir.

Bu sayfada da servis ismi girildikten sonra kurulum tamamlanır.

Oluşturulan Parser dosyasını ilgili connector de;

“ARCSIGHT_HOME\user\agent\ flexagent”

Altına yerleştirilerek kurulum tamamlanır.

Kurulum tamamlandıktan sonra Connector ün kurulmuş olduğu cihazda servisinin çalıştırılması gerekmektedir. Connector ün kurulu olduğu cihazın tekrar başlatılması durumunda servisin otomatik çalışması için durumunun “Automatic” olması gerekmektedir.

Servis çalıştırıldıktan sonra ilgili connectorün “ARCSIGHT_HOME\current\logs\agent.out.wrapper.log” dosyası kontrol edildiğinde First Event from kısmında deviceProduct ve deviceVendor alanı görülür.

Hedef gösterilen ArcSight Logger üzerinde deviceVendor = “TEST” araması yapıldığında aşağıdaki şekilde görüntülenmektedir.

Logger v7 Öncesi sürümlerde maplenmiş alanları aşağıdaki gibi görüntülenebilir.

Logger v7 ve sonrası sürümlerde yeni gelen Search sekmesinde ise aşağıdaki gibi görüntülenebilir;

Kaynaklar:

https://community.microfocus.com/t5/ArcSight-Connectors/ArcSight-FlexConnector-Developer-s-Guide/ta-p/1584874

https://regex101.com/

Caner Koltuk