Какой протокол windows наиболее защищен от подбора

Протокол расширенной проверки подлинности (EAP) для доступа к сети

Расширяемый протокол проверки подлинности (EAP) — это платформа проверки подлинности, которая позволяет использовать различные методы проверки подлинности для безопасных технологий сетевого доступа. Примеры этих технологий включают беспроводной доступ с помощью IEEE 802.1X, проводного доступа с помощью IEEE 802.1X и подключения типа «точка — точка» (PPP), таких как виртуальная частная сеть (VPN). EAP не является определенным методом проверки подлинности, таким как MS-CHAP версии 2, а платформой, которая позволяет поставщикам сети разрабатывать и устанавливать новые методы проверки подлинности, известные как методы EAP, на клиенте доступа и сервере проверки подлинности. Платформа EAP изначально определена RFC 3748 и расширена различными другими rfcs и стандартами.

Методы аутентификации

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

EAP-Transport Layer Security (EAP-TLS): стандартный метод EAP, использующий TLS с сертификатами для взаимной проверки подлинности. Отображается как смарт-карта или другой сертификат (EAP-TLS) в Windows. EAP-TLS можно развернуть как внутренний метод для другого метода EAP или как автономный метод EAP.

Методы EAP, использующие EAP-TLS, основанные на сертификатах, обычно предлагают самый высокий уровень безопасности. Например, EAP-TLS является единственным разрешенным методом EAP для режима WPA3-Enterprise 192-bit.

Протокол проверки подлинности EAP-Microsoft Challenge Handshake Protocol версии 2 (EAP-MSCHAP версии 2): определенный корпорацией Майкрософт метод EAP, инкапсулирующий протокол проверки подлинности MSCHAP версии 2, который использует имя пользователя и пароль для проверки подлинности. Отображается как безопасный пароль (EAP-MSCHAP версии 2) в Windows. EAP-MSCHAPv2 можно использовать в качестве автономного метода для VPN, но только в качестве внутреннего метода для проводной или беспроводной связи.

Подключения на основе MSCHAPv2 подвергаются аналогичным атакам, как для NTLMv1. Windows 11 Корпоративная, версия 22H2 (сборка 22621) включает Credential Guard в Защитнике Windows, который может вызвать проблемы с подключениями на основе MSCHAPv2.

Защищенный EAP (PEAP): определенный корпорацией Майкрософт метод EAP, инкапсулирующий EAP в туннеле TLS. Туннель TLS защищает внутренний метод EAP, который может быть незащищен в противном случае. Windows поддерживает EAP-TLS и EAP-MSCHAP версии 2 как внутренние методы.

EAP-Tunneled Transport Layer Security (EAP-TTLS): описано RFC 5281, инкапсулирует сеанс TLS, который выполняет взаимную проверку подлинности с помощью другого внутреннего механизма проверки подлинности. Этот внутренний метод может быть протоколом EAP, например EAP-MSCHAP версии 2, или протоколом, отличным от EAP, например протоколом проверки подлинности паролей (PAP). В Windows Server 2012 включение EAP-TTLS обеспечивает поддержку только на стороне клиента (в Windows 8). В настоящее время NPS не поддерживает EAP-TTLS. Поддержка клиентов позволяет взаимодействовать с часто развернутыми серверами RADIUS, поддерживающими EAP-TTLS.

Модуль удостоверений подписчика EAP (EAP-SIM), EAP-Authentication and Key Agreement (EAP-AKA) и EAP-AKA Prime (EAP-AKA): описано различными RFCS, обеспечивает проверку подлинности с помощью SIM-карта и реализуется при покупке клиентом плана беспроводной широкополосной связи с оператором мобильной сети. В рамках плана клиент обычно получает беспроводной профиль, предварительно настроенный для проверки подлинности SIM.

Туннель EAP (TEAP): описано RFC 7170, туннельный метод EAP, который устанавливает безопасный туннель TLS и выполняет другие методы EAP внутри этого туннеля. Поддерживает цепочку EAP — проверку подлинности компьютера и пользователя в одном сеансе проверки подлинности. В Windows Server 2022 включение TEAP обеспечивает поддержку только на стороне клиента — Windows 10 версии 2004 (сборка 19041). В настоящее время NPS не поддерживает TEAP. Поддержка клиентов позволяет взаимодействовать с часто развернутыми серверами RADIUS, поддерживающими TEAP. Windows поддерживает EAP-TLS и EAP-MSCHAP версии 2 как внутренние методы.

В следующей таблице перечислены некоторые распространенные методы EAP и номера назначенных методов IANA.

Настройка свойств EAP

Вы можете получить доступ к свойствам EAP для проводного и беспроводного доступа 802.1X следующим образом:

• Настройка политик проводной сети (IEEE 802.3) и расширений политик беспроводной сети (IEEE 802.11) в групповой политике.
  • Политики>конфигурации>компьютера Windows Параметры Security Параметры>
  • Wi-Fi CSP
  • WiredNetwork CSP

  Свойства EAP для подключений виртуальной частной сети (VPN) можно получить следующим образом:

  • Использование программного обеспечения для мобильных Управление устройствами (MDM), например Intune
    • Поставщик служб конфигурации VPNv2
    • Параметры профиля VPN

    Дополнительные сведения о настройке свойств EAP см. в разделе «Настройка профилей и параметров EAP» в Windows.

    Профили XML для EAP

    Профили, используемые для различных типов подключений, — это XML-файлы, содержащие параметры конфигурации для этого подключения. Каждый другой тип подключения следует определенной схеме:

    • Профили Wi-Fi (WLAN)
    • Профили проводной сети (Ethernet)
    • Профили VPN

    Однако при настройке использования EAP каждая схема профиля имеет дочерний элемент EapHostConfig .

    • Wired/Wireless: EapHostConfig является дочерним элементом элемента EAPConfig . Безопасность MSM > (Проводная/беспроводной) >OneX> EAPConfig
    • VPN: EapHostConfig является дочерним элементом конфигурации Eap > проверки подлинности > NativeProfile >

    Этот синтаксис конфигурации определен в групповой политике : спецификация расширения беспроводного или проводного протокола.

    Различные графические интерфейсы конфигурации не всегда отображают все технически возможные варианты. Например, Windows Server 2019 и более ранних версий не могут настроить TEAP в пользовательском интерфейсе. Однако часто можно импортировать существующий XML-профиль, который ранее был настроен.

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

    Дополнительные сведения о настройке профилей XML можно найти в XML-профилях. Пример использования XML-профиля, содержащего параметры EAP, можно найти в разделе «Подготовка профиля Wi-Fi» через веб-сайт.

    Параметры безопасности

    В следующей таблице описаны настраиваемые параметры безопасности для профиля, использующего 802.1X. Эти параметры сопоставляют с OneX.

    Параметр	XML-элемент	Description
    Выберите метод проверки подлинности сети:	EAPConfig	Позволяет выбрать метод EAP, используемый для проверки подлинности. Просмотр параметров конфигурации метода проверки подлинности и параметров конфигурации сотовой проверки подлинности
    Свойства	Открывает диалоговое окно свойств выбранного метода EAP.
    Режим проверки подлинности	authMode	Указывает тип учетных данных, используемых для проверки подлинности. Поддерживаются следующие значения:

    1. Проверка подлинности пользователя или компьютера
    2. Проверка подлинности компьютера
    3. Проверка подлинности пользователей
    4. Проверка подлинности гостя

    Дополнительные параметры > безопасности IEEE 802.1X

    Если проверка применены расширенные параметры 802.1X, все перечисленные ниже параметры будут настроены. Если это не проверка, применяются параметры по умолчанию. В XML все элементы являются необязательными, при этом значения по умолчанию используются, если они отсутствуют.

    Параметр	XML-элемент	Description
    Max Eapol-Start Msgs	maxStart	Указывает максимальное количество сообщений EAPOL-Start, которые можно отправить на сервер authenticator (RADIUS), прежде чем запрашивающий (клиент Windows) предполагает, что отсутствует средство проверки подлинности, используемое 3 по умолчанию.
    Период начала (секунды)	startPeriod	Указывает период времени (в секундах), до того как сообщение EAPOL-Start будет отправлено для запуска процесса проверки подлинности 802.1X, по 5 умолчанию .
    Период хранения (секунды)	heldPeriod	Указывает период времени (в секундах) для ожидания после неудачной попытки проверки подлинности повторной проверки подлинности, используемой 1 по умолчанию.
    Период проверки подлинности (секунды)	authPeriod	Указывает период времени (в секундах) для ожидания ответа от сервера проверки подлинности (RADIUS-сервера), прежде чем предположить, что отсутствует средство проверки подлинности, по 18 умолчанию .
    Сообщение «Eapol-Start»	supplicantMode	Задает метод передачи, используемый для сообщений EAPOL-Start. Поддерживаются следующие значения:

    1. Не передавать ( inhibitTransmission )
    2. Передача ( includeLearning )
    3. Передача на IEEE 802.1X ( compliant )

    Дополнительные параметры > безопасности Единый вход

    Параметр	XML-элемент	Description
    Включение Единый вход для этой сети	singleSignOn	Указывает, включен ли единый вход для этой сети по умолчанию false . Не используйте singleSignOn в профиле, если сеть не требует его.
    Выполнение непосредственно перед пользователем

    Параметры конфигурации метода проверки подлинности

    Если сервер сетевого доступа настроен для того же типа метода проверки подлинности для туннелированного метода EAP (например, PEAP) и не туннелированного метода EAP (например, EAP-MSCHAP версии 2), существует потенциальная уязвимость безопасности. При развертывании туннелированного метода EAP и EAP (который не защищен), не используйте один и тот же тип проверки подлинности. Например, при развертывании PEAP-TLS не развертывайте протокол EAP-TLS. Это связано с тем, что если требуется защита туннеля, она не служит ни для каких целей, чтобы разрешить выполнение метода за пределами туннеля.

    В следующей таблице описываются настраиваемые параметры для каждого метода проверки подлинности.

    Параметр	XML-элемент	Description
    Использование моего интеллектуального карта	SmartCard CredentialsSource>	Указывает, что клиенты, выполняющие запросы проверки подлинности, должны представлять смарт-карта сертификат для сетевой проверки подлинности.
    Использование сертификата на этом компьютере	CredentialsSource>CertificateStore	Указывает, что проверка подлинности клиентов должна использовать сертификат, расположенный в хранилищах сертификатов текущего пользователя или локального компьютера.
    Использование простого выбора сертификата (рекомендуется)	SimpleCertSelection	Указывает, будет ли Windows автоматически выбирать сертификат для проверки подлинности без взаимодействия с пользователем (если это возможно) или если Windows отобразит раскрывающийся список для пользователя, чтобы выбрать сертификат.
    Расширенные	Открывает диалоговое окно «Настройка выбора сертификата».
    Параметры проверки сервера
    Использование другого имени пользователя для подключения	DifferentUsername	Указывает, следует ли использовать имя пользователя для проверки подлинности, отличное от имени пользователя в сертификате.

    Ниже перечислены параметры конфигурации для настройки выбора сертификата. Эти параметры определяют критерии, которые клиент использует для выбора соответствующего сертификата для проверки подлинности. Этот пользовательский интерфейс сопоставляется с TLSExtensions >FilteringInfo.

    Параметр	XML-элемент	Description
    Издатель сертификата	CAHashList Enabled=»true»	Указывает, включена ли фильтрация издателя сертификатов.

    1. Все корневые центры сертификации и промежуточные центры сертификации.
    2. Содержит только те издатели, для которых есть соответствующие действительные сертификаты, которые присутствуют на компьютере (например, сертификаты, которые не истекли или не отозваны).
    3. Окончательный список сертификатов, разрешенных для проверки подлинности, содержит только те сертификаты, которые были выданы любым из издателей, выбранных в этом списке.

    При нажатии кнопки «Добавить или изменить» в диалоговом окне «Выбор EKUs» откроется диалоговое окно «Добавить и изменить EKU«, которое предоставляет два варианта:
    1. Введите имя EKU . Предоставляет место для ввода имени пользовательского EKU.
    2. Введите идентификатор EKU . Предоставляет место для ввода идентификатора OID для EKU. Разрешены только числовые цифры, разделители и . разрешены. Разрешены дикие карта, в этом случае разрешены все дочерние OID в иерархии.

    Параметры PEAP в пользовательском интерфейсе сопоставлены с MsPeap Подключение ionPropertiesV1, который расширен msPeap Подключение ionPropertiesV2.

    Параметр	XML-элемент	Description
    Параметры проверки сервера
    Выбор метода проверки подлинности	Позволяет выбрать тип EAP, используемый с PEAP для проверки подлинности сети. Доступны два типа EAP: безопасный пароль (EAP-MSCHAP версии 2) и Smart карта или другой сертификат (EAP-TLS).
    Настройка	EAP-MSCHAP версии 2: UseWinLogonCredentials

    Если выбран безопасный пароль (EAP-MSCHAP версии 2), имя входа в систему Windows и пароль (и домен, если таковой) доступен, проверка box, который указывает, что текущее имя входа Windows на основе пользователя и пароль используются в качестве учетных данных для проверки подлинности сети.

    Параметры EAP-TTLS в пользовательском интерфейсе сопоставляются с EapTtls Подключение ionPropertiesV1.

    Параметр	XML-элемент	Description
    Включение конфиденциальности удостоверений	Этап1Identity> IdentityPrivacy> AnonymousIdentity	Указывает, что клиенты настроены таким образом, чтобы они не могли отправлять свое удостоверение, прежде чем клиент прошел проверку подлинности сервера RADIUS, а также предоставляет место для ввода значения анонимного удостоверения. Если вы выберете «Включить конфиденциальность удостоверения», а затем введите anonymous в качестве значения анонимного удостоверения, ответ удостоверения для пользователя с удостоверением alice@example anonymous@example . Если выбран параметр «Включить конфиденциальность удостоверений», но не указать значение анонимного удостоверения, ответ удостоверения для пользователя alice@example . @example
    Параметры проверки сервера
    Выберите метод, отличный от EAP для проверки подлинности	Этап2Authentication>

    1. Майкрософт: смарт-карта или другой сертификат (EAP-TLS)
    2. Майкрософт: защищенный пароль (EAP-MSCHAP версии 2)

    Параметры TEAP в пользовательском интерфейсе сопоставлены с EapTeap Подключение ionPropertiesV1. TEAP доступен начиная с Windows 10 версии 2004 (сборка 19041) и Windows Server 2022.

    Параметр	XML-элемент	Description
    Конфиденциальность удостоверений	Этап1Identity > IdentityPrivacy > AnonymousIdentity	Указывает, что клиенты настроены таким образом, чтобы они не могли отправлять свое удостоверение, прежде чем клиент прошел проверку подлинности сервера RADIUS, а также предоставляет место для ввода значения анонимного удостоверения. Если вы выберете «Включить конфиденциальность удостоверения», а затем введите anonymous в качестве значения анонимного удостоверения, ответ удостоверения для пользователя с удостоверением alice@example anonymous@example . Если выбран параметр «Включить конфиденциальность удостоверений», но не указать значение анонимного удостоверения, ответ удостоверения для пользователя alice@example . @example
    Параметры проверки сервера
    Выберите метод EAP для проверки подлинности	Phase2Authentication (> InnerMethodConfig > EapHostConfig)	Позволяет пользователю выбрать основной или вторичный метод проверки подлинности между Корпорацией Майкрософт: Smart карта или другим сертификатом (EAP-TLS) и Корпорацией Майкрософт: защищенный пароль (EAP-MSCHAP версии 2).

    Серверная проверка

    Многие методы EAP включают параметр для клиента для проверки сертификата сервера. Если сертификат сервера не проверен, клиент не может убедиться, что он взаимодействует с правильным сервером. Это предоставляет клиенту риски безопасности, включая возможность того, что клиент может неназнательно подключиться к изгоев сети.

    Для Windows требуется сертификат сервера с EKU проверки подлинности сервера. Идентификатор объекта (OID) для этого EKU 1.3.6.1.5.5.7.3.1 .

    В следующей таблице перечислены параметры проверки сервера, применимые к каждому методу EAP. Windows 11 обновила логику проверки сервера, чтобы быть более согласованной (см. статью «Обновлено поведение проверки сертификата сервера» в Windows 11). Если они конфликтуют, описания в следующей таблице описывают поведение Windows 10 и более ранних версий.

    Параметр	XML-элемент	Description
    Проверка удостоверения сервера путем проверки сертификата	EAP-TLS: ВыполнениеServerValidation

    EAP-TTLS:
    ServerValidation>
    Имя сервера

    Необходимо ввести имя точно так же , как оно отображается в поле темы каждого сертификата сервера RADIUS или использовать регулярные выражения (regex), чтобы указать имя сервера.

    Полный синтаксис регулярного выражения можно использовать для указания имени сервера, но для отличия регулярного выражения с литеральной строкой необходимо использовать по крайней мере один * в указанной строке. Например, можно указать nps.*\.example\.com сервер nps1.example.com RADIUS или nps2.example.com .

    Кроме того, можно включить разделять ; несколько серверов.

    EAP-TTLS:
    ServerValidation>
    TrustedRootCAHashes

    Если доверенные корневые центры сертификации не выбраны, клиент проверяет, выдан ли сертификат сервера RADIUS любым доверенным корневым ЦС.

    Если у вас есть инфраструктура открытого ключа (PKI) в сети, и вы используете ЦС для выдачи сертификатов серверам RADIUS, сертификат ЦС автоматически добавляется в список доверенных корневых ЦС. Вы также можете приобрести сертификат ЦС от поставщика, отличного от Майкрософт. Некоторые доверенные корневые центры сертификации майкрософт предоставляют программное обеспечение с приобретенным сертификатом, который автоматически устанавливает приобретенный сертификат в хранилище сертификатов доверенных корневых центров сертификации. В этом случае доверенный корневой ЦС автоматически отображается в списке доверенных корневых ЦС.

    Не указывайте доверенный сертификат корневого ЦС, который еще не указан в сертификатах доверенных корневых центров сертификации клиентских компьютеров для текущего пользователя и локального компьютера. Если вы назначите сертификат, который не установлен на клиентских компьютерах, проверка подлинности завершится ошибкой.

    Запрос пользователя проверки сервера

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

    • немедленно завершить подключение или
    • разрешить пользователю вручную принять или отклонить подключение.

    Параметр	XML-элемент
    Не запрашивайте у пользователя авторизацию новых серверов или доверенных центров сертификации	ServerValidation DisableUserPromptForServerValidation>

    Запрещает пользователю доверять сертификату сервера, если этот сертификат настроен неправильно, не является доверенным или обоим (если он включен). Чтобы упростить взаимодействие с пользователем и запретить пользователям ошибочно доверять серверу, развернутым злоумышленником, рекомендуется выбрать этот проверка box.

    Параметр	XML-элемент
    Уведомления перед подключением	ServerValidation>

    2. DisableUserPromptForServerValidation= false

    Указывает, уведомляется ли пользователь о том, не указан ли имя сервера или корневой сертификат или не удалось проверить удостоверение сервера. Ниже приведены доступные варианты выбора и указания каждого из них:

    1. Не попросите пользователя авторизовать новые серверы или доверенные центры сертификации. Если имя сервера не находится в списке Подключение этих серверов, или корневой сертификат найден, но не выбран в списке доверенных корневых центров сертификации в свойствах PEAP или корневой сертификат не найден на компьютере, то пользователь не получает уведомления и попытки подключения завершаются ошибкой.
    2. Сообщите пользователю, не указан ли имя сервера или корневой сертификат. Если имя сервера не находится в списке Подключение этих серверов, или корневой сертификат найден, но не выбран в списке доверенных корневых центров сертификации в свойствах PEAP, то пользователю будет предложено принять корневой сертификат. Если пользователь принимает сертификат, проверка подлинности продолжается. Если пользователь отклоняет сертификат, попытка подключения завершается ошибкой. Если корневой сертификат отсутствует на компьютере, пользователь не получает уведомления и попытка подключения завершается ошибкой.
    3. Сообщите пользователю, не удалось ли проверить удостоверение сервера. Если имя сервера не находится в списке Подключение этих серверов, или корневой сертификат найден, но не выбран в списке доверенных корневых центров сертификации в свойствах PEAP или корневой сертификат не найден на компьютере, то пользователю будет предложено принять корневой сертификат. Если пользователь принимает сертификат, проверка подлинности продолжается. Если пользователь отклоняет сертификат, попытка подключения завершается ошибкой.

    Параметр	XML-элемент
    Не запрашивайте пользователя, если не удается авторизовать сервер	ServerValidation> DisableUserPromptForServerValidation

    Указывает, если проверка сертификата сервера завершается ошибкой из-за следующих причин, пользователю будет предложено принять или отклонить сервер:

    • Корневой сертификат для сертификата сервера не найден или не выбран в списке доверенных корневых центров сертификации.
    • Один или несколько промежуточных корневых сертификатов в цепочке сертификатов не найдены.
    • Имя субъекта в сертификате сервера не соответствует ни одному из серверов, указанных в списке Подключение этих серверов.

    Параметр	XML-элемент
    Не запрашивайте пользователя, если не удается авторизовать сервер	ServerValidation>DisablePrompt

    Указывает, если проверка сертификата сервера завершается ошибкой из-за следующих причин, пользователю будет предложено принять или отклонить сервер:

    • Корневой сертификат для сертификата сервера не найден или не выбран в списке доверенных корневых центров сертификации.
    • Один или несколько промежуточных корневых сертификатов в цепочке сертификатов не найдены.
    • Имя субъекта в сертификате сервера не соответствует ни одному из серверов, указанных в списке Подключение этих серверов.

    Параметры конфигурации проверки подлинности сотовой связи

    Ниже перечислены параметры конфигурации для EAP-SIM, EPA-AKA и EPA-AKA соответственно.

    EAP-SIM определен в RFC 4186. Модуль удостоверений подписчика EAP используется для проверки подлинности и распространения ключей сеанса с помощью модуля идентификации подписчика (SIM) поколения 2-го поколения глобальной системы мобильной связи (GSM).

    Параметры EAP-SIM в пользовательском интерфейсе сопоставлены с EapSim Подключение ionPropertiesV1.

    Товар	XML-элемент	Description
    Использование надежных ключей шифров	UseStrongCipherKeys	Указывает, что если выбрано, профиль использует строгое шифрование.
    Не показывайте реальное удостоверение на сервере, если удостоверение псевдонима доступно	DontRevealPermanentID	Если этот параметр включен, клиент должен завершить проверку подлинности, если сервер запрашивает постоянное удостоверение, хотя у клиента есть псевдоним. Псевдонимные удостоверения используются для конфиденциальности удостоверений, чтобы фактическое или постоянное удостоверение пользователя не отображалось во время проверки подлинности.
    ProviderName	Доступна только в XML-коде строка, указывающая имя поставщика, которое разрешено для проверки подлинности.
    Включение использования областей	Realm= true	Предоставляет место для ввода имени области. Если это поле остается пустым с выбранным параметром «Включить использование областей «, область является производным от международного удостоверения мобильного подписчика (IMSI) с помощью области 3gpp.org, как описано в стандарте 23.003 V6.8.06.0, как описано в стандарте 3-го поколения партнерства (3GPP).
    Указание области	Realm	Предоставляет место для ввода имени области. Если включено включение использования областей , эта строка используется. Если это поле пусто, используется производная область.

    EAP-AKA определен в RFC 4187. Для проверки подлинности и ключа EAP (AKA) используется для распространения ключей проверки подлинности и сеанса с помощью механизма AKA. AKA используется в 3-м поколении мобильных сетей Универсальной мобильной телекоммуникационной системы (UMTS) и CDMA2000. AKA основана на симметричные ключи и обычно выполняется в модуле удостоверений подписчика (SIM).

    Параметры EAP-AKA в сопоставлении пользовательского интерфейса с EapAka Подключение ionPropertiesV1.

    Товар	XML-элемент	Description
    Не показывайте реальное удостоверение на сервере, если удостоверение псевдонима доступно	DontRevealPermanentID	Если этот параметр включен, клиент должен завершить проверку подлинности, если сервер запрашивает постоянное удостоверение, хотя у клиента есть псевдоним. Псевдонимные удостоверения используются для конфиденциальности удостоверений, чтобы фактическое или постоянное удостоверение пользователя не отображалось во время проверки подлинности.
    ProviderName	Доступна только в XML-коде строка, указывающая имя поставщика, которое разрешено для проверки подлинности.
    Включение использования областей	Realm= true	Предоставляет место для ввода имени области. Если это поле остается пустым с выбранным параметром «Включить использование областей «, область является производным от международного удостоверения мобильного подписчика (IMSI) с помощью области 3gpp.org, как описано в стандарте 23.003 V6.8.06.0, как описано в стандарте 3-го поколения партнерства (3GPP).
    Указание области	Realm	Предоставляет место для ввода имени области. Если включено включение использования областей , эта строка используется. Если это поле пусто, используется производная область.

    EAP-AKA ‘ определен в RFC 5448 и RFC 9048. EAP-AKA Prime (AKA’) — это измененная версия EAP-AKA, которая добавляет новую функцию вывода ключей для упрощения доступа к сетям на основе 3-го поколения (3GPP) с помощью стандартов, отличных от 3GPP, таких как:

    • Wi-Fi
    • Оптимизация для эволюции данных (EVDO)
    • Взаимодействие по всему миру для доступа к микроволновой печи (WiMax)

    Параметры EAP-AKA в пользовательском интерфейсе сопоставлены с EapAkaPrime Подключение ionPropertiesV1.

    Товар	XML-элемент	Description
    Не показывайте реальное удостоверение на сервере, если удостоверение псевдонима доступно	DontRevealPermanentID	Если этот параметр включен, клиент должен завершить проверку подлинности, если сервер запрашивает постоянное удостоверение, хотя у клиента есть псевдоним. Псевдонимные удостоверения используются для конфиденциальности удостоверений, чтобы фактическое или постоянное удостоверение пользователя не отображалось во время проверки подлинности.
    ProviderName	Доступна только в XML-коде строка, указывающая имя поставщика, которое разрешено для проверки подлинности.
    Включение использования областей	Realm= true	Предоставляет место для ввода имени области. Если это поле остается пустым с выбранным параметром «Включить использование областей «, область является производным от международного удостоверения мобильного подписчика (IMSI) с помощью области 3gpp.org, как описано в стандарте 23.003 V6.8.06.0, как описано в стандарте 3-го поколения партнерства (3GPP).
    Указание области	Realm	Предоставляет место для ввода имени области. Если включено включение использования областей , эта строка используется. Если это поле пусто, используется производная область.
    Игнорировать несоответствие имени сети	IgnoreNetworkNameMismatch	Клиент сравнивает имя сети, известное ему, с именем, отправляемым сервером RADIUS во время проверки подлинности. Если есть несоответствие, он игнорируется, если этот параметр выбран. Если проверка подлинности не выбрана, проверка подлинности завершается ошибкой.
    Включение быстрой повторной проверки подлинности	EnableFastReauth	Указывает, что включена быстрая повторная авторизация. Быстрая повторная проверка подлинности полезна при частой проверке подлинности SIM. Ключи шифрования, производные от полной проверки подлинности, используются повторно. В результате алгоритм SIM-карты не требуется для каждой попытки проверки подлинности, а количество сетевых операций, которые приводят к частым попыткам проверки подлинности, уменьшается.

    192-разрядный режим WPA3-Enterprise

    Режим WPA3-Enterprise 192-разрядного режима — это специальный режим для WPA3-Enterprise, который применяет определенные высокие требования безопасности к беспроводному подключению, чтобы обеспечить не менее 192 бит безопасности. Эти требования соответствуют набору алгоритмов коммерческой национальной безопасности (CNSA), CNSSP 15, который является набором криптографических алгоритмов, утвержденных для защиты секретной информации США Агентства национальной безопасности (NSA). 192-разрядный режим иногда можно называть «режимом B Suite B», который является ссылкой на спецификацию шифрования NSA Suite B, которая была заменена CNSA в 2016 году.

    Режим WPA3-Enterprise и WPA3-Enterprise 192-bit доступны начиная с Windows 10 версии 2004 (сборка 19041) и Windows Server 2022. Однако WPA3-Enterprise был выделен в качестве отдельного алгоритма проверки подлинности в Windows 11. В XML это указано в элементе authEncryption .

    В следующей таблице перечислены алгоритмы, необходимые для CNSA Suite.

    Алгоритм	Description	Параметры
    Стандарт AES (Advanced Encryption Standard)	Симметричный блочный шифр, используемый для шифрования	256-разрядный ключ (AES-256)
    Обмен ключами эллиптической кривой Диффи-Хеллман (ECDH)	Асимметричный алгоритм, используемый для установления общего секрета (ключа)	384-разрядная кривая основного модуля (P-384)
    Алгоритм цифровой подписи с многоточием (ECDSA)	Асимметричный алгоритм, используемый для цифровых подписей	384-разрядная кривая основного модуля (P-384)
    алгоритм SHA	Функция хэша шифрования	SHA-384
    Обмен ключами Diffie-Hellman (DH)	Асимметричный алгоритм, используемый для установления общего секрета (ключа)	3072-разрядный модуль
    Ривст-Шамир-Адлеман (RSA)	Асимметричный алгоритм, используемый для цифровых подписей или создания ключей	3072-разрядный модуль

    В соответствии с CNSA, wpA3-Enterprise 192-разрядного режима требуется, чтобы EAP-TLS использовался со следующими наборами шифров с ограничениями:

    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      • ECDHE и ECDSA с использованием 384-разрядной основной модулы кривой P-384
      • ECDHE с помощью 384-разрядной основной модулы кривой P-384
      • RSA >= 3072-разрядный модуль

      P-384 также называется secp384r1 или nistp384 . Другие эллиптические кривые, такие как P-521, не допускаются.

      SHA-384 находится в семействе хэш-функций SHA-2. Другие алгоритмы и варианты, такие как SHA-512 или SHA3-384, не допускаются.

      Windows поддерживает только TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 наборы шифров для wpA3-Enterprise 192-разрядного режима. Набор TLS_DHE_RSA_AES_256_GCM_SHA384 шифров не поддерживается.

      TLS 1.3 использует новые упрощенные наборы TLS, из которых совместим только TLS_AES_256_GCM_SHA384 с режимом WPA3-Enterprise 192-bit. Так как протокол TLS 1.3 требует DHE и разрешает сертификаты ECDSA или RSA, а также хэш AES-256 AEAD и SHA384, TLS_AES_256_GCM_SHA384 эквивалентны TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 и TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 . Тем не менее, RFC 8446 требует, чтобы приложения TLS 1.3 поддерживали P-256, которые запрещены CNSA. Поэтому 192-разрядный режим WPA3-Enterprise не может быть полностью совместим с TLS 1.3. Однако известные проблемы взаимодействия с TLS 1.3 и WPA3-Enterprise 192-bit mode отсутствуют.

      Чтобы настроить сеть для режима WPA3-Enterprise 192-разрядного режима, Windows требует, чтобы EAP-TLS использовался с сертификатом, соответствующим требованиям, описанным ранее.

      Дополнительные ресурсы

      • Управление политиками новой беспроводной сети (IEEE 802.11) Параметры
      • Управление политиками новой проводной сети (IEEE 802.3) Параметры
      • Расширенные Параметры безопасности для политик проводной и беспроводной сети

      Записки IT специалиста

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

      Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

      Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

      • Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
      • Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

      Чтобы проще представить себе этот процесс проведем простую аналогию. Вы находитесь за границей и вас останавливает полицейский, вы предъявляете свой паспорт. Полицейский проверяет данные в паспорте и сверяет фотографию — это процесс аутентификации. Убедившись, что вы это вы, полицейский просит показать визу — это процесс авторизации, т.е. вашего права здесь находиться.

      Точно также, сотрудник полиции, остановив трудового мигранта и проверив его паспорт, просит разрешение на работу, если разрешения нет, то зарубежный гость успешно прошел аутентификацию, но провалил авторизацию. Если аутентификация не пройдена, то до авторизации дело не дойдет.

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

      Локальная аутентификация

      Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование — это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь — единственный кто его знает.

      

      Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

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

      В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже.

      LAN Manager (LM)

      Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

      Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

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

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

      А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

      NT LAN Manager (NTLM)

      Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

      Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

      Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

      Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

      

      Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер — к кому обращаются.

      Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

      Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной.

      В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

      В случае получения доступа к третьим ресурсам схема также немного изменяется:

      

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

      Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

      Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

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

      NTLMv2

      Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

      

      Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число — запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента. Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.

      Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

      Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

      Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

      При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

      Настройки безопасности

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

      За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера — Конфигурация Windows — Политики безопасности — Локальные политики — Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

      

      В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

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

      Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

      Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
      Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLM аутентификацию , и никогда не используют сеансовую безопасность NTLMv2.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	0
      Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
      Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
      Отправлять только NTLMv2-ответ	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
      Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
      Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2.	5

      Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно.

      После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

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

      Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

      Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

      

      

      Или подпишись на наш Телеграм-канал:

      Лекция 5. Протоколы сетевой аутентификации. Модели разграничения доступа. Вредоносное программное обеспечение.

      Локальная аутентификация в операционных системах Windows выполняется в следующей последовательности:

      

      1. Пользователь вводит логин и пароль
      2. Данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш. В открытом виде пароли нигде не хранятся.
      3. Служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя
      4. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля)
      5. Затем LSA сравнивает хэши, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и до окончания сеанса пользователя

      Рис. 1. Схема работы локальной аутентификации Windows

      Протоколы сетевой аутентификации

      Существует несколько различных протоколов, описывающих процесс аутентификации субъектов в локальной сети. В рамках операционных систем Windows компании Микрософт использовались протоколы:

      • LAN Manager (LM),
      • NT LAN Manager (NTLM),
      • NT LAN Manager версии 2 (NTLM v2)

      Рассмотрим актуальные на данный момент протоколы аутентификации – NTLM v2 и Kerberos.

      Протокол NTLM v2.

      Схема работы протокола NTLMv2 с контроллером домена

      

      1. Клиент при обращении к серверу сообщает ему имя пользователя и имя домена
      2. Сервер передает ему случайное число — запрос сервера
      3. Клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента
      4. Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш
      5. От данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу
      6. Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена (КД)
      7. КД извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом
      8. В случае совпадения серверу возвращается ответ об успешной аутентификации.

      Рис. 2. Схема работы протокола NTLMv2 с контроллером домена

      Протокол аутентификации Kerberos

      Протокол Kerberos был специально разработан для обеспечения надежной аутентификации пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sign-On (возможность одноразовой аутентификации в нескольких приложениях). Протокол Kerberos предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними с учетом того, что начальный обмен информацией между клиентом и сервером может происходить в незащищённой среде, а передаваемые пакеты — перехвачены и модифицированы.

      Протокол использует понятие Ticket (билет, удостоверение).

      Ticket является зашифрованным пакетом данных, выданным выделенным доверенным центром аутентификации, в терминах протокола Kerberos — KDC (Key Distribution Center, центр распределения ключей).

      KDC состоит из двух компонент:

      • сервер аутентификации (англ. Authentication Server, сокр. AS);
      • сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS).

      

      Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдаёт первичное удостоверение пользователя для доступа к сетевым ресурсам — TGT (Ticket Granting Ticket). В дальнейшем при обращении к отдельным сетевым ресурсам пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket.

      Рис. 3. Схема работы протокола Kerberos

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

      В качестве примера реализации протокола Kerberos следует отметить доменную аутентификацию пользователей в операционных системах компании Microsoft, начиная с Windows 2000.

      Протоколы аутентификации для удалённого доступа

      Часть протоколов сетевой аутентификации были разработаны специально для обеспечения удаленного доступа к информационным ресурсам посредством открытых каналов связи (к примеру, телефонные линии, Internet).

      Такими протоколами являются:

      • PAP (Password Authentication Protocol);
      • CHAP (Challenge Handshake Authentication Protocol);
      • EAP (Extensible Authentication Protocol);
      • RADIUS (Remote Authentication Dial-in User Service);
      • TACACS (Terminal Access Controller Access Control System).

      В качестве примера кратко рассмотрим работу протокола RADIUS.

      Протокол аутентификации RADIUS

      Протокол аутентификации Remote Authentication Dial-in User Service (RADIUS) 2 рассматривается как механизм аутентификации и авторизации удалённых пользователей в условиях распределённой сетевой инфраструктуры, предоставляющий централизованные услуги по проверке подлинности и учёту для служб удалённого доступа.

      В рамках стандарта выделяются следующие роли:

      Клиент RADIUS. Клиент RADIUS принимает от пользователей запросы на аутентификацию. Все принятые запросы переадресовываются серверу RADIUS для последующей аутентификации и авторизации. Как правило, в качестве клиента протокола RADIUS выступает сервер удалённого доступа.

      Сервер RADIUS. Основная задача сервера RADIUS заключается в централизованной обработке информации, предоставленной клиентами RADIUS. Один сервер способен обслуживать несколько клиентов RADIUS. Сервер осуществляет проверку подлинности пользователя и его полномочий. При этом в зависимости от реализации сервера RADIUS для проверки подлинности используются различные базы данных учётных записей.

      Посредник RADIUS. Взаимодействие клиентов и серверов RADIUS осуществляется посредством специальных сообщений. В распределённых сетях клиент и сервер RADIUS могут быть разделены различными сетевыми устройствами (такими, например, как маршрутизатор). Под посредником RADIUS понимается сетевое устройство, способное осуществлять перенаправление сообщений протокола RADIUS.

      Поддержка протокола RADIUS реализована на многих современных платформах, что позволяет использовать его в межплатформенных решениях.

      В качестве примера сервера и посредника RADIUS можно привести реализованную в Windows Server 2003 службу проверки подлинности в Интернете (Internet Authentication Service, IAS). Эта служба позиционируется как механизм централизованной аутентификации и авторизации пользователей, использующих различные способы подключений к сети. Служба IAS интегрирована с другими сетевыми службами Windows Server 2003, такими, как служба маршрутизации и удалённого доступа и служба каталога Active Directory.

      Авторизация – модели разграничения доступа

      Для более подробного изучения механизмов авторизации рассмотрим следующие модели разграничения доступа:

      • Discretionary access control, DAC
      • Mandatory access control, MAC
      • Role-based access control, RBAC
      • Attribute-based access control, ABAC
      • Гибридные модели

      Discretionary access control (дискреционная модель разграничения доступа)

      • Избирательное управление доступом
      • Для каждой пары субъект-объект задаётся перечисление допустимых разрешений (Например read, write, execute)
      • Часто объект имеет привязанного субъекта-владельца. Владелец может устанавливать разрешения для других субъектов.

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

      Существуют два подхода к построению дискреционного управления доступом:

      • Каждый объект системы имеет привязанного к нему субъекта, называемого владельцем. Именно владелец устанавливает права доступа к объекту.
      • Система имеет одного выделенного субъекта – суперпользователя, который имеет право устанавливать права владения для всех остальных субъектов системы.

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

      Mandatory access control (мандатная модель разграничения доступа)

      • Мандатное управление доступом
      • Все субъекты и объекты ИС должны быть однозначно идентифицированы
      • Задан линейно упорядоченный набор меток секретности
      • Объекты несут метку секретности, определяя ценность содержащейся информации – уровень секретности
      • Каждому субъекту присвоена метка секретности, определяющая максимальное значение метки секретности объектов, к которым субъект имеет доступ; Метка секретности субъекта называется его уровнем доступа.

      Процедура назначения прав доступа происходит с использованием так называемых меток конфиденциальности или мандатов, назначаемых субъектам и объектам доступа.

      Так, для субъекта доступа метки, например, могут определяться в соответствии с уровнем доступа лица к информации, а для объекта доступа (собственно данные) – с уровнем секретности. Признаки конфиденциальности фиксируются в метке объекта.

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

      Требования к мандатному механизму управления доступом:

      

      1. Каждому субъекту и объекту доступа должны сопоставляться классификационные метки, отражающие их место в соответствующей иерархии. Посредством этих меток субъектам и объектам должны назначаться классификационные уровни. Данные метки должны служить основой мандатного принципа разграничения доступа
      2. Система защиты должна реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов:
      • субъект может читать объект, только если мандатная метка субъекта не меньше, чем мандатная метка объекта.

      Рис. 4. Чтение информации в мандатной модели

      

      • субъект осуществляет запись в объект, только если его мандатная метка не больше, чем мандатная метка объекта.

      Рис. 5. Запись информации в мандатной модели

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

      Достоинства.

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

      Недостатки.

      • Избыточности прав доступа для конкретных субъектов в пределах соответствующих уровней.

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

      Role-based access control (ролевая модель разграничения доступа)

      • Управление доступом на основе ролей
      • Субъекту присваивается роль или роли
      • Выдаются разрешения заданным ролям
      • Реализует DAC и MAC
      • Может быть усложнен введением наследования ролей
      • Распространен в корпоративных приложениях
      • Пример: пользователь может подтвердить заказ, если его роль – менеджер

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

      Если бизнес-правила одномерны и все действия можно распределить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.
      

      Рис. 6. Распределение ролей по бизнес правилам в ролевой модели

      Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит и т. п.).

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

      Рис. 7. Рост многомерности бизнес правил

      После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», то придется добавить новые роли, такие как «Администратор филиала «Г», «Менеджер филиала «Г», «Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Это порождает много рутинного ручного труда.

      Кроме этого, появляются и другие недостатки:

      • одно бизнес-правило «размазывается» среди множества ролей и становится неочевидным, что усложняет понимание такого правила и его поддержку;
      • начинается взрывной рост числа ролей, что значительно усложняет управление ими.

      

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

      Рис. 8. Бизнес-правила с атрибутами, значения которых заранее не известны

      

      Бизнес-правила, которые ограничивают доступ не к действиям, а к данным, также невозможно выразить с помощью ролевой модели:

      Рис. 9. Бизнес-правила, которые ограничивают доступ не к действиям, а к данным

      Attribute-based access control (модель разграничения доступа на основе атрибутов)

      • Управление доступом на основе атрибутов
      • Субъекты и объекты наделяются атрибутами
      • Политики вычисляют условия, заданные через выражения атрибутов субъекта и объекта
      • Пример: Пользователь может подтвердить заказ, если подразделение пользователя равно подразделению, в котором создан заказ, и должность субъекта – менеджер

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

      Бизнес-правило представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.

      

      Можно явно выделить несколько категорий атрибутов:

      Рис. 10. Несколько категорий атрибутов

      Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу.

      

      Простые правила описываются простыми условиями.

      Рис. 11. Пример простых бизнес правил

      

      Многомерные правила в этой модели не становятся более сложными

      Рис. 12. Пример многомерных бизнес правил

      ABAC позволяет избежать проблем, которые появляются в RBAC:

      • бизнес-правило не «размазывается» по системе, что делает его понимание и поддержку достаточно простыми;
      • не происходит взрывного роста числа условий, что упрощает их сопровождение.
      • ABAC позволяет решить проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет ограничений на сложность бизнес-правил. Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении.

      

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

      Рис. 13. Пример бизнес правил с применением фильтра

      Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных.

      

      
      Таблица 1. Сравнение ABAC и RBAC

      Как видно из сравнения, RBAC хорошо подходит только для реализации простых бизнес-правил. С увеличением сложности правил целесообразность использования RBAC уменьшается из-за растущей стоимости поддержки системы контроля доступа, а начиная с определенного уровня сложности правил этот подход вообще не дает результата.

      ABAC, в свою очередь, не ограничивает сложность бизнес-правил. Благодаря более понятному бизнесу и компактному выражению этот подход позволяет не увеличивать стоимость поддержки при реализации более сложных правил, а также дает возможность обеспечивать контроль доступа не только к действиям, но и к данным.

      Вредоносное программное обеспечение

      Обзор актуальной вирусной активности на сайте https://news.drweb.ru/

      Антивирусная программа— программа для обнаружения компьютерных вирусов и вредоносных программ, восстановления заражённых (модифицированных) такими программами файлов, а также для предотвращения заражения (модификации) файлов вредоносным кодом

      Вредоносное ПО (malware – сокращение от malicious software) – это различные программы, которые могут наносить вред.

      Вредоносное ПО – это любая нежелательная программа, которая устанавливается на компьютере без вашего ведома. Вирусы, черви и троянские кони – это примеры вредоносных программ, которые часто совокупно называются вредоносным ПО.

      Компьютерные вирусы – это небольшие программы, которые разработаны для распространения от одного компьютера к другому и вмешательства в работу компьютера.

      Вирус может повредить или удалить данные на вашем компьютере, использовать вашу почтовую программу для самостоятельного распространения на другие компьютеры и даже стереть все на вашем диске.

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

      Признаки возможного заражения компьютера:

      • Компьютер работает медленнее, чем обычно
      • Компьютер перестает реагировать на действия пользователя или часто «зависает»
      • Компьютер «зависает» и перезагружается каждые несколько минут
      • Компьютер запускается самостоятельно, после чего отказывается работать надлежащим образом
      • Приложения на компьютере не работают корректно
      • Диски или дисководы недоступны
      • Печать не работает надлежащим образом
      • Отображаются необычные сообщения об ошибках
      • Меню или диалоговые окна отображаются искаженно

      Категории угроз

      Рекламные программы

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

      Рекламное ПО/шпионское ПО

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

      Приложение из неизвестного источника

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

      Backdoor-программы

      Для организации кражи данных или манипуляции с компьютером, backdoor-программа удаленного администрирования проникает в систему через черный ход, о чем пользователь, как правило, даже не догадывается. Через Интернет или ЛВС клиентская часть такой программы (Client) может управляться третьими лицами.

      Файлы со скрытыми расширениями

      Исполняемые файлы, скрывающие настоящие расширения файлов. Этот метод сокрытия часто используется вредоносным ПО.

      Фишинг

      Фишинг — это способ обмана, используемый интернет-мошенниками для того, чтобы получить личные сведения о пользователе.

      В качестве приманки мошенники, которые занимаются фишингом, используют электронные письма и веб-узлы, которые имитируют хорошо известные и надежные торговые марки.

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

      Цель рассылки поддельных сообщений — обманным путем заставить потребителей предоставить указанные ниже личные сведения:

      # Личное имя и имя пользователя.

      # Адрес и номер телефона.

      # Паспортные данные или PIN-код.

      # Номер банковского счета.

      # Номер дебетовой или кредитной карточки.

      # Код проверки карточки (CVC) или контрольное число карточки (CVV).

      # Номер социального страхования.

      Программы-шутки

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

      Все симптомы таких развлекательных программ могут быть также имитированы вирусами или троянами.

      Обманная программа

      «ложные антивирусы» – это поддельные программы, которые сообщают о вирусном заражении и опасности и при этом внешне очень похожи на профессиональные антивирусные программы. Поддельные антивирусы предназначены для запугивания пользователей и придания им неуверенности. Если жертва попалась на удочку и считает себя подверженной угрозе, зачастую за отдельную плату ей предлагается устранение несуществующей опасности. В других случаях жертва, поверившая в нападение на нее, принуждается к определенными действиям, вследствие которых действительно будет совершено нападение.

      Bot-сети

      Под Bot-сетью понимается удаленно управляемая сеть (в Интернете), состоящая из отдельных персональных компьютеров, связывающихся между собой. Контроль сети достигается с помощью вирусов или троянских программ, инфицирующих компьютер, они ожидают дальнейших указаний злоумышленника, не принося вреда инфицированным компьютерам. Эти сети могут применяться для рассылки спама или организации DDoS атак; пользователи участвующих компьютеров могут и не догадываться о происходящем.

      Эксплойт

      Эксплойт — это компьютерная программа или скрипт, использующий специфические уязвимости операционной системы или программы.

      Скрытый майнер (stealth miner, майнер-бот, ботнет)

      К данной категории относятся программы, которые в автоматическом режиме ведут майнинг криптовалют незаметно для пользователя. Это стороннее ПО, которое устанавливается на компьютер, использует его ресурсы и перечисляет все заработанные средства на криптовалютный кошелек разработчика.

      Фарминг

      Фарминг — это манипуляция хост-файлом веб-браузера для перенаправления запроса на фальшивый сайт. Это производная от классического фишинга. Фарминг-мошенники содержат сервера больших объемов, на которых хранятся фальшивые веб-страницы. Фарминг можно назвать общим понятием различных типов DNS-атак. При манипуляции хост-файлом с помощью троянской программы или вируса производится манипуляция системой. В результате система способна загружать только фальсифицированные веб-сайты, даже если вы правильно вводите адрес.

      АУТЕНТИФИКАЦИЯ в разных версиях 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).

      Листинг 2. Включение поддержки NTLMv2 в системах Windows 9x/NT 4.0

      (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 .

      Похожие публикации:

      1. Volkswagen polo как подключить блютуз
      2. Как в питоне вывести текст лесенкой
      3. Как отправить sms со смартфона на короткий номер
      4. Как сделать картинку фоном в css