Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
1833 Views 4 Replies Latest reply: Feb 26, 2013 10:07 AM by PhilM RSS
secnet500 Newcomer 5 posts since
Jan 5, 2011
Currently Being Moderated

Feb 20, 2013 6:45 AM

Enterprise Firewall blocks Microsoft WSUS-Download

Hello,

 

we have a problem that our McAfee Enterprise Firewall (Version 7.01.03) sometimes blocks Downloads from Microsoft (Internet) to

our WSUS-Server (Intranet).

 

An the Enterprise Firewall we have a Netgroup with all URLs and DNS-Domains that WSUS use for downloads.

This netgroup is bound at a rule für outbound traffic from the WSUS-Server.

 

Log WSUS-Server:

2013-02-14 01:13:00.737 UTC Error WsusService.19 ContentSyncAgent.JobError Download error: http://wsus.ds.download.windowsupdate.com/msdownload/update/software/secu/2013/0 1/windows6.1-kb2799494-x86_a75eeccdf902f6c35d7bced5dbe77f078dd8705c.cab failed in download: (-2145844845) Der Client verfügt nicht über ausreichend Zugriffsrechte auf das angeforderte Serverobjekt.

   at Microsoft.UpdateServices.ServerSync.ContentSyncAgent.JobError(IBitsJob job, BitsJobError joberror, String fileRemoteName)
   at Microsoft.UpdateServices.ServerSync.ContentSyncAgent.MonitorStatusThreadProc()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup (TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

 

Log Enterprise-Firewall:

date="Jan 23 10:15:47 2013 CET",fac=f_http_proxy,area=a_proxy,type=t_attack,pri=p_major,pid=2439,ruid=0,eu id=0,pgid=2439,logid=0,cmd=httpp,domain=htpp,edomain=htpp,hostname=host.yyy,cate gory=policy_violation,event=ACL deny,attackip=x.x.x.x,attackburb=inside,srcip=x.x.x.x,srcport=3372,srcburb=insi de,dstip=62.159.74.65,dstport=80,dstburb=Internet,protocol=6,service_name=http-n on-trans,user_name=(null),auth_method=(null),rule_name="Deny All",cache_hit=1,reason="Traffic denied by policy.

 

NetGroup Enterprise-Firewall Rule:

DNS:

download.windowsupdate.com

microsoft.com

update.microsoft.com

windowsupdate.microsoft.com

URLs:

download.microsoft.com

download.windowsupdate.com

ntservicepack.microsoft.com

stats.update.microsoft.com

stats1.update.microsoft.com

update.microsoft.com

windowsupdate.microsoft.com

wsus.ds.download.windowsupdate.com

 

Nachricht geändert durch secnet500 on 20.02.13 06:45:39 CST
  • lawrencegarvin Newcomer 2 posts since
    Feb 22, 2013
    Currently Being Moderated
    1. Feb 22, 2013 12:37 PM (in response to secnet500)
    Re: Enterprise Firewall blocks Microsoft WSUS-Download

    It looks to me like a simple HTTP 403 coming from the firewall/proxy. Apparently what  you've granted access to is not enough.

     

    Log WSUS-Server:

    2013-02-14 01:13:00.737 UTC Error WsusService.19 ContentSyncAgent.JobError Download error:http://wsus.ds.download.windowsupdate.com/msdownload/update/software/secu/2013/0 1/windows6.1-kb2799494-x86_a75eeccdf902f6c35d7bced5dbe77f078dd8705c.cab failed in download: (-2145844845)

     

    In the WSUS server log the code -2145844845 is an 0x80190193 error, which is an HTTP 403.

     

    In the Firewall log it confirms this.

     

    rule_name="Deny All",cache_hit=1,reason="Traffic denied by policy.

     

    All WSUS downloads are done via anonymous connection on HTTP (port 80), so it shouldn't take a lot of special configuration -- unless you're trying to target by destination URL. The URLs that need to be allowed are listed in the WSUS product documentation. Start here for guidance on configuring the firewall/proxy: http://technet.microsoft.com/en-us/library/dd939815(v=ws.10).aspx

  • mole.dai Newcomer 5 posts since
    Feb 26, 2013

    hello

     

    You need to check something

     

    1. Is firewall dns service opened?

    2. What is your WSUS server's DNS setting?

     

    if firewall dns service is opened and wsus server dns setting isn't firewall IP, the 'update.microsoft.com' resolve ip is different between wsus server and firewall dns.  So it will be deny when through firewall.

  • PhilM Champion 528 posts since
    Jan 7, 2010
    Currently Being Moderated
    4. Feb 26, 2013 10:07 AM (in response to secnet500)
    Re: Enterprise Firewall blocks Microsoft WSUS-Download

    It is possible that part of your problem could be tied to the fact that you are trying to use rules to control access, and are then using host and domain objects to do so.

     

    I can understand why, and Sam (sliedl) or Matt (mtuma) as McAfee engineers may be able to offer a more eloquent answer. But going all the way back to my original Sidewinder v5 training in 2000 and training courses I have been on for other Firewall solutions since then when the subject of using hosts or domains in access rules is raised there is always a sharp intake of breath from the instructor.

     

    Regardless of vendor you can see where they are going with it - as soon as you use domain or host objects you are then relying heavily on DNS (which explains mole.dai's response) and the slightest issue with DNS will result in the rule not working. A similar subject was raised a few weeks ago and Matt did provide a good explanation for this. It was something along the lines that Host network objects use forward DNS, which is fairly predicatble, but Domain objects rely on reverse DNS and quite often the reverse lookup for an IP address (62.159.75.65 in your example) simply doesn't match the domain object(s) you are trying to specify in your rule.

     

    What you are seeing in the log file is that the connections are failing to match any "allow" rules on your Firewall and are therefore being caught by the "Deny All" rule at the bottom of the policy - either that or another explicit "deny" rule is matching and blocking the connection.

     

    It does look as though you are reaching the correct conclusion - the download request is hitting an akamai service and trying to control this through a firewall is a little like trying to hit a moving target. I'm just not sure that you'll ever manage to achieve it using a locked-down rule.

     

    -Phil.

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points