Makaleler > Active Directory Sunucularında Security Event ID Analizi

Active Directory Sunucularında Security Event ID Analizi

Şubat 15, 2012

Bu makalemizde orta ve büyük ölçekli kurumların hemen hemen tamamında kullanılan, IT süreçlerini ve yönetimi ciddi manada kolaylaştıran Active Directory’e log yönetimi açısından bakacağız ve bu multimaster mimarinin yöneticileri diye tabir edilen DC (Domain Controller) sunucularında oluşan güvenlik log kayıtlarını birlikte inceleyeceğiz.

Aslında bir DC (Domain Controller) sunucusana ait bir günlük “Security” log kayıtları alınıp incelendiğinde orada o kuruma ait bir yaşam döngüsünü görmeniz mümkündür. Örneğin sabah mesai başlamasıyla birlikte kullanıcıların logon olması ile tüm bilgisayarlar önce DC’ ye gider ve daha sonra yapılacak işlemler için kerberos biletini alır (TGT). Bu biletin alınması ile birlikte Windows Server 2003 sunucularda “672”, Windows Server 2008 sunucularda “4768” numaralı event id oluşur. Akabinde diğer erişim hizmetlerinde ve politikaların alınması için “4769” event id oluşur ve bu aşamadan sonra süreç başlar.

Kullanıcıların gün içerisinde yaptıkları aktivitelerin bir kısmı DC sunuclarında security kayıtlarına atılmaktadır. Tamamı demedim çünkü DC suncuları tıpkı bir noter gibi çalışmakta ve kendisine gelen talepleri ilgili politika ve kurallara göre işletmektedir. Örneğin bir dosya sunucusunda ilgili klasore erişim yapılacaksa istemci DC’ ye gider, ben \\FileServer\Paylasim dosyasına erişmek istiyorum der ve yetkinlik biletini alır. Bununla birlikte ilgili log kaydı atılır. Yapılan erişimlerde DC’ ye sorulmadan, otorite veya noter olarak başvurulmadığı durumlarda DC konudan habersizdir. Bu gibi durumlarda başvurulacak log kaydı istemci tarafıdır.

SIEM projelerinde yaşanan en büyük problem log kirliliği sebebi ile logların takip edilemez bir hal almasıdır. Bununla birlikte en büyük dezavantaj log yönetimi için kullanılan çözüme “yalancı çoban” muamelesi yapılmasıdır. Yani gereksiz log kayıtlarından arındırılmamış bir log sisteminin oluşturacağı uyarı mekanizmaları ve bildirim (mail, sms v.b.) sayısının fazla olması monitor yapan ve bu uyarıları takip eden sistem sorumlusu personel için sıradanlaşır. Gün içerisinde log sistemlerinden gelen yüzlerce gereksiz uyarıların sıradan hale gelmesi, günün birinde gelecek çok ciddi ve belkide hizmet kesintisine, iş sürekliliğine engel olabilecek uyarıların göz ardı edilmesine sebep olacaktır.

Burada iş log yönetimi sistemlerinin operasyon sorumlusu personele düşmektedir. Gürültü kirliliğinin azaltılması, gerksiz log kayıtlarının daha kaynağında iken drop edilerek alınmasının engellenmesi ile olur.

Burada hangi event id loglarının filtrelenceği tehdit modeline göre değişiklik gösterir. Fakat benim acizane tavsiyem aşağıda listesi verilen event id loglarının filtrelenmesidir.

Burada bir kez daha belirtmekte fayda var. Filtrelenmesi tavsiye olunan log kayıtları tamamen tehdit modeline ve kurum ihtiyaçlarına göre değişiklik göstermektedir. Örneğin, 540 numaralı event id network logon gösterir ve çok fazla oluşur. Bu event id den çok fazla bir işe yarar bilgi alamazsınız. Ama kurum olarak ne olursa olsun tüm network logon bilgilerini görmek isterseniz durum değişebilir. Bu arada aşağıda ekran görüntüsü verilen ve Logyonetimi ekibi tarafından kurulan www.eventid.com.tr adresinden de event id açıklamaları ile ilgili bilgi alabilir veya katkıda bulunabilirsiniz.

Yapılan filtrelemeler sonrasında, ortalama 4000 istemcinin olduğu bir Active Directory ortamında 1 gün içerisnde DC (Domain Controller) sunucularda en çok oluşan event id ve sayıları aşağıdaki şekildedir;

Yukarıda yer alan listede özellikle 4624 numaralı event id sayısının %60’dan fazlası gereksiz log kaydıdır yani kullanıcı adı alanında sonu “$” ile biten “pcname-1$” bilgisayarı “Pcname-2$” bilgisayarı ile görüştüğü durumlarda oluşur ve bu log kaydının sizin için bir değeri yoktur.

DC üzerindeki “Windows Event Log” konfigurasyonunda “Security” log boyutunun 256 Mb değeri aşması durumnda, en eski log kaydından itibaren üzerine yazıldığı düşünülürse 1500 client olan bir ortamda 20 dk içerisinde eski logların üzerine yazmaya başlayacaktır.

Bu da gösteriyor ki 20 dk içerisinde yaşanan network kesintisi, log yönetimi çözümlerinde yaşanan sıkıntılar v.s. log kaybına sebebep olacaktır.Ve bu log kayıtları geri dönülemez kayıtlar olması sebebi ile yedekli mimarilerin kurulması hem ajanlı hem ajansız senaryolar üzerinde çalışılmalı ve özellikle DC üzerinde log kaybının kesinlikle önüne geçilmelidir.

Yukarıda yer alan örnek üzerinden analize devam edersek karşımıza çıkan tablo şu şekildedir;

Bir gün içerisinde Dc tarafında oluşan 18 gb’lık log kaydının tamının sıkıştırılmadan log sistemlerine alınması gibi bir şey söz konusu değildir. Aksi taktirde disk maliyetinin önüne geçilemez. Log yönetimi konusunda piyasada bulunan çözümlerin ortalama sıkıştırma boyutu1:10 oranındadır. Burada sıkıştırma oranının artması disk maliyetini azaltırken, log veritabanında yapılan arama işlemlerinin de süresini uzatmaktadır. Sıkıştırma algoritmalarından geçerek arşivlenen data, boyutu yukarıda verilen 18 gb değerinin 1.8 Gb olarak sıkıştırılarak arşivlenecektir.

“Active Directory” ortamında izlenmesi veya toplanması gereken log kayıtlarında özellikle aşağıdaki değişikliklerin izlenmesinde fayda vardır;

Grup Policy objelerinde yapılan değişiklikler
OU (Organizational Unit) izinlerinde yapılan değişiklikler
Grup Policy obje linklerinde yapılan değişiklikler
OU silinmesi
GPO silinmesi
Trust ilişkilerinde yapılan değişiklikler
Ayrıcalıklı gruplardaki üyelik değişiklikleri (Domain admin grubuna üye eklenmesi)
Etki alanı denetleme politikalarında yapılan değişiklikler
Etki alanı hesaplarında yapılan değişiklikler
Yeni eklenen DC sunucular

Yukarıda bahsi geçen log kayıtlarının üretilmesi için öncelikle GPO (Group Policy Objects) ve OU (Organizational Units) üzerinde denetleme politikalarının aktif hale getirlmesi gerekmektedir.

DC sunuculardan alınan log kayıtları ile hangi event id ile, hangi bilgilere erişilebilir bir kaç örnek verelim.

Yukarıdaki örnekte yer alan ve domain admin kullanıcısının herhangi bir kullanıcıya ait şifrenin resetlenmesi durumunda ilgili personele mail attırılarak resetleme işleminden haberdar edilebilir.

Bu ve buna benzer örnekleri http://www.eventid.com.tr/web/logyonetimi.aspx adresinden ulaşabilirsiniz.

Daha önceki makalelerde de bahsettiğimiz ve özellikle takip edilmesini uygun gördüğümüz event id listeleri şu şekildedir;

Burada bahsi geçen event id bilgilerinin bazıları istemci tarafında alınırsa faydalı olacak log kayıtlarıdır. Örneğin 528 (A user successfully logged on to a computer), bu event id oturumun açıldığı bilgisayarda oluşur. Logon Type=2 (Makina başından yapılan logon) veya Logon Type=10 (RDP) olan bir logon işleminde birebir istemici tarafında alınan bir log kaydıdır. Dc sunucuda bu logon tiplerine ait bilgiler sadece domain admin veya o sunucu sorumlusuna ait bilgilerdir.

Osman Doğan

DC Event ID