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

	— Никакая я не змея! — сказала Алиса. — Я просто... просто... — Ну, скажи, скажи, кто ты такая? — подхватила Горлица. — Сразу видно, хочешь что-то выдумать.
	Льюис Кэрролл. Приключения Алисы в Стране чудес (пер. Нины Демуровой)

Одной из главных задач, которые приходится решать при построении защищенной информационной системы, является создание надежной схемы аутентификации. В сетях на основе Windows аутентификация используется для подтверждения права пользователя работать от имени указанной им учетной записи и служит основой для большинства других защитных механизмов, таких как разграничение доступа, аудит и т. д.

Обычно имя пользователя и пароль, применяемые для аутентификации, вводятся на одном компьютере, а их подлинность проверяет другой. На начальном этапе развития сетей использовалась передача имени и пароля на удаленную систему в открытом виде, однако такой подход быстро был признан небезопасным, поскольку в IP-сетях существует множество способов, позволяющих злоумышленнику перехватить трафик и воспользоваться украденным паролем. В связи с этим разработчики операционных систем отказались от передачи пароля в открытом виде и предложили более защищенные алгоритмы. Например, в семействе Windows реализованы следующие алгоритмы аутентификации: Lan Manager, NT Lan Manager, NT Lan Manager version 2 и Kerberos version 5.

Вначале был LM

Протокол Lan Manager (LM), разработанный Microsoft совместно с IBM, даже в Windows NT был включен только для совместимости с устаревшей операционной системой Windows 95 и клиентами Lan Manager. Данный протокол реализует весьма слабую схему защиты пароля при пересылке по сети и при хранении в кэше системы. Существует множество программ, позволяющих за приемлемое время восстановить из хеша LM или перехваченных откликов исходный пароль. Наиболее известной из них является @stake LC 4 (предыдущее название L0phtCrack, http://www.atstake.com/research/lc/). Появилась даже система моментального взлома паролей NT — система с Web-интерфейсом, которая использует заранее рассчитанные таблицы соответствия значений хешей и паролей для практически моментального восстановления пароля из хеша LM (http://lasecpc13.epfl.ch/ntcrack, http://www.antsight.com/zsl/rainbowcrack/).

Несмотря на недостатки этого протокола, он зачастую используется в сетях с Active Directory. Многие администраторы мотивируют это необходимостью обеспечения «совместимости» с клиентами на основе Windows 9x или просто не уделяют должного внимания применению этого протокола в сети, что приводит к компрометации паролей пользователей и администраторов.

Процесс отказа от LM и перехода на более защищенные протоколы аутентификации в разнородной среде далеко не прост и, как правило, осуществляется в несколько этапов. На первом из них необходимо обновить все операционные системы до соответствующего уровня, т. е. установить на них модули поддержки протоколов NTLMv2. Для этого на операционные системы Windows 9x следует установить клиенты Active Directory Services (ADSC) (http://www.microsoft.com/windows2000/adclients). Операционная система Windows NT 4.0 поддерживает протокол NTLMv2 начиная с четвертого пакета обновлений (Service Pack 4). Но и на систему Windows NT 4.0, функционирующую в среде Active Directory, тоже желательно установить ADSC, поскольку его функции не ограничиваются только поддержкой NTLMv2. Получить более подробную информацию о клиенте ADSC и загрузить эту программу для Windows NT 4.0 можно с сервера Microsoft. Клиент для Windows 9x находится на компакт-диске с дистрибутивом Windows 2000 в папке Clients.

Развертывание клиента ADSC в корпоративной сети — задача, требующая большого количества времени и человеческих ресурсов. Чтобы ускорить процесс, целесообразно автоматизировать его. Для этого можно воспользоваться сценариями входа пользователей в систему, подобными сценарию, приведенному в листинге 1. Применение такого сценария требует создания в общей папке Netlogon контроллера домена (в данном случае используется машина с именем w2ksrv06) папки dsclients, в которой создаются папки w9x и nt4. В них копируются разархивированные дистрибутивы клиентов ADSC для Windows 9x и NT 4.0 соответственно. Чтобы облегчить работу пользователей, следует задействовать локализованную версию ADSC. Русская версия ADSC без проблем устанавливается и работает на англоязычной версии Windows NT 4.0.

Active Directory ds.bat
@echo off
if «%OS%»==»» GoTo :W9x
:NT
if not «%CommonProgramFiles%»==»» GoTo :Eof
if exist %windir%system32ActiveDS.dll GoTo
 :Eof
net use z: /delete /yes
net use z: w2ksrv06
etlogon /yes
z:
ifmember Administrators
if not errorlevel 1 (notepad.exe notadmin.txt
 & goTo :Eof)
notepad.exe z:dsinst.txt
regedit -s z:
t4.reg
cd dsclients
t4
setup /Q
GoTo :Eof
:W9X
if exist %windir%systemActiveDS.dll GoTo :Eof
net use z: w2ksrv06
etlogon /yes
regedit -s z:win98.reg
z:
cd dsclientsw9x
setup /Q
notepad.exe z:dsinst.txt
:Eof

Рассмотрим процесс работы сценария. При регистрации пользователя в системе сценарий по системным переменным определяет версию операционной системы. Поскольку в Windows 9x предопределенная переменная %OS% отсутствует, если значение этой переменной равно пустой строке, управление передается в секцию W9X. Далее сценарий определяет, установлен ли на данной машине клиент ADSC. Для этого выясняется, есть ли в системе файл %windir%systemActiveDS.dll. Если да, то сценарий завершает работу. В противном случае с буквой Z монтируется сетевой диск, содержащий файл для установки клиента, в реестр на основе данных файла win98.reg вносятся необходимые изменения, после чего запускается процесс установки клиента в фоновом режиме.

Желательно объяснить пользователям, что происходит с их системой (поскольку процесс установки ADSC занимает некоторое время и требует перезагрузки). Для этого в файле dsinst.txt, отображаемом в ходе процесса установки, необходимо описать выполняемые действия, попросить дождаться окончания процесса установки, а по его завершении перезагрузить систему. Полезно также предварить процесс установки рассылкой по электронной почте и согласовать возможные задержки с руководством предприятия.

В случае если переменная %OS% определена, выявляется наличие системной переменной %Common

ProgramFiles%. Данная переменная по умолчанию определена в операционных системах начиная с Windows 2000, поэтому в случае ее отсутствия управление передается процедуре установки клиента ADSC для операционной системы Windows NT 4.0.

Установка ADSC на Windows NT 4.0 должна выполняться в контексте безопасности пользователя, обладающего привилегиями администратора. Поэтому в случае если клиент не установлен, проверяется, является ли текущий пользователь членом группы Administrators (для локализированных версий NT необходимо добавить проверку на членство в группе «Администраторы»). Для этого используется утилита ifmember из состава Resource Kit, загрузить которую можно с сервера Microsoft (http://www.microsoft.com/windows2000/techinfo/ reskit/tools/new/ifmember-o.asp). В информации о загружаемом файле отобразится его размер, равный 1,16 Mбайт, однако это ошибка сервера и реальный объем равен 115 Кбайт. После загрузки утилиты ее исполняемый файл необходимо скопировать в папку Netlogon контроллера домена.

Если пользователь не имеет прав администратора, на экран выводится текст из файла notadmin.txt, содержащего предупреждение о необходимости обратиться в службу технической поддержки для установки важного системного компонента. Сотруднику службы технической поддержки достаточно будет зарегистрироваться в системе с правами администратора и дождаться завершения процесса установки, что занимает около минуты, или временно повысить привилегии пользователя до уровня администратора. Во втором случае в сценарий необходимо добавить процедуру удаления учетной записи пользователя из группы администраторов, например при помощи команды:

net localgroup Administrators %username% /delete

Кроме установки программных компонентов, для отключения LM необходимо реализовать поддержку NTLMv2, что достигается путем модификации параметров системного реестра, содержащихся в файлах win98.reg и nt.reg (см. листинг 2).

(win98. reg) 
REGEDIT4
[HKEY_LOCAL_MACHINESystemCurrentControlSet
ControlLSA]
«LMCompatibility»=dword:00000003
(nt.reg)
REGEDIT4
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSet
ControlLsa]
«LMCompatibilityLevel»=dword:00000003
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSet
ControlLsaMSV1_0]
«NtlmMinServerSec»=dword:00080000
«NtlmMinClientSec «=dword:00080000

В Windows 98 используемый протокол аутентификации определяется значением параметра HKEY_LOCAL_MACHINESystemCurrentControlSet ControlLSALMCompatibility, а в Windows NT 4.0 HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlLsaLMCompatibilityLevel. Кроме того, в NT 4.0 есть возможность настроить минимальный уровень совместимости для протокола NTLM. Подробнее об этих параметрах и их значениях рассказано в статьях базы знаний Microsoft под номерами Q147706, Q239869.

Отключение LM в Windows 2000

Для отключения поддержки LM в Windows 2000 удобно использовать групповые политики. Для этого параметру Computer Configuration — Windows Settings — Security Settings — Local Policies — Security Options — LAN Manager Authentication Level необходимо присвоить значение не ниже трех (Send NTLMv2 Response Only). После применения этой политики компьютеры перестанут использовать для аутентификации протокол LM.

После того как на всех компьютерах сети будут проделаны необходимые действия, можно отключить поддержку протокола LM на контроллерах домена. Для этого в групповой политике для OU Domain Controllers параметру LAN Manager Authentication Level присваивается значение не ниже четырех (Send NTLMv2 response only efuse LM). Следует понимать, что после выбора данного значения клиенты, не настроенные на поддержку NTLM, не смогут проходить аутентификацию в домене и, соответственно, описанный выше сценарий развертывания ADSC и настройки NTLM работать не будет. Для того чтобы сохранить возможность автоматизированной настройки клиентов, можно выделить один компьютер, поддерживающий LM, и скопировать в одну из его общих папок сценарий ds.bat и сопутствующие файлы. Тогда после установки операционной системы Windows 98/NT 4.0 достаточно будет запустить сценарий с сервера, после чего начинать работу в домене.

Отключение поддержки 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.