Logları Ayarlama Enstitüsü

Her sistemin kendine özgü bir log tutma şekli var.

Sistemler üretilirken, o sistemin nasıl log tutacağı, 

log tutarken nasıl cümleler kuracağı, o sistemi üreten yazılımcıların keyfine bağlı olarak belirleniyor. Bir kaynak ip değerinin kaç farklı ifadesi olabilir: 

src, src_ip, srcip, sourceip, source_ip 

veya karakterden tasarruf edeyim derken ne kadar anlaşılmaz olduğunu anlayamayan, iyice işleri çığırından çıkaran yazılımcı ifadesiyle: sip!

Yazılımcıdan sip kelimesinin başka ne anlama geldiğini bilmesini bekleyemeyiz.

Bir standardın olması lazım. Ortak bir arayüzün olması lazım. Bu programcılara birileri dur demeli!

Programlama dillerinin kütüphanelerinde hazır fonksiyonlar olur.

Bu kütüphanelerde sık kullanılan değerlerin ve fonksiyonların en iyi hallerinin tanımları bulunur.

Pi sayısı veya sinüs hesaplayan fonksiyon gibi.

Bunun bir sebebi her programcının ayrı ayrı pi değeri tanımlamasının veya sinüs fonksiyonu yazmasının önüne geçmek ve ortak bir arayüz oluşturmaktır.

Bu ortak arayüz sonucunda yazılan kodlar diğer programcılar tarafından daha anlaşılabilir ve bakımı kolay kodlar olur. Bunun getirdiği zaman kazancı paha biçilemez.

Aynı mantığın, çalışan sistemlerin ürettiği loglar için geçerli olduğunu düşünelim.

Sisteminizde çalışan tüm işletim sistemlerinin, bu işletim sistemleri üzerinde çalışan servislerin kaynak ip değerini ifade etmek için 

src_ip=10.10.1.1 

şeklinde bir ifade kullandığını düşünün.

Logları sınıflandırmak, bu loglar üzerinden işlem yürütmek ne kadar kolay olur değil mi?

Bugüne kadar edindiğimiz tecrübeler neticesinde kaynak ip değeri gibi sistemlerde sıklıkla kullanılan 20-30 arası log alanı var:

Tarih, kaynak ve hedef ip, portlar, kullanıcı adı, domain, filename, url vs.

Bu alanların ifadesinin standartlaştırılması log işleme yazılımlarının ve bu yazılımları kullanan kişilerin işlerini büyük oranda kolaylaştıracak ve zaman kazandıracaktır.

Zira log işleyen yazılımların ve bu yazılımlar ile çalışanların vakti en çok, logların belli bir kalıba oturtulması için harcanıyor.

Çoğu zaman loglar sadece bir hata, bir olağandışı aktivite olduğu zaman incelenir.

Loglar incelenerek hata ayıklanır, suçlu yakalanır veya saldırı tespit edilir vs.

Bu durumda her sistemin ayrı telden çalması yerine belirli kısıtlar ve standartlar çerçevesinde aynı dili konuşuyor olmaları daha faydalı olur.

Kısıtlar ayak bağı gibi görünseler de, bazen uçmak için en iyi yolu gösterirler.

O programcılara siz de kızgınsanız, enstitümüze hoş geldiniz :)