Максимальная защита AD. Active Directory: распространенные виды атак и защита от них

Сергей «grinder» Яремчук (grinder@synack.ru)

Служба каталогов Active Directory обладает многими преимуществами. Это и централизованное управление учетными записями и доступом к ресурсам, и групповые политики, позволяющие развертывать ПО на множестве компьютеров и более гибко производить настройки, аудит объектов и многое другое. Инфраструктура AD - ключевой элемент сетей, построенных на базе Windows. К ее защите следует приложить максимум усилий.

Контроллеры домена содержат все необходимые данные, используемые для аутентификации в домене. В случае их отказа работать не сможет ни один из пользователей. Компрометация учетных данных имеет не менее пагубные последствия: пользователь, обладающий определенными правами, может нанести серьезный вред системе или получить доступ к конфиденциальной информации. Именно поэтому их защите, сохранности и целостности необходимо уделять повышенное внимание. Рекомендуется планировать все мероприятия с самых первых шагов – начиная от физической безопасности сервера, ограничения к нему доступа, определения задач для администраторов и заканчивая планом резервного копирования и восстановления работоспособности контроллера домена или отдельных учетных записей, удаленных случайно или умышленно.
Придется разобрать достаточно много вопросов и произвести не один десяток настроек для того, чтобы служба каталогов и контроллер домена были в безопасности. Каких именно? Читай дальше.

Подбор хэш-функции пароля

В сегодняшних сетях зачастую можно встретить работу нескольких поколений Windows, и администратору в целях совместимости приходится принудительно активировать системные параметры, обозначенные как «не рекомендуемые». Многие дыры живут в Windows еще со времен 95/NT, благополучно перекочевывая из релиза в релиз, и все для того, чтобы системы мирно сосуществовали друг с другом (плюс, чтобы начинающий админ мог поднять сеть за несколько кликов мышки). Хотя нужно признать, что в новых системах, чтобы вернуть совместимость (а значит, получить в подарок весь груз уязвимостей), необходимо выполнить некоторые действия, осознавая, к каким неприятностям это может привести.

Протоколом сетевой аутентификации в NT является NTLM (NT LAN Manager; чуть позже его стали называть NTLMv1). Он изначально поддерживается в сетях Windows 2k/XP/2k3, а после активации соответствующей политики – и в более новых системах. Основой NTLM послужил архаичный протокол аутентификации Microsoft LAN Manager, с которым сохранена совместимость. В итоге, введенный пользователем пароль хранится в двух хэшах - LM и NT. При этом NT-хэш является, по сути, MD4-хэшем пароля, поддерживает все символы Unicode и длину пароля вплоть до 256 символов. С LM, которому уже более 20 лет, ситуация куда прозаичнее. У него два больших недостатка. Первый - пароль разбивается на две части, каждая по 7 символов, которые и шифруются по отдельности (максимальная длина пароля равна 14 символов). Если символов в пароле меньше, оставшееся место дополняется нулями. Нужно ли говорить, что намного легче подобрать 2 хэша по 7 знаков, чем один на 14? Тем более, угадав часть пароля, нередко можно сделать вывод по остальным символам. Второй недостаток – LM-хэш регистронезависим, так как все символы перед шифрованием приводятся к верхнему регистру. То есть, password и PASSWORD для LM - один и тот же пароль. Это еще больше упрощает подбор. При аутентификации вместо самих хэшей передаются хэши хэшей, и что самое интересное, по умолчанию при ответе по сети передаются оба варианта (LM и NT).

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

Некоторые клиентские программы могут без участия пользователя произвести NTLM аутентификацию при условии, что ее поддерживает сервер. Поэтому хэш можно получить даже при помощи telnet, просто подключившись к нужному порту. Программы, позволяющие подобрать пароли, имеются в свободном доступе - John the Ripper (www.openwall.com/john), LCP (www.lcpsoft.com/russian) и L0phtCrack LC5. Последнюю в открытом доступе найти нельзя; после приобретения Astake компанией Symantec она исчезла с сайта, но достаточно ввести в гугле «LC5 download», и ты найдешь нужный файл. Например, LCP может сама захватывать передаваемые по сети пакеты, или импортировать учетные записи с локального и удаленного компьютера, выполнять импорт файлов SAM, Sniff и созданных другими утилитами (LC, LCS и PwDump). Реализовано три типа атак для подбора паролей по хэшам: атака по словарю, гибридная атака по словарю и brute force.

Именно по этим причинам на смену протоколу сетевой аутентификации NTLMv1 пришел NTLMv2. Новая реализация во многом похожа на своего предшественника, но хэш образует более устойчивый к взлому алгоритм HMAC-MD5, а при запросе используется 128-разрядный ключ. Чтобы сделать невозможными некоторые атаки, где проигрываются ранее записанные учетные данные, в NTLMv2 введена метка времени. В доменной среде NTLMv2 применяется вместо Kerberos в ситуациях: аутентификация по IP-адресу, в рабочей группе, если клиент не принадлежит домену или текущему лесу (в том случае если не установлено доверительное отношение), и при невозможности использования Kerberos (например, блокировка firewall). Есть еще варианты, но о них чуть дальше.

Запретить хранение LM-хэшей в Windows 2k/XP/2k3 довольно просто: для этого необходимо добавить в реестр параметр NoLMHash типа DWORD в раздел HKLM\SYSTEM\CurrentControlSet\Control\Lsa со значением 1 (подробнее о запрещении хранения LM-хэшей можно прочитать в статье KB299656). Кстати, если длина пароля более 15 символов, то сохраненный LM-хэш нельзя использовать для аутентификации, а значит, он непригоден и для взлома.

Параметр типа DWORD LMCompatibilityLevel в этом же разделе позволяет разрешить LM-аутентификацию только по запросу сервера или вообще запретить. Здесь указывается одно из 6 значений:

0 (по умолчанию) - использовать LM- и NT-ответы, NTLMv2 отключен;
1 - использовать при необходимости NTLMv2;
2 - только NT-ответ;
3 - только NTLMv2;
4 - отказывать контроллеру домена в LM-аутентификации;
5 - отказывать контроллеру домена в LM- и NT-аутентификации, только NTLMv2.

В доменной среде проще воспользоваться возможностями групповой политики (Group Policy Object), выбрав в редакторе GPO пункт «Параметры безопасности» по маршруту «Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики» и активировав политику «Network security: Do not store LAN Manager hash value on next password change» (не хранить хэш-значения LAN Manager при следующей смене пароля). Начиная с Vista, она действует по умолчанию. Политика «Network Security: LAN Manager authentication level» определяет настройки NTLM; установив ее в «NTLM2 responses only», можно запретить использование LM и NTLMv1.

В Vista и выше LM-хэши и NTLMv1 также поддерживаются, параметр LmCompatibilityLevel установлен в 3, – то есть, по умолчанию для недоменной аутентификации используется NTLMv2, а политики запрещают их использование. Использование NTLM в доменной среде определяет политика «Network Security: Restrict NTLM: NTLM authentication for this domain». По умолчанию в Win2k8R2 она не установлена. Если в сети нет клиентов с устаревшими системами, ее можно переключить в «Deny all», полностью запретив использование этого протокола. Как вариант, при помощи этого параметра можно запретить NTLM при доступе к серверу домена или учетной записи.

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

Теперь, когда ты все знаешь об особенностях аутентификации пользователя в AD, разберем, как можно усложнить жизнь потенциальному взломщику. Некоторые советы тебе, возможно, покажутся банальными, но опыт показывает, что придерживаются их далеко не все. В первую очередь следует изменить установленный по умолчанию логин администратора домена: «Конфигурация компьютера -> Параметры Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности -> Учетные записи: Переименование учетной записи администратора» или во вкладке «Active Directory -> Пользователи и компьютеры». То же самое проделываем и с гостевой учетной записью (если таковая используется, по умолчанию она отключена). После этого не забываем отслеживать попытки использования этих логинов в программах аудита и, обнаружив неладное, бьем тревогу. Нападающему в этом случае придется пройти полный путь, то есть – подбирать и логин, и пароль. Кроме того, у админа появится больше информации для блокировки таких попыток. Пароль должен быть достаточно сложным, сочетать в себе буквы (в разных регистрах), цифры, а также спецсимволы.

Часто нападающий при поиске объекта для атаки ориентируется на описание учетной записи. Поэтому следует удалить или изменить описание админских учеток, чтобы усложнить ему поиск. Взамен – создаем несколько ложных учетных записей с описанием «Администратор», но без каких-либо прав и контролируем попытки доступа к ним.
Кардинальным решением является отключение учетной записи администратора. Это можно сделать при помощи GPO-политики «Учетные записи: Состояние учетной записи администратора»; тем более что она автоматически включается при запуске системы в безопасном режиме. Учитывая важность учетной записи администратора, ее нужно использовать только при первоначальных настройках. Хорошим вариантом будет создание двух дополнительных учеток: для выполнения задач администрирования и для повседневной работы (веб-серфинг, почта, аська, ведение документации и т.д.)

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

Часто почтовый адрес пользователя совпадает с его логином – и может быть использован при попытке взлома. Злоумышленнику собрать базу таких логинов очень просто. Достаточно произвести DHA-атаку (Directory Harvest Attack) при помощи специальной программы, генерирующей набор e-mail адресов и отправляющей на них проверочные сообщения. Если SMTP-сервер подтверждает прием сообщения для такого адреса (250 Recipient OK), то он считается действующим. Многие почтовые серверы имеют функции, обеспечивающие защиту от DNA-атаки. Например, в Exchange Server есть параметр «SMTP Tarpitting» для установки случайного времени задержки при ответе на команду RCPT TO во время SMTP-запроса. Это затрудняет сбор действующих адресов с домена.

Проблемы Kerberos

Несмотря на то, что на сегодня Kerberos признан самый безопасным механизмом аутентификации, его реализации далеко не безгрешны. Так, версия Kerberos в Win2k позволяла устроить UDP-шторм в сети, поскольку сервер отвечал на любые UDP-пакеты, направленные в 464 порт (Kerberos). Кроме этого, возможно было вызвать переполнение стека при некоторых запросах.

Чтобы системы от Win2k3 и ниже для пересылки пакетов Kerberos вместо UDP использовали TCP, следует установить параметр реестра MaxPacketSize в значение 1 (DWORD). Он находится в разделе HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters.

Еще одна проблема связана с тем, что если пользователь является членом нескольких групп, или атрибут sidHistory, показывающий миграцию пользователя в домене, имеет большой размер, то билет (Ticket Granting Ticket, TGT) может превысить установленный по умолчанию лимит в 12000 бит. Попытка аутентификации при помощи Kerberos закончится неудачей, и вместо него будет задействован NTLM. Причем, последняя ошибка характерна не только для Win2k3 и предыдущих версий, как это описано на странице support.microsoft.com/kb/327825, но появляется при некоторых условиях и в Win2k8. Недостаточный и фиксированный размер билета дает возможность проведения DOS-атаки, результатом которой является отказ в регистрации пользователя с учетными правами администратора. Правда, для такой атаки необходимо иметь права по управлению группами.
Чтобы избежать подобной ситуации, увеличь размер токена, установив максимальное значение 65535 для параметра реестра MaxTokenSize (REG_DWORD), или используй формулу для расчета, описанную в бюллетене KB327825. Также следует удалить sidHistory, чтобы освободить место в билете. Это можно проделать при помощи VBS скрипта, взятого с support.microsoft.com/kb/295758.

В Kerberos версии 5.0, на основе которого построен Kerberos в Windows от 2k, для получения билета используется механизм предварительной аутентификации (pre-authentication). В ходе него клиент отсылает на сервер: логин, домен и отметку времени, зашифрованные посредством секретного ключа, который создан на основе пароля. Знание метки времени позволяет программе KerbCrack (Kerberos Password Crack, ntsecurity.nu/toolbox/kerbcrack) расшифровать данные для входа. Сам KerbCrack может запускаться во всех ОС Windows на ядре NT, включая Vista, и состоит из двух программ: снифера и расшифровщика.

В реализациях Kerberos до Win2k3 включительно для шифрования используются алгоритмы СРС-32, MD4, MD5 и DES. Начиная с Vista, в этом списке появился более надежный AES 128/256. Это сделало применение KerbCrack неэффективным. Если для аутентификации применяются смарт-карты, то в сеансе предварительной аутентификации для шифрования используется закрытый ключ пользователя. Поэтому, чтобы избежать перехвата, такой метод регистрации предпочтителен. Как вариант, можно зашифровать трафик при помощи VPN, например, IPsec. И, наконец, использовав политику «Network Security: Configure encryption types allowed for Kerberos», можно жестко установить используемые Kerberos алгоритмы шифрования и запретить устаревший DES.

Следует добавить, что в Win2k8 появился новый параметр «Allow Cryptography algorithms compatible with Windows NT 4.0». По умолчанию он не установлен – «Not Configured», а значит, все клиенты, не поддерживающие новые и более защищенные алгоритмы, не смогут подсоединиться к домену. Если при подключении к Win2k8-домену появляются ошибки, описанные в KB942564 (go.microsoft.com/fwlink/?Linkid=104751), то включи этот параметр. Правда, цена такого шага – снижение безопасности. В крайнем случае, в Win2k8 в свойствах отдельной учетной записи, во вкладке Account, можно разрешить использование DES/AES и отключить предварительную аутентификацию. Здесь же находится параметр «Smart Card Is Required for Interactive Logon», установка которого требует использования смарт-карты при входе. По умолчанию эта политика отключена.

Заключение

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

Порты Active Directory

Active Directory для взаимодействия с клиентскими системами использует следующие порты:

88 (UDP и TCP) - Kerberos аутентификация;
53 (UDP и TCP) – DNS запрос;
135 (UDP и TCP) – взаимодействие между КД и КД и клиентами;
138 (UDP) и 139 (TCP), 445 (UDP и TCP) – служба репликации файлов, или 135 и > 1024 в DFS Replication;
389 (UDP и TCP)/ 636 (UDP и TCP) – LDAP/LDAP-SSL запросы;
464 (UDP и TCP) – установка пароля Kerberos;
3268 и 3269 (TCP) - доступ к глобальному каталогу (Global Catalog, GC).

Тонкая настройка Kerberos

В большинстве случаев параметры настройки Kerberos, заданные по умолчанию, являются оптимальными, но, используя политики безопасности домена, их можно несколько ужесточить, еще более обезопасив свою сеть. Все настройки, относящиеся к Kerberos, находятся в пункте «Domain Security Policy -> Account Policies» («Политика безопасности домена -> Политики учетных записей»).

INFO

По умолчанию в системах от Vista и выше для недоменной аутентификации используется NTLMv2.
Чтобы NTLMv2 могли использовать клиенты Win98, на них следует установить специальный Directory Service Client.
При правильных настройках и постоянном аудите происходящих событий риск нарушения работоспособности AD можно свести к минимуму.

WWW

Статья «NTLM’s time has passed» на blogs.technet.com/authentication.
Программа John the Ripper - www.openwall.com/john.
Программа LCP - www.lcpsoft.com/russian.

Веб-интерфейс к AD, написанный на PHP: phpadview.web.envionsoftware.com.

WARNING

Многие дыры живут в Windows еще со времен 95/NT, благополучно перекочевывая из релиза в релиз, и все для того, чтобы системы мирно сосуществовали друг с другом.

Содержание