У меня есть несколько ящиков, в которых я не хочу разрешать входящий или исходящий трафик в Интернет, за исключением обновлений Windows. Однако установленный межсетевой экран (Cisco ASA), по-видимому, поддерживает только правила на основе IP. Насколько я могу судить, доступ к обновлениям Microsoft через что-либо другое, кроме полдюжины URL-адресов, маскирует списки Microsoft, поскольку это невозможно.
Я начал создавать полный WSUS, в который затем вручную скопировал бы файлы обновлений, так что прямой доступ Microsoft не требуется, но это звучит очень тяжело для очень небольшого числа задействованных устройств.
Я также постоянно обдумывал ручные обновления, но я не уверен, как быть удобно и уверенно, что правильные обновления применяются в правильном порядке.
Любые идеи из любого направления будут оценены. Я хочу, чтобы это было как можно более простым / экономичным, но у меня было очень мало гибкости в отношении единственной абсолютно необходимой политики доступа в Интернет.
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 функция, представленная в 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-сервера должно помочь свести к минимуму любые задержки.
Комбинация этих двух подходов должна делать то, что вам нужно, с тем, что у вас есть, и без дополнительных затрат, но я настоятельно рекомендую прочитать связанные документы, чтобы вы понимали их ограничения.