РЕКОМЕНДАЦИИ ПО ЗАЩИТЕ КАТАЛОГОВ УЧЕТНЫХ ЗАПИСЕЙ В ДОМЕННОЙ СТРУКТУРЕ

В современных компьютерных сетях для эффективного управления сетевыми ресурсами применяются службы каталогов стандарта X.500. Основной административной единицей в сетевой инфраструктуре предприятия является домен – совокупность всех сетевых объектов. Служба каталогов представляет собой распределенную базу данных, в которой содержатся все объекты домена. Такая служба каталогов является единой точкой аутентификации и авторизации пользователей и приложений в масштабах предприятия. Также, служба каталогов позволяет управлять политиками (настройками безопасности) на всех объектах, входящих в домен. В домене, построенном на базе решений компании Microsoft, службой каталогов является Active Directory (AD). AD имеет широкие возможности масштабирования (в ней может содержаться более двух миллиардов объектов), она позволяет создавать иерархическую структуру доменов, благодаря чему возможно гибкое масштабирование ИТ-инфраструктурой компании.

Служба каталогов AD является сердцем ИТ-инфраструктуры предприятия. В случае её отказа будут парализованы все сервера, вся сеть, работа всех пользователей будет приостановлена. Многие атаки на AD основаны на получении доступа к привилегированным учетным записям пользователей. Пользователь с такими привилегиями может парализовать работу предприятия либо похитить конфиденциальную информацию.

При входе пользователя в AD используются протоколы аутентификации, которые являются критической точкой при проверке подлинности пользователя. В AD для аутентификации пользователя в домене используются протоколы NTLM и Kerberos. NTLM, в связи с тем, что в нем используется алгоритм шифрования DES, не является надежным. Первая версия этого протокола обладает критическими уязвимостями, в связи с чем была разработана вторая версия этого протокола, NTLMv2, которая устраняет часть уязвимостей, но, тем не менее, считается менее надежной, чем протокол Kerberos. Несмотря на то, что в Windows 2000 появилась поддержка протокола Kerberos для аутентификации, протоколы семейства NTLM остаются широко применяемыми. Причины этому следующие:

• Протокол NTLMv2 широко распространен (например, он используется при VPN-подключениях как часть протокола PEAP и при аутентификации через WiFi по протоколу EAP-MSCHAPv2);
• В случае, если аутентификация по протоколу Kerberos по какой-либо причине не срабатывает, применяется аутентификация с использованием NTLM;
• Kerberos не умеет работать с локальными учетными записями на доменных машинах, при операциях с ними используется NTLM.

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

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

Для выключения хранения NTLM-хешей можно воспользоваться стандартной настройкой групповых политик AD «Network Security: Do not store LAN Manager hash value on next password change», расположенной по адресу: «Computer Configuration > Policies > Windows Settings > Name Resolution Policy > Security Settings > Local Policies > Security Options». После применения этой настройки, новые NTLM-хеши не будут образовываться у попавших под действие этой групповой политики объектов.

Для выключения отправки NTLM-запросов и NTLM-ответов можно воспользоваться соседней настройкой групповых политик «Network security: LAN Manager authentication level», расположенной по тому же адресу. В ней требуется задать значение «Send NTLMv2 response only. Refuse LM & NTLM». Задание этой настройки гарантирует то, что NTLM-хеши не будут ни отправляться, ни приниматься ни одной системой, которая попадает под эту групповую политику.

Следует отметить, что это не приведет к проблемам в работе современных ОС – даже Microsoft Windows 98 сможет корректно работать в домене, где есть такая настройка – для этого потребуется добавить поддержку NTLMv2 установкой компонента dsclient.

Следующий шаг – препятствие генерации NTLM-хешей. Для этого достаточно включить генерирование паролей с длиной более 14 символов. NTLM не сможет создать хеш для такого пароля и выдаст предупреждение, что введенный пароль не сможет быть применен на старых системах (Microsoft Windows 3.1 / 3.11). Для этого рекомендуется использовать Fine Grain Password Policies / Password Settings Object. Создается новый PSO и привязывается к целевой группе, для которой будет действовать политика длинных паролей.

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

Помимо аутентификации учетных записей в домене AD, также работает аутентификация внутри запроса на удаленный вызов процедуры DCE/RPC и DCOM. Для отключения NTLMv1 в этих протоколах существуют специальные групповые политики – «Network Security: Minimum session security for NTLM SSP based (including secure RPC) client» и «Network Security: Minimum session security for NTLM SSP based (including secure RPC) server» – первая групповая политика настраивает ситуацию, когда с текущего хоста запрашивается RPC-вызов, вторая – когда к текущему хосту приходит RPC-запрос. Важно использовать данную настройку, так как до Microsoft Windows Vista эта настройка не являлась настройкой по умолчанию, а системам Microsoft Windows XP/2003 требуется указать, что необходимо для RPC использовать NTLMv2.

В NTLM всех версий существует уязвимость – возможность «replay-атак». NTLM аутентифицирует сессию по ее сетевым параметрам. Допустим, из-под одного и того же адреса и порта прокси-сервера выходит несколько мультиплексированных сессий – NTLM не различает эти разные сессии. Для защиты от этой уязвимости применяется механизм Extended Protection for Authentication (EPA). Этот механизм представляет из себя генерацию (со стороны клиента) и проверку (со стороны сервера) двух дополнительных полей в сообщении NTLM_AUTHENTICATE – «MsvChannelBindings» и «MsvAvTargetName», которые образно называются «Channel Binding Token». Для того, чтобы включить данный механизм, требуется выполнить следующие действия:

1. Включить EPA в NTLMv2 – в ключе реестра «HKLM > System > CurrentControlSet > Control > LSA» добавить DWORD32-значение «SuppressExtendedProtection», которое выставляется в ноль. Логика следующая: это значение указывает, при работе каких протоколов подавлять генерацию CBT. Если в единицу поставить первый бит (т.е. SuppressExtendedProtection = 1), то CBT не будут генерироваться при работе NTLMv2, если второй – то при работе Kerberos. Соответственно, установка SuppressExtendedProtection в тройку выключает механизм и для NTLM, и для Kerberos, а в ноль – включает.
2. Для использования исключительно протокола NTLMv2 при доступе к файловым сервисам («файловым шарам»), требуется в ключе реестра «HKLM > System > CurrentControlSet > Services > LanmanServer > Parameters» создать DWORD32-параметр «SmbServerNameHardeningLevel». Этот параметр требуется выставить в значение «2» – для ограничения работы с данным сервером только по протоколу NTLMv2.
3. Для включения проверки CBT у входящих аутентификаций поверх HTTP требуется в конфигурации IIS (путь «system.webServer > security > authentication > windowsAuthentication») параметр «extendedProtection» установить в «1».

Следующий этап – минимизация использования NTLMv2 для того, чтобы в большинстве случаев использовался именно протокол Kerberos. Требуется включить аудит применений NTLM – в групповых политиках для этого есть соответствующие настройки: «Network Security: Restrict NTLM: Audit Incoming NTLM Traffic» (установить в значение «Enable auditing for domain accounts») и «Network Security: Restrict NTLM: Audit NTLM authentication in this domain» (установить в значение «Enable for domain accounts to domain servers»). После применения данных настроек, в журнал будут записываться ситуации, когда доменные учетные записи аутентифицируются не по протоколу Kerberos, а по протоколу NTLM, что даст возможность для поиска неисправностей в работе протокола Kerberos.

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

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

• в 1993 году специалист из Японии Мицуру Мацуи, изобретатель линейного криптоанализа, представил доказательства того, что есть возможность вычисления ключа шифрования DES при наличии у атакующего 2⁴⁷  пар известных открытых текстов;
• в 1991 году израильские криптологи Эли Бихам и Эди Шамир, изобретатели дифференциального криптоанализа, представили атаку, в ходе которой ключ шифрования находился на основе 2⁴⁷  пар выбранных открытых текстов с помощью дифференциального криптоанализа [1];
• в 1994 году Алекс Бирюков и Эли Бихам представили метод, позволяющий вычислить 6 из 56 битов ключа DES при наличии 2⁵⁰  пар открытых текстов, или 24 из 56 битов ключа DES при наличии 2⁵²  пар открытых текстов [1]. Остальные биты вычислялись с помощью полного перебора.

В дальнейшем эти атаки совершенствовались. Чаще всего это выражалось в том, что требовалось значительно меньше пар известных открытых текстов (до 2⁴³  [2]). Однако, для всех этих атак требовалось колоссальное количество пар «открытый текст – шифртекст», для получения которых требовалась очень трудоемкая операция. Поэтому намного проще атаковать DES методом полного перебора ключей шифрования [2].

Вскоре после появления DES, были найдены проблемы с ключами шифрования, такие как [3]:

• 4 ключа из возможных 2⁵⁶  ключей являются слабыми, то есть, они не обеспечивают требуемую криптостойкость при зашифровывании. При шифровании используется только 56 из 64 битов ключа, поэтому, после удаления проверочных 8 бит, ключ становится симметричным и состоит наполовину из нулей или единиц, или из всех нулей или единиц, поэтому они считаются слабыми. Если при шифровании будет использоваться слабый ключ, то все ключи раундов получатся идентичными, и, если текст зашифровать или расшифровать два раза на этом ключе, можно получить исходный текст. Злоумышленник, если получит после двойной дешифрации тот же самый результат, сможет определить, что он нашел ключ.
• существуют 6 пар эквивалентных ключей. Если зашифровать информацию одним ключом из такой пары, другим ключом из этой пары ее можно будет расшифровать.
• 48 ключей, при расширении дающие только 4 различных ключа раундов, называют «возможно слабыми». Каждый из таких ключей раундов используется при шифровании по 4 раза.

С этими недостатками можно справиться с помощью запрета использования проблемных ключей. Помимо этого, если уменьшать число раундов, алгоритм DES подвержен снижению криптостойкости, хотя считается, что есть возможность сокращать число раундов любого многораундового шифра до определенных пределов для достижения оптимального соотношения «скорость шифрования / криптостойкость» [4]. Еще в 1998 году специальный компьютер DES Cracker вскрыл ключ DES всего за 3 дня.Самым безопасным из них является алгоритм шифрования AES, принятый в качестве стандарта шифрования правительством США по результатам конкурса AES [7]. В рамках конкурса AES производился криптоанализ алгоритма Rijndael, лежащего в основе стандарта шифрования AES. Приведем некоторые результаты, которые были учтены при выборе победителя конкурса [1]:

• были проведены атаки на усеченные версии Rijndael, для одной из которых, Square-атаки на состоящую из 6 раундов версию алгоритма, потребовалось 2³²  выбранных пар «открытый текст – шифртекст» и 2⁷²  операций шифрования;
• авторами алгоритма шифрования Twofish было предложено усиление Square-атаки: ее новый вариант вскрывал 6-раундовый Rijndael за 2⁴⁴  операций, а 7-раундовый – за от 2¹⁵⁵  до 2¹⁷²  операций шифрования на таком же количестве пар «открытый текст – шифртекст».

Так как в алгоритме Rijndael выполняется не менее 10 раундов, эксперты признали адекватным запас криптостойкости алгоритма [1]. После конкурса AES попытки вскрытия этого алгоритма участились и усилились. В работе [5] описана атака на 6-раундовую версию алгоритма AES-128, для которой требуется 2³⁹  выбранных открытых текстов, 2⁷¹  шифротекстов с адаптивным выбором и 2⁷¹  операций шифрования. Также была предложена атака на 10-раундовый AES-192. Для реализации этой атаки требуется 2¹²⁵  выбранных открытых текстов на 256 связанных ключах и 2^146.7  операций. В работе [6] сказано, что алгоритм AES подвержен атаке по времени выполнения (timing attack) на платформе графических процессоров CUDA, суть которой состоит в том, что на некоторых аппаратных платформах некоторые операции могут выполняться за различное число тактов процессора. Следовательно, операции выполняются за различное время, и путем высокоточных замеров времени выполнения шифратором определенных операций криптоаналитик может сделать предположения о значении определенных фрагментов секретного ключа. Так как до сих пор никто не предложил действительно работающую атаку на полнораундовый вариант AES, поэтому его можно считать достаточно криптостойким.

Современные ОС, такие как Microsoft Windows 7, поддерживают алгоритм шифрования AES и по умолчанию выбирают именно его. Но в домене могут быть и машины не под управлением этой ОС. На этих машинах могут быть другие принципы выбора алгоритма шифрования, использующегося в Kerberos. Следует выполнить следующие шаги:

• при наличии возможности следует отключить поддержку алгоритма шифрования DES в ОС, не относящихся к Microsoft Windows, и приложениях, использующих аутентификацию по Kerberos;
• убедиться, что в домене нет учетных записей пользователей, у которых включена поддержка алгоритма DES (опция «Use Kerberos DES encryption types for this account» в свойствах доменной учетной записи).

Ниже приведен ряд потенциальных недостатков протокола Kerberos и возможных путей их решения.

• KDC может являться единой точкой отказа (single point of failure). Если KDC недоступен, никто не сможет получить доступ к ресурсам. Поэтому KDC требует избыточности. Также, KDC должен быть способен одновременно обрабатывать большое количество запросов. Поэтому он должен быть масштабируемым. В ОС Microsoft Windows это может быть достигнуто путем увеличения количества контроллеров домена, на которых расположен KDC.
• Секретный ключ временно хранится на рабочей станции пользователя, что может привести к его компрометации. Следует на время хранения секретного ключа на рабочей станции пользователя шифровать его безопасным алгоритмом шифрования (таким как AES) либо же хранить в хешированном виде.
• Сеансовый ключ хранится на рабочей станции пользователя в открытом виде в кэше или таблице ключей, что может привести к его компрометации. Его также следует на время хранения шифровать безопасным алгоритмом шифрования либо же хранить в хешированном виде.
• Kerberos уязвим к подбору паролей, он не сможет узнать, что атакующим производится подбор пароля по словарю. Следует настроить ОС, использующие Kerberos, на задержку между попытками ввода пароля.
• Kerberos не защищает сетевой трафик, если не включено шифрование. Поэтому следует использовать безопасные версии сетевых протоколов: вместо LDAP использовать LDAPS (LDAP over SSL), вместо HTTP использовать HTTPS.
• Kerberos требует, чтобы системные часы на всех клиентах и серверах были синхронизированы. Для того, чтобы на всех клиентах и серверах были синхронизированы системные часы, требуется в локальной сети иметь свой сервер NTP (Network Time Protocol), обеспечивающий централизованное распространение единого времени.

Также, для выявления сетевых атак, приводящих к перехвату сообщений аутентификации протокола Kerberos, на предприятии рекомендуется применять системы SIEM [8].

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

Список литературы:

1. Панасенко С.П. Алгоритмы шифрования. Специальный справочник. – СПб.: БХВ-Петербург, 2009. – 576 с.: ил.
2. Menezec A., van Oorschot P., Vanstone S. Handbook of Applied Cryptography. – Boca Raton, Florida: CRC Press, 1996. – Pp. 256-259.
3. Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си. – Пер. с англ.: М.: Издательство ТРИУМФ, 2002. – 816 с.
4. Брассар Ж. Современная криптология. – Пер. с англ.: М.: Полимед, 1999. – 176 с.
5. Biryukov A. The Boomerang Attack on 5 and 6-round Reduced AES // AES'04 Proceedings of the 4th international conference on Advanced Encryption Standard. – Springer-Verlag Berlin, Heidelberg, 2004. – Pp 11-15.
6. Fomin D. A timing attack on CUDA implementations of an AES-type block cipher // CTCrypr 2015 Preproceedings. Kazan, 2015. – Pp. 288-301.
7. Бутакова Н.Г. Криптографические методы и средства защиты информации [Текст] : Учеб. пособие / Н. Г. Бутакова, Н. В. Федоров. - СПб.: ИЦ "Интермедия", 2017. – 384 с.
8. Бутакова Н.Г. Проблемы интеграции средств сетевого мониторинга информационной безопасности под управлением SIEM // Перспективы развития науки и образования: Сборник научных трудов по материалам Международной научно-практической конференции 30 июня 2017 г. М.: «АР-Консалт», 2017 г. – С. 25-27.