Домены Securing Active Directory в потенциально враждебной сети

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

• Имейте отдельную привилегированную учетную запись для управления Вашими веб-машинами направления.

• Имейте трудный брандмауэр сетевого уровня на своих веб-машинах направления, если это возможно.

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

• Если Контроллер домена поставлен под угрозу... строго говоря, Ваш Домен не стал и должен быть восстановлен. Более практически это зависит от типа компромисса и является чем-то, что необходимо было бы оценить на индивидуальной основе. Я наследовал два домена, которые были строго говоря "поставлены под угрозу", я восстановил один и восстановил второе. Существует много факторов для рассмотрения.

Вот общие методы, которые я использую. Надо надеяться, я могу добавить много к ним:

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

• Контроллеры домена не выполняют внешне доступных сервисов.

• Диапазоны портов RPC ограничиваются на всех доменных контроллерах/участниках известной группой портов:

  1. Средства администрирования-> Component Services-> Component Services-> Компьютеры
  2. Мой Компьютер-> Свойства-> Протоколы По умолчанию-> TCP/IP С установлением соединения-> Свойства
  3. Добавить
  4. Установите диапазон портов (что-то как 6051-6071). Чем больше Ваша сеть и больше Вы используете RPC, тем шире располагаются, Вам будет нужно. Для сети 25-30 машин Windows я нашел, что 20 портов более чем достаточно.
  5. Набор и присвоение Диапазона портов и выделение динамического порта По умолчанию к "интернет-Диапазону"
  6. Хорошо
  7. Перезагрузка

• Предоставьте доменным участникам только следующий доступ к Контроллеру домена (и в сетевом брандмауэре, брандмауэре хоста Контроллера домена, и в брандмауэр хоста Доменного участника - использует Групповую политику для осуществления этого):

  • Порт TCP/UDP 53 (DNS)
  • Порт TCP/UDP 88 (Kerberos)
  • Порт UDP 123 (NTP)
  • Порт TCP/UDP 135 (Картопостроитель Конечной точки RPC)
  • Порт TCP/UDP 137 (NetBIOS)
  • Порт UDP 138 (NetBIOS)
  • Порт TCP 139 (NetBIOS)
  • Порт TCP/UDP 389 (LDAP)
  • Порт TCP/UDP 445 (SMB по IP)
  • Порт TCP 3268 (LDAP Глобальный Каталог)
  • Порт TCP/UDP 6051-6071 (RPC - заменяют любым диапазоном, который Вы выбрали выше),

• Установите политику IPSec, таким образом, весь Контроллер домена к трафику Контроллера домена шифруется по проводу

• Используйте Групповую политику для укрепления правил сетевого брандмауэра в брандмауэре хоста. Конкретно:

  • Ограничьте Удаленный рабочий стол своими администраторскими рабочими станциями/сетью
  • Ограничьте SNMP своим администратором и контролирующими рабочими станциями/сетью
  • Ограничьте исходящий системный журнал (я использую событие к системному журналу) к Вашему серверу входа
  • Ограничьте исходящий SMTP своим почтовым сервером
  • Стандарт "ограничивает все в / только, что сервер требует" тактики

• Настройте все сетевые службы для выполнения как Пользователи Active Directory (приложения IIS, запущенные при пользователях, назвали "svc-servicename"). Эти пользователи присвоены единственной группе с nerfed полномочиями и удалены из группы Пользователей домена.

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

• Внешне стоящие серверы находятся в отдельном домене, чем машины HQ/Office. У меня есть одностороннее доверие (демилитаризованная зона доверяет HQ) упростить некоторые логины, но смотрю на постепенное выведение этого.

Документ лучших практик Microsoft, который я прочитал когда-то предположенный, что Ваши стоящие с Интернетом серверы (сеть, электронная почта, и т.д.) должны или быть автономными машинами или быть в отдельном лесу Active Directory от Вашего корпоративного леса. Этот отдельный лес должен существовать полностью в демилитаризованной зоне, в то время как Ваш корпоративный AD лес должен существовать полностью в самых строгих границах Вашего корпоративного брандмауэра. Гораздо меньшему количеству пользователей нужен доступ к стоящим с Интернетом серверам, чем к регулярным корпоративным вычислительным ресурсам, таким образом настраивание системы таким образом не должно налагать значительные дополнительные административные издержки с точки зрения пользовательской поддержки. Просто необходимо помнить отдельные имена пользователей и пароли для каждого домена.

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

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

Когда я сначала добрался здесь, я был удивлен, что сеть Windows, которую это открывает, могла выжить вообще. Но это сделало. Да, Тюрьма была королевской болью для выкорчевывания. Да, у нас действительно был случайный взломанный сервер (с интернет-стороны, не стороны WLAN). В целом, сумма злого изделия, которое мы видели на WLAN, больше интересуется отправкой большого объема электронной почты, чем это находится в сканировании всего локального для машины для собирания червей ее пути вокруг.

У нас действительно есть подлинный барьер между WLAN и чем-либо интересным, которое помогает.

Кроме того, мы навсегда собираемся в журналы входа в систему WLAN видеть, кто был включен, какой IP, когда RIAA отправляет нам уведомление преступника за torrenter.

Я рекомендовал бы читать Руководство Лучшей практики для Обеспечения Установок Active Directory.

Вещи, что я думаю, важны в небезопасной сети:

• IPSec для подлинного трафика
• Используйте двухфакторную аутентификацию (смарт-карта, или ответ проблемы является дешевым),
• Отключите NTLM

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

Общее правило состоит в том, что единственной вещью, которая идет на DC, является сам Active Directory. Это не всегда достижимо, конечно, но это - все о сокращении количества сервисов, которые потенциально подвергаются.

Вам необходимо понимать атаки типа «передача хэша» (PtH) и «передача билета» (PtT), поскольку они являются основными средствами, с помощью которых злоумышленники распространяются по всему Windows. сеть. У Microsoft есть руководство по PtH, но оно может быть немного сложным, если вы еще не знакомы с проблемами безопасности: https://www.microsoft.com/en-us/download/details.aspx?id=36036

Лучше всего использовать дизайн Microsoft «красный лес». Красный лес - это отдельный лес с односторонним доверием, в котором размещаются учетные записи администратора вашего домена. Это требует дополнительных усилий и серверов, но вы можете получить 95% преимуществ и без этого, если будете осторожны.

Любая учетная запись с привилегиями в AD (администраторы домена, служба поддержки и т. Д.) Никогда не должна входить на какой-либо обычный рядовой сервер или рабочая станция. То есть, вы должны установить права Deny Logon, чтобы включить администраторов домена и другие привилегированные группы на обычных машинах.

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

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

Администратор домена не должен НИКОГДА входить в систему DMZ или подключенный к Интернету компьютер. Вы не должны даже RDP от одного. У вас должны быть выделенные рабочие станции для этих учетных записей, и ваши обычные учетные записи рабочих станций не должны иметь возможность входить в административные рабочие станции AD. Не должно быть никаких учетных записей, которые могут входить как на обычные рабочие станции, так и на рабочие станции администратора AD. Это предотвращает кражу этих высокопривилегированных учетных данных, когда злоумышленник получает права администратора / системы на одной рабочей станции и впоследствии распространяется на другие (обычно путем кражи учетных данных, когда администратор рабочей станции входит в систему).

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

Восстановление AD после компрометации возможно, но должно быть выполнено абсолютно правильно --- и, очевидно, там будет некоторое время простоя, пока домен восстанавливается и дезинфицируется. По нашим оценкам, восстановление после скомпрометированного контроллера домена было за несколько дней до внедрения Red Forest; это меньше 12 часов с красным лесом.

Обратите внимание, что каждая мера безопасности - это одна часть общего решения, и вам нужны все остальные. Эти предложения относятся к защите AD. Вам по-прежнему необходимо сегментировать вашу сеть и иметь соответствующие ограничения брандмауэра / ACL. Вам по-прежнему необходимо должным образом защитить свои учетные записи пользователей с помощью смарт-карт (настоятельно рекомендуется) или надежных политик паролей. Вам по-прежнему нужны обнаружение вторжений, антивирус, хороший внешний брандмауэр и веб-прокси.