Active Directory Üzerindeki DNS Kayıt Silinmelerinin Takibi – Tracking DNS Record Deletion
Active Directory mimarisinin vaz geçilmez bileşenlerinden biri DNS’ dir. Malum DNS sadece AD için değil günlük yaşamımızdaki internet trafiğinden tutunda kullandığımız pek çok sistem için vazgeçilmez bir hizmettir.
Ancak DNS çok önemli bir servis olduğu kadar çok kritik bir servis olup sorun olması durumunda bu sorunun analizinin yapılması da son derece önemlidir.
DNS konusunda aslında yazılacak çok fazla konu başlığı var ancak zaman en büyük düşmanımız ve vaktim olduğu sürece bende yazmaya gayret ediyorum.
Bu makalemde geçenlerde bir sorun durumunda ihtiyacım olan ve araştırmamın sonucunda bulduğum bir makaledeki DNS kayıtlarının silinmesinin nasıl takip edileceğini detaylandıracağım.
Öncelikle loglama olarak bildiğimiz bu Audit işinde bazı 3 party çözümler bulunmaktadır. Bunlar her daim bizim logları takip etmemizi kolaylaştıracaktır.
Ancak burada ince bir detay var. Loglama yazılımlarının bir kısmı mevcut system olay günlüklerini alırlar ve bunları kendi veri tabanlarında ( veya dosya sistemlerinde ) saklarlar. Size bir ara yüz sunar ve bu ara yüz üzerinden olay günlüğü içerisindeki bileşenlere göre ( olay numarası, kaynağı ve benzeri ) arama yapmanıza imkân sunarlar. Bu noktada bildiğiniz gibi olay günlüklerinin boyutu sınırlıdır. Benim sunumda çok yer var, loglama yazılımı almak yerine ben olay günlüklerinin boyutunun büyütürüm demek bir çözüm olmuyor. Neden derseniz Microsoft tarafından olay günlükleri için ideal boyutlar yayınlanmıştır. Yani özellikle kritik olan sunucularda bu olay günlüklerinin önerilen boyutların üstüne çıkarılması sorunlara neden olabilir.
Bu durumda ya log kaybetmeyi göze alacaksınız ya da bir loglama yazılımı almanız gerekli. Ancak burada bir önemli detay daha var. Eğer sizin loglama yazılımınızın çalışma mantığı agent yüklü olan sunucu üzerindeki ( agentsız da olabilir ) olay günlüklerini toplamak üzerine ise bu durumda sizin öncelikle Windows tarafında takip etmeniz gereken kritik noktaların olay günlüklerine düşmesini sağlamanız gerekmektedir. Örneğin benim makalenin konusuna dönersek, ben istiyorum ki bir dns kaydı silinirse kim silmiş görmek istiyorum, şimdi siz bunu Windows üzerinde açmazsanız bu olay günlüğüne düşmez, düşmez ise de bu durumda sizin loglama yazılımınız böyle bir detay veremez. Ancak ikinci bir tür loglama yazılımı daha vardır, bunlar kernel seviyesinde çalışan ve olay günlüklerine bakmayan yazılımlardır. Örneğin Quest firmasının intrust ürünü olay günlüklerini toplar, ancak yine quest firmasının Change Auditor yazılımı kernel seviyesinde AD üzerindeki değişiklikleri yakalar. Yani ikinci ürün eğer bu tür bilgileri loglama üzere destek sunuyor ise sizin olay günlükleri için ek bir gpo ayarı yapmanıza gerek yoktur. Ancak bu tür yazılımların az olması veya Active Directory, Exchange gibi sistemlerin dışında diğer tüm sistemler için desteklenmiyor olması bir sıkıntı. Bu nedenle günün sonunda en temel olan şey olay günlüklerine yazdırmaktır.
Özetlemek gerekir ise,
1 – En ucuz yöntem Windows olay günlüklerini takip etmektir
2 – Windows olay günlüklerini açtıktan sonra merkezi loglama, merkezi rapor alma ve hızlı sonuçlara ulaşmak için bir log yazılımı almak
3 – Ürüne özel kernel seviyesinde takip yapan log yazılımları alma.
Ben her 3 özelliği de sorumlu olduğum sistemlerde kullanıyorum ve gayet başarılı.
Peki, genel bilgilerin yanında özel bilgilere geçelim, yani makale konumuza dönelim. Amacımız AD veri tabanı içerisinde bulunan dns zone altındaki herhangi bir kayıt üzerinde yapılan değişikliğin güvenlik olay günlüklerine yansıması.
DNS kaydı neden silinir?
Bunun aslında pek çok nedeni olabilir, yanlışlıkla elle silme, istemci makinenin dns kaydını güncelleyememesi, yaşlandırma dediğimiz özelliğin makinenin dns kaydını güncelleyemeden kaydı yaşlandırıp silecek şekilde yanlış konfigüre edilmesi gibi durumlar oluşabilir. Bizimde amacımız bunları incelemek.
DNS Aging Scavenging konusunda bilgi için aşağıdaki linkleri inceleyebilirsiniz.
Ek olarak bu makaleninde yararlı olacağını düşünüyorum.
https://www.hakanuzuner.com/dns-dynamic-update-credentials/
Benim amacım öncelikle Domain Controller makinelere etki eden Default Domain Controller Policy Üzerinde değişiklik yaparak “Audit directory service access” özelliğini açmak olacaktır. Bunun nedeni ise DNS, Active Directory veri tabanında tutulmaktadır ve buradaki değişiklikler aslında directory servisine erişim olarak nitelendirilmektedir.
Peki, bunun için Default Domain Controller Policy de aşağıdaki ayarı yapabiliriz;
Default Domain Controller Policy – Computer Configuration – Windows Settings – Security Settings – Local Policies – Audit Policy altında yer alan “Audit directory service access” kısmına tıklıyoruz ve “success , Failure” için bu özelliği açıyoruz. Ancak bunu yapmak yeterli değil. Bildiğiniz gibi Audit işleminin aktif olması için dosya veya obje üzerinde de güvenlik ayarlarından, audit sekmesinden kimlerin hangi hareketleri için loglama yapılacağını ayarlamamız gerekiyor. Söz konusu bir DNS zone olduğu için o zone’ un özelliklerinden bunu yapamıyoruz. Bunun için ADSIEDIT aracı ile Active Directory veri tabanının içine girip oradan DNS zone’ u bulup bu ayarı yapmamız gerekmektedir.
ADSIEDIT aracını açıyoruz ardından bağlantı kurmak için ayarları açıyoruz
Şimdi burada DNS zone’ u bulmak için bilmemiz gereken bir detay var. Bildiğiniz gibi DNS zone AD veri tabanı içerisinde replikasyon türüne göre 3 farklı yerde bulunabilir
DNS zone özelliklerine girer, ardından replikasyon bölümüne tıklarsak
Bizim DNS’ in hangi bölümde olduğunu görebiliriz. Benim DNS’ im varsayılan kurulum ile gelen domain seviyesinde bulunmaktadır. Yukarıdaki 3 seviye için bağlantı yolunu aşağıdaki gibi yazmanız gerekmektedir
Eğer zone domain bölümünde ise DC=cozumpark,DC=com ( muhtemel varsayılan kurulum dışında ayar yapmamışsanız bir sonraki bölümdedir )
Eğer DNS, Domain DNS Zone içerisinde ise
DC=DomainDNSZones,DC=cozumpark,DC=com
Gördüğünüz gibi benim DNS Zone’ um burada.
Eğer Forest DNS Zone içerisinde ise aşağıdaki yolu izleyebilirsiniz.
DC=ForestDNSZones,DC=cozumpark,DC=com
Peki, ben kendi DNS Zone’ umu buldum. Şimdi izlemek istediğim zone üzerinde “Özellikler – Güvenlik – Gelişmiş ve Audit” bölümüne geliyorum
Yukarıda olduğu gibi hali hazırda bir kayıt görebilirsiniz, ancak bunu görmezden gelip “Add” diyerek “Everyone” kullanıcısını bir kez daha seçelim. Ardından aşağıdaki gibi yeni bir pencere açılacaktır
Server 2008 ve R2 deki ekranlar aşağıdaki gibidir;
Everyone kullanıcısını seçtikten sonra yeni bir pencere açılacaktır.
Bu pencerede ise “Write all properties, Delete ve Delete subtree” kutucuklarını her iki durum içinde işaretliyoruz.
Son durum aşağıdaki gibidir
Server 2012 için aynı ekranlar
Yine yukarıdaki gibi 3 kutucuğu işaretliyoruz
Bunu birde Fail için yapıyoruz
Son durum aşağıdaki gibidir
Evet artık sistem izlenmeye hazır. Bundan sonra yapmamız gereken tek şey güvenlik olay günlüklerinde 4662 ( Server 2003 için 566 )olay kaydını incelemek. Tabiki bu olay kaydı sadece DNS e özgü değil directory servis erişimlerini loglamaktadır.
Örnek bir çıktı
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: mm/dd/yyyy hh:mm:ss AM/PM
Event ID: 4662
Task Category: Directory Service Access
Level: Information
Keywords: Audit Success
User: N/A
Computer: <Server Name>
Description:
An operation was performed on an object.
Subject :
Security ID: COZUMPARK\Administrator
Account Name: Administrator (computer account /user account)
Account Domain: COZUMPARK
Logon ID: 0x1d3d5
Object:
Object Server: DS
Object Type: dnsNode
Object Name: DC=test,DC=COZUMPARK.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=COZUMPARK,DC=com (This tells the name of the record that was deleted)
Handle ID: 0x0
Operation:
Operation Type: Object Access
Accesses: Write Property
Access Mask: 0x20
Properties: Write Property
dnsNode
Yada canlı bir sistemde
Gerçek ortamlarda çok sayıda 4662 olayını göreceksiniz, bunların arasından DNS ile ilgili olanları Windows olay günlüklerinden ayırt etmek mümkün değil, ancak bir log yazılımınız var ise bu logları alırken “Object Type = dnsNode” olarak alır ve sizde süzerken buna göre süzerseniz bu olayları rahatlıkla inceleyebilirsiniz.
Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek üzere.
Yararlandığım kaynak
http://blogs.technet.com/b/networking/archive/2011/08/17/tracking-dns-record-deletion.aspx
