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. For the local Log Viewer, this is Local reporting. XGS 87/87w and 107/107w do not support local reporting; use Sophos Fusion or a syslog server on these models.
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. An API key can be sent in the Header or in Query parameters; its value and the password for Basic Authentication 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 the download, but not that the expected traffic is actually detected or blocked. Validate this effect separately in the Log Viewer.

Choose the right feed and action

Supported indicators

A feed contains exactly one of these 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. IP ranges, IPv6 addresses, networks, wildcard domains, and regular expressions cannot be used in Third-Party Threat Feeds as substitutes for individual supported IoCs.

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.

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 and requires the Xstream Appliance Bundle.
• 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 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.

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

A successful connection and Sync status: Success prove only that the firewall could download and read the list. 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, Total threat indicators, and Storage quota. Refresh only updates these displayed counters. Synchronize now, by contrast, retrieves the selected feed immediately. Individual IoCs can be opened and searched through Threat indicators or through the indicator count of the relevant feed.

For an Authentication error, check the API key or credentials. For a Connection error, check DNS, internet access, the HTTP status, and the feed server. An SSL/TLS error points to the certificate or certificate chain, while Failed often indicates the feed format or invalid indicators.

If storage is full, 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, 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.

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. Host and network exclusions use 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 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.

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.