Świetne pytanie.
Po pierwsze - większość „testerów penetracyjnych” uważam za dzieciaków skryptowych. Moje uprzedzenia mogą być niesprawiedliwe lub dokładne, ale zamieszczam niniejsze oświadczenie, aby w przypadku wykrycia jakiegokolwiek cynizmu w moim tonie wiedzieć, skąd on pochodzi. Nie twierdzę, że nie ma wykwalifikowanych pentesterów, ale taka jest moja ogólna ogólność.
(Niebieski zespół na całe życie!)
Moje pytanie: 1) Czy istnieje sposób, aby Active Directory rejestrował nieudane żądania nazwy użytkownika w centralnej lokalizacji, abyśmy mogli zauważyć w nich skok?
Nie podałeś wystarczających informacji, aby ktokolwiek mógł udzielić dokładnej i pewnej odpowiedzi na to pytanie. Powiedziałeś, że twoja aplikacja zawiera lukę, która pozwoliła atakującym wyliczyć konta użytkowników. Staram się zrozumieć, w jaki sposób czujesz, że potrzeby AD wykonać rejestrowanie dla swojej aplikacji.
Najwyraźniej awarie pojawiały się tylko w lokalnym dzienniku zdarzeń serwera, na którym aplikacja została zainstalowana.
Najwyraźniej awarie pojawiły się w dzienniku zdarzeń na serwerze? Lub niepowodzenia nie pojawiają się w dzienniku zdarzeń na serwerze? Jeśli tak, to co dokładnie powiedziały te wydarzenia? Kto je zalogował? Twoje zgłoszenie? Lub Windows? Dowiedz się, a być może uda mi się dodać dodatkowe wyjaśnienie do mojej odpowiedzi.
Zamierzam wyjść tutaj na prostotę w oparciu o twoje przypuszczenie, że te zdarzenia powinny być jakoś zarejestrowane przez Active Directory ... co jeśli twoi pentesterzy tak naprawdę nie wykorzystują wady aplikacji, ale zamiast tego używają bardzo dobrze znaną wadą samego protokołu Kerberos do wyliczania nazw użytkowników? Sam Kerberos zawiera coś, co uważam za wadę projektową, w której atakujący może podejmować tysiące prób „wstępnego uwierzytelnienia” (tj. Atak brutalnej siły), a KDC zareaguje inaczej w zależności od tego, czy konto użytkownika istnieje, czy nie. Nie jest to zachowanie specyficzne dla Active Directory, ale ma również zastosowanie do MIT Kerberos, Heimdal itp. KDC odpowieKDC_ERR_PREAUTH_REQUIREDjeśli podana została poprawna nazwa użytkownika bez danych przed autoryzacją, nawet bez próby autentycznego uwierzytelnienia. W ten sposób możesz wyliczyć nazwy użytkowników z KDC. Ponieważ jednak osoba atakująca (lub narzędzie, z którego korzysta osoba atakująca, taka jak KrbGuess - ponieważ pentesterzy są najlepsi, gdy korzystają z narzędzi innych osób), nie musi kontynuować pełnej próby uwierzytelnienia, nic nie jest rejestrowane, ponieważ nie podjęto próbę autentycznego uwierzytelnienia!
Teraz przejdź do następnego pytania:
2) Jeśli nie, jaki jest najlepszy sposób monitorowania i aktywnego wykrywania tego rodzaju ataków w przyszłości (Mam nadzieję, że nie będzie musiał kupować zbyt dużo nowego sprzętu).
Kilka rzeczy.
Po pierwsze, istnieją płatne produkty klasy korporacyjnej, które zostały zaprojektowane do wykrywania tego rodzaju ataków (między innymi). Wielu dostawców oferuje takie produkty, a rekomendacje produktów są nie na temat błędu serwera, ale wystarczy powiedzieć, że nie ma ich tam. Wiele z tych produktów wymaga, aby skonfigurować dublowanie portów między kontrolerami domeny a tymi „modułami zbierającymi dane”, tak aby widziały i analizowały dosłownie każdy pakiet wchodzący lub wychodzący z kontrolerów domeny.
(Przepraszam, to trochę pasuje do twojej klauzuli „bez kupowania zbyt wielu nowych rzeczy”).
Kolejną rzeczą, która może ci pomóc, jest wpis rejestru:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
LogLevel = 1
Udokumentowane tutaj .
Jeśli włączysz ten wpis rejestru, powinieneś zostać zalany zdarzeniami w dzienniku zdarzeń zabezpieczeń dotyczącym błędów Kerberos, które informują, że wymagane jest wstępne uwierzytelnianie Kerberos. Przykład takiego zdarzenia:
A Kerberos Error Message was received:
on logon session DOMAIN\serviceaccount
Client Time:
Server Time: 12:44:21.0000 10/9/2012 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN
Server Name: krbtgt/DOMAIN
Target Name: krbtgt/DOMAIN@DOMAIN
Error Text:
File: e
Line: 9fe
Error Data is in record data.
Ale to może ci pomóc, jeśli nie określa, skąd dokładnie pochodzi tsunami żądań Kerberos. To prowadzi nas z powrotem do produktów do wykrywania włamań dla przedsiębiorstw, o których wspomniałem wcześniej.
I nie zapomnij o przekazywaniu zdarzeń systemu Windows, które może sprawić, że Twoje serwery będą przekazywać zdarzenia do scentralizowanej lokalizacji, które będą analizowane za pomocą dowolnego narzędzia, które masz do dyspozycji.
Cała ta odpowiedź była do tej pory oparta na protokole Kerberos, czego nie mogę nawet przyjąć za pewnik, ponieważ podałeś tak mało szczegółów w swoim poście. Niemniej mam nadzieję, że to trochę pomoże.