Sophos Central Endpoint and SEC: Computers fail/hang on boot after the Microsoft Windows April 9, 2019 update. Please follow knowledge base article 133945
Learn about the Benefits of Multi-Factor Authentication (MFA). Turn your MFA on now!
Outage on MySophos and Partner Portal. You may contact Sophos Support through Phone.
This article lists the different types of SXL lookups that are present in the Sophos Endpoint.
The following sections are covered:
Applies to the following Sophos products and versions Sophos Anti-Virus for Windows 2000+Sophos Cloud Managed EndpointUTM Managed Endpoint (Windows 2000+)
SXL stands for Sophos Extensible List. It is used for retrieving data from a remote computer. The main purpose of SXL is to extend the protection offered on the endpoint by providing access to a wider amount of detection data/information when needed. This allows endpoints to provide up-to-the-minute detection by checking online for further information about a file/website being scanned. There are lots of different reasons why an SXL lookup will take place, from accessing a file to browsing a website. There are three main features within the endpoint that will generate the SXL lookups:
Note: If you disable these features, this will reduce the number of lookups that are generated. However, this will dramatically reduce your protection.
All versions of SXL are supported and used in conjunction with each other.
A typical SXL lookup has the following structure:
The protocols that SXL uses vary depending on the version and type of the lookup that is carried out, as detailed in the following table:
As you can see from the SXL Lookup type table above we currently have three separate SXL Lookup types. These types being: SXL2, SXL3.1, and SXL4.
SXL2 requires that endpoints are able to resolve DNS requests. This generally means that the endpoint will talk to its local resolver on the network, which then resolves the DNS request on your behalf.
Crucially, the endpoint does NOT need to send DNS request directly to the SXL servers: just to the resolvers which are typically internal.
The example below explains why it is not possible to give a complete set of addresses for this. We are unable to enumerate all possible requests as the Payload-Information is different for every single request.
Note: Live protection (SXL2) uses DNS but sample submission (an associated option) requires HTTP port 80.
SXL3.1 runs over either HTTP and DNS, This will default to sending these request over HTTP.
This lookup does support proxies so typically if you have web access these requests will be successful. If use of a 3rd party web filtering tool is used that blocks access to our SXL addresses these lookups will fail.
The IP that http.00.a.sophosxl.net resolves to will constantly change. This enables us to allocate traffic to the best server based on the volume of traffic and your geographic location. Due to the volume of address changes this makes, we are unable to provide a Static IP Address or range for this particular lookup.
Fortunately, if you are unable to allow the SXL3.1 addresses through your web filter and/or proxy via HTTP you will be able to override this lookup to send the requests via DNS in the same manner as SXL2, this can be overridden by amending the registry value on the endpoint. See Registry value.
SXL4 performs HTTPS requests in a similar procedure to how SXL3.1 requests are performed on HTTP. For these lookups to be successful we will require web access in order for these requests to be successful. We will require an exclusion to be put in place within any web filters and/or proxies which may potentially block these requests.
Unlike SXL3.1 lookups you are unable to change these requests to send over DNS. A successful HTTPS request is a requirement for these lookups to be successful.
Unfortunately, we are unable to provide static addresses for these lookups as this traffic is directed through an Amazon Web Services load balancer so it is not a possibility for us to predict which IP Address this may be translating to.
Amazon has provided us with a .json file which lists all of the possible addresses this could hit however it is worth noting that this includes any application which uses Amazon AWS.
Note: See article AWS IP Address Ranges for information on how to interpret the JSON data.
Note: The below registry changes are only applicable for downgrading SXL3.1 connections to use SXL2.
The protocol used depends on the presence of the following registry value:
Open registry (see, Editing the Windows registry) and go to:
If the above key is present and set to 1 it will use HTTP:
If this value is not present or set to 0 it will use DNS:
If HTTP is not available, you can revert some of the requests to the following addresses:
and these DNS addresses:
If you've spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article. This is invaluable to us to ensure that we continually strive to give our customers the best information possible.
Every comment submitted here is read (by a human) but we do not reply to specific technical questions. For technical support post a question to the community. Or click here for new feature/product improvements. Alternatively for paid/licensed products open a support ticket.