Windows kimlik doğrulama prosedürü. Eski bir Windows NTLM kimlik doğrulama hatası, kullanıcının anonimliğini kaldırmanıza izin verir.Parolaları hesap veritabanında saklamak

02/11/2011 Jean de Clercq

Elbette herhangi bir Windows yöneticisi, bir Windows ortamında iki ana kimlik doğrulama protokolüyle birden fazla kez uğraşmak zorunda kalmıştır: Kerberos ve NTLM. Bu makale, Kerberos ve NTLM'nin Windows 7 ve Windows Server 2008 R2'de nasıl desteklendiğine odaklanmaktadır. Ama önce, bu protokoller arasındaki temel farkları vurgulamak istiyorum.

Microsoft, Windows 2000'de Kerberos protokolüne öncülük etti. NTLM, Windows NT günlerinde çok daha önce kullanıldı. Kerberos, güvenilir üçüncü taraf (TTP) konseptine dayalı bir kimlik doğrulama protokolüdür, NTLM ise bir sorgulama / yanıt mekanizmasına dayanmaktadır. İki protokol arasındaki farklar tabloda daha ayrıntılı olarak açıklanmıştır.

NTLM kimlik doğrulaması sırasında veri alışverişinde bulunulurken, bir sunucu kaynağı (örneğin, bir dosya sunucusu) istemciye gönderilen bir istek oluşturur. İstemci, kullanıcının parolasının bir karmasını içeren bir NTLM yanıtı oluşturur ve sunucu bu yanıtın doğruluğunu doğrular. İstemci yerel bir hesap kullanıyorsa, sunucu, kullanıcının yerel Güvenlik Hesap Yöneticisi (SAM) veritabanında depolanan parola karmasını kullanarak kullanıcının yanıtını doğrular. İstemci bir etki alanı hesabı kullanıyorsa, yalnızca etki alanı denetleyicileri Active Directory (AD) veritabanlarında kullanıcı parolası karmalarının kopyalarını sakladığından, sunucu doğrulama için etki alanı denetleyicisine bir yanıt gönderir.

Windows Kerberos'ta, güvenilir bir üçüncü taraf, Kerberos Anahtar Dağıtım Merkezi (KDC) hizmetini barındıran Windows 2000 veya sonraki bir etki alanı denetleyicisidir. KDC, Kerberos'un etkin olduğu bir istemci ile bir sunucu arasında kimlik doğrulamayı kolaylaştırır. KDC hizmeti, AD sisteminin bir parçası olarak otomatik olarak kurulur ve iki alt sistemden oluşur: Kimlik Doğrulama Hizmeti (AS) ve Bilet Verme Hizmeti (TGS).

Bir kullanıcı Kerberos protokolünü kullanarak bir Windows etki alanında oturum açtığında, Windows istemcisi önce kullanıcının parolasını kullanarak etki alanı denetleyicisinde kullanıcının kimliğini doğrular. Aynı zamanda, istemci, kimlik doğrulama hizmetine bir Bilet Hibe Bileti (TGT) bileti talep eder. TGT, sonraki kimlik doğrulama isteklerinde kullanıcının parolasının yerini alacak geçici bir parola (varsayılan olarak ömrü 8 saattir) olarak düşünülebilir. Kullanıcının sunucu kaynağına erişmesi gerektiğinde, istemci, sunucu kaynağının kimliğini doğrulamak için bir TGT yayınlamak için bir TGT sunacaktır. NTLM'den farklı olarak Kerberos'un Windows Güvenlik Hesapları Yöneticisi ile yerel kimlik doğrulaması için kullanılmadığını unutmayın; kapsamı, bir etki alanı denetleyicisinde etki alanı kimlik doğrulamasıyla sınırlıdır.

Kerberos, Windows 2000 ve Microsoft'un daha yeni sürümlerinde standart kimlik doğrulama protokolüdür. Bu işletim sistemlerinde, kimlik doğrulama protokolü bir anlaşma mekanizması kullanılarak tanımlanır. Varsayılan Kerberos protokolü uygun değilse veya kimlik doğrulamayla ilgili istemci veya sunucu bileşenlerinden biri tarafından desteklenmiyorsa, Windows NTLM'ye geçer.

Neden Kerberos?

Kerberos, çeşitli nedenlerle NTLM'den daha verimlidir. Kerberos ile, kullanıcının parola karması, NTLM'ye göre çok daha az açığa çıkar. Parolanın karması, yalnızca kullanıcı bir TGT istediğinde ortaya çıkar - özünde, her sekiz saatte bir. Öte yandan, NTLM ile, istemci sunucuda kimlik doğrulaması yapmak için NTLM kullandığında parola karması açığa çıkar. Bu, Kerberos'un NTLM'ye göre önemli bir avantajıdır; gerçek şu ki, ağ trafiğini şifre karmalarının varlığı için kontrol eden özel araçlar var. Bu araçlar, algılanan karmaları yakalar ve bunlardan kullanıcı parolalarının kurtarılmasını kaba kuvvetle gerçekleştirir.

Kerberos'un bir diğer avantajı, paket yeniden iletim saldırılarına karşı koruma sağlamak için zaman damgaları kullanmasıdır. Bu nedenle, Kerberos merkezli bir Windows ortamında kusursuz çalışan bir zaman eşitleme hizmetine sahip olmak çok önemlidir. Windows 2000 ve sistemin daha yeni sürümlerinde, zaman hizmetleri ön yapılandırma olmadan çalışır. Farklı bilgisayarlardaki bilgisayar saatleri senkronize edilmezse, bu, Kerberos kimlik doğrulama işlemi sırasında ek trafiğe neden olabilir veya en kötü durumda, bu durum kimlik doğrulama işleminde bir hataya neden olabilir.

Yukarıdakilere ek olarak, Kerberos protokolü, karşılıklı kimlik doğrulama ve kimlik doğrulama delegasyonu gibi gelişmiş kimlik doğrulama özelliklerini uygular. Karşılıklı kimlik doğrulama, kullanıcı ve hizmetin birbirinin kimliğini doğrulaması anlamına gelirken NTLM, kullanıcının kimliğini doğrulamakla sınırlıdır. Bu işlevsellik olmadan, kullanıcıların kimlik bilgilerini sahte bir sunucuya sağladığı durumlar ortaya çıkabilir.

Bir hizmet, kimlik doğrulama yetkilendirme mekanizmasını kullanarak bir kullanıcı adına uzak kaynaklara erişebilir. Başka bir deyişle, kullanıcı, proxy sistemine (kullanıcı) kimliğini uygulama sunucusunda kendi adına kanıtlama hakkını verebilir. Sonuç olarak, uygulama sunucusu, proxy sisteminin kimliğine göre değil, kullanıcının kimliğine göre yetkilendirme kararları verebilmektedir. Temsilci kimlik doğrulama özelliği, Web tabanlı bir ön uç kullanarak veritabanlarına erişim gibi çok katmanlı uygulamalarda çok kullanışlıdır.

Son olarak şunu söylemeliyim ki Microsoft uzmanları NTLM protokolünü modernize etmek için çok uğraşmış, yani NTLMv2'nin NT4 SP4 ortamında desteklenen bir versiyonunu ve daha yeni versiyonlarını oluşturmuş olsalar da, Microsoft Kerberos'ta daha modern şifreleme algoritmaları uygulanıyor. . Bunu Kerberos Şifreleme Araçları bölümünde daha ayrıntılı olarak ele alacağım.

NTLM protokolünün sınırlamaları

Kerberos kimlik doğrulamasının faydaları yadsınamaz. Ancak, AD Server 2008'de bile, Windows 2000 öncesi bir Windows sistemine bağlandığınızda veya net use komutunu ve bir IP adresini (NetBIOS adı değil) kullanarak paylaşılan bir kaynağa bağlandığınızda olduğu gibi, Windows genellikle NTLM kullanır. Ayrıca, hizmet asıl adları (SPN) düzgün yapılandırılmamış olan uygulamalar yine de NTLM'yi kullanır.

Şu anda hangi protokolü (NTLM veya Kerberos) kullandığınızı öğrenmek için, netmon yardımcı programını veya başka bir ağ izleyicisini kullanarak NTLM trafiğini görselleştirebilirsiniz; bir alternatif, klist aracını (Windows 7 ve Server 2008'de bulunur) kullanarak Kerberos bilet önbelleğinin içeriğini kontrol etmektir. Windows 7 ve Server 2008'de Microsoft, kullanıcılarınız ve uygulamalarınız tarafından NTLM kullanımını izlemek ve engellemek için kullanabileceğiniz yeni Grup İlkeleri'ni tanıttı. Bu tür üç ilke vardır: biri gelen NTLM trafiği için (sunucu düzeyinde izleme ve engelleme için), diğeri giden NTLM trafiği için (istemci düzeyinde izleme ve engelleme için) ve biri etki alanı trafiği için (sunucu düzeyinde izleme ve engelleme için). etki alanı denetleyici düzeyi). Bunlar, Bilgisayar Yapılandırması, Windows Ayarları, Güvenlik Ayarları, Yerel İlkeler öğeleri sırayla seçilerek erişilebilen Güvenlik Seçenekleri Grup İlkesi Nesnesi (CPO) kapsayıcısında bulunur (bkz. Şekil 1). Hepsi Ağ güvenliği: Restrict NTLM: öğesiyle başlar.

Her ilke ayarının denetim ve engelleme parametreleri vardır. NTLM denetimini etkinleştirdiğinizde program, orijinal NTLM verileri ve 8001, 8002, 8003 ve 8004 sayılarıyla olay günlüğü girişleri oluşturur. Günlük girişleri, Olay Görüntüleyici (Yerel), Uygulamalar ve Hizmet Günlükleri, Microsoft ile Operasyonel kapsayıcıda depolanır. , Windows, NTLM. Bir test ortamında NTLM'yi denetleyerek başlamanızı ve tüm uygulamalarınızın orada doğru şekilde temsil edildiğinden emin olmanızı öneririm. Protokolün kullanımını keyfi olarak engellemeye başlarsanız, büyük olasılıkla bazı uygulamalar çalışmayacaktır. Olayları kaybetmemek için, NTLM denetim araçlarını test etmeden önce bir denetim olayı toplama çözümü kurmalısınız; yerleşik Windows Event Collector, Event Subscriptions veya bir üçüncü taraf çözümünü kullanabilirsiniz. Ayrıca, önce sunucularda NTLM'yi izlemeye başlamanızı tavsiye ederim. Sunucunun NTLM protokolünü kullandığı anlaşıldıktan sonra ayrıntılı analiz için istemcileri bağlayabilirsiniz. Hangi uygulamaların NTLM kullandığını anladıktan sonra, bir NTLM engelleme stratejisi geliştirebilirsiniz. Bu strateji, yeniden yazılamayan veya yeniden yapılandırılamayan ve her zaman NTLM gerektiren eski uygulamalar için bir dışlama stratejisi içerebilir.

Ne yazık ki, bahsedilen NTLM ayarları eski Windows sistemlerinde uygulanamaz. Ancak, bu sistemler NTLM sürüm kontrolüne izin verir. Örneğin, NTLM kimlik doğrulama protokolünün LM yığınını devre dışı bırakabilir (çünkü bu yığın doğal olarak zayıftır) veya NTLMv2'yi zorlayabilirsiniz. Bunu yapmak için, Bilgisayar Yapılandırması \ Windows Ayarları \ Güvenlik Ayarları \ Yerel İlkeler \ Güvenlik Seçenekleri GPO kapsayıcısında bulunan Ağ Güvenliği: LAN Yöneticisi Kimlik Doğrulama Düzeyi GPO ayarını kullanın (bkz. Şekil 2).

Kerberos şifreleme araçları

Kimlik doğrulama protokolleri tarafından kullanılan kriptografik protokoller, ikincisinin güvenliğini sağlamada önemli bir rol oynar. Daha önce de belirttiğim gibi, Kerberos bu alanda NTLM'den daha iyi puan alıyor. RC4 şifreleme algoritması ilk olarak Windows 2000'de Windows Kerberos protokolünde uygulandı ve hala Windows 7'nin yanı sıra Server 2008 sistemlerinde destekleniyor (daha doğrusu RC4_HMAC_MD5 sürümü destekleniyor). Server 2008, Windows Vista ve daha yeni sürümlerde Microsoft, Gelişmiş Şifreleme Standardı, AES ve Windows 7 desteği eklemiştir ve Server 2008 R2, kutudan çıktığı haliyle Kerberos AES şifreleme türlerini (AES128_HMAC_SHA1 ve AES256_HMAC_SHA1) destekler. AES, DES'ten daha yeni ve daha güçlü bir şifreleme algoritmasıdır. AD etki alanınızı Windows 2008 Etki Alanı İşlev Düzeyine (DFL) yükselttiğinizde etki alanı denetleyicilerindeki Kerberos mantığı AES şifrelemesine geçecektir.

Windows 7 ve Server 2008 R2'de, Kerberos kimlik doğrulaması için DES şifreleme türleri varsayılan olarak devre dışıdır. Eski uygulamalardan biri yalnızca DES şifrelemesini kullanacak şekilde kodlanmışsa veya bir hizmeti çalıştıran Windows hesabı (o hizmet hesabı) yalnızca DES şifrelemesini kullanacak şekilde yapılandırılmışsa, bu uyumluluk sorunlarına neden olabilir. İlgili hizmeti veya uygulamayı farklı bir şifreleme türünü (RC4 veya AES) destekleyecek şekilde yeniden yapılandıramazsanız veya DES desteğini geri yüklemezseniz bu hizmetler veya uygulamalar başarısız olur.

Yalnızca DES standardı kullanılarak şifrelenmiş uygulamalarınız veya hizmetleriniz olup olmadığını öğrenmek için, ilgili uygulama veya hizmet başladığında ağ izleyicisini başlatabilir ve Kerberos kimlik doğrulama başlıklarındaki Etype alanlarının içeriğini kontrol edebilirsiniz. AD kullanıcısının veya bilgisayar hesabının veya bilgisayar hesabının yalnızca DES şifreleme türlerini kullanacak şekilde yapılandırılıp yapılandırılmadığını belirlemek için, nesnenin Hesap özellikleri sekmesinde Bu hesap için Kerberos DES şifreleme türlerini kullan seçeneğinin seçili olduğunu doğrulamanız gerekir. Bu özelliklere AD Kullanıcıları ve Bilgisayarları MMC ek bileşeninden erişilebilir.

Yukarıdaki kontrolleri tamamlarsanız ve bu sorunu yaşadığınızı tespit ederseniz, Ağ güvenliği GPO ayarını kullanarak Windows 7 veya Server 2008 R2 çalıştıran bilgisayarlarda Kerberos kimlik doğrulaması için DES şifrelemesini etkinleştirebilirsiniz: Kerberos standardıyla uyumlu şifreleme türlerini yapılandırın; bu ayarlar Bilgisayar Yapılandırması, Windows Ayarları, Güvenlik Ayarları, Yerel İlkeler, Güvenlik Seçenekleri GPO kapsayıcısında bulunur.

Bu nedenle, iki Windows kimlik doğrulama protokolünden Kerberos tercih edilen protokoldür. Yöneticiler, kullanıcıların ve uygulamaların NTLM'yi değil Kerberos'u kullanması konusunda her zaman ısrar etmelidir. Windows 7 ve Server 2008 R2'deki NTLM kullanımına ilişkin yeni kısıtlamalar, bu hedefe ulaşmamız için mükemmel bir fırsat sunuyor.

Jean de Clercq ( [e-posta korumalı]) HP Güvenlik Ofisi'nin bir çalışanıdır. Microsoft ürünlerinde kimlik yönetimi ve güvenlik konusunda uzmanlaşmıştır

Windows Server 2008 R2 ve Windows 7'de Kimlik Doğrulama

Son zamanlarda bu sorunla karşılaştı: Firefox, Chrome, Opera geçmek istemiyorum NTLM yetkilendirmesi... geçen tek kişi oydu IE... Bu sorunun gözlendiğini söylemeyi unuttum Windows 7... Aşağıda bu sorunların nasıl giderileceği anlatılacaktır.

Opera: resmi olarak desteklemiyor NTLM-yetkilendirme, ancak ayarlarda bu seçeneği etkinleştirmenize veya devre dışı bırakmanıza izin veren bir öğe bulabilirsiniz. Bu nedenle, proxy sunucunuzun ayarlarında eklemeniz gerekir. temel yetkilendirme... devre dışı bırakmak için NTLM yetkilendirmesi(ve aslında bu tarayıcının bir proxy üzerinden çalışmasını sağlarız) aşağıdakileri yaparız:

1) tarayıcıya şunu yazın: config
2) NetWork bölümüne gidin ve NTLM'yi Etkinleştir parametresinin işaretini kaldırın
3) tarayıcıyı yeniden başlatın.

Doğru, bir nüans var (tabii ki, bir rahatsızlık): ilk başlangıçta, giriş şifresini (tamamen, yani etki alanı ile) girmeniz ve kutuyu işaretlemeniz gerekecek "Kaydetmek"... Şimdi, tarayıcının sonraki her açılışında, yetkilendirme plakası görünecek ve sadece düğmesine basmanız gerekecek. "TAMAM"... Rahatsız edici, ama ne yapabilirsiniz.

Not: bazen bazı işletim sistemlerinde, tam tersine, açmanız gerekiyordu NTLM yetkilendirmesi... Belki de tarayıcı sürümlerine ve işletim sistemine bağlıydı.

Firefox, Chrome: biraz şaman yapmanız gerekse de destekliyorlar. İnternette bulduğum birkaç seçeneği anlatacağım, size uygun olanı bulana kadar her şeyi denemeniz gerekebilir.

1) HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa kayıt defterine adında bir parametre eklemeniz gerekecek LmUyumlulukSeviyesi tip DWORD ve ona bir değer atayın 1 ... Bundan sonra bilgisayarı yeniden başlatmanız gerekecek (bana uygun seçenek buydu)

2) NS Firefox geçebilir ntlm yetkilendirme, adres çubuğunda about: config dosyasını açmanız ve parametreleri aşağıdaki gibi değiştirmeniz yeterli gibi görünüyor:

network.negotiate-auth.delegation-uris = http: //, https: //
network.negotiate-auth.trusted-uris = http: //, https: //

Ardından tarayıcıyı yeniden başlatın.

3) Politika düzenleyicisini açın ( gpedit.msc) Bilgisayar Yapılandırması -> Windows Yapılandırması -> Güvenlik Ayarları -> Yerel İlkeler -> Güvenlik Ayarları -> Ağ Güvenliği: LAN Yöneticisi kimlik doğrulama düzeyi ve parametreyi ayarlayın LM ve NTLM gönder - pazarlık yaparken NTLMv2 oturum güvenliğini kullanın.

Ardından politikayı kapatıp yeniden başlatıyoruz.

İngilizce sürümünüz varsa, şunu beğenin: makine politikası-> bilgisayar yapılandırması-> Windows ayarı-> yerel politikalar-> güvenlik seçeneği-> Ağ güvenliği: LAN Yöneticisi kimlik doğrulama düzeyi ve öğesini seçin. LM ve NTLM - Anlaştıysanız NTLMv2 oturumunu kullanın.

4) Başka bir seçenek aracılığıyla yapılandırmak squid_ldap:

auth_param temel program / usr / lib / squid3 / squid_ldap_auth -b "cn = kullanıcılar, dc = ofis, dc = ru" -f "sAMAccountName =% s" -h 192.168.0.74 -D "cn = yönetici, cn = kullanıcılar, dc = ofis, dc = ru "-w" secpass "
auth_param temel çocuk 5
auth_param temel bölge Benim inet Proxy'm
auth_param temel kimlik bilgileri 60 dakika

external_acl_type nt_groups% GİRİŞ / usr / lib / squid3 / squid_ldap_group -R -b "cn = kullanıcılar, dc = ofis, dc = ru" -f "(& (cn =% v) (memberOf = cn =% a, cn = kullanıcılar, dc = ofis, dc = ru)) "-D" cn = yönetici, cn = kullanıcılar, dc = ofis, dc = ru "-w" secpass "-h 192.168.0.74

acl tümü kaynak 0.0.0.0/0.0.0.0
acl group_inet harici nt_groups giriş

http_access group_inet'e izin verir
http_reply_access hepsine izin ver
icp_access hepsine izin ver
http_access hepsini reddet

Yine de deneyin 🙂

Araştırmacılar yıllardır konferanslarda Single Sign-on teknolojilerinin güvenli olmadığını konuşuyorlar. Microsoft uzun süredir her şey için böyle tek bir kimlik doğrulama sistemi kullanıyor ve bilgi güvenliği uzmanları 1997'de bunun pek iyi bir fikir olmadığını söylediler. Genel olarak çoklu oturum açmanın ve özel olarak KOBİ kaynaklarıyla çalışma durumundaki güvenlik açığı Rus araştırmacı ValdikSS tarafından bir kez daha gösterildi. Bir kurbanın Microsoft Hesabını tehlikeye atmanıza, Microsoft kullanıcılarının anonimliğini kaldırmanıza ve bir VPN hakkında veri bulmanıza olanak tanıyan bir yöntem tanımladı.

Aslında, bir saldırıyı başarılı bir şekilde uygulamak için, bir saldırganın yalnızca kendi SMB kaynağına (ağ kaynakları: dosyalar ve klasörler, yazıcılar, vb.) o. Saldırı, en son güncellemelere sahip Windows 10 dahil tüm modern işletim sistemlerinde çalışır. Ayrıca, NTLM kimlik doğrulaması ile ilgili bu sorunlar sadece 1997'de tartışılmakla kalmıyor, düzenli olarak hatırlanıyor. Bu nedenle, bu konu geçen yıl BlackHat konferansında gündeme getirildi (PDF). Ne yazık ki, sık sık bahsetmekten hiçbir şey değişmez.

"Habrahabr" kullanıcısı ValdikSS'de, bu "90'lardan kalma hata"nın bugün nasıl istismar edilebileceğinden bahsetti. Araştırmacı şunları yazıyor:

“Standart bir tarayıcıda (Internet Explorer, Edge) veya standart Windows API çağrıları aracılığıyla çalışan veya HTML işleme motoru olarak Internet Explorer'ı kullanan herhangi bir uygulamada (Outlook, Windows Gezgini) bir SMB kaynağına bağlantı açmaya çalıştığınız anda, SMB kaynağı, siz daha oturum açma ve parola iletişim kutusunu görmeden hesap ayrıntılarınızı hemen alır. Bir saldırgan için, örneğin, bir web sitesi sayfasındaki bir SMB sunucusundan bir resme bağlantı eklemek veya size sadece açmanız ve - bom! - hesap verileriniz bir saldırganın elinde."

Ev bilgisayarının hesap adı ve parola hash'inin sızdırılması bir felaket olarak görülmezken, kurumsal alan söz konusu olduğunda ise bambaşka bir konuşma başlıyor.

“Etki alanının adından hesabın hangi kuruluşa ait olduğunu anlamak genellikle kolaydır ve ardından şifre başarılı bir şekilde kaba kuvvet uygulanmışsa, İnternet'ten erişilebilen kurumsal kaynaklarda (posta, VPN) kimlik doğrulamayı deneyebilirsiniz. .

Ancak şifreyi tahmin etmek her zaman gerekli değildir. NTLM kimlik doğrulamasını kullanarak girebileceğiniz bazı kaynakları önceden biliyorsanız, istemci SMB sunucunuza bağlanır bağlanmaz gerçek zamanlı olarak, istemciden uzak sunucuya ve sunucudan istemciye proxy istekleri ve üzerinde başarılı bir şekilde kimlik doğrulaması yaptınız! ”diyor ValdikSS.

Durum, modern işletim sistemlerinde Microsoft'un tek bir Microsoft Hesabının kullanımını aktif olarak teşvik etmesi ve kelimenin tam anlamıyla kullanıcıyı bir hesap oluşturmaya zorlaması gerçeğiyle de ağırlaşıyor. Microsoft Hesabı kullanıcıları için bu tür saldırılar, yalnızca kuruluşlar için değil, bireyler için de iki kat tehlikeli olabilir. Gerçek şu ki, saldırganın SMB sunucusuna bir saldırı olması durumunda, aslında kurbanın Microsoft Hesabını tehlikeye atacak olan veriler aktarılacak ve birçok hizmet buna bağlı (Skype, Xbox, OneDrive, Office 360, MSN, Bing, Azure, vb. Ayrıca).

Araştırmacı ayrıca bazı durumlarda saldırının kurbanın VPN bağlantısının oturum açma ve parola karması hakkında veri çıkarmak için kullanılabileceğini de yazıyor.

Bunu yaparken ValdikSS, NTLM kimlik doğrulamasıyla ilgili sorunlardan yararlanmanın birkaç yolunu açıkladı. Çok bariz olan şeylere ek olarak, araştırmacı, kullanıcıların anonimliğini kaldırmak için deliğin kullanılmasını önerdi:

“Anonymization amacıyla yapılan sömürü daha ilginç. Kurban Internet Explorer kullanıyorsa veya Outlook durumunda mektubun içine tıkladığında hesap site sayfalarından gönderilecektir. Posta hizmetlerinin hemen hemen tüm web arayüzleri, bir mesajı görüntülerken dosya: // şemasıyla resimleri filtreler (dosya: // şema, \\ şemasının bir analogudur), ancak bunu güvenlik açığı olarak görmeyen Yandex değil (genel olarak doğrudur). Posta kullanarak anonimleştirme daha tehlikelidir çünkü yalnızca Windows hesabı olan IP adresine değil, aynı zamanda postaya da bir bağlantı verir.

Chrome'un file: // şeması da çalışır, ancak yalnızca adres çubuğundan. SMB görseli içeren herhangi bir şey yüklemek veya bağlantıya tıklamak başarısız olacaktır. Chrome, Internet Explorer'dan çok daha popüler olduğu için sosyal mühendisliğin uygulanması gerekecektir.

Kendi iyiliğiniz için hesapları çalabilirsiniz. Bazı VPN sağlayıcıları, hem oturum açma hem de VPN kimlik doğrulaması için aynı kullanıcı adlarını ve parolaları kullanır. Bir hesabın belirli bir hizmete üyeliği, kullanıcının gelen bağlantısının IP adresi ile belirlenebilir. Ve bir Microsoft Hesabınız varsa ve parolayı karmadan bulduysanız, tebrikler - OneDrive bulutundaki dosyalara, Outlook postasına, bir Microsoft hesabına bağlıysa Skype hesabına ve çok daha fazlasına erişiminiz var. "

Sonuç olarak, ValdikSS, örneğin aşağıdakiler dışında tüm adres aralıkları için TCP bağlantı noktası 445'e erişimi kısıtlayarak bu tür saldırılara karşı koruma sağlayabileceğinizi yazıyor:

• 192.168.0.0/16
• 169.254.0.0/16
• 172.16.0.0/12
• 10.0.0.0/8
• fd00 :: / 8
• fe80 :: / 10

Ayrıca makalenin yorumlarında, kullanıcılar aşağıdaki yöntemi önerdi:

Windows Kayıt Defteri Düzenleyicisi Sürüm 5.00

"RestrictReceivingNTLMTraffic" = dword: 00000002
"RestrictSendingNTLMTraffic" = dword: 00000002

Ayrıca araştırmacı, bu tür saldırılara karşı kendi sistemini kontrol etmesine izin veren özel bir sayfa oluşturdu.

ntlm kimlik doğrulamasını başarıyla yapılandırdım. Maalesef yapılandırma, yarı temel yetkilendirmeye izin verir. Örneğin, kaplumbağa svn1.8.4 (ayrıcalıklı lib ile), chrome veya IE web tarayıcılarını kullandığımda, hiçbir şey sormadan NTLM'den başarıyla çıkıyorlar. Günlük dosyasında kimliği doğrulanmış kullanıcılar görüyorum. Ne yazık ki, örneğin yapılandırılmamış FireFox veya Maxthon kullandığımda, bu tarayıcı benden kimlik bilgileri istiyor. Buna ihtiyacım yok çünkü bilgisayarsız bir bilgisayardan erişmeye çalıştığımda da aynı durum oluyor.

Windows sunucusunu etki alanı denetleyicisi olarak, windows7 / 8'i sistem istemcisi olarak, linux / debian'ı web sunucusu olarak kullanıyorum. Kerberos'u linux do windows AD'den, yerel NTLM kimlik doğrulaması için winbind'den ve apache 2.2 serisinden yapılandırdım. Apache tutkal kimlik doğrulaması için mod_auth_ntlm_winbind.so apache2 modülünü ve winbind iletişimini sürdürmek için config / ntlm bağlamında kullanıyorum. Bu doğru çalışıyor, apache için örnek:

ana www dizini için #defaults Seçenekler Dizinler FollowSymLinks MultiViews AllowOverride Yok #değiştirildi, herhangi bir ip erişimini engelle, gelecekte belirtilen ana bilgisayarlardan authless erişim ekle Sipariş reddet, hepsinden reddet izin ver #Winbind helper ile NTLM auth için #allow from IP / mask #ayarları AuthName "NTLM Authentication" NTLMAuthHelper üzerinde NTLMAuth "/ usr / bin / ntlm_auth --domain = MY.WINDOWS.DOMAIN --helper-protocol = squid-2.5-ntlmssp" NTLMBasicAuthoritative on AuthType NTLM üzerinde geçerli kullanıcı gerektirir # debeçünkü herhangi birini tatmin eder

Apache authtype değişkenini kullanarak yeniden yönlendirme yapabileceğimi ve ardından yeniden yazmanın üzerindeki yapılandırmaya ekleyebileceğimi umuyordum:

RewriteRule ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%(AUTH_TYPE)&REMOTE_USER=%(REMOTE_USER) üzerinde RewriteEngine

Ve cgi içeriği olarak örnek bir TestAuth.pl betiği:

#! / usr / bin / perl kullanımı katı; uyarıları kullanın; Verileri kullan :: Damper; #baskı sistemi değişkenlerini yazdırmanın kolay yolu "İçerik türü: metin / düz \ r \ n"; #respectint HTML protokolü yazdır "\ r \ n"; print "Çevre şunları içerir: \ r \ n"; "x \ r \ n" yazdır; Print Data :: Damper-> Dump ([\ @ ARGV, \% ENV],); #tüm komut dosyası argümanlarını ve işlem değişkenlerini yazdırır

Ne yazık ki, her durumda, Windows tabanlı auth ntlm kullanarak ve kimlik bilgilerini sorarak, her zaman AUTH_TYPE'nin her zaman NTLM olduğunu görüyorum. O zaman tarayıcının ne yaptığını bilmenin bir yolu yok. Bu durumda, etki alanındaki istemcilerden erişebilirim.

ntlm hepler strace sarmayı denedim. Maalesef, bir karınca FF isteği tarafından tetiklenen başarı/başarısızlık ve IE erişimini birleştiren dört yolla dökümümde önemli bir şey görmüyorum. Sanırım aynı durum, ntlm yardımcısı yerel samba sunucusuna kimlik doğrulaması yaptığında da oluyor, ancak bunu hiç test etmedim.

Şimdi birden çok auth, Basic ve NTLM türüyle bazı yapılandırmalar yapmaya çalışıyorum. Önce Temel yapmaya çalışıyorum ve her zaman başarısız olduğunda bunu filtreleyip bilgi sayfasına yönlendiriyorum. Ne yazık ki, şu anda NTLM karışımı ile başarı yok: (NTLM her zaman önce yapılır.

O zaman, kimlik bilgilerinin nasıl önleneceği hakkında bir fikri olan var mı? Davet edilen istemcilerden erişimi nasıl iptal edebilirim? İstemden veya istemci api penceresinden kimlik bilgileri nasıl tanınır?

0

2 yanıt

Şu anda bu sorunu NTLM'yi Kerberos kimlik doğrulamasına geçirerek çözdüm. Winbind'e hazır olanların tümü doğrudan kerberos altında çalışır çünkü daha önce kerberos'u AD sunucu iletişimi ile winbind için yapılandırdım. Kerberos açık kaynak olduğundan, geliştiriciler kullanıcının uç noktasında farklı alt kimlikler öngördü. apache2.2 kerberos modülünde çok kullanışlı bir bayrak:

KrbMethodKrbMethodK5Passwd üzerinde pazarlık yapın

İstediğim bu. Tarayıcı, "Kullanıcı kimlik bilgilerini açma" özniteliğine sahip bir krb çerçevesi alır, ardından istemci almaz. Ancak eğer öyleyse (bir tür uyumsuzluk?), Apache sunucu modülü bunu algılamalı ve kimlik doğrulamasını iptal etmelidir.

Microsoft'tan NTLM kullanıldığında, protokol hatalı olduğu için bu mümkün değildir. 201 web sitesi kodunun döndürülmesinden sonraki ilk NTLM çerçevesi, "kullanıcıdan kimlik bilgileri isteme" özniteliğini eklemenin bir yolu yoktur. Ardından, açılır pencere veya işletim sistemi oturum anahtarı işaretinden sonra bu çerçeveyi filtreleyebilirim. Bu tarayıcı, işletim sistemi oturum anahtarı mevcut olmadığında her zaman bir açılır pencere gösterir.

Sonunda, bu başka bir şans. Kullanıcının kimlik bilgilerini girmesi biraz zaman alır veya kimlik bilgileri tarayıcıda depolandığında kabul eder. Yetkilendirme çerçevesini tarayıcıya gönderme ile çerçeveyi istemciden oluşturma arasındaki süreyi sayabilirim. Zaman çok uzun olduğunda, iptal edebilirim. Ne yazık ki, bu meşgul bilgisayarlarda veya ağlarda yanlış yetkilendirmelere neden olabilir.

İleride her iki yöntemi de kullanacağım :) apach winbind auth modülü ile her şey yapılabilirse eğlenceli olur. Daha sonra tüm konfigürasyon, kerberos auth ile aynı şekilde apache altında kapsüllenebilir.

İlginç araştırmalarınız ve yardımlarınız için hepinize teşekkür ederim :)

NTLM kimlik doğrulamasının kullanılması, kimlik bilgisi içermeyen yetkilendirmeyi garanti etmez. Sunucunun tanıyabileceği geçerli Windows kimlik bilgileriniz varsa, parola istemi almazsınız.

Kullanıcının geçerli eksik NTLM kimlik bilgileri yoksa, bunları sağlaması istenir. Bu, "temel" kimlik doğrulamaya geri dönmenin bir yolu değildir.

Ne yazık ki, kullanıcının kimlik bilgilerini sağlayıp sağlamadığını veya sistemden geçip geçmediğini belirlemek mümkün değildir.

Belki de kullanıcılarınızın deneyimlemesini istediğiniz şey (yani dahili ve harici kullanıcılar için farklı siteler) hakkında yeni bir soru sorun ve birileri farklı bir şekilde yardımcı olabilir.