Tracking DNS Record Deletion

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.

 

https://www.cozumpark.com/blogs/windows_server/archive/2013/03/17/active-directory-dns-zerinde-g-ncel-veya-ge-erli-olmayan-kay-tlar-n-temizlenmesi-dns-aging-and-scavenging.aspx

 

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;

 

 

 

image001

 

 

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

 

 

image002

 

 

 

image003

 

 

 

Ş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

 

 

image004

 

 

 

image005

 

 

 

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 )

 

 

image006

 

 

 

Eğer DNS, Domain DNS Zone içerisinde ise

 

DC=DomainDNSZones,DC=cozumpark,DC=com

 

 

image007

 

 

 

Gördüğünüz gibi benim DNS Zone’ um burada.

 

 

image008

 

 

 

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

 

 

 

image009

 

 

 

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;

 

 

 

image010

 

 

 

Everyone kullanıcısını seçtikten sonra yeni bir pencere açılacaktır.

 

 

 

image011

 

 

 

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

 

 

 

image012

 

 

Server 2012 için aynı ekranlar

 

 

image013

 

 

 

Yine yukarıdaki gibi 3 kutucuğu işaretliyoruz

 

 

 

image014

 

 

 

Bunu birde Fail için yapıyoruz

 

 

 

image015

 

 

 

Son durum aşağıdaki gibidir

 

 

 

image016

 

 

 

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

 

 

 

image017

 

 

 

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

 

https://blogs.technet.com/b/networking/archive/2011/08/17/tracking-dns-record-deletion.aspx