Share via

DNS Hesapları Neden, Kim tarafından, Nasıl Siliniyor?

  • Article

Merhaba,

Birkaç ay önce Auditing ile ilgili yazdigim yazida genel itibariyle nasil ayarlanmasi gerektigi, Auditing Policy’lerinin nasil kullanilmasi gerektigi, Auditpol ile nasil ayarlamalar yapabilecegimizden bahsetmistim. Bu yazimda ise Auditing kullanilarak silinen bazi DNS adreslerinin pesine düsecegiz.

Her ay mutlaka birkaç tane DNS kaydi silinen sunucu veya istemciler ile ilgili problemler üzerinde müsterilerim ile birlikte çalismalar yapiyorum. Genelde bu tür problemler, çokça kullanilan sunuculara yapilan isteklerin cevaplanamiyor olmasi ile birlikte ortaya çikmaktadir. Aksi halde sistemler üzerinde çalisan DNS Client servisi her açilista veya 24 saatte bir kayitlari yenilemektedir. Siz farketmeden kayit yeniden olusabilir. Peki neden siliniyor? Auditing olmadan buna kesin bir cevap vermek mümkün degildir.

Kimler süpheli?

  1. Administrator: Evet, ortamin hakimi Domain Admin’lerden bir tanesi “yanlislikla” silmis olabilir.
  2. Scavenging: Dogru ayarlanmamis bir scavenging, bir anda birçok kaydin silinmesine sebep olabilir.
  3. Kaydin sahibi: Evet. Ama burada bir suçlama yok! Çünkü sistemi shutdown ederek, eger DHCP opsiyonlarinda tanimliysa, kaydin silinmesi için istek göndermis olabilir.
  4. Replikasyon: Burada asil süpheli baskasi olmali. Replikasyon ona söyleneni yapar ve silinmis kaydi replike eder. Gerçekten öyle mi? Replikasyon o kadar masum degildir!
  5. Hiç update edemedim ki! Evet bu da mümkün, kaydin daha önce var oldugundan emin misiniz? Bunu anlamanin en kolay yolu kaydi silinmis bir sistem üzerinde ipconfig /registerdns çalistirmaktir. Eger kayit olusmuyorsa, hedefteki DNS Zone’un güvenlik ayarlarini kontrol etmek de fayda var.
  6. Usak: Kastim servisin kendisinin buna sebep olmasi :) Bilinen iki problem için kod güncellestirmesi bulunuyor:

Bilinen problemler giderildikten sonra problem devam ediyorsa, IT Admin olarak bizim yapmamiz gereken süphelinin pesine düsmektir.

ÖNEMLI!!! Auditing etkin oldugu müddetçe size yararli olacaktir. Kayit silindikten sonra etkinlestirip izlemenin, bir önceki silinme islemi için bir yarari yoktur. Etkinlestirildikten sonra ki hareketleri izleyebilirsiniz.

Bir önceki Auditing yazisinda belirttigim gibi Directory Services Access Auditing UI veya Auditpol kullanilarak etkinlestirilebilir. Yalniz bu yeterli degildir. Yine daha önce belirttigim gibi izlenecek olan kayit ve/veya zone seviyesinde SACL belirlenmelidir.

Peki SACL nedir?

Açilimi System Access Control List olan SACL, dosya ve klasör seviyesinde object access kontrolü yapma yetkisidir. ACE (Access Control Entries) den farkli olarak kullanici veya gruba sadece Auditing yetkisi verilmesidir. Auditing hakki olan bir kullanicinin, ACE hakki olmayabilir. Tipki ACE ile yaptiginiz gibi dosya veya klasör özelliklerinden Auditing üzerinden haklari verebilirsiniz. Daha fazla bilgi için tiklayabilirsiniz.

Eger bir zone altindaki tüm kayitlari izlemek istiyorsak, DNS konsolu üzerinden zone seviyesinde önce özellikler sonrasinda ise Auditing sekmesine ulasmak için Security sekmesine tiklamali ve sonrasinda Advanced ile devam etmelisiniz. Everyone için Delete, Delete Subtree ve Write All Properties haklarini “Success” için vermelisiniz. Eger silmeye çalisip, silemeyen hesaplari da izlemek isterseniz “Failure” tanimi da yapmalisiniz. Neleri Audit edecegimiz (Delete, Write) önemlidir çünkü ne kadar fazla SACL girilirse, Security event’leri bir o kadar artar ve isimize yarayacak bilgilerin event dosya boyutunu büyüklügünün çabuk dolmasiyla silinmesini istemeyiz.

Artik yapmamiz gereken izlemek olacaktir. Akla gelen soru belli: Hangi eventleri izleyecegiz?

2003 sunucu üzerinde izleme yapiyorsaniz, 566; 2008 sunucu üzerinde izleme yapiyorsaniz 4662 ID numarali eventleri takip etmeniz gerekiyor. Örnek bir Audit event’I asagida bulabilirsiniz.

 

Subject :

  Security ID: S-1-5-21-2344108740-3013817150-2900169035-16685

  Account Name: (Sistem Adi veya Kullanici Adi)

  Account Domain: <DomainName>

 

Object:

  Object Server: DS

  Object Type: dnsNode

  Object Name: DC=test,DC=domain.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domain,DC=com

  or the GUID = {38173e3c-1083-4871-9f95-301f120a2a61}

 

Operation:

             Operation Type: Object Access

          Accesses: Write Property

                                               

             Access Mask: 0x20

             Properties: Write Property

               {e0fa1e69-9b45-11d0-afdd-00c04fd930c9} dnsRecord attribute ait GUID

               {d5eb2eb7-be4e-463b-a214-634a44d7392e} dnsTombstoned attribute ait GUID

  {e0fa1e8c-9b45-11d0-afdd-00c04fd930c9} dnsNode attribute ait GUID

 

Bizi ilgilendiren 3 sey:

  1. Kim = Account Name
  2. Silinen DNS Node = Object Name
  3. Hangi operasyon = Write Property = TombStoned attribute

 

Yukarida ki örnekte görüldügü gibi Account Name bize kimin sildigini söyleyecek. Burada bir kullanici hesabi görüyorsaniz, bu muhtemelen “elle” silinmeyi isaret etmektedir. Çünkü genelde birçok servis Local System account ile çalismaktadir ve Vista sonrasinda Network üzerinden görüsme yapan Local System account bilgisayar adi ile authenticate olmaktadir.

Eger DC adini görüyorsaniz, muhtemelen ya scavenging ya da replication’dir. Scavenging ayarlarini kontrol ederek hangi DNS sunucusunun scavenger oldugunu bulmali ve degerleri kontrol etmelisiniz. Üzerinde scavenging etkinlestirilen tüm DNS sunuculari scavenger’dir. Bizim tavsiyemiz ayni domain altinda sadece bir sunucunun scavenger olarak çalismasidir. Aging ve scavenging birkaç cümle ile anlatilacak bir özellik degildir; sanirim o konuyu baska bir yaziya birakacagim. Ama bilmeniz gereken varsayilan degerleri ile 8 günlük IP kiralamanin saglandgi bir ortamda 7’ser günlük no refresh ve refresh zamanlari yeterli olacaktir. Daha fazla bilgi için bakiniz.

Makinenin kendi adini görüyorsaniz, bu tamamen normal olabilir. Sistem kapanip adresi siliyor olabilir. Sistem kapali iken DNS/IP eslestirmesinin çalismamasi en son üzüleceginiz sey olacaktir. Ancak bunun böyle olup, olmadigini ya da olmasini isteyip istemediginizi daha fazla arastirmaniz gerekir. Tabii KB2520155 makalesinde belirtilen kod güncellestirmesinin yapildigini varsayiyorum.

Örnekte gördügünüz gibi Attribute isimleri yerine GUID’leri yer almaktadir. Bizi ilgilendiren dNSTombstoned attribute’dur. DNS kayitlarinin silinmesi Active Directory’de yer alan diger kayitlarin silinmesinden biraz farklidir. AD’de bir obje silindiginde isDeleted attribute’un degeri TRUE olarak degistirilir. Sonrasinda objenin birçok diger attribute’u silinir ve adi degistirilerek Deleted Objects container’in altina tasinir. Bu objeye tombstone denmektedir ve amaç replikasyon ile bu objenin tüm DC’lere dagitilmasi ve DC’lerin kendi veritabanlarinda bu objenin silmesini saglanmasidir. Tombstone lifetime (2008, 180 gün) sonrasinda bu obje tamamen silinir. Silinememesi halinde ise hayatina lingering object olarak devam eder. Bu da ayri bir yazinin konusu olabilir.

AD-Integrated bir zone altinda bulunan DNS kayitlarinin silinmesi ise bu prosesden önce farkli bir proses izler. Her DNS objesinin artik dnsTombstoned attribute’u vardir. Eger elle konsol üzerinden veya sistemin kendisi TTL=0 olan bir update gönderirse veya scavenging kaydin silinmesine karar verirse bu attribute’un degeri TRUE olarak degistirilir. Bu durumda obke diger AD objeleri gibi “silinmis” olarak düsünülmez. Ancak DNS konsolu bu kayitlari yüklemeyecektir. Eger ayni kayit “elle” tekrar yaratilirsa veya sistemin kendisi (ya da DHCP) bir güncellestirme gönderirse, sadece bu attribute degistirilerek kaydin yeniden DNS’e yüklenmesi saglanabilir. Eger kayit 7 gün boyunca dnsTombstoned degeri TRUE olarak kalirsa, sonrasinda diger AD objelerinin silinmesinde izlenen yol izlenecektir. Bu nedenle event’I izlerken DELETED property’si yerine Write Property degerine bakmaktayiz. Zaten properties altinda da dnsTombstoned ‘un GUID’ini görmeniz gerekir. Aksi halde IP adres veya timestamp degisikligi gibi degisiklikler sizi yaniltabilir. Hepsi event 4662’dir ancak önemli olan hangi attribute’un güncellendigidir.

Replikasyonun her zaman masum olmadigindan bahsetmistim. Bunun nedeni SRV gibi DNS kayitlarinin birden fazla dnsRecord içeren tek bir DNS Node altinda tutuluyor olmasidir. Yani 10 tane DC’ye ait bir Kerberos SRV kaydi aslinda AD üzerinde sadece bir kayittir. Eger bu dnsRecord’lardan bir tanesi güncellenirse, tüm objenin versiyon numarasi degisir. Bu durumda, bir DC’nin SRV kaydini bulundurmayan baska bir DC, üçüncü bir DC’nin SRV kayit degisikligini daha yeni olmasiyla, replikasyon sonucunda SRV kaydini silebilir. Bunu farketmeyebilirsiniz çünkü NetLogon servisi her 24 saatte bir kayitlari yenilemektedir.

Umarim bu bilgiler silinen kayitlarin takibi için size yol gösterecektir. Iyi avlanmalar…

Okan ÇETINIM