Active Directory - одна из лучших функций Windows Server, но также и большая блестящая цель. В случае компрометации он предоставляет злоумышленнику вашу сеть Windows.
Какие шаги необходимо предпринять в среде с внешними серверами Windows (в моем случае - веб-серверами) для защиты Active Directory от атак? Как уменьшить потенциальный ущерб в случае взлома члена домена? Наконец, есть ли способ уменьшить потенциальный ущерб в случае взлома контроллера домена?
Я ищу информацию, относящуюся конкретно к Active Directory (2003 и 2008). Должны быть даны универсальные передовые методы (чтение журналов, безопасность паролей администратора и т. Д.).
Не входите в систему ни на одном компьютере в вашей сети с учетной записью администратора домена или с аналогичной учетной записью, за исключением ваших контроллеров домена. Таким образом, скомпрометированная система не сможет украсть ваши учетные данные.
Иметь отдельную привилегированную учетную запись для управления компьютерами с выходом в Интернет.
Если возможно, установите надежный брандмауэр сетевого уровня на свои компьютеры с выходом в Интернет.
Если возможно, разместите свои компьютеры с выходом в Интернет в демилитаризованной зоне, которая в основном представляет собой подсеть с ограниченным подключением к остальной части вашей внутренней сети.
Если контроллер домена скомпрометирован ... строго говоря, ваш домен ушел и его нужно восстановить. На практике это зависит от типа компромисса, и вам придется оценивать это в каждом конкретном случае. Я унаследовал два домена, которые, строго говоря, были "взломаны", я восстановил один и восстановил второй. Следует учитывать множество факторов.
Вот общие методы, которые я использую. Надеюсь, я могу многое добавить к ним:
Контроллеры домена находятся в собственном сегменте сети. Весь трафик к контроллерам домена или от них должен проходить через сетевой брандмауэр.
На контроллерах домена нет доступных извне служб.
Диапазоны портов RPC ограничены на всех контроллерах / членах домена известной группой портов:
Разрешить членам домена только следующий доступ к контроллеру домена (как в сетевом брандмауэре, так и в брандмауэре хоста контроллера домена и брандмауэре хоста члена домена - используйте групповую политику для обеспечения этого):
Установите политику IPSec, чтобы весь трафик контроллера домена к контроллеру домена шифровался по сети.
Используйте групповую политику для усиления правил сетевого брандмауэра на брандмауэре хоста. В частности:
Настройте все сетевые службы для запуска от имени пользователей Active Directory (приложения IIS запускаются под пользователями с именем «svc-servicename»). Эти пользователи назначаются в одну группу с ослабленными привилегиями и удаляются из группы «Пользователи домена».
Переименуйте учетную запись администратора на что-нибудь другое, добавьте «Администратор» в качестве отключенной гостевой учетной записи (легко преодолеть, но это может блокировать некоторые глупые сценарии).
Серверы, обращенные извне, находятся в отдельном домене, чем машины штаб-квартиры / офиса. У меня есть одностороннее доверие (DMZ доверяет HQ), чтобы упростить некоторые входы в систему, но я собираюсь отказаться от этого.
Это несколько противоположная точка зрения. Я работаю в вузе с сегментом беспроводной локальной сети, к которому студенты (и где-то от одного до трех устройств в своих сумках) могут подключиться. Он находится внутри нашего межсетевого экрана, граничащего с интернетом, но все еще в некоторой степени защищен брандмауэром из-за сочных качеств большей сети. Однако есть некоторые ограничения.
Чтобы студенты могли печатать со своих ноутбуков, мы должны разрешить вход в домен, что, в свою очередь, требует видимости для DC. То же самое и с общими сетевыми ресурсами. Более того, студенческие ноутбуки не являются доменом, и у нас нет никаких средств контроля над тем, что на них установлено.
Когда я впервые приехал сюда, я был удивлен, что такая открытая сеть Windows может выжить вообще. Но это случилось. Да, Сламмер было настоящей головной болью, которую нужно искоренить. Да, время от времени у нас были взломанные серверы (со стороны Интернета, а не со стороны WLAN). В общем, количество вредоносного ПО, которое мы видели в WLAN, больше заинтересовано в отправке больших объемов электронной почты, чем в сканировании всего локального для машины, чтобы пробираться сквозь нее.
У нас есть барьер аутентификации между WLAN и всем интересным, что помогает.
Кроме того, мы всегда будем обращаться к журналам входа в WLAN, чтобы узнать, кто на каком IP был, когда RIAA отправляет нам уведомление о нарушении для торрентера.
В одном из передовых практик Microsoft, который я однажды прочитал, предлагалось, чтобы ваши серверы с выходом в Интернет (Интернет, электронная почта и т. Д.) Были либо автономными компьютерами, либо находились в отдельном лесу Active Directory от вашего корпоративного леса. Этот отдельный лес должен полностью находиться в демилитаризованной зоне, в то время как ваш корпоративный лес AD должен существовать полностью в пределах строгих границ корпоративного брандмауэра. Доступ к серверам с выходом в Интернет требуется гораздо меньшему количеству пользователей, чем к обычным корпоративным вычислительным ресурсам, поэтому настройка системы таким образом не должна вызывать значительных дополнительных административных издержек с точки зрения поддержки пользователей. Вам просто нужно запомнить свои отдельные имена пользователей и пароли для каждого домена.
Я бы рекомендовал прочитать Руководство по лучшей практике для защиты установок Active Directory.
Вещи, которые я считаю важными в ненадежной сети:
Первые два предложения требуют, чтобы вы установили службу PKI. Внедрение PKI может быть настоящей головной болью, но оно может дать вам много действительно интересных возможностей и позволит вам эффективно и безопасно работать в ненадежной среде.
Общее правило заключается в том, что единственное, что работает с контроллером домена, - это сам Active Directory. Конечно, это не всегда достижимо, но все дело в сокращении количества потенциально открытых сервисов.
Вам нужно будет понять метод передачи хеш-кода (PtH) и атаки типа Pass-the-ticket (PtT), поскольку они являются основным средством распространения злоумышленников по сети Windows. У Microsoft есть руководство по PtH, но оно может быть немного сложным, если вы еще не знакомы с проблемами безопасности: https://www.microsoft.com/en-us/download/details.aspx?id=36036
Лучший способ - использовать дизайн Microsoft Red Forest. Красный лес - это отдельный лес с односторонним доверием, в котором размещаются учетные записи администратора вашего домена. Это требует дополнительных усилий и серверов, но вы можете получить 95% преимуществ и без этого, если будете осторожны.
Любая учетная запись с привилегиями в AD (администраторы домена, служба поддержки и т. Д.) Никогда не должна входить на какой-либо обычный рядовой сервер или рабочую станцию. То есть, вы должны установить права Deny Logon, чтобы включить администраторов домена и другие привилегированные группы на обычных машинах-членах.
В общем, все действия администратора должны происходить в системах, которые не имеют доступа к Интернету и имеют ограниченное IP-соединение с машинами, которые имеют.
Очевидно, вы можете ограничить администраторов домена таким образом, только если у вас есть отдельные учетные записи для администрирования сервера и рабочей станции. У вас также должны быть отдельные непривилегированные учетные записи для Интернета / электронной почты. Такое разделение ролей - один из ключевых аспектов защиты сети.
Администратор домена должен НИКОГДА войдите в систему DMZ или подключенный к Интернету компьютер. Вы не должны даже RDP от одного. У вас должны быть выделенные рабочие станции для этих учетных записей, и ваши обычные учетные записи рабочих станций не должны иметь возможность входить в рабочие станции администратора AD. Не должно быть никаких учетных записей, которые могут входить как на обычные рабочие станции, так и на рабочие станции администратора AD. Это предотвращает кражу этих высокопривилегированных учетных данных, когда злоумышленник получает права администратора / системы на одной рабочей станции и впоследствии распространяется на другие (обычно путем кражи учетных данных, когда администратор рабочей станции входит в систему).
Аналогичным образом должны быть выделенные учетные записи для машин DMZ, и ни одна учетная запись не должна иметь доступ как к DMZ, так и к внутренним активам. Также можно настроить отдельный домен DMZ (с доверием к внутреннему домену или без него).
Восстановление AD после компрометации возможно, но должно быть сделано абсолютно правильно--- и, очевидно, будет некоторое время простоя, пока домен восстанавливается и дезинфицируется. По нашим оценкам, восстановление после скомпрометированного DC произошло за несколько дней до внедрения Red Forest; это меньше 12 часов с красным лесом.
Обратите внимание, что каждая мера безопасности является частью общего решения, а все остальное вам понадобится. Эти предложения относятся к защите AD. Вам по-прежнему необходимо сегментировать вашу сеть и иметь соответствующие ограничения брандмауэра / ACL. Вам по-прежнему необходимо правильно защитить свои учетные записи с помощью смарт-карт (настоятельно рекомендуется) или надежных политик паролей. Вам по-прежнему нужны обнаружение вторжений, антивирус, хороший внешний брандмауэр и веб-прокси.