Ertuğrul Akbaş ve Hasan Erhan beyin katkılarıyla Log Yöntimi projelerindeki deneyim ve tecrübelerin paylaşıldığı bir çalışma

1. Log Yönetimi Tecrübeleri –Genişletilmiş SürümDr. Ertuğrul AKBAŞ eakbas@gmail.com
Hasan ERHAN hasanerhan@gmail.com
Bu çalışma Hasan Erhan beyin katkılarıyla genişletilmiştir.
Aşağıda gerçekleştirilen projeler, daha önceden başka ekipler tarafından yapılan projelerin analizlerinde
elde ettiğim tecrübelerimi paylaşmaya çalıştım. Aşağıda teknik unsurlar özetlenmeye çalışılacak. Bununla
birlikte bir projenin başarılı olabilmesi için proje ekibinin çok önemli bir etken olduğu unutulmamalıdır.
Log yönetimi projelerinde genelde karşılaşılan problemleri özetlemek gerekirse:
o
o
o
Sistemin ürettiği verinin Log Yönetim yazılımı tarafından karşılanamaması, parsingkabliyetinin
yeteri kadar çeşitliliği karşılayalamaması
o Sisteminürettiğiverininyeterli parse
mekanizmasıolmadığındandolayısisteminiçinedahiledilememesiyadaeksik
dahiledilmesi. Bununiçin built-in parse mekanizmasının, sistemdealınmasıplanlanan
log kaynaklarınıkarşılayacak
kadargenişolmasıyadayetmediğidurumlardaesnekbir parse
mekanizmasınınprogramlamasınınmümkünolması
gerekmekte.
Log Yönetim Sisteminin EPS değerlerinin yeterli olmaması ve kullanıcının bunun farkında
olmaması
o EPS değeri aşağıda da anlatılacağı gibi sistemin performansının belirlenmesine önemli bir
faktör. Birdiğeretkengelenverininboyutuve parse edilmesigerekenalanlarınçokluğu.
EPS değerlerinindahaönceden POC
ortamındabelirlenmesikonumlandırılacakürünündoğruölçeklendirilmesikonusundaöne
mehaizbir durum.
Veri kaybı
o Log alınankaynağın continuous olmasıdurumunda network
yadahizmetkesintisindenötürüsürekliliğinikaybetmesive
geriyedönükloglarınalınamamasıdurumusözkonusu. Loglamamaürününün agentserver mantığıdoğrultusundaçalışması
busorunubüyükölçüdeortadankaldırıyorancak syslog
gibitemelproblemleresahipaktarımlardahalendevamedenbir
problem.
Aktarılanlogunkaynağındasıralamamantığıilealınmasıbuproblemibüyükölçüdekaldırıyo
r.

2. 1
o
o
Aranılan verinin bulunamaması
o Aranılanverininbulunabilmesiiçin log yönetimiyapanyazılımınkendiiçindebir index
venormalleştirmesürecinibarındırmasıgerekiyor. Bilindiğigibi her log
kaynağıkendimantığıçerçevesinde log alanlarıbarındırır. Her bir log
kaynağınagörebumantığıntekbirsistemiçindeparçalaraayırılarakdepolanmasıvedepola
nanalanlarınindekslenmesiaranılanverininbulunmasıveişlenmesinidahakolay hale
getirir. Parse
edilenlogundüzenlibirveritabanımantığıileiçsistemdetutulmasıvesorgulamalarıperform
anslı hale getirecekbirindexlememekanizmasıbuproblemibüyükölçüdehalledecektir.
Indexlemeninyanısıragelenlogunnormalleştirilmesiyaniveritabanıyazılımınaayrıntılıbirş
ekildetek tip olarakatılması da önemlibirfaktör.
o Yedeklerden geri dönememe
o Arama kriterlerinin beklenen seviyede olmaması
o Raporlama yeteneklerinin ileride çıkacak ihtiyaçlara göre planlanmamış olması
o Raporlamayıeldetutulanveriningrafikvetablomantığıileözetlenereksunmasıişiolarakdüş
ünüyorum. Bu anlamdaeğerverinindepolamasırasında parsing
mekanizmasınınetkinliğinegöre minimal
alanlarlaifadesimümkünsegeriyesadecegrafikvetablolamayazılımınınyeteneğikalıyor.
o Logların eksik alınması
o Mail Server
o WEB Server
o FTP Server
o DC ve diğer Serverlar vb..
Logların kısa süreli kaydedilmesi.
o Bu işlemiçin archiving
yöntemininkullanılmasıloglarınihtiyaçolduğuandaaktifedilmesiilekısıtaşılabilir.
o Satın almaya kadar ortam ölçeklendirmesini ertelemek (EPS değerleri)
o Sadece fiyatına bakıp seçim yapmak (En çok rastlana durumlardan biri)
o Neleri log'lamanız gerektiğini üretici firmanın size söylemesini beklemek
o Hukuk ekibini gözardı etmek
o Arayüz çok kullanışlı o yüzden desteğe ihtiyaç yok vb..
Son 5 madde ayrıca AntonChuvakin'inSixMIstakes of Log Management makalesinde de ifade
edilmiştir.
o
Korelasyon
o Korelasyonloglamacihazlarındagenelikleçokdairdelenmeyenbirmadde.
Korelasyonmekanizmasınıngüçlüolmasıatakönlemekonusundaoldukçayardımcıolabiliyor.
Hattadoğrucihazlardantoplananverininkorelasyonunetworkdebulunanhatalarıntespitindedahi
yardımcıolabilir.
http://www.slideshare.net/anton_chuvakin/csi-netsec-2007-six-mistakes-of-log-management-byanton-chuvakin
Log yönetimi çözümlerin korelasyon kabiliyetleri ile ilgili olarak aşağıdaki çalışmaya da göz atılabilir.

3. 2
http://www.olympos.net/belgeler/log-yonetimi/korelasyon-motoru-ileri-analitik-yontemler-bilgiguvenligi-ve-log-yonetimi-29121324#axzz2l738kxg0
Log Yakalama veya Log Kaçırmama Özelliği
Bir log yönetim sisteminin en önemli özelliği gelen bütün logları yakalamak ve işlemektir. Sistemin bu
özelliği bir proje yapılırken neredeyse hiç göz önünde bulundurulmamaktadır. Saniyede 100 lerce 1000
lercelog oluştuğu ve bu loglar ekrandan çok hızlıca aktığı için gözle oluşan logların kontrolü mümkün
değildir. Dolayısı ile gözle kontrol çok yanıltıcıdır.Bu yanıltıcı gözlemleme yerine korelasyon yöntemi aktif
olarak kullanılabilirse, gözlemleyen kişinin dikkati doğru korelasyon kuralı ile doğru noktaya
yönlendirilebilir.
Aşağıdaki linkteki çalışmadan daha detaylı bilgi edinilebilir.
http://www.slideshare.net/anetertugrul/siem-log-ynetimi-ve-5651projelerinin-performans-ve-log-kairip-kairmadiinin-testleri-nasil-yapilir
Testler yapılırkan normal şartlar için değil Peak EPS değerleri için test edilmelidir. Burada en önemli kriter
1. Belirli bir sayıdaki logu belirli sürede gönderebilmek
2. Toplam log sayısına değil de saniyede kaç adet gönderilebildiğini hesaba katmaktır.
Log Yönetimi Sistemlerinin Log Yakalama (Toplama) Hızı
Bir log yönetim sisteminin en önemli özelliği gelen bütün logları yakalamak ve işlemektir. Sistemin bu
özelliği bir proje yapılırken neredeyse hiç göz önünde bulundurulmamaktadır. Maalesef görsel unsurlar
bu özelliği perdelemektedir.
EPS Nedir?
Bazı sistemler kullanıcı ve bilgisayar sayısına göre kurgulama ve fiyatlandırma yapmaktadır. Bu doğru bir
yaklaşım olmadığı gibi sektörce bilinen yazılımlar EPS değeri kullanmaktadır.

4. 3
Yukarıdaki verilen örnekleri kullanarak bir ölçekleme yaparsak:
100 Cihazlık bir ağ için
Ortalama EPS : 40
Peak EPS : 2500
Ortalama Peak EPS: 1500
250 Cihazlık bir ağ için
Ortalama EPS : 100
Peak EPS : 6000
Ortalama Peak EPS: 4000
500 Cihazlık bir ağ için
Ortalama EPS : 200
Peak EPS : 12500
Ortalama Peak EPS: 7500
1000 Cihazlık bir ağ için
Ortalama EPS : 400
Peak EPS : 25000
Ortalama Peak EPS: 15000

5. 4
Önemli olan sistemin Peak EPS değerlerini karşılayabilmesidir. Ortalama EPS ve Ortalama Peak EPS
sadece storage ihtiyacı için hesaplamada kullanılacak parametrelerdir.
Cihaz Sayıları ile EPS ve Biriken Günlük Log Sayıları Arasındaki İlişkiler
Bu konuda aşağıdaki çalışmaya bakılabilir.
http://www.slideshare.net/anetertugrul/log-yonetiminde-cihaz-sayilari-ile-eps-degerleri-arasindaki-iliski

6. 5
Arama Hızı
Diğer önemli bir husus da bu loğların ne hızla raporlara yansıdığıdır.Aşağıda pek çok raporda Big Data ve
Veri arama (Search) için önerilen ve milyonlarca dolar ciro yapan firmaların search hızları ile ilgili bir fikir
oluşturması açısından alınan örnekleri görebilirsiniz. Herhangi biri daha hızlıdır diye bir görüş ortaya
atmak bu çalışmanın konusu değildir.
Ticari Ürünlerden Örnek Arama Senaryoları ve süreleri
Aşağıdaki örnekler sadece bir fikir oluşturması açısından verilmiştir. Fikir oluşturması açısından
Bir fortinate firewalldan gelen SYSLOG paketleri dosyaya yazılırsa ortalama :
1 000 000 (bir milyon) satır 1 GB lık bir text (ASCII) dosya oluşturmaktadır.
Örnek Arama Hızları:
http://splunk-base.splunk.com/answers/5987/is-there-any-way-to-speed-up-searches
http://splunk-base.splunk.com/answers/50503/reducing-time-taken-for-search-in-splunk-query

7. 6
http://splunk-base.splunk.com/answers/36166/from-forwarder-to-index-to-search-is-taking-too-longroughly-10-to-15-minutes

8. 7
http://splunk-base.splunk.com/answers/54306/reasonable-search-performance
http://splunk-base.splunk.com/answers/12559/searches-taking-long
http://splunk-base.splunk.com/answers/13354/slow-search-for-squid-for-a-30-days-report

9. 8
Örnek Bir Arama Kriteri:
EPS : 5000
Dakikada oluşan log: 5000 X60 =300 000 (Üçyüzbin)
Saatte oluşan log=300 000 X60=18 000 000 (Onsekiz milyon)
10 Saatte Oluşan log = 18 000 000 X10= 180 000 000 (Yüzseksen milyon)
Yukarıdaki değerlere bakarak 5000 EPS log akışına sahip bir sistemde 10 saate 180
milyon log oluştuğu ve dolayısı ile herhangi bir 10 saatlik aramanın 180 milyon
kayıt arasından olacağı unutulmamalı.
Dolayısı ile son 1 ayda en çok “socialmedia “ da gezen kullanıcıların listesi ve
sıralaması istendiğinde
Eğer 5000 EPS lik bir ağda bu sorgu yapılacaksa
18 000 000 x 24 x 30=12 960 000 000 (yaklaşık 13 milyar) kayıt içerisinde
arama , sayma ve sıralama yapılmak zorunda olduğu unutulmamalı
Eğer seçilen sistem günlük birkaç milyon log biriktirebiliyorsa (yukarıdaki
rakamlarla kıyaslanırsa ne kadar küçük bir rakam olduğu görülür) log arama
handikapları gözle tespit edilemez. Sistemlerin kapasiteleri milyarlarca log
oluştuğunda ortaya çıkar

10. 9
Kendi Geliştirdiğimiz Sistemlerdeki Durum Nedir?
Benzer arama hızı testlerini ANET yazılım tarafından geliştirilen ürünlerle yapınca
ortaya çıkan durum:
487 milyon kayıt oluşturuldu. Bu kayıtlar içerisinde KAYNAK IP si diğerlerindne
farklı farklı olan logu ilk once ve de en sonra göndererek (Zaman olarak) yaptığıız
aşağıdaki fiziksel özelliklere sahip bir sistemdeki testlerde
487 milyon kayıt içerisinde aranan o iki logu bulma süresi 60 saniyedir. Bu arama
system 6500 EPS log işlemeye devam ederken yapılan bir testtir
ANET yazılım ürün detayları için
http://www.anetyazilim.com.tr/Downloads/doc/tr/log_management_compare/ANE
T_Log_Compare.pdf

11. 10
Örnek Bir Arama Kriteri:
EPS : 5000
Dakikada oluşan log: 5000 X60 =300 000 (Üçyüzbin)
Saatte oluşan log=300 000 X60=18 000 000 (Onsekiz milyon)
10 Saatte Oluşan log = 18 000 000 X10= 180 000 000 (Yüzseksen milyon)
Yukarıdaki değerlere bakarak 5000 EPS log akışına sahip bir sistemde 10 saate 180
milyon log oluştuğu ve dolayısı ile herhangi bir 10 saatlik aramanın 180 milyon
kayıt arasından olacağı unutulmamalı.
Dolayısı ile son 1 ayda en çok “socialmedia “ da gezen kullanıcıların listesi ve
sıralaması istendiğinde
Eğer 5000 EPS lik bir ağda bu sorgu yapılacaksa
18 000 000 x 24 x 30=12 960 000 000 (yaklaşık 13 milyar) kayıt içerisinde
arama , sayma ve sıralama yapılmak zorunda olduğu unutulmamalı
KORELASYON MOTORU
Log Yönetimi katmanından SIEM katmanına çıkmak için korelasyon özelliğinin devreye girmesi gerekir.
Log yönetimi çözümlerin korelasyon kabiliyetleri ile ilgili olarak aşağıdaki çalışmaya da göz atılabilir.
http://www.olympos.net/belgeler/log-yonetimi/korelasyon-motoru-ileri-analitik-yontemler-bilgiguvenligi-ve-log-yonetimi-29121324#axzz2l738kxg0
Genelde yapılan yanlış alarm yönetiminin korelasyon olarak algılanmasıdır. Örnek korelasyon kuralları:
1 dakikaiçerisindeaynıkaynaktan 15 den fazla deny/reject/drop olursauyar
5 dakikaiçerisindeaynıkaynaktan 3 den fazla IPS logugelirseuyar
5 dakikaiçerisindeaynıkaynaktan 3 den fazla Virus logugelirseuyar
1 dakikaiçerisindeaynıkaynaktanfarklı 50 veyadahafazlafarklıip ye trafikolursauyar

12. 11
Yenibirkullanıcıoluşturulurvebuoluşturulankullanıcıileerişimyapılmayaçalışılıpbaşarısızolunursauy
ar
Aynıkullanıcıdan 3 den fazlabaşarısızerişimolupsonrasındabaşarılıerişimolursabubrüte force
atackolasılığıdırveuyar
Administrators grubunakullanıcıeklenirseuyar
Aynıkullanıcıile 1 dakikada 5 den fazlabaşarısızerişimolursauyar(Kullanıcıbilgileriilebirlikte)
Aynıkullanıcı 60 dakikada 50 den fazlasistemlere login olursauyar(Kullanıcıbilgileriilebirlikte)
Aynıkaynak IP den 3 veyadahafazlabaşarısızerişimvehemenardındanbaşarılıerişimolursauyar.
Web sunucuyacgi, asp, aspx, jar, php, exe, com, cmd, sh,
batdosyalarıuzaklokasyondnaişletilmeküzeregönderilirseuyar
İstenmeyenuygulamalar (Teamviewer, LogmeIn, Nmap, Nessus) çalıştırıldığındauyar
Spam yapankullanıcıyıtepit et.(saatte 60 den fazla mail gönderenkullanıcıyıtespit et)
Spam yapılankullanıcıyıtepit et.(saatte 25 den fazla mail alankullanıcıyıtespit et)
Gözetlenen log kaynağı son 1 saatiçerisinde log göndermezseuyar
Mesaisaatleridışındasunucularaulaşanolursauyar
W32.Blaster Worm: Eğer 1 dakikaiçerisinde 10 adet deny veyakullanıcıadıolmayanbaşarılı login
loğugelirseuyar