topic Re: DNS traffic identified as sophos-live-protection in General Topics

DNS traffic identified as sophos-live-protection

LCMember1959 — Wed, 26 Oct 2016 10:28:31 GMT

Some DNS traffic is classified as sophos-live-protection in our traffic logs. Has anyone else seen this? I only have logs 5 days back in time, so I cannot say when this started but it wasn't with the latest apps update. Our firewall is PA-5050 running PAN-OS 6.1.14.

Re: DNS traffic identified as sophos-live-protection

bmorris1 — Wed, 26 Oct 2016 10:39:37 GMT

Hi,

UDP 53 is one of the standard ports used in the sophos-live-protection app signature. If you run a packet capture, check the queries to see if they are going towards sophos. Sophos uses specially crafted DNS packets to function, I believe this is how it does the live lookup functionality.

hope this helps,

Ben

Re: DNS traffic identified as sophos-live-protection

LCMember1959 — Wed, 26 Oct 2016 10:42:10 GMT

Some of this traffic is coming from our domain controllers (to external DNS servers), and they have no Sophos installed. To my knowledge we don't use any Sophos software whatsoever in our network.

Re: DNS traffic identified as sophos-live-protection

bmorris1 — Wed, 26 Oct 2016 10:45:33 GMT

Hi,

If that is the case then I would advise you open a case with TAC to get the traffic investigated, could be legimate or mis-identification. Your best bet is to run a packet capture to see what the query is that is trigging this.

Take a look here on how to run a capture:

https://live.paloaltonetworks.com/t5/Featured-Articles/Getting-Started-Packet-Capture/ta-p/72069

Ben

Re: DNS traffic identified as sophos-live-protection

TranceforLife — Wed, 26 Oct 2016 11:42:11 GMT

Agreed with Borris. This is the way Sophos works .I did a some research, and please find bellow one explication why some DNS queries can be identified as Sophos

Sophos has an endpoint product (Sophos Endpoint) which does web control (web access control, live protection from and blocking access to malicious website, etc).

It does this by making use of what is called SXL (Sophos Extensible List). This is basically making queries to Sophos servers over the DNS/HTTP/HTTPS protocol (mostly DNS). These look like typical DNS packets, except that the DNS query field payload is very long, and in a certain format. An example:

3.1o18sr00n61snno1p37507pqr8n37np4ss2452r34ssn879r45q336649r69p43.278por741os37393648s22q137o1159n2539961nq023n1n0q44035s4s9o86qp.rs184r9428sop6747559os0897962s08nrs30q417ns31n.408qr9on9r75nor4.i.07.s.sophosxl.net: type TXT, class IN

Re: DNS traffic identified as sophos-live-protection

LCMember1959 — Wed, 26 Oct 2016 13:07:44 GMT

Thanks for the feedback. I see this problem in DNS queries from our domain controllers to the DNS servers of our ISP, and neither we nor our ISP use Sophos in any way, shape or form. So I will open a TAC case on this.

Re: DNS traffic identified as sophos-live-protection

LCMember1959 — Thu, 27 Oct 2016 14:36:48 GMT

After talking to TAC we found that it was indeed DNS queries from BYOD clients using Sophos Live Protection. I guess we could use some kind of application override to force this traffic to be identified as DNS, but instead we will just block sophos-live-protection.

Re: DNS traffic identified as sophos-live-protection

djr — Thu, 22 Dec 2016 09:28:06 GMT

Hi Terje,

I am seeing this on my network but I still think this is a mis-classification. If it was genuine live update traffic, surely it would not be routed via our DNS servers but instead would go directly from the client to sophos? Did you manage to confirm that genuine sophos live update traffic is still routed through the client's DNS servers? If so, this is bad because it is putting a lot of extra load on our domain controllers and BIND servers.

Thanks

David

Re: DNS traffic identified as sophos-live-protection

TerjeLundbo — Thu, 22 Dec 2016 10:43:01 GMT

Hi David.

We concluded that the traffic is a genuine DNS request, but that the Sophos client adds a lot of content to the request and this makes PA change the appid from dns to sophos-live-protection. Here is the full reply I got from PA support:

It's not a situation I've come across before, and I can't think of anything other than Sophos live protection that may trigger this, but it's entirely possible there are other similar solutions that utilize DNS in this way that could result in a session having it's appid shifted from DNS to something that's effectively tunneling within DNS.

Since the Sophos application is working within the DNS queries, the identification isn't really wrong, but obviously it does result in the whole session being misleadingly categorised, which is made worse in this situation - since it's a session between your internal DNS servers and ISP's servers, the session contains hundreds or more DNS lookups that are totally unrelated to Sophos live.

If you'd like to avoid this happening completely I would think you could use an Application Override rule to force all UDP connections between your internal and external DNS servers on port 53 to be categorised as DNS, which should avoid any application shifting occurring.

Re: DNS traffic identified as sophos-live-protection

djr — Thu, 22 Dec 2016 10:57:01 GMT

Terje,

I looked into this a while back but I didn't actually look closely at the traffic content. I don't think this is mis-categorised, sophos admit they use port 53 for their updates but don't mention that they actually tunnel it in DNS requests so I presumed the traffic was going directly between our clients and sophos until I noticed the flows were coming from our DNS server this morning.

I think I need to do some more digging because from what I can see each session transfers around 600kB, so if that means the actual signature updates are passed through the DNS servers, it may be a good reason to move away from sophos. If they just check to see if they need updates that way, it would be less of an issue, but 600kB seems a lot just for that.

Thanks,

Re: DNS traffic identified as sophos-live-protection

Retired Member — Tue, 28 Mar 2017 05:52:54 GMT

We are seeing this also on PAN 8.0.1.

thanks