Это “в порядке” для использования брандмауэра окон для DC с общедоступным IP?
У меня в настоящее время есть несколько специализированных веб-серверов Windows, которые размещаются в различных регионах. До сих пор я управлял ими без Active Directory, но я чувствую, что он добавляет большое ненужное администрирование наверху и ограничения.
Теперь я задаюсь вопросом, как DCS должен был бы быть защищен. У меня нет своего собственного центра обработки данных в моем распоряжении, но я мог арендовать два более выделенных сервера и использовать более выделенные серверы как DCS. Я знаю, что DC должен идеально быть помещен позади выделенного брандмауэра, но это сделало бы аренду DCS намного более дорогой.
Было бы нормально использовать Windows Firewall на DCS вместо отдельного устройства брандмауэра? Это не могло бы быть решение для учебника, но кажется, что все должно быть безопасным, если я ограничиваю доступ к входящим портам DC к IP-адресам моих собственных веб-серверов. В конце концов, это - то же самое, которое я сделал бы с отдельным устройством брандмауэра.
Когда я впервые прочитал вопрос, я был очень обеспокоен тем, чтобы дать DC публичный IP вообще. Но если подумать, я могу подумать, что IF DC был не членом моего большого леса AD, и единственными машинами в домене были веб серверы.
Это все равно позволило бы мне управлять моими веб серверами с помощью групповой политики и общей аутентификации, с помощью всего одной дополнительной учетной записи AD для присвоения себе, не подвергая мои настоящие внутренние контроллеры домена воздействию большой плохой паутины. На самом деле, вы настраиваете AD только для DMZ.
Тем не менее, Я все еще вижу некоторые проблемы в этом подходе:
- AD тесно связан с DNS. Вам нужно будет тщательно подумать об управлении записями DNS для ваших веб-серверов в сочетании с AD.
- Хотя брандмауэр Windows Firewall адекватен (едва ли) для этого с точки зрения несанкционированного доступа, он не отрезает его от аудита и отказа в обслуживании. Было бы тривиальным нарушить работу ваших сайтов, направив DoS-атаку на ваш центральный DC - может быть, не повреждать или снимать, но, по крайней мере, нарушать.
Меня пугает мысль о том, чтобы разместить контроллер домена в публичном интернете. Учитывая это, если вы действительно можете ограничить связь с контроллером домена до группы машин, использующих брандмауэр Windows Firewall по умолчанию, то правила "Allow" для этих авторизованных машин не кажутся мне неразумными.
В идеале я бы предпочел изолированную сеть управления, к которой были бы прикреплены веб-серверы и контроллер домена, при этом контроллер домена не имел бы прямого подключения к Интернету, а VPN для получения доступа к сети управления. Учитывая это, вы, вероятно, сможете понять, что в вашем сценарии хостинга то, что вы описываете, не является неоправданным откатом назад. Кто-то, повышающий привилегии на одном из веб-серверов, в сценарии с DC с брандмауэром, окажется в аналогичном положении в сценарии с моей изолированной сетью управления. Это не так уж и много отличается, если вы тщательно относитесь к DC как к изолированной машине и ограничиваете его связь с Интернетом (в идеале, полностью отключив его, как только у вас будет установлена VPN в "jump box")
.Я не рекомендую, так как брандмауэр сам по себе является базовым.
Наличие AD только для вашего веб-приложения не является более небезопасным, так как оно находится под базовой аутентификацией, но проверьте там некоторые подсказки (даже если они помечены на 2008 год): Служба домена Active Directory в сети периметра (Windows Server 2008)
Брандмауэр Windows является псевдо-полным для UDP, без гражданства для ICMP и statefull для Ipv4,Ipv6 (для фильтрации трафика, для проверки я не нашел ни одного документа, но если он есть, то он действительно ограничен).
Аппаратное устройство обычно имеет статус.
Брандмауэр с контролем состояния:
В вычислительной технике брандмауэр с контролем состояния (любой брандмауэр, который работает с контролем состояния соединений) проверка пакетов (SPI) или проверка по статусу) - это брандмауэр, который отслеживает состояние сетевых соединений (например, TCP-потоков), UDP-коммуникация), проходящая через него. Брандмауэр запрограммирован на различать легитимные пакеты для различных типов соединений. Только пакеты, соответствующие известному активному соединению, будут разрешены с помощью параметра брандмауэр; другие будут отвергнуты.
Статусная проверка, также называемая динамической фильтрацией пакетов, заключается в том, что функция безопасности, часто включенная в бизнес-сети. Контрольная точка Программное обеспечение ввело stateful inspection при использовании своей FireWall-1 in 1994.1[2] https://en.wikipedia.org/wiki/Stateful_firewall
Stateless:
Брандмауэры без гражданства следят за сетевым трафиком, ограничивают или блокируют пакеты, основанные на адресах источника и получателя или других статических ценности. Они не "знают" о закономерностях трафика или потоках данных. A брандмауэр без гражданства использует простые наборы правил, не учитывающие возможность того, что пакет может быть получен брандмауэром. "притворяться" тем, о чем ты просил. - Узнай больше: 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 использует Служба Application Layer Gateway Service для динамического отображения портов для канал данных FTP, тем самым облегчая фильтрацию с учетом состояния протоколов. FTP-трафик. https://technet.microsoft.com/en-us/library/cc755604(v=ws.10).aspx