icerige gec

Log Yönetimi Tecrübeleri –Genişletilmiş Sürüm-

Kasım 22, 2013 yazan ertugrul.akbas

Log Yönetimi Tecrübeleri –Genişletilmiş Sürüm-

 

Dr. Ertuğrul AKBAŞ [email protected]

Hasan ERHAN [email protected]

 

 

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:

  • Sistemin ürettiği verinin Log Yönetim yazılımı tarafından karşılanamaması, parsing kabliyetinin yeteri kadar çeşitliliği karşılayalamaması
    • Sistemin ürettiği verinin yeterli parse mekanizması olmadığından dolayı sistemin içine dahil edilememesi yada eksik
      dahil edilmesi. Bunun için built-in parse mekanizmasının, sistemde alınması planlanan log kaynaklarını karşılayacak
      kadar geniş olması yada yetmediği durumlarda esnek bir parse mekanizmasının programlamasının mümkün olması
      gerekmekte.
    • Log Yönetim Sisteminin EPS değerlerinin yeterli olmaması ve kullanıcının bunun farkında olmaması
      • EPS değeri aşağıda da anlatılacağı gibi sistemin performansının belirlenmesine önemli bir faktör. Bir diğer etken gelen verinin boyutu ve parse edilmesi gereken alanların çokluğu. EPS değerlerinin daha önceden POC ortamında belirlenmesi konumlandırılacak ürünün doğru ölçeklendirilmesi konusunda öneme haiz bir durum.
      • Veri kaybı
        • Log alınan kaynağın continuous olması durumunda network yada hizmet kesintisinden ötürü sürekliliğini kaybetmesi ve
          geriye dönük logların alınamaması durumu söz konusu. Loglamama ürününün agent-server mantığı doğrultusunda çalışması
          bu sorunu büyük ölçüde ortadan kaldırıyor ancak syslog gibi temel problemlere sahip aktarımlarda halen devam eden bir
          problem. Aktarılan logun kaynağında sıralama mantığı ile alınması bu problemi büyük ölçüde kaldırıyor.
        • Aranılan verinin bulunamaması
          • Aranılan verinin bulunabilmesi için log yönetimi yapan yazılımın kendi içinde bir index ve normalleştirme sürecini barındırması gerekiyor. Bilindiği gibi her log kaynağı kendi  mantığı çerçevesinde log alanları barındırır. Her bir log kaynağına göre bu mantığın tek bir sistem içinde parçalara ayırılarak depolanması ve depolanan alanların indekslenmesi aranılan verinin bulunması ve işlenmesini daha kolay hale getirir.  Parse edilen logun düzenli bir veritabanı mantığı ile iç sistemde tutulması ve sorgulamaları performanslı hale getirecek bir indexleme mekanizması bu problemi büyük ölçüde halledecektir. Indexlemenin yanısıra gelen logun normalleştirilmesi yani veritabanı yazılımına ayrıntılı bir şekilde tek tip olarak atılması da önemli bir faktör.
          • Yedeklerden geri dönememe
          • Arama kriterlerinin beklenen seviyede olmaması
          • Raporlama yeteneklerinin ileride çıkacak ihtiyaçlara göre planlanmamış olması
            • Raporlamayı elde tutulan verinin grafik ve tablo mantığı ile özetlenerek sunması işi olarak düşünüyorum. Bu anlamda eğer verinin depolama sırasında parsing mekanizmasının etkinliğine göre minimal alanlarla ifadesi mümkünse geriye sadece grafik ve tablolama yazılımının yeteneği kalıyor.
            • Logların eksik alınması
              • Mail Server
              • WEB Server
              • FTP Server
              • DC ve diğer Serverlar vb..
              • Logların kısa süreli kaydedilmesi.
                • Bu işlem için archiving yönteminin kullanılması logların ihtiyaç olduğu anda aktif edilmesi ile kısıt aşılabilir.
                • o   Satın almaya kadar ortam ölçeklendirmesini ertelemek (EPS değerleri)
                • Sadece fiyatına bakıp seçim yapmak (En çok rastlana durumlardan biri)
                • Neleri log'lamanız gerektiğini üretici firmanın size söylemesini beklemek
                • Hukuk ekibini gözardı etmek
                • Arayüz çok kullanışlı o yüzden desteğe ihtiyaç yok vb..

Son 5 madde ayrıca Anton Chuvakin'in Six MIstakes of Log Management makalesinde de ifade edilmiştir.

  • Korelasyon
    • Korelasyon loglama cihazlarında genelikle çokda irdelenmeyen bir madde. Korelasyon mekanizmasının güçlü olması atak önleme konusunda oldukça yardımcı olabiliyor. Hatta doğru cihazlardan toplanan verinin korelasyonu networkde bulunan hataların tespitinde dahi yardımcı olabilir.

http://www.slideshare.net/anton_chuvakin/csi-netsec-2007-six-mistakes-of-log-management-by-anton-chuvakin

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-bilgi-guvenligi-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 lerce log 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-5651-projelerinin-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.

 

 

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

 

Ö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

 

 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

 

 

 

 

 

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

 

 

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

 

 

 

Ö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 “social media “ 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

 

 

 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/ANET_Log_Compare.pdf

 

 

 

 

 Ö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 “social media “ 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-bilgi-guvenligi-ve-log-yonetimi-29121324#axzz2l738kxg0

Genelde yapılan yanlış alarm yönetiminin korelasyon olarak algılanmasıdır. Örnek korelasyon kuralları:

  • 1 dakika içerisinde aynı kaynaktan 15 den fazla deny/reject/drop olursa uyar
  • 5 dakika içerisinde aynı kaynaktan 3 den fazla IPS logu gelirse uyar
  • 5 dakika içerisinde aynı kaynaktan 3 den fazla Virus logu gelirse uyar
  • 1 dakika içerisinde aynı kaynaktan farklı 50 veya daha fazla farklı ip ye trafik olursa uyar
  • Yeni bir kullanıcı oluşturulur ve bu oluşturulan kullanıcı ile erişim yapılmaya çalışılıp başarısız olunursa uyar
  • Aynı kullanıcıdan 3 den fazla başarısız erişim olup sonrasında başarılı erişim olursa bu brüte force atack olasılığıdır ve uyar
  • Administrators grubuna kullanıcı eklenirse uyar
  • Aynı kullanıcı ile 1 dakikada 5 den fazla başarısız erişim olursa uyar(Kullanıcı bilgileri ile birlikte)
  • Aynı kullanıcı 60 dakikada 50 den fazla sistemlere login olursa uyar(Kullanıcı bilgileri ile birlikte)
  • Aynı kaynak IP den 3 veya daha fazla başarısız erişim ve hemen ardından başarılı erişim olursa uyar.
  • Web sunucuya cgi, asp, aspx, jar, php, exe, com, cmd, sh, bat dosyaları uzak lokasyondna işletilmek üzere gönderilirse uyar
  • İstenmeyen uygulamalar (Teamviewer, LogmeIn, Nmap, Nessus) çalıştırıldığında uyar
  • Spam yapan kullanıcıyı tepit et.(saatte 60 den fazla mail gönderen kullanıcıyı tespit et)
  • Spam yapılan kullanıcıyı tepit et.(saatte 25 den fazla mail alan kullanıcıyı tespit et)
  • Gözetlenen log kaynağı son 1 saat içerisinde log göndermezse uyar
  • Mesai saatleri dışında sunuculara ulaşan olursa uyar
  • W32.Blaster Worm: Eğer 1 dakika içerisinde 10 adet deny veya kullanıcı adı olmayan başarılı login loğu gelirse uyar