Home / server / Questions / 400270
In Process
user125245
Asked: 2012-06-20 11:11:31 +0800 CST

Windows updates behind a physical firewall with only IP based rules and generic outbound connections are turned off

  • 772

I have some boxes that I do not want to allow any in or outbound traffic to the internet Except for windows updates. However the fire wall in place (Cisco ASA) apparently only supports ip based rules. As best I can tell access to Microsoft updates via anything other then the half dozen URL masks the Microsoft lists as needed does not appear possible.

I have kicked around building a full WSUS that I would then manually copy the update files to so that no direct Microsoft access is needed but this sounds very top heavy for the very few boxes involved.

I have also kicked around manual updates all around but am not certain how to be conveniently and confidently sure that the correct updates are being applied in the correct order.

Any ideas from any direction would be appreciated. I want this as simple / cost effective as possible but have very little flexibility on the only absolutely required internet access policy.

update cisco-asa outboundrules

1 Answers

  1. Cisco ASA can perform URL filtering when HTTP inspection is enabled. They have a great write-up showing how it works here. The most relevant example from that document for you would look something like this:

    ! 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

    The main catch is that HTTP inspection can only deal with unencrypted HTTP. It isn't possible to inspect HTTPS traffic with the ASA. Some Microsoft Update URLs are available as HTTPS, so this is something to be aware of.

    Using an inspection policy still leaves you open to a user crafting a custom HTTP request that matches the policy, but that does not actually go to an authorized site. This can be mitigated by using actual hostnames in your access lists, using the FQDN Object feature introduced in 8.4(2). This allows you to create an object that references a fully-qualified domain name, which in turn can be used in an access-list. For example:

    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

    If you go with this approach, I suggest positioning the FQDN line as low as possible in the ACL, so it only gets triggered for actual update traffic. The ASA does perform DNS caching, but if a queried FQDN's TTL is very low, it could result in a lot of DNS requests from the ASA. Using a local, caching DNS server should help to minimize any delays.

    A combination of these two approaches should do what you need with what you have and with no additional cost, but I strongly suggest reading the linked documents so you understand their limitations.

    • 3