Назад | Перейти на главную страницу

Можно ли использовать брандмауэр Windows для контроллера домена с общедоступным IP-адресом?

В настоящее время у меня есть несколько выделенных веб-серверов Windows, которые размещены в разных регионах. До сих пор я управлял ими без Active Directory, но мне кажется, что это добавляет много ненужных административных накладных расходов и ограничений.

Теперь мне интересно, как должны быть защищены DC. У меня нет собственного центра обработки данных, но я мог бы арендовать еще два выделенных сервера и использовать их в качестве контроллеров домена. Я знаю, что в идеале DC следует размещать за выделенным межсетевым экраном, но это сделало бы аренду DC намного дороже.

Можно ли использовать брандмауэр Windows на контроллерах домена вместо отдельного брандмауэра? Возможно, это решение не из учебника, но похоже, что все должно быть в безопасности, если я ограничу доступ к входящим портам DC IP-адресами моих собственных веб-серверов. В конце концов, это то же самое, что я сделал бы с отдельным брандмауэром.

Когда я впервые прочитал вопрос, я действительно был обеспокоен тем, чтобы вообще предоставить DC публичный IP. Но, подумав об этом, я мог бы подумать об этом, ЕСЛИ DC были не я был членом моего большого леса AD, и единственными машинами в домене были веб-серверы.

Это по-прежнему позволит мне управлять своими веб-серверами с помощью групповой политики и общей проверки подлинности с одной дополнительной учетной записью AD, которую я могу назначить себе, не подвергая мои настоящие внутренние контроллеры домена большой плохой сети. По сути, вы настраиваете AD только для DMZ.

Однако я все еще вижу некоторые проблемы в этом подходе:

  1. AD тесно связан с DNS. Вам нужно хорошо подумать об управлении записями DNS для ваших веб-серверов в сочетании с AD.
  2. Пока брандмауэр Windows адекватный (едва) для этого с точки зрения несанкционированного доступа, это не исключает проверки и отказа в обслуживании с точки зрения сопротивления. Было бы тривиально нарушить работу ваших веб-сайтов, направив DoS-атаку на ваш центральный контроллер домена - может быть, не испортить или отключить, но, по крайней мере, разрушить.

Я не рекомендую это делать, поскольку брандмауэр сам по себе действительно прост.

Наличие AD только для вашего веб-приложения не более небезопасно, чем наличие его с базовой аутентификацией, но проверьте там какой-нибудь совет (даже если он помечен для 2008 года): Доменные службы Active Directory в сети периметра (Windows Server 2008)

Брандмауэр Windows - это псевдо-состояние для UDP, без сохранения состояния для ICMP и с сохранением состояния для Ipv4, Ipv6 (для фильтрации трафика, для проверки я не нашел ни одного документа, но если он есть, он действительно ограничен).

Аппаратное устройство обычно отслеживает состояние.

Состояние:

В вычислениях межсетевой экран с отслеживанием состояния (любой межсетевой экран, который выполняет проверку пакетов с отслеживанием состояния (SPI) или проверку с учетом состояния) является межсетевым экраном, который отслеживает состояние сетевых подключений (таких как потоки TCP, связь UDP), проходящих через него. Брандмауэр запрограммирован так, чтобы различать допустимые пакеты для разных типов соединений. Брандмауэр разрешит только пакеты, соответствующие известному активному соединению; другие будут отклонены.

Проверка с отслеживанием состояния, также называемая динамической фильтрацией пакетов, - это функция безопасности, часто включенная в бизнес-сети. Компания Check Point Software представила инспекцию с отслеживанием состояния при использовании FireWall-1 в 1994 году.1[2] https://en.wikipedia.org/wiki/Stateful_firewall

Без гражданства:

Межсетевые экраны без отслеживания состояния отслеживают сетевой трафик и ограничивают или блокируют пакеты на основе адресов источника и назначения или других статических значений. Они не «осведомлены» о моделях трафика или потоках данных. Брандмауэр без сохранения состояния использует простые наборы правил, которые не учитывают возможность того, что пакет может быть получен брандмауэром, «притворяющимся» тем, о чем вы просили. - Смотрите больше на: http://www.inetdaemon.com/tutorials/information_security/devices/firewalls/stateful_vs_stateless_firewalls.shtml#sthash.iDNnjqWC.dpuf

Из TechNet:

Брандмауэр Windows обеспечивает фильтрацию трафика TCP / IP (IPv4 и IPv6) с отслеживанием состояния, который использует транспортный протокол TCP. Он также обеспечивает фильтрацию трафика TCP / IP с «псевдосостояниями», использующего транспортный протокол UDP. Трафик ICMP не фильтруется с сохранением состояния; скорее, трафик ICMP разрешен или заблокирован на основе настроек брандмауэра Windows (например, вы можете явно разрешить или запретить входящие эхо-запросы или исходящие сообщения о недоступности адресата, настроив параметры брандмауэра Windows). Поскольку брандмауэр Windows напрямую привязан к архитектуре TCP / IP Windows, он не обеспечивает никакой фильтрации протоколов, отличных от TCP / IP, таких как IPX / SPX или AppleTalk.

За исключением некоторого трафика протокола передачи файлов (FTP), брандмауэр Windows не использует информацию уровня приложений для постоянной фильтрации трафика. FTP является особым случаем из-за способа, которым FTP-сервер устанавливает канал данных для передачи файлов FTP. Во время обычного сеанса пользователя FTP клиент FTP инициирует канал управления с сервером FTP. Когда FTP-клиент передает файл с FTP-сервера, FTP-сервер пытается установить канал данных с FTP-клиентом, инициируя обмен данными через порт TCP, отличный от того, который используется для канала управления. Это может привести к тому, что большинство брандмауэров, запущенных на компьютере клиента FTP, отбрасывают пакеты канала данных, поступающие с сервера, поскольку они кажутся незапрошенными. Чтобы преодолеть эту проблему, брандмауэр Windows использует службу шлюза уровня приложения для обеспечения динамического сопоставления портов для канала данных FTP, тем самым облегчая фильтрацию FTP-трафика с отслеживанием состояния. https://technet.microsoft.com/en-us/library/cc755604(v=ws.10).aspx

Меня пугает мысль о размещении Контроллера домена в общедоступном Интернете. Сказанное выше, если вы действительно можете ограничить связь с контроллером домена до группы машин, использующих брандмауэр Windows в состоянии запрета по умолчанию с правилами «Разрешить» для этих авторизованных машин, мне это вовсе не кажется необоснованным.

В идеале я бы предпочел изолированную сеть управления, к которой были подключены веб-серверы и DC, с DC, не имеющим прямого подключения к Интернету, и VPN для получения доступа к сети управления. Учитывая, что вы, вероятно, можете получить это в своем сценарии хостинга, то, что вы описываете, не является необоснованным отступлением. Кто-то, повышающий привилегию на одном из веб-серверов в вашем сценарии DC с брандмауэром, будет в аналогичном положении в моем сценарии изолированной сети управления. Это не так уж и много отличается, если вы тщательно относитесь к DC как к изолированной машине и ограничиваете его связь с / из Интернета (в идеале полностью отключите его, как только у вас будет установлена ​​VPN для «переходной коробки») .