Обновления Windows позади физического брандмауэра только с основанными на IP правилами и универсальными исходящими соединениями выключены

Cisco ASA может выполнять фильтрацию URL-адресов, если включена проверка HTTP. У них есть отличная статья, показывающая, как это работает здесь . Наиболее подходящий пример из этого документа для вас будет выглядеть примерно так:

! Replace regex with all known MS Update hostnames
regex ms-updates "^update\.microsoft\.com|download\.windowsupdate\.com$"

! Match if the Host: header does not match the regex.
class-map type inspect http match-any not-ms-updates
 match not request header host regex ms-updates

! Drop packets matching the class-map (and thus not matching the regex).
policy-map type inspect http ms-update-policy
 parameters
 class not-ms-updates
  drop-connection log

! Configure HTTP inspection with the policy applied.
policy-map global_policy
 class inspection_default
  inspect http ms-update-policy

service-policy global_policy global

Основная загвоздка в том, что проверка HTTP может иметь дело только с незашифрованным HTTP. Невозможно проверить трафик HTTPS с помощью ASA. Некоторые URL-адреса Центра обновления Майкрософт доступны по протоколу HTTPS, поэтому об этом следует знать.

Использование политики проверки по-прежнему оставляет вас открытыми для пользователя, создающего собственный HTTP-запрос, соответствующий политике, но который фактически не переходит в авторизованный сайт. Это можно смягчить, используя фактические имена хостов в ваших списках доступа, используя функцию FQDN Object , представленную в 8.4 (2). Это позволяет вам создать объект, который ссылается на полное доменное имя, которое, в свою очередь, может использоваться в списке доступа. Например:

object network ms-update-1
 fqdn update.microsoft.com

access-list inside_access_out extended permit any object ms-update-1 eq 80
access-list inside_access_out extended deny ip any any log

access-group inside_access_out in interface inside

Если вы придерживаетесь этого подхода, я предлагаю разместить строку FQDN как можно ниже в ACL, чтобы она срабатывала только для фактического трафика обновлений. ASA выполняет кэширование DNS, но если TTL запрашиваемого FQDN очень низкое, это может привести к большому количеству запросов DNS от ASA. Использование локального кэширующего DNS-сервера должно помочь свести к минимуму любые задержки.

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

Я предлагаю расположить строку FQDN как можно ниже в ACL, чтобы она срабатывала только для фактического трафика обновлений. ASA выполняет кэширование DNS, но если TTL запрашиваемого FQDN очень низкое, это может привести к большому количеству запросов DNS от ASA. Использование локального кэширующего DNS-сервера должно помочь свести к минимуму любые задержки.

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

Я предлагаю расположить строку FQDN как можно ниже в ACL, чтобы она срабатывала только для фактического трафика обновлений. ASA выполняет кэширование DNS, но если TTL запрашиваемого FQDN очень низкое, это может привести к большому количеству запросов DNS от ASA. Использование локального кэширующего DNS-сервера должно помочь свести к минимуму любые задержки.

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