Active Directory Konfigürasyonlarında Yapılan Genel Hatalar

Hataların Giderilmesi İçin Neler Yapılabilir?

Şirketlerdeki IT ortamının yönetiminde Active Directory, Windows ortamları için rakipsiz bir merkezi yönetim aracıdır. İrili ufaklı bir çok şirkette sistem yöneticileri veya dış kaynak firmalar tarafından Active Directory kurulurken bazı konular atlanabiliyor. Gerek tecrübesizlik (ilk zamanlar ben de yaptım) gerekse zaman yetersizliğinden kaynaklanan bu durumlarda genel olarak yapılan ve yapılmaması gerekenlerden bahsetmek gerek çünkü aşağı yukarı hepimiz acemiyken bu yollardan geçtik diye düşünüyorum. En azından meseleğe yeni başlayan arkadaşlar için ve doğru bilinen yanlışların önüne geçebilmek için bunlar önemli konular. Gelelim yapılması gerekenler ve yapılmaması gerekenlere.

1- Zayıf Şifrelerle Oluşturulmuş Servis Hesapları

Şirketlerde bir servis hesabı oluşturulmayan senaryo yok denecek kadar azdır. Bu durumlarda servis hesabı bir kez oluşturulur ve sonrasında şifresi değiştirilmez. Değiştirilmediği bir yana bu şifreler genelde 123456 gibi basit şifreler verilerek ihmal edilir. Bu hesaplara yapılabilecek bir brute-force gibi bir saldırıda basit şekilde ele geçirilmesine sebebiyet verilmiş olur. Servis hesaplarının senaryo destekliyor ise lokal olarak oturum açmasının GPO ile kısıtlanması gerekmektedir. Ama en iyi senaryoda destekliyor ise Group Managed Service Account (gMSA) kullanılması uygundur. Detaylar için buraya tıklayın.

2- Her Yerde Oturum Açmış Domain Admin Hesapları

Yapılan en büyük yanlışların başında Domain Admin hesaplarının son kullanıcı makinelerinde, RDS sunucuları gibi ortak kullanılan sunucularda oturum açmış olmasıdır. Bu da yetmezmiş gibi Veeam, SQL Server gibi bazı uygulamaların yedek alması veya otomatikleştirdiği bazı görevlerde servis hesabı olarak Domain Admin bilgilerinin girilmiş olması da var. Bu yanlıştan derhal dönülmelidir çünkü bu hesapların şifreleri varsayılanda bellekte tutulmaktadır ve mimikatz gibi veya kendi özelinde bazı araçlarla bunlar kazınabilir. Ek sıkılaştırma yapmadıysanız ki yapsanız dahi tavsiye etmem domain admin hesabını domain controller dışında kullanmayın. Domain ortamlarında Tier Modeling yapısını uygulayın. Şifrenizi derhal değiştirerek her bir görev için ayrı hesaplarla otomatikleşmiş işlemleri yönetin ve ihtiyacı olduğu kadar yetki verin. Ortak kullanım alanlarında asla yetkili hesapları kullanmayın. Şüpheli makineleri incelerken yetkili hesaplarla giriş yapmayın.

Şüpheli makineye domain adminle giriş yapıyorum (temsili)

3- Başıboş Bırakılmış Lokal Adminler

Şirketinizde patronunuz, üç harfliniz (yanlış anlaşılmasın CEO felan), kankanız ve gerçekten ihtiyacı olan ne bileyim kim varsa lokal admin yetkisi tanımlanmış kişiler fazlaca olabilir. Öncelikle bunları azaltmak yapabileceğiniz en doğru hamle olacaktır. Yalnızca ihtiyacı olana ihtiyacı olduğu kadar yetki verin. Standart kullanıcılar sizin göz bebeğinizdir onları sevin. Lokal Admin yetkisi olan kişiler için ise ayrı bir GPO uygulamanız olsun, güvenliği üst seviyede tutmak için.

4- Powershell’in Herkeste Açık Olması

Powershell kullanımı çok faydalı ve etki alanı çok yüksek bir araçtır. Windows ile doğrudan etkileşimi vardır. Pek bahsedilmez ama powershell scriptleri dosyasız çalıştığından bir çok antivirüs bu betikleri yakalamakta zorlanır. Tamamen bellekte çalışmasından kaynaklanan bu durum biz sistem yöneticileri için ise tam bir eziyettir. GPO ile ihtiyacı olmayan makinelerde powershell’i yasaklamanız ve loglamanız en doğru karar olacaktır.

5- Süresi Geçmiş Silinmeyen Objeler

Active Directory Users And Computers konsolunda eski bilgisayar ve kullanıcı hesapları kontrol edilerek kullanılmayacak ise silinmeli belirli bir süre sonra kullanılacak ise devre dışı bırakılmalıdır. Ortamda SIEM çözümü kullanılıyor ise bu hesaplar bu işlemlerden sonra izlenmelidir. Powershell kullanarak 180 günden eski aktif olmayan bilgisayarları bulmak için aşağıdaki kodu kullanabilirsiniz:

#Kaynak: Emre’nin sistem odası

# $DaysInactive kaç günü baz aldığı , $domain kendi domainizin adını girin

$domain = “ahmetdoruk.com”
$DaysInactive = 180
$time = (Get-Date).Adddays(-($DaysInactive))
$date = Get-Date ($time) -UFormat %d.%m.%y
$File = “c:\users\%username%\Desktop\Inactive_Computers.txt”
# Son 180 gündür oturum hiç açmamış bilgisayarları $file kısmında yolu yazan dosyaya listeleyerek
$CompList = Get-ADComputer -Filter {LastLogonTimeStamp -lt $time -and operatingSystem -notlike “*server*”} -SearchBase “DC=ahmetdoruk, DC=com” -Properties Name,LastLogonTimeStamp,OperatingSystem |
Select-Object Name, OperatingSystem, @{Name=”Last Logon TimeStamp”; Expression={[DateTime]::FromFileTime($_.lastLogonTimestamp)}} | Export-Csv $File -encoding UTF8 -notypeinformation
# Son 180 günde hiç oturum açmamış bilgisayarların isimlerini getirir
$Computers = Get-ADComputer -Filter {LastLogonTimeStamp -lt $time -and operatingSystem -notlike “*server*”} -SearchBase “DC=ahmetdoruk, DC=com” -Properties Name,LastLogonTimeStamp,OperatingSystem |
Select-Object -ExpandProperty Name

6- Kullanıcıları Güvenli Şifre Politikalarına Zorlamamak

Son kullanıcılar her yere ayrı ayrı kullanıcı adı ve şifreyle girmekten bıkmış insanlardır. Haksız sayılmazlar. Sosyal medya hesaplarının hepsine ayrı ayrı, bankalara ayrı, e-devlete, evdeki bilgisayara, e-postaya, işteki bilgisayara ayrı derken son kullanıcı kolay bir yol bulur. Bütün şifreleri aynı yapmak :) Tamam dışardaki hesapları bizi ilgilendirmez (kısmen) ama şirket içerisindeki şifresi ile gravatar şifresi aynı olursa ne olur? Bakınız! 167 milyon şifre içerisinde şirketinizde çalışan bir kullanıcı da olabilir. O halde ne yapmalıyız? Group Policy ile şöyle örnek bir şifre politikasına zorlayabiliriz;

• Mümkünse 42 günde bir şifresini değiştirmeye zorlayan GPO ile bir politika oluşturabiliriz. Süresi size kalmış ama 6 ayı geçmemesi tavsiye edilir.
• Son 5 veya 10 parolayı kullanamamalarını sağlayabiliriz.
• Minimum 8 hane, küçük ve büyük harf, sayı ve karakter içeren yani karmaşık bir şifre oluşturmaya zorlayarak kolay şifre oluşturmalarını engelleyebiliriz.
• Ek olarak 5 defa denemeden sonra 30 dakikalık bloklama uygulatabiliriz.
• Mümkün ise iki faktörlü doğrulama kullanın.

Böylece şifrelerinin dışarıdaki bir kez oluşturup hiç değiştirilmeyen şifrelerden farklı olmasını sağlayabiliriz. Çözüm mü? Kesinlikle! Nasıl Yapıldığını yazdığım makaleye buradan ulaşabilirsiniz.

7- Eski Protokollerin Kullanılmasına Gereksiz Yere Devam Edilmesi

NTLM gibi eski protokollerin kullanılmaya devam etmesi sistemin zayıflıklarını arttıracaktır. Eğer yapınız uygun ise tüm kullanıcıların Kerberos ile oturum açmasını sağlayan bir güvenlik politikası uygulayın. Windows’un desteğini kestiği güvenlik güncellemesi almayan Windows 7, Server 2008 gibi işletim sistemlerini daha güncel işletim sistemlerine yükseltin.

Domain Controller’da şöyle bir powershell ile kimlerin NTLM ile oturum açtığını tespit edip ona göre aksiyon alabilirsiniz;

Get-WinEvent -FilterHashtable @{logname=’Security’ ; ID=4624} | where {$_.message -match “ntlm v1”} | fl > C:\NTLMv1.txt

Sonuç : ID=4624 NTLM olayları, Workstation Name : NTLM kullanan makine ismi

8- Güvenlik Sıkılaştırmalarının Yapılmaması

Varsayılanda kurulup bırakılan Active Directory kurulumlarında ekstra güvenlik ayarları yapılandırılmmamış olarak gelir. Bunları yapmanın bir çok yolu ve yöntemi vardır ama yanlış yapıldığında domain ortamında kullanıcıların ağda oturum açamamasına sebebiyet verebilir. Etki değerlendirmesi için test ortamında deneyerek yol almanızda fayda var. Hiç yoksa danışman desteğine başvurun. Fidye virüsleri ile ilgili yazımda detaylıca bazı güvenlik önlemlerini yazdığım konuları okuyabilirsiniz.

9- Ortamda Additional Domain Controller Bulunmaması

Primary Domain Controller’ın başına gelecek bir felakette kullanım dışı kalması ve bazı güvenlik yapılandırmalarında kullanıcıların domain controller’ı görmeden oturum açamaması senaryoları aktif olabilir. Ancak her durumda ortama Additional bir Domain Controller kurulmasını tavsiye etmekteyim.

10- Domain Controller Makinesinin Güncellemeleri Geç Takip Etmesi

Büyük bir hatadır. Domain Controller’da oluşabilecek zaafiyetler tüm şirketi/şirketleri etkileyeceğinden mümkün olan en kısa sürede güncellemeleri makineye ulaştırmanız gerekir. Test için ilk önce Additional DC’de güncelleme yapabilirsiniz. Varsa test ortamında doğrudan etkisini görebilirsiniz.

11- Gereksiz Servislerin Domain Controller Makinesinde Çalışır Halde Beklemesi

Hiç kullanmadığınız yazdırma servisi DC makinesinde neden açık bekler? Kullanılmayan servisleri tespit ederek başlangıçta açılmasını devre dışı bırakın. DC’ye ek yazılım kurmaktan da şiddetle kaçının. Domain Controller üzerine başka roller kurmak da sağlıklı çalışmasını etkiler. Bazen yoklukta yapılabiliyor ama zorda kalmadıkça yapmayın.

12- Orta ve Büyük Ölçekli Kurumlarda DC Makinelerde Oluşabilecek Bazı Event’lerin SIEM ile İzlenmemesi

Bununla ilgili ek bir yazı yazmayı düşünmekteyim. Aslında her madde ayrı bir makalelerin konusu. SIEM bizim için alarm üretebilen, bir çok işlemi takip edip bize bildirebilen çok önemli bir güvenlik istihbarat aracıdır. Şirketinizdeki yöneticileri böyle bir yatırımın yapılması konusunda ikna etmeniz çok önemlidir. Bunu yapamıyorsanız en azından Active Directroy’deki önemli bazı işlemleri loglamanız sizin hayrınıza olacaktır.

Bu tip teorik makaleleri yazmayı seviyorum çünkü konuşma yapar gibi hızlıca yazıp yayınlayabiliyorsunuz :) Vakit oldukça her bir maddenin altını nasıl yapıldığına dair detaylı makaleler ile doldurmaya çalışacağım. İyi okumalar…