Bilginin Adresi Ana Sayfa
Forum Anasayfası Forum Anasayfası > Bilgisayar Güvenliği / Computer Security > Güvenlik / Security Makaleleri
  Aktif Konular Aktif Konular RSS - Windows Server  Salt Okunur Etki Alanı Denetçileri
  SSS SSS  Forumu Ara   Events   Kayıt Ol Kayıt Ol  GiriÅŸ GiriÅŸ

Windows Server Salt Okunur Etki Alanı Denetçileri

 Yanıt Yaz Yanıt Yaz
Yazar
Mesaj
megabros Açılır Kutu Gör
Security Professional
Security Professional
Simge

Kayıt Tarihi: 08-06-2009
Konum: Turkey
Status: Aktif DeÄŸil
Points: 752
Mesaj Seçenekleri Mesaj Seçenekleri   Thanks (0) Thanks(0)   Alıntı megabros Alıntı  Yanıt YazCevapla Mesajın Direkt Linki Konu: Windows Server Salt Okunur Etki Alanı Denetçileri
    Gönderim Zamanı: 23-08-2009 Saat 13:07

Bu makalede Windows Server 2008 işletim sistemiyle beraber gelen ve güvenlik açısından düşünüldüğünde oldukça faydalı bir özellik olan Salt Okunur Etki Alanı Denetçileri (Read-Only Domain Controllers – RODCs) ele alınmıştır.Özellikle Kamu kurumlarıda kullanımıyla sağlanacak faydaların üzerinde durulmuş, kullanımında karşılaşılabilecek sorunlar irdelenmiştir.

Ülkemizdeki kamu kurumlarının yapısı düşünüldüğünde genelde Ankara’da merkez bir binadan ve taşrada birçok şubeden oluştukları söylenebilir. Sistem denetlemesini yaptığımız bir çok kamu kurumunda merkez binanın bilişim sisteminin sahip olduğu güvenlik imkanlarının taşraya pek yayılamadığını rahatlıkla söyleyebiliriz. Dolayısıyla, “bu kurumların sahip oldukları güvenlik derecesini, en zayıf halkaları olarak nitelendirebileceğimiz taşradaki şubeleri belirler”, demek pek de yanlış olmaz. Özellikle fiziksel güvenlik ele alındığında taşradaki şubelerin bu konuda oldukça zayıf kaldığı söylenebilir. Taşradaki şubelerin genel özelliklerini şu şekilde sıralayabiliriz:

  • Daha az kullanıcıya sahiptirler.

  • Fiziksel güvenlikleri merkez teşkilata göre daha zayıftır.

  • Daha düşük band genişliğine sahiptirler.

  • Bilgi işlem personelinin bilgi ve tecrübesi yetersizdir. Bazı şubelerde böyle bir personel dahi bulunmaz.

İşte bu noktada RODC’lerin önemi ortaya çıkmaktadır. RODC’lerin amacı, şubelerde ne meydana geliyorsa, onun orada kalması olarak özetlenebilir. Kamu kurumlarının taşradaki şubelerinde elbette bir etki alanı denetçisi (DC – Domain Controller) ihtiyacı olacaktır. Fakat bu şubelerin fiziksel güvenliği yeterince sağlanamadığından, yazılabilir bir DC kurmak yerine bir RODC kurmak daha uygun olacaktır. Böylece daha gelişmiş güvenlik özellikleri, daha kısa sisteme giriş süreleri ve ağ üzerindeki kaynaklara daha verimli erişim sağlanmış olacaktır.

Bir RODC’ye sahip olabilmek için Windows Server 2003 orman fonksiyonel seviyeye (forest functional level) ve en az bir adet Windows Server 2008 DC’ye sahip olmak gerekmektedir. Windows 2008 aktif dizin kurulumu esnasında Şekil-1’deki pencere karşımıza çıkacaktır. Şekilden de görüldüğü gibi ağacımızdaki ilk DC’yi (FDC de diyebiliriz – Full Domain Controller) oluşturacağımız için RODC seçeneği pasif durumda gözükmektedir.

 

RODC’ler kullanıcı hesabı şifre özetleri (RODC ile aynı sitede olan kullanıcı ve bilgisayarlar hariç) haricinde yazılabilir bir DC’de tutulan tüm nesne ve özellikleri (attributes) barındırır. Veritabanında bir değişiklik olacağı zaman RODC üzerinde direkt bir değişiklik yapılmaz. Yazılabilir DC üzerinde değişiklik yapılır, daha sonra bu değişiklik RODC’ye replike edilir.

Aktif dizini kullanan bazı uygulamalara ait örneğin şifreler ya da kimlik bilgileri gibi kritik bilgiler olabilir. RODC’nin ele geçirilmesi durumunda bu bilgilerin saldırganın eline geçmesini engellemek gerekecektir. Bu gibi durumlar için RODC’ye replike edilmeyen bir grup özellik konfigürasyonu yapmak mümkündür. İşte bu özellik kümesine RODC filtrelenmiş özellik kümesi (RODC filtered attribute set – RO-FAS) adı verilir. RO-FAS’a özellik atamak için aktif dizin şemasında searchFlags özelliğinin 9. biti (0×0200) set edilir.

Ele geçirilmiş bir RODC, kritik hesaplar için şifre özeti talep edebilir. Bunu engellemek için sistem yöneticisi her RODC için ADSI EDIT ile veya Active Directory Users and Computers bileşeni üzerinden bir şifre replikasyon politikası oluşturabilir. Bu politikaların iki özelliği vardır:

  • msDS-RevealOnDemandGroup: RODC’de belleklenmeye müsait kullanıcıların, grupların ya da bilgisayar hesaplarının isimlerini içerir. (tipik olarak RODC ile aynı sitede olan kullanıcı ve bilgisayarlar)
  • msDS-NeverRevealGroup: Belleklenmeyecek hesapları içerir. (örneğin domain admin hesabı)

Diğer önemli özellikler de:

  • msDS-AuthenticatedAtDC: RODC’de şifre özetleri tutulmayan hesapları listeler.

  • msDS-RevealedList: RODC’de tutulan şifre özetlerini listeler.

RODC üzerinde herhangi bir değişiklik yapılmadığından, RODC’den dışarıya doğru bir replikasyona gerek kalmamakta, replikasyon sadece RODC’ye doğru yapılmaktadır, dolayısıyla tek yönlü bir replikasyon söz konusu olmaktadır. Bu da zaten düşük bandgenişliğine sahip olan taşra şubelerindeki ağ yükünü azaltan bir avantaj olarak gözükmektedir. 

Kullanıcılara ait şifre özetleri, bir DC’de tutulan yegane kritik değerler değildir. KrbTGT hesabı her bir DC’de çalışan Kerberos Key Distribution Center (KDC) servisi için anahtarlar içerir. Tipik olarak domaindeki her bir KDC aynı KrbTGT hesabını paylaşır. Dolayısıyla saldırgan DC’yi ele geçirdiğinde bu hesapları da ele geçirmiş olur ve etki alanının tümüne saldırabilir. Fakat yeni sistemde her bir RODC’nin kendine ait KrbTGT hesabı vardır.

RODC’lerin bir başka özelliği de, FDC’lerin aslında RODC’leri etki alanı denetçisi olarak güvenilir görmemeleri (not trusted), RODC’leri member server olarak görmeleridir. Bir RODC “enterprise domain controllers” ve “domain controllers” gruplarına üye değildir.

RODC’ler salt okunur çalıştıkları ve diğer DC’ler RODC’lerden replike olmadıkları için RODC’lerin bazı tuhaf davranışları da mevcuttur:

  • RODC’lerde yavaşça kaybolan nesnelerin (lingering objects) sezimi mümkün değildir. Yavaşça kaybolan nesneler genelde, “tombstone” durumuna düşmüş DC’lerde görülmektedir.

  • RODC’ler LDAP güncelleme işlemi (add, modify, delete, rename, move) hizmeti vermezler. Bu durumda RODC’ler bir hata döner ve bu hizmeti verebilecek bir DC’ye işlemi havale ederler. Havale işlemi uygun şekilde ele alınmazsa uygulamalar başarısızlıkla sonuçlanabilir.

  • Ağaç içerisindeki bir başka etki alanından RODC’ye kimlik doğrulaması yapıldığında eğer RODC ile FDC arasında bir ağ sorunu varsa kimlik doğrulama gerçekleşmeyecektir.

Sonuç olarak RODC yapısının Türkiye’deki merkez-taşra yapısına sahip olan ve özellikle taşra tarafında fiziksel güvenlik zaafları bulunan kurumlar için oldukça yararlı olduğu düşünülmektedir.

Saygılar..
Yukarı Dön
 Yanıt Yaz Yanıt Yaz

Forum Atla Forum İzinleri Açılır Kutu Gör



Bu Sayfa 0.195 Saniyede Yüklendi.