MS14-068 Kritik Windows Güncellemesi ve Zafiyetin İstismarı

MS14-068 Kritik Windows Güncellemesi ve Zafiyetin İstismarı

Microsoft tarafından MS14-068 hak yükseltme zafiyetine ait bülten 18 Kasım 2014 tarihinde yayınlanmıştı. Zafiyete ait güncelleme KB3011780 güncelleme paketi bulunmaktadır. Bu paketin sistemde mevcudiyetini kontrol etmek için bağlantıdaki Powershell betiği kullanılabilir veya daha basit olarak aşağıdaki komut çalıştırılabilir:

wmic qfe where HotFixID="KB3011780" get Caption, HotFixID

Yazının devamı için bakınız:
http://www.siberportal.org/blue-team/securing-microsoft-domain-environment/mitigating-the-vulnerability-in-kerberos-could-allow-elevation-of-privilege-ms14-068/
ve
http://www.siberportal.org/red-team/microsoft-domain-environment-penetration-tests/obtaining-domain-admin-privileges-by-exploiting-ms14-068-vulnerability-with-the-python-kerberos-exploitation-kit-pykek/
ve
http://www.siberportal.org/blue-team/securing-microsoft-domain-environment/analysis-vulnerability-in-kerberos-could-allow-elevation-of-privilege-ms14-068/

Aktif Dizin Nesnelerine Ait Denetimler İçin Temel Kontroller

Aktif Dizin Nesnelerine Ait Denetimler İçin Temel Kontroller

Etki alanı (Domain), bir grup bilgisayarın bir araya gelmesiyle oluşan belli kurallar ve prosedürlerle bir merkezden yönetilen mantıksal bir yapıdır. Orta ve büyük ölçekli bütün kurumlarda sistemlerin neredeyse tamamı Microsoft etki alanı yapısıyla direk olarak yönetilirler veya etki alanındaki nesneler (sistem yöneticilerinin hesabı vs) tarafından dolaylı olarak yönetilirler. Bu sebeple, etki alanının güvenilir bir şekilde oluşturulması, yönetilmesi ve korunması kurum için oldukça önemlidir. Etki alanı güvenliğini sağlamak ve kurum etki alanındaki sistemlere karşı yapılabilecek saldırılar için alınması gereken temel önlemler “Etki Alanı Saldırılarına Karşı Temel Korunma Yöntemleri” yazılarında [1] [2] özetlenmişti. Bu yazıda ise etki alanındaki nesnelerin yönetildiği dizin hizmeti olan Aktif Dizin denetimleri incelenecektir. Bu amaçla öncelikle Aktif Dizin kavramından bahsedilecek, daha sonra da Aktif Dizin denetimleri için kontrol maddeleri listelenecektir.

Aktif Dizin Nedir?

Aktif Dizin Servisi (Active Directory Domain Service), Windows Server 2000 ile kullanılmaya başlanan ve etki alanındaki fiziksel ve mantıksal nesnelerin (ve bu nesnelere ait özelliklerin) oluşturulduğu, yönetildiği, ilkelerin belirlendiği, sorgulandığı merkezi dizin servisidir. Aktif Dizin üzerinde tutulan temel nesneler aşağıdaki gibidir:

• Kullanıcılar (kullanıcı hesapları)
• Gruplar (yöneticiler, operatörler, kullanıcı grupları vb.)
• Bilgisayarlar
• Yazıcılar
• Sunucular
• Etki alanları
• Site’lar

Aktif Dizin servisi, ağ kaynaklarına ait bilgileri kendine ait bir veritabanında (NTDS) tutar, merkezi olarak organize eder, kullanıcıların yetkileri dahilinde erişimlerini denetler. Aktif Dizin servisi, Microsoft sistemlerinin bulunduğu ortamlarda bir çok yarar sağlamaktadır. Bu yararlardan bazıları şunlardır:

• Merkezi yönetim
• Ölçeklenebilirlik
• DNS ile entegrasyon
• Politika-tabanlı yönetim
• Multi-master replikasyon
• Esnek kimlik doğrulama ve yetkilendirme
• Diğer dizin servisleriyle birlikte çalışabilme
• İmzalanmış ve şifrelenmiş LDAP trafiği
• Betikler ile yönetim

Aktif Dizin Kontrol Maddeleri

Aktif Dizin üzerindeki nesnelerin güvenilir bir şekilde yönetilmesi için bir takım kontrol maddeleri bu başlık altında belirtilmiştir. Kontrol maddelerinde ne yapılması gerektiği üzerinde durulmuş olup, nasıl yapılacağı konusu sistem yöneticilerine bırakılmıştır. Kontrol maddelerinde belirtilen nesnelerin otomatik olarak nasıl  tespit edileceği ile ilgili internet üzerinde - başta Powershell olmak üzere - bir çok betik bulunabilir. Ayrıca aşağıdaki maddeleri ve çok daha fazlasını gerçekleştirebilen otomatik denetim araçları da kullanılabilir.

Denetim sonucunda gerçekleştirilmesi gereken işlemler kurum politikasında belirtilmelidir. Örneğin, uzun süre oturum açmayan kullanıcı hesapları tespit edildikten sonra bu hesaplar belli bir süre boyunca devre dışı bırakılabilir ve bir süre sonra da tamamen silinebilir. Benzer olarak tespit edilen nesnelerin ne zaman, hangi kullanıcı tarafından oluşturulduğu da incelenebilir.

Aktif Dizin güvenliği için kontrol edilebilecek temel maddeler aşağıdaki gibidir:

1) Ortak Hesap Kullanan Kullanıcı Hesapları

Ortak hesap kullanımı özellikle yardım masası veya teknik destek gibi vardiyalı çalışan bölümlerde sık karşılaşılabilen durumlardandır. Kurum içerisinde ortak kullanılan kullanıcı hesapları tespit edilmelidir. Aksi halde işlemi gerçekleştiren kullanıcının kimliğinin tespit edilmesi kaydı tutulan başka faktörlerle (IP adresi, çalışılan saat dilimi, …) mümkün olabilmektedir.

2) Uzun Süredir Oturum Açmamış Kullanıcı Hesapları

Kurum içerisinde uzun bir süre (3 hafta gibi) oturum açmayan kullanıcı hesapları tespit edilmelidir. Bu süre kurum politikasına göre değişiklik gösterebilir. Tatil izinleri, yurt dışı gezileri gibi durumlar göz önüne alınarak bu süre ve kapsam belirlenmelidir.

3) Parolasını Hiç Değiştirmemiş Olan Kullanıcı Hesapları

Bir çok kurumda bir kullanıcı hesabı oluşturulurken standart bir parola ile oluşturulurlar. Bu parola o hesabın sahibi olan kullanıcı tarafından ilk oturumda değiştirilmesi gerekmektedir. Parolasını hiç değiştirmemiş olan kullanıcı hesapları tespit edilmelidir.

4) Uzun Süredir Parolasını Değiştirmeyen Kullanıcı Hesapları

Kurum politikasına uygun olacak şekilde kurum içerisinde bir parola politikası oluşturulmalı ve uygulanmalıdır. Parola politikasında parola değiştirme süresi için uygun bir değer verilmelidir. Belirlenen süre boyunca parolasını değiştirmeyen kullanıcı hesapları tespit edilmelidir. Uzun süredir parolasını değiştirmeyen ve parolası saldırganlar tarafından bir şekilde ele geçirilmiş olan bu kullanıcı hesapları etki alanına karşı gerçekleştirilebilecek sonraki saldırılarda kullanılabilmektedir.

5) Parolasını Değiştiremeyen Kullanıcı Hesapları

Uygulama/servis kullanıcıları veya belirli sebeplerle bazı kullanıcı hesaplarının parolalarının değiştirilmemesi gerekebilmektedir. Parolasını değiştiremeyen kullanıcı hesapları tespit edilmelidir.

6) Parola Değiştirmesi Zorunlu Olmayan Kullanıcı Hesapları

Başta uygulama ve servis kullanıcı hesapları olmak üzere, parola politikasına rağmen parola değiştirmesi zorunlu olmayan kullanıcı hesapları tespit edilmelidir.

7) Parolası Sona Ermeyen Kullanıcı Hesapları

Parola politikasına rağmen parolası sona ermeyen kullanıcı hesapları tespit edilmelidir. Özellikle uygulama ve servis kullanıcı hesaplarında görülen bu durum saldırı yüzeyini arttırmaktadır.

8) Parolası Olmayan Kullanıcı Hesapları

Parola politikası sebebiyle, kurumlarda çok sık karşılaşılan bir durum olmasa da, parolası boş olan kullanıcı hesaplarının varlığı tespit edilmelidir.

9) Parolası Olmak Zorunda Olmayan Kullanıcı Hesapları

Önceki kontrol maddesine benzer olarak, parolası olmak zorunda olmayan kullanıcı hesapları tespit edilmelidir.

10) Süresi Geçmiş Kullanıcı Hesapları

Kurum politikası gereği bazı kullanıcı hesapları (danışman, sistem destek, stajyer vs) süreli olarak oluşturulabilmektedir. Bu süre sonrasında bu hesaplar ile işlem yapılamamaktadır. Kurumda süresi geçmiş olan (expire) kullanıcı hesapları tespit edilmelidir.

11) İşten Ayrılmış Kullanıcı Hesapları

Kurumların çoğunda merkezi kimlik yönetimi henüz tam anlamıyla aktif bir şekilde kullanılmamaktadır. İşten ayrılmış olan kullanıcı hesabı ile gerçekleştirilebilecek işlemler sonucunda  kurum ve kurum çalışanları zor durumda kalabilmektedir. Bu sebeple, kurum ile ilişkisi kesilen kullanıcı hesapları tespit edilmelidir. Bunun yanında yetkilendirme işlemleri için kullanıcıdan bağımsız tasarımların kullanılması [3] [4] güvenliği arttırmaktadır.

12) Kurum Personeli Olmayan Kullanıcı Hesapları

Danışmanlık, sistem destek, stajyerlik gibi sebeplerle etki alanında oluşturulan kullanıcı hesapları tespit edilmelidir. Bu hesaplar oluşturulurken süreli bir şekilde oluşturulması tavsiye edilmektedir. Ayrıca bu hesaplar için özel yapısal birimlerin (OU) oluşturulması ve bu OU altındaki nesnelere sıkılaştırılmış grup ilkelerinin uygulanması tavsiye edilmektedir.

13) “Users” Konteynırında Bulunan Kullanıcı Hesapları

Bir kullanıcı oluşturulduğunda varsayılan olarak “Users” adlı verilen konteynır altında oluşmaktadır. Bir konteynır içerisindeki nesnelere varsayılan grup ilkeleri uygulandığı için “Users” altında kullanıcı hesabının bulunması kontrol eksiliğine sebep olmaktadır. Bu sebeple, “Users” konteynırında bulunan kullanıcı hesapları tespit edilmelidir. Etki alanına yeni eklenen kullanıcı hesapları üzerindeki denetimleri arttırmak için ve etki alanına eklenen ancak henüz faal olmayan nesneleri daha iyi takip edebilmek için; bu hesapların sıkılaştırılmış bir OU altında oluşturulması tavsiye edilmektedir. Kullanıcı hesabı ile işlem yapıldıktan ve grup ilkesi alındıktan sonra ilgili OU altına eklenmesi güvenliği arttırmaktadır. Sonuç

14) Dial-in Bağlantı Hakkı Olan Kullanıcı Hesapları

Dial-in bağlantı hakkı olan kullanıcılar tespit edilmelidir. Uzak erişimler için dial-in bağlantı yerine kurum ihtiyacına daha güvenilir bir şekilde cevap verecek yöntemler (SSL VPN gibi) tercih edilmelidir.

15) Gereksiz Tanımlama Bilgisine Sahip Olan Kullanıcı Hesapları

Kullanıcı hesaplarına ait bir çok bilgi, herhangi bir kullanıcı tarafından elde edilebilmektedir. Etki alanına gerçekleştirilen saldırılarda da bu bilgiler kullanılmaktadır. Kullanıcı hesaplarına ait gereksiz bilgilerin Aktif Dizin üzerinde saklanmaması tavsiye edilmektedir.

16) Eksik Tanımlama Bilgisine Sahip Olan Kullanıcı Hesapları

Denetim yönü ile ele alındığında, kurum politikası ile belirlenmiş tanımlamalar her kullanıcı hesabında bulunmalı, standart tanımları bulunmayan kullanıcı hesapları tespit edilmelidir.

17) İsimlendirme Standardına Uymayan Kullanıcı Hesapları

Kurum politikası gereği kullanıcı hesaplarının nasıl oluşturulacağı belirlenmelidir. Sicil numarasının kullanılması (36146), personelin ad ve soyadının farklı şekillerde kullanılması (remzi.karadayioglu, rkaradayioglu, r.karadayioglu, karadayioglu.remzi,…) bir standart olarak belirlenmelidir. Bunun yanında aynı isim ve soy isme, iki ve daha fazla isme veya soy isme sahip personel için de standardın oluşturulması tavsiye edilmektedir. Belirlenen isimlendirme standardına uymayan kullanıcı hesapları tespit edilmelidir.

18) Kritik Gruplara Üye Olan Ortak Kullanılan Kullanıcı Hesapları

Etki alanında bazı grupların yetkileri diğerlerinden daha fazla öneme sahip olmaktadır. Bu gruplardan bazıları yerleşik (built-in) gruplar (Domain Admins, Enterprise Admins, …) olabildiği gibi, bazı gruplar (Oracle Admins, Microsoft Sistem Yöneticileri, Aktif Cihaz Yönetim Grubu,… ) ise daha sonradan oluşturulmuş olabilir. Etki alanında kritik yetkilere sahip olan gruplar belirlenmeli ve bu gruplara üye olan kullanıcı hesapları tespit edilmelidir.

19) Hiçbir Gruba Üye Olmayan Kullanıcı Hesapları

Grup üyeliği bulunmayan kullanıcı hesapları tespit edilmelidir.

20) Üyesi Olmayan Gruplar

İçerisinde hiçbir üyesi olmayan, boş gruplar tespit edilmelidir.

21) İsimlendirme Standardına Uymayan Gruplar

Kullanıcı hesaplarında olduğu gibi, kurum tarafından oluşturulmuş olan isimlendirme standardına uygulan gruplar tespit edilmelidir.

22) Kritik Grupların Yetkilendirmeleri

Etki alanında kullanıcı yerine, grup ve rol bazlı bir yetkilendirme yapılması gerektiği daha önceden belirtilmişti. Bu grupların etki alanındaki yetkileri tespit edilmelidir.

23) Uzun Süredir Kullanılmayan Bilgisayar Hesapları

Kullanıcı hesaplarında olduğu gibi, uzun süredir kullanılmayan bilgisayar hesapları tespit edilmelidir.

24) Adı Standarta Uymayan Bilgisayar Hesapları

Kullanıcı hesaplarında ve gruplarda olduğu gibi, kurum tarafından oluşturulmuş olan isimlendirme standardına uygulan gruplar tespit edilmelidir.

25) Devre Dışı Bırakılmış Bilgisayar Hesapları

Kullanıcı hesaplarında olduğu gibi, devre dışı (disabled) bırakılmış olan bilgisayar hesapları tespit edilmelidir.

26) “Computers” Konteynırında Bulunan Bilgisayar Hesapları

“Users” konteynırında bulunan kullanıcı hesaplarında olduğu gibi, “Computers” konteynırında bulunan bilgisayar hesapları tespit edilmelidir.

27) İçerisinde Nesne Bulunmayan Yapısal Birimler

Gruplarda olduğu gibi, içerisinde hiçbir üyesi olmayan, boş yapısal birimler (OU) tespit edilmelidir.

28) Adı Standarta Uymayan Yapısal Birimler

Kullanıcı ve bilgisayar hesaplarında, gruplarda olduğu gibi, kurum tarafından oluşturulmuş olan isimlendirme standardına uygulan gruplar tespit edilmelidir.

29) Site İçerisinde Belirtilmemiş Olan Yerel Ağlar

Site, birbiri ile ağ iletişimi kuvvetli olan fiziksel yapılardır. Site, ağın hızına ve trafik kapasitesine göre tasarlanır. Özellikle oturum açma ve replikasyon işlemlerinin daha hızlı gerçekleşebilmesi için Site yapısının iyi tasarlanması gerekmektedir. Bir Site içerisinde bir veya daha fazla alt ağ (subnet) bulunabilmektedir. Böylece bir kullanıcı aynı site içerisinde bulunduğu etki alanı denetleyicisini (DC) kullanarak kimlik doğrulatır. Benzer olarak bir etki alanı denetleyicisi aynı site içerisindeki bir etki alanı denetleyicisi ile replikasyon işlemini gerçekleştirmek için oluşturulan Site ve Subnet bilgilerini kullanılır. Aynı site içerisinde etki alanı denetleyicisi bulunamazsa, farklı site üzerindeki etki alanı denetleyicisi arayışında bulunulur.

Kurum içerisindeki her bir yerel ağ (LAN), içerisinde etki alanı denetleyicisi bulundurmasa dahi, Aktif Dizin üzerinde tanımlanması tavsiye edilmektedir. Bu sebeple, Site içerisinde belirtilmemiş yerel ağlar tespit edilmelidir.

30) DNS Üzerinde Kaydedilmemiş Yerel Ağlar

Alan Adı Sistemi (Domain Name System - DNS); ağdaki bilgisayarları ve ağ hizmetlerini adlandırmak için kullanılan bir sistemdir. DNS, Aktif Dizin yapısı için zorunlu bir roldür. Microsoft ortamlarında, istemciler ağdaki etki alanı denetleyicilerinin ve diğer servis sunucularının yerlerini DNS kullanarak tespit ederler. Eğer DNS üzerinde bir problem oluşursa, erişimlerde problem yaşanacaktır. Aktif Dizin ile entegre olarak oluşturulan Microsoft DNS üzerinde tüm yerel ağlara ait kayıtların bulunması tavsiye edilmektedir. Bu sebeple, DNS üzerinde kayıtlı olmayan kuruma ait yerel ağlar tespit edilmelidir.

Sonuç

Kurum etki alanının (ve dolayısıyla kurumun) güvenliği için alınması gereken önlemlere [1] [2] ek olarak, saldırı yüzeyini daraltmak için belli aralıklarla risk analizleri ve kontroller gerçekleştirilmelidir. Bu yazıda Aktif Dizin sıkılaştırması için gerekli olan temel kontrol maddeleri üzerinde durulmuştur. Bu yazıda bahsi geçen kontrol maddeleri kurum tarafından belli periyotlarla gözden geçirilmesi, ek kontrol maddeleri ile desteklenmesi, otomatikleştirilmesi için betikler (Powershell gibi bir betik dili kullanılarak) hazırlanması veya otomatik olarak bu işlemleri gerçekleştirebilen araçlarla denetimlerin gerçekleştirilmesi, denetim raporu sonucuna göre gerekli iyileştirmelerin kurum politikasına uygun olarak gerçekleştirilmesi, gerçekleştirilen işlemlerin dokümante edilmesi tavsiye edilmektedir.


Kaynaklar

[1] http://www.bilgiguvenligi.gov.tr/microsoft-guvenligi/etki-alani-saldirilarina-karsi-temel-korunma-yontemleri-1.html
[2] http://www.bilgiguvenligi.gov.tr/siniflandirilmamis/etki-alani-saldirilarina-karsi-temel-korunma-yontemleri-2.html
[3] http://itfreetraining.com/70-640/agdlp/
[4] http://itfreetraining.com/70-640/agudlp/

Grup İlkeleri (Preferences) ile Yerel Kullanıcı Parolalarının Ayarlanması ve Bu Özelliğin Kötüye Kullanılması

Grup İlkeleri (Preferences) ile Yerel Kullanıcı Parolalarının Ayarlanması ve Bu Özelliğin Kötüye Kullanılması

Grup ilkeleri Policy ve Preferences olmak üzere iki şekilde kullanılır. Eğer kullanıcı isteğine bırakılmadan bir ilkenin grup ilkeleri ile ayarlanması isteniyorsa Policy kullanılır. Eğer kullanıcı tarafından değişiklik yapılmasına izin verilecek ayarlar yapılacak ise Preferences tercih edilir.

Preferences ile yerel kullanıcı ve grupların bir takım özellikleri ayarlanabilir. Bu özelliklerden birisi de yerel kullanıcıların parolasıdır. Böylelikle, yerel kullanıcıların parolası merkezi bir şekilde yönetilebilir. Ancak bu ayarın yapılması durumunda bu parolalar (parolaların açık hali), etki alanındaki herhangi bir bilgisayardan elde edilebilir.

Bu yazıda Windows Server 2008 R2 olan bir bilgisayar DC olarak kullanılmaktadır. Bu bilgisayarın adı (hostname) "SRV1", oluşturulan etki alanının adı ise "sizma.local" olarak belirlenmiştir.Senaryo için, etki alanında W7 adlı bir bilgisayar ve "Akif Pinar" adlı standart bir etki alanı kullanıcısı kullanılacaktır.

W7 bilgisayar "Orijinal Makineler" adlı bir OU içerisindedir:

"Akif Pinar", "Bilgi Islem" adlı bir OU içerisindedir:

"Akif Pinar" standart bir etki alanı kullanıcısıdır:

Not: W7 bilgisayarında "Akif Pinar" adlı kullanıcı ile oturum açılmasaydı, aşağıda belirtilen modül çalıştırılıp, Preferences içerisindeki parola bilgileri elde edilebilirdi.

Senaryonun en son aşamasında "GPO_AdministratorPassword", "Policy2" ve "Policy3" adlı grup ilkeleri aşağıdaki gibi konumlandırılacaktır.

Ancak ilk durumda "Policy2" ve "Policy3" oluşturulmamış ve herhangi bir OU altına bağlanmamıştır (link edilmemiştir).

İlk durumda, W7 bilgisayarın bulunduğu OU altına sadece "GPO_AdministratorPassword" ilkesi uygulanmaktadır. Bu ilke ile yerel "Administrator" hesabının parolası ayarlanmıştır:

Not: W7 üzerinde oturum açan "Akif Pinar" hesabının bulunduğu OU'ya özel bir politika uygulanmamıştır.

"Akif Pinar" kullanıcısı ile W7 üzerinde oturum açıldığında 5 adet grup ilkesi görülmektedir (\\SRV1\sysvol\sizma.local\Policies dizini altında):

Not: 4. ekran görüntüsünde bulunan Group Policy Management arayüzünde, "Group Policy Objects" altında ilk durumda 5 adet grup ilkesi bulunmaktaydı.

SYSVOL dizini altındaki "Groups.xml" dosyası 2 grup ilkesinde bulunmaktadır. Bunlardan birisi "GPO_AdministratorPassword", diğeri ise "GPO_TubitakDisable" ilkesidir:

Not: Groups.xml haricinde aranabilecek diğer 2 dosya Printers.xml ve Drives.xml dosyalarıdır.

Bu XML dosyalarının içeriği aşağıdaki gibidir:

Yukarıdaki ekran görüntüsünde de görüldüğü gibi, "GPO_TubitakDisable" ilkesi ile "tubitak" adlı yerel kullanıcının hesabı devre dışı bırakılmıştır. Bunun yanında "GPO_AdministratorPassword" ilkesi ile yerel "Administrator" kullanıcısının parolası ayarlanmıştır. Ancak parola açık halde değil, şifreli (değişikliğe uğramış şekilde) olarak "cpassword" değerinin karşısında saklanmaktadır. Kullanılan AES şifresi Microsoft tarafından bağlantıdaki linkte internete sunulmuştur. İnternet üzerindeki betikler kullanılarak cpassword değerinden parolanın açık hali elde edilebilir. Bunun yanında MSF post exploit modülü ile bu işlemler kolay bir şekilde gerçekleştirilebilir.

Bu amaçla öncelikle W7 makinesine Meterpreter oturumu açılır:

Daha sonra da açılan Meterpreter oturumunda post/windows/gather/credentials/gpp modülü (Windows Gather Group Policy Preference Saved Passwords) çalıştırılmak üzere ayarlanır.

Gerekli ayarlamalardan sonra bu modül çalıştırılır:

Yukarıdaki ekran görüntüsünde de görüldüğü gibi, "GPO_AdministratorPassword" ve "GPO_TubitakDisable" grup ilkeleri içerisinde "Groups.xml" dosyaları tespit edilmiştir. Ancak, sadece "GPO_AdministratorPassword" içerisinde parola bilgisi (cpassword) tespit edilmiştir. Tespit edilen bu değer deşifre edilmiş ve yerel "Administrator" kullanıcısının parolası "Test#12345." olarak tespit edilmiştir.

Daha sonra "Policy2" adı verilen grup ilkesi herhengi bir OU için oluşturulmuş ve bu ilke W7 bilgisayarına alınmıştır (gpupdate /force). Bu grup ilkesi; W7 bilgisayarından, "Akif Pinar" oturumunda görülmektedir:

MSF modülünün yeniden çalıştırılmasıyla, W7 bilgisayara ve oturum açan "Akif Pinar" adlı kullanıcıya yeni oluşturulan grup ilkesi uygulanmamasına rağmen, yeni oluşturulan "Policy2" adlı grup ilkesindeki parola bilgisi ("Deneme123456.") elde edilmiştir.

Sonraki aşamada ise, "Policy3" adlı bir grup ilkesi oluşturulmuş hiç bir OU'ya uygulanmamıştır. Bu ilke de W7 bilgisayarına alınmıştır (gpupdate /force). Bu greup ilkesi; W7 bilgisayarından, "Akif Pinar" oturumunda görülmektedir:

MSF modülünün yeniden çalıştırılmasıyla, W7 bilgisayara ve oturum açan "Akif Pinar" adlı kullanıcıya yeni oluşturulan grup ilkesi uygulanmamasına rağmen, yeni oluşturulan "Policy3" adlı grup ilkesindeki parola bilgisi ("Misafir123") elde edilmiştir.

Sonuç:

• Preferences kullanılarak yerel kullanıcıların parolaları ayarlanmamalıdır.
• Gereksiz grup ilkeleri oluşturulmamalıdır.
• Grup ilkeleri üzerindeki erişim ayarları (ACL) uygun şekilde yapılandırılmalıdır.
• MS14-025 zafiyeti kapatılmalıdır. Bu amaçla, KB2962486 güvenlik yaması geçilmelidir.

Exchange Server: Information Rights Management (IRM)

Exchange Server: Information Rights Management (IRM)

Mesajlaşma güvenliği için kullanılan tekniklerin bir takım eksiklikleri bulunmaktadır. Örneğin, TLS ile, iki SMTP makinesi arasındaki SMTP trafiği korunabilmektedir. Posta seviyesinde bir koruma gerçekleştirilememektedir. Posta, istemci tarafına ulaştıktan sonra herhangi bir koruma sağlamamaktadır. S/MIME ile PKI kurulmasında ise özel anahtarların saklanması, yapılan işlemlerin maliyeti problem olmaktadır. Bunun yanında posta deşifre edildikten sonra herhangi bir kontrol mekanizması da sunulmamaktadır. Posta şifresiz olarak kopyalanabilir, çıktı olarak alınabilir veya bir başka kullanıcıya iletilebilir. Kısacası, TLS ve S/MIME gibi güvenlik metotlarının belirtilen sınırları için yeni bir teknik uygulanmaya başlanmıştır: Information Rights Management (IRM)
IRM ile veri kaçağına, imaj kaybına, finansal kayba karşı önlem alınır.

IRM ile posta gönderildikten sonra, alıcı tarafında posta içeriği ve ekleri üzerinde ne gibi işlemlerin gerçekleştirilebileceği belirlenebilir. IRM kısıtları şu şekildedir (Bunlar AD RMS için geçerli):

• Full Control: Her işlem gerçekleştirilebilir.
• View: İçerik açılabilir.
• Edit: İçerik değiştirilebilir.
• Save: Kaydedilebilir.
• Copy: İçerik kopyalanabilir.
• Save: Kaydedilebilir.
• Print: İçerik çıktısı alınabilir.
• Access the message programmatically: Makro gibi programlar çalıştırılabilir.
• Forward: Posta iletilebilir.
• Reply: Gönderene cevap verilebilir.
• Reply All: Gönderene alıcı listesindekilerle beraber cevap gönderilebilir.

IRM ajanları HTS üzerinde çalışır. Bunun yanında, Active Directory Rights Management Services (AD RMS) ile de kullanılabilir. IRM koruması, AD RMS ilkelerinde belirlenerek gerçekleştirilir. IRM koruması Exchange Server 2010 ortamında şu yollarla gerçekleştirilebilir:

• Outlook kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler.
• OWA kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler.
• ActiveSync aygıtları ve Windows Mobile kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler. Windows mobile desteği olmayan cihazlarla da bu mesajlar alınabilir ve görüntülenebilir. Bunun için posta indirilmeden önce CAS’a SSL ile bağlanılmalıdır. Posta şifresi bağlantı kurulduktan sonra  çözülmektedir.
• Outlook 2010 kullanıcıları kural oluşturarak otomatik olarak IRM korumalı posta oluşturabilirler.
• Exchange Server 2010 HTS rolüne sahip sunucuda iletim kuralları ile otomatik olarak IRM korumalı posta oluşturulabilinir. 

IRM korumalı posta iletişimi organizasyon dahilindeki etki alanında, farklı forest’ları arasında, bulut tabanlı Exchange ortamları arasında gerçekleşebilir. Farklı bir federasyonda veya güven ilişkisinin olmadığı sistemlerle olan iletişimde kullanılamaz. Kullanılması için Windows Live ID hesabı ile AD RMS arasında bir güven kurulabilir.
IRM ile posta içeriğinin organizasyon tarafınca okunabileceği de unutulmamalıdır. Bu sebeple, S/MIME koruması aksine, IRM korumalı içerik deşifre edilerek taranabilir, politikalara göre filtreleme gerçekleştirilebilir. Ayrıca yasal denetimler için de kullanılabilir.

IRM’in eksiklikleri şunlardır:

• Postanın Windows Snipping Tool harici 3. taraf bir ekran kopyalama aracı ile ekran görüntüsü alınabilir.
• Kamera veya fotoğraf makinesi ile posta görüntülenebilir.
• El ile yazılarak veya ezberlenerek veri kaçağı gerçekleşebilir.
• Bir zararlı tarafından posta içeriği silinebilir, çalınabilir, bozulabilir.

Exchange Server: Sertifikalar && S/MIME

Exchange Server: Sertifikalar && S/MIME

Sertifikalar
Mail iletişimini daha güvenilir hale getirmek için sertifikalar kullanılabilmektedir. Exchange Server 2000 ve 2003 ortamlarında sertifika kullanımı yaygın olmamakla birlikte IIS üzerinde manuel olarak gerçekleştiriliyordu. Exchenge Server 2007 ile birlikte bu işlemler Exchange Management Console ve Exchange Management Shell üzerinde daha basit adımlar ile gerçeklenmeye başlamıştır.

Exchange Server 2010 üzerinde sertifika 5 servis için oluşturulabilmektedir. Bu servisler şunlardır:

• IMAP
• POP
• SMTP
• IIS (HTTP)
• UM (Unified Messaging)

Bu trafikler ve kullanan bileşenler şu şekildedir:

• SMTP: HTS ve ETS arasında veya ortak organizasyonlar arasındaki SMTP trafiğinde kimlik doğrulama ve şifreleme sağlamak için kullanılır.
• EdgeSync Senkronizasyonu: HTS ve ETS arasındaki LSAP iletişimini şifrelemede kullanılır.
• UM: UMS rolündeki sunucudan HTS rolündeki sunucuya, IP giriş kapılarına (gateway) ve Ofis İletişim Sunucuları’na (Office Communication Servers) giden SMTP trafiğini şifrelemek için kullanılır.
• Autodiscover: CAS ve istemci arasındaki HTTPS trafiğini şifrelemek için kullanılır.
• POP3/IMAP4: Posta alınması sürecinde şifreleme ve kimlik doğrulama için kullanılır.
• Outlook Anywhere: CAS rolündeki sunucudan istemciye giden trafik güvenliğini sağlamak için kullanılır.
• OWA: CAS rolündeki sunucudan istemciye giden HTTP trafiğinin güvenliğini sağlamak için kullanılır.
• ActiveSycn: CAS rolündeki sunucudan istemciye giden HTTP trafiğinin güvenliğini sağlamak için kullanılır.

Kullanılan sertifika güvenilir bir sertifika otoritesi tarafından onaylanmış olabileceği gibi, kendimiz de bir sertifika oluşturabiliriz. Kendimizin onaylayacağı sertifikada bir uyarı mesajının çıkabileceği, bu uyarı mesajını almamak için istemcilere onaylayıcının sertifikasının yüklenmesi gerektiği unutulmamalıdır. İç sistemlerde kendimizin imzaladığı, dış sistemlerde ise bir CA tarafından imzalanan sertifikaların kullanılması önerilmektedir.
Kendimizin onayladığı sertifikaları kullanabileceğimiz sistemler şu şekildedir:

• Hub Transport sunucuları arasına
• HTS ve ETS arasında
• EdgeSync trafiği için
• UM trafiği için
• Dahili CAS rolü sunucularında

CA tarafından onaylanan sertifikaları kullanabileceğimiz sistemler şu şekildedir:

• POP3 & IMAP4 trafiği için
• OWA için
• Outlook Anywhere
• ActiveSync için
• Autodiscover için

Ek Bilgiler:

• Exchange Server 2010 kurulumu sırasında varsayılan olarak SMTP sertifikası da oluşturulmuş durumdadır. Ama diğer iletişim protokolleri için sertifikalar, Exchange ortamı yöneticisi tarafından oluşturulmalıdır.
• Exchange Server 2013 kurulumu sırasında MBS üzerinde kendinden imzalı sertifika yüklü olarak gelmektedir. CAS, MBS üzerindeki sertifikaya güvendiği için kullanıcılar herhangi bir sertifika uyarısı almamaktadır.
• Sertifika oluşturulması için bakınız: http://www.cozumpark.com/blogs/exchangeserver/archive/2009/11/22/exchange-2010-sertifika-olu-turma.aspx

Secure/Multipurpose Internet Mail Extensions (S/MIME)
Sayısal imzalama gönderici taraflı kimlik doğrulama, bütünlük ve reddedilemezlik kazandırmak için kullanılan bir çözümdür. Sayısal imza ile, SMTP protokolünde olduğu gibi, posta açık olarak gönderilir. Base64 kodlama gerçekleştirilse bile şifreleme yapılmadığı sürece posta bir başkası tarafından okunabilir. Asimetrik şifreleme ile ise gizlilik, bütünlük ve alıcı taraflı kimlik doğrulama gerçekleştirilmektedir. Posta iletişiminde sayısal imzalama ve şifreleme kullanılması ile güvenlik arttırılması sağlanabilir. Bu amaçla posta içeriğine bir takım eklentiler konulmalıdır. MIME(Multipurpose Internet Mail Extensions) gönderilecek olan postaya resim, ses, görüntü gibi eklentileri eklemek için kullanılan bir internet standardıdır. Bu standarda bahsedilen güvenlik eklentilerinin eklenmesiyle yeni bir standart oluşturulmuştur. Bu standart S/MIME olarak adlandırılmaktadır. S/MIME temelinde asimetrik şifreleme ve sayısal imzalama yatmaktadır. S/MIME ile posta gönderilirken, önce göndericinin özel anahtarı ile imzalanır, sonra da alıcının genel anahtarı ile şifreleme gerçekleştirilir. Bu postayı alınırken, önce alıcının özel anahtarı ile şifre çözülür, sonra da göndericinin genel anahtarı ile doğrulama gerçekleşir. Böylece iki taraflı kimlik doğrulama, gizlilik, bütünlük ve reddedilemezlik sağlanır. Kullanılan sertifikalar etki alanını yöneticisi tarafından imzalanabildiği gibi, uluslar arası sertifika makamları tarafından da imzalanabilmektedir.

Ek Bilgiler:

• Bu şekilde iletişim için posta istemcisinin S/MIME desteğinin olması gerekmektedir. Örneğin, OWA’da, S/MIME ActiveX kontrolü kullanılarak sağlanır. Bu sebeple ActiveX desteği olan bir istemci tercih edilmeli ve ActiveX özelliği açılmalıdır.
• S/MIME desteği ilk olarak Exchange Server 2003 ile birlikte Outlook Web Access için yayınlanmıştı. Günümüzde bu destek gelişerek sürdürülmektedir. S/MIME v3 ile üç sarmallı bir iletişim (Triple-Wrapped Messages) sağlanmaktadır. Bu yapı ile önce imzalama, sonra şifreleme, sonra yine imzalama işlemi gerçekleştirilmektedir.
• S/MIME ile gerçekleşen operasyonlar ile güvenlik sağlandığı gibi, bu operasyonlar istemci tarafında gerçekleştiği için posta sunucusu için herhangi bir işlem maliyeti yoktur. Diğer taraftan, kullanıcıların özel anahtarları etki alanı sunucusunda tutulmadığı durumlarda, sunucu tarafında yöneticilere kontrol eksikliği oluşabilmektedir. Posta sunucusundaki imzalanmış ve şifrelenmiş posta okunamadığı için taşıma kuralları uygulanamaz, Anti-virüs/Anti-spam gibi çözümlerle zararlı tespiti gerçekleştirilemez, veri kaçağı anlaşılamaz. Bu durum da kontrol eksikliğine sebep olabilmekte ve yasal düzenlemelere karşı bulguya sebep olabilmektedir.

Kaynak site:
http://technet.microsoft.com/en-us/library/aa995740(v=exchg.65).aspx

Exchange Server: Anti-Spam Koruması (1)

Exchange Server: Anti-Spam Koruması (1)

Mail aracılığı ile organizasyon sistemine girilmesinin önlemek, istenmeyen postaları istemcinin posta kutusuna ulaşmadan kesmek için exchange ortamında bir takım ayarlamalar yapmak gerekmektedir. Aksi halde sistem kaynakları boşa harcanır, gereksiz bant genişliği azalır, posta kutuları şişer, en kötüsü kullanıcılardan şikayet gelir. Microsoft Exchange Server 2007 üzerindeki AntiSpam yapısı, Exchange Server 2010 geliştirilmiştir. Exchange Server 2010, taşıdığı  Multi-Pronged Anti-Spam altyapısı yönüyle aynı zamanda bir virüs koruma özelliği de sağlamaktadır.

ETS rolündeki sunucu, exchange ortamını SPAM ve virüs gibi zararlılara karşı korumalıdır. Bu sebeple ETS üzerinde Antispam özelliği aktif edilmelidir. Anti-spam ve Antivirüs özellikleri sayesinde spam olarak algılanan mesajlar, zararlı içeriğe sahip mesajlar bu sunucu tarafından filtrelemeye tabi tutulur ve kurallarda tanımlanan düzeneğe göre hareket eder. HTS rolündeki sunucu, ETS rolünden gelen internet postalarını aldığı gibi, yapılabilecek olan ayarlamalar ile internetten gelen postaları direk olarak üzerine de alabilir. Yani ETS rolünün olmadığı durumlarda ETS rolünün görevini HTS gerçekleştirebilir. Bu durumlarda koruma mekanizmaları HTS üzerine kurulmalıdır.
HTS rolü üzerinde aktifleştirilen AntiSpam özelliği ile Akıllı Koruma (Intelligent-Defense) devreye girer. Böylece

• Spam maillerinin hacmi azaltılır.
• Mevcut Spam mailler ortadan kaldırılır.
• Mail için kullanılan disk ve bant genişliği kaynağı düşürülür.

Anti-Spam Filtre Kategorileri
Anti-spam filtreleri çeşitli kategoride uygulanmaktadır. Bu filtrelerin tamamı her SMTP bağlantısında uygulanmaktadır. İnternet ortamındaki bir SMTP sunucusundan alınan bir posta tüm filtrelerden geçtikten sonra HTS rolündeki sunucuya iletilmektedir. Bu filtreler şunlardır:

• Connection Filtering
• Sender Filtering
• Recipient Filtering
• Sender ID Filtering
• Content Filtering
• Sender Reputation
• Attachment Filtering

Microsoft Exchange 2010 Anti Spam korunmasını güçlendirmek ve sürekliliğini sağlamak için haftada veya iki haftada bir güncelleme işlemi gerçekleştirilmelidir. Güncelleme işlemi ile Content Filter (SCL oranlarının güncelliği sağlanır), Spam imzaları, IP Reputation kayıtları (spam posta gönderen IP adres listesinin güncelliği sağlanır) güncellenir. Güncelleme işlemleri için Anti-Spam özelliği etkin olan sunucunun proxy veya direk olarak internete erişmesi veya WSUS ile bağlantılı olması gerekmektedir.
Bunun yanında daha etkin bir koruma için zararlının ilk aşamalarda (connection Filtering aşaması gibi) tespit edilmesi önem arz etmektedir.
Sonuç olarak, organizasyondaki spam etkinliğini azaltmak için sistemi iyi planlamak, yapılandırmak, izlemek ve güncellemek gerektiğini söyleyebiliriz.

Exchange Server: Yapılandırma ve Protokol Güvenliği

Exchange Server: Yapılandırma ve Protokol Güvenliği

Güvenilir Yapılandırma
ETS Yapılandırması

• ETS rolü, diğer sunucu rolleri ile kullanılamaz.
• ETS rolü kurulan sunucu etki alanına dahil olmamalı, çalışma grubu olarak çalışmalıdır. 
• ETS hem Internet’teki tüm domain isimlerini çözümleyebilmeli hem de iç ağdaki HTS rolüne sahip sunucuya ulaşabilmelidir.
• ETS rolü zorunlu olmamakla birlikte, DMZ bölgesinde konumlandırılmalıdır. Bu sunucunun biri iç ağa, diğeri dış ağa bakan iki ağ arayüzü olmalıdır. Arkasında ve önünde farklı markaların güvenlik duvarları gibi koruyucu mekanizmaları bulunmalıdır. 

ETS rolünün bu şekilde yapılandırılmasını temel yararları şu şekildedir:

• ETS üzerinde herhangi bir şekilde kullanıcı bilgisi bulunmadığı ve etki alanına dahil olmadığı için, sunucu bir şekilde ele geçirilse bile saldırı alanı daraltılmış olacaktır. 
• Benzer şekilde kimlik doğrulaması işlemi ETS üzerinde gerçekleşmediği için arka taraftaki sistemlere gelen tüm isteklerin kimlik doğrulaması yapmış kullanıcılardan gelmesi sağlanır.
• İstemciler posta kutularının bulunduğu sunucu bilgilerini bilmesine gerek kalmadan tüm isteklerini ETS üzerinden gerçekleştirebilmektedir. Böylece arka taraftaki sisteme gerçekleşebilecek saldırı yüzeyi azalmaktadır.
• İstemciler sadece ETS rolüne sahip sunucunun alan adı ile işlemlerini gerçekleştirirler. Arka sistemde yapılacak bir değişiklik istemciye yansımayacaktır. Böylece esneklik sağlanmaktadır.

Diğer Sunucu Rollerinin Yapılandırılması

• CAS rolü, MB rolü ile farklı sunucularda kurulmuş ise aralarındaki bağlantının hızlı olması performansı arttırır.
• HTS, AD sorgularını Global Catalog Server üzerinde gerçekleştirir. Bu sebeple, HTS ve GCS aynı Aktif Dizin Site içerisinde yer almalıdır.
• HTS, AD sorgularını hızlı gerçekleştirmeli ve bu sorgulara hızlı cevap almalıdır. Bu sebeple, HTS ve AD arasındaki bağlantı hızlı olmalıdır.
• MBS rolünün olduğu her AD sitesinde ve Exchange organizasyonunda birer tane CAS ve HTS rolünde sunucu kurulması tavsiye edilmektedir.

MBS, CAS ve HTS rolleri olmazsa olmaz rollerdir ve temel Exchange yapısının vazgeçilmezleridir. Bu üç rolü aynı sunucu yada farklı sunuculara kurulabilir. Rollerin ayrı sunucularda tutulması maliyeti arttırsa da güvenliği de arttırmaktadır. Rollerin farklı sunucularda yapılandırılmasının 3 temel nedeni şunlardır:

• Enhanced Scalability (Ölçeklendirilebilirlik): Her rol farklı sunucu üzerinde kurulabilir ve her rol için için özel olarak ayarlar yaparak yüksek bir performans sağlanabilir.
• Improved Security (Güvenlik): Sadece ilgili rolün istediği ayarları aktif edip, diğer ayarlar kapatılarak güvenlik arttırılır.
• Simplified deployment and administration (Yönetilebilirlik): Yönetim işlemleri kolaylaşmaktadır.
• ISA Server 2006 ve Exchange Server 2010 birlikte çalışabilmektedir.

Protokol Güvenliği
Exchange ortamında kullanılan HTTP, SMTP, IMAP ve POP protokollerinde kullanıcı bilgileri açık metin olarak iletilmektedir. Bu durumda araya giren bir kullanıcı tarafından bu bilgiler elde edilebilmektedir. Bu sebeple belirtilen protokollerin güvenilir versiyonları tercih edilmelidir. Bu amaçla bu protokollerin TLS/SSL ile birlikte kullanılmalıdır.  HTTP yerine HTTPS, SMTP yerine SMTPS, IMAP yerine IMAPS, POP yerine POPS kullanılacak şekilde ayarlama yapılması önerilmektedir. Ayrıca güvenlik duvarları arasında sadece gerekli olan bu portlara izin verilmelidir. Bu protokollerin kullandığı portlar şu şekildedir:

• SMTPS : 465
• POP3S : 995
• IMAPS : 993

Exchange Server: RBAC

Exchange Server: RBAC
Role-Based Access Control

Rol Tabanlı Erişim Kontrolü
Exchange Server üzerinde bazı yönetimsel işlemlerin gerçekleştirilmesi için belli hakların tanımlı olması gerekmektedir. Exchange Server 2000 ve 2003 üzerinde hak tanımlama işlemleri yetki devri ile gerçekleşiyordu. Yani bir hakka sahip olan bir kullanıcı haklarını bir başka kullanıcıya verebiliyordu. Exchange Server 2003 için varsayılan gruplar şunlardır:

• Exchange Full Administrator
• Exchange Administrator
• Exchange View Only Administrator

Ancak bu durum karışıklığa sebep olmaktaydı. Bu sebeple Exchange Server 2007 ile RBAC adı verilen yeni bir kontrol mekanizması oluşturulmuştur. Bu mekanizma Exchange Server 2007’deki bu mekanizmada AD nesneleri üzerinde ACL (Access Control List) değişiklikleri yapılmaktaydı. Exchange Server 2007 için varsayılan gruplar ise şunlardır:

• Exchange Organization Administrators
• Exchange Recipient Administrators
• Exchange View-Only Administrators
• Exchange Public Folder Administrators (Service Pack 1 ile geldi)

Exchange Server 2010 ile geliştirilen RBAC ile kullanıcı ve grupların erişim seviyelerinin tanımlanması ACL değişikliğine gerek kalmadan otomatik olarak gerçekleştirilmeye başlanmıştır. Gerekli olan haklar belirli kullanıcı gruplarına atanmış halde gelmektedir. RBAC sayesinde yönetimsel işlerin yanında kendi posta kutuları ve Distribution grupları için hangi işlemleri yapmaya yetkili oldukları ayarlanabilmektedir.

RBAC temelde “Kim Neyi Nerede yapmaya yetkilidir?” sorusuna cevap arar. Cevaba ulaşabilmek için RBAC modelinde rol gruplar 3 temele dayanır:

• Rol Grubu: Görevi gerçekleştirecek kullanıcıların bulunduğu Universal Security gruplardır. Kim sorusunun cevabıdır.
• Rol: Kullanıcılara atanan görev ve izinlerdir. Ne sorusunun cevabıdır.
• Rol Kapsamı: Hangi nesneler (kullanıcı, makine, OU vs) üzerinde görevin gerçekleştirileceğidir.

Exchange Server: Sunucu Rolleri

Exchange Server: Sunucu Rolleri

Exchange Server 2007 ile birlikte, sistem ihtiyaçlarının daha iyi karşılamak ve güvenliği arttırmak için 5 adet sunucu rolü bulunmaktadır. Bu roller şunlardır:

• Mailbox Server Role ( Posta Kutusu Sunucu Rolü – MB)
• Client Acces Server Role ( İstemci Erişim Sunucu Rolü –Cas)
• HUB Transport Server Role ( Merkez Aktarım Sunucu Rolü- HT)
• EDGE Transport Server Role ( Uç Aktarım Sunucu Rolü –EDGE)
• UNIFIED Messaging Server Role ( Birleşik Mesajlaşma Sunu Rolü-UM)

Mailbox Server Rolü (MBS)
Kurulması gereken zorunlu bir roldür. Organizasyondaki tüm kullanıcıların e-mail veri tabanının tutulduğu ve işlendiği sunucu rolüdür. CAS tarafından aktarılan trafiğin sonlandığı yerdir.

Görevleri:

• Posta kutusu (mailbox), genel dizin (public folder), posta arşivi  veri tabanlarına ev sahipliği yapar.
• E-mail adres ilkelerinin düzenlemesini sağlar.
• Adres defteri, görev notları ve offline adres defteri (OAB) oluşturulmasını sağlar
• Yüksek erişilebilirlik ve esneklik sağlar.
• İçerik indeksleme gerçekleştirir.

Ek Bilgiler:

• Kullanıcılar MAPI (Messaging Applicaiton Program Interface) kullanarak CAS sunucusuna bağlanırlar. Direk olarak posta kutularına erişemezler.
• MBS rolünde posta kutuları arasında posta transferi gerçekleştirilmez. Bu işlem HTS rolü tarafından gerçekleştirilir. 

Client Access Server Role (CAS)
Kurulması gereken zorunlu bir roldür. CAS rolü birçok farklı türdeki istemci uygulamalardan Exchange sunucunuza gelen bağlantıları alır ve sonrasında internette ya da yerel ağdaki ilgili mail sunucusuna teslim eder.
CAS rolünün desteklediği erişim metotlarından bazıları şunlardır:

• Messaging Application Programming Interface (MAPI)
• Microsoft Outlook Web App (OWA): Web tarayıcı üzerinden erişimler için kullanılır
• Microsoft Exchange ActiveSync: PDA gibi mobil cihazlar ile erişimler için kullanılır.
• Microsoft Outlook Anywhere
• Post Office Protocol Version 3 (POP3)
• Internet Message Access Protocol Version 4 (IMAP4)
• Exchange Web Services (EWS)
• Outlook Express gibi yazılım tabanlı istemciler Exchange sunucularına POP3 ya da IMAP protokolüyle erişirler. Mobil cihazlar, PDA ya da cep telefonu gibi donanım tabanlı istemciler ise Exchange sunucularına ActiveSync, POP3 ya da IMAP protokollerini kullanarak erişirler. 

Görevleri: 

• Tüm istemci isteklerini karşılar
• Temel olarak sadece proxy işlemi gerçekleştirir. Kullanıcı verisini tutmaz sadece gelen isteği doğrular yani kimlik doğrulaması gerçekleştirir. Böylece, kullanıcının aktif veritabanının bulunduğu Mailbox rolüne sahip sunucuya yönlendirir.
• Free/Busy (Uygun/Meşgul) bilgisini sağlar
• Çevrimdışı adres defterini dağıtılmasını (Offline Address Book - OAB) gerçekleştirir
• AutoDiscover özelliğini sağlar. Bu özellik sayesinde kullanıcılar bilgilerini girmese dahi profilleri otomatik olarak gelecektir.

Ek Bilgiler:

• Exchange 2010 ile beraber kullanıcıların direk olarak MBS erişimleri engellenmiştir. Erişim CAS üzerinden gerçekleşmektedir.  
• Public Folder bağlantıları, CAS rolüne uğramadan, direk MBS rolüne gitmektedir. 
• Exchange Server 2013 ile birlikte CAS üzerinde veri işleme kendi başına yapılmamaktadır ve üzerinde herhangi bir veri bulunmamaktadır. Bu sebeple, istemci bağlantısının kontrolü CAS tarafından değil, MBS tarafından gerçekleştirilmeye başlanmıştır. 
• Exchange Server 2007’de posta kutusu istemcileri Client Access Server ve Mailbox Server ile haberleşir ve mail trafiği bu iki rol üzerinden gerçekleştirilirdi. Dolayısıyla bu iki rol üzerinde herhangi bir servisin durması istemciler tarafından hissedilirdi. Exchange Server 2010’da ise bu yapı değiştirilerek istemcilerin sadece Client Access Server ile haberleşmesi sağlanmış ve birden fazla Client Access Server ile süreklilik parametresi iyileştirilmiştir.

Hub Transport Server Rolü (HTS)
Kurulması gereken zorunlu bir roldür.  HTS, ETS ve UMR ile SMTP kullanarak sürekli iletişim kurar.

Görevleri:

• Exchange organizasyonundaki tüm posta trafiğini yönetir. Aynı organizasyon içinde gönderilen postalar bile bu sunucu tarafından işlenir. Gelen ve giden posta trafiğini yönlendirir.
• Gelen mesajları MBS rolüne sahip sunucuya yönlendirir.
• Taşıma kuralları uygulanır.
• Mesaj filtreleme işlemleri gerçekleştirilir.
• Journaling işlemleri gerçekleştirilir. Journaling, mesajların izlenmesi ve aynı mesajdan bir kopyanın istenilen yerde tutulmasını sağlayan bir yapıdır.
• ETS rolünden gelen internet postalarını alır.
• Üzerinde bulunan Microsoft Exchange EdgeSync hizmeti, ETS rolünün ihtiyaç duyduğu bilgileri AD üzerinden alır ve ETS rolüne sahip sunucuya kopyalar.

Konnektörler:
Exchange Server 2007 ve 2010′da posta alma/gönderme işlemlerinin gerçekleştirirler. İki çeşittir:

• Send Connector: Sistemin Outbound SMTP bağlantıları görevini yerine getirerek posta gönderilmesini sağlar.
• Receive Connector: İstemcilerin dışarıdan mail alması için tasarlanmıştır. Bu konnektör, SMTP Inbound bağlantılarını dinler ve belirlenen Ip/Port kriterlerine gelen SMTP bağlantılarını karşılar. Böylece posta alınmasını sağlar.

Ek Bilgiler:

• Bu rol, Exchange 2007 ve Exchange Server 2010 sürümlerinde bulunmaktayken; Exchange Server 2013’te, bu rol yerine MBS üzerinden çalışan HUB Transport Servisi gelmiştir.

Edge Transport Server Rolü (ETS)
Kurulması zorunlu bir rol değildir.

Görevleri:

• Organizasyonun bütün mail alış verişini gerçekleştirir. Dış SMTP sunucularından gelen tüm maillerin ilk ulaştıkları noktadır. SMTP relay kullanarak Internet tarafından gelen tüm talepleri karşılayarak saldırı alanını daraltır.
• Dışarıdan iç sisteme gelecek saldırılara karşı filtreleme görevi sağlar.
• Aldığı mailleri HTS rolüne sahip sunucuya yönlendirir. HTS ile de MBS’a iletilir.
• Posta ilkeleri tanımlanır. Bu kurallar ile internetten veya organizasyondan gönderilen tüm postalar kontrol edilir. Kontrol işlemine göre posta silinebilir, yönlendirilebilir, dondurulabilir.
• Sistemin performansını, ölçülebilirliğini ve erişilebilirliğini arttırmak için kullanılabilir.

Ek Bilgiler:

• ETS rolü kurulan sunucu etki alanına dahil olmamalıdır. Bu rolün çalışması için etki alanındaki kullanıcıların bilgilerine ihtiyaç duyar. Bu bilgiler AD LDS (Active Directory Lightweight Directory Services) (eski adı ADAM) dizin hizmeti üzerinde depolanır. ETS’nin direk olarak etki alanına erişimi olmadığı için, gerekli olan bu bilgiler HTS üzerinde kurulu olan MS EdgeSync hizmeti ile tek yönlü olarak kopyalanır.
• Exchange Server 2013 ile bu rol kaldırılmıştır.
• Address Rewriting yapısı sayesinde, iç ve dış etki alanlarını farklı isimlerle dışarı çıkarılabilir. Bu daha çok fazla sayıda domain yapısına sahip olan kurumlarda kullanılabilen bir özelliktir.

Unified Messaging Server Rolü (UMS);
Kurulması zorunlu bir rol değildir.

Görevleri:

• Sesli posta veya telefondan bilgisayarı ya da bilgisayardan telefonu arama gibi işlemleri gerçekleştirir.
• Sistemin performansını, ölçülebilirliğini ve erişilebilirliğini arttırmak için kullanılabilir.

Exchange Server: Giriş

Exchange Server: Giriş

E-Posta Sistemleri 
Günümüzde sosyal mühendislik gibi bir çok saldırı posta yolu ile gerçekleşmektedir. Bu sebeple posta sunucularının güvenliğine önem vermek gerekmektedir.

Elektronik posta (e-posta) sistemleri iki öğeden oluşur:

• Elektronik posta sunucular (mail server) : Exchange Server, Lotus Notus Mail Server, Send Mail, Qmail ve Postfix gibi genellikle sunucu üzerinde çalışan ve e-posta hizmeti veren programlardır.
• Elektronik posta istemciler (mail client) : Outlook Express, Thunderbird, PowerMail gibi kullanıcı bilgisayarlarında çalışan ve adımıza açılmış olan bir e-posta hesabına erişmek için kullandığımız uygulama programlarıdır.

Güvenilir Bilgi İşleme 
Daha önceki Exchange Server sürümlerinde posta kutusu (mailbox) ve kullanıcı işlemlerinin tamamı, Aktif Dizin üzerinden gerçekleştirilirdi ve bu durum Aktif Dizin üzerine büyük bir yük oluşturmaktaydı. Exchange Server 2007 ile birlikte bu işlemler Exchange Server Management Console (EMC) veya PowerShell üzerinden gerçekleştirilebilmektedir.

Exchange Server 2007 ile birlikte kurulum ile beraber güvenlik sağlanmaktadır. Güvenlik için sıkılaştırma işlemlerinin bir çoğu yapılmış olarak kurulumla gerçekleşmektedir. Exchange Server 2007 ve sonraki sürümlerde Microsoft tarafından Güvenilir Bilgi İşleme (Trustworthy Computing) metodu kullanılmaktadır. Kullanılan SDLC (Security Development Lifecycle) ile daha güvenilir bir sistem hazırlanmıştır. Trustworthy Computing, temel olarak aşağıdaki başlıklarda güvenliği kapsamaktadır:

• Tasarımda Güvenlik: Ürünün tasarlanması sırasında güvenilir kod geliştirmek için gerekli olan araçlar ve tekniklerden faydalanılmıştır.
• Kendiliğinden Güvenlik: Güvenilir bir sistemin sağlanması için en önemli konulardan birisi iletişimin güvenilir hale getirilmesidir. Bu amaçla SMB (Server Message Block) ve bazı UM (Unified Messaging) iletişimleri hariç tüm iletişimlerde Kerberos protokolü, sertifika, SSL (Secure Sockets Layer), diğer bazı endüstriyel şifreleme teknikleri kullanılmaktadır.
• Zararlılara Karşı Güvenlik: SPAM maillere karşı ajanlar yüklü olarak gelmektedir. Daha önceki versiyonlarda ajanlar kullanılmamaktaydı. Bunun yanında Microsoft Forefront Protection ile virüslere karşı önlem oluşturulmuştur.
• Dağıtımda Güvenlik: Exchange Server kurulumu sırasında en iyi alıştırmalara göre “Microsoft Exchange Server Best Practices Analyzer” ile sistem analizi gerçekleştirilebilmektedir. Bunun yanında mail sunucuda yapılacak işlemler için yönetici ve standart kullanıcılar için En Az Yetki Prensibi’ne göre hazırlanmış rol tabanlı bir izin modeli oluşturulmuştur.

İletişim Protokolleri 
Exchange ortamında temel olarak 5 adet protokol kullanılmaktadır:

• HTTP: Veriler ağ üzerinden açık olarak geçmektedir.
• IMAP4 & POP3: Yerel kullanıcıların uzaktaki bir e-posta sunucusuna erişmesini sağlayan bir uygulama katmanı protokolüdür. Veriler ağ üzerinden açık olarak geçmektedir. IMAP ile E-Posta sunucusuna bağlantı kurulduğunda, kutuda birikmiş e-postaların sadece başlık bilgilerini istemciye getirir. POP3 ise bütün mesajları istemciye çeker.
• SMTP: Posta gönderilmesi için kullanılan protokoldür. Tek yönlü bir protokoldür (sadece gidiş).  E-posta, e-posta sunucuları arasında aktarılırken de SMTP kullanılır. Veriler ağ üzerinden açık olarak geçmektedir. İstemci bilgisayar SMTP sunucusuna bağlanarak gerekli kimlik bilgilerini gönderir.  Onay verildiğinde posta SMTP sunucusuna iletilir.
• MAPI: Posta uygulamalarının sunuculardan posta alırken veya posta gönderirken kullandıkları arabirim protokolüdür. Exchange Server 2010 öncesinde kullanıcılar MAPI (Messaging Application Program Interface) aracılığıyla Mailbox sunucusuna ulaşabiliyorlardı. 2010 ile beraber bu değişmiştir. Mailbox server diğer sunucu rolleri ile MAPI bağlantısı üzerinde konuşur. Sadece ortak klasörlere (public folder) erişmek için MAPI kullanan son noktalar direk olarak Mailbox’a ulaşır.

Not: Posta iletişiminin sağlanabilmesi için DNS’e MX kaydının girilmesi gerekmektedir.

Not: Ortak klasörler ile Exchange sisteminde dosya, kontakt, takvim, mail, forum gibi kaynaklar tek kopya üzerinden bir çok kullanıcının erişimine açıldığı klasörlerdir. Exchange Server 2013 mimarisinde bu klasörler artık veritabanı yerine özel olarak dizayn edilmiş posta kutusu (mailbox) bazlı olarak oluşturulmaktadır.

AD-CS: Temel Güvenlik Önlemleri

Aktif Dizin Sertifika Servisi: Temel Güvenlik Önlemleri

Bir organizasyonda Aktif Dizin Sertifika Servisi için tavsiye edilen temel güvenlik önlemleri şu şekildedir:

• Kök ve Ara Sertifika Otoriteleri, sadece kendisinin altındaki otoritelere sertifika dağıtımı yaparken açık olmalı, diğer zamanlarda çevrimdışı çalışmalıdır. Bu otoriteler, direk olarak son kullanıcı sertifikalarının yayımlanması ile ilgilenmemelidir. Çevrimdışı tutulan bu Sertifika Otoriteleri Hyper-V ile sanallaştırılmalıdır. Fiziksel olarak korumak daha kolay ise, sanallaştırma yerine fiziksel sunucular kullanılmalıdır.
• Kök veya Ara Sertifika Otoriteleri’nden sertifika taşınması için USB veya floppy disk kullanılmalıdır, ağ bağlantısının kurulmasından kaçınılmalıdır.
• Donanım güvenlik modülü (Hardware Security Module - HSM) ile bir sertifika yetkilisinin (CA) ve ortak anahtar altyapısının (PKI) güvenliği arttırılır. HSM, işletim sisteminden ayrı olarak yönetilen, tahsis edilmiş bir donanım aygıtıdır. Bu modüller ile hem imzalama ve şifreleme işlemleri hızlanır, hem de SO anahtarları için de güvenli bir donanım depo sağlanır. 
• SYSKEY.exe aracı kullanılarak anahtarlar depolanmalıdır.
• Sertifika otoritesi ile olan iletişim şifreli olmalıdır. Özellikle Web tabanlı sertifika kaydı için SSL üzerinden iletişim gerçekleştirilmelidir.
• Kritik sertifika verme işlemlerinin otomatik olarak onaylanılmasından kaçınılmalıdır. Bir yönetici tarafından onaylanması ve onaylanmadan önce farklı yollarla (mail/telefon vs) bu talebin onaylanması gerekmektedir.
• CA sunucusunda oturum açılma işlemlerinde sıkı güvenlik politikaları uygulanmalıdır. Kimlik doğrulama işleminin akıllı kartlar ile gerçekleştirilmesine özen gösterilmelidir.
• CA tarafından verilen sertifikanın kullanım amacı belirtilmeli ve sadece bu amaç için kullanılabilmesi sağlanmalıdır. Posta yollamak için verilen sertifika, doküman imzalamak için kullanılmayacaksa, imzalama yetkisine sahip olmamalıdır.
• Grup ilkeleri ile sertifika yönetimi sağlanmaya çalışılmalıdır. Manuel operasyonlardan kaçınılmalıdır.
• Kullanıcılar Kök Sertifikalarını kendileri güncelleyememeleri sağlanmalıdır. Böylece zararlı bir sertifika otoritesine ait sertifika depolanmamış olur.
• Güven yapısının olduğu sistemlerde PKI yapısına dikkat edilmelidir. Güven duyulan tarafa sertifika üretme yetkisi verilecekse, bu süre kısa tutulmalı ve verilen sertifikalar kontrol edilmelidir.
• Etki alanındaki kimlik doğrulamış grupların (Authenticated Users), organizasyondaki Sertifika Otoriteleri üzerinde hiçbir hakkı olmamalıdır. Sertifika isteyebilecek grupların (bilgisayar veya kullanıcı) ise, sadece sertifika talep etme (Request Certificates) haklarının olması gerekmektedir.
• Her bir Sertifika Otoritesi’nde yerel bir grup oluşturulmalı ve bu gruba CA’yı yönetmesi için gerekli haklar verilmelidir.
• İstemcilerde ve CA’larda gizli anahtarların bulunduğu dizinler özel olarak korunmalıdır. Bu dizinler şu şekildedir:
• Windows Vista/2008/7 istemcilerde, %APPDATA%\Microsoft\Crypto\Keys
• Windows 2003/XP istemcilerde, %APPDATA%\Microsoft\Crypto
• Windows Server 2003 CA’da, %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto
• Windows Server 2008 / 2008 R2 CA’da, %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto, %WINDIR%\ServiceProfiles
• Bir Sertifika Otoritesi üzerinde gerçekleşen olaylar için denetimler uygun şekilde yapılandırılmalıdır. Ayrıntılı bilgi için: http://technet.microsoft.com/tr-tr/library/cc772451.aspx
• Bir Sertifika otoritesinde kritik bir olay meydana geldiğinde bu olay anlık olarak ilgili yöneticiye bildirilmelidir. Ayrıntılı bilgi için: http://technet.microsoft.com/en-us/library/cc731934.aspx
• PKI ortamının yönetimi için rol tabanlı bir yönetim uygulanabilmektedir. Kullanıcı ve grupların yapabilecekleri operasyonlar sahip oldukları rollere göre gerçekleştirilmelidir. AD-CS üzerindeki rol tabanlı yönetim kuralları için bakınız: http://technet.microsoft.com/tr-tr/library/cc732590(v=ws.10).aspx
• Veritabanı ve loglar ayrı disklerde tutulmalıdır.
• Sertifika otoritesine ait veritabanı, sertifikalar ve anahtarlar yedeklenmelidir.
• Uygulamalar sertifika geçerliliği kontrolü gerçekleştirilirken sertifikanın iptal olup olmadığı kontrolünü gerçekleştirecek şekilde ayarlanmalıdır. /NoCRLCheck parametresi kullanılması durumunda HTTPS bağlantısı öncesinde CRL kontrolünün yapılmayacağı göz önünde bulundurulmalıdır.

AD-CS: En iyi uygulamalar

Aktif Dizin Sertifika Servisi: En İyi Uygulamalar
(Best Practices)

Bir organizasyonda Aktif Dizin Sertifika Servisi için tavsiye edilen en iyi uygulamalar şu şekildedir:

• Organizasyondaki AD-CS ve PKI gereksinimi analiz edilmeli ve gerek duyuluyorsa planlı ve yazılı bir şekilde kurulum gerçekleştirilmelidir.
• AD-CS sunucu rolünün yüklü olduğu makinede sadece DNS rolünün yüklü olması tavsiye edilmektedir. Özellikle AD-DS yüklü olmamasına özen gösterilmelidir. Aksi halde SO üzerindeki bir problem tüm etki alanındaki sistemlerin çalışmasına engel olabilir.
• Tek katmanlı SO hiyerarşik yapıdan kaçınılmalıdır.
• Sertifikaların geçerlilik süreleri operasyonel işlemlerin çok sık gerçekleştirilmemesi için çok kısa olmamalı, güvenlik zafiyeti ve kontrol eksikliğine sebep olmaması için çok uzun olmamalıdır.
• Katmanlı yapılarda her katman arasındaki sertifika geçerlilik tarihinin en fazla 10 yıl olması tavsiye edilmektedir. Örneğin, Kök Sertifika Otoritelerinin sertifika ömrü 30 yıl iken, Ara Sertifika Otoriteleri’nin 20 yıl, Kayıt Eden Sertifika Otoriteleri’nin ise 10 yıl olması uygundur.
• Sertifikaların kontrol edildiği CA kaldırıldığında, sertifika kontrolü gerçekleştirilemeyeceği için bazı uygulamalar düzgün çalışmayabilir. Bu sebeple kaldırılan Sertifika Otoritesi’nin sertifikası, üst Sertifika Otoritesi tarafından iptal edilmeli ve iptal nedeni belirtilmelidir. Daha sonra iptal nedeninin gösterildiği sertifika iptal listesi (CRL) yayınlanmalıdır.
• Kök CA kaldırıldığında,bu KÖK CA tarafından verilen tüm sertifikalar iptal edilmeli ve iptal nedeni belirtilmelidir. Daha sonra iptal nedeninin gösterildiği sertifika iptal listesi (CRL) yayınlanmalıdır.
• Sertifika Otoritesi’ne ait bilgisayarın adı ve etki alanı kurulum sonrasında değiştirilemez. Bu sebeple dikkatli olarak isimlendirme yapılmalıdır. Departman adı, lokasyon adı gibi bilgilerin isim içerisinde geçmemesi tavsiye edilmektedir.
• Sertifika otoritesi kurulduktan sonra kurulum türü değiştirilemez. Bu sebeple, Enterprise veya Standalone kurulumlarından hangisinin kurulacağına dikkat edilmelidir.
• Sertifika işlemlerinin yönetimi için grup ilkeleri uygun şekilde yapılandırılmalıdır.
• Sertifika İptal Listeleri (CRL) ve SO sertifikalarına erişim kolay ve hızlı olmalıdır.
• Sertifika Otoriteleri yedekli çalışmalıdır.

AD-CS: Kurulum Türleri

Aktif Dizin Sertifika Servisi: Kurulum Türleri

İki türde AD-CS kurulumu gerçekleştirilebilir:

• Enterprise CA
• Standalone CA

Enterprise CA Kurulumu
Dijital imzalama, S/MIME kullanarak e-posta güvenliğini sağlama, SSL/TLS kullanarak güvenli bir Web sunucusuna kimlik doğrulaması yapma, akıllı kart kullanarak etki alanında oturum açma gibi amaçlarla sertifika yayımlayabilir. Enterprise CA şu özelliklere sahiptir:

• Active Directory Etki Alanı Hizmetleri'ne (AD DS) erişim gerektirir.
• Genellikle kayıt etme (issuing) işlemi için kullanılırlar.
• Ormandaki (Forest) tüm kullanıcı ve bilgisayarlar için; sertifikasını, Güvenilen Kök Sertifika Yetkilileri (Trusted Root Certification Authorities) sertifika deposuna yerleştirmek amacıyla grup ilkesini kullanır. 
• AD DS'ye kullanıcı sertifikaları ve sertifika iptal listeleri (CRL) yayımlar.

Enterprise CA'ları, bir sertifika şablonuna dayalı olarak sertifika verir. Sertifika şablonları kullandığınızda aşağıdaki işlevleri kullanmak mümkündür:

• Enterprise Sertifika Otoriteleri, sertifika kaydı sırasında kullanıcılar için kimlik denetimini zorunlu kılar. Her sertifika şablonunun, sertifika istek sahibinin istediği türde sertifika almaya yetkili olup olmadığını belirleyen, AD DS üzerinde ayarlanmış bir güvenlik izni vardır.
• Sertifika konusu veya adı, AD DS üzerindeki bilgilerden otomatik olarak oluşturulabilir veya istek sahibi tarafından sağlanabilir.
• İlke modülü, verilen sertifikaya, sertifika uzantılarının önceden tanımlanmış bir listesini ekler. Uzantılar sertifika şablonu tarafından tanımlanır. Böylece, sertifika ve amaçlanan kullanımla ilgili olarak sertifika isteyenin sağlaması gereken bilgiler azalır.
• Sertifika vermek için otomatik kayıt kullanılabilir. Ancak yöneticilerin, bu otomatik yapıyı kontrol etmesi ve güvenliğini sağlaması için, parola politikası gibi bazı politikaları sıkı tutması gerekir.

Standalone CA Kurulumu
Dijital imzalama, S/MIME kullanarak e-posta güvenliğini sağlama, SSL/TLS kullanarak güvenli bir Web sunucusuna kimlik doğrulaması yapma gibi amaçlarla sertifika yayımlayabilir. Standalone Sertifika Otoriteleri şu özelliklere sahiptir:

• Enterprise Sertifika Otoriteleri’nin aksine Standalone CA'lar, Active Directory Etki Alanı Hizmetleri'ni (AD-DS) kullanmayı gerektirmez. AD DS kullanılsa bile, SO hiyerarşisinde ya sadece çevrimdışı güvenilen Kök Sertifika Otoriteleri olarak kullanılabilir; ya da istemcilere bir extranet veya Internet üzerinden sertifika vermek için kullanılabilir. 
• Genellikle Kök ve Ara CA’lar için kullanılırlar.
• Ağ bağlantısı kapalı tutularak, çevrimdışı olarak çalışmalıdırlar. Çevrimiçi çalışacaklarsa HSM (Hardware Security Module) kullanılmalıdır.
• Sertifika oluşturmak için şablon kullanmazlar.
• İstemciler, bir Standalone Sertifika Otoritesi’ne sertifika isteği gönderdiğinde, kendilerini tanımlayan bilgileri sağlamaları ve gereksinim duydukları sertifikanın türünü belirtmeleri gerekir. (Enterprise CA'larına istek gönderilirken bunların yapılmasına gerek yoktur; çünkü, etki alanındaki istemcilerin bilgileri zaten AD DS üzerinde bulunmaktadır ve sertifika türü de bir sertifika şablonuyla belirtilmiş olması gerekmektedir). İsteklerle ilgili kimlik doğrulama bilgileri yerel bilgisayarın Güvenlik Hesapları Yöneticisi (Security Accounts Manager) veritabanından alınır.
• Varsayılan olarak, Standalone Sertifika Otoritesi’ne gönderilen tüm sertifika istekleri, Standalone Sertifika Otoritesi’nin yöneticisi gönderilen bilgileri doğrulayıp isteği onaylayana kadar beklemeye alınır. Sertifika isteyenin kimlik bilgileri Standalone Sertifika Otoritesi tarafından doğrulanmadığı için, yöneticinin bu görevleri gerçekleştirmesi gerekir.
• Yöneticinin, Standalone CA'nın sertifikasını etki alanı kullanıcısının güvenilen kök deposuna dağıtması ya da kullanıcıların bu görevi kendilerinin yapması gerekir.

Standalone olarak kurulan bir sertifika otoritesi, AD-DS kullanırsa; bu sunucu aşağıdaki ek özelliklere sahip olur:

• Domain Admins grubunun bir üyesi veya etki alanı denetleyicisine Yazma erişime sahip bir yönetici Standalone bir Kök (root) Sertifika Otoritesi yüklerse, etki alanındaki tüm kullanıcı ve bilgisayarlar için Güvenilen Kök Sertifika Yetkilileri (Trusted Root Certification Authorities) sertifika deposuna otomatik olarak eklenir. Bu nedenle, etki alanına Standalone bir Kök CA yüklenecekse, sertifika istekleri alındığında CA tarafından gerçekleştirilecek varsayılan eylem, istekleri beklemede (requests as pending) olarak değiştirilmelidir. Aksi takdirde, etki alanına sertifika isteyenin kimliğini doğrulamadan otomatik olarak sertifikalar veren bir güvenilen Kök CA yüklenmiş olur.
• Kuruluştaki üst etki alanının Domain Admins grubunun bir üyesi veya AD DS'ya Yazma erişime sahip bir yönetici tarafından Standalone CA yüklenirse; yüklenen bu Standalone CA, kendi CA sertifikasını ve sertifika iptal listesini (CRL) AD DS'ye yayımlar.

Katmanlı Yapı

• Tek katmanlı yapıda Kök SO Enterprise olarak kurulurken, Ara ve Kayıt Eden sertifika otoriteleri bulunmamaktadır.
• İki katmanlı yapıda Kök SO olan Standalone, Kayıt Eden Sertifika Otoritesi Enterprise olarak kurulurken, Ara SO bulunmamaktadır.
• Üç katmanlı yapıda Kök ve Ara SO Standalone olarak, Kayıt Eden SO Enterprise olarak kurulur.

AD-CS: Rol Servisleri

Aktif Dizin Sertifika Servisi: Rol Servisleri

Windows Server 2008 R2 üzerinde AD Sertifika Hizmeti’nin 6 bileşeni bulunmaktadır. Bu bileşenler şu şekildedir:

• Sertifika Otoritesi (Certification Authority) : Temel rol servisidir. Kök ve Alt CA sunucuları; etki alanındaki veya dışında bulunan kullanıcı, bilgisayar veya servislere sertifika verilmesi ve bu sertifikaların geçerliliğinin yönetilmesi işlemlerini gerçekleştirir.
• CA Web Kaydı (Certification Authority Web Enrollment): Kullanıcıların sertifika talep etmek, yenilemek, Sertifika iptal listesine (Certificate Revocation List – CRL) erişmek, akıllı kart sertifikalarının dağıtmak için basitleştirilmiş bir web ara yüzü sunmaktadır. Bu arayüze “http://SunucuAdi/certsrv” adresinden erişilebilir.
• Çevrimiçi Yanıtlama Hizmeti (Online Responder Service): Belirli sertifikaların iptal edilme durum bilgisi isteklerini alır, bu sertifikaların durumunu analiz eder ve istenen sertifika durum bilgilerini içeren imzalı bir yanıtı geri gönderir. Bu servis Online Certificate Service Protokol’ünü (OCSP) çalıştırır. Bu servis, kompleks yapılar içinde, Certificate Revocation List (CRL) kontrolünü daha rahat erişilebilir kılmaktadır. CRL girdileri, istekte bulunan kişiye tüm CRL yerine, geçerliliğini öğrenmek istediği sertifikanın geçerlilik durumunu imzalı olarak yollar. Bu sayede istemci, sertifika doğrulamak istediğinde hem harcanan toplam ağ trafiği büyük oranda düşmüş olur, hem de daha hızlı cevap alır. http://technet.microsoft.com/tr-tr/library/cc770413(v=ws.10).aspx
• Ağ Aygıtları Kayıt Servisi (Network Device Enrollment Service): Etki alanı hesabı olmayan yönlendiricilerin ve diğer ağ aygıtlarının, Simple Certificate Enrollment Protocol (SCEP) kullanarak sertifika almasına olanak sağlar. http://technet.microsoft.com/tr-tr/library/cc753784(v=ws.10).aspx
• Sertifika Kaydı Web Hizmeti (Certificate Enrollment Web Service): Kullanıcıların ya da bilgisayarların, bilgisayarlar etki alanı üyesi olmasa bile ya da etki alanı ağında olmasa bile, HTTPS protokolünü kullanarak sertifika kaydı gerçekleştirmelerini sağlar. Bu hizmet; gelen talepleri HTTPS trafiği üzerinden alır, talebi asıl yapan istemci adına DCOM protokolünü kullanarak CA’ya bağlanır ve sertifika kayıt işlemini tamamlar, daha sonra sertifika cevabını yine HTTPS üzerinden geri gönderir.
• Sertifika Kaydı İlkesi Web Hizmeti (Certificate Enrollment Policy Web Service): Kullanıcıların ve bilgisayarların sertifika kaydı ilkesi bilgilerini almalarını sağlar. Bu hizmet; ağdaki istemci bilgisayarlara sertifika ilkesini iletmek için HTTPS protokolünü kullanır. LDAP kullanarak AD-DS’ten sertifika ilke bilgisini alır, bu bilgiyi ön belleğinde saklar ve istemciye sunar. Bu hizmet, bir önce belirtilen rol servisi (Sertifika Kaydı Web Hizmeti) ile otaklaşa çalışır. Bu iki hizmet, istemci bilgisayar etki alanının bir üyesi olmadığında veya bir etki alanının bulunduğu ağa bağlı olmadığında da ilke tabanlı sertifika kaydı sağlar. Bu sayede orman (forest) sınırları dışarısında gereksiz yere CA kurulmasının önüne geçilebilmekte, organizasyon dışındaki iş ortakları ve hareketli (mobil) çalışanlara sertifika düzenlenebilmektedir.

Aktif Dizin Sertifika Servisi: Rol Servisleri

Aktif Dizin Sertifika Servisi: Rol Servisleri

Windows Server 2008 R2 üzerinde AD Sertifika Hizmeti’nin 6 bileşeni bulunmaktadır. Bu bileşenler şu şekildedir:

• Sertifika Otoritesi (Certification Authority) : Temel rol servisidir. Kök ve Alt CA sunucuları; etki alanındaki veya dışında bulunan kullanıcı, bilgisayar veya servislere sertifika verilmesi ve bu sertifikaların geçerliliğinin yönetilmesi işlemlerini gerçekleştirir.
• CA Web Kaydı (Certification Authority Web Enrollment): Kullanıcıların sertifika talep etmek, yenilemek, Sertifika iptal listesine (Certificate Revocation List – CRL) erişmek, akıllı kart sertifikalarının dağıtmak için basitleştirilmiş bir web ara yüzü sunmaktadır. Bu arayüze “http://SunucuAdi/certsrv” adresinden erişilebilir.
• Çevrimiçi Yanıtlama Hizmeti (Online Responder Service): Belirli sertifikaların iptal edilme durum bilgisi isteklerini alır, bu sertifikaların durumunu analiz eder ve istenen sertifika durum bilgilerini içeren imzalı bir yanıtı geri gönderir. Bu servis Online Certificate Service Protokol’ünü (OCSP) çalıştırır. Bu servis, kompleks yapılar içinde, Certificate Revocation List (CRL) kontrolünü daha rahat erişilebilir kılmaktadır. CRL girdileri, istekte bulunan kişiye tüm CRL yerine, geçerliliğini öğrenmek istediği sertifikanın geçerlilik durumunu imzalı olarak yollar. Bu sayede istemci, sertifika doğrulamak istediğinde hem harcanan toplam ağ trafiği büyük oranda düşmüş olur, hem de daha hızlı cevap alır. http://technet.microsoft.com/tr-tr/library/cc770413(v=ws.10).aspx
• Ağ Aygıtları Kayıt Servisi (Network Device Enrollment Service): Etki alanı hesabı olmayan yönlendiricilerin ve diğer ağ aygıtlarının, Simple Certificate Enrollment Protocol (SCEP) kullanarak sertifika almasına olanak sağlar. http://technet.microsoft.com/tr-tr/library/cc753784(v=ws.10).aspx
• Sertifika Kaydı Web Hizmeti (Certificate Enrollment Web Service): Kullanıcıların ya da bilgisayarların, bilgisayarlar etki alanı üyesi olmasa bile ya da etki alanı ağında olmasa bile, HTTPS protokolünü kullanarak sertifika kaydı gerçekleştirmelerini sağlar. Bu hizmet; gelen talepleri HTTPS trafiği üzerinden alır, talebi asıl yapan istemci adına DCOM protokolünü kullanarak CA’ya bağlanır ve sertifika kayıt işlemini tamamlar, daha sonra sertifika cevabını yine HTTPS üzerinden geri gönderir.
• Sertifika Kaydı İlkesi Web Hizmeti (Certificate Enrollment Policy Web Service): Kullanıcıların ve bilgisayarların sertifika kaydı ilkesi bilgilerini almalarını sağlar. Bu hizmet; ağdaki istemci bilgisayarlara sertifika ilkesini iletmek için HTTPS protokolünü kullanır. LDAP kullanarak AD-DS’ten sertifika ilke bilgisini alır, bu bilgiyi ön belleğinde saklar ve istemciye sunar. Bu hizmet, bir önce belirtilen rol servisi (Sertifika Kaydı Web Hizmeti) ile otaklaşa çalışır. Bu iki hizmet, istemci bilgisayar etki alanının bir üyesi olmadığında veya bir etki alanının bulunduğu ağa bağlı olmadığında da ilke tabanlı sertifika kaydı sağlar. Bu sayede orman (forest) sınırları dışarısında gereksiz yere CA kurulmasının önüne geçilebilmekte, organizasyon dışındaki iş ortakları ve hareketli (mobil) çalışanlara sertifika düzenlenebilmektedir.

AD-CS: Sertifika Otoriteleri için Katmanlı Yapı

Aktif Dizin Sertifika Servisi: Sertifika Otoriteleri

Sertifikaların Kullanım Alanları
Microsoft PKI yapısında 3 katmanlı sertifika otoritesi bulunmaktadır:

• Kök (Root) CA: Organizasyon PKI yapısında en güvenilir CA türüdür. Kök Sertifika Otoriteleri, son kullanıcılara da sertifika verebileceği gibi, sadece alt katmanındaki sertifika otoritelerine sertifika vermesi tavsiye edilmektedir. Kendi sertifikalarını kendileri imzalarlar.
• Orta/Alt (Intermediate / Subordinate) CA: Kök Sertifika Otoriteleri tarafından kendisine sertifika dağıtma yetkisi verilen otoritelerdir. Bu sertifika otoriteleri de direk olarak son kullanıcı ve bilgisayarlara sertifika vermezler, diğer otoritelerin sertifikalarını onaylarlar.
• Veren/İhraç Eden (Issuing) CA: Direk oalrak son kullancııdan gelen sertifika isteğini işler. Bu amaçla önce bu isteği alır, uygunsa onaylar, gerekli düzenlemeleri yaparak sertifikayı oluşturur ve sonra da yayımlar.

PKI yapısı oldukça iyi tasarlanması gereken bir yapıdır. Bu yapı oldukça esnek ve genişletilebilir. PKI yapısı tasarlanırken, kullanacak bir organizasyonda en az bir tane Kök Sertifika Otoritesinin bulunması zorunludur. Kök SO birden fazla da olabilir. Büyük ölçekli organizasyonlarda 5-6 katmanlı bir yapı, orta ölçekli organizasyonlarda 2 katmanlı bir yapı önerilmektedir. Küçük ölçekli sistemlerde ise sadece Kök SO’nin bulunması yeterli olacaktır.

Hiyerarşik yapının sebepleri
Hiyerarşik yapının oluşmasının birden fazla sebebi olabilir. Bunlardan bazıları şu şekildedir:

• Kullanım: Sertifikalar posta gönderme, doküman imzalama, disk şifreleme,… gibi farklı amaçlarla kullanılabilmektedir. Bu amaçlara yönelik olarak farklı otoritelerin kullanılması organizasyon için faydalı olabilmektedir.
• Kuruluş bölümleri: Sertifikalar, varlığın organizasyonundaki rolüne göre dağıtılabilmektedir. Rollere göre dağıtım farklı katmanlardaki otoritelerce gerçekleştirilebilir.
• Coğrafi bölümler: Farklı lokasyonlardaki sistemler için farklı SO ihtiyacı olabilmektedir.
• Yük dengeleme: Aynı türden sertifikalar vermek için birden fazla Orta (Intermediate) SO kullanılması ağ yükünü bu otoriteler arasında dağıtır.
• Yedekleme ve hataya dayanıklılık: Birden fazla SO bulunması, herhangi bir otoritede meydana gelebilecek bir problem sırasında, organizasyondaki operasyonların aksamasının önüne geçecektir.

Hiyerarşik yapının yararları
SO hiyerarşisinin yönetime sağladığı bazı yararlar şu şekildedir:

• Esnek ve genişletilebilir bir yapı sağlanabilmektedir.
• Farklı departmanlarda, lokasyonlarda farklı PKI güvenlik ilkeleri uygulanabilmektedir.
• Orta veya daha alttaki bir SO’nin saldırıya maruz kalması diğer SO’lerine bağlı sistemlerin işleyişini etkilemez.
• Alt sistemlerin kontrolü yetki devri sayesinde departman sorumlularına veya yöneticilerine verilebilir.