Человек, как известно, существо ленивое.
А тем более, когда касается вопроса выбора устойчивого пароля.
Думаю, каждый из администраторов когда-либо сталкивался с проблемой использования легких и стандартных паролей. Такое явление часто встречается среди верхних эшелонов руководства компании. Да-да, именно среди тех, кто имеет доступ к секретной или коммерческой информации и крайне нежелательно было бы устранять последствия утечки/взлома пароля и дальнейших инцидентов.
В моей практике был случай, когда в домене Active Directory с включенной парольной политикой люди бухгалтеры самостоятельно дошли до идеи того, что пароль вида «Pas$w0rd1234» отлично прокатывает под требования политики. Следствием стало повсеместной использование данного пароля везде и всюду. Отличался он иногда лишь набором цифр.
Очень захотелось иметь возможность не только включать парольную политику и определять набор символов, а еще и фильтровать по словарю. Чтобы исключить возможность использования подобного рода паролей.
Компания Microsoft любезно сообщает нам по ссылке, что всякий, кто умеет держать правильно в руках компилятор, IDE и умеет правильно произносить C++, способен сам себе библиотеку нужную скомпилировать и использовать по своему разумению. Ваш покорный слуга на такое не способен, вот и пришлось искать готовое решение.
После длительного часа поиска взору были явлены два варианта решения проблемы. Я, конечно, говорю об OpenSource решении. Ведь платных вариантов — от и до.
Вариант №1.
Коммитов нет уже как года 2. Родной инсталлятор работает через раз, приходится подправлять руками. Создает свою отдельную службу. При обновлении файла паролей DLL-ка автоматически не подхватывает измененное содержимое, нужно останавливать службу, выжидать таймаут, редактировать файл, запускать службу.
Не айс!
Вариант №2.
Проект активен, жив и даже не надо пинать хладное тело.
Установка фильтра заключается в копировании двух файлов и создании нескольких записей реестра. Файл паролей не в локе, то есть — доступен для редактирования и, согласно задумке автора проекта, он просто вычитывается раз в минуту. Также при помощи дополнительных записей реестра можно произвести дополнительную настройку как самого фильтра, так и даже нюансов парольной политики.
Итак.
Дано: домен Active Directory test.local
тестовая рабочая станция Windows 8.1 (для условия задачи — несущественно)
фильтр паролей PassFiltEx
- Скачиваем по ссылке последний релиз
- Копируем PassFiltEx.dll в C:WindowsSystem32 (или %SystemRoot%System32).
Копируем PassFiltExBlacklist.txt в C:WindowsSystem32 (или %SystemRoot%System32). При необходимости дополняем его своими шаблонами
- Редактируем ветку реестра: HKLMSYSTEMCurrentControlSetControlLsa => Notification Packages
Добавляем PassFiltEx в конец списка. (Расширение указывать не нужно.) Полный список пакетов используемых для проверки будет выглядеть вот так «rassfm scecli PassFiltEx«.
- Перезагружаем контроллер домена.
- Повторяем вышеуказанную процедуру для всех контроллеров домена.
Также можно добавить следующие записи реестра, что дает большую гибкость в использовании данного фильтра:
Раздел: HKLMSOFTWAREPassFiltEx — создается автоматически.
- HKLMSOFTWAREPassFiltExBlacklistFileName, REG_SZ, Default: PassFiltExBlacklist.txt
BlacklistFileName — позволяет указать кастомный путь к файлу с шаблонами паролей. Если у этой записи реестра пустое значение или она не существует, то используется путь по умолчанию, а именно — %SystemRoot%System32. Можно указать даже сетевой путь, НО нужно помнить, что у файла шаблонов должны быть выставлены четкие разрешения на чтение, запись, удаление, изменение.
- HKLMSOFTWAREPassFiltExTokenPercentageOfPassword, REG_DWORD, Default: 60
TokenPercentageOfPassword — позволяет указать процентное вхождение маски в новый пароль. По умолчанию значение равно 60%. Например, если указано процентное вхождение 60 и в файле шаблонов есть строка starwars, тогда пароль Starwars1! будет отклонен, в то время, как пароль starwars1!DarthVader88 будет принят, поскольку процентное вхождение строки в пароль менее 60%
- HKLMSOFTWAREPassFiltExRequireCharClasses, REG_DWORD, Default: 0
RequireCharClasses — позволяет расширить требования к паролям по сравнению со стандартными требованиями сложности паролей ActiveDirectory. Встроенные требования сложности требуют 3 из 5 возможных различных видов символов: Верхний регистр, Нижний регистр, Цифра, Специальный и Unicode. При помощи данной записи реестра можно установить свои требования к сложности паролей. Значение, которое можно указать, — это набор битов, каждый из которых — соответствующая степень двойки.
То есть — 1 = нижний регистр, 2 = верхний регистр, 4 = цифра, 8 = спец символ, and 16 = символ Unicode.
Таким образом, при значении 7 требования будут “Верхний регистр AND нижний регистра AND цифра ”, а при значении 31 — “Верхний регистр AND нижний регистр AND цифра AND спец символ AND символ Unicode”.
Можно даже комбинировать — 19 = “Верхний регистр AND нижний регистр AND символ Unicode”. -
Ряд правил при составлении файла шаблонов:
- Шаблоны регистронезависимы. Следовательно, запись в файле starwars и StarWarS будет определяться как одинаковое значение.
- Файл блеклиста перечитывается каждые 60 секунд, таким образом можно спокойно его редактировать, через минуту новые данные уже будут использоваться фильтром.
- На данный момент нет поддержки Unicode для проверки по шаблону. То есть, использовать Unicode символы в паролях можно, но фильтр не сработает. Это не есть критично, потому что не видел я пользователей, которые пароли в юникоде используют.
- Желательно не допускать пустых строк в файле шаблонов. В дебаге потом видно ошибку, когда происходит подгрузка данных из файла. Фильтр работает, но зачем лишние эксепшены?
Для дебага в архиве идут батники, позволяющие создать лог и потом его разобрать при помощи, например,
Данный фильтр паролей использует Event Tracing for Windows.
ETW провайдер для этого фильтра паролей — 07d83223-7594-4852-babc-784803fdf6c5. Так, например, можно настроить трассировку событий после следующей перезгрузки:
logman create trace autosessionPassFiltEx -o %SystemRoot%DebugPassFiltEx.etl -p "{07d83223-7594-4852-babc-784803fdf6c5}" 0xFFFFFFFF -ets
Трассировка будет запущена после следующей перезагрузки системы. Чтобы остановить:
logman stop PassFiltEx -ets && logman delete autosessionPassFiltEx -ets
Все эти команды указаны в скриптах StartTracingAtBoot.cmd и StopTracingAtBoot.cmd.
Для разовой проверки работы фильтра можно использовать StartTracing.cmd и StopTracing.cmd.
Для того, чтобы удобно читать выхлоп дебага данного фильтра в Microsoft Message Analyzer рекомендуется использовать следующие настройки:
При остановке лога и разбора в Microsoft Message Analyzer выглядит все примерно вот таким образом:
Здесь видно, что была попытка установить пароль для пользователя — об этом нам говорит волшебное слово SET в дебаге. И пароль был отклонен ввиду наличия его в файле шаблонов и более чем 30% соответствии в вводимом тексте.
При удачной попытке смены пароля видим следующее:
Есть некоторое неудобство для конечного пользователя. При попытке смены пароля, который попадает в список файла шаблонов, сообщение на экране не отличается умом и сообразительностью от стандартного сообщение при непрохождении парольной политики.
Поэтому будьте готовы к звонкам и крикам: «Я ввела пароль как надо, а оно не работает.»
Итог.
Данная библиотека позволяет запретить использование простых или стандартных паролей в домене Active Directory. Скажем «Нет!» паролям вида: «P@ssw0rd»,«Qwerty123», «ADm1n098».
Да, безусловно, пользователи полюбят вас еще больше за такую заботу об их безопасности и необходимости придумывать зубодробительные пароли. И, возможно, количество звонков и просьб помочь с паролем у Вас добавится. Но за безопасность приходится платить.
Ссылки на использованные ресурсы:
Статья на Microsoft относительно кастомной библиотеки фильтра паролей:
PassFiltEx:
Ссылка на релиз:
Списки паролей:
DanielMiessler lists:
Wordlist from weakpass.com:
Wordlist from berzerk0 repo:
Microsoft Message Analyzer:
Источник: habr.com