Człowiek, jak wiadomo, jest istotą leniwą.
A zwłaszcza, gdy chodzi o wybór mocnego hasła.
Myślę, że każdy administrator chociaż raz spotkał się z problemem stosowania łatwych i standardowych haseł. Tego rodzaju zjawisko jest często dostrzegane w wysokich szczeblach zarządzania w firmie. Tak, tak, właśnie wśród tych, którzy mają dostęp do tajnych lub komercyjnych informacji i bardzo niepożądane byłoby znoszenie konsekwencji wycieku/łamania hasła oraz dalszych incydentów.
W mojej praktyce był przypadek, kiedy w domenie Active Directory z włączoną polityką haseł, księgowi sami doszli do pomysłu, że hasło typu „Pas$w0rd1234” doskonale spełnia wymagania polityki. Skutkiem było powszechne stosowanie tego hasła wszędzie i zawsze. Różniło się ono czasami tylko zestawem cyfr.
Bardzo chciałem mieć możliwość nie tylko włączenia polityki haseł i określenia zestawu znaków, ale także filtrowania według słownika. Aby wykluczyć możliwość stosowania tego rodzaju haseł.
Firma Microsoft uprzejmie informuje nas pod tym linkiem, że każdy, kto potrafi poprawnie posługiwać się kompilatorem, IDE i umie poprawnie wypowiadać C++, jest w stanie samodzielnie skompilować i używać potrzebnej biblioteki według własnego uznania. Wasz pokorny sługa do tego się nie nadaje, więc musiałem szukać gotowego rozwiązania.
Po długiej godzinie poszukiwań moim oczom ukazały się dwa rozwiązania problemu. Mówię oczywiście o rozwiązaniu OpenSource. Ponieważ płatnych opcji jest mnóstwo.
Opcja nr 1.
Nie było commitów już od około 2 lat. Własny instalator działa raz na jakiś czas, trzeba go ręcznie poprawiać. Tworzy swoją oddzielną usługę. Przy aktualizacji pliku haseł DLL nie ściąga automatycznie zmienionej zawartości, trzeba zatrzymać usługę, czekać na timeout, edytować plik, uruchomić usługę.
Nie za bardzo!
Opcja nr 2.
Projekt jest aktywny, żyje i nawet nie trzeba go szturchać.
Instalacja filtra polega na skopiowaniu dwóch plików oraz utworzeniu kilku wpisów w rejestrze. Plik haseł nie jest zablokowany, to znaczy — dostępny do edycji i, zgodnie z zamysłem autora projektu, jest po prostu odczytywany co minutę. Dodatkowo, za pomocą dodatkowych wpisów w rejestrze można dokonać dodatkowej konfiguracji zarówno samego filtra, jak i niuansów polityki haseł.
Więc.
Dane: domena Active Directory test.local
testowa stacja robocza Windows 8.1 (w kontekście zadania — nieistotne)
filtr haseł PassFiltEx
- Pobieramy najnowszą wersję z linku
- Kopiujemy PassFiltEx.dll do C:WindowsSystem32 (lub %SystemRoot%System32).
Kopiujemy PassFiltExBlacklist.txt do C:WindowsSystem32 (lub %SystemRoot%System32). W razie potrzeby uzupełniamy go własnymi szablonami
- Edytujemy gałąź rejestru: HKLMSYSTEMCurrentControlSetControlLsa => Notification Packages
Dodajemy PassFiltEx na koniec listy. (Rozszerzenie podawać nie trzeba.) Pełna lista pakietów używanych do weryfikacji będzie wyglądać następująco: „rassfm scecli PassFiltEx«.
- Restartujemy kontroler domeny.
- Powtarzamy powyższą procedurę dla wszystkich kontrolerów domeny.
Można także dodać następujące wpisy rejestru, co daje większą elastyczność w używaniu tego filtra:
Sekcja: HKLMSOFTWAREPassFiltEx — tworzona automatycznie.
- HKLMSOFTWAREPassFiltExBlacklistFileName, REG_SZ, Domyślnie: PassFiltExBlacklist.txt
BlacklistFileName — pozwala określić niestandardową ścieżkę do pliku z szablonami haseł. Jeśli ten wpis w rejestrze ma pustą wartość lub nie istnieje, to używana jest ścieżka domyślna, czyli — %SystemRoot%System32. Można nawet podać ścieżkę sieciową, ALE należy pamiętać, że plik szablonów musi mieć wyraźne uprawnienia do odczytu, zapisu, usuwania, zmienia.
- HKLMSOFTWAREPassFiltExTokenPercentageOfPassword, REG_DWORD, Domyślnie: 60
TokenPercentageOfPassword — pozwala określić procentowe wystąpienie maski w nowym haśle. Domyślna wartość wynosi 60%. Na przykład, jeśli ustawione jest procentowe wystąpienie 60 i w pliku szablonów znajduje się ciąg starwars, wtedy hasło Starwars1! zostanie odrzucone, podczas gdy hasło starwars1!DarthVader88 zostanie zaakceptowane, ponieważ procentowe wystąpienie ciągu w haśle jest poniżej 60%.
- HKLMSOFTWAREPassFiltExRequireCharClasses, REG_DWORD, Domyślnie: 0
RequireCharClasses — pozwala na rozszerzenie wymagań dotyczących haseł w porównaniu do standardowych wymagań dotyczących złożoności haseł Active Directory. Wbudowane wymagania dotyczące złożoności wymagają 3 z 5 możliwych rodzajów znaków: wielkie litery, małe litery, cyfry, znaki specjalne i Unicode. Dzięki temu wpisowi rejestru można ustawić własne wymagania dotyczące złożoności haseł. Wartością, którą można podać, jest zestaw bitów, z których każdy odpowiada odpowiedniej potędze liczby 2.
To znaczy — 1 = małe litery, 2 = wielkie litery, 4 = cyfra, 8 = znak specjalny, a 16 = znak Unicode.
W ten sposób, przy wartości 7 wymagania będą „Wielkie litery AND małe litery AND cyfra”, a przy wartości 31 — „Wielkie litery AND małe litery AND cyfra AND znak specjalny AND znak Unicode”.
Można nawet łączyć — 19 = „Wielkie litery AND małe litery AND znak Unicode”. 
Kilka zasad dotyczących tworzenia pliku szablonów:
- Szablony są niestrunowe. Dlatego zapis w pliku starwars i StarWarS będzie traktowany jako ta sama wartość.
- Plik czarnej listy jest odczytywany co 60 sekund, więc można go swobodnie edytować, a po minucie nowe dane będą już używane przez filtr.
- Na chwilę obecną nie ma wsparcia dla Unicode przy sprawdzaniu zgodności ze wzorem. To znaczy, że można używać znaków Unicode w hasłach, ale filtr nie zadziała. Nie jest to krytyczne, ponieważ nie widziałem użytkowników, którzy korzystają z haseł w Unicode.
- Należy unikać pustych linii w plikach szablonów. W debugowaniu pojawia się wtedy błąd, gdy dane są ładowane z pliku. Filtr działa, ale po co generować zbędne wyjątki?
W celach debugowania w archiwum znajdują się skrypty, które pozwalają na utworzenie logu, a następnie jego analizę za pomocą, na przykład,
Ten filtr haseł korzysta z Event Tracing for Windows.
Dostawca ETW dla tego filtra haseł — 07d83223-7594-4852-babc-784803fdf6c5. Można na przykład skonfigurować śledzenie zdarzeń po następnym uruchomieniu:
logman create trace autosessionPassFiltEx -o %SystemRootbugPassFiltEx.etl -p "{07d83223-7594-4852-babc-784803fdf6c5}" 0xFFFFFFFF -ets
Śledzenie zostanie uruchomione po następnym uruchomieniu systemu. Aby zatrzymać:
logman stop PassFiltEx -ets && logman delete autosessionPassFiltEx -ets
Wszystkie te polecenia są zawarte w skryptach StartTracingAtBoot.cmd i StopTracingAtBoot.cmd.
Do jednorazowego sprawdzenia działania filtra można użyć StartTracing.cmd i StopTracing.cmd.
Aby wygodnie czytać wyjście debugowania tego filtra w Microsoft Message Analyzer , zaleca się zastosowanie następujących ustawień:
Po zatrzymaniu logowania i analizy w Microsoft Message Analyzer wszystko wygląda mniej więcej tak:
Widać, że była próba ustawienia hasła dla użytkownika - mówi nam o tym magiczne słowo SET w debugowaniu. Hasło zostało odrzucone z powodu jego obecności w pliku szablonów i zgodności wprowadzanego tekstu w ponad 30%.
W przypadku udanej próby zmiany hasła widzimy następujące:
Jest pewne niedogodność dla końcowego użytkownika. Przy próbie zmiany hasła, które znajduje się na liście pliku szablonów, komunikat na ekranie nie różni się zbyt wiele od standardowego komunikatu dotyczącego niespełnienia polityki haseł.
Dlatego bądźcie gotowi na telefony i krzyki: „Wprowadziłem hasło jak należy, a to nie działa.”
Podsumowanie.
Ta biblioteka pozwala zabronić używania prostych lub standardowych haseł w domenie Active Directory. Powiedzmy „Nie!” hasłom takim jak: „P@ssw0rd”, „Qwerty123”, „ADm1n098”.
Tak, z pewnością użytkownicy pokochają cię jeszcze bardziej za taką dbałość o ich bezpieczeństwo i konieczność wymyślania skomplikowanych haseł. I być może liczba telefonów i próśb o pomoc z hasłem wzrośnie. Ale za bezpieczeństwo trzeba płacić.
Linki do użytych zasobów:
Artykuł Microsoft dotyczący niestandardowej biblioteki filtrów haseł:
PassFiltEx:
Link.
Listy haseł:
DanielMiessler lists:
Wordlist z weakpass.com:
Wordlist z repozytorium berzerk0:
Microsoft Message Analyzer:
Źródło: habr.com
