Browse Live Discover and Response Queries by Category
Under Review

Domains (FQDNs) to allow for Live Discover (for MDR team)

What are the domains or FQDNs to allow for access to Live Discover?

The goal is to allow the Sophos MDR team to access an endpoint that is in red status and getting blocked by the firewall.

When a device behind the Sophos firewall goes into a red heartbeat status we have a rule that blocks outbound traffic from the possibly infected host.  The problem is that the MDR team cannot access the host.  Even when we put a firewall rule above to allow all the domains (FQDN) per Sophos' article, the device is still offline in Live Discover.  I've opened ticket 06978860 with support and been back and forth for weeks with no progress as they can't tell me the correct domain or FQDN for Live Discover.

I tested this on my laptop.  I have a rule to allow all the domains per the article (https://doc.sophos.com/central/customer/help/en-us/PeopleAndDevices/ProtectDevices/DomainsPorts/index.html#domains), followed by a rule to drop internet traffic.  My laptop goes offline in Live Discover when I do this. Yet I’m able to browse to sophos.com web site and get Sophos Endpoint updates.  I don’t think the list of domains in the article includes the domains required for Live Discover.  Have you done this same test on your end to verify?  Please test it out and let me know what you find and if you can identify the domain responsible for Live Discover so we can get this resolved.

BoreasJeff
Parents
  • Hi community.sophos.com/.../boreasjeff, Thanks for reaching out to the Sophos Community Forum.  Checking through the details in the support case you mentioned, it looks like you do have all of the necessary domains and ports excluded. This should be sufficient for the device to show online in Sophos Central for both Live Discover queries and Live Terminal sessions. Were any changes made recently outside of the allow rules you have defined for the domains and ports related to Sophos? 
  • in reply to Qoosh
    To close the loop on this thread:  The problematic URL was found by checking the MCS Logs (C:\ProgramData\Sophos\Mangement Communications System\Endpoint\Logs\MCSClient.log) locally on one of the affected devices and was found to be: - mcs-push-server-.prod.hydra.sophos.com If allow lists are populated with all patterns mentioned under the doc.sophos.com/.../index.html section, communication will work as expected, specifically: *.sophos.com. What may cause discrepancies during troubleshooting is a 10-minute backoff period the communication components will observe when attempts to reach our server fail.
Comment
  • in reply to Qoosh
    To close the loop on this thread:  The problematic URL was found by checking the MCS Logs (C:\ProgramData\Sophos\Mangement Communications System\Endpoint\Logs\MCSClient.log) locally on one of the affected devices and was found to be: - mcs-push-server-.prod.hydra.sophos.com If allow lists are populated with all patterns mentioned under the doc.sophos.com/.../index.html section, communication will work as expected, specifically: *.sophos.com. What may cause discrepancies during troubleshooting is a 10-minute backoff period the communication components will observe when attempts to reach our server fail.
Children
  • in reply to BoreasJeff
    Certainly, if the endpoint fails to reach Sophos Central, the MCS services will observe a brief waiting period. On subsequent attempts to reach Sophos Central, if failures continue, the device will increase the wait period up to a maximum of 10 minutes.  To reset the backoff period, you will need to stop and re-start the "Sophos MCS Agent" and "Sophos MCS Client" services. If network changes are also occurring at the same time, this can cause inaccurate results during testing unless the services are also being stopped and restarted.
  • in reply to Qoosh
    Maybe it was the "backoff period" .  Would you please explain?
Unfiltered HTML