Brute Force Nedir? Deneme Sınırı ve Hesap Kilitleme

Brute force saldırısı, bir hesabın parolasını tek tek deneyerek bulmaya çalışmaktır. Saldırganın elinde bir açık, bir zafiyet ya da özel bir araç olmak zorunda değildir; yalnız sabrı ve otomatik bir deneme aracı vardır. Savunmanın cevabı da aynı ölçüde basittir: denemeyi sınırlamak.

Telefonunuzun ekran kilidini düşünün. Şifreyi yanlış girdiğinizde telefon size “bir daha deneyin” der. Birkaç yanlıştan sonra tavrı değişir: bir dakika bekletir. Israr ederseniz beş dakika, sonra on beş dakika. Kimse telefonun içine giremesin diye tasarlanmış bir hapishane değildir bu; yalnız deneme hızını düşüren bir mekanizmadır. Gerçek sahibi için bir dakika beklemek katlanılır bir şeydir, ama dakikada binlerce kombinasyon denemeyi uman birinin bütün yöntemini çökertir.

Kurumsal sistemlerde bu mekanizmanın adı account lockout policy’dir ve iyi kurulduğunda telefonunkine benzer, kötü kurulduğunda saldırganın işine yarar. Bu makale ikisinin farkını anlatıyor. Ölçümü de laboratuvarda kendimiz yaptık. Bir domain controller’da kilit kaçıncı denemede devreye giriyor, cevap nasıl değişiyor ve geride hangi kayıt kalıyor?

Baştan bir yanlış anlamayı kapatalım: bu saldırılar Active Directory’ye özgü değildir. Parola soran her yüzeyde olurlar ve pratikte çoğu internete bakan taraflarda, yani web uygulamalarında, yönetim panellerinde, e-postada ve VPN kapılarında görülür. Ölçümü bir domain controller’da yaptık, çünkü sayacı ve kaydı görülebilen yer orası; ama aşağıdaki tablo, aynı saldırının hangi yüzeyde kime karşı yürüdüğünü ve orada savunmanın neden başka bir şey olduğunu gösteriyor.

Bu makale siber güvenlik önlemleri rehberimizin kimlik katmanının derinleşmesidir; siber güvenlik hizmetimizin kimlik ve erişim tarafına karşılık gelir.

Brute Force Saldırısı Nasıl Çalışır?

Saldırganın elinde iki liste vardır: kullanıcı adları ve parolalar. Kullanıcı adları genellikle zaten bilinir, çünkü çoğu kurumda kullanıcı adı e-posta adresinin kendisidir ve e-posta adresleri kamuya açıktır. Geriye parolayı bulmak kalır.

Deneme iki yerde yapılabilir ve ikisi bambaşka şeylerdir:

• Çevrimiçi deneme. Saldırgan sizin giriş ekranınıza, VPN kapınıza ya da e-posta sunucunuza bağlanıp parola dener. Her deneme ağdan gider, sunucu cevaplar ve bu cevap kaydedilir. Bu makalenin konusu budur.
• Çevrimdışı deneme. Saldırgan parolaların hash’lerini ele geçirmiştir ve kendi bilgisayarında saniyede milyarlarca deneme yapar. Orada sizin sunucunuzun koyduğu hiçbir sınır işlemez; savunma, hash’in nasıl üretildiğine bağlıdır. Bunu şifreleme rehberimizin kaba kuvvet bölümünde anlattık.

Ayrım pratikte şunu söyler: çevrimiçi denemede zaman savunmanın tarafındadır. Her denemenin bir ağ turu vardır ve siz o turu yavaşlatabilirsiniz. Çevrimdışı denemede zaman saldırganın tarafındadır.

Üç Akraba Saldırı: Brute Force, Password Spraying, Credential Stuffing

Aynı aileden üç saldırı vardır ve savunmaları farklıdır. Karıştırıldıklarında, alınan önlem gerçekte karşılaşılan saldırıyı hiç görmez.

Password spraying’in kilitlemeyi neden atlattığı bu tabloda görünüyor. Saldırgan tek bir hesapta ısrar etmez; Sirket2026! gibi yaygın bir parolayı yüzlerce hesapta birer kez dener. Hiçbir hesap eşiğe yaklaşmaz, hiçbir kilit açılmaz, ama şirkette o parolayı kullanan tek bir kişi varsa saldırgan içeridedir.

Credential stuffing ise sizin sisteminizdeki bir zayıflığı değil, çalışanın başka bir sitede kullandığı aynı parolayı kullanır. Sızan veritabanları birleştirilip milyonlarca kullanıcı ve parola çifti hâline gelir. Buna karşı parola kuralları yetmez; ikinci bir doğrulama adımı gerekir.

Bu Saldırı Nerede Oluyor? İç Ağ ve İnternete Bakan Yüzeyler

Üçünün de ortak şartı tek: bir giriş ekranı. Bu yüzden saldırı Active Directory’ye özgü değildir, parola soran her yüzeyde olur ve pratikte en çok internete bakan taraflarda görülür, çünkü orayı denemek için içeri girmek gerekmez.

Tablonun en tehlikeli satırı üçüncüsüdür. Kurumsal bir web uygulamasında ya da içerik yönetim sisteminde çoğu zaman hesap kilitleme diye bir şey yoktur. Kullanıcı yüz kez yanlış parola girebilir, hiçbir sayaç dolmaz, hiçbir alarm çalmaz ve pek çok kurulumda kayıt bile tutulmaz. Aşağıda ölçtüğümüz Active Directory mekanizması bu tabloda bir istisnadır, kural değil: saldırıyı sayan ve durduran bir taraf olması, kendiliğinden var olan bir şey değil.

İkinci tehlike iki yüzeyin aynı hesapları paylaşmasıdır. Microsoft 365 kullanan bir kurumda dışarıdan denenen kullanıcı adı, içerideki domain hesabının ta kendisidir. Bulut tarafına yapılan bir deneme, eşikler birbirine göre ayarlanmamışsa içerideki hesabı kilitleyebilir; bunun kuralını aşağıda akıllı kilitleme bölümünde veriyoruz.

Credential stuffing ise ağırlıkla ilk üç satırda görülür. Sızdırılmış çiftlerdeki kullanıcı adı çoğunlukla bir e-posta adresi olduğu için denendiği yer de e-posta ve web uygulamalarıdır.

Hesap Kilitleme: Savunma mı, Saldırgana Silah mı?

Hesap kilitleme, belirli sayıda yanlış denemeden sonra hesabı kullanılamaz hâle getirir. Kulağa kusursuz gelir, ama iki kenarı vardır ve ikincisini Microsoft kendi belgesinde yazar.

Hesap kilitleme eşiği belgesine göre eşik tanımlı bir domainde saldırgan, bütün kullanıcılara bilerek yanlış parola göndererek her hesabı kilitleyebilir. Bunun için ağa erişmesi yeter, kimlik doğrulaması bile gerekmez. Yani kötü kurulmuş bir lockout policy, saldırgana bütün şirketi çalışamaz hâle getirme imkânı verir.

Aynı belge iki referans daha veriyor. Windows güvenlik baseline’ı eşik için 10 hatalı denemeyi başlangıç noktası olarak öneriyor. Varsayılan domain policy’de ise eşik 0’dır, yani hesaplar hiç kilitlenmez. Yerleşik Administrator hesabı da bilerek kilitleme dışında tutulur; yönetici her durumda girebilsin diye.

Kilidin süresi de en az eşik kadar önemlidir. Süresiz kilitleme, her olayda yardım masasına bir iş ve kullanıcıya bir kesinti yazar. Kısa süreli kilit ise saldırganı yavaşlatırken gerçek kullanıcıyı bir iki dakikadan fazla bekletmez.

Laboratuvarda Ölçtüm: Eşik Sıfır ile Eşik Beş Arasındaki Fark

Bu mekanizmayı bir domain controller’da kendim ölçtüm. Ortam kendi laboratuvarımız: dc01, bir Windows domain controller. Ölçüm için açtığım bf-test hesabına LDAP üzerinden yanlış parolayla bağlanıp dönen cevabı kaydettim.

İlk bulgu ölçüme başlamadan çıktı. Şifresiz LDAP portuna (389) yapılan basit bağlama denemesi, parola yanlış olduğu için değil, imzasız bağlama kapalı olduğu için reddedildi:

HATA: Bu işlem için sağlam kimlik doğrulaması gerekiyor.

Ölçüm bu yüzden şifreli porttan (636) yapıldı. Kimlik doğrulama hatasının dönüş kodu, LDAP cevabının data alanında duruyor. 52e parolanın yanlış olduğunu, 775 hesabın kilitli olduğunu söyler.

Birinci koşu, varsayılan policy’yle. Domain nesnesindeki lockoutThreshold değeri 0 idi. Art arda 12 yanlış deneme yaptım:

 1  20:32:50.968  52e   parola yanlis           100 ms
 2  20:32:51.310  52e   parola yanlis            13 ms
 ...
12  20:32:54.838  52e   parola yanlis            14 ms

Hiçbiri hesabı kilitlemedi. On iki denemenin on ikisi de aynı cevabı verdi ve saldırgan istediği kadar denemeye devam edebilirdi.

İkinci koşu, eşik 5 yapıldıktan sonra. Aynı hesaba temiz bir sayaçla yeniden denedim:

 1  20:33:59.682  52e   parola yanlis           100 ms
 2  20:34:00.226  52e   parola yanlis            16 ms
 3  20:34:00.750  52e   parola yanlis            17 ms
 4  20:34:01.278  52e   parola yanlis            18 ms
 5  20:34:01.804  52e   parola yanlis            16 ms
 6  20:34:02.328  775   HESAP KILITLI            13 ms

Beş denemeye izin verildi, beşincisi hesabı kilitledi ve altıncı denemede cevap değişti. Buradaki ayrıntı savunma açısından önemli: saldırgan kilidi görür. Cevabın 52e’den 775’e dönmesi, ona “bu hesapta kilitleme var, ısrar etme, başka hesaba geç” der. Yani kilitleme tek başına saldırganı kör etmez, yalnız yavaşlatır.

Kilidin süresini de ölçtüm. Kilitlenme saat 20:34:02’de oldu, on saniyede bir tek deneme yaparak yokladım ve hesap 20:35:11’de yeniden 52e vermeye başladı. Ayarladığım kilit süresi 60 saniyeydi; ölçülen fark, yoklama aralığından geliyor.

Sayaç Ne Zaman Sıfırlanır?

İki koşu arasında beklemediğim bir şey oldu ve mekanizmanın en çok atlanan ayarını gösterdi. Eşiği 5 yaptıktan hemen sonraki denemede hesap ikinci denemede kilitlendi. Sebebi şuydu: ilk koşudaki 12 başarısız deneme sayaçta hâlâ duruyordu.

Windows’ta hatalı deneme sayacı her başarısız girişte artar, ama kendiliğinden sıfırlanması için bir süre geçmesi gerekir. Bu sürenin adı gözlem penceresidir ve laboratuvardaki değeri 10 dakikaydı. Yani “beş deneme hakkı” cümlesi eksik bir cümledir; doğrusu “gözlem penceresi içinde beş deneme hakkı” olur.

Pratikte iki sonucu var. Sabah yanlış parola girip iki hak harcayan bir kullanıcı, öğleden sonra üç kez daha yanılırsa kilitlenir. Saldırgan açısından ise tersi geçerlidir. Pencereyi bilen biri denemelerini araya boşluk koyarak yayabilir ve sayacın sıfırlanmasını bekleyebilir. Bu yüzden pencereyi kısaltmak kullanıcı için rahatlık, saldırgan için de kolaylıktır; ikisi arasındaki denge bilinçli kurulmalıdır.

Ölçümü temizlemek için sayacı sıfırladım ve pencereyi 60 saniyeye indirdim; yukarıdaki temiz koşu bu ayarla alındı.

Savunma Tarafında Ne Göründü?

Denemeler sırasında domain controller’ın güvenlik günlüğünde şunlar birikti:

Id     Adet   İlk                   Son
4625     21   20:32:22              20:35:11
4740      2   20:33:26              20:34:01

4625 başarısız oturum açma, 4740 ise hesabın kilitlendiği andır. Tek bir 4625 kaydının içine bakınca saldırının kaynağı da çıkıyor:

TargetUserName : bf-test
Status         : 0xc000006d
SubStatus      : 0xc000006a   (parola yanlış)
IpAddress      : 192.168.1.115
ProcessName    : lsass.exe

Yani sunucu, hangi hesaba, hangi adresten, hangi saniyede denendiğini zaten yazıyor. Bu kayıtların okunmadığı bir kurumda saldırı sessiz geçer; okunduğu bir kurumda ise parola denemesi, saldırganın attığı ilk adımda görünür hâle gelir.

Ölçüm bittikten sonra eşiği ve süreleri eski değerlerine döndürdüm, test hesabını sildim.

Ölçümün Yan Bulgusu: Değiştirilen Parola Hemen Geçersiz Olmuyor

Ölçümler sırasında beklemediğim bir şey çıktı ve bir olaydan sonra sık kurulan şu cümleyi doğrudan ilgilendiriyor: “parolayı değiştirdik, kapattık.”

Bir test hesabının parolasını değiştirdim ve eski parolayla giriş denedim. Giriş başarılı oldu. Bunu dakika dakika ölçtüm:

parola degistirildi: 21:24:01
+0 dk  21:24:02  000  ESKI PAROLA CALISTI
+1 dk  21:25:02  000  ESKI PAROLA CALISTI
+2 dk  21:26:02  000  ESKI PAROLA CALISTI
+3 dk  21:27:02  000  ESKI PAROLA CALISTI
+4 dk  21:28:03  000  ESKI PAROLA CALISTI
+5 dk  21:29:03  52e  reddedildi

Eski parola tam beş dakika boyunca çalıştı, beşinci dakikada reddedildi. Bu bir hata değil, Microsoft’un KB 906305’te belgelediği bir davranış: “Bir domain kullanıcısı NTLM kullanarak parolasını başarıyla değiştirdikten sonra, eski parola kullanıcı tarafından tanımlanabilen bir süre boyunca ağ erişimi için kullanılmaya devam edebilir.” Amaç, birden çok makinede oturum açmış servis hesaplarının parola değişikliği yayılırken çalışmaya devam edebilmesi.

Süre OldPasswordAllowedPeriod kayıt defteri değeriyle ayarlanıyor; tanımlı değilse varsayılan beş dakika. Laboratuvardaki domain controller’da bu değer tanımlı değildi, ölçtüğüm süre de tam olarak buydu.

Kapsamı doğru anlamak önemli: bu kural yalnız NTLM ile ağ erişimi için geçerli, etkileşimli oturum açma davranışı değişmiyor ve Kerberos kullanan bileşenler bundan etkilenmiyor. Ayrıca yalnız domain hesaplarında, ve parola geçmişi en az iki parolayı hatırlayacak şekilde ayarlıysa çalışıyor.

Pratik sonucu şu: bir parolanın ele geçtiğini öğrendiğiniz an parolayı değiştirmek yeterli bir müdahale değildir, kapı birkaç dakika daha aralık kalır. Microsoft’un aynı belgedeki tavsiyesi de bu yönde: parola sıfırlanırken kullanıcının bir sonraki oturum açmada parolasını değiştirmesi işaretlenmeli, böylece eski parola en kısa sürede geçersiz kılınır. Acil bir olayda hesabı geçici olarak devre dışı bırakmak, beklemekten daha kesin bir cevaptır.

Daha İyi Tasarım: Kilit Yerine Uzayan Bekleme

Ölçümün gösterdiği şey şu: kilitleme çalışıyor, ama ikili bir cevap veriyor. Hesap ya açıktır ya kilitlidir. Oysa savunmanın elinde üçüncü bir cevap var: bekle.

ABD’nin kimlik doğrulama standardı NIST SP 800-63B, bir hesapta art arda başarısız denemelerin 100’ü geçmemesini şart koşuyor ve kullanıcıyı gereksiz yere kilitlememek için bir yöntem öneriyor: hesap sınıra yaklaştıkça uzayan bir bekleme süresi, örneğin 30 saniyeden bir saate kadar. Aynı belge, riske dayalı değerlendirmede IP adresini ve coğrafi konumu da sinyal olarak sayıyor.

Telefon benzetmesinin tam karşılığı budur. Telefon sizi hesabınızdan atmaz, yalnız bekletir ve her yanlışta biraz daha uzun bekletir.

Bu yaklaşımın pratik üstünlüğü, yardım masasını da rahatlatmasıdır. Süresiz kilitlemede her yanlış parola bir destek talebine dönüşür; uzayan beklemede kullanıcı kendi başına toparlanır.

Aynı fikir firewall’ların yönetim girişinde de var. Lab’daki FortiGate, üç hatalı denemeden sonra adresi 60 saniye bekletti ve beklerken yapılan her deneme süreyi baştan başlattı; ölçümü FortiGate Firewall yönetim erişimi yazımızda gösterdim.

Microsoft Entra Akıllı Kilitleme: Bulutta Farklı Çözüm

Kimlik doğrulama bulutta yapılıyorsa mekanizma biraz daha akıllıdır ve üçüncü cevabı zaten verir. Microsoft Entra’nın akıllı kilitleme özelliği her kurumun Entra ortamında, yani her tenant’ta varsayılan olarak açıktır ve belgesine göre şöyle çalışır:

• Varsayılan eşik 10 başarısız denemedir. İlk kilit bir dakika sürer, sonraki kilitler daha uzun. Microsoft artış oranını bilerek açıklamıyor, çünkü saldırgan oranı bilirse ona göre bekler.
• Aynı yanlış parola sayacı artırmaz. Servis son üç hatalı parolanın hash’ini tutar; aynı yanlışı defalarca yazan kullanıcı bu yüzden kilitlenmez.
• Tanıdık ve tanıdık olmayan konumun sayacı ayrıdır. Ofisinden giren çalışan ile bilinmeyen bir adresten gelen deneme aynı kefeye konmaz.

Şirket içinde Active Directory, bulutta Entra çalışıyorsa iki policy’nin birbirine göre ayarlanması gerekiyor. Microsoft’un kuralı net: bulut eşiği şirket içi eşikten küçük, bulut kilit süresi şirket içi süreden uzun olmalı. Örnek olarak bulutta 10, şirket içinde 20; bulutta 120 saniye, şirket içinde 60 saniye veriliyor. Amaç, saldırıyı şirket içi hesaplara ulaşmadan bulut tarafında durdurmaktır; aksi hâlde buluta gelen bir parola denemesi, şirket içindeki gerçek hesabı kilitler.

Bu, kendi ölçümümüzün de tamamlayıcısı. Laboratuvardaki domain controller ikili cevap veriyordu: açık ya da kilitli. Bulut tarafı aynı işi konuma ve parola tekrarına bakarak yapıyor, yani gerçek kullanıcıyı daha az cezalandırıyor.

Kilitlemenin Göremediği Saldırı ve İzlemenin Rolü

Hesap başına kilitleme, hesap başına sayar. Password spraying tam olarak bu sayacın dışından geçer: yüz hesapta birer deneme, hiçbir sayaç dolmaz.

Ölçüm: On İki Hesaba Tek Parola

Bu cümleyi de laboratuvarda sınadım, çünkü “sayaç dolmaz” iddiası ölçülmeden yazılacak bir şey değil. Aynı domain controller’da on iki test hesabı açtım, on birine benzersiz parolalar verdim, birine de karmaşıklık kuralının ürettiği tipik kalıptan bir parola koydum: Sirket2026!. Eşik yine 5, kilit süresi ve gözlem penceresi 60 saniye. Sonra o tek parolayı on iki hesabın hepsinde birer kez, arka arkaya iki tur denedim.

tur 1  sp-test01  52e  parola yanlis
tur 1  sp-test02  52e  parola yanlis
...
tur 1  sp-test07  000  GIRIS BASARILI
...
tur 2  sp-test12  52e  parola yanlis

hesap      badPwdCount  kilitli
sp-test01            2  hayir
sp-test02            2  hayir
...
sp-test07            0  hayir
...
sp-test12            2  hayir

Yirmi dört denemenin yirmi ikisi başarısız oldu, ikisi başarılı: ortak parolayı taşıyan hesaba iki turda da girildi. Hiçbir hesapta sayaç 2’yi geçmedi, yani eşiğin (5) yarısına bile gelmedi ve hiçbir hesap kilitlenmedi. Lockout policy açıktı, doğru çalışıyordu ve saldırıyı görmedi bile.

Sunucu tarafında kalan iz de bunu doğruluyor:

Id     Adet   Farklı hedef hesap   Süre                 Kaynak IP
4625     22   11                   21:22:52 - 21:22:57  192.168.1.115
4740      0   -                    -                    -
4624      2   sp-test07            21:22:53, 21:22:56   192.168.1.115

Altı saniye içinde, tek bir adresten, on bir farklı hesaba başarısız giriş. Tek bir kilitlenme kaydı yok, çünkü kilitlenecek bir hesap olmadı. Saldırının bıraktığı tek işaret desendir. Tek tek bakıldığında hepsi “kullanıcı parolasını yanlış yazmış” gibi görünen kayıtlar, yan yana konduğunda başka bir şey anlatıyor. Bu yüzden password spraying’e karşı kurulan savunma kilitleme değil, aşağıdaki üç maddedir.

Bir ayrıntı daha: başarılı girişin kaydı ayrı bir olay kimliğiyle (4624) tutuluyor. Saldırgan içeri girdiğinde sistem bunu da yazıyor, ama o satır yüzlerce normal giriş arasında duruyor. Onu fark ettiren şey, aynı saniyelerde aynı adresten gelen on bir başarısız denemedir.

Bu boşluğu kapatan üç önlem var:

• Kaynak başına sınır. Aynı IP adresinden gelen denemeler, hangi hesaba yapıldığından bağımsız olarak sayılır ve sınırlanır. Linux tarafında bunun hazır aracı fail2ban, kimlik doğrulama kayıtlarını izleyip eşiği aşan adresi geçici olarak engeller.
• Yasaklı parola listesi. Yaygın ve sızdırılmış parolalar hiç kabul edilmezse, saldırganın denediği tek parola kimsede çıkmaz. NIST bunu da şart koşuyor.
• Alarm. Aynı kaynaktan kısa sürede onlarca farklı hesaba düşen 4625 kayıtları, tek başına anlamsız görünen olayların birlikte anlattığı bir desendir. Kayıtların merkezde toplanmasını Syslog rehberimizde ve Syslog sunucusu kurulumu sayfamızda anlattık. Her cihaz bu adresi yazmaz. Lab switch’imin başarısız giriş kaydı kullanıcı adını taşıdı ama kaynak adresi taşımadı; ölçümü switch syslog ayarı yazımızda anlattık.

Active Directory tarafında password policy, ayrıcalıklı hesapların ayrılması ve acil durum hesapları Active Directory güvenlik sıkılaştırması rehberimizin konusu. İnternete açık bırakılmış bir uzak masaüstü kapısının neden bu saldırıların ilk hedefi olduğunu ise RDP güvenliği bölümünde yazdık.

Yasaklı Parola Listesi: Active Directory Zayıf Parolayı Reddedebilir mi?

Yukarıdaki ölçümün can alıcı satırı, ortak parolayı taşıyan hesaba girilmesiydi. Saldırı oradan yürüdü. Akla gelen ilk soru da şu oluyor: o parola hiç kabul edilmeseydi, saldırının deneyecek bir şeyi kalır mıydı?

Yerleşik Karmaşıklık Kuralı Bunu Yapmıyor

Active Directory’de açık olan parola karmaşıklığı ayarı, parolanın içinde büyük harf, küçük harf, rakam ve sembol gruplarından en az üçünün bulunmasını ister. Kelimenin ne olduğuna bakmaz. Bunu da ölçtüm: laboratuvardaki domainde bir test hesabına sırayla dört parola atamayı denedim.

PAROLA TESTI  'Password1'    -> KABUL EDILDI
PAROLA TESTI  'Sirket2026!'  -> KABUL EDILDI
PAROLA TESTI  'Yaz2026!!'    -> KABUL EDILDI
PAROLA TESTI  'parola123'    -> REDDEDILDI  (parola ilkesi isteklerini karsilamiyor)

Sonuç tek cümleyle şudur: dünyada en çok denenen parolalardan biri olan Password1 kabul edildi, küçük harfli parola123 reddedildi. Reddedilen parola daha güvenli olduğu için değil, karmaşıklık kutucuklarından birini işaretlemediği için reddedildi. Karmaşıklık kuralı bir parolanın biçimini denetler, tahmin edilebilirliğini değil. Sirket2026! gibi kalıpların yaygınlaşmasının sebebi de tam olarak budur: kuralı geçen en kolay kalıp odur.

Microsoft Entra Parola Koruması: Reddetmeyi Domain Controller’a Öğretmek

Yasaklı parola denetimini Active Directory’ye eklemenin Microsoft tarafındaki yolu Microsoft Entra Parola Koruması. Şirket içi kurulumu iki bileşenden oluşuyor: domain controller’lara kurulan bir DC aracısı (bir parola filtresi DLL’i olarak çalışır) ve forest’te herhangi bir domain üyesi makinede çalışan bir proxy servisi. Policy buluttan indirilir, sysvol’de saklanır ve parola değişikliği anında yerel olarak uygulanır.

Microsoft’un kendi belgesindeki tasarım ilkeleri, böyle bir kuruluma ilk sorulan soruları da karşılıyor: domain controller’ların internete çıkması gerekmez, üzerlerinde yeni bir ağ portu açılmaz, şema değişikliği istenmez ve kullanıcının açık metin parolası domain controller’dan dışarı çıkmaz.

Uygulamadan önce bilinmesi gereken dört şey var:

• Denetim modunda başlanır. Microsoft’un kurulum belgesi de bunu öneriyor: Audit modunda zayıf parola reddedilmez, yalnız event log’a yazılır. Böylece kuralın kimleri etkileyeceği, kimse kapıda kalmadan görülür. Hazır olunca Enforced moda geçilir.
• Bütün domain controller’lara kurulmalıdır. Aracı yalnız kendi üzerindeki parola değişikliklerini denetler ve kullanıcının hangi DC’ye düşeceği seçilemez. Kısmi kurulum Microsoft’un kendi ifadesiyle güvenli değildir, yalnız test içindir.
• Lisans gerekiyor. Lisans tablosuna göre genel yasaklı liste bulut hesapları için ücretsiz katmanda da geçerli, ama şirket içi Active Directory’ye uygulamak Entra ID P1 ya da P2 istiyor. Kurumun kendi terimlerini yasaklayan özel liste de aynı lisansa bağlı ve en fazla 1.000 terim alıyor.
• Terim listesi marka adlarından oluşur, parola listesinden değil. Şirket adı, ürün adı, şehir, kısaltma. Algoritma normalleştirme yapıyor (büyük harfleri küçültüyor, 0’ı o’ya, 1’i l’ye, @’i a’ya çeviriyor) ve bir harf uzaklığındaki varyasyonları da yakalıyor. Yani SistemKusu terimini yasakladığınızda S1stemKusu! de kapanıyor: 1 önce l oluyor, slstemkusu ile sistemkusu arasında tek harf fark kalıyor.

Lisans Yoksa: Parola Filtresi DLL’i

Entra lisansı olmayan kurumlarda aynı işi yapan açık kaynaklı parola filtresi DLL’leri var; Windows’un LSA parola filtresi arayüzünü kullanırlar, yani mekanizma Microsoft’un kendi ürünüyle aynıdır. Bu araçlar sızdırılmış parola listelerini içeri aktarabildiği için kapsamları da geniş olur. Kurulum kararı verilirken bakılacak yer, aracın hangi listeyi kullandığı ve reddi event log’a yazıp yazmadığıdır. Yazmıyorsa kullanıcı neden reddedildiğini anlamaz ve yardım masası aramaları başlar.

Hangi yol seçilirse seçilsin, yasaklı liste bu makaledeki ölçümün gösterdiği boşluğu doğrudan kapatıyor: saldırganın denediği tek parola hiçbir hesapta yoksa, spraying deneyecek bir şey bulamaz.

Nereden Başlanır?

Ölçtüğümüz mekanizma, doğru sırayla kurulduğunda birkaç saatlik bir iştir. Sıra şöyle işler:

1. Uzaktan erişimde ve e-postada çok faktörlü doğrulama. Parolanın tahmin edilmesi tek başına yetmez hâle gelir; bu, listedeki tek en etkili adımdır. Yöntem seçimi ve kurulum sırası için 2FA nedir makalesine bakın.
2. Yönetim arayüzlerini internete kapatmak. Denenecek kapı yoksa deneme de olmaz.
3. Deneme sınırı ve kilit süresi. Eşik yazılır, kilit süresiz bırakılmaz, yerleşik yönetici hesabı için ayrı bir kurtarma yolu tanımlanır.
4. Kaynak başına sınır ve yasaklı parola listesi. Password spraying’i kilitlemeden bağımsız olarak karşılar; yasaklı listenin Active Directory tarafındaki karşılığını yukarıda anlattık.
5. Başarısız giriş alarmı. Kilitlenmeler ve 4625 desenleri birinin önüne düşer.
6. Aynı soruyu internete bakan yüzeylere de sorun. Web uygulamanızda ve yönetim panelinizde kaç yanlış denemeye izin veriliyor, deneme kaydı tutuluyor mu? Çoğu kurulumda cevap “sınırsız” ve “hayır” çıkıyor.

Kurumunuzda bu adımların hangisinin eksik olduğunu görmek için tahmine gerek yok: sunucularınız zaten kaydı tutuyor. Son yedi gündeki başarısız oturum açma sayısını tek satırla çıkarabilirsiniz:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-7)} | Measure-Object

Sayı üç haneliyse ve bunu yapan sizin kullanıcılarınız değilse, kapınız çoktan bulunmuş demektir.

Sonuç: Brute Force Savunması Basit, Ama Ayrıntıdadır

Brute force, siber güvenliğin en eski ve en basit saldırısıdır: parolayı tek tek denemek. Savunması da aynı ölçüde basittir, ama ayrıntıda saklıdır. Laboratuvarda ölçtüğümüz üç şey bunu özetliyor. Varsayılan ayarda hiçbir kilit yoktu ve on iki deneme aynı cevabı aldı. Eşik açılınca beşinci denemede kilit devreye girdi ve saldırganın gördüğü cevap değişti. Kilit, ayarlandığı süre kadar sürdü ve her denemenin kaydı kaynak adresiyle birlikte sunucuda kaldı.

Ölçümün ikinci yarısı, kilitlemenin sınırını gösterdi. Tek bir yaygın parolayı on iki hesapta denediğimde hiçbir sayaç eşiğe yaklaşmadı, hiçbir hesap kilitlenmedi ve ortak parolayı taşıyan hesaba girildi. Geriye kalan tek işaret, altı saniye içinde tek adresten on bir hesaba düşen başarısız giriş kayıtlarıydı. Aynı gün ölçtüğüm iki şey daha bu tabloyu tamamlıyor. Active Directory’nin yerleşik karmaşıklık kuralı Password1 parolasını kabul ediyor; değiştirilen bir parola da ağ erişiminde beş dakika daha çalışmaya devam ediyor.

Buradan çıkan asıl ders, kilitleme kutusunu işaretlemek değil. İyi bir deneme sınırı gerçek kullanıcıya saniyeler, saldırgana saatler kaybettirir; kötü kurulmuş olanı ise saldırganın elinde bütün şirketi kilitleyen bir düğmeye dönüşür. Aradaki farkı yaratan şey eşiğin sayısı değil, kilidin süresi, yasaklı parola listesinin varlığı, ikinci doğrulama adımı ve kayıtlara bakan biri olup olmadığıdır. Bir de şu: bu sayacın hiç olmadığı yüzeyleriniz, yani web uygulamanız ve yönetim paneliniz, aynı saldırıyı çok daha sessiz karşılıyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn