SoI decided to have a meeting in London a few months ago with @sophossecurity and it literally blew my mind. They showed me how easy it is for cyber criminals to hack you - but also how easy it is to stop those trying to get to you.
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.
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.
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.
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.
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.
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.
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.
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.
Posting on here since Sophos has been less then helpful, We installed Sophos endpoint wither their Ventura Config profile and it looks like it works and is functional. However when I go to do an update on the computer while logged in as the local admin no password is accepted. Also when I go to More info and then install through that window it locks SophosEndpoint as the user name and no password I try works there. I've attached a screenshot of the weird login window I haven't seen before
Looks like its performing permissions management over the softwareupdate binary. You will need to work with the vendor on this, even if they dont want to work with you. The application should be auto promoting this binary, and not prompting for anything so a rule is likely configured wrong.
We use CyberArk EPM, and last month I noticed if it installs before any user logs it EPM force generates macOS's Secure Token. Of course, EPM has no way to pass that secure token to a user. The vendor was as useless as you would expect. We wound up delaying the install of EPM until after Disk Encryption is enabled, that way the end user would have already logged in and they get a Secure Token and Volume Ownership before EPM can go and mess things up. I'd wager Sophos is doing the same thing.
Using the kb as reference (Use secure token, bootstrap token, and volume ownership in deployments - Apple Support) we created an extension attribute to hunt through our machines and report back any machines that had tokens assigned to the "_sophos" account. That list lined up with the machine errors we were seeing, (and some machines we had not yet).
We've broken out in to two phases for remediation:
The remediation attempts got so convoluted, that we abandoned them. Since ensuring that Sophos installation is either handled automatically after a delay from enrollment or white gloved by installation teams post login, this issue has disappeared from our management space.
We opted to start over (wipe and ADE) with all affected machines in the name of reliability and brevity. The answer from both vendor and Apple support has amounted to "that shouldn't happen" so I would not hold my breath on a solution.
Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.
This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.
3a8082e126