Set up and safely operate Sophos Firewall Threat Feeds

Sophos Firewall Threat Feeds automatically import known malicious IP addresses, domains, and URLs as Indicators of Compromise (IoCs). For a safe rollout, first observe the feed in Monitor mode, check hits and side effects, and only then switch to Block.

This article focuses primarily on Third-Party Threat Feeds, such as the feeds from Cybora. The feature was introduced with Sophos Firewall v21.

Set up a Threat Feed

Third-Party Threat Feeds require the Xstream Protection Bundle, but no additional Sophos Fusion (formerly Sophos Central) licence. The firewall must be able to reach the feed URL over DNS and HTTPS.

1. Open System services > Log settings.
2. Under Active threat response, enable at least one supported log destination. Local reporting stores event logs locally for the Log Viewer; these logs are not on-box reports. Alternatively, use Sophos Fusion (formerly Sophos Central) or a syslog server as the log destination.
3. To see hits on incoming DNAT and WAF traffic, also enable Remote source match (inbound traffic). This option is disabled by default.
4. Open Protect > Active threat response > Third-party threat feeds > Add.
5. Enter a unique name and description, for example:
   • Pilot: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Reviewed production feed: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. For Indicator type, select IPv4 address, Domain, or URL. If a source provides multiple types, create a separate feed for each type.
7. Set Action to Monitor for the rollout. After a reviewed observation period, it can be changed to Block.
8. Under Position, select Top for a pilot feed so that its match isn’t hidden behind another third-party feed. Bottom suits a lower-priority feed whose overlaps are already understood.
9. Under External URL, enter the appropriate address from the Avanet feed list or your provider. The URL must return the plain-text file directly. If the endpoint instead responds with HTTP 302, for example, SFOS lists it as a Connection error. The file contains one indicator per line.
10. Under Authorization, select No authentication, API key, or Basic authentication as required by the provider. For API key, enter the provider-specified header or parameter name and the secret value separately, then select Header or Query parameters as the transmission location. If a provider requires the header X-API-Key, for example, this is the name, not the secret key. For Basic authentication, enter the username and password. The API key value and password each support no more than 64 characters. Credentials do not belong in tickets or screenshots.
11. Enable Validate server certificate. For a public certificate, the issuing CA must be present under Certificates > Certificate authorities; for a private CA, import its certificate first.
12. Select a Polling interval that matches the provider’s update interval.
13. Run Test connection and save with Save.

Then check Sync status, Last updated, the number of Threat indicators, and the available Storage quota. Success confirms a successful connection or HTTP GET request, but neither complete processing of the list nor that the expected traffic is actually detected or blocked. Content and effect must be validated separately.

Choose the right feed and action

Supported indicators

Each feed configuration processes exactly one of these indicator types:

• IPv4 address: scanners, botnets, compromised systems, or C2 servers
• Domain: malware, phishing, or command-and-control domains
• URL: specific malicious paths or download links

The feed must be a plain-text file with one indicator per line. If the provider’s file contains multiple types, SFOS only considers the selected Indicator type. Each required type therefore needs its own configuration; a mixed file does not need to be split solely because it contains multiple types. IP ranges, IPv6 addresses, networks, wildcard domains, and regular expressions are not used in Third-Party Threat Feeds as substitutes for individual supported IoCs.

An IPv4-only format example looks like this:

192.0.2.10
198.51.100.20

These documentation addresses illustrate only the format, not real threats or reachable test destinations. For the controlled test further below, use the individual IPv4 address of your own test destination instead, not its network with a CIDR suffix. For Cybora, use the supplied feed files directly.

SFOS doesn’t impose a fixed number of IoCs per third-party feed. The usable size is limited by the model-dependent Storage quota. After import, check the free quota, number of Threat indicators, and successful retrieval together.

A large list is not automatically a good one. Origin, freshness, update interval, false-positive risk, and hits in the local environment matter more than the raw number of entries. A feed that provides no lasting benefit only consumes storage. The integration is not limited to a fixed provider selection list: any third-party feed can be integrated if it meets the file requirements described. Sophos names GreyNoise Intelligence, CrowdSec, and Q-Feeds as example providers; this does not replace checking the specific endpoint or running your own Monitor pilot.

Monitor before Block

Monitor logs hits but allows the traffic. This shows which sources, destinations, and services would be affected. Block logs and drops matching traffic.

For a new feed, this sequence is useful:

1. Place the feed near the top of the Third-Party list.
2. Start with Monitor.
3. Check hits and possible false positives during a representative period.
4. Document the responsible person and the exception process.
5. Only then switch to Block.

A well-curated IPv4 feed for highly exposed services can be put into production sooner than a domain or URL feed. The latter more often match shared infrastructure, CDNs, or redirects and therefore require particularly careful review.

Before switching to Block, record the feed name, IoC count, position, and the hits observed so far. If the change causes unexpected disruption, immediately set Action on the same feed back to Monitor and retest the affected traffic. A faulty or uncontrollable feed can be temporarily disabled. A global Threat Exclusion is not an equivalent rollback because it also affects MDR, NDR, and Sophos X-Ops.

Order and naming

Active Threat Response processes the modules in this order: MDR, NDR Essentials, Sophos X-Ops, and then Third-Party Threat Feeds. With Log and drop, a match in an earlier module stops further checking. With Log only or Monitor, however, the firewall logs individual events for MDR, X-Ops, and Third-Party Threat Feeds.

Within Third-Party Threat Feeds, the firewall evaluates the Block and Monitor lists separately in their displayed order. It logs the first match in each list and blocks based on the first match in the Block list. Production feeds, pilot feeds, and temporary incident lists should therefore be clearly named and ordered:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

A good name identifies the provider or purpose, indicator type, and action. This saves time during log analysis and reviews.

Distinguish Threat Feed modules

Several features with different purposes and licence requirements appear under Active threat response:

• Sophos X-Ops Threat Feeds: Sophos indicators; require Network Protection and, for enforcement, Web Protection. Both are included in the Standard or Xstream bundle or can be licensed individually.
• MDR Threat Feeds: IoCs from Sophos MDR; require the Xstream Protection Bundle and MDR Essentials or MDR Complete in Sophos Fusion. The dedicated guide explains Sophos Fusion integration, the local action, audit ID, Task Queue, and incident verification.
• Third-Party Threat Feeds: external IPv4, domain, or URL lists; require the Xstream Protection Bundle.
• NDR Essentials: analyses traffic with machine learning. The module licensing overview names the Xstream Appliance Bundle, while the configuration guide names the Xstream Protection Bundle. Use the specific NDR Essentials licensing and source comparison before purchase or rollout and obtain confirmation of the entitlement for the actual firewall.
• NDR Active Threat Intelligence: logs Sophos-curated NDR patterns, requires the Xstream Protection Bundle, and must be enabled per firewall rule using Scan with NDR Active threat intelligence. XGS 87/87w and 88/88w are not supported.

For Synchronized Security and the additional endpoint context in Active Threat Response logs, an Intercept X licence in Sophos Fusion is also required. This licence is not required for the Threat Feed itself, but for enriching the event with host, user, and process details from the endpoint.

Synchronized Security is optional for threat feed matching. If a managed Sophos Endpoint sends a red Security Heartbeat after contacting a malicious server, a properly configured Heartbeat rule can block its traffic; Lateral Movement Protection can additionally isolate the compromised endpoint from the internal network. This endpoint response supplements the feed and its logs, but does not replace the feed configuration or firewall rule.

For NDR, see the separate guide Operate Sophos Firewall NDR and Active Threat Response.

Understand the effect on traffic

IPv4, domain, and URL traffic

Forwarded IPv4 traffic requires a firewall rule that processes the relevant traffic. System-bound traffic to services under Administration > Device access, such as WebAdmin, VPN Portal, and VPN, is matched separately against source-IP indicators and does not pass through a transit firewall rule.

DNS requests answered by the firewall itself as the DNS server are matched against domain IoCs by the DNS module. If clients use another DNS server, IPS must see the DNS traffic. A domain feed alone therefore does not prove that the actual resolver path is being inspected.

For forwarded traffic, domain and URL feeds additionally require Application Classification or an IPS policy in the firewall rule. Application Classification is enabled by default, but it should still be verified in the affected rule path.

For complete HTTPS URLs, the firewall must also see the path. For the Web Proxy path, select Use web proxy instead of DPI engine and Decrypt HTTPS during web proxy filtering under Web filtering in the firewall rule. For the DPI path, clear Use web proxy instead of DPI engine and add a suitable SSL/TLS inspection rule with Action: Decrypt. Without decryption, the firewall sees only the domain through SNI, not the complete URL path.

The responsible inspection path is the web module for the Web Proxy, or IPS for the DPI Engine with SSL/TLS inspection rules. This applies to both encrypted and decrypted HTTPS; which IoCs can be detected still depends on whether only the domain or also the URL path is visible.

DNAT and WAF from SFOS 22

Since SFOS 22, the firewall can match the source IP of incoming forwarded traffic for DNAT and WAF against MDR, NDR, and Third-Party Threat Feeds. This makes it possible to identify known scanners and botnets before they reach published services.

For these hits to appear in the Active Threat Response log, Remote source match (inbound traffic) must be enabled under System services > Log settings > Active threat response. It is disabled by default. Without this setting, blocking may work while the expected DNAT or WAF events remain absent from the Log Viewer.

Typical use cases

Threat Feeds do more than protect outbound client traffic. Publicly accessible services in particular are often scanned automatically within a short time.

• DNAT to internal servers: An IPv4 feed can block known malicious sources before they reach the published server.
• WAF publications: Reputation data complements WAF rules against bot traffic, CVE scans, CMS probes, and credential stuffing.
• VPN Portal, User Portal, and WebAdmin: Protect these services first with MFA, source networks, and Device Access and Local Service ACL. Threat Feeds additionally reduce traffic from known attacker sources.
• Outbound client traffic: Domain and URL feeds can block known malware, phishing, and C2 destinations.
• Heavily scanned WAN addresses: A good IPv4 feed reduces automated noise and relieves the firewall and its logs.

Threat Feeds complement basic hardening; they do not replace it. Published services still need restrictive DNAT or WAF rules, only the required ports, sensible source or country restrictions, IPS or WAF, and enabled logging. A feed is not a licence for broad Any rules. The overall process is described in the Sophos Firewall Hardening Hub.

Check synchronisation and operation

Test feed retrieval and traffic effect separately

Sync status: Success confirms a successful connection or HTTP GET request to the External URL, not the completeness or successful processing of all expected indicators. Test connection is also only a connection check. A complete test covers three levels:

1. Retrieval: Test connection, Sync status, Last updated, and Storage quota are plausible.
2. Content: An expected IoC appears under Threat indicators.
3. Effect: Controlled test traffic produces a hit in Log viewer > Active threat response or at the configured Sophos Fusion or syslog destination. Depending on the match, the feed name, Log/Drop action, match direction, source and destination or URL, protocol, and ports can be traced.

For a reproducible test, use a short custom pilot feed on a controlled HTTPS server. It contains the IPv4 address of a controlled test destination. Keep the feed on Monitor, have a lab client connect to the test destination, and check the log entry. Do not access production malware destinations or third-party systems for testing.

Synchronisation and Storage Quota

These values in the feed overview are important for ongoing operation:

• Success, Fetching, or Disabled under Sync status
• the expected timestamp under Last updated
• a plausible number of Threat indicators
• sufficient available Storage quota
• a successful manual update using Synchronize now

The Summary shows Active feeds as the number of active feeds and the total number configured, Total threat indicators as the number of IPv4, domain, and URL indicators, and Storage quota as the storage used within the model-dependent quota. Larger appliances have more space than desktop models. Refresh only updates these displayed counters. Synchronize now under Manage, by contrast, retrieves the selected feed immediately. Individual IoCs can be opened and searched through Threat indicators or through the number under Total indicators for the relevant feed. Fetching means that the download is in progress; Disabled means that the feed is switched off.

For an Authentication error, first check the API key name, secret value, and transmission location, or the username and password. If these details are correct, also investigate a failed TLS handshake: check the feed server’s certificate and chain of trust, and consult the provider if necessary. Not every authentication error is a TLS error. Keep Validate server certificate enabled; resolve missing CA trust with the correct CA certificate, not by disabling validation.

For a Connection error, check DNS, internet access, the feed server, and the HTTP status; 404, 500, and 302 are also possible causes. SSL/TLS error is a separate status for certificate problems. For Failed, check that the file actually delivered is plain text, contains one indicator per line, and uses the appropriate supported types; other errors are also possible. After correcting the issue, run Test connection and Synchronize now again, check the timestamp and expected IoC, and only then repeat the controlled traffic test. If the error persists, record the status, time, and sanitised feed details without secrets for the provider or support.

Storage full means that there is not enough space for the complete list. The firewall continues to retrieve the feed at the configured polling interval but only updates the stored IoC list once space becomes available. Review feed scope, quality, and priority instead of adding more lists. On XGS 87/87w, 88/88w, and 107/107w, only 24h, 7d, and 30d polling intervals are available for Third-Party Threat Feeds. A provider feed that updates more frequently does not override this appliance limitation.

If no hits appear

Use this troubleshooting order:

1. Feed enabled, Sync status: Success, and expected IoC under Threat indicators
2. a higher-priority MDR, NDR, or X-Ops detection for the same IoC
3. Active Threat Response logging and, for DNAT/WAF, Remote source match
4. the matching firewall rule and its logging
5. for domains and URLs, Application Classification or an IPS policy
6. for URLs, Web Proxy or DPI and SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions, and SSL/TLS Exclusion Lists

To trace an allowed domain or URL IoC to the responsible rule, open Log viewer > Web filter, search for the IoC in Category or directly for the domain, and open the detailed view. It shows the Firewall Rule ID and the Web policy selected in that rule. If the matching policy action is Allow, check the rule and policy order. An intentional block uses a narrowly scoped URL group in a blocking web policy assigned to a higher-priority LAN-to-WAN rule. Then repeat the same traffic test.

For the DPI path, also open Log viewer > SSL/TLS inspection, search for the URL in Server name, and check Action and SSL/TLS rule. A URL IoC requires Decrypt. If the match shows Don't decrypt, the rule ID identifies the exception or rule that bypasses decryption. Add a narrow URL group to a higher-priority Decrypt rule only after making this attribution. Roll out TLS Inspection step by step describes the controlled approach.

If a feed produces no relevant hits over a representative observation period, reassess its value. First confirm that retrieval and the inspection path are working, and check whether MDR, NDR, or X-Ops already detect the same IoCs. A short test without hits is not a reason to delete the feed. If the feed is genuinely redundant after these checks, document its name, URL, indicator type, action, position, polling interval, and the secure storage location of its credentials before deleting it. Under Protect > Active threat response > Third-party threat feeds, delete the reviewed feed to free up storage. Then check Refresh, Storage quota, and Active feeds, and use Synchronize now to retrieve a feed that previously failed with Storage full again. To restore the deleted feed, recreate it using the documented values, initially on Monitor. Temporarily disabling a feed for rollback remains a separate process; it is not treated as evidence that storage has been freed.

Handle false positives

For an incorrect block, first open the log entry and document the feed name, Log/Drop action, match direction, source and destination or URL, protocol, and ports. Then confirm that the traffic is legitimate, report the affected indicator to the feed provider, and create only the narrowest possible exception with a reason, owner, and review date.

A broad exception for entire networks is not a clean solution. For domain or URL hits, TLS Inspection, a web policy, DNS Protection, or another security feature may also be involved.

Create a controlled exclusion under Protect > Active threat response > Add threat exclusions. Under Host and network exclusions > Add new item, select existing host or network objects. Under Threat exclusions, enter one IP address, domain, or URL; an entry can contain no more than 128 characters. After Add and Apply, repeat the same traffic test and confirm in the Log Viewer that only the expected detection is absent.

⚠️ A threat exclusion applies to every Active Threat Response module, not only to the feed that caused the false positive. Before clicking Apply, assess the effect on MDR, NDR, Sophos X-Ops, and third-party threat feeds. Document the entry, reason, owner, and review date, and remove the exclusion when it is no longer required.

Backup and restore

A firewall backup contains the Third-Party Threat Feed configuration, but not the downloaded lists. After a restore, the firewall immediately retrieves the sources again and applies the configured action. DNS, internet access, certificate validation, and credentials must therefore work immediately after recovery.

Threat Feed configurations cannot be imported or exported separately; Threat Exclusions, however, can. After a restore, check feed retrieval, IoC count, and traffic effect again.

Automating ThirdPartyFeed via XML

To automate the same feed configuration, the XML interface uses the ThirdPartyFeed object. It configures retrieval and the action, not the individual downloaded IoCs. Access, explicit write operations, version-dependent request construction and secure response evaluation are explained under Securing XML API access. Confirm the complete write request and required fields for the installed SFOS 22 or 23 build before making changes. Before use, confirm the specific Add/Edit operation and its payload in API help for the installed build. If the syntax is unclear or sources conflict, do not write; clarify the issue with Support instead.

Before making a change, identify the existing feed by its Name in WebAdmin and record its name, indicator type, URL, action, enabled state, position and polling interval. The name identifies the feed configuration, not the provider or an individual IoC. The same provider may have several separately named configurations for IPv4, domains and URLs. Do not infer unverified rename, upsert or overwrite semantics from the object name.

• Identity and source: Name is required, allows a maximum of 63 characters and permits only letters, numbers, underscores and hyphens. Description is optional and limited to 255 characters. ExternalURL is required and limited to 1024 characters; continue to use a directly accessible HTTPS plain-text feed with one indicator per line.
• Action and order: Action requires exactly block or monitor, corresponding to Block or Monitor in the UI. monitor logs matches without blocking through the feed; block logs and blocks. The labels Log only and Log and drop used in other modules are not substitute values for this field. Position allows top or bottom, corresponding to Top or Bottom. This selects the position within Third-Party Feeds, not their precedence over MDR, NDR Essentials or Sophos X-Ops. Block and Monitor lists remain separate; the first match in each list is decisive.
• Indicator type: IndicatorType requires ip, domain or url, corresponding to IPv4 address, Domain or URL. Here, ip is not an IPv6, network or range type. Create a separate configuration for each required indicator type.
• Authentication: Authorization requires noAuthentication, basicAuthentication or apiKey. Only Basic Authentication uses Username and Password, each with a maximum of 64 characters. Only API key authentication uses Key, Value and AddTo: the key name and secret value are separate and each is limited to 64 characters; the transmission location is exactly header or queryParam, corresponding to Header or Query parameters. The provider’s requirement determines this, not an assumed default. Use only the fields belonging to the authentication method; obtain secrets from a protected secret store and keep them out of XML files in the repository, URLs in tickets, shell history, screenshots and logs. For query parameters, pay particular attention to masking logged feed URLs.
• Certificate validation: ValidateServerCertificate is required; the object example shows true and false. For secure operation, explicitly enable validation and establish the appropriate CA trust beforehand. A TLS or authentication error does not justify disabling validation.
• Polling interval: PollingInterval is required and allows only 5m, 15m, 30m, 1h, 6h, 24h, 7d or 30d. These are fixed tokens, not an arbitrary number of minutes. On XGS 87/87w, 88/88w and 107/107w, the selection remains restricted to 24h, 7d and 30d. For example, 1h suits an hourly provider update only on a model that supports this interval.
• Enabled state and defaults: For Enabled, the parameter table lists 1 and 0, whereas the object example shows true and false. This is an unresolved difference in representation, not evidence that the forms are interchangeable. Before attempting a write, clarify which form is valid in the installed build. The table also lists monitor, top, ip and noAuthentication as defaults for the corresponding fields; check the actual values on the installed build. Set the action, position, type and authentication deliberately rather than relying on omitted values.

Interpreting Add/Edit responses safely

The following mappings are documented for Add Third-party threat feed and Edit Third-party threat feed. The Message.* values are unresolved message symbols, not literal error messages or sufficient instructions for action on their own:

In particular, 409 / Message.CPResourceConflict belongs to Add, and 404 / Message.CPRecordNotFound belongs to Edit. Do not equate these object-specific mappings with general XML codes or an HTTP transport status; the actual response and Status Message Information in the build are decisive. After every change, compare the saved feed in WebAdmin with the intended values and check the Audit Trail. In the event of an error, timeout or unclear response, first check the state actually saved before sending an Add or Edit again. Do not infer an automatic retry, renaming or supposed fix from a symbol.

An appropriate configuration response proves neither feed retrieval nor IoC content nor any effect on traffic. Afterwards, continue to check Test connection, Synchronize now, Last updated, Storage quota, an expected IoC and a controlled Monitor traffic test. Switch to Block only after this check; in the event of unexpected failures, restore the recorded action or disable the feed in a controlled manner as described above, rather than setting a global Threat Exclusion as a substitute.

Cybora Threat Feeds for Sophos Firewall

Cybora delivers its IPv4, domain, and URL feeds as HTTPS text files with one indicator per line. Its public product description says that it combines OSINT and community sources, commercial threat intelligence, honeypots, sensors, and firewall signals. The format therefore fits the SFOS third-party interface directly, but a Monitor pilot must still establish the feed’s value in the local network.

Cybora serves here as a specific provider example. Apply the same technical selection criteria as for any other provider: suitable indicator types, a directly retrievable file, freshness, acceptable false positives, traceable hits, and an accessible correction process.

Compare plans

Free (Basic) contains IPv4 indicators only and is updated every 24 hours, making it suitable for validating delivery and SFOS compatibility before purchase. Standard provides IPv4 and a smaller domain set every six hours. Premium provides IPv4, domains, and URLs hourly, while Ultimate provides the same indicator types every 15 minutes. On XGS 87/87w, 88/88w, and 107/107w, however, the shortest selectable SFOS polling interval remains 24h, regardless of provider plan.

Beyond quantity and price, freshness, supported indicator types, source quality, update interval, false-positive risk, and traceability in the Log Viewer matter. The right feed is the one that produces relevant hits with acceptable side effects in the local environment.

Avanet Firewall Network

Part of the Premium feed comes from a distributed firewall network. This perspective helps identify attack patterns that are barely visible on a single firewall.

In distributed brute-force attacks, each bot makes only a few failed login attempts and often remains below a local threshold. Combining anonymised signals reveals IP addresses that systematically attack infrastructure across multiple systems. This creates a continuously updated Threat Intelligence Feed for automated defence.