4 Replies Latest reply: Feb 26, 2013 10:07 AM by PhilM RSS

    Enterprise Firewall blocks Microsoft WSUS-Download

    secnet500

      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
        • 1. Re: Enterprise Firewall blocks Microsoft WSUS-Download
          lawrencegarvin

          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

          • 2. Re: Enterprise Firewall blocks Microsoft WSUS-Download
            mole.dai

            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.

            • 3. Re: Enterprise Firewall blocks Microsoft WSUS-Download
              secnet500

              thx for your help.

               

              I don't think it's a problem with our DNS Setup.

              The WSUS Server uses the firewall as a  proxy.  The DNS resolution should be ok.

               

              We allowed all connections to the microsoft servers according to the microsoft knowledgebase.

               

              I think the problem is,  every microsoft server has different ip`s (from the akamai pool).

               

              This is the flow

               

              Wusus Server ----> DNS Resolutin e.g. microsoft com <------ Wsus Server receives a acamai IP  ---------> Wsus Server tries to connect to the acamail ip  ----> our Firewall denies this connection because the acamai ip is not in the allow list

               

               

              have a look at this connection

               

              IP: 62.159.74.65

               

              Where does this ip come from?

              Has nothing in common with windows!


              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,cat e 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.

               

               

               

              ; <<>> DiG 9.7.3 <<>> -x 62.159.74.65

              ;; global options: +cmd

              ;; Got answer:

              ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4195

              ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

               

              ;; QUESTION SECTION:

              ;65.74.159.62.in-addr.arpa.     IN     PTR

               

              ;; AUTHORITY SECTION:

              159.62.in-addr.arpa.     10173     IN     SOA     pns.dtag.de. dnsadmin.nic.dtag.de. 2013022200 28800 7200 604800 86400

               

              ;; Query time: 0 msec

              ;; SERVER: 127.0.0.1#53(127.0.0.1)

              ;; WHEN: Tue Feb 26 12:05:04 2013

              ;; MSG SIZE  rcvd: 103

              • 4. Re: Enterprise Firewall blocks Microsoft WSUS-Download
                PhilM

                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.