Обзор учетных записей

Учетная запись — объект, хранящийся в локальной базе безопасности или в базе Active Directory, с помощью которого проводится аутентификация пользователя. Главные компоненты учетной записи — имя пользователя, его пароль и уникальный идентификатор безопасности (Security Identifier. SID).
Пароль в локальной базе или в AD хранится в двойном виде — в виде LM-хэша и в виде NTLM-хэша.

LM-хэш используется для аутентификации пользователей с использованием протокола LM. NTLM-хэш используется для аутентификации с использованием протоколов NTLM, NTLM v2 и Kerberos.
LM-хэш. Несмотря на название, это значение не является хэшем. LM-хэш состоит из двух 8-байтных независимых половин. Для вычисления LM-хэша пароль пользователя преобразуется в верхний регистр и дополняется до 14 символов нулевыми байтами. Каждая 8-байтная половина LM-хэша образуется путем шифрования известной 8-байтной константы по алгоритму DES с 56-битным ключом, который представляет собой 7 байт пароля пользователя. В том случае если длина пароля пользователя — 7 символов или меньше, вторая половина LM-хэша представляет собой известную константу.
NTLM-хэш представляет собой реальный М04-хэш пароля пользователя, преобразованного в Unicode. Хэшируется только пароль (дополнение пароля до определенной длины не производится).

Уязвимости учетных записей
Основными уязвимостями учетных записей являются: инвентаризация, то есть удаленное получение списка учетных записей на данном компьютере, подбор паролей для известных учетных записей и извлечение LM-и NTLM-хэшей с их последующей расшифровкой.

• Выполнение инвентаризации позволяет злоумышленнику получить список учетных записей (имен пользователей) для последующей атаки на них. В зависимости от версии ОС и ее настроек даже анонимный пользователь мог получить список локальных или доменных учетных записей.
• Существует большое количество утилит, позволяющих подобрать пароль пользователя либо по словарю, либо прямым перебором всех возможных символьных вариантов (brute-force attack), зная его имя входа (logon name).
• Злоумышленник, обладая административными правами, может извлечь LM- и NTLM-хэши, а затем запустить программу их расшифровки. Поскольку для получения LM-хэша используется слабый алгоритм, взлом LM-хэша не занимает много времени.

Защита учетных записей

Защита от инвентаризации
Для блокирования анонимной инвентаризации в Windows ХР и Windows Server 2003 применяются две настройки групповой политики (раздел Security Options): Network Access: Allow Anonymous SID/Name Translation и Network Access: Do Not Allow Anonymous Enumeration of SAM Accounts. Для повышения безопасности обе этих настройки должны иметь значение Enabled.

Важно заметить, что настройка Network Access: Do Not Allow Anonymous Enumeration of SAM Accounts
не применяется к контроллерам домена, так как контроллеры не имеют локальной базы учетных записей. Для разрешения анонимного доступа к учетным записям используется опция Permissions compatible with pre-Windows 2000 servers, задаваемая при повышении компьютера до контроллера домена. Выбор этой опции приводит к тому, что в группу Pre-Windows 2000 Compatible Access включаются системные группы Everyone и Anonymous Logon. Исключение всех групп из группы Pre-Windows 2000 Compatible Access блокирует анонимный доступ к базе Active Directory.

Защита от подбора паролей
Эффективной защитой против подбора паролей является использование сложных, не словарных паролей, а также блокировки учетных записей при превышении количества неправильно введенных паролей. Для задания этих настроек можно применить групповую политику (разделы Password Pulicies и Account Pulicies). Важно отметить, что для того, чтобы эти настройки вступили в силу, необходимо привязать GPO на уровне домена.

Защита от извлечения хэшей из SAM/AD
Хранение в базе LM-хэша может требоваться для поддержки pre-Windows 2000 клиентов, но представляет собой серьезную уязвимость. Поэтому в Windows ХР и в Windows Server 2003 существует настройка групповой политики Network security: Do not store LAN Manager hash value on next password change (раздел Security Options). После включения этой опции и смены пароля LM-хэш перестает храниться в локальной базе безопасности или в базе Active Directory. На хранение NLTM-хэша эта опция не влияет.
Если злоумышленник имеет физический доступ к компьютеру он может скопировать разделы реестра, содержащие пароли, на другой компьютер, а в дальнейшем расшифровать их. Также возможна загрузка с альтернативного носителя и последующая смена пароля в реестре на тот, который нужен злоумышленнику. Для защиты от таких атак компанией Microsoft было введено дополнительное шифрование хэшей паролей системным ключом. По умолчанию этот ключ также хранится в реестре, что делает атаки возможными. Для управления местоположением системного ключа используется утилита 8У8КЕУГДля блокирования атак следует выбрать вариант дополнительного шифрования ключа с помощью пароля, вводимого при загрузке компьютера или хранимого на дискете. Подробнее о SYSKEY см. «The system key utility» в Windows Server 2003 Help.

Организационные меры
Дополнительно к техническим мерам, рекомендуется также принять следующие организационные меры:

• минимизировать членство в группах с повышенными правами — Administrators, Server Operators, Account Operators, Domain Admins, Enterprise Admins;
• при запуске сервисов под пользовательской учетной записью по возможности не назначать этой записи административные права;
• не использовать административную учетную запись для  ежедневной работы, вместо этого использовать функцию Run As для выполнения административных задач;
• не использовать одинаковый пароль для регистрации в локальной сети и для доступа к сайтам или электронной почте.

Обзор аутентификации LAN

Аутентификация — это процесс проверки подлинности пользователя или компьютера. Конечным результатом процесса аутентификации в сетях Microsoft является формирование токена (token) для пользователя или компьютера. Токен — это структура, содержащая S1D пользователя/компьютера, S1D"ы всех групп, в которые входит пользователь, а также права пользователя (например, такие как право на локальную регистрацию в системе или право на изменение времени). Просмотреть свой токен в ОС Windows Server 2003 можно с помощью утилиты команды whoami.

Поддержка протоколов аутентификации
В сетях Microsoft поддерживаются следующие протоколы аутентификации — LAN Manager (LM), NT LAN Manager (NTLM), NTLM v2 и Kerberos. Поддержка этих протоколов в конкретных версиях Windows приведена в таблице 4.1.

Протоколы LM, NTLM и NTLM v2

Протокол LM является слабым и не обеспечивает адекватной защиты. В этом протоколе для аутентификации используется уязвимый LM-хэш. Этот протокол уязвим как к атакам по словарю (dictionary attack), так и к атакам прямого перебора (brute-force attack).

Протокол NTLM улучшает безопасность за счет использования более стойкого NTLM-хэша. При этом протокол аутентификации становится менее уязвимым к атакам прямого перебора, но по-прежнему уязвим к атакам по словарю.
Механизмы аутентификации LM и NTLM идентичны. Отличия проявляются только в использовании разных вариантов хранимого пароля. Для аутентификации по протоколу LM используется LM-хэш. Для аутентификации по протоколу NTLM используется NTLM-хэш.
При использовании любого из этих двух протоколов клиент сначала генерирует аутентификационную строку S2i (длина строки - 21 байт).

• Для протокола LM:                 S21 = LM_HASH + Zeros (5)       (LMJ1ASH дополняется 5 пулевыми бантами)
• Для протокола NTLM:   S21= NTLMHASH + Zeros (5) (NTLM_HASH дополняется 5 нулевыми байтами)

Далее требуется ввести функцию Е (key, data): шифрование 8-байтного блока данных data с помощью 7-байтного ключа key (алгоритм DES, длина ключа 56 бит). Сам алгоритм аутентификации выглядит следующим образом:

• Сервер посылает клиенту 8-байтный вызов (challenge) N
• Клиент посылает серверу 24-байтный ответ (response) Rn
  Rn = Е ((first 7 bytes of S21), N) + E ((second 7 bytes of S21), N) + E ((third 7 bytes of S21), N)
• Сервер вычисляет Rn, используя посланный вызов и хранящийся в SAM/AD LMHASH или
  NTLM_HASH (в зависимости от протокола). Если Rn, вычисленный сервером совпадает с Rn,
  предоставленным клиентом, аутентификация считается успешной.

Протокол NTLM v2 также использует NTLM-хэш, но его алгоритм изменен, что еще более улучшает безопасность. NTLM v2 является двусторонним протоколом аутентификации (аутентифицирует как клиента, так и сервер). Тем не менее он также остается уязвимым к атакам по словарю.

Протокол Kerberos
Протокол Kerberos является надежным, проверенным и стандартным протоколом аутентификации. В настоящее время используется пятая версия этого протокола (Kerberos v5). Поддержка протокола Kerberos включена во многие операционные системы — Windows 2000/2003, Sun Sularis, Linux, FreeBSD и другие. Kerberos является двусторонним протоколом аутентификации (аутентифицирует как клиента, так и сервер), его описание приведено в RFC 1510 и 1964.
Основными компонентами системы Kerberos являются:

• Key Distribution Center (KDC); в сетях Microsoft эту роль выполняет контроллер домена;
• Ticket-granting ticket (TGT);
• Service ticket (ST).

KDC является посредником между клиентом и сервером. При первоначальной аутентификации после проверки имени и пароля, клиент получает специальный билет (ticket), дающий возможность обращаться к службе KDC за сервисными билетами. Этот билет носит название ticket-granting ticket (TGT). В дальнейшем, когда клиенту нужно получить билет на доступ к серверу, клиент обращается к KDC, предъявляя свой TGT. Поскольку предъявление корректного TGT говорит о том, что клиент уже прошел аутентификацию, служба KDC выдает клиенту сервисный билет на доступ к серверу. При обращении к серверу, клиент предъявляет ему полученный сервисный билет. Таким образом, при использовании Kerberos клиент хранит у себя один TGT и один или несколько сервисных билетов.
К сожалению, в реализации Kerberos для Windows (как и в некоторых других реализациях) за счет того, что используется механизм пре-аутентификации, становится возможным перехватить пре-аутентификатор и взломать пароль с помощью атаки по словарю или прямым перебором. Данная уязвимость Kerberos не является новой (о ней упоминалось еще в 1993 г.) или специфичной для Windows. Данной уязвимости не подвержен механизм регистрации по протоколу Kerberos с использованием смарт-карт.
Поскольку протокол Kerberos является стандартным, есть возможность настроить взаимодействие между различными реализациями протокола Kerberos. Например, можно настроить UNIX-станцию на регистрацию в Active Directory. Для подстройки Kerberos для работы с другими его реализациями служат настройки Use DES encryption types и Do not require Kerberos preauthentication в свойствах учетной записи пользователя в Active Directory.

Многофакторная аутентификация с использованием смарт-карт

Многофакторная аутентификация (multi-factor authentication) подразумевает" применение более чем одного метода аутентификации. Пользователь должен использовать две или более категории аутентификации, такие как:

• нечто, известное пользователю (например, пароль или пин-код);
• нечто, принадлежащее пользователю (например, смарт-карта);
• нечто, являющееся свойством пользователя (например, снимок сетчатки, отпечаток пальца).

Описанные ранее протоколы аутентификации (LM, NTLM, NTLM v2 и Kerberos с парольной аутентификацией) являются примерами однофакторной аутентификации. Применение многофакторной аутентификации позволяет резко повысить безопасность процесса проверки подлинности пользователей.
В Windows 2000/ХР/2003 поддерживается механизм двухфакторной аутентификации с использованием протокола Kerberos совместно со смарт-картами (smart card) и. Смарт-карта — устройство, размером с кредитную карточку, которое содержит цифровой сертификат пользователя и его секретный ключ. Информация на смарт-карте защищена персональным идентификационным кодом (пин-кодом). Для аутентификации пользователь вставляет смарт-карту в специальное считывающее устройство (smart card reader) и вводит пин-код. Извлеченный со смарт-карты сертификат пользователя, снабженный дополнительной цифровой подписью на основе собственного же секретного ключа, передается на контроллер домена. Далее контроллером производится сопоставление сертификата и учетной записи пользователя.
Смарт-карты могут быть использованы в следующих сценариях:

• аутентификация в домене с использованием протокола Kerberos;
• аутентификация удаленного доступа (dial-up, VPN) с использованием протокола EAP-TLS;
• шифрование EFS;
• шифрование и цифровая подпись электронной почты.

Несмотря на привлекательность такого метода аутентификации, у него есть и недостатки. Основной недостаток — дополнительные финансовые затраты на оснащение компьютеров считывателями смарт-карт или закупку USB-токенов и затраты на подготовку и внедрение инфраструктуры открытых ключей (РК1).

Защита аутентификации LAN

Технические меры

Основную угрозу для протоколов однофакторной аутентификации представляет практика использования коротких (<5 символов) и словарных паролей. Хотя в Windows 2000/2003 нет механизма, проверяющего пароли на предмет их нахождения в словаре, настройка групповой политики Passwords must meet complexity requirements (Computer configuration - Windows Settings - Security Settings - Account Pulicies -Password Pulicy), позволяет контролировать сложность паролей. Если эта настройка включена, то пароль должен содержать символы как минимум трех из четырех классов (четыре класса это: символы верхнего регистра, символы нижнего регистра, цифры и специальные символы).
Также рекомендуется задать для всех паролей минимальную длину не менее 6 символов (настройка Minimum Password Length в разделе Password Pulicy групповой политики).

Внимание! Чтобы настройки раздела Account Pulicies вступили в силу в домене, они должны быть заданы в GPO, привязанном к домену (например, в GPO «Default Domain Pulicy»).
Дополнительные технические меры:

• Обновить все компьютеры Windows 98 и Windows NT 4.0 для поддержки наиболее безопасного метода аутентификации NTLM v2. Для этого следует установить Directory Services Client на Windows 98 и SP6 на Windows NT. Кроме установки DS Client для компьютеров Windows 98 необходимо вручную модифицировать реестр, как описано в КВ239869 (http://support.microsoft.com/kb/239869).
• Выключить поддержку ненужных протоколов аутентификации. Лучше всего это сделать через групповую политику (Computer configuration - Windows Settings - Security Settings - Local Pulicies -Security options — Network security: LAN Manager authentication level). Во избежание проблем несовместимости перед настройкой этой опции рекомендуется ознакомиться со статьей КВ823659 Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments (http://support.microsoft.com/kb/823659).
• Использовать регистрацию в системе с применением смарт-карт, в тех случаях, когда защита процесса аутентификации должны быть максимальной.
• Использовать ограниченные часы входа и ограничение на станции входа в свойствах доменной учетной записи пользователя (Logon Hours, Workstation Restrictions).

Организационные меры

Хотя этот аспект часто недооценивается системными администраторами, следует уделить внимание обучению пользователей и разъяснению политики безопасности организации. В противном случае при введении жестких мер по обеспечению безопасности, пользователи могут начать нарушать установленные правила, задавая, например, такие пароли как P@sswOrd (формально соответствующие требованиям сложности).

Доверительные отношения в Active Directory

Доверительные отношения в Active Directory — это механизм, позволяющий клиентам из одного домена получать доступ к ресурсам из другого домена. В Active Directory существует несколько видов доверительных отношений.

типы довирительных отношений:

При установлении доверительных отношений существует риск того, что администратор доверенного домена (т.е домена которому доверяют) сможет повысить свои привилегии в доверяющем домене (т.е домене, который доверяет). Для этой цели злоумышленник может изменить атрибут SIDHistory у учетных записей в своем домене. Для защиты от подмены идентификаторов безопасности (SID) и повышения привилегий у всех исходящих внешних (external) и межлесных (cross-forest) доверительных отношений автоматически включен режим фильтрации идентификаторов безопасности (SID Filtering). В большинстве случаев не требуется менять этот режим, исключение составляет лишь сценарий миграции — перенос пользователей из домена в домен с сохранением доступа к ресурсам. В этом случае выключить редим фильтрации можно из доверяющего домена, выполнив команду netdom trust /d: /EnableSIDHistory no.
По умолчанию все пользователи из доверенного домена входят в системную группу Authenticated users в доверяющем домене. Это дает им возможность доступа к ресурсам, на которые назначены разрешения этой группе. В случае, когда пользователям из доверенного домена нужен доступ только к одному-двум серверам с общими ресурсами, можно повысить безопасность доверительных отношений, включив для исходящего доверительного отношения режим избирательной аутентификации (selective authentication). В этом режиме пользователи из доверенного домена, которым требуется доступ к ресурсу, должны иметь в доверяющем домене разрешение Allowed to authenticate, установленное на компьютерную учетную запись, где располагается ресурс.