Exchange Server Impersonation – Delegation ve Folder Permissions
Arasındaki Farklar
Exchange server organizasyonlarında pek çok
farklı yetki talepleri bulunmaktadır. Bunların en başında birisi veya bir grup
adına mail gönderme gelmektedir. Ancak bu izinler bazen bu kadar masum veya
bilindik olmayabilir. Özellikle arşivleme ile başlayan ve ajanda, posta kutusu
raporlama, audit gibi izleme derken çok ciddi seviyelere gelmektedir. Özellikle
bir hesaba verilen aşırı yetki toplam güvenlik seviyesi için büyük risk
doğurabilir. Buraya kadar anlattığım işlemler aslında hep delegation
– delasyon başlığı altında bildiğimiz izinler. Yani
bir active directory hesabına atanmış izinler olarak tanımlanabilir. Tabiki bu
izinler aslında güvenlik yöneticilerinin çok hoşuna giden türden izinler değildir.
Peki bir kullanıcı veya servis hesabına bir
başka kullanıcı posta kutusuna erişim izni vermek istersek ne yapabiliriz?
Microsoft Outlook 2016 sürüm 16.0.6741.2017′ dan sonra “Direct Connect to Office 365” olarak isimlendirdiği bir özellik sunmaya başladı. Bu özellik Office 365 Outlook 2016 ilgili sürüm ve Outlook 2019 gibi yeni sürümlerde aktif olarak gelmektedir. Peki nedir bu özellik derseniz, eğer outlook herhangi bir autodiscover servisine ulaşamaz ise doğrudan office 365′ e bağlanmaya çalışmaktadır. Aslında kullanıcılar için kolaylık sağlamak adına yapılan bu değişiklik özellikle autodiscover özelliğini kullanmayan müşterilerin başını bir hayli ağrıttı. Örneğin On-Prem Exchange kullanırken müşteri Outlook 2019 geçişlerini yaptıktan sonra birden yerleşik Exchange sunucusuna bağlanamadığını fark ediyor, bunun sebebi ise bundan önceki outlook profilleri autodiscover yerine elle yapılandırılmış. Outlook herhangi bir autodiscover bağlantısı tespit etmediği içinde otomatik olarak office 365′ e bağlanamaya çalışıyor.
Aslında bu yeni özellik görebileceğiniz gibi en alt sırada yer alıyor;
SCP lookup
HTTPS root domain query
HTTPS Autodiscover domain query
Local XML file
HTTP redirect method
SRV record query
Cached URL in the Outlook profile (new for Outlook 2010 version 14.0.7140.5001 and later versions)
Direct Connect to Office 365 (new for Outlook 2016 version 16.0.6741.2017 and later versions)
Tabiki tek sorun bu değil, bazen network kaynaklı da autodiscover servisine ulaşamadığınız durumlarda yine sonuç can sıkıcı olabiliyor.
Bu durumda aşağıdaki gibi bir uyarı alabilirsiniz;
Your mailbox has been temporarily moved to Microsoft Exchange server.
A temporary mailbox exists, but might not have all of your previous data.
You can connect to the temporary mailbox or work offline with all of your old data.
If you choose to work with your old data, you cannot send or receive e-mail messages.
Exchange Server yüklemelerinde veya CU geçişlerinde aşağıdaki gibi hatalar alabilirsiniz;
Error: The Mailbox server role isn’t installed on this computer. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.UnifiedMessagingRoleNotInstalled.aspx
Error: The Mailbox server role isn’t installed on this computer. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.BridgeheadRoleNotInstalled.aspx
Error: Global updates need to be made to Active Directory, and this user account isn’t a member of the ‘Enterprise Admins’ group. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.GlobalUpdateRequired.aspx
Error: You must be a member of the ‘Organization Management’ role group or a member of the ‘Enterprise Admins’ group to continue. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.GlobalServerInstall.aspx
Error: You must use an account that’s a member of the Organization Management role group to install or upgrade the first Mailbox server role in the topology. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DelegatedBridgeheadFirstInstall.aspx
Error: You must use an account that’s a member of the Organization Management role group to install the first Client Access server role in the topology. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DelegatedCafeFirstInstall.aspx
Error: You must use an account that’s a member of the Organization Management role group to install the first Client Access server role in the topology. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DelegatedFrontendTransportFirstInstall.aspx
Error: You must use an account that’s a member of the Organization Management role group to install or upgrade the first Mailbox server role in the topology. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DelegatedMailboxFirstInstall.aspx
Error: You must use an account that’s a member of the Organization Management role group to install or upgrade the first Client Access server role in the topology. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DelegatedClientAccessFirstInstall.aspx
Error: You must use an account that’s a member of the Organization Management role group to install the first Mailbox server role in the topology. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DelegatedUnifiedMessagingFirstInstall.aspx
Error: Setup encountered a problem while validating the state of Active Directory: Exchange organization-level objects have not been created, and setup cannot create them because the local computer is not in the same domain and site as the schema master. Run setup with the /prepareAD parameter on a computer in the domain and site , and wait for replication to complete. See the Exchange setup log for more information on this error. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.AdInitErrorRule.aspx
Error: The forest functional level of the current Active Directory forest is not Windows Server 2003 native or later. To install Exchange Server 2013, the forest functional level must be at least Windows Server 2003 native. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.ForestLevelNotWin2003Native.aspx
Error: Either Active Directory doesn’t exist, or it can’t be contacted. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.CannotAccessAD.aspx
Warning: Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.NoE12ServerWarning.aspx
Warning: Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers. For more information, visit: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.NoE14ServerWarning.aspx
Kontol ettiğiniz zaman aslında bu hataların gerçekci olmadığını görebilirsiniz. Yani hataların mantıklı hatalar olmadığını fark etmişsinizidir. Bunun temel nedeni yüklemeye çalıştığınız CU veya ilk yükleme ise schema extend işlemi yapmak istemektedir. Ancak yükleme yapmaya çalıştığınız exchange sunucusu farklı bir site içerisinde ise (Schema master’ dan) bu hatayı alırsınız.
Güvenlik
uzmanlarından Dirk-jan Mollema tarafından tespit edilen bir açık kullanılarak
standart bir posta kutusu kullanıcısı yani bir şirket çalışanı kendisini domain
admin yapabilmektedir.
Malum hepimiz
pentest yaptırıyoruz ve standart olarak her pentest sırasında domain admin
hakkını kaptırmamak için elimizden gelen çabayı gösteriyoruz. Ancak pek çok
pentest sırasında nasıl standart bir user açıyor isek beraberindeki porta
kutusu aslında o arkadaşların çok kolay bir şekilde domain admin olmasını
sağlıyor. Bu nedenle exchange server kullanan ve güvenliğe önem veren herkes
için çok kritik bir mail okuyorsunuz şu anda.
Atak iki tane
Python temelli araç ile başarılı bir şekilde gerçekleştiriliyor. Hatta o kadar
iddialı ki bu kodları paylaşmış durumda.
https://github.com/dirkjanm/privexchange/
Özetle size
pentest’ e gelen birisi rahatlıkla domain admin olabilir.
Remove the unnecessary high
privileges that Exchange has on the Domain object (see below for some
links on this).
Enable LDAP signing and enable
LDAP channel binding to prevent relaying to LDAP and LDAPS respectively
Block Exchange servers from making
connections to workstations on arbitrary ports.
Enable Extended Protection for
Authentication on the Exchange endpoints in IIS (but not the Exchange Back
End ones, this will break Exchange). This will verify the channel binding
parameters in the NTLM authentication, which ties NTLM authentication to a
TLS connection and prevent relaying to Exchange web services.
Remove the registry key which
makes relaying back to the Exchange server possible, as discussed in
Microsofts mitigation for CVE-2018-8518.
Enforce SMB signing on Exchange
servers (and preferable all other servers and workstations in the domain)
to prevent cross-protocol relay attacks to SMB.
If EWS push/pull subscriptions
aren’t used, they can be disabled by setting the EWSMaxSubscriptions to 0
with a throttling policy, as discovered by @gentilkiwi here. I haven’t
tested how much these are used by legitimate applications, so testing it
with a small user scope is recommended.
Soru: Mevcut Exchange server üzerine veya
ortamına yeni sürüm bir Exchange server yüklenirken yetkili bir kullanıcı
olmasına rağmen yetki hatası neden alınır?
Cevap: Genel bir
hata olmasına karşın muhtemel schema upgrade işlemi gerektiği için bu false
positive hatayı alıyorsunuz. Bunun sebebi ise eğer schema güncelleme gibi bir
işlem yapılması gerekiyor ise öncelikle schema master rolü ile aynı site
içerisinde hatta ilgili role üzerinde bu yükseltme işlemini gerçekleltirmeniz
önerilmektedir. Bunu yaptıktan sonra kuruluma devam edebilirsiniz.
Özellikle Exchange Server 2013 sonrasında loglama alt
yapısında pek çok değişiklik oldu. Özellikle kendi kendine yönetim ve
iyileştirme politikasının bir ürünü olan “Managed Availability” kavramını çok
ciddi manada sistemin log üretmesine neden oldu.
Öncelikle 2010 uzmanları bu loglar ile sık sık dolan C
disklerinden dolayı tanıştı, daha çok neden bu kadar çok log üretildiğini
araştırdılar, sonuca ulaşınca ise genelde otomatik temizleme komutlarını
zamanlanmış görev yapıp sorundan kurtuldular. Ancak gelin görün ki zaman
içerisinde sorun çözümlemek için bu logların hayati önemi olduğunu anladılar.
Durum böyle olunca logların silme sürelerini en azından son 7 günden 30 güne
yükselttiler. Buraya kadar hayat güzel gidiyordu ancak yine başka bir sorun ile
karşı karşıya kaldık. Çok büyük yapılarda özellikle bildiğiniz gibi sorunların
çözülmesi için yeniden kurmak, silmek tekrar oluşturmak gibi kobi çözümleri çok
kabul edilen çözümler değildir. Şimdi bir kobi çalışanı iseniz sakın alınmayın
bu sektörün bir gerçeği. Bende kobide çalıştım ve çok iyi biliyorum. Eğer sarf
edeceğiniz efor, alacağınız danışmanlığın ücreti karşılığını bulmayacak ise bu
kadar uzman bir personel veya danışmana gerek yoktur. Ancak bir mail kesintisi
ile milyonları kaybeden veya kaybedeceği prestijin telafisi olmayan kurumlar
için bu tarz iletişim alt yapılarındaki kesiniler kabul edilemez. Bir sorunun bu
nedenle kök neden araştırması çok önemlidir. Bir uzman olarak sizlerin de çok
iyi bildiği gibi sorun çözmek için öncelikle teşhisi iyi koymak lazım, bunun
için de iyi bir analiz yani log okumak lazım. Makalemin başında anlattığım
dağınık yapı itibari ile büyük bir exchange sunucu ortamı için bu kadar bilgiyi
toplamak son derece zor olacaktır.
Ama her türlü zorlukta imdadımıza yetişen powershell
burada da hayatımızı kurtarıyor. Aşağıdaki linkten edineceğiniz log collector
komut seti sayesinde tüm exchange loglarını merkezi olarak alabilir ve daha
sonra sorun çözümlemek için kullanabilirsiniz.
Peki nasıl kullanıyoruz. Öncelikle bildiğiniz gibi
exchange server çok fazla log üretiyor ve siz merkezi olarak birden çok sunucu
log dosyasını bir sunucu üzerine toplamak istiyorsanız öncelikle yeterli boş
alanınızın olduğunu kontrol edin. Benim tavsiye yanlış hesaplama durumuna
karşılık C diskinizin dolması = işletim sisteminizin her an mavi ekran vermesi
ve bir daha normal açılmamasına yol açabilir. Ondan en temizi bir yönetim
sunucusu gibi bir sunucuda komutu çalıştırmanız veya gerçekten yeterli
yerinizin olduğundan emin olduktan sonra çalıştırmanızı öneririm.
İlk komutumuz aşağıdaki gibidir;
.\ExchangeLogCollector.ps1 -AllPossibleLogs
Bu komutu çalıştırdıktan sonra komutu çalıştırdığınız
sunucu üzerindeki tüm varsayılan logları toplayıp aşağıdaki dizine
yerleştirecektir;
C:\MS_Logs_Collection
Not: Ortalama 1000 kullanıcı ve iki MBX sunucu olan bir
exchange server ortamında tek bir sunucu için bu komut ortalama 30GB log
topladı, tabiki bu sizin kullanıcı, mail alma gönderme sayısı, ekleri, DAG
yapısı vb pek çok değişkene göre değişir ancak fikir vermesi açısından
paylaşmak istiyorum ki olası bir disk boş yer sorunu yaşamayın.
Bir uyarı sonrası “y” tuşuna basarak toplama işlemi
için onay verebilirsiniz.
Not: remote toplama için exchange server minimum 2012
ve üstü bir OS de çalışmalı. 2008 ve 2008 R2 üzerinde ise bu log toplama
işlemini remote yapamazsınız.
Exchange Server 2010 -2019 sistemleri için mail alma ve gönderme limitlerinden hangisi en bakındır?
Exchange ortamında temel 4 mail alma gönderme limit uygulanabilir; Organizational limits Connector limits Server limits Recipient limits
Bunlardan baskın olan çakışma anında değeri en küçük olandır. Önerilen yapılandırma ise olası bir farklılıkta mailin sistemde en az noktaya kadar ilerlemesidir. Örneğin Kullanıcı kotası düşük ise connector kotalarının yüksel olması malinin aslında buraya kadar iletilmeyi denemesine neden olur. Ama tabiki pek çok gerçek hayat senaryosunda bunu yapamayabilirsiniz.
Değişen ve gelişen teknolojiler ile beraber her geçen gün iletişim için kullandığımız araçların başında gelen e-posta trafiğinin sayısı ve boyutu inanılmaz bir şekilde artmaktadır.
Bunu aşağıdaki görselden çok rahat bir şekilde görebilirsiniz.
Gelişen teknoloji ile beraber sadece mail sayısı değil mail içeriklerinde paylaştığımız görseller, ofis dosyaları veya diğer eklerinde boyutları ciddi büyümüş durumda.
Böyle bir ortamda sistem yöneticileri için en kritik soru kotaların nasıl yapılandırılması gerektiğidir. Tabi ki her şirket iş ihtiyacı farklı olduğu için buradan rakam belirtmek doğru değildir. Kimi şirketler çok iyi bir arşivleme sistemi kurduğu için kullanıcı kotasını 1GB yapar ancak üstündeki tüm veri arşivlenmiş olduğu için kullanıcı 1GB üstündeki verilerine de aynı posta kutusundan erişir. Ancak arşiv sistemi olmayan başka bir şirket 1GB kota koymaya kalkar ve bir bakar ki kullanıcı çalışamaz bir hale gelir. Veya bir tasarımcı için 5GB mail kotası az gelir iken standart bir ofis çalışanı için çok gelir.
Benim bu yazıyı kaleme alma sebebim aslında bunlar değil. Bunlar söylediğim gibi her şirketin ihtiyacına göre belirlemesi gereken bir politika ancak benim gibi danışmanlık yapan insanlar için önemli olan bu mail sistemlerinin sağlıklı çalışması. Bu noktada da iki önemli tavsiyem olacaktır.
Exchange Server sistemlerinde hiç bir kullanıcı için unlimited yani sınırsız kota izni vermeyin.
Exchange Server sistemlerinde hiç bir veri tabanı için unlimited yani sınırsız kota izni vermeyin.
Dışarıdan veya içeriden gelebilecek bir atak veya beklenmedik sorunlarda artan uyarı, bilgilendirme veya izleme mailleri sizin veri tabanlarınız da veya ilgili posta kutusunda limit olmadığı için diskinizin dolmasına sebebiyet verebilir.
Şirkete özel kotayı istediğiniz gibi hesaplayabilirsiniz ancak her zaman disk boyutunu hesaba katmanız lazım.
basit bir hesap ile toplam kullanıcı sayınız ve ortalama kotanız çarpımı toplam disk alanından en az %10 küçük olmalıdır.
