Log yönetimi kapsamında, iş sürekliliğini ve kesintisiz hizmeti sağlayan uygulama sunucularında, logların merkezi olarak konsolidasyonu çok önemlidir. Sunuculardan logların toplanması, anlamlı hale getirilmesi ve raporlanması planlı bir süreci gerektirir. Sunucu loglarının alınması konusundaki en ufak bir ihmarkarlık çok ciddi sıkıntılara sebep olabilir. Yetkisiz erişimin olduğu kritik bir sunucuda gerçekleşecek bir veri kaybı veya önemli bir verinin çalınmasının önüne geçebilmemiz ve tespit edebilmemiz için ilgili log kayıtlarını merkezi olarak topluyor olmalıyız.
Kritik sunucular üzerindeki logların alınması ve raporlanması aşamasında, logların nasıl toplanacağı, toplanan logların nasıl anlamlandırılacağı ve nelere dikkat etmemiz gerektiği ile ilgili proje planını çıkarıyor olmalıyız. Aksi taktirde toplanan logların kurumumuza hiçbir katkısı olmayacağı gibi iş sürekliliğini kesintiye uğratacak problemlerle karşılaşmamız ihtimal dahilindedir.
Faz-2 olarak nitelendirdiğimiz Kritik sunucu loglarının alınması ve raporlanması süreci şu şekildedir;
1. Kritik Sunucuların Belirlenmesi : Sunucu loglarının alınması sürecinde ilk yapılması gereken, kritik sunucuların belirlenmesidir. Bu süreç 5-10 sunucunun olduğu işletmelerde çok geçerli olmayabilir. Fakat sunucu sayısı, 500-1000 hatta daha fazla olan işletmelerde kapsamın kritik sunucular olarak çizilmesi çok önemlidir. Çünkü log toplanan sunucu sayısının artması hem bu logların takibi ve monitor edilmesini zorlaştırır, hemde log yönetimi kapsamında kullanmış olduğumuz çözümler için ciddi yük oluşturur. Bu noktada almış olduğumuz log yönetimi çözümlerinin Event Per Second (Saniyede alabileceği event) sayısı çok önemlidir. Eğer saniyede alacağımız log sayısı bu değeri aşarsa hem performans kaybı hemde topladığımız loglarda kayıplar yaşanabilir. Bu yüzden IT altyapımızda yer alan sunucularımızın hangilerinden log kayıtlarını toplayacağımızı belirlemeliyiz. Kısacası “Kritik Sunucu” listemizi oluşturmalıyız. Kritik sunucuları belirlerken kriterlerimiz şunlardır;
a. Üzerinde çalışan uygulamaların önemi. Örneğin firma çalışanlarının özlük veya maaş bilgilerinin bulunduğu insan kaynakları uygulamalarının çalıştığı sunucular.
b. Üzerinde kritik dosyaların bulunması. Örneğin tüm çalışanların ortak erişim sağladığı dosya sunucuları.
c. Üzerinde kritik hizmetlerin olması. Örneğin IIS, FTP v.b hizmet sağlayıcı konumundaki sunucular.
d. İş sürekliliğindeki önemi. Sunucu üzerinde kritik bir dosya yoktur, kullanıcıların veri girdiği bir uygulama çalışmıyordur. Ama üzerinde çalışan bir servis vardır ki onun durması veya farklı bir hesap ile çalıştırılmaması gerekiyordur. Bu da bizim kritik sunucu kriterimiz içerisine girer.
2. Alınacak Log türlerinin Belirlenmesi : Bu aşamada sunucu üzerinde işletim sistemine ait hangi log kayıtlarının alınacağı belirlenir. Burada sunucu üzerinde çalışan işletim sistemi ve size verbileceği log yapısı çok önemlidir. Windows server 2003 için örnek verecek olursak, bu log çeşitleri şunlardır;
a. System Log : İşletim sistemi bileşenleri tarafından sebep olunan hatalar, bu Log’a kaydedilir. Örneğin, bir HBA kartının sürücüsünün tanınmaması, bir servisin çalışmaması gibi temel hatalar bu Log’a kaydedilir.
b. Application Log: Uygulamaların neden olduğu hatalar bu log’a düşer. Örneğin çalışan bir uygulamanın regedit kaydına bir şey yazamaması.
c. Security Log: Logon/Logoff, yetkili/yetkisiz erişim denemeleri bu log’a düşer. Örneğin kritik bir dosyaya kimin eriştiğini, hangi yetki ile eriştiğini, sildiğini veya açtığını security log kaydından görebiliriz. Sistemlerin başlatılması, account yönetimi ile ilgili işlemler, şifre süresinin aşılması, izin düzenlemeleri ve grup üyelikleri v.b log kayıtları security logunda bulunur.
Her bilgisayarda standart olarak gelen bu izleme politikalarının dışında da çeşitli log mekanizmaları olabilir. Örneğin Active Directory olan bir ortamda DC (Domain Controller ) üzerinde Directory Service veya DNS sunucu üzerinde dns loglarının tutulduğu kayıt defterleri olabilir. Windows tabanlı bilgisayarlarda 9 değişik izleme politikaları vardır. Burada sunucular üzerindeki hangi log kayıtlarını alacağımızı doğru blirlemeli, alacağımız bu logların, log yönetimi için kuracağımız sistemlere gereksiz yük getirmesinden kaçınmalıyız.
Şekil-1’de yer alan sistem ve uygulama event tipleri de şu şekildedir;
I. Information : Herhangibir uygulamanın veya servisin başarılı olarak yüklendiğinin bilgisini verir.
II. Warning : İleride sorun oluşturabilecek olaylar hakkında bilgi verir. Ve bu durum hakkında sizin önlem almanız noktasında uyarır.
III. Error : Herhangi bir uygulama veya servisin çalışması sırasında oluşan hatayı size bildirir.
Şekil-1
Security event tipleri şu şekildedir;
I. Success : Başarılı gerçekleşen olay kaydında düşer.
II. Failure : Yapılan işlemin başarısız olduğunu gösterir.
Belirlemiş olduğumuz security loglarının alınabilmesi için işletim sistemi tarafında bu izleme politikaların oluşturulması gerekir. Aksi taktirde ilgili log kaydında istediğimiz verilere ulaşamayız. Şekil -2 de yer alan izleme politikaları ve özellikleri şu şekildedir;
o Account Logon : Kullanıcının Domain’ e logon olduğu bilgisi.
o Account Management : Kullanıcı veya Grup oluşturma, silme, değiştirme bilgilileribulunur.
o Directory Service Access: AD (Active Directory) objelerini açan kullanıcı bilgilerini izlenmesini sağlar.
o Logon Events : Local veya networkden logon/logoff olan kullanıcı bilgilerinin izlenmesini sağlar..
o Object Access : Dosya ve klasor üzerinde kullanıcıların yaptıkları işlmlerin izlenmesini sağlar.
o Policy Change : Politikalarda yapılan değişiklikleri izler.
o Privlege Use : Kullanıcıların sistemler üzerinde yaptığı değişikliği tutar. Sistem saatinin değiştirilmesi gibi.
o Process Tracking : Çalıştırılan program bilgilerinin izlenmesini sağlar.
o System Events: Kullanıcıların restart ve shutdown etme bilgilerinin izlenmesini sağlar.
Şekil-2
Bütün bu politikaları konfigure edebilmek için Administrators grubunun üyesi olmamız ve gerekir. Her bir politikayı çift tıklayarak Sucess/Failure işaretlememiz yeterlidir. Yani başarılı ve başarısız gerçekleşen işlemleri n izlenmesi sağlanır.
3. Log Toplama Zaman Aralığı : Logların toplanmasına başlamadan önce, bu logların hangi zaman aralığında alınması gerektiği belirlenmelidir. Sunucular üzerindeki log boyutunun önerilen değerlerin üzerine çıkması işletim sistemi performansı ve iş sürekliliği açısından sıkıntılara sebep olabilir. bu yüzden kritik boyuta gelmeden logların merkezi olarak loglanması gerekir. Windows event log mimarisini inceleyecek olursak, log boyutunun 300 mb geçmemesi gerekir. win 2008 ile birlikte bu değerin 4-16 gb olması problem değildir.Varsayılan değerler ise kısaca şöyledir;
o Win2003 16 mb
o Win2003 DC 132 mb
o Win 2000 ve XP 512 kb
Log boyutunun belirlenen sınıra ulaştıkdan sonra ne yapılacağı şekil-3 de “When maximum log size is reached” bölümünde belirlenir.
Şekil-3
Overwrite events as needed: Log boyutunun kritik değere ulaşması halinde mevcut logların üzerine yazılır. Logların zamanında alınamaması durumunda log kaybı yaşarız. Belirlediğimiz log boyutunun aşılması bir DC sunucusu için 1 saat gibi kısa bir sürede gerçekleşirken, bir başka sunucuda 1 haftada bu limite ulaşılabilir. Bu sebepden log kaybı yaşamadan en uygun sürenin belirlenmesi gerekir. Yani kritik sunucu üzerindeki loglar dakika,saat veya günlük zaman aralıkları ile alınabilir.
Overwrite events older than: Log boyutunun belirlenen değere ulaşması durumunda yeni gelen event log kayıtlarının 7 günden eski logların üzerine yazılmasını sağlarız. Eğer 1 hafta boyunca mevcut logları alamamış isek log kaybı yaşarız.
Do not overwrite events: Kesinlikle hiçbir log kaydının silinmemesi ve bir başkasının üzerine yazılmaması demektir. Mevcut loglar manuel silinebilir. Fakat log boyutu 200-300 mb olduğunda işletim sisteminde problemler yaşanabilir.
Öneri; Kritik sunucularınız üzerindeki “When maximum log size is reached” seçeneğinin “Overwrite events as needed” olması ve belirlenen limite ulaşılmadan mevcut logların merkezi log korelasyon dahilinde alınmasıdır.
4. Kritik Logların Belirlenmesi: Sunuculardan belirlenen log kayıtlarının toplanması süreci başladıktan sonra alarm kurallarının oluşturulması ve uyarı mekanizmalarının kurulabilmesi için kritik log kayıtlarının sunucu bazında belirlenmesi gerekir. Örnek vermek gerekirse;
o Logon/logoff takibi için Event Id 528,
o Başarısız oturum açma girişimi için Event Id 529,
o Logların silinmesi durumunda Event Id 517,
o Kullanıcı hesabındaki değişikliklerin takbi için Event Id 642,
o Kimlerin ağ üzerinden oturum açtığının belirlenmesi için Event Id 540,
o Web sunucu üzerinde bulunan index.html dosyasında gerçekleşecek değişiklik,
o Dhcp sunucu servisinin durması v.b.
5. Realtime Alarm ve İzleme Mekanizmalarının Kurulması : Kritik sunucu loglarının alınma sürecinde 5. aşama alarm ve izleme mekanizmasının kurulmasıdır. Belirlenen sunuculardan logların toplanması ve bizim için kritik log kayıtlarının log yönetimi sistemine düşmesi durumunda ilgili kişi veya kişilere mail, sms veya popup olarak bildirimin yapılması ve zaman kaybetmeden gereken aksiyonun alınması gerekir.
6. Raporlama Ekranlarının Oluşturulması : RealTime izlemenin dışında bir diğer süreç ise mevcut politikalara ve kriterlere uygun logların haftalık, aylık veya yıllık olarak raporlanması ilgili kişi veya kişilere pdf, xlsx veya docx formatında gönderilmesi sağlanmalıdır. Aslında şu ana kadar yapılan bütün çalışmaların meyvesi bu rapor ekranlarıdır. Örneğin kritk olarak belirlenen bir sunucuya 1 hafta içerisinde logon olan Top 20 username veya yetkisiz erişim denemesi yapılan Top 20 Servername v.b Şekil-4 benzeri raporlar hazırlanabilir.
Şekil-4
