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

Правило брандмауэра, разрешающее доступ к обновлениям Windows или другим ресурсам в CDN?

Как лучше всего проделать брешь в брандмауэре границы, чтобы разрешить обновления Windows?

Насколько я могу судить, сайты обновлений Windows размещены в сети распространения контента, которая потенциально может менять IP-адреса каждые 30 секунд.

Если я «отравлю» DNS нашего кампуса статическим назначением сайтов, в конечном итоге я буду указывать на сайты, на которых фактически больше не размещается контент.

Существуют ли какие-либо IP-адреса, на которых размещается содержимое обновления, которое гарантированно никогда не изменится?

В более общем смысле, как люди настраивают брандмауэры, чтобы разрешить доступ к ресурсам, размещенным в сетях CDN, где IP-адреса будут постоянно меняться? Брандмауэр просто просматривает пакеты и от них и не обязательно знает, по какому URL (если https) направляется запрос, поэтому у брандмауэра нет прямого способа узнать, что этот пакет отправляется на сайт обновления описаний вирусов Symantec. пока тот смотрит на стрим чемпионата мира по футболу.

И в моей ситуации у меня нет возможности просто указать конкретную конфигурацию систем в сети. Ах, радость работы в университете ...

Хотя я этого не пробовал (см. Мой комментарий выше), я думаю, что лучшее решение - дальше по стеку: использование прокси-сервера.

Вы можете настроить что-то вроде Squid перед своими компьютерами с Центром обновления Windows (или, что более вероятно, сервером WSUS) и разрешить * .windowsupdate.microsoft.com и * .windowsupdate.com (и скоро) отрицая все остальное; затем это можно было бы применить на вашем пограничном брандмауэре, заблокировав TCP 80/443 для вашего сервера WSUS и принудительная настройка прокси для службы WinHTTP на рассматриваемом сервере (ах).

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

Я несколько решил эту проблему, настроив обратные прокси-серверы и отравив DNS.

  1. для каждой службы укажите IP-адрес и привяжите HAproxy к этому IP-адресу и настройте HAproxy для приема запросов, видимых на этом IP-адресе, и пересылки их на DNS-адрес этой службы. (10.10.10.30 запросы прокси к www.apple.com, 10.10.10.31 запросы прокси к update.microsoft.com, 10.10.10.32 прокси к windowsupdate.com и т. Д.)

  2. настроить этот HAproxy-сервер на использование не зараженного DNS-сервера

  3. отравить кампусный DNS, чтобы указать эти службы на внутренние IP-адреса HAproxy (windowsupdate.com -> 10.10.10.32, 10.10.10.30 -> www.apple.com, 10.10.10.31 -> update.microsoft.com и т. д.)

  4. убедитесь, что на прокси-сервер не действуют ограничения на исходящий трафик пограничного брандмауэра.

Я тестировал это на ограниченной основе, и это действительно работает. Если / когда это будет запущено в реальное производство, это, вероятно, будет сделано с использованием F5 вместо HAproxy.

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

Надеюсь, у кого-то есть более элегантное решение, чем у меня ...

Я рекомендую установить WSUS на сервере в вашей демилитаризованной зоне и предоставить ему неограниченный доступ к microsoft.com

Затем с помощью групповой политики я бы указал всем остальным вашим устройствам использовать ваш сервер WSUS. Есть несколько плюсов:

  1. Только один сервер имеет доступ через «дыру в межсетевом экране»
  2. Вы можете контролировать, какие обновления поступают на какой сервер, из централизованной панели управления.
  3. Уменьшение использования полосы пропускания, так как только один сервер загружает из Интернета, остальные загружаются через вашу локальную сеть.