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