DMZ - Active Directory - (Философия)

Question

Я искал повсюду и нашел много разных ответов на мой вопрос без реального прямого Да или Нет.

Я сделал очень грубую сетевую диаграмму, чтобы объяснить, что я хотел бы настроить. Я настроил DMZ и внутреннюю локальную сеть. Со временем я буду настраивать дополнительные сервисы, которые будут выходить в Интернет. Итак, я прочитал, что наличие RODC в DMZ - это хорошая идея, но я также читал, что это ужасная идея. Кроме того, наличие дочернего домена в DMZ - это хорошая идея, а также плохая идея.

Я не новичок в том, как настроить эти серверы и правила брандмауэра. В чем моя проблема, так это в философии установок. У меня есть межсетевой экран периметра и внутренний брандмауэр, все контролирующие доступ. Является ли способ, которым я сделал Network Diagram, хорошей практикой или ужасной практикой?

Кроме того, я хотел бы установить «одностороннее» доверие между родительским доменом и дочерним доменом.

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

Некоторая информация о сети:

DMZ: 192.168.10.0/24 - дочерний домен: DMZ.Contoso.com

LAN: 192.168.50.0/24 - родительский домен: Contoso.com

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

Благодарю вас

Answer 1

Ну, я сделал небольшое изменение в дизайне. Я не расширил Active Directory в DMZ, как показано. Вместо этого я создал новый лес внутри DMZ и создал одностороннее доверие между внутренним лесом и лесом DMZ. Таким образом, даже если моя DMZ скомпрометирована, это не будет иметь значения, поскольку данные, находящиеся в DMZ, такие как любое потенциальное имя пользователя и пароли, не могут быть применены к внутренней локальной сети. Имейте в виду, это немного больше административной работы, но ничего, что не может быть обработано.

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

Теперь, когда говорится, что ни одна система не является на 100% доказательством взлома, если кто-то достаточно решителен, он попадет и разрушит хаос.

Исследование продолжается для лучших практик.

Спасибо всем за ваш отзыв

Answer 2

Amigo, мне может не хватать опыта администрирования продуктов Microsoft. Тем не менее, учитывая мой обширный опыт работы в области администрирования UNIX и Linux, я считаю, что вам следует рассмотреть наихудшие сценарии использования исторически уязвимого программного обеспечения - как доказывает собственный контроллер домена Microsoft.

Я чувствую себя гораздо менее нерешительно при развертывании BSD (Open, Free или Net) с использованием Samba в качестве контроллера домена - особенно в Интернете, читайте только одно на диаграмме, которая находится в DMZ.

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

Ни один брандмауэр 3 или 4 уровня (проклятый почти каждому существующему ...) в мире не может защитить вас от атак на уровне 7 против действительных и разрешенных портов и служб. Поэтому, если бы это был я, я бы поместил все серверы в демилитаризованную зону, оставил бы доступным для записи контроллер домена вне публичной сети и с частной внутренней сетью для межсерверной связи. Я бы заменил MS Windows на OpenBSD с Samba и DJBDNS - больше ничего. Я бы настроил свои маршрутизаторы для явного отбрасывания всего входящего трафика, за исключением каналов, которые я явно определяю. Я хотел бы проверить мою конфигурацию брандмауэра. И если бы мне пришлось запускать Windows на каком-либо из серверов, я бы нашел быстрый способ полностью стереть машины и восстановить их в рабочее, функциональное состояние с чем-то вроде G4U. Затем мне также пришлось бы исследовать и установить средства, позволяющие правильно обнаруживать серверные компромиссы и атаки. Лучше, если брандмауэр автоматически узнал атакующие IP-адреса и создал соответствующие правила DROP с таких адресов - но не навсегда, только на день или два.

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

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

Надеюсь, это поможет!

F.