АУТЕНТИФИКАЦИЯ в разных версиях Windows

Отключение поддержки LM на контроллерах домена и серверах не означает, что клиенты не будут посылать ответы LM, перехват которых злоумышленником может перевести к компрометации пароля. Например, в случае если злоумышленник работает за машиной Windows 98, он может беспрепятственно установить значение параметра реестра LMCompatibility равным 0, после чего под тем или иным предлогом заставить администратора провести процедуру аутентификации с его рабочей станции. В результате администратор не сумеет войти в систему, однако LM-хеш пароля (точнее, LM-ответ, сгенерированный на основе хеша) будет передан по сети, и злоумышленник сможет его перехватить и восстановить пароль. Об этом следует помнить и не входить в сеть под учетной записью администратора с рабочих станций пользователей.

Кроме того, Windows 9x кэширует пароли пользователей в файлах PWL, имеющих слабую защиту, что тоже может привести к компрометации пароля. В корпоративных системах эту функцию желательно отключить, для чего, согласно рекомендациям статьи Q137826, посредством системной политики или сценария регистрации в сети установить значение параметра реестра HKEY_LOCAL_MACHINESoftware MicrosoftWindowsCurrentVersionPoliciesNetwork DisablePwdCaching равным 1.

И последним этапом является отключение функции создания и хранения хешей LM на котроллерах домена (см. статью Q299656). Для этого на контроллерах домена необходимо установить пакет обновления Windows 2000 SP2 и выше, создать параметр реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlLsaNoLMHash и перезагрузить компьютер. Хеши LM будут удаляться из системы по мере смены пользователями своих паролей. Чтобы автоматизировать настройку этого параметра на вновь устанавливаемых контроллерах и серверах домена, можно воспользоваться расширениями набора параметров безопасности для объектов групповой политики (см. «Все и сразу», Windows & .NET Magazine, № 1 за 2003 год) или рекомендациями статьи базы знаний Microsoft 214752. Для этого в файл %windir%infSceregvl.inf необходимо добавить следующие параметры:

— в секцию [Register Registry Values]

MACHINESystemCurrentControlSetControlLsa NoLMHash,4,%NoLMHash%,0

— в секцию [Strings]

NoLMHash = «Network security: Do not store LAN Manager hash value on next password change»

Затем требуется зарегистрировать сделанные изменения командой regsvr32 scecli.dll и настроить значение этого параметра в соответствующих объектах групповой политики.

После выполнения описанных процедур клиенты и серверы сети будут осуществлять аутентификацию на основе протокола NTLMv2. Вторая версия протокола NTLMv2, поддерживаемая Windows 9x+ADSC/NT SP4/2000/XP/2003, реализует довольно стойкую к взлому схему сетевой аутентификации и на сегодня рекомендована для использования в процессе аутентификации клиентов 9x/NT. Восстановление алфавитно-цифрового пароля, состоящего из восьми символов, в случае его перехвата на системе, производящей 4 млн. переборов в секунду (16-процессорный кластер на основе Athlon 1,4 ГГц), занимает примерно 21 месяц (http://www.blackhat.com/presentations/win-usa-02/urity-winsec02.ppt).

Затем необходимо настроить аутентификацию системных служб. Работа служб от имени привилегированной учетной LocalSystem существенно увеличивает возможности злоумышленника в случае компрометации этой записи, поэтому рекомендуется запускать службы от имени учетной записи пользователя. Кроме того, некоторые задачи, к примеру шифрование баз данных сервера SQL, невозможно выполнять, не применяя для запуска службы пользовательскую учетную запись. Обычно учетные записи, используемые для запуска служб, имеют высокие привилегии либо на конкретном узле, где работает служба, либо во всем домене. Но, несмотря на это, администраторы зачастую назначают учетным записям пароли, которые не меняются годами и за это время могут быть перехвачены и восстановлены злоумышленниками.

Рекомендуется периодически менять пароли для учетных записей служб, что удобно делать при помощи сценария (см. листинг 3)

Сценарий сначала меняет пароль доменной (или локальной) учетной записи, а затем пароль в параметрах запуска служб. Информация о службах берется из тестового файла (по умолчанию — services.txt). В файле указывается учетная запись, а также службы, запущенные от ее имени. Если таких учетных записей несколько, то информация о них начинается с новой строки. Ниже приведен пример файла конфигурации, меняющего пароли для учетных записей sqlsrv1 и sqlsrv2 в домене Dom, а также пароли для связанных с ними служб SQL Server на компьютерах SqlSrv, Cluster0 и Cluster1.

Domsqlsrv1
SqlSrvMSSQLSERVER
Domsqlsrv2
Cluster0MSSQLSERVER
Cluster1MSSQLSERVER

Еще одна проблема, которую приходится решать администратору при создании надежной системы аутентификации, связана с аутентификацией пользователя в сетевых приложениях. Многие приложения (SQL Server, Internet Information Server, Exchange Server) могут задействовать собственные, иногда более уязвимые механизмы аутентификации. К примеру, пользователь, проходящий аутентификацию на SQL Server, в случае применения метода SQL Server Authentication, пересылает по сети пароль в закодированном виде (перевод в UNICODE и операция XOR со строкой 0xA5). Сервер IIS при использовании метода аутентификации Basic требует от клиентского приложения передавать пароль в открытом виде, просто преобразовав его в кодировку usa-ascii при помощи раскладки BASE64. Очень часто администраторы, для того чтобы защитить свою сеть от распространения сетевых «червей» через анонимный сервер SMTP, включают на нем аутентификацию BASIC, что приводит к появлению в сети незашифрованных паролей. Это существенно облегчает злоумышленнику задачу, поскольку, перехватив закодированный пароль администратора при обращении, например, к серверу IIS или SMTP, он может моментально восстановить его и использовать для доступа к сети.

Можно применять и более защищенные методы сетевой аутентификации в серверных приложениях (NTLM), но лучше всего использовать шифрование данных на уровне сессий при помощи протокола SSL.

Кроме того, применение NTLM может вызвать проблемы в различных приложениях. Например, если в Web-приложении используется связка IIS + SQL и эти службы расположены на различных компьютерах, а сервер IIS требует задействовать аутентификацию NTLM, для соединения с сервером SQL придется использовать SQL Server Authentication или анонимный доступ, а также применять дополнительные приложения для имперсонации (см. Q248187). Все эти методы далеко не безопасны, а также сложны в реализации и эксплуатации.

Ставка на Kerberos

Для решения данной проблемы используется механизм делегирования аутентификации протокола Kerberos. Общая его идея заключается в том, что, если пользователь успешно аутентифицировался в одной из сетевых служб (к примеру, на сервере IIS), эта служба может работать в сети в контексте безопасности данного пользователя. Применение такого метода возможно, если пользователь прошел аутентификацию на сервере IIS с протоколом Kerberos (поддерживается IIS 5.0 и выше и Internet Explorer 5.0 и выше) и компьютер, на котором установлен IIS, является доверенным для делегирования. Подробное описание процедуры настройки делегированной аутентификации можно найти в статье базы знаний Micorosft Q319723. Причем, даже если IIS не настроен на поддержку метода аутентификации NTLM (NTAuthenticationProviders = Negotiate), в случае сбоя аутентификации по протоколу Kerberos (если, например, клиент обратился к серверу через IP-адрес, а не посредством FQDN) Internet Explorer будет использовать NTLMv2. Кроме того, в статье Q215383 не совсем верно описано применение сценария adsutil.vbs. Значение переменной метaбазы необходимо указывать без кавычек:

cscript adsutil.vbs set w3svc/NTAuthenticationProviders Negotiate,NTLM

В Windows Server 2003 появилась возможность выборочного делегирования и смены протокола аутентификации. При использовании выборочного делегирования появляется возможность указать, к каким службам сервер может обращаться от имени пользователя, что уменьшает возможный ущерб при компрометации сервера. Смена протокола аутентификации позволяет серверу работать от имени пользователя, даже если тот задействовал для первоначальной аутентификации протокол, отличный от Kerberos. Подробнее о расширениях протокола Kerberos в Windows Server 2003 рассказано в статье Жана де Клерка «Windows .NET Server и Kerberos» (Windows & .NET Magazine, 2003, №2).

Схема аутентификации, используемая в протоколе Kerberos v 5, реализованном в Windows 2000/XP/2003, защищена от восстановления пароля лучше, чем протоколы семейства Lan Manager, однако не является абсолютно неуязвимой. Она также подвержена атакам, направленным на взлом пароля после перехвата сессии аутентификации. Существует ряд утилит, собирающих запросы AS-билетов, в которых содержится зашифрованная ключом пользователя метка времени, для дальнейшего восстановления пароля посредством атаки по словарю или полного перебора. Однако, как уже говорилось, Kerberos более устойчив к подобным атакам. Например, для восстановления пароля, состоящего из восьми алфавитно-цифровых символов (a-z, A-Z, 0-9), понадобится непрерывная работа 100 компьютеров, эквивалентных Pentium IV на 1,5 ГГц в течение 247 дней. Но для восстановления пароля длиной шесть символов одному компьютеру Pentium IV на 1,5 ГГц понадобится 6,4 суток (http://www.brd.ie/papers/w2kkrb/feasibility_of_w2k_ kerberos_attack.htm). Таким образом, стойкость механизмов аутентификации целиком зависит от надежности используемых паролей.

Меняем отношение к паролю

Существует пять подмножеств символов, используемых в паролях: A-Z, a-z, 0-9, ~-+ (спецсимволы) и ALT-символы. ALT-символы вводятся путем нажатия кнопки ALT и набора на цифровой клавиатуре номера кода. Подробнее об ALT-символах и их применении можно узнать из Windows 2000 Security Hardening Guide (http://www.microsoft.com/technet/security/prodtech/ Windows/Win2kHG/03OSInstl.asp).

При создании собственных паролей следует учитывать два основных условия:

• пароль должен быть относительно прост для запоминания;
• пароль должен быть сложен для вскрытия.

Первое условие должно уменьшить вероятности потери пароля, в то время как сложность пароля снижает вероятность его компрометации. Рекомендуется использовать пароли длиной не менее восьми символов, содержащих символы как минимум трех из описанных выше пяти подмножеств. Желательно менять пароли не реже чем раз в три месяца.

В Active Directory присутствует ряд настроек, позволяющих регламентировать парольную политику предприятия. Изменяя значения параметров, содержащихся в разделе Computer Configuration — Windows Settings — Security Settings — Account Policies — Password Policy, можно устанавливать минимальную длину пароля, регламент его смены, продолжительность хранения истории паролей, а также включать процедуру проверки сложности пользовательского пароля. При необходимости можно создать свой модуль проверки сложности пользовательских паролей. Структура подобных модулей описана в статье Александра Эпштейна «Фильтры для пароля» (Windows & .NET Magazine/RE №3, 2003), и в статье базы знаний Microsoft Q151082.

Перед внесением изменений в политику паролей нужно создать соответствующий раздел в политике информационной безопасности предприятия. Пользователи сети должны быть ознакомлены с соответствующими пунктами, пройти инструктаж и подписать данный документ. Дополнительно к техническим параметрам паролей в политику безопасности рекомендуется внести следующие пункты:

• пользователь несет личную ответственность за секретность своего пароля;
• пользователям запрещается записывать свои пароли на любом носителе информации (бумага, жесткий диск и т. д.);
• пользователям запрещается передавать свой пароль в открытом виде через средства коммуникаций;
• пользователям запрещается называть свой пароль по телефону, при личной встрече или другим способом. В случае необходимости входа в систему представителей службы технической поддержки пароль вводится самим пользователем.

Кроме описанных настроек, рекомендуется периодически проводить аудит надежности аутентификации в сети, причем не ограничиваться пассивным мониторингом сложности паролей, а прослушивать трафик на зеркальном порту коммутатора, подключенного к серверному сегменту при помощи специализированной «хакерской» программы, к примеру Cain & Abel (http://www.oxid.it/). Гарантирую, что за короткое время вы узнаете о стойкости аутентификации в своей сети много интересного.

Можно ли обойтись без пароля

Сложный пароль трудно запомнить и неудобно набирать. Поэтому зачастую использование сложных паролей приводит к тому, что они, несмотря на административные запреты, начинают появляться в самых неожиданных местах — под клавиатурой, на мониторе, на корпусе компьютера.

Значительно более надежными являются методы обеспечения безопасности, основанные на том, чем мы обладаем физически. Один из примеров — использование интеллектуальных пластиковых карт (Smart Card). Но, как показывает практика, применение подобных устройств не только не решает всех проблем, связанных с аутентификацией, но и порождает новые.

Сергей Гордейчик — инструктор учебного центра, MCSE. С ним можно связаться по адресу: Gordey@infosec.ru.